Guillaume Ballet

It's a good thing that you told me, I just logged back in precisely to talk about work.

Alright Sir, I shall abide by this OG rule

- Building on this, storing uncompressed points becomes possible, which will improve computation speed and put verkle trees within reach of more low-power devices.

- Verkle trees offer an advantage that a node that is serialized on disk need not store a reference to its children, that might make the overall database significantly smaller.

Very productive week at the geth offsite. A few decisions impact verkle:
- While data will never be deleted from the verkle tree in normal operation, our deep reorg code needs support for it, as it relies on reverse-diffs to reorg past the 128-depth limit.

what, you too???

Does anyone have extra appveyor licences?

me too! we should meet

- Apple podcasts: https://podcasts.apple.com/de/podcast/ethplorateurs/id1644754305
- Direct link: https://www.buzzsprout.com/2048500/12836686

Nouveau podcast! Barnabe et moi-meme parlons des retraits!

- Spotify: https://open.spotify.com/episode/6Vmquudlk93saK7xKFJQNg
- Amazon: https://music.amazon.com/podcasts/f60ed3ed-f11b-4d8f-b522-05f775e121eb/episodes/0842752c-2489-44ba-97b2-94e260066203/ethplorateurs-les-retraits

* @gballet.bsky.social is Geth core dev at the Ethereum Foundation. He focuses on evolutions to the protocol and bringing research ideas to fruition. His talk provides a high-level introduction to verkle sync and proposes a separation between attesters and block proposers.

That's it in a nutshell. Thanks to Ignacio, Josh and Tanishq for their input so far.

The transition is decoupled from the conversion, so things can happen in time. Ultimaltely, this approach gives rise to a state expiry scheme: the MPT can be translated to verkle, and then "forgotten". "Resurrecting" values into the new tree is a matter of passing a verkle proof.

4) The "state expiry" method: the Merkle tree is frozen in place, and we start from a fresh tree. Reading and writing work the same as with the overlay method, but no conversion/merging of the trees ever happens : values in the Merkle tree progressively become clobbered by values in the verkle tree

Compared to the two previous options, though, it still looks like the worst of both worlds. Still, it's nice because it's not as "centralized" as the offline conversion method.

3) The "local bulk": pretty much the same as the other, except each machine does the conversion themselves. This approach has started to look feasible based on recent optimizations in the conversion process and verkle trees in general.

2) The offline method: a few very powerful machines do the translation at a fixed block height, and then share the result with the rest of the network. Less powerful clients download the conversion and replay blocks in verkle mode until the head in MPT mode has been reached.

Reading the state means first searching the verkle tree for a key, and then from the merkle tree if it could not be found. Writing to the state always mean writing to the verkle tree.

1) the option is known as the "overlay tree" method. The idea is to start with an empty, fresh verkle tree. Each block, a fixed number of values are copied from the merkle tree into the verkle tree.

To this end, the unwavering Pari and myself have revisited the options and dumped our thoughts in this document. Feedback welcome: https://notes.ethereum.org/@parithosh/verkle-transition. There are basically four options:

What's up with verkle trees? We've been busy working on the conversion from the current merkle tree to a verkle tree. This is a challenging problem, because the amount of data is huge. This means it doesn't find in RAM, and needs at least a day for the translation to complete on a beefy machine.