Feature request: standard payment router contract

[thegostep]

A standard payment router contract can help achieve a few key objectives:

• Reliable logging of payment amounts
• Miner can define recipient address different from coinbase address
• Spread luck / incentivize finality

[thegostep]

v0.2 proposal

Miner payments in v0.2 must be done via a proxy payment contract as opposed to direct coinbase transfers. This will allow for reliable logging of payment amounts, as well as enable miners to route payments freely.

Update April 11th:

While processing payments through a smart contract adds a gas overhead to all bundles, we expect it to provide significant improvements to the security of the chain as it allows for more experimentation in payout mechanics (for example, smoothing MEV revenue variance across blocks to reduce incentive for time-bandit attacks).

Here is the implementation currently being considered. You can find it deployed to goerli at address 0x9d5fd9f03419912de052f37450f968bbdc5ef92d

/**
 *Submitted for verification at Etherscan.io on 2021-04-07
*/

pragma solidity 0.8.3;

contract MinerPayment {
    mapping (address => address) private _minerReceivingAddresses;
    
    event FlashbotsPayment(address coinbase, address receivingAddress, address msgSender, uint256 amount);
    event RecipientUpdate(address coinbase, address receivingAddress);
    
    receive() external payable {
        _payMiner();
    }
    
    function setMinerReceivingAddress(address _newReceivingAddress) external {
        _minerReceivingAddresses[msg.sender] = _newReceivingAddress;
        emit RecipientUpdate(msg.sender, _newReceivingAddress);
    }
    
    function _getMinerReceivingAddress(address _who) private view returns (address) {
        address receivingAddress = _minerReceivingAddresses[_who];
        return (receivingAddress == address(0)) ? _who : receivingAddress;
    }
    
    function getMinerReceivingAddress(address _who) external view returns (address) {
        return _getMinerReceivingAddress(_who);
    }
    
    function _payMiner() private {
        address receivingAddress = _getMinerReceivingAddress(block.coinbase);
        uint256 amount = address(this).balance;
        payable(receivingAddress).transfer(amount);
        emit FlashbotsPayment(block.coinbase, receivingAddress, msg.sender, amount);
    }
    
    function payMiner() external payable {
        _payMiner();
    }
    
    function queueEther() external payable { }
}

[chpiatt]

Would payments to this contract necessarily need to be made directly via EOA or would an internal transaction from another smart contract meet the requirements for inclusion? A lot of complex logic for bots happen in the context of smart contracts and the profit split for a lot of strategies would be a lot easier if this were handled inside another SC. Otherwise, bot operators would need to make assumptions about profitability when supplying the miner tip.

[Austin-Williams]

You can call all the functions on this contract form another contract. There are no EOA-only enforcements.

[thegostep]

// SPDX-License-Identifier: MIT
pragma solidity 0.8.3;

// This contract accepts ETH, delivering it to the miner of the current block.
// The FlashbotsPayment event is interpretted by Flashbots MEV-geth at block construction time to determine bundle profitability
// queueEther() can be used if multiple transactions pay the miner, saving gas from emitting multiple events and sending ETH twice

contract FlashbotsMinerPaymentV1 {
    event FlashbotsPayment(address coinbase, address msgSender, uint256 amount);

    receive() external payable {
        _payMiner();
    }
    
    function _payMiner() private {
        uint256 amount = address(this).balance;
        payable(block.coinbase).transfer(amount);
        emit FlashbotsPayment(block.coinbase, msg.sender, amount);
    }
    
    function payMiner() external payable {
        _payMiner();
    }
    
    function queueEther() external payable { }
}

[thegostep]

The proposed contract introduced ~11k gas overhead to all flashbots bundles. While this is a trivial amount compared to the cost savings of using flashbots, the searcher community felt the objectives listed above did not justify such a cost and off-chain methods should be explored to achieve goals 1 and 2.

Based on this feedback, the introduction of a proxy payment contract will be delayed in order to provide more time to explore alternatives.

