rjl493456442 27c4ca9df0 eth: resolve finalized from disk if it's not recently announced (#33150) ... This PR contains two changes: Firstly, the finalized header will be resolved from local chain if it's not recently announced via the `engine_newPayload`. What's more importantly is, in the downloader, originally there are two code paths to push forward the pivot point block, one in the beacon header fetcher (`fetchHeaders`), and another one is in the snap content processer (`processSnapSyncContent`). Usually if there are new blocks and local pivot block becomes stale, it will firstly be detected by the `fetchHeaders`. `processSnapSyncContent` is fully driven by the beacon headers and will only detect the stale pivot block after synchronizing the corresponding chain segment. I think the detection here is redundant and useless.		2026-03-11 11:23:00 +08:00
..
api.go
beacondevsync.go
beaconsync.go	eth/downloader: fix stale beacon header deletion (#33481)	2025-12-29 16:13:30 +08:00
downloader.go	eth: resolve finalized from disk if it's not recently announced (#33150)	2026-03-11 11:23:00 +08:00
downloader_test.go	eth/protocols/eth: drop protocol version eth/68 (#33511)	2026-02-28 21:43:40 +01:00
events.go
fetchers.go
fetchers_concurrent.go
fetchers_concurrent_bodies.go	eth/protocols/eth, eth/protocols/snap: delayed p2p message decoding (#33835)	2026-02-15 21:21:16 +08:00
fetchers_concurrent_receipts.go
metrics.go
peer.go
queue.go	eth/protocols/eth, eth/protocols/snap: delayed p2p message decoding (#33835)	2026-02-15 21:21:16 +08:00
queue_test.go	eth/protocols/eth, eth/protocols/snap: delayed p2p message decoding (#33835)	2026-02-15 21:21:16 +08:00
resultstore.go
skeleton.go	eth/downloader: fix stale beacon header deletion (#33481)	2025-12-29 16:13:30 +08:00
skeleton_test.go	eth/protocols/eth: drop protocol version eth/68 (#33511)	2026-02-28 21:43:40 +01:00
statesync.go
syncmode.go
testchain_test.go