Skip to content

miner: avoid unnecessary work after payload resolution#33943

Merged
rjl493456442 merged 2 commits into
ethereum:masterfrom
jrhea:miner-unnecessary-work
Mar 4, 2026
Merged

miner: avoid unnecessary work after payload resolution#33943
rjl493456442 merged 2 commits into
ethereum:masterfrom
jrhea:miner-unnecessary-work

Conversation

@jrhea
Copy link
Copy Markdown
Contributor

@jrhea jrhea commented Mar 3, 2026

Issue

In buildPayload(), the background goroutine uses a select to wait on the recommit timer, the stop channel, and the end timer. When both timer.C and payload.stop are ready simultaneously, Go's select picks a case non-deterministically. This means the loop can enter the timer.C case and perform an unnecessary generateWork call even after the payload has been resolved.

Fix

Add a non-blocking check of payload.stop at the top of the timer.C case to exit immediately when the payload has already been delivered.

@rjl493456442
Copy link
Copy Markdown
Member

rjl493456442 commented Mar 4, 2026

When both timer.C and payload.stop are ready simultaneously

It's a very rare situation which is not expected to happen frequently.

Besides, there is no severe consequence of the work generation, the work will be silently ignored if the payload.stop has been closed right?

I feel it's the unnecessary complexity.

@jrhea
Copy link
Copy Markdown
Contributor Author

jrhea commented Mar 4, 2026

When both timer.C and payload.stop are ready simultaneously

It's a very rare situation which is not expected to happen frequently.

Besides, there is no severe consequence of the work generation, the work will be silently ignored if the payload.stop has been closed right?

I feel it's the unnecessary complexity.

It happened very frequently in the traces I was monitoring; otherwise I wouldn't have bothered. I kept seeing traces where the block was delivered on iteration N and the trace would continue for iteration N+1. If you think about it, it makes sense that it happens often. Let's say the miner is working on a block and spends the entire 2 seconds trying to stuff as many transactions as it can into the block. meanwhile the stop signal arrives somewhere in those 2 seconds....then it is a coin flip whether or not the miner goes into that extra iteration after the block has been delivered.

@jrhea
Copy link
Copy Markdown
Contributor Author

jrhea commented Mar 4, 2026

Besides, there is no severe consequence of the work generation, the work will be silently ignored if the payload.stop has been closed right?

agreed that it will be silently ignored. this isn't a hill I am going to die on though

rjl493456442
rjl493456442 previously approved these changes Mar 4, 2026
@rjl493456442 rjl493456442 added this to the 1.17.2 milestone Mar 4, 2026
@rjl493456442 rjl493456442 merged commit 4f75049 into ethereum:master Mar 4, 2026
7 of 8 checks passed
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.

2 participants