---
# System prepended metadata

title: Notes on storage structure

---

# Notes on storage structure
- In current production, everything in the subspace has diffs and is merklized
- Observations for possible change
    - Some accts have a VP specified in storage with "?", while others dont
        - assuming Established do and Implicit dont
    - Every token address has inflation data, while native (NAM) inflation data is also held in Parameters and PosParams
        - prob some redundancy here for NAM that can be simplified
        - no token other than NAM should even have this data
- Relevant issues
    - #2265
    - #2343

## Subspace
- PoS address (tnam1qgq..qc8j2fp)
    - address_raw_hash
    - bond
    - unbond
    - consensus_keys
    - last_block_proposer
    - liveness
    - params
    - total_consensus_stake
    - total_deltas
    - validator
        - consensus_key, eth_keys
        - commission_rate, max_commission_rate_change
        - rewards_products
        - (incoming | outgoing)_redelegations
        - total_redelegated_(un)bonded
        - last_known_rewards_product
            - may not be used atm and can prob delete
        - state
        - deltas
        - last_slash_epoch
        - total_(un)bonded
        - email, description, website, discord
    - validator_addresses
    - validator_rewards_accumulator
    - validator_rewards_commissions
    - validator_set_positions
    - validator_sets
        - consensus
        - below_capacity
    - delegator_redelegated_(un)bonds
    - slashes
        - validator/<_address_> (processed)
    - enqueued_slashes
- MASP (tnam1pcq..qzmefah)
    - commitment_tree
    - convert_anchor
    - head-tx
    - note_commitment_anchor
    - nullifiers
    - tx-{id}
    - pin-{thing}
- Multitoken (tnam1pyq..qej6juv)
    - <_token_>/balance/
- Governance (tnam1q5q..qrw33g6)
    - counter
    - max_code_size
    - max_content
    - max_period
    - min_fund
    - min_grace_epoch
    - min_period
    - proposal (most data will be here)
- IBC (tnam1qcq..qvtr7x4)
    - acks
    - channelEnds
        - counter
        - ports
        - 
    - clients
        - counter
        - <_id_>
            - clientState
            - connections
            - consensusStates
            - update_height
            - update_timestamp
    - connections
        - counter
        - <_id_>
    - commitments
    - nextSequenceAck
    - nextSequenceRecv
    - nextSequenceSend
    - receipts
- Account (address of acct)
    - VP (marked "?")
    - protocol_public_keys
    - public_keys
    - threshold
- Token (address of token)
    - denomination
    - p & d gain
    - last inflation
    - locked ratio and last locked ratio
    - max reward rate
    - NOTE: some of these are prob redundant for NAM  at least (mb max reward rate for everything)
    - NOTE: tokens that aren't NAM shouldn't have inflation data
- Protocol parameters (tnam1qsq..qxdl54l)
    - eth_start_height
    - eth_activation_status
    - eth_min_confirmations
    - eth_native_erc20
    - eth_bridge_contract_addr
    - epoch_duration
    - epochs_per_year
    - fee_unshielding
    - implicit_vp
    - max_block_gas
    - max_expected_time_per_block
    - max_proposal_bytes
    - max_signatures_per_transaction
    - max_tx_bytes
    - minimum_gas_price
    - pos_inflation_amount
    - staked_ratio
    - tx_whitelist
    - vp_whitelist
- Ethbridge (tnam1quq..qfgdmms)
    - validator_set_updates / bp_root_and_nonce / eth_msgs
        - body
        - seen
        - seen_by
        - voting_power
        - voting_started_epoch
    - erc20 cap key
        - uin256 value representing a token cap
    - erc20 token whitelist key
        - boolean value indicating whether an erc20 token is whitelisted or not
- Bridge pool (tnam1...)
    - **\$bridge_pool_transfer_hash**
        - the hashes of transfers in the bridge pool
    - signed bridge pool root
    - bridge pool nonce
- wasm
    - code
    - hash
    - len
    - name
    
## Misc addrs

- tnam1qqh0hc6z4hmq5keh5q8u4s3hakdkuj65ccfv0jly?
    - Is this an implicit acct?
        - (tiago) yes. you can use [this site](https://slowli.github.io/bech32-buffer/) to decode bech32m encoded addrs; change the hrp to `tnam`, paste the addr and hit decode. the first two hex digits of the decoded addr are the discriminant byte, valued at 0 for implicit accts
    - No "?" (VP)
- tnam1qquwj3wj5lvmhwl6y05p3hsuqaf37nkteuy8cym8?
    - Is this an implicit acct?
        - (tiago) same deal, also implicit
    - No "?" (VP)

## Issues from a random convo Tiago and Jacob had

- Lots of node local data is persisted at every block, but
its history is not relevant
    - The map from token alias to address in conversion state
    - the tx_queue
    - ethereum_height
    - eth_events_queue
- Low level store implementation apis *ideally* should be kept crate private. Problem: How to implement RocksDB in /apps then?
- Write log behavior should be hidden behind a storage api mimicking the abci calls.

- Jacob and Brent notes
    - `BlockStateWrite` should be split into two structs like `BlockStateAppend` and `BlockStateOverwrite`
        - the conversion state, tx_queue, eth_heigh, eth_events_queue should be in `BlockStateOverwrite`
        - Then `DB::add_block_to_batch` logic would be changed to do different things on the fields within `BlockStateAppend` and `BlockStateOverwrite`
        - Need to figure out what `put_cf` does and how to do smth different for the `BlockStateOverwrite`
            - want to do same current thing for `BlockStateAppend`
        - ACTUALLY, in `DB::add_block_to_batch`, we declare a `prefix_key` that encodes the block height. Everything that is written without `prefix_key` should be `BlockStateOverwrite`, while everything with it should be `BlockStateAppend`
