For example, a Marketplace would allow for bids in the form of “I’ll pay X to include transaction Y as long as it comes before any other transactions which interact with the smart contract identified by Z”.
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. To me, those seem like things that the “proposer” should be doing, rather than the “relay” or the “builder”.
Would it be plausible to make the “mevpool marketplace” operate solely on packages of transactions, that is:
flowchart LR
Extractor1 --tx pkg--> Marketplace
Extractor2 --tx pkg--> Marketplace
Marketplace --{tx pkgs}--> Miner1
Marketplace --{tx pkgs}--> Miner2
Miner2 --block--> Network
So that extractors who want their tx Y to be first monitor the mempool for other txs that interact with smart contract Z, setup a tx pkg that does that and submits it to the marketplace. Other extractors might submit competing packages, bidding fees up, and the marketplace sends the proposed packages to miners who build block templates, etc.
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.
This assumes miners can do package RBF in a fairly optimal manner, and that we can add “sealed txs” to the mempool, but otherwise seems to keep things fairly simple on the miner/marketplace side.
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.