Jordan Hrycaj 8ed40c78e0
Core db+aristo provides tracer funtionality (#2089)
* Aristo: Provide descriptor fork based on search in transaction stack

details:
  Try to find the tx that has a particular pair `(vertex-id,hash-key)`,
  and by extension try filter and backend if the former fails.

* Cleanup & docu

* CoreDb+Aristo: Implement context re-position to earlier in-memory state

why:
  It is a easy way to explore how there can be concurrent access to the
  same backend storage DB with different view states. This one can access
  an earlier state from the transaction stack.

* CoreDb+Aristo: Populate tracer stubs with real functionality

* Update `tracer.nim` to new API

why:
  Legacy API does not sufficiently support `Aristo`

* Fix logging problems in tracer

details:
  Debug logging turned off by default

* Fix function prototypes

* Add Copyright header

* Add tables import

why:
  For older compiler versions on CI
2024-03-21 10:45:57 +00:00
..
2024-03-20 15:15:56 +00:00

Nimbus-eth1 -- Ethereum execution layer database architecture

Last update: 2024-03-08

The following diagram gives a simplified view how components relate with regards to the data storage management.

An arrow between components a and b (as in a->b) is meant to be read as a relies directly on b, or a is served by b. For classifying the functional type of a component in the below diagram, the abstraction type is enclosed in brackets after the name of a component.

  • (application)
    This is a group of software modules at the top level of the hierarchy. In the diagram below, the EVM is used as an example. Another application might be the RPC service.

  • (API)
    The API classification is used for a thin software layer hiding a set of different drivers where only one driver is active for the same API instance. It servers as sort of a logical switch.

  • (concentrator)
    The concentrator merges several sub-module instances and provides their collected services as a single unified instance. There is not much additional logic implemented besides what the sub-modules provide.

  • (driver)
    The driver instances are sort of the lower layer workhorses. The implement logic for solving a particular problem, providing a typically well defined service, etc.

  • (engine)
    This is a bottom level driver in the below diagram.

                                          +-------------------+
                                          | EVM (application) |
                                          +-------------------+
                                               |          |
                                               v          |
                            +-------------------------+   |
                            | State DB (concentrator) |   |
                            +-------------------------+   |
                                |           |       |     |
                                v           |       |     |
       +----------------------------+       |       |     |
       |       Ledger (API)         |       |       |     |
       +----------------------------+       |       |     |
                    |      |                |       |     |
                    v      v                |       |     |
       +--------------+  +--------------+   |       |     |
       | legacy cache |  | ledger cache |   |       |     |
       |   (driver)   |  |   (driver)   |   |       |     |
       +--------------+  +--------------+   |       |     |
                    |      |                v       |     |
                    |      |   +----------------+   |     |
                    |      |   |   Common       |   |     |
                    |      |   | (concentrator) |   |     |
                    |      |   +----------------+   |     |
                    |      |         |              |     |
                    v      v         v              v     v
       +---------------------------------------------------------------------+
       |               Core DB (API)                                         |
       +---------------------------------------------------------------------+
                       |                  |
                       v                  v
       +--------------------------+   +--------------------------------------+
       | legacy DB (concentrator) |   |   Aristo DB (driver,concentrator)    |
       +--------------------------+   +--------------------------------------+
             |                 |                |          |
             v                 |                v          v
       +--------------------+  |     +--------------+  +---------------------+
       | Hexary DB (driver) |  |     | Kvt (driver) |  | Aristo MPT (driver) |
       +--------------------+  |     +--------------+  +---------------------+
             |                 |                |          |
             v                 v                |          |
       +--------------------------+             |          |
       | Key-value table (driver) |             |          |
       +--------------------------+             |          |
                    |                           |          |
                    v                           v          v
       +---------------------------------------------------------------------+
       |                Rocks DB (engine)                                    |
       +---------------------------------------------------------------------+
    

Here is a list of path references for the components with some explanation. The sources for the components are not always complete but indicate the main locations where to start looking at.

  • Aristo DB (driver)

    • Sources:
      ./nimbus/db/core_db/backend/aristo_*

    • Synopsis:
      Combines both, the Kvt and the Aristo driver sub-modules providing an interface similar to the legacy DB (concentrator) module.

  • Aristo MPT (driver)

    • Sources:
      ./nimbus/db/aristo*

    • Synopsis:
      Revamped implementation of a hexary Merkle Patricia Tree.

  • Common (concentrator)

    • Sources:
      ./nimbus/common*

    • Synopsis:
      Collected information for running block chain execution layer applications.

  • Core DB (API)

    • Sources:
      ./nimbus/db/core_db*

    • Synopsis:
      Database abstraction layer. Unless for legacy applications, there should be no need to reach out to the layers below.

  • EVM (application)

    • Sources:
      ./nimbus/core/executor/* ./nimbus/evm/*

    • Synopsis:
      An implementation of the Ethereum Virtual Machine.

  • Hexary DB (driver)

  • Key-value table (driver)

    • Sources:
      ./vendor/nim-eth/eth/trie/db.nim

    • Synopsis:
      Key value table interface to be used directly for key-value storage or by the Hexary DB (driver) module for storage. Some magic is applied in order to treat hexary data accordingly (based on key length.)

  • Kvt (driver)

  • Ledger (API)

  • ledger cache (driver)

    • Sources:
      ./nimbus/db/ledger/accounts_ledger.nim
      ./nimbus/db/ledger/backend/accounts_ledger*
      ./nimbus/db/ledger/distinct_ledgers.nim

    • Synopsis:
      Management of accounts and storage data. This is a re-write of the legacy DB (driver) which is supposed to work with all Core DB (API) backends.

  • legacy cache (driver)

    • Sources:
      ./nimbus/db/distinct_tries.nim
      ./nimbus/db/ledger/accounts_cache.nim
      ./nimbus/db/ledger/backend/accounts_cache*

    • Synopsis:
      Management of accounts and storage data. It works only for the legacy driver of the Core DB (API) backend.

  • legacy DB (concentrator)

  • Rocks DB (engine)

    • Sources:
      ./vendor/nim-rocksdb/*

    • Synopsis:
      Persistent storage engine.

  • State DB (concentrator)

    • Sources:
      ./nimbus/evm/state.nim
      ./nimbus/evm/types.nim

    • Synopsis:
      Integrated collection of modules and methods relevant for the EVM.