[Review] Total Transaction Data Limit

[gastonponti]

Simple Summary

Add a limit of how much total transaction data can be in a block.

Abstract

Add a limitation on the size of the block transaction data to allow us to future gas limit increments without putting at risk the health of the network.

Motivation

As part of Celo’s pursuit of processing more transactions per second, we constantly search for different ways to increase the gas limit without degrading the performance of every node. Increasing the gas limit of the block roughly translates to more processing and more space available for calldata. With the current recommended validator specs, the network is able to handle more bytecode execution but can face limitations with the byte block size.

There’s a data limit on the networking layer that introduces failure the moment network messages surpass 10M size. This is also problematic since relaying 10M messages on the p2p network signifies a lot of bandwidth consumption.

To address this problem, this CIP proposes to define a limit to the size of the block (in bytes), not just in gas. This way, malicious actors would not be able to generate very big data blocks that could harm the health of the network.

Enabling this CIP would allow the Celo network to increase the gas limit for blocks, since the risk of using gas to create very large data blocks will be managed separately.

Specification

Parameter	Value
MAX_TX_DATA_PER_BLOCK	5,242,880 (5MB)

Add a rule that a block is only valid if:

sum(len(rlp(tx)) for tx in block.txs) <= MAX_TX_DATA_PER_BLOCK

Rationale

In order to enforce a max size per block, the CIP modifies block validation rules to limit the amount of bytes that can be consumed by transactions. The rest of the block is not dynamic so doesn’t need to be computed every block. The only exception is the Epoch Block that contains the diff in the validator set, but this is also limited by the number of validators to be elected.

As transactions are serialized as an RLP string, the limit is enforced by the RLP encoded version of them.

The elegance of this solution is that it’s invisible for dApp developers and protocols, since there are no changes to execution rules; only changes to how many or how big transactions included in a block can be. Alternative solution would have been to define different costs for data than for execution or making calldata more expensive in terms of gas; but those would have affected dApp developers and protocols.

To set some examples aimed to explain the rationale behind the 5MB decision, more than 95% of the transactions that we handle today have less than 500 bytes. If we assume a block full of these common transactions, with a media of gas consumption of 150k gas, we are talking about a maximum of 10485 transactions, which translates to process 1500M gas. We feel confident that this limit won't change any usage on our network, but will add a new layer of security from malicious attacks that will allow us to increase the block limit without facing issues.

Backwards Compatibility

This change implies a change in protocol rules, more precisely in rules of block validation. As such, it is a breaking change and requires a hard fork. It also requires validators to change rules on how valid blocks are created.

But, as mentioned above, it does not affect users, nor dApp or protocol developers.

Implementation

An implementation suggestion is available at celo-org/celo-blockchain#2174

Security Considerations

No security considerations as the limit proposed in this CIP is bigger that the one we have in production (~4.7MB using the worst case scenario of having 20M gas / txZeroData(4)).

License

This work is licensed under the Apache License, Version 2.0.