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/tests/test_aristo/test_blobify.nim

73 lines
2.0 KiB
Nim
Raw Normal View History

No ext update (#2494) * Imported/rebase from `no-ext`, PR #2485 Store extension nodes together with the branch Extension nodes must be followed by a branch - as such, it makes sense to store the two together both in the database and in memory: * fewer reads, writes and updates to traverse the tree * simpler logic for maintaining the node structure * less space used, both memory and storage, because there are fewer nodes overall There is also a downside: hashes can no longer be cached for an extension - instead, only the extension+branch hash can be cached - this seems like a fine tradeoff since computing it should be fast. TODO: fix commented code * Fix merge functions and `toNode()` * Update `merkleSignCommit()` prototype why: Result is always a 32bit hash * Update short Merkle hash key generation details: Ethereum reference MPTs use Keccak hashes as node links if the size of an RLP encoded node is at least 32 bytes. Otherwise, the RLP encoded node value is used as a pseudo node link (rather than a hash.) This is specified in the yellow paper, appendix D. Different to the `Aristo` implementation, the reference MPT would not store such a node on the key-value database. Rather the RLP encoded node value is stored instead of a node link in a parent node is stored as a node link on the parent database. Only for the root hash, the top level node is always referred to by the hash. * Fix/update `Extension` sections why: Were commented out after removal of a dedicated `Extension` type which left the system disfunctional. * Clean up unused error codes * Update unit tests * Update docu --------- Co-authored-by: Jacek Sieka <jacek@status.im>
2024-07-16 19:47:59 +00:00
# Nimbus
# Copyright (c) 2024 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.
{.used.}
import unittest2, ../../nimbus/db/aristo/aristo_blobify
suite "Aristo blobify":
test "VertexRef roundtrip":
let
leafRawData = VertexRef(vType: Leaf, lData: LeafPayload(pType: RawData))
leafAccount = VertexRef(vType: Leaf, lData: LeafPayload(pType: AccountData))
leafStoData =
VertexRef(vType: Leaf, lData: LeafPayload(pType: StoData, stoData: 42.u256))
branch = VertexRef(
vType: Branch,
bVid: [
VertexID(0),
VertexID(1),
VertexID(0),
VertexID(0),
VertexID(4),
VertexID(0),
VertexID(0),
VertexID(0),
VertexID(0),
VertexID(0),
VertexID(0),
VertexID(0),
VertexID(0),
VertexID(0),
VertexID(0),
VertexID(0),
],
)
extension = VertexRef(
vType: Branch,
simplify VertexRef (#2626) * move pfx out of variant which avoids pointless field type panic checks and copies on access * make `VertexRef` a non-inheritable object which reduces its memory footprint and simplifies its use - it's also unclear from a semantic point of view why inheritance makes sense for storing keys
2024-09-13 16:55:17 +00:00
pfx: NibblesBuf.nibble(2),
No ext update (#2494) * Imported/rebase from `no-ext`, PR #2485 Store extension nodes together with the branch Extension nodes must be followed by a branch - as such, it makes sense to store the two together both in the database and in memory: * fewer reads, writes and updates to traverse the tree * simpler logic for maintaining the node structure * less space used, both memory and storage, because there are fewer nodes overall There is also a downside: hashes can no longer be cached for an extension - instead, only the extension+branch hash can be cached - this seems like a fine tradeoff since computing it should be fast. TODO: fix commented code * Fix merge functions and `toNode()` * Update `merkleSignCommit()` prototype why: Result is always a 32bit hash * Update short Merkle hash key generation details: Ethereum reference MPTs use Keccak hashes as node links if the size of an RLP encoded node is at least 32 bytes. Otherwise, the RLP encoded node value is used as a pseudo node link (rather than a hash.) This is specified in the yellow paper, appendix D. Different to the `Aristo` implementation, the reference MPT would not store such a node on the key-value database. Rather the RLP encoded node value is stored instead of a node link in a parent node is stored as a node link on the parent database. Only for the root hash, the top level node is always referred to by the hash. * Fix/update `Extension` sections why: Were commented out after removal of a dedicated `Extension` type which left the system disfunctional. * Clean up unused error codes * Update unit tests * Update docu --------- Co-authored-by: Jacek Sieka <jacek@status.im>
2024-07-16 19:47:59 +00:00
bVid: [
VertexID(0),
VertexID(0),
VertexID(2),
VertexID(0),
VertexID(0),
VertexID(5),
VertexID(0),
VertexID(0),
VertexID(0),
VertexID(0),
VertexID(0),
VertexID(0),
VertexID(0),
VertexID(0),
VertexID(0),
VertexID(0),
],
)
check:
avoid some trivial memory allocations (#2587) * pre-allocate `blobify` data and remove redundant error handling (cannot fail on correct data) * use threadvar for temporary storage when decoding rdb, avoiding closure env * speed up database walkers by avoiding many temporaries ~5% perf improvement on block import, 100x on database iteration (useful for building analysis tooling)
2024-09-02 14:03:10 +00:00
deblobify(blobify(leafRawData), VertexRef)[] == leafRawData
deblobify(blobify(leafAccount), VertexRef)[] == leafAccount
deblobify(blobify(leafStoData), VertexRef)[] == leafStoData
deblobify(blobify(branch), VertexRef)[] == branch
deblobify(blobify(extension), VertexRef)[] == extension