[Hot State] Add a separate StateMerkleDb for hot state #18385
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This was referenced Dec 23, 2025
wqfish
force-pushed
the
pr18385
branch
3 times, most recently
from
e43e00d to
bf1a4dd
Compare
wqfish
changed the title
wqfish
force-pushed
the
pr18385
branch
2 times, most recently
from
e92b3e4 to
6c89feb
Compare
wqfish
requested review from
0xmaayan,
JoshLind,
banool,
grao1991,
gregnazario and
lightmark
as code owners
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
This was referenced Dec 26, 2025
wqfish
added
the
CICD:run-e2e-tests
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This part of the config is exposed via the `get_dir_paths` API.
wqfish
force-pushed
the
pr18385
branch
2 times, most recently
from
375c1a9 to
19548d3
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
In order to compute the hot state root hash for each block (including the speculative ones), we have to be able to return Merkle proof for any given key and version. The most straightforward way to do this is to add another instance of `StateMerkleDb` in `StateStore`. For now, we always delete and reset the DB on restart. This will give us more flexibility to make changes.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Contributor
✅ Forge suite
|
Contributor
✅ Forge suite
|
Contributor
✅ Forge suite
|
wqfish
added a commit
that referenced
this pull request
Jan 8, 2026
This commit implements the logic to compute root hashes for hot state. It's an initial version with a number of TODO items, but it's a reasonable start. Most of the logic is gated behind a flag so we are not enabling this in mainnet yet, until we run things in testnet for some time and gain more confidence. How this roughly works: - `State::update` computes the changes to hot state. They are saved in `ExecutionOutput`. - The above changes are passed to `StateSummary::update` and used to compute in-memory `SparseMerkleTree`. - The resulting Merkle trees are committed to persisted database (`hot_state_merkle_db` introduced in #18385) so the proofs can be used in turn for future `StateSummary::update`.
wqfish
added a commit
that referenced
this pull request
Jan 8, 2026
This commit implements the logic to compute root hashes for hot state. It's an initial version with a number of TODO items, but it's a reasonable start. Most of the logic is gated behind a flag so we are not enabling this in mainnet yet, until we run things in testnet for some time and gain more confidence. How this roughly works: - `State::update` computes the changes to hot state. They are saved in `ExecutionOutput`. - The above changes are passed to `StateSummary::update` and used to compute in-memory `SparseMerkleTree`. - The resulting Merkle trees are committed to persisted database (`hot_state_merkle_db` introduced in #18385) so the proofs can be used in turn for future `StateSummary::update`.
wqfish
added a commit
that referenced
this pull request
Jan 8, 2026
This commit implements the logic to compute root hashes for hot state. It's an initial version with a number of TODO items, but it's a reasonable start. Most of the logic is gated behind a flag so we are not enabling this in mainnet yet, until we run things in testnet for some time and gain more confidence. How this roughly works: - `State::update` computes the changes to hot state. They are saved in `ExecutionOutput`. - The above changes are passed to `StateSummary::update` and used to compute in-memory `SparseMerkleTree`. - The resulting Merkle trees are committed to persisted database (`hot_state_merkle_db` introduced in #18385) so the proofs can be used in turn for future `StateSummary::update`.
wqfish
added a commit
that referenced
this pull request
Jan 8, 2026
This commit implements the logic to compute root hashes for hot state. It's an initial version with a number of TODO items, but it's a reasonable start. Most of the logic is gated behind a flag so we are not enabling this in mainnet yet, until we run things in testnet for some time and gain more confidence. How this roughly works: - `State::update` computes the changes to hot state. They are saved in `ExecutionOutput`. - The above changes are passed to `StateSummary::update` and used to compute in-memory `SparseMerkleTree`. - The resulting Merkle trees are committed to persisted database (`hot_state_merkle_db` introduced in #18385) so the proofs can be used in turn for future `StateSummary::update`.
wqfish
added a commit
that referenced
this pull request
Jan 8, 2026
This commit implements the logic to compute root hashes for hot state. It's an initial version with a number of TODO items, but it's a reasonable start. Most of the logic is gated behind a flag so we are not enabling this in mainnet yet, until we run things in testnet for some time and gain more confidence. How this roughly works: - `State::update` computes the changes to hot state. They are saved in `ExecutionOutput`. - The above changes are passed to `StateSummary::update` and used to compute in-memory `SparseMerkleTree`. - The resulting Merkle trees are committed to persisted database (`hot_state_merkle_db` introduced in #18385) so the proofs can be used in turn for future `StateSummary::update`.
wqfish
added a commit
that referenced
this pull request
Jan 8, 2026
This commit implements the logic to compute root hashes for hot state. It's an initial version with a number of TODO items, but it's a reasonable start. Most of the logic is gated behind a flag so we are not enabling this in mainnet yet, until we run things in testnet for some time and gain more confidence. How this roughly works: - `State::update` computes the changes to hot state. They are saved in `ExecutionOutput`. - The above changes are passed to `StateSummary::update` and used to compute in-memory `SparseMerkleTree`. - The resulting Merkle trees are committed to persisted database (`hot_state_merkle_db` introduced in #18385) so the proofs can be used in turn for future `StateSummary::update`.
wqfish
added a commit
that referenced
this pull request
Jan 8, 2026
This commit implements the logic to compute root hashes for hot state. It's an initial version with a number of TODO items, but it's a reasonable start. Most of the logic is gated behind a flag so we are not enabling this in mainnet yet, until we run things in testnet for some time and gain more confidence. How this roughly works: - `State::update` computes the changes to hot state. They are saved in `ExecutionOutput`. - The above changes are passed to `StateSummary::update` and used to compute in-memory `SparseMerkleTree`. - The resulting Merkle trees are committed to persisted database (`hot_state_merkle_db` introduced in #18385) so the proofs can be used in turn for future `StateSummary::update`.
wqfish
added a commit
that referenced
this pull request
Jan 8, 2026
This commit implements the logic to compute root hashes for hot state. It's an initial version with a number of TODO items, but it's a reasonable start. Most of the logic is gated behind a flag so we are not enabling this in mainnet yet, until we run things in testnet for some time and gain more confidence. How this roughly works: - `State::update` computes the changes to hot state. They are saved in `ExecutionOutput`. - The above changes are passed to `StateSummary::update` and used to compute in-memory `SparseMerkleTree`. - The resulting Merkle trees are committed to persisted database (`hot_state_merkle_db` introduced in #18385) so the proofs can be used in turn for future `StateSummary::update`.
wqfish
added a commit
that referenced
this pull request
Jan 8, 2026
This commit implements the logic to compute root hashes for hot state. It's an initial version with a number of TODO items, but it's a reasonable start. Most of the logic is gated behind a flag so we are not enabling this in mainnet yet, until we run things in testnet for some time and gain more confidence. How this roughly works: - `State::update` computes the changes to hot state. They are saved in `ExecutionOutput`. - The above changes are passed to `StateSummary::update` and used to compute in-memory `SparseMerkleTree`. - The resulting Merkle trees are committed to persisted database (`hot_state_merkle_db` introduced in #18385) so the proofs can be used in turn for future `StateSummary::update`.
wqfish
added a commit
that referenced
this pull request
Jan 11, 2026
This commit implements the logic to compute root hashes for hot state. It's an initial version with a number of TODO items, but it's a reasonable start. Most of the logic is gated behind a flag so we are not enabling this in mainnet yet, until we run things in testnet for some time and gain more confidence. How this roughly works: - `State::update` computes the changes to hot state. They are saved in `ExecutionOutput`. - The above changes are passed to `StateSummary::update` and used to compute in-memory `SparseMerkleTree`. - The resulting Merkle trees are committed to persisted database (`hot_state_merkle_db` introduced in #18385) so the proofs can be used in turn for future `StateSummary::update`.
wqfish
added a commit
that referenced
this pull request
Jan 11, 2026
This commit implements the logic to compute root hashes for hot state. It's an initial version with a number of TODO items, but it's a reasonable start. Most of the logic is gated behind a flag so we are not enabling this in mainnet yet, until we run things in testnet for some time and gain more confidence. How this roughly works: - `State::update` computes the changes to hot state. They are saved in `ExecutionOutput`. - The above changes are passed to `StateSummary::update` and used to compute in-memory `SparseMerkleTree`. - The resulting Merkle trees are committed to persisted database (`hot_state_merkle_db` introduced in #18385) so the proofs can be used in turn for future `StateSummary::update`.
wqfish
added a commit
that referenced
this pull request
Jan 14, 2026
This commit implements the logic to compute root hashes for hot state. It's an initial version with a number of TODO items, but it's a reasonable start. Most of the logic is gated behind a flag so we are not enabling this in mainnet yet, until we run things in testnet for some time and gain more confidence. How this roughly works: - `State::update` computes the changes to hot state. They are saved in `ExecutionOutput`. - The above changes are passed to `StateSummary::update` and used to compute in-memory `SparseMerkleTree`. - The resulting Merkle trees are committed to persisted database (`hot_state_merkle_db` introduced in #18385) so the proofs can be used in turn for future `StateSummary::update`.
wqfish
added a commit
that referenced
this pull request
Jan 14, 2026
This commit implements the logic to compute root hashes for hot state. It's an initial version with a number of TODO items, but it's a reasonable start. Most of the logic is gated behind a flag so we are not enabling this in mainnet yet, until we run things in testnet for some time and gain more confidence. How this roughly works: - `State::update` computes the changes to hot state. They are saved in `ExecutionOutput`. - The above changes are passed to `StateSummary::update` and used to compute in-memory `SparseMerkleTree`. - The resulting Merkle trees are committed to persisted database (`hot_state_merkle_db` introduced in #18385) so the proofs can be used in turn for future `StateSummary::update`.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In order to compute the hot state root hash for each block (including the
speculative ones), we have to be able to return Merkle proof for any given key
and version. The most straightforward way to do this is to add another instance
of
StateMerkleDbinStateStore.For now, we always delete and reset the DB on restart. This will give us more
flexibility to make changes.
Note
Adds a hot-state storage path to enable Merkle proofs for speculative blocks.
hot_state_merkle_dbinAptosDB/StateStore; proof APIs now takeuse_hot_stateto read from hot or regular stateStateMerkleDbto support hot vs. regular instances (separate folder/CF names), deletion-on-restart, and checkpointing for bothHotStateConfig { max_items_per_shard, delete_on_restart }, path overrides forhot_state_merkle_db, andStorageDirPathsgettersAptosDB::open/open_internal/open_dbsgainreset_hot_stateand return the optional hot DB; all call sites updated (genesis, tests, benchmarks, tools)use_hot_stateparams); newHotStateErrorfor missing/misconfigured hot stateWritten by Cursor Bugbot for commit 97680f2. This will update automatically on new commits. Configure here.