Eip1234 #17675
Eip1234 #17675
Conversation
There was a problem hiding this comment.
@holiman I would like to suggest generalizing block rewards and diff calculation like parity did openethereum/parity-ethereum#9480 instead of copy-paste or forcing one rule for side chains. In this way it would be possible to tune block time and fork numbers on dev networks
consensus/ethash/consensus.go
Outdated
|
|
||
| // calcDifficultyConstantinople is the difficulty adjustment algorithm for Constantinople. | ||
| // It returns the difficulty that a new block should have when created at time given the | ||
| // parent block's time and difficulty. The calculation uses the Byzantium rules, but with bomb offset 5M. |
There was a problem hiding this comment.
Nitpick, please move bomb offset 5M to a new line.
I'd also perhaps use 5M and 3M instead and do the decrement internally. It's not really that expensive imho but the code would look a lot cleaner opposed to guessing why the -1 here opposed to the EIPs.
Also please add a link to the two iceage postponing EIPs here for reference. Some future maintainer will thank us.
consensus/ethash/consensus.go
Outdated
| // Note, the calculations below looks at the parent number, which is 1 below | ||
| // the block number. Thus we remove one from the delay given | ||
| bombDelayFromParent := new(big.Int) | ||
| bombDelayFromParent = bombDelay.Sub(bombDelay, big1) |
There was a problem hiding this comment.
bombDelayFromParent := new(big.Int).Sub(bombDelay, big1)
|
@eosclassicteam While in general that's not a bad idea, within Geth we kind of always focused on the Ethereum use case and tried to avoid making everything too abstract/flexible. There have been multiple consensus issues in Parity caused by EIPs getting accidentally activated due to their flexible architecture, as well as configuring a Parity node is a nightmare that can lately only be done via custom tooling. Our code mostly assumes that Ethereum hard forks come in progression one after the other and this keeps everything a lot simpler. I of course understand that this puts a bit more burden on teams creating Ethereum forks, but at the end of the day why should the go-ethereum maintainers pay the price of running derivatives based on our code? :) |
|
For dev/private networks we already have the Clique engine, so PoW difficulty/rewards are a lot less relevant. |
ghost
mentioned this pull request
Replaces #17657 (but maintains the commit history from @eosclassicteam ). I wasn't sure you wanted me to push directly into your branch -- this PR contains a bit less copy-paste.