State Expiry, State Rent, Statelessness, Regenesis and State’s Equilibrium
State, state, state – a big problem with several proposed solutions in the Ethereum and EVM ecosystem. State growth is a challenge for any blockchain looking to scale while retaining its key properties: immutable ledgers and full-historical verification.
In this blog post, we will be touching on the topic of state growth and the current proposals to handle it proposed over the recent years, including the Load Network team’s architectural approach.
As we’ll see, the main idea behind these attempts is to restrict or even reduce the ever-growing EVM state, come with tradeoffs and implementation complexities.
State Rent
Proposed by Alexey Akhunov, State Rent in brief is about charging rent to all items in the state and deleting any which exhaust their “balance” / “credits”.
State rent is relatively simple when it involves accounts with balances only, without deep-looking into account’s storage and potential data associated with it. The financial value associated with account storage could be very complex to programmatically compute and identify what value is associated with the non-EOA storage. On top of that, the storage is variable and could shrink or increase in size based on smart contract internal actions.
Continuing on the storage angle, the current smart contract protocol compilers on Ethereum and the wider EVM ecosystem (Solidity, Vyper, etc) assume by conviction that the smart contracts storage cannot simply disappear (get purged once rent is unpaid or unwanted). If a smart contract’s associated storage simply disappears, the contract could behave erratically or even break due to the storage-builtin assumptions. Fixing this would require changing the smart contract layer programming conviction, rewriting the contracts in a new rent-safe way – and this goes against the primacy of decentralized computer ethos: “code is law” & smart contract compute determinism.
State Rent has some other problems to solve such as how much to pay rent per account, over which storage unit, pricing over time, etc.
State Expiry
The State Expiry model has pretty similar storage consequences to State Rent – technically, expelling a storage item or account from the state is State Expiry following State Rent expiration.
Models such as State Expiry, which are less complex than State Rent as rent isn’t involved, could be implemented when Ethereum embraces a new programming conviction: a new smart contract protocol with no migration or backward compatibility overhead. Will we see State Expiry addressed along the RISC-V roadmap?
Stateless
The core idea is that for Stateless Ethereum to work, blocks must include more than just the typical transaction data (sender, receiver, input data). They also need to contain merkle proofs for every state item accessed by the transactions in that block.
This is necessary because stateless verification operates without knowledge of the full state – it only has access to the state root hash (the commitment to the entire state).
The merkle proofs allow verifiers to confirm that specific state items (account balances, contract storage slots, etc.) actually exist in the state tree and contain the correct values, without needing to store the entire state themselves.
Therefore, Stateless EVM shifts the burden of state storage from verifiers to block producers, who must now gather and include all relevant proofs alongside the transactions, including the requirement of full-state accessibility to produce such proofs.
Stateless Ethereum comes with two major challenges to solve: the first is how to democratically divide the overhead gas fee per block to cover the cost to include the merkle proof in the block (one block’s proof paid by N > 0 transaction creators).
The second problem to solve is the necessity to include the entire bytecode of a smart contract within the merkle when involved in a transaction. The complexity of this design will exponentially increase with larger smart contracts and cross smart contracts transaction calls.
The middleground proposal: Regenesis
Also proposed by Alexey Akhunov, Regenesis is the middle ground proposal between the statelessness and the two other mentioned proposals.
Regenesis offers a middle ground between stateful and stateless EVM. Instead of requiring blocks to carry all state proofs, transactions include Merkle proofs only for state items they access that aren’t yet in the “explicit state.” When a transaction is included in a block, its proven items join the explicit state, eliminating the need for future transactions to prove them again. This creates a growing explicit state that periodically resets during “regenesis events.”
The approach shifts burden from block producers to transaction creators, who need access to the full state for creating proofs, but benefits validators who only need to maintain the smaller explicit state rather than the entire EVM state.
Load Network approach: State’s Equilibrium
As a storage-focused chain, one of the main principles Load Network is built on is to have practical and principles-aligned solutions for the problems state growth and history expiry.
Load Network is the first EVM L1 built on top of Arweave permanent storage. This settlement layer (Arweave) is what facilitated us to build the novel approach to state growth used currently in Load.
First let’s start defining the hot state, cold state & system equilibrium:
- We call Hot State the EVM State (including history) which lives on the Pruned Nodes for the span of 30 days (2592000 Load blocks)
- Cold State is the data that gets settled on Arweave through the Arweave Reth ExEx. Technically the Cold State gets instantly settled from the Hot State after each block finalization on the EVM (canonical chain).
- System Equilibrium is reached (and supposed to be constant) at any moment in the system as long as any item of the full state (or history) is retrieved from the Hot State & Cold State during the first 2592000 blocks of the transaction block inclusion, and from the Cold State after that.
The Load’s State-Equilibrium is built on these principles:
- System must be always in equilibrium
- The system is forward-compatible with any upcoming socially-adopted State solution approach in the Ethereum space.
- Burned is divided between block producer and transaction creator(s)
- The system makes use of Arweave’s distributed and decentralized gateway stack, and Arweave ExEx data pipeline uses ANS-104 dataitems for near-instant data retrieveability.
Unlike Regenesis middleground approach between Statelessness & Statefulness, our State Equilibrium approach is a middleground between State Rent & State Expiry:
- State Expiry is implemented under Pruned Nodes
- State Rent is implemented under the Arweave ExEx pipeline, whereas the paid Rent covers the storage/history item storage for 200+ years through Arweave endowment security.
In this model, the block producer (miner) has the responsibility to load the block data on Arweave (the ETL process is programmatic through an in-binary ExEx). For cost effectiveness, the ExEx serializes block data in Borsh (full data: block object, header, transaction objects, transaction receipts) and compresses it in Brotli, resulting in ~55% size compression, therefore lower costs charged through Arweave data settlement (at the time of writing, storing 1MB on Arweave costs $0.014).
Load Network Arweave ExEx address
Now that we have explained the block producer burden, we will take on the transaction creator burden. Arweave data storage associated with the block data settling is technically paid by the transaction creators, to address this, with our first approach for a fair gaseconomics we have implemented the following:
- Increased the EVM transaction base fee from 21k gas to 500kk gas (block gas limit from 30kk to 500kk)
- Theoretically, factored that at least 1 transaction in a block (paying the base fee) is sufficient to cover the Arweave transaction base fee (which falls under the bracket of the size of a 1-transaction borsh-brotli serialized block): 256kb ~= 487585094 winstons ~= $0.0034
Using the State Equilibrium model, Load Network is able to achieve a hybrid model of state rent-expiry, allowing high-throughput high-performance nodes, respecting physical limitations (hardware, bandwidth, p2p networking, etc), while putting the lowest possible constraints on the nodes and keeping the full state, full history, and permanent data backup (which introduces new innovative such as no reliance on 3rd party Archive nodes, data indexers, chain snapshots, etc.)
While State-Equilibrium still a very new approach in the EVM space and it’s showing good results (and the first to leverage Arweave storage), we are actively working on improving the following angles:
- Fast state reconstruction from Arweave Cold State
- JSON-RPC GET server built on top of Arweave Cold State (Archive Node)
- Developing the fairest and economically secure gaseconomics equation
- Cryptographic proofs for the correctness of data settlement on Arweave, including a slashing mechanism (Consensus Layer work)
Conclusion
Regenesis and State Expiry may see the light of day faster than other proposals, and that also depends on the development of Ethereum Execution Clients and some data standardization and the potential adoption of new VMs. Personally, we believe that State Equilibrium will reach the desired maturity for wider adoption among the EVM ecosystem.