github.com/hyperledger/burrow@v0.34.5-0.20220512172541-77f09336001d/docs/reference/state.md (about)

     1  # State
     2  
     3  State is written to our EVM or WASM engines on executing bytecode provided by [`CallTx`](/reference/transactions.md#CallTx) transactions that have been 
     4  accepted into the blockchain. The state is stored through the following generic interface:
     5  
     6  ```go
     7  type StorageSetter interface {
     8  	// Store a 32-byte value at key for the account at address, setting to Zero256 removes the key
     9  	SetStorage(address crypto.Address, key binary.Word256, value []byte) error
    10  }
    11  ```
    12  
    13  The raw data stored according depends on a schema determined by the execution engine and contract in question, in the case of the EVM this is described by the 
    14  ABI generated when a contract is compiled.
    15  
    16  Burrow stores its state in an authenticated key-value data structure - a merkle tree. It has the following features:
    17  
    18  - We store a separate complete version of all core state at each height - this gives us the ability to rewind instantly to any height.
    19  - We are able to provide inclusion proofs for any element of state (not currently exposed by our RPC interfaces).
    20  - State has a single unified state root hash that almost surely guarantees identity of state by comparison between state root hashes
    21  
    22  ## Structure
    23  
    24  Burrow stores its core state the `Forest` which is implemented as a merkle tree of commit objects for individual sub-trees thereby providing the state root hash. 
    25  Each tree in our forest is lazily loaded by prefix (i.e. initialized if it does not exist), returning a read/write tree. This contains immutable snapshots of its 
    26  history for reading, as well as a mutable tree for accumulating state. All trees ultimately wrap [IAVL](https://github.com/tendermint/iavl), an (immutable) AVL+ library, 
    27  persisted in [goleveldb](https://github.com/syndtr/goleveldb) - a key/value database.
    28  
    29  ### Index and derivable data
    30  
    31  Alongside our core data we have additional data that can be derived from (such as indices) or is peripheral to (such as contract metadata). 
    32  Since we can generally detect if these are incorrect or regenerate them we store them in a plain non-authenticated key-value storage called the `Plain`
    33  
    34  ### Relationship with Tendermint state
    35  
    36  Tendermint also uses merkle trees to store raw block and transaction data. Tendermint blocks close in our state root hash as the `AppHash` thereby creating a 
    37  merkle graph that conveys the authenticated data structure property to our application state.