Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support historical view for MemoryStore #1995

Open
xgreenx opened this issue Jun 27, 2024 · 1 comment
Open

Support historical view for MemoryStore #1995

xgreenx opened this issue Jun 27, 2024 · 1 comment

Comments

@xgreenx
Copy link
Collaborator

xgreenx commented Jun 27, 2024

image
xgreenx added a commit that referenced this issue Jul 4, 2024
Closes #451

## Overview

Added support for the state rewind feature. The feature allows the
execution of the blocks in the past and the same execution results to be
received. Together with forkless upgrades, execution of any block from
the past is possible if historical data exist for the target block
height. The default size of historical/rewind window is 7 days.

Also added support for rollback command when state rewind feature is
enabled. The command allows the rollback of the state of the blockchain
several blocks behind until the end of the historical window.

## Implementation details

The change adds a new `HistoricalRocksDB` type that is the wrapper
around regular `RocksDB`. This type has inside another RocksDB instance
that is used to duplicate all tables plus has one more column to store
the reverse modifications at each block height. The reverse modification
is the opposite to the operation that was done during transition from
block height X to X + 1. The screenshot below should describe the idea:

<img width="723" alt="image"
src="https://github.com/FuelLabs/fuel-core/assets/18346821/c4becce0-1669-4938-8dd7-87d274efa224">

The key of duplicated tables is extended with block height, and the
value is the reverse operation to reach the state of entry at the
previous height. Having the history of reverse operations, we can
iterate back from the latest version of the entry to the previous one.

Using the main property of the RocksDB(sorting keys by default), lookup
operations are fast and we don't need to iterate all modifications. It
is just enough to find the nearest reverse operation to the target
height.

## Checklist
- [x] New behavior is reflected in tests

### Before requesting review
- [x] I have reviewed the code myself
- [x] I have created follow-up issues caused by this PR and linked them
here
  - #1997
  - #1995
  - #1993
@MitchTurner
Copy link
Member

We don't have an immediate need for this, but it might be worth implementing if someone has time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants