core, eth/protocols/snap, eth/downloader: snap/2 sync logic

[jrhea]

Summary

Replace the snap/1 sync logic with snap/2's.

What changed

• Healing removed. The syncer no longer requests trie nodes from peers. Snap/1 serving is unchanged.

• Sync loop restructured. Sync() runs a download -> catch-up -> trie rebuild loop.

  • Download. Still fetches account ranges, storage slots, and bytecodes from peers, writing flat state to disk. When the downloader restarts the syncer with a new pivot root, the syncer detects the change and runs BAL catch-up before resuming download.

  • BAL catch-up. When the pivot moves, catchUp() fetches BALs from peers, verifies them against block headers, and applies the state diffs.

  • Trie rebuild. After download completes, triedb.GenerateTrie() rebuilds all tries from the flat state.

• Deep reorg detection. The downloader checks if the old pivot was reorged before restarting the syncer. If so, sync progress is wiped and the syncer starts fresh.

• Skip snapshot generation. The downloaded flat state is the snapshot. SnapSyncComplete calls RebuildFromSyncedState() instead of Rebuild().

Notes

• Storage roots left stale during sync. When BALs are applied during catch-up, account storageRoot fields become inconsistent. Rather than recomputing storage tries on every pivot move, they are left stale and all storage tries are rebuilt at the end from flat state.

• On deep reorg we restart from scratch. A reorg > 64 blocks is catastrophic and rare enough that we wipe sync progress and start over. Causes include:

  • finality reversion case (33%+ validators slashed)
  • long period without finality

• Current pivot is HEAD-64. Shorter slot times or faster finality could impact this.

Follow-up PRs

• Metrics and progress logging. Add counters and timers for access list fetch/apply, trie rebuild, and pivot movements.

• BALs are currently stored in the KV store. Long-term, they probably need to move to the freezer for cheaper retention over the weak subjectivity period.