-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Change block delay to 5 seconds #3412
base: staging
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Noticed one mini cleanup which you could add in this or a future PR: MIN_BATCH_DELAY_IN_MS
in the comments should be renamed to MIN_BATCH_DELAY_IN_SECS
.
Put this in discord and also putting here: some interesting numbers for you from our end over at Puzzle. Background on data below: so in light of adjusting block reward algorithm we ran numbers to see how this increase in activity effected consensus and run quick analysis on projections of what it will do to consensus times/block rewards down road October 2nd: October 3rd: ~11k Arcade WAUs Back of napkin projections: 30k Arcade WAUs 40k Arcade WAUs Based on this quick analysis -- we think it's best to wait and see how this is effected with the coinbase ramp with Leo Wallet, Pondo, Verulink, and Arcane during this month. If their numbers lineup with ours and based on number of transactions we expect coinbase to see alone, we are likely to hit 5s/block in November. And that is not counting what we are trying to grow to in November at Puzzle as well. There is a chance we get to 10s/block based on activity alone -- not even counting increasing validator set. Most importantly, I think it's good incentives we should be having as a community. We should be incentivized to fix this issue by driving more demand to the chain usage and its dapps as a community and increasing the validator set as a community. I'd rather community pressure be set to keeping highest performant blockchain possible while driving increase in validator set & chain usage to solve this problem rather than making the blockchain artificially slower. Happy to hear any other arguments and change mind for making the the blockchain 40% slower before increasing usage or increasing validators which could potentially get us there in the coming month based on existing production data Also should state we don't mind trying for a month as it seems like a relatively easy change to make. Trying for a month to try to time is as it happens in real time until we see those nominal increases from CB / chain usage or increase in validator activity is fine as well -- but that's just the data that we are seeing from our own usage increase campaigns at Puzzle from first week of October. |
In my testing of 4 and 8 validator networks this resulted in consistent block times of 11 seconds |
The Everstake team analyzed the impact of transaction volume on block creation delays. Height, Transfers, Delay: The highest number of transactions recorded is 196. Height, Transfers, Delay: The maximum block height is 673182, and the minimum block height is 659874. The correlation between transfers and delay is 0.4744 (not very close to 1, but also not close to 0, suggesting a relationship, though other factors are also influencing this). The intercept is 2.1196 → indicating that the base block creation time is 2.12 seconds. The regression coefficient is 0.029 → meaning an increase of one transaction leads to an increase in delay by 0.029 seconds. Delay = 0.029 * transfers + 2.1196 We believe that setting an artificial MIN_BATCH_DELAY_IN_SECS=5 (as proposed by @zkxuerb in the discussion here) is a compromise between validators and provers. This adjustment would help align the inflation curve with the one planned in the tokenomics. We believe the Aleo network is in the initial stage now and has significant potential for further organic growth, and increasing the number of transactions per block will lead to the desired 10-second delay when the number of transactions approaches 275 per block. |
node/bft/src/lib.rs
Outdated
@@ -49,9 +49,9 @@ pub const CONTEXT: &str = "[MemoryPool]"; | |||
pub const MEMORY_POOL_PORT: u16 = 5000; // port | |||
|
|||
/// The maximum number of milliseconds to wait before proposing a batch. | |||
pub const MAX_BATCH_DELAY_IN_MS: u64 = 2500; // ms | |||
pub const MAX_BATCH_DELAY_IN_MS: u64 = 5500; // ms |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why was this change necessary?
node/bft/src/lib.rs
Outdated
/// The minimum number of seconds to wait before proposing a batch. | ||
pub const MIN_BATCH_DELAY_IN_SECS: u64 = 1; // seconds | ||
pub const MIN_BATCH_DELAY_IN_SECS: u64 = 5; // seconds |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A fixed delay of 5 seconds per proposal will always result in a block time that is >10 seconds, which is incorrect. Notice that the current wait time of 1 second already does not incur a blocktime of 2 seconds, because of all the overhead required to craft the block itself.
More importantly, increasing this wait-time arbitrarily will BREAK validator nodes that are syncing near tip, because they will see existing blocks that are accurate with 1 sec wait times and believe they are invalid.
(In other words: A migration could halt the chain. You can test this by first running a network with 1 second wait times, then turning off all nodes and spinning up with the 5 second wait time. Certain validators will halt, and if that number is >1/3 then the network is stopped.)
The better approach is to keep the fixed minimum at something low (like 1 second) and introduce an additional wait-time that honest validators will follow based on the current network load. (This could in theory be a naive 5 seconds).
Motivation
The motivation behind this change is to stabilise the network's inflation rate as it is currently higher than planned since block times are 3 seconds but the economics were modelled over 10 seconds.
This is a short term fix by adding a constant. The longer term fix would be dynamically calculating the block reward ( or block delay ) based on an average block time taken from past x amount of block (TBD).
Test Plan
Tested on an isolated network. Empty block times are 8 seconds to allow for a buffer to 10 seconds because the block time increases with more transaction load.
Changed two constant: