2022-09-16 07:24:12 +00:00
|
|
|
# Nimbus
|
2022-06-16 08:58:50 +00:00
|
|
|
# Copyright (c) 2021 Status Research & Development GmbH
|
|
|
|
# Licensed under either of
|
|
|
|
# * Apache License, version 2.0, ([LICENSE-APACHE](LICENSE-APACHE) or
|
|
|
|
# http://www.apache.org/licenses/LICENSE-2.0)
|
|
|
|
# * MIT license ([LICENSE-MIT](LICENSE-MIT) or
|
|
|
|
# http://opensource.org/licenses/MIT)
|
|
|
|
# at your option. This file may not be copied, modified, or distributed
|
|
|
|
# except according to those terms.
|
|
|
|
|
|
|
|
## This module fetches the Ethereum account state trie from network peers by
|
|
|
|
## traversing leaves of the trie in leaf path order, making network requests
|
|
|
|
## using the `snap` protocol.
|
|
|
|
|
2023-03-03 20:01:59 +00:00
|
|
|
{.push raises: [].}
|
|
|
|
|
2022-06-16 08:58:50 +00:00
|
|
|
import
|
2022-08-24 13:44:18 +00:00
|
|
|
std/sequtils,
|
2022-06-16 08:58:50 +00:00
|
|
|
chronos,
|
2022-10-20 16:59:54 +00:00
|
|
|
eth/[common, p2p, trie/trie_defs],
|
2022-07-01 11:42:17 +00:00
|
|
|
stew/interval_set,
|
2022-09-16 07:24:12 +00:00
|
|
|
"../../.."/[protocol, protocol/trace_config],
|
2022-11-01 15:07:44 +00:00
|
|
|
"../.."/[constants, range_desc, worker_desc],
|
2022-10-08 17:20:50 +00:00
|
|
|
./com_error
|
2022-06-16 08:58:50 +00:00
|
|
|
|
|
|
|
logScope:
|
|
|
|
topics = "snap-fetch"
|
|
|
|
|
2022-07-01 11:42:17 +00:00
|
|
|
type
|
2022-08-04 08:04:30 +00:00
|
|
|
GetAccountRange* = object
|
2022-09-02 18:16:09 +00:00
|
|
|
data*: PackedAccountRange ## Re-packed reply data
|
|
|
|
withStorage*: seq[AccountSlotsHeader] ## Accounts with non-idle storage root
|
2022-07-01 11:42:17 +00:00
|
|
|
|
2022-06-16 08:58:50 +00:00
|
|
|
# ------------------------------------------------------------------------------
|
|
|
|
# Private functions
|
|
|
|
# ------------------------------------------------------------------------------
|
|
|
|
|
2022-08-04 08:04:30 +00:00
|
|
|
proc getAccountRangeReq(
|
|
|
|
buddy: SnapBuddyRef;
|
|
|
|
root: Hash256;
|
2022-10-14 16:40:32 +00:00
|
|
|
iv: NodeTagRange;
|
2022-11-01 15:07:44 +00:00
|
|
|
pivot: string;
|
2022-08-04 08:04:30 +00:00
|
|
|
): Future[Result[Option[SnapAccountRange],void]] {.async.} =
|
|
|
|
let
|
|
|
|
peer = buddy.peer
|
2022-06-16 08:58:50 +00:00
|
|
|
try:
|
2022-08-04 08:04:30 +00:00
|
|
|
let reply = await peer.getAccountRange(
|
2023-03-10 17:10:30 +00:00
|
|
|
root, iv.minPt.to(Hash256).data, iv.maxPt.to(Hash256).data,
|
|
|
|
fetchRequestBytesLimit)
|
2022-06-16 08:58:50 +00:00
|
|
|
return ok(reply)
|
|
|
|
except CatchableError as e:
|
2023-01-30 22:10:23 +00:00
|
|
|
let error {.used.} = e.msg
|
2022-11-01 15:07:44 +00:00
|
|
|
trace trSnapRecvError & "waiting for GetAccountRange reply", peer, pivot,
|
2023-01-30 22:10:23 +00:00
|
|
|
error
|
2022-06-16 08:58:50 +00:00
|
|
|
return err()
|
|
|
|
|
|
|
|
# ------------------------------------------------------------------------------
|
|
|
|
# Public functions
|
|
|
|
# ------------------------------------------------------------------------------
|
|
|
|
|
2022-08-04 08:04:30 +00:00
|
|
|
proc getAccountRange*(
|
|
|
|
buddy: SnapBuddyRef;
|
2022-11-01 15:07:44 +00:00
|
|
|
stateRoot: Hash256; ## Current DB base (see `pivot` for logging)
|
|
|
|
iv: NodeTagRange; ## Range to be fetched
|
|
|
|
pivot: string; ## For logging, instead of `stateRoot`
|
2022-09-16 07:24:12 +00:00
|
|
|
): Future[Result[GetAccountRange,ComError]] {.async.} =
|
2022-06-16 08:58:50 +00:00
|
|
|
## Fetch data using the `snap#` protocol, returns the range covered.
|
2022-08-04 08:04:30 +00:00
|
|
|
let
|
2023-01-30 22:10:23 +00:00
|
|
|
peer {.used.} = buddy.peer
|
2022-06-16 08:58:50 +00:00
|
|
|
if trSnapTracePacketsOk:
|
2022-12-24 09:54:18 +00:00
|
|
|
trace trSnapSendSending & "GetAccountRange", peer, pivot, accRange=iv
|
2022-06-16 08:58:50 +00:00
|
|
|
|
2022-07-01 11:42:17 +00:00
|
|
|
var dd = block:
|
2022-11-01 15:07:44 +00:00
|
|
|
let rc = await buddy.getAccountRangeReq(stateRoot, iv, pivot)
|
2022-06-16 08:58:50 +00:00
|
|
|
if rc.isErr:
|
2022-09-16 07:24:12 +00:00
|
|
|
return err(ComNetworkProblem)
|
2022-06-16 08:58:50 +00:00
|
|
|
if rc.value.isNone:
|
2022-11-01 15:07:44 +00:00
|
|
|
trace trSnapRecvTimeoutWaiting & "for AccountRange", peer, pivot
|
2022-09-16 07:24:12 +00:00
|
|
|
return err(ComResponseTimeout)
|
2022-08-24 13:44:18 +00:00
|
|
|
let snAccRange = rc.value.get
|
2022-08-04 08:04:30 +00:00
|
|
|
GetAccountRange(
|
Prep for full sync after snap make 4 (#1282)
* Re-arrange fetching storage slots in batch module
why;
Previously, fetching partial slot ranges first has a chance of
terminating the worker peer 9due to network error) while there were
many inheritable storage slots on the queue.
Now, inheritance is checked first, then full slot ranges and finally
partial ranges.
* Update logging
* Bundled node information for healing into single object `NodeSpecs`
why:
Previously, partial paths and node keys were kept in separate variables.
This approach was error prone due to copying/reassembling function
argument objects.
As all partial paths, keys, and node data types are more or less handled
as `Blob`s over the network (using Eth/6x, or Snap/1) it makes sense to
hold these `Blob`s as named field in a single object (even if not all
fields are active for the current purpose.)
* For good housekeeping, using `NodeKey` type only for account keys
why:
previously, a mixture of `NodeKey` and `Hash256` was used. Now, only
state or storage root keys use the `Hash256` type.
* Always accept latest pivot (and not a slightly older one)
why;
For testing it was tried to use a slightly older pivot state root than
available. Some anecdotal tests seemed to suggest an advantage so that
more peers are willing to serve on that older pivot. But this could not
be confirmed in subsequent tests (still anecdotal, though.)
As a side note, the distance of the latest pivot to its predecessor is
at least 128 (or whatever the constant `minPivotBlockDistance` is
assigned to.)
* Reshuffle name components for some file and function names
why:
Clarifies purpose:
"storages" becomes: "storage slots"
"store" becomes: "range fetch"
* Stash away currently unused modules in sub-folder named "notused"
2022-10-27 13:49:28 +00:00
|
|
|
data: PackedAccountRange(
|
2023-03-03 20:01:59 +00:00
|
|
|
proof: snAccRange.proof.nodes,
|
Prep for full sync after snap make 4 (#1282)
* Re-arrange fetching storage slots in batch module
why;
Previously, fetching partial slot ranges first has a chance of
terminating the worker peer 9due to network error) while there were
many inheritable storage slots on the queue.
Now, inheritance is checked first, then full slot ranges and finally
partial ranges.
* Update logging
* Bundled node information for healing into single object `NodeSpecs`
why:
Previously, partial paths and node keys were kept in separate variables.
This approach was error prone due to copying/reassembling function
argument objects.
As all partial paths, keys, and node data types are more or less handled
as `Blob`s over the network (using Eth/6x, or Snap/1) it makes sense to
hold these `Blob`s as named field in a single object (even if not all
fields are active for the current purpose.)
* For good housekeeping, using `NodeKey` type only for account keys
why:
previously, a mixture of `NodeKey` and `Hash256` was used. Now, only
state or storage root keys use the `Hash256` type.
* Always accept latest pivot (and not a slightly older one)
why;
For testing it was tried to use a slightly older pivot state root than
available. Some anecdotal tests seemed to suggest an advantage so that
more peers are willing to serve on that older pivot. But this could not
be confirmed in subsequent tests (still anecdotal, though.)
As a side note, the distance of the latest pivot to its predecessor is
at least 128 (or whatever the constant `minPivotBlockDistance` is
assigned to.)
* Reshuffle name components for some file and function names
why:
Clarifies purpose:
"storages" becomes: "storage slots"
"store" becomes: "range fetch"
* Stash away currently unused modules in sub-folder named "notused"
2022-10-27 13:49:28 +00:00
|
|
|
accounts: snAccRange.accounts
|
2022-09-02 18:16:09 +00:00
|
|
|
# Re-pack accounts data
|
|
|
|
.mapIt(PackedAccount(
|
Prep for full sync after snap make 4 (#1282)
* Re-arrange fetching storage slots in batch module
why;
Previously, fetching partial slot ranges first has a chance of
terminating the worker peer 9due to network error) while there were
many inheritable storage slots on the queue.
Now, inheritance is checked first, then full slot ranges and finally
partial ranges.
* Update logging
* Bundled node information for healing into single object `NodeSpecs`
why:
Previously, partial paths and node keys were kept in separate variables.
This approach was error prone due to copying/reassembling function
argument objects.
As all partial paths, keys, and node data types are more or less handled
as `Blob`s over the network (using Eth/6x, or Snap/1) it makes sense to
hold these `Blob`s as named field in a single object (even if not all
fields are active for the current purpose.)
* For good housekeeping, using `NodeKey` type only for account keys
why:
previously, a mixture of `NodeKey` and `Hash256` was used. Now, only
state or storage root keys use the `Hash256` type.
* Always accept latest pivot (and not a slightly older one)
why;
For testing it was tried to use a slightly older pivot state root than
available. Some anecdotal tests seemed to suggest an advantage so that
more peers are willing to serve on that older pivot. But this could not
be confirmed in subsequent tests (still anecdotal, though.)
As a side note, the distance of the latest pivot to its predecessor is
at least 128 (or whatever the constant `minPivotBlockDistance` is
assigned to.)
* Reshuffle name components for some file and function names
why:
Clarifies purpose:
"storages" becomes: "storage slots"
"store" becomes: "range fetch"
* Stash away currently unused modules in sub-folder named "notused"
2022-10-27 13:49:28 +00:00
|
|
|
accKey: it.accHash.to(NodeKey),
|
2022-09-02 18:16:09 +00:00
|
|
|
accBlob: it.accBody.encode))),
|
Prep for full sync after snap make 4 (#1282)
* Re-arrange fetching storage slots in batch module
why;
Previously, fetching partial slot ranges first has a chance of
terminating the worker peer 9due to network error) while there were
many inheritable storage slots on the queue.
Now, inheritance is checked first, then full slot ranges and finally
partial ranges.
* Update logging
* Bundled node information for healing into single object `NodeSpecs`
why:
Previously, partial paths and node keys were kept in separate variables.
This approach was error prone due to copying/reassembling function
argument objects.
As all partial paths, keys, and node data types are more or less handled
as `Blob`s over the network (using Eth/6x, or Snap/1) it makes sense to
hold these `Blob`s as named field in a single object (even if not all
fields are active for the current purpose.)
* For good housekeeping, using `NodeKey` type only for account keys
why:
previously, a mixture of `NodeKey` and `Hash256` was used. Now, only
state or storage root keys use the `Hash256` type.
* Always accept latest pivot (and not a slightly older one)
why;
For testing it was tried to use a slightly older pivot state root than
available. Some anecdotal tests seemed to suggest an advantage so that
more peers are willing to serve on that older pivot. But this could not
be confirmed in subsequent tests (still anecdotal, though.)
As a side note, the distance of the latest pivot to its predecessor is
at least 128 (or whatever the constant `minPivotBlockDistance` is
assigned to.)
* Reshuffle name components for some file and function names
why:
Clarifies purpose:
"storages" becomes: "storage slots"
"store" becomes: "range fetch"
* Stash away currently unused modules in sub-folder named "notused"
2022-10-27 13:49:28 +00:00
|
|
|
withStorage: snAccRange.accounts
|
2022-09-02 18:16:09 +00:00
|
|
|
# Collect accounts with non-empty storage
|
|
|
|
.filterIt(it.accBody.storageRoot != emptyRlpHash).mapIt(
|
|
|
|
AccountSlotsHeader(
|
Prep for full sync after snap make 4 (#1282)
* Re-arrange fetching storage slots in batch module
why;
Previously, fetching partial slot ranges first has a chance of
terminating the worker peer 9due to network error) while there were
many inheritable storage slots on the queue.
Now, inheritance is checked first, then full slot ranges and finally
partial ranges.
* Update logging
* Bundled node information for healing into single object `NodeSpecs`
why:
Previously, partial paths and node keys were kept in separate variables.
This approach was error prone due to copying/reassembling function
argument objects.
As all partial paths, keys, and node data types are more or less handled
as `Blob`s over the network (using Eth/6x, or Snap/1) it makes sense to
hold these `Blob`s as named field in a single object (even if not all
fields are active for the current purpose.)
* For good housekeeping, using `NodeKey` type only for account keys
why:
previously, a mixture of `NodeKey` and `Hash256` was used. Now, only
state or storage root keys use the `Hash256` type.
* Always accept latest pivot (and not a slightly older one)
why;
For testing it was tried to use a slightly older pivot state root than
available. Some anecdotal tests seemed to suggest an advantage so that
more peers are willing to serve on that older pivot. But this could not
be confirmed in subsequent tests (still anecdotal, though.)
As a side note, the distance of the latest pivot to its predecessor is
at least 128 (or whatever the constant `minPivotBlockDistance` is
assigned to.)
* Reshuffle name components for some file and function names
why:
Clarifies purpose:
"storages" becomes: "storage slots"
"store" becomes: "range fetch"
* Stash away currently unused modules in sub-folder named "notused"
2022-10-27 13:49:28 +00:00
|
|
|
accKey: it.accHash.to(NodeKey),
|
2022-09-02 18:16:09 +00:00
|
|
|
storageRoot: it.accBody.storageRoot)))
|
2022-06-16 08:58:50 +00:00
|
|
|
let
|
2022-07-01 11:42:17 +00:00
|
|
|
nAccounts = dd.data.accounts.len
|
|
|
|
nProof = dd.data.proof.len
|
2022-06-16 08:58:50 +00:00
|
|
|
|
|
|
|
if nAccounts == 0:
|
2022-07-01 11:42:17 +00:00
|
|
|
# github.com/ethereum/devp2p/blob/master/caps/snap.md#getaccountrange-0x00:
|
|
|
|
# Notes:
|
|
|
|
# * Nodes must always respond to the query.
|
|
|
|
# * If the node does not have the state for the requested state root, it
|
|
|
|
# must return an empty reply. It is the responsibility of the caller to
|
|
|
|
# query an state not older than 128 blocks.
|
|
|
|
# * The responding node is allowed to return less data than requested (own
|
|
|
|
# QoS limits), but the node must return at least one account. If no
|
|
|
|
# accounts exist between startingHash and limitHash, then the first (if
|
|
|
|
# any) account after limitHash must be provided.
|
2022-06-16 08:58:50 +00:00
|
|
|
if nProof == 0:
|
2022-07-01 11:42:17 +00:00
|
|
|
# Maybe try another peer
|
2022-11-01 15:07:44 +00:00
|
|
|
trace trSnapRecvReceived & "empty AccountRange", peer, pivot,
|
|
|
|
nAccounts, nProof, accRange="n/a", reqRange=iv
|
2022-09-16 07:24:12 +00:00
|
|
|
return err(ComNoAccountsForStateRoot)
|
2022-07-01 11:42:17 +00:00
|
|
|
|
2022-11-08 18:56:04 +00:00
|
|
|
# So there is no data and a proof.
|
|
|
|
trace trSnapRecvReceived & "terminal AccountRange", peer, pivot, nAccounts,
|
|
|
|
nProof, accRange=NodeTagRange.new(iv.minPt, high(NodeTag)), reqRange=iv
|
2022-07-01 11:42:17 +00:00
|
|
|
return ok(dd)
|
|
|
|
|
2022-08-04 08:04:30 +00:00
|
|
|
let (accMinPt, accMaxPt) = (
|
Prep for full sync after snap make 4 (#1282)
* Re-arrange fetching storage slots in batch module
why;
Previously, fetching partial slot ranges first has a chance of
terminating the worker peer 9due to network error) while there were
many inheritable storage slots on the queue.
Now, inheritance is checked first, then full slot ranges and finally
partial ranges.
* Update logging
* Bundled node information for healing into single object `NodeSpecs`
why:
Previously, partial paths and node keys were kept in separate variables.
This approach was error prone due to copying/reassembling function
argument objects.
As all partial paths, keys, and node data types are more or less handled
as `Blob`s over the network (using Eth/6x, or Snap/1) it makes sense to
hold these `Blob`s as named field in a single object (even if not all
fields are active for the current purpose.)
* For good housekeeping, using `NodeKey` type only for account keys
why:
previously, a mixture of `NodeKey` and `Hash256` was used. Now, only
state or storage root keys use the `Hash256` type.
* Always accept latest pivot (and not a slightly older one)
why;
For testing it was tried to use a slightly older pivot state root than
available. Some anecdotal tests seemed to suggest an advantage so that
more peers are willing to serve on that older pivot. But this could not
be confirmed in subsequent tests (still anecdotal, though.)
As a side note, the distance of the latest pivot to its predecessor is
at least 128 (or whatever the constant `minPivotBlockDistance` is
assigned to.)
* Reshuffle name components for some file and function names
why:
Clarifies purpose:
"storages" becomes: "storage slots"
"store" becomes: "range fetch"
* Stash away currently unused modules in sub-folder named "notused"
2022-10-27 13:49:28 +00:00
|
|
|
dd.data.accounts[0].accKey.to(NodeTag),
|
|
|
|
dd.data.accounts[^1].accKey.to(NodeTag))
|
2022-07-01 11:42:17 +00:00
|
|
|
|
|
|
|
if accMinPt < iv.minPt:
|
|
|
|
# Not allowed
|
|
|
|
trace trSnapRecvProtocolViolation & "min too small in AccountRange", peer,
|
2022-11-01 15:07:44 +00:00
|
|
|
pivot, nAccounts, nProof, accRange=NodeTagRange.new(accMinPt, accMaxPt),
|
|
|
|
reqRange=iv
|
2022-09-16 07:24:12 +00:00
|
|
|
return err(ComAccountsMinTooSmall)
|
2022-07-01 11:42:17 +00:00
|
|
|
|
|
|
|
if iv.maxPt < accMaxPt:
|
|
|
|
# github.com/ethereum/devp2p/blob/master/caps/snap.md#getaccountrange-0x00:
|
|
|
|
# Notes:
|
|
|
|
# * [..]
|
|
|
|
# * [..]
|
|
|
|
# * [..] If no accounts exist between startingHash and limitHash, then the
|
|
|
|
# first (if any) account after limitHash must be provided.
|
|
|
|
if 1 < nAccounts:
|
2022-08-04 08:04:30 +00:00
|
|
|
# Geth always seems to allow the last account to be larger than the
|
|
|
|
# limit (seen with Geth/v1.10.18-unstable-4b309c70-20220517.)
|
Prep for full sync after snap make 4 (#1282)
* Re-arrange fetching storage slots in batch module
why;
Previously, fetching partial slot ranges first has a chance of
terminating the worker peer 9due to network error) while there were
many inheritable storage slots on the queue.
Now, inheritance is checked first, then full slot ranges and finally
partial ranges.
* Update logging
* Bundled node information for healing into single object `NodeSpecs`
why:
Previously, partial paths and node keys were kept in separate variables.
This approach was error prone due to copying/reassembling function
argument objects.
As all partial paths, keys, and node data types are more or less handled
as `Blob`s over the network (using Eth/6x, or Snap/1) it makes sense to
hold these `Blob`s as named field in a single object (even if not all
fields are active for the current purpose.)
* For good housekeeping, using `NodeKey` type only for account keys
why:
previously, a mixture of `NodeKey` and `Hash256` was used. Now, only
state or storage root keys use the `Hash256` type.
* Always accept latest pivot (and not a slightly older one)
why;
For testing it was tried to use a slightly older pivot state root than
available. Some anecdotal tests seemed to suggest an advantage so that
more peers are willing to serve on that older pivot. But this could not
be confirmed in subsequent tests (still anecdotal, though.)
As a side note, the distance of the latest pivot to its predecessor is
at least 128 (or whatever the constant `minPivotBlockDistance` is
assigned to.)
* Reshuffle name components for some file and function names
why:
Clarifies purpose:
"storages" becomes: "storage slots"
"store" becomes: "range fetch"
* Stash away currently unused modules in sub-folder named "notused"
2022-10-27 13:49:28 +00:00
|
|
|
if iv.maxPt < dd.data.accounts[^2].accKey.to(NodeTag):
|
2022-11-08 18:56:04 +00:00
|
|
|
# The second largest should not excceed the top one requested.
|
2022-08-04 08:04:30 +00:00
|
|
|
trace trSnapRecvProtocolViolation & "AccountRange top exceeded", peer,
|
2022-11-01 15:07:44 +00:00
|
|
|
pivot, nAccounts, nProof,
|
|
|
|
accRange=NodeTagRange.new(iv.minPt, accMaxPt), reqRange=iv
|
2022-09-16 07:24:12 +00:00
|
|
|
return err(ComAccountsMaxTooLarge)
|
2022-08-04 08:04:30 +00:00
|
|
|
|
2022-11-08 18:56:04 +00:00
|
|
|
trace trSnapRecvReceived & "AccountRange", peer, pivot, nAccounts, nProof,
|
|
|
|
accRange=NodeTagRange.new(accMinPt, accMaxPt), reqRange=iv
|
2022-09-02 18:16:09 +00:00
|
|
|
|
2022-07-01 11:42:17 +00:00
|
|
|
return ok(dd)
|
2022-06-16 08:58:50 +00:00
|
|
|
|
|
|
|
# ------------------------------------------------------------------------------
|
|
|
|
# End
|
|
|
|
# ------------------------------------------------------------------------------
|