# Suavoma

## Resources
* **Abstract Suave** - SUAVE is a permissionless credible commitment device (PCCD) that program and privately settle higher-order commitments for other PCCDs. It should look like a faster blocktime version of Ethereum but with SGX to ensure private mempool
* **Concrete Suave** - SUAVE is designed to decentralize the MEV supply chain by enabling centralized infrastructure (builders, relays, centralized RFQ routing, etc.) to be programmed as smart contracts on a decentralized blockchain.
* **Endgame Suave** - Suave is designed to be the Mempool and Blockbuilder for all blockchains

***Note that Abstract and Concrete is not Flashbots teminology. I am boring here for understanding, consistency with our specs, and information disseminartion*

### Abstratc Suave
* [Xyn Spec](https://hackmd.io/@sxysun/suavespec)
* [The Future of MEV is SUAVE](https://writings.flashbots.net/the-future-of-mev-is-suave)
* [Devcon Talk](https://youtu.be/ACXAzLy3iWY)
* [Apriori slide deck](https://github.com/0xapriori/Suave-research/blob/main/mmFood.pdf)
* [Suave, Anoma, Shared Sequencers, and Super Builders](https://dba.mirror.xyz/NTg5FSq1o_YiL_KJrKBOsOkyeiNUPobvZUrLBGceagg)

### Concrete Suave
* [Suave-Geth repo](https://github.com/flashbots/suave-geth)
* [Suave.Salon EthCC](https://drive.google.com/file/d/14KD40UV5yQwesnCEkDxd24Bb9tZMrHse/view?pli=1)
* [Code Demo](https://drive.google.com/file/d/1IHuLtxwjRvRpYjMG3oRuAgS5MUZtmAXq/view)
* [SUAVE smart contract programming model: TEE-based smart contracts for block building - Andrew Miller](https://www.youtube.com/watch?v=DhsDFKnHPa0)
* [Slides](https://t.co/xW4KthwFk8)
* [The MEVM, SUAVE Centauri, and Beyond](https://writings.flashbots.net/mevm-suave-centauri-and-beyond)
* [Quintus Q&A](https://twitter.com/0xQuintus/status/1679590263067492353?s=20)
* [Modular Summit - Robert Miller](https://www.youtube.com/watch?v=WYH7n4M016A)
* [MEV in Modular World - Bell curve podcast](https://blockworks.co/podcast/bellcurve/8abf40ae-de03-11ed-bafe-f7f4165ccafd)
* [MEV-Share: programmably private orderflow to share MEV with users](https://collective.flashbots.net/t/mev-share-programmably-private-orderflow-to-share-mev-with-users/1264)
* [Announcing MEV-share beta](https://collective.flashbots.net/t/announcing-mev-share-beta/1650)
* [Block Building Inside SGX](https://writings.flashbots.net/block-building-inside-sgx)
* [Convo on FB Forum Hasu, Elijah, Nikete, apriori](https://collective.flashbots.net/t/concerns-with-suaves-effect-on-ethereum-security-and-total-value-extracted/1035/10
)

### Literature
* [CredibleCommitments.wtf](Crediblecommitments.wtf)
* [MEV & Credible Commitments](https://docs.google.com/presentation/d/1BhPNVYzIVkpiQ9dKUqBhPYY7z04tchmlcfhwf5FaWvw/edit#slide=id.g187ff1cf8c1_0_459)
* [Ethereum is game-changing technology, literally](https://medium.com/@virgilgr/ethereum-is-game-changing-technology-literally-d67e01a01cf8)
* [Game theory on the blockchain: a model for games with smart contracts](https://arxiv.org/pdf/2107.04393.pdf)
* [Disarmament Games](https://www.cs.cmu.edu/~conitzer/disarmamentAAAI17.pdf)
* [Computing the Optimal Strategy to Commit to](https://www.cs.cmu.edu/~sandholm/Computing%20commitment%20strategy.ec06.pdf)
* [Reasoning about Knowledge](https://www.cs.rice.edu/~vardi/papers/book.pdf)
* [Program Equllibrium](https://sci-hub.st/https://doi.org/10.1016/j.geb.2004.02.002)
* [Introduction to Multi-Agent Systems](https://sci-hub.st/10.1007/978-3-642-14435-6_1)
* [On Imperfect Recall in Multi-Agent Influence Diagrams](https://arxiv.org/pdf/2307.05059.pdf)
* [TEE/SGX Wiki](https://collective.flashbots.net/t/tee-sgx-wiki/2019)

## Notes on Spec

Suave is a market place for MEV solutions. Similar how users send their transactions to flashbots rpc endpoint to access the flashbots builder and MEV-Share devices, a user would instead have more choices. The advantage to this is it allows for decentralized MEV solutions as applications on SUAVE. In this way Suave acts as a global mempool and blockbuilder for Ethereum, rollups, and in the future all blockchains. 



For context there exist many competing MEV markets/devices today. All of these devices require users to make trust assumptions about the operators. These can include; 


* Order Flow auctions

* Block space markets

* Private mempools 

* Cowswap
* Penumbra
* Solver APIs 



With SUAVE these devices can be instantiated as smart contracts within Suave Chain's version of the EVM. Flashbots calls this the MEVM which is the EVM with custom precompiles for various MEV related actions. (need specifics here). 


### Summary

* SUAVE maintains a global state, which consists of accounts. There are two types of accounts: Externally Owned Accounts (EOAs) and Contract Accounts. EOAs are controlled by private keys, while Contract Accounts are controlled by the code they contain. The state is stored in a Merkle Patricia Trie.
* Transactions are the means to transfer value and data between accounts. They contain fields like nonce, gas price, gas limit, recipient, value, data, and signature. Transactions are signed by the sender and submitted to the network.
* SUAVE transactions are private. SUAVE transactions are meant to act as higher-order commitments to other domains such as Ethereum.
* Preference-gas is a measure of computational resources in SUAVE. Every transaction has an associated preference-gas cost. Users pay for preference-gas with Ether when executing transactions or smart contracts. SUAVE validators receive the fees as a reward for validating and including transactions in SUAVE blocks.
* SUAVE’s blockchain is an ordered sequence of blocks. Blocks contain a header and a list of transactions. The block header contains fields like parent hash, beneficiary, state root, transactions root, receipts root, logs bloom, difficulty, number, gas limit, gas used, timestamp, extra data, mix hash, and nonce.
* SUAVE uses some consensus algorithm to agree on the state of the network.
* SUAVE smart contracts are self-executing contracts with the terms of the agreement directly written into code. SUAVE uses the Ethereum Virtual Machine (EVM), a Turing-complete virtual machine.
* Smart contracts on SUAVE should be higher-order commitment constructors (MEV-time applications) for domains like Ethereum. The semantics of those higher-order commitments should also be either smart contracts on SUAVE or higher-order commitments themselves.
* The SUAVE state is updated after each transaction or contract execution. The state consists of account balances, nonces, and contract storage. State transitions follow specific rules, which determine how accounts and storage are updated.
* SUAVE state include settled higher-order commitments for other domains, i.e., the resolved propositional commitments (e.g., a transaction on Ethereum).
* SUAVE relies on a peer-to-peer network for communication and synchronization. Nodes use protocols like devp2p or libp2p to discover and connect to peers, share transactions, and synchronize blockchain data.
* SUAVE nodes expose a JSON-RPC API for interacting with the network. This API allows querying the blockchain, sending transactions, managing accounts, and subscribing to events.

## Older Notes & Comments on Spec

**1.** Overall, the strategic uncertainty MEV of SUAVE originates from people's uncoordinated use of SUAVE's commitment constructors. And those commitments are either about higher order commitments of MEV games on other domains, or commitments of games on top of SUAVE.
**2.** We would expect most of non-SUAVE MEV comes from strategic uncertainty, which SUAVE solves almost completely (per the reasoning above, folk theorem of higher order commitments and the competition between mechanism designers to build better commitment constructors/focal points), while the MEV coming from fundamental uncertainty doesn’t decrease much from lower latency of PCCDs.
**3.** In reality, fundamental uncertainties are not purely random walks, and previledged actors with information/capital advantage can still extract huge MEV. For example, insider information like knowledge of price impacting trades or whitehat hacks are innately discrete events that can never be hedged. More generally, for any kind of fundamental uncertainty that have discrete impacts, the commitment game will devolve into latency races or centralization to private SUAVE relays. The quantification of the relative percentage of this kind of MEV is still an open problem.
**4.** Higher-order commitments eliminates strategic/information uncertainty for a given fundamental uncertainty level, and it mitigates the Stackelberg leader (latency race) effect greatly if the level of fundamental uncertainty can be reduced. In fact, with lower expressivity in the commitment constructors, the strategic uncertainties just become fundamental uncertainties due to the inability to predicate/determine on the strategy space or the game structure.

**Example of higher order commitment**

(* allowing higher-order commitments to condition on real-time binance price *)
Inductive Commitment := 
| mkCommit: Commitment -> Oracles -> Commitment.

(* oracles provide additional information for *)
Inductive Oracles :=
| binancePrice: rational -> Oracles
| NYSEPrice: rational -> Oracles.

## Comments
**2.** The literature provides helpful context, but SUAVE doesn't solve strategic uncertainty, neither does Anoma - the most a discrete system can do is reduce strategic uncertainty to an oracle problem. For example, in mutually-assured destruction, with credible commitments (suppose that they were binding to actually controlling nuke launches) you can commit to a strategy, but there's still uncertainty in whether the commitments actually reflect the reality (i.e. whether you don't have some secret nuke which isn't tracked in the system). Participants would still have strategic uncertainty in correspondence to how sure they are that the stated correspondence between the discrete digital representations, commitment constructors, etc. actually represents the real-world actions which they care about. Maybe this counts as "fundamental uncertainty" but it seems to me like a distinct category from what the spec discusses under that term.
**3.** Yeah, I'm not sure where this "asset price is random walk" theory comes from, I don't see any reason to expect that to be true. Future expected trajectories of asset prices are basically a world modelling problem - e.g. if there is an asset which reflects the price of storing a ton of carbon, w.r.t. gold (say) I would expect this to go down in the next few decades as the technology improves (and probably most people would), it's certainly not random. Probably there are some interesting directions in modelling fundamental uncertainty as a causal structure inference problem or something like this.
**4.** Agree that higher-order commitments are necessary, though I think it's better to avoid the recursive type constructor definitions (as the talk mentioned). I think coordinating to avoid latency races is a very important topic which the SUAVE design provides a thoroughly unsatisfying answer to, they've just gone another step forward in the latency race, someone can just make a "SUAVE 2" with fewer validators and even lower latency. This is part of why I think the "slow game" problem & consensus between users is important.

## Notes on Andrew Miller presentation

* Secret network is a bit like Suave. It only has one mempool and its a private mempool because all of the transactions in secret network are encrypted and the only way secret network transactions get into a block is by tendermint validators putting them in order but you can't do anything with the ciphertext until the block is already finalized and then you only get to execute them in the next vblock.

Secret network is already like suave in that they have uniswap v2 clone which automatically has forntrunning resistance becasue of that built in blind ordering that is applied to every transaction sent through Secret Network. Sienna swap eliminates the nearest possibility of front running, and they have replay prevention that is sort of accurate

Before

That aloe does not solve the whole problem you want to solve because if you just have the fair ordering then you have messy arbitrage which comes later; e.g., unsophisticated trades create mess someone must clean up. Messy arbitrage opportunities is the result of shitty user trades where the user trades on one pool but most of the liquidity is fragmented across other pools so the user gets a terrible price.

After

You only see the result of the trade after the block is finalized in time for the beginning of the process of the next block. Next A PGA happens rhen because whoever can get a transaction at the top of block gets to take all of the arbitrage opportunity restoring the balance of the pools and the searcher gets to pocket that arbitrage differnce.

Suave

How this could be done in a more trust-minimized way is MEV-share does today as in secret network in that your transaction is private until it gets settled. With mev-share backrunners get to bid on placing their tx after your's in the same block but when bidding they have to share the larger percentage of the arbitrage they take back with the original user. At a technical level it is implemented as extract and redistribute. Prefer to think of it as your getting a competitive auction to arbitragers for a commission for them to do the backrunning for you automatically upgrading your shitty transaction into a more sophisticated arbitrage free transaction that results.

What is Suave as compared to what exists today?

1. Replace trust in the operator with trust in TEEs, This could be combined and/or replaced cryptography and threshold MPC
2. Make the operation of the service decentralized, geographically and administratively - many different nodes not controlled by Flashbots, lower trust environments
3. User programmable, based on smart contracts. An open, contestable, marketplace for mechanisms - if you don't like the way Mev-share distributes the rules you can just fork the mev-share smart contract and replace it with a different rule. No one can stop you from uploading a different sc to suave. If you can convince users to send their txs to that one instead no one can stop them from picking your contract if they want. Thats what it means to be contestable. This is what makes it an open marketplace because flashbots doesn't have to come up with the perfect auction structure, smart contract developers can do so.

A starting point of what this could look like is replicating whats in the ecosystem today. Make MEV-share auction, Mev-share matchmaker a backrun smart contract. Make the flashbots builder a blockbuilding contract, etc.

With Suave Market for mechanisms based on Smart Contracts, we have transparency, user empowerment. Competing contracts can fulfill user orders. Contracts require a privacy oriented programming model.

Suave's strategy was anticipated by StrategyProof Computing from the NG, Parks, Seltzer 03. It sounds like a modern description of Suave. It didn't forsee smart conracts and it isn't aimed at the preventing private negotiation aspect its jsut concerned about the efficiency of maarket mechanisms. But it says all of the impossibility result of perfect auctions that there is not going to be a perfect mechanism so what this advocates for is you should have an open system where anyone can propose innovative new market design components which are compositional and can interact with each other in that way market designers can innovate on parts of this and you can have an ecosystem of gradually improving market mechanisms. SCs is the only tool for open composition and innovation we have seen so that is kind of a natural fit. They only focus on performance and efficiiency of the market and didn't go into the doomer thesis; If you don't have this open contestable marketplace where the market designs are public smart contracts you can look at analyze and fork. Then the market dominator may become entrwenched through private negotiated bulk deals at which point it becomes impossible to dislodge them.

* Suave aims to fulfill this vision of Strategy proof computing, in having an open marketplace for mechanisms.... even just for these blockspace/orderflow auctions
* Emphasis on "openness"...Suave ensures market innovation occurs in the open, through published smart contracts... rather than in private arenas with deep moats.

> The SPC infrastructure must provide suport for multiple users to design and deploy competing LSP mechanisms, in amarket for mechanisms. With this, we achieve the second set of design principles of open and decentralized systems. Our belief is that an open marketplace will naturally lead to mechanisms with the "right scope" and the "right complexity." This decision rpresents a tradeoff b/w providing a large enough scope to suggiciently simplify the game-theoretic decision facing a participant - for example, bringing resources that are complementary for a large number of users into the same scope- while maintaing a small enough scope to build computationlly reasonable resource allocation mechanisms. The degree of which market forces lead to the emergence of mechanisms with the right scope is an important research question.

Suave as an Ideal Functionality
* In cryptography we use ideal functionalities to make a specification. If you skip the TEEs and decentralization and you did a trusted smart contract with a central third party it would look like this. For cryptographers this is understood as a security definition that describes the interface.
* The interface is that there is a service which has smart contracts and private data storage on it. Just like secret network. The different kind of interfaces are market design innovators can make new contracts and push them onto the chain. Users can interact with the smart contract and there is still room for searchers/arbitragers who get explicit hints like mev-share hints or anything they can infer from side channels that are captured in the specification and they can invoke their own sc txs and input arbitrage inputs and so on. The imporitant thing is that this outputs an L1 block to Ethereum.

Suave Architecture

There are Scs on suave. There is a suave chain. There is a mempool of pending suave bids as well as bids that are finalized being in a chain. Being committed in suave chain doesn't mean the bid is satisfied yet it means its sequenced and has DA and you cannot ignore it on the suave chain. Not all of the execution happens on suave chain that suggests linear bottleneck and latency bottlenecking. The point is we will have off-suave chain execution. Rollup of a rollup or Sidechain of a sidechain. The execution is off-chain of suave chain but still carried out in trusted hardware enclaves by executors we call TEE kettles. So they can have access through their kettles to the confidential data but only according to the rules of the smart contracts as defined. Each smart contract defines the program rules for interacting with that contract's private data

There is some mempool of pending Suave bids. Suave blocks probably come much faster than L1 blocks, but not infinately fast. The thing that will make this realistically performant is being able to do concurrent execution by lots of different enclave nodes multiple cores on each enclave. Each one may be doing some simulation. Weather you can do simulation or not is up to the contract rules to define. In secret network it used to be that they allowed open simulation. So you can simulate transactions even before they are finalized in a block. So you can simulate a front-run, the victim, and a backrun. If it succeeded you can increase the front run and try again. This way you can do the MEV on secret network. Now you can only execute them after the block is finalized. It would be useful if smart contrcat authors could approve some functions to be done with local simulation. It just gives more flexibility to the Suave app designers.

The is a spectrum

## Potential outline for article

### Abstract Suave

Begin with describing the Problem that Suave is trying to solve - Coordination Problems, a committment device for committment devices. Trying to solve this problem for Ethereum and rollups in particular.

Here we may want to briefly explain MEV and discuss MEV given to Molach as a coordination failure. Briefly bring in Slae Star Codex on Molach -> then Explain Molach Extractable value by bringing in 3EV framework which concludes that Monarch Extractable value and programmable privacy are the only welfare maximizing ways to solve these coordination problems.

Introduce some of the credible commitment literature.

### Concrete Suave
Lean in on the Andrew Miller and Robert Miller presentations for the details of what this looks like e.g.; explain current architecture and TEE Builders. Ask for feedback on this specifically from Quintus and Andrew.

### Endgame Suave

Discuss the vision outlined in the intial proposal and project it into the future. What does the world with Suave look like? What are the drawbacks? Is the path to Endgame reasonable or corect; e.g., MEV-Share?

Present Suave 2 anecdote and also introduce the concept of the slow game.

### Mid curve thoughts
:::info
Key question I have is how can Suave make credible commitments about domains which have shorter block times than SUAVE? It seems SUAVE would need to be as fast as Solana if not faster in order to make gaurantees about arbitrage opportunities on chain for example.

This Begs the question of why should SUAVE exist then in the first place if Solana can act as a Sequencer for all other blockchains. It has the DA Througput, 400ms blocktimes, plan for multiple leaders, formalized PBS, and Diet clients with fraud proofs, perhaps SNARKed state proofs in the future.

This makes sense for a couple practical reasons. First, Solana presents itself as one of the few blockchains that is postiioned for speed of light blocktimes or 250MS. This would be attractive to Market makers to make on chain knowing they can update their quotes more frequently than 12s- CLOBs are now possible. As a side benefit for AMMs, this reduces the LVR of for passive LPs as well. With professional market makers attracted to making on chain then they could serve as a fallback for filling partial orders not covered by an RFQ or to augment a partial fill on a different domain.

:::

## Notes from Bell Curve Podcast on Modular MEV

### Fast Block times

>JC: As far as expressing preferences arbitrage I see and I want certain transactions to close this arb on another chain. If going through this process requires me to express a preference on Suave chain to commounicate this is what I want done. This implies you are bounded by the Suave chain blocktimes. If another chain I want to express a preference for has a realy fast blocktime and maybe that opportunity is going to disappear that means SUave chain would need a fast block time to express that preference in the first place. Does that kind of pressure just lead to having low blocktimes, incentivize Suave chain to have super low blocktimes and have the race to centralization there?

>RM: I think it is a little different on Suave chain because we are really only posting data about other chains and settling payments. So I think in some ways it is less important than other domains. You raise a good point, I do think that Suave's blocktimes will have to be faster and should be faster than other domains. On the other hand I thoink there are ways to craft your preferences up front that don't require you to communicate them in real-time. As an example, you could offer to an executor on a domain that's really fast, hey if you spam my contract and it emits a log that says success I'm willing to pay you some amount. That gives an incentive up front for an executor to be spaming your contract at the precise moment it needs to be without you needing to communicate that at the moment it needs to, it will just spam your contract apriori. I think you can probably do similar things with latency in that way. There are upfront ways to communicate your preferences to prime executors working on lower blocktimes.

>Hasu: I would also point out that you can think of Suave almost as a board where basically anyone can submit their transaction execution requests. Once you make such a request and its floating in the Suave mempool then the request is basically out there. And anyone who goes and executes it they can then come and claim their payment later on after the transaction was executed. They need to execute it then an Oracle reports a state change from the domain then the payment can be unlocked from the target chain. SO that means the settlement is not bound to the blocktime of the target chain. The settlement can happen anytime later. Thats why in my opinion Suave Blocktimes do not need to be lower than any participating chains because its okay for executors to claim their payment with a little bit of delay because they know the payment is trustless.

>JC: The settlement after the fact wasn't the part I was getting at. If it requires a tx on Suave chain to communicate that preference in the first place, if that blocktime is longer than the domain I want to express that preference for I won't be able to express that preference in time.

>Hasu: I believe you can communicate all your preferences just through pre-signed transactions they do not actually need to be mined in Suave chain in order ot be commitments.

>RM: That does work. We do have a notion of a special transaction in Suave that will carry your signed commitments if you want to throw it in the Suave mempool which is what you want if you want the maximum number of executors to access your transaction, if you want it to be censorship resistant. If you want to skip all of that and really save on latency you could communicate it directly with executors jsut with this signature model. I do think your touching on something which you can't really get around because of the laws of physics that there will be some cross-domain MEV which is not possible to extract because of latency. There is some kind of pressure like there is today from latency in cross-domain extraction on domains that are centralized and have faster blocktimes too. I think thats inherent to cross-domain MEV, I don't know that we can do anything about that. This is a reason for us as a community to align on real decentralization.

### Why do you need a Suave chain?

- Need for a chain to transmit preferences efficiently: low cost and DoS resistant
- Imposing a fee during network congestion by including preferences on-chain deters attackers
- Suave's design allows low-cost expression of preferences without congestion, requiring the chain to introduce a new transaction type
- Owning the full stack allows for faster iteration on design parameters and tailored optimizations
- Suave may need a faster block time than Ethereum L1, achievable on the Suave chain
- Considered making Suave chain a rollup to access L1 data trustlessly, avoiding the need for oracles with trust assumptions
- Replacing GETH's existing mempool with one optimized for faster communication enhances Suave's domain specificity for MEV
- Neutrality: As Suave expands beyond Ethereum, it should be a neutral layer with ownership and participation crafted from different domains
- Designing for political neutrality can foster adoption, as existing Ethereum ownership might not appeal to other platforms like Cosmos or Solana

>JC: Why do you need a chain in certain cases to express these preferences and settle them after the fact as opposed to having this more p2p layer part of Suave where I can communicate my intent and if you execute it on the other chain you get paid on the other chain. Why do we need to go through this process of communicating that through Suave and having this Oracle problem to go back and settle that payment after the fact. Why can't we have this more global p2p layer and settle on those chains themselves where I'll give you a payment if you get my thing done?

>RM: Its a good question. The tl;dr is why do you need a chain? There are a few reasons. In order to be economically efficient we need some way of transmitting preferences. We think that is both as low cost as possible and Dos resistant. One way to be DoS reisstant is to force attackers to pay a cost if there is spam within the network. With a blockchain we can impose a fee in periods of network congestion by including preferences on chain and this would deter attackers. We have the designed the mechanism within Suave which we think allows as low cost as possible extraction of preferences when there are not periods of congestion and that requires you to chain itself add a new type of transaction. I don't think this is something we can get through ACD today. This allows us to introduce new mechanisms that we think are more economically efficient to express preferences while still having the property of being DoS resistant. A standalone p2p network thats global wouldn't have the same mechanism. At least I havn't seen any design of one so far.

>The second more general thing other than this one specific mechanism for achieving low cost but Dos resistant expression of prefrences is the notion of owning the full stack. By being able to change things on the full stack we can iterate more fast on many different design parameters and make tailored optimizations which would be difficult to retrofit on an existing domain and which you may not want on an existing domain. It probably makes sense for Suave to have a faster block time than Ethereum L1 which is a non-starter on Ethereum L1, but we can offer that on Suave chain. Another example is, We thought of making Suave chain a rollup that is using the derivation function of the rollup in order to get trustless access to L1 data and rollup data and to not need Oracles with trust assumptions or at least use trust assumptions of L1. These are examples of optimizations.

>One final one I'll throw out is replacing the existing mempool within GETH with a different mempool thats optimized for faster communication. These types of optimizations make Suave a better domain and specific for MEV.

>Hasu: The last thing to point out is nuetrality. As Suave moves beyond Ethereum I think there is the question is it fair that all of these preferences get settled on an actual settlement layer or should this be its own standalone nuetral layer that has ownership and participation and so on thats crafted in an entirely bottom up way from these different domains. Part of getting adoption for a system like this is designing for political nuetrality. And maybe the existing ownership of Ethereum may not be optimized in such a way that it gets buy in from Cosmos, Solana, and other centralized exchanges.

## Notes from SUAVE, Anoma, SS, SuperBuilders

>SUAVE can support either desired path. Users and executors can all have their own risk tolerance and interact however they wish. SUAVE can’t provide “technical X-domain atomicity” on its own, but it can provide “economic X-domain atomicity” in this sense from the user perspective (though the executor may get stuck holding the risk).

- Possible that executors specialize in building particular rollup blocks and another executor holds auction for all rollup blocks before sending to shared sequencer
- Who gets the SS MEV? How is this split. What welfare function are you optimizing for?

Solving Comparison: Suave with Anoma . 

User bid -> Suave
Executor -> Optimistic Rollup Block
Executor -> ZK Rollup Block
Executor -> Shared Sequencer Block 
Shared Sequencer (sends block) -> Ethereum Ordering & Consnesus
Ethereum -> Rollup Nodes Execute

User intent -> Anoma
Solver -> pTX
Solver -> pTx
Solver -> Tx (fully balanced) 
TX -> Typhon for Ordering, Consensus, and Execution

Is there a downside to Suave and Shared Sequencer running the same consensus protocol? Is there any upside; e.g., IBC

Suave + Shared sequncer is a bit constraining as you don't have flexibility to do things like Threshold Decryption at the rollup level. Unless ofc you stipulate that all of your rollups blocks must be built in a specific way.

## Diagram


## Shared Sequencing

i have a hypothetical question. Lets assume Suave is shipped and in phase 3 outlined in the writings.

As I understand (from Ben Fisch modular talk) the main selling points of shared sequencer is interoperability:
-simplify x-rollup atomicity/bridging
-Mitigate security risks of bridging
-Support x-rollup building with economic bonding

Espresso is assuming that there will be a super builder who proposes an entire block to the network for all rollups. Without a shared sequencer the super builder has to navigate separate auctions with different rollup sequencers which make any atomicity guarantees hard.

-----

However, If Suave can deliver full rollup blocks to rollup sequencers, what is the benefit of the rollups using a shared sequencer?

- Perhaps there is better welfare maximizing MEV extraction?
- Maybe Network effects - this gains adoption and allows rollups to tap each other for liquidity more easily?

Lets say Suave loses liveness. Then who is feeding the shared sequencer? Do you suspect a competing builder market or would the rollup revert to based rollup or would the shared sequencer then take blocks?

If you assume the shared sequencer will be dumb then you are basically enshrining a PBS structure and a permanently outsourced builder marker.
5m

PEPC-SHS
>**If Validator is SUAVE-aware** - Validator can profit switch `b` against its best known mempool block. SUAVE will have native plugins for this where validators can directly listen to bids and automatically profit switch over bids they’re able to parse and control. Other actors translate these to bids that validators can control.

Does Shared sequencing imply shared governance? for example would the shared sequencer validator set be composed of only rollup "elected" shared

How does espresso monetize? What happens to Shared sequencer governance? Can it be fully Autonomous no upgrade keys etc.? Is that a good or bad idea, why not? Does shared sequencer lead to shared prover?

Given that the "endgame is shared sequencer" then how does that fit wit the games being played on L1; different OFAs, RFQs, Solvers, etc.
It means all the action goes to Suave. Will rolluos work together to achieve some optimal welfare. Can token holders be convinced of this?

### Based Rollups and Decentralized Sequencing Taiko spaces

Lets start with the basics of answering the question what is sequencing? Why do rollups even need sequencing?

Justin: Sequencing very simply is the ordering of transactions within a rollup or any chain. Why do we need sequencing - the reason is that there needs to be some ordering of transactions which are chosen because transactions are not commutative in the sense that if you do tx A then tx B its not the same as doing tx B then tx A. If we want to agree on the state of something given some tx as input its kind of fundamental to be doing this sequencing. It turns out there is a whole spectrum of designs for sequencing. The way that we do it at ethereum layer 1 is we have this notion of a proposer who has monoply rights over this sequncing for 1 slot, 12 seconds and the proposer rotates every slot. Its decentralized from the macro standpoint but at the microstandpoint its hyper-centralized. But there are all other sorts of designs.

Taiko: Thank you Justin Daniel do you have anything to add to what justin Just Said?

Daniel: Not really. I think the same idea applies to Layer 2 except on Layer 2 its a sequencer alot but on L1 we don't really see that much.

I think it might be helpful to clarirfy two things about sequencing because there is
a. the part of agreeing on the sequence and
b. how did that sequence get proposed in the first place and who is providing input on what the ordering should be?

Those are two different but complimentary aspects of Sequencing.

Taiko: What are the differences and the risks when the two sides are not acting in good faith?

Justin: What Ben might be alluding to is that there might be an entity a proposer, technically a sequencer for that one slot and the best they can do is propose a sequencing but then for this ordering of transactions to be finalized or set in stone you need the rest of the network to participate. In the case of Ethereum we are asking attesters to attest for this proposal and to eventually finalize it. It is possible in various situations if there is an attack on the network or very high latency there are some edge cases where these proposed sequencings don't make it on chain and then some other sequencer down the line ends up taking precedence over earlier sequencers potentially if there is a re-org.

Ben: This is amplified even more when you look at PBS where you may have buidlers or a builder makret that has some input into suggesting how ordering should be within a block but they have absolutely no power over deciding what that ordering should be and its up to the proposer to accept or not to accept these suggestion that comes from a builder market. The proposer's proposal doesn't need to be accepted but its more likely to be accepted once it gets proposed because of the enshrined role a proposer plays in consnesus. I think it is good when we talk about sequencing broadly and this is a common point of confusion that leads to debates because people aren't talking about the same thing. Seperate between the way that a sequence gets suggested and the component of the infratsucture that actuallys finalizes the sequence. Those are two distinct and important aspects of sequencing and we should be specefic about which one we are talking about when having a conversation about it.

Tomasz: Thats why when we introduced PBS on Ethereum thats why we less often talk about sequencing in the context we talk about in L2s. In L2s we think about those two roles combined mostly. And the same as we talk about decentralizeation we talk seperation of those roles and responsibilities. These are two very distinct questions to ask. Is it decentralized? Is it seperating the blockbuilding and proposals or participation in potential consensus. And then even more in the context of ZK rollups you start talking about the prover market and it gets a bit more complex.

Justin: I think of the proposers as having the option if they want to to delegate work involved in sequencing to the builders and its a very nice relationship. Its a trustless relationship. Its very similar to ETH stakers who have the option if they want to to delegate the operations of being a staker to some sort of operater. I would argue that the true sequencer in terms of the one thats enshrined and in a position of power is the proposer because of the L1 in the same way the ETH staker the one that provides the ETH should be in a position of power, not the operater of the Validators.

Ben: Yes I would agree with that characterization

Taiko: In the context of rollups most of them have a centralized sequencer although this has been changing lately with more and more rollups announcing decentralized sequencer protocols. I think Arbitrum and Aztec just launched something like this. But there is still debates on weather decentralizing the sequencer is important. Ive read some opinions lately that say it shouldn't be at the top of the priority-list for rollups. Some say that having escape hatches and actual fraud and validity proofs in production and removing multisig control is more important than decentralizing the sequencer. Where would you put the sequencer decentralization question on your priority list. Maybe Ben Let's start with you.

Ben: Escape hatches are a form of decentralizing the sequencing. They are a hybrid, they give you a hybrid between what we may call a based rollup and a centralized rollup because it says that some of the time the sequence can be influenced or determined by the L1. If the centralized sequencer is censoring your transactions then a user can post transactions directly to the L1 that after a delay can get forced included into the order. So its giving some of the sequencing power to the decentralized L1. I think that whenever this question comes up of once you have built an escape hatch do you or do you not need to decentralize the sequencer and how high priority is this? I think it comes down to looking at what are the properties you care about the most? If the property you care about the most is that nobody can be censored forever, then maybe this escape hatch is good enough for you. But if you care about the economics of the rollup more holistically, not having price discrimination, not having monopoly pricing, not giving the sequencer so much control so as to force certain users to go to this more expensive escape thatch route. Then it would be higher priority to address these.

I think that another problem and again this is about levels of priority, but when it comes to security of bridging between different rollups if many rollups are running on their own sequencers and running their own consensus protocols it leads to systemic risks around bridging because now different sides of the bridges need to trust each other unless they are waiting for L1 finality. Which takes much longer. If they are trusting each other for finality on transaction ordering it gives a large opportunity to attackers to profit from equivocating on those orderings. It all comes down to the different priorities within an individual rollups team and we should look at what are the properties that benefit from decentralizing sequencing beyond escape hatches.

Tomasz: I think that often when we talk about decentralization of sequencers sometimes we feel like it means we also talk about permissionlessness of who can be a sequencer and this is not true. Because of this liveness and censorship resistance risks. Liveness being the risk that you simply stop producing blocks on L2 for some period of time. And we've seen that on some dev-nets or test nets or even main-nets of current rollups where they stop producing blocks for some hours. The second censorship resistance not only talking about escaping and removing the assets but also being able to inject transactions. Escape hatches and forced sequencing is inefficient. This is important how we deliver that does not mean you have something similar to Ethereum where anyone can become sequencer. There are many proposals like proof of governance from Jon Charbennau. Those are saying its still a very permissioned set-up maybe permissioned by voting for the same governance mechanics that define many aspects of the social consensus of the layer 2. Its very important to introduce it, how we introduce it and in the context of all the roadmaps of different L2s I think it will be coming at different times and we will see many different hybrid models and different approaches and i think its important to learn about which one of those work best and start arriving at some solution that will be adopted as a gold standard over time.

Justin: I would agree, I think its important to have this decentralized sequencer in the endgame of the roadmap from a pragmatic standpoint there are all sorts of things that can be prioritized. Even today we see some very successful rollups that don't even have fraud proofs or validity proofs and they have prioritized all sorts of other things which have arguably been good moves. When we think about rollups the goal is to inherit the security from L1s. There 2 aspects of security, safety and liveness. Rollups give us almost 100% safety of the L2. Liveness often times there are some subtleties worth fleshing out. If you have this escape hatch which is basically a based rollup with a delay of one hour then you might be inclined to think you have 95 or 95% of the liveness of Ethereum. But actually this little delta in an adversarial environment can be exploited. We've already talked about accidental liveness failures and censorship. When you look at censorship specifically there are some opportunities to create toxic MEV. SO let's say that your rollup has a huge amount of economic activity. If you can censor for example buys or sells of a specific asset on your DEX or you can censor oracle transactions for a whole hour then you are in a huge position of power to create a lot of disruption and toxic mev that can be extracted by the Sequencer.

Another problem with the escape hatch is the idea is its only ever used if the rollup is completely broken. There is this risk that if it does ever get used you break the network effects, because you are basically forcing everyone to take the escape hatch and leave.

## Quintus Interview

### Can you explain the off-chain Kettle nodes?

The Kettle execution nodes are just execution some subset of the contracts in the MEVM. What about that stuff not defined by the MEVM?

Contract interface with these things - use as an interface some input which the contract takes into a function call from the outside world and similarly when you need to expose information to off-chain . You can imagine off chain component has some identifiers that represent some kind of news input that mark full information and based on that order these identifiers and execute a function call which orders these bundles into the block and the TEE can store thee best block of all of those.

- Another way to do is to break the privacy at some point. Just build a block in the standard plain text way

- A less explored avenue would be to directly define the proprietary code as a private contract in MEVM so you are not leaking trade secrets and exit the Kettle.

Don't know if you gain anything with the off-chain interface.

### Why do you need a shared sequencer?

Pushing more complexity to suave and then what suave needs to do is run consensus and have a proposer in suave in which case suave becomes a shared sequencer. From other chain's perspective more value capture comes from suave than shared sequencer

If you establish highest value block you can address with TEEs. Its on the avenue we explored that far down.

The reason that you want TEEs to run most independently as execution nodes is cost saving in gas and latency overhead.

Validity conditions you can do like order by gas price - FCFS you would need a contract that orders things first come first serve

- Feasibility of things being ordered FCFS - assume you can do this or some source of order flow. The challenge is still that if all the arbitrum send their user to fcfc committee who signs off on the ordering and the shared sequencer checks for the signature then its fine but if arbitrum users just send there will be competing blocks proposed so arbitrum shared sequencer will have to query for this rule.

### How does a shared sequencer split revenue amongst rollups?

Splitting revenue is the defining question for infrastructure economics going forward in block chain - many results that tells you, you can't do this in most permissionless generalized setting.

Nikette paper - idk what the answer is imagine will be a simple agreement 30% 40% and thats that and you can encode these in a smart contract

Running a TEE you should in theory have a lot more insight into how the auction evolved bid distribution for this auction bid from that auction but not free from manipulation. The contract must be decided wrt how this TEE receives bids and the consensus someone is checking the payments are checking what TEE signed and it might be feasible to do something that is more complex.

Much MEV will still be just CEX-DEX between multiple DEXs. The real cross chain value comes from the UX of having atomic execution for normal users as opposed to searchers.

### How will RFQ change CEX-DEX arbitrage?

Is the RFQ part of the DEX if you take RFQ fillers not part of the DEX then it will change because LPs will receive less non-toxic flow and less liquidity on chain for the majors eth-usdc. The outcome is there is less liquidity to arbitrage against on chain and SCP or whoever more fillers on Unsiwap

### Uniswap X on suave

Executors and active participants on market do we expect every interacting with order flow to be running a kettle node or do we expect them to interact with n to 1 with many executors querying one node with an rpc expect both to be true and it can make sense for everyone to run a kettle and in terms of economic activity power law distributed will look beaver builder some look like Typhon, aggregate inputs from other TEEs. I think you will see this in a couple of years time sequencers will be much more active in the block building process.

### Future with only based rollups

Big block builder for based rollups.

### More Quintus on CT

I had a few people ask me how SUAVE would ever be able to produce competitive blocks. I think this question comes mostly from the fact that we have explained things mostly from the user angle and not the searcher/builder angle

"How will suave in its final form compete with centralised builders? Isn't TEE computation too slow"

ofc we want to make TEE computation as efficient as possible, but let's say there's still a big delta. SUAVE is designed to be fully programmable which includes

users/searchers choosing what computation happens using contracts vs outside the TEE. In the extreme case, a latency sensitive searcher can send their bundle in plaintext like today
The builder operating the TEE can do normal building in parallel to executing the contracts and

only combine these as a final step to form a full block

A hybrid cases would be:
* aggregator contract which outputs plaintext tx or bundle
* output an encrypted bundle but with info about this bundle (hints) so that out-of-TEE ordering can be done before TEE simulation

The example we show in the post shows block building happening mostly as a contract, but that's just an illustrative example and doesn't show the scope of what's possible

Not sure how much of this made sense. AMA

(note, I wrote this with full suave design in mind not centauri)

I had a few people ask me how SUAVE would ever be able to produce competitive blocks. I think this question comes mostly from the fact that we have explained things mostly from the user angle and not the searcher/builder angle

A few thoughts:

"How will suave in its final form compete with centralised builders? Isn't TEE computation too slow"

ofc we want to make TEE computation as efficient as possible, but let's say there's still a big delta. SUAVE is designed to be fully programmable which includes

users/searchers choosing what computation happens using contracts vs outside the TEE. In the extreme case, a latency sensitive searcher can send their bundle in plaintext like today
The builder operating the TEE can do normal building in parallel to executing the contracts and

only combine these as a final step to form a full block

A hybrid cases would be:
* aggregator contract which outputs plaintext tx or bundle
* output an encrypted bundle but with info about this bundle (hints) so that out-of-TEE ordering can be done before TEE simulation

The example we show in the post shows block building happening mostly as a contract, but that's just an illustrative example and doesn't show the scope of what's possible

Not sure how much of this made sense. AMA

(note, I wrote this with full suave design in mind not centauri)

some context I might've needed to give:
contracts are on suave state and updating global state is more complex and slow

TEE's run off-chain computation according to these contracts, but the computation doesn't need to permute the global state so it's not bottlenecked by consensus

he benefit of TEEs isn't just privacy, its that you can control how your order is being executed w/o TTP

Manta is a good example. We have been toying w some ideas that would make entities like manta sending tx to multiple TEE nodes more appealing. Briefly:

* fresh price data directly in nodes
* privacy can remove need to trust others (granted there is compute efficiency tradeoff here)
* make bundle bidding more appealing than block bidding. Lowest hanging fruit here would be private block auction

Yeah it doesnt have to be price data. Probably will never get to what u can do in house but can get much closer

what do you mean by "permute the global state"

Global state is what there is consensus over and then there’s “local state” which is the view of individual TEEs

Global state is necessary to enforce the rules and then local state is how each TEE has been playing within those rules

Is local state just a local (and thus lighter weight) copy of global state to run simulations on or is local state different from global state?

There are some technical nuances to local state but the analogy would work well with cowswap:

The rules of the auction are global state while the state of the current batch and seen solutions is local state

I would add that “rules of the auction” can have a pretty broad meaning. in the example of Cowswap, one could first commit the encrypted txns to the global state before they can be used in local state to further constrain a solver’s meddling ability to meddle w a batch

Ok so the flow is something like this? :

- global state has the meta-auction rules (how TEE outputs are settled against each other)
- global state also has committed txs that must be included by individual TEE node
- local state is what's held in a TEE node?

Do TEE nodes stake, and get slashed optimistically on "global state" if they misbehave?

Because I'd be confused how you can avoid consensus bottlenecks and enforcement not be optimistic

We can layer on optimistic enforcement (perhaps heterogenously), but TEE guarantees include integrity of computation

## Similarites and complimentary nature of Suave and Anoma

In Anoma we have a notion of partial solving where solvers will match partial transactions until there is a fully balanced transaction which is then sent to Typhon for consensus and execution.
In Suave you may have a notion of bundle merging where executors will merge bundles until there is a competitive block which is then sent to the particular domain. An Ethereum block for example.

Today, builders build entire blocks for Ethereum. In the long-run, SUAVE’s ultimate goal is to have this network of executors building blocks collaboratively, “snowballing” into building a full block. One executor can build a portion of an encrypted block, then another can add on more transactions, and so on. This collaboration is how to get fully DBB.

I'm wondering if the correct analogy is

Partial Solving : Bundle Merging
partial transaction : Bundle
Solver : Executor

As Suave's builder market is an instance of an executor within the executor market, Anoma's partial solving markets are instances of solvers within the solver market.

Both Suave and Anoma aim to offer programmable privacy with cryptography and TEEs.

I think these similarities highlight the key conceptual overlaps between the two projects.

### Compliments

Will be very cool if users could send intents to Suave for particular solver markets. Suave as a solver Dao for Anoma in this way. If the end user product is designed correctly the user won't know or care which solver market they are using as long as their intent gets satisfied

## Privacy

Privacy in the service of two goals

1. Decentralize Flashbots as it is today
2. Allow the user to internalize the value of their MEV (distribute)

## Robert Miller on Suave

### SUAVE architecture with the MEVM

SUAVE - 3 main components
- MEMVM chain - modified EVM chian with special precompiles for MEV use cases
- some of these precompiles call out to an execution Node.
- Execution Node - this is an off-chain node providing
- execution,
- similating transactions,
- merging them together,
- building a block,
- inserting new transactions.
- Its doing this to provide credible and private compute off-chain that you don't want to do on-chain.
- These run in trusted execution environments so that you can still trust the outputs and the results of this compute even though its not all being performed on-chain
- Confidential data store - for private information you don't want to store on-chain which can be accessed by the execution node.


4 main stake holders

- developers who are writing their MEV infrastructure as smart contracts
- users who send private data that they want included on chain and authorizing some contracts saying they accept this auction or block-building contract for their transaction to have access to their private data.
- Executors backrunning, arbitraging, doing MEV things to execute people's bids
- The net result of SUAVE is creating blocks that are included on chain for Ethereum or rollups

Execution Nodes

* Smart contracts define off-chain execution that is performed inside execution nodes
* Execution nodes have access to private data
* Execution nodes run insdie of trusted execution environments to provide privacy and credibility to compute


Commentary:

You have developers who are defining in smart contracts off-chain execution which is performed by the execution node. Your smart contract says take all of these transactions, simulate them and treat them according to this algorithm. That's not actually performed on-chain. Instead all of that is performed in an Execution Node in a TEE like an SGX where you know the code is runnning with some level of privacy and integrity. This is a really scalable way to get private and confidential compute for MEV use cases. The other thing to note is that Execution Nodes if a user permissions a certain smart contract, have access to private data.

### Example MEVM Contract

function EGPBuild (Bundle [] allBundles) external {
// EGP = effective gas price
// Pass #: Estimate EGP of each bundle based on top-of-block sim
SimulatedBundle [] simmedBundles = new SimulatedBundle [] (allBundles. length);
State l1State = getState("EthereumMainnet", "latest") // Get latest mainnet state
for (uint 1 = 0; 1 < allBundles. length; 1++) {
    SimulatedBundle simmedBundle = simulateBundle(L1State, allBundles [i]);
    simmedBundles [i] = simmedBundle;
    
}
    
// Sort the bundles by EGP such that the highest EGP is first
sortBundles (simmedBundles, "effectiveGasPrice");
    
    
Block block;
block.state = l1State;
for (uint 1 = 0; 1 < allBundles. length; i++) {
    Sim simmedBundle = simulatepplyingBundle(block, allBundles [i]);
    
    if (simmedBundle.reverts as false && simmedBundle <= 0.99*simmedBundles[il){
block.txs.push (simmedBundles.txs);
    }
        
}
exportBlock (block);
    
}

Commentary

This is what an MEVM contract looks like. Take for example the Flashbots builder today - FB blockbuilding algorithm written with MEVM. You can see how it has a couple functions you normally don't have within Ethereum
- We are getting Ethereum main-net state on the 5th line, the latest block state
- We are simultating bundles of transactions getting results
- We have a pending block there and we are simulating adding new transactions to it, seeing if they fail and discarding them
- We are exporting the block (2nd to last line) making it available for Ethereum proposers to include it on chain if they request it from SUAVE

These are the super powers the MEVM gives you that you don't have available on Ethereum. This is jsut one example.

### Other potential MEVM contracts
- New building algorithms
- Pre-confirmations
- UniswapX
- CowSwap
- MEV-Share
- Distirbuted building
- Composing the above
- ...etc

Commentary

Any off-chain MEVM infrastructure we have the ambition of being able to support within the MEVM.

### Suave as a Market
- Suave is a decentralized platfrom for MEV applications
- Suave will drastically lower the barrier to experimenting in the block building market and open access to orderflow in particular
- MEV applications compete and compose together in an open market for innovation, resulting in better outcomes for users and betetr blocks for validators

Having low barriers for people to deploy their own MEV infrastructure in this environment. Have these different applciations compose together into something that is larger. This is not a monolithic flashbots builder that we are decentralizing. Instead this is a platform where anyone can deply their own applications and all of these can compete and compsoe togetherin this open market. We thing ultimately this positivie sum platform vision will result in better blocks for validators.

### Other domains and SUAVE

This isn't supposed to be made just for Ethereum but instead a platform to be building blocks for many chains. You can have execution nodes running, EVM, WASM, or any VM you want. The integration is relatively straight forward so long as your chain has some way to listen to Suave for blocks.

We landed our first block on Goerli test net a couple of days ago.


### Roadmap

Suave Centauri

My thoughts: MEV-Share and SUAVE-GETH devnet, landing blocks on Goerli already

* Privacy-aware orderflow auction to return to users the MEV that their transactions creater. In this auction, searchers competw for the right to back run a user, thereby bidding up the value returned to them. Initially the auction assums trust in Flashbots but is private for users and searchers
* SUAVE Chain devnet for stress testing and community experimentation

Commentary:

- Moving towards the Centauri release which is a devet launching in Q4 where anyone that wants to can deploy their own MEV infrastructure as smart contracts on SUave. We will share examples of what it looks like to take all of our centralized infrastructure and create them as smaert contracts on SUave using the MEVM targetting Q4 of this year

SUAVE Andromeda

My thoughts: Sweet spot for Suave to start picking up significant volume and begin experimenting with cross-domain MEV for Ethereum and rollups. TEE Execution nodes remove trust in Flashbots

* SUAVE Chain mainnet will allow users to express preferences and send them to the Execution Market
* SGX-based orderflow auction to remove trust in Flashbots and make the auction efficient for searcehrs
* SGX-based centralized block building to enable open but private orderflow for centralzied builders

Commentary:

- Initially execution nodes won't be in SGX or TEEs so they will require some trust in Flashbots
- The next release Andromeda we will put those nodes inside an SGX and that sysetm will not have any trust in FlashbotsAt that point we will look to move onto other Domains too. If you are a rollup or L1 developer reach out to discuss integration.

SUAVE Helios

No commentary in this presentation

Anoma <3 SUAVE

I'm asking the question this way because I've been thinking about and studying SUAVE for this article im writing and in their model the smart contracts on suave constrain the solvers. The user specifies up front which contracts they are willing to interact with.