Jon Charbonneau https://paragraph.com/@jon-dba Co-founder dba.xyz Sun, 05 Apr 2026 02:45:13 GMT https://validator.w3.org/feed/docs/rss2.html https://github.com/jpmonette/feed en Jon Charbonneau https://storage.googleapis.com/papyrus_images/73d4fdc0ee3391cb76561ce281b3207a6e577357b41019d4820d2e11f67c107a.jpg https://paragraph.com/@jon-dba All rights reserved <![CDATA[Endgame: Proof of Governance]]> https://paragraph.com/@jon-dba/endgame-proof-of-governance RjcLgUEFItut53pWUHaz Mon, 07 Aug 2023 05:23:42 GMT Thank you to Hasu, Mike Neuder, Konstantin Lomashuk, Sacha, Josh Bowen, Tomasz Stańczak, Chris Hager, and Toni Wahrstätter for great conversations around this topic.

Introduction

This post expands upon my conversation with Hasu in our first episode of Uncommon Core 2.0 as well as my talk at Modular Summit. I’ll cover the following:

  • Proof-of-stake (PoS) - The key motivations for PoS and its relevant properties are often deeply misunderstood, particularly “economic security” and “decentralization.”

  • Delegated proof-of-stake (DPoS) - I’m using this to refer to any PoS system with native stake delegation (e.g., typical Cosmos chains). Simple DPoS by itself has severe shortcomings, including generally poor delegate selection (topheavy stake delegation) and capital inefficiency.

  • Liquid staking tokens (LSTs) - LSTs are often the best tool for achieving a decentralized operator set on top of a permissionless PoS mechanism. It’s essential for these LST protocols to be properly aligned with the underlying chain (e.g., Lido’s proposed dual governance) or even more directly monitored by the chain’s governance (e.g., Cosmos Hub’s proposed liquid staking module).

  • Proof-of-governance (PoG) - A chain’s governance could just directly elect operators without staking. I’ll argue that this can be more secure and decentralized than PoS in many circumstances. An implicit form of PoG may be inevitable as LSTs continue to proliferate (i.e., it may be the LST’s governance which controls delegation, with some dual governance backstop).

  • Restaking & PEPC - If PoS economic security may not be exactly what it seems at the surface, then what is restaking really for?

I’ll primarily analyze this landscape from the perspective of how to choose rollup operators (e.g., sequencers and provers) vs. how to choose Ethereum validators. I intentionally use these opposite ends of the spectrum (e.g., a rollup can be secure even with a single default sequencer) to reveal the underlying fundamentals applicable to all chains. The mechanisms I describe may also be viable for certain traditional “monolithic chains” (i.e., not just rollups).

Arguments in crypto often take the following narrow forms:

  • Is PoS better or worse than PoW?

  • Is PBS better or worse than POB?

  • Is FCFS better or worse than explicit price auctions?

The list goes on. The simple answer - they’re tools which are neither inherently good nor bad. They may be more or less effective in different scenarios depending on the desired outcome. Different protocols have different desired outcomes, so different mechanisms often make sense. This should be plainly obvious, but I feel that we frequently look past this.

Rollups generally serve a very different purpose vs. Ethereum, and sequencers play a very different role vs. Ethereum validators. I often notice an inclination to take the mechanisms we see on Ethereum → try to strap them onto rollups without sufficiently reconsidering them from first principles. Unique problems require independent analysis.

Consensus Protocols & Sybil Resistance Mechanisms

We’ll build up from the absolute basics here because I’m going to be rather contrarian on a lot of fundamentals later on. For more background, I recommend Tim Roughgarden’s awesome video series on PoS.

For starters, proof-of-work (PoW) and proof-of-stake (PoS) are examples of sybil resistance mechanisms. They are not consensus algorithms/protocols (despite frequently being misnomered as such).

  • Sybil resistance mechanism (e.g., PoW or PoS) - Dictates who can participate in the consensus protocol (e.g., proposing and voting on blocks).

  • Consensus algorithm/protocol (e.g., BFT-type or longest-chain) - Dictates how the participants reach consensus. It instructs which blocks will be committed to honest nodes’ local view of the chain (and in what order).

Consensus protocols must protect themselves against sybil attacks. If 1 identity = 1 vote and it’s costless to fake identities, then a single attacker could overwhelm the network:

Source: Doing Decentralized Identity Right, Kelvin Fichter
Source: Doing Decentralized Identity Right, Kelvin Fichter

We can view blockchains in two deployment settings regarding who can participate in consensus:

  • Permissioned - We avoid sybil attacks with a trusted setup to pick all consensus nodes. New entrants cannot join permissionlessly. This permissioned setting is generally called proof-of-authority (PoA).

  • Permissionless - Consensus nodes are not known in advance, and they can change over time unpredictably. We need to get more creative here to solve the sybil attacks.

In the permissionless setting, we generally tie voting power to some real economic cost to prevent sybils:

  • PoW - Probability of proposing a block = % of total hash power

  • PoS - Probability of proposing a block = % of total assets staked

Different sybil resistance mechanisms may also have varying degrees of accountability and punishment for undesirable behavior:

  • PoW - You could hard fork to change the hashing algorithm, but this punishes all miners whether honest or dishonest. The hash rate would completely reset as well (e.g., go back to CPU mining), potentially allowing for further attacks.

  • PoS - This allows for targeted punishment, slashing the stake of malicious actors and removing them from the consensus set.

There are countless nuanced tradeoffs between PoW vs. PoS, but both share at least one issue:

Source: Doing Decentralized Identity Right, Kelvin Fichter
Source: Doing Decentralized Identity Right, Kelvin Fichter

Assigning consensus voting power based purely on economics is often suboptimal.

Proof-of-Stake vs. Proof-of-Governance

Proof-of-Stake

We often take PoS as a given nowadays, but we need to question whether “staking derivatives have just been turning them into effectively Proof of Authority networks with hand-selected validators”?

Let’s consider the options here broadly:

1) DPoS (Delegated Proof of Stake) - Token holders all delegate their tokens to a validator who votes for them. This is capital inefficient, and LSTs inevitably arise. There’s also heightened demand for LSTs when in-protocol delegation does not exist (as is the case with Ethereum).

2) LSTs (Liquid Staking Tokens) - LST protocols (e.g., Lido) manage stake delegation behind the scenes and give users a liquid token (e.g., stETH) representing their share.

3) LSTs + Dual Governance - The LST protocol cedes some control for incentive alignment. For example, the LST protocol’s governance (e.g., LDO token holders) may give veto rights to LST holders (e.g., stETH).

Proof-of-Governance

I’ll provide a fourth option here as well:

4) PoG (Proof of Governance) - The chain’s governance mechanism elects delegates. No staking is required. There’s a critical difference between this and the PoA I mentioned earlier:

  • PoA - Generally used to describe private blockchains (e.g., a bank’s). Also reasonable for public RWA blockchains like Noble (mints USDC) where the issuer (e.g., Circle) has effective “authority.”

  • PoG - Clear and credible decentralized governance mechanisms in place to elect delegates.

Consider the following example:

  • A rollup whose validating bridge controls most of its assets

  • Decentralized onchain governance is in place to manage the bridge’s upgradeability

  • This governance mechanism has the power to elect whichever sequencers they choose (or force their removal) at any time

The difference between the above scenario (PoG) vs. some company running a permissioned blockchain where they’re the sole validator (PoA) should be clear. The rollup has governance mechanisms in place to choose delegates which are:

  • Clear - In this case, the mechanism is clearly defined onchain (the bridge contract).

  • Credible - In this case, the bridge’s governance is likely to sway everyone to follow (it controls most of the assets).

This contrasts to the PoA example where there’s no process in place to choose another operator. Technically, anyone can fork even a corporate chain (if the code is open-source) and put in themself as the delegate, but nobody would follow it.

Whatever mechanism will practically dictate a contentious scenario (e.g., a fork) is in control. This gets into the recent discussion at Modular Summit where Anatoly offered the following hypothetical:

“You can take Ethereum L1 data right now, dump it into Solana, dump the state root that's computed from that Ethereum data, and then run an Optimism style proof to check if fraud has occurred… Does that make Ethereum a Solana L2? Mechanically yes, socially no.”

Vitalik’s response described this situation incredibly well:

“The sovereign is the one that decides the exception, and in blockchains the exception is bugs and 51% attacks. And the question is always what happens if Ethereum hard forks for example. If Ethereum hard forks then there’s a few possibilities.

One possibility is that the Solana bridge, and if we assume that it's a perfect ZK bridge, then according to the old ZK rules the Ethereum chain will just start being invalid, and that bridge will just basically create its own version of Ethereum Classic 2.0.

But then the question is what do the assets follow, and realistically in this case the assets would follow Ethereum, but if you get into a world where the majority of assets are rooted onto Solana and then bridged onto Ethereum then that would look very different. And in that case then Ethereum would not actually be capable of hard forking unless there’s some kind of onchain governance.

Or a possible third world would be a world where the assets are all based on Solana but at the same time the Solana community is willing to hard fork whenever Ethereum is willing to hard fork. And in that case that's a construction based off of I guess some kind of deeper version of onchain governance. And in that case you would still be able to call Ethereum an L2, but it would be part of this ecosystem where things are willing to be part of the governance of each other.

You basically just have to look at what happens if one chain or the other chain gets 51% attacked… what happens if one chain gets 51% attacked and the community decides to do a user-activated soft fork to kill the attackers. So not like an easy slashing hard fork, but like a censorship hard fork where the community responds by picking the minority chain, and on the minority chain the majority would have to either skip being on that chain or get slashed, and if they skip being on the chips they get leaked.”

Similarly to the L2 discussion above, Ethereum social consensus has the ultimate power over the consensus layer delegates today. This was clearly displayed in Dankrad’s recent comments around restaking alignment:

“We should establish a social norm here that building on Ethereum, like building smart contract protocols on top, we should almost never touch that. I mean it would be in a very extreme, very rare situation.

But messing with the staking layer is a different matter. For example if lots of validators start censoring we do want the ability to intervene. So I think it would be a good signal to send, yes we might be opinionated on what you do on the staking layer, and that might include messing with your protocol and destroying it.”

While social consensus is always the ultimate power, the mechanisms enshrined onchain (e.g., PoS vs. PoG, rollup validating bridge vs. no bridge, etc.) have profound consequences. Social fork coordination can be messy and difficult. Conversely, the momentum will generally be to follow a credible onchain governance mechanism where one is present (e.g., a bridge which may control most of the chain’s assets).

I’ll now walk through the merits of each approach. The table below shows some of the major considerations from the perspective of a “typical” rollup. This is of course inherently subjective.

Again, I’m not saying either PoG or PoS is universally “better” than the other. We need to assess the problem from different vantage points. Ethereum vs. your typical rollup likely have very different priorities, and different mechanisms may better serve those goals. PoS clearly makes sense for Ethereum validators. My goal is to assess the opposite end of the spectrum (sequencers on rollups with active and opinionated governance) to understand the full tradeoff space. Let’s go through it now.

Capital Efficiency

  • DPoS - Inefficient (unable to use the liquid collateral + long unbonding period) → LSTs likely arise.

  • LSTs - Far more capital efficient. Most stake can be represented synthetically and used freely. LSTs trying to support untrusted delegates (e.g., not KYCing and whitelisting operators) may require delegates to place some proportional stake themselves. The unbonding period also introduces some inefficiency.

  • LSTs + Dual Governance - Same as above.

  • PoG - Optimal. Capital isn’t locked at all. All assets stay in their native form and retain full utility and value capture. Value captured can be burned, sent to a treasury, etc. (whatever governance chooses). Productive capital remains liquid. Strike economic arrangements directly with operators.

Allowing for separation of capital and labor vs. slashing incentive compatibility is the fundamental tradeoff:

  • Require delegates to stake - You could try to impose a limit where delegates must put up some personal stake as skin in the game proportional to the stake allocated to them. (E.g., the Cosmos Hub liquid staking module proposal recommends 250:1). This is capital inefficient, and it’s not possible to know if out-of-protocol delegation is helping the validator fulfill their bond. The norm today is requiring no bond.

  • Don’t require delegates to stake - This is the most capital efficient scenario, but it maxes out the principal-agent problem (PAP) for delegates as they do not bear the direct slashing cost.

There’s inherently a pressure to separate capital and labor here, so we see PoS systems gravitate in this direction over time. The strength of this pressure will vary based on several factors including native delegation (e.g., Ethereum does not support in-protocol delegation) and usefulness of the asset (e.g., ETH is top-shelf collateral to be used throughout DeFi).

While LSTs continue to grow in major markets (e.g., Ethereum), it’s possible that chains with highly inefficient markets gravitate less towards LSTs. Maybe nobody cares enough about them (e.g., not worth LSTs’ time to deploy there) and the asset kinda sucks anyway so nobody wants to use it. There are still benefits to the liquidity of LSTs (e.g., don’t need to wait for the unbonding period to be able to sell), but these factors could slow their growth at least.

Permissionless

Bitcoin and Ethereum have permissionless consensus - anyone who meets the specified requirements may start proposing blocks. Note that the degree of “permissionless-ness” is sometimes viewed as a spectrum based on these requirements. Higher minimum stake limits, caps on the total amount of validators, high hardware requirements to mine (e.g., ASICs), etc. are sometimes viewed as “less permissionless”.

Overall though, anyone can join based on some clearly defined conditions within your control. If you meet the requirements, you can join. You don’t need permission from some external body or governance process (e.g., if a protocol requires governance whitelisting to become a validator).

While Ethereum seeks permissionless validator entry, I don’t view this as necessary for rollup sequencers in many circumstances. Indeed, it may even be very positive for rollups to have some form of permissioning here. Hand-picking delegates allows you to select them based on their willingness and ability to enforce conditions which aren’t necessarily programmatically enforceable.

Real-time Censorship Resistance & MEV Protection

Following on that last point, reputable validators can provide the following:

MEV Protection - Centralized sequencers are currently trusted to keep user transactions private, preventing manipulation such as front-running. Chains with permissionless and untrusted validators (e.g., Ethereum) just shift this problem to other trusted third parties (TTPs) such as builders, matchmakers, and fillers. Chains with smaller validator sets can try to hold them accountable for undesirable MEV behavior, as is the plan for dYdX to start. This is even easier if you can explicitly hand-pick each validator.

Real-time Censorship Resistance (CR) - Block proposers who are trusted with seeing builder block contents can modify the blocks. For example, mining pool operators could see megabundles in the clear sent by Flashbots’ MEV-Relay. This allowed them to fill in the rest of the block (preventing censorship) even though Flashbots was censoring OFAC transactions in the PoW days.

Relays and builders only became a censorship chokepoint after the Merge, when PBS moved to a full-block commit-reveal to allow for untrusted validators to participate. While the long-tail of validators can now participate in MEV rewards, they’re unable to enforce CR if they receive these rewards. This is a challenging balance that Vitalik has written about before.

While theoretically these issues can be fixed by the likes of inclusion lists and proposer suffixes, they come with a host of other issues. One is the simple desire to keep the long-tail of Ethereum validators low-resourced (e.g., some of these proposals are incompatible with statelessness). Additionally, it’s unclear if something like publishing an inclusion list with OFAC transactions could weaken the legal argument that proposers are simply neutral infrastructure providers akin to internet service providers (ISPs).

Encrypted mempools and distributed building (e.g., with SUAVE) are other incredibly valuable long-term pursuits here. They can preserve privacy and minimize the power of any individual actor.

Overall, having a long-tail of permissionless operators shifts the MEV problem to unaccountable TTPs and introduces censorship chokepoints at least for the foreseeable future. While both of these can theoretically be addressed via better mechanisms over time (e.g., inclusion lists, encrypted mempools, and decentralized building, etc.), we’re certainly not there today. Electing validators that are willing and able to enforce your desires around censorship resistance may be the clearest path today for some chains.

“Permissionless-ness” and “decentralization” are both means to an end. In particular, we’re generally looking for:

Permissionless & decentralized operators → guarantees for users (e.g., CR)

The end guarantees for users are what really matter. I worry that we’re missing the forest for the trees here:

Permissionless operators → centralized TTPs arise → worse guarantees for users (e.g., censorship chokepoints and front-running)

Our end goal is always the properties that the system offers to users. We need to keep that in mind then ask the best way to get it today. The operators are just service providers that should be accountable to users and serve their needs. Always remember what validators are supposed to be:

Governance-elected and accountable operators may be the easiest way to achieve some of these goals, particularly as the infrastructure matures. Governance can intentionally choose geo-distributed operators who are willing to meet their desired criteria (e.g., not censor transactions or front-run trades).

Governance-elected accountable operators → out-of-protocol actors (e.g., builders) powerless → user guarantees preserved (e.g., CR & no front-running)

I’ll note a subtle but critical point here - it’s not necessarily clear who the “user” is across different domains. While the “user” of a typical rollup is indeed a literal human being who wants to do stuff (make a trade, buy an NFT, etc.), the target “user” of Ethereum may be very different. Specifically, Ethereum may design itself with the assumption that rollups are its primary “users” rather than actual people in the long-run. This would result in a very different set of goals to optimize for (e.g., less concern about handling MEV protection in-protocol).

Any protocol must decide who are the “users” they’re optimizing for and what guarantees they require. We generally want open access (e.g., censorship resistance) for those users. Permissionless block producers are simply a tool to further that goal.

Protocols aren’t made for stakers. They’re made for users.

Governance

This is closely tied to the point above regarding permissionless-ness, so I’ll keep it short. Permissionless-ness is required if you don’t want opinionated and active governance. Ethereum is run by a very rough offchain social consensus that’s moving towards ossification over time. Managing an elected set of delegates to serve as validators clearly wouldn’t be viable.

However, it appears likely that most rollups will have relatively opinionated and active governance mechanisms whether they like it or not. In particular, onchain governance will be necessary to manage upgradeability for their validating bridges. The minimal viable form here would be something like a fast path for emergency halts and a slow path for upgrades. These DAOs are already even electing security council members anyway.

If rollups will have this governance in place anyway, they now have the option to select their operators as well. This governance mechanism could be tasked with electing sequencers in much the same way that stakers or an LST protocol’s governance would.

The exception would be if you wanted a rollup with an immutable bridge contract that holds most of your rollup’s money. Then PoG wouldn’t seem plausible. However, I don’t expect that to be common in practice.

Another scenario is potentially a relative weakening of onchain rollup governance in some cases. Alternatives to the “canonical” bridge such as CCTP (native mint and burn USDC) or adoption of the EIP-7281 (aka xERC20) standard would increase native mint-and-burn. Reducing the tokens passively stored in bridges can meaningfully reduce risk.

This just sets up the interesting question of what is the real “rollup governance” at that point (as opposed to just the “bridge governance”). To my point earlier, you need to consider whether a governance mechanism is “credible” (i.e., who decides a fork).

In any case, I think it’s very likely that this onchain bridge governance will be the de facto rollup governance for most of these chains. These bridges will often hold a sizable portion of rollup assets, and some form of onchain governance will likely manage their upgradeability. You can read more about this power dynamic here and here.

This highlights how important figuring out onchain governance will be. This is especially critical for shared governance, bridge contracts, and upgrades as with Optimism’s plan for the Superchain. The Superchain bridge will have governance powers over all OP Chains in the Superchain with the Optimism Collective controlling upgrades.

Settlement Assurances & Economic Security

Nic Carter had a great post a while back which included the below excerpt:

“Ledger costliness is the most profound and direct variable available to us to evaluate a blockchain’s settlement guarantees. Put simply, it is equivalent to the amount paid to validators/transaction selectors per unit of time.

At the time of winning a block, the miner necessarily has to have burned resources roughly equivalent to the value of the block (typically with a small margin), unless they are extraordinarily lucky. Because of this, miners are incentivized to create valid and rule-following blocks.

So why does more ledger costliness per unit time mean more security for transactors? Because a greater salary to miners (who are presumed honest) means you need a larger army of mercenaries to defeat them.

These resources have to come from somewhere: you need to marshal resources and hardware capable of producing hashes, electricity, and so on.”

Settlement assurances are a system’s ability to grant recipients confidence that a transaction will not be reversed. “Economic security” is generally viewed as the cost to reorg the chain:

  • PoW - Creating blocks to reorg has a real cost (burn energy) ≈ average block rewards. As more blocks pass, the security builds up (cost to reorg increases).

  • PoS - Costless to simulate blocks and create a fork. However, staked validators may be slashed for malicious behavior. The cost to reorg is generally described as the amount of stake you could have slashed.

However, delegation explicitly reduces this cost for the operators. Now it’s the delegators’ stake (not the validators’ stake) that gets slashed. Would you accept $1,000 out of thin air right now if the cost was burning $2,000 of my money? It’s a classic principal agent problem.

PAP - The conflict in interests and priorities that arises when one person or entity (the "agent") takes actions on behalf of another person or entity (the "principal").

Note that a PAP exists in both PoS and PoG. Delegates may act contrary to the interests of the delegators (stakers or governance). Maybe a crazy MEV opportunity comes along and the delegate can make a bunch of money by acting maliciously. They could deviate no matter what we use (note that designs such as MEV-burn can actually help mitigate this “rug-pooling”). The difference is that PoG accepts this PAP and can choose not to extend it to delegator funds.

So, is there any real “economic security” in PoS if it’s not even the operator’s money at stake? Well, it just depends what you mean exactly. It just isn’t quite a 1:1 parallel with the “economic security” in the PoW context.

It’s reasonable to argue that PoS slashing (even if it’s all delegated) is still “costly” in the sense that validators don’t want to lose money for their delegators. But let’s be clear - that’s very different from actually slashing their own money. Anatoly recently posed this question:

This resurfaces many of the discussions around why we still haven’t seen reorg-geth.

Source: Dan Marzec
Source: Dan Marzec

There’s broadly two somewhat related incentives for the PoS delegates here to act honestly:

1) Legal Liability - There’s an argument that validator delegates could have legal liability. Although there isn’t necessarily a clear legal contract between the delegator (staker) and delegate (operator), double-signing would provably violate the rules of the protocol which the user was expecting them to follow. (Not legal advice, I’m not a lawyer, I really don’t know). I personally wouldn’t feel so great using a PoS chain if the validators weren’t publicly known.

2) Reputation - This is a repeated game. Validators have long-term businesses which stand to profit from their continued services. If they nuke their reputation, that business is dead. If they are purely rational actors, they will act honestly so long as:

Reputational value > Profit from corruption

If we view “reputational value” as a strict calculation, then you could rephrase this as:

DCF of future validation profits > Profit from corruption

This gets even trickier to overcome because it’s not isolated. In reality, you would need many operators to collude (enough to comprise the majority of voting power), all of whom lose their reputation. This increases the cost of attack to the sum of their reputational value. There can also be related business lines which would suffer. I imagine it wouldn’t be great for Coinbase’s businesses even outside of staking (and thus their stock price) if they started re-orging chains and nobody wanted them as a validator anymore. I’d probably take my trading elsewhere.

This is all to say that reputation is real. We often treat it like some handwavy thing that doesn’t exist vs. treating delegated stake as perfectly secure and real. The reality is that it can be quite the opposite. Reputation and associated future cashflows are real assets with real value today, and those are the assets that the operator actually has at stake personally.

This was a point that Nic also touched on in the PoW context:

To sum up, outbidding the set of honest miners dutifully producing blocks on Bitcoin is very expensive. They collectively take a salary of $6.9 billion dollars per year right now, and many of them have presumably invested in their businesses in anticipation of future cashflows (meaning that the hardware active on the network might be even higher than current miner revenue would imply).

So Bitcoin is protected not only by the daily salary that the protocol pays its miners, but by the discounted rewards these miners expect to earn in the future. This means Bitcoin isn’t just protected by the reality on the ground today, but miner expectations about rewards in the future.

We don’t have an easy way to model expectations, so the easiest thing to do is to simply take the miner salary per unit time and compare blockchains on that basis.

In summary (didn’t include legal liabilities, because I’m not a lawyer):

  • PoW Miners - There’s an upfront energy cost to revert blocks, and the assumption is that re-orging the chain would also reduce their future revenue (i.e., the chain would become unstable and not valuable).

  • PoS Validators - There’s no upfront energy cost to revert blocks, but re-orging the chain will burn stake (though this is likely delegated and thus not their money). Similarly, validators will lose out on future cashflows they would have otherwise earned (they can be removed from the validator set).

This is my general subjective opinion:

  • Explicit Upfront Cost to Re-org - A lot of the mining pool operator’s hash power can be outsourced, but PoW is pretty cool here and can be pretty responsive on removing delegation. PoS is almost entirely delegated in practice and removing delegation can be more difficult. Burning this stake would only be a cost for the operator to the extent it results in legal and/or reputational consequences.

  • Long-term Cost to Re-org - PoS & PoG are really cool here, especially for publicly-known operators (most of them). Double-signing is a uniquely attributable and cryptographically provable fault. This is a huge plus. This is an iterated game where reputation and future value matter a lot. However, this is not the case for the long-tail of operators (e.g., solo stakers) where the upfront profit from corruption can easily outweigh long-term reputational loss (if any). PoW lacks this level of provable attributability, and there have been accusations of large miners playing games such as messing with timestamps or re-orging blocks on short time horizons where there’s plausible deniability of who was first.

Overall, I don’t think that PoG’s lack of slashing is actually the loss it may seem at first glance. It seems completely unrealistic in practice that the best way to attack a PoS network is to literally go and try to buy up potentially billions of dollars of stake. PoS slashing just becomes a PAP with separation of capital and labor. If PoS funds are all delegated, then the cost of performing a re-org in PoS is:

  • Reputational - Very real and valuable. Attackers lose all future cashflows. Given many reputable operators, this is a very high cost and difficult to coordinate.

  • Potentially legal liability - If you buy the argument that operators are legally liable for funds that they get slashed on behalf of their users (again not legal advice, I literally have no clue), then getting slashed gives them an eventual legal bill.

  • Coordination - It’s simply hard to get a bunch of people together to agree on colluding for something like this if the majority of voting power is distributed well.

Reputation exists equally in both PoS and PoG. Legal liability can be implicit or explicit in either scenario as desired (you can imagine simply having operators sign onchain legal agreements with offchain recourse if they ever double-sign). Subjective operator selection increases the coordination cost if it’s able to get a better distribution needed to reach a majority of voting power.

If it makes you feel better, you can have operators put up a relatively small bond (maybe somewhere in the thousands of dollars, to the point where it’s painful to lose but not worth them raising delegated funds out-of-protocol). If the required bond is too large or uncapped, then you just push stake delegation out-of-protocol. LSTs can pop up exactly as they have played out on Ethereum.

Overall, having ~$40bn currently staked or a trillion dollars staked makes no difference to these.

The cost of corruption is one half of the equation, but now let’s consider the other half - the profit from corruption. I also recommend a great post by Viktor Bunin from a few years back - Proof of Stake’s security model is being dramatically misunderstood.

Some of the often-cited profit motives for reorg-ing a chain tend to include:

  • MEV - there was a gigantic arbitrage in one block, and you want a piece of it

  • Shorting - open a huge short position, attack the network, price falls

  • Exchange double-spending - send money to an exchange, cash out, then reorg

  • Honest majority bridge exploit - lie to the other side of the bridge and print money (e.g., this may have been rational as the price of LUNA plummeted)

In practice, these attacks tend to be unrealistic in most cases. Even more importantly in the context of rollups - sequencers are simply relied upon for less than base layer validators. Rollups are not susceptible to these reorgs once the data is on the base layer. At that point, the base layer (e.g., Ethereum) would need to reorg for the rollup blocks to revert. The ability to reorg (and profit from doing so) is constantly being reset from the rollup’s perspective. Rollups can also prevent honest majority bridge exploits.

Lastly, we might consider an attacker who’s simply trying to break shit. They control delegated funds, and they’re willing to self-sabotage to get everyone else’s stake slashed.

An attacker could manage to take control of a large portion of stake and perform a ransom attack. As Justin Drake recently described on the latest EF Research AMA:

Staking comes with risks that should be taken into account. In September 2021 David Hoffman asked "Why aren't you staking all of your ether?" and my answer (see here) was "When you make the sausage you know how it's made." One of my main worries is ransom attacks (see more detailed explanation below). Ransom attacks are just as relevant today and I'm not sure my 3% APR is worth the risks. (I should note that Puffer's secure signer dramatically reduces the risk of ransom attacks for solo stakers and I may start using that to stake most of my ETH.)

I do believe staking is riskier than most people perceive it to be and that being aware of the risks is healthy. Tail risks are especially easy to underestimate because years can go by with stakers happily earning a substantial yield and then suddenly, out of nowhere, many stakers see themselves losing a large portion of their stake.

The top staking risk is IMO a so-called "ransom attack". Suppose an attacker gets hold of X% of staking keys. (Staking keys are "hot keys", i.e. private keys connected essentially 24/7 to the internet—they are significantly more exposed than withdrawal keys held in cold storage.) The attacker can now setup a smart contract which will trustlessly slash 3*X% of the stake of the compromised validators unless a ransom is paid.

Let's consider a concrete example. Imagine there's a rogue sysadmin within Coinbase Cloud who manages to get hold of the staking keys for the 10% of Coinbase Cloud validators. (Notice that the rogue sysadmin doesn't need access to the withdrawal keys held in cold storage.) The sysadmin is now in a position to slash 3*10% = 30% of Coinbase's validators (roughly 0.63M ETH, or $1.2B). The attacker now sets up a smart contract to trustlessly slash the ETH unless a $1B ransom is paid. The rational move for Coinbase Cloud (and possibly its fiduciary duty) is to pay the $1B ransom (recuperating $200M of the $1.2B), and Coinbase Cloud users see themselves losing 25% of their stake in one fell swoop.

There are other scary scenarios where an attacker can get hold of a large percentage of staking keys and perform a similar ransom attack:

  1. An inside job in one of the top consensus clients. For example, a rogue Prysm or Lighthouse dev could insert some subtle bug or backdoor.

  2. A supply chain attack targetting one of the libraries used by Prysm or Lighthouse. This could be combined with an inside job for plausible deniability.

  3. An accidental remote code execution in a particular operating system. Apple now routinely posts Rapid Security Responses, often in response to actively exploited bugs. Linux and Windows likely also suffer from crippling 0-days.

Ransom attacks turn Ethereum staking into a multi-billion dollar bug bounty program. 0-days previously sold for millions of dollars on the dark web could now be weaponised for hundreds of millions.

These tail-risks increase when slashing risk is packaged up and distributed with financial products (i.e., LSTs) which lay the foundation of DeFi. This risk is further heightened with the advent of restaking, which can subject this stake to many additional slashing conditions external to the core protocol. These harmful actions may even be accidental - simple errors resulting in slashing are more likely when adding on new services. This is precisely why safeguards will be used, such as councils with the ability to veto accidental slashing and other mechanisms to prevent accidental double-signing.

Overall, it seems that reputational and legal risk are the primary assets really at “stake” here for operators (i.e., the cost of corruption). The profit from corruption is generally too difficult to achieve in practice regardless. Self-inflicted attacks (e.g., ransom attacks) may be more likely than the more often-cited profit motives for a majority attack (e.g., double spending). While staking is intended to increase the cost of corruption, it can also increase the profit from corruption. Removing staking and associated financial products layered on top reduces that leverage and tail-risk when they aren’t needed.

Accountability - Slashing vs. Removal

I would then argue that the more important accountability mechanism in PoS > PoW is not the ability to burn funds, but rather the ability to remove the attacker in a targeted manner. PoW requires the nuclear option (brick the hashing algorithm). PoS allows you to more precisely remove the attacker. PoG retains the same ability to remove only the attacker. You don’t light their delegates’ money on fire, you just kick the bad actor out.

This also makes socially forking to remove these censoring validators meaningfully easier in practice. The classic hypothetical example was the debate that followed the onset of the OFAC-related censorship issues last year:

There was strong consideration that if the majority of validators began actively re-orging blocks with OFAC transactions, they should be forked out. This presumably would’ve been done via a user-activated soft fork (UASF) to inactivity leak them out (though a hard fork to simply burn their funds would also be possible).

However, this of course would be a highly contentious debate with severe consequences. Would we actually be willing to destroy the majority of users’ funds on this fork? Should we really be penalizing every random user who delegated their ETH to a large validator that complied with regulators if they were mandated to censor?

If large validators weren’t just custodying entirely users’ delegated funds, I would argue that a UASF would be far cleaner and less contentious. Simply fork and remove the censoring operators if you don’t approve of them any longer. Removing stake from the equation (effectively held hostage) empowers governance (offchain social consensus in Ethereum’s case) to easily hold the operators alone accountable.

In the same way that PoS enables more targeted accountability than PoW, I think the same can be said for PoG over PoS. You can simply excise the attackers’ personal assets (their reputation, i.e. future cashflows) rather than also inflicting collateral damage on their delegators’ assets (i.e., slashing users’ funds).

This can increase the credibility of such a threat.

The credibility of what the protocol is willing to defend was explored more broadly in Barnabé’s phenomenal article Seeing like a protocol - Where does protocol credibility come from?:

To create credibility here, casting the spell of extending the protocol’s boundaries with further introspection and agency is not enough, if other institutions work towards eroding credibility by shifting incentives of the protocol’s agents. Credibility is fully obtained whenever it is clear that the community is willing to defend the protocol’s preferred outcomes in the last resort, forcing the outcomes it cares about even at the cost of forking out part of the validator set.

Removing Censoring Delegates

Let’s now look at the specific mechanics of removing operators guilty of double-signing - the fundamental in-protocol violation for a consensus protocol. There are two subsets of this - proposing multiple blocks in a single slot (equivocation) and submitting contradictory attestations.

This penalty provides varying degrees of weight depending on the scenario:

  • Proposer equivocation - The proposer commits to one block (e.g., sign a header sent by a relay) then equivocates to sign another block in the same slot. Proposer slashing for equivocation (e.g., to perform an unbundling attack) is a rather weak deterrent unfortunately. The profit from attack (millions in the case of the Low-Carb Crusader) can easily outweigh the small slashing penalty against some of their 32 ETH balance. This can be addressed by more robust mechanism design which makes these games nearly impossible.

  • Consensus double-signing - Once the rest of the consensus set signs on a proposer’s commitment, you now have a much stronger commitment. Now you can hold many validators accountable if all attesters sign off on conflicting blocks. If two forks independently meet the ⅔ quorum typically needed to finalize, then at least ⅓ of all stake must have signed on both forks. This ⅓ balance is potentially slashable. The signatures can be presented onchain to prove double-signing.

Social consensus generally enforces censorship resistance (CR) on a long time horizon via the threat of forking. This could be a hard fork to explicitly remove the offenders, or it may simply be a user-activated soft fork (UASF) to inactivity leak them out as mentioned earlier. In any case, the big difference here is that social consensus must step in to enforce long-term CR vs. double-signing is automatically slashable because it is provable in-protocol.

However, an often overlooked point is that a malicious majority of delegates can simply censor the transactions which prove double-signing. If an attacker controls ⅔ of voting power (in either PoS or PoG), they could simply ignore and build around any blocks which would include the transactions to prove double-signing and have them slashed. Automatic slashing for double-signing is most valuable in the event of a malicious majority attack, but that’s also unfortunately when it’s most likely to fail.

Similarly, the malicious majority could censor the slower paths to remove them:

  • PoS - Attackers can refuse to include any transactions from delegators attempting to remove their delegated funds from the operator.

  • PoG - Attackers can refuse to include any transactions from governance attempting to vote them out as operators.

This is where one of the superpowers of rollups comes in - you can forcibly remove the malicious operators via the rollup’s base layer. Rollup forced inclusion mechanisms are often discussed in the user mass exit scenario (where they bridge out all funds because the sequencer is censoring them). However, this forced inclusion method could be used to remove the sequencer.

  • Monolithic blockchain - Majority censorship would require social consensus to kick in and remove them

  • Rollups - Because rollups can delegate their CR to another layer (their DA layer), they can use this to forcibly remove their operators onchain (even if they’re malicious)

Decentralization

Regardless of the staking design, we see a clear separation of capital (stake) and labor (validator operators). So let’s ask what PoS is providing then:

  • ✅ Sybil Resistance / Delegation - Users elect operators they trust by delegating stake to them. If this is managed by an LST provider, then the LST’s governance in turn is actually choosing the delegates.

  • ❌ Slashing Penalty - The slashing penalty no longer directly applies to the operators themselves if funds are delegated. The delegators’ money is at risk.

We’re back to that point I made earlier - PoS is fundamentally used for electing delegates. The ability to burn funds is an optional feature. Staking forces delegators to have skin in the game though, incentivizing them to pick good operators so they don’t get slashed. If PoS is primarily about picking delegates, then we need to ask what will yield the better decision:

  • DPoS - Token holders vote for themselves. They directly vote on personal funds. Tragedy of the commons (i.e., top-heavy stake distribution).

  • Governance (PoG or LST) - Governance votes for the collective interest. Voters do not put personal funds at stake. They vote for the best overall composition, not just the best delegate for their personal funds.

WTF is decentralization though? Simon Brown recently gave a great presentation at Flashbots’ PBS Salon on Measuring the Concentration of Control in Ethereum.

For our purposes here, I’ll keep it simple and look at two high level points:

1) Number of total validators - The total number of consensus participants. This says nothing about their distribution of voting power.

By this measure, the below voting power distribution would be very "decentralized”:

2) Distribution of voting power - This is mostly commonly measured by something like the Nakamoto coefficient, but broadly we’re talking about how distributed is the top chunk of stake (whether ⅓, ½, ⅔, etc.). We don’t consider the bottom minority stake here, we just look at how many people need to collude to cause a liveness/safety failure.

By this measure, the below voting power distribution would be very decentralized:

Ethereum is undoubtedly decentralized on #1 - there are over 700k active validators. Even though the vast majority of them are run by shared entities, the number of actual operators running Ethereum consensus is still in the single-digit thousands. That’s still incredibly high. “However, “solo stakers” (running <200 validators and not part of a major organization) comprised ~6.5% of Ethereum’s total stake from the Merge through the end of 2022. That number also seems likely to decrease over time in my opinion.

The importance of long-tail validators is a point of common debate, but it’s generally viewed as desirable in Ethereum. The scenario where this long-tail may be particularly valuable is for a liveness-favoring chain that’s going through a doomsday-type scenario. Ethereum of course optimizes for these conditions.

For example, let’s say there’s a big war going on and major countries partition the network. Or maybe the minority of validators actively choose to initiate a UASF to remove a censoring majority of validators. In either case, this long-tail of validators would continue to progress the network while the majority gets inactivity leaked out. The network would remain live at all times, and it would begin to finalize once the majority of stake has been leaked out. This affords Ethereum the option of removing attackers via UASF while retaining liveness (as opposed to needing to resort to a hard fork).

While the above is a fun point of debate, this scenario doesn’t apply for the vast majority of chains. For any chain that favors consistency (safety), your chain will just halt if a quorum isn’t reached. It doesn’t make any difference if you have some at-home stakers comprising a few percent of the total voting power. Rollups will generally fall into this bucket (as will most chains).

Rollups are likely to make the opposite tradeoffs, complementing Ethereum’s consensus. They will tend to favor fast finality (optimistic responsiveness) rather than dynamic availability (which Gasper achieves). Think something that looks more like Tendermint.

A long-tail of validators may also be helpful for turning “strong censorship” (never included) into “weak censorship” (included, but with a delay). For example, even if 9 out of 10 validators are censoring, then you’ll on average be included by the 10th block. However, note that this can be prevented if the censoring majority decides to simply ignore the minority-produced blocks, as they have enough voting power to finalize without them. Additionally, rollups should already inherit “eventual” censorship resistance (CR) from their base layer. Sequencers are primarily tasked with real-time guarantees, so the distribution of the majority of voting power is what actually matters.

Overall, I don’t think this long tail of at-home sequencers would add much to most rollups, and they’re not likely to even exist often (especially in a world with many rollups). Rollups are already paying Ethereum consensus for this long-tail decentralization and disaster scenario recovery among other things.

Back to those pie charts I showed you earlier, that second one was actually the distribution of stake under the hood allocated amongst Lido operators:

Source: VaNOM, Q1 2023
Source: VaNOM, Q1 2023

This is exactly the kind of distribution that’s optimized for real-time security. While PoS can easily support a long-tail permissionless validator entry, it tends to result in a top-heavy validator selection as described above. Subjective governance processes which decide as a collective can optimize for the best overall set of delegates. Protocols like Lido can and do impose strict requirements on decentralization within their operator set (e.g., stake distribution, geographical distribution, client diversity, cloud services, etc.).

The endgame for decentralized Ethereum validators is likely to take the shape of something like Lido’s Staking Router. This upgrade allows for running any arbitrary staking “module” under the hood for Lido, including those which would allow for long-tail bonded validators.

Historically, Lido has been very simple and scalable. Users’ ETH deposits are delegated to a curated Node Operators Registry (NOR) - that’s the pie chart you saw above. While this is highly capital efficient, it’s not very flexible in allowing for different staking models.

With the introduction of the Staking Router, the NOR becomes the first module within Lido. Anyone can make a proposal to the Lido DAO to onboard any other module. For example, this may be a module where stakers run DVT. These proposals would come with the associated technical plans and business cases for the DAO to approve. They can even have independent fee mechanisms (rather than the standard 90% / 5% / 5% split between stETH / operator / Lido DAO for the NOR). The Lido DAO will assess these proposals and decide on the stake delegation between different modules.

Source: Introducing Lido V2 — Next Step In Decentralization
Source: Introducing Lido V2 — Next Step In Decentralization

As with dual governance, LST protocols have a balance of incentives here:

  • Economic efficiency - It’s simple and scalable to run all stake under one entity (e.g., Coinbase’s cbETH)

  • Decentralization - It’s more complicated to manage a large set of trusted operators, a module for untrusted DVT stakers, etc.

However, a decentralized LST protocol that’s aligned with the underlying chain may be able to safely grow further. As Hasu described on a recent episode of Bell Curve:

“Decentralization for many systems can be seen as a form of sacrifice… but in staking protocols, this does not apply… The more decentralized you can make it, the better it gets, because it’s so much about neutrality and trust. And this is why for Lido decentralization is not a sacrifice of anything, it’s extremely good… It’s the number one priority in the sense that it’s not a defensive move. Decentralization for Lido is offense.”

LST governance is able to handle the functions that Ethereum is unable to. In particular, LST governance can manage the additional subjective incentives required to decentralize operators (e.g., different modules may receive different fee rates). Free market economics do not lead to a long-tail of solo stakers or uniform stake distribution in the long-run.

The Ethereum core protocol is largely built on the notion that it should be objective and un-opinionated whenever possible. However, subjective management and incentives will be required to achieve a decentralized operator set.

While governance minimization is often desirable, some minimal form of governance will always likely be necessary for LSTs. Some process is needed to match the demand for staking with the demand to run validators. LST governance will always be needed to manage the objective functions of the node operator set (e.g., targets on stake distribution, different module weighting, geography targets, etc.). This fine-tuning can be infrequent, but this high-level goal setting is critical for monitoring and maintaining the decentralization of the operator set.

Delegation Control

All of these are mechanisms for electing delegates, so we need to consider who is given the power to choose the delegates here:

  • DPoS - Token holders vote with their feet via direct delegation. This is decent alignment of interest - you’re at least incentivized to vote for a good operator. However, it’s often incredibly centralizing - users tend to select the largest operators.

  • LSTs - LST governance will now decide how to delegate the funds to stakers instead of the actual LST holders. This is problematic - LST governance and rollup governance may be misaligned.

  • LSTs + Dual Governance - The issue above can be greatly mitigated with a dual governance proposal as has been discussed for Lido. This proposal would provide some mechanism for Ethereum-aligned participants (e.g., stETH holders) to veto actions taken by the Lido DAO. This provides LST holders meaningful agency to protect the consensus layer against a potentially misaligned LST DAO. Sacha had a great presentation on the topic here.

  • PoG - Rollup governance just elects the delegates themselves. This gives them the highest control and incentive alignment. This also preserves the ability for a rollup to use a governance mechanism other than simple majority token voting. For example, Optimism is experimenting with creative governance mechanisms that go beyond simple token voting.

I view some form of dual governance as necessary for an LST protocol to be viable long-term. However, it’s still imperfect, as noted by Danny Ryan in The Risks of LSD:

“It is important to note here that ETH holders are not by definition Ethereum users, and in the long run, we expect that there are massively more Ethereum users than ETH holders (people with ETH held beyond the amount needed to facilitate TXs). This is a critical and important fact that informs Ethereum governance – there is no on-chain governance granted to ETH holders or stakers. Ethereum is the protocol that users choose to run.

ETH holders in the long run are just a subset of users, so staked ETH holders are even a subset from there. In the extreme of all ETH becoming staked ETH under one LSD, governance vote weights or aborts by staked ETH do not protect the Ethereum platform for users.

Thus even if the LSD protocol and the LSD holders are aligned on subtle attacks and capture, users are not and can/will react.”

However, as Hasu pointed out in Do stakers represent users?:

First, the observation “users and block producers are not the same group” is completely orthogonal to whether stake is delegated or not. It’s simply a property of PoS and all other known Sybil resistance mechanisms (except maybe proof of humanity which is unworkable for other reasons).

TLDR: “Stakers don’t represent users” is a true observation but one that exists in PoS and all other consensus systems. LSD-PoS is not to blame and in fact makes the problem better, not worse.

PoS gives the delegation control to token holders, not the superset of users or the chain’s community. I think most of us would agree that simple token holder majority governance isn’t the ideal solution either:

However, PoG allows your chain to use any governance process to make the decision. Optimism recently announced its plans to give its Token House powers over sequencer selection while the Citizens’ House (identity-based governance) has veto rights.

Source: Doing Decentralized Identity Right, Kelvin Fichter
Source: Doing Decentralized Identity Right, Kelvin Fichter

Governance should also have the power to quickly swap out the elected sequencers if needed (e.g., if they start acting counter to governance’s desires).

Allowing rollup governance to directly control the sequencers appears meaningfully beneficial. This also allows rollups to experiment with creative (less plutocratic) governance mechanisms for delegation other than simple token voting.

Even if simple rollup token voting governance is used to select operators, this will often still be preferable to staking. Stakers are incentivized to pick the biggest validator when it’s their own money in native delegation. Subjective governance processes such as what Lido does are far better for operator decentralization.

The question then is whether rollup governance should handle operator selection or implement PoS and let LST protocols take the reins. You could also get creative with dual governance if you go the PoS route. While Ethereum has no onchain governance that Lido can give veto rights to, LSTs elsewhere may instead grant veto rights to their onchain governance mechanism (rather than just the LST holders). One argument for PoS over PoG is that LSTs at least “free-market” and there can be several, though in practice LSTs are likely to be winner takes all/most.

For a rollup with competent enough governance mechanisms, simply bringing the delegation in-house seems desirable. Outsourcing power over consensus layer operations seems unnecessary. Go pick a bunch of people you trust in your community, go handpick a bunch of geographically decentralized ones, etc. The absolute minimum is likely to be a single default sequencer live at a given time with a list of pre-elected hot backups ready to automatically swap in if there’s any CR or broader liveness issues.

The real value-add of LST protocols here in my mind is the ability of a specialized protocol (e.g., Lido) to pick all your operators for you in the event that your own governance simply doesn’t want to or is too incompetent. This is a valuable service that can be replicated without staking and delegation of funds though.

PoS vs. PoG Economics 101

Let’s consider two hypothetical scenarios for a rollup:

  • LST + Dual Governance - An LST protocol captures all stake, and they pick delegates to operate the rollup. 90% of rewards go to LST token holders (e.g., stOP), 5% goes to LST governance (e.g., controlled by LDO), and 5% goes to the operators (e.g., Coinbase).

  • PoG - Governance elects the exact same delegates that the LST protocol would have selected. They make a direct agreement to pay out inflationary rewards equivalent to what they would have made as LST operators. All fees and MEV are burned.

Here are some hypothetical numbers to illustrate the major differences:

In both scenarios:

  • Income - $50mm of fees and other MEV in excess of what it pays to the DA layer

  • Operator Costs - Operator set requires $30mm p.a. (LST scenario - paid as 5% of all rewards. PoG scenario - paid via lower inflationary rewards going only to them).

For the differences, PoG comes out ahead. LST governance takes 5% of all rewards here ($30mm). This is their payment needed to manage a responsible operator set, fund operations such as possibly incentivizing LST liquidity, take a profit, etc. If the rollup has its own governance though, it could internalize this work rather than leak value out to LST protocol governance. Other staking operators like Coinbase (for cbETH) charge a whopping 25% fee rate. There’s no reason for a protocol to be subsidizing this amount of value for large operators.

Overall, the PoS scenario pays out $30mm to operators + $30mm to LST governance = $60mm. They only capture $50mm in revenue in excess of DA layer fees. The $10mm shortfall is borne by all token holders via excess issuance.

Rather than distributing fees and MEV to stakers, the PoG scenario burns all of them (you could equally imagine them sending it to a rollup treasury, funding public goods, or whatever else they want). Because this is $20mm greater than the inflationary rewards paid to operators, the rollup token is net deflationary at the end of the year. Assuming a flat market cap, the token price increases.

Additionally, high payment of issuance rewards consistently leaks value. Staking rewards may be treated as income in many jurisdictions (not tax advice). To the extent that they are, you’d consistently leak value to taxes and associated sell pressure. Whatever is paid out will potentially be taxed at a high rate. Minimum viable issuance is maximally tax efficient for keeping value within a given ecosystem.

Finally, staking rewards overall lead to concerning distributions of wealth. They unnecessarily hand value to large capital holders, tax collectors, and institutional staking operators. These are exceedingly plutocratic mechanisms with even worse wealth distribution than present-day systems in many ways. We often don’t like to hear this in crypto, but a more creative and potentially subjective distribution of capital is an absolute must (e.g., Optimism’s RetroPGF). Blindly giving rewards to large stakers who don’t actually contribute to the economic growth of the system is simply a poor use of capital.

It’s also an odd incentive. I am clearly incentivized by a PoS protocol to go give my money to a staking provider that then gives me an LST in return. They will hand my stake to some delegate with no skin in the game, and I go play with my financial product. Did I actually contribute to the chain’s “economic security” in this case? Or am I just being paid for taking on smart contract risk and levering up the system?

The primary value-add from PoS here is in my mind not the “economic security of slashing,” but rather the services offered by LST protocols. And I’m not talking about the liquid staking token. That’s not their product here. Their product is outsourced management of a decentralized and robust set of operators. Ethereum has no governance mechanism in place to do this. LST protocols can do a far better job than free market economics would lead to, and they’d potentially do a far better job than many chains’ own governance mechanisms would as well. Governance is hard.

Endgame - PoS vs. PoG Summary

PoG and PoS end up with striking similarities if you play out the economic incentives to their logical conclusion:

  • Total separation of capital (stake) and labor (operators)

  • Operator selection and delegation is managed by governance aligned with the chain (e.g., dual governance or PoG)

Let’s walk through that table again and recap the merits of each approach here (from the perspective of a “typical” rollup):

  • Capital Efficient - DPoS is super capital inefficient. LSTs alleviate the vast majority of this inefficiency. The free market tends toward economic efficiency over time. PoG is optimal on all dimensions.

  • Permissionless - PoS allows for “permissionless” entry in that anyone can buy up stake and become a validator (this is a spectrum though, subject to validator caps, staking queue, etc.). PoG is “permissioned” in that you need governance approval to become a block producer.

  • Real-time CR & MEV Protection - Known operators can be hand-picked to meet your requirements then held accountable. This empowers them to enforce guarantees such as real-time CR and MEV protection which may not be attributable in-protocol. Completely permissionless and untrusted validators tend to push these chokepoints offchain to unaccountable actors.

  • Governance - Some form of governance is of course required in PoG to manage the operator set. This is undesirable for chains like Ethereum that try to be as hands-off and neutral as possible. This seems to be less of a concern for most other chains though which are likely to have some form of governance whether onchain or offchain, however minimal.

  • Accountability - PoS allows you to slash operators’ money who are acting in an undesirable manner vs. PoG only allows you to remove them. The latter seems less “economically secure” on the face of it, but the reality is that funds are effectively all delegated → operators’ real personal “stake” is primarily reputational (future cash flows) and possibly legal (but idk).

  • Decentralization - It’s possible for certain PoS designs to more naturally support a long-tail of validators which is potentially helpful for CR and liveness. However, subjective targets set by governance (either an LST’s or the underlying chain’s) can enforce far better stake distribution on various metrics, increasing real-time CR and liveness. Free market economics otherwise consolidate stake. Note that it would also be technically possible to build functionality similar to Lido’s staking router into a given chain’s own core functions.

  • Delegation Control - You can give this power to stakers (DPoS), external LST governance, or your own governance (which can be whatever you want!). The latter often seems preferable to me. If external LSTs are to be used though, they require significant attention to minimize and align their governance with the underlying chain.

  • Economic Overview - Staking can lead to excess value leaked to delegates, LST providers, and the tax man. This seems like a generally inefficient and poor distribution of wealth. PoG gives your chain a chance to get more creative and less plutocratic.

Restaking & PEPC

So, if I’m questioning the fundamentals of staking, what does that mean for restaking?

The Use Cases for Restaking

In this section, I’ll first summarize Sreeram’s recent description of EigenLayer as a “marketplace for decentralized trust” on another great episode of Bell Curve. He describes three elements of decentralized trust that restaking can offer to Actively Validated Services (AVSs = services provided by EigenLayer restakers):

1) Economic security - Typical PoS staking economics. You could restake say $1bn to secure some application. If the restakers misbehaved, this can be slashed. You don’t care much whether this is 1 person with $1bn staked or 1 million people with $1,000 each staked.

2) Decentralized operators - You want many distributed nodes that make collusion difficult. This could be useful for something like Shamir secret sharing - you distribute pieces of a secret to many participants, and a majority of them is needed to put it back together. You can’t slash them because this is a non-attributable fault if they collude.

Note that “economic security” and “decentralization” aren’t at all unique to Ethereum restakers. You could equally bootstrap these in some other way, even using assets like RWAs as collateral.

The specific relation is primarily due to the fact that Ethereum happens to have the largest amount of staked assets sitting around, so it’s easiest to piggy-back off of it. If I’ve got some stETH sitting around, you probably won’t have to twist my arm to go restake it. Some delegate can take my money, use it to validate an AVS, and make me more money. If you want to bootstrap some capital for securing your AVS, you can get it pretty easily.

Pooling security is often viewed as beneficial. The argument is that it’s much harder to attack a committee with $100bn at stake vs. a committee with $50bn at stake.

While we can see that restaking could help bootstrap staked assets, it’s less clear that restaking helps to easily bootstrap decentralized operators. As a delegate with some stETH, I just care about capital costs. My additional capital cost is 0 if I’m already holding some stETH. However, the operator’s additional cost is unchanged.

It’s just as much work for an Ethereum validator to integrate some random unrelated new AVS using restaking vs. if that application was launched as a self-secured app-chain. They need to get a team up to speed, get the software running, monitor it over time, etc. There are real overhead costs and ongoing work associated with this. Whether it’s restaked or self-secured makes effectively no difference to their operational burden.

3) Proposer commitments - This third point now is unique to Ethereum (or more generically, unique to the chain of the restaker making the commitment). Restaking is clearly valuable when you want a credible commitment from a specific chain’s proposer. For example, you may want the Ethereum proposer to commit to follow a certain transaction ordering in their block, sell you the first N% of the block, commit to triggering liquidations on a lending protocol under certain conditions, etc.

Protocol-Enforced Proposer Commitments (PEPC)

Those proposer commitments via restaking are also precisely the idea behind Barnabé's PEPC (protocol-enforced proposer commitments). Note that PEPC is very much still in the research phase without a concrete spec, so the below is rather exploratory thinking at this stage.

Rather than having Ethereum validators opt into out-of-protocol commitments (e.g., via EigenLayer), the idea here would be to enshrine a mechanism that allows proposers to do this natively. Proposers would be able to opt into binding arbitrary commitments over the blocks they propose. This can be viewed as a generalization of PBS.

The critical difference between PEPC vs. restaking is the first half of that acronym - these proposer commitments would be protocol-enforced. Attesters would reject a block as invalid if a proposer doesn’t fulfill a commitment they opted into.

This is a much stronger enforcement vs. out-of-protocol restaking where the only recourse is to slash the proposer. The validity of the Ethereum block wouldn’t be dependent on the proposer commitment with restaking. As mentioned with the Low Carb Crusader, the profit from deviating can outweigh the associated slashing costs. Note that restaking applications can circumvent Ethereum’s 32 ETH limit though, requiring pooling of much higher stake to form a single operator of an AVS (e.g., maybe 10,000 ETH is required to be a validator on my new chain secured by restaking)

For more details, please see Barnabé’s amazing new post on PEPC.

The Real Use Case for Restaking

With the background in place, I’ll now provide my own opinion here:

  1. Economic security - As you can probably imagine based on my earlier arguments, I think this economic security point gets way too much attention. I don’t get the sense that many AVSs actually care about this aspect that much either. You can also pledge any asset, not just ETH.

  2. Decentralized operators - This is clearly valuable, but as described above this has nothing to do with Ethereum. You can sign up any set of decentralized operators without them committing to also being Ethereum stakers. Ethereum is once again just a natural place to find a bunch of operators.

  3. Proposer commitments - This is clearly a valuable concept, as evidenced by exploration of PEPC. In the absence of an in-protocol mechanism, this makes a ton of sense for restaking.

So, I see the real use cases for restaking actually coming down to two buckets for the most part:

  1. Technical (proposer commitments) - There’s no way around this - if you want a credible commitment to the ordering of an Ethereum block, it’s gotta come from Ethereum validators. MEV-Boost++ is one example of a hypothetical application that could fall into this bucket.

  2. Social - I view Ethereum alignment as the primary use case for most restaking applications today, not pooling of economic security or decentralization. It’s getting to say “look we’re an Ethereum project!” It’s much the same reason why chains keep calling themselves Ethereum L2s regardless of the architecture.

Being an “Ethereum-aligned” project or an “Ethereum L2” is seemingly more of a vibe than anything else at this point. That’s not even a criticism (at least for the well-intentioned ones who are clear about it). Incentive alignment can be a legitimate point. These are incredibly social systems we’re building, and everyone wants to sit at the cool kids table (especially when there’s roughly one lunch table of users in crypto right now).

As an aside, this actually gives me quite a bit of comfort regarding the whole “restaking alignment” fear going around lately. This potentially self-selecting nature of restaking could mitigate the probability of tail risks. If AVSs use restaking primarily for the Ethereum alignment, then you’re not going to use it if the whole Ethereum community would freak out at you for using it.

The centralization fear is that someone could launch an AVS that’s super valuable but difficult to run operationally (e.g., a Solana fork). However, I think a lot of use cases would naturally filter out. I don’t believe most of these AVSs mentioned today benefit from the “economic security” as much as we keep touting. It appears far more social. You’d be launching Solana on staking to say “hey look we’re Ethereum aligned.” If that’s the case, this ceases to be a benefit (and indeed becomes detrimental) if using restaking would be viewed as misaligned with Ethereum.

This self-selection doesn’t address technical cases where proposer commitments are necessary, or if some other application intentionally uses restaking maliciously despite negative social pressure. So it’s not a solution by any means, but I do think that it directionally mitigates some of the fear of a creeping problem.

Looking further ahead, I believe it would be incredibly valuable to explore various forms of dual governance in the context of restaking.

Conclusion

PoG is far from perfect, and it’s certainly not a fit for everyone. However, it’s instructive to consider where it may be reasonable so that we can better understand the properties applicable to all chains.

I realize that saying “oh yea just let governance decide” isn’t exactly the most confidence-inspiring thing given the state of most crypto governance.

However, the alternative is “oh yea just let free market economics hopefully result in decentralization” or “let someone else’s governance do it for you.”

I generally favor governance minimalism when possible. PoG is not an attempt to expand the reach of governance. It is rather an acknowledgment that this governance must necessarily happen regardless.

The choice is simply whether that governance managing a chain’s consensus operators should be outsourced to the free market (i.e., between LST protocols’ governance) or in-housed within a chain’s own governance. I think both approaches are reasonable under different circumstances.

Some minimal governance will always be needed to manage decentralization targets among operators and provide a fallback response in extreme scenarios. From there, the free market can handle the specific implementations and associated economics (e.g., as in the case of Lido’s Staking Router).

I worry that many rollup teams’ currently expressed plans for “permissionless” mechanisms optimize for the nice word but may fall very short in practice. Many designs such as variations of MEV auctions or prover races are likely to be extremely centralizing in practice with entirely unaccountable out-of-protocol actors. The free-market economics left unchecked do not tend towards decentralized participants, and they may be hard-to-impossible to remove once in place.

Some of these designs appear to choose a poor place on the tradeoff spectrum - they take on Ethereum’s current weaknesses (e.g., no MEV protection by default + relatively centralized out-of-protocol and unaccountable actors who present censorship chokepoints) without gaining the benefits that Ethereum derives from having made this tradeoff for the sake of permissionless-ness and neutrality.

Yes, the long-term answer to many of these issues is all the fancy ZK encrypted mempool threshold FHE one-shot signatures for distributed intent matching and blah blah. But we’re not there today.

Plus, if we can figure out all this crypto governance stuff maybe we can use it to replace our governments IRL.

Disclaimer: The views expressed in this post are solely those of the author in their individual capacity and are not the views of DBA Crypto, LLC or its affiliates (together with its affiliates, “DBA”).

This content is provided for informational purposes only, and should not be relied upon as the basis for an investment decision, and is not, and should not be assumed to be, complete. The contents herein are not to be construed as legal, business, or tax advice. References to any securities or digital assets are for illustrative purposes only, and do not constitute an investment recommendation or offer to provide investment advisory services. This post does not constitute investment advice or an offer to sell or a solicitation of an offer to purchase any limited partner interests in any investment vehicle managed by DBA.

Certain information contained within has been obtained from third-party sources. While taken from sources believed to be reliable, DBA makes no representations about the accuracy of the information.

The author of this report has material personal investments in stETH, ETH, and EigenLayer.

]]> jon-dba@newsletter.paragraph.com (Jon Charbonneau) <![CDATA[The Rollup Multiverse]]> https://paragraph.com/@jon-dba/the-rollup-multiverse W82L0GXb2lbiU0xxaGs3 Tue, 30 May 2023 17:38:17 GMT Thank you to Patrick McCorry and Kobi Gurkan for the invaluable feedback and review.

Introduction

I like rollups so I’m writing another thing, sorry.

I’m pretty sure it’s helpful because I’ve gotten a ton of value out of these myself. Just writing it all down and talking to people like Patrick and Kelvin who have amazing mental models has been awesome. There might be a double-digit number of people crazy enough to even want this level of intuitive understanding of these systems, but if you’re one of ‘em hopefully this helps.

This time I’ll more directly address why the rollup ≠ bridge rambling is important, since I probably could’ve done a better job of explaining the practical and social implications more plainly in my last post.

A few people got a tad upset at that one. Not my intention, but it wasn’t the first time and won’t be the last.

Some of it was a lack of understanding of how rollups work, but others were more reasonable - that the post was technically accurate, but it’s not reflective of the current reality, and hair-splitting over definitions will create more confusion.

I can appreciate the latter sentiment, because reducing confusion is my explicit intention here. The first obvious point is that these aren’t children’s books.

That post was a technical look into the fundamental security and social consensus properties of rollups that takes over an hour to read if you go at it non-stop. Though some already had pretty strong opinions ~20 minutes after posting it 😉. It’s aimed at the reasonably technical audience responsible for building rollups and shaping the messaging around them.

First, to be clear:

I’ve always considered myself very Ethereum-centric. It’s quite apparent from where I spend my time, and honestly most of my crypto bags are just ETH. This isn’t a FUD rant. It’s a short (for me) rant on the following:

  • The current understanding of how rollups fundamentally work is inaccurate and misleading - it is itself the cause of much confusion today

  • This framing is based on a microcosm of what we see in front of our eyes, and it will clearly change very soon

  • A new framing can be incredibly helpful to fundamentally understand why these systems are so great

  • The possibility of a rollup forking is a feature, not a bug

  • Why we’re stuck on it, and how to improve it

Our Current Framing is Harmful to Users

The focus of this whole framing:

The bridge is an incredibly important piece of how rollups like Optimism and Arbitrum work, but it is not the rollup itself. This may seem like semantics, so I’ll be concrete.

It’d probably be fine if this description was stretching reality but it actually worked. However, in reality it’s misleading:

It should be obvious why this is. If we keep telling users that “the rollup is the bridge” and the “settlement layer L1” (Ethereum here) is this god that determines the truth, then users will naturally be led to believe that L1 + rollup bridge = safe. That’s quite clearly the message.

Assets That Live Natively on Both Chains

Unfortunately, the reality is quite the opposite. Rollups can inherit their base layer’s (e.g., Ethereum) security without the bridge. For assets that live natively on multiple chains, the native representation is always safer than their lock-and-mint bridged representation.

The bridged asset is just an IOU from the bridge. That’s why versions from different bridges aren’t fungible. As an example:

  • If I hold native USDC minted on a rollup - I trust Circle

  • If I hold bridged USDC minted on Ethereum → bridged to the rollup - I trust Circle and the rollup bridge

Circle is itself effectively a bridge from the real world (they bridge real-world USD into onchain USDC). CCTP will also allow for permissionless burning of native USDC on one chain and minting native USDC on another. As mentioned in my last post:

In this case, Circle must attest to all mint-and-burns, so it happens to be the same trust model. In any case, holding a native asset that lives natively on multiple chains means you’re always trusting:

  • The backer (e.g., Circle) + mint-and-burn mechanism (e.g., CCTP)

Holding a lock-and-mint bridged representation of this asset means you’re trusting:

  • The backer (e.g., Circle) + mint-and-burn mechanism (e.g., CCTP) + the lock-and-mint bridge (e.g., rollup contract bridge)

You’re inherently taking implementation risk here. For example, a smart contract bug could cause a bridge hack leaving the bridged rollup funds entirely unbacked. These contracts will harden over time, but we’re definitely not all the way there yet. It’s a risk.

And yet, this framing has left people with no clue. They’re ~50/50 on what’s safer. So not only only is our oversimplified mental model not reflective of the fundamental reality, it’s also confusing and misleading.

Rollup Bridged Asset vs. Asset That Only Lives Natively on the Rollup

The apples to oranges comparison would be a rollup-native asset (e.g., OP) vs. a bridged base layer-native asset (e.g., bridged ETH) on a rollup. So now the difference comes down to:

  • Bridged ETH - Additionally trust correct bridge implementation (including its onchcain governance potentially)

  • Native OP - Additionally trust Optimism social consensus (offchain governance)

As I noted in the last post, this points to the fundamental reason to own any asset vs. another:

However, you should notice why it’s a perfectly ok assumption. You’re obviously happy with the social consensus of Optimism if you hold OP because that’s precisely why you hold it. It derives its value from that social consensus.

That’s why these bridges are amazing - I don’t have to trust another chain or its social consensus. I can always force withdrawal back to Ethereum if that’s the only social consensus I wanted to opt into.

If you don’t trust the social consensus of a given chain not to take all your money, obviously you shouldn’t hold that chain’s native asset. Ethereum could hard fork tomorrow and just delete your ETH, but you probably feel pretty good about those odds if you hold ETH.

And that matters! What if Justin Sun was using bridged ETH (or some other asset custodied by an Ethereum rollup bridge) on a rollup instead of STEEM during the Steem-Hive Hard Fork? Well then they wouldn’t have been able to fork out his funds. The social consensus can always hard fork a rollup, but they can’t socially fork the collateral in the bridge

You may not want to opt into some external social consensus at times. You just wanna keep Ethereum’s. Or, if the contract is upgradeable via an onchain governance mechanism you have faith in, you at least know the rules of the “due process” you’re signing up for.

Rollups let you choose, and that’s a superpower. However, if you want to use something like OP or ARB, then you are opting into another social consensus. The chain and social consensus around it are fundamentally the driver of its value in the first place.

Our Current Framing is Not Future-Proof

And that’s exactly why assets like USDC deployed natively (including on rollups) may very well grow in importance over the long-run. It’s safer and fungible.

Today it’s lock-and-mint bridged to rollups, but CCTP could make this mint-and-burn easy (and quite attractive, especially for optimistic rollups). We’re also likely to see other real-world assets (RWAs) move onchain over time (e.g., Treasuries, etc.).

The implications of this would be clear - the relative importance shifts from the “official” rollup bridge → USDC and Circle (which is itself just a bridge for USD). The whole “practical” argument was that a rollup is defined by the bridge because it holds the majority of assets.

So what happens once we have a chain where native USDC (or some other RWA) TVL surpasses the “official” bridge TVL? This seems highly likely given people have aspirations for consumer-oriented applications and payments, as simple examples. Now does Circle define the rollup? Or swap in any other RWA that may be used onchain. The mental model falls apart.

It’s the same reason that people worry about stablecoin issuers’ control over Ethereum in deciding a contentious fork:

Does that mean Circle defines Ethereum? Of course not! The two ideas below are plainly incompatible:

  • To realize that stablecoin issuers’ power over Ethereum is a concern, but it does not define Ethereum

  • Thinking the enshrined bridge will always define the rollup

It touches on the fundamentally important point though - social consensus always decides the chain, but whatever valuable state you have that someone has god mode control over (whether that’s Circle or an Ethereum rollup bridge) has power in swaying social consensus to be the chain that “matters”.

To ignore the practical realities of what these systems will soon look like is short-sighted. Acting like the single “official” bridge is the final arbiter on everything in the rollup is inaccurate. We’re communicating everything (incorrectly) based on two highly financialized general-purpose rollups with largely bridged assets for which this is a “good enough” description without looking any further.

This applies equally to native assets which derive their value from a given chain’s social consensus. If the majority of assets on a rollup are from native applications (i.e., bridged funds represent a smaller portion of value), then the rollup has significantly higher “practical” sovereignty.

What happens when the next big memecoin that moons is native to a rollup, and that comprises nearly all of its value? Assuming the memecoin is also primarily used on this rollup, then the community doesn’t care as much about the bridge (because there’s not much in it).

Take some rollup where the large majority of funds are from native assets, and there’s a crazy bug on the rollup where someone prints a bajillion native tokens. Or maybe rollup governance token holders are getting greedy and extracting too much value. The L1 contract is immutable, or governance doesn’t want to fork the contract, Ethereum obviously refuses to hard fork, etc. Well then social consensus obviously forks the rollup.

They can’t fork the bridge contract, but users can just force withdraw their ETH to the original contract. The rest of the chain doesn’t even really care because it’s not much of the value on the rollup anyway.

Hence my the framing I chose to use about “L1s” and “L2s” being relative terminology:

In essence, I use “L1” to refer to the portion of assets which derive their social consensus (and thus their value) from that chain. It is the ledger of record for these assets.

I then described a chain to be acting as an “L2” for its foreign state which does not add any security or social consensus assumption’s beyond that state’s “native” chain (or entity).

I consider “implementation risk” generally within the bounds of the native chain here. For example, if you put your money into a faulty smart contract (e.g., a rollup bridge), you’re obviously taking a risk. You also need one honest party. This differs from an honest-majority bridge where now you trust another external consensus (or committee of people) to attest to offchain state, even if the contract implementation is perfect.

For example:

  • Using bridged ETH on a rollup - Even malicious rollup operators can’t take my money. Ethereum can still save me (forced exit).

  • Using native USDC on Ethereum - Even if Ethereum is entirely malicious, they can’t take my money. Circle can still save me (redeem for dollars).

Hence my somewhat crazy statement in the last post:

You could say that people like USDC for much the same reason they like rollups.

You’re using some asset (ETH or dollars) bridged somewhere else without signing up for another set of rules, security, and social consensus.

As noted in the previous post, Ethereum can even be an “L2” to Optimism in this sense:

For example, let’s say I bridge my OP token from Optimism to Ethereum. In both cases:

  • My OP maintains the same social consensus assumptions of Optimism.

  • My OP maintains the same security assumptions of Optimism.

Note that Optimism’s security = Ethereum’s security in this case, so it’s indirect. In any case, the point remains - I’m adding no new assumptions external to Ethereum.

Whenever you use a chain as an L2, you have the same security and social consensus assumptions that you’d have on the home L1 + bridge risk (implementation risk). You’d be safer holding OP on Optimism vs. holding a bridged representation of it on Ethereum.

The “L1” for any chain by this framing is then the party that dictates the valuable state (purely financial or otherwise), and thus has significant power over determining that chain’s future path:

  • Rollup bridge contract - Rollup onchain governance and Ethereum have power

  • Real-world assets (RWAs) - Issuer has power (e.g., Circle)

  • Native state - Rollup social consensus has power

This is a spectrum. To ignore this is to ignore the fundamental nature of how these systems work. We completely miss who actually has the power here.

The counterargument is the following:

Here I just fundamentally disagree. People don’t use these rollups only for bridged assets. Using ETH on Optimism is clearly only one of many things you can do there. You could have a million other things on a rollup where bridged ETH plays a de minimis role.

In many situations, you’ll likely have rollups that look much like today’s. They'll have a bridge that holds a large portion of the rollup’s underlying assets. This could effectively control the rollup, as it’ll be impractical to fork away. Figuring out onchain governance will be especially important here.

So the current framing is good enough if you think the only long-run use case for rollups is roughly a bunch of based rollups without native tokens, and you just bridge up some ETH to leverage long ETH even more because it’s too expensive on L1.

If you think it’s anything else (I sincerely hope so), then we’re completely missing the picture. What do NFT rollups look like? Native DeFi applications? Gaming? RWAs? Literally any of the things everyone keeps saying they’re excited about?

ETH will certainly play a huge role, but this isn’t a black-and-white all-or-none thing here. Maybe I’m too optimistic, but my strong guess is that rollups will actually have some interesting and valuable state beyond bridged ETH trading.

TLDR - Use whatever definitions for “L1” and “L2” you want, I know people get scared by new things. But this alternative framing of L1 and L2 actually captures both critical points:

  • Assets are safer on their native chain (or entity)

  • The chain (or entity) which acts as the L1 for given assets is the ledger of record. It has effective control over them when chains are used as L1s and L2s here, so the real L1 has meaningful implicit economic influence over the social consensus of the L2 which is reliant on this collateral

The current framing captures neither. It’s mostly just a loose description of the security relationship, but this doesn’t seem helpful since “base layer/DA layer” and “rollup” already cover this. That’s where the rollup’s security comes from.

Also, the current “L2” definition generally includes validiums, which makes little sense to me. These validium bridged assets don’t get Ethereum security anymore - they get the security of their DA layer.

(Note that a validium DA failure wouldn’t let you force an invalid state transition and steal user funds. However, you could force a valid state transition and withhold the data. Then, nobody else can recreate the state, and you demand ransom with the chain halted.)

Onchain vs. Offchain Governance

My previous post fit my typical style of focusing more on the technical and economic implications of my arguments. This time, I’ll philosophize a bit on the more squishy social stuff.

As a refresher, I mentioned last time:

