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

Archival state support for state_db and native_db #1170

Draft
wants to merge 15 commits into
base: nightly
Choose a base branch
from

Conversation

dubbelosix
Copy link
Contributor

Description

Basic support at the code level to read archival state for

  1. state_db (jmt)
  2. native_db (accessory)

Changes

  1. Added archival_version to ProverStorage
  2. Support for NativeDB and StateDB for versioning
  3. Test cases for querying archival state using ProverStorage and WorkingSet for accessory and jmt

Pending

Expose archival state via RPC macros

Copy link

codecov bot commented Nov 21, 2023

Codecov Report

Merging #1170 (ab46a03) into nightly (d624e21) will increase coverage by 0.1%.
Report is 3 commits behind head on nightly.
The diff coverage is 96.5%.

❗ Current head ab46a03 differs from pull request most recent head 9df60cd. Consider uploading reports for the commit 9df60cd to get more accurate results

Additional details and impacted files
Files Coverage Δ
full-node/db/sov-db/src/schema/tables.rs 88.3% <100.0%> (+3.3%) ⬆️
...system/module-implementations/sov-evm/src/hooks.rs 96.1% <100.0%> (ø)
module-system/sov-modules-core/src/storage/mod.rs 92.6% <ø> (ø)
module-system/sov-state/src/prover_storage.rs 93.6% <93.7%> (-0.2%) ⬇️
full-node/db/sov-db/src/native_db.rs 97.7% <95.0%> (-2.3%) ⬇️

... and 3 files with indirect coverage changes

@bkolad bkolad closed this Nov 21, 2023
@bkolad bkolad reopened this Nov 21, 2023
version: Option<Version>,
) -> anyhow::Result<Option<Vec<u8>>> {
let version_to_use = version.unwrap_or_else(|| self.get_next_version());
let mut iter = self.db.iter::<ModuleAccessoryState>()?;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With this change, we use iterator on every access to the database.

Do we want to measure performance impact on regular execution?

Maybe it is too late to discuss it, but it looks like archival state taxes on regular execution.

I am raising this point, because together with ForkManagement our storage can become bottleneck.

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

Successfully merging this pull request may close these issues.

None yet

4 participants