EIP7736 Impact Estimation

[weiihann]

Summary

There are two parts to this task:

1. Labelling: Label each key-value pair with the last accessed (i.e. read and write) block number
2. Analysis: Compute the expiry epoch of each stem and analyse how many expired stems can be deleted

Mechanism of Labelling

How it works roughly:

1. Propagate block number from BlockChain to State
2. Every access operation updates the block number of stateObject and cached temporarily
3. During state's commit operation, a diff layer is created, which includes the labels
4. When diff layer merges to the disk layer, the labels are persisted to the database.

The storage format of the labels:

• [SnapshotAccountMeta] + Account hash → block number
• [SnapshotStorageMeta] + Account hash + slot hash → block number

Mechanism of Analysis

This is still work in progress. The implementation will reference the OverlayVerkleTransition function. The rough flow looks something like:

1. Create a custom command
2. Iterate over each key-value pair in the snapshot
3. Using the preimage, get the actual account address and slot number from their hashes
4. Compute the stems for the required fields to be inserted into Verkle
5. Get the block number labels, convert into expiry period and match it to the stems
6. Keep track of the expiry period count
7. Repeat until all accounts and slots are done
8. At the end, we should know the percentage of stems that are expired. From there, compare it with the size of Verkle, then we roughly know how much storage can be reduced.

One caveat: In Verkle, contract code is chunkified and split into different stems, it’s possible that only some parts are accessed while some aren’t. Therefore, the actual result should actually be better than the result that we have.