docs: ADR-065 Store V2 #15028
docs: ADR-065 Store V2 #15028
Conversation
alexanderbez
added
T:Docs
| to change the backing commitment store in the future should evidence arise to | ||
| warrant a better alternative. However there is promising work being done to IAVL | ||
| that should result in significant performance improvement <sup>[1,2]</sup>. | ||
|
|
There was a problem hiding this comment.
one thing to note with this refactor is we should think about removing the fast node system in iavl because it was a poor mans SS & SC separation. With this redesign we can remove it
| However, in order for the SC layer to remain lightweight and not duplicate a | ||
| majority of the data held in the SS layer, we need to have an aggressive pruning | ||
| strategy. A pruning strategy could be enforced programmatically or through |
There was a problem hiding this comment.
can you define what duplicate means here? sc isnt meant to store the values in ss. this would be duplicating data unnecessarily
| a pruning strategy might be too limiting. So we propose to have a configurable | ||
| pruning strategy, height retention and interval, with a default height retention | ||
| of 2,592,000 (1s block time over a month). |
There was a problem hiding this comment.
if this is left to the node operator then they can get proofs is split between both ss and sc. With adr 40 they were talking about reconstructing the tree on the fly but since insertion order matters with iavl we cant make that assumption.
| while being a bit more flexible with the underlying implementations and overall | ||
| less intrusive. Specifically, we propose to: | ||
|
|
||
| * Separate the concerns of state commitment (**SC**), needed for consensus, and |
There was a problem hiding this comment.
I've been using a different separation of concerns to guide my design, which is based on the requirement of different roles of clients, it goes like this:
- consensus state machine (validator node)
- it requires read/write on the latest version of the state
- generating the root hash for consensus
- export/restore snapshots for state-sync
- historical queries without merkle proofs (grpc query server)
- it requires read-only access to historical states without generating merkle proofs
- historical queries with merkle proofs (
/abci_query?proof=true)
The SS (or the versiondb) is to serve the requirement of 2, I'm experimenting with a new IAVL implementation which focuses on the requirement of 1 first, the requirement of 3 is considered as lower priority, it can be at least supported by the traditional design.
It's slightly different from simply separating SC and SS.
There was a problem hiding this comment.
One tricky part is, a separated SC will need to duplicate the keys no matter what, which is a significant duplication already, for example in our evm module, the keys are larger than values (32bytes for value and 20+32 bytes for keys).
|
One thing maybe good to include in the storage refactoring is, currently SDK stores some secondary indexes into the IAVL tree, which is only for convenience of query, I think we can have a special API for these cases, to only store them in SS, but not in SC? |
agree, we dont need proofs on reverse indexes for queries. i wonder if there is an api where we can say this state should be included in a commitment and this state should not. It would help in reducing the duplicate data between ss and sc |
|
Will there be a separate ADR for cache store refactoring? |
there will be a new cache store in store v2 from my understanding, it might make sense to include this here. imo it shouldnt be a refactor but a rewrite. same with other kv stores. I think this adr should mention the interfaces that will be adopted or a proposal on how they will look. |
There was a problem hiding this comment.
Left a few more comments, i think there is still more information missing in terms of trying to define some interfaces. How will the gas kv store look, how will the cache kv store look? Still some items that are fundamental to storage v2 rewrite that are missing here.
tac0turtle
assigned aaronc, kocubinski, facundomedica, tac0turtle, julienrbrt, samricotta, atheeshp and testinginprod
Description
This ADR is currently a collaborative living document to outline the proposed changes the design and implementation of the storage primitives in the Cosmos SDK.
RENDERED
Author Checklist
All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.
I have...
!to the type prefix if API or client breaking changeCHANGELOG.mdReviewers Checklist
All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.
I have...
!in the type prefix if API or client breaking change