You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently the application only remembers the last committed state, however, if we stored the state hash at each past block height, or the last N heights, we could go back in state (it's not emptied from the IPLD store) and run multiple consistent queries on the same height.
Think about how to implement this in the view of a new block being produced every second:
Should we remember the last N heights, and purge the ones before?
Should we insert all and hope RocksDB will just store them?
Is there some data structure we could use to only store changes, but still have fast lookups? Should we do bisection to find which range a block falls into?
Tendermint will also store all all hashes as part of the headers, but it also has an option of how many blocks to retain. It would be reasonable to say: we support queries up to the last hour, or last 24 hours.
The text was updated successfully, but these errors were encountered:
A followup for #347
Currently the application only remembers the last committed state, however, if we stored the state hash at each past block height, or the last N heights, we could go back in state (it's not emptied from the IPLD store) and run multiple consistent queries on the same height.
Think about how to implement this in the view of a new block being produced every second:
Tendermint will also store all all hashes as part of the headers, but it also has an option of how many blocks to retain. It would be reasonable to say: we support queries up to the last hour, or last 24 hours.
The text was updated successfully, but these errors were encountered: