Implement RLPx "snap" capability #184
Labels
network
Issues related to network communication
Milestone
Comments
17 tasks
github-merge-queue bot
pushed a commit
that referenced
this issue
Oct 31, 2024
…andling logic (#960) **Motivation** Handling snap capability message `GetAccountRange` <!-- Why does this pull request exist? What are its goals? --> **Description** * Add functionality to iterate the Trie (TrieIterator) * Add functionality to iterate over all accounts in the state (Store::iter_accounts) * Add logic to handle `GetAccountRange` snap request * Fix slim encoding of `AccountState` * Remove unneeded trait `RLPEncodeSlim` **Notes** * ~We don't have the listen loop implemented so this PR only adds the standalone logic for handling the request and creating a response, we still need to plug it in to the main loop.~ * ~We are not able to run the hive test suite due to missing listen loop + old blocks being used by the test suite. I instead copied the state from a Geth execution (loading genesis + importing chain) and used that state to replicate hive tests as unit tests. These tests could be removed once we fix those two problems~ <!-- A clear and concise general description of the changes this PR introduces --> <!-- Link to issues: Resolves #111, Resolves #222 --> Partially addresses #184 --------- Co-authored-by: Esteban Dimitroff Hodi <esteban.dimitroff@lambdaclass.com>
h3lio5
pushed a commit
to h3lio5/lambda_ethereum_rust
that referenced
this issue
Oct 31, 2024
…andling logic (lambdaclass#960) **Motivation** Handling snap capability message `GetAccountRange` <!-- Why does this pull request exist? What are its goals? --> **Description** * Add functionality to iterate the Trie (TrieIterator) * Add functionality to iterate over all accounts in the state (Store::iter_accounts) * Add logic to handle `GetAccountRange` snap request * Fix slim encoding of `AccountState` * Remove unneeded trait `RLPEncodeSlim` **Notes** * ~We don't have the listen loop implemented so this PR only adds the standalone logic for handling the request and creating a response, we still need to plug it in to the main loop.~ * ~We are not able to run the hive test suite due to missing listen loop + old blocks being used by the test suite. I instead copied the state from a Geth execution (loading genesis + importing chain) and used that state to replicate hive tests as unit tests. These tests could be removed once we fix those two problems~ <!-- A clear and concise general description of the changes this PR introduces --> <!-- Link to issues: Resolves lambdaclass#111, Resolves lambdaclass#222 --> Partially addresses lambdaclass#184 --------- Co-authored-by: Esteban Dimitroff Hodi <esteban.dimitroff@lambdaclass.com>
fmoletta
added a commit
that referenced
this issue
Nov 12, 2024
… parent (#1124) **Motivation** We are currently storing nodes on the DB even if they are already inlined in their parent node. This is not only storage-inefficient but it also needs special handling when verifying proofs or importing trie nodes from other clients (such as in snap sync) as inlined nodes will not be sent separately. This PR aims to solve this issue at `TrieState` level, so that the change is invisible to the main trie logic. The state will skip insertion for inlined node hashes and will decode them instead of fetching from the db upon lookups <!-- Why does this pull request exist? What are its goals? --> **Description** * `TrieState::insert` now skips node hashes that represent inlined nodes * `TrieState::get` now decoded the node if it is inlined instead of performing a db lookup <!-- A clear and concise general description of the changes this PR introduces --> <!-- Link to issues: Resolves #111, Resolves #222 --> Closes None, but is needed in order to validate and integrate output from snap sync requests #184
Merged
github-merge-queue bot
pushed a commit
that referenced
this issue
Nov 20, 2024
**Motivation** When we receive a range of data (be it storage, accounts, nodes) from a snap request response we also receive the edge proofs for the given rate. In order to validate that response and integrate the data received we must verify the proofs in relation to the given range <!-- Why does this pull request exist? What are its goals? --> **Description** * Implement function `verify_range` which verifies a given range of trie elements with the provided edge proofs and also returns a boolean indicating if there is more state to be fetched after the last key. <!-- A clear and concise general description of the changes this PR introduces --> <!-- Link to issues: Resolves #111, Resolves #222 --> Closes None, but it is vital to process the responses from other nodes during snap-sync #184 --------- Co-authored-by: Esteban Dimitroff Hodi <esteban.dimitroff@lambdaclass.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Info in the spec. Note that this requires #171 to be implemented. As part of this, the "snap" capability should be added to the supported capabilities advertised in the initial "Hello" message.
In order to support this capability we must:
A) Be able to provide our own state for snap-syncing
B) Use snap syncing to sync our own state
Progress can be tracked by supporting the following hive tests:
The initial approach will be to fulfill data requests from our own state, but later on we will want to maintain our own snapshot separate from the state to allow fast snap syncing for other nodes (more info)
The text was updated successfully, but these errors were encountered: