Settlement Layers? Ethereum Rollups? Sovereign Rollups?
Is a Sovereign Rollup just a fancy word for a Velvet Fork? Or can it form the basis for a new settlement layer?
As we have discussed before, Ethereum and adjacent communities are pursuing a modular (and layered) approach for blockchain scalability.
Data Availability. A public bulletin board that guarantees all online parties can get access to recently published ordered data.
Settlement Layer. A consensus protocol that collectively agrees on the balance of all accounts according to an ordered list of transactions.
Execution Layer. Performs all the hard work of executing complex transactions and smart contract code.
In Ethereum, and even Bitcoin, the data availability layer and the settlement layer are combined. The combination is important for practical deployments of blockchain networks.
It allows the network to rate-limit the publication of data by entangling it with a fee market. If a user is willing to pay a competitive network fee and the data fits within agreed constraints, then the user can post whatever data they want.
For example:
Bitcoin blobs. Ordinal NFTs are enabled due to the extra witness data allowance and fee discount associated with a SegWit witness alongside a further relaxation with Taproot.
Ethereum blobs. EIP-2028 reduced the gas cost of CALLDATA to enable the initial versions of rollups. There is on-going work with EIP-4844 to create a separate fee market for CALLDATA and allow data blobs to be posted at a further discounted rate.
It is interesting, perhaps even surprising in the case of Bitcoin as an unintended pursuit, that both networks have worked towards reducing the cost of posting data blobs.
However, we need to keep in mind that while both Bitcoin and Ethereum can serve as a data availability layer (to some extent), they do not share the same capabilities when it comes to the settlement layer.
There is a small difference which has huge ramifications for the security of a rollup and arguably how practical it is to deploy as a technology.
How Do We Think About Rollup Security?
As we have explored in the past, there are two key components to consider when evaluating the security of a rollup:
Validating bridge. A trusted third party who will enforce a fixed ruleset for evaluating whether a database update for the off-chain system is valid.
One honest assistant. An honest party who can step up, assist the validating bridge, and save the day on behalf of all participants.
In regards to rollup security, nearly all discussions focus on how one honest party can assist the validating bridge. It is a new set of challenges that is unique to the land of rollups and ranges from participating in a fraud proof game, posting data blobs on-chain, or how to coordinate provers to submit validity proofs. The challenges can be summarised as data availability, state transition integrity, and censorship-resistance.
We normally make an assumption that the validating bridge works as expected because it is a trusted third party. It can access all assets in the underlying blockchain, it can be implemented as a smart contract, and we only need to pay a fee to Ethereum for the privilege of leveraging it to protect the off-chain system.
Of course, there can be challenges with the design and implementation of the bridge, but we can trust that a validating bridge will honestly follow the protocol.
What Security Will A Validating Bridge Inherit?
Now — if we dive into the assumption of the validating bridge and the underlying blockchain — it is crucial to truly understand the security properties we can inherit.
Sreeram Kannan has a nice thread on Twitter which tries to summarise the assumptions:
Re-org resistance. The underlying blockchain decides and protects finality in regards to the total ordering of all transactions.
Censorship resistance. Anyone, regardless of who they are, can issue a transaction for execution as long as they are willing to pay the appropriate network fee for it.
Data availability. A public bulletin board that guarantees all online parties can get access to recently published ordered data. (same as above)
Validity. The underlying blockchain can independently verify, without replaying every transaction, that all actions performed on the rollup (execution layer) are valid.
To achieve the above properties, we must rely on the underlying blockchain’s consensus protocol and wider network effects.
In Bitcoin and Ethereum, we assume there is an honest majority of block producers (stakers/miners) who are actively participating and a diverse network of verifiers (“running nodes”) who check the validity of all published blocks in real-time.
The honest majority assumption for block producers can be summarised as:
Highest fee first. A block producer will always pick transactions that pay them the most money regardless of its content.
Respect fork-choice rule. A block producer will always extend the blockchain’s tip according to the network’s fork-choice rule.
Put together, it allows anyone to transact as long as they are willing to pay a competitive fee and ensures that all block producers will eventually converge on a single blockchain fork.
Interestingly, as long as the blockchain is progressing, we do not need to trust the block producers to post valid blocks. All blocks can be checked and immediately rejected by verifiers running the node software.
As long as a sufficient number and diverse economically important agents run verifiers, then value will be ascribed to the one true blockchain that adheres to the rules.
Can Rollups Inherit Security From Bitcoin?
This brings us to the question:
Do the security properties, as outlined by Sreeram Kannan, actually apply in practice for Bitcoin and Ethereum?
In Bitcoin and Ethereum, we have previously covered how well the networks achieve these security goals.
To summarise it, both networks provide re-org resistance, censorship resistance and data availability, to similar degrees. They provide a platform that allows anyone to post data as long as they are willing to pay a fee to do so.
ZombieCoin: As an interesting note, one of my first projects back in 2014, called ZombieCoin, used Bitcoin to coordinate a botnet’s command and control centre because of the above properties.
The subtle difference is validity and it differs greatly between Bitcoin and Ethereum.
As mentioned previously, we can deploy a validating bridge smart contract on Ethereum and inherit the validity property. On the other hand, in Bitcoin, the scripting language and UTXO model lacks the expressiveness to build a validating bridge. The platform cannot be used to check the validity of the data blobs or the off-chain database.
Put another way — outside of charging fees for posting data — we should treat Bitcoin as data availability layer that lacks any form of computation and we cannot build the kinds of rollups we have on Ethereum without drastic changes to Bitcoin.
Thankfully — this is not the end of the story.
The rise of Taproot Wizards, Eric Wall’s Talk and now the release of RollKit has shown that a different type of rollup can be built on Bitcoin.
A Sovereign Rollup?
This brings us to the question — what the hell is a Sovereign Rollup — and why can it be deployed on Bitcoin? Alongside other networks like Celestia.
The “Rollup” part is inspired by the original rollup repo by Barry Whitehat that solved the data availability problem of Plasma. It essentially “rolls up the transactions” and posts a data blob to an underlying blockchain. As long as the data is posted, which anyone can do, then it can be used.
The “Sovereign” part relates to how the validity of the data blobs is checked and used to compute the off-chain database. It relies on an external community to run a software client (a full node) that can fetch the data blobs, parse the data blobs according to a fixed set of rules, and compute the off-chain database.
Going further, the security of the Sovereign rollup relies upon a majority, or even a supermajority, of economically important agents to agree upon the same set of consensus rules for parsing the data. If they reach collective agreement, then they can all compute the same off-chain database, ascribe real economic value to it, and trust the assets will be protected.
This security assumption can be a bit fuzzy to explain sometimes. What does it mean for a majority or super majority to ascribe value? It is very similar to the governance rules for blockchain networks like Bitcoin and Ethereum. For example, why should BTC have more value than BCH? or ETH have more value than ETC?
It ultimately comes down to the market of buyers and how they ascribe value to a given ruleset.
Before continuing — the key takeaway — security does not depend on who or how the data is posted to the underlying blockchain, but how the economic agents parse the published data and who gets to decide the rules for parsing the data.
How Does A Sovereign Rollup Compare To An Ethereum Rollup?
An interesting way to compare the two systems is to consider the impact of replacing a validating bridge smart contract with an external software client run by economically important agents and unbeknownst to the underlying blockchain.
With that in mind, we have put together a comparison table to quickly highlight how that single difference — validating bridge vs external software client — impacts certain properties of a rollup.
Let’s cover each point one by one.
Security assumption.
A Sovereign rollup depends on which ruleset (and off-chain database) is preferred by economically important agents. The underlying blockchain has no influence on the validity ruleset. It can only guarantee that data is publicly available and its total ordering.
A validating bridge inherits all security properties from the underlying protocol and the new security challenge is the 1 honest assistant.
Upgradability.
A Sovereign rollup relies on the community to collectively agree upon a fixed ruleset for parsing the data. An upgrade relies on a process for the economically important agents to agree to the new rules. It may reflect ‘rough consensus’ or an external governance protocol on which software client to adopt.
A validating bridge will enforce all rules and changing the rules can only be performed by an upgrade procedure implemented in the smart contract code. The rules for upgrading the system is publicly verifiable to all.
Bridge assets.
A Sovereign rollup cannot make use of the underlying rollup except for data availability. Native assets like BTC cannot be transferred while inheriting the underlying blockchain’s security. It must rely on an external bridge protocol with its own trust assumptions.
A validating bridge has the sole responsibility protecting all assets it transfers from the underlying blockchain to the rollup.
Consensus fork. This is an interesting discussion on whether there is a conflict in the community in regards to the ruleset and if the off-chain system can split into two. This has already happened with BTC/BCH and ETH/ECH as both communities could go their separate ways and allow the market to decide which one should is valuable.
There are three type of assets to consider:
Native bridging. An asset is bridged from the underlying blockchain to the rollup.
Minted on the rollup. An asset is issued on the rollup and natively belongs to it.
Bridge operators. An external operator is supporting the effort of moving funds from another blockchain system to this rollup. It has its own trust assumptions for securing the assets.
To keep the comparison simple:
In a Sovereign rollup, the root of trust for deciding the ruleset and what is the off-chain database is up to the community. If there is a consensus fork, then the assets minted on the rollup will be replicated across the different forks and it is up to the external bridge operators to pick one of the forks.
In a validating bridge, a consensus fork is not possible. It is up to the smart contract to decide the rule set, the off-chain database, and to ultimately protect all assets that are natively bridged onto the rollup.
Censorship-resistance. It is the same on both rollups — there must be a forced inclusion mechanism implemented that allows the user to submit their transaction to the data availability layer and for it to be picked up by others.
Consensus protocol. A consensus protocol can be useful in a rollup to allow a set of Sequencers to agree upon the ordering of transactions before the data blob is posted to the data availability layer or to help coordinate the executors to attest to the new database state after executing the data blob.
However, a consensus protocol is optional for both type of rollups, and it can be argued whether we should even call it a “consensus” as opposed to an “appointment/ordering” protocol.
Let’s consider the base case with no consensus protocol. We can rely on the forced inclusion mechanism to allow a user to submit a data blob directly to the data availability layer and its position in the total ordering will be decided by the platform. Anyone can pick up the ordered data blobs, execute the blobs, and then compute the off-chain database.
So, if we want to add a consensus protocol to a rollup, the extra rules for parsing the data blobs can be encoded into the validating bridge or the external software client. For example, a round-robin protocol or a fair-ordering protocol can be implemented in the smart contract.
Gossip protocol. There is no requirement for agents to coordinate via a peer to peer network. All data can be posted to the data availability layer and all agents can read the published data. Whether there is a validating bridge or an external software client has no impact on how to send messages within the rollups.
Sovereign Rollup == Settlement Layer?
The mental modular for scalability is often thought of in distinct layers of execution → settlement → data availability. Each layer should have a direct dependency on the next one, but otherwise it is independent in nature.
By evaluating how to deploy a rollup on top of a data availability layer, like in the case of Bitcoin, it does highlight some problems with this mental model of layers.
If there is no fee market to rate-limit the publication of data blobs, then it can easily lead to spam that must be parsed and discarded by a Sovereign rollup. At the same time, the lack of expressiveness of the settlement layer can impact our ability to deploy validating bridges and rely on the settlement layer to protect all systems built on top of it.
In practice, at least to me, it appears we want to combine the layers of settlement and data availability, as this allows users to pay for the privilege of publishing data while enabling the deployment of validating bridges.
The subtle difference between Bitcoin and Ethereum — the ability for the platform to validate data blobs to an attested execution — has huge ramifications for how we can deploy rollups.
Do you want to deploy a validating bridge and allow the underlying blockchain to enforce the ruleset for determining what the off-chain system looks like?
Do you want to deploy an external software client and use the platform as a bulletin board for fetching ordered data blobs?
Put another way, the question is really about deciding who should be responsible for validating the data.
Can we trust the honest majority from the underlying platform to validate whether the data blobs leads to the the attested execution?
Should we introduce a new set of economic actors for checking whether the data blobs leads to the attested execution? Alongside re-using the honest majority of the underlying platform to guarantee the data blobs are available.
I am excited, thanks to the openness and permissionless nature of blockchains, that both rollup approaches can be evaluated empirically by the different startups. It’ll be up to the market to decide what works in the long term.
For me, and my own thesis on how these systems may evolve, I do believe we should try to minimise the introduction of different parties who are actively involved in protecting the integrity of a system. After all, a system is only as secure as its weakest link.
In the world of Sovereign rollups, we need to trust the honest majority of the underlying blockchain for ordering the data blobs and another set of parties to protect the integrity of how the data blobs should be parsed. A new set of actors is needed for every deployment and we need a way to scale this human process across hundreds/thousands of rollup deployments.
That looks a lot harder than an Ethereum rollup, or I should call, the Validating Rollup. A project can just deploy a validating bridge and solve the problem of finding one honest assistant to help the bridge. There is no need to introduce an extra set of decision makers to protect the off-chain system and thus it allows us to rely on software to scale and support the deployment of hundreds/thousands of rollups.
There is another interesting thought experiment that I would like to highlight in regards to Sovereign rollups. If we squint our eyes, they look very familiar to how we can build new settlement layers on top of a data availability layer.
If we consider the case of Bitcoin, the platform’s fee market can be used to prevent spam on the data availability layer while allowing a Sovereign rollup to be deployed on top of it. This rollup can allow users to mint assets, transfer assets, and deploy validating bridges to other off-chain systems. As such, it follows the path of Layer-3s, SHARP and the SuperChain.
Of course, BTC the native asset can’t be transferred to the Sovereign rollup in a trustless manner, but it does allow an eco-system to emerge on top of Bitcoin while allowing BTC to be used to pay for the network fee.
Regardless, I hope you have enjoyed this blog post. I’d like to finish on naming conventions. I have always disliked the term ‘Discrete rollup’ (sorry apolynya) to describe the type of rollup deployed on Ethereum. It should really be called a Validating Rollup as an underlying validating bridge is responsible for protecting all assets locked into the off-chain system.
See you next time, frens! And thanks again to Ser Chris Buckland for the quick sanity skim/check.
Is there a straightforward case where it is better to use Sovereign Rollup instead of Validating Rollup? I mean from the newly added trust assumption point of view. In the case of Sovereign Rollup, there must be some tradeoff because of its weakest link.