Improving the security of the chain by smoothing MEV revenue variance / reducing incentive for time-bandit attacks / providing finality protection remains a core objective of flashbots and will be introduced in a future release.

[bixia]

do you have this contract deployed on the mainnet? cause i need to use it? does anyone knows the deployed address in mainnet?

[jgorfenger]

I made a GitHub account just to say this:
I am hotly against this so-called "feature". Calling another contract WITH a non-zero transfer, possibly doing more transfers, will increase gas costs by a non-trivial amount, not to mention having to go through hashing to determine the location of the mapping.

Therefore, despite whatever flexibility/logging we gain from implementing this, we lose out so much more in terms of gas costs. Say this operation takes a (conservative) extra 4,000 gas: there will be plenty of times when a miner could have fit more profitable transactions in the block had this extra operation not taken place. Not to mention that we are already using up a lot of the Ethereum network - think how much more gas would be wasted on logging Flashbots payments.

So both the miners AND the searchers would be losing out on this proposal.

If miners want to route it to some other address, they can do that sort of routing at periodic intervals. There is no need to be calculating a routing every single MEV transaction. Logging payment amounts and doing custom routing is simply too expensive to do on-chain. As far as I can tell, logging payment amounts right now by looking at coinbase transfers and gas does not seem too difficult as it is.

[abog854]

I don't see why this feature is needed, and agree to the points @jgorfenger made about gas usage. You mention these objectives:

• Reliable logging of payment amounts

Direct transfer to COINBASE are already a unique pattern, that's very easy to search for and analyze. Can you explain why this is needed?

• Miner can define recipient address different from coinbase address

The COINBASE address is already meant to be the address where miners want to get fees sent to, sending MEV there seems like a logical thing. Can you explain why this is needed?

• Spread luck / incentivize finality

It looks like the start of an interesting idea, but there is nothing else. Can you clarify what this is about? What is the concrete proposal here?

[Austin-Williams]

Direct transfer to COINBASE are already a unique pattern, that's very easy to search for and analyze. Can you explain why this is needed?

It isn't easy to search for if the coinbase payments are internal txs, which they almost always are. This pattern makes finding them as easy as grabbing logs.

The COINBASE address is already meant to be the address where miners want to get fees sent to, sending MEV there seems like a logical thing. Can you explain why this is needed?

Mining pools have expressed that they want to be able to provably show their participants how they are paying out their MEV income from flashbots. They also want the ability to have MEV income be separate from block reward income (as they may pay out differently for the two). Logging, and having MEV income held in a different account, addresses this.

It looks like the start of an interesting idea, but there is nothing else. Can you clarify what this is about? What is the concrete proposal here?

This is not addressed in this version of the contract. The overarching idea (which has not been solidified yet) is that it may be possible to prevent time-bandit attacks if miner payments are spread over multiple miners and over multiple consecutive blocks. This would almost certainly be most practical to achieve by having all flashbots searcher payments be handled via a payment contract like this one.

This time-bandit-protection is not present in the proposed payment contract.

[CodeForcer]

I was originally against this, but now I see this as the only way to protect against a future of damaging the consensus through miner-on-miner Salmonella. In such a scenario one miner attacks another miner performing MEV trading through block reorgs.

In a simple example, you create a bait token which creates winning sandwiches that have a small win and very large trade size.

You sustain a few round of losses while the competing miner sandwiches you, until you get the re-org, at which point you take their buy transaction and include it in your block, and discard the sell/victim transactions, essentially draining your competitor.

This strategy can be extended in a variety of ways to attack other miners or traders who perform MEV, but a proxy contract can mitigate this by punishing re-orgs.

[Austin-Williams]

I think the gas costs here are a non-issue for the Ethereum network and for searcher competitiveness.

For the Ethereum network as a whole: flashbots reduces the amount of gas used for the extraction any given MEV opportunity. If flashbots prevents even one failed tx from landing on chain (and it usually prevents several from landing on chain) then the extra gas spent on logging will have been paid for many times over by the gas savings from a single failed tx not landing on chain.

