Skip to main content

Validation Budgets and Stablization Window

· 3 min read

Final Update:

The updated release had some issues with loading ledger snapshots on first-generation Hotspot hardware, and we had to cut the 2020.08.26.0 release in order to reduce snapshot import memory usage. Since the only new behavior was core PR 599, we did a very short beta to confirm the fix for the issue and released the image to GA around 12:30PM PDT.

Original Post:

The 2020.08.25.0 release focuses primarily on to changes to the functioning of the consensus group.

Heretofore, the group used a particular block as the start of its stabilization window (the time period over which we attempt to maintain the one block per minute cadence). With this release we move to a rolling 100000 block window to maintain responsiveness and to adapt to the post-snapshot world where most new Hotspots don't have the target block. Prior to this release we also simply failed to the present block when calculating the catchup time, and this release we use the earliest available block if the target block for the start of the window is not available.

We've been seeing a lot of long block times recently, for which we apologize. A major source of disruption that we've seen is that transaction validation times have bloated as the size of the network has grown. In particular, the most expensive part of validating or constructing a block is the verification of Proof of Coverage receipts. We've noticed that a class of these are extremely expensive to validate for various reasons. As a result, we're adding a time budget for the verification of any individual transaction. This may result in the lower receipt acceptance rates for certain Hotspots, but we've set the budget generously at a limit that we think will not affect most users, but should improve chain stability.

This release also bumps the blessed snapshot to 468001.

Update: We found an issue with the windowing adjustments that wasn't revealed by the beta process (it only caused issues on consensus group members) which we have now fixed in release 2020.08.26.0, which contains all of these PRs plus two additional changes to fix the issue.




We have been betaing 2020.08.25.0 since last night and expect to release it to GA this morning.

Update: We found a critical issue at the last moment and cut another image (2020.08.26.0), which will go through the beta process and be deployed as soon as this evening.