EIP-7612: Verkle state transition via an overlay tree

Describes the use of an overlay tree to use the verkle tree structure, while leaving the historical state untouched.

Metadata

Status: DraftStandards Track: CoreCreated: 2024-01-25

Authors

Guillaume Ballet (@gballet), Ansgar Dietrichs (@adietrichs), Ignacio Hagopian (@jsign), Gottfried Herold (@GottfriedHerold), Jamie Lokier (@jlokier), Tanishq Jasoria (@tanishqjasoria), Parithosh Jayanthi (@parithosh), Gabriel Rocheleau (@gabrocheleau), Karim Taam (@matkt)

Requires

EIP-4762, EIP-6800, EIP-7545

Links

GitHub page Discussion on Ethereum Magicians

Abstract

This EIP proposes a method to switch the state tree tree format from hexary Merkle Patricia Tree (MPT) to a Verkle Tree (VKT): the MPT tree is frozen, and new writes to the state are stored in a VKT “laid over” the hexary MPT. The historical MPT state is left untouched and its eventual migration is handled at a later time.

Motivation

The Ethereum state is growing, and VKTs offer a good mitigation strategy to stem this growth and enable weak statelessness. Owing to the difficulty of translating contracts with large storage while they are being accessed, proposals for migrating the current MPT state are complex and will require client teams to undergo a long process of refactoring their code to handle this conversion.

The bigger the state, the longer any conversion process will take. This has an impact both while the conversion is happening, as well as when full-syncing the chain if the conversion is part of consensus. Fullsync is used extensively by core dev teams to test the performance of new code. A conversion longer than a month will impact the release schedule of client teams who typically release at this rate. Nodes that cannot follow the conversion will need to wait longer to rejoin. The conversion will also make reorgs slower, so reducing its duration is desirable.

This current proposal suggests to stop the MPT state growth in its tracks by activating a new “overlay” VKT, that all new state updates are written to. The “base” MPT is frozen in place, until all execution clients are ready to perform the full transition. Data is read first from the overlay tree, and if not found there, from the MPT.

Whenever the block that freeze the MPT is finalized, internal node data can be deleted, in order to free up disk space.

Specification

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.

Constants

Parameter	value	Description
`FORK_TIME`	`TBD`	Time at which the overlay tree is activated.

Helper functions

Changes to the execution spec

In the execution spec, modify the State class as such:

And the state access functions are modified as such:

Add the following function which is used when storing a contract in the tree:

Changes to the block header

At FORK_TIME the block header state root is changed from the MPT root to the VKT root.

Rationale

This approach doesn't convert the state, which is left to a subsequent EIP. This is meant as a stopgap in case we decide to push the conversion itself to a later time. It has the advantage of simplicity, which means that the Verge fork could happen at the same time as other, simpler EIPs. It also requires no change at the consensus layer.

Backwards Compatibility

No backward compatibility issues found.

Test Cases

Reference Implementation

transition-post-genesis branch in github.com/gballet/go-ethereum implements this when setting --override.overlay-stride=0 on the command line.

Security Considerations

Needs discussion.