Summary

Currently COSMOS-SDK store ABCI Information in state.db ( on disk) at every commit. Purpose of storing ABCI information is to compare when new commit comes and validate new commit is at least one height above existing ABCI Response information.

While to compare, we just need ABCI Information for one previous block, cosmos-sdk continues to store all blocks and never deletes them. As a result state.db is bloated, turning state.db in 100s of GB (95% of data is ABCI Information) and also increasing latency.

Store ABCI Response information in optimized manner and delete everything above 100 or 1000 blocks. Currently state.db ABCI Response information pruning is handled with same configuration for blockstore.db and application.db. High volume chains (Osmosis as an example) produce 10s of transactions per block, and so state.db bloat exponentially.

We need mechanism where older ABCI information is deleted from state.db every time new block is committed. Basically we store ABCI Information in separate DB and delete ABCI Information of block H1 when H1+100 is committed.

Code:

1. Tendermint saves ABCI Response Information to State.db - Tendermint saves ABCI Response before commit -

   tendermint/internal/state/execution.go

   Line 233 in 0cceadf

   if err := blockExec.store.SaveABCIResponses(block.Height, abciResponses); err != nil {

It is not deleted until pruning configuration deletes it. Pruning configuration honors bonding period, so state.db is not deleted until for bonding period (2-4 weeks). At that point LevelDB is bloated, with multiple levels, and disk space is never reclaimed. (Info on LevelDB Deletion: https://twitter.com/valnodes/status/1435465250803945472)

2. Merkle Tree Verification never goes beyond 100 aunts:

   tendermint/crypto/merkle/proof.go

   Line 16 in 3d448e1

   MaxAunts = 100

Problem Definition

I do not see any, but would like to discuss use-case where one want to get merkle proof at height 1.

Proposal

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned