-
Notifications
You must be signed in to change notification settings - Fork 106
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
Portal state network task-list #1923
Comments
Added a task for witness / statelessness but perhaps that deserves its own task list considering it is not really something in Portal. We also already have an issue for this, but specifically for the verkle version: #1451 And here is the old spec on witness: https://github.com/ethereum/portal-network-specs/blob/01a49a8c9bf08121ecde1b9270a6f2f679cb2568/witness.md. This has since then been removed from the repo. |
I've created a new issue for the proof generation and verification task here: #1934 |
Attempt to task-list for the development of the state network. This list is going to be incomplete so feel free to add/suggest items. Perhaps some tasks don't really make sense even depending on the path taken.
One important and still open question regarding the state network is whether to provide leaves only or also intermediate nodes of the tries.
The latest update to the specifications indicate only the leaves, but I don't think this should be seen as a chosen direction.
Now, we could start with providing the leaves, and as R&D goes on it should always be considered what benefit adding the intermediate nodes gives us for each problem tackled.
edit:
Trie node storage is now being called
Model A
and flat storage of leaf data isModel B
, see below.It has been suggested that the development of Portal state network should first focus on
Modal A
, hence we will have to adjust the task list a bit accordingly.See message from Piper: https://discord.com/channels/890617081744220180/1089234065816821860/1187092509327884410
Task-list
Model A and Model B
AccountTrieNodeKey
andContractStorageTrieNodeKey
, which I wouldn't actually do, to allow testing with this approach also. But we can move them to the end to match the prefix values for the other 3 types.Offer
would work with proof,FindContent
without). Does it need two different content keys for this? Or alter Portal wire protocol to accommodate for this?Model A
Proof validation
Proof generation
Adding content decoding & proof verification for account trie node and storage trie node proofs requires access to state root.
Gossip & storage:
Possible unittest between nodes
Implement eth_getBalance or equivalent JSON-RPC calls that needs to access state. This would require to walk the trie, but via the network.
Potential bigger test between several nodes (local testnet):
eth_getBalance
or similar method, the recursive NH gossip could also be skipped and instead just have all trie nodes injected (even without the proofs/validation).State network bridge that generates the new state content and gossips them in the network:
Model B
Proof generation & verification: dedicated issue Portal State Network - Proof generation & verification #1934
Test: generation + serdes + verification loop.
Add content decoding & proof verification for account trie and storage trie proofs to state network. This does require access to state root.
Potential test between nodes:
Implement eth_getBalance or equivalent JSON-RPC calls that needs to access state.
Potential bigger test between nodes:
State network bridge that generates the above the state content and gossips them in the network: Initial state network bridge implementation #1902
Similar tests as already mentioned above could be done by usage of the bridge instead.
How to deal with cold leaf proofs: https://github.com/ethereum/portal-network-specs/blob/master/state-network.md#updating-cold-leaf-proofs
Pruning of old leaves with proof
Neither model.
nimbus-eth1/nimbus/evm/state.nim
Line 289 in 657379f
The text was updated successfully, but these errors were encountered: