From e2deabe5f3b6e159d044135d1b90b394c28e2cc3 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?P=C3=A9ter=20Szil=C3=A1gyi?= Date: Wed, 2 Feb 2022 18:09:43 +0200 Subject: [PATCH] eth/downloader: remove Ethereum 1&2 notions in favor of merge --- eth/downloader/beaconsync.go | 4 ++-- eth/downloader/skeleton.go | 20 ++++++++++---------- 2 files changed, 12 insertions(+), 12 deletions(-) diff --git a/eth/downloader/beaconsync.go b/eth/downloader/beaconsync.go index eeb2730261ce4..5afd7292b9ecd 100644 --- a/eth/downloader/beaconsync.go +++ b/eth/downloader/beaconsync.go @@ -128,7 +128,7 @@ func (b *beaconBackfiller) setMode(mode SyncMode) { b.resume() } -// BeaconSync is the Ethereum 2 version of the chain synchronization, where the +// BeaconSync is the post-merge version of the chain synchronization, where the // chain is not downloaded from genesis onward, rather from trusted head announces // backwards. // @@ -148,7 +148,7 @@ func (d *Downloader) BeaconExtend(mode SyncMode, head *types.Header) error { return d.beaconSync(mode, head, false) } -// beaconSync is the Ethereum 2 version of the chain synchronization, where the +// beaconSync is the post-merge version of the chain synchronization, where the // chain is not downloaded from genesis onward, rather from trusted head announces // backwards. // diff --git a/eth/downloader/skeleton.go b/eth/downloader/skeleton.go index ff6f5860810d1..8965ca01cf3e4 100644 --- a/eth/downloader/skeleton.go +++ b/eth/downloader/skeleton.go @@ -152,26 +152,26 @@ type backfiller interface { resume() } -// skeleton represents a header chain synchronized after the Ethereum 2 merge, -// where blocks aren't validated any more via PoW in a forward fashion, rather -// are dictated and extended at the head via the beacon chain and backfilled on -// the original Ethereum 1 block sync protocol. +// skeleton represents a header chain synchronized after the merge where blocks +// aren't validated any more via PoW in a forward fashion, rather are dictated +// and extended at the head via the beacon chain and backfilled on the original +// Ethereum block sync protocol. // // Since the skeleton is grown backwards from head to genesis, it is handled as // a separate entity, not mixed in with the logical sequential transition of the // blocks. Once the skeleton is connected to an existing, validated chain, the // headers will be moved into the main downloader for filling and execution. // -// Opposed to the Ethereum 1 block synchronization which is trustless (and uses a -// master peer to minimize the attack surface), Ethereum 2 block synchronization -// starts from a trusted head. As such, there is no need for a master peer any -// more and headers can be requested fully concurrently (though some batches might -// be discarded if they don't link up correctly). +// Opposed to the original Ethereum block synchronization which is trustless (and +// uses a master peer to minimize the attack surface), post-merge block sync starts +// from a trusted head. As such, there is no need for a master peer any more and +// headers can be requested fully concurrently (though some batches might be +// discarded if they don't link up correctly). // // Although a skeleton is part of a sync cycle, it is not recreated, rather stays // alive throughout the lifetime of the downloader. This allows it to be extended // concurrently with the sync cycle, since extensions arrive from an API surface, -// not from within (vs. Ethereum 1 sync). +// not from within (vs. legacy Ethereum sync). // // Since the skeleton tracks the entire header chain until it is cosumed by the // forward block filling, it needs 0.5KB/block storage. At current mainnet sizes