Block time measurement in horizontally-scaled networks

Jaack
Avascan
Published in
4 min readMay 8, 2023

When it comes to the solution for scalability, we know that there could be two ways of solving it: either by scaling vertically or horizontally.

When scaling a blockchain network vertically, new layers are built on-top of a blockchain to reduce the amount of data there needs to be about a fixed set of transactions.

The solution is simple: generate and process transactions on a separate chain, put all those transactions in a list, then generate a proof attesting that the list is correct, and post the list’s title and its proof on the main chain.

This is a simplified concept, but it’s a way to describe the basic idea behind it: the solution is to virtually increase the block size, without increasing it on the main chain. This has started what is called as the ‘Blockspace War’, or ‘L2 War’: multiple L2 chains (rollups and sidechains, mostly) compete to get their transactions and proofs included in the nearest block at all time.

The quickest one, over time, is the one that has the best user experience, hence the one that will win the most users.

Time is of essence here

In the Blockspace War, there’s a fixed time constraint, that is the time is takes for a block to be produced. On ethereum, that’s about 12–13 seconds.

This is a compromise between the amount of gas a single block can ingest (gas limit) and the minimum time it takes for a block to be produced. Ethereum developers could theoretically reduce the gas limit to 2,000,000 down from the current 30,000,000 and that would bring block time down to about 2 seconds, but a lot of applications wouldn’t work, because they need a lot of gas to execute all the operations in a single block.

So the amount of transactions an L2 on Ethereum can produce will always be limited by the time it takes for a new block to be produced. We can say that L2s on Ethereum (vertical scaling) have the execution level separated from, but bound by, the consensus level.

In horizontal scaling, this is not the case. Let’s take Avalanche subnets, the case most clear (to me, at least). With subnets, validator nodes all talk to each other about ‘main chain stuff’ (transactions on the Primary Network), but some of them also talk about other stuff happening on their own chains (using a node plugin). So, a validator node could concurrently produce Primary Network blocks and their own chain’s blocks.

So the metric here is different: in horizontal scaling, block time is lower and lower across the whole network. The more subnets there are, the more blocks can be produced.

So we can say that L2s (subnets) on Avalanche (horizontal scaling, that most also call L1s depending on the point of view) have the execution level separated, and accelerated by, the consensus level.

We analyzed block times across Ethereum and Avalanche over time, and the results are very clear: Ethereum block times have a lower bound of 12 seconds, so there are times when blocks get produced over a greater time frame (peak was 30 seconds in 2017, during the Cryptokitties network clogging).

Source: Etherscan.io

L2 activity has not influenced the average block time (it’s still around 12 seconds). Surely, more transactions are processed because they’re executed off-chain, but there’s a limit to how many data validators can put in a single block.

Source: Avascan

On Avalanche, activity across the network, caused by new subnets spinning up over the course of 2022, has dramatically decreased block time from a recorded high of about 0,19 seconds (190 ms) in July 2022 (still very low compared to Ethereum), to a record low of 0,01666 seconds (16 ms) on January 3rd, 2023. Over the course of 2022, more than 5 subnets have launched in production, and you can guess when they launched by looking at the drops in block times.

Of course, transactions on all Ethereum L2s could amount to a higher number than all Avalanche Subnets, but that’s just because the availability of the data is spread between two (or more) layers. On Avalanche, each subnet is sovereign and contains every data about their own execution and consensus, minimizing single points of failure.

As more and more subnets will spin up, block time across the whole Avalanche network will likely decrease even more.

--

--