Miner Collator#23278
Conversation
jwasinger
force-pushed
the
miner_interface
branch
from
fd5906a to
7c8f842
Compare
|
My original commit is fairly old, I suppose you pulled in master on top later on. Next time, use rebase instead, to keep the commit history cleaner - making it easier to review, and avoid a mega-squash later on.
|
…ult block collator which has current miner block collation behavior. Co-authored-by: Martin Holst Swende <martin@swende.se> Co-authored-by: Jared Wasinger <j-wasinger@hotmail.com>
jwasinger
force-pushed
the
miner_interface
branch
from
7c8f842 to
c9fc365
Compare
|
I think I rebased off the wrong fork. Now it's fixed. Currently failing one of the clique tests though. |
|
|
||
| if len(localTxs) > 0 { | ||
| if err := w.submit(bs, types.NewTransactionsByPriceAndNonce(bs.Signer(), localTxs, bs.BaseFee()), interrupt); err != nil { | ||
| return err |
There was a problem hiding this comment.
Whoops. I think this should should not return in the case that the recommit timer elapses (at least that is the behvior in the current miner/worker.go)
|
|
||
| // Collator is something that can assemble a block. | ||
| type Collator interface { | ||
| CollateBlock(bs BlockState, pool Pool, interrupt *int32, isSealing bool) error |
There was a problem hiding this comment.
Both interrupt and isSealing are for the recommit feedback. Can we somehow nuke them out from the plugin interface? So that the plugin implementers only need to take care of the transaction selection and ordering.
Actually after The Merge, the recommit is totally meaningless. Since in the PoS, we can only generate a single block for attestation.
There was a problem hiding this comment.
Regarding isSealing, I think it can be removed. When not sealing, we can always use the standard strategy for constructing the pending block when the newTxs event fires. So then CollateBlock only would get called during sealing.
There was a problem hiding this comment.
Regarding the interrupt. I am thinking to abstract it inside BlockState so that the collator doesn't actually need to know/care about the details of it (i.e. having AddTransactions fail when the interrupt goes off).
|
We may also want an additional collator hook (maybe when newHead event fires). Reasoning being that Collators will want to be aware of chain reorgs to adjust whatever custom data they are storing/tracking accordingly. mev-geth doesn't return bundles to the pool of eligible bundles when blocks with already-included bundles are reorged away. So to at least provide an interface which enables a custom collator compatible with the behavior of mev-geth, just the |
|
This is superseded by #23383 |
3 participants
Introduces the concept of a Collator which implements a strategy for selecting and ordering transactions from the pool into a pending block.
Includes implementation of a default collator which implements the current miner block collation behavior: choose transactions ordered descending by price, preferencing local over remote transactions when sealing.