For individual searchers: The small increase in gas cost applies to all searcher competitors, so this payment contract has no effect at all on searcher competition among searchers. As for the competition between flashbots searchers and non-flashbots bots, the small added gas costs are more than compensated for (again, by several multiples) by the prevention of even a single of your failed txs from landing on chain.

So gas costs shouldn't be of any concern for flashbots searchers or people who care about the Ethereum network as a whole.

[jgorfenger]

Remember that the 0.2 upgrade will introduce more than one bundle per block, which could compound this issue to the point that, perhaps, a regular ETH transfer does not make the block because of some Flashbots logging contract.

One problem here is that everyone is speculating about the gas costs and no one is actually doing any testing to see what the effect really is. I'll try to look into it and see what this contract would actually do.

[azavalla]

Some thoughts:

• I don't think that "simplifying accounting for the miner" is a very strong argument. It is not like they can't do it anyway.
• Flashbots already prevents failing transactions from landing on-chain. I don't think that "using flashbots is cheaper than not using it" is a valid argument. We should aim for the best possible flashbots, not just for a net positive one.
• I think that the gas cost issue outweighs the advantages proposed so far.

Ultimately, it should be up to the user if they want to use the logging router or a coinbase transfer. IMO this feature should be in the "nice to have" category. Definitely not a "required".

[jgorfenger]

I have done some more testing using the router contract code that @thegostep provided using the settings identical to the ones deployed on Georli.

I've found that for a sample searcher contract, the gas used in the transaction increased by 11,345 when using the standard payment router contract compared to a coinbase transfer.

For many contracts, this is comparatively a huge amount of gas - most transactions will see a 3-10% increase in gas usage. This means that the relative gas price for these bundles will go down by about 2-9%. A bundle costing 151,000 gas with a relative gas price of 150 Gwei in v0.1 will have a relative gas price of only 139.5 Gwei in v0.2.

The miner, searcher, and Ethereum network as a whole all take a hit because of this router contract. With bundle merging being introduced in v0.2, all it takes are two Flashbots bundles using the standard payment router to boot a regular ETH transfer transaction out of the block. The gas that would have been used for a standard ETH transfer - paid for by the sender - is replaced by Flashbots logging, whose extra gas (a) pays nothing to the miner, causing the miner to lose out on potential profits, and (b) makes bundle inclusion more difficult against on-chain mempool transactions for searchers.

Proof that miners will lose out

I will assume (b) needs no proof and will prove (a). Consider a situation in which the greatest-price transactions from the mempool to be included in the next block have a relative gas price of x. Let there be one Flashbots bundle whose relative gas price via a coinbase transfer is y, where y > x. Let z = y - e, where e is the loss in relative gas price when sending the miner payment through the standard payment router contract; therefore, z is the relative gas price of sending the miner payment through the standard payment router contract. Let us also assume that the searcher is paying 100% to the miner, which is the approximate outcome of searcher competition. There are two cases:

1. z > x
   The bundle (using the standard payment router) is still included in the block. However, the miner could have gained more had a coinbase transfer been used instead, since the bundle's relative gas price is always lower than an equivalent bundle that uses a coinbase transfer.
2. z <= x
   The bundle (using the standard payment router) is not included in the block since its relative gas price is not better than that of the mempool transactions. But since y > x, the miner could have gained more from including the bundle with a coinbase transfer rather than the mempool transactions.

In both cases, the miner will certainly lose profits if the standard payment router is used.

Why this is important

Some of the benefits espoused by the proponents of this proposal are well and good except that most of them simply do not apply to the proposed contract. The proxy contract is simply redirecting where the transfer is going and making a log message. It cannot help protect against reorganization attacks in its current state. It does not evenly distribute miner rewards, either. It should be up to the miner to distribute the rewards in, perhaps, a more efficient manner than to force all Flashbots bundles to include them.

This is coming from someone who at this time is neither a searcher nor a miner. I appreciate any/all critiques of my methods and simply want the best for Flashbots. The contracts I used in my tests are quite trivial - one does a coinbase transfer, while the other directly calls payMiner from the standard payment router contract.

[tkstanczak]

this would probably decrease the cost of the contract by ~10%
byte[] deployedCode = Prepare.EvmCode
// jump out if length of call data is 1 which means enqueue funds)
.Op(Instruction.CALLDATASIZE) // 2 gas
.PushData(20) // 3 gas
.Op(Instruction.EQ) // 3 gas
.PushData(100) // jump out if equal // 3 gas (get the address of the last JUMPDEST)
.Op(Instruction.JUMPI) // 10 gas
.PushData(0) // 3 gas
.Op(Instruction.DUP1) // 3 gqs
.Op(Instruction.DUP1) // 3 gqs
.Op(Instruction.DUP1) // 3 gqs
.Op(Instruction.SELFBALANCE) // 5 gas
.Op(Instruction.COINBASE) // 2 gas (address of storage to check)
.Op(Instruction.SLOAD) // 2200 gas (load if redirection address)
.Op(Instruction.DUP1) // duplicate SLOAD result // 3 gas
.Op(Instruction.DUP5) // duplicate 0 for the gas for call // 3 gas
.Op(Instruction.EQ) // 3 gas
.Op(Instruction.NOT) // 3 gas
.PushData(99) // if redirection is zero // 3 gas
.Op(Instruction.JUMPI) // 10 gas
.Op(Instruction.POP) // 2 gas // pop duplicate SLOAD result (zero here)
.Op(Instruction.COINBASE) // 2 gas
.Op(Instruction.JUMPDEST)
.Op(Instruction.DUP5) // duplicate zero for gas
.Op(Instruction.CALL) // transfer BALANCE to COINBASE if SLOAD is zero or transfer BALANCE to SLOAD result if SLOAD result is not zero
.Op(Instruction.RETURN) // return before the jump destination for SSTORE handling
.Op(Instruction.JUMPDEST)
.Op(Instruction.CALLDATALOAD) // use redirection address (possibly fix the padding using memory ~ 20 gas?)
.Op(Instruction.COINBASE) // 2 gas
.Op(Instruction.SSTORE) // 20000 gas
// come here for SSTORE
.Done;

the contract is relatively easy that the Solidity overhead may not be worth it

[tkstanczak]

I was writing it without checking things so some calls may be slightly out of order -> just pick it as a general idea

[tkstanczak]

current cost for 0 value and non-zero value calls (non-zero is +9000 cost of call -2300 cost of stipend so 6700 higher than zero value)

[Randall4]

Your solution does not help Flashbots identify transactions, unfortunately, though I share your sentiment. Throw a LOG2 somewhere in there (we probably don't have to log the coinbase address) and estimate again. You'll end up somewhere around ~9700 gas more than a coinbase transfer, though in assembly I bet you'll do better.

If we can find a way to avoid the contract altogether it would be a big win for everyone and would keep Flashbots competitive against other MEV organizations.

[Randall4]

I have an alternative solution to the router contract that could preserve coinbase transfers but still allow Flashbots transactions to be identified more effectively. In this proposal, searchers could choose one of two options:

1. All direct coinbase transfers MUST contain a specific pattern in the lowest 16 bits of the transfer value. Here is one such random sequence that I rolled using six-sided dice: 0xde8d
   In addition to the fact that coinbase transfers are already relatively rare, there would only be a 1/65536 chance of a different transaction sending ETH to the coinbase from matching, if transaction values are assumed to be random. This cannot prove that the transaction went through Flashbots, but neither could the router contract, so in my opinion the security properties are similar. (A motivated "spammer" would still be able to route payments through a router contract.) The maximum possible difference in ETH for the miner payment would be 0.000000000000065535, which is certainly small enough for no one to mind the small change in value.

2. Searchers could elect to go through the router contract instead, if, for instance, they cannot easily set the last 16 bits of the transfer value.

I guess this would depend on what Flashbots is trying to accomplish with its logging. I think the goals of the router contract would be made clearer if you shared your current difficulties in logging miner payments. Maybe we could even find a solution that preserves the current structure.

[Brucecarl]

Still can understand this propose was included in v0.2???
gas costs increased a lot!!!

[Randall4]

One thing to keep in mind would be the potential for a malicious token to also make a coinbase transfer and destroy the pattern in the last 16 bits, preventing the token from being used on Flashbots. A solution for this would be, on the relay side, to trace the coinbase transfers and only look at the largest one. Or, even better, allow the sender to specify the address the coinbase transfer will be sent from.

[wjmelements]

The nice thing is, this will make flashbots less competitive than alternatives, and reduce their influence over the network. There are no other upsides; this is just a waste of gas. The coinbase key can already redirect as much eth as they want to as many addresses as they want, and in less gas than this. It's trivial to track coinbase payments; this log is an expensive crutch for terrible engineers.

[axic]

The below is without any warranties attached and is only for educational purposes, but it would be possible to use something like Yul to get better efficiency:

{
  // Construct the log for "event FlashbotsPayment(address coinbase, address msgSender, uint256 amount);"
  mstore(0x00, coinbase())
  mstore(0x20, caller())
  mstore(0x40, callvalue())
  log1(0, 0x60, 0x82bfd7d226ef75398f858bca413814d37886af582526e7fae712e36fe8a5d297 /*topic*/)

  // Transfer the incoming payment to the coinbase
  pop(call(not(0), coinbase(), callvalue(), 0, 0, 0, 0))
}

This will emit the log as implemented in #45 (reply in thread) and transmit any incoming value to the coinbase.

It translates to the following bytecode:

Binary representation:
4160005233602052346040527f82bfd7d226ef75398f858bca413814d37886af582526e7fae712e36fe8a5d29760606000a160006000600060003441600019f150

Text representation:
    /* "flashbots.yul":166:176   */
  coinbase
    /* "flashbots.yul":160:164   */
  0x00
    /* "flashbots.yul":153:177   */
  mstore
    /* "flashbots.yul":193:201   */
  caller
    /* "flashbots.yul":187:191   */
  0x20
    /* "flashbots.yul":180:202   */
  mstore
    /* "flashbots.yul":218:229   */
  callvalue
    /* "flashbots.yul":212:216   */
  0x40
    /* "flashbots.yul":205:230   */
  mstore
    /* "flashbots.yul":247:313   */
  0x82bfd7d226ef75398f858bca413814d37886af582526e7fae712e36fe8a5d297
    /* "flashbots.yul":241:245   */
  0x60
    /* "flashbots.yul":238:239   */
  0x00
    /* "flashbots.yul":233:324   */
  log1
    /* "flashbots.yul":430:431   */
  0x00
    /* "flashbots.yul":427:428   */
  0x00
    /* "flashbots.yul":424:425   */
  0x00
    /* "flashbots.yul":421:422   */
  0x00
    /* "flashbots.yul":408:419   */
  callvalue
    /* "flashbots.yul":396:406   */
  coinbase
    /* "flashbots.yul":392:393   */
  0x00
    /* "flashbots.yul":388:394   */
  not
    /* "flashbots.yul":383:432   */
  call
    /* "flashbots.yul":379:433   */
  pop

Some potential optimisations:

• The last pop can be removed, stack balancing is a requirement for Yul, but not for the EVM at the end of execution.
• The not(0x00) should be rewritten to 0xfff...fff as the push is cheaper if only runtime cost is considered (and not deploy cost).
• If deploy cost is a concern, a lot of the 0x00s can be replaced with dups. I think deploy cost is not a concern tough, only runtime.

If one wants to have that event emitted, I do not think this can be made any more cheaper.