Change block delay to 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:
/// The maximum number of milliseconds to wait before proposing a batch.
pub const MAX_BATCH_DELAY_IN_MS: u64 = 5500; // ms
/// The minimum number of seconds to wait before proposing a batch.
pub const MIN_BATCH_DELAY_IN_SECS: u64 = 5; // seconds
Put this in discord and also putting here:
some interesting numbers for you from our end over at Puzzle. TLDR; looks like for every 10k we add to our Arcade WAU numbers, we add 50k txns and increase consensus block times by ~0.5s. Because of this fact -- in our opinion -- this ARC should be held off until November when we have more data from Coinbase Quest full launch and it's effects on consensus block times to see if they are in line with what we see.
Background on data below: October 2nd -- we thought most mainnet kinks were worked out so we kicked off Puzzle Arcade campaigns with communities we've been working with for past few months Oct 2 & Oct 3rd our costs blew up from paymaster and oct 4th we had to ask communities to stop using/chill out -- was costing us too much and validator rewards wouldn't have chance of covering at current delegation see here: https://x.com/lets_puzzle/status/1842360983605637450
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: 25,568 Puzzle txns 3.04 s/block start block: https://aleoscan.io/block?h=798610 end block: https://aleoscan.io/block?h=827030
October 3rd: ~11k Arcade WAUs 50,726 Puzzle txns 3.41 s/block start block: https://aleoscan.io/block?h=827030 end block: https://aleoscan.io/block?h=852349
Back of napkin projections: 20k Arcade WAUs 100k Puzzle txns ~4 s/block
30k Arcade WAUs 150k Puzzle Txns ~4.5 s/block
40k Arcade WAUs 200k Puzzle Txns ~5 s/block
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. For this analysis, we identified the longest continuous sequence of blocks in the entire history of the mainnet. This sequence consists of 13,309 blocks. The average time to create a block in this sequence is 3.0443 seconds. The maximum delay recorded is 12 seconds.
Height, Transfers, Delay: 660038, 131, 12 668226, 143, 12 660300, 126, 11 670953, 170, 11 670564, 102, 10
The highest number of transactions recorded is 196.
Height, Transfers, Delay: 672520, 196, 10 672883, 188, 9 673028, 174, 10 673033, 173, 9 670953, 170, 11 672996, 168, 6
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 Delay = 10 seconds, when transfers ≈ 275.
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.
Updated the code in the latest commit based on @raychu86 recommendations, I'm still testing this in isolation. Would be great if others can also run tests to validate if block times are ~10 seconds. Goal is to then test this on Canary.