Keccak256 mining

[atoulme]

Signed-off-by: Antoine Toulme [email protected]

PR description

This PR introduces more flexibility around PoW operations, by renaming some classes that use the Ethash term to PoW. It also calls out explicitly the PoW algorithm used, if any. It introduces the ability to select the PoW algorithm in the hard fork schedule.

This PR also introduces a keccak256 hasher that can be used to validate solutions or run CPU mining.
The changes can be used with a new dev network named ecip1049_dev.

The changes are associated with ECIP1049

Changelog

• I thought about the changelog and included a changelog update if required.

[shemnon]

The renaming are fine. I have some design concerns with how PoWAlgorithm is wired down through the protocol specs.

[atoulme]

All good points and I can follow this pathway. I wanted to create a “dev-keccak256” network that would use keccak mining with a fixed difficulty. How would you go about that here? Set all fork blocks to 0 and add a new fork name for keccak? Would there still be a keccak config block next to the ethash one?

[shemnon]

That is exactly what was done in the EIP-1559 test networks. There can be a keccak config block configuring the parameters of keccak. However I would expect this would only cover dev related options like fixeddifficulty as most of the parameters would be implicit in the keccak fork. I would recommend ecip1049 for the fork name.

[atoulme]

I think the goquorum compatibility boolean confused me, apologies. This should be a bit nicer now. I am about to push this, with a TODO for the actual keccak hasher algorithm.

[shemnon]

Where's the mixhash? To replace the POW you replace the step where MixHash is sent to Dagger/hashimoto and instead send mixhash to keccack. That's the Ethereum way.

Doing it this way has deep implications to block header validation for the rest of the Besu client. Preserving the meaning and utility of MixHash (which isn't part of Ethash, just what feeds the Ethash) is necessary for the stability of Besu.

[antsankov]

Hi folks, author of ECIP-1049 here just weighing in. The proposal has compatibility as its top priority, so there should be no changes to the block construction itself. Also the way the work is verified currently, using keccak256 of mixhash and nonce. The way I envision the system in the proposal is:

• Block is valid if keccak256(keccak256(rlp(unsealed header)), nonce) <= 2^256 / difficulty
• mixhash = keccak256(rlp(unsealed header)) which is stored in the block. Currently this process is ethash(rlp(unsealed header))
• So to validate a block we check keccak256(mixhash, nonce) <= 2^256 / difficulty

Let me know if this mental model is valid, since this is what I am basing my analysis of the code on.

=================================

Left 2 comments in the code as well.

[shemnon]

So the Implementation section of ECIP-1049 doesn't have that level of clarity (this one correct? ethereumclassic/ECIPs#13). It seems to be an extension of the rational section. That is perhaps my biggest beef in that the spec doesn't in fact specify anything with clarity. It has some hints but is missing actual details, such as what is H sub 'n bar'?

There needs to be a "specification" section in ECIP-1049, as noted by the ecip template. These three bullet points should be in that section. There also needs to be clear specification as to the proposed difficulty bump. And some justification of the 100x difficulty bump, it appears to be pulled from thin air.

Also, there are so many versions of ECIP floating around I think the PR description and ultimate merge commit needs to reference the "official" location of the ECIP it's implmementing.

[antsankov]

I sincerely apologize about any confusion with the proposal, the roll out plan is this ECIP is officially here: ethereumclassic/ECIPs#394. This is the re-draft that will be finalized into ECIP-1049, once we have a block number we feel comfortable to activate on. I'm adding to it based on your points, and welcome the feedback.

Once this PR to Besu is merged, we have a number of hardware engineers, and other full node teams (Mantis, and core-geth) that'll base their implementation of nodes and hardware/mining pools software off of what Besu supports, and then we'll activate mainnet once it's supported by the nodes.

• The 100x difficulty bump is based on discussions with experienced chip designer and former ATI Technologies VP Henry Quan report here, and was selected on estimates of how much higher we predict initial Keccak-256 hash rate will be compared to Ethash, when first launched.
• H sub n refers to nonce.

[peterwillcn]

why use Keccak256?

[shemnon]

I'm going to be a bit of a hard nose about this, but until the referenced ECIP (https://ecips.ethereumclassic.org/ECIPs/ecip-1049) specifies what has been discussed in this PR I'm not going to give it a serious review. If we are implementing what should be specified in an ECIP then the ECIP should actually specify something.

I'm not looking for yellow paper equations but at least "this field now has this data (xxxx)" "this field now has this data (yyy)" "to calculate that value do XYZ." "If I J and K then the block is valid, otherwise it is invalid."

[antsankov]

ACK @shemnon - Proposal will be sealed shortly, and only thing left after sealing is to determine what block number it's activated on. See changes:

• Added in an implementation standard here which outlines exactly how to implement ECIP-1049 and the formal of definition of the keccak256 proof of work algorithm.
• Added in a verified miner test vector in the Appendix of the ECIP, which shows a single solved block with all of the inputs and outputs of the PoW specified.

[shemnon]

Looks mostly good. Just a few more smaller comments.

[shemnon]

Not for this PR, but I think it's time we renamed a bunch of our Mainnet* classes to better names. Default, PoW, etc etc.