status-im
/
nimbus-eth1
mirror of https://github.com/status-im/nimbus-eth1.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity
nimbus-eth1/nimbus/db/aristo/aristo_constants.nim

36 lines
1.0 KiB
Nim
Raw Normal View History

Multi layer architecture 4 aristo db (#1581) * Cosmetics, renamed fields (eVtx, bVtx) -> (eVid, bVid) * Multilayered delta architecture for Aristo DB details: Any VertexID or data retrieval needs to go down the rabbit hole and fetch/get/manipulate the bottom layer -- even without explicit backend. * Direct reference to backend from top-level layer why: Some services as the vid management needs to be synchronised among all layers. So access is optimised.
2023-05-14 17:43:01 +00:00
# nimbus-eth1
# 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.
{.push raises: [].}
import
Aristo db address sup trie items properly (#1600) * Fix include why: Eth67 not default yet so that got missed * Rename `LeafKey` => `LeafTie` why: Name is a pen picture of what this object is for. Also, it avoids the ubiquitous term `key`. * Provided `getOrVoid()` wrapper for `getOrDefault()` also: Provide `isValid()` syntactic sugar for `.isNil.not`, `!= 0` etc. Reorg descriptor source, split into sub-sources * Bundled `NodeKey` objects with root ID and called it `HashLabel` why: `NodeKey` (aka repurposed Hash265) objects are unique only within a particular sub-trie (e.g. storage slots) which are kept separated (i.e non-interleaved) by design. This is not applied to the backend as the map VertexID->NodeKey labelling the nodes needs not be injective. For the in-memory database (transaction) layers, the injective map VertexID->(VertexID,NodeKey) is used where the first field of the image tuple is the root ID of the sub-trie the `NodeKey` object is valid. So identical storage tries for different accounts can be represented.
2023-06-12 13:48:47 +00:00
eth/[common, trie/nibbles],
./aristo_desc/aristo_types_identifiers
Multi layer architecture 4 aristo db (#1581) * Cosmetics, renamed fields (eVtx, bVtx) -> (eVid, bVid) * Multilayered delta architecture for Aristo DB details: Any VertexID or data retrieval needs to go down the rabbit hole and fetch/get/manipulate the bottom layer -- even without explicit backend. * Direct reference to backend from top-level layer why: Some services as the vid management needs to be synchronised among all layers. So access is optimised.
2023-05-14 17:43:01 +00:00
const
EmptyBlob* = seq[byte].default
## Useful shortcut (borrowed from `sync/snap/constants.nim`)
EmptyNibbleSeq* = EmptyBlob.initNibbleRange
## Useful shortcut (borrowed from `sync/snap/constants.nim`)
Aristo db update foreground caching (#1605) * Fix vertex ID generator state handling for rocksdb backend why: * Key error in walk iterator * Needs to be loaded when opening the database * Use non-zero sub-table prefixes for rocksdb why: Handy for debugging * Fix error code for missing key on rocksdb backend why: Previously returned `VOID_HASH_KEY` rather than `GetKeyNotFound` * Explicitly copy vertex data between internal table and function/result argument why: Function argument or return reference may still refer to the same data object. * Updated error symbols why: Error symbol names for the hike module now start with the prefix `Hike`. * Write back modified branch node into local top layer cache why: With the backend available, the source of the branch node references might not be the top layer cache. So any change must be explicitely recorded.
2023-06-22 11:13:24 +00:00
EmptyVidSeq* = seq[VertexID].default
## Useful shortcut
Extended data Payload specs for the backend. (#1630) why: For the main tree with root vertex ID 1, the leaf nodes hold the account data. These accounts may link to sub trees the storage root node ID of which must be registered here. There is no reverse key lookup on the backend. note: These definitions are experimental. Also, there are some tests missing for validating Payload data conversions.
2023-07-05 20:27:48 +00:00
VOID_CODE_HASH* = EMPTY_CODE_HASH
Aristo db address sup trie items properly (#1600) * Fix include why: Eth67 not default yet so that got missed * Rename `LeafKey` => `LeafTie` why: Name is a pen picture of what this object is for. Also, it avoids the ubiquitous term `key`. * Provided `getOrVoid()` wrapper for `getOrDefault()` also: Provide `isValid()` syntactic sugar for `.isNil.not`, `!= 0` etc. Reorg descriptor source, split into sub-sources * Bundled `NodeKey` objects with root ID and called it `HashLabel` why: `NodeKey` (aka repurposed Hash265) objects are unique only within a particular sub-trie (e.g. storage slots) which are kept separated (i.e non-interleaved) by design. This is not applied to the backend as the map VertexID->NodeKey labelling the nodes needs not be injective. For the in-memory database (transaction) layers, the injective map VertexID->(VertexID,NodeKey) is used where the first field of the image tuple is the root ID of the sub-trie the `NodeKey` object is valid. So identical storage tries for different accounts can be represented.
2023-06-12 13:48:47 +00:00
## Equivalent of `nil` for `Account` object code hash
Detach from snap/sync declarations & definitions (#1601) why: Tests and some basic components were originally borrowed from the snap/sync implementation. These have fully been re-implemented.
2023-06-12 18:16:03 +00:00
VOID_HASH_KEY* = EMPTY_ROOT_HASH.to(HashKey)
## Equivalent of `nil` for Merkle hash ket
VOID_HASH_LABEL* = HashLabel(root: VertexID(0), key: VOID_HASH_KEY)
Multi layer architecture 4 aristo db (#1581) * Cosmetics, renamed fields (eVtx, bVtx) -> (eVid, bVid) * Multilayered delta architecture for Aristo DB details: Any VertexID or data retrieval needs to go down the rabbit hole and fetch/get/manipulate the bottom layer -- even without explicit backend. * Direct reference to backend from top-level layer why: Some services as the vid management needs to be synchronised among all layers. So access is optimised.
2023-05-14 17:43:01 +00:00
# End