Commit graph

7 commits

Author SHA1 Message Date
rjl493456442
7122ecc3eb
eth/protocols/snap: remove uncovered states before resuming (#35159)
Some checks are pending
/ Linux Build (push) Waiting to run
/ Linux Build (arm) (push) Waiting to run
/ Keeper Build (push) Waiting to run
/ Windows Build (push) Waiting to run
/ Docker Image (push) Waiting to run
This PR fixes an issue where flat states are continuously persisted
during downloadState, while the sync journal is only persisted at the
end of Sync.

As a result, an unclean shutdown can leave the on-disk flat state ahead
of the journal markers. Some persisted entries may be stale (storage
slots that should have been deleted), and these dangling entries are not
detected or fixed by subsequent state downloads.

To address this, this PR introduces a cleanup step before state
downloading begins. It removes all state entries that are not covered by
the persisted journal markers.
2026-06-17 13:44:12 +08:00
rjl493456442
0e810e4984
eth, triedb, internal: add snap/2 sync progress (#35178)
This PR does two things:

- Expose snap/2 specific sync progress fields
- Seed the sync progress after `loadSyncStatus `
2026-06-17 13:43:51 +08:00
rjl493456442
1be5da2330
eth/protocols/snap: redo the snap sync if the bal is unavailable (#35181)
Some checks are pending
/ Linux Build (push) Waiting to run
/ Linux Build (arm) (push) Waiting to run
/ Keeper Build (push) Waiting to run
/ Windows Build (push) Waiting to run
/ Docker Image (push) Waiting to run
This PR introduces a new condition that if the local node falls behind
too much and the required BAL for catching up is very likely to be
unavailable, the entire snap sync will be restarting from scratch.

As the defined BAL retention window is weak-subjective-period which is
calculated dynamically. A more conservative threshold is used (90K
blocks) for robustness.

Apart from that, the BAL catchup will be divided into several spans and
apply one by one. It's essential to prevent the potential out-of-memory
panic of placing the entire BAL set in memory.
2026-06-17 09:57:08 +08:00
rjl493456442
6ed112aee0
eth/protocols/snap: fix catchup stall (#35158)
This PR fixes an issue that when peers legitimately lack a requested
BAL, empty (0x80) is delivered and this BAL entry will be refetched 
over and over again. 

A `refused` tracker is added and catchUp will fail if this BAL is
unavailable against the entire peerset.
2026-06-16 09:11:15 +08:00
Jonny Rhea
e2164cc78c
eth/downloader, eth/protocols/snap: freeze pivot once state is downloaded (#35155)
Some checks are pending
/ Linux Build (push) Waiting to run
/ Linux Build (arm) (push) Waiting to run
/ Keeper Build (push) Waiting to run
/ Windows Build (push) Waiting to run
/ Docker Image (push) Waiting to run
2026-06-15 16:09:41 +08:00
Jonny Rhea
17aab1ac9a
core, eth/protocols/snap, eth/downloader: snap/2 sync logic (#34626)
Some checks are pending
/ Linux Build (push) Waiting to run
/ Linux Build (arm) (push) Waiting to run
/ Keeper Build (push) Waiting to run
/ Windows Build (push) Waiting to run
/ Docker Image (push) Waiting to run
Adds snap/2 (EIP-8189), a block-access-list (BAL) based state sync, and
wires it to run side by side with snap/1. It's opt-in (for now) behind a
new --snap.v2 flag and chosen at startup.

https://eips.ethereum.org/EIPS/eip-8189

---------

Co-authored-by: Toni Wahrstätter <info@toniwahrstaetter.com>
Co-authored-by: Gary Rong <garyrong0905@gmail.com>
2026-06-11 14:45:07 +08:00
rjl493456442
77a2816468
eth/protocols/snap: introduce snapv2 skeleton (#35098)
This PR is a prerequisite for landing snap v2, the BAL-healing snap sync
algorithm.

It duplicates much of the snap v1 skeleton, which is expected to be
deprecated once v2 is enabled. The code duplication is acceptable as a 
short-term tradeoff, simplifying development and reducing integration 
complexity.
2026-06-02 14:48:26 +08:00