Data storage formats
Besu offers two formats for storing the world state, Bonsai Tries and Forest of Tries.
Bonsai Tries
Bonsai Tries is a data storage layout policy designed to reduce storage requirements and increase read performance. This is the default for Besu.
Bonsai stores leaf values in a trie log, separate from the branches of the trie. Bonsai stores nodes by the location of the node instead of the hash of the node. Bonsai can access the leaf from the underlying storage directly using the account key. This greatly reduces the disk space needed for storage and allows for less resource-demanding and faster read performance. Bonsai inherently prunes orphaned nodes and old branches.
To run a node with Bonsai Tries data storage format, use the command line option --data-storage-format=BONSAI
.
Do not run an archive node with Bonsai Tries. Bonsai is designed for retrieving recent data only.
Forest of Tries
Forest of Tries, also called forest mode, is another method of representing the world state, and is more suitable for archive nodes.
In forest mode, each node in the trie is saved in a key-value store by hash. For each block, the world state is updated with new nodes, leaf nodes, and a new state root. Old leaf nodes remain in the underlying data store. Data is accessed and stored by hash, which increases the size of the database and increases the resources and time needed to access account data.
Forest pruning using the --pruning-enabled
option is no longer supported.
We recommend using Bonsai Tries to save disk space.
Forest of Tries vs. Bonsai Tries
Storage requirements
Forest mode uses significantly more memory than Bonsai. With a full node, forest mode uses an estimated 750 GB of storage, while Bonsai uses an estimated 650 GB of storage. Archive nodes must use forest mode, which uses an estimated 12 TB of storage.
Accessing data
Forest mode must go through all the branches by hash to read a leaf value. Bonsai can access the leaf from the underlying storage directly using the account key. Bonsai will generally read faster than forest mode, particularly if the blocks are more recent.
However, Bonsai becomes increasingly more resource-intensive the further in history you try to read data. To prevent this, you can limit how far Bonsai looks back while reconstructing data. The default limit Bonsai looks back is 512. To change the parameter, use the --bonsai-historical-block-limit
option. This might directly impact JSON-RPC API queries.
Using --bonsai-historical-block-limit
doesn't affect the size of the database being stored, only how far back to load. This means there is no "safe minimum" value to use with this option.
Syncing nodes
The following table shows the ways you can sync a full node with the different data storage formats using fast and snap sync.
Data storage format | Sync mode | Storage estimate | Can other nodes sync to your node? |
---|---|---|---|
Bonsai | Fast | 1140 GB | No |
Bonsai | Snap | 1090 GB | Yes |
Bonsai | Checkpoint | 840 GB | No |
Forest | Fast | 1200 GB | Yes |
We recommend using snap sync with Bonsai for the fastest sync and lowest storage requirements.