72 lines
5.4 KiB
Markdown
72 lines
5.4 KiB
Markdown
---
|
|
eip: 2035
|
|
title: Stateless Clients - Repricing SLOAD and SSTORE to pay for block proofs
|
|
author: Alexey Akhunov (@AlexeyAkhunov)
|
|
discussions-to: https://ethereum-magicians.org/t/eip-2035-stateless-clients-repricing-sload-and-sstore-to-pay-for-block-proofs/3284
|
|
status: Stagnant
|
|
type: Standards Track
|
|
category: Core
|
|
created: 2019-05-16
|
|
---
|
|
|
|
## 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](https://medium.com/@akhounov/data-from-the-ethereum-stateless-prototype-8c69479c8abc).
|
|
|
|
## 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](https://github.com/holiman/vmstats/blob/master/README.md) 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](./eip-2028.md), 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](./eip-1884.md) 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](./eip-2028.md) 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](./eip-2026.md) (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
|
|
Copyright and related rights waived via [CC0](../LICENSE.md).
|
|
|