# 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`