…ambdaclass#403) When `--checkpoint-sync-url` is provided, the node currently always downloads a fresh finalized state from the peer, even if a recent state is already on disk. Skip the network round-trip when the persisted state is fresh enough to resume from. This PR introduces a state data freshness threshold - `MAX_RESUMABLE_DB_STATE_AGE = 450` slots (~30 min at 4s/slot) - picked conservatively considering the per-block backfill cost. I couldn't identify in the specs a formal weak-subjectivity period or a method of calculating it, so this is a judgement call; happy to take any suggestions on the value or a better approach for it. ## What Changed - `crates/storage/src/store.rs` — added `Store::from_db_state(backend, expected_genesis_time)`, a no-write constructor that wraps an already-initialized backend. Returns `None` if the backend is empty or its persisted `genesis_time` doesn't match. Added the `MAX_RESUMABLE_DB_STATE_AGE = 450` constant (~30 min at 4s/slot). - `crates/storage/src/lib.rs` — re-exported `MAX_RESUMABLE_DB_STATE_AGE`. - `bin/ethlambda/src/main.rs` — in the checkpoint-sync branch of `fetch_initial_state`, try `Store::from_db_state` first. If the persisted finalized slot is within `MAX_RESUMABLE_DB_STATE_AGE` of wall-clock, return the resumed store and skip checkpoint sync. Otherwise warn and fall through to the existing sync path. ## Correctness / Behavior Guarantees - New short-circuit fires only when: checkpoint URL provided AND DB populated AND persisted `genesis_time` matches AND `current_slot - latest_finalized.slot <= MAX_RESUMABLE_DB_STATE_AGE`. Everything else remains unchanged. - 30 min threshold is conservative for the current `BlocksByRoot`-only backfill cost; can be increased once `BlocksByRange` long-range sync (lambdaclass#351) is added. ## Tests Added / Run Three unit tests in `crates/storage/src/store.rs` covering the `from_db_state` contract: - `from_db_state_returns_none_on_empty_backend` - `from_db_state_returns_some_on_matching_genesis_time` - `from_db_state_returns_none_on_genesis_time_mismatch` ## Related Issues / PRs - Closes lambdaclass#121 - Related to lambdaclass#351 (BlocksByRange long-range sync — once landed, `MAX_RESUMABLE_DB_STATE_AGE` can probably be raised toward `STATES_TO_KEEP`) ## ✅ Verification Checklist - [x] Ran `make fmt` — clean - [x] Ran `make lint` (clippy with `-D warnings`) — clean - [x] Ran `cargo test --workspace --release` — all passing - [x] Local devnet test --------- Co-authored-by: Pablo Deymonnaz <pdeymon@fi.uba.ar>

Avoid checkpoint-sync when we have recent state in the DB #121

Description

Metadata

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

Issue actions