-
Notifications
You must be signed in to change notification settings - Fork 20k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
eth, miner: remove duplicated code #23256
Conversation
This touches some core logic in the miner, I think we should have a review call to discuss this one. |
There was a problem hiding this 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.
282f3c8
to
78212c8
Compare
I want to help |
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. |
78212c8
to
6239e0f
Compare
8e4e457
to
65ca904
Compare
65ca904
to
20936a1
Compare
miner/worker.go
Outdated
func (w *worker) getSealingBlock(parent common.Hash, timestamp uint64, coinbase common.Address) (*types.Block, error) { | ||
req := &getWorkReq{ | ||
params: &generateParams{ | ||
timestamp: timestamp, | ||
forceTime: true, | ||
parentHash: parent, | ||
coinbase: coinbase, | ||
noUncle: true, | ||
noExtra: true, | ||
}, | ||
result: make(chan *types.Block, 1), | ||
} |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
4124b97
to
7c56c0a
Compare
There was a problem hiding this 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?
e22dadd
to
8d636fd
Compare
// | ||
// The maximum acceptable reorg depth can be limited by the finalised block | ||
// somehow. TODO(rjl493456442) fix the hard-coded number here later. | ||
state, err = w.eth.StateAtBlock(parent, 1024, nil, false, false) |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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'
7574518
to
84e85be
Compare
There was a problem hiding this 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
// | ||
// The maximum acceptable reorg depth can be limited by the finalised block | ||
// somehow. TODO(rjl493456442) fix the hard-coded number here later. | ||
state, err = w.eth.StateAtBlock(parent, 1024, nil, false, false) |
There was a problem hiding this comment.
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
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 |
Sure |
On |
6e950e4
to
c9fd441
Compare
|
c9fd441
to
5287292
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
* 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 <[email protected]>
This PR removes the duplicated code in the catalyst package, reuse the miner package code instead.
Highlight the critical changes in this PR:
GetSealingBlock
which will assemble and return the sealing block based on the given parameters.