ECIP 1017: Different behaviour for go-ethereum and Parity

[ntallar]

I'm running the latest versions that include the ECIP 1017:

• Parity version: 1.7.0
• Geth classic version: 4.0.0
• Operating system: Linux
• And installed parity: via installer

Description

When having a Geth classic and a Parity client connected, with a miner being connect to the Parity node, the blocks eventually start not being accepted by the Geth classic client, due to:

I0914 16:45:02.620198 eth/fetcher/fetcher.go:689] Peer 33a367fa384cbffd: block #85 [04b9d5cb…] import failed: invalid merkle root: header=98458fbbb578b578afca077b4d6e5867e7490b09644af140f958279e50915c98 computed=7f942e6aed49da03f07aeaf8b605f337dc0a6a8cddb8ea4c24329f01db590c5c

This issue seems to only arise when the era corresponding to the block number is equal or higher than 21, and could mainly be an issue when creating private networks.

How to reproduce

Configured both Geth classic and Parity clients with the default Ethereum Classic configuration, only changing:

"genesis.difficulty": "0x40"
"ecip1017EraRounds": 4

This eventually causes block 85 (in era 21 of ECIP 1017), mined by Parity to not be accepted by the Geth Classic client.

Possible explanation

This seems to be caused by a difference in how the block reward is calculated after the ECIP1017 was in place as Geth classic uses exponentiation to obtain the block reward while a loop is used in Parity clients.

[rphmeier]

cc @sjmackenzie as the original author of ECIP1017 implementation.

[sjmackenzie]

@splix @whilei can you take a look at this please.

[whilei]

Projected geth block winner rewards for era(s) in question for comparison:

	state_processor_test.go:127: 72057594037927936 // era 20
	state_processor_test.go:127: 57646075230342348 // 21
	state_processor_test.go:127: 46116860184273879 // 22
	state_processor_test.go:127: 36893488147419103 // 23
	state_processor_test.go:127: 29514790517935282 // 24

@ntallar Can you explain your reasoning more why a loop vs exponentiation would yield different values?

[rphmeier]

would be accumulated rounding error, I suppose. it should just use the same approach as the go code to take reward * (4**era) / (5**era)

[ntallar]

That's right @rphmeier , I think it's a rounding error as reward * (4**era) / (5**era) is different than calc_reward = reward; for _ in 0..eras { calc_reward = calc_reward / U256::from(5) * U256::from(4); } if reward=5000000000000000000 (5 ether) and era=21. If I didn't make any mistake the first way has 46116860184273879 as a result and the second way 46116860184273876.
Either way, I found this while testing, this being a rounding error is just my hyphotesis.

[splix]

We discussed Rounding Error as a potential issue for ECIP-1017, but decided as it isn't going to happen in next few decades we can postpone the solution. That will probably include a formal definition how you should make calculation/rounding, or even a value table for some eras.

I guess it's a question to @snaproII which number to choose as correct 46116860184273879 or 46116860184273876, so we can choose right formula

[5chdn]

Did you decide yet which formula you are going to use?

[whilei]

see recently merged ECIP1039 👍

[whilei]

also noting #7067