Proposal: Flashbots Core v0.2

[thegostep]

Flashbots Core consists of MEV-geth together with the Flashbots Relay. The current live version is v0.1, this document describes the proposed improvements to roll out in the next version, v0.2. The tentative timeline for this version is:

• Week of April 5th: collect feedback from community, start work on formal specification and implementation.
• Week of April 12th: incorporate feedback, continue work on specification and implementation.
• Week of April 19th: release specification and reference implementation of MEV-geth, testing.
• Week of April 26th: launch.

Feedback

The detailed proposed changes are outlined here: https://hackmd.io/@flashbots/core-v2-proposal

The proposed upgrade process is outlined here: https://hackmd.io/@flashbots/core-upgrade-process

We kindly ask the community to provide feedback in this discussion thread.

[llllvvuu]

Summarizing my feedback from Discord re: revamped auction pricing:

• V_direct / s_U may over-penalize strategies that leverage transactions from the mempool
• We can alternatively discourage bundle-stuffing by capping gas score to a constant g_max, i.e.

score = (V_direct + sum([min(g_T, g_max) * s_T for T in U])) / s_U

g_max needs to be small enough so it is not advantageous to include arbitrary mempool transactions in the bundle, but otherwise should be as large as possible, so that including strategically selected mempool transactions is minimally penalized. One option is to set g_max = g_tail from the previous block (thanks to @thegostep)

[llllvvuu]

Yes, let me clarify my math. I think it may have been confusing because I only specified the numerator initially (edited my post to show the full score).

The g_max would serve to drag down the weighted average. i.e.

• if V_direct / s_V > g_max, adding more transactions can only decrease the score.
• if V_direct / s_V <= g_max, then no amount of transactions will bring the score above g_max. The bundle will lose the auction.

Without the cap, bundle stuffing works because the included g_T >> g_tail, >> other_bids, which cancels out V_direct < g_tail, < other_bids, so necessarily the included tx's would be suppressed by the cap (this can probably be backtested)

My underlying motivation is to expand the search space for searchers, enabling legitimately big bundles using mempool tx's (this is where MEV gets interesting IMO), so it would be ideal to not have any tx/size limit (or at least a very generous one) nor too much penalization for using mempool tx's.

[llllvvuu]

One other idea would be to approximate the opportunity cost for the miner. That is to say, rather than rewarding expensive from-mempool transactions (which would be included regardless), penalize cheap transactions (which cost counterfactual money to include):

score = V_direct - sum([min(g_tail - g_T, 0) * s_T for T in U])

This is also a function for which it never benefits your score to add tx's, nor do you get free tx execution. The edge case I can see with this one is that if there is no denominator then if g_tail dips then you can fill the next block with CHI mints and keep g_tail suppressed - so this score would require a bundle size limit, but it could be something generous like 50% block limit (in addition, to be robust to larger bundles, the "opportunity cost" could be based on an increasing g_tail which is working backwards from the end of the last block, rather than fixed at the very end).

[llllvvuu]

One last cherry on top (not as necessary - this is just so existing bots, which are built around gas rather than coinbase, could easily join) would be if the searcher could authenticate which tx's are their own so that there can be an exception for the searcher's own tx's to be able to pay the bribe with gas - that is, treat g_T * s_T for those transactions as part of V_direct. (This would also help with logging Flashbots payments)

Implementing this and the above comment should come close to optimal profit for mev_geth.

[jparyani]

I think I'm ok with changing to the formula:

score = (V_direct + sum([min(g_T, g_max) * s_T for T in U])) / s_U

There's a somewhat separate discussion, but I think we're going to make g_tail set by the relay, and not the miner. That gives us a ton more flexibility here, and we can eventually move to the relay doing heavier weight simulations to fine tune this param better. I think we can do the same for g_tail, and make it be provided by the relay.

This means we can tune this param in real time, and we can even set it to 0 until we have a firmer opinion on what it should be.

[llllvvuu]

One more idea is, maybe max miner profit can be directly computed by the miner? It could be computationally cheap if we make the simplifying assumption that including the bundle won't affect affect gas paid by any of the other transactions in the block, so that computation is just a simple summation for the with-bundle block vs the without-bundle block (i.e. no re-running any transactions). "Bundle stuffing" would be automatically addressed, as the miner would just dedup those transactions when summing the with-bundle block.

[rkrasiuk]

another suggestion to revamping the auction pricing is quadratically rewarding higher gas priced transactions while weighing the total bundle cost against the direct payment. i.e.
score = (V_direct - (sum([g_T^2 * s_T for T in U]) / V_direct) ) / s_U
my issue with having a g_max is while it does give the final say to the direct payment in the case of g_T > g_max for every T in U, it penalizes higher gas-priced transactions from the bundle, which bring value to the miner.

[jgorfenger]

Please review my comments regarding the standard payment router contract proposal: #45

I fear that this proposal will become an anti-feature that burdens the network and directly reduces profits for both miners and searchers. This proposal should only come into the system if it can be shown or proven that it will actually reduce gas or increase profits for most if not all use cases. (However, I don't think that is the case and personally believe this should be removed from 0.2.)

[wjmelements]

plz include #48 asap kthx