forked from cerc-io/plugeth
f62c58f8de
During snap-sync, we request ranges of values: either a range of accounts or a range of storage values. For any large trie, e.g. the main account trie or a large storage trie, we cannot fetch everything at once. Short version; we split it up and request in multiple stages. To do so, we use an origin field, to say "Give me all storage key/values where key > 0x20000000000000000". When the server fulfils this, the server provides the first key after origin, let's say 0x2e030000000000000 -- never providing the exact origin. However, the client-side needs to be able to verify that the 0x2e03.. indeed is the first one after 0x2000.., and therefore the attached proof concerns the origin, not the first key. So, short-short version: the left-hand side of the proof relates to the origin, and is free-standing from the first leaf. On the other hand, (pun intended), the right-hand side, there's no such 'gap' between "along what path does the proof walk" and the last provided leaf. The proof must prove the last element (unless there are no elements). Therefore, we can simplify the semantics for trie.VerifyRangeProof by removing an argument. This doesn't make much difference in practice, but makes it so that we can remove some tests. The reason I am raising this is that the upcoming stacktrie-based verifier does not support such fancy features as standalone right-hand borders. |
||
|---|---|---|
| .. | ||
| catalyst | ||
| downloader | ||
| ethconfig | ||
| fetcher | ||
| filters | ||
| gasprice | ||
| protocols | ||
| tracers | ||
| api_admin.go | ||
| api_backend.go | ||
| api_debug_test.go | ||
| api_debug.go | ||
| api_miner.go | ||
| api.go | ||
| backend.go | ||
| bloombits.go | ||
| handler_eth_test.go | ||
| handler_eth.go | ||
| handler_snap.go | ||
| handler_test.go | ||
| handler.go | ||
| peer.go | ||
| peerset.go | ||
| state_accessor.go | ||
| sync_test.go | ||
| sync.go | ||