Upgrading a rollup’s enshrined bridge requires upgrading its smart contract. This upgrade path is often undesirable:

  • Today - Contract upgrade keys are often held by a multisig of core team members. They may have the ability to make instant and arbitrary upgrades to the contract.

  • Future - Hopefully, upgrade keys will move over to rollup governance (or become immutable). In any case, this must take the form of onchain governance (e.g., token voting, or using some other form of onchain identity to vote). Ideally, the upgrade window would be set comfortably longer than the withdrawal period. If you don’t like the upgrade, you can withdraw your funds.

Just because the bridge contract requires onchain governance (or is immutable) does not mean the rollup itself requires onchain governance (or is immutable).

Offchain governance can always fork the rollup, but onchain governance is needed to fork the bridge. Bridge ≠ rollup.

And users can still withdraw their collateral from the bridge to the original fork. They may or may not choose to bridge it back into the new fork. The new rollup would simply lose the ties to the collateral behind the bridge.

Whether it’s “practical” to fork socially is a spectrum based on how important the bridge is, but it is not a fundamental limitation. If all the users decide that the forked rollup is the new “canonical” rollup and they all use that one, then that’s what matters.

There’s a reason that Ethereum has offchain governance - onchain governance kinda sucks so far. If there’s one thing that crypto certainly hasn’t figured out yet, it’s how to implement functioning and non-plutocratic token-holder governance. This understandably hasn’t been a priority for most rollups at the moment, so I applaud those who are focusing on it.

Arguing that the bridge defines the rollup then implies that if onchain governance (generally token holders) say something, that’s what goes. This seems patently unacceptable to me considering these are inherently social systems. The implication here is that every Ethereum rollup is fully subject to onchain governance (if any), and rollup social consensus is absolutely powerless.

Take another simple example - we have some social media application that has its own rollup. Users have a little bit of bridged ETH on there to pay for gas fees. But this application starts to get really popular, so the governance token holders get greedy. They start jacking up prices on users.

But most of the valuable state here is just user data, not the bridged funds. Patrick had an amazing way of framing this more broadly:

The fundamental issue is that people talk about blockchains in the form of products. That creates lots of confusion as there is no native way to compare it.

It’s better to get back to basics and say: “I want to build a database that anyone can read/write too.”

Then talk about posting data onchain as that allows anyone to post a transaction / read all transactions to compute the db.

“Ok now anyone can get access to the database, how can I send messages from a blockchain network to this database and vice versa”

Then you start thinking about bridging protocols and of course the validating bridge. So there are really two tasks:

  • how to build an open database

  • how to communicate to/from the open database

The reason people link the validating bridge to the rollup is mostly because:

  • it is hard as shit to build

  • it currently holds >90% of bridged assets

  • it is currently being leveraged to define access to the DA layer

  • multiple validating bridges == fragmentation of assets, not really desirable for DeFi

So theoretically they are two different problems, but practically the bridge has been overloaded to perform more than just custodying assets. Whether that is good or bad I don’t know, but it’s still early days in the land of bridges and cross-chain protocols.

We want to build systems with open databases. Anyone can read it, interact with it, and verify it at any given time. For this database to interact with external state, we need a method of communication (bridges). Rollup bridges are great for this - they can reduce trust in external parties.

The DA layer is just a public bulletin board to this end which provides global consistency. If people wanted, they could decide to interpret the data differently, or even pick a different bulletin board.

With this in mind - the users hold the power here. So what they do? They socially fork the chain. This property is absolutely critical. It’s a huge part of what makes blockchains what they are. No lock-in, social consensus, users decide. That’s literally the whole reason that people want to do a bunch of social media stuff onchain. This extends to the protocol itself just as much as it applies to someone making a front-end application for it.

To ignore this social consensus property appears completely antithetical to everything we’re supposedly building.

It makes little sense to use this messaging that the bridge = the rollup, leaving users entirely subject to onchain governance. Yes, the bridge’s onchain governance has power, but this is not an absolute.

Obviously these contentious forks are not everyday circumstances. People don’t like thinking about them. It’s abnormal for large and economically important contingents (e.g., onchain bridge governance vs. offchain rollup social consensus) to diverge, but these are precisely the defining moments and qualities that make these systems what they are. It can be easy to forget that sometimes.

The fact that social consensus has power is great! It’s a feature, not a bug!

Why Are We Stuck to Our Current Mental Model?

For most of the people I’ve argued with here, I obviously love them. We just love debating about crypto, and mostly get caught up on some finer points of semantics on occasion. I tend to debate the most with the people I like a lot in case you haven’t noticed by now.

Outside that, I think there’s a few broad reasons why some others have had a tough time seeing eye-to-eye here:

  • They already get it - A handful of people already intuitively understand what I’m saying. But the current rough terminology we’re using seem “good enough,” and this new stuff is just too confusing. As described above, our mental models aren’t translating very well outside of this small group. Most people don’t get it. It also makes little sense in the future (not even that far out).

  • They don’t get it - See above. This is no fault of their own - I think we just haven’t been doing a great job of explaining how these systems work to most people. We’re all learning as we go along.

  • It’s uncomfortable - It’s the opposite of how most people describe this stuff, and it doesn’t apply to the two largest rollups today. It doesn’t fit what we see right in front of our eyes. This is naturally jarring, but I think we need to open up here. Rollups are gonna be much bigger than what we see today.

There are also some more personal factors:

  • “Settlement Layer” - The whole “Ethereum world settlement layer” thing sounds cool and valuable. A lot of people like that, and I reframed what this notion actually means. While the social implications I’m making are positive, a lot of people seem more focused on what they view as the economic implications based on their preconceived notions of where value will come from.

  • ZKR vs. ORU - Some ZK teams in particular have dedicated an immense amount of work into building amazing proving systems and associated bridges. It’s a tremendous achievement which can’t be understated. The rollup ≠ bridge thing can seem as if it’s giving a “free pass” to rollup teams who’ve focused less on the bridge/proof aspect of the rollup.

  • “Sovereign Rollups” - The implication that the bridge grants security to the rollup makes it sound like “traditional” sovereign rollups (i.e., those without an enshrined L1 bridge) are completely insecure. It amazes me how prevalent this notion is, even amongst “experts” I speak to. This was a big point I wanted to clarify in that post.

    The cynic in me realizes that some of this is likely intentional. This is probably seen as beneficial because they aren’t generally viewed as an “Ethereum idea.” They’re seen as more of a Celestia or Bitcoin thing now. This of course makes little sense, as you could easily deploy “sovereign” rollups like this on Ethereum.

I get it, we all want our thing to be special:

  • My ZKR is super fast, and your ORU isn’t.

  • My ORU actually works, and your ZKR is on “announcement of an announcement” #12 for being the first zkEVM.

  • My sovereign rollup is super sovereign, and your smart contract rollup isn’t.

  • My smart contract rollup is super secure, and your sovereign rollup isn’t.

Sometimes they’re a lot closer than we actually think though.

But we’re missing what makes our things actually special, and it’s often the social consensus behind them. Blockchains are social coordination tools. We are building inherently social and political systems. That’s the whole point.

Hopefully we can broaden our views going forward without going totally crazy (maybe a bit optimistic, but worth a shot). I just don’t want to start going the Bitcoin maxi route because then Eric and Udi will start trolling us more, and we’ll have to give Eric more tungsten cubes.

It’s not good business to get anyone upset, but I’m gonna call stuff out if I think it’s incorrect and misleading. Maybe I could tone down the post titles since some people don’t really read past them, but then again this is crypto. We’ve gotta have some fun while we’re here.

The Rollup Multiverse - The Bridge Defines One Rollup

Before we wrap up, I’ll briefly explain what I think is the more “technical” reason we’re stuck on.

I send Ethereum assets (e.g., ETH) into the contract and get the bridged version on the rollup. Assuming correct implementation, I can always get my ETH back on Ethereum.

That’s great. This contrasts with traditional honest majority bridges where I now trust the receiving chain’s consensus not to screw me. The rollup operator could be malicious, rollup social consensus could socially fork, etc. It doesn’t matter. The bridge will just observe the rollup chain that this holder cares about. They can always come back home.

The bridge often does other important stuff as well. For an “enshrined” bridge, the rollup’s state often depends on the contract in some way today. For example, even if the Arbitrum sequencer never includes your transactions, you can post it to the delayed inbox contract and "force include" it after some delay period (currently ~24 hours on Arbitrum One).

This bridge enforcement could be seen as one distinction vs. an “unofficial” rollup bridge (which still fully validates the rollup) where the rollup’s state doesn’t depend on it in any way. As I mentioned last time, Sovereign Labs will implement the fork-choice rule baked directly into the ZK proof, which includes scanning the DA layer for any eligible transactions to force inclusion of. Clients just run the rules offchain and enforce it using the proof. Clients also receive the proof via p2p rather than looking to the contract as their “source of truth.”

They can then have validating bridges to the base layer which aren’t “enshrined” in the sense that the bridge doesn’t directly impact the rollup’s state in any special way. Different bridges can have different upgrade paths.

Back to the Arbitrum inbox though:

  • This enforces censorship resistance, allowing users to force include transactions into the “canonical” chain from the bridge’s point of view. It doesn’t care if the rollup socially forks. It won’t observe it (unless the contract is upgraded to do so).

    This bridge has a total radar lock on one rollup from its perspective, implying its existence. It does “define” this one rollup in this sense, regardless of whether anyone cares about it.

  • However, it provides no guarantees of being included in the “canonical” chain from anyone else’s point of view. The contract saying “please force include my ARB transfer” isn’t very meaningful if the rollup were to socially fork, and this new fork is the only one where ARB has any value. Everyone else moved onto another fork which doesn’t listen to the contract anymore.

And that’s the point - the “canonical” chain is relative. As a user who has assets bridged from Ethereum, I place no assumptions on the rollup. I can go back home to Ethereum because that’s the ledger of record for my asset. It can’t help me if the thing I want to do is inherently tied to the social consensus’ view of what is the “canonical” rollup.

We live in the multiverse of rollups. It’s messy when the timelines fork, but it can happen.

TLDR - Rollup = bridge, but also rollup ≠ bridge. You get to choose though, and that’s why they’re great.

Simple Takeaways

Here are the key points:

  • Rollups can inherit their base layer’s security regardless of whether they have a bridge.

  • Rollups are basically just some data output that we all agree is interesting, based on some data input that we posted onchain (like on Ethereum).

  • The bridge doesn’t define the “canonical” rollup because there is no globally absolute “canonical” rollup. It does cool stuff like control the collateral for bridged funds though, and that’s super important when applicable.

  • Assets which some offchain actor (e.g., a rollup’s L1 bridge contract, or RWA issuers) has total control over can’t be forked without their permission. The entities that control these assets are economically super important. They can sway social consensus.

  • Social consensus = communities can always socially fork the native state that derives its value from that chain and the social consensus around it.

  • Natively minted assets are safer than their lock-and-mint bridged representations.

  • If you’re gonna bridge, rollup bridges are dope. Sidechain bridges = you’ve gotta trust the other chain’s consensus too. Rollup bridges = the home chain can save you.

That’s about it. Call these things rollups, L1s, L43s, cotton candy, whatever - I don’t really care. Just remember those.

Words Aren’t Real

I’d pay a lot for a canonical crypto dictionary, but alas, here we are. The teams building “zkEVM L2s” don’t even agree on what’s a “zkEVM” or an “L2.” It’s kinda funny if we’re being honest.

If you use the big buzz words, then just clearly define what you mean. But the whole “my thing is X and yours isn’t because I defined it this way” without clearly describing what you’re talking about isn’t helpful. Then you’re just arguing over semantics for marketing, and everyone else gets confused.

If you’re clear and truthful about what you mean, you can start calling your rollups “pancakes” and bridges “bananas” for all I care. In any case, pancakes ≠ bananas (but they’re dope when you put ‘em together).

Arguing over canonical terminology is probably a lost cause for a while:

But debating over the real stuff behind them is helpful:

I have little hope for a canonical crypto dictionary anytime soon, but I do still hope we can get a little better at understanding what we’re actually building.

Disclaimer: The views expressed in this post are solely those of the author in their individual capacity and are not the views of DBA Crypto, LLC or its affiliates (together with its affiliates, “DBA”). The author of this report has personal investments in ETH, Celestia, and Sovereign Labs Inc.

This content is provided for informational purposes only, and should not be relied upon as the basis for an investment decision, and is not, and should not be assumed to be, complete. The contents herein are not to be construed as legal, business, or tax advice. References to any securities or digital assets are for illustrative purposes only, and do not constitute an investment recommendation or offer to provide investment advisory services. This post does not constitute investment advice or an offer to sell or a solicitation of an offer to purchase any limited partner interests in any investment vehicle managed by DBA.

Certain information contained within has been obtained from third-party sources. While taken from sources believed to be reliable, DBA makes no representations about the accuracy of the information.

]]> jon-dba@newsletter.paragraph.com (Jon Charbonneau) <![CDATA[Rollups Are L1s (& L2s) a.k.a. How Rollups *Actually Actually Actually* Work]]> https://paragraph.com/@jon-dba/rollups-are-l1s-l2s-a-k-a-how-rollups-actually-actually-actually-work 9ZV9pgFuCACoEZok6Cr9 Fri, 26 May 2023 21:40:19 GMT Thank you Kelvin Fichter for the awesome discussions getting philosophical on rollups, and for review of this post. Also thank you for the cartoons and starting the bridge ≠ rollup crusade lately.

Thank you Mustafa Al-Bassam, Christopher Goes, James Prestwich, Nick White, & Cem Özer for feedback and related conversations as well.

And a huge thanks to Toghrul Maharramov for review and fun back and forths! Especially since we disagreed on a bunch of stuff here :)

Editor’s Note - The original post started with “The prevalent understanding of rollups is a lie.” While I strongly believe in the rest of my points throughout the post, I don’t want that to get lost here. I often write in jest, and I misjudged that this opening with the meme-y title would be taken quite literally by many. I acknowledge this would be confusing for the casual reader, as I also redefine some terms throughout in a manner which I have found useful for my own mental models.

My key point is that there are a lot of misconceptions out there that social consensus and “sovereignty” only apply to traditional “sovereign rollups” or other L1s. I’m highlighting that this very much still applies for smart contract rollups too. While in practice these contentious hard forks (e.g., bridge and social consensus diverging) will be incredibly rare to ever be exercised, the fundamental existence of it is critical.

For example, it’s incredibly unlikely that Ethereum would disagree with Circle in a hard fork, but it’s absolutely critical that it can. In the same way Ethereum is not “defined by” Circle, I push back on framing that “the rollup is defined by the bridge” because I think it’s reductive and can be quite misleading.

It’s also gotten near impossible to keep up (even for myself) as new definitions of “technical sovereignty” and “social sovereignty” have arisen even prior to my piece. It’s confusing for anyone that there are now plans for so-called “sovereign rollups” with these validating bridges to the base layer, because they’re architected very differently and the technology keeps changing.

With all that in mind, I hope you find this piece and the follow-up post helpful.

Introduction

I believe the prevalent understanding of rollups needs to be meaningfully reconsidered. As I noted in my “Rollups Aren’t Real” post:

There’s an interesting argument that there is no such thing as a globally canonical chain (only bridges deciding which chain to consider canonical), good counter arguments, and other great related Twitter threads on the tradeoffs all rollups make between sovereignty and (automatic) composability.

Kelvin and Toghrul have also been going full PvP on this topic lately:

Well, I’ve decided to join the fight. Someone who built half the stuff we use just told me that “everyone is going to hate your argument because it doesn’t pump anyone’s bags.” Should be fun.

This is how rollups *actually actually actually* work.

Blockchains 101

I’ll very briefly start from the absolute basics to build up the correct mental model. Blockchains are “replicated state machines”:

  • Replicated - Many nodes hold a copy of the blockchain’s state.

  • State - The state is like a snapshot of all the stuff we agree on today (e.g., what addresses exist, who holds what amount of money, etc.).

  • Machine - The blockchain does stuff to modify the state over time. The whole “world computer” thing.

So, blockchains are just a fancy tool for everybody to agree on some state of the world and update it. Everyone applies the “state transition function” (STF) to update the state. The STF is:

  • A mathematical function (representable as a program)

  • Takes the current state + some input → generates new state (e.g., take the current Ethereum state → execute some transactions → calculate the new Ethereum state)

  • f(Input, S_current) = S_next

Importantly, the STF is deterministic - every node will always get the same result if they run it over the same input and current state.

Rollups 101

Throughout this report, I will use the following definition for rollups:

“Rollups are blockchains that post their blocks to another blockchain, and inherit the consensus and data availability (DA) of that blockchain.”

Putting things together, a rollup comes from:

  1. Input Data - An ordered array of input data posted to another blockchain (the DA layer)

  2. Function - Agreed upon rollup node software is run deterministically over the input data

  3. Output Data - Running the function over the inputs produces deterministic outputs (the rollup blockchain) which gives us the current state

That’s it. The rest is all ~implementation details~.

Sovereign Rollups vs. Smart Contract Rollups

Now let’s get more specific on those implementation details.

As a devil’s advocate, I’ll first present the traditional wisdom that you’ve likely seen by now. In the following sections, I’ll provide my counterargument to the points I’m about to describe. It appears to be a contentious topic, so I want to provide both sides of the story:

The classic rollup fundamentalists state the following:

Smart Contract Rollups (a.k.a. Classic Rollups)

Today’s smart contract rollups (a.k.a. classic rollups) post their transaction data to Ethereum. This solidifies their data availability (DA) and ordering. You get these guarantees from consensus, which rollups outsource to their DA layer.

1) Data Availability - DA is needed to ensure safety and recoverability of the chain state. If you don’t know what the inputs are, you can’t compute over them.

  • Optimistic rollups (ORUs) - You can’t create a fault proof to challenge an invalid state transition if the data is missing.

  • ZK-rollups (ZKRs) - A proof ensures that a state transition is valid, but we still can’t recreate the rollup’s state if we don’t have the data behind it (i.e., funds are frozen).

2) Data Ordering - Data ordering is also critical. We just don’t mention it often because we implicitly get it from the way that DA layers work. Running the same function over different orderings of input data would produce different outputs. If the DA layer just made available the data for a bunch of unordered trades, that wouldn’t be very helpful in computing the result.

Additionally, the fundamentalists will tell you that classic rollups use Ethereum for “settlement.”

3) Settlement - These rollups deploy L1 smart contracts to Ethereum which run onchain light clients of the rollup to:

Source: Celestia, An Introduction to Sovereign Rollups
Source: Celestia, An Introduction to Sovereign Rollups

Standard light clients trust an honest majority of the chain’s consensus, but rollup light clients are special because they check the validity of the rollup’s state transition. Even if a dishonest sequencer submits a block with an invalid state transition (e.g., printing a bunch of money), the rollup contract will reject it. Proofs protect the rollup:

Source: Kelvin Fichter, How Rollups actually work
Source: Kelvin Fichter, How Rollups actually work

Sovereign Rollups

Sovereign rollups also rely on a base layer (e.g., Ethereum or Celestia) for DA and ordering. However, they do not have an L1 smart contract which determines their canonical chain. Rollup nodes decide this for themselves - they check for DA on the L1, then they locally verify the fork-choice rule. For example, proofs could be sent around the p2p layer for light clients to check (instead of posting them to a smart contract). They don’t need a settlement layer - they just do their own settlement. The rollup’s users decide which fork to follow.

Source: Celestia, An Introduction to Sovereign Rollups
Source: Celestia, An Introduction to Sovereign Rollups

Comparison

The fundamentalists argue that sovereign rollups then inherit *some* security from the L1. Smart contract rollups additionally inherit censorship resistance and validity guarantees from the L1, where:

  • Censorship Resistance - Within predefined time, a user-originated transaction is guaranteed to be inserted into the canonical chain.

    The argument here is that sovereign rollups can use the DA layer to force transaction inclusion, but they don’t guarantee inclusion in the canonical rollup (since the base layer doesn’t determine the canonical rollup). Smart contract rollups guarantee inclusion in the canonical rollup since the base layer chooses it. (I’ll explain shortly why I disagree with this).

  • Validity - Execution is compliant with the state transition function (STF) of the protocol (enforced via validity or fault proofs checked by the smart contract).

Source: Based on Toghrul Maharramov, Rollups Through the Prism of the Bridges
Source: Based on Toghrul Maharramov, Rollups Through the Prism of the Bridges

(1) Remember - this is me playing the devil’s advocate and presenting the other side’s argument. These rows are incorrect.

If you subscribe to the logic above though, rollups would then have to choose between:

  • Sovereignty (i.e., rollup nodes determine the canonical chain for themselves), or

  • Trust-minimized composability with the L1

They are supposedly mutually exclusive. If a rollup has trust-minimized composability with the underlying layer, then such a rollup is “defined through the validating bridge.”

Settlement Isn’t Real

Now that we’ve level set on the basics, I’ll explain why everything I just told you is a lie. The crux of it is that nebulous buzz word - “settlement.” Settlement is a myth.

Ethereum is often referred to as the “settlement layer” for rollups because the L1 smart contract supposedly decides the canonical rollup chain. This is wrong.

The bridge provides a view into the rollup. The bridge does not define the rollup.

What people really mean by “settlement” here is usually just finalizing an enshrined bridge. That’s also why there’s a messy debate over when a rollup finalizes. People often mistakenly think that an ORU finalizes after a week, but that is just when the bridge finalizes its view. Different “observers” view finality at different times. The bridge is one such “observer” of the rollup (which is slow in this case), but the bridge is not the rollup.

An observer who runs Ethereum + rollup full nodes would perceive much faster finality. They just need to check:

  1. The state transition of the rollup is valid

  2. The associated rollup data has been posted and ordered on the DA layer (and the DA layer has finalized this ordering)

Sovereign Rollups vs. Enshrined Bridge Rollups

Here’s a more accurate table. I refer to “smart contract” rollups as “enshrined bridge” rollups to drive the point home here:

We think of these bridges as “defining” the canonical rollup today mainly due to the fact that there tends to be an "official" bridge which holds much of the rollup’s TVL. In practice, that means the bridge holds tremendous power over the rollup.

But let’s play out a little thought experiment:

  • An Ethereum rollup has an “official” enshrined bridge which checks the rollup’s validity using fault proofs. The website for the “official” bridge has a terrible UX so nobody uses it. It has $0 in it.

  • Everyone uses other “unofficial” bridges because they have pretty websites and finalize quickly. They custody most of the rollup’s funds - billions of dollars. There’s also a bunch of native assets on the rollup.

Now, does the “official” bridge really define the rollup? It has $0 in it, so it’s really just a “validating contract” rather than a “validating bridge” at this point. If the rollup decided to fork away from that contract completely, it could do so with little issue. More on this later.

All Rollups Are Sovereign Rollups

But wait, wasn’t “settlement” the big difference between sovereign and classic rollups? Exactly:

To “not enshrine a settlement layer” is primarily a social distinction rather than a technical one, which means that there is a social contract between the rollup’s community that the rollup’s transaction validity rules are defined by the community rather than an immutable L1 contract.

All rollups are sovereign rollups.

Even Preston Evans of Sovereign Labs notes that sovereign rollups “may be a little bit of a misnomer” and “the whole difference between sovereign and non-sovereign rollups is maybe a bit overblown”. And he’s building sovereign rollups! I’ll attest to the fact that he’s a genius who knows what he’s talking about far better than I do.

“Sovereign rollups” are a pretty amorphous concept at this point, but that’s a bit fuzzy for my liking. I’ll specify it here. The debate over whether or not a rollup is sovereign boils down to two concrete points:

1) “Technical Sovereignty” - Source of Truth (SoT) for Rollup Users

Technical sovereignty addresses how users receive the “truth” of the rollup. This is unrelated to the ability for social consensus to fork the chain (which is how we often see “sovereignty” described).

Smart Contract Rollups: Enshrined Bridge = Source of Truth (SoT)

Users of enshrined bridge rollups typically learn the rollup’s state in a trust-minimized way by looking at the onchain Ethereum smart contract. The expectation is for users to run an Ethereum full node (but not a rollup full node) which in turn runs a light client of the rollup (the bridge is the light client). The contract is the users’ SoT for the canonical chain.

So the smart contract is really doing two things here:

  • Checks the validity of the rollup’s STF - The contract does onchain verification of a validity proof (in the ZKR context).

  • Enforces the rollup’s fork-choice rule - The contract checks that a new proof builds on the previous proof (and not some other fork), that it’s processed all of the relevant forced transactions which were sent on L1, etc.

Sovereign Rollups: p2p Proofs = Source of Truth (SoT)

By the definition of technical sovereignty, sovereign rollup users don’t look to an enshrined bridge contract which verifies proofs to determine the “canonical” chain. Their SoT comes from somewhere else. Proofs can be distributed in other ways.

Sovereign Labs will implement the following construct:

  • Immediately distribute proofs p2p - Distribute proofs via the p2p layer immediately as they are generated. This is the SoT for rollup users, which verify them directly by running rollup light nodes.

  • Immediately post proofs onchain (but don’t verify onchain) - Post proofs as data blobs to the DA layer (but don’t verify them onchain) immediately as they are generated. This is used for prover incentivization - the first proof which proves a batch wins the race and is paid for their work.

  • Periodically post proofs onchain (and verify onchain) - The bridge requires onchain proof verification, but users don’t. Onchain proof verification is expensive, so proofs will only be batched and verified onchain periodically as needed. This allows the bridge to update its view of the rollup and bridge funds.

The result - you get a trust-minimized bridge with the DA layer, but the bridge is no longer the SoT for light clients. These rollups have “technical sovereignty”.

Yes, I know that goes against what most of you thought was a “sovereign rollup.”

This bridge could even be implemented without a smart contract. It could use a simple zkSNARK verifier as proposed here. This would allow minimal DA layers such as Celestia (which will not support arbitrary smart contract logic) to have a trust-minimized two-way bridge with its rollups.

You’ll notice one issue - enshrined bridge contracts also enforce the rollup’s fork choice rule normally. If we distribute the proofs p2p, how will users know that these blocks being proved also follow the rollup’s fork-choice rule?

It’s actually quite simple - rather than having a smart contract enforce the rollup’s fork-choice rule, the fork-choice rule is built into the validity proof itself. We no longer need a smart contract to enforce it. Users can simply receive the proof directly via p2p and verify that:

  • The rollup’s state transition is valid

  • The new block follows the fork-choice rule - it is the “canonical” tip of the chain which builds on the previous proof

To implement this new rule, you just add another statement into the proof being generated which says “I have scanned the DA layer for proofs (starting at block X and ending at block Y), and this proof builds on the most recent valid proof.” This proves the fork-choice rule directly.

This rollup is still posting its validity proofs to the DA layer as data blobs, so the proofs show that it scanned all of them to determine the latest one. However, it’s possible for anyone to post a proof, so you also need to bake in your rule around which is the “canonical” proof. In Sovereign Labs’ case, the plan is simply for the fork-choice rule to select the first proof that proves a valid new state transition for the rollup (i.e., it's ordered first on the DA layer).

The TLDR results of this are then:

  • Fast p2p proofs for users - p2p proofs can be distributed immediately to users, giving them relatively fast finality at the speed of the DA layer block times (once the rollup transaction data has been posted and finalized onchain). This is their SoT rather than the L1 smart contract.

  • Batched onchain proofs - Onchain proof verification is expensive, so current ZKRs tend to only post proofs every few hours to save on costs. The construct described here would also recursively batch proofs and verify them onchain periodically to save on costs. However, users no longer need to wait for this onchain verification to “finalize” in their eyes (because they get the faster proofs via p2p).

Scroll has a similar plan - they will post intermediate ZK proofs onchain to Ethereum (but not verify them), so light clients can sync fairly quickly. The only difference is that they’re only posting them onchain vs. Sovereign Labs is also planning to distribute them p2p prior to onchain verification.

Both constructs allow users to finalize their view of the rollup at the speed of the base layer (rather than waiting to verify the proofs via a smart contract in order to save on gas costs). Rollups can be viewed as achieving finality when:

  • Their transaction data has been posted to their DA layer

  • The DA layer has finalized

  • Any honest node can compute the deterministic resulting state transition

The real difference in “finality” timing is just when different parties become aware of it. For example:

  • A full node would know instantly that the new rollup state is final (assuming full transaction data is posted onchain, not just state diffs)

  • A validating bridge wouldn’t know that the new rollup state is final until it has verified a validity proof or the challenge window has passed

The construct described allows light clients to perceive that fast finality at the speed of the DA layer without running a full node. Note that in any case, true finality is bounded to the DA layer’s finality time. Implementations such as a rollup consensus can give you strong pre-confirmations, but it’s not truly final until the data is solidified onchain.

2) “Social Sovereignty” - Ability to Upgrade & Fork

The other definition of sovereignty we more often hear about is “social sovereignty” - the ability for a chain’s community to socially hard fork and upgrade as it pleases. Note that this requires allowing for offchain governance:

  • Social sovereignty ≠ 51% of token holders can vote for an upgrade (e.g., to upgrade the enshrined bridge contract), and if you lose the vote you’re forced to go along

  • Social sovereignty = If you disagree with the changes, anyone can socially fork the chain (e.g., how Ethereum conducts any hard fork)

Upgrading a rollup’s enshrined bridge requires upgrading its smart contract. This upgrade path is often undesirable:

  • Today - Contract upgrade keys are often held by a multisig of core team members. They may have the ability to make instant and arbitrary upgrades to the contract.

  • Future - Hopefully, upgrade keys will move over to rollup governance (or become immutable). In any case, this must take the form of onchain governance (e.g., token voting, or using some other form of onchain identity to vote). Ideally, the upgrade window would be set comfortably longer than the withdrawal period. If you don’t like the upgrade, you can withdraw your funds.

This contrasts to definition of sovereign rollups which is often provided:

Sovereign rollups upgrade through forks like a layer 1 blockchain. New software versions are published, and nodes can choose to update their software to the latest version. If nodes disagree with the upgrade, they can stay on the old software. Providing a choice lets the community, those that run nodes, decide whether they agree with the new changes. They can’t be forced into accepting upgrades, even if most nodes upgrade. This feature, compared to smart contract rollups, is what makes sovereign rollups ‘sovereign’.

However, I contend that the above statement equally applies to enshrined bridge rollups. Nodes for an enshrined bridge rollup:

  • Can socially fork the rollup regardless of whether they upgrade the L1 contract

  • Cannot socially fork the enshrined bridge and carry over its collateral (i.e., the new representation of those assets will be unbacked if they fork the rollup socially)

  • Bridge ≠ rollup

Therefore, even enshrined bridge rollups can implement social hard forks. They simply have an implicit cost imposed on forking to a varying degree based on how much collateral is in the enshrined bridge contract. Just because the bridge contract requires onchain governance (or is immutable) does not mean the rollup itself requires onchain governance (or is immutable).

As I alluded to earlier - you can imagine an example where there are no funds in the bridge. In this scenario, a social fork of the rollup would effectively impose 0 cost on the rollup. They wouldn’t end up with any unbacked collateral. So these are the options to hard fork an enshrined bridge rollup:

  • Upgrade the existing contract (requiring onchain governance) and socially go along with this as defining the new rollup

  • Socially hard fork a new instance of the rollup (offchain governance). This could point to a new smart contract (e.g., also deployed on Ethereum L1), or they may decide to look somewhere else for proofs (e.g., distribute them p2p)

Whether it’s “practical” to fork socially is a spectrum based on how important the bridge is, but it is not a fundamental limitation. If all the users decide that the forked rollup is the new “canonical” rollup and they all use that one, then that’s what matters.

And users can still withdraw their collateral from the bridge to the original fork. They may or may not choose to bridge it back into the new fork. The new rollup would simply lose the ties to the collateral behind the bridge. You let the bridge die and move on.

In this sense, all rollups retain total “social sovereignty”. They do not have social sovereignty over assets that are locked in the underlying bridge on another chain.

Offchain governance can always fork the rollup, but onchain governance is needed to fork the bridge. Bridge ≠ rollup.

By this “social sovereignty” definition, I argue that:

Sovereign rollups are the superset term which encompasses all rollups. “Classic” rollups are basically just a type of sovereign rollup which additionally tack on a validating bridge.

Bringing things full circle, we come back to Mustafa’s point I quoted above:

To “not enshrine a settlement layer” is primarily a social distinction rather than a technical one, which means that there is a social contract between the rollup’s community that the rollup’s transaction validity rules are defined by the community rather than an immutable L1 contract.

The difference between sovereign vs. classic rollups as he described in that great article (read it) is primarily a description of the community’s current social contract. Ethereum rollups today have a rough social contract that users look to the bridge for the canonical rollup.

The point I am highlighting here is simply that this current social contract is not fundamental. Indeed, it is even highly likely that social consensus would shift away from the bridge at times (e.g., if there’s a major hack within a rollup’s own state, and the bridge can’t be upgraded to fix it, which I’ll detail in an example below). The community always retains social sovereignty.

Basically this is most of us right now, except it’s for Mustafa:

All Rollups Are L1s (& L2s)

Sunny had a unique mental model in a recent speech:

“Every chain is an “L1” for its internal state and an “L2” for its foreign state”

You could extend this logic to pretty much any external representation of an asset being an L2. So Coinbase is an L2 to Ethereum, Lightning is an L2 to Bitcoin, every chain is an L2 for Circle (they always control USDC), etc. They’re just L2s with varying trust assumptions

However, I propose a new mental model. A single chain (or other entity) can simultaneously fulfill three different roles:

The L2 property is achieved by rollups with validating bridges which also ensure DA.

The sidechain property is achieved via a trusted bridge (e.g., honest majority) between the native L1 and the sidechain.

In essence, I use “L1” to refer to the portion of assets which derive their social consensus (and thus their value) from that chain. It is the ledger of record for these assets.

Enshrined Bridge Rollups Are Layer 2s

A classic rollup acts as an L2 to Ethereum when I bridge ETH → rollup because:

I do not add any security or social consensus assumptions beyond ETH’s native chain (Ethereum). I place no trust in the security or social consensus of the rollup.

That does not mean you aren’t taking any additional risk. You’re putting your money into a bridge (e.g., smart contract). Of course a faulty contract could rug you, the proof implementation could be wrong, etc. But that’s no different than putting your money into a DeFi scam contract on Ethereum. You can see the code, and you make a decision. It’s not Ethereum’s fault or the rollup’s fault if the bridge gets hacked. It’s your fault for putting your money into a buggy contract. (You may also have a 1 of N assumption for optimistic bridges, but that isn’t the case either for ZK bridges.)

Additionally, the rollup’s governance or operators should not have the power to upgrade the contract and steal my ETH. Then I would be placing an honesty assumption on them. The contract should be immutable, or there should be an upgrade delay which is significantly longer than the forced withdrawal mechanism.

If these conditions are fulfilled - then even a malicious rollup social consensus, operator, and/or governance can’t take my money. I can always get my ETH back on Ethereum.

This is not the case for sidechains (honest-majority bridges). If I bridge my ETH via an honest majority bridge to another chain, Ethereum can’t save me if that chain is malicious. They can freeze my funds and/or lie to the bridge to withdraw its collateral. I have no recourse.

For example, IBC is currently implemented by each connected chain running an onchain light client of the other chain. These light clients trust the honest majority of the other chain. If the Osmosis validator set is corrupted, they can lie and tell the Cosmos Hub whatever they want. (IBC today doesn't include state transition proofs as part of the Tendermint light client, but note that IBC can be modified to additionally implement state transition proofs as well.)

Enshrined Bridge Rollups Are Layer 1s

Enshrined bridge rollups are also “L1s” by my definition for their native state. This state derives its meaning and value from the rollup. Take Optimism as an example:

  • OP’s value is derived from the social consensus around the Optimism chain.

  • OP bridged to Ethereum would derive its value from the underlying OP collateral on Optimism.

  • They’re 1:1 redeemable, so they should trade ~1:1 in price (otherwise there’s a risk-free arbitrage) other than some discount to account for the withdrawal period (time = money) and some level of smart contract bridge risk.

  • If Optimism disappeared, that wrapped token would be unbacked.

So let’s consider a hypothetical example:

  • Optimism has fully matured - it has a validating bridge, forced transaction inclusion, bridge contract has governance upgrade delays, etc.

  • Optimism has an enshrined bridge smart contract on Ethereum which holds 10% of the rollup’s funds (e.g., bridged ETH)

  • Ethereum and Optimism have communities with distinct social consensus and interests

  • Some crazy shit happens on Optimism (e.g., someone conducts a highly profitable trading strategy), and now the attacker controls the majority of all rollup funds

  • Optimism nodes all want to fork the rollup to undo it, but governance doesn’t have the power to upgrade their existing smart contract. The attacker now holds most of the OP, and they reject any vote to fork.

Source: Gabriel Shapiro
Source: Gabriel Shapiro

On this “new Optimism” fork:

  • Bridged assets are now completely unbacked - Bridged assets which represent native Ethereum assets in the validating bridge contract (e.g., ETH) are unbacked

  • Forked “OP” is the valuable one - All of Optimism’s social consensus has decided that this is the “canonical” version

On the “Optimism Classic” fork:

  • Bridged assets are fully backed - Wrapped assets which represent native Ethereum assets in the validating bridge contract (e.g., ETH) are fully backed

  • “OPC” is valueless - All of Optimism’s social consensus has decided that this valueless (the trader owns most of it anyway), and nobody uses this chain anymore

So, even though the rollup decided to fork:

  • Optimism served as an L2 for bridged assets such as ETH - All users of the original chain just withdraw their ETH back to the L1 and recover their full collateral

  • Optimism served as an L1 for native assets that derive their value from Optimism - The value of OP is fully derived from the social consensus of Optimism. OPC is valueless as social consensus has abandoned it. Forked OP has the full social consensus, so it remains valuable.

In summary, when I use ETH or OP on Ethereum and Optimism (via an enshrined validating bridge) as a light client user, I consent to the following security assumptions and social contracts:

1) Assumes Optimism has a fully implemented validating bridge, forced tx inclusion, removal of arbitrary contract upgrades, etc. (Note this is not yet the case.)
1) Assumes Optimism has a fully implemented validating bridge, forced tx inclusion, removal of arbitrary contract upgrades, etc. (Note this is not yet the case.)

Assets bridged over a trust-minimized bridge retain the full security and social consensus assumptions of their underlying base layer.

Of course it would be bad if someone hacked Optimism and stole all the bridged ETH. That could be a death knell to a rollup if most of their TVL is from that contract. However, they didn’t break the rollup or its safety guarantees because:

The bridge is not the rollup. A fault in the bridge (e.g., a hack) does not break the rollup.

That’s why your native rollup assets can’t be stolen even if the bridge is hacked to withdraw its collateral. Maybe the attacker even minted a bunch of wrapped OP on Ethereum, but that’s not your problem. OP derives its value from the social consensus and value from Optimism. The bridged OP is simply a claim on that asset. The OP in your wallet didn’t go anywhere.

However, you would be shit out of luck if you held the wrapped bridged OP on Ethereum L1. That’s now under-collateralized. You’re taking smart contract risk when you hold any bridged asset.

Rollup bridge hacks then pose no risk to rollup-native assets held on the rollup. They pose a risk to bridged assets that derive their value from the “real” asset locked in the bridge as collateral.

All rollup assets inherit the base layer’s full technical security, but the native assets also rely on the social consensus of the associated rollup:

However, you should notice why it’s a perfectly ok assumption. You’re obviously happy with the social consensus of Optimism if you hold OP because that’s precisely why you hold it. It derives its value from that social consensus.

Just because OP relies on the social consensus of Optimism doesn’t mean that it doesn’t inherit security from Ethereum. All rollups derive security from their DA layer (particularly reorg resistance and DA) even when there are no bridged assets. Yes, social consensus for native assets could choose to fork, but that’s always the case:

If you believe that social consensus makes all technical security guarantees meaningless, then Bitcoin and Ethereum are completely insecure. PoS provides no security to Ethereum and PoW provides no security to Bitcoin by that logic, since social consensus is the ultimate authority. In reality, you’re always just subjecting yourself to the social consensus around any asset you hold. What you don’t want to do is to give a separate social consensus set power over your assets (e.g., Optimism shouldn’t be able to steal my ETH).

Burning Bridges

As an interesting thought experiment, let’s consider a rollup where the bridge burns your collateral. What if we made a simple OP Stack fork with an enshrined bridge to Ethereum, but burned the ETH you put into it:

  • Today - Lock your ETH on Ethereum, get a wrapped representation on Optimism

  • Ultra-based rollup - Burn your ETH on Ethereum, and get ubETH on this OP Stack rollup. Let’s also make it a based rollup for the memes, because memes.

What you’ve effectively done here with this bridged ubETH is:

  • Retain Ethereum security across this bridge for this rollup

  • Transferred the value of this asset from Ethereum social consensus → Optimism social consensus

ubETH no longer derives its value from being able to redeem it for ETH on Ethereum. The collateral is gone. But ubETH is the native token of this based rollup now - you need it to pay for gas, etc. It’s also used for governance. Its value is purely from the social consensus around it there.

You could also bridge the ubETH back to Ethereum, but now you get a wrapped version down there. You’re not getting back your ETH collateral. Rather, your bridged token is a representation of the ubETH collateral on the rollup (which is the “real” asset now).

Now I consent to the following security assumptions and social contracts:

1) Assumes Optimism has a fully implemented validating bridge, forced tx inclusion, removal of arbitrary contract upgrades, etc. (Note this is not yet the case.)
1) Assumes Optimism has a fully implemented validating bridge, forced tx inclusion, removal of arbitrary contract upgrades, etc. (Note this is not yet the case.)

Note it’s also possible to make this feature optional. You could allow for users to lock collateral in the bridge and get a bridged representation (say opETH), but that asset isn’t fungible with ubETH. Only ubETH is the native token for fees on the rollup and has other governance rights. It’d be a fascinating social experiment. I’d probably burn some ETH for the culture.

Sidechains - Honest Majority Bridges

When I use ETH or SOL on Ethereum and Solana (via an honest majority bridge) with a light client, I consent to the following security assumptions and social contracts:

1) Assumes Solana is connected to Ethereum via a bridge which trusts the honest majority of each chains’ respective consensus. 2) Weakest link of the two is inherited.
1) Assumes Solana is connected to Ethereum via a bridge which trusts the honest majority of each chains’ respective consensus. 2) Weakest link of the two is inherited.

When you use an honest-majority bridge to move your ETH to a wrapped version on Solana, you are granting Solana full control over your assets as well. Solana isn’t serving as an L2 extension of the asset you had on Ethereum. It’s a sidechain with full control over your ETH. It has the ability to confiscate your funds if it chooses to. It could also lie to the Ethereum bridge and withdraw the initial ETH collateral.

It goes the other way as well. A 51% attack on Ethereum could revert blocks that sent ETH to Solana, making the wrapped representation unbacked. Even a user running an Ethereum full node would lose funds here. This is the classic example Vitalik gave in his infamous argument for why the future will be *multi-chain*, but it will not be *cross-chain.*

Note that if I run a full node, I make no safety assumptions when operating on a native chain (e.g., using ETH on Ethereum). Even a dishonest majority can’t fool me. However, if I’m only running a light client, then I am trusting the honest majority. They could maliciously convince me to send me my funds out for example.

Ethereum is an L2

Ethereum can even be an “L2”. For example, let’s say I bridge my OP token from Optimism to Ethereum. In both cases:

  • My OP maintains the same social consensus assumptions of Optimism.

  • My OP maintains the same security assumptions of Optimism.

Note that Optimism’s security = Ethereum’s security in this case, so it’s indirect. In any case, the point remains - I’m adding no new assumptions external to Ethereum.

This also captures the notion that when you’re using USDC on Ethereum, you’re really trusting Circle. Ethereum can’t save you if a centralized issuer has the right to confiscate your funds. Conversely if Ethereum tried to take your USDC, Circle could always give your dollars back. Circle is the real ledger of record here.

So yea, Ethereum is an L2 to Circle. USDC holds precisely as much sway over Ethereum as an enshrined bridge holds over a rollup. “Native USDC” can be thought of as “bridged USD.” The dollars are in Circle accounts instead of Ethereum bridge contracts.

In fact, you could say that people like USDC for much the same reason they like rollups:

  • I want to use my ETH on some other chain without trusting anyone but Ethereum

  • I want to use my USD on some other chain without trusting anyone but Circle

TLDR on L1s, L2s, & Sidechains

I don’t know that this L1 & L2 definition will stick, but I think it’s a helpful framework to drive the point home. Different assets derive their value from different sources, and they carry different assumptions as a result.

When I use a chain ETH on chains as:

  • L1 (e.g., ETH on Ethereum) - I rely only on Ethereum security and social consensus.

  • L2 (e.g., ETH on Optimism) - I rely only on Ethereum security and social consensus. I also take implementation risk. (I.e., the smart contract could have a bug, same as any other smart contract on Ethereum. This includes the associated proof system, and potentially a 1 of N assumption for fraud proofs.)

  • Sidechain (e.g., ETH on Solana) - I rely on Ethereum and Solana for both security and social consensus. I also take implementation risk, same as any other smart contract on Ethereum.

Whenever you’re using a chain as an L2, that’s when you’re subject to bridge risk. If you’re using something that’s bridged, you fundamentally carry that risk if the bridged representation has value primarily from the underlying collateral elsewhere. Assets are always safest on their native chains.

However, the native tokens on that L2 do not carry this bridge risk. It’s acting as its own L1.

You could deploy an asset natively on multiple chains using a burn-and-mint bridge. However, note that this asset would then carry the security risk of the lowest common denominator of bridges deployed across all chains. For example, if someone tricks one bridge and mints a bunch of assets on that chain, then the whole token supply is affected (since all assets are fungible and redeemable 1:1).

The difference between an L2 vs. sidechain is basically whether the other chain can screw you. Obviously your money can always get stolen if you put it into a faulty smart contract (like a rollup bridge). But that risk is known and internal to the chain you’re coming from. If you perfectly inspected that code, you could find the bug. All the data is available to you. Neither Ethereum’s nor Optimism’s security rugged you if the contract gets hacked.

The difference is that in a sidechain (i.e., honest majority bridge), the risk is external to your sandbox of the data you can read trustlessly. The consensus of the other chain could just lie and rug your bridge even if it’s perfectly implemented. In a true L2 rollup bridge, the only risk is implementation, which can be known.

Overall, rollups bring two very different concepts:

  • Inheriting security - Rollups always inherit the security of their DA layer.

  • Scaling - If you have a validating bridge to your DA layer (or another chain on it), then you’re scaling - that’s what L2s do. These chains can interact with bi-directional messaging, and you retain the security assumptions of your home chain. For example, I can use my ETH on Optimism to do something that requires computation I can’t do on Ethereum, and I retain Ethereum security while doing it.

Also note that the L1 & L2 mental model I’m describing here is quite asset-specific. It’s not very helpful in considering some completely generic message passing between a rollup and its base layer. Arbitrary messages don’t really derive and hold value in the same way from social consensus or something locked in a bridge.

Getting Philosophical on Rollups

Coming back to what I described earlier, a rollup is just an output we get by running a function over some input data. It derives security based on the layer where that data is posted.

We need to stop thinking about rollups as some canonical thing defined by math and science and cryptography that Ethereum tells us is the objective truth. It doesn’t need to be this specific thing where I make a new chain, bridge over a bunch of assets, launch some DeFi stuff, etc. then Ethereum tells me it’s ok.

I can trustlessly run any function over some data on Ethereum and make a rollup. That’s it. I don’t need anyone’s permission. We come to some rough social consensus on what outputs are interesting bits of data that we care about. Rollups are literally just completely made up things.

As a random example, you could just launch a new rollup deployed on top of Optimism Mainnet to do contract secured revenue (CSR) for it:

The rollup can just trustlessly read the data that’s already being produced and posted by Optimism:

I honestly don’t have any idea if this is an interesting specific use case. But it’s a great point of what these systems fundamentally are. There are essentially infinite undiscovered rollups hidden in Ethereum’s data. You can make a rollup to trustlessly read and compute over that data however you want, then you could provably communicate it back. That’s cool.

Maybe people will find your thing interesting, maybe they won’t. But that’s the point. It’s all social consensus.

The Cost of Enshrined Bridges

It should now be clear that all rollups are “socially sovereign” rollups. However, they do not have sovereignty over assets which are locked in their bridge. Indeed that is exactly the point of these bridges. You want to use an asset (e.g., ETH) on another domain (e.g., Optimism) without trusting the other domain’s security or social consensus.

However, this comes at a cost - enshrining a bridge may impose a high cost on social hard forks. Traditional honest majority bridges rely on the other chain’s consensus. While this is optimal from a security perspective (i.e., I can use my asset on another chain without trusting it), it tethers chains together and limits their flexibility to upgrade. The connected chains would have to hard fork together.

Honest majority bridges typically allow each chains’ consensus set to hard fork costlessly. Validators are able to enforce social consensus, making hard forks more like real “upgrades.” This is often very desirable, as chains will reasonably want to make upgrades over time.

However, a trust-minimized bridge by definition does not just take the consensus set’s word:

So there is a tradeoff when you get trust composability, but it’s not a mutually exclusive and absolute “your chain is no longer sovereign.”

Note that IBC-connected chains would have a similar constraint today if they wanted to hard fork in a manner which changes the light client’s rules. For example:

  • A hard fork which changes the state machine is fine (e.g., print a bunch of tokens)

  • A hard fork which affects consensus requires coordination (e.g., includes irregular validator set changes, header format changes, etc.)

If one chain has a light client-breaking hard fork, then all of its implemented IBC-connected chains must hard fork as well. In Cosmos today this is reasonable to coordinate, but obviously Ethereum isn’t going to hard fork for every rollup that wants to upgrade.

This complexity of fork coordination could be mitigated by implementing some form of onchain upgrade mechanism (similar to how rollup onchcain governance could upgrade their smart contract). It just has the same constraint I mentioned earlier - you can’t use offchain governance to do this. It needs to be legible onchain.

It’s also important to note that consensus faults from connected chains are not “contagious.” The classic example that’s cited is the following:

  • Osmosis had LP pairs such as OSMO/UST

  • As Terra collapsed, its economic security was approaching 0. It would become rational for a 51% attacker to take control of the chain, message Osmosis via IBC to mint a huge amount of wrapped UST, then drain all LP pools paired against UST

Obviously this would be bad. However, similar to a rollup bridge hack not “breaking” the rollup, this does not “break” Osmosis. Anyone who exposed themselves to UST price risk would be wiped out, but that’s the risk you take when you willingly expose yourself to the price risk of another asset. UST did indeed go to 0 anyway. This attack wouldn’t have “broken” other chains connected to Terra.

Where trust-minimized bridging is particularly valuable though is when a user wants to use a given desirable asset (e.g., ETH) on other domains in a more productive manner while retaining their initial security assumptions. They don’t want to allow the chain they’re using to confiscate their funds.

This is how rollups “scale” the native assets of Ethereum. All Ethereum rollups inherit its security, but they’re not “scaling Ethereum” if they don’t have a trust-minimized bridge between them to port across assets and other messages.

The Root of the Misunderstanding

Sreeram recently had an amazing thread (as usual) on Bitcoin sovereign rollups and security which I’ll summarize as a starting point. These rollups would post their data to Bitcoin, but Bitcoin doesn’t have smart contracts to verify proofs (nodes verify offchain).

There are four properties which determine the security (safety and liveness) of a chain:

  1. Re-org Resistance - Finalized blocks will not be reverted.

  2. Censorship Resistance - Anyone willing to pay the necessary fees can get their transactions included.

  3. Data Availability - All transaction data for the chain has been made available. This allows anyone to recreate the rollup state (and arbitrate fault proofs if needed).

  4. Validity - Anyone can determine that the transactions correctly result in the current state.

Writing data to a base layer (such as Bitcoin) gives you the first three. Number four is where the knives come out and people start fighting. As I discussed earlier, the classic rollup fundamentalists will tell you that you aren’t getting the validity from the base layer if the base layer doesn’t verify for itself (as in an Ethereum smart contract).

But we don’t need Ethereum to tell us that - that’s the whole point of proofs! Just send me a proof.

The fundamentalists will tell you to run an Ethereum full node to check that proof. However, that’s just because the rollup light client is implicitly embedded within the Ethereum full node. But you don’t need to run an Ethereum full node and verify all the other stuff that Ethereum does - you just care about verifying the rollup’s proof here. You can simply have a rollup light client that checks the proof in some other manner (e.g., p2p, or post the proofs to may chains) without the overhead of running an Ethereum full node.

Obviously you get other nice things by running an Ethereum full node, but that’s besides the point. To know the validity, I can check in any number of ways. So “getting validity from Ethereum” makes no sense here. You’re always running some type of node to check the state of the world:

  • If you’re a full node, you’re assured of validity by checking yourself.

  • If you’re a light node, you’re assured of validity from the proof. You just pick one method or another for how you check that proof (whether that’s p2p, via a smart contract bridge, etc.).

In any case - the user is ensured of validity, and they now have all four security properties.

So yes, you can get the full security (safety and liveness) of the base layer even if the base layer does not verify the proofs for your rollup.

What you don’t get is a validating bridge that allows you to move assets back and forth between the rollup in a trust-minimized way, but this is completely orthogonal to whether your rollup inherits the base layer security. Again - “scaling the base layer” and “inheriting security” are completely different things. Both are valuable, but they are very different.

And yet the fundamentalists argue that sovereign rollups rely on an economic majority security:

Source: Patrick McCorry - Settlement Layers? Ethereum Rollups? Sovereign Rollups?
Source: Patrick McCorry - Settlement Layers? Ethereum Rollups? Sovereign Rollups?

The argument posits that the offchain actors in a sovereign rollup determine the “canonical chain” (and they are presumably the economically important actors) vs. classic rollups allow Ethereum to decide the canonical chain. Indeed they go so far as to say “in a validating bridge, a consensus fork is not possible.”

As described earlier, this is false. Social consensus always determines the canonical chain, regardless of whether you have an enshrined bridge. It’s not possible to fork the bridge socially, but the bridge is not the rollup. The rollup can do as it pleases. A blockchain is always reliant on social consensus. That’s fundamentally what it is.

So here’s the mistake that the fundamentalists make in my view:

Many incorrectly assume that the social consensus of an enshrined bridge rollup will abide by the base layer’s (e.g., Ethereum’s) social consensus regarding which is the “canonical chain.” However, this is indeed an ASSUMPTION.

All rollups are sovereign rollups, and even users of an enshrined bridge rollup may choose to follow another chain. Whether or not to abide by the bridge’s view of the rollup is itself a matter of social consensus.

Thankfully, Kelvin has been slowly converting the “rollup is defined by the bridge” team.

WTF Is “Settlement” Then?

As James so eloquently put it:

“Settlement” generally gets thrown around for one of three things as he describes:

1) Ledger of Record (for a specific asset) - This could be Ethereum for ETH, SOL for Solana, etc. It’s the definitive ledger of record for that asset. “Settlement layer” is fuzzy (e.g., I can “settle” an ETH trade on Coinbase). This is how I use the term “L1.”

2) Finalizing an Enshrined Bridge (for a specific rollup) - The bridge doesn’t “settle” the rollup. It just finalizes its bridge. Bridge ≠ rollup.

3) Petty Boosterism (for my favorite coin) - Settlement layer sounds cool I guess.

I’ll add a fourth one as well:

4) Source of Truth (for rollup nodes) - The bridge can be users’ SoT, implicitly verifying the rollup’s state transition within a base layer (e.g., Ethereum) full node. It provides a single point of reference for nodes to look to. These proofs could also be distributed via the p2p layer. However, posting them to a chain (or many chains) could be useful in circumstances where p2p communication is uniquely challenging. For example, it can be difficult to conduct IVG fault proofs via p2p, so it’s easier to have a smart contract arbitrate them. That technical distinction is noteworthy here.

Overall, “settlement layer” has been a fuzzy mix of the above, referring to a bridging/liquidity hub which verifies the state transitions of connected chains. For Ethereum rollups today, it’s incredibly important - the bridge is so important to their existence that it would in practice likely dictate the “canonical chain” in the event of any social consensus split today.

However, this is a spectrum of importance which will continue to evolve with different “settlement layers.” Enshrined bridges may become even more valuable as many chains hopefully begin to interoperate more. Conversely, native burn-and-mint bridging for the likes of USDC with CCTP could be a force in the other direction, reducing the need for bridged assets (and their associated risks).

Lmk if you have any better names out there.

Settling to 2 Chainz - Validiums Aren’t Real

Here’s a fun idea - what if we have a rollup that “settles” to two chains?

Let’s say we deploy Optimism as a “validium.” Normally this would use one settlement layer and one DA layer:

Source: Me, The Complete Guide to Rollups
Source: Me, The Complete Guide to Rollups

But now let’s deploy it as a validium ”settling” to multiple chains:

  • Optimism has two validating smart contract bridges on two chains - one on Settle_1 and another on Settle_2. Both bridges receive validity proofs proving the validium’s correct state transitions.

  • Optimism uses DA_1 as its DA layer. DA_1 sends DA attestations to smart contracts on Settle_1 and Settle_2.

Some argue that this would degrade your security to the lowest common denominator of the chains you’re settling to. However, the only funds at risk are the funds bridged from the chain you're settling to. Remember, bridge ≠ rollup.

Let’s think about what could break here:

  • DA layer - The validator set of DA_1 could lie to either bridge, sending it an attestation that data is available when it is not. It could potentially also censor or reorg depending on the chain.

  • Settlement layers - The contracts on these chains are just finalizing the bridges. A fault in Settle_1 could make contracts there think your validium is sending messages that it isn't sending, but that fault won't impact the validity of messages seen on Settle_2.

A “settlement layer” isn’t finalizing your rollup. It’s finalizing its bridge which has a view into your rollup. If Settle_1 is malicious, it can’t steal your OP in your wallet on Optimism for example. Anyone using this rollup can compute over the data on the DA layer and see the deterministic result. So the lowest common denominator security doesn’t apply to “settlement layers,” but it does apply to your DA layer. The DA layer is where you derive your security from. If you were to rely on separate DA layers equally, then a fault on either side could cause a fault everywhere.

So validiums are just rollups. They’re rollups to whatever DA layer they use.

The rollup isn’t inheriting security of their settlement layer. Just think about it. Let’s say you have a classic rollup that uses Ethereum for DA and has a validating bridge there. I can go deploy a validating bridge for your rollup on some shit chain by myself. It looks to Ethereum for DA, and it also gets sent a perfectly legit validity proof. I didn’t make your rollup an insecure validium. I just gave your Ethereum rollup another bridge.

Rollups inherit security from their DA layer. You get your security by posting your data somewhere, then everyone can go agree on what that data means. That’s about it.

Bridging & Liquidity Hub

As it pertains to rollups, arguably the primary benefit from posting proofs to Ethereum is because it serves as a hub for liquidity and bridging**.

Rollups already get security from the DA layer, but trust-minimized bridging is what allows a rollup to fully tap into the economic activity of other chains. That’s the real reason that rollups enshrine trust-minimized bridges to Ethereum. They want to tap into the full liquidity and network effects that Ethereum facilitates.

Remember that trust-minimized bridging between rollups is only possible for rollups which use the same DA layer. Any rollup can enshrine a trust-minimized bridge either to their DA layer, or directly to other rollups which share their DA layer. So we can broadly imagine three bridging topologies:

Pairwise Bridging

Rollups can enshrine bridges with each other, effectively forming a “cluster” of rollups that are all tied together. If there are many chains, this eventually results in high messaging complexity. Pairwise bridging between N rollups = N^2 bridges.

The fungibility of assets is another problem. Considering two examples:

  • Transfer an asset from chain A → B → C

  • Transfer an asset from chain A → D → C

The two assets on Chain C are not fungible. You always need to trace back the routes for wrapped asset bridging.

Hub-and-Spoke Bridging

A single chain can serve as a bridging hub to coordinate between many rollups. Rollups would enshrine a bridge into this “settlement layer.” This may be the base layer itself (e.g., Ethereum or Celestia), or it may be a “settlement rollup” on top of the DA layer (e.g., Eclipse or Astria EVM). These hubs could restrict their VMs, or be general purpose.

In any case, rollups which enshrine bridges into this shared “settlement layer” get direct trust-minimized bridging with it. Additionally, they would have indirect trust-minimized bridging to other rollups that also enshrine bridges to this same settlement layer.

You reduce the N^2 bridging complexity back down to N, and you solve the issue of asset fungibility that arises from bridging between many different chains. It can also serve as a focal point of shared liquidity.

Aggregated Bridging

Lastly, we could get fancy with ZK stuff and do aggregated bridging with many rollups. I wrote about this idea from Sovereign Labs almost a year ago, and they released another great post covering it recently here.

This is another option to get all-to-all bridging and reduce the bridging complexity back from O(N^2) to O(N), without using one chain as the coordination hub. The basic idea is surprisingly simple - take a proof for all N chains, recursively aggregate all of them offchain, then verify the aggregate proof on each rollup. Now each rollup has a single proof for all rollups in this network!

Effectively you’re making a very “flat” bridging topology vs. a more vertical hub-and-spoke model where you’re bridging up and down through a single point. You can now eliminate the two-hop bridging process as well.

Stickiness & Network Effects in the Rollup Stack

Maybe you’re thinking this is all just a bunch of semantics around social consensus jargon, and none of this matters. Well, now I’ll explain why that is not the case. Aside from the obvious security implications, there’s another huge point:

The arguments I have laid out have fundamental implications for the balance of power in the rollup stack.

Let’s dive into that. Where do the network effects for DA layers, settlement layers, and rollups really come from?

Rollups

Following my logic argued above, rollups may have more power and sovereignty over the valuable new state which they create natively. Even when they have an enshrined bridge to Ethereum, I don’t inherently consider them “baby chains” that are locked into Ethereum.

If all the valuable new state is being created on rollups with their own native assets that derive valuable from their own environment, that has meaningful implications for the power dynamics in the stack.

DA Layers

As a recap of what I provided above to synthesize things:

  • Rollups can inherit full security from their DA layer, regardless of whether they have an enshrined bridge connected to it

  • It’s only possible to get trust-minimized bridging between rollups that share a DA layer

Overall, there are positive network effects here. It’s beneficial to have many rollups sharing the same DA layer - they can pool security and increase the size of the ecosystem that gets trust-minimized bridging with each other. Having each chain be its own DA layer that connected chains can run DAS on top of would create incredibly high overhead and fragmented security.

Conversely, overloading a single layer that may not be able to handle the whole world’s DA throughput could increase costs for everyone. Scalable DA will matter.

Settlement Layers

So, are all the rollups going to ditch Ethereum then? They have sovereignty over their valuable state, and maybe they want to do their own thing. There’s always been speculation around this idea. Or maybe they just need a DA layer, but they don’t need to “settle” to Ethereum anymore?

Well, not so fast - settlement layers still have some serious network effects. We see this incredibly clearly today since we’re colored by Ethereum. As I mentioned above, this is arguably the biggest benefit to today’s rollups. They draw a huge amount of their TVL and users by tapping into Ethereum’s massive liquidity and network effects.

ETH is Ethereum’s #1 export. You’re not about to dip on Ethereum if ETH actually becomes “money” (whatever this means), and your whole rollup economy is based on it. Trust-minimized bridged ETH is the Trojan Horse into the rollups:

This dynamic will look quite different for different settlement layers. Others won’t have the depth of liquidity and native activity that Ethereum will have. The bridging topologies may also evolve meaningfully over time (e.g., as in the aggregated bridging example).

The following are some of the areas which could make a settlement layer attractive to a rollup:

  • Asset issuance - For example, this could be desirable native assets (e.g., ETH) or from a stablecoin issuer (e.g., if USDC or DAI issues only on the settlement layer, then it’s bridged up) that people want to use on rollups in a trust-minimized manner

  • Bridging hub - Even if the assets used in a rollup ecosystem aren’t native to the settlement layer, a bridging hub is still valuable for routing between them (e.g., as described above with fungibility issues around bridging paths)

  • Users - There’s not a lot of these in crypto. This is kinda related to the above points.

  • DeFi & Shared Liquidity - Stuff like DeFi pooling could be useful where you keep all the liquidity on one chain then batch transactions from a bunch of chains to interact with the unified liquidity.

  • Onchain verification vs. p2p - As described previously, p2p fault proofs can be particularly challenging. It’s potentially easier to run them onchain.

This is also one of the reasons why I find the proposal I mentioned earlier to enable ZK verification on Celestia quite interesting. It allows rollups to create a trust-minimized two-way bridge with Celestia, bridging up their native token into the Celestia rollup ecosystem. To the extent this becomes a widely used asset in these rollups, that’s sticky in the way that I mentioned for ETH in Ethereum rollups.

I’d also note that just being “branded” as part of an ecosystem could still help with network effects. Social alignment with the values of an ecosystem such as Ethereum or Celestia does have real implications.

Conclusion

It’s social consensus all the way down, rollups are real, and nothing is real.

Disclaimer: The views expressed in this post are solely those of the author in their individual capacity and are not the views of DBA Crypto, LLC or its affiliates (together with its affiliates, “DBA”). DBA is an investor in Eclipse Laboratories, Inc. The author of this report has material personal investments in ETH, Celestia, and Sovereign Labs Inc.

This content is provided for informational purposes only, and should not be relied upon as the basis for an investment decision, and is not, and should not be assumed to be, complete. The contents herein are not to be construed as legal, business, or tax advice. References to any securities or digital assets are for illustrative purposes only, and do not constitute an investment recommendation or offer to provide investment advisory services. This post does not constitute investment advice or an offer to sell or a solicitation of an offer to purchase any limited partner interests in any investment vehicle managed by DBA.

Certain information contained within has been obtained from third-party sources. While taken from sources believed to be reliable, DBA makes no representations about the accuracy of the information.

]]> jon-dba@newsletter.paragraph.com (Jon Charbonneau) <![CDATA[How To Do Lower-Case r research]]> https://paragraph.com/@jon-dba/how-to-do-lower-case-r-research vmLKVZbBFxap6Iyjnm8R Mon, 01 May 2023 23:20:18 GMT Introduction

This is my first shot at a “personal” post. I’ve been in crypto for just over a year, and somehow managed to trick people into thinking I know what I’m talking about despite lacking any of the knowledge, skills, or background I’d love to have.

Some people have awesome backgrounds and do capital R Research, but I just embrace it and do lower-case r research.

These are some of my personal reflections and ramblings. Mostly it’s my advice for how even as a newcomer to crypto, you can trick people into thinking you also know what you’re talking about.

Be Obsessively Curious

This is the biggest thing I’ve noticed from the most successful people around me. You’ve gotta be a little messed up in the head to read about erasure coding on a Saturday at 2am. I don’t really have any advice here tbh. Hopefully you like this stuff. If you don’t, probably ngmi.

Nobody’s an Expert in Crypto

This is awesome! I definitely was super nerd-sniped by the tech and aligned with crypto’s ethos and politics.

But possibly the biggest reason I dipped from my job in banking (lol yea) last year to work in crypto was that it’s constantly changing.

You can literally show up as a nobody and add value right away. Lean into that! I especially focus on areas that are constantly evolving and lack real “experts.”

Recently I’ve been spending a bunch of time on intents/preferences and how to decentralize rollups. That means going deep on things like SUAVE and shared sequencers. These are perfect as a newbie because nobody really understands them! The teams building them kinda do, and even they have open questions. Shared sequencers didn’t even exist as an idea until the end of last year.

I’m not going to be the world’s expert on the fancy new ZK SuperHyperMegaNova folding schemes or some other paper that I don’t understand. I could spend the next year on some of that stuff alone, and I’ll still be the 1000th smartest person in the room behind all the guys who studied cryptography for the last century. I’m usually just gonna do this:

Be Focused & Find Synergies

I don’t think it’s super helpful to be a gaming expert for a month, then try to be a ZK expert the month after, then a monkey PFP expert the month after. Find the general area you really like, and go deep. For me, that’s loosely been “infrastructure” stuff.

Getting decently competent at this stuff isn’t a magic trick, and you don’t have to be Einstein. It just takes a lot of time. Part of that is the obsessiveness and curiosity I mentioned above. The other half is focus.

That tends to mean finding areas with synergies. Blending together related topics in a specific area is where you can add value. For example, rollups are hard because you’ve gotta think about how to scale blockchains, make sustainable economics, implement proofs, decentralize operators, and a bunch of other stuff.

There’s a ton of brilliant developers, cryptographers, formal economists, and many others who are infinitely smarter than me. But not a lot of people have like 80% competency in several of the related areas that mesh together. That’s often where you can be useful.

Write!!

I can’t emphasize this enough. Write. But not crappy generic stuff. There’s an overload of crypto content out there, but not a lot of good stuff. Quality > Quantity.

The simplest example of this was the first mega report I did on Ethereum. I had just started and barely knew what I was doing. Ethereum was the most important thing in crypto, and people talked about it constantly. It was AMAZING to me that not a single comprehensive report existed which could take you from 0-100 in like an hour.

I didn’t have to be a genius to do it. I just had to sit down for a month and ignore most of my other responsibilities. I made it because it’s what I would have killed to have available to me to read, so I figured it’d be helpful for others too.

I was nowhere near the world’s expert in a single thing I wrote there. Maybe you’re an expert in data availability sampling, but then you might not understand MEV super well. Ethereum had become so big and complex that it’s hard for people to find the time to fit it together.

Just find the synergies that are valuable and put those pieces together. Crypto is often about putting the puzzle pieces together. It weaves together so many seemingly unrelated disciplines. Get good at making puzzles.

Don’t write for others. Be incredibly selfish, and do it for yourself. I’ll often listen to a podcast or read some post, but then when I try to explain it I realize 1% of it stuck. At least for me, writing is by far the best way to learn.

Then, putting it out there is how you meet and attract likeminded people. If I wasn’t writing for the past year, I’d literally be nowhere and know nobody.

A lot of people probably don’t write enough because they’re afraid of others saying you’re a dumb idiot who doesn’t know what you’re talking about. That’s fine! That’s probably part of why I write such long pieces. Leave no stone unturned, and you’ll be a helluva lot more confident in what you’re saying. But only under one condition.

ELI5 & Information Density

The one thing I think I’ve actually been very good at is technical writing that’s approachable to a broad audience. Your weakness is a strength here!

I could ELI5 when I’m writing about KZG commitments because when I started that report I didn’t know what a polynomial was. I was literally watching Khan Academy videos. It’s easiest to ELI5 if that’s the process by which you have to learn it. It’s not magic. Write as you learn. Use your lack of technical background to your advantage.

A huge component of this is just writing style. Don’t be afraid of long reports. I write borderline books. Be afraid of long reports that have the amount of information you could fit into a blog post. Use bullet points, short sentences, simple graphics, etc. I make memes 50% because memes are dope, and 50% because they seriously work.

This also just takes legwork. Reread your book a hundred times to remove two commas and like half a word on every turn. Get to the point. Make it readable.

Don’t try to write academic papers in such an incomprehensible manner that nobody will read them. Write like a literal 5 year old, otherwise nobody will know what the hell you’re talking about.

Use the People Around You

Talk to the smart people! I didn’t design shared sequencers when I made that Rollups Aren’t Real post. I spent a ton of time talking to the people on the cutting edge who were when nobody else really was.

We host small research sessions every week or two in our office, and we had all the gigabrains in there for three meetings before I made that post. Shoutout Josh for even flying back and forth for each of them. Smart and curious people love to talk about this stuff.

But you MUST put in the work. Show you’re interested and put in the time, then people will talk to you. If you DM “yo what do you think of my coin” then yea people won’t respond. If you put in the work, then anyone will.

When I did that Ethereum report, I was a total rando. But I reached out to Tim and the man, the myth, the legend Dankrad himself. He hopped on a call for an hour to answer every dumb question I had. Then he reviewed my post in painstaking detail providing invaluable comments!

I couldn’t have done a single meaningful thing in crypto without the absolutely brilliant and amazing people around me. Most of them are infinitely smarter than I am. But if you’re obsessively curious and hard-working, literally anybody can leave a mark here.

That’s what makes crypto so fucking fun.

Afterword

This isn’t advice anymore. I just want to give a sincere thank you to all of the unbelievable people who’ve made the past year the best of my life.

MJ is top of that list. I never imagined loving what I do this much, and loving the people I get to do it with. I couldn’t have dreamed for a better partner to guide me and hide my flaws.

I truly can’t express how lucky I am to be in the position I’m in. I very rarely get emotional, but this one actually is for me. We get to work on some of the coolest problems in the world, building what I honestly believe can be some of the most important stuff in the world. I just wanna do math and check the results with my friends.

I can’t wait to look back on all of it with y’all one day.

]]> jon-dba@newsletter.paragraph.com (Jon Charbonneau) <![CDATA[SUAVE, Anoma, Shared Sequencers, & Super Builders]]> https://paragraph.com/@jon-dba/suave-anoma-shared-sequencers-super-builders oJmqGieO5fxWDP0I7sL9 Thu, 27 Apr 2023 00:25:51 GMT Thank you to Rajiv Patel-O'Connor, Tarun Chitra, getsqt, Ben Fisch, Evan Forbes, Christopher Goes, and apriori for incredibly valuable insights, feedback, and review of this post.

Thank you to Robert Miller, Hasu, Shea Ketsdever, Josh Bowen, and many others for great discussions around some of the topics here as well.

Introduction

This post further analyzes SUAVE and shared sequencers as a follow up to my last:

Part I - SUAVE: I dive into its contemplated architecture, uses, limitations, and interactions. I won’t focus on the specific PET implementations (i.e., SGX, MPC, FHE, etc.). I’ll mostly treat that as a black box here.

Part II - Anoma: Anoma is built on many of the same underlying ideas as SUAVE, but it takes a fundamentally opposite approach.

Part III - Shared Sequencers:

  • Use in atomic X-chain transactions and MEV capture

  • Interaction with PBS and potentially centralizing forces on builders

  • Economic allocation challenges

  • Rollups’ reduced flexibility to implement validator-enforced customizations

  • Rollups’ ability to implement VM customizations (e.g., deterministic ordering rules)

Part I - SUAVE (Single Unifying Auction for Value Expression)

SUAVE will be an independent network which allows any chain to outsource two roles:

  • Mempool - Users could send transactions to the SUAVE mempool instead of their “home” chain’s public mempool (e.g., Ethereum).

  • Decentralized Block Builder - SUAVE outputs (full or partial) blocks that other domains’ validators can accept (e.g., Ethereum proposers could accept a block built by SUAVE).

Source: The Future of MEV is SUAVE
Source: The Future of MEV is SUAVE

The goal is to be the mempool and block builder for any domain. Aggregating preferences in a single auction has several benefits:

  • X-chain builders can earn more than single-chain builders.

  • Efficiency gains from aggregating and clearing preferences in the same auction.

  • A decentralized and privacy-preserving builder should attract more orderflow vs. centralized builders.

  • This stuff is complicated. Most chains shouldn’t have to focus on building advanced privacy-preserving primitives.

Architecture

Flashbots describes SUAVE as having three components:

  1. Preference Environment - SUAVE Chain and its mempool are specialized to aggregate user preferences from any domain. Users place bids for execution.

  2. Execution Market - A network of specialized “executors” listen to the SUAVE mempool and compete to execute user preferences.

  3. Decentralized Block Building - Executors can ultimately produce (partial or full) blocks for other domains.

Source: The Future of MEV is SUAVE
Source: The Future of MEV is SUAVE

The SUAVE protocol itself has two logical layers:

  • Messaging layer (i.e., SUAVE mempool) - Transmits preferences to be executed

  • Settlement layer (i.e., SUAVE Chain) - Settles payments to executors that fulfill preferences

SUAVE Chain is primarily intended to process transactions for:

  • Bridging funds

  • Initializing smart contracts which offer bids to fulfill preferences

  • Submitting oracle updates about the state of other domains (to check that preferences were fulfilled)

  • Claiming bids after a preference is fulfilled

However, SUAVE is a permissionless EVM chain, so anything could be deployed. Native transaction activity outside of its “intended” use is unclear.

The incentives to participate are:

  • Executors - Incentivized by bids

  • SUAVE Chain Validators - Incentivized by network transaction fees

The exact security model of SUAVE Chain is still TBD (e.g., L1, rollup, re-staking, etc.).

TLDR - SUAVE has its own chain and mempool. Anyone can express preferences to SUAVE for any executor to fulfill. Whatever executor fulfills the preference can claim the associated bid (payment). Together, these pieces allow any chain to outsource their own mempool and block building.

Simplified Transaction Lifecycle

I think of the typical SUAVE transaction lifecycle in four high level stages:

  1. Preference Expression - I tell SUAVE what I want done. I place a bid for whoever gets it done. It’s like a bulletin board for preferences.

  2. Execution Optimization - Some magic happens inside the black box. Executors figure out the optimal way to get me what I wanted.

  3. Preference Settlement - Executors go to the chain(s) where I want something done, and they make sure it gets done.

  4. Payment Settlement - After my preference has been fulfilled, the executor can claim the bid I placed back on SUAVE Chain.

Now let’s walk through it in detail.

1) Preference Expression

You can think of users as having two kinds of transactions:

  1. Smart Preferences - I have a preference I want fulfilled, and I’m willing to pay a bid to any executor that can get it done for me. I can express any arbitrary preference I want by writing a smart contract on SUAVE.

    Example - I want to close an ETH/USDC arbitrage between Optimism and Arbitrum. I’ll pay 3 ETH to whoever gets it done for me.

  2. Dumb Preferences - I’m just a regular user who wants to buy a shitcoin without 100% slippage. I just set my wallet RPC to rpc.flashbots.net and send my transaction:

    Today - Your transaction is routed to Flashbots Protect, where the centralized builder keeps your transaction private and includes it.

    Future - Your transaction is conditioned for you behind the scenes such that it’d be directed to an OFA like MEV-Share which feeds into SUAVE. The conditions of the OFA can be encoded as part of your preference for you.

There isn’t a clear technical distinction, but the point is that “regular” unsophisticated users wouldn’t need to personally code some complex smart contract logic to express their preferences to use SUAVE in a basic way.

Preferences are messages that a user signs to express a particular goal. They unlock a payment (bid) if the user’s conditions are met. Preferences can range from:

  • Simple Transaction - Contain a simple payload to be executed on a specific domain (e.g., an ETH transfer on Ethereum).

  • Abstract Intent - Make an abstract statement of what I want to achieve and leave the optimal routing to the executors. This may involve an arbitrarily complex sequence of events across multiple domains.

SUAVE is introducing a new transaction type that provides a decentralized way to pass preferences. These will build on the existing properties of bundles (e.g., pre-confirmation privacy and no reverts) and allow for richer expression.

We could see innovation around preference expression to serve users’ needs. For example, executors could specialize to “pre-process” transactions in ways that make them more valuable, such as:

  • Paying gas fees on users’ behalf

  • Batching similar transactions together (e.g., trades with a coincidence of wants)

As more preferences are aggregated in one unified mempool, executors can better maximize all users’ welfare. For example, batch clearing is more efficient when more users have offsetting preferences. This is similar to the batching that CoW Swap solvers do today. However, the batching in SUAVE here could be more decentralized and completely generalized (vs. centralized and app-specific).

Note that SUAVE can still build blocks with transactions from any publicly available mempool as well, just like any centralized builder:

Example Bids

Users can express whatever preference they want via smart contracts on SUAVE Chain. This requires depositing funds on SUAVE Chain and placing a bid that an executor can claim if they fulfill your preference.

SUAVE is a stateful system where:

  • States are denoted by s_1 → s_2 → s_3…

  • s is the current SUAVE state

  • S is the set of all historical SUAVE states confirmed by the SUAVE Chain consensus

  • exec(bid,s’) outputs b,e

  • b is the bid that is paid to address e (the executor who fulfills the preference)

Considering a few examples:

Source: MEV Roast | Privacy Tradeoffs - Phil Daian
Source: MEV Roast | Privacy Tradeoffs - Phil Daian

In all cases - I have something I want done. If an executor gets it done for me, they can claim the 3 ETH bid against the oracles. Note that the example bids above are flexible in who the bid specifies as the executor able to claim the reward:

  1. If my preference is fulfilled, whoever submits the transaction behind me can claim the bid. This assumes that the executor can reliably insert another transaction of their own (position 1) behind mine (position 0). They’re effectively “tagging” themself as the executor who can claim the bid.

  2. Similar case as the first example.

  3. Given that the block is empty, the only person who could be the executor is the actual block producer (i.e., miner, validator, etc.), so they’re specified as the executor able to receive the bid.

  4. I just want someone to create a resulting state for me, and whoever sends the transaction that gets that done can claim the bid.

Preference Expression & SUAVE Chain Block Times

With this in mind, will SUAVE Chain’s block times present a bottleneck in preference expression? Consider an example:

  • If SUAVE Chain has 1s block times, and

  • I want to express a preference for a domain that has 500ms block times

There are two possible scenarios here:

  • Expressing my preference requires a SUAVE Chain onchain transaction - I’m now bottlenecked by SUAVE Chain’s block times.

  • Expressing my preference does not require a SUAVE Chain onchain transaction - there’s no bottleneck.

If this is a meaningful bottleneck, then SUAVE Chain would be pressured to have ultra-fast block times in order to service preferences for other domains with low block times. You’ll get dragged down to the lowest common denominator.

Let’s walk through an example preference lifecycle to see the flow:

  1. Bridge funds to SUAVE Chain. However, if I already have funds on SUAVE Chain, this isn’t needed.

  2. Initialize a smart contract that allows me to express my preferences, and deposit funds. If I need to make a new smart contract or deposit funds, then I’ll need a transaction.

    If this is a generic function, I can just reuse an existing smart contract (e.g., a strategy that I have deployed as a smart contract with funds in it).

  3. Communicating my preference typically would not require a transaction to be mined on SUAVE Chain:

    Option 1 - Create a signature (not a transaction) that expresses my preference and pass it directly to the SUAVE executor marketplace to save on latency (this is a different network layer than the mempool).

    Option 2 - Use SUAVE’s special transaction type carrying your signed commitment into the SUAVE mempool. This ensures the maximum number of executors will see it. (Note: there are currently very few details as to what exactly this new transaction type is, or how it achieves these properties.)

  4. SUAVE executors compete and/or collaborate to fulfill my preference on the destination chains.

  5. Oracle updates SUAVE Chain after my preference was met, and the executor can claim the bid I made. This requires an onchain transaction, but it’s of little concern (executors can get paid back after the fact).

MEV Bot Contracts

Let’s take a step back and understand how searchers operate today. MEV bots deploy custom onchain smart contracts to execute their strategies:

  • Offchain - The source code is first written offchain in an easily readable HLL (e.g., Solidity). While a DeFi protocol’s smart contract would verify and publish this, a MEV bot wouldn’t.

  • Onchain - Smart contracts only store the compiled bytecode onchain (e.g., EVM bytecode for Ethereum). This is not as easily readable as the HLL from which it was compiled. They’re generally written in a manner which intentionally obfuscates them (i.e., it’s difficult to de-compile the visible bytecode and figure out the logic behind them).

Smart contracts cannot execute by themselves (an EOA must trigger their code to initiate a transaction). So, searchers run offchain logic and real-time monitoring (e.g., mempool transactions, CEX prices, chain state, etc.) then decide when to make transactions/bundles and trigger their onchain contract logic based on that information.

They can push bundles to them, expressing how they want something executed. For new strategies, they deploy new contracts. As opposed to just sending vanilla EOA transaction bundles on the fly, searchers often use smart contracts as well to provide finer control over execution:

  • They can provide guardrails, adding in custom checks during execution simulation which can revert if some condition is not met (e.g., if they would incur more slippage on a trade than expected).

  • More easily facilitate execution across multiple contracts in the same transaction (e.g., borrow flashloan from Aave + trade on DEXs + repay flashloan)

  • Potential gas savings, such as writing something more efficiently than what a UI provides (e.g., directly interacting with a Uniswap pool vs. going through their router contract).

Downsides include:

  • You’re making your code public. Raw EVM bytecode is difficult to read, but given enough time you may be able to back out useful information.

  • If you’re not careful, your bot could get hacked or exploited if there’s a vulnerability.

Let’s consider a simple sandwich bot example. I’m a searcher with a smart contract SC deployed onchain to execute my strategy. The transaction flow is as follows:

  1. My trading system runs offchain logic to monitor the mempool, and it spots a target tx_user (SushiSwap trade with a high slippage limit).

  2. Trading system processes that info with transaction simulations and/or other heuristics to optimize and speed up the process. I decide whether or not I can trade on it, and what I’m willing to bid.

  3. I send my bundle to builders via a JSON-RPC request. My bundle is composed of [tx_frontrun, tx_user, tx_backrun], and I offer my bid via direct coinbase.transfer to the fee recipient (it’s also possible to bid via gas price).

    Using SC to help manage on-chain execution, I can make the coinbase.transfer conditional upon my validity conditions (e.g. only pay if I'm able to earn at least as much as I expected from the sandwich).

    I signed my transactions with my EOA. However, note that SC will actually execute the trade (i.e., SC has my funds in it, and that’s what will execute the txs against SushiSwap, not my EOA). I’m just signing with my EOA to call the SC.

  4. Builder simulates the bundle, which includes running through the checks I programmed into SC. If it reverts upon simulation (e.g., if someone gets the opportunity ahead of me, my conditions aren’t met, etc.), then the builder won’t include it. My transaction is successful though, and they accept my bid.

  5. Builder submits block → relay → proposer includes the block.

  6. EL nodes execute the transactions in the block sequentially. This includes my bundle in which the "bread" = my transactions to my SC. SC checks specific conditions in the bytecode around reversion. (E.g., checks that the sender interacting with it, my EOA, is authorized to do so and other criteria for execution are fulfilled. Note that adding more checks also increases my gas cost.). Then it has some branching logic to execute the strategy. It now successfully executes, and the chain state is updated.

Overall, searchers already express preferences via smart contracts in a sense today, but they do not bid with them in the same manner as they would with SUAVE.

Bidding Language

For a unified auction to interpret a wide range of preferences, there needs to be some form of unified “language” that everyone can use. In SUAVE’s case:

  • SUAVE Chain will be an EVM fork

  • All preferences will be expressed via smart contracts on SUAVE (EVM bytecode)

The Turing-complete EVM provides the requisite expressivity. However, one question is whether the EVM is too expressive. Classical impossibility theorems exist in this area, showing how a bidding language which allows for arbitrary expression can result in unbounded computational complexity, rendering your auction impractical. In a world where SUAVE is looking to express arbitrarily complex preferences for arbitrarily many domains, that combinatorial explosion seems unclear.

There may also be concerns with griefing attacks here. For example, I might express a preference via a contract that always overflows the gas limit unless one particular input is provided. Then, nobody could simulate the actual condition for that contract until they have that input. The EVM doesn’t provide great DoS prevention here.

The need for EVM smart contracts to express all preferences also seems suboptimal. If you’re trying to implement complex logic such as:

  • If price on Uniswap is > 2000 and < 2000 on SushiSwap → then trade on Uniswap first, and SushiSwap second

  • If price on Uniswap is < 2000 and > 2000 on SushiSwap → then trade on SushiSwap first, and Uniswap second

Then writing custom smart contracts that implement this as a decision tree appears to be necessary. You obviously won’t be writing out new smart contracts every time you want to express something to SUAVE - you’ll have template contracts to execute strategies similarly to what was described earlier.

However, not every abstract preference a user could have will be serviced by existing contracts. It would appear beneficial to have a more native way to express preferences at the user intent level.

2) Execution Optimization

Next up, executors compete to fulfill user preferences across any domain.

Orderflow Auction (OFA)

You’ve probably heard of MEV-Share by now - Flashbots recently announced their beta version. This is the (trusted) v1 of the OFA which will eventually be worked into SUAVE. It’ll take multiple iterations to improve it and reduce the trust in operators such as Flashbots.

Those details aren’t the focus here though. The abstraction is that users send orders, and searchers (executors) competitively bid to give users best execution. Some variation of this would be a central part of SUAVE.

Programmable Privacy

Bids b are composed of:

  • Deposit k

  • Payee e: S → A

  • Execution predicate P(s)

  • Encrypted data blob c

  • Encryption predicate Q(s)

  • Set of peekers ∑

In which:

  • e maps from SUAVE states s ∈ S to the set of SUAVE accounts A

  • Predicates P(s) and Q(s) are likewise over states of SUAVE

The result of executing a bid b:

  • If the current state of SUAVE s_cur satisfies P → transfer the deposit k to the e(s_cur) account, modifying SUAVE state to s_next

  • If the current state of SUAVE s_cur does not satisfy P → SUAVE state remains unaltered

Within the bid, a user has three programmable privacy control knobs:

  • Execution predicate

  • Encryption predicate

  • Set of peekers

Programmable privacy = allowing the user to selectively decrypt and reveal as much (or as little) of their data as they wish, and under what conditions. You can partially decrypt information such that executors can fulfill your preferences while also keeping various aspects of your economic preferences private for example.

A user can enforce conditions such as:

  • “Parts of my Tx data can only be decrypted when condition X on the world state against these oracles is met”

  • “I only want my Tx to execute if it’s first in the block, otherwise it should fail."

Credible Commitments

SUAVE also requires credible commitments - we need to enforce certain conditions for execution. This is already part of MEV-Share with its “validity conditions.” They’re passed along with the user's transactions, stipulating conditions such as “the user must be paid ≥1 ETH for this bundle to be executed.”

In the initial stages of MEV-Share, these conditions will not be enforceable - they’ll rely on trusting the builder who’s including them. Later iterations of the OFA will look to reduce trust in the enforcement of validity conditions by leveraging SGX.

Fee Escalators

Preferences can also include fee escalators - transactions which increase their gas price over time. They can even start with a negative value (i.e., an executor must pay the user for the right to execute it). This allows users to permissionlessly conduct an implicit Dutch auction for the right to fulfill their preference.

As an example:

  • Tx starts with a fee of -$200

  • Executing the Tx would allow someone to capture a $100 MEV opportunity

  • Fee gradually increases as time passes

  • Executor should pick up the Tx once the fee escalator has risen above -$100

Fee escalators can be powerful when combined with the programmable privacy described. Users are free to decrypt and reveal as much or as little as they wish.

If you keep this fee curve and your transaction information private, searchers could try to brute force optimize this against other bundles. You get the guarantee here that the user gets optimal MEV execution while giving permissionless real-time access to their orderflow. This just relies on a competitiveness assumption around searchers and validators.

Decentralized Block Building (DBB)

The DBB network aggregates preferences (many of which now have their execution paths optimized by executors) and turns them into blocks across domains.

DBB is described as one of the three logically separate components within SUAVE because not all domains even have a notion of block building and PBS. However, this DBB role is really a specialized instance of an executor within the execution marketplace.

We’re used to a clear distinction shown between searchers and builders today, but in reality the lines are a bit fuzzy. Executors are an umbrella term for the actors who fulfill these preferences, and that can include the roles we see today in searchers and builders.

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

3) Preference Settlement on Destination Chain

Now it’s time for the user’s destination chain validators to accept (or reject) what the SUAVE executors are trying to fulfill.

SUAVE does not replace the mechanism by which a chain selects its blocks. They retain full control. Ethereum, Arbitrum, Optimism, etc. wouldn’t be changing their fork-choice rules to opt into SUAVE. There are no protocol-level changes required for SUAVE to build a block for a chain.

For example:

  • Ethereum proposers decide whether or not to include a block sent by SUAVE

  • A rollup’s decentralized PoS sequencer set can decide whether or not to include a block sent by SUAVE

Destination chain proposers may or may not be “SUAVE-aware” and natively integrated. For example, an Ethereum validator could profit switch between SUAVE bids and centralized builders, or it could simply not pay attention to SUAVE. It’s more efficient if these validators are themselves SUAVE executors, but it’s not required. Other actors could work to fulfill these preferences regardless.

Let’s consider the transaction flow:

  1. Searcher - I want [tx_1, tx_2, tx_3] mined. If they are, I’ll pay a 3 ETH bid b to the executor e

  2. SUAVE - Propagate and aggregate searcher input, ensure payments are valid

  3. Executor - Ensure validators perform economically optimal action

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

If Validator is SUAVE-unaware - Executor gets the validator to include the bundle over PGAs or some other third-party channel (e.g., executor makes best effort PGA bids to get them included, or relays them as a bid via a third-party plug-in such as MEV-Boost).

As I’ve written previously, this means that SUAVE cannot guarantee atomic inclusion of X-chain transactions by itself. You need the proposers of respective chains to agree on atomic inclusion for that guarantee to be enforced.

X-Domain MEV

SUAVE allows you to express preferences for X-domain transactions. Let’s consider an example. A user communicates their preference to SUAVE that they want two trades executed at the current block height to close an arbitrage:

  • Trade 1 (T_1) - Buy ETH at $2,000 on Rollup 1 (R_1) in Block 1 (B_1)

  • Trade 2 (T_2) - Sell ETH at $2,100 on Rollup 2 (R_2) in Block 2 (B_2)

These rollups may even have completely different length unsynchronized block times. R_1 could have 1s blocks and R_2 has 10s blocks. It’s then perfectly reasonable that T_1 closes its leg of the arbitrage, but then T_2 fails.

That’s why SUAVE is not prescriptive about how preferences are actually achieved. SUAVE looks to be maximally flexible such that it can coordinate for any domain and user. Executing on different domains will therefore present different challenges. Different users will accept different outcomes and levels of risk.

If the user is only willing to take execution if both legs are filled, then the executor must hold the risk for them that only one leg executes. For example, the user can require the executor to fulfill both legs with their own capital, then they can exchange the funds for the user’s locked capital only if both legs are filled. If they fail to fully meet the preference, then the executor is stuck holding the risk.

This requires sophisticated executors to price the execution risk of conducting the statistical arbitrage, which means less executors will likely bid for the opportunity (they may not have the upfront capital or want to warehouse the risk).

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

4) Payment Settlement on SUAVE Chain

Now that the destination chain confirmed their own block, SUAVE Chain needs to become aware of that result. As mentioned earlier, bids are only unlocked for executors who meet users’ preferences. Oracles are required to prove that these preferences were fulfilled elsewhere.

These oracles can be implemented however desired. In any case, these oracle contracts are responsible for importing external events into SUAVE’s state.

A simple example would be an oracle contract which allows SUAVE bids to query Ethereum’s history. I might want to bid for an empty block in 10 blocks. I can submit a bid by creating a transaction, and the transaction will output a payment if the oracle tells it that the Ethereum state has transitioned such that the payment should be made.

Why Does SUAVE Need a Chain?

SUAVE Chain plays an important role in preference expression, and is needed for payment settlement after the fact. Recalling the simplified transaction flow:

You might be asking a few questions here:

  • Why not just have a standalone global p2p layer for SUAVE preference expression (something akin to Anoma’s intent network), then settle payments on the destination chains?

  • Why do we need SUAVE Chain for preferences and settlement? Even if a single chain is needed, why not use an existing one (e.g., Ethereum)?

1) Economic Efficiency - Low Cost & DoS Resistant

SUAVE has two requirements for transmitting preferences:

  • Low Cost - Relying on a p2p layer alone would also achieve this. In normal times (not overly congested), SUAVE Chain can operate similarly though. This requires changing the actual chain and introducing a new transaction type.

  • DoS Resistant - A blockchain can deter DoS attackers by forcing them to pay a cost for spam. A chain allows for imposing fees (by including preferences onchain) in the event of excessive network congestion. A standalone p2p network would not have the mechanism needed to charge such a fee.

2) X-Domain MEV & Neutrality

A chain is needed to settle payments for X-domain preferences. Consider the example earlier where a user submits a preference for X-domain arbitrage, but is only willing to pay if both legs execute. There must be some oracle verification after the fact to settle only if the entire preference was met. You can’t just pay out on each leg of the trade (e.g., you could then pay for one leg of the trade, but then the other leg fails).

There needs to be some domain which provides this all-or-nothing payment option. Bridging assets to SUAVE Chain and settling everything there is one such option. That may be unacceptable to some users, but it needs to be a possibility as SUAVE is trying to support all potential models of preference expression and settlement.

This is best served as its own independent chain (versus an existing chain) to remain neutral when settling preferences across multiple domains. This will also be important as SUAVE moves towards providing services for all domains (not just Ethereum). It can have independent ownership and participation separate from any existing chain, which is likely needed to get buy-in from other domains, whether that be Cosmos, Solana, CEXs, etc.

3) Flexibility

SUAVE also needs to implement a wide variety of optimizations that would be unacceptable to existing domains. It needs to control the full stack chain to implement these. This could be as simple as relatively higher gas limits and lower block times - these are of course unacceptable to Ethereum.

Another example relates to the mempool. Flashbots has considered replacing Ethereum’s current mempool within Geth with a different structure that’s optimized for faster communication.

Flashbots has also considered making SUAVE Chain a rollup in the long-term. This could allow SUAVE Chain to use the rollup’s derivation function to trustlessly access the state of Ethereum L1 and its other rollups. This is valuable in reporting state transitions of other domains back to SUAVE Chain so that the conditional payments from bids can be unlocked to executors.

Roadmap

SUAVE of course isn’t live yet, and there isn’t even a spec out. It’s an ambitious vision which will take years to realize. The plan is to ship it in phases:

  • MEV-Share is an OFA that keeps user transactions private from searchers. It initially relies on Flashbots as the trusted matchmaker. Builders would be trusted to respect users’ desired execution and payments.

  • SUAVE Chain mainnet allowing users to send preferences to the Execution Market

  • SGX-based OFA to remove trust in Flashbots

  • SGX-based centralized block building to enable open but private orderflow

  • SGX-based decentralized building network to allow for permissionless and private collaborative block building

  • Onboard second domain to SUAVE and allow for expression and execution of cross-domain MEV preferences

In the longer-term, Flashbots intends to look into crypto-economics, custom secure enclaves, MPC, and FHE to further reduce the trust guarantees in the system.

Source: dystopiabreaker
Source: dystopiabreaker

Summary

So, who’s going to use SUAVE and why? A few high level users could be:

  • Normie users - I just want to send my swap into an OFA that’ll give me good execution.

  • Power users - I want to buy a ton of ETH, so I express a preference to sweep liquidity across exchanges on many different domains (e.g., I can specify which chains and versions of wrapped ETH I consider fungible). This is a bit analogous to intermarket sweep orders (ISO) in traditional finance. You can think of it like a meta DEX aggregator.

  • Searchers - I run specific strategies, looking for MEV opportunities. I can express my preferences for specific opportunities I want to capture.

Some of the biggest open questions include:

  • Preferences - The best way to express this generic notion of “preferences” is unclear. Trying to build for the current blockchain stack (e.g., EVM smart contracts) inherits certain limitations.

  • Privacy - Nobody loves SGX, but that seems like the practical reality in the near to medium-term. The timeline and feasibility of moving away from this is unclear.

  • Oracles - The oracles back to SUAVE Chain for settlement introduce many complexities and questions.

Overall, SUAVE is dope. It’s an ambitious and fascinating abstraction of how to express and fulfill any generic preference.

Part II - WTF is Anoma?

In case SUAVE wasn’t confusing and fascinating enough, I’ve got another one:

Anoma is another protocol under development which is very reminiscent of the core ideas behind SUAVE. For starters, Anoma:

  • Is an architecture for blockchains. It’s a framework.

  • Is not a blockchain.

Any chain can implement the Anoma architecture. You can have an Anoma L1, Anoma L2, whatever. A chain implementing the Anoma architecture is referred to as a “fractal instance” of Anoma, and all share certain homogeneous standards.

Confusingly, one of the planned fractal instances is also currently called “Anoma.” For simplicity, I’ll call it “Anoma L1” when I refer to this specific instantiation. It’ll be an IBC-enabled L1 PoS chain. If I just say “Anoma,” I’m talking about the architecture.

Remember, Anoma and Anoma L1 are completely separate ideas. Think of “Anoma” a bit like you think of “Cosmos”. You can have a Cosmos L1, Cosmos L2, whatever. It’s just referring to chains that share some set of standards. The standards that Anoma chains and Cosmos chains implement aren’t exactly analogous, but it’s a helpful simplification.

Settlement + Counterparty Discovery

Every blockchain today provides settlement - consensus agrees upon and finalizes some updated state of the world.

However, they’re not directly optimized for counterparty discovery (CD). For simple stuff, it doesn’t really matter. If I want to send you some ETH, I don’t need CD. You just give me your address. I submit a transaction to the Ethereum mempool which authorizes sending ETH from my address to yours.

