Change block delay to 5 seconds

[zkxuerb]

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

[vicsn]

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.

[mwyatt896]

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.

[Meshiest]

In my testing of 4 and 8 validator networks this resulted in consistent block times of 11 seconds

[everstakemasha]

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.

[raychu86]

Why was this change necessary?

[raychu86]

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).

[zkxuerb]

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.