Lotus (and other Filecoin chain clients) awards the corresponding reward minus penalty from f02 to the miner by calling the reward actor within an implicit message at the end of block execution.
IPC inherits the first step from ref-fvm, but does not go full circle with the second step. Consequently, miner tips are sitting idle at the reward actor (f02). Fixing this in active networks will require an upgrade.
What this means for this PR
This PR is no longer correct in conveying a tx priority of zero via the Eth RPC API.
Blockscout is not correct assuming that the reported non-zero premium goes to the block producer.
Solving the root problem
I can imagine two possible solutions:
We introduce a feature flag in ref-fvm to prevent managing the premiums via the reward actor. IPC and non-Filecoin users of ref-fvm enable this feature flag. The miner tip and penalty are reported back in the ApplyRet, so Fendermint can handle this however it wants.
We keep things as they are, and claim the reward in Fendermint by calling the reward actor.
Considerations:
Both solutions require us to know the address of the block producer so we can credit the tip, which we don't AFAIK.
Choosing (1) allows us to drop the reward actor, which anyway is Filecoin specific (requires being informed of the "wincount") and was added without full understanding of why it was needed (according to @aakoshh).
ref-fvm
credits miner tips/premiums to the reward actor (f02) here:https://github.com/filecoin-project/ref-fvm/blob/c39d880d086aa2e771c7190163436e02715d80f3/fvm/src/executor/default.rs#L509
Lotus (and other Filecoin chain clients) awards the corresponding reward minus penalty from f02 to the miner by calling the reward actor within an implicit message at the end of block execution.
https://github.com/filecoin-project/lotus/blob/ebf1e00846fe5806a33fc948c83be6dfa46d6fc1/chain/consensus/compute_state.go#L247-L256
IPC inherits the first step from ref-fvm, but does not go full circle with the second step. Consequently, miner tips are sitting idle at the reward actor (f02). Fixing this in active networks will require an upgrade.
What this means for this PR
Solving the root problem
I can imagine two possible solutions:
Considerations:
Originally posted by @raulk in https://github.com/consensus-shipyard/ipc/pull/882#pullrequestreview-2043684517