ethereumjs
Client: Verkle Trie Integration + Proof Consumption - Tracking Issue
There are recent efforts to replace the current MPT state trie storage datastructure with a new trie format called Verkle Trie which is described in this draft EIP.
As discussed with @gballet from the go-ethereum team we would like to prototype a verkle trie integration in the EthereumJS client with the main focus on proof consumption and block execution. Guillaume is working on Verkle Trie support for go-ethereum here https://github.com/ethereum/go-ethereum/pull/23630, and outline how a broader network setup might look like is written down here.
Effort on this is rather broad and this is a tracking issue for high level discussion and TODO checks. Dedicated tasks should rather become it's own place to discuss.
References:
- Verkle Trie Talk, Guillaume Ballet, ETHOnline, Oct 15, 2021
Some first TODOs here:
- [ ]
rust-verkleimplementationWASMcompilation- [ ] Analyze if a
WASMcompilation is possible, structural needs, see https://github.com/crate-crypto/rust-verkle/issues/24 - [ ] Compilation setup and execution from the EthereumJS side
- [ ] First
VMStateManagerexperiments and simple tests to do a dedicated Verkle Trie backed state manager (eventually needs some confirmation if this is the correct entry point)
- [ ] Analyze if a
- [ ] Client Proof Consumption: TODO
- [ ] Blockchain, Block, Common: understanding of proof-including block format TODO
Also taking over some answers from Guillaume from our Discord channel for further reference:
Guillaume Ballet — 18.10.2021
(1) In state expiry, if contract data is resurrected, then I assume that the entire contract data is resurrected, i.e. for each key you access you either prove that it is empty, or you give a proof of what value it contained in the past
it is not the case that the entire contract data is resurrected, which is one of the most complex bits of ASE. If you try to read the storage of a contract at an address that you resurrected, it should revert. The idea is that, if you are a crypto-kitty user, you only resurrect the bits that corresponding to your kitties, and not the whole 1GB+ of it (or was it 4GB? anyway, you get the idea).
(2) Is it allowed to send ETH to addresses at later periods than the current period?
That's a good question, my hunch is that it should not be allowed, because it breaks the "the epoch at which the address has first been created" scheme.
(3) What about privacy? If my address expires, then if I want to resurrect it, then I probably have to pay for this proof from another account, thus linking both accounts together?
That is indeed a potential privacy leak, although I assume it is possible to build some sort of mixer collecting addresses, and sending one proof resurrecting a lot of accounts in one swoop - thus providing plausible deniability.
One thing I didn't mention in the presentation, is that the math behind verkle trees is meant to be zk-friendly. One can imagine a method where the account is resurrected in a zero-knowledge way, albeit not at first.
(4) What about contracts which have dependencies on other contracts. What if older contracts now expire (and are thus empty?)? Then the behavior of this contract could change; it thinks that at address X there is no code (while there should be).
Indeed execution would revert. Which means it's the responsibility of the tx sender to ensure that all the addresses they need are resurrected. UX-wise, it's a challenge and probably requires a simulation.
It also has impact on smart-contract security, because if you have e.g. a pointer in the data that says where you should read/write your data, then someone could front-run you, change that pointer to a non-resurrected location, and therefore cause a revert for your transaction. Hence the joke about "sweat" in the presentation: ASE are cool, but they are not easy.
Some more references:
- Fantastic slides from Dankrad for ACD summary (ACD Call #401, Oct 29 2021)
- Also from Dankrad: Verkle Trie EIP Calculator
Have now created a base branch #verkle-stateless-demo where we can do the work against and also added some set of branch protection rules along.
For now I've set this to me being the only one allowed to force-push, will make this very carefully and always do a branch backup before. 🙂
Do we still need this given the other Verkle issues and PR we have? @gabrocheleau @holgerd77