Can this be plugged into reth or geth?

[chrisco512]

Do you have an example of using this as a backend for geth or reth? How difficult would it be to make it compatible?

[jumanzii]

+1 here. I guess it might be compatible for reth? is there anyone on this task?

[absolute0kelvin]

Maybe you cannot easily "plug" QMDB into reth or geth.

Both reth and geth use a "two-layer" architecture. The base layer is a normal kvdb (leveldb or MDBX) and all kinds of storages are built on this layer, such as:

1. A flat KV to fast read/write world state
2. An ADS (Merkle Patricia Trie) to calculated the world state root. Its leaves are hashes of the values in the flat KV
3. The historical block/transaction/events data for serving web3 rpc

QMDB is a single-layer architecture. It combines three functions (a kvdb, a flat world state and an ADS) into an integrated design. Only in this way it can reach very high performance.

So geth/reth must be changed largely to use QMDB.

[dboreham]

1. A flat KV to fast read/write world state
2. An ADS (Merkle Patricia Trie) to calculated the world state root. Its leaves are hashes of the values in the flat KV
3. The historical block/transaction/events data for serving web3 rpc

QMDB is a single-layer architecture. It combines three functions (a kvdb, a flat world state and an ADS) into an integrated design. Only in this way it can reach very high performance.

Isn't the entire point of a project like QMDB that it can plug into the "upper" interface of this arrangement, thereby providing the functionality of the original two lower layers?

So geth/reth must be changed largely to use QMDB.

Isn't that a fitness for purpose issue? If the problem being solved is "blockchain nodes are too slow/resource intensive" then the problem isn't solved until you have shown a blockchain node that's faster/consumes fewer resources? Showing microbenchmark results for CRUD operations is only a step toward that ultimate goal.