Reduction of block time

[ngurmen]

Hello Everyone,

I have a question regarding the min block time in a subnet. What kind of considerations we would need to think about in terms of things like network load, machine specs, etc. if we want to cut the block time of a subnet in half? I would appreciate any feedback on this.

Thanks,
Nihat

[aaronbuchwald]

Hey @ngurmen , reducing the block time has a number of effects.

For consensus protocols that can offer sub-second finality, the time to finality is dominated by the VM's targeted block production rate instead of the latency of the consensus protocol itself.

The tradeoff for the VM's block production rate is that by increasing the frequency of block production the VM will not be able to batch as many transactions into a block and may not amortize the cost as effectively.

Producing more blocks means more blocks to store/sync and and more merkle trie roots to commit to disk for the same total amount of work (assuming that the choice is between committing N transactions into either 2 blocks over 2s or 1 block over 2s).

Committing blocks more frequently results in writing merkle trie roots or diffs that need to be stored, whereas batching the same data into a single block will frequently result in a smaller representation on disk.

To see how this impacts the machine specs required for nodes on your subnet, it will be specific to the workload on your subnet. To determine this, I'd recommend creating a representative workload of activity on your subnet (note: the active state size and historical state size of an archival node are important to take into consideration here since the cost of storing state will be very different for a fresh network vs. a persistent network for a long period of time) and empirically determine what machine specs are necessary to handle it when switching from 2s to 1s if you want to get an accurate estimate.

[ngurmen]

Hi @aaronbuchwald, thank you for the information. I would like to follow up with a question from a different angle. Would the subnet be more susceptible to chain reorgs with a smaller min block time? Would there be a need for adjustment of block acceptance parameters to compensate for that? If it is compensated would this compensation negate the benefits of reducing the min block time by half?

[aaronbuchwald]

As soon as a block is accepted, it is finalized in the Avalanche consensus model.

Most other blockchains expose non-finalized data or different levels of finality, which take into account some notion of depth, which must be handled at the application level ie. latest, finalized, safe, etc.

Since Avalanche offers full finality after only a second or two, Subnet-EVM by default only exposes accepted data over the API to reduce the complexity of handling different statuses at the application level.

That being said, it is still possible for there to be a different tree of processing blocks BEFORE they are accepted (see here: https://github.com/ava-labs/avalanchego/blob/master/vms/README.md#implementing-the-snowman-vm-block). These blocks can still be re-orged by the VM before anything gets accepted. However, in practice, the ProposerVM (https://github.com/ava-labs/avalanchego/blob/master/vms/proposervm/README.md) provides a soft proposer mechanism so only one validator proposes a block at a time and most blocks are accepted without any conflicts, such that there is no need for reorgs.

As a result, the main concern for reducing the block time imo would be about how the VM will handle state and not about any ramifications in consensus or how the application layer needs to handle consensus results.

[ngurmen]

I appreciate your time. Thank you.