Integrating SUAVE with Astria Rollups

[itamarreif]

Overview

Astria is building a decentralized shared sequencer network that creates a market for transaction ordering on Celestia-based rollups. Decentralizing a shared sequencer means that authority over ordering is distributed across a diverse set of node operators, providing better guarantees for users with regards to value extraction.

The shared sequencer creates a single “meta block” consisting of transactions belonging to one or more rollups. It is a lazy sequencer construction, meaning it treats the data it orders as simply bytes, only ordering and not executing any rollup transctions.

We propose a method of integrating SUAVE bundle construction into our existing shared sequencer transaction flow, enabling rollup developers to harness the benefits of SUAVE and MEV-Share to reduce value leakage occuring on their networks.

At a high level, the construction can be described in three steps:

1. MEV-leaking transactions can be submitted through SUAVE to produce searcher bundles
2. Searcher bundles are then submitted to the shared sequencer, integrating MEV Share with Astria’s blockspace market
3. Rollup nodes deterministically derive state transitions from sequenced transactions, placing SUAVE-generated bundles at the top of the block as ordered by the shared sequencer.

Goals

• Implement a proof-of-concept for a rollup that enshrines SUAVE in its block building process.
• Demonstrate using SUAVE to construct bundles for Astria-based rollups. This enables users and protocols to inherit the benefits of MEV-Share, curbing the value leakage that is currently captured entirely by centralized sequencer operators.

Non-goals

• Implement a production-ready SUAVE integration for Astria-based rollups.
• Demonstrate searching for MEV on Astria-based rollups using SUAVE.
• Implement a sufficiently secure or decentralized SUAPP.

Background: Astria

Write Path: Transaction Submission

1. Users sign a transaction via a wallet, submitting it to the rollup node (e.g. Astria’s modified Geth), which is then gossiped to the rollup’s mempool.

2. The Composer is a developer tool we have created to act as a gas station. It retrieves pending transactions from the rollup node’s mempool, then wrapping them in an Astria transaction and submitting them to Astria’s mempool.

3. Astria’s shared sequencer constructs a cross-rollup “meta-block”, finalizing an ordering over the data posted to multiple rollups’ namespaces at once.

4. The finalized shared sequencer blocks are posted to Celestia, allowing rollups to leverage strong guarantees over data availability for cheaper.

Read Path: Block Retrieval and Execution

5. Each rollup runs its own instance of the Conductor. The Conductor reads and validates rollup data from finalized Astria blocks.

6. Filtered blocks are passed to the rollup node (e.g. Geth) using Astria’s Execution API, and are then executed by it, resulting in an updated rollup state and state root. This is how a rollup derives its state from the sequenced data posted to and made available by the data availability layer.

Conductor

The Astria Conductor is a sidecar process that a rollup node operator runs alongside the rollup node. It acts as a light client of the shared sequencer and data availability networks, pulling in Astria and Celestia blocks, validating them and feeding them into the rollup node using the Execution API.

• Data flow and verification spec
• Sequencer inclusion proofs spec

The Astria Execution API

Astria integrates block production infrastructure into rollup architectures by running a Conductor instance as a sidecar to the rollup node. The sidecar reads and validates finalized Astria blocks for the rollup’s data and communicates with the rollup-specific software using Astria’s Execution API.
While an in-depth explanation of the API and the specific request semantics can be found in the specification document and the protobuf definitions, the main request of interest in this situation is ExecuteBlock.

SUAVE-Enabled Astria Rollup

When ingesting SUAVE produced blocks, the write/read path of a single Astria rollup is modified to look like the following:

Write Path

1. User connects to the rollup node (e.g. Geth) and signs a transaction and submits transactions via a wallet, submitting it to the rollup node (e.g. Geth), gossiping the transaction to which land in the rollup’s mempool.

2. Some of the rollup’s nodes run SUAVE wallets which pull all the transactions that reach thei rollup’s mempool and posts them to a SUAPP as a SUAVE transaction with the user’s rollup transaction as a confidential input. Nodes that do not operate a SUAVE wallet forward the user transactions to the Composer as described above.

   • Alternatively, the user can maintain both rollup and SUAVE wallets and sign and submit directly to SUAVE instead of passing through a rollup node. However, our proof of concept implementation does this from the rollup node to simplify things.

3. The Kettle validates the SUAVE transactions and stores the rollup transaction it received as confidential inputs in its local confidential store. The public part of the SUAVE transaction is gossiped to other Kettles.

4. A SUAVE block is finalized with the SUAVE transaction, and the Kettle executes it against the SUAPP. The SUAPP accesses the rollup transaction from the confidential inputs and passes it to a precompile that sends a bundle back to a Composer instance.

5. POST requests with bundles are received in the Composer, which then serializes bundles and puts them into an Astria transaction to be submitted to the Astria sequencer.

6. The ordered sequencer blocks are posted to the data availability layer, Celestia, similar to the previous path.

Read Path

7. The Conductor receives individual blocks and filters these to get only the data for its particular rollup’s namespace.

8. Filtered blocks are passed to the rollup node via Astria’s Execution API.

9. The rollup deserializes the transactions it receives into either SUAVE bundles or regular transactions.

10. The rollup node verifies the Kettle signatures accompanying all the SUAVE bundles.

11. The rollup then executes transactions from SUAVE bundles first and regular transactions afterwards, resulting in the updated rollup state.

Use Case & Examples

SUAPP-generated Top of Block

As described in the implementation above, this construction allows rollup developers to incorporate a SUAVE-driven Top of Block Auction into their protocol design.
This is implemented by adding additional middleware to the Execution API server in the rollup node (Geth) that does the following:

1. Filter out the SUAVE bundles from the rest of the transactions
2. Validate Kettle operator signatures for each bundle
3. Unbundle the transactions from inside the SUAVE bundles and prepend them in order to the non-SUAVE transactions

Afterwards, we end up with a block ordering that can be succinctly described as (Bundle_0, ..., Bundle_k, Transaction_0, ... Transaction_n), where each bundle is then unbundled into the constituent transactions.

Importantly, this ordering is deterministcally derived from the order finalized by the sequencer.

OVAL-style DeFi mechanisms

Uma’s OVAL allows protocols to manage the value leaked by oracle-related actions.
Specifically, liquidations in lending markets typically follow an oracle price update which adjusts the LTV ratios for all users, leading to newly available liquidations. Currently, this happens entirely out of protocol, leaking value from lenders to searchers and builders.

Oval attaches repayment instructions to the searcher’s bundles that will require any excess value to be repaid back to the protocol. Integrating SUAVE into the shared sequencer allows rollup developers to restrict certain types of transaction flow only to SUAVE bundles. This allows for the design of DeFi mechanisms that internalize this value extraction, reducing the overall value leakage and making DeFi markets more efficient.

[Quintus]

This is super clear

@itamarreif

Alternatively, the user can maintain both rollup and SUAVE wallets and sign and submit directly to SUAVE instead of passing through a rollup node. However, our proof of concept implementation does this from the rollup node to simplify things.

I think this would make sense. AFIU, the approach where the node signs for the user is introducing the rollup node as a trusted actor for all the MEVM calls (circumventing the TEE security). User protection against trusted actors is one of the main benefits of using SUAVE.

• A related point is that a fuller implementation should include a mechanism for selecting a kettle. If there are multiple kettles posting to Astria, there is a problem in which the one posting first reveals information that other agents can take advantage of. We could handle this all internally to SUAVE or devise some mechanism with the rollup. The simplest course of action would be implementing PBS with Astria’s ssequencer as the proposer but this puts complexity of verifying TEE signatures and selecting a block on Astria’s sequencer. Execution tickets also fit in. The design space is large and we have options

• Another attack vector to mitigate in fuller designs is censorship from the Astria sequencer. Consider, for example, the Astria sequencer claiming to not have received a bundle from SUAVE and then just including mempool transactions. This would channel MEV to the Astria sequencer. One could remove this incentive by the rollup only considering transactions that have been signed by SUAVE, but this would reduce the censorship resistance of the rollup overall (now both SUAVE and the Astria sequencer can censor).

[itamarreif]

Agree with both points you made, @Quintus. A few thoughts:

1. Having the rollup node submit transactions to the SUAPP on behalf of users was just a matter of that being the simplest to implement. Some other options that would be interesting to explore:

   • A user submits directly to the SUAPP and a searcher generates bundles by interacting with the SUAPP (“matchmaker SUAPP”).
   • The rollup requires its entire block to be a single SUAVE bundle (i.e. only process the first that it reads from the DA layer) and use the SUAPP as a “rollup-owned builder”. Users can then submit directly to the SUAPP and the SUAPP would submit the entire block to the shared sequencer when it is programmed to do so. We were originally going to implement this but ended up not doing so because this was simpler to implement.
   • A centralized rollup operator that users submit transactions to but uses a TEE coprocessor to provide a guarantee about the order in which transactions are included, e.g. a CEX or NFT marketplace that wants to leverage decentralized infrastructure to provide credible service guarantees to users.

2. Implementing a PBS-style setup where SUAVE acts as a builder that posts to a relay and Astria’s network provides proposers, then Astria’s consensus validates the Kettle signature seems like one of the obvious ways forward with something like this. This was also something I considered during the initial design process and have some thoughts on how an implementation would work. Would love to chat and explore this further.

3. My mental model for getting this PoC together was working with a single Kettle. The main reason being that I found the SUAPP design to be integral for anything more complicated than a simple passthrough example. I was aiming for creating the simplest possible SUAPP since, to be honest, I’m not the best Solidity dev and the goal was mainly to provide an example for others to build on. There are a few “common pitfalls” I’ve run into while putting this together that one would need to be aware of in order to turn this into a sufficiently decentralized & incentive robust design. The intention is to put together another document on these after I finish with the PoC implementation. Off the top of my head:

   • Bundle arrival order can be different than bundle creation order due to network behavior.
   • It seems useful to have a mechanism for ensuring a bundle was created by a specific SUAPP
   • The confidential state stored in each Kettle is different, which can impact the bundles created by a SUAPP.
     These are certainly solvable, but slightly out of scope of a proof of concept.

[CTra1n]

@Quintus

Another attack vector to mitigate in fuller designs is censorship from the Astria sequencer. Consider, for example, the Astria sequencer claiming to not have received a bundle from SUAVE and then just including mempool transactions. This would channel MEV to the Astria sequencer. One could remove this incentive by the rollup only considering transactions that have been signed by SUAVE, but this would reduce the censorship resistance of the rollup overall (now both SUAVE and the Astria sequencer can censor).

This is definitely a vector that needs to be considered in detail. Here are some thoughts on how we could approach it.

A key requirement of the design is for SUAVE transactions to be included before any mempool transactions if the Astria proposer agrees to the protocol. Therefore, if the Astria proposer commits to including the SUAVE ToB bundle, no normal mempool transactions can be included without the ToB bundle. For this to be effective, the Astria proposer can’t be allowed to see the state before committing to it, as in MEV-Boost. Ideally we would have a DA layer in the middle here to act as the relayer does in MEV-Boost and/or settle any disputes on timing. 2 paths towards this would be:

• Having (multiple) independent Kettles (not just the sequencing Kettle) perform the PBS relay role. This way, if all kettles are not colluding, we can identify any misbehaviour from the SUAVE seqeuncer kettle as sending to the relays can be recorded by the SUAVE chain. If we force relay requests to be processed by all of the relays (through a SUAVE-chain majority validator signatue), the Astria proposer can either:
  -Not send a relay request to the relays, but not learn anything about the block.
  -Send a relay request and have the the SUAVE ToB bundle broadcast to the Astria network (unless all Kettles are censoring).
• Leverage a trusted Celestia to ensure timely delivery of the SUAVE ToB bundles. If Celestia doesn’t see the SUAVE transactions, can we be sure that they weren’t provided? Probably. Moreover, if SUAVE produced bundles for Astria must be provided in sequence and one is missing, we can fallback to the Astria-only path after some cutoff time. Questions that remain there:
  -Can Celestia be trusted for censorship resistance?
  -Can Celestia produce blocks fast enough? This doesn’t seem like an issue when the Astria sequencer is lazy and just producing bytes.

There are other questions here about how reliable/synced are the clocks across all 3 domains, but at the very least, it sounds like Astria and Celestia will have some shared concept of time.

[Hasu]

“Astria can censor SUAVE txns to internalize MEV”

Is this actually a concern? It seems to me that Astria validators shouldn’t be able to make more money from MEV by making their own blocks than they are already paid by the SUAVE builder layer.

Similar to how on L1, a proposer can theoretically produce their own blocks (and censor searchers), it’s just never in their incentive to do so.

Maybe I’m making some assumptions that I shouldn’t make, e.g. Astria validators select the most competitive block from a market of blocks inside SUAVE.

[Hasu]

Is it fair to say both rollup node + Astria validators are trusted parties right now? The former can see the user’s txn unencrypted; the latter can see the SUAVE bundle unencrypted.

