How are block interval, block size and effective throughput related?

Question

I have two questions:

1. Why does the effective throughput (as defined below) decreases when the block interval is decreased?
2. How does a reduction in the block size results in maintaining a high effective throughput?

The origin of these questions is as follows. First, this paper about Scaling Decentralized Blockchains says:

To improve the system’s latency, we can in principle simply reduce the block interval. To do so while retaining high effective throughput, however, would also require a reduction in the block size.

which implies that the effective throughput decreases when the block interval is decreased. This results in my first question.

Second, they define effective throughput as follows:

X% effective throughput := (block size)/(X% block propagation delay)

This formula indicates a decrease in effective throughput when the block size is decreased, while their goal is the opposite, i.e. maintaining a high effective throughput (by decreasing the block size). This is what my second question is about.

Answer 1

First off, it is worth noting: this paper is not only talking about throughput in the 'transactions/second' sense, it is also addressing the effects of block size and interval on the network's latency (which is an important factor in scaling blockchain networks). The authors define 'effective throughput' as:

Our results hinge on the key metric of effective throughput in the overlay network, which we define here as which blocks propagate within an average block interval period the percentage of nodes to.

I find this confusingly written, but understand it to mean "within the period of time defined by the average block interval, what percentage of the network's nodes will have received and validated the most recent block".

As a simple example of why this metric is important: if only 50% of nodes can download and validate blockheight X before blockheight X+1 is mined, then the other 50% of nodes will be continuously playing catch-up, and will not be able to meaningfully contribute to the network. This hurts network decentralization, as less users will be able to directly participate in the network.

Why does the effective throughput (as defined below) decreases when the block interval is decreased?

To understand this, consider an extreme example: a blockchain with 1GB blocks every 10 minutes. In order for nodes on the network to stay in sync with the chain, they will need to download and verify the validity of 1GB worth of blockdata every 10 mins. Any nodes which cannot do this, will decrease the 'effective throughput' of the network.

So now, consider what happens if you decrease the block interval to 1 min. Suddenly, a lot of nodes that could download and process that data within 10 mins will no longer be able to keep up with the rest of the network, since they now only have 1 min to do the same. Thus, our 'effective throughput' has decreased, since a much smaller percent of nodes will be able to engage and contribute to the network.

How does a reduction in the block size results in maintaining a high effective throughput?

I think your confusion here comes from thinking about throughput in terms of 'transactions/second'. Decreasing the blocksize would result in less transactions/second, but it would also mean a node would have to download and validate less data per block interval. In relation to the author's definition of 'effective throughput', we see that lowering the resource requirements for a node will allow more nodes to join the network.

Second, they define effective throughput as follows:

X% effective throughput := (block size)/(X% block propagation delay)

This formula indicates a decrease in effective throughput when the block size is decreased, while their goal is the opposite, i.e. maintaining a high effective throughput (by decreasing the block size).

Decreasing the block size variable would also affect the X% block propagation delay variable. So if a lower block size results in a higher throughput, we would expect that the X% block propagation delay would see a larger relative decrease than the decrease in block size.

Answer 2

Let's think of blocks as a basket. Each transaction is an apple weighing 0.1 kg. You are the network. Currently, let's say we have a basket large enough to carry 1000 apples (10kg). As the network, it takes you around 100 seconds to carry this from point A to B.

Our throughput is 10kg/100seconds = 0.1 kg per second.

Now, we want to increase this.

Our options are to either reduce the amount of time it takes to carry the basket, or increase the size of the basket.

Let's increase the size of the basket first. Now, we can fit 2000 apples (20 kg). However, because it is now heavier, it takes us longer than 100 seconds to carry it from point A to B. With a linear scale, we would expect it to now take twice as long, or 200 seconds. Thus, this doesn't actually increase throughput, since 20kg/200seconds = 0.1 kg per second

What if we try to change the time instead?

As we saw, the time increases when capacity (weight) increases. Thus it should decrease when capacity decreases, but that would essentially have the same effect as we saw with the capacity increase.

However, what if we simply reduced the distance from point A to B? If it's only half the distance, we can carry the same capacity in half the time. Thus, 10kg/50seconds = 0.2 kg per second. We doubled our throughput! Unfortunately, this comes at the cost that our network's reach has been halved.

In the case of Bitcoin and other cryptocurrencies, the same problem can be restated. The distance A to B is the peer-to-peer network. The capacity (or size) of the basket is the blocksize, and apples are transaction.

A good network is one where we have an optimal block size for containing as many transaction as possible, while still being able to broadcast that block efficiently to the rest of the network. Since mining depends on the miners being able to build on top of the latest block, it is very important that participants are notified of the latest block as soon as possible.

If we have 100 MB blocks, it would take a very long time to broadcast this to enough of the network. This would mean that we have to increase the blocktime sufficiently, so that mining can still take place fairly.

Similarly, going in reverse, if we were to reduce the block time, we would also need to reduce the block size so that blocks are still broadcasted quickly enough to work with the faster block time.

Bitcoin is not the best example of this, due to a relatively low block size with a relatively high block time. It would be feasible to increase the block limit without requiring adjustment on the other factors (indeed, this is essentially what segwit did in a slightly roundabout manner).

A better example may be Ethereum. There is no fixed block size in ethereum. Instead, miners vote on a parameter known as max gas, which is essentially a measure of the computation needed to verify a block. A higher max gas implies more transactions, and thus a larger block size.

This factor is constantly adjusted by ethereum miners based on how efficiently blocks are being propagated at the current size. If the network is too large for the current size, we would expect to see a lot of orphan blocks (or uncles, as ethereum calls them) since some miners on the network will still mine on an older block after a new one has already been found. If this is the case, we will see max gas reduce, and thus reduce the block size. If the opposite is true (where very few uncles are found), max gas may increase.

Eventually, the network will find an equilibrium between an acceptable orphan rate, and an optimal block size that allows to the maximum number of transactions in a block while still permitting propagation to take place efficiently.

You can see a chart of how this limit has changed over time over at etherscan.io's gaslimit chart. Essentially, as the network has developed better technologies to relay blocks quickly, we have seen the block size increase. However, it's not a very large increase, indicating that it is still bottlenecked by the network layer and block verification time.