eth/downloader: remove Ethereum 1&2 notions in favor of merge

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.
 //

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