nimbus-eth1/nimbus/db/ledger
Jordan Hrycaj a1161b537b
Core db update storage root management for sub tries (#1964)
* Aristo: Re-phrase `LayerDelta` and `LayerFinal` as object references

why:
  Avoids copying in some cases

* Fix copyright header

* Aristo: Verify `leafTie.root` function argument for `merge()` proc

why:
  Zero root will lead to inconsistent DB entry

* Aristo: Update failure condition for hash labels compiler `hashify()`

why:
  Node need not be rejected as long as links are on the schedule. In
  that case, `redo[]` is to become `wff.base[]` at a later stage.

  This amends an earlier fix, part of #1952 by also testing against
  the target nodes of the `wff.base[]` sets.

* Aristo: Add storage root glue record to `hashify()` schedule

why:
  An account leaf node might refer to a non-resolvable storage root ID.
  Storage root node chains will end up at the storage root. So the link
  `storage-root->account-leaf` needs an extra item in the schedule.

* Aristo: fix error code returned by `fetchPayload()`

details:
  Final error code is implied by the error code form the `hikeUp()`
  function.

* CoreDb: Discard `createOk` argument in API `getRoot()` function

why:
  Not needed for the legacy DB. For the `Arsto` DB, a lazy approach is
  implemented where a stprage root node is created on-the-fly.

* CoreDb: Prevent `$$` logging in some cases

why:
  Logging the function `$$` is not useful when it is used for internal
  use, i.e. retrieving an an error text for logging.

* CoreDb: Add `tryHashFn()` to API for pretty printing

why:
  Pretty printing must not change the hashification status for the
  `Aristo` DB. So there is an independent API wrapper for getting the
  node hash which never updated the hashes.

* CoreDb: Discard `update` argument in API `hash()` function

why:
  When calling the API function `hash()`, the latest state is always
  wanted. For a version that uses the current state as-is without checking,
  the function `tryHash()` was added to the backend.

* CoreDb: Update opaque vertex ID objects for the `Aristo` backend

why:
  For `Aristo`, vID objects encapsulate a numeric `VertexID`
  referencing a vertex (rather than a node hash as used on the
  legacy backend.) For storage sub-tries, there might be no initial
  vertex known when the descriptor is created. So opaque vertex ID
  objects are supported without a valid `VertexID` which will be
  initalised on-the-fly when the first item is merged.

* CoreDb: Add pretty printer for opaque vertex ID objects

* Cosmetics, printing profiling data

* CoreDb: Fix segfault in `Aristo` backend when creating MPT descriptor

why:
  Missing initialisation  error

* CoreDb: Allow MPT to inherit shared context on `Aristo` backend

why:
  Creates descriptors with different storage roots for the same
  shared `Aristo` DB descriptor.

* Cosmetics, update diagnostic message items for `Aristo` backend

* Fix Copyright year
2024-01-11 19:11:38 +00:00
..
backend Optional accounts cache module for creating genesis (#1897) 2023-11-20 11:51:43 +00:00
base Core db update storage root management for sub tries (#1964) 2024-01-11 19:11:38 +00:00
.gitignore Add check copyright year linter to CI 2023-11-01 10:41:20 +07:00
README.md Ledger abstraction for accounts cache (#1824) 2023-10-18 20:27:22 +01:00
accounts_cache.nim Fix default pruning for ledger and update core db and ledger logging (#1861) 2023-10-25 15:03:09 +01:00
accounts_ledger.nim Core db update storage root management for sub tries (#1964) 2024-01-11 19:11:38 +00:00
base.nim Core db aristo hasher profiling and timing improvement (#1938) 2023-12-12 17:47:41 +00:00
base_iterators.nim Core db aristo hasher profiling and timing improvement (#1938) 2023-12-12 17:47:41 +00:00
distinct_ledgers.nim Core db update storage root management for sub tries (#1964) 2024-01-11 19:11:38 +00:00

README.md

The file accounts_cache.nim has been relocated

Background

The new LedgerRef module unifies different implementations of the accounts_cache. It is intended to be used as new base method for all of the AccountsCache implementations. Only constructors differ, depending on the implementation.

This was needed to accomodate for different CoreDb API paradigms. While the overloaded legacy AccountsCache implementation is just a closure based wrapper around the accounts_cache module, the overloaded AccountsLedgerRef is a closure based wrapper around the accounts_ledger module with the new CoreDb API returning Result[] values and saparating the meaning of trie root hash and trie root reference.

This allows to use the legacy hexary database (with the new CoreDb API) as well as the Aristo database (only supported on new API.)

Instructions

Legacy notation LedgerRef replacement Comment
import accounts_cache import ledger preferred method,
AccountsCache.init(..) AccountsCache.init(..) wraps AccountsCache
methods
or
import ledger/accounts_cache stay with legacy
AccountsCache.init(..) version of
AccountsCache
--
fn(ac: AccountsCache) fn(ac: LedgerRef) function example for
preferred wrapper
or method
fn(ac: AccountsCache) with legacy version,
no change here

The constructor decides which CoreDb API is to be used

Legacy API constructor new API Constructor
import ledger import ledger
let w = AccountsCache.init(..) let w = AccountsLedgerRef.init(..)