How does SUAVE work?

At the core of SUAVE are Kettles, which can be thought of as a superset of ETH Nodes/Validators, the key distinction here is that Kettles are intended to run in Trusted Execution Environments (TEEs). This aspect is foundational to the security and integrity of SUAVE, since TEEs ensure that Kettles can execute transactions with a high degree of trust and reliability. Moreover, TEEs make a distributed private datastore possible, where Kettles synchronise over this private data. As we will see, this distributed private store, which has strict (yet configurable) read/write permissions is what really makes SUAVE work.

How do TEEs facilitate a more trustless setup in SUAVE?

A TEE is a secure and isolated environment in a computer that allows software running inside it to retain confidentiality (with respect to other processes running in the machine) and integrity of the actual code running. Integrity is the more interesting aspect for SUAVE because it’s a peer-to-peer system and requires explicit trust that Kettles are running the correct code. TEEs make use of underlying specialised hardware (such as Intel’s SGX) to provide these qualities. At a higher level, the two main methods for maintaining integrity are secure boot phase checks and remote attestations:

• Secure boot: Ensures that the TEE is not compromised on startup (also involves software assertions)
• Remote attestation: Allows TEEs to verify the code they are running using digital signature algorithms via private keys baked into the hardware.

In the context of SUAVE, if a Kettle wants to run malicious code (e.g. doesn’t propagate confidential data store changes), assuming a normal functioning TEE, the altered code may not pass the boot phase and would certainly not pass remote assertions checks, thus lowering trust assumptions. The trust is shifted to hardware developers like Intel to not have any backdoors, which is significantly less of an attack vector than trusting a Kettle to not change their client code (which itself is already relatively unlikely, as mentioned before).

However, it’s important to keep in mind that TEE’s are not 100% secure and there have been several exploits in the past. When engineering systems to minimise trust it’s important to consider what is actually at stake in the worst case. For instance, stakes are significantly higher in critical systems like an L1, since funds can be stolen if a majority of validators/miners maliciously fork the chain. However, in the context of SUAVE, the stakes are not as high^[1]. For example, a scenario involving an Order Flow Auction (OFA) could see a malicious Kettle mismanaging transaction data, possibly attempting to exploit the transaction for MEV. Although undesirable, this situation doesn’t pose a system-critical threat in the same way as a compromised Layer 1 blockchain might.

Impact of SUAVE on OFAs

OFA’s allow users that create value in terms of MEV to receive a portion of the value they create. For example, consider a large Uniswap sell order which could significantly move the pool out of line, the value created here is that a searcher could backrun this transaction with a buy to bring the pool back in line and profit off the difference.

By sending this kind of transaction to an auctioneer instead of the Mempool, the user would receive some rebate (see diagram above). Auctioneers connect to a network of searchers and forward the users transaction but importantly do not share the signature (so searchers cannot execute without participating in the auction). Searchers bid for the right to execute the transaction. Note that there can be several winning searchers as long as they do not conflict with each other. Users will then typically receive some fixed share (90% for MEV-Blocker) of the bid.

In their current state, OFAs rely on a centralised auctioneer to remain credibly neutral. The two main ways a malicious auctioneer could harm a user would be by either 1. leaking transaction data, or 2. preferential treatment of particular searchers.

• The former case is straightforward; if the transaction data is leaked, searchers can bypass the entire auction and pay nothing back to the user. An auctioneer could extract this value themselves or leak it to searchers to frontrun the original user, although this kind of misconduct is easily identifiable on-chain.
• The latter case involves giving preferential treatment to certain searchers, who may have revenue sharing agreements on the side with the auctioneer. Here, searchers who have fairly bid higher, do not win, and users end up receiving less funds. This is difficult to identify and only the most effective searcher could even identify this foul play, as they would need to notice that bids lower than theirs are winning the auction.

OFAs, if built on SUAVE, would not suffer from the previously discussed threats. Instead of a centralised server (run by the auctioneer) the auction would exist in a smart contract deployed on the SUAVE chain. Importantly, the contract would have access to private data and the access control for this data is entirely managed by the contract itself. This way the trust shifts to the proper function of the TEE (as well as the actual underlying code of SUAVE) as opposed to the auctioneer, since if the TEE is properly operating, a Kettle would not be able to tamper with the private data.

Impact of SUAVE on Block Building

Since the Ethereum Merge and a move to proposer builder separation (PBS), block builders have played an integral role in the transaction supply chain. Builders are specialised agents that receive transactions (or bundles) and order them such that they build the most profitable block.

The idea is that, by outsourcing building to sophisticated participants that are able to more efficiently extract MEV, the block reward earned by validators will increase. We can see this in practice by comparing rewards per block: since 1st Jan 2024 Mev-Boost yielded 10.35 times as many rewards (in ETH, on average per block, see query here) compared to mempool blocks.

Block building, by nature, is not inherently centralised, because in theory its possible to achieve an equilibrium with numerous block builders each holding only a minor share of the market. However, the reality deviates from this ideal due to the competitive factors among block builders which has led to a scenario where three builders dominate, collectively holding more than 90% of the market share. The underlying driver for this outcome is exclusive orderflow where the most valuable transaction originators (such as MEV bots or Telegram bots) form partnerships with builders. When the order is exclusively sent to a single builder, the builder can get away with bidding less to the validator (since other builders don’t have the transaction) and gets to keep the difference, which in turn is often shared with the transaction originator.

For example, if two builders have access to the same transaction, a price war could emerge, where all value generated from this transaction is bidded away. However, if only a single builder sees the given transaction, they can bid just enough to win the auction and keep the surplus. In the above diagram, it is evident that searcher 0x33..9c49 sends the most value to Titan Builder^[2] demonstrating exclusivity in practice.

Given this, we can model block builders as a centralised solution, the drawbacks of which are evident since almost 62% of blocks were built by censoring builders (between 9 Mar and 5 May 2024). Censoring transactions directly contradicts one of Ethereum’s key value-add of being a credibly neutral base layer, although there is work being done on inclusion lists to circumvent this outcome in EIP-7547.

Block builders on SUAVE allows us to remodel how we think of a builder – currently block building takes an all or nothing approach, but it could be improved if builders collaborated by each contributing a portion of the block instead. The reason for this is that not all block space is equal: top of block space is far more significant than bottom of block, since searchers can operate on a more stale state (see diagram below).

But, currently if a builder receives a bundle that captures a significantly valuable top of block opportunity, they are also more likely to win the rest of the block (all or nothing) and if they are censoring, they will not include violating transactions.There are still open questions around modular block building using SUAVE, one to consider is the incentive for current builders to pivot to this model. For example, for non-integrated builder-searchers (e.g. Titan builder), a SUAVE builder could threaten their business model since they aren’t themselves transaction originators.

Concluding thoughts

We’ve demonstrated some of the ways SUAVE could provide greater execution guarantees within the transaction supply chain relative to the status quo. It is still in its earliest stages with the Rigil testnet only having gone live in Q4 2023, hence there are still open questions on key implementation details. At the end of the day, incentives rule the world and it’s unclear if SUAVE will gain adoption from actors currently involved in the transaction supply chain. For instance, integrated builder-searchers only run builders because pre-existing solutions did not meet their searcher need, only time will tell if SUAVE can.

Footnotes

^[1] With SUAVE the worst case scenario is usually equivalent to the base case outcome for a naive user. E.g. With the order flow example a naive user may not know OFAs exist and simply send a large swap via the Mempool that would move a pool out of balance hence being fully exploited by MEV bots similar to the worst action a misbehaving Kettle can take.

^[2] Note that this analysis only looks at the magnitude of the bid (as opposed to frequency), thus it could be skewed by large but infrequent bids (perhaps stemming from a large liquidation). Checks have been made to ensure this does not significantly skew results presented.