Linked with GitHub
# Verkle Migration paths
1. MPT Expiry (EIP as specced)
- No difficult transition steps
- Relative simplicity
- Lasting overhead for missed access
- Permanent requirement for two databases
- Only really makes sense in the context of state expiry
2. Offline conversion + online catchup
- Full conversion to verkle
- Relative simplicity compared to other schemes
- Double storage space during transition
- Need to support two forms of sync at the same time
- Need to implement deletion in verkle tree if we want the canonical verkle tree to be independent from the snapshot time
3. Offline conversion (rollup awareness day) | Simplicity | Actually takes one month according to Guillaume |
- Very simple
- Would only be practical if it takes <1h to convert
- Actually takes ~1 month according to Guillaume
4. MPT state + stateless verkle (Justin's proposal)
- Allows all nodes to keep following the chain -- some become stateless
- Plenty of time to check everything is going well before actual hard fork
- High complexity -- requires a lot of extra elements compared to 2
5. Overlay Tree (EIP 2584)
# Detailed descriptions
## 1. MPT Expiry
At the hard fork, the MPT is frozen and an empty verkle tree is added. Whenever a miss occurs in the verkle tree, check the MPT for the key.
Optional extension 1: Afterwards, offline convert the MPT to verkle
Optional extension 2: Once the MPT is converted to verkle, perform state expiry, i.e. require witnesses for all transactions that "miss" on the most recent verkle tree.
## 2. Offline conversion + online catchup
## 3. Offline conversion
Stop the chain, convert all state to verkle, restart the chain.
According to Guillaume, full conversion might currently take one month.
## 4. MPT state + stateless verkle (Justin's proposal)
Start similar to 2: Some nodes convert an offline conversion of some MPT root `MPT0` to a verkle root `V0`. They then catch up with the current chain so that they have an up to date verkle root at the soft fork height $h_0$. Through a vote mechanism, this verkle root at $h_0$ is informally agreed on a side subnet (nodes can have a manual override in case there are disputes).
After $h_0$, for each block there will be a corresponding verkle root with witness on the side subnet. All nodes can now decide between thre possible options:
1. Verify the conversion of MPT to Verkle locally, by computing the verkle root at $h_0$. Afterwards they will full nodes with verkle state
2. Download the verkle tree at $h_0$, catch up using the witnesses. After the transition they will be full nodes with verkle state
3. Do nothing. They will become stateless verkle nodes
At the hard fork height $h_1$, the MPT root is removed from the blocks and the verkle root plus witnesses are added.
## 5. Overlay tree