Best-(Worst-)Case MEVil Response

[MattCorallo]

@ajtowns

I think a “bid” of that form would be unpleasant if passed all the way through to miners – accepting the bid but still including transaction W that interacts with smart contract Z means (in general) modifying transaction W to spend an output of Y (or perhaps some child of Y), and potentially updating the witness data of W to deal with the difference in value of Y’s output vs Z’s output.

Mmm, this is a good point, and I had mostly been thinking of this in the context of things like CSV (and CSV-based rollup) protocols, where this likely doesn’t apply (at least if they’re EVM-like). However,

@ajtowns

Would it be plausible to make the “mevpool marketplace” operate solely on packages of transactions, that is:

Yea, sorry, somewhat shorthand here this is indeed how I’ve been thinking about bids. A proposer would be able to submit one or more transactions in a single bid, and indeed would be able to do what you describe here.

@ajtowns

For sealed bids, I think you could reveal with utxos the package spends, the txids and wtids, and the total sigops, weight, and fee, and then either rely on trusting the marketplace to reveal the tx contents or a trusted execution environment in a similar way.

Yep, though you can pass this all the way through to miners just as well. Basically you’d move bids to always be “the full set of transactions which interact with a contract” rather than ever being a subset of them (for contracts that rely on state passed via UTXOs) and then you can send the whole tx bundle through to the miner’s TEE (or, indeed, just reveal the metadata if you’re using a trusted marketplace).

@ajtowns

This assumes miners can do package RBF in a fairly optimal manner

Indeed, though luckily this is somewhat simplified in that the miner is required to only either include or not-include the whole package, they cant split it into parts. They just have to be able to compare that to their existing mempool, which is hard but if we’re talking about a server-class processor with SGX you can throw some CPU at it and get close enough to optimal that I’m not worried :).

@ajtowns

Revealing the utxos that sealed txs are spending might be something of a give away to competitors, but seems unavoidable if you want miners to be building the block templates.

This is part of the reason for the TEE - if we can take the whole block building logic and shove it in SGX, we can run it locally at the miner but also send it Sealed transaction (packages) which can be considered for the block template but won’t be extractable (at least for reasonable cost).