That’s not the case for more complex interactions like trading. This requires CD to:

  • Help counterparties discover each other, and

  • Agree on what to settle with each other

I know what I want (e.g., I want to swap 1 ETH for 1000 USDC), but I don’t know how to get it. Just having that “intent” of what I want isn’t enough to settle on-chain. I need a fully formed state transition.

You’re probably thinking, “Ok cool, so what? I can just go to Uniswap or whatever other application for CD. That’s what they’re there for.” And you’re correct!

Example - DEXs Today

Let’s consider a CLOB as a simple example. You could put every bid/ask on-chain, but this is generally prohibitively expensive (and unnecessary). As a result, you’ll see constructions like dYdX:

  • Today - Settlement all happens on-chain, but the orderbook and matching engine lives entirely off-chain (currently a single centralized server).

  • V4 - The orderbook and matching engine will run entirely in-memory (off-chain) within validators. Each validator will host their own view of orders.

So there’s two parts to the solution here:

  • App-chain - Lets you customize your chain to your needs, but this can introduce more work and complexity at least today. Also composability may suffer to some degree.

  • Off-chain - This scales, but it still comes with drawbacks such as trusting validators regarding MEV. For example, they can see everything in the clear and pull orders/ignore cancellations/front-run/give worse execution at the last second.

AMMs like Uniswap arose largely due to the constraints and gas inefficiencies of CLOBs. Everyone can just use the AMM contract as the central point of counterparty discovery. Current AMMs still have some obvious drawbacks here in terms of efficiency, and broadcasting your trade naively has problems:

  • Sending transactions to public mempool = sandwiching

  • Sending transactions to private mempools (e.g., Flashbots Protect) = trust and suboptimal execution/inclusion time

The Anoma architecture attempts to alleviate this problem by unifying both:

  • Settlement - The same stuff as before. You’ve got a validator set that agrees on stuff and settles it.

  • Counterparty Discovery - CD is built into the protocol itself. It’s not left outside for others to deal with in an indirect manner.

Both of these tasks are required to move from a user wanting to do something → blockchain settles a state transition. The difference is just that Anoma blockchains vertically integrate settlement and CD. Most applications require CD, and building it into the core architecture provides them with some interesting benefits which we’ll see shortly.

Transactions vs. Intents

The key part of Anoma here is their notion of “intents.” Conceptually, they try to achieve a very similar goal as SUAVE’s notion of “preferences.”

Overall, SUAVE appears at least somewhat constrained in its approach of preference expression vs. a system such as Anoma which is built from the ground up on the notion of “intents.” Anoma doesn’t plan for users to end up actually submitting “transactions.”

First, let’s look at how you actually interact with a blockchain today. I want to swap 1 ETH for 2000 USDC, so I send a transaction to the Ethereum mempool:

  • What you think transactions say - “I authorize someone to take my 1 ETH, and give me at least 2000 USDC.”

  • What transactions actually say - “I authorize this execution trace, and all opcodes being called can do arbitrary computation to change the state.”

You never actually defined what you want. You defined how you want to get it.

If the code is clean, I’ll send 1 ETH and receive 2000 USDC. If not and I didn’t audit every opcode I signed (lol), maybe a proxy contract steals my money.

Existing protocols are designed with transactions as their fundamental unit, but transactions are completely non-intuitive. They don’t match how anyone actually thinks. You always think in terms of some state change you want (e.g., I want a future state where I own 1 less ETH and 2000 more USDC).

In Anoma, intents are the fundamental unit by which users express their preferences, and intents work the exact opposite way. Intents match what users are actually thinking:

Concretely, intents are off-chain signed messages that describe a partial state transition. They authorize some state preference that I want (e.g., I want a future state where I own 1 less ETH and at least 2000 more USDC). Intents are fully programmable - you can express any arbitrarily complex state preference. Maybe I only want to swap my ETH if it’s sunny in New York and the Yankees won today. You get the idea. Intents are just arbitrary code that’s evaluated at runtime by the settlement layer.

You can think of intents as “partial transactions”, as they require some other parts to form complete transactions that satisfy users’ constraints and enact a state change. Specialized middlemen called “solvers” (akin to executors) look through these intents to fulfill them. Solvers facilitate CD and route the intents to eventually be executed onchain by validators.

Intent Gossip Layer

Users sign these binding intents via some client (e.g., wallet, dApp UI) then broadcast them to intent gossip nodes. This can be directed to certain node types, or undirected where it gets broadcast to as many nodes as possible. The intent gossip layer is just a p2p networking layer with a bunch of intents floating around (kind of like a mempool, but they’re “intents” instead of “transactions”).

Validators don’t need to have any view of these intents. Most of them probably won’t ever be settled onchain even. You could have billions of them floating around, and solvers can specialize in subscribing to certain “topics” they care about. Some form of specialization is likely to occur as solving becomes an NP hard problem, so a generalized solver would become intractable at scale.

A solver might only subscribe to process intents for:

  • Anoma L1

  • A specific application

  • Only a certain intent type (e.g., ETH trading pairs) but across many chains

The intent gossip network can span over all Anoma fractal instances. One globally connected intent gossip network can handle the intents for any and all Anoma fractal instances. UIs for applications can support deployment and order fulfillment across different security models if they wish. Intents are able to specify which security models they’re willing to settle to.

As noted earlier with SUAVE, a global p2p layer could have some DoS concerns. In practice, solvers could operate much as builders do today (e.g., have a reputation system for known peers, blacklist as needed, etc.). It’s unclear how robust this can be under extreme scenarios.

While having a blockchain such as SUAVE Chain allows you to impose some fees in the pessimistic case, it still doesn’t prevent the need to do the computational search. This may still present some attack vectors (e.g., as described earlier with the contract overflow example).

Solvers Match Intents

Solvers transform user intents into fully formed state transitions which meet users’ desires. This achieves similar properties to what I described earlier with SUAVE batching as one generalized example:

  • User A intent - I want 1 more ETH, and I’m willing to spend up to 2000 USDC

  • User B intent - I want 2000 more USDC, and I’m willing to spend up to 1 ETH

  • The solver can match these intents, settling them onchain as a single transaction

Similar to SUAVE, they also don’t need to find perfectly offsetting intents. Solvers can route intents in complex ways with many intents that end up offsetting in aggregate, or they can fill them themselves if attractive. It’s completely generalized.

Intents can specify settlement-conditional fees - they’re only paid out if the intent is satisfied, settled, and confirmed onchain by consensus. This can be split amongst nodes involved in the gossiping and solving processes.

Anoma is also looking to implement various PETs to coordinate trustless operation on user data, which we can again treat as a black box for the purposes of this post:

Source: Anoma
Source: Anoma
Source: Anoma
Source: Anoma

Note that users can also send intents which describe a full state transition. For example, if Alice just wants to send 1 ETH to Bob, she doesn’t need CD. If she doesn’t need solvers to do any work, she can skip them and submit a full transaction herself (in a sense, acting as her own solver).

Consensus & Threshold Decryption (Ferveo)

Right before solvers send transactions to the transaction mempool, they can encrypt them. Validators don’t actually see the transactions that solvers send to them. They receive the transaction ciphertext:

The particular scheme used is Ferveo - a distributed key generation (DKG) and threshold public key encryption protocol. Note that Ferveo is just a framework - different chains can flexibly implement different rules around it (e.g., requiring all transactions to be encrypted vs. auctioning off the top of the block in the clear). You may have heard that Osmosis also plans to use Ferveo.

Here’s the basic transaction flow:

  1. Validators generate a shared threshold public key. The shards of the corresponding private key are distributed amongst the validators according to stake.

  2. Solvers encrypt transactions to that public key, then send them to the transaction mempool.

  3. Proposer orders encrypted transactions into a block, and proposes it to the network.

  4. Validator set comes to consensus on block N, committing to the ordering. These consensus votes also include validators’ respective private key shards. Once ⅔ of validators (by stake) sign to commit to the block, the transactions can be decrypted atomically. Everyone can see the result of the eventual execution of these transactions in N+1 as soon as block N is signed off.

  5. The decrypted transactions are included in block N+1 (in the same order as committed to in block N) and executed.

This provides temporary privacy. The privacy here is a means to an end. Because the validators don’t see the transactions in the clear, they shouldn’t be able front-run or censor them (if they are not colluding).

Note that implementing threshold decryption today alongside CometBFT consensus (Tendermint) would require ABCI++ to enable “vote extensions''. ABCI++ isn’t finalized yet, but it’s expected in the near to medium-term.

Anoma Example Application - Central Limit Order Book (CLOB)

With Anoma, you could potentially have MMs continuously send bid/ask limit orders as intents. You have an entire order book living as public binding intents.

Obviously MMs need to update their stale prices when information changes:

  • Centralized traditional CLOB - MM can race to send a cancel order to pull their stale bid. The centralized operator can cancel on FCFS.

  • Fully on-chain CLOB - This would require an on-chain transaction. You can only cancel an order if your cancellation transaction is included in the block in time.

With Anoma, MMs could potentially just intermittently update their intents. E.g., “I’m willing to buy X for Y, but this order is only good for block height Z.” They can then continuously update their orders every block. They could become stale intra-block, as there’s no method to cancel. There’s a continuously updated order book of intents that users can execute on.

Additionally, this DEX isn’t bounded by a single domain. You don’t need to think in terms of one DEX on one chain. Intents are fully composable, programmable, and global. I can specify exactly where and how I’m willing to get filled on my order.

Anoma Example Application - Batching (e.g., CoW Swap)

As a quick TLDR, CoW Swap is an Ethereum application which matches trades via batch auctions using a variety of liquidity sources. Users submit trades to CoW Swap over some predefined batch auction period. Then:

  • CoW Protocol first seeks a coincidence of wants (CoW) within the existing batch to offer the best price (e.g., if Alice wants to swap 1 ETH → 2000 USDC and Bob wants to swap 2000 USDC → 1 ETH, they can just be matched).

  • If there isn’t a CoW offering best execution, then trades can be settled via underlying on-chain AMMs directly (e.g., Uniswap) or via DEX aggregators (e.g., 1inch) depending on which pool/path offers the best price.

The protocol continuously runs these batch auctions. Within batches, this optimal order matching and routing is facilitated by many competing “solvers” (yes, that’s actually what they’re called here too). The winning solver is the one that can maximize traders’ surplus either by the most optimal CoW, finding the best liquidity sources, or combining both in a single settlement.

However, you’re relying on a central party to coordinate here in the case of CoW Swap today. Anoma could potentially decentralize this type of batching:

  1. Encrypt all users’ intents against the Ferveo threshold public key and send them to the validators.

  2. Validators include the encrypted intents.

  3. These intents are all tagged as being intended for the “Anoma CoW Swap” application/validity predicate on Anoma, so validators know to only decrypt them after the predefined batch period is up (say 10 blocks).

  4. The validators decrypt all “Anoma CoW Swap” transactions which were included according to their validity predicate (so here, after 10 blocks).

  5. Solvers can now look at the decrypted intents and compute over them according to their application’s solver algorithm (e.g., everyone gets the same clearing price, best price is the optimal solution). The validity predicate can enforce these optimality criteria. Solvers are unable to inject new transactions into the batch.

Anoma & SUAVE

Anoma and SUAVE appear similar in their notions of generalizing user intents/preferences. A market of solvers/executors compete to fulfill them, grounded in privacy technology to facilitate trustless collaboration. However, they have fundamentally opposite approaches.

Anoma’s vision is for many fractal instances with a homogeneous architecture. Many chains with shared standards get a lot of benefits as described above.

SUAVE takes a very different view - it’s built in realization of the fact that many chains are likely to have completely heterogeneous architectures. It’s another layer in the stack to service this role for any chain. It’s agnostic to what your chain looks like. It just wants to optimize as the universal preference layer, outsourcing key components for any domain.

They’re built with very different and possibly even complementary design goals.

Part III - Shared Sequencers

I’ll assume general familiarity with shared sequencers (SSs) such as Espresso or Astria here. If you’re unfamiliar, please refer to my previous post.

X-Domain MEV

As mentioned above, SUAVE can provide a best-effort “economic atomicity.” This is the case with any builder. Only proposers (validators) have the power to guarantee transaction inclusion. SUAVE executors are not necessarily validators of other chains, and they can’t guarantee atomic inclusion of X-chain transactions.

Conversely, SSs can guarantee the atomic inclusion and execution of transactions across rollups opted into it. SSs act as the shared “proposer” for all of their rollups. However, SSs such as Espresso and Astria do not execute transactions, so they can’t guarantee that a transaction won’t revert upon execution.

That’s why SSs will need stateful builders to sit in front of them.

SUAVE could be such a builder. In the earlier example, a user wanted two trades executed at the next block height to close an arbitrage:

  • Trade 1 (T_1) - Buy ETH at $2,000 on Rollup 1 (R_1) in Block 1 (B_1)

  • Trade 2 (T_2) - Sell ETH at $2,100 on Rollup 2 (R_2) in Block 2 (B_2)

A SS with PBS can now get stronger economic guarantees throughout that whole process:

SUAVE anticipates that different X-chain atomicity approaches will arise, and it looks to support preference expression for all of them. Domains don’t need to integrate with SUAVE directly, adopt a particular ordering model, or even have a notion of PBS. SUAVE is just a global “bulletin board” for preferences that sophisticated actors who understand the risk can compete to execute on across domains.

SUAVE can be seen as a demand-side aggregator for X-domain preferences. It exposes the tools necessary to securely express these preferences. In doing so, this incentivizes the development of solutions such as SSs. They can provide the “supply” of X-domain transactions, allowing for more efficient capture of X-domain MEV.

Shared Sequencers → Super Builders?

It’s well understood that X-domain MEV exerts centralizing pressure on block producers (e.g., validators/sequencers). There’s an incentive for the same actor to control X-chain block production to more efficiently internalize X-chain MEV.

As I just described above, a SS can offer exactly these guarantees. And they don’t need to carry heavy state on hand or execute transactions, so they can hopefully be lightweight and decentralized.

But we’ve just shifted the centralizing force to the builder. We’ve done that on L1 Ethereum with MEV-Boost though, so what’s the big deal? Keep validators decentralized, and shift the centralizing force to builders.

However, there’s a much stronger centralizing force here compared to something like L1 Ethereum. Building a block for L1 Ethereum is one thing, but doing it for arbitrarily many high throughput domains at low latency is another.

Overall, this stack may drive up the resource requirements for builders in terms of software/hardware level transaction execution, X-chain inventory management, balance sheet size, and risk taking. To be a competitive block builder, it may become a requirement to fulfill these conditions.

To be clear, centralizing forces from X-domain MEV exist for builders whether for a SS or any other domain. However, there’s a distinction here:

  • Builder for Other Domains - There is still a centralizing force due to X-domain MEV economic incentives. However, it’s not a strict “requirement.” Today, the barrier to entry as a builder is lower (i.e., you could choose to just be an Ethereum L1 builder).

  • Builder for SS - Incredibly high requirements may be completely unavoidable to even enter the market. It seems likely that a single builder will need to build for all SS rollups.

As mentioned, SSs need some form of PBS. It seems likely that this takes the simple form of one auction for one mega auction across all SS rollup blocks. If the PBS interface here is building one mega block for all SS rollups, then that solidifies the most extreme requirements.

In theory, a SS could run more granular auctions for each individual rollup it sequences for. Then it would need to interpret this arbitrarily high number of auctions, checking for conflicting preferences. For example:

  • Builder A is bidding for atomic inclusion of blocks B_1 & B_2 for R_1 & R_2

  • Builder B is bidding for atomic inclusion of blocks B_2 & B_3 for R_2 & R_3

The SS proposer would have to comb through all the bids, checking for conflicts, and optimizing the merging of them. That probably sounds familiar - that’s what a builder does.

So in practice, there will likely be a builder aggregating across all domains and interfacing with the SS proposer in a single large PBS-style auction.

Basically, SSs appear to be speedrunning the Endgame. There’s a fair argument that this is inevitable anyway, but it’s an open question still.

We’ll likely see both SSs and “traditional” rollups decentralizing their sequencer (e.g., implementing a simple consensus set) prior to SUAVE. However, decentralizing sequencers (proposers) is not enough. We also need to consider rollup block building.

It seems likely that some variation of proposer-builder separation (PBS), protocol-owned building (POB), etc. is destined to arise on rollups in the near to medium-term. This should be an area of focus as they consider how to decentralize.

SUAVE X-Domain Decentralized Building

SUAVE is a decentralized block builder, so does it solve the problem here? Not entirely. It’s still unavoidable that if you’re building a mega block for all the rollups on a SS, you have to meet the high requirements. SUAVE executors would be stuffing every rollup on the SS into their SGX to end up building a full block for it (or use other forms of cryptography down the road).

The technical challenge is one obvious question, but the point is that SUAVE isn’t just about lowering the hardware requirements for builders regardless. What it could help with is making the block building process more collaborative and trustless. You could have many builders each contributing a piece to the blocks they output.

Economics

Now for the really hard part - incentives.

Figuring out the economics of SSs may prove to be the most challenging component. First, the nice part - SSs should allow their rollups to capture more aggregate value from MEV.

Let’s consider a simple example. We have 10 equal (isolated) rollups whose validators capture $1mm each per year. In aggregate, they capture $10mm per year.

Now those same rollups all decide to opt into a shared sequencer. There’s no reason that $10mm should go away, that’s still there. Maybe it’s even $11mm due to better bridging and interoperability → more activity overall. But now there’s even more value for them to internalize from X-chain MEV. Let’s break that down.

MEV Capture Today

Basic single-chain MEV strategies are commoditized. If you’re running atomic arbitrage between ETH/USDC pairs on Ethereum L1 SushiSwap and Uniswap, you’re bidding almost all of that value back to the Ethereum proposer. It’s effectively riskless profit.

X-chain MEV is the opposite. Validators can’t make X-chain atomic commitments. X-chain MEV can only be captured probabilistically by sophisticated searchers running statistical arbitrage. They have to manage inventory across chains and warehouse risk → market is riskier and less competitive → a lower % of the MEV gets bid back to validators.

MEV Capture With Shared Sequencers

Now validators (SSs) can make X-chain atomic commitments. X-chain MEV can be captured with high confidence by searchers running atomic arbitrage. Extraction becomes highly efficient and competitive → a higher % of the MEV gets bid back to validators (SSs).

That’s great for the rollups! They were capturing $10mm in aggregate before, and now let’s say they’re capturing $12mm. But wait - how do we split that up?

The SS has a lot of power here. They now decide the transaction inclusion and ordering for all rollups by default → they get first dibs on MEV. So we need to decide how to divvy that up. Having a “perfect” allocation mechanism which would need to simulate all possible outcomes is likely an outright impossibility.

You appear to broadly have two paths then:

  • More granular auctions - The logical way to do PBS with a SS is one big block for all the rollups. Is it possible for the SS to run many sub-auctions for the individual rollups, or some other creative mechanism?

  • Decide on a “good enough” allocation mechanism - Just take an opinionated but transparent stance on what’s “fair” (e.g., split the revenue equally with all rollups, though even this isn’t easy).

I certainly don’t have the answer here today. This is a fascinating area of open research.

If the above is figured out, will rollups be ok with sharing the pie in a “good enough” way? Or do they go full Game of Thrones on each other? Honestly, we’ve seen a bit of both, so I’m not sure. It’ll be an interesting political and social experiment to watch play out regardless.

One-Size-Fits-All

When rollups opt into a SS, they’re opting into somewhat of a “one-size-fits-all” model. Some even think they look like one big rollup. It’s a realization that every chain is destined to be influenced for the sequencing of other domains.

Even Ethereum is influenced by Binance. Ethereum ←→ Binance is indeed the largest MEV source in crypto today. Several of the largest builders engage in this statistical arbitrage, and this has centralizing spillover effects into Ethereum.

That’s the reality of X-domain MEV. There are tradeoffs in how you choose to address this influence.

  • “Sovereign” end of the spectrum - Many distinct chains with entirely unique and decentralized validator sets. Infeasible in practice due to the centralizing pressures.

  • “Non-sovereign” end of the spectrum - One node for one chain to rule them all. If you want a seat at the table, you co-locate. Feasible, but what’s the point anymore?

Opting into a SS allows a rollup to mitigate the centralizing force of X-domain MEV on their validator set (because they can operate X-domain). Its nodes can hopefully be lightweight relative to the number of chains they service, and they can effectively internalize the X-domain MEV. Better interoperability also reduces the impact of X-chain UX.

But, this may come with some tradeoffs:

  • Builders - As discussed earlier, this construct appears likely to incentivize highly centralized and resource-heavy builders.

  • Rollups - Rollups sacrifice to an extent on customizability. You’ll be limited in enforcing many of the things that a chain with its own validator set could do.

In my view, it wouldn’t make sense to implement another validator set within your rollup in many cases (as another round of processing before or after the SS) for several reasons:

  • Ease - Part of using a SS is for the ease of deployment. If you’re implementing a second validator set, that’s no longer the case.

  • Lose Guarantees - If your consensus can arbitrarily include, exclude, and reorder transactions after the SS, then it can no longer give you any useful inclusion guarantees.

  • Stronger Trust Assumptions - You want to inherit the real-time CR and liveness of the decentralized SS’s pooled security. If your second consensus can censor you/have a liveness failure after the fact, that’s lost. You’re only as strong as your weakest link.

The tradeoff - your rollup won’t be able to implement features which require a validator set to enforce with discretion. Examples could include:

To varying degrees, the tradeoffs and associated complexities are just so high that it’s not worth implementing separately as a rollup on top of a SS in my view.

Let’s consider the example where you want threshold decryption for your rollup. Let’s say a SS includes encrypted transactions to which it does not have the decryption key (your rollup’s own nodes have the decryption keys). This becomes problematic - you have an entirely separate consensus set with the power to arbitrarily halt your rollup if they choose not to decrypt. There’s also a challenging timing mismatch with the SS.

Your validators should ideally be the same group with the threshold decryption key shares, and they should have the same quorum as your consensus. Then, they can just include their key shares as part of their consensus votes, automatically decrypting as they sign off on a block.

For this reason, you’d want the SS itself to implement threshold decryption natively if you want it for your rollup. To be clear, a SS could do this! But, the tradeoff is that it still leans closer to a “one-size-fits-all” approach in many cases, leaving SSs room to differentiate on various features.

As an example, this seems somewhat against the grain of the Cosmos mindset. There, we see applications that want their own customized chains, and they want their own validators to enforce those rules. It could be infeasible to implement many of these customizations if opted into a SS.

Retaining VM Control

While these rollups may look like one big chain in some sense, there’s a key distinction here in that rollups opted into a SS can always fork away (e.g., if the SS is extracting too much value). Valuable shared state is what’s hard to fork away, but SSs don’t have this on their own. They’re effectively just a service provider. A rollup can always just swap out their SS for some other sequencing mechanism with only a minor hardfork.

Additionally, rollups certainly aren’t handing over total control. They still have complete flexibility to customize their VM as they wish. They can even enforce complex transaction ordering rules by encoding them deterministically in the state transition function (STF) of their rollup. For example, “the first transaction in my block must have oracle update XYZ to be valid” or “this type of batch must be right after it” etc. This could even include customizations such as Osmosis’ ProtoRev Module to automatically internalize cyclic arbitrages.

As discussed above, you wouldn’t want to have each rollup do a full round of non-deterministic reordering of transactions after the SS. So long as the VM rules are deterministic though, builders can create blocks within the bounds of these rules. Then rollup nodes can interpret the SSs output according to their rollup’s own deterministic rules. This doesn’t require a discretionary validator set to do anything.

Conclusion

SUAVE is an ambitious attempt to unbundle the mempool and builder role for any chain. It looks to enable the expression and execution of any arbitrary preference in a trustless and collaborative manner.

Anoma is another idea to address some of the same underlying challenges. However, it takes a radically different approach by rebuilding the entire blockchain stack, trying to get many chains to share the same standards.

SSs could enable many chains to feel and act more like one chain again. However, they come with tradeoffs, including somewhat reduced flexibility, challenging value attribution, and potentially higher-resourced builders.

In any case, rollups are coming, and so are decentralized sequencers (hopefully). They’re likely to arrive before something like SUAVE, so rollups need to think more about how to responsibly incorporate the builder role into their designs.

Otherwise, Vitalik might just be right about the Endgame after all:

Block production is centralized, but block validation is trustless and highly decentralized.

Disclaimer: The views expressed in this post are solely those of the author in their individual capacity and are not the views of DBA Crypto, LLC or its affiliates (together with its affiliates, “DBA”). The author of this report has material personal positions in ETH and Skip Protocol Inc.

This content is provided for informational purposes only, and should not be relied upon as the basis for an investment decision, and is not, and should not be assumed to be, complete. The contents herein are not to be construed as legal, business, or tax advice. References to any securities or digital assets are for illustrative purposes only, and do not constitute an investment recommendation or offer to provide investment advisory services. This post does not constitute investment advice or an offer to sell or a solicitation of an offer to purchase any limited partner interests in any investment vehicle managed by DBA.

Certain information contained within has been obtained from third-party sources. While taken from sources believed to be reliable, DBA makes no representations about the accuracy of the information.

]]> jon-dba@newsletter.paragraph.com (Jon Charbonneau)