HomeEIPsNewsletter
EIPsEIP-2035
EIP-2035

Stateless Clients - Repricing SLOAD and SSTORE to pay for block proofs

StagnantStandards Track: Core
Created: 2019-05-16
Alexey Akhunov (@AlexeyAkhunov)
Discussions ForumOriginal Proposal LinkEdit
1 min read

EIP-2035 proposes to increase the gas cost of EVM opcodes SLOAD and SSTORE to accommodate the extra bandwidth required to propagate block proof together with the block headers and block bodies. This change prepares Ethereum for the introduction of block proofs, which allows any Ethereum node that wishes to receive them to process transactions in the blocks without needing to access the Ethereum state. In most Ethereum nodes, it will speed up the block processing and reduce the memory footprint of such processing. For mining nodes, however, there will be more work to do to construct and transmit the block proofs, so the extra charge (payable to the miners) is introduced. In the first phase, only contract storage will be covered by the block proofs, meaning that the Ethereum nodes will still need access to the accounts in the state, but block proofs will make it optional to have access to contract storage for executing transactions. Therefore, only SSTORE and SLOAD opcodes are affected. The motivation behind this change is to address the concern that opcodes that read the state tree are under-priced relative to other opcodes, which can degrade network performance via transaction spam. The costs have been derived from an updated version of the calculation table used to generate the 1.0 gas costs, and the rules attempt to target a limit of 8 MB of data that needs to be read in order to process a block.

Video
Anyone may contribute to propose contents.
Go propose
Original

Simple Summary

The gas cost of EVM opcodes SLOAD and SSTORE increases in order to accommodate extra bandwidth required to propagate block proof together with the block headers and block bodies, as explained here.

Abstract

It is part of the State Rent roadmap. This particular change prepares Ethereum for introduction of the block proofs (current understanding is that they can be introuced without a hard fork). The introduction of the block proofs allows any Ethereum node that wishes to receive them, to process transactions in the blocks without needing to access the Ethereum state. All necessary information for the execution (and the proof of validity) is continued in the block proofs. In most Ethereum nodes, it will speed up the block processing and reduce the memory footprint of such processing. For mining nodes, however, there will be more work to do to construct and transmit the block proofs. Therefore, the extra charge (payable to the miners) is introduced. In the first phase, only contract storage will be covered by the block proofs. It means that the Ethereum nodes will still need access to the accounts in the state, but block proofs will make it optional to have access to contract storage for executing transactions. Therefore, only SSTORE and SLOAD opcodes are affected.

Motivation

There is empirical analysis showing that SLOAD opcode is currently underpriced in terms of execution latency it adds to the block processing. The hypothesis is that it is due to the latency of the database accesses. In the same analysis, SSTORE is not considered, because its effect on the database accesses can be (and are in many implementations) delayed until the end of the block. Stateless clients approach to the contract storage will largely negate that latency because no database accesses will be required. Instead, bandwidth consumption goes up. There is emprical analysis (unpublished, but will be) suggesting that 1 uncached SSTORE or SLOAD adds at most 1 kB to the block proofs. At the current cost of data transmission (68 gas per byte), this translates to the increase of gas cost of both operations by 69k gas. However, in light of proposal in EIP-2028, the increase can be made much smaller.

Specification

Not very formal at the moment, but will be formalised with more research and prototyping. Gas of operations SLOAD and SSTORE increases by X gas when the storage slots accessed (read by SLOAD or written by SSTORE) were not previously accessed (by another SLOAD or SSTORE) during the same transaction.

Future variant (will be possible after the implementation of the Gross contract size acccounting) is researched, where the increase is varied depending on the size of the contract storage, i.e. SLOAD and SSTORE for smaller contracts will be cheaper.

Rationale

EIP-1884 seeks to increase the gas cost of SLOAD but using a different justification (latency of the execution as described in the Motivation). This EIP is likely to increase the cost of SLOAD by a larger amount, therefore partially (because EIP-1884 also proposed other increases) supersedes EIP-1884.

EIP-2028 describes the model that can be used for deciding the gas cost of data transmission. It is relevant because in the stateless client regime SSTORE and SLOAD operations add more data to be transmitted (as well as computation to verify the proofs).

The main alternate design is the rent proportional to the size of the contract storage, which unfortunately introduces a serious griefing vulnerability problem, and so far the solution seems to be in redesigning and rewriting smart contracts in a way, which makes them not vulnerable. However, this approach is likely to be very expensive on the non-technical (ecosystem) level.

Backwards Compatibility

This change is not backwards compatible and requires hard fork to be activated. There might also be an adverse effect of this change on the already deployed contract. It is expected that after this EIP and EIP-2026 (rent prepayment for accounts), the recommendation will be made to raise the gas limit. This can somewhat dampen the adverse effect of EIP. The most problematic cases would be with the contracts that assume certain gas costs of SLOAD and SSTORE and hard-code them in their internal gas computations. For others, the cost of interacting with the contract storage will rise and may make some dApps based on such interactions, non-viable. This is a trade off to avoid even bigger adverse effect of the rent proportional to the contract storage size. However, more research is needed to more fully analyse the potentially impacted contracts.

Test Cases

Tests cases will be generated out of a reference implementation.

Implementation

There will be proof of concept implementation to refine and clarify the specification.

Copyright and related rights waived via CC0.

Further reading
Anyone may contribute to propose contents.
Go propose

Not miss a beat of EIPs' update?

Subscribe EIPs Fun to receive the latest updates of EIPs Good for Buidlers to follow up.

View all
Serve Ethereum Builders, Scale the Community.
Resources
GitHub
Supported by