I’d be curious what you think of a simple flow like this:

1. Users send txns to SUAVE. There is no rollup mempool at all. SUAVE acts as the rollup’s encrypted + programmable mempool
2. SUAVE builds the best block from txns. This can include SUAPPs like mev-share.
3. Astria sources the block from SUAVE and appends it to the meta-block, e.g. using a mechanism like PBS.

Benefits

• removing the trust assumptions in rollup + Astria validators
• entire rollup block – not only individual txns – is built in mev-optimal way:
  • user protection: txns are fully encrypted until confirmed on-chain
  • efficient blocks: no spam/reverts/latency wars
  • more revenue: MEV is fully internalized to Astria, from where it can be shared w/ rollup

What’s needed from status quo:

• PBS-like mechanism between SUAVE <> Astria
• simple decentralized block building in SUAVE – e.g. kettle-based builder

[CTra1n]

Perhaps unrelated to what you are suggesting, but if SUAVE is competing with other builders/relayers in an MEV-Boost style system for the ToB piece, then I would say we aren’t concerned about SUAVE misbehaviour. Censorship from SUAVE can be easily circumvented.

However, it seems like the Astria proposal wants to enshrine the role of SUAVE, so I’ll focus on that paradigm.

Protocol-enforcing blocks to come from SUAVE, unless done carefully, could centralize the sequencer, which seems to be something Astria are working away from with the decentralization talk. However, following @Hasu’s train of thought regarding trust in the Astria validators, SUAVE could offer a (significant) incentive to Astria proposers to delegate block production ahead of time, and for SUAVE to then gain the proposal key for opted-in proposer slots. Maybe even something like Execution Tickets to provide a validator-controlled gateway for external builders to become proposers.

This would allow the Astria consensus protocol to rotate proposers upon failure, keep SUAVE out-of-protocol if/when needed, yet give Astria <> SUAVE all of the block building benefits in the optimistic case.

Can this be done in SUAVE? SUAVE committing to pay the proposers a higher expected revenue from block building should work, and wouldn’t technically require SUAVE as an entity to front capital. Otherwise in the Execution tickets scenario, we probably need individual kettles to participate on behalf of SUAVE.

[gets]

This is similar to how we envision this working with the Espresso Sequencer. We are incorporating something akin to execution tickets, and potentially also an enshrined JIT PBS mechanism. Ideally SUAVE (or kettles) need to then bid in the auction to win sequencing rights for some subset of rollups in some fixed slot.

[Quintus]

@CTra1n

A key requirement of the design is for SUAVE transactions to be included before any mempool transactions if the Astria proposer agrees to the protocol. Therefore, if the Astria proposer commits to including the SUAVE ToB bundle, no normal mempool transactions can be included without the ToB bundle

this is a good idea

@CTra1n

-Can Celestia produce blocks fast enough? This doesn’t seem like an issue when the Astria sequencer is lazy and just producing bytes.

I do think this is an issue. The “laziness” doesn’t refer to block time, which I think everyone would like to be as quick as possible. I think the redundant relay path seems better of the two you proposed.

@Hasu

Similar to how on L1, a proposer can theoretically produce their own blocks (and censor searchers), it’s just never in their incentive to do so.

Fair point

@CTra1n

Perhaps unrelated to what you are suggesting, but if SUAVE is competing with other builders/relayers in an MEV-Boost style system for the ToB piece, then I would say we aren’t concerned about SUAVE misbehaviour. Censorship from SUAVE can be easily circumvented.

Irrespective of who the builders are, I think the goal should be to source blocks in a way that makes it hard/unlikely for a misbehaving party to cause a missed slot.

[Adi]

Super interesting work!

@itamarreif

SUAPP-generated Top of Block

…
This is implemented by adding additional middleware to the Execution API server in the rollup node (Geth) that does the following …

I wonder if this design is not necessarily SUAVE-specific. I’m probably missing something, but could an alternative simple ToB auction work as follows? – the user wallet <> Rollup node interaction is modified to account for top of block auction bundles, and then the same middleware mentioned in the OP orders the auctions deterministically and unbundles the transactions therein before passing them for execution. This provides no confidentiality guarantees, it’s just a basic auction mechanism. If it’s done in-protocol (reminds me of Skip’s protocol-owner builder).

Separately, I’d be curious to know what are the guarantees offered for cross-rollup bundles (with or without SUAVE MEV protection), but I understand if this is out of scope for the moment.