This EIP describes a scheme to charge for data in state, and 'archive' data which is no longer being paid for. It also describes how resurrection of 'archived' data happens.
## Motivation
The Ethereum blockchain in its current form is not sustainable because it grows
indefinitely. This is true of any blockchain, but Ethereum grows faster than most chains.
Many implementation strategies to slow down growth exist. A common strategy is 'state
pruning' which discards historical state, keeping only the active copy of contract data
and a few recent versions to deal with short-range chain reorganizations. Several
implementations also employ compression techniques to keep the active copy of the state as
small as possible.
A full node participating in consensus today requires storing large amounts of data even
with advanced storage optimizations applied. Future storage requirements are unbounded
because any data stored in a contract must be retained forever as dictated by the
protocol. This EIP attempts to correct this by adding new consensus rules that put an
upper bound on the size of the Ethereum state.
Adding these new rules changes fundamental guarantees of the system and requires a hard
fork. Users of Ethereum already pay for the creation and modification of accounts and
their storage entries. Under the rules introduced in this EIP, users must also pay to keep
accounts accessible. A similar rent scheme was proposed in [EIP-103] but rejected
even back then because the proposal would've upset peoples expectations. As implementers
of Ethereum, we still feel that state rent is the right path to long-term sustainability
of the Ethereum blockchain and that its undesirable implications can be overcome with
The cost of storing an account over time is called `rent`. The amount of `rent` due depends
on the size of the account. The `ether` that is paid for `rent` is destroyed. The `rent` is deducted whenever an account is touched.
`rent` can be paid from the account's regular `balance` or from its 'rent balance'. Accounts
can be endowed with `rent balance` through a new EVM opcode. When `rent` is charged, it is
first taken from the `rent balance`. When `rent balance` is zero, it is instead charged from the account's regular `balance` instead.
The reason to separate `balance` and `rent balance` is that certain contracts do not accept `ether` sends, or always send the entire balance off to some other destination. For these cases, a separate`rent balance` is required.
When an account's `balance` is insufficient to pay rent, the account becomes `inactive`. Its
storage and contract code are removed. Inactive accounts cannot be interacted with, i.e.
it behaves as if it has no contract code.
Inactive accounts can be restored by re-uploading their storage. To restore an inactive
account `A`, a new account `B` is created with arbitrary code and its storage modified
with `SSTORE` operations until it matches the storage root of `A`. Account `B` can restore
`A` through the `RESTORETO` opcode. This means the cost of restoring an account is
equivalent to recreating it via successive `SSTORE` operations.
### Changes To State
At the top level, a new key `size` is added to the accounts trie. This key tracks the
total number of trie nodes across all accounts, including storage trie nodes. To track
rent, the structure of account entries is changed as well.
Before processing the block in which this EIP becomes active, clients iterate the whole
state once to count the number of trie nodes and to change the representation of all
