Summary

Storage in the cosmos-sdk is where we spend the most amount of time in execution. The original store package was written many years ago and left to ferment. As the needs of blockchains expanded and we gained better insight into how applications using the cosmos-sdk reads and writes we have learned how to better design the storage layer.

Problem Definition

Cosmos-sdk spends immense amounts of time at the storage layer and this is causing many bottlenecks.

Proposal

We need to refactor many parts of the storage layer in order to get somewhere where the users of the cosmos-sdk can get the highest performance for their applications.

Things we can do today:

• Refactor Cache kv store
• Refactor multistore
• Write benchmarks for many things in the store package
• Profile current store and bring performance improvements to users.
• Refactor key structure in IAVL to take advantage of data locality.

Things to do in the future:

• Refactor the design of storage to do something along the lines of ADR-40
• Use a different tree structure
• Use a different database

Previously there was work around a new storage layer, store/v2 and adr-40, this work and design is currently under review from the core sdk team.

Work Breakdown

Phase 1

• Write a specification of the store package and how it works with the current tree (iavl)
  • cachekv
  • multistore
• Spec: Produce a spec for store v2 #14667
• Refactor store package (API cleaning and improvement)
  • cachekv store docs and refactor to provide strong guarantees and more performance
    • It mixes so many jobs, and does a poor job at it, especially around iterator
    • Someone ground up rewriting it, and writing out what the guarantees we should want, will net save so much headache
    • (Make parallel iterators explicitly clear in how expectations are made of it)
  • Store: Write regression tests & more benchmarks/tests #13224

ref: #7101, #6687

Phase 2

• POC to prove iavl key format lends to higher performance
• Refactor IAVL key layout to operate within data locality
• Tests and benchmarks
• Migration for current state

Phase 3

• evaluate different data structures
• evaluate adr040 design and implementation on how to progress to separating SS and SC
• .... TBD