New message pool selection logic #2838
Conversation
don't swallow them, the failed gas guess is too high.
…ative failed gas estimation
vyzo
force-pushed
the
feat/message-pool-selection
branch
from
4c3726a
to
06a1368
Compare
|
@vyzo thank you for excellent comments 🙏 I could totally follow along |
vyzo
force-pushed
the
feat/message-pool-selection
branch
from
7d0c411
to
6f660f7
Compare
the default non-stable sort may reorder chains with the same gasPerf, which might change the order of messages per nonce; facepalm.
Merge chains when gasPerf is non-descreasing (instead of increasing) to create maximal chains. This also obviates the need for stable sort, as the chains are guaranteed to be in decreasing order for the same actor.
| @@ -146,6 +146,9 @@ type FullNode interface { | |||
| // MpoolPending returns pending mempool messages. | |||
| MpoolPending(context.Context, types.TipSetKey) ([]*types.SignedMessage, error) | |||
|
|
|||
| // MpoolSelect returns a list of pending messages for inclusion in the next block | |||
| MpoolSelect(context.Context, types.TipSetKey) ([]*types.SignedMessage, error) | |||
There was a problem hiding this comment.
Can we add a list of 'priority addresses' to this API? And have it prioritize messages from those addresses, even if they arent necessarily the most profitable ones?
There was a problem hiding this comment.
can be done as a followup, but i think its a pretty important thing to have
There was a problem hiding this comment.
yes, we can do that, but I was thinking of doing it in a subsequent pr after discussing it.
There was a problem hiding this comment.
agreed on importance, let's discuss on the colo -- I want to think about it a bit.
There was a problem hiding this comment.
I think we want a separate api call because we need to know priority addresses for pruning too -- we shouldn't prune messages from our miner etc.
As extensively discussed in the colo(s).
TBD: