My View on Layer 2 and Rollups

Special thanks to my team (opens in a new tab), Dogan (opens in a new tab), Kautuk (opens in a new tab) and c-node (opens in a new tab) for feedback and review.

There are lots of confusing terminology and controversial discussions about Layer 2 and Rollups. What makes a blockchain L2, how it inherits the security of the underlying blockchain, how it is bridged from/to the underlying blockchain...

As Chainway, we are building "A Sovereign Validity Rollup on Bitcoin". So we are deeply involved in these discussions. I am trying to share my thoughts on these topics in this blog post.

forever on Bitcoinhttps://t.co/gZ6XvIMI4c (opens in a new tab) pic.twitter.com/9XRZDIkc0A

— Chainway (@chainway_xyz) August 11, 2023

Overview

Let's define some terminology first.

• Layer 1 (L1): The blockchain. For example, Ethereum is the L1 for Arbitrum. An L2 blockchain can be an L1 for another L3 blockchain too in terms of its point of view, but let's not go that deep.

• Layer 2 (L2): A blockchain that inherits some properties, which we will discuss later, from the underlying blockchain. For example, Arbitrum is an L2 blockchain for Ethereum and Lightning Network is an L2 state channel (not a blockchain) for Bitcoin.

• Rollup: A blockchain that somehow executes transactions off-chain, shrinks them into smaller transaction(s), and submit them to the underlying blockchain. Those transactions validity can be proven via zero knowledge proofs, or can be challenged by fraud proofs. Please note that we are mentioning proving or challenging the validity of the transactions, not the verification of these proofs. Delegating the verification to the underlying blockchain is not a requirement for a Rollup. Will deep dive into this later.

• Bridging: A mechanism that allows the transfer of assets from one blockchain to another. Generally, bridging between independent blockchains is not possible without strong trust assumptions. A blockchain can minimize the trust assumptions by enshrining state and correct chain verification to the other blockchain. Which is not possible in most of the cases. Also, this part will have a dedicated section.

We may define more terminology, but let's do it when we need it.

What defines the security of a blockchain?

(ii) There are our properties that together determine the security of a chain: (a) re-org resistance, (b) censorship resistance, (c) data availability and (d) validity.

— Sreeram Kannan (@sreeramkannan) March 6, 2023

I believe this is a great definition of the security of a blockchain. We will refer to these properties while discussing the properties of different L2 solutions.

What type of data is posted to the L1?

The most important topic to discuss here is how the L2 blocks are finalized on the L1. Finalization is subjective to the node types (L1, L2, L2 Light...). In order to understand this carefully, we need to deep dive into the data posted to the L1 and how it is verified (but, does it have to be verified?).

A blockchain can post different data to the underlying blockchain:

• Validity Rollups: State transition data with a validity proof
• Optimistic Rollups: State transition data and raw block data
• Validiums: Validity proof
• Optimistic Chains(?): State transition data
• Full Batch Data (including witnesses)

Validity Rollups

Validity rollups process a batch of off-chain transactions in some zk circuit or zkVM and generate a proof that can verify the validity of the batch and generates the state transition data. This proof together with the state transition data is posted to the underlying blockchain.

Here is the hot take: The underlying blockchain does not have to verify the validity of the proof. It can just accept the proof and the state transition data without processing or saving it. The validity of the proof can be verified by the users of the L2 blockchain. If the proof is invalid, then the users can basically ignore the state transition data. If the proof is valid, then the users can process the state transition data and update their state. You may ask what is the point of posting the proofs and state transition on-chain then, the answer is really really simple: Data Availability. The users can ensure that whatever happens on the L2 blockchain, the data will be available on the L1 blockchain. This is the only thing that the L1 blockchain has to ensure.

Cem Özer used a great sentence in his tweet (opens in a new tab).

So anyone running a full node for the rollup, i.e. executing the data blobs posted on Bitcoin that refer to the rollup, can deterministically know the correct state of the rollup chain.

If your rollup posts the proofs and state transition data, then your rollup nodes can determine the latest state of the L2 blockchain by just scanning blocks of the L1 blockchain. This is what we call Data Availability.

I can hear you asking, so what is the point of verifying the proofs on the L1 blockchain? We discovered a concept, settlement. The settlement brings an important but also a dangerous property to the L2 blockchain, trustless bridging. Verifying the proof on L1 allows L1 to know the latest state of the L2 blockchain. This is basically all you need for bridging your tokens. (Some may argue about the definition of trustless, but let's not go there.)

Trustless bridging is important for an L2 if the L2 wants to utilize the liquidity of L1, however, there is a catch: Now your rollup's latest state is strictly tied to the L1 state.

Let's say there is a bug in the L2 blockchain that allows the users to mint tokens out of thin air. You immediately fixed the bug and deployed the new version of the L2 blockchain. However, the L1 blockchain still has the old verifier of the L2 blockchain, which means that new proofs cannot be validated on the L1 blockchain. This means that the L1 blockchain will not accept the new state transition data. This is a problem because the L2 blockchain cannot move forward without the L1 blockchain accepting the new state transition data.

A naive solution is to deploy the new verifier to the L1 blockchain and point your L2 blockchain to the new verifier. Uups, you just left all the bridged L1 tokens in the old smart contract. You lost all the pegs, and you cannot do anything about it. The other way is to upgrade your existing verifier contract. Sounds cool, but who has the upgrade authority? Today, the answer is a small multisig with some trusted people. Now we are back to the trust assumptions. If a small multisig can upgrade the verifier contract, then they can also steal the funds in the verifier contract. Suddenly, your L2 trustless bridge is not trustless anymore. It has an honest majority assumption within a small group of people. In the future, we may give the upgrade authority to the users of the L2 blockchain, but this is not possible today (I am not sure if this is possible in the future too, but let's assume it is).

Some sharp-eyed people may discover a new property in the last paragraph, sovereignty. Settling on a blockchain allows you to have a trustless bridge, which will and has to verify the latest chain. Your rollup is not sovereign anymore. It is deeply connected to the L1 and can't fork without it. You either need to fork the L1, not possible, or upgrade the L1 verifier contract, which is not trustless.

Posting all the necessary data to the L1, but not verifying it, is a good idea if you want to have a sovereign L2 blockchain, which I believe is more useful in most cases. This is what we define in the beginning as a Sovereign Validity Rollup.

Optimistic Rollups

Optimistic rollups process a batch of off-chain transactions directly and post the state change into L1 together with the raw transaction data. Once it is posted, there is a challenge period, which is generally 1 week, that allows anyone to challenge the validity of the batch. If the batch is invalid, then the challenger can post a fraud proof to the L1 blockchain. If the batch is valid, then the batch is finalized on the L1 blockchain.

Similarly, fraud proofs do not have to be verified by the L1 blockchain. The L1 blockchain can just accept the fraud proof and record it somewhere (calldata is enough for this). The users of the L2 blockchain can verify the fraud proof and revert the state change. If the fraud proof is invalid, then the users can ignore the fraud proof. If the fraud proof is valid, then the users can revert the state change.

This is similar to Sovereign Validity Rollups, which uses L1 for data availability, but not for settlement.

In the Optimistic Rollup scenario, you get a bridge with the L1 that has 1/N honest participant trust assumption. This means at least one good actor is watching the state changes and challenges the rollup if there is fraud. This is a good assumption, but not trustless. The bridge also has the same upgradeability problem with the Validity Rollups.

The contrary to the Validity Rollups, Optimistic Rollups have to post raw transaction data to the L1 blockchain. This is required for a watcher to generate fraud proofs. It is not possible to generate a fraud proof only with the state change. This will affect our security assumptions once we start talking about Optimistic Chains.

Validiums

Validiums process a batch of off-chain transactions in some zk circuit or zkVM and generate a proof that can verify the validity of the batch and outputs the state root. This proof is posted to the underlying blockchain.

Thanks to proof that verifies and records the latest state of the Validium to the L1, we can easily bridge from/to the L2. All you need to do is to prove you are in the state root (basically). The important point here is you need to have the whole state tree in order to prove you are in the tree, which is not stored on the L1. Ups, so where it is stored? It may be stored on a centralized party or a data availability committee. This is a trust assumption. If the party holds the data is honest, then you are good to go. If not, then you are in trouble. You cannot prove you are in the state root, which means you cannot bridge your tokens.

Sorry for the spoiler, but Validiums are not L2s. They are highly scalable though, but not in terms of security. There is no (L1) guarantee you can construct the latest state on your own, there is (L1) no guarantee you can retrieve data from the data availability committee. Validiums skips to inherit most of the security of the L1 blockchain. They are just a highly scalable blockchains that can be used for some use cases.

You may notice I haven't mentioned sovereign validiums, which is basically useless. If you don't post your data to the L1 and also do not have some sort of bridge, it is basically just checkpointing (not the real checkpointing that you built your consensus around it) your state to the L1. You can do this with a centralized database too, why bother with a blockchain?

Optimistic Chains(?)

Optimistic Chains are not a thing yet, but they are starting to be. Optimistic Chains are basically Optimistic Rollups without posting the raw transaction data to the L1 blockchain. Instead, they store raw transaction data on a centralized party or a data availability committee. This is a trust assumption similar to validium. If the party holds the data is honest, then you are good to go. If not, then you are in trouble. You cannot challenge against the state root, which means proposer can propose invalid state roots and finalize them on the L1 blockchain, and you cannot do anything about it 🤮. Similar to Validiums, Optimistic Chains are not L2s too for me.

Honestly, I don't know why Optimistic Chains are becoming a thing. I might be missing something, but let's see. Again, just like sovereign validiums, no need to talk about sovereign optimistic chains also.

Full batch data

The full batch data version is generally used in Sovereign Rollups that does not have any validity or fraud proof mechanism. Actually, they do not have to have it. Validity (if recursive) and fraud proofs are good for light clients of the L2 (which makes sense to have it if you are sovereign), but not for the L1. The L1 blockchain does not have to verify the validity of the transactions, it just needs to ensure the data availability. If you post whole batch data (including witness data) to the L1 blockchain as calldata, then the L1 blockchain can ensure the data availability. This is the only thing that the L1 blockchain has to ensure. As soon as it is written, rollup full nodes can execute the transactions one by one and apply the state changes. They can basically ignore the invalid batches. The pain point with this approach is the cost of publishing the data into the L1 blockchain. It is generally more expensive than posting a validity proof with state diffs.

Some rollup types add async proving on full batch data, like Sovereign SDK (opens in a new tab). This allows fast finality for full nodes, but still allows trustless light clients and bridges.

I am not going to talk about this more, maybe in another article about sovereign rollups and sovereign chains. I just wanted to mention that this is a thing.

Sovereignty

Wow, there were lots of things to talk about even though I skipped almost everything about re-org resistance, censorship resistance, and probably some other new rollup types. I will try to write another detailed article about these topics. Let's talk a little more about sovereignity, data availability, and bridging.

Sovereignty; very basically is ability to fork independently from the underlying chain while still inheriting the security of the underlying chain. This is a very important property for a blockchain. Please note that, there is no trustless bridge between the Sovereign Rollup (or Chain 😳) and the DA, but the security of the L2 has nothing to do with it. Native assets on Sovereign Rollups are as secure as a native asset on L1 (if everything is implemented correctly, such as censorship resistance). If you try to bridge the token somehow from the L1 to the rollup, then those tokens' security is determined by the security of the bridge.

Unfortunately, there is not enough information about sovereignty and sovereign rollups. Celestia is creating terminology for the topic, but it is still not enough. Also, I noticed a part from one of their articles that I don't agree with. In their article (opens in a new tab) they say:

Sovereign rollups can have a bridge with their DA layer. If the DA layer supports smart contracts, the bridge can be trust-minimized. If there is no smart contract support, like with Celestia, then the bridge would require stronger trust assumptions.

I believe this statement is not correct. If you have a bridge with your DA layer, then you are not sovereign. You are deeply connected to the DA layer and cannot fork without it. You either need to fork the DA layer, not possible, or upgrade the DA layer, which is not trustless. Enshrining your bridge into the DA layer makes you a smart contract (or enshrined) rollup, not a sovereign rollup.

Important Update: Celestia has slightly changed their article just before I published this article. You can see the PR (opens in a new tab). Thank you @c-node for the feedback to the team and letting me know about the update. I still think what they are saying is not possible, but I will let you decide.

However, it is possible to bridge between rollups that share the same DA layer. Every rollup on the same DA layer scans its slots, which it can find the latest state of the other rollup, and it is really fast if the rollup is a validity rollup (generates proof for its execution). As every rollup is sovereign, it is generally easier to upgrade compared to Data Availability layers.

Conclusion

To sum up, I believe the most confusing point on rollups and L2s is the settlement and bridging. For me, settlement = bridging. Actually, we can completely forget the term settlement. Settlement is needed if you want to have a trustless (in the future though) bridge between your L2 and L1. It is definitely not a prerequisite for being an L2. As you can see from my examples, sovereign rollups are not settled on the L1 blockchain, but they are still L2s and inherits the security of the L1 blockchain. So we can easily conclude, rollup != bridge. We can also conclude that current "trustless" bridges are not so trustless. It is ok to have a trust assumption with the current tech, but we need to be honest about it. In the future, we may have trustless bridges, but we don't have them today and we need to admit it.

There are lots of incorrect terminology out there and probably some (maybe most) people will find mine incorrect too. Sovereignty, settlement, and rollups are new technologies. It is natural to have debates and confusions around it. I believe there is no strictly correct terminology as these are all spectrums and open to discussions, but we need to be consistent. I tried to be consistent with my terminology, but I may have failed. Please let me know if you find something incorrect or inconsistent. I will try to update the article accordingly.

I will also write other articles on this topic to discuss consensus, finality, re-org resistance, censorship resistance, and more. Stay tuned.

Thank you for reading.

• Twitter (opens in a new tab)
• Github (opens in a new tab)