Fork Architecture & Conventions¶
go-ethereum-classic re-introduces Proof-of-Work to a modern go-ethereum that has removed it. This page explains how the fork is structured so it can track upstream with minimal friction.
Sibling-file convention¶
PoW/ETC code lives in dedicated sibling files next to the upstream files they extend, rather than inline in upstream files wherever that can be avoided:
*_pow.go— revived Proof-of-Work machinery (miner, downloader, protocol, handler, fetcher, …).*_etc.go— ETC chain specifics (config, bootnodes, protocol params, EVM tweaks).*_mess.go— MESS artificial finality.
Upstream files stay byte-identical wherever possible, so a rebase onto a new go-ethereum tag only conflicts where upstream itself changed a line the fork also touched.
Sibling vs in-place — when each applies¶
The sibling pattern works cleanly when upstream removed a symbol and the fork
re-adds it — pure addition, no collision. Examples: the revived
worker_pow.go, ChainSideEvent, the uncle logic. These coexist with the modern code.
It does not apply when upstream keeps a symbol but the fork must change its behavior — e.g. the ethtest client reverting eth/69 back to eth/68. Go won't let you redefine a method, so those edits are made in place and kept minimal. Build tags would duplicate the whole file and let the variant drift silently, which is worse for rebases, not better.
Composition over upstream¶
The branch etc/v1.17.3-full-node is based on the v1.17.3 release tag, with
the fork's commits on top — roughly one per subsystem, each meant to compile on
its own (see the commit list on the home page).
How the wiki maps it¶
- PoW Code Mapping — symbol-by-symbol diff of revived code against its pre-purge origin.
- File diffs / changelog — file-level changes grouped by subsystem.
- Version Comparison — how the ETC patches evolved between releases.
Files adapted in place from v1.17.3 are mapped with source: upstream; files
revived from before upstream's PoW purge use source: purgeN (a pre-purge commit).