Buidler DAO Co-founder: What I Understand Layer0, Layer1, and Layer2 Actually Are?

Written by: Buidler DAO Co-founder Jason, 《Buidler DAO: What I Understand about Layer0, 1, and 2?》

This is my first macro analysis article. Previous articles focused on analyzing specific projects. This time, I want to try discussing a broader and less familiar area, while also structuring and organizing the scattered content I previously posted on Twitter into a single article. Web3 has always been a field filled with new concepts, so I dare to use this article to explain my understanding of Layer0, 1, and 2. You might wonder why the title isn’t “A Comprehensive Explanation of Layer0, 1, and 2”? On one hand, it’s because I lack the confidence and ability to explain it clearly; on the other hand, many definitions are still vague and lack industry standards. For example, from my perspective, Celestia belongs to Layer0, but there are many opinions that it belongs to Layer1. Therefore, this article represents my personal understanding, which may be incomplete or inconsistent with your views, and I welcome discussions.

Article Overview:

01/ Layer0: Cross-chain Communication

02/ Layer0: Modular Blockchain

03/ Layer1 Base Blockchain

04/ Layer2 Mainstream Solutions: Rollups

Layer0: Cross-chain Communication

Layer0 is, in my opinion, the layer with the most ambiguous definitions and complex understandings in the industry, so I will spend more time explaining it.

Many people define Layer0 as the Blockchain Infrastructure Service Layer, but I think this concept is still too broad. Currently, I believe the keywords for Layer0 are chain issuance, multi-chain, and cross-chain, with the core content focusing on cross-chain communication and modular blockchain. Therefore, once we clarify cross-chain communication and modular blockchain, the content of Layer0 will be mostly covered.

Let’s first talk about cross-chain communication. It’s important to note that cross-chain communication is different from cross-chain. Cross-chain communication is a technical implementation, while cross-chain is a business scenario.

Cross-chain is an extremely important capability for blockchains. Suppose each chain is a bank; if blockchains cannot communicate across chains, it would be equivalent to being unable to perform bank transfers. The cross-chain we often refer to is asset cross-chain, meaning I want to transfer aToken from Chain A to Chain B. First, the token project needs to issue its native token on both chains, and then use a cross-chain bridge to facilitate the "transfer" of tokens on both sides. The reason for putting "transfer" in quotes is that the process of transfer is not what we understand as moving from A to B. Its working principle is to lock the aToken on Chain A and then mint the corresponding amount of bToken on Chain B. As for the intermediate process of locking assets on Chain A and minting assets on Chain B, many issues arise, mainly communication issues. How does Chain A notify Chain B, "Zhang San just locked 20 aTokens with me, you need to quickly issue him 20 bTokens"?

When the chain itself is closed, it can only connect the asset changes of the two chains through off-chain monitoring, such as writing a script. But this is not native enough and not secure enough, which is why cross-chain bridges often encounter problems. Cross-chain communication mainly addresses the issue of native information transmission between multiple chains.

I previously wrote an article related to the LayerZero protocol, which focuses on cross-chain communication, titled 《Can the Cross-chain Gh0stlyGh0sts Become the Next Azuki?》. This is also the first project to achieve native cross-chain communication using LayerZero to enable NFT asset cross-chain effects. (Recommended reading: 《Cross-chain Communication Protocol LayerZero Ecosystem Review: How to Become the "DeFi Lego" Layer 0?》)

As mentioned earlier, traditional cross-chain bridges achieve pseudo-communication by monitoring the two chains off-chain, rather than truly transmitting information between the two chains. In the left and middle models of the diagram below, LayerZero directly deploys its nodes within the two chains, allowing these nodes to facilitate communication between multiple chains.

As shown in the diagram below, I can clearly specify in the contract code which chain (chainId) I want to transmit information to. This is the blockchain-native cross-chain communication.

I have high hopes for the LayerZero protocol, which has also completed a $135 million financing led by Sequoia. The reason is that I believe this is a truly native cross-chain solution, and asset cross-chain is just one of its application scenarios. The communication between chains is not limited to assets. Just like communication between banks is not limited to transfers, if I have a bad credit record at ICBC, they can inform CCB of this, which may cause issues when I apply for a loan there. The business scenarios behind cross-chain communication will definitely uncover many opportunities.

After discussing LayerZero, we can understand that the main content of Layer0, cross-chain communication, is clear. It is important to note that Layer0 is a concept, while LayerZero is a specific protocol within this concept; these two should not be confused.

Layer0: Modular Blockchain

Another important aspect of Layer0 is modular blockchain. The term cross-chain communication is relatively easy to understand and is indeed quite fundamental, belonging to Layer0. However, the term modular blockchain may sound very "big" at first, not like a layer concept, but rather a "full set." If blockchain is a hamburger, Layer refers to the lettuce, patty, and bun inside, but modularization sounds like a complete big hamburger rather than a piece of lettuce.

In a broad sense, modular blockchain is a type of "architecture." Layer2 is also a modular blockchain, abstracting the computation layer. However, from the current narrow positioning of modular blockchain, we need to understand the purpose of modularizing blockchain, which helps define its layer. I believe the most direct purpose is to enable simpler and faster chain issuance. The effect of modularization is to clarify the blockchain technology architecture, encapsulate it more completely, and allow it to be used out of the box, like building blocks, enabling the ability to issue a new chain at a lower cost. You can roughly understand that the purpose of modular blockchain is to issue a Layer1, which helps explain why it is positioned at Layer0.

The two representatives of modular blockchain, Cosmos and Celestia, will be introduced to help clarify their meanings. Thanks to @Kasey_ibc, a deep contributor to the Cosmos ecosystem, for the discussions and research on his high-quality Twitter content.

Celestia is the evangelist of the modular blockchain concept. I previously posted an analysis on Twitter regarding modular blockchain, and here I will reference that content to discuss Celestia. You can find the specific content in my original Twitter post, linked here: https://twitter.com/jason_chen998/status/1561576592337682434

The official website describes its advantages, with the first point being the ability to deploy blockchains as easily as smart contracts, lowering the barriers and costs of chain issuance.

The opposite of modular blockchain is that most Layer1s are monolithic blockchains, where a single chain handles consensus, data availability, and execution.

Consensus: Nodes in the entire network decide which transactions to package and in what order.

Data Availability: Verifying that a block has been fully broadcast and written to the chain.

Execution: Specific transaction and state changes.

If a single chain handles all three tasks, it is a monolithic blockchain, which is the problem currently faced by L1s, where transactions, settlements, and block production queue up to be completed. Therefore, the design approach is to separate the core responsibilities of consensus, data availability, and execution into individual chains, allowing each to focus on its own tasks and then assembling them together.

At this point, you should realize that this follows the modular design principles that have been adhered to in software development for 30 years, encapsulation, polymorphism, coupling, and cohesion, breaking down a complex system into functional components, allowing each to work independently before reassembling them. Thus, this top-level design concept has always existed, and applying this design philosophy to blockchain design is not a novel idea.

When discussing the separation of consensus, data availability, and execution into individual chains, you should recognize that this is what L2 is doing. The rollup scaling approach involves taking the execution layer out as a sub-chain to handle Ethereum's transaction processing, then returning the results to the Ethereum main chain. Therefore, rollups are essentially a modular design concept. As mentioned earlier, the broad definition of modular blockchain is not a specific thing; it is a concept or design philosophy. However, the narrow definition of modular blockchain refers to encapsulating the underlying capabilities of consensus and data availability, which are the foundations of a blockchain and involve the highest complexity and difficulty. Once these two capabilities are established, issuing a new chain becomes much easier and cheaper, allowing developers to focus on their business and computation.

Celestia mainly modularizes data availability capabilities, storing transaction records through consensus mechanisms and providing data availability without participating in settlement and execution layers, ensuring that the stored data is valid. Other developers can then build their own settlement and execution layers on Celestia in a rollup manner. Thus, Celestia is like AWS in the blockchain field. Traditionally, if a company needed to develop software, it would have to buy a server to host it. If 10 companies needed servers, they would each need one. AWS says, "Don't buy your own; I'll build a big one. You just focus on software development, and when you need to store or access data, come to me. I can guarantee your data is valid (it can be stored and retrieved)."

So why does Celestia want to modularize the data availability layer? The most challenging part of issuing a new chain is getting as many nodes as possible to participate in the consensus and data availability processes for my chain. With enough nodes maintaining my chain, more application-level execution can occur.

Next, we need to look at how data availability is achieved on L1 chains. We know that blockchains consist of numerous nodes that can freely join. The more nodes, the more secure and decentralized it becomes. Nodes are divided into full nodes and light nodes. Full nodes maintain a complete data ledger, so a small number of malicious nodes cannot affect the overall network, which is the foundation of blockchain.

However, as time goes on, the data grows larger, and maintaining a full node becomes too costly. If everyone is unwilling to run full nodes, the blockchain becomes centralized and insecure, leading to the existence of light nodes that do not maintain or verify all transaction data but only store block headers. When data availability needs to be verified, they send it to neighboring full nodes for validation and then return the results.

In summary, the most challenging part of creating a chain is how to get enough nodes to maintain the consensus and data availability of my chain. This is the problem Celestia aims to solve. It states on its website that it hopes to make creating a chain as simple as creating a smart contract, allowing developers to focus on their upper-layer execution and settlement without worrying about the underlying data issues, achieving the effect of "one-click chain issuance."

After discussing Celestia, let’s look at Cosmos. In fact, there is a high overlap in the members of these two organizations, with many people contributing to both.

Cosmos aims to become the internet of blockchains. First, it provides a set of "chain issuance" capabilities, allowing each community to have its own sovereign chain. A sovereign chain is an independent blockchain where data generation and writing are internally closed loops. Secondly, chains can communicate and interact with each other, achieving interconnectivity among thousands of chains, which is a very compelling vision.

As for why it believes there is a demand for communities to issue their own chains, it is because it divides blockchains into public chains and proprietary chains. On public chains like Ethereum, developers face two layers of governance: the chain and the application, and applications must adhere to the constraints of the underlying chain, making it difficult to unlock the value of applications. Therefore, it aims to create a custom chain for each application.

To achieve this goal, it must first address the issues of barriers and costs associated with issuing a new chain, and secondly, solve the problem of how to facilitate communication between so many chains to form a snowball ecosystem.

Cosmos's approach to barriers and costs aligns with Celestia's, which is to encapsulate underlying capabilities. The blockchain architecture is divided into three main layers: network, consensus, and application. It encapsulates the network and consensus layers, including atomic capabilities such as accounts, transactions, and signatures, providing an SDK for developers to build sovereign chains based on this. By using pre-configured modules, they can customize and construct blockchains, then publish them to the Cosmos network for interaction with other sibling chains. Interaction is achieved using the cross-chain communication protocol IBC, creating a hub effect where other chains connect to this hub for data relaying.

In summary, the concept of Layer0 focuses on chain issuance, multi-chain, and cross-chain, making chain issuance simpler. However, if many chains are issued without interconnectivity, they cannot form a synergy, so the cross-chain issue needs to be addressed.

Layer1 Base Blockchain

Layer1 refers to base blockchains. Well-known examples include Bitcoin, Ethereum, and Binance Chain, as well as Avalanche, Near, and Terra, because they are the main networks within their ecosystems, processing and completing transactions on their own blockchains while also having their native tokens. The recently emerging public chains Aptos and Sui are also Layer1s, but it’s important to note that many people easily confuse Layer1 with public chains; public chains include Layer1 but are not equivalent.

Layer1 public chains are the species with the deepest moat in the crypto world. As more nodes, developers, and projects join their ecosystems, the advantages of the snowball effect become very apparent. Unless a foundational token collapses directly, like Luna did for Terra, causing a major avalanche for the big snowball, the complex web of interests within the ecosystem will tightly bind together, making the roots of the chain deeply entrenched. Therefore, creating a successful Layer1 public chain has always been a pursuit for countless organizations in the crypto space.

Currently, the largest Layer1 public chain in terms of application domain is Ethereum. Competing chains will try to find ways to attract developers and users from the Ethereum ecosystem because the high gas fees of Ethereum, which can reach dozens of dollars during peak times, are quite painful for ordinary users like me. Therefore, most competing chains currently focus on low gas fees and high TPS strategies to capture user resources. For example, Aptos, which just completed a hot airdrop this week, has been the subject of much discussion. When Aptos launched its mainnet, many marketing accounts claimed that Aptos boasted 10K TPS, but in reality, it only achieved 4 TPS. This led to a lot of ridicule, making people think it was inflated. The 10K TPS is the theoretical maximum capacity, while 4 TPS is the actual running capacity at that time, similar to how the Hong Kong-Zhuhai-Macao Bridge theoretically claims a daily capacity of 250,000 crossings, but in reality, only a few vehicles pass through each day. Can we say that the performance of the Hong Kong-Zhuhai-Macao Bridge is inflated?

Building a public chain is like building a city. The prosperity of a city requires the construction of housing, hospitals, shopping malls, railways, and other infrastructure to create a livable environment, attracting residents to move in. If a chain lacks applications to attract users, it is useless. No matter how strong Aptos is in terms of performance or how high its theoretical TPS is, without sufficient applications to validate it, it is like a Hong Kong-Zhuhai-Macao Bridge with no cars running on it. Therefore, the methods for public chains to attract developers can be divided into several categories:

1. Public chains provide sufficient support to developers, offering money and traffic for developing applications. This is why many public chains are backed by exchanges, as they can afford to invest money and frequently host hackathons and issue grants to attract investment.
2. The biggest attraction of new public chains for developers is the ample opportunity, as the competition on mature Ethereum is too fierce. Moving to a new public chain allows developers to directly transfer applications that have already been validated on Ethereum. For instance, recently, we have seen NFT trading platforms and domain service providers on Sui, which are already well-established on Ethereum, still receiving significant funding. I have seen many people joking in groups that any project can be replicated by just changing the programming language.
3. Another effective method, in my opinion, is direct EVM (Ethereum Virtual Machine) compatibility. For developers, the biggest cost is not writing code but learning it. Starting from scratch with an entirely unfamiliar tech stack, then going through practical development, debugging, etc., can discourage many developers. So, is there a way for Ethereum ecosystem developers to smoothly and cost-effectively migrate to a new chain? Is there a way for me to develop and debug applications running on Windows using a Mac? By installing a virtual machine, many people have friends who buy a Mac but find it inconvenient, so they switch it to Windows, or they are essentially running a virtual machine. The EVM serves Ethereum's smart contracts, so if a chain is EVM-compatible, developers can smoothly migrate Ethereum applications to the compatible chain. The well-known BSC is an EVM-compatible chain.

Layer2 Mainstream Solutions: Rollups

Now let’s talk about Layer2. Earlier, I mentioned that many competing Layer1 chains target Ethereum's "expensive" and "slow" characteristics, but what can be done to optimize Ethereum itself? Layer2 is one approach.

When discussing Layer0, I talked about monolithic chains, where everything is done on a single chain. How can that not get congested? At this point, someone thought about whether it is possible to execute transactions on Ethereum externally and then return the results to Ethereum for data availability processing. This approach is called rollups, which is also the mainstream solution for Layer2. It’s like fixing a heavily congested road by building an elevated bridge. I also saw an interesting explanation: doing a nucleic acid test for 10 people in a mixed tube is rollups.

By processing transactions off-chain, it avoids the slow consensus process of Ethereum, thereby reducing the computational load on the Ethereum mainnet and improving overall processing speed and throughput.

When I was studying, my research direction happened to be blockchain scaling, and the solution I proposed in my paper was similar to rollups, as shown in the diagram below.

As mentioned earlier, rollups involve executing computations off-chain and then placing the results on-chain. The biggest problem with this process is how to prove that the result is valid. Two types of proof methods have led to two mainstream rollup solutions: Optimistic rollups and zk rollups.

As the name suggests, Optimistic means optimistic. Optimistic rollups use fraud proofs as a method of validating data validity. After synchronizing the results of off-chain computations to the Ethereum mainnet, it optimistically assumes that the data is correct. If someone believes the data is incorrect and constitutes fraud, they can challenge the aggregated transaction results during a window period, also known as the challenge period, by computing a fraud proof.

If the proof successfully demonstrates fraud, the transaction will be re-executed to update the data state, and the sorting node that packaged the transaction at that time will be penalized by reducing its submitted collateral (becoming a sorting node requires a collateral deposit) and distributing it to the validating nodes that submitted the fraud proof.

In this process, besides the two nodes, sorting nodes and validating nodes, there are also two other important roles involved: CTC (Canonical Transaction Chain) contract and SCC (State Commitment Chain) contract.

The logic here is a bit complex, so please be patient. All Optimism transaction data blocks are stored in a special Ethereum contract called the CanonicalTransactionChain, abbreviated as CTC. The contract address is:

0x5E4e65926BA27467555EB562121fac00D24E9dD2

You can see that the sorting node Sequencer writes about two batches (the professional term for batches is Batch) every minute, with each batch possibly containing hundreds of transaction data. The CTC contract mainly stores transaction data summaries.

Additionally, the state root after transactions is stored in the StateCommitmentChain contract, abbreviated as SCC. The contract address is:

0xBe5dAb4A2e9cd0F27300dB4aB94BeE3A233AEB19

Approximately every 6 minutes, a batch is written, and validating nodes can read the records from these two contracts to verify whether there are fraudulent transactions.

The above describes the method of validating data validity in Optimistic rollups, which has a game theory feel to it. Through the confrontation between both parties and the incentive model, it achieves a minimal degree of malicious fraud. Now let’s see how ZK solves this.

zkSync is a major player in zk rollups. Its official slogan is "rely on math, not validators," which directly addresses the fraud proof of Optimistic rollups, indicating a clear contrast.

In zk rollups, the validity of each transaction is verified before the transaction occurs. Sorting nodes cannot act maliciously. However, in Optimistic rollups, the behavior of sorting nodes is unregulated, so validating nodes must monitor for fraudulent transactions. If fraud is detected, they need to submit a fraud proof to the mainnet.

The main advantage of zk rollups over Optimistic rollups is that they use pure mathematical calculations with zero-knowledge proofs for transaction validity verification, so transferring funds to Ethereum does not experience delays. Once the zk rollup contract completes the validity proof, the transaction will be executed. In contrast, extracting funds from Optimistic rollups will incur delays due to the need to allow time for fraud proofs.

The core architecture of zk rollups includes:

1. On-chain contracts: Similar logic to Optimistic rollups, deploying corresponding smart contracts on Ethereum to store block summary data, verification contracts, etc. However, it does not need to publish as much transaction data on Ethereum contracts as Optimistic rollups do, because its validity has already been proven before being placed on-chain, rather than requiring data to be sent to the chain for others to verify. However, zk rollups can also store transaction data in the calldata of smart contracts, which is a temporary storage area that is immutable but not persistent, similar to memory, so it can be accessed if needed.

2. Off-chain virtual machine: Although zk rollups are dependent on Ethereum, the transaction execution process occurs in an independent EVM virtual machine, which is the actual environment where zk rollups execute.

The overall process is similar to Optimistic rollups. After users sign transactions, they submit them to the Layer2 sorting nodes of zk rollups for processing and packaging into a batch, which is then submitted to Ethereum.

The zero-knowledge proofs used by zkSync are quite complex and involve a lot of cryptographic mathematics, which I find difficult to fully understand, so I won’t pretend to understand by copying complicated mathematical formulas from development manuals.