-
Notifications
You must be signed in to change notification settings - Fork 750
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Client: Verkle Trie Integration + Proof Consumption - Tracking Issue #1533
Comments
Also taking over some answers from Guillaume from our Discord channel for further reference: Guillaume Ballet
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).
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.
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.
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. |
Some more references:
|
This repo compiles the verkle verifier to WASM for use in our integration. |
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 |
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 ethereum/go-ethereum#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:
Some first TODOs here:
rust-verkle
implementationWASM
compilationWASM
compilation is possible, structural needs, see Add WASM compilation support for verkle prover crate-crypto/rust-verkle#24VM
StateManager
experiments and simple tests to do a dedicated Verkle Trie backed state manager (eventually needs some confirmation if this is the correct entry point)The text was updated successfully, but these errors were encountered: