rain & coffee

@rainandcoffee

x.com/i/article/2032…

20

16:39 • 13 Mar 2026

Quick side note: Encrypted/Private Mempools are not just needed for MCP setups, but also for live blockchain systems today - as Julian Ma eloquently puts it, it can solve/help on many fronts - especially ensuring that the entirety of DeFi happens on-chain (and not party off-chain). I would recommend reading his flurry of tweets: here, here and here.

Many moons ago, we wrote a blogpost about the mechanisms and setups of MEV in a modular ecosystem. In that piece, we had a section aptly named data availability MEV. There, we mentioned that most MEV (if not all, barring specific cross-domain situations) would likely end up in the execution layer, where leader election happens, since they decide inclusion and ordering. However, over the last few weeks I’ve had several discussions in which the idea of DA MEV has come up. Funnily enough, not in the context of modularity, but rather on monolithic L1s (specifically ones utilising multi-concurrent proposers (MCP)).

With this newfound context, we thought it would be fruitful to dive a little bit deeper into this topic, alongside other interesting mechanical changes coming to several more modern chains, and their effects on MEV.

In my last article, we focused on the development of multiple concurrent proposers (MCP) and their possible effects not only on censorship resistance, but also on throughput and customisation. An interesting (and somewhat underexplored) aspect of MCP is its potential effect on MEV, specifically on the data-availability side.

If you need a quick primer on data availability: DA allows us to check with a very high probability that all the data for a block has been published. Data availability is required to be able to detect fraud and also to recreate the entirety of the chain.

And a primer on MCP; instead of a singular proposer deciding what block gets proposed, multiple concurrent proposers contribute mini-blocks that get merged into a singular, larger one.

The DA MEV Problem

In setups with delayed execution, where transaction inputs are published before execution (MCP), there’s a high probability that MEV-prone validators could participate in transaction stealing by taking transactions from the DA layer and engaging in front-running.

For example, a validator (or a set of them) could collaborate in playing timing games, waiting for bids and then submitting higher ones. This is especially important in cases where the DA layer does not have the ability to Replace-by-Fee (RBF). Meaning you could see one validator’s set of transactions published first, take the ones you deem valuable and outbid for execution.

While DA generally doesn’t have a significant impact on MEV in most cases, due to the absence of leader election (in most L2s) and the fact that a single leader is chosen in advance on most L1s. However, MCP changes this equation entirely. MCP introduces several concurrent leaders. And with several concurrent leaders all observing a public mempool, you get a multiplicative effect on the MEV attack surface.

A possible solution to these types of attacks is to encrypt the data being made available in relation to the transactions about to be executed and put into a confirmed block. The reason for doing this is to reduce the potential for MEV games arising from the introduction of more novel mechanism designs. However, most methods for achieving encrypted DA are likely to lead to an increase in latency, as both ZK and FHE have considerable compute overhead (although we’re closer to closing the gap with ZK). There are, however, other ways to get to the same goal.

Encrypted DA

The core idea is straightforward: utilise cryptography (or hardware) to hide transaction content until the finalised ordering of transactions in a block is irrevocably committed. This removes the ability to steal transactions and engage in timing games. One thing to keep in mind, though, is that while providing encryption, we also want to limit the latency we introduce into the system.

There are several methods you could utilise to achieve this, each with different tradeoffs and properties. Let’s explore the main ones:

1. Threshold Encryption (e.g., Shutter Network)

Transactions are encrypted to a threshold committee; the decryption key is released only after block ordering is committed. Shutter is already live on Gnosis Chain, providing the closest real-world validation of this approach.

The tradeoff: liveness depends on the threshold committee. If t-of-n participants are offline or colluding, decryption stalls.

2. Verifiable Encryption + Private DA (VE-PDA)

Users encrypt transactions but attach a ZK proof that the ciphertext is valid (correct format, sufficient gas, no double-spend). Validators can verify correctness without seeing content. Celestia’s Private Blockspace proposal extends this to the DA layer, where blobs are encrypted at submission and are decryptable only post-ordering.

The tradeoff: ZK proof generation adds user-side latency (seconds on consumer hardware today); proving overhead is the main bottleneck.

3. Trusted Execution Environments (TEEs)

Hardware-based: transactions flow through secure enclaves (SGX/ TXD etc) that order before revealing content. Explored by Flashbots in their anonymised mempool post.

The tradeoff: the trust assumption shifts entirely to the hardware manufacturer (Intel) and the supply chain and of possible physical attacks (maybe we put them Space? But latency.. see Spacecomputer!) SGX has a well-documented history of side-channel attacks (Spectre, Plundervolt).

4. Delayed Reveal / Commit-Reveal Schemes

The simplest approach: users commit a hash of their transaction, ordering is determined, then plaintext is revealed.

The tradeoff: two-round latency doubles block time, and users can grief by never revealing. Celestia’s account-centric private blockspace proposes a variant where reveal is enforced via stake slashing.

5. Time-Lock Puzzles / Timed-Release Encryption

A transaction is encrypted such that it becomes computable to decrypt only after X seconds — no key ceremony needed.

The tradeoff: computationally expensive, and adversaries with faster hardware can decrypt early. Not yet practical at blockchain timescales.

Public vs. Encrypted DA

Let’s make the contrast concrete.

Under public DA: A proposer sees swap(USDC→ETH, amountIn=50000) in the mempool. They can immediately construct a front-run buy and back-run sell around it. The content of the transaction is what enables the attack. However, on Ethereum, a very large portion of today’s order flow is private, and what actually goes on behind the scenes is less than clear - but it does mitigate some of the issues (but not in a verifiable, decentralised nor trustless manner.

Under encrypted DA: The proposer sees 0x9f3a...c2b1, a ciphertext. They have no idea if it’s a swap, transfer or a contract deployment. They cannot construct a sandwich because they don’t know the token pair, direction, size, or anything else meaningful. The ordering commitment happens before decryption. Once the block order is irrevocably finalised on-chain, the decryption key is released and transactions execute in that committed order. At that point there is nothing to front-run; the ordering is already done. However, efficiently constructing a block becomes significantly more difficult (if not impossible) since the proposer has no clue about how much gas a specific transaction will consume (and if he knows, then he will also have an idea of what type of transaction is committed).

Quantifying the MEV under MCP

Let’s look at some data to understand just how needed encrypted DA is (especially in a multi-proposer situation).

*7 proposers is the proposed number of Sei Giga proposers in the only live MCP system

The probability of a sandwich attack per transaction on Ethereum accounts for around 2%. The true figure likely sits between 2% and 12% per block, depending on whether the base is all DEX swaps, or only swaps above the minimum profitable size threshold. Public DA values are lower bounds; however, it could be much higher because of structural MCP-specific mechanisms such as coordination breakdown, timing games, and duplicate inclusion which compound (we’ll get into these type of attacks further on).

Under Proposer-Builder Separation, it is block builders, not proposers, that execute sandwiches; however, we’ll get further into MCP vs PBS further on in the article. Flashbots’ BuilderNet partially addresses builder centralisation but redistributes rather than eliminates MEV, leaving the extraction mechanism intact.

Some important caveats on this model. It assumes proposers act independently, whereas in reality, they likely coordinate or bid through the same MEV infrastructure (like MEV-Boost relays), which changes the math. The strongest real-world evidence for encrypted DA solving sandwich attack iis essentially zero sandwich attacks on rollups with private mempools.

The 1.8-3.5% floor for encrypted DA that we model is illustrative. It would depend on relay-level leakage (if MEV-Boost or equivalent infrastructure sees plaintext before encryption, a possibility in TEE-based schemes), timing attacks (the existence and size of a ciphertext can leak information even if content is hidden), and statistical inference (high-frequency traders can sometimes infer transaction content from size + timing patterns on known protocols).

As for why encryption eliminates the content-visibility attack vector, the Flashbots anonymised mempools paper directly argues this. Without content visibility, front-running requires guessing rather than reading. Shutter Network’s deployed implementation on Gnosis Chain shows near-zero sandwich attacks on encrypted transactions in practice.

Why does MCP increase the chance of attacks (in this case, sandwich attacks)?

On Ethereum today, many searchers compete to find and submit sandwich bundles, but they all route through the single builder who wins the block-building action and the single proposer who proposes it. The builder acts as a coordinator and filter — only one sandwich bundle is executed per victim transaction, because only one block is finalised. The many searchers compete with each other to get their bundle picked, bidding away profits to the builder via gas. You’re not adding new searchers, you’re adding new block assemblers that the same pool of searchers can already route to.

The real reasons MCP with public DA increases MEV risk are structural and specific to concurrent block production. Three matter most. First, timing games: with N proposers all watching the same mempool and each other’s DA proofs, the game-theoretic equilibrium shifts toward delay wherein proposers hold back their block to observe competitors, widening the extraction window for every pending transaction. Second, same-tick duplicate inclusion: multiple proposers can independently include the same victim transaction in concurrent block proposals, creating races in which several sandwich attempts land in the same slot, and the victim’s transaction is manipulated by more than one actor before consensus resolves which block wins. Third, coordination breakdown: the current builder is a centralised coordinator that picks the single best bundle — under MCP, that coordination disappears, and the absence of a chokepoint means chaotic multi-party extraction rather than the orderly, profit-maximising single extraction you get today.

Concurrent proposers need encrypted DA

A protocol that decentralises its proposer set without introducing encrypted DA will temporarily be subject to arguably the worst possible MEV environment. Which is the predicted outcome of applying the sandwich model to any N > 1 public-DA MCP system.

The only way to reach “low” amounts of MEV with high decentralisation in the block building is encrypted MCP (if you just encrypt block building, the public DA is still possible to attack). Encryption collapses the content attack window to near zero. The residual reflects side-channel leakage from transaction size and timing signals (more on this below) and MCP-specific timing-game effects that persist even after content is hidden. However, despite that, you still achieve lower sandwich MEV than Ethereum while providing materially stronger guarantees of censorship resistance via MCP

As such, encrypted DA feels less like an optionality and more of an architectural need to prevent decentralisation from amplifying MEV.

MCP-specific MEV Attacks:

Landers & Marsh formalise some rather interesting MEV-attacks that are introduced in an MCP context:

Same-tick duplicate steals: Proposer B copies a high-value transaction from Proposer A’s block and includes it in their concurrent block for the same tick. A loses the fee.
Proposer-to-proposer auction race: N proposers race to include the highest-value pending transaction, creating an implicit priority-fee auction without a formal builder market.
Proof-of-availability timing game: all collaborating proposers delay block release to the last moment T to observe competitors’ DA proofs. This creates a systemic latency floor. Encrypted DA eliminates content leakage but not the timing signal itself.
Threshold key release delay: If keyholders are bribed by a block proposer, a colluding subset could delay decryption after ordering commitment, enabling last-second content observation.

If you’re interested in how to mitigate these, I’d recommend reading the article linked above.

One very interesting aspect of the article is that in most cases, encrypted MEV does not fully eliminate timing games itself, and likely there’s a need for both encryption and priority DAGs.

The Death of PBS in an MCP world

The issues of MEV eventually led to the introduction of proposer-builder separation in Ethereum, as PGA wars heated up. The fair-exchange problem between the builder and the proposer (solved by the “trusted” relay) remains a persistent issue. However, in a world with MCP, PBS is unnecessary and probably harmful.

This is primarily because the properties gained from MCP are similar to those from PBS (currently implemented outside the base protocol), but are based on in-protocol rules rather than external ones.

PBS was necessary due to the market dynamics of the Ethereum block-building and validation phase. However, in a world where not a singular validator has control over what block gets proposed (and where the fair exchange problem isn’t as big a problem), there is no need to split block building from validation - since optimisation and performance won’t matter as much (you can get included anywhere).

PBS essentially removes the probabilistic censorship-resistance benefits gained from MCP, which would be a step in the wrong direction (unless you then start working on the fair exchange problem, but again, you’ve already solved this with MCP). What PBS does do well is force highly optimised building, but at the cost of centralisation (with the gain of performance). This single-builder censorship also reduces the inclusion probability. Furthermore, running a PBS auction with several validators rather than one is a whole different beast; the economics are not the same.

However, given that most nodes are run by a handful of service providers, do we really achieve true separation of block building?

Source: Hildobby, Dune.

Perhaps a needed change is to allow each provider to have only a single subblock per MCP block. The security threshold isn’t that hard to reach for a set of colluding staking providers.

Essentially, by having MCP, you decentralise the sequencer/builder (since we go back to validators ordering blocks) and remove the centralising bottleneck of before (singular leader).

Something we’d love to see explored more in-depth is also the MEV in delayed execution environments (especially Monad)

On the other hand, the multiple concurrent builders of Solana share some similarities with how a full MCP implementation would look, and at least have the concept of several different actors contributing to the creation (but not proposing of a block). On Ethereum, most blocks (~95%) are built through MEV-Boost. While several builders are active at any time, there can only be one auction winner, so it loses the angle that you could argue Solana has with the multiple concurrent builders. The fact of the matter is that there isn't a singular chain today with more than one proposer with the power to propose a block at any time. 

The easiest way to think about MCP is to break it down into having more than one proposer providing blocks at a time, and a final merging of those sub-blocks.

These groups of proposers are likely subcommittees (like the current ones in Ethereum) since doing this with the entire validator set would be unfeasible. This also means we must ensure that no single subcommittee is just one staking pool, which could lead to censorship and collusion concerns. Another thing to remember is the relatively unsophistication of the fabled home staker - MCP means increased complexity.

Let's summarise the reasons why MCP has properties worth having:

Reasons for having multiple concurrent proposers:

• Increase censorship resistance (more so than ever, especially with current bottlenecks)

• Scale the base protocol instead of outsourcing

• Disperse MEV as no single proposer (or builder) decides on inclusion

Issues that are immediately clear from implementing MCP

• Prevalence of competition in ordering (inclusion and ordering) - rise of PGA?

• Invalid transactions - simulations

• Hardware requirements increase

• Data availability of invalid transactions

• Needing a finality gadget

Let’s review the properties one by one, starting with the strengths. Then, we’ll consider whether the possible issues might arise and whether they’re too grand for MCP to be implemented on chains with considerable technical baggage.

1. Increase censorship resistance

Most blockchains today that have a deterministic approach to finality and consensus derive this from a singular leader that sets the path for what gets included and added to a block (some nuances). Afterwards, a block is propagated, and eventually, most of the validator set agrees to the block and gets added to the canonical chain. In Ethereum, we have subcommittees of this set to enable faster blocks (but longer epochs to get the extensive set to agree). In an MCP setup, several different proposers are building their own local blocks that will eventually be merged. This means that instead of a singular block proposer (or builder/relay, preferably we forgo these in MCP setups), there are now several entry areas into a block. This makes censorship considerably harder (easy to go to https://www.mevwatch.info/ and see the effect a centralised relay has on inclusion). In a world where there are several includers, censorship resistance is hardened. 

Current bottlenecks (do note that several teams, including Flashbots, are also working on improving the current situation) are specifically the fact that a single builder wins an auction that a single proposer proposes. This is further exacerbated by a single (trusted) relay sitting in the middle as auctioneer. While the core Ethereum protocol is decentralised, the way we currently get included in the Ethereum blockchain isn't. On Solana, the centralised aspect of the Jito relay/builder is also a legitimate concern they're trying to solve via restaking (the FIRST real yield restaking “AVS”!!). In Bitcoin, this can be solved by running your own full node, which is relatively low effort; however, this does come at the cost of finality. Bitcoin has probabilistic finality and no “finality gadget, " which would be needed to ensure deterministic and fast finality in MPC implementations. Bitcoin relies on the longest chain rule.

2. Scale the base protocol instead of outsourcing 

Generally, to solve issues with the primary protocol, much of the actual development has been outsourced to third-party teams to solve problems inherent with the “stale” design of L1s. This isn't limited to just Ethereum, but goes much broader. By implementing MCP, you start to deal with some of the issues previously solved/created by out-of-protocol implementations. In this case, you heighten hardware requirements (but increase censorship resistance) - potentially a worthwhile trade-off depending on the decentralisation needs of the users of the protocol. Anyhow, this is also something you could expect to see on Solana, especially with the centralised aspects of Jito. Furthermore, since you're outsourcing elements of the block building to several parties, the end result is an increase in total bandwidth

3. Disperse MEV

One of the more unique outcomes of MCP is that, instead of leaving all the MEV in one basket since either a single proposer or builder decides on inclusion, the MEV is distributed among active proposers in a specific block. This means that you no longer have to hope to win the MEV lottery, but rather, with more likelihood, can expect a more even stream of rewards (most companies, which most validators are, would prefer a constant reward structure). It is also generally a better way to ensure that no single party can re-order to extract MEV (the current case). However, this also fits into the censorship-resistant case. 

If you've read any of our other articles in the past, you might be familiar with the term CAP theorem: Three informal properties that you must possess for a distributed system to work as intended.

C: This stands for consistency; basically, the UX should be identical from user to user, and users should feel like they are interacting with a single database every time they use the system.
A: Stands for availability, which is what we also refer to as liveness. It refers to the fact that all messages are handled by nodes in the system and reflected in future blocks/queries. All commands need to be carried out.
P: This stands for partition tolerance (or censorship resistance), which means that the system needs to uphold consistency and availability even during an attack or partition of network nodes.

MCP is one of the best ways to achieve key parts of the CAP theorem (specifically censorship resistance), which are generally waved off as game-theoretic issues. Trust the protocol, not game theory.

Now, positives don't come without negatives, and the CAP theorem works in ways that with something great, something bad comes as well - it is almost impossible to fulfil it in its entirety. As such, let's look at some issues that may arise when implementing MCP.

Issues with MCP that need to be addressed

The main issue is generally considered to be the fact that MCP, to some extent, introduces two phases of competition within a block. The first is an inclusion fee, and the second is an ordering fee. The ordering fee is specifically difficult to deal with since in the first phase, the local producer only has his view of a block—and not the whole view. This means that trying to optimise how much needs to be bid to be somewhere specific in a block is a difficult task. 

Not only is it difficult, but it essentially (in an auction-type setup) brings us back to the days of priority gas auctions (PGAs). While you do have much higher guarantees of censorship resistance, you essentially bring back what MEV-Boost sought to adhere to—high median gas fees in competitive slots, pricing out others during inclusion, etc.

There are other issues around transactions than just how you order them (both from a local and global perspective). Here we are referring specifically to part of the propagation of the local<->global view of a block, and what sending invalid transactions means. Considering that, at the beginning of a phase (before the merging of blocks into a singular, multiple proposer built block), there is no view of what state changes might affect other transactions from different proposers. This means there's the possibility that proposers give each other invalid transactions (even more of an issue if this is posted on-chain, as data availability). It could also be that the parameters a validator in the current MCP set has aren't being followed, such as max gas (and going beyond that). These specific issues are rather simplistic to solve since you need an actor (or set of rules in the protocol) that, when the previously mentioned DA is revealed, you can order txs by fees and take out those with the lowest fees with the same wanted state changes. Again, the issue with this is that we reinforce a problem we had already solved (PGAs). However, if we don't have any mechanics such as auctions (PGA) for searchers/builders to control block positioning, then we just resort to spam and reinforced latency games. Everything we'd also discussed likely breaks the likelihood of preconfs.

An extra consideration on both Ethereum (post Pectra, so now) and on Solana is the fact that transactions aren't invalidated by nonce w/ 7702 and obviously the lack of nonces (for transactions, not accounts) on Solana. This means that figuring out if a transaction is invalid or not becomes quite the issue - essentially, you'd need to simulate all combinations to figure out what the correct ordering should be, which will likely add considerable bandwidth strain to the network. On Solana, the already decent hardware requirements will likely make this process easier, but on Ethereum, an increase is definitely needed on the hardware side. However, one likely way to solve this on the Ethereum side is that when the merging of subblocks happens, the actual ordering is computed on the execution client (instead of trusting the builder+relay), again, we need better hardware. 

On the DA side, as mentioned earlier, another important aspect is the issue of leaking these invalid transactions on-chain (making them essentially free). This further exacerbates the simulations mentioned above before consensus, meaning you can filter the invalid transactions during merging. Some various implementations have been done for FOCIL (sending address rather than tx) work that could likely be reused for this (unless we just trust the simulation completely, although if there's an actor involved here (and not the protocol rules), then it could interfere with simulations by making other transactions invalid). 

As mentioned in the summary, a likely needed aspect of implementing MCP is the fact that we'd likely need a finality gadget that handles synchronisation - this is also what we've alluded to above in the ordering simulation pre-consensus aspect. This also introduces the ability to delay the block proposal for timing games, which we already see during MEV-boost auctions. An effect of this could be seeing other blocks before proposing your own, creating possibilities for sending transactions that invalidate others’ (especially useful for a searcher). If we implement extremely stringent rules to combat timing games, we run into an issue of shutting off validators that aren't as performant as others (meaning more missed blocks). 

Possible ways to combat the timing games could also be obtained from learning from improvements done by chains such as Monad, which utilises asynchronous execution (delayed execution). Here, you could implement a rule that says the full effects of a transaction set from all active proposers in a slot can't be known until the entire set has been constructed. 

This considerably limits throughput, since the likelihood of the same transactions being included by more than one proposer is relatively high. The delayed execution also means that despite being “included” in the subblock, the possibility of not getting included in the merged block is possible, meaning that a reverted transaction (despite inclusion) will happen. This mirrors back to the double inclusions mentioned in the beginning. Note that you'd likely need some finality gadget that acts this way (and as such executes, propagates and finalises the block)

While we've primarily focused on the Ethereum side so far, it is worth noting that Solana is more actively pursuing MCP. This has been exacerbated by the fact that Max Resnick is now part of Anza, and Anatoly has been outspoken about wanting to implement it as well. Anatoly recently had a post covering it, so let's summarise parts of their focus and the issues they foresee:

• What if blocks arrive at different times from different validators (this could also be timing games)

• How to merge transactions, again, we've covered this before

• How to split capacity in a block (max gas) between validators to increase bandwidth to the max

• Issues arising from wasted resources (via having the same transactions land in several subblocks, also an issue raised above)

Generally, many of the problems in implementing MCP on Solana resonate with the issues on Ethereum. However, Solana puts a lot more weight on optimising bandwidth and performance, meaning that managing block resources and merging blocks matter a lot more while ensuring that consensus stays robust.

Another key aspect we alluded to at the article's beginning: MCP can also be used to scale the protocol, not just strengthen it. Not only that, but it can also be used to protocolise application-specific sequencing (ASS) via ordering (which we have a lot of writing, see here & here). There could be a world where, instead of a proposer for XYZ transactions, an app is the proposer and orders its own set of transactions according to its wishes (the world delta is working towards) - or vice versa, the app gives a proposer a set of rules to follow regarding ordering its transactions. Interestingly enough, MEV taxes to applications (the tx originators) together with MCP is also being explored (and a lot easier since not a single proposer controls inclusion)

In a recent post by Max and Anatoly, they view MCP as enabling tighter spreads (the decentralised NASDAQ idea) via application-specific sequencing. In the current climate, as mentioned before, only a single leader proposes blocks. This means that in a situation where prices move, when using an orderbook, quoters will seek to cancel certain bids. In the single proposer situation on Solana, a Jito auction is run as the proposer has a monopoly. Preferably (as on Hyperliquid), cancels should be prioritised to allow makers to have tighter spreads. Hence wanting ASS to prioritise exactly that for apps, with a single leader they have monopoly to run auctions, with MPC we can forego this. However, in all likelihood ASS in this case is going to be limited to state silos. The presented proposal essentially means that application developers can define what should be prioritised for a specific account (i.e., a cancellation). The highest priority txs that get executed first for that specific account (not necessarily max tip, but instead cancels since they're essential for active liquidity). The idea is that you have a threshold for everyday transactions regarding fees, while certain prioritised transactions can exceed this.

We also discussed the issue of both inclusion and ordering fees above. Solana seems fine with this. Inclusion fees will go to the validator who included a transaction, while ordering fees will be paid to the protocol (burned). When you merge a block from the many subblocks, you then just take the merged set of transactions and order them according to the set ordering fees (and execute them). 

The setup above plays into Turbine, Solana's block propagation mechanism. Leaders (MCP) use shreds, they send it to a relay in the Turbine tree - relays should have shreds from all leaders. Relays send ping to single consensus leader about shreds - this leader must include large enough fraction of messages and then broadcast + come to consensus.

With the recent announcement of Alpenglow, this implementation might look slightly different considering the single layer of relay nodes. As well as the removal of voting as on-chain transactions (now on-chain). This coupled together should make running a validator cheaper which would likely increase the amount of them, and allow less sophisticated ones to participate. This sounds great for decentralisation, but could have likely effects on the performance of the chain. One questions interesting to ask, with the new announcements is specifically how they plan to deal with faults of validators in a world where we have MCP on Solana.

MCP in other ecosystems:

There has also been some work done on the Cosmos side on implementing MCP, notably Informal Systems has just released a spec for multi-proposer in a BFT consensus model. Notably, they use a secure broadcasting protocol, wherein vote extensions force each sunblock from a validator to be acknowledged by other validators. The block building part of Tendermint/CometBFT then agrees on a set of these. This means you have a large number of subblocks from specific validators.

Sei is also currently working on MCP (and trying to become the first to implement it) via their work on Sei Giga, which derives part of its design from the Autobahn paper, which we highly recommend reading. The general idea is that data availability is separate from ordering, and made available faster via separate (multiple) lanes before being ordered into a global chain. It differs slightly from the idea of MCP on Ethereum because validators aren't necessarily all providing blocks simultaneously in set slots, but rather continuously and then merged to a global view. 

Patrick O'Grady of Commonware is also working on an approach to this.

Lastly, Delta also has a design wherein the base layer functions as a censorship-resistant bulletin board. At the same time, each application runs its concurrent sequencer, which produces blocks settled onto a global state layer.

Recommended Reading:
The Path to Decentralised Nasdaq, Max Resnick (Anza) & Anatoly Yakovenko (Solana Labs)

Multiple Concurrent Proposers, FOCIL and Preconfirmations

Block construction session

Autobahn Sei Multiple Proposers
Autobahn paper

As they grow in traction, most applications quickly realise that their customisation and internalisation choices are limited as simple smart contracts. Applications are inherently opinionated about many things, especially ordering in the DeFi case.

The idea is relatively simple: the fat application and protocol are the same, and both benefit each other. There are perfect examples of this already, such as taking advantage of ordering and customisation for a better application.

The idea comes from the fact that we at Maven11 generally believe that applications are opinionated by default. They all have some idea of how they want specific things to function within their application (often without the power to do so); this could be related to ordering, fairness, distribution, customisation & and the list goes on. To better understand why we believe that applications are opinionated, it may be easier to look at blockchain applications as actual companies (which they often are). Companies in the real world are opinionated about many things and can often be expressive (meaning they aren’t limited/restricted too much). You could compare the current situation for most blockchain applications to that of “companies” in a central planning economy run by a socialist dictatorship. Most real-world companies in modern economies, while they have to adhere to some degree of governmental laws and legislation, their landlord isn’t watching over their every step. This, in turn, allows companies to compete across more axes as they can define and fine-tune a more significant part of the user experience.

Let’s take an example of a real-life company, in this case, a burger joint. In this joint, the local landlord controls how the seats should be placed, where the windows are allowed, and the burgers' pricing. What business would appreciate this type of overreach? Not many. The fundamental issue with most businesses functioning as smart contracts on generalisable blockchains is that they run into these issues - a complete lack of control and, therefore, a degrading user experience. While some aspects of newer monolithic systems have provided models like local fee markets, even there, much of the customisation is still lacking. In the rest of this article, we aim to present our thesis on why applications are opinionated and how they can become opinionated (and those who are already expressing these opinions).

All the applications we've spoken to had one thing in common: they were all opinionated about how to service their users best. Can they do so in current conditions in a generalisable environment - in most cases, no. Although application-specific sequencing aims to solve some of the ordering concerns some applications have, we'll cover them in more depth later.

Conceptually there are simple reasons why an application would want to control aspects of its design that isn’t possible on a baselayer w/o significant changes (either ASS, off-chain or rollup-esque setups):

• Static VMs

• No ordering control

• Inelastic scaling

• MEV leakage

• Global state (good & bad)

  • Contention, the beauty and the beast of composability

We have specifically covered the ordering part in depth in a complete article on the concept of transaction ordering, which can be found here. As such, we’ll just summarise shortly why this matters:

• Allows for internalising MEV (end the proposer monopoly!! Or become your own proposing monopolist?)

• Ordering constraints for specific apps: fair ordering, welfare maximisation, priority lane, LVR auctions, frequent batch auctions and swap splits (and the list goes on)

While many projects (most successfully CoWSwap) are utilising batch auctions for their intent batches, something we specifically would like to see on an application-specific level is noted below;

In terms of live implementations of ordering rules, there are quite a few - some highly successful already, and several significant players are moving towards using ordering rules to their advantage in the coming year. Underneath are just a few examples.

Hyperliquid; prioritises cancels and makers over takers by running cancels and post-only orders first.

Unichain; TEE builder(s) to ensure no malicious actors in the supply chain with a “highway” for arbitragers.

Penumbra; ordered batch auction with an accrued time arbitrage value

Slinky (Skip); oracle data at block level (protocol-level) to ensure the application(s) on the chain can utilise fresh (and cryptoeconomic secure) oracle data

Oval (UMA) and Warlock; Oracle-Extractable Value auction for the right to act on updated information - specifically relevant for liquidations, but could also work for arbitrage.

Generally, many of these ordering rules can (and are going to be) implemented on generalisable chains via applications-specific sequencing (ASS); however, some considerable constraints need to be kept in mind, specifically around composability, resource locks and exogenous vs endogenous MEV capture. And certainly also a spectrum of security, we'll cover some of the security considerations and composability settings both for ASS and other setups below;

While ASS has been pushed primarily (at least as a concept) via bundles, fat TXs and off-chain (guardian) node systems, there are several different ways of achieving control over sequencing:

• App-chain

• App-rollup (deriving security)

• App-based-rollup (if lanes/flags)

• Fat TXs/Bundles

• Off-chain node systems

Key things to keep in mind between all the various solutions is that there are generally four key security parameters that must be taken into account:

1. Decentralisation

2. Transparency or Privacy (either can play a big part in censorship; TEE could be used to “trustlessly” enforce rules in the supply chain). The caveat here is that a lot of power is still in the app/wallet pre-ordering

3. Censorship

4. Stakes/bonds (rules backed by economic security)

Looking at the five ways of achieving sequencing control above, generally, we'd flag the issues/powers as

• App-chain

  • Orchestration push, but complete control - need to write everything yourself. Lend itself well to eg. Perps

• App-Rollup

  • Less push, inherit security, complete control - flurry of SDKs. Composability is still hard.

• Based-Rollup

  • Less built out, higher degree of composability depending on outsourcing/delegation, less specific control but gain network effects

• Fat TXs/Bundles

  • Less lift, exogenous MEV is hard to capture, endogenous MEV easier. Might have to change call data of txs, dependent on global ordering rules. Susceptible to exogenous MEV if composable.

• Off-chain node(s)

  • Less secure, solid complete control, composability essentially impossible

In most of the cases above, your likely dependencies will be; the underlying chain, your own protocol or not, are you inheriting some security (ie DA/Dispute Resolution) and is there a need for a consensus algorithm or economic bonds. How much of this is outsourced (and is incentivisation needed?). Also, but not least, are you on contested global state.

Do consider that most of the app-specific chain or rollups can enforce rules on a “consensus” protocol level, meaning the protocol is built respecting rules rather than forced in. This is also why economic security or verifiability (validity proving) is so vital in most setups. You could argue there's quite some likelihood that based rollup setups with execution flags or lanes could provide the best of both worlds (still unclear aspects though, specifically around execution preconfs with sync composability and ordering lanes). When we say both worlds, we're specifically referring to also dealing with the issue of composability (while retaining control), let's look at the composability spectrum.

This is heavily based on the great work by Thogard but simplified to provide a simpler explanation of the tradeoffs, if you want the nitty gritty aspects - I heavily recommend checking out his work. Keep in mind that app-chain could also mean app-rollup. The general idea is that while some control is possible in terms of ordering and MEV internalisation on the baselayer with existing contracts, not all MEV is capturable (especially exogenous MEV, which is highly prevalent in intent based protocols). Furthermore, on the baselayer, you're still constrained in customising the infrastructure backing the applications. Let's take a look at what we mean when we say customisation (and specilisation), since there are several aspects that are important to keep in mind for a business (application) founder.

The customisation part of a chain, often overlooked by many (but a big issue for specifically EVM-chains), is how that affects UX. A great example is the constant approval needed of tokens to trade, and of course the hated EoA. EIPs like 7702 can be implemented (and adjusted) to fit your application needs. However, that's just the beginning of what you could implement; how about changing your VM to one better fitting your developer's needs (and, as such, providing a better user experience). Maybe your chain needs a high degree of security with ZK verification, and the native BNS-128 isn't good enough on Ethereum, so change that. The reasoning here for your own infrastructure (and so many providers offer this now) is that you should be allowed to be opinionated about how you build your business and not be constrained.

Other things that might be interesting to add for an application could be new precompiles (which can take a long time to implement on a baselayer).

Another reason, and one generally utilised as the most prominent reason in the past (but has subsided since then), is scalability. Now, we don't just wanna trout the “modular scalability horn” yet again. However, we will note that the elasticity (i.e., increasing gas limits) you're afforded regarding scaling and latency can be a considerable gain depending on the application.

However, we see this move towards infrastructure control as an evolution that the application takes on as it increases in complexity and popularity (although newly built applications with complete control have seen to do well because they're able to provide a much better UX). The general evolution is likely a 4 step process (or 5 if you consider smart contract into smart contract w/ ASS)

This is not the time to get into the complexity, orchestration and cost of a fully decentralised app-chain, but if you're interested in our thoughts on this, feel free to watch our presentation from Denver last year (link to slides)

The clearest and most famous example of the many mentions of specialisation above is the one needing composability the least (one of the downsides often associated with app-specific infrastructure) - the “decentralised” exchange Hyperliquid. It does two specific things that benefit its users immensely- controlling ordering and customising its infra to the user.

On the ordering front, they prioritise cancel and maker orders to provide a better trading experience. On the customisation front, the general trading experience we usually associate with on-chain venues is abstracted away via infinite approvals and one-click trades (ie EIP7702-esque), as well as elastic scaling and a tailored consensus algorithm to penalise inefficient nodes for “CEX-esque” experience (even w/ a larger/decentralised set, I expect this to feel much the same)

It's just the beginning innings of the game. With other larger players like Uniswap moving in a similar direction (but as a rollup), we expect to see many more similar announcements as time passes.

One aspect to also keep in mind as we see more applications move aspects off-chain is that we keep the censorship resistance of the protocol (especially with the advent of auctions). There are various ways to achieve this, such as:

• Based sequencing (w/ some nuances depending on the degree of outsourcing, fair-exchange and proposer monopoly)

• TEE (obfuscate the ability for dishonesty in the supply chain)

• Bonds/Stakes

• Application-specific rollups w/ decentralised rotating sequencers

• Mixture (ie Unichain)

• Fair exchange solving via consensusless decentralised protocols against censorship

Other issues to keep in mind as we specialise further are:

• With faster chains, how do we deal with reverts? how fast can simulations get (ie can the top of block invalidate the bottom)?

• If the decentralised sequencing mentioned above is not single leader but competitive, how much of this is latency games

• Consensus is slow, might make sense to just stream txs (but then latency game as said above)

• TEE's might push towards spamming (already a massive issue) because of private OF

Generally there are some downsides to taking control:

• Lack of composability depending on setup, with ASS a lot (just like chain abstraction) comes down to resource locks.

• If ASS, lack of own fee market? Lack of VM/EIP control

To give a broader view of the vertical in terms of taking control (beyond the simplistic - go build app rollup/chain), there are other examples of app-specific infrastructure for specific needs:

• Spire (building based-rollups, app-specific ones will have much control)

• Astria/Espresso/Radius, allowing for app-specific builders (+ shared seq for composability)

• Spicenet (sovereign rollup on Celestia)

• Sorella (LVR auctions in Univ4 hooks)

• Initia (Apps can ASS their sequencer using the mempool lanes on each minitia / Skip's Protocol-owned-Builer)

• Magicblock (ephemeral/based rollups on Solana)

• Delta (each app is its own sequencer but with a global state layer underneath)

Offering Application-specific sequencing on a baselayer there are specifically:

• Semantic Layer

• Fastlane Labs

• RaaS - in theory, all RaaS providers could/are providing some degree of ordering/customisation control

The fat protocol and applications thesis are one and the same, they merge ever closer together as applications become businesses, and businesses become infrastructure.
Whether that is sequencing rules, using a different virtual machine or making custom changes to existing ones (such as adding new opcodes or changing gas limits) is really up to the end developer, depending on their product.

Something we'll start to see happen (and already is) this year is the move of many smart contract applications to their own application-specific rollups. This is primarily to control ordering (either for priority fee extraction or to provide specialised setups that gets closer to fair ordering). But also the ability to customise/specialise your VM, OPCodes, precomplies, new curve support for ZKPs or even gas limits (e.g. keep all active world state on disk).

One thing that we do need to mention as well is that there's undoubtedly also a ton of validity in the idea of a “fat wallet thesis” considering their power as the transaction originator, curated interface with revenue share from various protocols - however, gaining ground here is much more complicated because of the network effects we generally see. There are also multiple things to remember, such as wallets are unlikely to change calldata of txs, which can limit aspects of monetisation and things like NBBO.

The gist of the thesis on app-infra and opinionated applications is that opinions matter;

• They enable applications to become better and more akin to real-world businesses.

• Creates better user experience

• When applications can conform to user’s wants, users are more sticky

If you're building opinionated applications, we'd love to talk to you - please reach out!

We'll leave you with a great quote to ponder (and chart) from the Syncracy Capital

Based Rollups 101

There’s been much discussion and excitement around based rollups. The reason for this is quite simple, based rollups are based. Specifically, they allow applications to stick to their underlying layer (+ retain synchronicity) - while gaining several superpowers that are usually reserved for rollups and app-chains (while deriving security). These are things like customisation, MEV internalisation and specialisation. The reason why we generally haven’t spoken about based rollups much in the past is that the implementation ideas in the past were generally centred around overloading the proposers and turning everything into singular chains - something that isn’t scalable in these hyper-decentralised systems. Furthermore, the UX of these setups (in the absence of preconfirmations or soft guarantees) just weren’t up to par for what applications would want.

In our view, the current dogma around based rollups has changed for the better. However, significant assumptions, what-ifs, and centralisation concerns remain. Underneath, we’ll give a simple overview of how based rollups were planned to work in the past, how current implementations work, and how an eventual ideal out-of-protocol implementation would look (and the in-protocol end-game).

In the past, the way based rollups were generally thought to be implemented in a way that was likely to either be cost-heavy, put significant pressure on existing proposers (and provide terrible UX) or be dependent on actors and middlemen that were outside the realm of usual Ethereum participants. This was because there were a lot of discussions specifically around having L1 validators also actively sequence and execute based rollup transactions (essentially turning it into a single chain, although with compression happening off-chain). Other ideas have centred around opt-in/opt-out but outside MEV-Boost, which, as we know, is responsible for most of the built Ethereum blocks - making an active integration out-of-protocol much more difficult to manage and gain traction for. As you’ll see later, we believe at least a first implementation of “efficient” based rollups is likely to happen within the MEV-Boost sphere of influence, as it makes integrations and conformity much easier.  

In any of the below examples and mentions of rollups keep in mind that compressions happen off-chains (and data posted to the L1 is done so in compressed form). We’re pretty used to this from existing L2s with their sequencers handling this work (and full nodes keeping the full state). In a based rollup, the compression work is a larger question since, in the below Taiko example, anyone can do this compression. In a MEV-Boost example this is likely done by searchers and builders that are also running full nodes on the based rollups. One caveat to make here is that similar to any other blockchain, the incentive to run a full node has to be created by there being significant traction on the based rollup. Either the amount of activity on the rollup has to be significant enough so that someone does the compression work or that searchers and builders become active there. Or in the initial bootstrapping phases they have to be additionally incentivised.

In terms of live implementations of based rollups on Ethereum to date, the most obvious example of this is Taiko, which functions quite a bit differently than described above. It also operates in a manner quite different from what a more integrated (pre-endgame) solution might look like. We give an overview of how Taiko operates below:

Taiko employs a separate L2 mempool where searchers participate in a just-in-time (JIT) auction to construct the most valuable L2 batch, similar to how Proposer-Builder Separation (PBS) operates on L1. These searchers bid to have their batch included by an L1 block builder, who selects the most valuable batch. This model can lead to L2 block builders competing to extract maximum MEV, mirroring L1 PBS.

In this setup, to get Ethereum synchronicity and composability, you would need the leading proposers and the known look-ahead subcommittee to be participants in the based rollup scheme. This is not the case at the moment, and blocks/transactions are, in theory, just forced in - which is very akin to centralised sequencers of today’s rollups.

An eventual out-of-protocol implementation of based rollups that fits into the current block-building pipeline (MEV-Boost sidecar) with full participation would likely be the next step in achieving the properties that most application developers wanting to build a based rollup are looking for. These properties are generally:

Properties:

• Composability
  - Atomic Inclusion; guarantees from one or more actors that a set of transactions will be included on domain(s) or none of them will
  - Atomic Execution guarantees a set order of execution (for example, via pre/post state commitments). It is needed for composability between applications.
  - Synchronous Composability; cross-chain contract calls.

  • L2 txs conditional on L1 state are possible today; in the other direction (L1-L2), you either need to prove state is correct at sequencing time (real-time validity proving) or the L1 sequencer set needs to be the same as L2 (hence integrations and collateralisation)

• Cross-Rollup Interoperability 

• MEV Retention/Internalisation

• Derive Ethereum security

• Customisation/Specialisation

• Fork Choices
  - Fair Ordering
  - Validity Conditions (oracle, gas token etc)

• Fast UX (with Preconfirmations)

A noteworthy mention of the MEV retention/internalisation aspect is that in most of the proposed setups, the Ethereum validators (inclusion powers) still hold quite some power, as they ultimately decide what gets into the block (and what doesn’t). As such, they will want to be paid some amount. You can almost picture rollups as searchers in the current paradigm (and as such, can derive some value from an auction).

What is very clear from the current state of Ethereum (and other monolithic chains) is that there’s a large number of applications yearning for customisation, specialisation and MEV retention while deriving Ethereum security (and synchronicity). We’ve previously covered the reasons for a modular setup quite in-depth in the articles here, and here as well as two recent presentations we did on why app developers will build modular here and here.

A MEV-Boost sidecar integration would likely end up looking somewhat like this, keep in mind that this requires that builders integrate with the supported rollups (unless we go straight to a MEV-Boost relay-esque setup, although this loses many of the above powers). The builders would likely end up as increasingly powerful entities, something we’ll get into later. The proposers are also required to opt-in (as they currently do with MEV-Boost), although if profits are higher for proposers running such a based rollup side-car, then others are likely to participate too (as most profit-seek).

Keep in mind that the L2 ticket auction is likely to be done in advance (in terms of which L1 proposer is supposed to include what L2 block). This is because the based rollup gateway protocol needs to ensure that the proposer has opted into the based rollup scheme. The gateway will know this since we also have the look-ahead of future proposers in the current/upcoming validator subcommittee (and can see who has opted in)

There are already a few proposals for how such an implementation might end up looking on Ethereum (both on the preconfirmation level but also with how based rollups would fit in):

For based rollups:

• Spire

• Taiko/Gwyneth

• Init4

For preconfirmations:

• Chainbound

• Primev

• Nethermind

• Commit-Boost

• Luban

However, there's no clear view on how this is going to be implemented fully (as in all MEV-Boost validators and builders participating), but it's very clear that these things are coming, and they're coming outside of the core protocol first.

There's also a clear desire to better support based rollups from within the core Ethereum community. Here we are specifically referring to wanting single slot finality but also faster block times - which lends itself much better to based rollups. These things are, as with most upgrades on Ethereum - quite far out. Preconfirmations/proposer commitments, on the other hand, are already in production both on mainnet and testnets - although they're seeing some considerable backlash from members of the community (again, centralisation concerns - we'll get into these more as we continue).

There are also some other interesting ideas (to provide preconfirmations) that make use of partial block building within a single MEV-Boost auction, by running several auctions within the usual timespan of one. In Based Preconfirmations with Multi-round MEV-Boost by Linoscope (Nethermind), the idea is that you have a fixed number of faster rounds in the MEV-Boost auction, where you build (and sign) a partial payload (of a block), this signing (from the proposer) acts as a preconfirmation. The full block (with the partial payload(s)) is then propagated as normal at the end of the normal slot. XGA above also makes use of similar ideas. However, instead of splitting up one auction into more, they split blockspace into two lanes - priority and non-priority. This is done to provide the ability (without enabling too much MEV) of selling future blockspace that is less leaky - meaning validators would be selling access to the non-priority blockspace (for preconfirmations). 

Keep in mind that things such as slashing, registry, and pricing are kept out for simplicity's sake

A preconfirmation protocol, as outlined in the diagram above, could be similar to what the Spire team proposed in their Preconfirmation Gateway; see here. The proposer/preconfer (likely having delegated the sequencer role) is known in advance via the Ethereum proposer lookahead. In the case of no active sidecar participants in the lookahead, a based rollup could likely use a fallback mechanism to elect a sequencer. Other use cases for the fallback mechanism (h/t mteam) could also be if a participant in the preconf sidecar has been slashed (or is out of collateral) 

While much of the above has focused on the intricacies of Ethereum and its road towards providing a platform for based rollups to shine, there are also other networks that can support them. Below, we will cover some of the places where based rollups can be built and networks specifically built to support them.

In terms of networks that could support (and are built to support based rollups) there are quite a few. Here is especially worth noting shared sequencers, which are essentially networks for sequencing (based) rollups:

• Shared Sequencers

  • Astria

  • Espresso

  • Radius

  • Nodekit

• Data Availability Layers (w/ Consensus)

  • Celestia

  • Avail

• Fast Monoliths

  • Solana (large ecosystem + properties that allow for efficient based rollups)

To summarize, based rollups are:

An off-chain state machine that delegates the sequencing of its blocks to the underlying layer (and its proposers). The sequencer is generally the winner of an auction or leader election (such as Ethereum's subcommittees and their subsequent slots). This sequencer is, in most cases (to avoid overloading), likely to be a proposer (that’s a part of the underlying layer’s set) tasked with inclusion; while it delegates/outsources the execution, constraints and building of the rollup block to more sophisticated actors (builders) - ala MEV-Boost.

Now that we’ve covered the whats of based rollups, it’s worth spending some time on the hows. There’s obviously nothing wrong with launching a based rollup right now, but quite a few changes have to be made around or on the baselayer to really support them in a way that makes them comparable to non-based rollups.

Obviously, it would make a ton of sense to have based rollups on a chain that is more suited to it (such as one with faster block times). However, since we're obviously interested in leveraging the decentralisation, censorship resistance and users alongside the liquidity of Ethereum, there are quite some changes needed here.

Although based rollups would also make a ton of sense on a Solana because of the faster/continuous slots, changes would need to be made (ie. sidecar) for sync functions to handle synchronous composability. Some interaction with Jito here (ala MEV-Boost) probably makes a lot of sense as well for the auctions and delegation. 

We've already mentioned a few of the requirements above, but let's cover all of them (to the best of our abilities) that we see as key to based rollups on Ethereum, Solana and Celestia.

For Ethereum, the requirements (for proper UX and the gaining of the properties outlined further up):

• Preconfirmations

  • Inclusion guarantee

  • Execution guarantee

  • In/out of protocol 

• Integration into the block building pipeline (MEV-Boost) via sidecar for based rollups with preconfirmations

  • Custom block validity rules

  • Super-builders

  • Spectrum of guarantees (sequencing/validation) 

  • Sidecar for synchronization

• Not overloading Ethereum consensus (hence the spectrums above)

• Non-builder+relay full node runners

• Faster block times (Vitalik was recently pushing for 2-4s, however; this is probably quite far out as we'd need significant changes to the protocol specs and consensus) - faster block times would also make preconfs less important, although integrations within schemes help improve synchronization.

• Keep in mind that the 12s block time is worst case scenario, most users aren't sending transactions at the beginning of a slot (median inclusion time likely to be 7 seconds when accounting for latency and end-of-slot non-acceptance of txs within MEV-Boost)

For Solana, the chain actually lends itself extremely well to support-based rollups. It has "fast" (in this case, continuous) block times, which provides fast deterministic consensus (a wanted property in the absence of preconfirmations for based rollups). There are, however, still issues that remain here, for example:

• Integration into the growing block-building pipeline in Jito

• Side-car for sync functions and synchronicity 

• Not overloading Solana validators (already heavy requirements)

  • Super-builders?

• Decentralisation of block building pipeline 

On a side note, we're already seeing based-like structures (ZK Compression) come to market on Solana, alongside renewed interest and funding in projects enabling/building rollups on Solana. ZK Compression, in some ways, works a lot like a based ZK-validium. This is generally because even though Solana is obviously an extremely efficient single state machine, it is becoming rather bloated - and apps don’t have customisation control nor mev internalisation.

For Celestia, there are actually a lot of properties that lend themselves very well to based rollups. There's the ease of verifiability with light clients, plenty of blockspace and a "lazy" base layer that provides consensus. There are a few changes that would make it even better for based rollups:

• Faster block times for better UX in the absence of preconfirmations

• Standards for cross-based-rollup interoperability (preferably atomic)

• ZK accounts for base layer asset velocity (preferably coupled with real-time proving)

As mentioned above, there's quite a spectrum of how based sequencing can be implemented natively (or out of protocol) to allow synchronization. This spectrum is quite relevant in the current (and older) discourse since it very much fits into the "don't overload Ethereum consensus" and the grace of homestakers. Many of the implementations that would allow for execution and sequencing guarantees (from the entire or a subcommittee) of validators would very much overload Ethereum consensus. As such, we find it vital to cover this topic a little bit more:

• Based Sequencing

  • Sequencing is done by a subset (or the entire) underlying layer's proposers - meaning that they'll need to run execution full nodes and actively build blocks

  • Overloads validators with state bloat, hardware requirements and vertical scaling

  • Likely to be delegated to specialised actors - the rise of super-builders

• Based Validation 

  • Sequencing is done by sophisticated actors specialised in block building, constraints and pricing

  • Inclusion guarantees are provided by proposers initially, and proposers might validate the execution validity later on (this is likely still an overload of current proposer specs, and we're likely to only get inclusion guarantees as outlined below)

    • In a perfect world, the L1 proposers would be sophisticated enough to handle all load (network/compute) and run L2 nodes. However, this is unlikely, and it is reinforced by their likely unavailability to price pre-confs/based roll-up blocks themselves. Hence, delegation.

Furthermore, as we've also seen, there are, at least pre-faster blocks, a need for preconfirmations. There's still much debate about how this will get implemented, but it's certainly worth considering already. As a refresher, preconfirmations are commitments about future inclusion or execution provided by proposers or delegated actors that have the ability to lock or provide access to state at designated times. In based rollups, this is significant because proposers can provide guarantees that a rollup block will eventually be executed/included. There is obviously likely to be a significant slashing of bonds imposed onto actors in such schemes to ensure that commitments are honoured. This is in an ideal world in-protocol since out-of-protocol reverts to social slashing by a small subset of people rather than the entire protocol's social consensus.

• Inclusion Guarantees 

  • Delegation of execution, block building and sequencing

  • Guarantees that blocks/txs will be included in a block (but not that they'll be executed by execution clients) or put in a specific order

  • Inability to ensure composability between applications 

  • Easier to price

  • Collaboration by the outsourced sequencer (builder) and proposer (relays likely play the usual role, although strain here is likely too)

• Execution Guarantees

  • Real-time validity proving or collateralisation.

  • Puts a heavy strain on proposers

  • Harder to price

  • Important if we consider that based rollups might synchronously touch the Ethereum L1 state - wherein app composability requires execution guarantees

While preconfirmations are quite limited in use at the moment, the wider scope is extremely broad and can provide a rather flexible baselayer for proposer commitments. The current properties of proposer commitments (outside of preconfirmation/commitment sidecars) are limited to state confirmations at block construction (meaning every 12 seconds). However, there are already a few out-of-protocol commitment schemes (such as Chainbound) that can enable the proposer to issue commitments to others about their specific block while supporting a key based rollup property in inclusion preconfirmations. Which, as outlined above, is something we're extremely keen to have. If you're interested in out-of-protocol preconfirmations, we highly recommend this talk by the Chainbound team.

Beyond just faster blocks for better UX, there are also other key points that preconfirmations would bring to the table (beyond being used for based rollups). Here are things such as: 

• Solvers/Chain Abstraction UX

• MEV mitigation/capture

The endgame of proposer commitments is extremely broad, and the general idea is that they'll be able to support even more use cases, such as:

• Partial block building (multiple concurrent proposers)

• State preconfirmations (synchronicity/sync functions) + cancellations

• L1 blockspace auctions and claims

In terms of in-protocol commitments and block proposal rights, there are several proposals and implementations being discussed, such as Protocol Enforced Proposer Commitments (PEPC) and Execution tickets (ET) (+ attester-proposer-separation (APS)). ET is seeing significant focus as they would allow for an in-protocol market (lottery) for block proposal purchasing rights. The idea around APS is that you split L1 validator roles into two separate ones - an Execution and a Beacon (consensus) proposer. The former would be tasked with proposing the block payload (the building of this is likely outsourced to builders, or we get builders to play this part). The latter (beacon, or attesters) would be tasked with voting on set block validity rules (especially important with based rollup blocks as more rules are likely outlined) and constrain execution powers through inclusion lists. This is likely (especially in a world of super-builders and centralisation concerns around preconfirmations and based rollup) to provide higher censorship resistance. If you're interested in preconf history (check this out).

As you might have noticed over the course of this article, there's a lot of delegation and outsourcing of work to more specialised actors either in the name of avoiding overloading or to ensure better market efficiency. What this means is that, and what it leads to has been happening for a while on Ethereum - a clear road towards putting most of the hefty work in the hands of the builders (highly sophisticated entities). This is leading to what has been coined as "super-builders".  The group of current builders within the MEV-Boost pipeline will likely also play key roles both in protocol (and out) for based rollups, preconfirmations and commitments.

The reason for why is quite clear, we don't want to overload Ethereum's consensus. We can't require every proposer to be as specialised, nor are they able to. It's general market forces, but it does lead to centralisation, and with that comes many risks. This is already in effect today, with 3 builders building the vast majority of Ethereum blocks today (with two of them, Titan and Beaverbuild, building almost 80%!). Proposers today also have an extremely trusted relationship with relays (which is hoped to be lessened by the advance of ePBS, although this is still not clear yet)

The builders are likely (in a based rollup case) going to be running full nodes on the rollups for sequencing, execution guarantees and block-building reasons. At the same time, they need to be able (in the preconfer case) to price these blocks/bundles correctly (some builders might outsource this preconf pricing to searchers). Inclusion guarantee preconfirmations are much easier to price, while execution guarantees require significant sophistication, and are still an open question.

On the subject of based rollups, a super-builder can generally be thought of as a specialised actor that isn’t building for a single chain (Ethereum) but a group of them (Ethereum+Rollups). This is needed, especially if we want intra-block synchronicity and cross-domain rollup interoperability. To some extent, you could also view Optimism's Superchain sequencer/builder as a super-builder of OP-Stack chains. As well as the decentralised sequencer networks of Astria/Espresso (but more multi concurrent, if no single leader). An interesting aspect of the delegation to builders is that a ticket holder of multiple rollups can provide inclusion guarantees for synchronous composability across these domains.

The term super-builders could also be used to refer to the extracurricular activities that they might take on outside of their original duties (building blocks!), such as commitments, and preconfirmations.

In all of these cases, we likely need significant bonds (stakes) for builders, especially with the growing work delegated to them. Preferably, a lot of these functions outsourced to them should also be provable on-chain (in-protocol) to ensure fair, robust and correct slashing. This signals an increase in horizontal scaling on the builder side (which Justin Drake offhandedly said they were fine with?). There are quite some worries here, such as multi-block MEV, a builder building for way more rollups than all others (or better at extracting MEV), and possibly out-bidding all other builders consistently. This further sophistication and optimisation are also, as with everything, going to lead to further centralisation and a higher barrier to entrance for new participants (unless they're Citadel). One thing that does seem quite clear is that at least Inclusion Lists (IL) are sorely needed in a world where builders are empowered even more.

This is all on top of the fact that the flow is increasingly moving off-chain/towards private order flow. Builders with exclusive providers (and ones that are integrated) do much better than the ones without, and these few are also the ones likely to profit the most of any based rollup integrations. This could also be worrying in the case where some applications (or Telegram bots) might have a rollup and also have exclusive flow towards a builder. Burak Öz, Danning Sui, Thomas Thiery, Florian Matthes highlight these issues well in their recent paper Who Wins Ethereum Block Building Auctions and Why?, especially around the high barrier to entry issues presented above.

An interesting caveat to this heightening of work put on the builders is that in terms of profit distribution, they're (at least on-chain) the ones receiving the least. Although since two of the three key builders are also prop shops the searcher profits are obviously much in their camp as well. Even the non-trading builders are likely to have agreements with searchers for revenue share since they don't trade on their flow. Currently, as pointed out by Yuki (Sorella/Fenbushi), the MEV to non-MEV profits are split roughly equally there's a large amount of profits kept on the table for applications, which often end up in the hands of proposers.  

One thing that it does make extremely clear is that there's a huge opportunity for applications (or projects) that allow/can capture (meaning internalising) their own/others' MEV. Clearly, in this day and age, with the amount of economic activity on-chain, it will likely mean they can outcompete those that cannot. These margins left on the table are opportunities for protocols that allow applications to become better and more efficient.

As mentioned much earlier, there are quite a few reasons why you'd build an application as a based rollup—especially if you're already entrenched and deployed on the underlying layer. Let's take an example of how an application might launch as a based rollup while keeping its existing contracts on the L1. 

In the case of Uniswap, you could have the Uniswap Router live in the based rollup, and have applications make calls through the rollup (meaning Uniswap would get to hopefully internalise part of the flow that runs through them via an auction). For example, an intent protocol that would want to touch L1 Uniswap liquidity would have to make the call through the router on the based rollup. 

This would likely also play alongside synchronicity to have functions created as a result of based rollup actions that could be executed on the L1. This would be interesting since applications would have access (at least read) to Ethereum and in the future, possibly make calls to and from its smart contracts. This is something that especially Uniswap would want since many applications are making calls to its routers/contracts every single block (think most of the intent protocols, and many others). The same goes for Aave, Maker and so on.

In the case of how a Uniswap (and all other applications that would want to internalise their MEV revenue) might pick a sequencer, it would likely be one that is willing to pay to sequence a block - which would mean returning some value to the application. In a world of a few of these types of actors, the likelihood of it reaching the exact total amount of possible returnable value is quite low, unless all actors have complete information symmetry between them and are able to all bid to the upper limit (although at this point you'd expect some collusion to start happening). 

• As is probably clear throughout the entire article, there are significant assumptions around how this is all going to end up and how it affects certain aspects of the protocols we use today. The timeline is also unclear, especially when its related to things in protocol. 

• However, what is clear is that there’s a large ecosystem of applications on very well-developed monolithic chains that yearn for the ability to customise, internalise, and derive security while being composable. 

• Order agnostic sequencing for specific applications (ie. see our ordering article) - not just MEV internalisation, but also verifiable sequencing rules, frequent batch auctions, fair ordering etc.

• Rollup specific fork choice rules (eg. valid blocks only if oracle pricing update)

• Optimal block validity (beyond highest fee), can be quite arbitrary (something different than => maximise value for example)

• Block builder sophistication and horizontal scaling needs more research around the danger (+ multiblock mev, block bids); how does this change with opcodes/gas limits/VMs/fork choice rules specialisation. 

• Partial block building + Multi concurrent proposers

• Constraining block builders with in and out-of-protocol Inclusion Lists

• Pricing for non integrated builders if delegated to (out delegate to searchers?)

• Rollup payment for orderflow

• Continuous block building (ala Shreds on Solana)

• Timing games and effects (+ attester wrong head votes)

If you're an application currently living on a monolithic singular chain and you're interested in exploring how you might be able to start taking advantage of aspects of modularity (as we've touched upon many times over the past year) while staying composable and aligned with the underlying layer, feel free to reach out to us. 

Further Reading: 

• https://research.chainbound.io/examining-the-based-sequencing-spectrum

• https://ethresear.ch/t/based-preconfirmations/17353

• https://mteam.space/eth-sequencing-preconfs-resources/based_rollups.html

• https://github.com/spire-labs/poc-monorepo

• https://ethresear.ch/t/based-rollups-superpowers-from-l1-sequencing/15016

• https://scalability.guide/posts/forced_vs_based/ 

• https://blog.20squares.xyz/preconfirmations-splitting-the-block/

• https://mirror.xyz/preconf.eth/3SXageNPpcQMz8L2YfW5ipvthNl-InPzaPAfb3LxwqA

• https://vitalik.eth.limo/general/2024/06/30/epochslot.html 

Thanks to Mathijs van Esch (Maven11) and mteam (Spire) for review.

The wider crypto community has long had a complements problem. The vast majority of products, infrastructure and security derivable haven't been commoditised, and building applications with more control is expensive. This is changing.

The idea of commoditising your complements was widely popularized as a concept back in 2002 by Joel Spolsky (Read the entire piece here if you're interested). The core goal of it is to increase profitability, innovation and user acquisition. This is a result of commoditising your complements (the things your applications rely on) e.g. API costs, hardware, and user acquisition (for example, offering some free software that gets you into their ecosystem) which can also lead to success for things you're either reliant on or directly involved with.

What we're starting to see happen for several different parts of the modular stack is that there are several competitors for every single service. This also means that competitors now have to start to differentiate, be cheaper, white glove services or give out grants to attract new developers. This is a vicious cycle as you're forced to give away significant incentives or time. One method to attract developers in this case could be to develop open-source software that is competitive (and cheaper/free) that acts as a funnel towards the project. A good example of this is the creation of various SDKs such as Rollkit. We are starting to see now that data availability, to some extent, is commoditized (there are obviously degrees of quality to that blockspace which we won't get into right now). This commoditization also means we're seeing a large influx of rollups of all shapes and kinds being developed. This "commoditization" of blockspace (specifically data availability, but we expect to see this happening with other parts of the modular stack as well) led by lower prices, has increased demand.

Another example of this we like to use is sequencing, and how that relates to Rollups-as-a-Service (RaaS). As mentioned previously, we see shared sequencers as the premier RaaS providers of the future. They're able to provide the service much cheaper with the added caveat of composability. Beyond that, it also makes it a lot easier for the RaaS provider (the shared sequencer), in this case, to monetise via economies of scale. Shared sequencing and those aforementioned economics can be compared to some extent to the way Visa operates. It is essentially a volume-driven business with relatively thin margins on a per rollup business (although you're able to take a sequencing fee, and perhaps some notion of MEV). Visa's margin is quite thin, yet its revenues are substantial. If we could make a prediction of where we see the vast majority of RaaS customers going (beyond the ones needing very specific, white glove services), we foresee them going to shared sequencers such as Astria, Espresso, Radius and Madara.

Beyond lowering the cost of your complements, commoditising your complements also ties into the idea of growing the market around you (the things you are dependent on). This will lead to creating value for yourself; while creating moats and monopolistic tendencies around your product. We especially see this in Web2 with open-source software, though this is likewise becoming a trend in Web3. This could also be something as simple as a Tesla wanting to lower the cost of making batteries since they're dependent on them in their cars. Or, in blockchain terms, a chain wanting to lower the cost of key aspects of it; such as having low-cost hardware sample data availability (e.g. Celestia)
On the topic of "growing the market" around you and, as such, growing yourself, one "crypto-native" idea of growing the surrounding market we see is airdropping to the protocols you are utilising in your setup. This is likely to grow the user base of the underlying and direct users, narrative, and attention towards your product. After all, at the end of the day, one of the most powerful aspects of blockspace is its alignment. Although, realistically (in a perfect market), it's based on quality (deterministic, block times), ease of verifiability, liquidity on top of it, cost etc.

Inefficient systems, high costs, and the inability to customise applications stiffen innovation. Commodification removes hindrances to innovation and allows developers to think outside the box, as they're not held back by costs and shackled to a set rulebook. Crypto is more BD/attention-driven at this point, but as the industry matures, this becomes more vital.

This can also be applied to how we build applications on/with blockchains. I started touting this idea during and before ETHDenver, starting with the idea of controlling ordering (while retaining security) as an application - and how this can help monetisation, customisation, and valuations. We think a few general examples will help explain how and where you can start to see this commodification happening and how you can take advantage of it.

• Data Availability (Celestia, Avail, EigenDA)

• Rollup SDKs (Sovereign, RollKit, OPStack, ZKStack)

• Shared Sequencing (Astria, Espresso, Superchain etc)

• MEV-alignment + Auctions (SUAVE, Intents)

• Economic Security (ICS, Eigenlayer, Babylon)

• Solvers (Outsource execution and pricing)

• VMs (zkVMs)

Now keep in mind some of these have been commoditized already to a certain extent, while others are still to be. Some (like solvers) are less likely to be and are instead forced to be incentivised to present the best possible outcomes. Although, there's a case to be made that solvers are likely to become commoditised (as market makers have been) over time - although, as with searching, there are always ways to improve (but less "clear" in a perfect world).

Specifically, regarding the latter commodification of zkVMs and its effect on the surrounding complements (such as rollups), we're seeing teams build generalised zkVMs rather than custom circuits. This is becoming possible by running the rollups' State Transition Function (STF) in Rust through compatible generalised zkVMs such as Risc Zero and Succinct. While a fully-fledged custom circuit zkVM for a certain blockchain VM is definitely more optimised, generalisable ones are catching up. This also means less maintenance and upgrading as the VM in question progresses. Sovereign Labs (one of the SDKs mentioned above) is going down this route. This provides a large degree of customisation on the application logic (such as custom/specific changes) while retaining the scalability and security of ZK. Another important point to add is also on the ZK acceleration part of things. Optimising software and hardware acceleration for specific schemes, algorithms and VMs is much easier for a generalisable VM than for specific use-cases where a custom circuit setup is used. Integration efforts are also likely to be much easier, and more prudent for hardware acceleration companies since there would be a larger possible customer base to tap into. This is something we're already seeing with companies like Ingonyama where integrations with specific highly utilised products are prioritised. This means as a user of a generalisable zkVM, your "customer support" is generally going to be much better. 

While many of these zkVMs are providing it open-source, one might ask where the monetisation comes from. One thing that has become quite clear is that, especially in web3, monetising software (specifically open-source) is quite difficult (as covered here). However, as explained earlier in the commodification of complements, providing open-source software by for-profit companies is not a new idea; rather, it is used as a funnel. Risc Zero is a great example of this, utilising their open-source zkVM to funnel developers into their ecosystem, who are all potential customers of "monetisable offerings" such as Bonsai. This is a trend we're likely to see also happen with Succinct, Modulus and other ZK companies.

The baseline is that as the prices of a product's complements decrease, the demand for the product increases. So, if an Ethereum with higher gas limits and block sizes, alongside pruning and keeping active state on disk, in memory, would decrease the cost of using Ethereum - the usage of Ethereum would, in turn, increase. And the greater the demand, the larger the profits.

To give a clearer overview of how we're looking at utilising commoditised complements within the modular stack, let's look at how this could potentially look for an application developer looking to build an application-specific rollup to take advantage of customisation. It is important to note that to an end user, this optionality in design choices will all be abstracted away. Essentially, the end goal is to provide web2 UX but with web3 security. 

In this case, an application built as infrastructure (rollup) has outsourced much of the work to its complements and is instead focused on providing the best possible product and user experience without having to deal with orchestrating everything that makes an efficient blockchain, efficient. 

What this also signals is that the ever-famous API Economy of web2 seems to be coming to crypto as well, slowly, but surely.

Now, when you open up and commoditize the complements you surround yourself with, you can also customise and specialise your specific infrastructure and environment to your application and, therefore, the end consumer's needs. This is specifically something we covered during our last piece on ordering. However, there are other important aspects and needs of developers that go beyond that. One point that is important to get across is that offering choice is not a bad thing. Choices and free permissionless markets are in our opinion extremely vital for innovation. Ultimately, at the end of the day, customers will, through market forces, settle on some number of products that they deem viable.

A few examples of this are (beyond the fair ordering, verifiable sequencing rules and MEV-extraction ideas that we presented in our previous article):

• Resource Pricing Efficiency (beyond the fees paid for complements)

• Warehousing of blockspace

• Custom OPCodes, Precomplies, Curves (e.g. Aligned-esque setup)

• Alternative VMs

• Gaslimits & block times

• State DB/Merklelisation optimisations - hardware changes

• Formal Verification

• Monitoring & Response w/ Fraud Proofs and Assertions on an ordering level - there's an entire discussion to be had here on "good" censorship as well. 

• Oracle Extractable Value (OEV) w/ Protocol-Owned-Oracles (BBOX/Warlock). Providing this with high degree of "security" can be done on a rollup level much easier.

One very important fact to note is that the commodification of complements is not always used in a collaborative or "friendly" way but rather as a way to make competitors irrelevant. These forrays can be used as attempts to commodity another project elsewhere in the stack, or even defend against others doing the same. This is also visible within the crypto VC space as well, for their portfolio companies (whether unintentional or not is a different discussion); such as the high rate of releasing open-source software that directly competes with others (and helps portcos).

Crypto applications have for long also been either prone or likely to participate in vampire attacks on protocols that might have common interests with one another. While in theory, if either side grows, they all grow (and their complements with them). For example, AVSs grow if Eigenlayer grows. Rollups on Celestia grow if Celestia grows. Ethereum grows if Ethereum rollups grow. Infinite games as the Eigenlayer community likes to put it. Although there are some nuances here. For example, a larger number of AVSs utilising the same compounded economic security, the higher the slashing risk (and social layer fork chances), and the more of the same competitor - the less revenue goes to each. In some cases it also depends on the layer you're deriving from. E.g. in a settlement layers case (where execution and liquidity also exist on the baselayer) rollups could be seen as parasitic. For a DA layer, it is its sole purpose to provide a service to rollups, and the more, the merrier.

As we mentioned earlier, there are ways for applications to gain customizability and control; however, it is often at the expense of security. The reasoning for building these applications, as infrastructure - is that it allows us to retain the aforementioned powers while deriving security from elsewhere. Now, there are several ways in which this can be done, let's cover some of them:

1. DA (last bastion of truth) 

2. Settlement (censorship resistance of dispute resolution)

3. Consensus (shared security model)

We made an argument during our "Building Applications with Modular Infrastructure" presentations that The Third Time is Not the Charm - Why is this?

First of all, there’s added cost to crypto economic providers (the operators running new state machines and runtimes). Furthermore, instead of paying some DA or Settlement fee, you have to pay for this received economic security either via some % of fees (which might not even cover the operating cost or pay enough of an APR to warrant providing economic security). The other, and less ideal possibility is that you pay some % of token incentives (but then you're adding consistent sell pressure to your native token). This is also one of the downsides of running a full-fledged app chain as a smaller application, beyond the orchestration task. 

Launching app chains is generally reserved for larger applications that want no dependencies, are okay with the orchestration overhead and are able to pay a large set of infrastructure providers for services. Both the incentives in the shared security and app-chain model get worse, specifically for applications with LPs, who have to pay some set yield to attract liquidity providers and offset Loss-Versus-Rebalancing (LVR) to some extent (although there is some very interesting LVR research and implementation work being done by several teams, such as Sorella Labs). Take the case of Osmosis, for example, they're paying emissions to stakers and infra providers, while also paying out rewards to LPs (double dipping on emissions) - 10,21% inflation and around $10M to LPs a year.

In the shared security cases, there's also the possibility that you've opted in to provide some set amount of security (that might not be available in the long run, in the case of airdrop hunters, so retention is super important in this model as well) that you might not be able to opt out of in the case where the receiver is now losing the operator money on hardware and DevOps.

Then there's also the added slashing conditions (risk) that are done via social slashing for most of the shared security models. This results from operators and restakers being opinionated on the outcomes of the state machines they're providing security to. In the case of just inheriting data availability security, this is not the case as data availability providers are unopinionated on the data they receive, their job is just to provide fast and deterministic proofs of this data having been made available. I.e. the validators and light nodes on a DA layer like Celestia are not running full nodes on supported rollups. We make the case that experimentation, customisation and specialisation are also possible while inheriting the last bastion of all truth for blockchains - data availability, from which all state derives. You essentially just pay the (now commoditised) DA fee, execution and state storage costs - while allowing applications to take significant overhead profits without having to incentives with their native token.

However, these shared security models allow some very interesting, original and unique setups to experiment with large amounts of security. Nevertheless, these systems end up looking like singular chains/state machines as operators are needed to run opinionated runtimes for every single network they support - losing significant scalability. However, some of this is offset by the fact that you can indefinitely compound this cryptoeconomic security, at the expense of significant risk - especially in the case of large slashing events that could have large second-order effects on the pegs of the various protocols built on top.

Many applications want the power of an app chain but cannot afford the security budget or deal with the orchestration associated with it. With the extensive number of available DA, settlement, and shared security protocols, launching modular app chains is becoming readily available at a fraction of the cost.

While the execution layer in these cases is quite centralised (depending on the utilisation of a decentralised shared sequencer or not), we do expect to see small sets for some liveness protection (although client diversity here would also be interesting to see). However, in the cases of a settlement layer underneath forced exit withdrawals are possible on L1 native assets. The smaller sets of sequencers (validators) also mean a much lower hardware cost (while retaining security). This can allow for some extreme levels of specialisation (i.e. MegaETH and Eclipse). Seeing this execution layer focus on performance (both on a VM and DB level) is extremely promising since giving up performance does mean giving up certain use cases (and, as such, users). 

As we’ve alluded to throughout the article, while distributed and decentralized systems relying on consumer hardware for security and verifiability is a thing of beauty - they’re not very efficient for scalability. Although performance suffers, it can be used to build certain efficient services (such as data availability sampling), which most rollup-centric layers seem to be going down. By deriving security from these layers (specifically the last bastion of security, DA), we can optimise performance and even remove “throttles” like consensus from the layers where execution and merklelisation happen. We’re seeing this happen with rollups building with extreme optimisations and hardware requirements on top of extremely decentralized baselayers and networks from where they derive security. At the same time, they’re able to retain control, lower cost, and stay “secure” (there’s a lot of nuance here, as is hopefully clear by now. 

For example, instead of running 1000s of highly optimised, expensive bare metal hardware - you could run a set of sequencers (for liveness) that outsource DA/Consensus to an efficient layer for a fee (rather than inflation to infrastructure providers). A good example of this is Eclipse:

We’re also seeing this with applications or communities that don’t want to deal with the orchestration of hardware and optimisations that rollups require (either on the SDK or sequencing level) and outsource these at the cost of some DA and sequencing cost (while retaining some control with integrations to SUAVE-like setups). This can be done by utilising Astria and Sovereign Labs, which can handle most of the heavy lifting while providing a very efficient setup.

The only costs beyond this are the RPC and Archive nodes that need to be in place (but even these are being commoditised). 

As profit margins get lower as users and applications demand lower costs, especially in the chase to support more and more users - so does the need to lower the associated costs with running infrastructure, especially if we aim not to inflate the native token indefinitely to support providers (price appreciation helps here, but there’s significant sell pressure as well)

What we’re also noticing is a focus on providing not just security in terms of the back-end, but also for front-facing developers via ecosystems/generalised rollups that see the need/want for more "secure" execution environments while tapping into hotbeds of liquidity. This is especially important with more "worry" that many larger funds have with participating in DeFi because of the inherent risks (reentry attacks etc). A good example of this is Movement Labs.

While there are some issues around application composability (when not in a shared sequencer environment with simulations), this is not the focus of this article - and we’ll be covering these issues (and solutions) for them later on. Specifically, inter-block between apps, but even two blocks, which is beyond what is possible with market makers/solvers and intents with bridging. We’re talking about building apps that control their own environment while being atomically composable with other applications in the delta. For this, you’d need a global succinct state layer with composers.

If you’re building applications that take advantage of modular infrastructure and its powers, feel free to reach out to us. We’d love to talk!

The reasoning behind building modular shouldn’t just be to fit into a narrative, nor just for the sake of it — but rather because it enables us to build better, more efficient or customisable applications. Many incredibly unique capabilities open up when building modular and specialised systems. Some of these are more obvious than others to the naked eye, while others are less obvious unless told. As such, we aim to provide a general overview of modular systems' powers beyond those you already know, such as scalability. 

We feel that one of the powers that modularity provides a developer is the ability to build highly customisable and specialised applications that bring a better experience to the end-user. An example of this, which we’ve previously discussed on a high level, is the power of setting rules or reordering the sequence of which transactions are executed.

Verifiable Sequencing Rules (hereby VSR) are one of the interesting opportunities that controlling ordering provides, especially for a developer interested in building a “fairer” trading system in terms of execution.  Obviously, the relationship of Loss-Versus-Rebalancing (LVR) for liquidity providers is slightly outside the scope of this article, so we will refrain from touching upon this too much. Keep in mind that the setup we’re going to explain is primarily for an AMM and not an order book model — although the specialisation, low cost and customisation of opcodes/gas limits (or even alt-VMs) that modularity provides could be used to build very efficient on-chain order books that derive scalability, deterministic DA and more from an efficient underlying DA layer. Furthermore, CLOBs (or even CEXs) would also benefit greatly (from a trust perspective) from utilising verifiable ordering rules catered towards their particular setup. In off-chain setups, some notion of either zero-knowledge or optimistic execution backed by crypto-economic security would obviously be needed.

VSRs are especially interesting when we consider the fact that most non-informed flow (retail users) haven’t (or are unlikely to) adopt protection methods. Neither have most wallets/DEXs implemented private mempools, RPC or analogous methods. Most trades are submitted directly through front-ends (whether that is an aggregator or a DEX’s frontend, although the rise of intents helps somewhat here). As a result, unless applications directly interfere with how their flow and orders are handled, the end-users are likely to be provided with less-than-ideal execution. 

The power of VSRs is evident when we think about wherein the transactional supply chain sequencing lies. It lies where transactions get ordered (or included) by a specialised actor, generally based on some auction or base fee. This ordering is incredibly important; it determines what transactions get executed and when - essentially, the one who holds the power of ordering holds the ability to extract or be paid to extract MEV, often in the form of priority gas fees (or tips). 

Because of this, it can be interesting to write rules on how sequencing should be handled to provide fairer execution of trades (in a DEX setup) to the end-user. However, you should largely refrain from such rules if you're building a generalised network (you'll end up hurting some).

Additionally, because some MEV is important; arbitrage, liquidations, etc. - one idea is to have a "highway" lane at the top of the block (ToB) specifically for, perhaps, whitelisted arbitrageurs and liquidators who pay a higher fee and share some of their revenue with the protocol. 

In the paper Credible Decentralized Exchange Design via Verifiable Sequencing Rules, Matheus V.,  X. Ferreira and David C. Parkes present a model where the sequencer of a block is constrained to a set execution ordering rule (and those constraints are verifiable). In the case of non-compliance with the set rules, a watcher could generate a fault-proof (or since the constraints would be mathematically verifiable, you could also imagine a ZK circuit with those constraints with a ZKP acting as a validity proof).  The main idea is essentially to provide the end-user (trader) with an execution price guarantee. This guarantee ensures that the execution price of a trade is as good as if it were the only trade in a block (obviously, some degree of latency is involved here if we assume a Buy/Sell/Buy/Sell ordering based on first-come-first-serve). The base idea of the proposal in the paper is that these sequencing rules will limit the builder (in a PBS scenario) or the sequencer only to include trades in the same direction (e.g. Sell/Sell) if they’re executed at a better price than what was available at the top of the block (or if there are simply no more swaps in the other direction following them). Furthermore, if there’s a situation where you have a sell at the end of a long range of buys, then this sell would not be executed (e.g. buy, buy, buy, sell), which could indicate a searcher (or builder/sequencer) using those buys to move the price in their favour). This essentially ensures that a user is guaranteed by the protocol’s rules that they won’t be used to give a better price to someone else (i.e. a lot of MEV) or given a poor price slippage as a result of priority fees. Obviously, the downside of the rules here (in a situation where there’s either a large number more sells than buys or vice versa) is that you’re likely to be given a relatively poor price as long tail. 

Having these rules as a pure on-chain construct is nigh on impossible with a general smart contract platform, as you’re not controlling execution and ordering. At the same time, you’re also competing with many others, so trying to enforce those at the top of the block with priority fees would be needlessly expensive. One of the powers of a modular setup, where you control the aforementioned powers, is that it allows an application developer to customise how their execution environment should function. Whether that is sequencing rules, using a different virtual machine or making custom changes to existing ones (such as adding new opcodes or changing gas limits) is really up to the end developer, depending on their product. 

In the case of a rollup utilising some data availability/consensus layer, as well as a settlement layer for liquidity, a likely setup would look something like this:

Another possible idea is that of optimal swap splitting; take the case of where you have a single pool (or maybe more); how do we swap large orders (that would cause large slippage)? Is it fair for the end-user if this trade is executed across sequential blocks (or later in the block if it fits within the VSRs)? 

If the end-user cares about latency (could be alpha-related), then this particular user would likely not want to have his order split up into an order of sequential blocks. However, this is unlikely to be a common occurrence, and optimising for swap splitting on larger orders could lead to more efficient execution for the vast majority of users. Irrespectively, one worry is that MEV searchers could possibly be aware of these sequential trades and try to position themselves to be included before/after the aforementioned trader. However, the total value of extraction will likely be much smaller due to the bite-sized split trades over a sequence of blocks. 

Another interesting idea we've mentioned previously in posts is using Frequent Batch Auctions (FBA), championed by the legendary Eric Budish and co here, to process transactions in a batch auction instead of serially. This is to help find coincidences of wants (CoW) and build arbitrage opportunities into the market mechanism design. This also helps to "combat" part of the latency game in continuous block building (or priority fee wars in serial blocks). Thanks to Michael Jordan (DBA) for bringing this paper to our attention and for his excellent work in his preparation for moderating the Latency Roast (highly recommended reading material).  Implementing this as part of the fork-choice and sequencing rules for a rollup is also an interesting setup that developers can use, and we've seen it gain significant traction over the past year, especially by Penumbra and CoWSwap but also by many others (such as this paper by Andrea Canidio and Robin Fritsch). A possible setup for this could look something like this:

In this setup, there are no first-come-first-serve nor priority gas fee wars, but rather an end-of-block batch auction out of the accumulative orders during the time between each block. 

Generally, in a world where much of the trading has moved to non-custodial “on-chain” venues, an FBA venue is likely one of the more efficient ways for “true” price discovery, depending on block times. Utilising FBA also means that since all block orders are batched up and aren’t revealed until the auction has concluded (assuming some encrypted setup), front-running gets reduced considerably. The uniform settlement price is key here (in terms of providing "fair" execution) since there's no point in reordering trades (if you follow the rules set by the protocols, i.e. bond/stake is important). 

Something also interesting to point out is that even back in 2018, a setup akin to what we just presented was talked about on the Ethresear.ch forums (see here). Again, Gnosis was before their time (and have generally been very involved with most of the active research in the Ethereum community). In the post, they refer to two papers; these present a batch auction mechanism on Plasma (sort of the prequels to modern-day rollups) where each batch accepts orders to buy ERC20 tokens for other ERC20s at some maximum limit price. These orders are collected over a time interval (as pointed out earlier) and provide a uniform settlement price (USP) on all token pairs. The general idea behind the model is that it would help eliminate much of the front-running evident in popular AMMs.

Another important thing to note is that in these setups, the sequencer(s) will likely need some incentivisation to execute (and enforce) these rules mentioned above. This is often overlooked and handwaved away, but much of the infrastructure of blockchain networks are run by professional companies with completely different cost-basis than a regular home-staker. Incentivisation is, in general, an essential part of secure infrastructure implementations. In the case of incentives aligning with the rules enforced, they (sequencers/builders) are also much more likely to make a greater effort (e.g. specialise more). This means these setups should also have an active market (i.e. be decentralised). Obviously, these sorts of markets are centralising in the sense that the cost of capital to specialise is likely to be high. As such, the smartest (and richest) will likely integrate and specialise to extract as much value as possible. Here, the possibility of exclusive order flow to some actors (as alluded to earlier in the 2nd diagram) is also a possible arrow in the knee, causing an increase in centralisation if block bids are based on the highest fee/best solution, which equals winning the right to propose. A general baseline fee may be enough, but it doesn’t really push ordering actors toward specialisation or improvements. As such, you might want to introduce some notion of satisfaction of a trader’s outcome with an incentive mechanism that fits with your particular case. 

This is clear to most, but it is still relevant to mention when talking about ordering on a rollup level. If you're able to control ordering (as alluded to earlier), it allows for much easier "extraction" (monetisation arguably a better word)  of value as a protocol. This is because you control the power to reorder transactions, usually based on priority fees on most L1s (MEV-boost-esque setups). This provides you with a priority fee paid by sophisticated actors looking to extract value somewhere on the chain. These actors are usually willing to pay quite a hefty sum (up until it doesn't provide value anymore) to be able to be the first to extract the said value. However, most current rollups are primarily first-come-first-serve. Most MEV extraction happens via latency wars (and spamming), which puts severe strain on the rollup infrastructure. It also leaves out significant value to be captured. Because of the aforementioned reasons, we're likely to see more and more rollups start to implement ordering structures that have some notion of priority fees (such as Arbitrum's Time Boost). 

Another example we like to use is the Uniswap one. Currently, Uniswap as a protocol "creates" a large amount of inefficiencies. These inefficiencies get exploited by actors looking to extract MEV (arbitrage, at the expense of liquidity providers). At the same time, these actors pay large sums for the right to extract this value, but none of it lands in the hands of the Uniswap protocol, nor does it land in the hands of its token holders. Rather, a large position of this extracted value is paid as priority fees to Ethereum proposers (validators) via MEV-Boost for the right to be included at some point in a block that allows for the value to be captured. So, while a large amount of MEV Uniswap flows and ebbs through Uniswap contracts, none of it gets captured by it. 

In a world where Uniswap has the control of ordering within the protocol (and the ability to extract priority fees from searchers), it can monetise on these inefficiencies - perhaps even pay out some of these profits to token holders, liquidity providers or others. This world looks more and more likely with a move towards off-chain execution (and Ethereum as a settlement layer) with changes to Uniswap, such as UniswapX and more coming to life.

If we assume some PBS setup for a rollup, the flow and monetisation areas look somewhat like this:

From this, we can extrapolate sequencer/proposer on a rollup monetisation as a function of:

Issuance (PoS)+SumOfFees(+priority)-cost of DA, state pub, storage

A great way to see how much value (especially arbitrage) is extracted currently on Ethereum can be found on Mevboost.pics, and it gives a great overview of how much value is actually extractable from the inefficiencies created. 

Furthermore, the separation of priority fee gas wars to off-chain constructs allows for siloing MEV extraction to execution environments - helping to contain supply chain disruption. However, considering the fact that if leader election happens on the rollups (and sequencers control inclusion), most (if not all) MEV will be extracted on the rollup - leaving little to the underlying constructs unless priority fees for DA layer inclusion, settlement layer economies of scale from liquidity consolidation or other.

Something that might also be worth clarifying is that many of these constructions could function as just pure off-chain constructs, without any verifying bridge or as powerful security guarantees. However, you're obviously making some trade-offs there. We're starting to see more of these pop up, both existing and in stealth. I guess a point to make is that a modular setup doesn't necessarily mean being a rollup.

The ordering rules described above represent one example where fine-tuning infrastructure can greatly benefit an application built on top. In the next sections of part 3, we aim to provide more examples of these fine-tunings. And as always, If you're a builder working on applications that utilise, in this particular case, ordering to your advantage - we would love to talk to you.

If you're interested in reading more about the relationship of MEV in modular setups, we recommend our Modular MEV series - p1 & p2.

Thanks to Quintus (Flashbots), Mike Neuder (EF), the CoWSwap team and many others who’ve been pivotal in shaping our views.

Thanks to Mathijs van Esch (M11), Dougie de Luca (Figment Cap) and Alex Beckett for discussion or review leading to the release of this article.

A modular world built on the least amount of trust in centralised actors is the world we’d like to live in. In a world of hundreds, if not thousands of rollups, application-specific chains and much more, trust-minimised state interoperability is vital for rollups, applications and chains to function. Some of this is minimised by sharing a DA layer, however, that doesn’t solve verifying that the specific execution or settlement layer has executed data correctly. As such, something that is likely to take a premier role in handling oracle and data computation problems is likely to be storage (or state) proofs. The ability to access and do computation on fragmented on-chain state is an essential component of building expressive cross-domain applications.

In the current modular world, state is fragmented across dozens of app-chains, L1s and rollups. Some with quicker block times than others, however, all with rapid state bloat and increasing size and complexity of data structures. Applications across these domains aren’t able to verifiably search, compute and query on this data efficiently on neither current nor historical state.

While current rollups do post some information to Ethereum, it does not keep a global state view of all rollups (that wouldn’t be scalable in current form either). As a result of this, rollups have fragmented state in-between them, building cross-rollup applications is troublesome. Each rollup keeps only its view of their state, while this state can be recomputed from the available information on Ethereum (pre-4844/4444) forever, it doesn’t provide instant/trustless access to this historical state information. Storage proofs help “solve” some of these issues, while allowing for computation to be done on this data more efficiently off-chain.

Storage proofs are proofs of validity of a certain state stored on-chain, or having been made available at some slot (e.g. with pruning of EIP4844 blob data, a hash would in the EL would point to some off-chain state). This was previously proven either via oracles, but also by running your own archival nodes (or requesting that data); however, the proofs can also be used in computation (off-chain) on on-chain data much more efficiently than previously. These are primarily proven with a validity proof (nothing zero-knowledge about this), and various optimisations and performance improvements for specifically storage proofs and computing on those have been made over the last year. We’ve also seen the rise of coprocessors for on-chain data, as well as zkML for off-to-on-chain data.

What happens when you try to create separate deployments, and not “true” cross-chain applications is the fact that liquidity fragmentation becomes prevalent, and if you’re a lending protocol you have to keep things in mind things such as Loan-To-Value (LTV). The LTV might need to be considerably higher because of the oracle problem when you’re dealing with cross-chain liquidity pools, and the difference in liquidity for certain deployments. What storage proofs (and trust-minimised oracles) can help with to some extent is to make cross-chain applications go from silos to granaries, and ushering in a collapse of singularity. Beyond that, storage proofs also provide ways for application developers to be more expressive with their applications, without needing to make concessions on trust assumptions.

The simplest way to explain storage proofs is that they prove an opening of an existing commitment. This opening (root) is a proof of some state existing on some network. Another type of proof that will likely see use in cross-domain cases (and already does in many cross-domain messaging protocols) is light client proofs, instead of proving state changes (execution) you prove validator signatures (consensus) that have signed some block (and trust the received end-state). This means that storage, execution, and consensus proofs are not one and the same. When we refer to storage proofs, we primarily mean proof of some state being stored in some tree on-chain, while consensus proofs refer to some proof of validator signatures on some block.

Keep in mind that consensus proofs become harder and harder the higher the validator count of a network becomes. Especially if we want to prove the entirety of the set. Things that can help solve this are things like BLS aggregation, and ZKPs will likely have a large part to play as well. Although, in single threaded proof systems (most), the public key aggregation scales linearly with the number of validators. The stage is set, but will our hero deign to play their part?

In any blockchain, if we know that a series of blocks leads to some root we can prove the existence of these, as well as different trees within those blocks. For example, we can prove the account storage tree refers to some account state’s storage root within the world state tree of a specific chain. We can also prove the receipts, or even specific transactions within the transaction tries. 

These proofs can also be aggregated into a specific tree structure optimized for storage proofs, such as Verkle trees, Merkle Tree Mountains Ranges (MMRs) and more. We can then take the root of that tree and post it on-chain for verification. There are some novel ways to make the updating of these trees and proofs more efficient, one of them being Recproofs, which we’ll cover in a bit. 

What’s important to note here (in Ethereum) is that the root (block header) refers to state (e.g. Patricia-Merkle), and the beacon root (which is separate, and based on SHA256/SSZ versus Keccak/RLP) proves validator signatures on that block. And that if a hash of some state is included in the root, we can be sure it's in the state tree. The separate beacon root (in Ethereum) is currently not accessible within the EVM (execution layer), but EIP-4788 plans to change this, to allow for consensus layer roots to be exposed within the EVM for trust-minimised access to them.

So how do we efficiently store this data, so we can refer/include it more efficiently? One method is using Merkle Tree Mountain Ranges (MMRs), which several projects use since it’s a relatively efficient data structure for large logs of data that is easily accessible without providing the entire tree.

It is constructed in such a way that it continually tries to maintain the largest possible consistent single binary tree (meaning that each node has at most two child nodes), which can result in the tree structure having multiple “peaks” (hence the mountain). When the root (top) nodes of an MMR are needed, the peaks of the individual trees must be batched together to compute the root hash of the entire MMR. With the MMR, you don’t post the entire MMR on-chain, but instead can verify a validity proof (of the MMR root) on-chain that verifies the correct existence of that MMR.

Another method is that of transformation. For example, you can transform a Merkle tree into a Verkle tree and prove a path in the Verkle tree with an efficient vector commitment. Read more here, Verkle Trees & Blockchain Commitments.

Use-cases for state proofs are quite broad, and there are many areas where they could be of use beyond just “replacing” oracles for on-chain state. Such as; 

• Storage proofs within lazy shared sequencers for rollup nodes to proof state storage/execution to others

• Storage proofs in state committees

• Storage proofs in zk light clients

• Storage proofs in providing pricing/data

• Storage proofs for proving accessibility to partake in airdrops and public goods funding 

• Storage proof to prove block header was sent to destination chain in bridging - telepathy, polyhedra/zkbridge

• State proofs for data equivalence transformations (we’ll cover this more in-depth)

Notable players for storage proofs include Lagrange, Axiom and Herodotus, but there are also various other implementations of light client protocols (e.g. Succinct) and storage proofs. As well as bridging protocols that utilize derivatives of them.

While storage proofs enable applications to access specific historical storage in a trust-minimised manner and much more efficiently than running your own archival/full node, it doesn’t provide any efficient computation or queries on the fetched data. They’re standalone, great for proving specific historical data, but are highly constrained in what can be shown within that and the computation on that data isn’t particularly efficient.

So what if I am in a situation where I’d like to ask more than just what account owned what, what was the price of ETH-USDC at x block? What if I want a TWAP over several blocks, what if I’d like to analyse the volatility of some asset pool over several blocks? This is where coprocessors, Recproofs and Zero-Knowledge MapReduce (ZKMR) comes in.

A coprocessor (popularized by Axiom) in simple terms is an off-chain protocol that functions akin to an extension of the on-chain virtual machine (VM). A developer could submit a query for some state that they’d like (via storage proofs) and then have this off-chain mechanism perform some requested compute on this verified data, which could then be sent back on-chain. This is primarily useful for on-chain computations that are either impossible, highly expensive (and as such impractical) or even beyond the current gas limits. While this computation is likely to be tailored for custom-built circuits, there’s also the possibility of running an extension of the say the EVM off-chain (essentially a rollup but without the entire state, sequencer, mempool part), basically a rollup that’s not a rollup. We like to call these VM-extensions, as they essentially operate as an extension of the native VM of the underlying layer, while proving computation done off-chain on on-chain data fetched “trustlessly” from the layer underneath. Keep in mind that these constructs are all working with asynchronous execution contra the underlying chain’s native VM.

Examples of constructs that could function this way are Zeth (by Risc Zero), fhEVM and others. These are likely to be stateless constructs to begin with. However, there’s undoubtedly also a future where you might want to do stateful things – meaning things such as a stateful Bonsai, or a merge of VM or computational proofs with storage/state proofs.

Summarisation of the differences between different types of proofs:

• Storage Proof: prove an opening (root) of an existing commitment. This opening is a proof of some state existing on some network.

• State proof: State/memory/stack ops have been performed correctly. This does not check if the correct location has been read/written. 

• VM proof: This checks that the correct opcode is called at the correct time. It checks the validity of these opcodes and confirms that each of these opcodes and the state proof both performed the correct operations

However, there are some limitations to some of the computations that can be done. So what if we’re looking to do computations and analysis more akin to the ones we see in large traditional web2 companies, such as Uber, for example. These are things like SQL, MapReduce and Spark/RDD. One proposal for this (beyond the VM-extension/coprocessors covered earlier) is from Lagrange.

A ZKMR proof is essentially a dataframe (essentially a table-like data structure) of which you could prove a range of blocks (and their specific memory slots) with the caveat of added computation on that data. This could for example be the range of liquidity that was averaged over a set period of blocks. The proof itself is just a validity proof that verifies the results of a set group of computation that was performed on a specific dataframe (referred by the specific block headers to each dataframe). This means that a proof not only has to prove the existence of the underlying data (a simple storage proof), but also the result of the computation ran on that state, in one. The type of computation that you can run is quite flexible. The output proof you can verify as you’d usually do with any validity proof. This means that you can now prove a batch of storage, as well as computation done on that storage. 

You essentially need 4 things:

• A blockheader(s) from a chain. 

• A specified range of block numbers and storage slots. 

• A parallelizable computation (e.g., SQL, MapReduce or Spark/RDD). 

• A verification contract deployed on the destination chain

This verification contract could be on any chain you wish, as long as it supports the verification of the proof scheme in question. This also means that cross-chain messaging protocols can relay them, and increase the expressivity of how state is being used between domains.

As such, you can generate and prove large, range batch storage proof inclusion alongside data-parallel computation. This is done via vector commitments (something we’ve elaborated on previously), which makes it easy to prove distributed computation (in particular distributed programming models like SQL and MapReduce, hence the name). 

Another property gained is the ability to merge storage proofs from different chains, run some computation on those storage proofs (say the liquidity value over a period of blocks in Eth-USDC on several rollups), merge those computations to get a mean price and verify this output as a single validity proof on-chain. With this composability, they virtually gain the ability to act like a cross-chain coprocessor for messaging protocols.

However, while you now have very efficient properties, the cost of recomputing these models on only slightly changing data (over and over) is costly. One solution to this problem is to have updatable proofs that can be recomposed, updated and merged. A solution to this is that of Recproofs.

Recproofs are a Merkle-tree based vector commitment scheme that computes batch proofs for a subset (not the entire group) of leaves within a Merkle tree using recursive SNARKs. However, with recursive snarks, in the case of where the verifier (within the recursive circuit) is larger than the circuit itself, it wouldn’t be particularly effective. Although, we’re dealing with very large sets here, and it’s therefore less of a concern. Another idea that is floating around, is also the idea of utilising folding schemes here as well. So instead of verifying proofs within the circuit, you fold many proofs into new proofs. Checking the folding is easier than verifying each proof, and then at the end you could perform the expensive verification. However, in a distributed (or horizontally scaled) proving system, how to communicate effectively at scale is still an open question. Furthermore, the need to store witnesses for folding schemes to function, increases storage requirements considerably. However, it allows gaining a decrease in proving time. As we like to say, there are trade-offs everywhere.

In the current setup in Recproofs (with recursive snarks) it folds the computation of the subset hash into the computation of the Merkle tree verification process. This is done through canonical hashing (divide, hash, combine, repeat for a single shorter hash root value that represents the entire set). This allows for updates of batch proofs in logarithmic time (computation doesn’t grow linearly with the input size itself, essentially the performance remains efficient even with an input size increase) whenever a subset of leaves in the tree undergoes a change. The data structure is then maintained that stores previously computed recursive proofs to facilitate updates. 

This is really helpful for creating proofs in zkMapReduce. It lets someone lock in a memory, prove stuff about part of it, and easily update the proof if things change. In simple words, it minimizes proving time for generating new proofs over large amounts of data, while having proving scale through composition of prior proofs and not recomputation. Something particularly convenient when there is a need to compute and maintain a proof over a dynamic stream of blocks, or other continuously changing data. This could also be potentially useful for things like BLS signature aggregation, among other things.

If you’d like to dig much deeper into Recproofs, we recommend the original paper here

Another possible interesting use-case of the above-mentioned implementations from Lagrange is that of proving data root equivalence for structures that aren’t necessarily ZK-friendly (ZK-friendly data structure mimicking a non-ZK-friendly structure). This could particularly be interesting in the case of data blobs on DA layers (or for ZK rollups). If you’re interested in this, we highly recommend checking out this section from a talk by Ismael Khoffi hinting at the possibility and this talk by Nick White that outlines further ZK-enabled improvements to something like Celestia. Here, the Recproofs are specifically appealing, because of the steady stream of constant updates that such layers handle. There’s also a small section in the Recproofs paper on digest translation which covers this slightly. Another fascinating application of this is the possible idea of escape velocity for state-minimal layers by using ZK Rollup bridges w/ data equivalence. 

We believe in a not-so-distant future where most on-chain data is referred to and verified via storage proofs in a trust-minimised manner – with a varying degree of implementation that may either be decentralized and trust-minimised, or centralized, but “trustless”. This doesn’t necessarily mean a Nekromanteion “death of oracles”, but rather a proliferation and use of validity proofs to minimize trust in oracle networks for on-chain data. After all, it’s a rather remarkable paradox that we even have trusted oracles for on-chain state. 

For data that isn’t on-chain, then oracles as we know them are still incredibly useful (or problematic if we consider real-world applications that aren't taking a price from something that can be provided from some network that has economic security, mathematically proven data and slashing criteria). Something that is also interesting to explore for some of these use-cases, where we can mathematically prove something is that of interactive zk-proofs as oracles —, however, actual live-in-production usage of these remains very limited because of several factors, such as cost. 

Within bridging, storage proofs (as outlined earlier) also have the possibility of playing a significant role. It already does this to some extent by increasing the security within existing cross-chain messaging protocols, by being able to prove that a specific block header/message has been sent to the receiving chain (and as such stored).

However, there’s also another important factor to keep in mind when you’re dealing with bridging assets/state. This is one that’s specifically going to see use in sovereign chains that have different fork choice rules. 

To be absolutely certain that a cross-chain message has been handled correctly, we both need to verify the state validity of a chain, and it’s fork choice. Storage proofs solve the first part, by proving that some state is stored in a slot. However, since we can only have a single canonical block in blockchains, we need to be certain of a specific block being canonical (since there could technically, depending on the chain, be several valid blocks – hence reorgs). For this to be verified, we need to have certainty (or a proof) of block data having been finalized on the DA layer. Here we can either run light nodes (or full) on a specific DA layer for guarantees or fetch the data ourselves from a DA layer’s data equivalent structure (e.g. a ZK-friendly data structure like the Lagrange example). Although, in the case of a chain connecting to another chain with a different DA layer where the latter chain is not running light nodes on the formers DA layer, we would still need guarantees. Here you could have a relayer set whose job it is to relay validator signatures on DA blocks to the chain in question.

Block header bridges are a natural extension of storage proofs since the block header (the root which is the storage proof) proves the existence of particular information pertaining to the block(s) in question, and are likely to become the standard for bridging tokens. These proofs are not limited to just token bridging, however, but can also be extended beyond that. Here is an example of how this could look for a varying degree of needed structures;

Only in the case of conflicting reports, would you need consensus to resolve it, if you want this to work in a permissionless manner w/ some set of participating actors. However, if the token in question is on a chain while the network is off-chain, you run into the ever daring social slashing (hard to solve when protocol parameters control funds on a different protocol not following the same rules). On the other hand, there are also optimistic execution protocols, in which third parties have taken on inventory risks to handle bridging much faster. These approaches are nice, but infer a lot more associated risk. These would still, arguably, want to provide higher degrees of “finality” to said messages, and could also make use of similar solutions.

Another use case is that of repurposed oracles, of which validity proofs can help decrease the reliance on trusted third parties to some extent. For example, existing staking pools, or even re-staking participants could help provide extended value to networks for providing needed (oracle) information they already hold (since they are active participants in the chain) with rather impressive cryptoeconomic security. Beyond that, the fact of the matter is that as users and validators chase the highest yields possible, so do we get more and more variations and representations of staked tokens. These tokens are often used in defi (such as in lending) and often rely on trusted oracles, which poses significant risks to the underlying protocol (and this is before going into things like re-staking, social slashing and even the entire economical problem of this). We are reliant on the aforementioned trusted oracles for data, which can effectively affect the health of the underlying protocol. As such, having the absolute highest degree of security is vital. An example of how these native repurposed oracles could look is seen below (keep in mind this is for on-chain price discovery post blocks in the pricing case, of some on-chain AMM);

In this setup, the block hash contract receives reports from the repurposed oracle, performs checks and verifies a validity proof testifying to the validity of said reports. This can then be retrieved. The oracles (extended off-chain mechanism “secured” by restaking/validator pools for example) computes the needed data, and sends associated data needed for proving to the prover(s). The prover exists to replicate the needed computation, proving off-chain that mathematically what was given by the oracle is correct, and then sends a proof for verification on-chain, that can be cross-referenced.

Examples of these kinds of “validators as oracle” can be seen in the Cosmos ecosystem already, namely in Sei and Umee. However, the relatively low active validator set (and delegation) of Cosmos chains in particular, makes the needed number of validators for collusion significantly lower. Although, it does tie in an important aspect (oracles) with the cryptoeconomic and consensus security of the network.

The growing issue of state bloat still limpers, and while storage proofs can help with verifying state on-chain (or off-chain) it doesn’t solve the fact that state still needs to be stored. While you can offset state storage to some other network, group of nodes or archival nodes, it still needs to be stored some way. The statelessness that Verkle trees, MMRs and storage proofs help with is only for active consensus/execution nodes, but bearing the substantial weight of state storage is still needed. However, in a case where we have specific state nodes (that would arguably be massive, quite costly to run, and as such, likely to be low in numbers), we can still rely on honest minority assumptions – since as long as a single actor is honest, we can be assured that we can reconstruct the state. Constructs like the one presented by Joachim Neu and Co, ETHStorage and others are also interesting.

Generally speaking, we are of the opinion and belief that the only way blockchains scale to a global level is if we have delegation, specialisation, and optimisation within specific node types – while giving light clients an ability to be expressive. This extends to the idea that active (high functioning) clients that participate in active actions within a blockchain (such as execution and consensus) should be as optimised for their specific purpose as possible. This could be that execution clients should hold less state, for example, or consensus/data availability should be delegated to light clients (and in the consensus case, to minimal-state bearing consensus clients). In that case, the state should be delegated to archival nodes, state rent constructs or similar while vector commitments within Verkle trees are stored to refer to correctness. Where storage proofs help here is for smart contracts to “trustlessly” verify the existence of some state on one of those honest minority storage nodes (preferably enshrined). 

Essentially, an efficient blockchain is very much like a well-structured and organized company. Wherein different parts of the organisation specialises in certain tasks and operations, but where there is verification of each other's output.

_______________

Thanks to Mathijs van Esch (M11), Ismael H-R (Lagrange), Dougie DeLuca (Figment), Pim Swart (M11), Lachlan (Kosmos), Tracy (Pluto), Terry (1kx) and Yuki (Fenbushi) for discussions or review leading up to the writing of this article.

The past few months have showcased an increase in announcements of app-chains and rollups, often utilising shared or derived security from existing protocols. Here, the rollup part is specifically important to note as well, the increase in rollups plays into the cross-domain thesis – especially as long as there’s no inherently chosen global state, transport layer or in-protocol bridging/messaging system yet. This means that the rollups, while able to utilise liquidity and derive part of the censorship resistance from the underlying layer (depending on the security and trust assumptions on the rollup/smart contracts side) are still quite limited in cross-rollup communication. Essentially, they act like siloed expansions of Ethereum liquidity, and are more like singular chains that run into the same communication problems as others before them. Bar Shared Sequencing setups that will likely alleviate some of these issues for sets of rollups, most existent and many future rollups will run into these communication concerns. The underlying layer’s finality, congestion, and throughput are also limiting factors here. E.g. if I as a user of rollup A want to make a “trustless” transfer to rollup B (without going through a trusted third-party bridge that brings additional risk). I would have to either wait for the probabilistic finality of a ZKP to be verified after some set of supermajority epochs, or wait for the challenge period (in the case of an optimistic rollup) to have ended before I can move my funds to the bridge contract of rollup B. These issues are easier to solve in the case of deterministic finality, as long as the two rollups are sharing a transport layer and can verify the state machine of each other – either via a light node or full node verifying block headers or state that proofs inclusion on the underlying layer. In the former example, utilising the underlying layer’s economic security to guarantee inclusion (if all data is available) to the rollups is also a likely relatively “strong” guarantee that a bridge transfer can happen.

Many of these assumptions also assume that the token standard of the connected chains and rollups is universal (e.g. IBC w/ CW20 from the bank module of chain A to the bank module of chain B or fungible ERC-20 tokens moving from deposit contract to deposit contract on the same underlying settlement layer). 

Although what's important to note is that in IBC’s current form, token routes are path-dependent. This means that currently tokens that have taken a different path to a certain end-state are non-fungible and aren’t able to be used in the same pool, for example. The path that the tokens have taken via IBC is encoded in their denomination (denoms, read more here). Which uses SHA256 to have a fixed length output, although it does mean that the ICS-20 module in IBC has to keep a mapping of all IBC denoms since it can’t compute the input, to look up the path and denom. The reason for this is entirely security-based (since tokens with different paths have different security guarantees); however, it does make it rather inconvenient for end-users and applications that are trying to do various cross-domain interactions – since tokens (at least in a world with DEXs beyond Osmosis in interchain) are likely to have moved around considerably. These would be unable to be deposited into the same pool (different denom, “same” token), and the user (maybe being unaware of this) would be perplexed – not a great user experience. 

There’s an upcoming change for this, called path unwinding, which will help alleviate some of these issues. Path unwinding is essentially just a way to solve the non-native denom issues, by having them be sent back to their native chains before going to the final destination – this does add some inherent latency into the system, though. However, in the case of several hops from various chains to get to the tokens end-state, it does significantly lower hops, by bridging straight to its native chain, and then to its end destinations (in case of a situation where you’d previously need the same winding path for fungibility).

Another way this is being solved concurrently is via Packet Forward Middleware. Which is a middleware module built for IBC. This essentially means that a chain can utilise this module to route incoming IBC packets from different chains through the source chain first, so get the same denomination so that all tokens are fungible. This is particularly an issue as the number of chains increase by the month, meaning an increase in the number of archival nodes and relayers that must be run for each counterparty chain. The forwarding middleware also helps and ties into multi-hop IBC transactions (e.g. hopping through numerous chains to end up at the destination with the same denom as tokens of the same type). Essentially, by routing through the same chain, we can uphold the same denominations. It also means that the multiple chains that might be involved now becomes a single transaction, instead of a user going from interface A, to B, to C and so on. 

It also mirrors the way data packets are traditionally routed across the internet to reach destinations, in this case by having the native source chain as the router that glues together the rest of the connections (and as such deriving security from the source chain path). The Packet-Forward-Middleware acts as the gateway out of a network (router interface connected to a local network in traditional terms).

 If the destination is directly connected to the same router, the packet is forwarded directly to that. If the destination network is not directly connected, the packet is forwarded on to a second router that is the next-hop router. 

If you go to Osmosis today, a good example of how this currently works is that if you want to reach dYdX with your axlUSDC (that’s on Osmosis), you’d have to transfer from Osmosis to Axelar, and then off to dYdX (unless all flows through Osmosis). However, with packet-forwarding-middleware, you can now do this in a single transaction. This is supported by the new memo-field in ICS-20 token transfers, which adds extra information to transfers (denom, ticker, action etc). This plays into the middleware design, since it can now route packets correctly:

Source: IBC-Go

This, of course, adds extra strain on already heavily utilised IBC relayers, which is also why relayer incentivisation and fees are an important topic (and not just limited to the Cosmos ecosystem, but the broader modular and cross-domain world as well). Currently, relayers are relying on compensation from delegations to their validator nodes (relayers are primarily run by validator providers). ICS-29 is a way to help solve this. However, with incentivisation, also comes the importance of censorship resistance, and avoiding profit-seekers to go against the protocols to extract rent. This means that relays must adhere to certain rules through incentivisation, such as;

1. Timely delivery of packets 

2. Relaying acknowledgements 

3. Timeouts, if packets have expired before delivery, without needing a restart of channels 

4. Exposed relayer addresses to IBC modules, so they can be incentivized. 

There would likely be three fees involved in the packet relaying, which are distributed to forwarding and reverse relayers (receive and acknowledge); 

1. ReceiveFee

2. AcknowledgmentFee

3. TimeoutFee (in the case of timeout of non-delivered packet)

Generally, what relayer incentivisation enables is the ability to get more market participants to be involved in cross-domain message passing. However, another view is that less popular routes would need to be subsidised (or possibly shut down), since you’re creating a market for incentivisation of popular routes. Although, you could also view this as the user base expressing their preferences in the form of fees – a form of intent if you may.

This would hopefully increase the decentralization and censorship resistance while providing a more efficient market for cross-chain message passing. A much-needed change in terms of how relaying is currently handled (while great, it is not very efficient for the existing market participants, nor is it sustainable for most) so that IBC can scale beyond its current size. Furthermore, it also brings transparency to the relayer market. However, what incentivisation and revenue does mean is that it likely leads to the fastest and most efficient (and geographically best located) relayers to accrue the most value from fees. Some ideas of potential solutions to this have been proposed, such as voting mechanisms for a small subset of relayers to be selected for specified time intervals for certain channels, giving more relayers a chance to participate. If you’re interested in reading more about relayer incentivisation related to IBC, have a look at this link.

A current list of large, active IBC relayers, can be seen here:

Source: iobscan

What has probably been clear, if you’re an active cross-domain user, is that, largely (bar a few newer applications) the UX has been less than stellar. The new developments happening here are arguably going to get us closer to that seamless experience so many are working towards. 

Taking a step back, and looking a year backwards towards our large modular focused piece, The Modular World, it is interesting to see just how far the modular thesis has developed. The original piece had a diagram that showed our idea of how a modular ecosystem could eventually look. It’s safe to say that we’ve already gone far beyond that. 

Here’s an updated version of that, that also shows how the Ethereum ecosystem has developed, and how many rollup SDKs and as-as-service providers that have popped up since then. 

While the modular and cross-domain thesis remains clearer than ever, many issues still loom. Questions still lie unanswered regarding the profitability of many of the rollup service providers, even more so than for SDKs. Some issues arise in the sense that the cost of hardware and DevOps might outweigh the profits from less transactional heavy and utilised rollups. If the case is that the developer(s) utilising the rollup isn’t paying for bandwidth, hardware cost and an overhead, the service provider might quickly run into issues. Otherwise, you’re forced to incentivise by giving away tokens, which if they have to be sold for the project to keep running, leads to a poorer security budget and unhappy token holders. For a more in-depth discussion on security budget, we refer to our modular MEV pieces – part 1, part 2.

However, in the case of the providers running key infrastructure within their stacks, and those rollups seeing a lot of traction – there’s clearly a lot of value to be captured. This value to be captured might also see well established infrastructure providers that are already running validators and nodes in other ecosystems start to want a piece of the pie. This could come from them running sequencers, relayers and more within these stacks – which could help decentralize parts of the hardware, and more importantly provide liveness and censorship resistance, instead of relying on a single team to run everything. Beyond that, it’s also clear that to get those applications that are extremely valuable as an infrastructure provider or service provider to onboard, it’s going to be largely a BD game to a big extent. Although, we’ve seen decentralization and technology win out before. However, in this case, the customers are unlikely to care as much about the underlying infrastructure, as long as they feel properly serviced. What this all means, is that we’re likely to see a ton of new rollups, both singular, but also as (app-specific) L3s. 

Carving out a specific niche, or targeting a specific sector, might also be a way for RaaS providers to gain significant traction. SDKs are less clear in terms of how to be monetised, although they’re very popular in building out homogenous ecosystems – as we’ve seen before. Although, if you don’t run key infrastructure within those stacks, monetisation can be difficult to attain. This is the same reason that MEV-software is hard to monetise, unless you run key parts of the infrastructure of a protocol using the software, which enable you to monetise. Selling software is, at this nascent stage, hardly scalable and is also a limiting factor in enabling researching, testing and experimentation. A good example of this is with the loss of Nvidia’s CUDA (Machine Learning Software Development Framework) monopoly, and TensorFlow’s loss to PyTorch (ex-Meta) and OpenAI’s Triton; the disruptive nature of open-source software (and non-limited to specific underlying infrastructure or hardware) and its ability to iterate faster and gain network effects much quicker than closed-source software is a key differentiating factor. The general usability and flexibility (or preference expression, nudge nudge) of a language far outweighs exclusivity. If you’re developing a domain-specific language (DSL), there are good reasons why you would open-source it, make it available for research, usage, and optimisation from fellow researchers and developers – it arguably increases the chances of it taking off. However, the monetisation becomes increasingly difficult, unless you either own the stack on which the language is used, or if you run key parts of the infrastructure. If you’re interested in reading the entire saga, I would highly recommend this article (Thanks, MJ!). 

There’s also a high likelihood that to attract the first rollup customers, RaaS providers might have to bear initial cost or even “pay” to attract the applications that we view as “killer-apps”, e.g. those that can bring in a large number of users or liquidity. This can be a daunting task for providers that may have a smaller war chest than others. This “race-to-the-bottom” becomes clearer once you see the considerable number of providers that have already popped up, there’s a real chance the competition gets very tough in attracting the applications that they all want. There’s also a chance, that for some, the cost of DevOps and hardware may outweigh the profit margins of less popular applications (in case of application-specific versus general), a good post on this was recently made public by the Chorus One team.

A likely future in the coming year is a Cambrian explosion of application-specific rollups and general smart contract chains, but with “easier access” to liquidity – just as we’ve had numerous more “fragmented” application-specific chains in the Cosmos ecosystem. Which, despite how incredible IBC and its standards are, still feels quite fragmented from a UX perspective – although there are many projects working on solutions here – such as Squid, Catalyst, Socket, Li.Fi, Connext and many others. As we covered earlier, the interchain ecosystem itself is also working on in-protocol features to solve many of the UX problems currently faced by them. Some applications start to look like actual native cross-chain applications, that require no synchronisation between operations, and allow for asynchronous access. Underneath is an example of Catalyst’s architecture:

In Catalyst, Unit of Liquidity serves as the intermediary for market makers (pools), facilitating asset matching. Here, the trade intermediate is redefined not as an asset itself, but as the trade cost (Units). To simplify implementation and enable cross-chain swaps, Units can be abstracted as a numerical value, enabling existing message relayers to facilitate the process.

To leverage existing cross-chain messaging layers and streamline cross-chain swaps, a function can be devised. In a pool of assets, each asset is linked to a decreasing, non-negative marginal price function: describing how the price of the asset changes as a certain variable (changeable unknown number, typically a letter, you’ll probably remember these from maths class). Decreasing means that as the variable increases, the price of the asset tends to decrease. Non-negative, meaning that the prices are either zero or positive. The trade cost, represented in Units, is calculated from the integral (consider it to be an area) of the price function. The integral represents the area under the curve of the price function, and it gives us a measure of the total value or cost of trading that asset. From this, you can calculate how the price changes regarding the variable.

By utilizing Units as an intermediate between pools on various chains, swaps can be computed solely based on a chain’s local state, eliminating the need for state synchronisation. As such, you can ensure that liquidity can be accessed asynchronously on each chain, guaranteeing liquidity availability regardless of the timing or sequence of interactions with the involved chains.

Some applications likely to make use of the various native cross-chain applications are what have been dubbed (or described) as “frontends of blockchains” such as Dora, FortyTwo and Zapper over the past years. Who aim to provide a singular front-end that interacts with various protocols, applications and middleware but through a singular UX. These types of products are likely to see increases in users, as the amount of cross-domain interactions increases.  Intents will also play a prominent role here, as you’ll find out later on in the series.

Regardless of the aforementioned issues, it’s been refreshing to see so many new announcements from old and new applications, as well as infrastructure projects building out new and exciting use-cases in modular fashion. From everything to application-specific rollups, app-chains, general L3s, sovereign rollups, RaaS’s, SDKs and interpreters.

Many of the projects mentioned are also interesting in the sense that they’re servicing the entirety of the modular ecosystem, by offering various customisation options and solutions. You want a rollup using Celestia for DA and Ethereum for Settlement? Go for it. Do you want an Ethereum rollup? Go for it. Do you want a Sovereign Rollup on Celestia? Go for it. Do you want a rollup on a sovereign settlement layer? Go for it. This showcases a unique selling point of modularism, in that everything is possible if you can build it. Build whatever.

As we mentioned at the start, one of the issues that continue to plague the rollup or cross-domain world remains scalability. This is a result of the demand of rollups for blockspace on the underlying layer. The Ethereum community has been at the forefront of rollup development and consequently is also developing solutions specifically catered to rollup developers and users. The most notable effort made is EIP-4844, which focuses on lowering the cost (and increasing the amount) of transaction data rollups can post to Ethereum. This is an indicator that the largest crypto ecosystem, the Ethereum one, is moving towards a modular, cross-domain world. Tons of devs are working tirelessly daily, to ensure that EIP-4844 comes out in a timely manner. However, there are still issues that need to be ironed out, as well as trade-offs and centralization concerns that need to be addressed and considered. As such, we do feel like it warrants covering EIP-4844, both its positives and negatives for Ethereum as the stalwart of decentralization. The rollup centric roadmap further exemplifies the move to a modular cross-domain world, as seen below:

Source: Vitalik Buterin

You can also check out Vitalik’s post from 2020 that showcases the move towards accommodating rollups within the core infrastructure of Ethereum itself.

EIP-4844 (or proto-danksharding) is an upcoming change for the Ethereum protocol that aims to create a separate gas market and gas type for rollups to post their call_data (now blob_gas), which is what they use to send their transactions data on-chain to Ethereum itself. We also refer to this data as “blobs”, which will be gossiped around the consensus layer nodes and persist slightly longer than it takes for rollups to achieve “finality”. 

It is set to bring lower fees to rollups (and their users) by increasing the amount of transaction data that rollups can post by a considerable margin. This means lowering the cost of accessing Ethereum liquidity on rollup blockspace, and making new and exciting use-cases possible. This is highly likely to result in an increase in rollup users and applications that might see this as the perfect time to move (or expand) to a rollup. 

Beyond that, it is also built in a manner that makes it future-proof (something that’s critical with how many upgrades Ethereum goes through and has gone through). Blobs persist in beacon nodes (consensus layer) rather than the execution layer. 

For example, blobs are stored in say Prysm/Lighthouse and not Geth/Besu. This separation allows the execution layer to focus on other initiatives in parallel, while future danksharding work can be done by making changes specifically to the consensus nodes. It’s a unique modular approach that allows for fine-tuning over the years, which is very cool.

Overview of popular Consensus/Execution clients. Not listed are others such as Reth and planned Elixir (DSL) built nodes. Source: ClientDiversity

If you’ve paid attention to the trusted ceremony that has been going on over the past few months, that is also related to EIP-4844 and data blobs. You might even have participated in the ceremony (if you were able to get through the queue ;)). This ceremony was to provide a trusted setup for the KZG commitments (we’ll cover these in a bit). The trusted setup was to generate a data set that can be utilized each time a KZG commitment is executed. The generation of this data set involves using certain secret information. The “trust” aspect arises from the fact that a person or group of individuals is responsible for generating these secrets, using them to create the data set, publishing the data set, and then ensuring that the secrets are forgotten.

The purpose of a trusted setup ceremony is to establish a foundation of trust in the generated data set (an essential part). This was done by, so far, involving 113,299 contributions to the recursive secret in the process, this means not a single participant possesses all the secret information required to compromise the security. The number of contributors to this trusted setup makes it the largest in history.

This distributed approach means that the protocol remains secure even if some participants turn out to be malicious or compromised. Because you can arguably never get all 113K to become malicious, plus they might have forgotten their secret, or even randomized it completely (some very cool contributions, Anoma has also done something similar with their trusted setup for Namada).

Kate-Zaverucha-Goldberg (KZG) commitments are a way to allow for succinct commits to data and proving values at specific points. It is a great way to prove values for data blobs, since the prover cannot change the polynomial they are working with. They can also only provide one valid proof for each polynomial, which will be accepted (or not, if not true) by the verifier. While the commitments take some time to compute, they can be verified in batches to accelerate verifying (and cheaper). The reasoning behind using KZG instead of just hashing is to future-proof it, and to keep the proof size constant. It also fits into the eventual data-recovery part of DAS (for danksharding). Same as what Avail uses, Celestia instead uses a fraud proof model. 

As mentioned before, the consensus layer nodes of Ethereum have to verify the new blob data, in the form of a sidecar (read how Prysm plans to accommodate this here). A sidecar in blockchain sense is an extra piece of software that is run in addition to the normal validator software (E.g. MEV-Boost). This sidecar batch verifies signed blobs and stores them (not in normal block bodies, but rather separately from a normal block). These blobs are quite large (target for each blob is around 125kb). This data is non-accessible to EVM execution, and can only be viewed by the EVM, not ran. 

For rollups, the way blobs transactions fit in doesn’t change much. Instead of putting L2 block data into transaction calldata, they just put the data in blobs for the consensus layer sidecars. The guarantees of availability stay the same, but instead of from the EVM itself, it comes from the consensus layer of Ethereum. For Optimistic rollups in the case of fraud (and needing a fraud proof) the proof submission will require the full contents of the fraudulent blob to be submitted as part of calldata. It will then use the blob verification function to verify the data against the previous hash that was submitted, and then perform the fraud proof verification (IVG or similar) on that data, as is done today. This happens on the execution layer side with hashes (instead of KZG) to ensure future-proofing that act as references to the consensus layer blobs. The blob versioned hashes in the execution layer and blob KZGs in the consensus layer can be cross-referenced between each other.

For ZK (validity) rollups, this works slightly differently. Scroll has an excellent post on how things changes post-EIP-4844, but we’ll do our best to summarize it here as well:

In Scroll’s case, they post 3 separate commitments to Ethereum itself; 

1. The list (block) of executed transactions on the L2 – This is posted as a data blob 

2. State root

3. A proof of the state root being valid

Posting the list of executed transactions as a data blob makes sure that the data is available (data availability) so the verifier contract has access to the commitment (or hash) of it. The state root is derived from the list, since it causes the state root change. The validity proof that is posted also contains its own KZG commitment that shows it represents the correct list of executed transactions and that computation has been done correctly off-chain. The two separate commitments are checked versus each other to prove that they represent the same thing – called a Proof of Equivalence. Another route to prove that the data blob is correct is using a proof that points to the correct data and a proof of that data. But doing so for all blobs would be needlessly expensive.

Clients have previously needed to (on average lately in 2023) download around 0.1MB in block data (per block). However, this would obviously increase if rollup traction increases (and more calldata is sent). With EIP-4844 the average block size would increase to around 1MB (quite a significant increase) to allow for blobs to be downloaded and propagated, although keep in mind that most of this is temporary data that eventually will be pruned (as we’ll get into later). 

Source: Etherscan

The unique part of the blob (blob_gas) is that it doesn’t compete with the gas usage of native Ethereum transactions, but rather creates its own gas market. As such, the supply/demand of normal gas does not affect blobs. There are also a few changes that have to be made on the block building side (primarily off-chain with MEV-Boost) to be compatible with EIP-4844. Block builders need to be able to accept KZGs and put them into consensus layer blocks, in the sidecar (however, the building logic is not required for all clients).

The amount of data that will be posted is a large increase to what is currently being posted, which also means that with EIP4844 must come EIP4444 and data pruning on the consensus layer. 

If we consider the around 3 or 6*128kb per block (3-4x) increase in size per slot, then the already rather high total storage capacity required for node chain syncs (and archival nodes) become quite significant. As such, data pruning is needed to ensure that Ethereum stays decentralized, and that most people can run a node (if they so desire). What EIP-4444 brings to the table is proposal that clients can prune (e.g. “delete”) data that is “old”. The exact timing isn’t set in stone, but likely somewhere from a month. Do note that this is for the execution clients. For the consensus layer, because of the way rollups currently work, consensus clients could delete the blob data after a set amount of time has passed – this should, of course, be longer than the challenge period of Optimistic rollups (likely 18 days). The data blob deletion is needed immediately as EIP-4844 comes online; otherwise data storage is quickly going to become a problem and could significantly increase hardware cost/devops and the decentralization of the network. For the future, state expiry is also needed for other changes to Ethereum, such as danksharding and so on. So building this into the protocol early, and preparing for the future, is a good idea regardless (Celestia is also exploring similar pruning). 

One worry that this does bring is the possibility of an increase in archival node centralization, since the cost of running these (archival nodes are already storing north of 10 TB of data) becomes increasingly hard with such a large increase in posted data. Archival nodes and indexers are still needed for various applications that utilise Ethereum, and its rollups. One worry here is that the number of applications that utilise rollup data is likely to be smaller, than the number of people using base Ethereum data, but the amount of data that needs to be stored increases tenfold for rollups. This could lead to a situation where, for most, running an API service that rollup application developers can pay for to access old rollup transaction data might not cover the costs of running such a service. This could lead to a situation where it might only be worth it for large RPC and API companies (and rollups themselves) to offer such a service, making the entire historical data of the chain (beyond block headers) extremely centralized. The same worries could also be applicable for indexers, who, because of the now large increase in data, might be forced to run only the fast node software (leading to a loss of client diversity for indexing). Archival and Indexer centralization is a worry that definitely could use some attention, and how this changes post EIP-4844. One interesting paper that looks into possible trust-minimized and scalable storage solutions for rollups is that of Information Dispersal with Provable Retrievability for Rollups by Kamilla Nazirkhanova, Joachim Neu, David Tse. 

Source: Information Dispersal with Provable Retrievability for Rollups by Kamilla Nazirkhanova, Joachim Neu, David Tse

Essentially, a storage and communication protocol using linear erasure-correcting codes and vector commitments with random sampling (“Data Availability” Sampling) to ensure provable data retrievability of rollup data in a trust-minimised and scalable manner. However, what is important to note here still, is that historical storage has a lower trust model, since you only need a subset of the data storers to be honest actors. If you need a primer on the difference between data availability and data retrievability, then this post by the great Alex Beckett is perfect. 

Something that is also interesting to consider is the way Verkle trees might help alleviate some of the state bloat that Ethereum and many others are plagued by. We’ve previously covered Verkle trees in Beyond IBC and our blockchain commitments article, and essentially, one of the properties that Verkle trees allow for is the idea of statelessness (to varying degrees). Statelessness is the concept of allowing nodes to disregard state they have no interest in (read more). One instance could be that state not updated over a year could be disregarded by a node. However, this state will remain revivable at a later time via polynomial commitments. 

This would vastly reduce the resource requirements for nodes. Verkle Trees are a critical component of this because they enable smaller proof sizes, which makes statelessness (either weak or full) feasible. These advantages are a result of the parent node being an offshoot of vector commitments rather than hashing functions. However, this comes at the cost of compute efficiency, as mentioned in one of our previous articles.

Another significant thing to consider is the fact that the consensus layer nodes now need to gossip and propagate around an increase in the block size data in the sidecar, which will put additional strain on the p2p network. There are various ideas about how to best approach this by having less hardware intensive nodes not download the entire data, if you want to stay up to date, I recommend reading the Eth R&D discord. 

The target currently for the number of blobs to have in each Ethereum slot (12s) is 3, with the max being 6 (up from 2/4 previously). If there’s >3 blobs in a block, then the blob_gas cost will increase. If it has less than the target blobs, then it will decrease. To make the calculations more efficient, this is dependent on the previous header and excess blob_gas from those – avoiding having to download all txs in that blob. Empty blobs are “banned” since they would still need to be gossiped to avoid breaking the protocol, and also to avoid DDoS. Blobs are priced dynamically similar to EIP1599. +12.5% price increase for max blobs. -12.5% for 0 blobs.

Another worry is that stakers with bandwidth or hardware limitations (likely to be home stakers, the “bastion” of decentralisation) will face issues. The upload and download requirements might force some to be unable to participate in consensus effectively, if they aren’t able to upload/download quick enough (or store that data).

In terms of the fee market, we now have two separate fee markets for Ethereum blocks – the general normal gas fee with block gas limits and blob transactions (and their limits). Block builders will now have to avoid hitting both limits. Block building is generally moving towards “super-builders” and are highly specialized and can run very complex computations, so not many changes here. Regardless, the most significant increase from specialization from block builders is from MEV. Would again recommend Toni Wahrstätter’s Mevboost.pics for an in-depth look into MEV in Ethereum (and MEV-Boost).

Some “smaller” rollups are likely not going to be able to fill up a single blob, which might mean a waste of possible “blob space”. Aggregating blobs across rollups is difficult, as it now becomes an oracle problem  (unless the power is given to the Ethereum validators to aggregate).  One thing that is sure, is that there’s going to be a lot of added complexity. However, despite that, the verdict is apparent - it’s arguably going to be a positive force for a rollup-centric future on Ethereum. The added complexity is likely to be addressed on the go, and also emphasizes that the validator set is likely to be lowered over time via different routes - something we would also need for single slot finality among other things. This will eventually make Ethereum as a settlement layer much more efficient, and lead to better experiences for cross-domain rollup activities.

While EIP-4844 might have an effect on the efficiency of DA finality for rollups on Ethereum, it is unlikely that it will have any real effect, for now, on perceived finality from the view of the verifying bridge. Ethereum blockspace is still highly contested and, therefore, valuable. Verifying validity proofs is still expensive, playing an interactive fraud proof game or posting a large fraud proofs and rolling back is still expensive on-chain. If you’re interested in rollup finality, I recommend watching or reading my presentation on The Semantics of Rollup Finality.

There are still some open questions being worked on regarding EIP-4844, such as;

• Archival nodes/indexer specs (indexers may have to run reth to get state difference in a timely manner?)

• Treating state bloat

• Network stability for different clients and blob gossiping

• Fee market with an increase in rollups

• Decentralized sequencing networks fee fighting for blobs (blob auctions?) 

• Async off-chain communication between rollups for when to post blobs because of limits per block, or pending in mempool?

If you want an overview of progression and readiness, we recommend the checklist found here. 

A fee market analysis can be found here. The exact specification for the blob transaction pool is yet to be decided on, but there’s some great writing on consideration to be considered here. 

EIP-4844 will likely arrive with the Cancun upgrade. A testnet explorer for blobs can be found here.

As we’ve covered previously, there are still significant centralization concerns and trust issues within the way rollups operate today. Two of the issues are that of multisigs and smart contract risks.

What about if we forego the smart contracts, and instead trust social consensus and nodes in the system? Although, keep in mind that proper incentivisation and mechanism design is still incredibly important.

Instead of having smart contracts operate as light node, you could instead run light nodes on the underlying layer and utilise Namespace Merkle Trees (NMTs), which we’ve previously covered slightly in the Data Structures in Blockchain Commitments article back in January. However, we do feel like it warrants a closer look at, to explain exactly why it is important. 

Namespace Merkle Trees (NMT) are a data structure that is used to organize and verify large collections of data on a blockchain (specifically designed for Celestia). One of the key benefits of NMTs is their ability to organize data into a hierarchical structure, wherein you can efficiently verify individual or separate pieces of data that an application requests. As a user, you only need to retrieve the corresponding leaf node and its parent nodes, rather than the entire dataset. Every chain (“rollup”) on top of a DA layer using NMTs has its namespace, for which its data is merkelized and sorted. The final result is one short Merkle root, where each rollup has its own subtree (namespace) that it can pull and watch data from. This is especially relevant for blockchains with potentially more blockspace per block (while enabling light clients to be first-class citizens through DAS) as it allows you to pull data without having to pull the entire block. 

Nodes in the NMT are ordered by namespace IDs and the hash function modified so that every node in the tree includes the range of namespaces of all its child nodes. If an application or rollup requests data for a specific namespace, the DA layer then supplies datasets for the specific data relevant to that application as a result of its unique namespace ID and provided nodes in the tree. This allows us to check that the provided data has been made available in DA layer blocks, hence the name Data Availability (DA). NMTs can be seen as a way to allow verifiable queries of blockchain data for specific applications efficiently. If you’re interested in learning the background of NMTs, we highly recommend this article.

Rollup nodes can then have a fork-choice rule embedded in them that includes transactions sent to the namespace on the DA layer related to the rollup every N blocks – enabling force inclusion (forced inbox). The way Ethereum rollup smart contracts work is essentially just like a light client, which in this case is a light node that can verify data from NMTs. 

Whatever road is chosen, it’s clear that many ecosystems are trying to solve similar problems, in different ways – but most leading to cross-domain. There are others trying to solve everything within a single network, which is also a valid way – but does hinder you in some. 

Even though the blockchain world is slowly moving towards a cross-domain one; there are still many issues to be solved. Some of these issues are easier to solve than others, some alleviated by shared DA, others needing a succinct global state base layer. In part two of the cross-domain thesis, we aim to cover some of the innovations that will help create a more trust-minimised world and others that will help alleviate many of the user experience concerns of our time.

We have intent to go deep.

Part two will cover; state/storage proofs, VM extensions, intents, optimal cross-domain trading and much more.

Thanks to Mathijs van Esch (Maven11), Pim Swart (Maven11), Dougie De Luca (Figment Cap), Jim Parillo (Figment Cap), Dmitriy (1kx), William (Volt) and Walt for review or discussions leading to the release of this article. Writer can be found at: 0xrainandcoffee

Shared Sequencer Networks has primarily been covered by Alex Beckett, and later more in-depth by Evan Forbes from Celestia and the Espresso Systems team (as well as Radius), alongside the new incredible pieces by Jon Charbonneau. Josh, Jordan, and their team at Astria are building the first Shared Sequencer Network in production. Astria’s Shared Sequencer Network is a modular blockchain that aggregates and orders transactions for rollups, without performing the execution of said transactions.

In the Astria setup, sequencers send the ordered blocks to the DA layer, and also to the rollup nodes. Rollups get a soft finality guarantee from the sequencers, and the hard finality guarantee from the DA layer (after the block is finalized), whereafter they will execute transactions valid to them.

A shared sequencer network is essentially a rollup-agnostic set of sequencers that, as the name implies, can serve a cluster of different rollups. This has various trade-offs and attributes, which we'll get into later. First off, we must describe the properties that are most important for a sequencer (or set of sequencers) to uphold. In a rollup, the sequencer or sequencer set has a primary requirement of censorship resistance or liveness (some of which is inherited from the base layer, alongside security). This means that a valid transaction submitted to the sequencer must be included in the chain within a finite amount of time (timeout parameter). The shared sequencer set only needs to ensure that transactions are included in a block (i.e. crLists).  

Achieving both censorship resistance and liveness is quite difficult, as outlined in our Modular MEV part 2. In consensus algorithms like Tendermint, you’re ensured recovery after an attack. However, you lose out on liveness in the advent of an attack. Essentially, requiring all other sequencers to sign off on a block, instead of picking a bespoke leader, might not be the best option. While this increases censorship resistance, it’s at the cost of “centralization”, and MEV extraction to a singular leader. Another sequencing mechanic that could be used, could be something akin to Multiplicity from Duality. Which is their gadget for non-leader nodes (or sequencers) to include additional transactions into a block. Overall, post-attack censorship resistance and liveness is difficult to achieve in most consensus protocols.

Another possible consensus algorithm, that could be used, could be something like HotStuff 2, which ensures liveness during attacks.

What it allows for is to avoid having to wait for the maximal network delay (timeout) before picking a new leader, in case of censorship or non-signing. The reason it might be an interesting consensus algorithm for decentralized sequencer sets is that it addresses the issue of liveness in consensus without adding an extra phase. If a leader knows the highest lock (the highest number of actors that agree on a specific output) and can convince honest parties, the issue is solved. If not, honest leaders after a specific point can drive progress responsively, aiding the next leader. For example, Hotstuff nodes do not need to confirm the switching message before notifying a new leader, instead it can directly switch to the new view and notify the new leader. 

Where it differs from Tendermint is that despite both being two phases (Hotstuff I had three, II has two), Tendermint has linear communication, but is not responsive, which Hotshot2 is. If a sequence of honest leaders exists, the protocol is optimistically responsive because all steps (except the first leader's proposal) depend on obtaining a quorum of messages from the previous step. In a shared sequencer setting, this makes it possible for the protocol to achieve better liveness without needing to fall back onto the underlying layer, without removing the possibility to do so.

A set of sequencers is allowed to submit transactions to the settlement layer (which the rollups inhabit). You can join this set provided they meet certain requirements, and that the number of wanted proposers isn’t reached. This could be to optimize latency, throughput and so on – e.g. Tendermint stays relatively low). These requirements will be similar to how you'd become a validator on a certain blockchain. For instance, you have certain hardware requirements that must be met, as well as a starting stake, or bond – this is especially important if you want to provide economical soft finality. 

A shared sequencer set (or really any decentralized sequencer set) consists of several components that work together to ensure that transactions are processed. These components include:

1. JSON-RPCs for each rollup for transaction submission (for non-full-node-runners) to node(s) that function as mempool(s) before building and ordering. Within the mempool, there needs to be some mechanism to decide on queue, as well as transaction selection processes to ensure efficient block construction

2. A block/batch builder algorithm, which processes the transactions in the queue and turns them into a block or batch. This step may also include optional compression to reduce the size of the resulting block (calldata compression). This should, as noted earlier, be separated from the proposer – essentially PBS. The compression of data, can come in the form of several ways, such as:

   1. No RLP encoding—However, this would likely be needed for a decentralized sequencer set, to help standardise the transfer of data between nodes in a space-efficient format.

   2. Omitting the nonce (unique number that validates data in a certain block)—it can be recomputed when required for execution by looking at the prior state of the chain. 

   3. Gas Price Simplification—set gas based on a fixed range of prices. 

   4. Gas Simplification—beyond just gas prices, also the gas numbering system

   5. Replace address with an index—Instead of storing the full address, rollups can store an index for a mapping of addresses stored elsewhere. 

   6. Value in Scientific Notation—The value field in an Ethereum transaction is priced in wei, making it a large number. You cannot omit the value field or reduce it to a fixed set of values. However, you can write it in scientific notation instead of wei to save on data.

1. Omit Data Field—Not needed for simple transfers, however on more complex transactions it would be needed.

   • Replace Individual Signature with BLS Aggregate Signature - The signature is the largest component of an Ethereum transaction. Instead of storing each signature, you can store a BLS aggregate signature for a certain number of transacitons. A BLS aggregate signature can be checked against the entire set of messages and senders to ensure validity. 

   • From Field as index - As with the To field, you can add the from field as an index to a mapping. 

   • One interesting notion of “modular” design is that you can also play around with this and make trade-offs where you see fit, to make it fit your specific rollup’s case.

3. A peer-to-peer (p2p) layer, which allows the sequencer to receive transactions from other sequencers and gossip blocks after building. This step is crucial for ensuring that the shared sequencer can work effectively across multiple rollups.

4. Leader rotation algorithm for the shared sequencer set (they don’t need to reach consensus, in the case of single leader election). You could choose to just have a leader rotation algorithm in place. Another route is to go down the multi-concurrent block producer road, as proposed by Duality. 

5. A consensus algorithm, for example the earlier discussed Tendermint or Hotstuff2, to ensure that rollup nodes are in agreement with the proposed ordering of the ledger.

6. An RPC client for block/batch submission to the underlying DA+consensus layer, which ensures that the block/batch is securely added to the DA layer, which ensures “final” finality and that all transaction data is available on-chain.

7. Separation of builder and proposer roles to ensure fairness and consistency, and to avoid MEV stealing. Alongside removing the execution from the ordering, something that’s important to optimize efficiency, lower PGA and heighten CR.

Rollup nodes receive ordered blocks from sequencers for soft commit & receive ordered DA layer blocks for hard commit

Transaction data (calldata) is first posted onto a base network, where consensus is performed to guarantee transactions for both users and rollups. Then, the rollup nodes execute the transactions (and commit to a state transition function that is added to the canonical rollup chain). The shared sequencer network provides rollups with their liveness and censorship resistance. Rollups maintain their sovereignty because all transaction data is stored in the base layer, allowing them to fork away from the shared sequencer at any time. The state root from the state transition function (STF) on the rollup side is calculated from the transaction roots (inputs) sent to the DA layer from the shared sequencers. On Celestia, this is generated as data is added to the chain and reaches consensus. As you already have the tx root (and all available data), Celestia can provide a small inclusion proof for light clients (that rollup nodes run on Celestia). 

To provide users with the UX they have come to expect, the rollup nodes receive the ordered block (that is also sent to the DA layer). This can provide the rollup with a soft finality guarantee—a promise that the block will eventually be ordered as is on the DA layer, which is when the rollup nodes execute the transactions and provide a new state root.

To determine the timing for block creation, sequencers need to establish a concept of slots. Sequencers should submit batches at regular intervals, typically every X seconds, where X is the slot time. This ensures that transactions are processed in a timely and efficient manner, since otherwise the leader for a specific slot would be timed out, and lose its signing reward (and execution rewards). For example, Celestia’s block time (according to GitHub specs) is likely going to be around 15 seconds. Because this is known, we can make some assumptions about how many “slots/blocks”  we could potentially fit into a finalized block from the shared sequencing set to the DA layer and rollup nodes. Considering optimized Tendermint, or something like Hotstuff2. 

Multiple batches can be submitted in a single slot, assuming the design allows the rollup full nodes to efficiently process them into a single block (within the slot’s time and timeout parameters). This can help to further optimize block creation and ensure that transactions are processed quickly. Additionally, slots can also be used to facilitate sequencer leader elections. For example, you could pick a slot leader randomly from among the stake pool, based on stake weight. Doing this in a way that preserves secrecy, makes the most sense, and utilizing something like Secret Leader Election would probably be preferred, to minimize censorship. Or even Distributed Validator Technology (DVT) type setups (such as Obol/SSV-esque solutions). Latency and slot times have considerable effects on how block submission and building affect the protocol. It, therefore, makes sense to look at how this can impact systems. Bloxroute especially has some great research and data points into how their relays have performed on Ethereum. In MEV-Boost the participating proposers (validators, or in a rollup case, sequencers) request from the relays a GetHeader. This provides them with the block bid, which is the value of a specific block. This is likely to be the highest value block received every time. For each slot, validators usually ask for a GetHeader around 400ms after slot time starts – and since there are obviously numerous validators – relays often have to serve countless requests. This would also be the case for a large shared sequencer set. This means that you need proper infrastructure in place to facilitate this. 

Relays also help in facilitating builder and proposer separation, while also working to verify that blocks built by builders are correct. They also check if fees are paid correctly as well and act as DoS protection. Additionally, they essentially act as escrowers of blocks and also handle validator registrations. This is particularly important in a world of unbounded sequencers, where you need proper accounting for who is participating, and who’s not (e.g. the syncing layer discussed previously).  

In terms of when blocks are ready (as in submitted by the builders), they are usually presented around 200ms before, or after slot start. Although, just like with GetHeader, there’s a considerable variance, but primarily they get served around 200ms before/after slot time starts. In the case where builders are sending to several relays, there’s actually quite a bit of latency. Bloxroute also looked at what happens when blocks are sent to several relays. As you might expect, the more relays blocks are getting propagated to, the more latency. On average, it took a second relay 99ms for the block to be available, another 122ms for the third and yet another 342ms for the fourth relay. Source: 

As might have been clear over the last couple of months, RPCs are incredibly important to blockchains. Not having the proper infrastructure in place is a massive burden, and having a proper selection of RPCs is also vital. In that vein, RPC inclusion is, therefore, crucial for retail users who send their transactions to RPCs (and the public mempool). Bloxroute made a small test of 20 transactions which were sent to various RPCs, and then measured how long it took each transaction to be included in a block. 

Source: Bloxroute Labs 

What was interesting to see is that some RPCs took several blocks to include the transaction, since it was dependent on what builder won the respective next block. The more builders that transactions are sent to from the RPC, the higher likelihood of a fast inclusion. Although there’s the chance that transaction originators could utilize their uniquely positioned order flow to target a specific builder or even build their own blocks. 

On the statistics front in regard to relay performance on Ethereum, it is interesting to look how they’ve performed as well. This helps us provide a more in-depth understanding of how PBS works in a multi validator/builder/relay world, which is hopefully where we are heading concerning rollups in general. Metrika has some great stats on this, and all credit goes to them for these data points.

What should be noted here is that a missed bid is just when a relay is expected to relay a bid, but does not. Expectations of bids come from validators that are registered to specific relay for any given slot. This is not a fault in itself for a relay, and isn’t treated as such on a protocol level, either.

Source: app.metrika.co 

If a bid fault were to happen (e.g. relays providing invalid blocks), and it was responsible, then it would count as a bid fault. These are usually not that frequent, and are for the most part registration preference faults (which is when gas limit or fees don’t meet the specific validator’s registration preferences). More rare are consensus layer faults, which is when a bid doesn’t align with consensus layer rules of Ethereum, such as timestamps being wrong or parent hashes not aligned with previous blocks etc.

In terms of latency (e.g. the time it takes a validator to receive a response for a block header built by a builder) the data is quite consistent. Although there are some outliers, for example if a relay that is being requested is in a different geographical location than say the chosen validator. 

 Source: app.metrika.co 

In terms of builders, the total builders over time on MEV-boost are around 84, of which the top 3 builders account for around 65%~ of built blocks. This is somewhat misleading, since these are also the longest running builders. Although it does showcase a somewhat centralized builder role still, as if you lower the timescale, we get similar results. In terms of actual active builders, the numbers are much lower, 35 in the past 30 days and 24 in the past week. The competition is tough, and the biggest and baddest usually win out. Something that exclusive order flow is likely and already only adds to. We expect the distribution of builders to remain somewhat centralized (due to it being a game of having the best order flow and hardware optimizations) around a few parties unless we get significant changes to the setup. While not a fundamental issue, this remains a centralizing force in the stack, and we are keen to learn about ideas on challenging the existing state of affairs here. We highly recommend reading Quintus’ piece on order flow, auctions, and centralisation if you’re interested in digging deeper into this (severe) topic.

In terms of where we expect to see the builder role moving forward in the modular stack, we are quite certain that (at least in Cosmos SDK setups) are going to see Skip/Mekatek type setups via Builder Modules. Another solution is SUAVE type setups—e.g. a specific global builder chain that services any arbitrary number of chains with block building and bid preference services to ensure PBS. We’ll cover this solution more in-depth later, and present some answers to some of the open questions around this.

On relays, we highly recommend a piece by Ankit Chiplunkar of Frontier Research and Mike Neuder of the Ethereum Foundation. The name of which is Optimistic relays and where to find them. Which goes into great detail of how relays in MEV-boost operate, their current tradeoffs and cost of running among possible changes that can be made to increase efficiency. An interesting note is that by Flashbot estimations, currently running a relay in MEV-Boost costs around ~$100k/year.

As a precursor to how we view finality concerning modular blockchains (as they look now), here is a refresher from our previous Modular MEV piece. Do note that this is not an “official” nor comprehensive view of finality; however, we feel that it most accurately represents the nuances of rollup finality in an easy to understand mental model. 

Pending_On_L2: Soft commitment given by the rollup’s sequencer(s) that the users’ transactions will eventually be committed and finalized on the underlying layer, of which it derives security.

Finality_On_L2: The sequencer(s) has committed to the state transition function of the rollup, and the block(s) have been added to the canonical chain of the rollup

Pending_On_L1: Transaction input or output/state transition function has been posted to the L1, but the validity proof has yet to be posted, or dispute period has yet to end – this also requires two successive epochs to have passed for Ethereum. This is the point where most Optimistic rollups say finality has been reached, however according to the canonical bridge – there’s still, at this point, an arbitrary 7-day challenge period.

Finality_On_L1: The dispute period has ended for Optimistic rollups, or the validity proof has been posted and verified, as well as confirmed in two successive epochs with a supermajority.

Now on sovereign shared sequencing rollups, this looks slightly different, let’s try to explain it with a diagram:

In this situation, we in theory get finality on the L1 before the L2, wait what? Yes, the L2 in this case is sovereign after all. This is assuming no fraud proof & challenge period, or that you’re using a validity proof. 

So, how do we actually achieve these levels of finality? Block finality is achieved when a block is added to the canonical chain and cannot be reverted. However, there’s some nuance here depending on the view of a full or light node. In the case of an ordered block, it is final once it has been included in a DA layer block. An executed block (w/ state root) is executed by rollup full nodes/validators which gives them guarantees of a valid state root derived from the ordered blocks on the baselayer. Finality beyond full nodes (e.g. for light clients or bridging) have to be convinced of the validity of said state root. Here, you can utilize one of the methods described below. Furthermore, another method is also having validators be held accountable for the correct attestation to a state root (the optimistic route), via a bond and subsequent fraud proof. You could also supply a validity (ZK) proof. 

There are different ways to achieve block finality:

1. Probabilistically, through proof-of-work (PoW), LMD+Ghost, Goldfish, Ouroboros (PoS) etc.

2. Provably, when the block is signed by enough committee members. (e.g. Tendermint 2/3rds, Hotshot2 or other PBFT types) 

3. Depend on the ordering of transactions/blocks on the DA layer so that it rules what is the canonical chain, and fork choice rule (E.g. Based).

There are different types of finality that can be achieved through different mechanisms.

One type of finality is “soft finality” (e.g. pending) which can be achieved if a single leader election is implemented. In this case, every slot will only have one or zero blocks (commit or not), and the syncing layer can safely assume the ordering of the transactions in these blocks.

Another type of finality is “provable finality” which provides stronger guarantees (essentially final) than soft finality. To achieve provable finality, a majority of sequencers must sign off on a block, thereby agreeing that this block is canonical. While this approach is nice to have, it may not be necessary if single leader election is already implemented, as it essentially guarantees block ordering. Obviously, this depends on the specific leader election algorithm in effect. E.g. is it a 51% implementation, a 66% or single leader (preferably random (VRF) and secret). If you want to read further on finality in Ethereum specifically, we highly recommend this piece, alongside one we’ll recommend for unbounded sets later on.

To prevent potential DoS attacks, it's essential to have economic barriers in place to both join the sequencer set and submit transactions to the sequencer layer. In both bounded (limited number of sequencers) and unbounded (unlimited) sets, there must be an economic barrier to submitting batches to the DA layer to prevent the syncing layer (that propagates blocks between sequencers) from being slowed down or DDoSed. However, the DA layer itself provides some protection, as there's a cost involved in submitting data to it (da_fee). The bond required to join an unbounded set should cover any additional cost necessary to protect against the syncing layer being spammed. On the other hand, the bond required to join a bounded set will depend on the demand (equilibrium from a cost/revenue perspective). 

With an unbounded sequencer set, provable finality on the sequencer layer is not possible (since we’re never quite aware of how many active voters/signers that are there). On the other hand, with a bounded sequencer set, provable finality can be achieved through a (super)majority of sequencers signing off on a block. This does require the syncing layer to be aware of the sequencer layer and which sequencers are active at any given time, which is some added overhead. In a bounded sequencer set (e.g. max 100), you’re also able to optimize the number of sequencer for “performance”, although at the cost of decentralization and censorship resistance. The importance of a bounded set, and an economical bond, is the ability to provide “fast'' provable finality, which is also deterministic. 

Both the unbounded and bounded sequencer types are something we also see in legacy blockchains, such as with PoS in Ethereum (Casper+LMD-GHOST), which is unbounded; PoS in Cosmos SDK/Tendermint based chains that utilize a bounded set.  One interesting thought is that, do we expect similar economics and choices from the community surrounding shared sequencers, as we’ve seen in Proof-of-Stake? Here we’ve seen a centralization towards a number of entities (hence unbounded doesn’t really matter, if you have a few large staking providers/pools anyway). Although, they do “mask” the centralization, and after all, you can still home-stake, if you wanted to. From an ideological perspective, the choice should almost always be unbounded – but bear in mind that the economics make them very similar regardless. Regardless of who the participants are, the economics of what you’re paying for should still be equal, e.g. cost of DA and hardware cost (although this might be lowered by the amount of stake allocated to you and experience, alongside running infrastructure efficiently already). Even in the bounded PoS world, we’ve seen a group of infrastructure providers becomes essentially the largest and most often seen validators across almost all chains. The correlation is massive between validators across most Cosmos chains already, which is also certainly a danger to the decentralization and censorship resistance of said chains. Although, one thing that is quite different is the fact that any retail user can stake any amount, to any validator of their choosing. Sadly, this is typically allocated to the top of the list, and life goes on. Yet again, we ask; do we expect similar economics to take place in the modular word? One would hope not, but as we specialize, you often want the best person for the job – which more often than not is expertise staking providers. We will also cover these economics later on, in a separate section.

However, one important thing to remember in all of this, is that at the end of the day, what matters most is end-user verification – which with light clients and DAS, is available to anyone, anywhere (even at the Pyramids of Giza); 

Source: @JosephALChami

The trade-offs and positives of unbounded and bounded in sequencer terms, can be summarized to:

Unbounded Sequencer Set:

• Anyone with a sufficient bond/stake can become a sequencer = high level of decentralization

• No single leader election is possible, as the set is potentially infinite.

• Non-single leader election via VRF is possible, but difficult to determine VRF parameters without knowing how many sequencers there will be. This should also, if possible, be a secret leader election implementation to avoid DoS attacks. 

• If no leader election = wasted resources problem: block building is essentially a free-for-all, and whoever submits the first valid block/batch wins while everyone else loses.

• No provable finality on the sequencer layer, only probabilistic – e.g. LMD Ghost+Casper

• Finality can only be reached once the batches are written to the DA layer (limited to underlying layers block times, 15 seconds in Celestia’s case).

• “Better” censorship resistance than a bounded set.

Bounded Sequencer Set: 

This is, for example, one of the solutions for single slot finality in Ethereum, alongside having super “majority” committees. See this.

• The number of permitted sequencers is limited at any specific time.

• A bounded set is potentially more complicated to implement than an unbounded set.

• Single leader election can be implemented, giving strong finality guarantees on the sequencer layer.

• The syncing layer needs to be aware of the sequencer set to know which blocks are valid.

• Writing the sequencer set (or set changes) into settlement layer blocks (e.g. fork-choice rules), which are written to the DA layer, can allow the syncing layer to determine the sequencer set independently. For example, this is how Sovereign Labs’ rollups function, the set changes are written into the validity proofs that are posted to the DA layer.

• Strong finality guarantees on the sequencer layer may not be necessary if the DA layer's speed is sufficient (However, most current setups that aren’t optimized settlement layers have at least 10+ second block times).

Regarding how these sequencer sets are monitored, and new entrants are added, or removed, there’s still quite a large design space for how this should be implemented. E.g. is this going to happen via token holder governance (and how do you then account for the many different tokens and rollups that are utilizing the set?). This means that it’s likely to be done via off-chain social consensus that signals on-chain changes (e.g. the Ethereum way). However, do keep in mind that the actual on-chain consensus is obviously in place regarding slashing for breaking consensus rules. 

The economics of a shared sequencer network allow for some interesting options. As we discussed before, a validator in a shared sequencer network isn’t too different from your typical L1 validator. The network it participates in is just more optimized for doing one task, receiving intents (pre-PBS) and consequently proposing and ordering transactions. Like a “regular” validator, there is a revenue and cost component. On both sides of the equation, the network the validator participates in has a lot of flexibility, similar to regular L1. 

Revenue is sourced from users, or the rollups they ultimately aim to interact with, who pay a certain fee for usage of the shared sequencer. This fee could be a percentage of MEV extracted (the input number might be hard to approximate here though), cross-chain value transferred, a gas like construct or a flat fee per interaction. The most elegant revenue solution is probably a setup where the value paid to the shared sequencer is less than the additional value gained by sharing a sequencer amongst rollups and getting the benefits of shared security and liquidity. The downside is that the benefits of decentralization of another part of the stack are hard to quantify. However, as a shared sequencer network grows into its own ecosystem, its ability to extract fees will probably increase. This is in a large part due to their inherent ability to easily aggregate, and it has somewhat an economics of scale effect. As more and more rollups, and consequently applications, join the network; the more cross-domain MEV is extractable. 

On the cost side, the shared sequencer network also has optionality to compete. They could easily subsidize usage of their network by fronting the cost of posting to the DA layer, or even for interacting with apps on the rollups itself. This would be similar to strategies used by web2.0 companies, whereas you take an initial loss on user (or rollup) acquisition in the hopes their long-term revenue will outweigh the expense. Another more novel, or crypto native, approach on this is allowing rollups to pay for DA fees in their native token. Here, the shared sequencer layer takes on the pricing risk between the token needed to post data on the DA layer and the native token of the rollup. In essence, it is still a shared sequencer fronting the cost; however, it creates ecosystem alignment by acquiring a token of a ‘supplier’ (the rollup) instead. This is somewhat similar to the warehousing construct we set out in the appchain thesis. Other parts where a cost reduction is possible is by utilizing different forms of DA. Different DA layers will offer different pricing due to utilization, the ability for users to easily verify through light clients or outright make different blocksize choices. Finally, the shared sequencer can also batch transactions before posting to the DA layer. In the case of ZKR this could allow for lowering tx costs due to a certain equilibrium of transactions, on the ORU side you could do various batching gas optimisations that we currently see live on various rollups. This would decrease the amount of data needed to be posted on the DA layer, thus lowering the cost of the shared sequencer network, increasing the profitability of the overall network. It does come at the cost of limiting interoperability and changing the time to finality (in the sense of finality on L1 as discussed earlier).

Overall, the economics of a shared sequencer network allow for some interesting experimentation and bootstrapping strategies. We estimate that the key differentiation will be the size of the ecosystem and hence the amount of cross-domain MEV and less so the cost side of things. We also highly recommend checking out the Espresso team's very in-depth blog posts on shared sequencing, they also cover some of the economics trade-offs (and positives) of these types of networks as well. To showcase another way for why rollups are incentivized to utilize shared sequencing (beyond the economics of it), it makes sense to look at aggregation.

Another way to describe the properties that shared sequencers enable is through the lens of aggregation theory. Aggregation theory (AT) is the concept of how platforms or aggregators can gain significant user traction through a systematic way of integrating other platforms and their users. You essentially change the game from distribution of a scarce resource (e.g. blockspace) to controlling the demand for abundant resources (again, blockspace in this example makes sense). AT is essentially aggregating the suppliers and products (i.e. rollups and blockspace) into a single superior user experience for an aggregated user base. This relationship becomes increasingly exclusive as the network effects of these aggregators grow – there’s no reason to move away. As this happens, the user experience is what becomes the vital differentiating factor between similar setups. If the incentives for new users are there (e.g. good UX and easy interoperability), then the likelihood of a rollup moving to their own network or a different set is unlikely – since network effects drive new suppliers and new users. This creates a flywheel effect, both from a supplier and user perspective, but also from an aggregated censorship resistance view. 

Source: Aggregation Theory 2015, Ben Thompson

In the vein of shared sequencers, AT can be seen through the almost “combination” and alliance of rollups that all utilize similar vertical parts of the stack – strengthening themselves and others, while enabling users to have the same experience, anywhere.

Suppliers (e.g. rollups) aren’t exclusive in theory in shared sequencer sets, however in reality; the shared sequencer set, it’s rollups and users benefit from a cycle of network effects that lead to increased usage of said rollups. These benefits make it easier for rollups and users to integrate with the shared stack, since they would lose out more by not participating. While these benefits may be hard to see when you only have two rollup sharing a sequencer set, it becomes a lot more clear as you add increasing numbers of rollups and users to the equation. The shared sequencer set has a direct relationship to users, as they order their transactions, even if the users themselves have no idea they’re even interacting with them – since from their perspective, they’re just using a rollup that they have reason to interact with (meaning the ordering/sequencers becomes exclusive). The only cost associated with these sequencers is essentially the cost of the hardware that they’re run on, as long as the blockspace and token that secures it is valuable to the end-users. The transaction fees are digital and paid from the users’ wallets, mayhap in the future, even abstracted away with advances such as paymasters within account abstraction (however, someone will have to bear the cost of DA, sequencing and execution).

This makes even more sense when you consider where Josh and Jordan from Astria formerly worked – Google. Google products have since inception been heavily inspired by the ideas of AT, this is especially prevalent with Google Search, which was created by modularizing (lol) individual pages and articles, making them directly accessible via a global search window. 

The customers in this case of the shared sequencer set (users of rollups) have an increasingly low acquisition cost, since they are likely to be attracted to the set as the number of suppliers (rollups) increase. This does mean that, in most cases, aggregators (or multi-aggregators) have a likely winner-take-all effect, since the value of this aggregator increases with the rise of suppliers (as long as the user experience is good, of course). In contrast, on singular sequencing networks, the customer acquisition is limited to a single network and its applications. If a user wants to utilize a rollup application that’s on a different rollup, they will (within current limitations) have to move off the network entirely. This means that the stickiness of users and value isn’t very high, and also means that at any moment, if a different rollup ecosystem becomes highly regarded (or has more incentivization), capital could take flight.

A Shared Sequencer set is a rollup network which aggregates and orders transactions for multiple rollups. These rollups all share the same sequencers. This pooling of resources means that rollups receive stronger economic security and censorship resistance, which allows for fast soft finality guarantees, and conditional cross-rollup transactions.

Now, there’s been quite a lot of noise on Twitter surrounding atomicity between rollups that are sharing the same sequencer set. This is primarily set around the fact whether it is atomic by default, or not – it is not. However, if the rollups in question have implemented each other’s state transition function (STF) as a dependency between them regarding conditional transactions – they could indeed have atomicity between them – as long as their slots/block times line up (which they should with a shared seq. set). In this case, to get atomic interoperability, you would essentially just run a light node of chain A on chain B and vice verse (similarly to how IBC works). To further this interoperability in terms of security measures (beyond trusting a single full node as a light node), you could implement ZKPs (state proofs, essentially) to solve the “oracle issue” of making sure state is indeed correct. This would give more clarity surrounding if conditional txs or similar have touched the canonical bridge between them. Fraud proofs is also a possibility, but would obviously leave us with a challenge period (which would mean third parties would pop up to take that risk for a fee). Furthermore, in the light client (and not full node on each other's case) it would be lagging behind at least a block, as a result of waiting for the signed header + fraud proof window (if any).

We’re of the belief that “bridging” is most likely to be solved in conjunction with light clients and ZK. The challenge of using light clients in this case (and not smart contracts) is that hard-forks on the rollup node sides (upgrades etc) would need to be done in conjunction with each other to keep their bridge running (just how IBC needs the same state module enabled). If you’d like to read more on this specific topic (and how to solve it) – we highly recommend this presentation. 

What makes shared sequencers incredible scalable is the fact that they’re not executing and storing any state (as centralized sequencers do now). The same goes for the rollup nodes themselves (they don’t have to scale to 100s of nodes, unless they want an atomicity between them – e.g. light clients/state proofs). These nodes just execute transactions that are valid to their rollup, as well as any conditional cross-domain transactions that are valid to them as well. If the rollup nodes had to execute and store state for many, many rollups, it would hinder scalability and lower decentralization (in turn lowering censorship resistance). It also reinforces the concept of Proposer-Builder-Seperation (PBS). Although we still need to separate the builder and proposer completely. In the current setup, the sequencer is essentially a builder and proposer (although they do not execute the transactions). The ideal setup is likely that sequencers just exist to blindly sign off on built blocks coming from a highly optimized builder setup and making sure blocks are correctly implemented (while providing a high degree of economic finality and censorship resistance to that attestation). Through that, they can provide a high degree of security and commitment to guarantee soft finality to rollup nodes. 

For cross-rollup conditional transactions, they also exist to help enable rollup nodes (the executors) to provide intermediate state roots, allowing for atomicity between rollup. If you want a deep dive on how this could possibly look, then this brief presentation is perfect for you.

Tradeoffs

The timeout parameter that was mentioned earlier has some interesting effects on MEV and transaction inclusion, depending on the ordering and leader/consensus mechanism of the sequencer set. e.g. if the timeout parameter, as described in our application-specific chain thesis, is relatively short, it is key for proposers on the decentralized sequencer level to post data as quickly as possible. In such a world, you could get competition of “validators” of the decentralized sequencer set competing to act as a leader and outbidding each other for blockspace on the DA layer up to a point at which it is no longer economically desirable to do so.

As was covered by Evan in the original lazy sequencers post on the Celestia forums, waiting to execute transactions until they’re posted to a base layer (Celestia in this case) is quite wasteful. Since you’re now limited to the base layer’s blocktimes - which is a long time to wait for finality from a UX perspective. To get better UX, the shared sequencers provide a soft finality commitment to rollups (as discussed earlier) which gives us the UX that users are used to in existing centralized rollups (while staying decentralized and with high censorship resistance). The soft commitments are in essence just a promise of the final order of transactions, but backed by a heavy economic bond and fast final finality from the baselayer once posted. This is also covered by fraud proofs (as noted in the introduction). The actual hard finality comes when all tx data has been posted to the baselayer (meaning the L1 actually reaches faster finality). This is dependent on whether or not the rollups are utilizing fraud proofs, or zero-knowledge proofs for their sovereign proof verification – which happens on the rollup side. The reason for wanting this separation is to take away the heavy computation of state transitions from the sequencers (which is a huge bottleneck). Instead, the rollup nodes only handled the ones valid to them (which does mean we have to add conditional transactions, state proofs or light node verification for proper interoperability). Hard finality is still dependent on the base layer (but this will likely be around 15s with Celestia, and also deterministic w/ Tendermint) – which does provide us a high degree of relatively fast hard finality guarantees on the rollup side. 

It is also possible to utilize ZK proofs within the network to optimize validation, transaction size (e.g. only posting state diffs – but this does add a higher degree of trust until a ZKP is posted). These state proofs can, as covered earlier, be used to allow for connected chains/rollups to have much easier and faster interoperability (not having to wait for a challenge window).

One downside to these conditional transactions that were covered earlier is that they’re likely to be a lot pricier to verify and post (e.g. Tendermint block header verification is costly, and is subsidized on Cosmos chains) – as well as add some latency to the system (but still much faster that siloed rollups). The atomicity that is achievable because of the vertical shared integrations do make up for a lot of this. 

In the bootstrapping phase of a new rollup, going with a shared sequencer set makes a lot of sense – and the positives that you’ve gained as a supplier will likely outweigh some of the trade-offs that you might be “forced” to make on a moat level. However, for already mature rollups with a lot of transaction and economic activity – giving up part of your moat likely makes little sense. 

This brings into question whether we would need something like an economic/transaction (per rollup) weighted redistribution of extracted MEV to entice already mature rollups to join a shared set – or even keep extremely mature rollups and avoid having them spin out their own network. This is all quite theoretical, but it’s certainly an interesting thought process surrounding how MEV would look in a shared vertical world between many rollups that have varying degrees of activity. For example, if a singular rollup that drives much of the value through the sequencer set is sharing parts of these profits with others (that might not be bringing in as much “value”), there’s certainly more reason for them to move to their own siloed system. Sreeram from EigenLayr has some thoughts here too, which we recommend reading as well.

This also becomes increasingly important when you consider the fact that searchers have a considerable technical cost to work on a new chain, so standardizing this and providing some sovereignty to chains regarding “their” MEV is probably a good starting point. Essentially, in MEV the dominant interface (or software) is likely to win out – however actually monetizing this software is incredibly difficult, unless you run key parts of the infrastructure (leading to centralization). On a market level, what shared sequencers provide is essentially a common mempool for many suppliers, with a centralized auction that would likely lead to more healthy competition.

A worry here is that in the case of two rollups both running a sequencer in the shared set. A rollup (A) with “less economic” value running a sequencer could be elected to propose blocks with a high amount of MEV + fees originating from a rollup (B). From rollup B’s perspective, they would essentially be missing out on some of the value, that they in a siloed approach would keep to themselves. 

Another note on the proposed tradeoffs made regarding interoperability, another way to solve some of these issues, is summarized below:

The point of the shared sequencer network is that it gives a guarantee of canonicity for multiple chains, which is certainly a big advantage in this case. This can be combined with a mechanism to give a guarantee over a valid state transition between rollups. This could be a committee-based approach (e.g. PoS), a bonded attestation (Optimistic approach), or the one that we prefer – a ZKP backed by a committee signing. Because the shared sequencers are “lazy” they only create mega blocks which order transactions for multiple rollups, and the execution of said transactions is left to the specific rollups. State proofs (i.e Lagrange, Axiom, or Herodotus and others) are all possible solutions to potentially get attestation to finality across sovereign rollups as well. You could even add economic bond finality attestations via things like staking pools, EigenLayr and more. The idea is that the shared sequencer gives an economic guarantee of the canonicity of ordering, and generating a validity proof from this ordering is as such deterministic. The basic idea is that rollups can synchronously execute transactions across each other. For example, two rollup node networks can be conditionally aware that the two rollup histories are valid via ZKPs and available (with the data published to an efficient DA layer). The rollup nodes can then settle both rollups simultaneously by posting on-chain a single-rollup block prefix received from both network A and B. One of the things that does need to be said, and we covered this earlier slightly – is that cross-rollup atomic (or synchronous) transactions are likely to be pricier than singular intra rollup transactions. This is because conditionally cross rollup transactions are consuming resources from two independent systems via shared execution.

Succinct also has a write-up on cross-chain “atomic” transactions between rollups with a shared sequencer (and shared fraud prover) within the Optimism superchain ecosystem that can be checked out here. Also, as Bo Du from Polymer puts it; “Cross chain atomic txs are like acquiring a lock across database shards for a write”. 

Jon Charbonneau and others have already gone quite in-depth into the inner workings of how a SUAVE like chain would possibly look, so we won’t go too into detail. You can check out his pieces if you want a more detailed description. Although, we do feel that vertical integration does deserve its own part, both to highlight how incredibly modular we can really go (and why) and some of the open questions and concerns surrounding vertical integration. 

While the current shared sequencing proposals from both Astria, Espresso and Radius are incredibly modular, the sequencers are still acting as both builders and proposer (although in the Astria case, they do not execute transactions). Astria is also actively building PBS into their architecture from the get-go.

There are several ways to achieve PBS if it’s not already built into the protocol (although at varying degrees of decentralization). Something like SUAVE, using an off-chain model such as MEV-Boost, or implementing builder modules (such as the Cosmos SDK ones being built by Mekatek and Skip).

What’s important to note is that neither of these are exclusive. You could flexibly utilize several different methods, and have anyone express their preferences. Whereby you’d have executors compete to fill those. Adding more optionality is always good (and adheres to our beliefs in modularity). Although, various implementations will have different trade-offs. With something like SUAVE, you do add privacy (with SGX or crypography) alongside cryptoeconomic security to the truth, instead of relying on a centralized PBS builder that is trusted completely. (Thanks to Jon Charbonneau for feedback here). 

A vertical integration into a builder chain would need to be done in a few that ensures fairness, and that doesn’t cut corners and increase latency and lowers performance. As such, a builder chain would need to be incredibly optimized, and likely require costly and performant hardware (leading to centralization). This means that to get end-user verification, we would likely need some implementation of light nodes (although they have to trust full nodes), or utilize a state proof type setup to ensure that chain and users have proof of bid preference being filled, and that blocks have been built correctly. 

A chain such as this would likely be incredible state heavy (which we would like to avoid). Although these state heavy transactions will be preference bids via smart contracts. In the case of preference bids, it either gets filled or doesn’t (in a short amount of time), since bids are usually only valid for a short period of time depending on the preferences. This means that we would likely be able to implement very efficient (and early) state expiry for bids – which would allow us to prune data and keep the chain “clean”. This expiry date needs to be long enough to still allow bid preference to get filled, although lowering it too much essentially makes it impossible to implement blockspace futures far into the future. The need to revive and retrieve expired bid contracts is unlikely to be needed, since they aren’t required to exist for infinity (unlike applications) – this can be made more “secure” and trustless by providing state/storage proofs as bids are filled, or via DAS storage solutions – such as the one proposed by Joachim Neu 

As we covered early, the need to verify the “truth” of SUAVE is likely going to be limited to “sharks” (power users) of the platform, since most users and customers of a SUAVE implementation all have significant economic gain to be derived from utilizing it. This could entice us to just have people run a full node, if they want to verify – although this excludes the vast majority of people (you could argue they have no need to verify). This is (in our opinion) antithetical to crypto, and we would preferably see verification of SUAVE happen “trustlessly” via state proofs or via a light client friendly implementation. 

The reason for needing this is that you’d want to verify that your bid preference were filled correctly, and that blocks are filled with correct information upon payout (to avoid weird rebundling and other exploits). This is essentially an oracle problem – which indeed can be solved for on-chain state (which all of SUAVE would be) via state proofs. Making these state proof cross-chain brings forward another problem though, how do we relay this information cross-chain in a way that makes it so nothing was tampered with or withheld? This could likely be via a strong economic finality attestation (such as the one presented by Lagrange, wherein you could use the re-staking validators of EigenLayr to attest to finality and truth of the chain with a very strong economic bond). This then brings forward a different problem (e.g. the bid contract specifies that the “oracle” – in this case restakers) have specified a token that is staked and provides the economic bond – but how do we then slash this outside of consensus? While you could code in slashing criteria, this isn’t in consensus and would mean social slashing would be utilized (which is hardly ever “fair”, and could lead to problems) via smart contracts. This is one of the bigger issues with slashing in EigenLayr at the current time.

So, where does this leave us? Likely in the situation that until we get on-chain “trustless” slashing outside of consensus, a SUAVE like chain would likely need its own consensus algorithm and cryptoeconomic security that attest to the finality of bid preferences and built blocks – however, that means adding more cryptoeconomic attack vectors, especially if its building blocks for rollups worth much, much more that its own cryptoeconomic security. 

Beyond this, there’s a super large design space for how a SUAVE-type chain and cross-domain MEV should look in general. Underneath are just some of the possible avenues to research:

• Intent Matching and Intent-Based Systems

• Convex optimizations in multi asset trades

• DSLs

• MEV redistribution

• Latency wars

• Scaling issues of having a single set of actors needing to build for the state machines of multiple rollups.

• Preference expression 

On preference expression, to interact with a smart contract in the EVM, a contract call (message) is sent to a specific function on an address with deployed code containing execution instructions. While users provide inputs, they may not have control over outputs due to potential statefulness.

In contrast, preference expression design systems (e.g. SUAVE and Anoma) only require users to sign preferences with a bond, which is paid to the builders and proposers if the preferences of the searchers are met. The implementation of different language and virtual machines may vary for complex combinatorial logic, such as transaction ordering for MEV searchers and builders. This is a new design space that is getting a lot of attention lately – especially surrounding the Anoma structure. We would recommend looking at the Anoma architecture here. And would highly recommend this short read as well, as an appetizer from Breck at Haun.

Much of this article wouldn’t be possible without the great research that has been done in this particular vertical. Many thanks to:

• Evan Forbes (Celestia)

• Alex Beckett (Celestia)

• The Astria Team

• The Espresso Team

• Flashbots

• Jon Charbonneau and Michael Jordan from dba (lower case research + a ton of other sources)

• Bloxroute Labs

Furthermore, we want to thank all the people, projects, and companies we reference throughout this article for their contributions to the space

The Modular Stack

If you’ve read any of our prior articles, or if you’re familiar with the way modular blockchains work, you’d know that they work quite a bit differently than their monolithic counterparts. With modular blockchains, you split off parts of the aspects of a blockchain that monolithic blockchains usually all possess. These are namely—Execution (Transactions/Smart Contract Interactions), Settlement (Dispute Resolution), Consensus and Data Availability. Now in a modular stack, you might have a data availability (and consensus) layer, a settlement (liquidity and dispute resolution) layer, and execution layers (hence referred to as rollup, however, keep in mind that settlement layers are rollups as well, in the modular stack). We’ve already looked at how the MEV supply chain looks in a monolithic setup, as well as in a semi-modular setup (with off-chain execution rollups), such as on Ethereum. When you start to split up more of the layers of a blockchain, it changes even further. If you need a refresher on the Modular Stack, we recommend reading up on our prior article – The Modular World. 

Inspired by Stephane’s great monolithic MEV Supply Chain Diagram and adapted to fit a Modular setup by r&c

This is an example of how a supply chain could look in a modular setup, regarding MEV. Underneath, we’ll take a bird's-eye view of how this looks in the entire stack:

In a modular stack, the sequencers essentially act as the builders in a monolithic setup. However, the sequencer also proposes blocks to the underlying layers to which they are connected. As such, we can both call sequencers builders and proposers. This is absent from any Proposer-Builder-Seperation (PBS) implementation, which would likely be implemented by third parties (or rollups themselves), to minimize PGA auction congestion on the execution layer.

The validators on the data availability layer are purely proposers, exactly like their counterparts on Ethereum(w/ MEV-Boost). Opposite, the sequencers essentially build blocks from bundles of transactions from users and searchers. They then send/propose these to the DA or settlement layer (depending on smart contract rollup or not), where the validators will include transactions/blocks based on the fee being paid (and into their respective Namespace). The Celestia validators are unable to reorder any transactions, just like their counterparts, as they would get slashed. 

Essentially, the sequencers, now builders, are able to put together the highest value block—which could contain cross-domain MEV opportunities, for example, to be included in the DA level block as soon as possible by the aforementioned validators. When a block is finalized on the DA layer, we essentially get complete finality on the rollup (Depending on rollup nodes having settled state, or dispute periods—although all data is now available). This opens up the opportunity for some interesting, and still somewhat theoretical, DA layer MEV interactions, which we’ll cover later on in the article. Before we start digging into cross-domain, bridging and DA layer MEV we need to understand how the modular stack functions in regard to liveness, finality, and incentivization which all affect how MEV is extracted and where. Alongside what off-chain actors inhabit the ecosystem. 

When talking about modular ecosystems, liveness becomes critical. This is because as you add more components to a stack, they all rely on each other and their liveness becomes even more critical. For instance, you need liveness between nodes on the various layers, but also between them and the DA layer. It is therefore essential that we also take a look at liveness in a modular setup. If you require a primer on liveness, then our previous article covers decentralized sequencers and methods for them to achieve liveness as well. In a modular stack, sequencers on specific rollups need to give liveness guarantees, but essentially derive some of their security from the layer below. In some cases, especially for app-specific rollups on top of a shared settlement layer, external sequencing is also a possibility. This would work in the sense that the rollup contract on the underlying layer (that has smart contracts) would be used to order transactions. In this setup, the users of the app-chain essentially just need to trust the underlying L1 for liveness—instead of having to trust another leadership election system (and it’s sequencer network). However, what this means is that the rollups in this setup would still be limited by the data sequencing abilities of the settlement layer—very much the case of rollups on Ethereum today.

An excellent way to illustrate how liveness works is by looking at the CAP Principle—Tim Roughgarden especially has an excellent explanation (alongside many other great lectures). CAP stands for three informal properties that you are required to possess for a distributed system to work as intended (regarding uptime and security). 

C: Stands for consistency, basically that the UX should be identical from user to user, and it should feel like you’re interacting with a single database every time you use the system.

A: Stands for availability, which is what we also refer to as liveness. The fact that all messages are handled by nodes in the system, and that they are reflected in future blocks/queries. All commands need to be carried out.

P: Stands for partition tolerance (or censorship resistance), which means that the system needs to uphold consistency and availability even in the event of an attack, or partition of network nodes. 

However, what the principle states is that no distributed system is able to uphold all of these properties. Here, C (consistency) is especially hard to achieve, while retaining all the other properties. To gain consistency, you usually have to give up on availability. However, availability (liveness) is a core property of a distributed system, so we can’t give up on that. This is the trade-off that most singular databases in web2 make, since they want consistency over anything.

Various consensus mechanisms make different tradeoffs depending on their setup when it comes to the CAP principle. For example, if Tendermint gets stake weight attacked, it might go into an asynchronous phase of a partially synchronous model (keeping consistency). The other side of the coin here is that the longest-chain consensus (non-fast-finality) gives up on consistency in the event of attacks.

What this basically shows is that you need to pick two out of the three, when your network is under attack. This means you either keep consistency or liveness.

So, why are we mentioning all of this? Well, it is crucial for the sequencer networks of rollups in a modular stack to achieve part of the CAP theorem. Otherwise, the MEV will be entirely taken by the team controlling that singular sequencer (unless other public goods setups are in effect, but there’s still a trust assumption in that case, the centralized sequencer and the team behind it). It is also to show that the sequencer set needs backstops in the case of liveness failure, to not lose consistency (or safety). One of the options that could be utilized to decentralize the sequencer set, is by using a stake weight leadership election algorithm. However, one of the issues that you might run into with requiring other validators (sequencers in this case) to sign off on blocks, is that of censorship. You already inherit your liveness properties from the underlying layer. In this case, optimizing for liveness, over post-attack safety (as is the case with Tendermint for example), might be the better option. Essentially, the network’s leadership election should only pick a leader that then proposes a block, instead of requiring other sequencers to validate the same block. We will go more in-depth on other solutions towards censorship resistance in the incentivization section.

One extra unique thing about running on a separate DA layer is that you can’t do a double spend, as all transaction data is published—unless you perform data withholding attacks; however, that should lead to slashing depending on the consensus algorithms used. In the case of similar DA layer attacks from validators, the consensus layer will also slash these. Moreover, in the case of data withholding, you can retrieve the data from the namespace (or similar).

The way sequencers of rollups maintain liveness outside the rollup system is through the underlying layer it is connected to, whether that is a settlement or DA/Consensus layer (however the settlement layer also retains liveness from the DA layer, so essentially the DA layer is what contingencies are built on top of). They are sending received transaction information to the underlying layer, which then gets sorted (in the case of Celestia) into their namespace. 

The resulting state roots of the transactions are settled either on the rollup’s own nodes or on the settlement layer in use. To uphold safety guarantees, the entire full transaction data has to be stored (or made available) on-chain. Although, we don’t need to execute it (since we do that off-chain). This is what provides us with data availability, which allows rollup nodes to see that all needed data associated with the rollup was published – to the underlying layer. This is where liveness and security are inherited from. 

In the case of ZK rollups, it relies on the censorship resistance of the underlying layer for its liveness, not security since you’re not required to monitor transaction validity (as it is ensured by the ZKP). However, regarding consistency, there are some variables (such as a trusted setup). Furthermore, as we pointed out in the last article, with ZKPs complex computation (and the time/cost it takes to do so) it means that sometimes batches can fall behind. This means that while some batches/blocks have finality on the execution layer, it might still take some time before they receive non-pending finality on the L1, which is when the recursively proven ZKP batch is verified (either via a verification smart contract, or from rollup nodes in a sovereign setting). The reason for this is both time/cost. The final cost of verifying transactions is cheaper if you verify a large amount at the same time, instead of more often. That means that even though you technically can lower costs with ZKRs compared to ORs, there are still some hurdles to how mature the rollups transaction activity is, before it reaches an equilibrium of cost and activity. This is bound to get lower and lower, as rollups mature and hardware acceleration tech, proving networks, schemes, and recursion increases in efficiency. 

Semantics (or subjective determination from the perspective of who the observer is). Does the trust-minimised two-way bridge decide what finality is? Well, that’s the way it would seem if you look at withdrawal times for rollups currently. This causes 3rd parties to pop up and take on inventory risk, providing instant withdrawals for end-users. We do think it’s relevant that we look at the difference between stages of finality, especially on the rollup side (particularly sovereign ones), so although much of this will be semantics – remember that semantics are important. 

Finality in rollups refers to the assurance that a particular transaction or set of transactions has been irreversibly committed to the blockchain(s). In rollups on top of Ethereum, this assurance is achieved through a combination of several mechanisms. 

In optimistic rollups, finality works differently compared to zk-rollups. Optimistic rollups primarily submit a compressed batch of transactions that include headers (showing what sequence of context is included), context (amount of txs, block info, time etc) and transaction data that commit to the rollups state transition function (which is then posted to the canonical chain). The rollup’s L1 smart contract then assumes that the transaction is valid and executes it. If the transaction is indeed valid, everything proceeds as normal. However, if the transaction is invalid, the rollup's canonical chain can be challenged. The challenge process involves submitting fraud proofs, which proves that the transaction(s) was invalid. If a valid fraud proof is submitted, the smart contract (and rollup nodes) will roll back the invalid transaction and revert any state changes that it caused in the canonical transaction chain. This means that optimistic rollups do not provide instant finality (despite all data being available) – instead, they have a challenge period during which transactions can be disputed (which is what the canonical bridge’s withdrawal period is based on). The length of the challenge period varies depending on the specific optimistic rollup implementation. However, the arbitrary period is currently set to 7 days, because of the valuable blockspace of the Ethereum network. If you want a flow diagram to help you understand Optimistic rollups (and how they work currently), I highly recommend L2Beats’ (click on the specific rollup you’re interested in)

The other is the use of zk-proofs to validate and bundle multiple transactions together into a single proof. These proofs are generated by the rollup's prover(s) after they have received the execution trace that attests to the validity of a certain rollups block batch. This gets submitted to Ethereum for verification by the smart contract governing the rollup (alongside either inputs or outputs as calldata, depending on the implementaion). Once the smart contract has verified the proof, it posts the relevant data, effectively committing the transactions to the blockchain. The on-chain mechanism is the use of Ethereum's consensus mechanism, which provides a final finality guarantee, which is enforced typically through “waiting” through two epochs of votes by a supermajority of the Ethereum validator set (different to deterministic consensus protocols, Ethereum is probabilistic). Once a validity proof has been verified on-chain, on the L1 it is considered final and irreversible, providing a high level of assurance that the transactions included in the block are also final. 

What should be noted is that the above is from the perspective of the validating (canonical) bridge to the rollup. If you’re purely a L2 user, then finality is going to feel much faster, and your transaction is essentially final when it is Pending_On_L1 (for Optimistic Rollups) or Finality_On_L1 (for ZK Rollups) (see underneath).

One mental model for the finality of rollups is putting it into 4 different stages, depending on the rollup. These are:

Pending_On_L2: Soft commitment given by the rollup’s sequencer(s) that the users’ transactions will eventually be committed and finalized on the underlying layer, of which it derives security.

Finality_On_L2: The sequencer(s) has committed to the state transition function of the rollup, and the block(s) have been added to the canonical chain of the rollup

Pending_On_L1: Transaction input or output/state transition function has been posted to the L1, but the validity proof has yet to be posted, or dispute period has yet to end – this also requires two successive epochs to have passed for Ethereum. This is the point where most Optimistic rollups say finality has been reached, however according to the canonical bridge – there’s still, at this point, an arbitrary 7-day challenge period.

Finality_On_L1: The dispute period has ended for Optimistic rollups, or the validity proof has been posted and verified, as well as confirmed in two successive epochs with a supermajority.

The L1 can have different finality trade-offs, e.g. Tendermint DA (deterministic) is quicker to reach finality than Bitcoin DA and ETH DA (probabilistic). However, the probabilistic model makes fraud proof considerably easier to implement. It should be noted that the STF commiting to the canonical chain, happens on the L1 as well.

The soft confirmations given by a single, centralized sequencer are possible because of the (trusted) promise from the sequencer that it will not reorder transactions, nor touch MEV (Also, the sequencer can provide instant transaction confirmations by requiring a security bond that will be forfeited if the promised block inclusion is not met, ensuring economic finality). If we move beyond centralized sequencers to decentralization of the sequencer set, much of this MEV is likely to be extracted by the chosen leader for a certain rollup block, or from a different mechanism (as we covered in part 1). There are and should be mechanisms in place to avoid reordering of transactions by a proposer, that they received from a builder (or FCFS), which should be punishable by the slashing of the sequencer’s bond. This bond should be high enough to avoid sequencers doing so, but also not high enough to gate keep the ability to become a part of a permissionless sequencer set – a fine line to walk. This is why the ability to force transactions through, to either the underlying smart contract of the rollup, or the DA layer where transactions data is posted – is incredibly important. 

For sovereign rollups, finality works slightly differently, since we don’t have to post proofs and calldata (tx data) to a congested L1. A recent post by Cem Ozer and Preston Evans goes into detail into exactly how this is possible with sovereign ZK Rollups. What's critical to note in this specific setup, especially in regard to MEV extraction, is that this design inherits the transaction (and proof) ordering from the base layer. Which means that the proposer on the base layer becomes the leader. This is similar to the "Based" design, which we'll be referring to several times in this article when referring to inheriting the ordering of the base layer (essentially outsourcing sequencing to the L1). When this is the setup, you're also now dependent on the block time (as a result of outsourcing sequencing and ordering) of the base layer.

If a rollup posts state-diffs (such as Starknet and ZKSync), even running a full node won't help reduce latency (since the full transaction data isn’t available). Most zk-rollups today use centralized sequencers to give soft finality guarantees (a commitment to the end-user that eventually the transaction data and proof will eventually make its way to the L1). But to make decentralized zk-rollups competitive on latency, we need to reduce latency for light clients. It is possible to do this without increasing proof verification costs by creating proofs in real-time (timestamps) and using recursion to aggregate them into a batch proof later (such as on Bonsai Network). As long as you distribute incremental proofs right away via the p2p network (on the rollup side) prior to the on-chain batch proofs, light clients will experience fast soft finality. However, the fast finality guarantees that the light client is given is only as fast as the block time of the underlying DA layer (since the Pure Fork Choice Rule is inherited from it).

The slower batch proofs are still posted on-chain (such as with existing ZK Rollups), so there's no extra cost for on-chain verification, beyond the on-chain verification of the batch proof every DA layer block.

This provides a trust-minimized bridge with the L1, where the bridge is no longer the source of truth for light clients. This is only possible if you’re bridging between protocols sharing the same DA layer, or operating in the same cluster, otherwise you're introducing additional trust assumptions on the rollup side.

In today's rollups, the L1 smart contract enforces the fork-choice rule (the rule deciding the canonical chain, this is with Tendermint chains ⅔ stake weight of the valset, or with Ethereum with Casper FFG + LMD GHOST) by verifying the zk-proof and checking that it builds on the previous proof and processes all relevant “forced transactions” (through the L1). Without a smart contract, it is still possible to enforce this rule by requiring proofs to be posted as calldata to the L1 and adding a statement to the zk-proof that it builds on the most recent valid proof (the ordering of these proofs on the base layer decides the canonical chain). This allows you to prove the fork-choice rule directly, instead of enforcing it client-side. On a DA layer like Celestia, this is easy to do, since you can look through the Namespace Merkle Tree(NMT) for transactions belonging to a specific rollup. If you want to read more about data commitments, like NMTs, read our article on data commitments here. 

In terms of models to gain security guarantees on finality, Josh Bowen of Astria puts it well, and I’m going to quote him here.

1. “Proof of Stake committees, which come to consensus over a given state root and create an aggregated signature. (Committee with stake behind it)

2. Succinct zero knowledge proof of a given state transition. (Validity Proof)

3. Signatures from a single actor attesting to a given state root backed by a bond which can be slashed if the state root is proven to be invalid via a challenge mechanism. (Fraud Proof)”

In regard to the current state of rollup MEV it makes sense to look at ecosystems with a lot of activity (and hence extractable MEV). For instance, Arbitrum previously chose to ignore MEV altogether by using a first-come, first-served mechanism, but this places higher hardware requirements on the nodes and reduces the cost of DDoS for searchers, who will spam the sequencer to get included in blocks. However, the larger a window is, the larger amount of MEV is likely to be extracted. This is likely leading to less centralization in regard to MEV actors, though. While if you were to lower the window, there would likely be less MEV, but high centralization in regard to who extracts it (based on geographical adjacency).

This is currently being addressed by the Arbitrum team, and its community, with much drama around whether they should implement a PoW type algorithm (calculating the lowest nonce) to be included in rollup blocks. If you’re interested in how the Arbitrum team wants to implement this, we highly recommend you read this forum post, which goes into detail. However, by adding considerable cost to the extraction, the profitability of such goes down the drain. This means that you’re essentially adding a race-to-the-bottom for searchers, who will now have to compete on PoW calculations and spend money on upkeep of additional hardware. This is arguably not a particularly solid implementation, since if there’s still profit to be made, searchers will commit to make it. As we’ve argued previously, we would much rather see MEV go into the security budget of a decentralized network (which would also mean going to the token holders), or through public goods funding (but then we add an entirely different discussion into what accounts for public good).

One important part of what rollups enable is the possibility of separation of transaction ordering and execution, which will go a long way in alleviating some of the MEV issues that currently exist in monolithic blockchains and their SBV mechanisms (currently off-chain via MEV-Boost). Although, what happens currently is just redirecting MEV profits from validators to rollup sequencers. Which, if you think in terms of the security budget of the underlying layer, is strange, since the validators now only earn a DA fee. I would almost propose that in a modular world, some of this MEV is directed down to the validators, and their security budget, which is where the rollup derives much of its security from. This could come in the form of a % base fee of the extracted MEV, that goes to the DA/Consensus layer – call it public goods.

However, one important thing to take into account when talking about a competitive and decentralized rollup MEV market is as Vitalik put it back in 2020: “a competitive MEV environment has other negative externalities, e.g. it bloats the chain with a high rate of failed transactions” which in turn leads to less decentralization due to higher resource requirements. All the while, the execution layer (rollup) derives security from the base layer, but doesn't provide it with a lot of the value extracted apart from a base (or priority) da fee. This is, of course, dependent on what sequencing is used, its ordering and the separation of builder/proposer. 

In the ever-evolving landscape of decentralized networks, the lines between economics and ideology blur, and the true cost of progress is obscured by the promise of profit. Yet, as those networks grow and thrive, those who bear the burden of payment must navigate the perilous waters of inflation and incentive. MEV is the lifeblood that flows through these networks, driving the participants forward in their pursuit of economic gain, even as the ideals of decentralization hang in the balance.

As we laid out in the previous article, someone at the end of the day needs to bear the economic burden of paying those that provide resources to a decentralized network. This is especially true in the beginning years of a network, as it aims to grow and mature. For mature and active chains, like Ethereum, this inflation is able to be lowered considerably. Here MEV plays a huge part in incentivizing the network participants, which makes it worth it, economically, to run certain activities. Obviously there’s also the ideological idea of decentralized networks, but at the end of the day, most of the actors and participants are participating because it makes sense from an economic point of view.

And while we’ve generally, at least in our past article, made the case for MEV rewards to be used in the incentivization of protocol security (via redistribution to the validators securing the network) – there are also other views on possible solutions. These include both using privacy preserving solutions to minimize MEV as much as possible, such as running parts of the MEV supply chain on SGX (TEE) hardware to store encrypted blocks and validate them permissionlessly without giving away vital information. However, the difficulty of obtaining TEE units (although this is getting a lot easier is an entire different story, which might also lead to centralization towards those with access to hardware. Furthermore, there’s been considerable discussion around the actual safety of TEE (a lot of drama here in the past year). Do you want to trust hardware, or do you want to trust cryptography? Cryptography is likely to have more performance overhead, while (if implemented correctly) higher security.

Other ideas include things such as time lock encryption, threshold encryption and so on. Although what’s important to note, is that even with current implementations of these solutions, MEV still slips through the cracks – whether that’s benign MEV (which is vital for the running of the on-chain financial systems), or non-benign MEV that’s harming the end-users. You essentially either allow arbitrageurs to give users fair prices at the expense of liquidity providers, or you compensate LPs via inflation, hurting the token holders (the current Osmosis strategy). Now, if that is happening on an application-specific chain, where you are also paying for security via your native token – you’re essentially double inflating your token holders. 

However, on the flip side, to get people to use the product (which will eventually provide the security budget from MEV and fees), you need to first mature the rollup or application to the point where it can support itself without much inflation (such as with Ethereum). That means you’re essentially forced to incentivize usage and liquidity providers, via issuance, as a starting point. You need the inflationary token to push the security budget pre-matureness of utilization of said application(s). A way to limit some of this pain is to utilize a EIP1559 (fixed-per-block fee that is burned) style token burning mechanism, which will limit the amount of pain taken by issuance of tokens, as the network  grows in usage.

With our thoughts surrounding incentivization out of the way, let’s look at it from another perspective – the reverse way to think of incentivization, is to think in terms of disincentivisation. 

There have been some thoughts and implementation research into how to eventually move to leaderless MEV capture that gets redistributed to the end-users. Duality especially has been digging into this, with their announcement of Multiplicity. It is essentially based on the belief that blockchains with leadership mechanics are unfair for end-users, since it allows for much cheaper censorship. So to improve this, they came up with the idea of multiple concurrent block proposers (named MCBP). They essentially want several sequencers/nodes that contribute transactions for each block. What multiplicity provides is essentially a gadget for non-leader nodes (or sequencers) to include additional transactions into a block. The way this works is sorta similar to some ideas of first-come-first-serve, that we covered in part 1 of this series. Which is leaderless. It is based on the idea that for a leader to construct a valid block, it must include at least ⅔ (by stake weight) of the nodes’ transaction bundles. 

That means you won’t be able to construct a valid block that omits transactions that are included in a bundle of  >⅓ stake weight. This means a quorum has to be reached between sequencers/nodes with regard to the bundles of transactions coming from various sequencers. The way this works is that each sequencer in the network constructs their own bundle (ala first-come-first-serve) of transactions, which they sign and send to the leader. Afterwards, you go to the concept we just presented, which is that the ⅔ stake weight of signed transactions must be included in a block. What this means is that to censor, you must bribe many more validators, which increases the security budget of the rollup.

Another way to think of incentives is to look at the way most stake works in Proof-of-Stake Ethereum. Most stake in PoS Ethereum is being delegated to staking pools, who further delegate it to trusted (Lido) or bonded (Rocket Pool, Swell) node operators (infrastructure companies). But these pools could suffer from a risk called MEV hiding, where node operators are incentivized to hide the real value they make from a block and keep a larger fee for themselves (in the case of private order flow). An open market for block building solves this problem because builders need to maximize their public bids in order to be competitive (such as MEV-boost). As long as validators sell their blockspace to the highest bidder, there is very high confidence they are not engaging in MEV hiding on the side. This is also an issue that could become prevalent in rollups (specifically centralized ones), even when the sequencer sets are decentralized. It is therefore vital that there exists an open and transparent market for the MEV supply chain.

Within the MEV supply chain, whether viewing it through a monolithic or modular lens, the input always comes from the transaction originator. The vast majority of order flow originates from retail users, for whom the predominant point of interaction with the chain is their wallet. These wallets are then the de facto aggregators of retail-originated order flow. An important extension of the ‘wallet’ as the typical example of the transaction originator comes by realizing that dApps are also significant order flow originators. While these originators so far haven’t been afraid to squeeze their users to juice up their margins (example being the near 1% ‘service fee’ charged on Metamask’s in-app swap functionality), there’s a much larger opportunity for them to cement themselves into the MEV supply chain.

Consider the parallel of MEV to Payment For Order Flow (PFOF) that we know from traditional finance. A zero-commission broker like Robinhood aggregates their users’ transactions and sells access to this order flow to market makers, who can then ‘earn the spread’ between these customer orders and the NBBO (a regulation that brokers must execute trades at the best nationally available ask/bid price). Market makers are happy to pay for this order flow because the general estimation of a Robinhood order is that these orders are generally non-toxic, i.e. the retail trader likely doesn’t have any information asymmetry over the market maker and thus there likely is room to make profit.  While of course this TradFi analogy only partially applies to the types of MEV seen in blockchains, the link in the chain that clearly can be analogous to ‘our’ MEV is the PFOF opportunity. 

Any entity in the supply chain that can capture significant order flow has the control to sell access to that currently are easily the de facto actors that are able to capture this order flow. A way to monetize wallets and/or return user-originated-MEV-value to users would be for these wallets to sell some preferred private relay access (think: all Metamask swaps being routed to a single market maker and/or block builder that is able to execute transactions with some additional no-frontrunning/sandwiching guarantees). Naturally, this type of (off-chain agreed upon) exclusive order flow access can have a centralizing effect: the preferred recipient of the order flow will generally be able to build more profitable blocks, allowing them to return more value to the originator of the flow and leading to a positive reinforcing feedback loop that’ll serve as an incentive to increase their exclusive flow access.

With the majority of order flow originating from wallets, we could see the wallets becoming a sort of kingmaker by controlling where a very significant portion of order flow goes and how it is executed. Co-incidentally, wallets are incentivized to an extent to route their order flow to the most dominant block builder in order to maximize the UX of their wallet (fast inclusion and predictably low tx fees). The centralizing effect of exclusive order flow access will get even stronger with the integration of PBS as builders will be more dependent on exclusive PFOF to compete in the block building race, and with the increase in modularity and complexity of decentralized sequencers doubly so.

Validators running multiple decentralized sequencers will be forced to buy the ‘best’ order flow for all chains/sequencers in order to be the builder of the most profitable blocks. To prevent this centralizing effect on block builders, the alternative could be to auction off individual or batches of transactions to bidders in a more level playing field, a concept which has been dubbed an order flow auction (OFA) but which functionally is the crypto-equivalent of PFOF. The TL;DR of OFAs is that transaction originators can solicit bids from (some set of) bidders for their transactions by disclosing (some amount of) information on it, with the winning bid being chosen based on some criteria.

While certain specific OFA implementations have been devised for trade execution (see DFlow, CowSwap, Hashflow, etc.), more generalized OFA implementations also warrant attention. Particularly, MEV-Share is an interesting protocol that could fill this need, by providing open access to searchers to users’ order flow through an OFA while returning MEV-able value back to the originator. The downside of the MEV-share implementation for now is the fact that the ‘matchmaker’ role, which is responsible for matching private user transactions with appropriate searcher bundles, initially is likely to be a ‘permissioned’ role run by Flashbots. This is needed to prevent competing matchmakers from engaging in bidding wars (thus again depleting value returned to transaction originators) and to ensure that bundles are only sent to trusted builders that will honour the ‘validity condition’ that accompanies each bundle and which posits that extracted MEV is returned to the user.

As mentioned previously, in a more modular future wherein an increasing amount of value will be derived from the cross-chain blockspace market, the pressure on block builders and validators to purchase exclusive order flow on ‘all’ chains increases to ensure maximum profitability (in order to capitalize on cross-chain MEV opportunities). At the same time, an abundance of blockspace may shift pricing power for this blockspace away from the blockspace producers to the transaction originators. Regardless, these approaches will decrease the amount of value that accrues to validators (and thus ‘decrease’ the security budget) as the proceeds of these (off-chain) auctions are returned to the transaction originator (or the order flow seller). This once more highlights the friction field that emerges around the value that can be captured on any set of chains; the value from this zero-sum game can increase the chain’s security budget, flow back to transaction originators, but not both. We’ll be covering this more in-depth, in the cross-domain MEV section as well.

So, where may this all end up going? Firstly, a key risk that ought to be mitigated is the MEV dystopia, i.e. the threat of vertical integration of key parts of the MEV supply chain spurred on by exclusive order flow (see this presentation for more). Metamask has already set Infura to be the default RPC provider, which is arguably fine for now, but a sliding scale where Infura would suddenly privatize their order flow or start building blocks isn’t out of the question. It is important that these types of parties remain aware of their dominant role and that observant third parties expose and denounce misuse of this position. Secondly, with dApps being significant originators of order flow and thus MEV, we’ll likely see more apps working toward designs that help internalize MEV, whether through app-chain designs, protocol-level choices, or their own exclusive deals. An interesting example of a protocol-level choice is Penumbra’s FBA (frequent batch swap), which basically arbitrages their pools internally by executing all swaps within a block in a single batch against a constant function market maker (CFMM) curve (think: Uniswap curve), thus using flow encryption to internalize their MEV. An example of a dApp creating their own exclusive deal has been Sushiwap integrating Manifold Finance for private RPC access with some additional guarantees in place for users. Finally, a ton of innovation is likely to happen within the OFA design space, with a particularly exciting domain being the effects and implications of the increasingly cross-chain and modular world on OFAs.    

Another “actor” that is going to play a large part in the modular world, is that of relayers. Relayers are responsible for the transfers of data between different blockchain systems. They especially become relevant for sovereign rollups, and rollups that don’t share the same base layer (such as a liquidity settlement layer). Although, in the case of rollups that share the same DA layer, you could facilitate cross-chain swaps as long as the rollups respect the other's fork-choice rule, while running a light node on each other (to get state transition information). In this setup, you’re also still reliant on relayers to facilitate the passing of messages, which in most cases will probably be facilitated through a standardized transport layer (such as IBC or Polymer). As such, it is certainly relevant that we describe how relayers function, and how they are being incentivized. There’s also MEV to be extracted here, which we’ll go more in depth with in the cross-domain MEV part. Most of the use-cases of relayers currently (beyond facilitating token bridging and data communication) is for liquidity balancing across chains for both searchers and market makers a like. At least in terms of relayers in the IBC ecosystem. There’s also relayers in place for a lot of other cross-chain messaging protocols in other ecosystems, and relayers are also used often for off-chain order books, for example. 

IBC relayers (such as Hermez) function within IBC to facilitate transfers of assets and data between different blockchain networks that have an open connection/channel with each other. They can profit by exploiting price differences between blockchains and by taking advantage of arbitrage opportunities between different DeFi protocols. Relayers can also extract profit by exploiting front-running opportunities. When sending packets through IBC channels, there are two main types of channels: ordered and unordered. Ordered channels ensure packets are delivered in the order they were sent, while unordered channels deliver packets in any order. Packet sequences enforce channel ordering. If a packet with an earlier sequence needs to be received before the current one, it is rejected until the correct packet is submitted. The IBC module guarantees that a packet will not be received on the destination chain if the timeout has passed.

If you’re interested in digging deeper into IBC and relayers, then I recommend this article by Adi

So what can an entity that runs DeFi strategies and a relayer do? They can buy an asset on a protocol where it's underpriced and sell it on the protocol where it's overpriced, thus capturing the difference as profit. IBC relayers can also extract MEV by exploiting front-running opportunities, in the case that they have information about cross-domain swap taking place (for example in a cross-chain application such as Mars/Squid/Catalyst).

Something that might also be possible is the idea of Denial-of-Service (DoS) attacks on relayer packets, which could cause them to timeout (as described earlier). This could be used to front run a particularly juicy MEV opportunity cross-chain, since if we consider the ordering methods – you would be able to send your packet after a timeout.

The unordered channels currently would allow for easier incentivization of relayers, since you could have a separate bidding market for inclusion of packets to relayers, as it would no longer be a first-come-first-serve setup. This could, as it’s now more economically viable, lead to a larger and more decentralized relayer set (instead of them being essentially multi-sigs at this point). This would also allow for MEV to be extracted, and possibly be redistributed either to relayers or to the protocols of which they connect. However, a downside of this, is that it could heighten the congestion, and cost of participating in cross-chain transactions.

If you’re interested in looking at current relayer (w/ IBC) incentivization, you should take a look at the ICS-29 specification. The folks over at Polymer are also working on a few new specifications for relayer incentivization.

Another possible extraction opportunity for relayers is to synchronize blockspace between chains (and taking on inventory risk). Essentially acting as an off-chain social contract-enabled liquidity layer. 

As we mentioned in part one of the saga, either the protocol itself has a built-in searcher-builder-validator/proposer (SBP) mechanic (preferably w/ PBS), or a third-party solution will pop up to provide that service. These third-party services also have the ability to potentially allow for off-chain social contracts between sequencers(rollups) that could allow for certain atomic and cross-rollup transactions. Thus, it is important to mention some of the projects that provide said marketplaces, and how they will fit into the modular stack as a whole. There are also some interesting integrations that could happen, through the DA layer for example as well. We’ll discuss this and more in this section as we explore the MEV marketplaces that will most likely play an essential role in how MEV is distributed in the future, as well as now. 

One thing that’s exciting about MEV marketplaces, beyond setting up a proper MEV supply chain either in-protocol or off-chain, is the ability they have to facilitate social contracts between actors. Let’s think of an example of how MEV marketplaces could be used to facilitate various activities across domains in the modular stack.

You could negotiate social contracts (mayhap eventually on-chain enforceable ones) via MEV marketplaces to put in place multi-loop party auctions. Essentially, two sequencer sets (proposers) negotiate a market between them to enable cross-chain atomic swaps. 

Here the visibility of what the swap entails is of utmost importance, to avoid mishaps. 

You could also use these MEV marketplace to essentially get cross-chain synchrony guarantees between rollups that share a common security layer (such as a settlement or DA layer). Wherein the marketplace actors would batch transactions into the same block of the underlying layer to facilitate atomic transactions. This requires the block windows of said rollup sequencers to line up, unless you put in a time-lock to batch them at the same time (but this could possibly interfere with timeout settings).

You also have folks, such as Mekatek who are working on implementing a builder module for Cosmos SDK chains which would enable specific chains to express their own preferences regarding MEV, how it should be extracted and distributed. If you’re interested in how this works, I highly recommend you reach out to their team. As well as Skip, who have just recently implemented their Proto-Rev module for Osmosis.

Teams working on MEV solutions in the modular stack are primarily Mekatek, Bloxroute, Skip and Flashbots - in the democratization and marketplace vertical. However, there are also a myriad of other MEV projects working on parts of the stack, such as Blink, Manifold, and many others across various different ecosystems.

Even though MEV in theory doesn’t change when you split up layers (execution is still in theory the same), it allows for optimization in the different layers to minimize the amount of MEV through things like different block building techniques, threshold encryption and so forth – depending on your application or general rollup. This is primarily because of the fact that in every single blockchain a leader is usually selected to propose a block, this means that the extractable value, or priority fees end up with that specific leader. One way to alleviate some of this is via the setup described in the incentivization part. Although, in theory, this is only masking the centralization. The thing about execution layers that are decoupled (which is all rollups, unless you use some “based”-esque sequencing and mempool model), is that they all siphon the MEV to them exclusively, while the leakage of MEV (beyond priority fees) is self-contained to the execution layer and very little slips downwards. The base consensus/da layer can’t actively do anything to stop the MEV from being extracted at the execution layer, unless we’re talking about data withholding, but with how the consensus is set up this would result in slashing. 

For a Sovereign rollup, that self settles on the rollup side via validity or fraud proofs client side (while handling consensus, state transitions and fork-choice rules themselves) you would likely see exactly the same leadership setup that you would see in smart contract rollup. As with their counterparts, some of this MEV drips down to the DA layer via fees, but MEV is still self-contained to the searcher-builder-sequencer (validator) supply chain on the rollup itself. This is especially prudent with deterministic consensus algorithms, that are much faster to reach finality on the rollup side. The only way you’d in theory get MEV to drip down to the DA layer beyond da fees, is if you go with a first-come-first-serve type setup – where you rely on the DA/Consensus layer to decide what the canonical rollup chain is, since its validators would decide the ordering. Although, if this is decided by priority fees (such as with Celestia), you essentially just get a MEV-boost type setup where fees are king, unless you’re able to bypass this in terms of geographical latency and private order flow. 

Now, in the case where an execution rollup utilizes a settlement layer (such as Astria, dYmension, Eclipse) where you rely on the settlement layer to post txs data to the DA layer (and settle state transitions and dispute resolution). 

The setup depends entirely on the sequencing/block production rules and to whom you outsource this to (if at all). If you have a leadership election setup on the execution rollup, the MEV gets extracted there. If you have a first-come-first-serve, you’re dependent on the ordering of the transactions on the underlying layer. 

First-come-first-serve (FCFS) decentralized sequencer network

However, you could also utilize the settlement layer for leader election (ala the Based setup, where you outsource sequencing to the “L1”), or depend on it for ordering if you utilize first-come-first-serve, while the settlement layer uses a leadership election setup. At the end of the day, it very much depends on the actual implementations of the rollup in question. Some of these predictions change if you utilize a shared sequencing setup, where the MEV of the execution layers are redistributed to the entire sequencing network. If that is the case, you might see the more popular execution layers push for a weighted redistribution, depending on how much “value” they provide in fees and MEV. Since if you don’t, they might view sharing their MEV as a negative, once they’ve reached maturity beyond the bootstrapping phase.

The total MEV of these shared layers are in general (beyond fees) the total amount of inefficiencies in the system caused by non-coordination between actors in the supply chain (liquidations, arbitrage, front-running, sandwiching). This, as we’ve seen on Ethereum rollups already, is a lot. In a modular world, our thesis is that the total MEV will grow even further due to more opportunities presented by a breaking down siloed monolithic environments into a diverse set of modular ones. We imagine a world where either MEV is likely going to be extracted entirely on the execution side (apart from fees), but also see great value in shared-layers coordinating to bring value to all the layers in a modular system (such as SUAVE-like implementations, or a restaking-esque solution, like the one presented by Espresso). These are primarily implementation details, but you could certainly imagine a world where you would pay “homage” to the layers you derive security from, beyond the baseline fees you pay for their services – depending on the matureness of your execution environment. 

The main reason for why this separation of MEV to the execution layers is good, is that the cost of MEV extraction is siloed to execution environments, which also means that supply chain disruption is able to be contained much easier. This also means that the cost of MEV won’t affect the base layers with regard to congestion, and allows for much more specialized layers that are optimized for specific purposes (same reason for why we want PBS). Although, if the MEV “problem” becomes so great on a specific execution rollup, it might lead to even more layers getting added to solve the congestion and disruption issues that it brings. It’s really an equilibrium that is extremely hard to find. Especially since if you just split up layers continuously, the vast majority of financial activity is still going to happen on the execution layer’s side (since it’s the leader and decides on ordering+finality), which is where the MEV lies (whether that's benign or not). This is why we’re most likely going to see PBS and SBV/MEV supply chains either being built into the protocols themselves from the get-go, or move off-chain (such as with MEV-boost). This is to solve the PGA auction issues that come with a non-seperation.

Less so modular, but rather app-specific, is the fact that various MEV minimization techniques work better when they’re contained and tailored to a specific application – such as with Shutter network (shielded mempool), or threshold encryption with Osmosis. This runs back to our application-specific thesis, in which our argument is that app-chains allow for better optimizations, both in resource pricing and tech choices, but also MEV minimization techniques – although at the cost of composability. However, things like Polymer (and IBC), alongside ICQs and IAs are set to change this.

Although we argue that the security budget is important for decentralized networks, it all ties back to where do you want the pain to land. If you value security budget, and you're willing to sacrifice end-user execution for MEV to be extractable to increase security, you would aim to find an equilibrium. If you, on the other hand, value MEV minimization more and are willing to have the pain of issuance land on token holders, a MEV minimization technique makes more sense.

What a shared security layer provides, is also the ability to lower the amount of issuance, since you're able to inherit security partly. This is also why we believe most modular chains will eventually revert to a few select, and highly optimized and secure DA/Consensus layers. It is at least a good starting point, for any new chains. And you could argue that the cost of leaving this shared layer is higher than what you stand to gain. This is in the same vein as why a shared sequencer network might make sense for execution rollups.

For an application-specific rollup with a controllable segregated execution environment, there are also some unique methods for providing better transaction execution. We have of course already covered some of these, such as threshold encryption, time lock puzzles, but another way is to change sequencing rules. What you could do is to require that the sequencer(s) (the builder and proposer) are constrained to a sequencing rule (a uniqueness to rollups, building on top of existing layers) that requires them to only execute swaps in the same direction if the price is better than what was available at the top of the block, or if there are no swaps in the opposite direction following their trade. This means that if someone wants to make a trade in a certain direction, they must ensure that the price is better than the price at the top of the block or that their trade won't be used to move the price for someone else. By following this rule, users can be assured that they are receiving a fair price and that their trades are not being used to benefit others. 

Source: Quintus on Flashbots Forums

While this sequencing rule ensures that users receive a fair price, it's important to note that there are still less favourable orderings that users can pay for. Additionally, being in the long tail of same-direction swaps at the end isn't desirable either. However, this rule still leaves room for multi-block twap MEV strategies that are more sophisticated. When it comes to more complicated orders like arbitrages touching multiple pools, the sequencing rule may not be sufficient to guarantee a fair price. If you’re interested in reading more about this particular setup, there’s a great post on the Flashbots’ forum that goes more in-depth.

The best way to describe cross-domain/chain MEV is that if transactions on one chain start effects on another chain, which is then capturable on that other chain. This MEV is then capturable on chain B, even though the activity or transaction originated from chain A.

For transactions on separate chains, there’s obviously MEV associated with them on the individual chains they inhabit. Now, couple that with a bridge swap taking place on a cross-chain AMM/DEX, and the MEV problem suddenly becomes a cross-domain issue. If someone, for example, sees a swap/transactions happening on Chain A, which indicates that they will likely handle a transaction to a certain pool on Chain B. A searcher, with liquidity on Chain B now has as much time as the latency is for the bridging to take place to essentially front run or similar. 

This extraction technique requires the searcher to have liquidity on several chains, which could lower possible attacks, since their liquidity is fragmented as well

There are various ways to hide some of this public data, which we’ll get into in a bit. However, essentially, you’re still being “MEV’ed” in the same ways as you were previously – depending on the setup of the particular chains in question. This is especially true in synchronous setups, while asynchronous setups (such as Catalyst for example), might yield better protection against hostile actors (that could inhabit a TTP state chain). State synchronous setups in general also provide pretty bad pricing for pools, however state proofs (of which several companies are working on) are definitely set to help alleviate some of this (but at the cost of some overhead or even centralization). As soon as you’re handling transactions on numerous different chains at the same time, MEV opportunities arise in a cross-domain fashion. Pricing here is especially important, and projects like Lagrange, Axiom and Herodotus are probably going to be able to provide much clearer (and trust-minimized) pricing for cross-domain on-chain activities. However, what should still be taken into account is the manipulation of price feeds, for more information on how protection could possible look here, I highly recommend looking at Consolidated Price Feeds.

Another key factor of cross-chain applications that also affects cross-domain MEV is the fact that on applications that have “multichain” pools, as in – I can deposit funds on chain X, while borrowing on chain Y. You essentially introduce differences in pool sizes across the various pools and chains. This makes life quite a bit harder, especially if liquidity of a certain asset is much lower on a specific chain, but still supposed to hold the same price points across the different chains. You need extremely strong consolidated price feeds models, or state proofs showing prices from the chain with the strongest liquidity – to avoid problems that come with price exploitation on lower liquidity chains. This also means you, in most cases, on cross-chain lending protocols will have to decrease the Loan-to-Value (LTV) of the cross-chain pools, unless you’re absolutely certain that you’re getting trust-minimized and proper price feeds from the strongest liquidity chain. This does introduce some extra risk parameters, especially on more complex protocols. In situations where you have an asynchronous cross-chain AMM with the same amount of liquidity in each pool, this becomes less of an issue as long as your liquidity pools are deep enough (and provide proper slippage information). However, you’re still going to be running into cross-domain MEV extraction opportunities on different chains. This, as said, can be lowered by hiding vital information (such as with time lock puzzles, encryption and so on) – however, there’s always going to be some information leaking which could affect your protocol. 

What this does mean is that (at least in the cross-chain AMM example) is that you get fragmented liquidity instances (although connected), which is a lot less capital efficient. Especially as the amount of chains support grows, since you’re now required to spread out X amount of liquidity to Y amount of chains. Essentially, arbitrage between the pools is what’s going to synchronize them, but the capital efficiency still remains quite low. The issue is easier to handle, if you do just stablecoin pools (such as with Stargate), but if you hardcode assets to $1 and a certain stable loses its peg, then you’re in for a world of trouble (and a lot of MEV). Replicated instances of liquidity becomes much easier to maintain and handle if your entire ecosystem of chains connected are standardized, such as with IBC and its interchain standard (ICS-20). Which can mean moving funds much easier, and not relying on “wrapped” assets that are incompatible with non-wrapped assets. This can be made more efficient by having off-chain agreements for atomic transactions (but adds extra trust assumptions), or via a shared DA layer. 

Now, as we’ve mentioned earlier in the section, the ability to avoid or minimize some of this cross-domain MEV extraction is interesting. However, most current solution to this, are going to add latency to the system – is this a trade-off the end-user is willing to make? Unless you’re extremely aware of the negative externalities that MEV can bring, then most users are probably not going to care. However, in the edge cases of power users that are moving large amounts of funds, this definitely becomes more fascinating. You could utilize ZK-Timelock puzzles, and encryption.

This allows you to send the finalized transaction commitments to pools, and any watcher would be able to challenge operators (the trusted third party) that did not execute the committed to finalized order of transactions, wherein they would lose their bond. The operators could also be run on an SGX machine, for example. However, this would add significant overhead, and possible latency.

Another area of research that is quite interesting, and something that we looked at slightly in the transaction originators section, is that of order flow auction systems. However, let’s try to look at this from the lens of a cross-domain position. 

Something that’s potentially appealing to explore is the idea of integrating MEV marketplaces, to facilitate private order flow auctions via specific transport layers. This would allow certain actors to take on inventory risks (via a fee), and provide certain privacy guarantees and fast, to atomic transactions (which are much easier to do with 1-1 assets, than swaps that depend on variable pricing). You could essentially have the transport layers integrate with block builders on connected chains, and as such optimize MEV (and it’s redistribution). 

This should, we hope, be done in a way that’s permissionless, and have similarities to the same ideals that Flashbots and others hold themselves to when it comes to building off-chain MEV marketplaces. The idea of an order flow system is to provide much faster execution (and eventual finality) for cross-domain transactions. This should also tie into incentivization of pivotal actors (such as relayers). Currently, most relayers aren’t running them for economical profit, since they operate at a loss for the most part (and many of them funded by grants and public goods from the chain or application’s governance). 

This also opens up another cross-domain MEV avenue, which is the access to exclusive blockspace markets via direct access (through integrations) to the block builders (in a modular world, the sequencers). This allows for searchers, that want to maximize their MEV profits, to integrate into cross-domain MEV marketplaces, that still allows the MEV to primarily land in the hands of the validators of the networks (and as a result the token holders).

However, the negative externalities of this, is similar to the problem that we already see in singular staking networks. Which is the centralization of stake. For example, sequencers (essentially the rollups validators) that run sequencers on several other chains are able to commit to extremely valuable cross-domain MEV activities if they’re the leader of two simultaneous proposed blocks. What can help limit some of the externalities of this, is shared sequencing setups for rollups - such as the shared sequencer network that Astria is working on, as well as projects like Suave and Espresso. We will cover shared sequencing more in-depth in a later article. One thing that’s also relevant, and I hope we see more research in this area, is the information asymmetry that comes with introducing so many actors into the system, all of which have different latency of information leakage, depending on where they sit in the system flow. 

As we move into a modular future, where blockspace becomes more and more abundant, there’s now less “worry” about being able to be included in a block – and instead much of the MEV (such as cross-domain order flow) could actually be extracted via transaction originators (as presented earlier) alongside integrations with the block builders (and proposers) themselves. Something that’s also an apparent “issue” is that of rollup sequencer networks outbidding/spamming blockspace on the underlying DA layer, to extract valuable MEV opportunities in the stack (we’ll cover this in more nuance in the next section). This obviously becomes increasingly expensive as blockspace grows on the underlying layer (such as with DAS), and might only be possible in short stints (if at all). 

One thing we also mentioned earlier is that there’s way more opportunities for well capitalized MEV extractors in a modular world, since liquidity is a now way more fragmented (and bridging often not atomic, unless specific criteria are met on the shared DA layer, or via social contracts). This could see large (in terms of capital) actors become increasingly wealthy, and drive centralization. If you want a more technical deep-dive on various aspects of cross-domain MEV, I will also recommend the cross-domain MEV paper by members of Flashbots, the EF, Gauntlet and Socket.

Just like with Ethereum’s crLists, we hope that cross-domain sequencing and blockspace markets also take a similar approach to censorship resistance – and therefore also integrate models like crLists (force builders to include a transaction inside a block). This is also what gives the ability for block builders to provide a soft-guarantee, that a users' transaction will eventually be finalized. Where this could possibly become an issue is for block builders that are geographically located in jurisdictions that don’t want certain actors to commit transactions (such as with OFAC), which could lead them to block certain transactions (and not adhere to crLists). 

Another quintessential aspect of cross-domain MEV, is that of benign arbitrage MEV that takes advantage of differences in prices across various DEX on different chains that carry the same assets. We won't go into too much detail on this, this is a well established topic. If you’re interested in seeing cross-domain MEV happening in real-time, I highly recommend you check out the Odos’ tracker.

There are also some interesting implementation of cross-domain consensus that is in the works by the team over at Anoma. If you want to read more about their specific solution, you can check out their Paxos Consensus paper here. 

Another component of the “modular stack” is the DA/Consensus layer. It is the lego block on top of which other components are built. A DA layer is usually seen as a lazy blockchain that does not differentiate between what data is posted on it. A rollup posting data is competing with a user that wants to inscript their NFT needs to be stored on-chain (Ordinals). This is a very pure marketplace, where you can pay in bytes made available and the preference is shown by willingness to pay a certain price. Those that pay most are to be included, as both miners and validators have to optimize for maximizing revenue due to the economics of their business. While this seems trivial and most readers will know this, it is important to know that pricing will determine whether your DA is included in a block. Especially if the fact that being included or not impacts the leadership rule of various parts of the stack. This is what gives the DA layer pricing power, or the other way around, others will be willing to pay up to make sure they are included and decide the ordering. The amount they are willing to pay depends on the MEV possible to be extracted (and the tx fees) and consequently this will mean extractable MEV will trickle down to the DA layer. 

There are a few setups in which the DA layer has pricing power to extract more value from rollups. First, you have could have (sovereign) rollups that rely on the DA layer for their sequencing. Here it becomes critical to get the rollup data on the DA layer prior to others as it directly impacts who dictate the state (e.g. the ordering of transactions) on the rollup. In such a scenario, we would envision most MEV to trickle down to the DA layer. The second scenario is one in which there is a rollup with a settlement layer, here the MEV will mostly be captured on the DA layer in the case that the settlement layer relies on posting to the DA layer for leadership election. The third scenario is still a somewhat more theoretical one, this relates to potential decentralized sequencer setups. You could envision a decentralized sequencer setup that results in proposers on the decentralized sequencer level competing to be able to post to the DA layer (or pricing out competition to do so). The point to which this matters will be a function of various parameters in the leadership election used, e.g. if the timeout parameter, as described in our application-specific chain thesis, is relatively short it is key for proposers on the decentralized sequencer level to post data as quickly as possible. In such a world, you could get competition of “validators” of the decentralized sequencer set competing to act as a leader and outbidding each other for blockspace on the DA layer up to a point at which it is no longer economically desirable to do so. 

A way for the rollups on top of a DA layer to maintain censorship resistance is requiring sequencers to stake a certain amount on an L2 and vouch for an L1 address with sequencing rights. Only transactions from addresses with sequencing rights will be processed, and invalid transactions will result in the sequencer's stake being slashed.

Another way to view this is that in “based” sequencing (using the DA layer directly for sequencing) the DA layer has pricing power to extract MEV. 

An important note here is, whether it's a good or a bad thing to have MEV be extractable by the DA layer. As in our first piece, you basically have two points of view here, one is the security budget. If MEV is extractable at the DA layer, consequently the value of the DA layer blockspace becomes more valuable. This makes the token, which gives you the right to sell future blockspace, more valuable. Consequently, the value at stake, is larger and the security budget of a chain becomes larger. The counterargument is that if MEV is extractable at the DA layer, the pricing variation caused by MEV on one rollup will impact all others interacting with the DA layer. This would be worse for protocols using the DA layer as pricing is less consistent and reliable. It is likely that this will end up in a situation without an optimum, and we are mostly curious to see how it plays out with the various shapes and forms of modular designs coming out in the next few years.

As we presented earlier, if the leadership election and MEV extraction happens on the execution layer itself, most (if not all, apart from DA fees) of the MEV will be extracted on the rollup.

This section will serve as an appetizer into some interesting thoughts and research that deserves more attention, and possible implementations. It's less coherent, and more just a gathering of things we find intriguing, with regard to MEV in the modular stack.

1. Decentralized L2 sequencing w/ CosmosSDK/IBC

2. MEV marketplace integrations into modular stack through DA block submission and sequencer APIs for 3rd party market swaps - PFOF

3. Mempool encryption by Jon Charbonneau and MEV findings on Osmosis (using threshold encryption) by Mekatek

4. Restaking for validators to engage in block sequencing on L2s. Is it worth it from a slashing properties' perspective? Enough yield for validators to run more runtimes? This is the same reason for why the Cosmos Hub’s current implementation of ICS might not be worth it from an overhead perspective. Especially if the supported chain has low activity.

5. Effects of latency on MEV, we've already covered this slightly in regard to the first-come-first-serve mechanism (and it's effect on Arbitrum). As well, as current and past geographical centralization of the MEV supply chain. But would be interested in seeing how this looks in a more “modular” stack.

As has probably become clear over the series, is that you're making trade-offs at every level, and it's really up to the developers of rollups to decide how they decide on what trade-offs to make. We hope that this article has helped somewhat with identifying which trade-offs are important to keep in mind, in regard to MEV, security budgets and decentralization.

If you’re building in the modular space, and interested in discussing parts of the article in more detail, feel free to reach out to us on Twitter – we’re here to help you make the design decisions that will be best for your end-users.

Thanks to Pim Swart and Mathijs van Esch for contributing to parts of the article, as well as to the many reviewers, such as Mekatek, Josh Bowen etc. Also, a big shout-out to the many folks that I got to discuss MEV with over the course of the last few months, particularly in Denver.

Writer: 0xrainandcoffee

Next up in the modular saga, we’re exploring shared sequencing, and all the derivatives of this that come with shared-layers. We’ll also look at some of the effects this can have on MEV, especially in a shared sequencing world, as well as on SUAVE-like setups.

Introduction to MEV

Maximum Extractable Value, or MEV, has been all the rage in crypto. MEV refers to the extraction of value from users by reordering, inserting, and censoring transactions within blocks, as well as the profits from benign MEV such as arbitrage, liquidations etc. It was first mentioned back in 2014 on the Ethereum subreddit, by /u/pmcgoohan. 

One of the earliest examples of quantifiable MEV was during the CryptoKitties craze. Specifically, the concept of completing pregnancies of CryptoKitties (giving birth to a new cat), wherein anyone could finalize the pregnancy via calling giveBirth() to the smart contract after the cat’s birthing block. By doing so, you could receive a reward in Eth. This was possible to front-run, resulting in profit (MEV). As Markus Koch pointed out back in 2018 (great read btw) – Early in the history of the game, accounts associated with a few people were the only ones giving birth to kitties. As time went by, other accounts began calling the giveBirth() method, seeing the profit freely available. It was also possible to see that only a few midwives (cat birth callers) accounted for most of the births.

Revenue of top giveBirth callers (midwives) via Markus Koch

It was also possible to see that the midwives were competing via gas fees (since despite being relatively even in code efficiency, some were ostensibly more successful and profitable than others in achieving the giveBirth call). The conclusion made, back then, was that the birthing fee made CryptoKitties more expensive to be played than if the mechanism wasn’t necessary. This is an example of where MEV equals poor transaction execution for the end-user, as it spiked gas fees during the births.

Another example is that of front-running on Bancor, back in mid-late 2017. The possibility of this was pointed out in June 2017 by Phil Daian (Flashbot co-founder) and Emin (Avax founder). They showed that miners would be able to front-run any transactions on Bancor, since miners were free to re-order transactions within a block they mined. Ivan Bogatyy took this one step further in August of the same year, and built a program that could monitor and execute front-running opportunities on Bancor as a non-miner (just a searcher!) — since blockchains, and their mempools are public. It’s a great read if you want to get a view into the world of MEV in the earlier days (Link).

Since then MEV has evolved rapidly and with increased on-chain economic activity from 2019 and onwards with the advent of DeFi, it has become a critical component of protocol design. With the rise of L2’s, bridges, app-chains and so forth it is interesting to look into the potential implications the “modular” design space might have on MEV.  But first, we must give an overview of the actors within MEV as it stands.

There are various actors within the MEV ecosystem. Searchers are usually the most profitable MEV participants (from a first principle perspective, although more “general” value ends up with builders and validators as they congregate value from many searchers), but there are other participants as well. Let's explain who they're first. What's also important to note is that part of the participants collude more than others do, as a result of protocol design. The participants (bar users and wallets) are searchers (S), builders (B) and validators (V). In the MEV supply chain, they have the following role to play:

Source: Stephane’s great piece on MEV supply chain

Searcher: try to find all extractable value on-chain through different methods. Searchers work with builders, as searchers are willing to pay high gas fees in order to have their transactions included. This is important because many of the things we take for granted, like arbitrage and liquidations, are performed by searchers. Searchers bundle transactions together and give them to builders.

Builder: Takes the bundled transactions that are grouped together and put them into blocks for proposers. In addition to the searcher’s transaction(s), several bundles can be grouped together for a block, and can also potentially contain other users’ pending transactions from the mempool, and bundles can target specific blocks for inclusion as well. 

Validator: Validators perform consensus roles to validate the blocks. They sell blockspace to the profit-seeking searchers and builders and are in turn rewarded with part of the spoils. Keep in mind that the validators get both rewards from issuance (Proposer, attestor, sync) and execution rewards (MEV+Tips).

So why do some say that MEV is bad when it seems on the surface to provide value to the ecosystems and the security budget? MEV gets competed for via Priority Gas Auctions (PGA)s. PGAs are auctions where fees are competitively bid up to obtain priority ordering for transactions. Fee estimators used PGA-inflated gas prices as a reference, causing users to overpay for their transactions. What should be noted, is that this was primarily the way it worked prior to MEV-Geth/Boost and Flashbots. After the release of MEV-Geth, much of the computation related to MEV was taken off-chain instead, by a permissionless side-relay that allows MEV searchers to communicate directly with nodes and other participants. Leading to a decrease in fee congestion pricing. This is also easier to see when you look at the share of vanilla builders versus MEV-Boost. 

Source: Mevboost.pics

At its core, the issue stems from the fact that users and bots are in the same pool, independent of whether they go after MEV or not.

The nature of MEV (and profit in general) and its relatively permissionless nature is that there’s a huge incentive for participants to extort users of the blockchain for profit. This, as in most profit-driven ventures, leads to participants centralizing (geographically for example) to make higher profits. Extortion is also centralized at the coordinator level, especially in the current implementation mechanism of shared layers that eventually rollups/sequencers will have to off-load tasks to (such as ordering, dispute resolution, liquidity and so on). Thus, extortion can and will happen (through centralization).

There's also an increasingly high barrier to entry to participate in MEV, leading to further centralization. This is partly because of the fact of the constant upkeep of MEV bots that searchers have to do. The competition is rough, and the code is constantly updated. If you find an edge, you’re much more likely to not share it. Although, as a result of blockchains being open ledgers, they will eventually be found. The MEV “marketplaces”, like Flashbots, are also quite centralized, since the vast majority of blocks flow through Flashbots (70%!), although MEV-Boost relays are permissionless, and have several endpoints (11 according to Mevboost.pics - creator Toni Wahrstätter). 

Source: Mevboost.pics

Important to note that there are plans to decentralize the entire MEV supply chain, and we believe that the Flashbots team is well aware of the nuances of the current implementation. The centralized Flashbots relay does not directly own any validator power. Neither can Flashbots censor non-MEV-related transactions. Validators can still include transactions that did not go through the Flashbots relay. Flashbots is clearly a centralizing force, but the alternative of a non-Flashbots world certainly feels like it would be worse. As participants in MEV-Boost make a larger income on average than non-participants, it leads to further centralization in actors utilizing it as well.

Fear not, though, “we’re going to decentralize!” as the age-old answer often is. Although, if Flashbots can’t come to a consensus on the ethics of MEV (as alluded to during a recent podcast w/ Phil Daian), how will the wider community agree on it?

If Flashbots as a system eventually becomes a DAO, it could possibly become decentralized itself. This is a similar analogy to Lido and others here. To off-load claims of centralization, many protocols say it will become a decentralized DAO (eventually), just like Flashbots. You could argue that it is merely altering the centralization into more layers, such that the centralization is harder to see. However, there’s some limited merit in adding more layers. At the end of the day, in most cases, some decentralization is better than none. Although, this depends on how attackable that decentralization is.

So why is it so vital for actors to participate?

Validators want to collect the most amount in fees/MEV in order to offer the highest staking rate on their user’s Eth. This is an incentive for validators to pick the highest-value block created by builders. 

Source: Mevboost.pics

Builders will aggregate transactions from users, MEV searchers and their own private order flow to make the highest value blocks possible:

1. Builders with exclusive private order flow should mainly be able to create the most valuable block. 

2. A builder having its blocks included consistently incentivizes more private order flow to arrive at this builder since users and searchers want their transactions included swiftly. 

3. Selling future block space upfront so market makers or protocols can secure block space for their transactions or users

MEV block production and transaction inclusion dynamics in essence create an unfair market for end-users. The market structure cannot be improved (and has not) without direct intervention. The protocol as such must control the market, or have mechanics built out to support it (as we’ve seen). Cooperation between proposers (who have all the power in the market) seems much more worrying, especially in a semi-permissionless half-decentralized sequencer setup. However, if slashing takes place in the advent of any extraction of MEV, what is the reason to become a sequencer apart from transaction fees?

This is especially true if you don't emission tokens for security, as you derive security from a base layer. Thus, it leads to the belief that an SBV (Searcher-Builder-Validator/Sequencer) supply chain must be in place. That could lead to trusted social contracts between actors as well. MEV could also in reality become a “problem” aggressed more so on the application side of things (such as some protocols have done so far - Timelock Puzzles and more), leaving the protocol without direct interference. But in some cases, and we will make that case, MEV can be seen as increasing the security budget of the underlying protocol.
In competitive block markets, where there’s competition for blockspace applications will eventually revert to “MEV” (as in priority gas fees). Builders don’t waste blockspace on unprofitable reversions, and will always make the most profitable block.

By enabling searchers and hunters to easily look for good predictable state changes resulting in MEV (so a marketplace) you can incentivize good MEV adding to the security and efficiency of protocols. Coupling these profitable actions with the sequencer itself, whom as a result of bonding tokens to become one (maybe with the added possibility of delegation from other users to gain a fraction of the profits) could share in that profit. This would allow the value chain to both land in the hands of users and sequencers, while adding to the security budget of the protocol itself. So the user shares in the value they themselves create. You can only scale a blockchain's decentralization with its success and adoption (matureness).

A way to reason about the role of MEV is by looking at it through the lens of the economic security of a chain. In general, this is seen as the value at stake to “protect” that chain, the amount of assets staked or the amount of money needed to perform a 51% attack in the case of Bitcoin. MEV is a critical component of this, as it enhances the yield for validators/miners and therefore allows greater economic value to be put up for stake.

So there are basically two lines of reasoning here. Either MEV is seen as bad; this follows the reasoning that value being (unknowingly) extracted from the user is bad for UX and sophisticated users extract this from less sophisticated users. As a result of this, a myriad of solutions to prevent MEV has popped up, things like threshold cryptography to encrypt TX’s pre-ordering and batch auctions with a uniform execution price are used to prevent or minimize MEV extraction. 

Another way to look at this is that MEV is actually a force of good. The reasoning here is that MEV extraction enhances the (potential) value of the blockspace being sold by validators/miners, and therefore allows for more yield towards those. As a result of yields being higher, it stands to reason that validators/miners are willing to put up more assets in order to get access to these yields. This will result in the chain having more economic security. Another way of achieving this economic security is by artificially enhancing the yield, by issuing more native tokens/rewards. However, this comes at the cost of token holders as they face inflation on their assets. If you view MEV through this point of view, it's actually a force of good for token holders, as it allows them to benefit from economic security while facing less inflation. 

Source: Mevboost.pics

It boils down to where do you want the pain to land. By allowing MEV to be extracted, you limit the inflation required to reach a certain level of economic security, at the cost of user experience. Issuance (inflation) thus becomes a needed utility to reach certain adoption metrics, which eventually will allow you to lower it to insignificant amounts, while MEV can contribute to the security budget (and as a such the decentralization of the protocol itself. 

However, by preventing or minimizing MEV (if even possible) you increase the general user experience at the expense of token holders, as you need more inflation to maintain economic security. Another, perhaps more farfetched, reasoning behind the level of MEV extraction can be that for an entirely rational actor, extracting the maximum amount might not be the most optimal. Since this will be such a burden on users that they will stop being actively economically on-chain, decreasing the overall amount to be extracted from them over the entire lifespan of a user. 

And while we view MEV through the lens of the base layer in the above section, the same argument can be made more on an application level (although our belief is these will intertwine more with app-chains). Research from Mekatek shows that on a DEX level, you either allow for arbitrage and benefit LPs, or don’t allow for it and compensate LPs with inflation at the expense of token holders. This is a similar dynamic as we have just presented on an infrastructure protocol level.  

So is MEV good or bad? The fairest answer we can give is, it's both and neither. Some forms of MEV can be seen as bad from the point of view of one, but as rewarding from the point of view of another. Overall, we are of the belief that MEV is neither good nor bad, it just is.

The topic of how much value to be optimally extracted becomes particularly important when you look at MEV on layer 2’s.  This is because, as it currently stands, most sequencers are centralized. They are entirely in charge of ordering in a block, and consequently can determine how much to extract. However, as like any point of centralization in crypto, the goal is to move to decentralized sequencer at which point you run into the same incentivization game theory of a PoS L1. The economics behind a sequencer can be shown as;

yield = issuance (inflation) + sum of fees collected - cost of DA & dispute resolution

(Keep in mind there’s overhead to count for as well in regard to the cost of running hardware)

By preventing or limiting MEV to be extracted from an L2, you decrease the sum of fees collected and therefore make it less profitable to run a sequencer, or participate in a decentralized sequencer network. Furthermore, there are various considerations that you need to consider when decentralizing a sequencer set. 

The reason why decentralizing sequencers is needed is clear—it decentralizes and removes trust assumptions from the centralized teams building the rollups. Currently, the way rollup sequencers function is that there exists a single sequencer (run by the team) that executes, batches and finalizes all transactions. This is obviously not ideal in the situation of a sequencer failure (although exit withdrawals can help here). Furthermore, it is also putting massive trust assumptions on the team that controls both the sequencer and the multi-sig smart contracts that allow for upgradeability, and fault proofs in the case of fraud. They also have the ability to reorder transactions and extract MEV. Although, the way transactions are currently finalized is under the assumption that the sequencers will not touch, extract or extort any MEV or transactions, which is what gives us the soft finality that allows sequencers to finalize transactions as soon as they’re received. This is what is referred to as soft finality, in some cases actual finality won’t be reached until up to 10 hours later, in the case of ZK rollups. A great example of this can be found if you look at the SHARP stark verifier contract from Starkware on Ethereum—which is where the ZK proof (that is recursively proven from a myriad of transactions) is finalized. This is usually done every 3–10 hours, which is quite the dispute time from when the first transaction in the batch was handled. 

Source: SHARP stark verifier contract

Source: SHARP stark verifier contract

This is done to lower the cost of transactions and put as many transactions in a single proof as possible, otherwise, the cost of transactions would skyrocket. Such is the way transactions are finalized on rollups - they receive a soft finality guarantee, that eventually they will be finalized on the underlying layer (in this case Ethereum). In the case of Optimistic rollups transactions are instead batched up and the state root (same as ZKRs) alongside the calldata (transaction state, this is just state diff with ZKRs) is sent to the L2 contract on Ethereum. Because of dispute period requirements (the ability to roll back a fraudulent transaction) actual finality of transactions on Optimistic Rollups doesn’t happen until around 7 days later (agreed on number). This means their actual soft finality guarantee last quite some time to allow for watchers to prove any fraud that has happened. These are all issues that need to be addressed when we decentralize the sequencer set; soft finality needs to be guaranteed, and eventual finality needs to be reached while allowing for the proofs (validity or fraud) to function as intended. 

Underneath is a picture of the way rollups function currently:

(r&c)

Keep in mind that L2 finality is not finality when you depend on the L1 for consensus. This is partly the trade-off you make when you move the consensus of the chain from the rollup to the underlying “settlement” layer. Unless you handle consensus on the rollup as well (which would lose the derived security, but could gain sovereignty and utilize a DA layer for data availability guarantees). However, the obvious tradeoff here is the fact that you fragment liquidity and increase the difficulty of interoperability.  

Next off, let’s explore some possibilities for decentralizing the sequencers of rollup, and what kind of implications this can have for MEV.

First off, to decentralize the sequencer set means to remove the trust assumption that we have in a singular one that is run by a team that has incentives to not touch MEV nor reorder transactions. This gives a certain “protection” against MEV. However, if you move to decentralize the sequencer set, possibly through the bonding of tokens. You open up the possibility for a permissionless or semi-permissioned set of validators/sequencers to extract value, since they have committed tokens of the rollup (such as with the Fuel token model). This means there needs to be a mechanism to ensure block ordering correctness and slashing properties in place. The reason for this is to ensure that the sequencer set keeps liveness, stays fair and doesn’t infer on transactions. Such as with reordering and placing their own transactions first in the pool—even if they paid less in gas fess, this usually warrants a public mempool, or guarantees of inclusion. 

 Underneath are some examples of how this could look:

1. Proof-of-Stake with Leader Election. This would likely be with Tendermint’s leader election or akin (since we derive consensus from the base layer) alongside a slashing module (like the Cosmos SDK one), or something similar. This is at least the option that most rollups that I’ve talked to seems to be going down. However, there are other options as well. With PoS, if you allow the largest holder to get the most % of blocks, it will inevitably also lead to centralization. Or also revert to a MEV auction, since you bid with the opportunity cost instead of outright payments. 

2. Fair Ordering Sequencing (Arbitrum have in particular looked at this). For this to work properly, you’d also need a bond that is slashable (which could be the same for everyone, to keep the essence of fairness). In this setup, you “pay” [opportunity cost per block * blocks staked] for the right to extract MEV over that period. For fair ordering to work, you’d need a fair ordering protocol that picks a fair sequence of events to eventually publish. This will usually come through honest majority assumptions, such as in the form of first serve ordering with a merged transaction list from the various sequencers. The system is, as such, first come-first serve with a 51%-of-N honesty assumption. In the case of dishonesty, the system could commit to a social fork (if they have sovereignty).

The problem in particular with the second option is the fact that it becomes a latency race to be included first, which will most likely lead to builders and searchers moving as close as humanly possible to the sequencers in question (much like what we’ve seen in Trad Fi, and even in the crypto world as well by optimizing network latency). This obviously causes geographical centralization. 

There have also been some discussions surrounding MEV auctions (bidding for the right to extract MEV and propose a block) for sequencing slots (particularly from the Optimism camp). However, we feel that it pushes towards centralization despite its permissionless nature, and it has a very high barrier to entry. Although some of the aforementioned methods also lead to “centralization”, it’s way less obvious and harmful to the protocol. 

Generally, the fair ordering mechanisms aren’t able to “prevent” or mitigate MEV in any way that doesn’t add considerable negative trade-offs. However, things like threshold encryption, time lock puzzles, batch auctions and meta mempools (unbundling the mempool and block builder role with a shared aggregation/sequencer layer—which could become useful in the area of cross-domain MEV, which we’ll also touch upon later) might have more success in providing such properties. 

Now that we’ve seen how sequencers currently work and some methods for possibly decentralizing them—let’s try to picture how a decentralized sequencer set looks, and what it needs to keep finality guarantees and make sure the protocol functions as intended.

Fair Ordering Example of Decentralized Sequencers (r&c)

On top is a sequencer setup in a smart contract rollup, underneath we’ll showcase how this would look with a sovereign rollup (rollup on top of a DA layer) via PoS leader election. In the fair sequencing setup, there isn’t much incentive to buy and stake the required token amount to become a sequencer, and the total cryptoeconomic security of the sequencer set, stays rather low.

PoS Leader Election Example of Decentralized Sequencers (r&c)

In this setup, the way it works is quite simple—When choosing the sequencer for a certain round, a committee simply utilizes a weighted round-robin method based on stake weight. With this method, any validator can easily calculate the eligible proposer for a given round. If you want to read about NMTs on Celestia, check out our data structures article here. (Keep in mind that the dispute window could potentially be lowered in this setup, as you’re not in the extremely competitive blockspace of Ethereum).

There’s also been some research and discussion (2017 on Tendermint repo) done into randomizing leader election as well, which could also be a method to get a similar setup to fair ordering, but with a random proposer (leader) instead of first-come, first-serve. Although, this disincentivizes sequencers to buy and stake more tokens (which weighted round-robin incentivizes), which could lower the economic security of the protocol.

MEV extraction differs between the two different setups, and can result in MEV being distributed and extracted differently. There are other concerns to keep in mind, such as finality guarantees, disincentivisation methods for MEV, which we’ll cover in a second part alongside the various actor that populates the space in modular MEV, and how collusion can happen. We’ll also look at shared sequencers and meta mempool setups—so look out for another part in the coming weeks!

Many thanks to Mathijs van Esch for participating in the writing of this article, and to Josh Bowen for the discussion that originally led to this series of articles.

Thanks to Mekatek for reviewing.

The four graphs on MEV data related to blocks per relay, builder payments and MEV-boost share are able to be found at https://mevboost.pics/, one of the greatest websites on MEV data - big thanks to Toni Wahrstätter

In this article, we are referring to Namespace Merkle Trees (NMT), Merkle Tree Mountain Ranges (MMR), and also Jelly Merkle Trees (JMT). This article will thus serve to explain some interesting aspects of them, their use cases, and hopefully, you’ll want to further explore data structures further. 

Merkle trees are the most commonly mentioned data structure when talking about the inner workings of many infrastructure projects in the blockchain industry. They are named after Ralph Merkle, who patented the concept in 1979 after introducing them in his paper “A Certified Digital Signature”. 

Merkle tree from Ralph Merkle in ‘A Certified Digital Signature’

The fact they have received so much attention in the crypto industry is hardly surprising, as they have been a critical data structure in commitments to the global state and transactions roots of blockchains. The most clear-cut example of this is the fact that Merkle Trees were first mentioned on page 4 in the original bitcoin whitepaper. The stated main advantage of using Merkle Trees in the block header was to allow nodes to discard spent transactions, consequently saving disk space.

Original Mention of Merkle Trees in the Bitcoin Whitepaper

As part of scalability research (including statelessness), a lot of resources have been put into altering Merkle Trees. This is because as we try to scale blockchains in a way that does allow people to keep running nodes (why? See end user verification) resource usage must be minimized. Through that lens, the various ‘flavours’ of Merkle Trees are fascinating innovations for scaling and security within blockchains and infrastructure projects.

One thing that does warrant being said, before we dive into the various data structures we’d like to showcase, is that some of them have different purposes. For example, JMTs, Patricia’s (in ETH) and Verkle trees are used to commit to the global state root, while NMTs and MMRs are used in transaction Merkle roots. However, both’s roots (top node) would commonly be provided in a block header. In Ethereum’s case, standard Merkle trees are used for transaction data, while a Patricia tree is used for the global state tree.

Namespace Merkle Trees, also known as "NMTs," are a type of data structure that is used to organize and verify large collections of data on a blockchain. As a variant of the aforementioned and more well-known Merkle Tree data structure, they offer a number of advantages in terms of efficiency and scalability when it comes to applications and rollups requesting data specific to them. They were initially presented in the LazyLedger paper presented by Mustafa Al-Bassam of Celestia in 2019 as part of his PhD.

Original Diagram of NMTs presented by Mustafa Al-Bassam in his PhD

One of the key benefits of NMTs is their ability to organize data into a hierarchical structure, wherein you can efficiently verify individual or separate pieces of data that an application requests. As a user, you only need to retrieve the corresponding leaf node and its parent nodes, rather than the entire dataset.

Another advantage is its ability to scale to very large collections of data. This is made possible by the use of multiple levels of "namespace" nodes, which allows for hierarchical organization. 

As with any Merkle tree structure, they use cryptographic hash functions to combine (hash) the data in each node, which ensures that the data cannot be modified without detection. Additionally, their hierarchical structure allows for efficient and secure verification of the integrity of said data.

Every chain (“rollup”) on top of Celestia has its own namespace, for which the data is merkelized and sorted. The final result is one short Merkle root, where each rollup has its own subtree (namespace) that it can pull and watch data from. This is especially relevant for blockchains with potentially more blockspace per block (while enabling light clients to be first-class citizens through DAS) as it allows you to pull data without having to pull the entire block. 

As such, an NMT on Celestia is a Merkle tree with the nodes ordered by namespace IDs and the hash function modified so that every node in the tree includes the range of namespaces of all its child nodes. If an application or rollup requests data for a specific namespace, the DA layer (Celestia) then supplies datasets for the specific data relevant to that application as a result of its unique namespace ID and provided nodes in the tree. This allows us to check that the provided data has been made available in Celestia blocks, hence the name Data Availability (DA). 

Another implementation of NMTs is the ones used by Sovereign Labs, a ZK sovereign rollup, who have been implementing them in Rust. 

A Merkle Tree Mountain Range (MMR) is a data structure that is used to maintain a consistent large log of data that is easily accessible without providing the entire tree. It is also based on the concept of a Merkle tree. In an MMR, each leaf node represents a piece of data, and the hashes at each level of the tree are computed by attaching the hashes of the child nodes and applying a hash function.

The MMR structure allows for particular efficient insertion of new data and the ability to prove the existence of an existing distinct piece of data within the tree. The name “Mountain Range” refers to the specific construction of the tree; It is constructed in such a way that it always tries to maintain the largest possible consistent single binary tree (binary meaning that each node has at most two child nodes), which can result in the tree structure having multiple “peaks” (hence the mountain) or sister trees. When the root nodes of an MMR are needed, the peaks of the individual trees must be batched together to compute the root hash of the entire MMR (the block header, root (top) node of a Merkle tree for example). This makes MMRs a useful tool for maintaining a consistent and long-term secure and verifiable record of data, where certain parts can be updated and referenced as needed.

A small representation of a simple MMR

Now imagine this on a larger scale, and you get the concept of MMRs.

Artistic Representation of a Merkle Tree Mountain Range

The ability to efficiently prove the existence of a particular piece of data within an MMR makes it useful for non-interactive state proofs, alongside Verkle Trees, which we’ll cover further down. A state proof is a method of verifying the current state of a system without requiring direct interaction with that system. In the context of an MMR and Verkle Tree, a state proof might be used to verify the current state of the data within the tree without having to directly access the tree itself.

This means you can allow a prover to provide a compact proof of the inclusion of a particular piece of data within the MMR. The proof can then be verified by a verifier using the root hash (known as block header in block commitments) of the MMR and the hashes (child nodes) at the appropriate levels of the tree for the data needed. By utilizing this method, it allows the verifier to confirm the authenticity of the proof without having to access the data in the MMR directly. Appending an element to an MMR is much more efficient, as you don’t need to navigate through the entire tree to include a new dataset. All of this can be achieved on-chain, which allows for full transparency. However, MMRs are much more expensive in terms of gas than Merkle tree proofs to verify on-chain (Comparison, note append gas and verification gas being different, although committing to an MMR is cheaper). In most use cases, MMRs would become infinitely large and not able to be verified on-chain (as a result of gas usage), hence off-chain verification via an open-source “trustless” ZKP setup in many cases.

Herodotus is an example of a project utilizing MMRs for their non-interactive state proofs, wherein the data required is computed into a ZKP, which can then be verified as needed. This allows them to keep a consistent state of verifiable data that can be refreshed and accessed as needed.

Originally developed by the Libra/Diem team for what was supposed to become the Facebook/Meta chain, Jellyfish Merkle Trees (JMTs) are a modified version of AR16MT. JMTs have several features that set them apart from other implementations of Merkle trees. Namely, version-based node keys which allow for smaller key sizes on average, reduced complexity with less node types, and a concise proof format—meaning less space usage and faster computation. They function to provide what was called either “Proof-of-Inclusion/Exclusion”. Which tracks the binary path to the intended node.

Penumbra is another project that is utilizing JMTs, although with some changes. Penumbra uses them to record all values related to the chain such as valset, proposals, assets etc. This, despite the chain providing privacy, obviously still needs to be stored and available to clients, so that they can verify that the information is indeed correct. A sparse Merkle tree, such as JMTs is ideal for such a purpose.

On any other blockchain, full nodes handle all transactions and keep a record of the entire chain state. Clients can check the accuracy of the data with Merkle tree commitments. On Penumbra, however, the chain only stores cryptographic commitments to private user data, and lets clients handle transaction execution and instead provide ZKPs to ensure that transactions are computed correctly. The implication of this is that clients must create Merkle proofs for verification by full nodes, but as the number of users on the chain grows, the burden on clients to process every transaction becomes unsustainable. To address this issue, they use a Tiered Commitment Tree (TCT), a light SNARK-friendly Merkle tree with subtrees that enables clients to ignore transactions that do not affect them.

Representation of a Tiered Commitment Tree (TCT) used in Penumbra

Note that a root refers to the “top” node (which is what is provided in a block header), while child nodes are also known as leaves(leaf)—hence a tree.

Now that we have discussed various flavours/alterations of Merkle Trees it can be interesting to look at one integration that Verkle Trees can achieve. As mentioned, Merkle Trees can bring improvements to the resource usage of nodes, this is why they were used in Bitcoin in the first place. One big effort in this area is using Verkle Trees to reach what has been coined “statelessness”. Statelessness is the concept of allowing nodes to disregard state they have no interest in (read more). One instance could be that state not updated over a year could be disregarded by a node. However, this state will remain revivable at a later time via polynomial commitments. This would vastly reduce the resource requirements for nodes. Verkle Trees are a critical component of this because they enable smaller proof sizes, which makes statelessness (either weak or full) feasible. These advantages are a result of the parent node being an offshoot of vector commitments rather than hashing functions. However, this comes at the cost of compute efficiency, as mentioned in our previous article. 

Efficient Verkle Tree (VT) Construction, in a normal VT there’s a proof for each path.

Other projects utilising Verkle trees to lower the resource usage of nodes and make their data commitments to chains more efficient are Polymer and Lagrange. Lagrange is compiling Merkle trees into Verkle trees for smaller commitments, so that the eventual Zero-Knowledge Proof (ZKP) that gets posted on another chain is much smaller and less costly than initially. Furthermore, vector commitment based proofs (which Verkle trees are) can be aggregated easier in a user’s browser than Merkle proofs within zkSNARKs. For this same reason, Polymer eventually wants to move to Verkle trees, as covered in our “Beyond IBC” article. They’re both using Plonky2 as their ZKP scheme for the on-chain verification. 

This is just an example of cool shit you can do with Merkle tree alterations. We hope that it either piqued your interest in data structures or has driven you to research parts of blockchain infrastructure that you might not otherwise have looked at. If you're working on anything in this domain, reach out to us!

Also many thanks to Mathijs van Esch for helping with parts of the article, and for providing the discussion leading to this.

Over the last couple of months, we have seen token bridges be targeted by increasingly elaborate exploits. This has prompted several people to talk about the actual security of bridges. As such, we would like to present a comprehensive overview of security and trust assumptions in blockchain bridges. This will provide a complete overview of most messaging protocols, bridges and interoperability projects. Furthermore, we will also take a look at the economics of cross-chain messaging protocols and bridging, since this is also extremely crucial if the token of the protocol enables you to take governmental control over it.

First off, let’s establish just how bad the problem has become in regard to exploits happening on bridge-related protocols.

Comparison of Exploits

Bridge Exploits In Numbers

As can clearly be seen, the exploits of bridges have been a huge issue as the number of chains in existence grow. This is only set to become a more systematic risk unless we prioritise security, and we as users need to be at the forefront of holding protocols responsible - it’s our funds at the end of the day. This is also why we are writing this article—to focus on trust assumptions and security in the interoperability space.

Likewise, as a result of the industry becoming increasingly multichain, app-chain and modularly focused we are also seeing a large influx of new blockchains and layers. To accommodate users and liquidity, interoperability is needed. As such, we've seen the importance and popularity of bridges, in particular token bridges, become increasingly popular as more and more blockchains start to build out their own ecosystems. As a result of this, there's a demand for liquidity to be moved from one chain to another. Hence the popularity of token bridges. Although this is not the only use-case of bridges. Here we are specifically referring to general messaging protocols, IBC for example, which enables a myriad of use cases through its messaging system and standards.

An excellent overview of how many assets are bridged across various chains can be seen here (s/o to CryptoFlows.info - creators are also behind other great sites such as L2Fees, CryptoFees):

This clearly shows the demand for bridges and highlights why it’s so incredibly vital that we push for security when it comes to cross-chain messaging protocols and bridges - because they handle tremendous amounts of value, both in regards to volume and are often also custodial in many cases controlled by multisig smart contracts.

In most bridge applications and cross-chain messaging protocols, there is a range of actions that contribute to its efficacy. These are primarily seen underneath. Although, they depend on the particular bridge/messaging protocol in question: 

Fraud Watcher/Monitoring: State monitors such as light clients, validators or oracles.

Relayers: Takes care of message passing/relaying such as a relayer (usually just a messenger, not a consensus participant), taking information from source to destination chain which operates off-chain.

Consensus: Agreement between actors monitoring the chains, this could be in the form of a trusted third-party valset, such as with Axelar or an off-chain network of consensus nodes, or even a multi-sig.

Signatures: Bridging actors cryptographically sign messages, this could be validators signing a cryptographic signature such as with IBC, or through a ZKP (such as Plonky2) with Polymer that attests to the validator signatures from the source chain.

Bridge Actors and General Architecture

You can then categorise these protocols into four major types:

Custodial Bridges (often asset-specific, but you could even say exchanges are custodial bridges): Providing wrapped assets that are collateralized in a custodial (through a third party) or non-custodial (smart contract) way. An example of this type of protocol is wBTC with a centralised merchant like BitGo which then mints an equivalent ERC-20 token (wBTC on Ethereum). We will get into the trust assumptions and risks of this type of solution later, but some of them should be quite clear just by this explanation alone.

Multisig Chain-specific: These are usually two-way bridges between two chains such as the Harmony Bridge, Avalanche Bridge and Rainbow Bridge, all connecting their respective chains to Ethereum via a smart contract on Ethereum. Users typically send an asset to the protocol, where it is held as collateral, and are issued a bridge-wrapped token on the destination chain, backed by that collateral locked in the contract on the source chain. These are often protected by a set number of validators or even just a multi-sig. We've seen how these solutions have proven prone to risk - namely with Ronin Bridge and recently the Harmony bridge.

Application-specific: An application that provides access to several chains, but is used just for that particular application, for example, Thorchain, which also operates its own chain with a separate validator set. The trust assumption with these often lies within a single validator set that controls and handles all messages and transactions across the network that connects to different smart contracts/addresses on various chains.

Generalised Cross-Chain Messaging: Cross-chain messaging protocols that allow for generalized messaging across chains with set instructions, such as IBC. These are usually dependent on validator sets. Here the trust lies within the two chains’ validator sets that are connected. With XCM, the trust lies with the Relay Chain (Polkadot). You could also add messaging protocols such as Polymer and LayerZero, that are both agnostic.

• Cross-Chain Messaging protocols are often used in conjunction with liquidity layers since they often only handle communication and standards between chains based on their specifications. A great example of this is Superform which uses both LayerZero and Socket (as a liquidity layer). You could also view separate Cosmos-based chains as liquidity hubs for IBC as well.

The Operational Simplified Architecture of Mentioned Bridge Types

This next section will serve to cover two of the vital parts of cross-chain protocols, namely the smart contract risks involved and the additional trust assumptions that need to be accounted for.

One of the first and most obvious security risks to cover is that of smart contracts. Smart contracts are used in most cross-chain bridges that don’t have a native generalized messaging protocol, therefore, it is of vital importance that they’re secure. So let’s cover some of the risks that need to be addressed here. The most effective way to avoid those risks is by omitting the usage of smart contracts altogether and instead relying on the security of the chains in question.

1. Correct Statements for calling contracts

   1. What functions rely on predefined conditions before execution is possible

   2. Assert conditions to check for things that need to hold true for all function executions, such as balances of bridge liquidity contracts

   3. Revert statements that are triggerable if required conditions aren’t met, such as those previously discussed.

2. Formal verification and rigorous testing

   1. Formal verification of contracts is important to ensure the correctness of said smart contracts under set conditions. Does the math work out? Does it work according to the specifications I need it to adhere to?

   2. Testing all functionalities of contracts - for every update or change made.

   3. Test randomness to ensure that if security properties are violated that the functions hold true.

   4. There are various testing methods that can be used such as - Unit testing, static and dynamic analysis and much more. Get in touch with folks like Runtime Verification, if you want to discuss what you can do.

      1. As always remember to audit your contracts, but be aware that an audit isn’t a stamp that something can’t go wrong, it’s just another way to minimise trust. Bug bounties are also another good thing to utilise, and there are various ways to implement those - such as Sherlock and ImmuneFi.

3. Upgradeability vs Non-Upgradeable

   1. Should your contract be immutable and non-upgradeable? This obviously ensures that “malicious actors” can’t cause problems. However, it lowers the ability for innovation. A new contract and a migration to it would be needed, which would need to go through the many checkpoints we’ve discussed previously. Another downside is, what if the contract has flaws that are now unable to be addressed and it simply lives until it gets exploited? Although, the beauty of being non-upgradeable is the fact that it limits exploits in the case that the contract is steadfast, and if an update is made without the proper security measures to an upgradeable contract it can lead to faults - as seen before.

   2. However, if you do go with upgradeability, which in most cases is the correct option there are various ways to ensure that you adhere to minimise trust and maximise security:

      1. Prepare for failure - what upgrades are needed if an exploit takes place, can I enact emergency measures?

      2. Utilise proxy patterns - splitting up state (info) and logic (execution) between separate contracts. This means that you could upgrade the logic of the smart contract (with a new one) without messing with the state itself.

4. Emergency Stops

   1. Have entities that have access to an emergency stop function which close accessibility to functions within the smart contract. This should only be used in very significant situations where it is needed to stop an exploit. This does however put power in the hands of the few, but it can sometimes help to safeguard functions in contracts in the case of exploits. This is a good method and idea to implement alongside the next point.

5. Monitoring (Watchers)

   1. Active monitoring of smart contract functions and execution is extremely important to ensure liveness and correct tracing. You can also utilise various monitoring tools to get alerts on certain triggers or functions which are important to the liveness and safety of the contract.

      1. One way to add to this is to have incentivised watchers (such as with Optimistic Rollups) that have incentivisation to catch fraudulent activity and report it. However, this needs to be implemented in a way where it will actually have an effect, there are more pressing matters than having watchers.

6. Governance

   1. In the case that control of your smart contracts is decentralised and given over to the token holders of your protocol there needs to be certainty in the security of governance systems.

   2. Things to consider are large token holders able to upgrade the contract and change functions in their favour, which could lead to malicious exploits causing failures and loss of funds - something that has been seen previously.

      1. A good method to consider is Optimistic Approval which is a method to add timelocks and a veto process to allow for aligning incentives and limiting power to certain actors and helps to avoid malicious proposals.

      2. This also ties into using timelocks to prevent smart contracts from executing functions that are integral to the system until a certain amount of time has passed, which can allow emergency functions to step in if needed.

      3. TWAP voting could also be used to reduce quick governance voting takeovers.

   3. A decentralised governance system can be very useful to allow community members to have a say in the future of the protocol. However, it does add risk and trust assumptions.

7. Access Controls

   1. Specific functions of contracts need to be addressed as to who can call them. Should all EoAs be allowed to call functions? Should functions be public or private? Should only functions be called within the smart contract etc… Some functions should only be accessed by some actors, such as upgradeability, or minting tokens.

   2. Who’s the owner, and what functions are they able to execute - does it lie solely with a single owner or a multi-sig? Often separate roles can access part of the functions to limit centralisation. Regardless, you should focus on eliminating single points of failure and minimise trust - focus on minimising, you can never remove trust.

8. Reentry

   1. Sequence numbers, timestamps or cryptographic proofs to ensure valid identification of contract calls to avoid double dipping.

9. Oracle Manipulation (Consolidated Oracles)

   1. Another important thing for smart contracts that depend on price feeds or similar information from oracles is to have secure methods for identifying manipulation and limiting what is possible from an outside perspective.

      1. A great research paper to read on this is the Consolidated Price Feeds which lays out ways to ensure security and minimise trust when using oracles.

As may have been clear from the above there are a lot of trade-offs involved when it comes to smart contract risks. We hope that with the above list the majority of risks involved are shown and users and developers alike can start assessing those risks. 

It should also be noted that even though some Cross-Chain Messaging Protocols do not rely on “smart contracts” per say, they still rely on code and protocol design that needs to be extensively audited and tested. This should go without saying, but it is still important to note. They should also be updated in line with many of the same ideas discussed too. A somewhat recent example of a non smart contract bug that resulted in an exploit is that of the BNB exploit, which was a result of out-dated code in an old IBC spec, that wasn’t kept up to date.

Another important part to cover is the trust assumption within the specific protocol that is being used. This is incredibly vital in the case of something like wBTC which is handled by a centralized custodian. It’s also relevant even in the case of roll-up contracts that act as bridge smart contracts for their specific layer 2. Often they’re controlled by a multi-sig or similar and in many cases are even upgradeable. In some cases the trust assumptions are small, in others, they’re quite large. However, what’s important to note is that in any bridge/messaging protocol there are trust assumptions to some extent, and there always will be. Even in the case of smart contract-free messaging protocols like IBC. In those cases, you’re trusting the validator sets of the connected chains. In other cases where there’s a trusted third party which operates the bridging protocol, you’re trusting that validator set primarily, such as Axelar and Polkadot. In those cases, you’re also often dependent on smart contracts that, at least in Axelar’s case, act as custodians of the funds being bridged to Axelar.

There Are Always Trust Assumptions

There are ways to solve some of these trust assumptions, such as relying on ZKPs to verify the correctness of block headers on-chain. However, there’s still a trust assumption that the block header is correct from the source chain (and its valset), and as such saying there aren’t trust assumptions involved is plain wrong. You’re also dependent on the verifier contract on-chain being correct, and as such open-sourced contracts should always be preferred and be subject to testing and formal verification. What this does prevent is relying on external trust assumptions, the less of these involved, the better. While we’ll never reach trustlessness, we can get relatively close and reach practical trustlessness which is the point where the trust lies solely within a decentralized network of sufficient cryptoeconomic accord. And by accord, what is meant is that the cost of an attack would far outweigh the gain. Here it is also vital to consider that it’s in most network actors’ interest to ensure the long-term health of the network for their own gain. This leads us to the ever-constant saying of - and + EV and the role of Moloch, and the ability for us as a community to coordinate together on and off-chain to fight off irrational actors.

The Types of Bridges Discussed Earlier Plotted In Regard to SC and TA Risks

Disparity in Trust

Although one thing that is vital to understand is that there's a disparity in trust. The trust system varies from one blockchain to the next. Transferring data from one blockchain to another that has a greater or lesser cryptoeconomic security could result in malicious actions.

Multi-sig wallets require multiple signatures from different parties in order to authorize a transaction, making it much more difficult for a single entity to compromise the security of the system. Decentralized governance, on the other hand, allows for the collective decision-making of a community of users, making it harder for a single entity to gain control of the system. However, each multi-sig setup will be different from the next, offering various amounts of security and trust assumptions. The same goes for the case of decentralised governance. Is there sufficient decentralisation in the token holders, do they have a governance implementation that favours security - for example, Optimistic Approval? There are several factors that are important to take into consideration, and often vary from protocol to protocol

Another key thing that we covered slightly earlier is "replay/reentrance attacks." In a replay attack, an attacker broadcasts a previously recorded transaction on one blockchain to another, potentially allowing them to spend the same funds or assets multiple times. The obvious way to avoid this is obviously the use of light clients to cryptographically prove that said transactions have been done on each chain. However, that is not possible on every chain. The clearest example of this type of exploit happening recently is with Nomad. Another option is to use sequence numbers or timestamps to ensure that each transaction has a unique identifier that cannot be reused - randomness is an important thing here as well.

One thing to also consider is where the liquidity on a specific asset lies. For example, is it in a source chain liquidity contract? Is it like certain USD stablecoins where the liquidity is actually off-chain? There are a lot of trust assumptions to consider. We should aim to minimise trust assumptions, but we can never remove them completely.

Now that we’re established some of the significant things to look out for when you’re bridging your treasured assets, just wanting to query data or sharing state - let’s understand why bridging assets and state are vital.

Data movement and state sharing is the next step in enabling true composability across chains. It allows applications to extend beyond the boundaries of chains and built protocols in a chain-agnostic way. With this, a module, account or smart contract on chain A can call or read the state of a smart contract, account or module on chain B. A great example of this happening is through the ICQ module within IBC. It is correspondingly vital to ensure the security of assets being bridged around to various chains, as we and many others foresee a future where many chains, hopefully, co-exist.

This section will serve as a guide to basically every single cross-chain bridging and messaging protocol in existence. It will cover their various security measures and where their trust assumptions lie. If we missed a certain protocol, then we do apologize. But, this section should still cover the vast majority of protocols that exist, and will even go into specific bridge contracts such as L2 bridge contracts as well.

We’ve already gone over how IBC works quite in-depth in previous articles such as this one, and this one. If you’re interested in reading up on them, I recommend you do so. What’s important to underline though is that the primary trust assumption within them lies in the validator set of the chains that have opened a channel. There are no smart contract risks, but rather the trust in the valset and their state.

As we covered in our Polymer article, there are various derivatives of IBC. By this, we mean cross-chain messaging protocols that utilise IBC in some way or another. This first section will cover such protocols. Namely Polymer and Composable, we’ve already done a comprehensive deep dive into Polymer, so we’ll keep that part short as you should already be quite well acquainted by now. It is also important to note that we are investors in Polymer and Composable.

Polymer

• IBC Routing protocol, is more of a generalized cross-chain messaging protocol than a bridge

• Light Clients or Smart Contracts acting as a light client verifying block headers (signatures from validators)

• Cryptographic proofs through validator signatures from validator sets - ZKP on non-Cosmos chains, via recursion (plonky2) and on-chain verification - their zkIBC implementation.

• IBC logic in smart contracts

• Can offer asynchronous bridging that relies on valsets of connected chains.

• Enables data sharing and query. Not just an asset bridge.

• Synchrony commits on the source chain (validator signatures), finality once block headers are checked on the destination chain.

• Cryptoeconomic security is the stake of the connected chains valsets with IBC, and for non-IBC based chains the trust assumption lies in the smart contracts deployed.

Composable

• XCVM operates similarly to how Polymer operates. By this, we mean the ability to deploy native cross-chain protocols. So the sharing of state, query ability and such.

• Centauri is their transport layer which is what facilitates the actual communication. This is based on IBC and allows for state sharing as well. It basically allows the bridging from IBC chains through their Parachain, which is connected to its respective Relay Chain.

• Operates with light clients as with IBC and a rust implementation of IBC to support the Polkadot ecosystem (Substrate). Light Clients or Smart Contracts/Pallets acting as light clients verifying block headers (signatures from validators)

• In this case, the trust assumption moves from two singular valsets to the valset of the Relay chain in question (Polkadot or Kusama) which operates the state of the Parachain being bridged to, from a chain that utilises IBC. This is through an IBC pallet (similar to the Polymer IBC contracts in Solidity on say Ethereum) which implements the IBC framework needed on their Parachain.

• Watcher nodes to verify block validity in case of attacks on chains.

• For chains with native light client support, the process is quite similar to how IBC works natively.

The next section will serve to explain how XCMP works, which is the native cross-chain messaging protocol of the Polkadot ecosystem. This is a natural follow-up to Composable since they indeed originate from that ecosystem.

XCM(P)

• Parachains make a single trust assumption since they all rely on Polkadot’s consensus, so they trust the main relay chain. Same with Kusama and its parachains.

• Thus XCMP relies on Relay Chain and parachain validators to verify messages sent from para chains, the process is finalized by a block on the relay chain.

• Established channels such as with IBC. However each submission needs to go to the relay chain, and as such need to monitor state on the relay chain to confirm that messages have reached consensus. Thus, the parachain block headers go into the relay chain blocks to confirm message passing.

  

• In this case, the Relay Chain sorta operates as the trusted third party (TTP) - so it’s as safe as the valset of the Relay Chain - your trust assumption.

• Parachains derive their security through the Relay Chain (Polkadot) through shared security.

• This means that the total stake of the Polkadot network is the trust assumption and cryptoeconomic security of XCMP.

IBC

• Requires a light client on each other’s chain to cryptographically verify consensus state between the two chains

• Requires Relayer to relay information between the light clients on the two chains. The relayers are required for liveness—the ability to be able to exchange messages among nodes, with the nodes successfully coming to a consensus.

• The relayer does not relay messages to light clients on each chain. Instead, the exact recipient of messages that the relayer submits to each chain is the IBC module on that chain. Light clients are a small subcomponent of the IBC module.

• IBC light clients only trust a specific header at initialization step (a root-of-trust, when the client is created). During that step, the client indeed trusts that the node which supplied the header is honest. After that step, they no longer have trust assumptions resting on specific full nodes being honest.

• Trust assumption lies within the two validator sets of the connected blockchains

• Cryptoeconomic security is the total stake of the chains in question

  

To continue on the Cosmos route let’s take a look at Gravity and Axelar which both operate their own bridges via smart contracts on non-CosmosSDK/Tendermint chains and onto their own chains that function as a trusted third party and consensus network. These are relatively simple solutions, but they do enable the Interchain ecosystem to connect to the wider blockchain ecosystem. So let’s take a look at them as well.

Gravity

• Runs a Cosmos chain as the consensus network which secures and mints ICS assets that are usable in the Cosmos ecosystem.

• Validators are required to run a full ETH node

• Connected by a relayer network (which in this case is not trustless as with IBC) which adds a trust assumption since they control their Cosmos SDK zone and as such run their own Eth nodes as previously noted.

• Liquidity bridged to Gravity is in smart contracts on Ethereum.

• Non-upgradeable contracts, only slight logic upgrades are possible.

• The trust assumption lies with the Gravity bridge valset, smart contract security risks and relayer network that has conflicting interests.

  

Axelar

• Similarly to Gravity, it relies on validators of the Axelar chain to run nodes/light clients on the chains onboarded to Axelar.

• They also batch up transactions similarly to Gravity

• Relies also on smart contracts that need to be ported to the targeted language of new onboarded chains. Axelar currently supports more chains than Gravity which only services Ethereum. These smart contracts aren’t liquidity smart contract as such, but rather a smart contract that can call other contracts. This means they in theory operate like a gateway or a light node in which messages are passed that fit the logic supplied by Axelar. Bridges, like Satellite, can then use the infrastructure to set up an actual liquidity bridge and bridge assets.

• Allows for general message passing cross chain and is targeting applications to implement Axelar as a messaging protocol ala what IBC is as well as what Polymer and Composable are targeting.

• Allows apps to use their infrastructure. Similarly to how LayerZero is not a bridge, but Stargate is. This is a solid comparison, however, keep in mind that Axelar operates its own consensus network, which is its Cosmos SDK chain where its validators also run nodes for connected systems.

• The trusted valset is currently 60 validators (although not all validators run nodes on the connected chains, for a subset of them or sometimes all). There’s obviously smart contract risk to take into consideration as well, and also if you’re using a bridge connected via their infrastructure they're smart contracts as well.

  

Next up I think it’s quite relevant that we take a look at LayerZero, who’s really taken the general cross-chain messaging protocol world by storm, and has seen great traction. What’s important to note here again, is that L0 is not a bridge, but rather a messaging protocol that you can build bridges with or use to call cross-chain smart contracts.

LayerZero

• Two entities— oracle and relayer.

  • The oracle forwards block headers to the destination chains, while the relayer forwards the transaction proof from the source chain against the relayed info from the oracle, which attests that the transaction/message is valid

• Applications are given the flexibility to use LayerZero’s default oracle and relayer or create and run their own. They’re used as a cross-chain messaging protocol, not an actual token bridge. But you can build bridges with it, such as Stargate and others, which use them for messaging.

• Endpoint, which is their version of Axelar’s Gateways, or Polymer’s IBC logic smart contracts. They basically handle the verification as a light client would in IBC.

• This does mean you, as with Axelar, are dependent on the LayerZero infrastructure and then the smart contracts connected to LayerZero.

• If one of the two actors is dishonest the transaction will fail. However, if both are dishonest (which if you rely on centralized solutions or the application’s own could be a problem) exploitation is possible. As such decentralized oracle networks being used here are essential, also having multiple options and possibly using consolidated oracles - refer back to the oracle part further up if needed.

• Doesn’t rely on a trusted third-party chain, but instead on a modular architecture that can have varying degrees of security and trust.

  

• As safe as the oracle/relayer solution being used as well as the natural smart contract risks.

• Does not provide or depend on any cryptoeconomic security per say. However, it does rely on crypto economical security of the networks used. So, the economic security of the oracle used. The security of the relayer is it a multisig etc. It also has trust assumptions in the smart contracts that are used too.

Next off let’s look at what has been coined “Optimistic Bridges” here I am particularly referring to Nomad and some of their partners. There’s obviously some connotation with this, but do remember that the exploit was not a result of the bridge mechanics, but rather a smart contract exploitation, which the security of the network failed to cover.

Optimistic Bridges

• Transaction/data posted to a contract function ala Endpoints/Gateways previously mentioned.

• Bridge agent signs Merkle root of data being correct and posts it. Then any relayer can post it to the wanted destination chain. This agent has to bond tokens that are slashed if fraud happens.

• After data is posted a fraud-proof window is started where any watchers (incentivised since they get the agent’s bond) of the chains can prove fraud on the source chain and as such the bond is slashed. However, currently, on-chain slashing as such isn’t possible so it has to happen in an off-chain network usually half-manually.

• If no fraud-proof is sent within the time frame data is considered final on the destination chain and can call the contract on the destination chain.

• This technique has a low trust assumption, however, it relies heavily on smart contracts and watchers working. If there are any smart contract exploits, the watchers are unable to do anything.

• They just need a single honest watcher, since only a single party needs to correctly verify updates.

• This does mean that the slashable stake that is bonded needs to not be extremely high since you’re relying on the fact that just one party is honest.

• Needs decentralised agents, otherwise, a single one can halt the system.

• Needs tax on watchers to prevent DoS, however, this means that if there’s never any fraud you’re also not gaining anything - needs different incentivisation schemes unless you’re just relying on the actors of the bridge to run them, but that leads to centralisation as well, since both watchers/actors and the protocol would be running everything.

• Cryptoeconomic security is dependent on the specific networks used. It could be the cryptoeconomic security of the watchers or agents that have bonded tokens to be allowed to participate, etc. There are various ways to limit their reach, as discussed previously.

  

  The Architecture of Optimistic Bridges

Next off let’s cover Multi-Party Computation (MPC) bridges, some of which also rely on their own trusted third-party externally verified consensus network, such as a blockchain. Two examples of such solutions are Qredo and Chainflip. Synapse also works somewhat similarly with their leaderless MPC valset.

Multi-Party Computation (MPC) With External Validators

• MPC is a threshold signature scheme that allows several nodes to create signatures under a single key, this makes it harder to collude and take over an account.

• External validators refers to the fact that the protocol is running a network or chain with validator nodes that verifies signatures and calls and controls the gateway smart contract functions on chains that the MPC wallet wants to bridge to. This can also be referred to as a middle chain approach.

• Many MPC solutions also run various hardware security.

• If an unauthorized attempt is used to access accounts the keys stored within that node are destroyed, social engineering is the only way to access (which we have seen succeed before)

• This also means that these bridges are often limited to a few individuals and not as widely available. Typically focused on institutional use.

• Trust assumption in that the bridge gateways contracts are set properly from the protocol in use. Security risks in the various smart contracts. Social engineering is also a valid concern here.

• The middle chain is often used to record the ownership of assets for users.

• The gateways should be controlled by a decentralized multisig/node network for optimal security assumptions.

• The middle chain in these cases often is the cryptoeconomic security for the system, since it allows to record and change who owns assets, as such it is the trusted third party.

• Keep in mind that with the number of signatories used the latency of system can increase, as seen below:

  

• The various solutions end up looking somewhat like this:

  

The previous two solutions can also be seen somewhat as an application-specific bridge, which is a type of chain we alluded to earlier as well. Another chain that fits into this grouping, is the one that people usually think of, Rune also known as THORChain.

Rune (THORChain)

• The THORChain essentially acts as an external validator that practically operates leaderless vaults on connected chains. This also means that it is the cryptoeconomic security of the entire network, as it acts as a middleman between the chains bridged. It is also one of the trust assumptions that need to be made.

• A state chain coordinates asset and exchange logic while delegating transaction output

• This works with an “endpoint” on each chain connected to handle the specific transactions

• Each signer is required to run a full node on connected chains

• Each chain’s client is relatively lightweight and only contains the logic needed to call contracts on particular chains. The main logic is in the observer clients that operate on the THORChain itself. Let’s sketch it out so you can get a better idea:

  

To finish off our analysis let’s take a look at a type of bridge that’s often not referred to as a bridge, but rather an L2 rollup contract. These are the contracts on Etherum that L2s communicate with and where assets are locked and then “minted” on said rollup. These contracts hold, at this point in time, billions of assets. As such the validity of them is incredibly important. Let’s take a look at how they work, and what type of security they provide.

Rollup Bridge Contracts

• Function akin to a bridge in the sense that assets are locked in an L1 smart contract, and then become available on the L2

• Rollup state and proofs are verified on the L2 contract, giving cryptographic security, that is somewhat derived from the underlying layer. If a validity proof is needed, it is sent and verified in a verifier contract on the L1.

• Most rollups have upgradeability in their smart contracts, which is obviously a risk that needs to be taken into consideration.

• Most rollups allow transacting via the L1, or force exit to it if the sequencer fails.

• Essentially a trust-minimized bridge. However, there are significant smart contract risks, as well as trust assumptions around who controls those.

• The Arbitrum and Optimism “bridges” work like this.

  

Now that we’ve covered the vast majority of the type of solutions that are currently used for cross-chain messaging protocols and bridges, let’s take a look at another very important part of the security of the protocols in question. Here we are referring to the economics of the protocol. In particular of interest here is the cryptoeconomic security of the protocol, if it has a token that gives governance powers or allows you to take over a vital part of the protocol itself.

Let’s start with an assumption - There’s a bridge protocol with a governance token that allows voting for upgrades to the protocol or allows taking control over core protocol functions. Now, if the total value locked in the protocol far outweighs the quorum to pass a proposal, then there’s clear value in attacking the protocol. This simple assumption is why bridge economics and governance functions are extremely vital to bridges. One way to mitigate this in regard to governance is to utilise a slightly more nuanced governance principle called Optimistic Approval, as covered earlier.

Cryptoeconomic security is a crucial aspect of blockchain bridges and cross-chain messaging protocols, and requires a carefully designed and implemented system of incentives and disincentives to ensure the security and integrity of the system. This is why systems that don’t necessarily rely on trusted third parties’ cryptoeconomic security work best. In systems where you rely on a bridge’s cryptoeconomic security for securing assets on various chains, obviously isn’t as secure as relying on the chains’ cryptoeconomic security themselves.

However, currently, most bridges and cross-chain messaging protocols rely on the economics of a trusted third party. Obviously, this can be quite ideal in a situation where that valset is incredibly secure, but could also falter in other situations. There’s also the usage of other mechanics that can be used to secure networks that are participating, such as Verifiable Delay Function, which could add randomness to participating oracles in networks that rely on such actors.

Other economic aspects that need to be taken into account are networks where cryptoeconomic values are used often such as in multisigs, valsets, mpc or even thresholds. These often rely on an honest majority assumption, meaning that the cost to attack these bridges is the cost to corrupt/overtake 51% of the network.

Trusted Third Parties

The use of trusted third parties in blockchain bridging has both advantages and disadvantages. On the one hand, these third parties provide a centralized and trusted point of coordination, which can make it easier to manage and secure the transfer of assets and data between the different networks. This can be particularly useful in situations where the different networks have different security and consensus models, or where there is a need for additional levels of oversight and control.

On the other hand, the use of trusted third parties introduces a potential point of failure in the system. If the third party were to be compromised, it could potentially lead to the loss of assets or data. Additionally, the centralization of authority in a trusted third party can potentially undermine the decentralization and trustlessness of the system itself.

Rate Limiting

Another aspect that is also economically relevant and that could help limit the damage attack cause is the use of rate limiting for the bridges. What is meant by rate limiting is the concept of limiting the amount of total USD value that can be bridged per hour, so that emergency solutions can be put into place to save the rest of the bridge.

Obviously, this causes issues on the UX side, especially for very popular bridges or for large bridging users, while obviously adding some security. For example, you could limit the total amount that could be bridged to 10M USD every hour. The vast majority of users/retail won’t notice, and it would limit the possible damage in an exploit to an amount that is much smaller. This would obviously have been quite useful in past exploits.

Is there some magic number for what the rate limit should be? Not really, it depends on the adoption of said bridge, and it also depends on what chain is being bridged to. For example, on an Arbitrum<>ETH bridge you’d need a large amount that is possible to be bridged, as a result of its popularity. However, in the case of a gaming-specific app chain or rollup, a ton of value isn’t needed to play a game, and you’d rather ensure the security of users’ funds. In this case, rate limiting would make a lot of sense.

The negatives are obvious - throttling and pricing out big players. However, does security outweigh those?

One solution could be to implement a “highway of bridge lanes”. Different bridges for different solutions and people. One obvious downside of this is the fragmentation of liquidity and volume that this would bring. For a gaming-specific rollup it makes sense to rate limit lower amounts, you won’t need big amounts there, and you want to ensure the security of your user’s funds under any circumstance.

Some other things to keep in mind are:

1. DoS attacks, so you’d need to implement considerable fees on big volumes.

2. You want to optimise for growth, but this puts a slight stopper on growth.

As has been clear throughout this article, it’s trade-offs all the way down. So this is also the case when it comes to rate limiting. However, it is an area we would love to see more experimentation in. In most of these cases there is no clear optimum, but in general, trying out new and daring things in this space is worth doing. No final design is ideal by any measure, but safety and security should be the biggest concern for any protocol. You could say rate limiting allows us to sacrifice UX for the few and provide security for the many.

Interoperability is often used to explain the seamless transfer of assets between applications and chains, while composability is used to describe the idea of a shared infrastructure between those specific applications, such as deploying an application on several chains with minimum work. This is the type of work being done by previously described cross-chain messaging protocols.

Composability is really only sustainable if transaction costs are low between chains and applications, otherwise, it loses the principal value that composability grants you. Composability leads to more choices for the end-user and the ability to seamlessly do actions across various ecosystems and applications while removing prior obstacles such as building ecosystems from scratch. 

Applications become composable when they're able to interact with other applications such as automated liquidity positions, lending etc.

We’ve tried to be as objective as possible and provide a clear overview of the current landscape in regard to cross-chain interoperability, and hope that it provided some sort of value to you as a reader. If there’s any point that you disagree with or feel was misrepresented, then do reach out to the writer @0xrainandcoffee on Twitter. 

Thanks to Runtime Verification for input on the smart contract part, as well as to the other readers of the article, who have helped.

For further reading of trust minimisation in bridging, I highly recommend reading the Clusters piece by Mustafa from Celestia - Link

An inevitable result of more blockchains, either in the shape of a rollup or otherwise, is that interoperability will become exponentially more important. So as the world becomes more and more modular we expect to see a plethora of bridges pop up. One of the more exciting ones we see is Polymer. We will dive into how they are bringing IBC to all ecosystems below.

As a slight refresher, here is part of a section of a previous article by us, on IBC.  

Inter-Blockchain Communication(IBC) is at its core a cross-chain messaging protocol for homogenous blockchains. This means that it connects chains that share similar functionalities, in this case, instant finality provided by the Tendermint consensus algorithm and ones that have light client functionality. The way IBC works is that two chains that are interested in having a connection with one another will put up a governance proposal on the destination chain. This is usually, to begin with, either through the Cosmos Hub or Osmosis (Currently Osmosis has 45 peers, and Cosmos 40). This means that there’s an agreement on a protocol level, and as such, there is no need for a trusted third party in an external bridge.

These two chains then require a light client on each other’s chain to cryptographically verify consensus state between the two chains, as well as a relayer to relay information between the light clients on the two chains. The relayers are required for liveness - the ability to be able to exchange messages among nodes, with the nodes successfully coming to a consensus. Let’s explore how this looks in practice:

This means that the trust assumption lies within the two validator sets of the connected blockchains, as such there are much fewer trust assumptions than other types of bridges and messaging protocols. For example, with XCMP in the Polkadot ecosystem, the trust assumption lies solely with the relay chain (Polkadot).

To show just how compatible and widespread IBC has become in the Cosmos ecosystem, and how many chains it connects - let’s take a look at a map of the current live connections.

mapofzones.com

With IBC there are two connotations that are important to note. Those two are connections and channels:

1. A connection is two stateful objects on two separate chains - the IBC module in the CosmosSDK.

2. A channel is a specific connection to a chain/app and provides message delivery info such as ordering, this is what is referred to the relayer.

ICS stands for Interchain Standard and sets parameters for transactions happening between chains using IBC. ICSs are basically module specifications for IBC transactions. For two chains to communicate using IBC they’re required to possess the same ICS specifications. One of the more interesting and unique ICSs is ICS-27, also known as Interchain Accounts.

Polymer will be supporting existing ICSs. As such, chains that are connected to Polymer will be able to take advantage of much of the great work being done by the wider IBC community of which Polymer has been a long time contributor.

Light clients are an essential part of blockchains. In their current form, they enable the ability for less hardware-intensive machines to participate in the verification process of blockchains and also help facilitate connections to others. They do so by only downloading the block header instead of an entire block. They trust honest full nodes to provide accurate information and hence are not trustless. There are several types of light client implementations, and one could even say that the rollup bridge contracts on Ethereum function akin to how light clients function for IBC-connected blockchains in the Cosmos ecosystem.

Light clients notably came into the spotlight with the emergence of the Cosmos ecosystem, and have gained significant popularity in regard to the possibilities it allows for in respect to scaling functions of blockchains. Here we're referring to how Celestia is utilising light clients to participate in data availability sampling to scale with the number of nodes in the network. This would allow light clients to have almost similar trust assumptions as full nodes while still not being required to download the entire block. This results in light clients, and consequently end-users, becoming first-class citizens of the networks they inhabit.

In most primordial monolithic blockchains, users are required to run a full node, where they'd have to store the entirety of the blockchain data if they'd like to participate in verification. This puts a hurdle on decentralization since as the scale and history of the blockchain grows, so increases the hardware requirements for full nodes. This problem is often referred to as state bloat. With light clients, as long as they're connected to an honest full node they're able to participate by scanning block headers, instead of entire blocks as with full nodes. A block header is a section in a block that serves as a summary of the rest of the block - such as the time and difficulty of when the block was mined, and the root of included transactions. 

The information needed for light clients to verify a block in PoS chains

Light clients are used in bridging to facilitate the possibility for two bridging chains to verify the state of each other through the help of an off-chain relayer. By verifying each other's state machines the two connected chains are able to reach finality between each other on a protocol level. In the current setup of light clients, this does mean there is a certain level of trust involved, as just explained. In IBC the connection between chains is set up with a light client on each chain to verify the state of the chain.

The relayer builds transactions based on the state of the connected chains which are then submitted to the other nodes in the network. With IBC this is done via the Hermes relayer implementation. Some work is being done on the incentivisation of relayers to enable further decentralization and security. Currently, relayers are run manually and many are run by various validators that also run full nodes on connected chains, often enabling them to profit heavily from interchain MEV. There is ongoing relayer incentivization work to alleviate some of the issues this brings, which Polymer is also taking an active role in. 

Light Client Block Verification in Tendermint is as follows;

Simplified Light-Full Node Relationship

Keep in mind that this is a simplified picture of the relationship between a full node and a light client. In actuality, many nodes participate in the peer-to-peer network.

So, light clients are clearly a great invention, but how can we make them even greater? In Polymer's case, they're making use of ZK light clients, a new invention. ZK light clients will allow for increasing trust minimization and efficiency of transactions. By utilising ZK proofs it is possible to encode light client verification logic into circuits that will allow for making verification of batches of block headers more efficient. We covered block headers briefly earlier on, but something important to note is that also present in block headers are the previous block(s)’s hashes, which is what allows us to create the “chain” of blocks. In essence, the block header contains any data that isn’t the list of raw metadata itself.

A great example of the efficiency of light clients is that assuming your blockchain had 10.000 1MB blocks, you would be consuming 10GB of space on each full node (for the simplicity of the example, we are leaving out techniques such as data pruning etc). However, by just using block headers for those same blocks, you'd take up an order of magnitude less space. This is further increased by utilising ZK proofs, and their recursive nature. What's vital is that they allow for devices with less resources to perform validation and for blockchains that support light clients to read the state of another. 

With recursive zk proofs, it is possible to increase the efficiency of the relay process and use even less space. Recursive zk proofs are when you take multiple proofs that are then aggregated into a single proof. The single proof is only valid if all inherent proofs are valid, and it is much easier to verify and less costly. This is especially appealing when proofs are verified on-chain. Thousands of proofs can be compressed into a single proof, saving enormous costs in the verification process. This is because a recursive zk proof proves the existence of a previous valid proof. Since the verification is a computation itself, it can be expressed in a circuit. A single proof on this computation/circuit certifies the validity of an inner proof, which may include another proof and so on and so forth.

Another reason for wanting recursive ZK snarks for on-chain verification, is that running a Tendermint “light client” on Ethereum is quite expensive, as you'll see throughout this article. Even if it is optimised, the actual cost of verification is expensive. If you were going to just verify Tendermint light client verification logic on Ethereum, it would even be possible to exceed the block gas limit. Recursively verifying ZKPs will allow for a much simpler on-chain verification process.

The reason for wanting recursive proofs to verify block headers is to generate several proofs in parallel and then recursively proof them together. This means that the usual cost of verifying a single block header of which there may only be a single cross-chain transaction can be recursively lowered in parallel. This also means that you now just verify the proof of validity on-chain instead of the entire block header. Similarly to how we achieve scalability with ZK-rollups.

Recursive ZK proving

The actual on-chain header verification will be happening under the secp256k1 elliptic curve parameters (for now, but there are other curves that are possible to use as well) with the ECDSA algorithm. secp256k1 was constructed in a systematic way which allows for especially efficient computation. As a result, it is often more than 30% faster than other curves if the implementation is sufficiently optimized. Secp256k1 curves are both used in Bitcoin and Ethereum. However, it is not the most SNARK friendly, and as such other curves will be researched as well.

Graph of secp256k1's elliptic curve - in reality, it will look like scattered points.

One thing to note is that the general calldata of all the transactions and their Merkle tree still need to be stored. We will get into how this can be made more efficient in the next section. If you're interested in reading a bit more into the reasoning behind the implementation of ZK light clients and IBC logic with ZK proofs in general, then I recommend that you head over and read the newly released Polymer article, which covers parts of these questions.

1. https://github.com/tendermint/tendermint/blob/v0.34.x/spec/core/data_structures.md

2. https://github.com/tendermint/tendermint/blob/v0.34.x/spec/light-client/verification/verification_002_draft.md

3. https://docs.rs/tendermint/0.23.7/tendermint/block/index.html

4. https://ipld.io/specs/codecs/dag-cosmos/tendermint_chain/

5. https://pkg.go.dev/github.com/tendermint/tendermint/light

6. https://www.researchgate.net/publication/344663049_A_Tendermint_Light_Client

7. https://medium.com/tendermint/everything-you-need-to-know-about-the-tendermint-light-client-f80d03856f98 

8. https://github.com/0xPolygonHermez/pil-stark/blob/main/circuits.bn128/stark_verifier.circom.ejs 

Verkle trees are a more efficient data structure for state commitments. The benefit here is that it allows you to have reduced proof sizes and verification costs on-chain for proofs. In general what Merkle/Verkle trees bring is the ability to make sure that the binding of data is identical down to the very last byte, which allows us to provide finality agreements to blockchain nodes. 

To understand how Verkle trees are different from Merkle trees, it is important to first understand the latter. Merkle and Verkle trees are quite similar in structure but have a few components that make them quite different as data structures for state commitments.

In a Tendermint/CosmosSDK structure, Merkle trees are used to share transaction data between nodes, in particular between full nodes and light nodes for the light node to verify a certain block. In this situation, the light node gets a commitment from the full node and gets the witness which enables the light client to construct the root in the block header.  

In Ethereum, Merkle trees are used in the Execution layer in which block headers consist of 3 roots of Merkle trees. These are the state root, the transaction root and the receipt root. 

There is also the Ethereum global state tree that updates over time, and as a result, also increases in size as time goes on. This is one of the reasons why Ethereum is also exploring the use of Verkle tress in future releases to minimize the amount of state that Ethereum full nodes are required to hold. This is what is referred to as statelessness (weak), which we will touch on a bit later on. This similarly also cements why light client compatibility is so vital for blockchains, and why Ethereum is also looking to add them in the future since it enables clients that have lesser hardware to be able to verify the blockchain itself. The state bloat issue is also why history expiry is needed with the added amount of calldata (transaction data) that is coming as a result of EIP-4844. In general, state bloat is a massive issue for blockchains if you're not interested or willing to increase the hardware requirements of nodes, as it hinders decentralisation. There are various ways to mitigate this, and one of them is Verkle trees. 

Let's take a look at how Merkle trees look on paper, which will then enable us to later see how they differ from Verkle trees.

Merkle Tree Implementation

The witnesses in Merkle trees have the size of lgxN(x-1). In a Merkle tree, the proof is the entire set of nodes in the tree that share a parent with nodes in the path down to the node being proven. This means that you have to include a lot of nodes in the witness that will allow you to prove a commitment. This of course grows exponentially in very big trees since the top of the tree that you need to prove would grow very large as well. 

The main difference between Merkle and Verkle trees lies in how they structure their witnesses and as a result their sizes. Before we look at the structure of Verkle Trees, let us detail how witnesses work in them. First off, what's important to note is that to all positives, there are tradeoffs. In the case of Verkle trees, by moving to a witness size of lgxN(2) you lose on compute efficiency. However, it enables us to reduce the proof size and as such also lowers the verification cost on-chain for proofs. This is especially vital if you're trying to bridge to and from Ethereum, where gas cost, for now, is quite high. A great example of just how expensive on-chain proofs are for bridging on Ethereum, take a look at the test calculations that Electron Labs did for their "ZK IBC" idea. To lower cost, verkle trees and recursive proofs can help immensely alongside many of the other scalability solutions in the works for Ethereum as a whole. 

In Verkle trees, instead of needing to provide all the nodes that share a parent, you instead only have to provide the path to the root. So in a very wide tree, the path will be quite small compared to all the sister nodes (witnesses) that would have to be provided in a Merkle tree commitment. Another added commitment that is needed alongside the path in Verkle trees is vector commitments (polynomial, which can create a proof for any point, refer back to the curves further up if you want a refresher on points), which replaces the functionality of the sister nodes in Merkle trees. This means that they give verification that a certain child node (the node under the parent) is actually the correct node in the tree, while only providing the path itself. 

Simple Verkle Tree Implementation

No sister nodes are required in proof construction in the tree. You just give the path itself plus a few short proofs to link each commitment in the path to the next.

If you're interested in learning exactly how the Verkle trees are constructed in Polymer, then we highly recommend that you check out their brilliant presentation on the internals of Verkle trees presented in a visual way - link. In the beginning, Polymer won't be using Verkle trees. However, in the future as a result of state bloat and proof verification pricing, it makes sense to make the switch. As such, Polymer is preparing for the future.

Beyond the basic functionality of Verkle trees and polynomial commitments, we can add even further optimisations that can allow for a myriad of other incredible future implementations. Let's cover them briefly: 

These optimisations come through properties that polynomial commitments enable. Primarily the ability to make fixed-size proofs that link the nodes in the path for any length or path. This is done through a deterministic source of randomness for non-interactive proofs via Fiat Shamir Heuristics(FSH). FSH enables us to implement multiproofs through random evaluation.  This is also where the trade-off between Merkle and Verkle trees comes in - the proof generation of computing a polynomial. This single polynomial proof can then act to prove the correct path(s).

Efficient Verkle Tree Implementation

If you're interested in digging deeper into how single efficient multiproofs are achieved we highly recommend you check out the great Dankrad's article on them.

The implementation of Verkle trees is going to allow for some quite unique and interesting functionalities that can aid in both the scalability and decentralization of blockchains. Let's take a look at statelessness in particular and also touch slightly on another method, namely state rent. Both of these are methods to alleviate the state bloat that all blockchains suffer from. As Vitalik notes in "a state expiry and statelessness roadmap" from around a year ago "The Ethereum state size is growing quickly. It is currently around 35 GB for just the state and over 100 GB including all Merkle proofs, and is increasing by roughly half that amount per year." 

Statelessness or weak statelessness is the concept of only requiring block proposers to store state, and then having other nodes in the network verify the block without having to hold and store the state of the blockchain. This is something that requires Verkle trees and multiproofs, which will enable clients to verify the global state, without actually holding any state themselves. Another added feature that is planned to be added alongside weak statelessness on Ethereum is state expiry, which we touched on earlier. With state expiry, the state still needs to go somewhere. This could either be on archival nodes, or we could also utilise a method referred to as state rent. 

State rent is the concept of "renting" out state to be stored and having proof of accessibility of it on other chains or within specific nodes on the chain itself. There are various projects working on solutions that could allow for this, for example, Laconic, but the way Polymer is structured you could also envision a world where Polymer is used for state rent as well. There is also a method for which you could disperse state with provable retrievability. Joachim Neu presented a very interesting paper on this during the Modular Summit, which we enjoyed co-hosting with Celestia. If you want to learn more, you can read the paper [here].

1. https://docs.google.com/presentation/d/1IZqyFgb6VwLBxieR0_wUFdzmAIC_ZAMicbKWL0fidMg/edit#slide=id.g119a168c71b_0_122 

2. https://docs.google.com/presentation/d/1zv26gsBiU-xsepXnrpmcBIFVP49QN9jvbbcI_AZKssA/edit?pli=1 

3. https://vitalik.ca/general/2021/06/18/verkle.html

4. https://notes.ethereum.org/@vbuterin/verkle_tree_eip 

5. https://nethermind.io/verkle-trees/

6. https://github.com/o1-labs/verkle-tree

7. https://dankradfeist.de/ethereum/2021/06/18/verkle-trie-for-eth1.html

8. https://github.com/lunfardo314/verkle

9. https://ethereum-magicians.org/t/proposed-verkle-tree-scheme-for-ethereum-state/5805

10. https://beamstart.com/news/merkle-trees-vs-verkle-trees-16609184619683

11. https://eprint.iacr.org/2021/599.pdf 

12. https://github.com/polymerdao/go-verkle 

13. https://hackmd.io/@vbuterin/state_size_management 

Something that has been researched by several teams lately is how to bring IBC to Ethereum before it adds light client compatibility. For example, Electron Labs has presented a "version" of IBC where they have a smart contract on Ethereum act as an on-chain light client (which IBC requires). This is similar to how bridge/rollup contracts work for Ethereum rollups. However, the problem with this is that you're essentially trusting a smart contract (which is often upgradeable or controlled by a centralized team) which obviously doesn't allow for trust-minimized bridging on a protocol level where the trust lies in the two validator sets of the two chains connected. The beauty of IBC on Tendermint/CosmosSDK chains is that they have light client support built in and that it enables chains to agree on a protocol level to open up a connection between them in a trust-minimized way. For now Electron Labs only have a circuit for ed25519 signature verification and not the actual light client logic. To enable the smart contract to act as a light client with IBC logic, they would need to make other necessary changes.

So how is Polymer planning on providing IBC in the Ethereum ecosystem, incl. rollups. Let's dig into Polymer's GitHub to look at the work they've done so far. 

Currently, the best way to implement IBC in a way, so that it functions on Ethereum, is to implement a ZK-IBC structure. Here validity proofs are verified on-chain proving the validity of a transaction that has been done on a connected chain. As mentioned earlier, Electron Labs have a great blog post on how this can be achieved as well, but there are a few things that I do feel are important to note. The IBC modules need to be converted to solidity so that IBC transactions can be verified properly + we also need a solidity verifier for Plonky2 (which is currently the fastest proving system for recursive snarks - which is one of the things we need for an efficient implementation of zkIBC). If you're interested in following along with the development of the Plonky2 verifier that Polymer is doing, I highly recommend you check their GitHub

Presently, Polymer has already created smart contracts on devnets that acts as on-chain light clients for both Ethereum and BSC. This enables the smart contracts to receive IBC packets since they have rewritten the IBC modules in Solidity. Likewise, Polymer has also done testing for a variety of other EVM-compatible chains such as Binance, Avalanche, Fantom, Polygon and also Solana.

1. https://github.com/polymerdao/plonky2-solidity-verifier 

2. https://ethresear.ch/t/bringing-ibc-to-ethereum-using-zk-snarks/13634

In addition to standard IBC, Polymer will also feature a by-product called end-to-end IBC. This is an excellent fit for the way we view the modular world taking shape, as connected chains are considered to be "rollups” in this product. E2E IBCs are remote VMs that allow for native IBC and light client support. E2E IBC can be adopted by all chains, both application-specific, other L1s, L2s and various execution environments.

What this means is that connected chains can have their own “rollup” that works as a remote VM in which there is light client support and native IBC connections. As such, chains that usually aren't able to utilise light clients can have an environment where they can connect and use IBC logic, without actually implementing the modules themselves.

These remote VMs will interact via Polymer through interchain account smart contract APIs on Polymer itself. Through this, they're decoupling the networking layer that chains usually rely on, and instead allow the remote VMs to operate as an extension of Polymer itself that supports native IBC connections. This means that Polymer is able to maintain an IBC connection on behalf of connected chains.

the remote VMs would be living on Non-IBC chains to enable IBC logic.

The state of the E2E IBCs is going to be verified on Polymer, as is usual with rollups through light clients, which CosmosSDK and Tendermint support. On the Polymer side, there will exist IBC smart contracts (also sometimes referred to as bridge contracts on Ethereum). These will handle movement from Polymer to the non-IBC chain. The native light client support means that trust minimization can easily be achieved.

Polymer will also feature what they call xApps, which will function as multichain applications in rollup form on top of Polymer. This will give them immediate access to a wide variety of chains on which to settle and handle transactions.

Preface 

The past few months have shown that certain implementations of algorithmic stablecoins with various percentages of backing aren’t scalable. Because of this, we’re extremely happy to be supporters of Gyroscope - a dynamic stablecoin protocol that is fully collateralized and decentralized. We believe that they are building out a protocol with extreme fortitude that can persistently support a decentralized stablecoin through a wide range of eclectic events. In addition, we are convinced that decentralised stablecoins are one of the best use cases of crypto. We first met the Gyroscope team in January 2021, after reading their research papers online. After extensive back and forth we are proud to have partnered with them on building out the Gyroscope project from the earliest days and into the future.

To understand how Gyroscope is trying to revolutionize the way stablecoins currently function, it’s important to first take an in-depth look at how stablecoins have progressed over the years and what sets them apart from each other. First, let’s start with the history of stablecoins and then move down to the various types of stablecoins that exist and some of the death spirals that can arise.

First off, let’s establish what a stablecoin is. A stablecoin is a cryptocurrency that is supposed to remain stable in value against a pegged external asset (usually USD). It should aim to minimize price volatility (in relative terms to the value of USD), either through full collateralization or other methods. The purpose of stablecoins is usually to negate the speculative nature of crypto and create a market for USD/Token markets on DEXs. 

The history of on-chain stablecoins started on a hot summer day in June 2014, when the first on-chain stablecoin was released — bitUSD on the BitShares blockchain. Suppose you’re familiar with the olden days. In that case, you might remember some of the people that were behind BitShares, such as Daniel Larimer of EOS fame and Charles Hoskinson, the champion fast eater.

So how did BitUSD work? Well, it actually worked in a similar way to some of the “algo” stablecoins of recent years, let me explain. 

One could redeem and mint BitUSD, however, the price of this transfer was determined by the BitUSD vs BitShares price in a distributed exchange, which is not linked to actual green American dollars. As such the price references itself and tries to fix its peg on the basis of arbitrage. The only argument of why BitUSD should trade at $1 is thus “why would it be anything else, it’s a stablecoin?” — Which is very much the same reason as with the UST debacle. 

In this situation, should the value of the collateral currency (in this case Bitshares) fall, any BitUSD holder could redeem and gain $1 worth of BitShares. However, this assumes that the market price of BitUSD is still worth $1 and there are sufficient Bitshares in collateral. So, not quite the same as LUNA/UST (Where UST was always redeemable for $1 of LUNA). Regardless, the same issues that UST was presented with, also existed way before that, even back in 2014. And if you’re wondering how the story of BitUSD and NuBits turned out — well you can check the charts, it will show a very similar story to the Luna debacle.

One of the earliest stablecoins, that even to this day has kept its peg is USDT (Tether). It came to the market in 2015 via Bitfinex. USDT is an off-chain collateralized on-chain stablecoin, backed by real assets and to this day is the most popular stablecoin in existence (MKT cap at ~$67.5B). Tether has seen various events and has had controversies around it since its inception. However, despite all of that, it has managed to keep its peg and become one of the go-to stables alongside USDC, for people seeking to offload risk.

While Tether has been useful in solving liquidity issues, it brings a key fundamental issue that blockchain was intended to solve into the space: centralisation. DAI was created to solve this centralisation issue (although it is still relatively centralised). However, it brought its own unique problem — namely, during contractionary (and sometimes expansive) market events (i.e., market volatility), DAI could lose its peg to the $USD when the collateral which backs DAI (principally ETH) was liquidated. As a result, DAI is currently backed by around ˜75% USDC and is therefore almost a decentralized derivative of USDC itself, backed by some volatile assets such as ETH. 

Tantamount to algorithmic and essentially unbacked stables, TerraUSD’s algorithmically pegged stablecoin was a design that allowed for dynamic adjustments to market forces in real-time like the ones used in BitShares with some changes, eventually leading to its downfall. 

So let's summarise the type of stablecoins that are currently in existence and input them into a diagram to see their differences. 

1. Collateralized off-chain

Under this section lies the two most popular stables, namely USDC and USDT which have a combined market cap of ~$119B. These are backed by real-world collateral held by a central entity, and in some cases frequently verified by external auditors. Keep in mind that in most cases these types of stables are often backed by both fiat and commodities among other trad-fi instruments.

2. Collateralized on-chain (+stables backed by yield generating assets)

These are stables that are backed by other on-chain cryptocurrencies and in some cases even backed partly by off-chain collateralized stables, such as with DAI. The peg is executed on-chain via smart contracts and is at the mercy of arbitragers to keep the peg safe, and for watchers/searchers to liquidate collateral when it reaches liquidation. Some of the collateralized on-chain stables are also backed by yield-generating assets, such as in the case of MIM and YUSD.

3. Non-collateralized/Algorithmic

This is usually referred to as seigniorage style stables, which use algorithms to control the money supply of the stablecoin, often through an asset held by the entity issuing the stable itself. You can compare this type of stable to a central bank printing and destroying the currency, but on a global decentralized scale. In most cases, there is no collateral (unless raised to back the peg, as with Luna’s or Tron’s reserves) and the peg is defended by mints/burns made on-chain via arbitrage hunters through a system that in Luna’s case had an internal asset be the primary risk absorber, which in a death spiral event led to the hyperinflation of said asset.

To give a better overview of where the various stablecoins land in regards to their risk absorption and primary value let’s plot them into a table.

External: Exonegous assets, Internal: Endogenous Assets

This makes it very clear that there’s a large variety of stablecoins currently on the market, with the primary ones being USDT/USDC which are both backed by a central entity. The only decentralized stable that’s somewhat close, albeit one order of magnitude smaller, is DAI, which has a market cap of around ~$6.4B. MakerDAO has recently had discussions about moving away from a principal backing of USDC towards more decentralized assets, such as ETH, which certainly makes for an exciting development. UST was the only decentralized stable, that was getting close to the market caps of the two large centralized ones. However, that was not to last. 

The problem with many of the fallen stablecoins over the years is the fact that when investor panic occurs, which can be caused by varying events in the market, it causes a “death spiral” and the stablecoin loses its peg and with it the trust that it had.

Another great example of such an event is the fall of Basis Cash which at its peak had a meagre market cap of $30m. Basis Cash also utilised a seigniorage algorithm, as previously mentioned. In which there exists a stablecoin and a token that enforces the peg in the form of minting and burning - through arbitrage. There exist other examples, some of which tried to enforce a partial crypto-collateralized scheme, such as in the last months of UST. However, when the token enforcing the peg becomes overvalued and unable to enforce the ever-growing market capitalization of the stablecoin, it eventually leads to a death spiral such as with Luna and Iron.

Another major part of keeping the peg of a stablecoin is trust. A great example here is USDD by Tron. USDD is technically overcollateralized by the BTC and USDC/T held in reserve, however, it is permissioned and fully based on the belief that it will be used to uphold the peg. As of writing this, USDD is trading at 0.98(July), which clearly shows a distrust in the way the system is operating and the inability for the general public to participate in arbitrage.

Now that we have covered the history of stables, both successful ones and fallen ones, let's turn our eyes towards possible events that can impact a stables price ‘positively’, as in asset appreciation, and then we’ll move onwards to Gyroscope itself.

Deleveraging spirals are one of the ways that can lead to a stablecoin price appreciating, rather than keeping its peg as a result of arbitrage. This can happen during times of collateral shock and lead to faster collateral drawn.

In liquidations, collateral is used to reduce supply. Stablecoin price rises in response to an imbalance in demand and amplifies the effect

When speculator liquidations begin to occur, as with for example DAI where it’s automated by the protocol or in a situation where voluntary deleveraging happens — collateral is used to repurchase the stablecoin to reduce the supply. If you’re interested in the exact way deleveraging spirals function and happen, you should check out Ariah’s work in this paper. 

In elastic markets, this can have an adverse effect as it causes an imbalance in demand relative to supply. To combat the reduced demand, an increase in the stablecoins price is needed to reduce demand. This can further amplify the problem. In a situation where continual liquidations occur, more collateral is then needed to reduce supply by a similar amount to earlier because of the increased price of the stablecoin, and so on and so forth. 

The speculator of the protocol will then most likely desire to increase collateralization when the expected liquidation cost is higher after a shock has hit the collateral value or if an expectation of volatility is anticipated. As such, the collateralization of DAI is exceptionally high. Often ranging between 2.5x to 5x, even though the collateral factor is actually 1.5x

Now that we have established the history of stables, the current market of existing stables and how a deleveraging spiral can occur, let’s dig deep down and understand how Gyroscope is trying to change the spectrum.

Gyroscope at its core is a protocol that allows for the minting of a meta-stablecoin. A meta-stablecoin is a stable that is composed of a basket of other assets, such as other stables, yield generating instruments or volatile assets. The basket of assets can then be used to acquire further yield. 

Gyroscope is unique in the sense that it is both collateralized and also has distinct defence mechanisms to restore the peg in the event of price downturns in currencies held in reserve. This is done through a method that is quite similar to the way ships work. For example, if there’s a hole in a ship, and a section of the ship gets flooded, the ship won’t sink. Why is that? Well, in most larger ships you have sections that can be blocked off in the case of flooding in one section. You can therefore limit the damage and spread of flooding by creating sections that can be blocked off. In the same vein, the stratified reserve of Gyroscope works similarly, let’s try to explain it with imagery. 

The section approach to diversifying risk is similar to how a ship diversifies its chances of flooding

Gyroscope is for all intents and purposes a fully-backed stablecoin since it aims to have a long-term reserve ratio of 100%. However, it has some more unique functionalities on top of that, which we’ll cover here. It has all-weather reserves and autonomous price bounding, to make sure that the price is as stable as possible. So what is an all-weather reserve? An all-weather reserve in this case is a basket of assets that collateralizes gyro. In the beginning, most of these will be other stablecoins, however, the reserve will eventually move to add other tokens too. When those are added, the reserve will diversify risks, to account for all possible events. Autonomous price bounding is when the prices for minting and redeeming stablecoins are set autonomously so that it balances the goal of a tight peg to exactly the USD. This is especially important during crises. We’ll go more in-depth with this shortly.

Arbitrage loop

Gyroscope, like basically any other stablecoin, has what we call an arbitrage loop. In Gyroscope's case, this is permissionless, unlike most centralized stablecoins. This is because the stablecoin itself is mintable with $1 worth of assets. When the price rises above peg, for example, more stablecoins can be minted and then sold on the market with proceeds. These proceeds can go to growing the reserve behind Gyro as well.

This also works the other way around. When there’s a drop in the stablecoin’s price, they can be bought on the market, and then redeemed for $1 worth of reserve assets. The arbitrage loop coupled with the all-weather reserve is the first line of defence in regards to keeping the peg of Gyro stable. This is something that has to happen permissionless, otherwise, the peg will never be arbitraged, just take one look at USDD. Furthermore, the peg cannot be restored purely with endogenous assets but has to be backed by exogenous assets too, hence the all-weather reserve of Gyroscope. In case of larger events and shocks to the reserve, more lines of defence exist to keep the peg and ensure stability. We’ll cover some more underneath.

Stratified Reserve

As mentioned earlier there are several lines of defence when it comes to keeping the peg of a stablecoin stable. The first one is the one described before, the stratified reserve that stores all issuance proceeds and diversifies risks in DeFi. The goal of this reserve is to keep a full collateralization ratio at all times. In the beginning, this will primarily be composed of stablecoins, but as sketched out in the ship painting, it will eventually hold other assets too. These assets would start fully backed, but in the case of the underlying asset dropping in value, then the represented asset would be under-backed. However, when there exist leveraged loans in the system, then those would be over-collateralized. Those would be built on top of Gyro.

These vaults exist to provide contained risks and should have as little overlap between each other as possible. This means that in the event of a failure of a vault, it won’t overflow to the other vaults. Even in the event of a vault failing, the system will still remain stable through the autonomous price bounding, which is backed by unaffected reserves. These reserves also serve to gain yield on assets, which eventually will lead to the reserve recovering back to its original strength. 

This can also be explained in the form of triangles holding a plank, let’s draw out an example:

As seen, even in the case of a triangle defaulting, the plank will still be held up by the remaining vaults/triangles.

The reason for this is to isolate risk as much as possible so that if a problem occurs it won’t cascade into other vaults. This means that the reserve of Gyroscope is separated into vaults (the triangles) that help contain risks. Such that if there’s a failure or cascade in one of the vaults, it won’t contaminate the rest. If a vault fails, then the dynamic price bounding which is backed by the rest of the reserve kicks in to help keep the peg.

Further Measures

The second line of defence is the one I just mentioned, dynamic pricing. In the event that a stablecoin unit turns undercollateralized, the bonding curve of the redemption market will then start decreasing redemption quotes. This means that it acts as a circuit breaker to maintain stability. This mechanism most likely won’t be used very often, unless in the case of extreme market events. Although, it’s important to secure the stability of the protocol in any situation, and thus Gyroscope aims to maintain stability in any event.

The reason for decreasing redemption quotes is to have it work as a deterrent to bank runs and attacks on the peg. In the same vein, it rewards users who wait out downturns in the market. Although, it is important to remember that while holders can still exit their stable position, there are now reasons to “bet” on the return of the peg to the targeted price. In due time as the redemption price autonomously works to recover towards peg, outflows will turn towards zero or through the reserve recovering through yield.

There also exist other stability mechanisms that can help stabilize the peg. One of them is because Gyro works similar to the way Maker’s Peg Stability Module operates. However, it does have some different functionalities. While Gyroscope allows for the exchange of its stable with $1 worth of assets, it does also allow for the ability to diversify risks in the reserve backing the stable. Furthermore, in the long term, it won’t be primarily backed by custodial stablecoins (such as the 70% USDC backing DAI). It also allows for the ability to flexibly survive depeg events, even in the event of a fluctuating reserve. 

This is through a leveraged loan mechanism that kicks in, in the event of the reserve becoming under-collateralized. If the price of the stable falls under the peg significantly (during a market crash for example), then leverage loan holders will be able to deleverage their positions at a discount. This will reduce the supply of the stable and help the price of the stable return towards $1 (This is quite similar to the way MIM operates — MIM always assumes 1MIM is $1, even if the price falls under the peg, and allows for the ability to redeem $1 of assets for 1MIM).

The Last Resorts

Last resort is used only when all else has failed. The way last resorts works on Gyroscope is that the reserve can also be recapitalized through the auctioning of governance tokens or the promise of future protocol-derived income from the reserve or trading fees. This is quite similar to the way Maker’s backstop works and is only supposed to only happen in the event of last resort during a difficult crisis, through governance. In the same vein, while the prices are good and the valuation of the governance token is high, governance of the protocol is also incentivized to auction off tokens early on to boost the reserve for darker times. This is similar to the way Frax operates by utilising FXS to control the peg in harsh market conditions. However, unlike with the FRAX/FXS mechanisms, this is a tertiary line of defense in Gyroscope, not a 1st line of defense as with Frax. 

Oracle Feeds

The way Gyro’s oracle feeds work is quite different from other protocols. They rely on several on-chain consistency checks as well as circuit breakers and manipulation-resistant methods for pricing LP and shares of the vaults. Here of particular importance, are the Consolidated Price Feeds. Correct price feeds are extremely important when the stablecoin is being used in DeFi. A great example is, that during the UST fiasco several protocols were exploited as their oracle provided the wrong information on the price of UST. This consequently allowed exploiters to seize advantage of incorrect prices to take out huge loans. The same goes for the latest Inverse Finance exploit, which also made use of bad oracles. The exploiters manipulated the price of a single oracle, which fed info to the protocol.

Layered Price Feeds are when you get on-chain references from AMMs and then ground the price received from AMMs by cross-referencing it with several oracles. 

Consolidated Price Feeds

Therefore by layering prices from various sources you can easily detect discrepancies and issues on-chain. This also means that manipulating the prices would take a huge amount of capital across several platforms to have an effect. If a discrepancy is detected the system can stop trading and wait for the issue to be resolved. Most projects usually just rely on a single oracle provider for their price feeds, this is much more exploitable. 

Dynamic pricing and beyond

Before we continue onwards to the unique governance mechanics of Gyroscope let’s dig a bit deeper into the dynamic pricing modules of Gyroscope and what they can enable for the protocol.

Gyroscope makes use of two unique and different automated market mechanisms. The first one is the Dynamic Stability Mechanism (DSM), which works to quote the minting and redeeming prices of stables while accounting for shocks to the assets that back the stable. 

The second pricing module is the Concentrated Liquidity Pools (CLPs) that help to concentrate liquidity within particular pricing bounds through customized Balancer v2 pools. This is done through a partnership with Balancer, which will allow for the logic needed for the customized AMMs.    

The CLPs concentrate liquidity where needed according to the information that is given by the DSM for the stablecoin pairs backed by Gyroscope’s reserve assets. CLPs are like Uniswap v3 but on Balancer and specialized to the most-traded range. This means that there will also be liquid paths both in and out of stablecoins from Gyro. Furthermore, the CLPs are independent, which means that just as with the stratified reserve any failures won’t affect the rest. 

These pricing modules enable some rather unique designs when it comes to building things beyond the basic mechanics of the Gyroscope protocol. It enables building a DEX that can withstand asset failures through the Gyroscope design, something that Osmosis could have made use of quite efficiently during the UST fiasco. 

The design allows for secondary markets to act as AMMs, Reserve Pools and so on, which can route trades as efficiently as possible. In essence, the various pools would look something like this from a birds-eye perspective.

The Connections to Gyro’s E-CLP from various sources, both reserve and outside pools

Once Gyroscope has accumulated a strong enough reserve with the widespread acceptance of the stablecoin itself, it will in any market situation be stable at $1. During extreme events, it’s possible that the peg could vary, however, the system by design is made so that such an event is extremely unlikely. Even in the event of a short-term depeg, the stratified reserve and yield mechanisms will aid the stable in the recovery to its peg.

Gyroscope is also trying to innovate on the governance front by implementing a new governance system called Optimistic Approval. Optimistic Approval aims to help align the governors of the protocol with the long-term interest of the protocol itself. So instead of being focused on the short-term and rapid ideas and concepts, the governance of Gyroscope will help to tie the best interest of the protocol together with the governors.

So this is all fine and dandy, but how can we make sure that the governors can’t abuse their power in other ways? This is especially pivotal, when you look at the last few months and how some of the governance proposals taken by Solend and Juno have turned out. 

Optimistic Approval

Optimistic Approval is a new form of governance proposed by the Gyroscope team that incorporates a veto mechanism into the governance of the protocol. Which is invokable by other parties in the system like vaults, stablecoin holders and so on, in the event of malicious governance proposals (something that I’m sure SOL holders wish they would have had during the Solend proposal). 

The reason for the adding of a veto is that it lowers the success probability of a governance-based attack, since if the malicious attackers are expecting a veto to be put in place, then the chances of this attack happening, to begin with, are already lowered by a wide margin.

Optimistic Approval relies heavily on the concept of timelocks and is indeed derived from it. Optimistic Approval enables proposals to be quickly passed unless a veto is initiated by some party. These parties could be members of the community at large, so not necessarily governance token holders, but rather other players that use the protocol such as a vault or stablecoin holder like DAI holders, LPs etc. If a situation arises where the minimum required number of users initiates a proposal veto, then the original timelock duration is then increased to enable more users to voice their opinion via voting for or against it. This means that unlike the majority of other protocols, Gyroscope is able to ship updates rather frequently, while still giving the wider community a chance to partake in the governance of the protocol.

The two major reasons for the implementation of optimistic approval are that it enables recourse. Let’s say that a malicious upgrade is being passed in a timelock-based protocol's governance forum, it will lead to the holders running for the exits. However, the chance of vetoing leaves actions on the table for the community. 

Likewise, it also acts as a fail-safe of the protocol. In the event of another malicious proposal, an absentee user doesn’t need to worry about losing funds (cough Solend), since only a small number of users are required to increase the timelock and keep the protocol safe.

However, there’s obviously one contrarian view on the concept of optimistic approval and that is determining what “the wider community” entails when it comes to being allowed veto powers to extend the timelock. Does this apply to holders of debt positions on protocols like Maker which allows for the minting of DAI, or should it lie in with the holders of DAI or MKR itself? There’s also the possibility of a wider community member wanting to fight against a proposal being implemented quickly and extending the timelock through vetoing. One thing that's very important to remember is, that there are many vital voices beyond large token holders, and basic token-based voting mechanisms might not incorporate them. Optimistic Approval helps alleviate some of these issues with current governance in crypto protocols, and it would be great to see more protocols utilise a similar scheme. 

Here’s how a timelock could look from a protocol using a traditional governance method, and how an Optimistic Approval-based timelock works on Gyroscope. 

Trad. Timelock-based governance proposal vs Optimistic Approval based proposal

This means that Optimistic Approval gives users and token holders of the protocol the ability to veto changes that they disagree with, as long as they meet a certain quorum. As such the stability of the protocol is ensured, since it adds checks and balances on the power of those who hold the governance token, ensuring that no malicious crypto-economic attacks are carried out by actors acting against the long-term interest of the protocol. This should of course always tie into the concept of allowing governors of the protocol to earn sufficient profit or other positives so that it outweighs the expected proceeds from a possible crypto-economic attack on the system itself. 

Stablecoins are incredibly important for the wider crypto ecosystem since they allow for the linking of the traditional financial world and the decentralized world of crypto. It furthermore enables the ability to have USD-Token pairs on DEXs, which is also something that’s very vital. In risk-off periods to which crypto is very prone, the ability to seek shelter in safe and uncompromising stablecoins is also vital for the health of the ecosystem. 

Stablecoins are also a vital key to unlocking global transactions that can’t rely on volatile assets. The nature of blockchains means that these transactions can be enabled with extremely low transaction fees and fast settlement.

Furthermore, we have seen an increased interest in having stablecoins used for cross-border payments and remittances from traditional finance players such as JP Morgan and Wells Fargo. This means that we could see a possible future where stablecoins are used to cut out intermediary financial institutions and enable truly global payments. However, if such a future is to exist it needs to be with a governance mechanism that is aligned with the long-term health of the protocol, as with Gyroscope.

The scalability of the stablecoin is also extremely important. We saw how UST and many other stablecoins outgrew their internal risk absorption mechanisms, which eventually led to their downfall. With the stratified reserve of Gyroscope, we are no longer constrained by a single system and can rather grow stablecoins as DeFi itself evolves. 

For an “algo” stable to truly succeed it needs four major functionalities

1. Acceleration — The ability to scale fast and still be resistant to major market shocks

2. Solvency — Trust and confidence in the backing of the stablecoin

3. Liquidity — Major liquidity flows and pairs to enable large swaps and easy transfers.

4. Exogenously secured with endogenous protocol profitability

The Four Pillars of Importance for stablecoins

It is also of absolute importance that the backing of the stablecoin is majorly exogenous, we’ve seen how a primary endogenous backing can have extremely negative effects during market shocks.

We believe that Gyroscope has the ability to solve these four major hurdles and we’re extremely excited to see where the future of Gyroscope takes us.

https://arxiv.org/pdf/2006.12388.pdf

https://arxiv.org/pdf/2109.08939.pdf

https://arxiv.org/pdf/2004.01304.pdf

Docs.gyro.finance

https://medium.com/gyroscope-protocol/gyroscope-a-new-crypto-native-self-stabilizing-money-22d111b76aab

Before we dive into the thesis itself, it’s very important that we’re on the same page, and as such, we’ll briefly be covering some of the various technical aspects that make the Cosmos ecosystem unique in an easily digestible way.

The overall architecture in Tendermint-based chains that use ABCI and the Cosmos SDK looks like this:

The Cosmos SDK is a set of modular tools that allow blockchain developers to build their application layer logic in a VM agnostic manner. The Cosmos SDK is designed to connect to Tendermint through ABCI. Beyond being the framework that allows for creating application-specific blockchains, it also allows for various customization options such as protocol-agnostic governance, transaction and staking mechanisms and much more. The SDK handles most of the tasks that are required on the application logic layer which means that developers aren’t required to build things completely from scratch. It handles transactions received from the Tendermint consensus engine via a router that sends messages to the appropriate processing modules alongside the state changes.

ABCI is the interface that connects the application part of the blockchain to the Tendermint state replication engine which provides the consensus and networking mechanisms. ABCI enables the splitting up of the blockchain stack, which means the application part of the blockchain can be virtual machine agnostic, and as such, any virtual machine and execution environment can be used for the application part of the stack. Examples of this are Junowasm, Cosmwasm, Agoric’s Hardened Javascript and even Secret’s version of Cosmwasm which allows for the usage of TEE. Tendermint itself creates three ABCI connections to the application part. These are the validation of transactions when broadcasted in the mempool, the connection between the application and the consensus engine for block proposals and the ability to query the application’s state.

The functionality of ABCI

Tendermint Core is what takes care of the consensus and network layer of chains in the Cosmos ecosystem. The consensus layer is what guarantees the validity and order of transactions through a consensus algorithm process between network participants, in Tendermint’s case - validators in a proof of stake setting. The network layer is responsible for facilitating peer-to-peer communications between nodes in the system and enabling third-party applications and nodes to interact with the consensus layer.

Tendermint uses a byzantine fault tolerant (BFT) consensus model and enables instant finality. The BFT process goes through three phases before the final commitment phase of the proposed blocks. These are the propose phase where a block is specified at a specific height, the prevote phase where 2/3rds of validators prevote for a proposed block and the pre-commit step where 2/3rds of validators pre-commit for the proposed block.

Tendermints’ BFT Process (Timeout: Small wait time to receive a proposal, or establish skip)

Inter-Blockchain Communication(IBC) is at its core a cross-chain messaging protocol for homogenous blockchains. This means that it connects chains that share similar functionalities, in this case, instant finality provided by the Tendermint consensus algorithm and ones that have light client functionality. The way IBC works is that two chains that are interested in having a connection with one another will put up a governance proposal on the destination chain. This is usually, to begin with, either through the Cosmos Hub or Osmosis (Currently Osmosis has 45 peers, and Cosmos 40). This means that there’s an agreement on a protocol level, and as such, there is no need for a trusted third party in an external bridge.

These two chains then require a light client on each other’s chain to cryptographically verify consensus state between the two chains, as well as a relayer to relay information between the light clients on the two chains. The relayers are required for liveness - the ability to be able to exchange messages among nodes, with the nodes successfully coming to a consensus. Let’s explore how this looks in practice:

This means that the trust assumption lies within the two validator sets of the connected blockchains, as such there are much fewer trust assumptions than other types of bridges and messaging protocols. For example, with XCMP in the Polkadot ecosystem, the trust assumption lies solely with the relay chain (Polkadot).

To show just how compatible and widespread IBC has become in the Cosmos ecosystem, and how many chains it connects - let’s take a look at a map of the current live connections.

Source: mapofzones.com

ICS stands for Interchain Standard and sets parameters for transactions happening between chains using IBC. ICSs are basically module specifications for IBC transactions. For two chains two communicate using IBC they’re required to possess the same ICS specifications.

One of the more interesting and unique ICSs is ICS-27, also known as Interchain Accounts.

Interchain Accounts enable composability as opposed to interoperability. They allow for chains to exchange not only data but also write state from one smart contract on one chain to another. This means that instead of requiring a user to move across various interfaces as an asset or message moves, he or she will be able to utilise a single interface on the source chain, as long as the transaction’s endpoint is specified.

ICS-27-enabled chains create accounts on other ICS-27-enabled chains and are able to control these accounts via IBC transactions. Interchain accounts keep all of the abilities of a normal account but are instead operated by a separate chain or end-user through IBC such that the owner on the source chain maintains complete control over any interchain accounts it enlists on destination chains.

When initialising an Interchain Account transaction you make use of IBC to send a non-IBC transaction (non-IBC transactions within an IBC transaction) - An example often given to illustrate this, is the concept of "a letter inside of an envelope inside of a box”

Interchain Accounts Transactions

The procedure after the IBC transaction happens in accordance with the ICS specifications that each chain is required to possess. This means that it allows transactions to go from being application-specific to being application-agnostic, in other words - it enables true composability across a range of different networks.

Interchain Security allows a Chain or Hub to produce blocks for other chains. Validators run two(or more) nodes, one on each chain, but only have to stake their native token on the main chain. This is enabled by Cross Chain Validation, which is an IBC-level protocol. The child chain uses IBC to communicate with the main chain to keep track of which validators are participating in Interchain Security using Cross Chain Validation. In this way, the security gained from the value of the stake locked on the main chain is shared with the child chain. As such, the consumer/child chain receives security from the main chain and doesn’t have to spin up its own validator set. This enables less capital-heavy applications to easily bootstrap their own chain while retaining a strong level of security from an existing validator set.

The main chain is in charge of producing blocks for a set of child chains. The validators will receive staking rewards from the chain(s) they’re validating. Slashing works to facilitate that no validator behaves maliciously.

Application-specific blockchains enable what we’d like to call “warehousing” of blockspace. If you view a blockchain stack as a supply chain, then the blockspace on various parts of the stack are technically being “bought” by the application(s) on the chain/layer that it inhabits. This means that it pays for gas alongside a myriad of different applications all inhabiting the same blockspace, which causes it to be highly congested and competitive and as such drives fees up. This fee spike caused by the heavily congested monolithic chain inhabited by thousands of applications is then pushed onto the end-users, which have to bear the heavy cost. On an application-specific chain, the application itself is able to better control the fees that are paid by the end-user and give them the ability to keep it at a constant. A great example of this is Osmosis. It also allows for easier subsidising of fees for applications that want to remove spiking fee structures completely. For example, one application could subsidise the average fees for a certain time period without having to worry about fee spikes as a result of heavy congestion.

This means that the application owns its own warehousing instead of being reliant on renting out one pallet in a corner of one.

Warehousing of blockspace

As such applications don’t rely on x or y chain as a warehouse which would mean taking on the risk of average fees being loftier for the application, similar to how a store has inventory risk. This means the application itself and as an extension of this, its community, can participate in and carry out inventory risk management. This causes resource pricing efficiency which in turn leads to a better economic model for the application(s).

As a result of the application being the owner of the chain it inhabits it allows for self-governance of fee structures, which means you’re no longer at the whim of the chain that you inhabit, you decide what each resource on your chain costs.

Beyond this, the flexibility allowed by the underlying tech stack allows for optimisation on the application layer while retaining composability between chains in the wider ecosystem as a result of its native cross-chain messaging system. This composability doesn’t require trust assumptions with third parties but instead allows for the validator sets of the two chains communicating to be the trust assumption.

Before the prevalence of Cosmos, there was a clear divide between applications and infrastructure (chains), application-specific chains with IBC break down this barrier and allow applications to become connected and composable infrastructure.

Preface

Fuel is the most interesting execution environment we have come across and we are proud to be supporters of Fuel. Fuel situates itself as the fastest execution layer for the modular future, which is one that most blockchains now realise they have to move towards, to provide the scaling that is needed for global use. Furthermore, it takes full advantage of the flexibility modularity offers to developers by not replicating the EVM. In this article, we will cover the uniqueness of Fuel and how they’re trying to provide the best possible experience for users, developers and block producers. If you’re interested in building on Fuel, don’t hesitate to reach out to us, we’d love to hear from you

In our last piece, we discussed at length the unique functionalities that Celestia enables. We also touched upon various modular protocols and their architecture. So for this next piece, we’re going to be looking at a different type of modular protocol. This is not a modular data availability layer that enables the building of clusters, but rather a modular execution layer.

So what is an execution layer even? An execution layer is a chain that purely handles the execution of transactions, while delegating the rest of the functionalities of a blockchain to other chains, such as consensus/data availability and settlement. An example of an execution layer is the current implementation of rollups on Ethereum, such as Arbitrum and ZKSync. So how is this different from a settlement layer? A settlement layer is also an execution environment, but one that has trust-minimised bridge contracts on it, that rollups use for unified liquidity. These rollups also send their various proofs and block headers to the settlement layer, which acts as the source of truth for the rollups. 

If you’re unsure of what a rollup is, then let’s break it down quickly. A rollup is a scaling solution that operates off-chain from the main L1 (in most cases, Ethereum). This solution performs transactions off-chain, which means it doesn’t have to compete for precious block space. After executing the transactions, it will send a batch of transaction data or proof of execution to the L1, where it will be settled. Because of this, the layer 2 scaling solution is secured by the same layer 1 security measures, since the DA layer or settlement layer acts as the source of truth for the rollup. 

Optimistic and ZK Rollups on Ethereum

Rollups come in two different flavours primarily (However there are other types of rollups too). These two are ZK rollups and Optimistic Rollups. Optimistic rollups assume that transactions are valid by default (hence the name Optimistic). However, in the case of a malicious or wrong transaction, fraud proofs are generated and sent to the L1 to roll it back, while the transaction proposer gets slashed. Zero-knowledge (ZK) rollups run complex computation off-chain as well, through a circuit which provides a validity proof (snarks, starks, plonks, kimchi etc.). This validity proof is posted to the L1 to show that the rollup has executed the transactions correctly, without actually posting the transaction data itself.

Now that we have established what an execution layer is, and how various current rollup scaling solutions work, let's take a look at what it means to be a modular execution layer. Fuel defines a modular execution layer as a verifiable computation system designed for the modular blockchain stack. So what does that actually mean? It means that Fuel is a blockchain execution environment that is able to leverage a lazy/modular blockchain for data availability. Furthermore, the verifiable computation part of the sentence refers to the flexibility of being either fraud or validity provable.

Note that the DA attestation refers to the proof of DA being sent to a contract on the settlement layer - With Celestiums through Gravity Bridge, or IBC with ICS enabled chains.

So why is Fuel, like many others, moving away from monolithic design principles? 

During heavy congestion on monolithic blockchains, L2s or rollup transaction costs rise to outlandish amounts. One of the examples of this happening recently is during the Otherside land sale by Yuga Labs, which catapulted even the transaction costs of L2s to two digits as a result of having to settle transactions on a monolithic chain. This is just one of the reasons why Fuel wants to move away from monolithic designs where consensus, data availability and execution are combined. The execution that Fuel wants to provide will be enabled by data availability and consensus from Ethereum’s rollup centric roadmap, and from other modular protocols such as Celestia. As a result of not being hindered by monolithic entities, Fuel is able to specialize at the execution layer which can immensely increase the capacity of execution. Where Fuel stands out is that they are working to provide fast throughput and complex smart contracts through their own distinctive VM, transaction design and domain-specific language. They do this by optimizing for the future of blockchains, where data availability capacity is no longer the bottleneck.

As mentioned earlier Fuel has been a layer-2 protocol for Ethereum, but is also situating itself to become the go-to execution layer for the future of modularity. Fuel's strategy to become the place to-go-to is to provide high throughput of Ethereum-style composable smart contract transactions. 

They’re still an optimistic rollup. However, Fuel has a very unique design compared to existing optimistic rollups. The uniqueness comes through their UTXO-based design, which allows for parallel transaction execution, which we’ll get more in-depth with later on. Fuel will also implement the ability for operating nodes to accept fees in other tokens than ETH, if they're willing to accept it for transaction fees. This is done by allowing nodes to set up non-primary mempools, where fees are paid in the token that the nodes want to receive.

Different mempools operated by Fuel Nodes which can choose to accept various tokens for the fee the end-user pays

So let’s dig deep down and analyse how Fuel works.

The way rollups work is that anyone is allowed to construct blocks off-chain and then submit them to Ethereum as calldata (which we severely lack, hence the development of blob transactions and eventually the move to sharding). This is done through a rollup contract that keeps track of the block headers of the rollup on Ethereum. In the case of optimistic rollups, a fraud-proof can be submitted and roll back the chain, burn the bonded amount and reward the fraud prover.

Now let’s look at how a rollup node operates, both off-chain and symbiotically with Ethereum. 

Fuel’s Operating Nodes

Rollup users send transactions to a Fuel node, which is done automatically through whatever dApps you’re using on the rollup side. The client/sequencer will then roll up transactions together into a Fuel block, which then gets sent to Ethereum, which confirms the block. The client also handles deposits from Ethereum, which is what I’ve called a bridge contract previously, which enables unified liquidity between the rollup and Ethereum. 

So how does Fuel’s fraud proofs work which ensures no malicious actions?

Once a fraud proof is submitted to the rollup contract, it needs to be validated to check that it has the correct formatting. This is done so that it can ensure that the proof wasn’t maliciously sent. Since if that was the case, a valid block could then be reverted as the result of the illegitimate fraud-proof. The proof verifier contract verifies that the fraud proof is correctly formatted and valid, and if so, processes it to slash the offending rollup block.

This scheme is unique since it does not require state serialization. Which is the action of computing the Merkle root of the state (which we covered in our previous article) after each transaction or block. This is made possible since Fuel uses UTXOs which means that transactions don’t need to be executed in order. This is because you can simply check at the end that every input that was computed, was previously unspent and unique. As a result of this, transactions are able to happen all at once and do not need to be ordered.

UTXO stands for unspent transaction output and is the transaction data model used for Bitcoin. UTXO represents an N amount of a coin/token which is allowed to be spent by an account by another. UTXO makes use of public keys to identify and transfer ownership of holdings. UTXO addresses are formatted by a public key which has an associated private key, which allows for spending on that particular account. This allows for having atomic amounts of tokens or state, which can be controlled by a spender.

Bitcoin’s UTXO Model

In a simplified model, each UTXO has two fields: 1. amount of coins, and 2. script hash that defines an owner. A contract UTXO has four fields, 1. amount of coins, 2. contract ID, 3. contract code hash and 4. a storage root — which is quite similar to a normal account-based contract. Keep in mind that, unlike non-contract UTXOs, contracts don’t have a defined owner similarly to contracts on Ethereum. Since each contract UTXO is uniquely identified by its contract ID in addition to its UTXO ID, each contract can be used multiple times in a single block by simply referencing it by contract ID. 

The reason for using UTXOs is that it enables something incredibly powerful, which is parallel transaction execution. This is because transactions have no interdependency and as such can be executed in parallel with one another. While this was tried previously, it depended on users signing over on the effects of the transaction being spent, resulting in contention. However, by not forcing users to sign every effect of a transaction, you can allow for much more streamlined execution. Since the atomic nature of UTXO transactions define each area of state a transaction is going to, it allows nodes on Fuel to determine which transactions have no interdependency and thus execute them in parallel.

This obviously makes Fuel extremely unique, since no other optimistic layer-2 uses a UTXO-based transaction system. But this is also their strength since it allows for parallel transaction validation, which should increase scalability compared to account-based rollups.

So why is it that using a UTXO based transaction system provides such incredible scalability? This is because each transaction can spend and process up to several inputs and outputs.

Several Inputs and Outputs are enabled in each transaction, as a result of using a UTXO-based transaction model

As a result of this, it allows Fuel to conduct atomic multi-user transactions, which unlocks a new world of possibilities for dApps on top of Fuel. On Fuel, each input in a UTXO-based system is only produced and consumed once, which means that the rollups chain’s state is stored as a key-value.

Since computing state elements with UTXO IDs is deterministic and stateless, once consumed, it allows for long chains and ‘trees’ of pre-signed transactions as well. 

A ‘Tree’ of pre-signed transactions that is able to go to various IDs

As a result of the state database only needing to be checked for the existence of consumed elements, it allows for interesting possibilities and interactions between users and transactions.

As with Bitcoin instead of having accounts you have atomic amounts of x coin/token/state that are controlled by a spender. These state elements can represent different assets, such as allowing ETH and ERC-20 tokens. Furthermore, because of Fuel’s various spending conditions, you can create HTLC outputs (allows for one cryptocurrency to be traded for some amount of cryptocurrency on another blockchain) which will allow for instant withdrawal between Fuel and Ethereum for example. This is done through LPs that can offer up liquidity to users wanting to withdraw quickly, for a fee of course. However, there’s zero systematic risk if they fully validate Fuel blocks before executing the withdrawals. 

So to sum up why a UTXO-based design is distinctive:

1. Parallel transaction validations

2. Unique fraud proofs without requiring state serialization

The security of a blockchain can be defined as the cost of attacking the network’s history. In most cases making it prohibitively expensive to attack the network is what secures it — cryptoeconomic security.

In the case of a Layer 2, such as Fuel, the rollup must also be trustless with state liveness and state safety. This is the case with most rollups on Ethereum, as they inherit the security of Ethereum itself and are thus trust-minimised. Furthermore, there’s also the fabled ‘decentralization’ which can usually be measured in the cost of running a full node (which if, too expensive, will cause the decentralization of the network to falter). This is usually why we don’t increase block sizes. Lastly, it must be permissionless to participate in the rollup’s ecosystem, which is what is enabled by the rollups’ bridge contract on Ethereum.

The underlying security is provided by the Layer 1, which provides data availability among others.

The Fuel roadmap and concept are that of an execution layer that specializes in the future — a modular future. This is seen through their focus on specializing in providing the best possible execution layer for both Ethereum and other DA solutions. The three pillars of the Fuel design are: 

1. Parallel transaction execution

2. The Fuel Virtual Machine (FuelVM)

3. A superior developer experience (with Sway and Forc)

Parallel transaction processing was heavily popularised by Solana, through the Sealevel runtime which sorts incoming transactions to run in parallel across several cores which means they don’t affect the same state in the VM’s memory. This is because Solana transactions describe all the state transactions will read or write when it’s being executed — similarly to UTXOs— thus enabling parallel processing. Solana is like Ethereum, account-based. However, unlike Ethereum, each node ensures that accounts accessed multiple times are only listed sequentially in one queue. 

So how does a rollup like Fuel benefit from this? It does so since it’s able to execute transactions in parallel by using the UTXO model. Therefore Fuel is able to use more threads and cores of a CPU, that in single-threaded blockchains are usually idle. As a result, Fuel can provide more compute and transaction throughput than other rollups on Ethereum.

The FuelVM is the virtual machine used on Fuel for building out various applications and smart contracts through the Sway language, which we’ll get into in a bit. In the FuelVM, transactions happen through UTXOs, as covered earlier. Where you have inputs that get destroyed and outputs created. A virtual machine is basically a state computer that allows smart contracts to interact with one another. It also specifies the rules for changing the state of each Fuel block. If you’re interested in how the FuelVM works and want to start building on Fuel, you can check out the GitHub, which has all the info you’ll need as a developer.

Sway is the language for building out smart contracts and applications on top of Fuel. It is heavily based on Rust, which is an already hugely popular language for building out blockchain applications (primarily used in the Cosmos ecosystem and on Solana and Near as well). Sway is optimised for use through the FuelVM and has a toolchain named Forc (the Fuel Orchestrator, pronounced "fork"). Forc provides tools and commands that developers can use within the FuelVM. You can compare Forc to Cargo, which is used as the Rust build system. This means that it is extremely easy for Rust developers to learn Sway, and start building on top of Fuel. Sway also has a vscode plugin, so it is extremely easy to get started with. Furthermore, Rust (of which Sway is a DSL of) has been voted the most loved programming language year after year by developers, and one of the most used as well.

To better understand how Fuel is trying to change the way rollups work currently, it is very important to look at their views on tokenomics for rollups. Tokenomics for rollups obviously work quite a bit differently, since you’re still reliant on Ethereum for settlement, getting unified liquidity and inheriting the security. Fuel has discussed three major token models that should be avoided for rollups (but that might be fine for other systems such as sidechains). They are:

1. A Proof-of-Stake model where validators can censor new rollup blocks, which isn’t needed since you inherit the security of Ethereum. A lot of rollups are trying to go this route with off-chain DA, such as ZKSync.

2. A model where you’re required to use the native token to pay for fees, thereby tying it to Ethereum. However, the rollup nodes themselves are still required to hold Ethereum to settle. This just adds further UX hurdles for users using the protocol. An example of a rollup going this route is Obscuro. 

3. A governance token that provides control over the rollup contract, which could be attacked via cryptoeconomic attacks.

So what model does Fuel see as the way forward?

The block space on the rollup is a limited resource, just like it is on Ethereum. However, the block space on the rollup is quite a bit different from Ethereum’s. This execution space is scarce, just like Ethereum’s, but it exists independently from it while still being correlated as you’re dependent on the underlying layer’s data availability. Fuel sees a future where this execution capacity can be tokenized, but not one where the token creates a higher fee or friction for the end-user. So how would you tokenize the block space? 

You could tokenize the scarcity of block space, by giving token holders the right to collect fees as a block producer. This moves the token demand to block producers which have demand for being able to collect fees on future block space. In this way, the end-users can utilise whatever token that block producers want to accept for fees, as specified earlier in the article. Furthermore, by using a model in which you tokenize scarcity through the right to collect fees, you can decentralize the block production. This means that the node operators of the rollup will bond tokens, for the right to produce blocks and collect fees from end-users, which creates a marketplace for the token — but doesn’t require the end-user to use that specific token. This means that the token is used for leader selection, the right to produce blocks and collect the fees associated with such. I have actually talked about this in regards to what I would like to see other rollups on Ethereum do, but so far most of them have decided to go with the previous three models discussed further up. 

This capture of the value of block space also relates heavily to MEV, which is also a huge issue with centralized block producers. However, by moving towards a token model, as the one described, you’re able to decentralize the operating nodes and their leader selection. This means a token model like this one, is also able to in a way ‘tokenize’ MEV, which is part of the value that the holders of the token derive the right to claim. By tokenizing the future cash flow of block space, the protocol is also tokenizing the future cash flow of ordering execution within that block space. 

Other rollups are also doing fascinating research in regards to minimising MEV within their protocols. For instance, the auctioning off of MEV, which essentially allows you to tokenize it, has previously been discussed here by Karl Floesch from Optimism. Arbitrum and Chainlink are exploring a fair sequencing service (FSS), that should increase the fairness and predictability of transaction ordering on a rollup.

A modular world where most of the functionalities of an original monolithic blockchain are separated into several chains creates the possibility to optimize various parts of those layers. This is what Celestia is doing by optimising for Data Availability, and what Fuel is doing by optimising for Execution in a modular paradigm. This is also what enables the various layers to create optimised nodes, whether that is full, light or bridge nodes. These nodes are able to be optimized for their specific purpose, which should increase the capabilities of the various layers immensely. 

Something I’ve talked about extensively over the various articles and threads I’ve done is the advance of state bloat, and how building modular can help alleviate some of that. This is what using a separate data availability layer that is stateless helps with strongly. Fuel thus seeks to go beyond the limitations of monolithic design principles.

Outside that, the transaction design is also extremely unique, since Fuel makes use of UTXO. This is quite unheard of since you’re basically using ‘old tech’, but also one of the reasons why Fuel is so interesting to me. 

Instead of building for the current climate on Ethereum, Fuel is building the engine for the autonomous future of modularity. This sets them apart from all current rollups. As I mentioned at the very beginning of the article, if you’re interested in building on Fuel, learning Sway or similar, do attend the Fuel Hackathon and reach out to us — we’d love to talk to you. 

Follow Maven11 on Twitter

Follow Fuel on Twitter

https://fuel-labs.ghost.io/introducing-fuel-the-fastest-modular-execution-layer/

https://docs.fuel.sh/v1.1.0/Introduction/Welcome.html

https://github.com/fuellabs

https://forum.celestia.org/t/accounts-strict-access-lists-and-utxos/37

https://github.com/FuelLabs/fuel-specs/blob/master/specs/vm/main.md

https://fuel-labs.ghost.io/token-model-layer-2-block-production/

https://docs.fuel.sh/v1.1.0/Concepts/Fundamentals/Transaction%20Architecture.html

https://docs.fuel.sh/v1.1.0/Concepts/Fundamentals/Block%20Architecture.html

https://docs.fuel.sh/v1.1.0/Concepts/Fundamentals/Security%20Analysis.html#commondefinitions

https://fuellabs.github.io/sway/latest/

https://fuel.network/blog

Preface

Back in 2019 when we invested in LazyLedger (now called Celestia) the word modular wasn’t popularized yet in relation to blockchain designs. Over the past year, it has been popularised by people like polynya, a ton of L2 teams, countless others and of course also the Celestia Labs team - who coined the term in their first LazyLedger blog post in relation to separating consensus and execution.

Because of this, we are excited to put forward an updated overview of our investment in Celestia. It will offer insights into the modular world we envision, the various layers and protocols in such an ecosystem and why we are so excited about the potential functionalities it offers.

Currently, most functioning and public blockchains are all monolithic entities. By monolithic, we mean a chain that handles both data availability, settlement and execution all on its own. Now, there are some variations of monolithic chains, especially in regards to rollups on Ethereum and subnets on Avalanche that have modular components. However, those aren’t modular blockchains in the most genuine sense of the word.

Let’s define what we mean when we say ‘modular’ so that there are no misinterpretations. When we say modular we refer to the fact that the usually combined layers, are decoupled. So what does this mean? It means that one of the three components of the chain is decoupled, so either execution, consensus or data availability. This means that you can put the term modular on rollups, since they only handle execution. While Ethereum handles everything else, as a monolithic entity.

In the case of Celestia, we can put the term modular on it since it only handles data availability and consensus. While it delegates settlement and execution to other layers. These layers are also modular since they only handle part of the components themselves. This means that in the case of Ethereum we can’t call it a modular blockchain, since the outsourcing of components only happens on its current rollups, in regards to execution. Nonetheless, Ethereum is still able to handle execution on its own, while also allowing rollups to batch transactions off-chain. This means that in its current implementation, Ethereum remains a monolithic chain. Although, Ethereum still remains the ideal settlement layer while being the most decentralised and secure smart contract chain at the same time.

Now, you might say what about Polkadot or Avalanche? In Avalanche's case, it's not modular, but rather just split up networks that are all capable of handling all the components of a blockchain. This means that they don’t scale modularly, but rather scale by utilising other monolithic chains horizontally. Polkadot's parachains handle execution, similarly to rollups, while sending blocks to the relay chain for consensus and data availability. However, the relay chain still ensures the validity of transactions.

Over time as monolithic chains grow it causes immense amounts of congestion and inefficiencies. Being confined to using a single chain for all purposes is simply not feasible, if we want to onboard more people. Since it causes extremely high fees and delays for the end-user. This is exactly why we’ve seen more and more chains deciding to move towards splitting their chains up. We’ve all heard of the fabled Merge, which will move Ethereum to a Proof-of-Stake chain. However, they also plan on moving to sharding eventually. Sharding is when you split the blockchain horizontally into several pieces. These shards will purely handle data availability.

This together with rollups is how the Ethereum community plans on fixing its scalability issues. Now, are there other ways too? There are certainly — we’ve also seen Avalanche move towards a slight modular future with Subnets, however, as explained earlier we wouldn’t categorise it as complete modularity.

To better understand how each of the various 'modular’ architectures function, let's try to draw them out so that we can get a better overview of the differences.

First, let’s take a look at the biggest smart contract blockchain in existence, Ethereum. Let’s look at how their current architecture looks, and how it's going to look in the future when sharding is enabled.

Currently, Ethereum handles all the components of a blockchain. However, it also offsets some of the execution to L2 rollups that then batch transactions to be settled on Ethereum. In the future, with sharding, the architecture will look a bit like this:

This would turn Ethereum into a unified settlement layer while shards would handle data availability. This means that shards would just be DA environments for rollups to submit data to. On shards, validators only need to store data for the shard they’re validating, not the entire network. Sharding will eventually let you run Ethereum on light nodes, similar to Celestia.

For Avalanche, their main scaling proposition is through singular blockchains that can easily be created — their subnets. The Avalanche architecture looks a bit like this:

A subnet is a set of new validators that validate a blockchain. Each blockchain is validated by exactly one subnet. All Avalanche subnets handle both consensus, data availability and execution by themselves. Each subnet will also have its own gas token, as specified by the validators. An example of a subnet that is currently live is the DefiKingdoms subnet, which uses JEWEL as its gas token.

Before we move on to look at Celestia's architecture let's first look at Cosmos. From which Celestia borrows heavily and with which there will be heavy interaction through IBC since it’s also built with the Cosmos SDK and a version of Tendermint - Optimint. Cosmos architecture is quite different from other current architectures, since it enables dApps as the application of the blockchain itself, instead of providing a VM. This means that a sovereign Cosmos SDK chain just has to define the transaction types and state traditions that it needs while relying on Tendermint as its consensus engine. Cosmos chains split up the application part of blockchains and use ABCI to connect it to networking(p2p) and consensus. ABCI is the interface that connects the application part of the blockchain to the Tendermint state replication engine which provides the consensus and networking mechanisms. Its architecture is often propagated as such:

Now let’s take a look at how Celestia’s architecture will look, once the ecosystem starts to get built.

This is how an early ecosystem could look on Celestia. Celestia will operate as the shared consensus and data availability layer between all the various types of rollups operating within the modular stack. The settlement layers would exist to facilitate bridging and liquidity between the various rollups on top of it. While you would most likely also see sovereign rollups functioning independently, without settlement layers.

Now that we have established the different degrees of modularity, how they function and how they look, let’s take a look at some of the unique capabilities and functionalities that pure modular blockchains such as Celestia enable.

One of the beautiful things about monolithic blockchains is the fact that all users, applications and rollups that make use of it, receive security from the underlying layer. So how does this work in the setting of a modular stack?

It’s quite simple really — Celestia provides the rudimentary functionality that chains require to establish shared security — data availability. This is because every single layer that utilizes Celestia is required to dump all their transactions data to the data availability layer, to prove that the data is indeed available. This means that chains can connect, watch and interoperate with each other effortlessly. By always having the security of the underlying DA layer it makes it extremely easy to hard and soft fork too, which we will get into later.

Likewise, Celestia allows various types of experimental execution layers to be run simultaneously, even without relying on a settlement layer, while still having the advantage of a shared data availability layer. This means that the rate of iteration will become much faster since it would likely scale linearly with the number of users. Therefore our thesis is that, in time, this leads to compounding improvements on execution layers, as we’re not restrained by monolithic entities with centralised execution layers, since execution and data availability is decoupled. The permissionless nature of modularity allows for experimentation and gives developers the flexibility to choose.

Celestia’s block verification works quite different from other current blockchains since blocks can be verified in sub-linear time. This means that throughput increases with a sub-linear growth in cost, compared to linear growth in cost. So how does this look on paper? Let’s take a look.

This is possible since Celestia’s light clients do not verify transactions, they only check that each block has consensus and that the block data is available to the network.

Celestia removes the need to check transaction validity since it only checks if blocks have consensus and data availability, as seen above.

Instead of downloading the entire block, Celestia light nodes just download small random samples of data from the block. If all the samples are available, then this serves as proof that the entire block is available. Basically, by sampling random data from a block, you can probabilistically verify that the block is indeed complete.

This means that Celestia reduces the problem of block verification to data availability verification, which we know how to do efficiently with sub-linear cost using data availability sampling.

DA proofs are when you require that blocks being sent, are to be erasure coded. This means that the original block data is now doubled in size, and the new data then gets encoded with redundant data. Celestia's erasure encoding expands the block sizes by 4x, in which 25% of the block is the original data, while 75% is the replicated data. Consequently requiring a misbehaving sequencer or similar to withhold more than 75% of the block’s data if it wanted to commit fraud.

Hence it allows light clients to check with a very high probability that all the data for a block has been published, by just downloading a very small piece of the block(DA sampling). Each round of sampling decreases the chance of data unavailability until it's certain that all the data is available. This is extremely efficient since instead of every single node downloading every single block, you instead just have many light nodes downloading small pieces of each block, but with the same guarantees of safety as before. This means that as long as there are enough nodes that are sampling for data availability, it is possible to increase throughput, as the number of sampling nodes increases. You may be familiar with this type of network in your daily life(DA proofs), even if you haven’t used blockchains, by using protocols such as BitTorrent.

When we talk about scalability the first thought that comes to mind from most people is usually transactions per second. However, this should not be the actual discussion being had around scalability. When talking about scalability in a specialized DA layer it should rather be mb/s, instead of transactions per second which should be the major hurdle to overcome. Mb/s becomes an objective measure of the capacity of a chain, rather than tp's since transactions vary in size. Here Celestia stands quite well, since it unbloats the DA layer and utilizes data availability sampling to increase the amounts of mb/s the system can handle.

By that, we mean that the real limitation of how many transactions a blockchain is capable of processing is based on input and output. So, by decoupling data availability from the input and output process, which rollups will handle, Celestia will be able to produce much higher bytes per second than monolithic entities.

This all stems from the data availability problem. Which is the number of data in a proposed block that a sequencer or similar can verify is available while being limited by the data throughput of the underlying DA layer. Now with monolithic blockchains that utilise full nodes, the normal step to take to fix this would be to increase the hardware requirements of full nodes. However, if you do that, there will be fewer full nodes and decentralization of the network would falter with it.

Therefore by utilising the technology we touched upon in the block verification part previously, we can increase scaling without increasing node requirements by making full nodes equal light nodes with DA sampling. This in turn causes node growth to cause more throughput since DA sampling causes sublinear growth — since it scales with the number of light nodes being added. In monolithic design, a block size increase equally increases the cost of verifying the network, but on Celestia, this is not the case.

Although, Ethereum is also looking to fix some of its scalability problems with EIP-4844 which would enable a new transaction type — blob transactions. Which will contain a large amount of data that cannot be accessed by EVM execution, but still be able to be accessed by Ethereum. This is done because presently, rollups on Ethereum rely on a minuscule amount of available call data to exercise their transactions. Sharding will also help but is still quite far out, but when released should dedicate around 16MB of data space for rollups per block. However, it remains to be seen how competitive the battle for the blob transaction space will become. Although, once you solve one of the scalability dilemmas, another might pop up. So by moving towards modular layers, we can allow the various parts of the stack to specialise for the specific resource they utilise the most.

In most cases when a hard fork takes place on monolithic chains, you lose the security of the underlying layer, since the execution environments don’t share the same security. This means that usually hard forks are not feasible or wanted since it would mean the new fork won’t have the security of the data availability and consensus layer. It's the same idea when we say that you could submit a change to the code of a blockchain, but you’d have to convince everyone to agree with your change. Take Bitcoin for example. Bitcoin’s code is changeable quite easily, however, getting everyone to agree with a change is the hard part. In the case of you wanting to hard fork a monolithic blockchain, you would also need to fork the consensus layer, which means you lose the security of the original chain. The amount of security lost depends on the number of miners or validators that don't validate the new canonical chain. However, if all the validators upgrade to the same fork, then no security is lost. On modular blockchains, this is not true, since if you want to fork a settlement or execution layer you would still have the security of the underlying consensus layer. In this case, forks are viable since the execution environments all share the same security. Although, this isn't possible for rollups on a settlement layer, since the settlement layer acts as the source of trust for the added blocks.

The case for hard forks being unlimited and easily accomplished for execution environments, is that wild ideas can be tested and tried. As well as making it feasible to work on top of the work of others, without losing the base layer security. If you think about the ideas of a free market (and some might not agree on this) it can often create competing implementations that can give better outcomes.

The modular stack is a concept unique to Celestia. It refers to the decoupling of all the various layers of a usual blockchain into separate layers. So when we say stack we refer to all the layers functioning together.

So what layers exist? There’s unmistakably the consensus and data availability layer Celestia, but there are also other layers. Here we refer to the settlement layer, which is a chain which rollups have a trust-minimized bridge with for unified liquidity and bridging between rollups. These settlement layers could be of various types. For example, you could have restricted settlement layers that only allow for simple bridging and resolution contracts for the execution rollups on top of it. However, you could also have settlement layers that have their own applications on them, as well as rollups. Although other types of rollups exist as well, that don’t rely on a settlement layer, but rather function on their own solely with Celestia — these are called sovereign rollups, and we’ll talk about those in the next chapter.

Now, it is also possible to have a stack where the execution layers don’t directly post block data to the settlement layer, but rather directly to Celestia instead. In that case, the execution layers would just post their block headers to the settlement layer, which would then check that all the data for a certain block was included in the DA layer. This is done through a contract on the settlement layer that receives a Merkle tree of transaction data from Celestia. This is what we call attestation of data.

Another huge advantage to the modular stack is its sovereignty. In the modular stack, governance can be compartmented to specific applications and layers and does not overlap with others. If there is an issue, governance can fix it without interfering with other applications in the cluster.

A sovereign rollup is a rollup that operates independently from any settlement layer. This means that it doesn’t rely on a settlement layer with smart contract capabilities where it would provide state updates and proofs, but rather function purely with a namespace on Celestia. Usually, rollups function within an ecosystem, like Ethereum, where it has a rollup smart contract (resolution contract). This rollup's smart contract also provides trust-minimized bridging between the settlement layer and rollup. However, on Ethereum, all the rollups compete for precious call data. This is why EIP-4844 is being worked on, which would provide a new transaction type— blob transactions. This would also increase the block size. However, even with blob transactions, there will most likely still be heavy competition for settlement.

Most monolithic blockchains are capable of handling smart contracts. On Ethereum for example there is an on-chain smart contract that handles state root, which is the Merkle root of the current state of the rollup. This contract constantly checks that the prior state root fits the rollup batches of its current root. If that is the case, then a new state root is created. However, on Celestia, this is not possible as Celestia won’t handle smart contracts.

Rather on Celestia, sovereign rollups post their data directly to Celestia. Here the data won’t be computed or settled, but rather just stored in block headers. A block header is what identifies a particular block on a blockchain, and each block is unique. Within this block header, a Merkle root exists which is made up of all the hashed transactions.

So how does it work? The rollup has its own peer-to-peer network from which both full and light nodes download the blocks. However, they also verify that all the rollup block data was sent and ordered on Celestia (hence the name data availability) through a Merkle tree — which we’ve seen examples of earlier. Thus, the canonical history of the chain is set by local nodes that verify that the transactions of the rollup are correct. The implication of this is that a sovereign rollup is required to post every transaction on the data availability layer, so that any node can follow the correct state. As a result, full nodes that function as watchers of the rollup’s namespace (think of a namespace as a rollup’s smart contract) can also provide security to light nodes. This is because, on Celestia, light nodes are almost equal to full nodes.

To elaborate on namespaces: On Celestia, Merkle trees are sorted by namespaces which enable any rollup on Celestia to only download data relevant to their chain and ignore the data for other rollups. Namespace Merkle trees (NMTs) enable rollup nodes to retrieve all rollup data they query without parsing the entire Celestia or rollup chain. Furthermore, they also allow validator nodes to prove that all data have been included in Celestia correctly.

So why are sovereign rollups a unique prospect? Because prior rollup implementations, such as on Ethereum are limited, since Ethereum nodes are required to store execution-related state as a result of being monolithic. However, in a modular design, we can have specialized nodes for various purposes, which should make it much cheaper to run the network. Thus the costs of running the network scales with the cost of light nodes rather than full nodes, since as we explained earlier - light nodes = full nodes.

Let’s take a look at how some of the rollup implementations could function as sovereign rollups. First, it is important to clarify how the various rollup proof systems function on Celestia.

Optimistic rollups depend on fraud proofs. The fraud proofs would be gossiped between clients peer-to-peer via full nodes and light nodes on the rollup side. We will look at an implementation of this further down. Sovereign rollups change the way fraud proofs are distributed. Instead of verifying them on a settlement layer contract, they're now distributed in the rollups peer-to-peer network and verified by local nodes. With Sovereign Optimistic Rollups on Celestia we can possibly also minimize the challenge period, which means we fix one of the major hurdles with current ORs, since they're currently very conservative with their dispute windows on Ethereum. This is possible since currently, all the fraud interactions happen on-chain in the highly competitive block space of Ethereum, which causes protracted finalization. However, on a sovereign rollup, any light node has full node security if it’s connected to an honest full node, and therefore fraud interactions should be much quicker.

ZK rollups depend on validity proofs (zksnarks for example). ZK rollups acting as sovereign rollups would function quite similarly to how current implementations work. However, instead of sending a ZK proof to a smart contract, it would be distributed in the peer-to-peer network on the rollup for nodes to verify. Sovereign ZK rollups much like ZK rollups on unified settlement layers allow for various execution runtimes to function on top of each other as sovereign chains, since their transactions aren't interpreted by Celestia. Here the runtimes on top of the ZK rollup could function in a variety of ways. There could be a privacy-preserving runtime, an application-specific runtime and much more. This is what is coined as Fractal Scaling.

Now that we have established the concept of sovereign rollups, and have an idea of how they will be implemented on Celestia, let’s take a look at how two different rollups’ architectures could look:

So why do they need Celestia? Optimistic rollups require DA so that fraud proofs can be detected and ZK rollups require DA so that the state of the rollup chain is known.

It’s also important to always be contrarian when you look at something. Because if not, you can often get blinded by your own conviction. In this section, I will try to explain some of the negatives that come with sovereign rollups.

Sovereign rollups are going to be heavily reliant on new ecosystems being built on top of them, similarly to the often touted L1 playbook. This means dApps etc. However, if the rollup has a VM implementation that already has a lot of development activity and dApps that are open source, then this becomes much easier to do. Despite this, liquidity is still the major issue to overcome. Liquidity will often be compartmentalized to the sovereign rollup and its runtimes. Thus the rollups would be heavily reliant on secure, trust-minimized bridging to other layers, such as other sovereign rollups or settlement layers. We’ll look at some possible implementations of this later on. Furthermore, the implementation of sovereign rollups is heavily dependent on infrastructure being built that can support its various functionalities.

Optimistic Rollup Implementation

In this section, we will try to explain how a possible Sovereign Optimistic rollup implementation could work. This part borrows heavily from the Light Clients for Lazy Blockchains research paper written by Ertem Nusret Tas, Dionysis Zindros, Lei Yang and Davis Tse.

One way to construct a unique way of providing fraud proofs for an OR is to have full and light nodes on the rollup to play a bisection game. A bisection game is played between two nodes, one that is a challenger and one that is a responder. The challenger would send a query to a responder through a third node acting as a verifier. The responder's reply to this query would happen through the same channel. After receiving the challenge, the verifier would forward the query to the responder, who would then produce a response that would be sent back to the verifier and the challenger. The verifier will consistently perform checks to make sure that there aren’t mismatches between the two, and that they aren’t malicious. The verifier acts to ensure that the responder isn’t sending the wrong Merkle trees, and the challenger acts to ensure that the responder is following the correct root. If the responder can defend himself, then the game carries on as usual. As a result of this bisection game, an honest challenger will always win, and an honest responder will always win.

It’s also possible to neither use a settlement layer connected purely to Celestia for bridging, nor function as a sovereign rollup. Since Celestia just provides the underlying DA layer with shared security, any settlement layer could be used as long as Celestia can send a Merkle root of available transaction data to a settlement layer contract. This means that any settlement layer could be used for rollups, if they so desired. So why would they do this? Many existing settlement layers, such as Ethereum, have an already existing and thriving ecosystem. Thus there’s already liquidity, and users to take advantage of. This is especially advantageous for rollups that don't want to rely on building an entire ecosystem from scratch. Now, this is not purely limited to Ethereum as a settlement layer. You could also make use of Mina as a ZK rollup for example. That means you could send your transactions data to Celestia, while sending state updates and zk-proofs to Mina. By doing so, you already have a settlement layer that’s validity proven by default.

If you’re a rollup operator and want to take advantage of liquidity and users that utilize other blockchains, then this type of solution is highly attractive to you. It’s also possible to sorta become a plug and play type of rollup operator. You could have different sequencers plugged into different settlement layers. For example, one ZK rollup sequencer could be connected to Mina and provide state updates and validity proofs. While another sequencer on a different zk-rollup could be connected to Ethereum for settlement through the Quantum Bridge (the fabled Celestiums). What they would all have in common, is that they would send all their transaction data to Celestia, and then Celestia would operate a smart contract or similar on the settlement layer where it would send a Merkle tree of available data (attestation).

Let’s take a look at how this could look architecturally with a ZK rollup as an example:

The source of revenue for Celestia itself is going to be transaction fees from various rollups’ submitted transaction batches. Celestia’s transaction fees are going to be quite similar to how Ethereum currently operates with EIP-1559, so a burn style mechanism. This means that there will be a dynamic base fee that will be burned, as well as a “tip” for validators to push a certain transaction through quicker, these validators would also get value from the issuance of tokens after new blocks. However, this is from the perspective of Celestia’s validators, so what would it look like from a user’s perspective? Let’s first establish how the various fees would look depending on what layers you’re using, and then we can conclude how the user experience would look.

The fee structure for execution rollups will primarily be the operating cost + the DA publishing cost. There will likely be an overhead cost too, so that the rollup makes a profit. That means for the user you would likely pay one fee that encompasses those 3 + a congestion fee — which will likely be much lower as a result of less congestion.

The source of revenue for the settlement layer is the settlement contract fee that the rollup would pay to be able to settle on it. Furthermore, there will also be enshrined trust-minimized bridging between rollups through the settlement layer, so it would also be able to charge bridging fees.

Then what about sovereign rollups that function without a settlement layer? On sovereign rollups, users would have to pay a gas fee to access computation on the rollup. The rollup would set a fee, most likely decided by governance, and then you would likely also have a congestion fee that would have to be paid for as well. These fees on the rollup would cover the fee of publishing data to Celestia, and a small overhead for the rollups validators. You would forego the settlement fee, which will likely produce extremely low fees for the end-user.

So to conclude, we can create a fee structure of how the various fees will look for the end-user. The end-user of a modular stack would likely get 3 constant fees, with 4 being possible. These are the DA publication fee, the settlement contract fee and the rollup execution fee. The fourth possible fee would be a congestion fee during heavy loads. The user only pays a single fee on the execution layer, this fee would encompass the costs of all the layers in the modular stack. So let’s take a look at what the fee structure would look like from the users' perspective:

So what does this mean for the future?

Well, if Celestia proves to be a cheaper and faster data-availability layer for rollups to use, while still providing decentralized and shared security, then you could see rollups increasingly use it for data availability. If we consider how much rollups are currently paying to use Ethereum for security, then the rollups on Celestia would pay much less. However, there are fixes coming to fix the congestion issues on Ethereum, primarily blob transactions, staking and sharding.

Then what about MEV? Rollups currently utilise sequencers to collect and order users' transactions in a mempool before they get executed and posted to the DA layer. This is an issue in regards to MEV, since the sequencer is primarily centralized in current implementations, and is therefore not censorship-resistant. The current solution to this is to decentralize the sequencers, which a lot of current rollups plan to do, though this brings with it its own set of issues. Another way to solve this in some form would be to separate validators and the ordering of transaction lists (take a look at Vitalik’s paper if you’re interested).

To conclude, the layers of the modular stack receive revenue through transaction value. Users obtain value from transacting on a layer and are thus familiarised with paying fees. The value thus refers to the value a user receives from having their transactions included on a layer.

As we’ve discussed previously, if a rollup has a settlement layer, it will have a trust-minimized bridge to other rollups via the settlement layer. But what happens if the rollup is sovereign, or if it wants to bridge to another cluster? Let’s look at cross-rollup communication.

In the case of two sovereign rollups that want to communicate, they can actually make use of light client technology, much like how IBC functions. The light clients would receive block headers from the two rollups and with it, the proofs that the rollups use, via a p2p network. This could both work via a lock and mint mechanism, such as with IBC, or via the validators through a relayer. With chains built using the Cosmos SDK and those who leverage Tendermint or Optimint bridging becomes much more seamless, as you can take complete advantage of IBC with ICS. However, this requires the two chains to include the state machines of each other and have the validators of the bridging chains write off on transactions. Other ways to bridge can exist as well. We could, for example, imagine a third chain that functions with some sort of light clients. On which the two chains that want to bridge can stream their block headers, which would then function as a settlement layer for the two. Or you could rely on a Cosmos chain to act as an “intercluster rollup hub”, where the validators of the chain could operate the bridge by following the conditions of the rollups. There also exists a wide variety of bridging as-a-service chains, such as Axelar, and many others.

However, by far the easiest way to facilitate bridging, is for execution rollups to use the same settlement layer since they would have trust-minimized bridge contracts on it.

The reason why bridges between layers are so important is that it allows for unified liquidity. Secondly, by allowing protocols and layers to be composable with one another through sharing state, we unlock new levels of interoperability. State sharing refers to the ability of one chain to make calls to another chain. Here is of special interest, particularly the abilities of interchain accounts with ICS-27.

So, therefore, we can conclude that light clients are crucial in interoperability standards like IBC. Celestia light clients’ will as a result enable more secure interoperability between chains in the various clusters. In regards to Celestia’s connection to IBC, then they’re planning on using governance to whitelist certain chain’s connections to Celestia, to limit state bloat.

While all the various monolithic and modular design approaches of the last few years are innovative, and the amount of talent building it, is astonishing. There is one fundamental question underlying various trade-offs that has been around in our space for quite some time. We believe it centres around end-user verification and the need thereof.

You can argue endlessly, and CT will, about the various trade-offs different designs make. But in the end, it perhaps comes down to the question - if having the possibility of end-user verification matters. A lot of design trade-offs (e.g. blocksize) centre around the ease of running a full node, and DAS enables light clients to be “first-class citizens”, comparable to full nodes.

The underlying assumption in thinking that, is that users will care about being first-class citizens at all. The fact that users can easily verify the chain by running a light client/full node does not mean they will, or that they will value the ability to do so.

The argument in favour of this is rather straightforward. If users do not care about verification you might as well run a centralized database. It will always be more efficient as decentralisation often comes at the expense of efficiency. Hence the reason why we are building crypto protocols at all, is that end users are able to verify the compute.

The argument against, is that as long as the network is sufficiently decentralized, end-user verification in itself does not matter. Users won’t care about it, as long as UX is good. There is no clear answer to how important end-user verification is for now. However, we think end-users being able to verify the chain is a worthwhile goal chasing and the reason why many are building in this space.

This section will serve as a way to envision what the modular stack built on top of Celestia could look like in the future. We will look at an architectural overview of how we view the modular stack, and what kind of layers we might see.

Underneath is a diagram of many of the possible layers that can function within a modular stack. They all have one thing in common, they're all using Celestia for data availability. We will likely see various sovereign rollups, both Optimistic and ZK rollups, which will function without a settlement layer. We're also likely to see rollups utilise Cevmos as a settlement layer, alongside various app chains. There is also the possibility that we might see other types of settlement layers. These settlement layers could be restricted, which means that they would either have pre-set contracts just for bridging and rollups, or rely on governance to whitelist contracts.

On the right side of the diagram are other non-native settlement chains which could also have rollups that utilise them for liquidity and settlement while relying on Celestia to provide an attestation of transaction data to the settlement layer.

All of these clusters would all be connected through various bridging services, both new and old.

What you don't see is also all of the infrastructures that will be built to provide easy access to the various functionalities of Celestia, such as RPC endpoints, APIs and much more.

If you’re looking to build on top of Celestia, whether that would be in regards to rollups, or other types of infrastructure, then do reach out. We would be happy to talk to you!