MevPool

a brief noodle on incentive compatibilty

This came out of an in-person conversation with Georgios and a few others.

Why do miners pool?

Miners are constantly grinding PoW. Each hash attempt has a very small chance of finding a block, and each block has a large reward. Most of the time, the miner operates at a loss, but every once in a while, the miner gets a huge payout that covers past and future electricity and hardware. The mining business is inherently risky. If the miner has a bad run of luck, and gets no blocks, they will shut down. Pools formed to address this.

Cash Flow Smoothing is the primary benefit of pooling. The law of large numbers eventually bankrupts a small miner, but not a large pool. Pools convert a high-variance cashflow into a lower-variance cash flow, and allow smaller miners to participate. The pool receives a portion of mining revenue as payment for this service. Pools provide a critical financial service to miners, and without pools, most miners would quickly exit.

In addition, pools allow miners to specialize. When self-mining, miners must run their own high-availability Bitcoin node. Node downtime means potential lost revenue. Lost revenue means decline and death. A pool runs this node for the miners involved. Pool-miners don’t even see blocks, they just get minimal templates that allow them to mine.

At its face, MEV is similar. Searchers specialize heavily in grinding a specific computational problem. Searcher revenue is chunky, like miner revenue. Searchers (like miners) have negative median income per block. Shouldn’t Searchers want to pool to smooth their cashflow and offset this risk?

MevPool

Suppose there was an MevPool, which worked like mining pools. The MevPool aggregates transaction flow and assigns Searchers to work on it. Searchers delegate their extracted profit to the pool, which negotiates with block builders/proposers/etc, and assigns pool profits to Searchers according to their work. Such a pool would smooth Searcher cash flows but sadly would collapse immediately.

Unlike miners, there is very high variance in Searcher competence. And Searcher OpEx is significantly lower than mining. And competence leads more directly to profits, and does not significantly increase opex. This means that there will be a pareto-like distribution of pool profit. A small number of Searchers will generate a large proportion of the revenue. This means that participating in MevPool is positive EV only if you’re a below-average Searcher, mooching off the profits of your more-profitable poolmates. 

From there, it all breaks down. Searchers can betray the pool trivially by keeping transaction flow for themselves. If the most-competent Searchers have negative EV from pool-participation, they’re basically guaranteed to betray the pool. This turns into a death-spiral, as the most competent Searchers abandon the MevPool (because why did they even join in the first place? Competent Searchers don’t even require cash flow smoothing as they already capture a significant percentage of the available MEV). 

The only way to make MevPool viable is to prevent this betrayal. One can imagine a complex scheme involving fake transactions and withheld transaction signatures to determine which Searchers are participating according to pool rules (simulating in a sense the blockshares model of a mining pool). But honestly, why bother?

It’s an empty pool. Get it? Because the pool would be empty oh nevermind. Photo by Izz R on Unsplash

Blinded Bundles

In other words, MevPool, like many interesting designs in the MEV space, essentially requires blinded searching. It requires searchers to be able to find MEV within a private transaction flow, without being able to read the contents of the transaction flow. It seems impossible on its face to both allow extraction and to hide the contents of the transactions being extracted from.

I think a fun place to start pursuing this formally would be to make an analogy to cryptographic oracle attacks. Argue that blinded Searching requires querying some MEV oracle to determine the fitness of the blind bundle (blindle?), and that the existence of that 1-bit oracle for bundles is sufficient to allow insertion-based MEV extraction if the Searcher can query it often enough.

Another fun thing to point out is that any implementation of that oracle would have to have an internal definition of MEV, which would necessarily not capture everything the Searcher considers to be MEV (as Searchers can perform stat arbs with exchange prices, and the oracle cannot). Therefore the pool will either drop stat arb, and capture less value than a competent Searcher over the same transaction flow OR be able to lie about the amount of MEV any given searcher created (betraying its Searchers).

Anyway

This isn’t going anywhere. There’s no big point. Just a fun little noodle. Don’t build MevPool. I’m not convinced blinded Searching is feasible, or even possible.