# Verkle Migration paths 1. MPT Expiry (EIP as specced) - **Pros** - No difficult transition steps - Relative simplicity - **Cons** - 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 - **Pros** - Full conversion to verkle - Relative simplicity compared to other schemes - **Cons** - 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 | - **Pros** - Very simple - **Cons** - 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) - **Pros** - Allows all nodes to keep following the chain -- some become stateless - Plenty of time to check everything is going well before actual hard fork - **Cons** - High complexity -- requires a lot of extra elements compared to 2 5. Overlay Tree (EIP 2584) - **Pros** - ??? - **Cons** - ??? # 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 https://notes.ethereum.org/@XwIwCeCIQMeAl00PUAbEDw/verkle-migration-sketch ## 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 https://eips.ethereum.org/EIPS/eip-2584