For background there is a design document relating to Bonsai DB in the wiki here
The issue for Bonsai archive is here and the PR is here. For context there was originally a draft PR which was a start at delivering the feature, and a re-based branch of that PR https://github.com/jframe/besu/tree/multi-version-flat-db-rebase
Design
Bonsai makes use of additional DB segments to store flat data in addition to the state trie. These segments include:
- ACCOUNT_INFO_STATE
- Key = hash of account
- Value = RLP encoded account state
- ACCOUNT_STORAGE_STORAGE
- Key = hash of account + hash of storage slot key
- Value = RLP encoded storage value
- CODE_STORAGE
- Key = hash of code or hash or account (based on--Xbonsai-code-using-code-hash-enabled config option)
- Value = the code
These are used to store account state, account storage, and code respectively.
In order to provide access to historic state and account storage, 2 new DB segments have been introduced:
- ACCOUNT_INFO_STATE_ARCHIVE
- ACCOUNT_STORAGE_ARCHIVE
Configuration
Bonsai archive is delivered as a new data storage format. Initially it will be experimental. To create a Bonsai archive node use --data-storage-format=X_BONSAI_ARCHIVE
Rocks DB column families
Currently the column families are identified by an individual byte. You need to know that e.g. 0x0a maps to "TRIE_LOG_STORAGE". The Bonsai archive work might be a good time to update the column families from bytes to string names to make querying the DB directly easier. This would likely mean moving the DATABASE_METADATA version from 2 to 3 and would require decisions about whether to upgrade existing DBs or just use the new names for new DBs.