Skip to content

eth, miner: remove duplicated code#23256

Merged
karalabe merged 10 commits intoethereum:masterfrom
rjl493456442:abstract-miner
Jan 24, 2022
Merged

eth, miner: remove duplicated code#23256
karalabe merged 10 commits intoethereum:masterfrom
rjl493456442:abstract-miner

Conversation

@rjl493456442
Copy link
Copy Markdown
Member

@rjl493456442 rjl493456442 commented Jul 23, 2021

This PR removes the duplicated code in the catalyst package, reuse the miner package code instead.

Highlight the critical changes in this PR:

  • Offer one more API in the miner package called GetSealingBlock which will assemble and return the sealing block based on the given parameters.
  • Sealing environment is abstracted out, all the functions will receive the sealing environment for further operations
  • Uncle blocks management is changed for sake of simplification

@rjl493456442 rjl493456442 requested a review from gballet as a code owner July 23, 2021 06:25
@rjl493456442 rjl493456442 changed the title [WIP] eth, miner: remove duplicated code eth, miner: remove duplicated code Jul 26, 2021
@holiman
Copy link
Copy Markdown
Contributor

holiman commented Jul 27, 2021

This touches some core logic in the miner, I think we should have a review call to discuss this one.

Copy link
Copy Markdown
Member

@gballet gballet left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with Martin, it seems correct (and I like that you broke some functions down into some with an explicit title) even though we should discuss this during a call. I have a couple nitpicks until then.

Comment thread miner/worker_test.go Outdated
Comment thread miner/worker_test.go Outdated
Comment thread miner/worker.go Outdated
@rjl493456442
Copy link
Copy Markdown
Member Author

Yes @holiman and @gballet . I won't want to merge this PR now, definitely after the fork. And we can schedule a review call for it, especially for some tiny details in the miner refactoring.

Comment thread miner/worker.go Outdated
@badbitses
Copy link
Copy Markdown

I want to help

@badbitses
Copy link
Copy Markdown

Who left and why

Comment thread miner/worker.go Outdated
@jwasinger
Copy link
Copy Markdown
Contributor

Who left and why

Hey @badbitses . This PR is mostly complete. If you are interested in contributing, I would advise to take a look through the open issues and see what piques your interest.

Comment thread miner/worker.go Outdated
Comment thread miner/worker.go Outdated
Comment on lines 1149 to 1171
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems that this method is only used for PoS blocks? Which makes sense, because it has noUncle and noExtra set to true, so it's not really abstract.
I find it a bit confusing to have this seemingly abstract block sealer mode for catalyst, whereas the ethash and clique engines use some other path to produce a block. Is the intent to later on align these three engines?

Copy link
Copy Markdown
Member Author

@rjl493456442 rjl493456442 Jan 5, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The main reason for catalyst has different path to produce block is it's rpc-event-based engine. While for ethash and clique they are chain-event-based engine, which just create blocks non-stop.

It's still ugly for them to have different paths, but we can find some proper solution to merge these paths I guess.

Comment thread miner/worker.go Outdated
Comment thread eth/catalyst/api.go Outdated
Copy link
Copy Markdown
Contributor

@holiman holiman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks ok, but I'm a bit confused by all the changes to the catalyst part.
Also, what I"m a bit scared about is coinbase - it would be bad if these changes make setting the coinbase not "stick".
So if a miner is mining, they need to be able to set the coinbase via,

  • startup param,
  • rpc,
    • before starting mining,
    • and during mining
    • and when mining is requested, but during sync, so mining is disabled

Do we have tests for these? Have you experimented anything with these scenarios?

Comment thread miner/worker.go Outdated
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this really so in practice? We're going to hold onto the latest 128 states either way for snap sync and reorgs. This clause would only trigger if someone requests mining on something super old. Is that a viable requirement?

Copy link
Copy Markdown
Member Author

@rjl493456442 rjl493456442 Jan 5, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure, but I guess so. Consensus layer might reorg to some old branch and require us to build a block there. If the chain is not finalized for very long time, so the deep reorg is expected?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think so too, since there is not really a guarantee that we won't reorg very deeply with non-finalization

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, but we'd get a sethead first from the beacon chain before mining on top, wouldn't we? Which would do the reorg and reconstruction of the needed state? Maybe I'm wrong tho'

Copy link
Copy Markdown
Member

@MariusVanDerWijden MariusVanDerWijden left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some small nits, looks pretty solid to me

Comment thread eth/catalyst/api.go Outdated
Comment thread eth/catalyst/api.go Outdated
Comment thread eth/catalyst/api.go Outdated
Comment thread miner/stress/beacon/main.go
Comment thread miner/worker.go Outdated
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think so too, since there is not really a guarantee that we won't reorg very deeply with non-finalization

Comment thread miner/worker.go Outdated
Comment thread miner/worker.go Outdated
@MariusVanDerWijden
Copy link
Copy Markdown
Member

I've asked Pari to run this code on a validator on kintsugi. Would be great to also put it on a clique miner maybe? cc @holiman

@holiman
Copy link
Copy Markdown
Contributor

holiman commented Jan 17, 2022

Sure

@holiman
Copy link
Copy Markdown
Contributor

holiman commented Jan 17, 2022

On rinkeby-aws-eu-west-3-001: Geth/v1.10.16-unstable-cc7f6269-20220112/linux-amd64/go1.17.6

@MariusVanDerWijden
Copy link
Copy Markdown
Member

eth/catalyst/api.go:80: File is not goimports-ed (goimports)
preparedBlocks *payloadQueue // preparedBlocks caches payloads (*ExecutableDataV1) by payload ID (PayloadID)

Copy link
Copy Markdown
Member

@karalabe karalabe left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

@karalabe karalabe added this to the 1.10.16 milestone Jan 24, 2022
@karalabe karalabe merged commit 78636ee into ethereum:master Jan 24, 2022
sidhujag pushed a commit to syscoin/go-ethereum that referenced this pull request Jan 28, 2022
JacekGlen pushed a commit to JacekGlen/go-ethereum that referenced this pull request May 26, 2022
* eth, miner: remove duplicated code

* eth/catalyst: remove unneeded code

* miner: keep update pending state even the Merge is happened

* eth, miner: rebase

* miner: fix tests

* eth, miner: address comments from marius

* miner: use empty zero randomness for pending blocks after the merge

* eth/catalyst: gofmt

* miner: add warning log for state recovery

* miner: ignore uncles for post-merge blocks

Co-authored-by: Péter Szilágyi <peterke@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

9 participants