Allow alternative methods of proposer payments in validation api (simple version).

[dvush]

📝 Summary

This will allow validation API to accept blocks where:

• proposer payment is plain transfer to the fee recipient
• proposer payment is internal payment to the fee recipient made through the smart contract
• fee recipient is set to coinbase and accepts payment directly

Its optional and should be enabled by setting --builder.validation_force_last_tx_payment=false --builder.validation_use_balance_diff (default: false) (note: the flag was renamed in #106)

This is similar to #78 but much simpler and does not discard withdrawals from the profit calculation.

The reason that this approach it better is that:

• its simpler
• builders and fee recipients can adapt to these rules
• its already deployed in the wild by other relays so if there would be some downsides to this approach it should be already noticed

The way we calculate profit is:

• check balance difference of the fee recipient after the block is applied
• if claimed profit is bigger or equal to balance difference we accept it
• otherwise check if last tx is payment to the fee recipient with value of exact profit (previous behavior)

Note that:

• withdrawals from the fee recipient decrease profit of the bid
• deposits to the fee recipient address can be claimed as a profit

📚 References

---

• I have seen and agree to CONTRIBUTING.md

[dvush]

Here are some clarifications on why we don't worry about withdrawals and deposits to the fee recipient directly (as opposed to payments made to coinbase) influencing the value of the bid.

Firstly, why might this be a problem? The fee recipient can send transactions out and can also receive ETH from transactions as part of some on-chain activity unrelated to its role as the fee recipient in some blocks. According to this rule for value calculation, these transactions will influence bid value: transactions from the fee recipient, when included, will reduce bid value, and transactions to the fee recipient will increase it.

Trying to account for this leads to complicated solutions for validation and block building. By giving up on these issues, we make the implementation safer and simpler.

Below, we consider the worst-case scenario of what can happen with these changes.

The worst-case scenario is that some builders who are unaware of this rule will be at a disadvantage compared to builders who know about it. The proposer will potentially miss out on profits compared to the value of deposits/withdrawals of the transaction by that fee recipient. Also, there's an edge case of a "forwarder fee recipient" (a contract that sends all received ETH elsewhere) which might not exist in practice.

There are multiple factors that need to align for this to be a problem:

• "Some builders who don't know about this rule": If there are at least a few builders who are aware of this, they will compete with each other to pay the highest amount to the fee recipient, even if they outcompete the builders who are unaware.
• "Will potentially miss profits compared to the value of deposits/withdrawal of the transaction": The value of the deposit/withdrawal should be significant for the loss to be substantial.
• "Of the transaction by that fee recipient": There should be a transaction by the fee recipient in the mempool when this fee recipient proposes a block. For small stakers, the probability of this happening is minuscule. The probability to win a block is 1/(number of proposers), and there must be a transaction in this specific block. This only matters for staking pools, but they already use specialized addresses to collect fees .

Other points:

• Proposer pools can make frequent withdrawals from the fee recipient, and these withdrawals reduce block profit. Withdrawal transactions decrease the block profit, so builders will not include them for blocks with the same fee recipient. Unless this pool control all the blocks, withdrawal transactions will be included by others proposers who have a different fee recipient.
• "Forwarder fee recipient": It's unclear if this case exists in practice. But if there is a builder who pays to the fee recipient in the last transaction, they will cover this case because we support a fallback to the old behavior.