-
Notifications
You must be signed in to change notification settings - Fork 20.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cmd, core, eth, miner, params, tests: finalize the DAO fork #2814
Conversation
Updated: Fri Jul 15 06:52:33 UTC 2016 |
985d8b4
to
2b400c8
Compare
Is there a spec for the hard fork independent of the PRs that you could link to? Is there no plan to prevent transaction replay across forks? |
this line of reasoning was sound |
There are 35 files changed, including modifications to the configuration/genesis, p2p networking, and EVM protocol. Given the inherent complexity - I wonder if the default should be the option with less technical risk. |
The application could randomize this boolean on first-start when there is no explicit flag to support or oppose the fork. This would help shield developers from accusations of bias and protect Geth neutrality. Was this possibility considered? Edit. Alternatively sidestep the issue of default behavior entirely and make it mandatory for the user to choose. Same as mist ethereum/mist#970. |
The explicit flag for or against makes far more sense to me |
eb9824a
to
03527b1
Compare
5dbca5a
to
ebb50a3
Compare
ebb50a3
to
993b412
Compare
karalabe:dao-hard-finalcombo |
Note: This PR contains all the pieces of the DAO hard-fork, each detailed below. The remaining PRs tagged
dao-fork-part
may be disregarded, they were meant to aid review.Note 2: After this PR is merged, we need to prep a merge into the
release/1.4
branch and inherentlymaster
, which needs a tiny amount of work due to the databse reogs already ondevelop
.cmd, core, eth, params: implement flags to control dao fork blocks #2788
This PR implements setting the
--support-dao-fork
and--oppose-dao-fork
flags. As of now they only modify a single database entry specifying whether the current default behavior should change.--support-dao-fork
will set it to either mainnet/testnet number--support-dao-fork
will leave it at its present value--oppose-dao-fork
will remove itCaveat: setting the dao number from a custom genesis file, removing it via
--oppose-dao-fork
and reenabling it via--support-dao-fork
will result in the mainnet/testnet number being set, the original private number being lost. Don't use this willy nilly on private networks; rather usegeth init genesis.json
for those scenarios.This PR further drops support to the deprecated
--genesis
flag. This is important because the--support-dao-fork
and--oppose-dao-fork
flags need to know the previous state/number in the database to ensure it's not accidentally overwritten! We do not know this with the--genesis
flag as the user might supply something we can only interpret much later in the code. Note, for main and test network we know in advance what their genesis file would contain, so that's not an issue.core: gracefully handle missing homestead block config #2790
Our nodes didn't handle an interesting corner case until now: having a chain configuration (in the genesis.json), but not having a
homesteadBlock
set in it (i.e.{..., "config": {}}
). Since our configs until now only featured the homestead block number, either it (block number) was present or the entire config section was missing (resulting the the defaults being used).With the DAO fork being worked on and requiring an additional config section, it becomes entirely possible to have the DAO fork number set, but the homestead number not set. This PR ensures that it the homestead block number is missing, it's assumed not forked.
Note, there's almost no end user use case to set the DAO hard fork in a private network (so skipping the entire config section or only setting the homestead block is still entirely workable), but it is needed to properly test it n automated ways so better to fix it up properly now.
cmd/geth, miner, params: special extradata for DAO fork start #2791
This PR modifies the miner so that if the DAO hard-fork is enabled, the fork block and
10
consecutive blocks all have0x64616f2d686172642d666f726b
(hex fordao-hard-fork
) as their extra-data.This is important to allow header-only mode clients (fast sync algo, light client) to verify whether a header is indeed on the correct chain and not get duped into syncing a live alternative fork. It also helps full nodes to split the network between two forks and avoid cross network noise.
Consecutive blocks are needed to prevent any malicious miner from minting a non-forked block with the fork extra-data. Unless almost all non-forking miners are malicious, there will be a non-forking block in the first
10
that does not have the fork extra-data set, separating that chain from the forked chain.This PR does not contain unit tests as out miner module wasn't written with unit tests in mind and I'd like to avoid a too invasive rewrite in such a critical time. However, this feature is covered by
hive
end to end tests with full mining.cmd, core, miner: add extradata validation to consensus rules #2794
This PR makes the necessary consensus modifications to header validation rules so that block header
extraData
fields are enforced to be either0x64616f2d686172642d666f726b
(hex fordao-hard-fork
) for pro-forkers or everything but that for non-forkers. These rules are upheld for10
blocks straight to protect both forkers and non-forkers against malicious actors of the opposite side.Since non-forkers also need to know the actual DAO hard-fork block number to enforce themselves onto the opposite side of the network (i.e. a non-forker fast syncing needs to be aware of the headers it needs to check), this PR makes a further modification to the previous chain configurations so not only a single
ChainConfig.DAOForkNumber
is maintained (previously implicitly signalling pro-fork), but rather an explicitChainConfig.DAOForkSupport
boolean flag is added too. This way both camps can maintain the block numbers whilst also allowing both decisions.core, eth: enforce network split post DAO hard-fork #2795
This PR is meant to enforce the network split after passing the DAO hard-fork block number. It is done by requesting the DAO fork-block's header immediately after an
eth
handshake completes. If the DAO challenge isn't completed within15 seconds
, the connection is dropped.To complete the DAO challenge, the remote peer must reply with the requested header (every peer will do so, it's how the
eth
protocol works). A few things can happen:core, params, tests: add DAO hard-fork balance moves #2800
This PR implements the last component of the DAO hard-fork, namely defines the list of DAO addresses the balances of which should be moved and executes the actual state transformation when the DAO hard-fork block arrives.
The PR also adds the DAO consensus tests from the upstream https://github.com/ethereum/tests repo, although as far as I know those tests are still under development, and hence are subject to change.
Note, the fork parameters (block number and refund account) are just placeholders, whereas the DAO drain list may or may not change.
cmd, core, eth, miner, params, tests: finalize the DAO fork #2814
The last commit for the DAO hard-fork. This finalizes the DAO child list, the refund contract address, the testnet and mainnet transition blocks as well as sets the default behavior of Geth to be pro-fork as per internal discussions.