143f2e99f5
* Aristo: Rename journal related sources and functions why: Previously, the naming was hinged on the phrases `fifo`, `filter` etc. which reflect the inner workings of cascaded filters. This was unfortunate for reading/understanding the source code for actions where the focus is the journal as a whole. * Aristo: Fix buffer overflow (path length truncating error) * Aristo: Tighten `hikeUp()` stop check, update error code why: Detect dangling vertex links. These are legit with `snap` sync processing but not with regular processing. * Aristo: Raise assert in regular mode `merge()` at a dangling link/edge why: With `snap` sync processing, partial trees are ok and can be amended. Not so in regular mode. Previously there was only a debug message when a non-legit dangling edge was encountered. * Aristo: Make sure that vertices are copied before modification why: Otherwise vertices from lower layers might also be modified * Aristo: Fix relaxed mode for validity checker `check()` * Remove cruft * Aristo: Update API for transaction handling details: + Split `aristo_tx.nim` into sub-modules + Split `forkWith()` into `findTx()` + `forkTx()` + Removed `forkTop()`, `forkBase()` (now superseded by new `forkTx()`) * CoreDb+Aristo: Fix initialiser (missing methods) |
||
|---|---|---|
| .. | ||
| aristo | ||
| core_db | ||
| kvt | ||
| ledger | ||
| notused | ||
| state_db | ||
| .gitignore | ||
| README.md | ||
| access_list.nim | ||
| aristo.nim | ||
| core_db.nim | ||
| distinct_tries.nim | ||
| geth_db.nim | ||
| incomplete_db.nim | ||
| kvstore_rocksdb.nim | ||
| kvt.nim | ||
| ledger.nim | ||
| state_db.nim | ||
| storage_types.nim | ||
| transient_storage.nim | ||
| trie_get_branch.nim | ||
| values_from_bytes.nim | ||
README.md
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.
-
-
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.
-
-
-
Sources:
./nimbus/db/aristo* -
Synopsis:
Revamped implementation of a hexary Merkle Patricia Tree.
-
-
-
Sources:
./nimbus/common* -
Synopsis:
Collected information for running block chain execution layer applications.
-
-
-
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.
-
-
-
Sources:
./nimbus/core/executor/* ./nimbus/evm/* -
Synopsis:
An implementation of the Ethereum Virtual Machine.
-
-
-
Sources:
./vendor/nim-eth/eth/trie/hexary.nim -
Synopsis:
Implementation of an MPT, see compact Merkle Patricia Tree.
-
-
-
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.)
-
-
-
Sources:
./nimbus/db/kvt* -
Synopsis:
Key value table interface for the Aristo DB (driver) module. Contrary to the Key-value table (driver), it is not used for MPT data.
-
-
-
Sources:
./nimbus/db/ledger* -
Synopsis:
Abstraction layer for either the legacy cache (driver) accounts cache (which works with the legacy DB (driver) backend only) or the ledger cache (driver) re-write which is supposed to work with all Core DB (API) backends.
-
-
-
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.
-
-
-
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.
-
-
-
Sources:
./nimbus/db/core_db/backend/legacy_* -
Synopsis:
Legacy database abstraction. It mostly forwards requests directly to the to the Key-value table (driver) and/or the hexary DB (driver).
-
-
-
Sources:
./vendor/nim-rocksdb/* -
Synopsis:
Persistent storage engine.
-
-
-
Sources:
./nimbus/evm/state.nim
./nimbus/evm/types.nim -
Synopsis:
Integrated collection of modules and methods relevant for the EVM.
-