Revenue allocation in shared sequencing

Quoting Ben Fisch from Espresso:

"How is revenue shared among rollups sharing the same sequencing layer? Rollups choosing to use a shared sequencer are asking this question. Even if the shared sequencing layer is increasing the overall volume of transactions, bringing more utility and more users to all rollups on it, the rollups naturally want to know how this translates to the same or greater profit than running their own sequencer. If the nodes of the sequencing layer took all the profit then rollups wouldn’t be incentivized to use it.

The problem isn’t simply choosing a solution concept for allocation (Shapley value etc), rather the problem is that the marginal contribution of each rollup is not easily discoverable. How are rollups convinced they are each getting their fair share of the profit? If simple tx fees (i.e., fees paid for the inclusion of an individual transaction in the block) were the only source of revenue this would be simple: the contribution of rollup X is the aggregate of fees paid by users for transactions on rollup X. In fact, rollups can take these fees directly. However, a significant fraction of the profit may come from MEV, which in the case of shared sequencing may have cross-rollup dependency. This may be less of a concern for projects who want to prevent MEV via methods like threshold encryption, but some rollups are either looking to profit from MEV or distribute the MEV to their users. Finding a fair allocation of the total MEV among rollups is complicated by the fact that the MEV is typically based on private information available to various actors in the system and only discovered through an auction run by the sequencing layer – there isn’t a publicly known deterministic function that calculates the MEV of an ordered bundle of transactions. These auctions may involve agents (searchers) bidding on atomic ordered bundles that include transactions from multiple rollups."

Some additional thoughts and directions:

  • Consider a situation in which a lending app-chain and a DEX opt into the shared sequencer. The lending protocol benefits from risk reduction while the DEX protocol might benefit from more LP fees. Should this factor into how MEV revenue is shared?
  • The core and shapley value are obvious starting points.
  • How should fees be paid? In PBS on Ethereum, builders pay directly in the EVM, however when multiple domains are being sequenced there may only be a single payment, which must somehow be distributed to different domains.

Relevant links:

6 Likes

Curious to hear whether you see Espresso sequencer complement / compete with SUAVE?

  • Is the main focus for SUAVE MEV mitigation on Ethereum and possibly afterwards priority gas auction based chains/L2s?
  • Would it be more advantageous for an L2 to implement SUAVE directly or SUAVE implementation on a shared sequencer makes more sense?
  • How would the former (single roll-up using SUAVE for decentralized block building) compare in terms of TPS compared to the current central sequencer
  • How would TPS with SUAVE compare to TPS with Espresso Systems?

Complementary! We’ve been thinking about it like this: rollups which deploy on Espresso (or equivalent) are effectively choosing Espresso to be “proposers” of their blocks. These proposers still need the blocks to be built, which is where SUAVE comes into the picture. Espresso and SUAVE will interact in a PBS-like interface.

Is the main focus for SUAVE MEV mitigation on Ethereum and possibly afterwards priority gas auction based chains/L2s?

Basically, yes. There’s more outside of blockchain too, but it makes sense to start with MEV and it makes sense to start on Ethereum.

Would it be more advantageous for an L2 to implement SUAVE directly or SUAVE implementation on a shared sequencer makes more sense?

Depending on the rollups design goals either option could work for them. One flow could be deployment on a SS and a full-block PBS interface between SUAVE and the SS. A different flow could be the L2 running their own set of a handful of sequencers, each of which runs a TEE locally and queries SUAVE blocks like that. The latter is a more complicated, but could bring some market efficiency IMO.

How would the former (single roll-up using SUAVE for decentralized block building) compare in terms of TPS compared to the current central sequencer

unclear what the setting is, but, depending on the SUapps deployed and TPS of the native chain, you could see no difference

How would TPS with SUAVE compare to TPS with Espresso Systems?

I think my comments above should explain why I don’t really understand this question

1 Like