Open kdeme opened 10 months ago
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: https://github.com/status-im/nimbus-eth1/issues/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: https://github.com/status-im/nimbus-eth1/issues/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 onModal 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
[x] Proof validation
[x] Proof generation
[x] Adding content decoding & proof verification for account trie node and storage trie node proofs requires access to state root.
[x] Gossip & storage:
[x] Possible unittest between nodes
[x] 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).[x] State network bridge that generates the new state content and gossips them in the network:
Model B
[ ] Proof generation & verification: dedicated issue https://github.com/status-im/nimbus-eth1/issues/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: https://github.com/status-im/nimbus-eth1/issues/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.