feat: mpool/wdpost: Maximize feecap config

[magik6k]

Related Issues

I imagine there is something open about messages getting stuck around upgrades, but can't find an issue.

Proposed Changes

We've seen messages get stuck in mpool when basefee is rising rapidly, caused by underestimating FeeCap.

This PR adds a new field to MessageSendSpec:

// MaximizeFeeCap makes message FeeCap be based entirely on MaxFee
MaximizeFeeCap bool

Because of the basefee mechanism there isn't munch downside to setting FeeCap as high as we're willing to pay for the message

Currently that field can be configured only by windowPoSt logic through SP node configuration:

  # type: bool
  # env var: LOTUS_FEES_MAXIMIZEWINDOWPOSTFEECAP
  MaximizeWindowPoStFeeCap = false

TODO:

• Decide if we want to default this to true?
  • At api level? Only for PoSt?
• Add configuration for other subsystems can be done later
• Test in a network

Additional Info

Checklist

Before you mark the PR ready for review, please make sure that:

• Commits have a clear commit message.
• PR title is in the form of of <PR type>: <area>: <change being made>
  • example: fix: mempool: Introduce a cache for valid signatures
  • PR type: fix, feat, build, chore, ci, docs, perf, refactor, revert, style, test
  • area, e.g. api, chain, state, market, mempool, multisig, networking, paych, proving, sealing, wallet, deps
• New features have usage guidelines and / or documentation updates in
  • Lotus Documentation
  • Discussion Tutorials
• Tests exist for new functionality or change in behavior
• CI is green

[Kubuxu]

LGTM

[rjan90]

Decide if we want to default this to true?

I would slightly lean to setting it to true by default. Reasoning being:

• Users already seem to think that they will always be able to publish their windowPoSt message as long as their MaxWindowPoStGasFeeis set high enough.
• The cost of fees paid for DeclareFaultsRecovered and non-optimistic SubmitWindowedPoStmessages is probably higher then if there is a short lived basefee spike.

[Reiers]

Message sent on mainnet, confirming that the message fee-cap is more than 10 times the current network base fee.
https://filfox.info/en/message/bafy2bzacebs77wmcwzdebplxr4ixqrmifw2o6gxnghsayvuawt2s5wdxdwzqc?t=4

Before:
https://filfox.info/en/message/bafy2bzacectvuk4s72hdknppwh3e5aa4smcfrbancfcdb6r5aclqtc3lpabjs?t=4

[arajasek]

LGTM, though @magik6k should 👀 the commit i pushed and revert it if it's wrong for some reason.

[beck-8]

Sorry, I am just posting a situation here, not saying this is a problem, I just want everyone to understand.
After many miners upgraded, I saw that they could not submit wdpost messages, all because of this parameter. They were small miners, so they kept the balance of the control wallet only 0.5-5FiL, so they had problems, and they were not clear about this part of the code change.
So I think it is possible to post this part of the changes clearly in the version changelog so that everyone can understand it?

[rjan90]

Hey @beck-8! Thanks for the call-out. I have added it to the upgrade section here in v1.26.2 now: