0

Traditionally, Ethereum pools used the deprecated Ethash, which is quite inconvenient to use with modern golang, specifically around the usage of Go modules. Examples of this are Sammy007's Open Ethereum Pool and Etherchain.org's example pool.

That being said, these are both from four or five years ago. It is now recommended to use the consensus/ethash module within the main Geth repo, as specified here.

So as a pool operator looking to operate a high performance pool, how can you use the consensus/ethash module without wasting a large amount of I/O? The main inconvenience I see is that the VerifyHeader function replaces the old "Verify" function, but its dependent upon the ChainHeaderReader function.

Putting aside having to either wrap the corresponding RPC calls in the object or caching the block data (to avoid I/O), the real issue I see is that you'll only ever be able to verify a block based off of the network difficulty (i.e. there is no good way to check a block based off of the pool's difficulty, not the network difficulty).

It definitely is possible to then create some hacky ChainHeaderReader implementation that allows you to inject a fake difficulty into the Parent that is returned from the GetHeader function here, but it just seems like this is jumping through hoops to use the modern version of Ethash (as a pool operator). Is there anything I'm missing about how this should be done?

1
  • It seems like what I'm really looking for is the verifySeal method, but it isn't exported
    – tug
    Jun 30 at 16:30
0

I found this alternative implementation etclabscore/go-etchash. I'm unsure about performance, but it seems to fit the bill (with no go modules issues and without cgo), and since the only difference between Ethash and Etchash is the epoch length there shouldn't be any problems.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.