This EIP proposes a procedure to convert, on each block, a fixed number of key-values from the existing Merkle Patricia Tree (MPT) to the Verkle Tree (VKT).
The accounts state is too large to wait for transactions to organically move all of them to the VKT through the Overlay Tree. Thus, we need a strategy to convert all the state within a reasonable time. The state conversion completion allows removing the Overlay Tree abstraction introduced in EIP-7612 and to use directly the VKT for all state access.
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.
| Parameter | value | Description |
|---|---|---|
CONVERSION_START_TIMESTAMP | TBD | Timestamp at which the conversion starts. |
CONVERSION_STRIDE | TBD | Maximum number of conversion units to be converted per block |
A conversion unit is:
Include the following code in the existing apply_body(...) function:
Before executing txs, it calls state_convert(...) (described below) which performs a state conversion step for this block.
In state.py, add the following code:
These new structures allows State to track where we're in the conversion process.
Modify the State class by adding the following attributes:
Define a function with the following signature:
Add or modify the following functions:
As mentioned previously, the next function is called by apply_body(...) to perform the conversion step for a block:
Performing the conversion step before the block txs execution has some benefits:
CONVERSION_STRIDE proposed valuePerformance benchmarks were done to achieve the right balance between:
If an account has code, this is chunked and inserted in the VKT in one go. An alternative is including a CodePhase and let each inserted chunk consume one unit of CONVERSION_STRIDE.
We decided to not do this to reduce the algorithm complexity. Considering the current maximum code size, the worst case scenario for a block could overflow the CONVERSION_STRIDE limit by 24k/31~=793 units.
EIP-7610 mentions the existence of 28 accounts that have:
These storage slots are to be omitted from the conversion process, as they can not be accessed.
TODO: We have an estimation, but it might be worth recalculating it closer to the proposed fork having a more up to date state size estimate.
The conversion logic runs at the start of each block, so missed slots don't create special situations.
The proposed order synergizes with many EL client flat-db architectures, minimizing random disk-IO.
CONVERSION_STRIDE limitThe CONVERSION_STRIDE parameter tries to limit the load of effective writes. These special accounts are skipped since we try to perform a bulk EIP-158 deletion of the remaining accounts.
This might sound dangerous since if there were 1k of these accounts and all corresponded to be converted in the same block, we'd be forcing the clients to iterate 1k accounts without counting any quota from CONVERSION_STRIDE. The number of remaining accounts to delete is very low (i.e.: dozen) and also not contiguous, so this shouldn't be a concern.
EL clients are expected to satisfy at least one of these conditions:
No backward compatibility issues found.
TODO: currently described in an external document.
transition-post-genesis branch in github.com/gballet/go-ethereum implements this when setting --override.overlay-stride to a non-zero value on the command line.Needs discussion.
Copyright and related rights waived via CC0.