EIP-2028 Transaction data gas cost reduction
Final · Fees & gas · EIP status Final · created 2019-05-03
Lowers the gas cost of data (calldata) carried in a transaction from 68 gas to 16 gas per non-zero byte. The cost of zero bytes is left unchanged.
Why it is needed
On Ethereum, sending data with a transaction costs gas per byte. This cost was high at 68 gas per non-zero byte, limiting how much data could fit in a block. Layer 2 scaling approaches in particular move storage and computation off-chain, which increases data transmission instead. Proof systems like STARKs or SNARKs compress the fact that computation over many transactions was done correctly into a single proof; fraud proof schemes must transmit Merkle proofs; and some approaches keep the data itself on the main chain as calldata for data availability. When calldata is expensive, all of these approaches become more costly. There was concern that lowering the cost could enlarge blocks, slowing propagation and weakening security, so the authors evaluated this using a mathematical model linking network latency and security along with empirical measurements, and proposed 16 gas based on the results.
What changes
Today
- A single non-zero calldata byte costs 68 gas.
- High data costs limit how much data can fit in a single block.
- It is costly for layer 2s to post proofs or data to the main chain.
After EIP-2028
- Each nonzero calldata byte costs 16 gas. The cost of zero bytes stays the same.
- More data can fit into a block within the same gas limit.
- Layer 2s post proofs and data to the main chain more cheaply.
Who is affected
- Users: The fee burden decreases when sending transactions with large data.
- Layer 2 operators: The cost of posting proofs and data to the main chain drops, making off-chain scaling approaches more economically favorable.
- App and contract developers: In gas calculations for calls that use a lot of calldata, the per-byte cost changes from 68 to 16.
- Client teams: The amount of data carried in blocks may increase, so the impact on propagation and processing delay becomes subject to verification. Reference implementations for Parity and Geth were provided.
In depth
Specification: changing a single constant
Only a single constant changes. The gas charged per nonzero byte of transaction data (GTXDATANONZERO) drops from 68 to 16. The gas cost of zero bytes does not change. EVM opcodes and the transaction format stay the same; only the multiplier applied to data bytes in the fee calculation changes. The original summary states that this figure is backed by mathematical modeling and empirical estimates.
Motivation: on-chain scalability, Layer 2, stateless clients
The original document gives three reasons. First, greater calldata bandwidth lets more data fit into a single block, improving on-chain scalability. Second, Layer 2s become cheaper. STARK/SNARK proof systems prove the integrity of the computation behind a large batch of transactions with a single proof, fraud-proof schemes must transmit Merkle proofs, and there is also the option of resolving data availability using calldata on the main chain. Third, stateless clients. The same model is also planned for use in pricing state access under a stateless client regime, proposed starting from State Rent version 4. Under that regime, the gas cost of state access operations is expected to rise roughly in proportion to the extra bandwidth needed to transmit block proofs and the extra processing needed to verify them.
Security model: block generation rate, chain growth rate, latency
The original document connects network latency and security using the model employed in the research of Sompolinsky and Zohar, and of Pass, Seeman, and Shelat. Lambda is the block generation rate [1/s], treating the process of finding a proof-of-work (PoW) solution as a Poisson process with rate lambda. Beta is the chain growth rate [1/s] at which new blocks are added to the heaviest chain, and D is the block delay [s], the time after a new block is mined until all miners begin mining on top of it. Not every block found ends up in the main chain (uncle blocks), so lambda >= beta, and for a blockchain using the longest-chain rule, lambda >= beta >= lambda / (1 + D * lambda) holds. This lower bound corresponds to the extreme case of a clique topology in which the latency between every pair of nodes is the maximum value D. With no latency (D=0), beta equals lambda, which confirms the model's consistency.
Efficiency and the cost of attack
An attacker trying to reorganize the main chain must produce blocks faster than beta. If the proof-of-work difficulty is fixed, the system's total hashrate correlates with lambda, so beta / lambda is defined as the system's efficiency, meaning the fraction of total hashpower actually used to extend the main chain. Rearranging the inequality above gives the lower bound beta / lambda >= 1 / (1 + D * lambda). If calldata becomes cheaper and blocks grow larger, the network delay D from transmission increases, and as delay increases, fewer nodes know the latest state, which lowers the cost of attacking the network. This EIP is a proposal that quantitatively weighs this relationship to determine the size of the reduction.
Decomposing delay: propagation delay and processing delay
Delay D depends on the location of mining nodes and a network topology that constantly shifts, making it hard to measure directly. In prior research, Decker and Wattenhofer showed that propagation time grows in proportion to block size, and Vitalik Buterin showed that the uncle rate, which is closely tied to efficiency, grows with block size. The original document splits delay into D = D_t + D_p, where D_t is the delay caused by block transmission and D_p is the delay that arises as nodes process a block. It assumes that calldata affects the two factors differently and tests each separately. This distinction matters in particular because calldata for Layer 2 and stateless clients is mostly Merkle authentication paths, so D_t is large while D_p is relatively small.
Validation plan, reference implementation, current status
Two kinds of tests were planned to set the gas cost. The first is a network test on Ethereum mainnet that estimates the effect of increased block size on D_p and D_t, total delay D, the efficiency ratio, and latency between mining pools. It includes regression tests on existing data and stress tests that create extreme conditions. The second is a local test on a single node that measures processing time as a function of calldata volume and the gas limit for ordinary operations. The reference implementations were provided as pull requests for Parity and Geth. The original status is Final, meaning the specification is a finalized proposal.