rollmint
rollmint copied to clipboard
celestiaorg
Ensure Intra-Block MEV Isn't Available to Bitcoin Miners
Adding data storage on Bitcoin causes some drama on twitter, but generally isn't all that problematic - Bitcoin miners have to get paid somehow. However, as we've seen with ETH post-merge (and even pre-merge), intra-block MEV can be hugely problematic for decentralization of the mining ecosystem. If the goal is to use Bitcoin as a "securely decentralized platform for DA", that's great, but if the goal is to use it as a "securely decentralized platform for consensus decisions of a rollup", that breaks itself - introducing intra-block MEV causes the decentralization part to fail and defeats the whole point.
Because of these concerns, its not entirely unlikely that the Bitcoin community would endeavor to soft-fork out applications operating on Bitcoin which introduce intra-block MEV to the underlying system.
Luckily, this doesn't appear to materially impact your system - utilizing Bitcoin only for data availability without piggy-backing onto its consensus for transaction ordering on the rollup should be possible in your framework without issue, and I'd very strongly encourage you to do so to avoid negative social outcomes.
As an alternative, consider not using in-chain-order as the canonical order of higer-level systems. Rather, randomize the order of interpreting on-chain data across a set of blocks by the block hash of a block later. In this way, miners don't have trivial MEV, but would rather have to opt to discard blocks with hashes which do not result in the higer-level transaction ordering they want (or mine every block in a "transaction ordering set" to prevent transaction inclusion of alternative histories).
One thing that's worth noting is that most rollups today capture their own MEV (via their sequencers) rather than leak it to the base layer, as a way to accrue value to the rollup. This would be the case if the rollup is constructed in such a way that there is only one possible sequencer per "time slot". (It would be possible for miners to censor specific sequencers though, but I think that's not the same as intra-block MEV.)
MEV would leak to the base layer if the rollup doesn't have sequencer nodes, but uses the base layer directly for sequencing (what Rollkit calls "pure fork-choice rule rollups", similar to colored coins type designs), or if there can be blocks from multiple sequencers per base layer block.
One thing that's worth noting is that most rollups today capture their own MEV (via their sequencers) rather than leak it to the base layer, as a way to accrue value to the rollup. This would be the case if the rollup is constructed in such a way that there is only one possible sequencer per "time slot".
Right, I don't think that's a concern.
(It would be possible for miners to censor specific sequencers though, but I think that's not the same as intra-block MEV.) MEV would leak to the base layer if the rollup doesn't have sequencer nodes, but uses the base layer directly for sequencing (what Rollkit calls "pure fork-choice rule rollups", similar to colored coins type designs), or if there can be blocks from multiple sequencers per base layer block.
Right, this was my point - for such things, it likely makes sense to...not have them. We should all endeavor to set social norms which discourage such systems in the strongest possible terms, including not building software to make it easy :p. For those who don't want to build a system involving sequencers, my alternative proposal using later block hashes to randomize rollup transaction ordering across a set of blocks should offer an option that avoids large MEV creation.
I also realize there may have been some terminology confusion, I updated the initial post to say "intra-block MEV" when referring to MEV where miners need context of the higher level protocols to extract value - ie value from explicit transaction fees is great, from centralizing specific optimizations very bad.
https://youtu.be/XwqLb4KoQYM?t=834 This is a nice overview of who can extract MEV.
If Bitcoin does Consensus and DA + Sovereign Rollup has Centralized Sequencer => MEV at the Sequencer. If Bitcoin does Consensus and DA + Sovereign Rollup has a Decentralised Sequencer TM-Style => MEV at the Seqeucners. If Bitcoin does Consensus and DA + Sovereign Rollup has an FCFS => MEV at the Bitcoin Miner.
I am saying that the title should be "Consider Removing Bitcoin Miners having Influence on the Rollup Block Order" because, in all cases, we still get the consensus from Bitcoin. Only who is the Leader(ordering the Block) determines where the MEV is.
Indeed, I renamed the issue to better capture what the issue is vs isnt, thanks.
Intra-block MEV.
Note that this is only an issue once Based rollups on Bitcoin are possible to build using Rollkit. Currently Rollkit only supports trusted sequencer rollups. Once this is enabled, "not building software to make it easy" as @TheBlueMatt mentions won't be possible since it'll already be built. Therefore, this cannot be ensured, so closing this issue makes the most sense.
Note that this is only an issue once Based rollups on Bitcoin are possible to build using Rollkit. Currently Rollkit only supports trusted sequencer rollups.
Not sure I understand your comment. This issue, then, is more suggesting that that not be built. Why build something that materially risks Bitcoin's long-term value?