2022-08-24 13:44:18 +00:00
|
|
|
# Nimbus
|
Core db and aristo updates for destructor and tx logic (#1894)
* Disable `TransactionID` related functions from `state_db.nim`
why:
Functions `getCommittedStorage()` and `updateOriginalRoot()` from
the `state_db` module are nowhere used. The emulation of a legacy
`TransactionID` type functionality is administratively expensive to
provide by `Aristo` (the legacy DB version is only partially
implemented, anyway).
As there is no other place where `TransactionID`s are used, they will
not be provided by the `Aristo` variant of the `CoreDb`. For the
legacy DB API, nothing will change.
* Fix copyright headers in source code
* Get rid of compiler warning
* Update Aristo code, remove unused `merge()` variant, export `hashify()`
why:
Adapt to upcoming `CoreDb` wrapper
* Remove synced tx feature from `Aristo`
why:
+ This feature allowed to synchronise transaction methods like begin,
commit, and rollback for a group of descriptors.
+ The feature is over engineered and not needed for `CoreDb`, neither
is it complete (some convergence features missing.)
* Add debugging helpers to `Kvt`
also:
Update database iterator, add count variable yield argument similar
to `Aristo`.
* Provide optional destructors for `CoreDb` API
why;
For the upcoming Aristo wrapper, this allows to control when certain
smart destruction and update can take place. The auto destructor works
fine in general when the storage/cache strategy is known and acceptable
when creating descriptors.
* Add update option for `CoreDb` API function `hash()`
why;
The hash function is typically used to get the state root of the MPT.
Due to lazy hashing, this might be not available on the `Aristo` DB.
So the `update` function asks for re-hashing the gurrent state changes
if needed.
* Update API tracking log mode: `info` => `debug
* Use shared `Kvt` descriptor in new Ledger API
why:
No need to create a new descriptor all the time
2023-11-16 19:35:03 +00:00
|
|
|
# Copyright (c) 2021-2023 Status Research & Development GmbH
|
2022-08-24 13:44:18 +00:00
|
|
|
# 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.
|
|
|
|
|
|
|
|
import
|
2023-11-08 12:18:32 +00:00
|
|
|
std/[os, strformat, strutils],
|
2022-08-24 13:44:18 +00:00
|
|
|
eth/common,
|
|
|
|
stew/byteutils,
|
2023-02-15 10:14:40 +00:00
|
|
|
../../nimbus/sync/[protocol, snap/range_desc],
|
2022-08-24 13:44:18 +00:00
|
|
|
./gunzip
|
|
|
|
|
2023-11-08 12:18:32 +00:00
|
|
|
import
|
|
|
|
nimcrypto/utils except toHex
|
|
|
|
|
2022-08-24 13:44:18 +00:00
|
|
|
type
|
|
|
|
UndumpState = enum
|
|
|
|
UndumpHeader
|
|
|
|
UndumpStateRoot
|
|
|
|
UndumpBase
|
2022-09-02 18:16:09 +00:00
|
|
|
UndumpAccountList
|
2022-08-24 13:44:18 +00:00
|
|
|
UndumpProofs
|
|
|
|
UndumpCommit
|
|
|
|
UndumpError
|
2022-09-02 18:16:09 +00:00
|
|
|
UndumpSkipUntilCommit
|
2022-08-24 13:44:18 +00:00
|
|
|
|
2022-09-02 18:16:09 +00:00
|
|
|
UndumpAccounts* = object
|
2022-08-24 13:44:18 +00:00
|
|
|
## Palatable output for iterator
|
|
|
|
root*: Hash256
|
|
|
|
base*: NodeTag
|
|
|
|
data*: PackedAccountRange
|
2022-09-02 18:16:09 +00:00
|
|
|
seenAccounts*: int
|
|
|
|
seenStorages*: int
|
2022-08-24 13:44:18 +00:00
|
|
|
|
|
|
|
# ------------------------------------------------------------------------------
|
|
|
|
# Private helpers
|
|
|
|
# ------------------------------------------------------------------------------
|
|
|
|
|
|
|
|
template say(args: varargs[untyped]) =
|
|
|
|
# echo args
|
|
|
|
discard
|
|
|
|
|
|
|
|
proc toByteSeq(s: string): seq[byte] =
|
2022-09-03 18:15:35 +00:00
|
|
|
utils.fromHex(s)
|
2022-08-24 13:44:18 +00:00
|
|
|
|
|
|
|
proc fromHex(T: type Hash256; s: string): T =
|
|
|
|
result.data = ByteArray32.fromHex(s)
|
|
|
|
|
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
|
|
|
proc fromHex(T: type NodeKey; s: string): T =
|
|
|
|
ByteArray32.fromHex(s).T
|
|
|
|
|
2022-08-24 13:44:18 +00:00
|
|
|
proc fromHex(T: type NodeTag; s: string): T =
|
|
|
|
UInt256.fromBytesBE(ByteArray32.fromHex(s)).T
|
|
|
|
|
|
|
|
# ------------------------------------------------------------------------------
|
|
|
|
# Public capture
|
|
|
|
# ------------------------------------------------------------------------------
|
|
|
|
|
2022-09-02 18:16:09 +00:00
|
|
|
proc dumpAccounts*(
|
2022-08-24 13:44:18 +00:00
|
|
|
root: Hash256;
|
|
|
|
base: NodeTag;
|
|
|
|
data: PackedAccountRange;
|
|
|
|
): string =
|
|
|
|
## Dump accounts data in parseable Ascii text
|
|
|
|
proc ppStr(blob: Blob): string =
|
2023-11-08 12:18:32 +00:00
|
|
|
blob.toHex
|
2022-08-24 13:44:18 +00:00
|
|
|
|
2023-02-15 10:14:40 +00:00
|
|
|
proc ppStr(proof: SnapProof): string =
|
2023-03-03 20:01:59 +00:00
|
|
|
proof.to(Blob).ppStr
|
2023-02-15 10:14:40 +00:00
|
|
|
|
2022-08-24 13:44:18 +00:00
|
|
|
proc ppStr(hash: Hash256): string =
|
2023-11-08 12:18:32 +00:00
|
|
|
hash.data.toHex
|
2022-08-24 13:44:18 +00:00
|
|
|
|
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
|
|
|
proc ppStr(key: NodeKey): string =
|
2023-11-08 12:18:32 +00:00
|
|
|
key.ByteArray32.toHex
|
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
|
|
|
|
2022-08-24 13:44:18 +00:00
|
|
|
result = "accounts " & $data.accounts.len & " " & $data.proof.len & "\n"
|
|
|
|
|
|
|
|
result &= root.ppStr & "\n"
|
|
|
|
result &= base.to(Hash256).ppStr & "\n"
|
|
|
|
|
|
|
|
for n in 0 ..< data.accounts.len:
|
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
|
|
|
result &= data.accounts[n].accKey.ppStr & " "
|
2022-08-24 13:44:18 +00:00
|
|
|
result &= data.accounts[n].accBlob.ppStr & "\n"
|
|
|
|
|
2022-09-02 18:16:09 +00:00
|
|
|
if 0 < data.proof.len:
|
|
|
|
result &= "# ----\n"
|
|
|
|
for n in 0 ..< data.proof.len:
|
|
|
|
result &= data.proof[n].ppStr & "\n"
|
2022-08-24 13:44:18 +00:00
|
|
|
|
|
|
|
result &= "commit\n"
|
|
|
|
|
|
|
|
# ------------------------------------------------------------------------------
|
|
|
|
# Public undump
|
|
|
|
# ------------------------------------------------------------------------------
|
|
|
|
|
2022-09-02 18:16:09 +00:00
|
|
|
iterator undumpNextAccount*(gzFile: string): UndumpAccounts =
|
2022-08-24 13:44:18 +00:00
|
|
|
var
|
|
|
|
state = UndumpHeader
|
2022-09-02 18:16:09 +00:00
|
|
|
data: UndumpAccounts
|
2022-08-24 13:44:18 +00:00
|
|
|
nAccounts = 0u
|
|
|
|
nProofs = 0u
|
2022-09-02 18:16:09 +00:00
|
|
|
seenAccounts = 0
|
|
|
|
seenStorages = 0
|
2022-08-24 13:44:18 +00:00
|
|
|
|
|
|
|
if not gzFile.fileExists:
|
|
|
|
raiseAssert &"No such file: \"{gzFile}\""
|
|
|
|
|
|
|
|
for lno,line in gzFile.gunzipLines:
|
|
|
|
if line.len == 0 or line[0] == '#':
|
|
|
|
continue
|
|
|
|
var flds = line.split
|
|
|
|
#echo ">>> ",
|
|
|
|
# " lno=", lno,
|
|
|
|
# " state=", state,
|
|
|
|
# " nAccounts=", nAccounts,
|
|
|
|
# " nProofs=", nProofs,
|
|
|
|
# " flds=", flds
|
|
|
|
|
|
|
|
case state:
|
2022-09-02 18:16:09 +00:00
|
|
|
of UndumpSkipUntilCommit:
|
|
|
|
if flds.len == 1 and flds[0] == "commit":
|
|
|
|
state = UndumpHeader
|
|
|
|
|
2022-08-24 13:44:18 +00:00
|
|
|
of UndumpHeader, UndumpError:
|
|
|
|
if flds.len == 3 and flds[0] == "accounts":
|
|
|
|
nAccounts = flds[1].parseUInt
|
|
|
|
nProofs = flds[2].parseUInt
|
|
|
|
data.reset
|
|
|
|
state = UndumpStateRoot
|
2022-09-02 18:16:09 +00:00
|
|
|
seenAccounts.inc
|
|
|
|
continue
|
|
|
|
if 1 < flds.len and flds[0] == "storages":
|
|
|
|
seenStorages.inc
|
|
|
|
state = UndumpSkipUntilCommit
|
2022-08-24 13:44:18 +00:00
|
|
|
continue
|
|
|
|
if state != UndumpError:
|
|
|
|
state = UndumpError
|
|
|
|
say &"*** line {lno}: expected header, got {line}"
|
|
|
|
|
|
|
|
of UndumpStateRoot:
|
|
|
|
if flds.len == 1:
|
|
|
|
data.root = Hash256.fromHex(flds[0])
|
|
|
|
state = UndumpBase
|
|
|
|
continue
|
|
|
|
state = UndumpError
|
|
|
|
say &"*** line {lno}: expected state root, got {line}"
|
|
|
|
|
|
|
|
of UndumpBase:
|
|
|
|
if flds.len == 1:
|
|
|
|
data.base = NodeTag.fromHex(flds[0])
|
2022-09-02 18:16:09 +00:00
|
|
|
if 0 < nAccounts:
|
|
|
|
state = UndumpAccountList
|
|
|
|
continue
|
|
|
|
if 0 < nProofs:
|
|
|
|
state = UndumpProofs
|
|
|
|
continue
|
|
|
|
state = UndumpCommit
|
2022-08-24 13:44:18 +00:00
|
|
|
continue
|
|
|
|
state = UndumpError
|
|
|
|
say &"*** line {lno}: expected account base, got {line}"
|
|
|
|
|
2022-09-02 18:16:09 +00:00
|
|
|
of UndumpAccountList:
|
2022-08-24 13:44:18 +00:00
|
|
|
if flds.len == 2:
|
|
|
|
data.data.accounts.add 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: NodeKey.fromHex(flds[0]),
|
2022-08-24 13:44:18 +00:00
|
|
|
accBlob: flds[1].toByteSeq)
|
|
|
|
nAccounts.dec
|
2022-09-02 18:16:09 +00:00
|
|
|
if 0 < nAccounts:
|
|
|
|
continue
|
|
|
|
if 0 < nProofs:
|
2022-08-24 13:44:18 +00:00
|
|
|
state = UndumpProofs
|
2022-09-02 18:16:09 +00:00
|
|
|
continue
|
|
|
|
state = UndumpCommit
|
2022-08-24 13:44:18 +00:00
|
|
|
continue
|
|
|
|
state = UndumpError
|
|
|
|
say &"*** line {lno}: expected account data, got {line}"
|
|
|
|
|
|
|
|
of UndumpProofs:
|
|
|
|
if flds.len == 1:
|
2023-03-03 20:01:59 +00:00
|
|
|
data.data.proof.add flds[0].toByteSeq.to(SnapProof)
|
2022-08-24 13:44:18 +00:00
|
|
|
nProofs.dec
|
|
|
|
if nProofs <= 0:
|
|
|
|
state = UndumpCommit
|
|
|
|
continue
|
|
|
|
state = UndumpError
|
|
|
|
say &"*** expected proof data, got {line}"
|
|
|
|
|
|
|
|
of UndumpCommit:
|
|
|
|
if flds.len == 1 and flds[0] == "commit":
|
2022-09-02 18:16:09 +00:00
|
|
|
data.seenAccounts = seenAccounts
|
|
|
|
data.seenStorages = seenStorages
|
2022-08-24 13:44:18 +00:00
|
|
|
yield data
|
|
|
|
state = UndumpHeader
|
|
|
|
continue
|
|
|
|
state = UndumpError
|
|
|
|
say &"*** line {lno}: expected commit, got {line}"
|
|
|
|
|
|
|
|
# ------------------------------------------------------------------------------
|
|
|
|
# End
|
|
|
|
# ------------------------------------------------------------------------------
|