Bonsai Tries

ANB Blockchain integrate Bonsai tries for faster transaction

ANB Blockchain applies bonsai tries within its system to be high advance and secured. a lattice-based cryptographic primitive that we apply to resolve some important open problems in the area. Applications of bonsai trees include an efficient, stateless 'hash-and-sign' signature scheme in the standard model (i.e., no random oracles), and The first hierarchical identity-based encryption (HIBE) scheme (also in the standard model) that does not rely on bilinear pairings. Interestingly, the abstract properties of bonsai trees seem to have no known realization in conventional number-theoretic cryptography. To know more about bonsai tries. Click here https://consensys.net/blog/news/bonsai-tries-a-big-update-for-small-state-storage-in-hyperledger-besu/

How ANB Bonsai Tries works?

Previously, Hyperledger Besu, like most Ethereum Mainnet clients, uses what’s called a “forest of tries” to store Ethereum’s complex and vital state. (As a refresher, state is defined as a set of variables describing a certain system at a specific time, which you can read more about here.) Pronounced, “try,” these data structures, when strung together (as trees), snapshot what the Ethereum blockchain looks like at a point in time. Transactions, account updates, smart contract changes, and metadata are all stored in tries within tries (for an explainer of Merkle trees see our handy infographic here).

When it comes to data storage and speed of systems ANB focuses to tighten its security and data efficiency. With the help of Bonsai Tries, ANB saves a lot of data storage in terms of its transaction capacity. This results in a non-friction system and no logs. The speed of transaction is maintained without bugs and nodal performance in terms of Proof-of-Staking is highly met.

This is the model of Bonsai Tries. datas are stored in compartments and chunck it into lower bytes.

Enter Bonsai Tries, a new storage format for Besu. The experimental “bonsai” flag, when set, starts a Besu node with a new “flat” storage structure. Instead of keeping large “trees” within the storage, Bonsai keeps only the most recent trie in its storage as well as a trie log layer. This log layer provides a smaller store of changes that, when needed, can be used to construct the complete history of the tries, not just the most recent. This reduces storage and offers much faster times for nodes to read any data about Ethereum’s current state (O(1) account lookups). It also makes accessing the most recent data on the blockchain much faster, though lookups farther back take a little more time. To get into the weeds, the bonsai approach also provides implicit tree pruning, reduced disk usage by nodes, faster synchronization of nodes, and a reduction of the client “running blocks behind” the network.

Tries log layer saves more space.

Performance Benchmarks

Now let’s look at some numbers. When we sort by the storage approach, a full archive of the Ethereum network is less than 1TB. Our tests showed in the older Forest mode, nearly 12.5TB were needed for the same archive. Even nodes running in Fastsync mode (designed to operate faster and lighter than a full archive), become much larger than those running Bonsai over time. When paired with Fastsync, Bonsai synchronizes with the Ethereum network 11 hours faster in our tests than the Forest mode. For those running nodes over time, this is a marked improvement for infrastructure. After two months, we recorded a ~554 GB difference in size between Fastsync Forest and Bonsai nodes. All of this culminates in faster read and storage performance for Besu nodes everywhere.