Jan, co-founder of CKB, made a judgment on Layer2 issues in 2019, reflecting the core values of Nervos's design philosophy.

Compiled by: Misty & Bai Ding, Geek Web3

This article is based on Jan's speech at the 2019 HBS Blockchain+Crypto Club Conference, focusing on the relationship between Layer2 and Layer1. He clearly stated that modular blockchain would be the right direction, and also discussed issues related to blockchain data storage mechanisms. At the same time, Jan raised an interesting topic: if the rise of Layer2 leads to the starvation of Layer1, how should it be resolved?

As one of the earliest teams to support the narrative of Layer2 and modular blockchain, Nervos's stance in 2018 and 2019 was quite forward-looking. At that time, the Ethereum community still held unrealistic fantasies about sharding, while the narrative of high-performance single-chain was rampant and had not been sufficiently falsified.

However, looking back at the issues exposed by Ethereum Layer2 in practice today in 2024, as well as the drawbacks of "high-performance public chains" represented by Solana in terms of decentralization and trustlessness, it must be said that Jan's views from five years ago were quite prescient. Out of interest in Layer2 itself, "Geek Web3" has organized Jan's lecture into a written format and published it here, welcoming Layer2 enthusiasts from the Nervos, Ethereum, and Bitcoin communities to learn and discuss together.

Below is the original text of Jan's lecture.

Definitions of Layer1 and Layer2

This is my definition of L1 and L2 (Layer 2 networks), as shown in the diagram.

First, it must be emphasized that Nervos is merely a blockchain network striving to meet the demands of a decentralized economy and is not responsible for solving "all problems." In our understanding, the key difference between Layer1 and Layer2 lies in the strength of consensus. L1 networks must have the broadest consensus, namely "global consensus." Through permissionless global consensus, anyone in the world can participate in the consensus process of L1, ultimately allowing Layer1 to serve as the "anchor" of a decentralized economy. From this perspective, we can refer to L1 as the "consensus layer."

In contrast, the consensus range of L2 networks is somewhat smaller; its participants may come only from a specific country, industry, or even a particular company or institution, or a very small community. The sacrifice in consensus range for L2 is a trade-off that brings progress in other areas, such as higher TPS, lower latency, and better scalability. We can refer to L2 as the "protocol layer," and L1 and L2 are often interconnected through cross-chain bridges.

It must be emphasized that our goal in building L2 networks is not merely to solve the scalability issue of blockchains, but because a layered architecture is the easiest way to implement "modular blockchain." A modular blockchain is one that addresses different types of problems by placing them into different modules.

Many people have been discussing compliance and regulatory issues in blockchain, so how should we incorporate Bitcoin or Ethereum into the existing regulatory framework? A layered architecture may be one answer to this problem. Directly adding business logic that meets regulatory requirements at the Layer1 level may compromise its decentralization and neutrality, so compliance-related logic can be implemented separately on Layer2.

Layer2 can be customized according to specific regulations or standards, such as establishing a small blockchain based on a permissioned model or a state channel network. This way, compliance is achieved without affecting the decentralization and neutrality of Layer1.

Additionally, we can also resolve the conflict between security and user experience through a layered architecture. Analogously, if you want to ensure the security of your private keys, you must sacrifice some convenience, and the same goes for blockchains; if you want to ensure absolute security, you must sacrifice something, such as the performance of that chain.

However, by using a layered architecture, we can fully pursue security on the L1 network while sacrificing a little security on the L2 network in exchange for a better user experience. For example, we can use state channels on L2 to optimize network performance and reduce latency. Therefore, the design of Layer2 is merely a trade-off between security and user experience.

The above naturally leads to a question: Can any blockchain serve as Layer1?

The answer is no. First, we must clarify that the decentralization and security of Layer1 networks take precedence over everything else, because we must achieve censorship resistance through decentralization. The pursuit of security in Layer1 is fundamentally because L1 is the root of the entire blockchain network and the anchor of the entire crypto-economic system.

Under such a judgment standard, Bitcoin and Ethereum are undoubtedly the most classic L1 networks, as they possess a very strong consensus range. Apart from these two, most blockchains do not meet the standards of L1, having a lower degree of consensus. For example, EOS does not meet the consensus standards and can only serve as an L2 network, especially since some of its rules only apply to itself.

Current Issues with Layer1 Networks

After clarifying the definition of Layer1, we must point out that some existing L1 networks have three issues, which also exist to some extent in Bitcoin and Ethereum:

1. The Tragedy of the Commons in Data Storage

When using blockchain, we need to pay certain fees, but in Bitcoin's economic model, the fee structure only considers computational costs and network bandwidth costs, without adequately considering data storage costs.

For example, users only need to pay a one-time fee to store data on-chain, but the storage duration is permanent, allowing people to abuse storage resources by permanently putting anything on-chain, ultimately leading to increasingly high storage costs for full nodes in the network. This raises a problem: the cost for any node operator wanting to participate in the network will be maximized.

Assuming that the total state/account data of a certain blockchain exceeds 1TB, not everyone can easily synchronize the complete state and transaction history. In such cases, even if you can synchronize to the complete state, it becomes difficult to independently verify the corresponding transaction history, which undermines the trustlessness of the blockchain, and trustlessness is precisely the core value of blockchain.

The Ethereum Foundation recognized the above issues and incorporated a design for a storage leasing system in EIP-103, but we believe this is not the optimal solution.

We proposed a new state model in Nervos called "Cell," which can be seen as an extension of UTXO. In the state of Bitcoin UTXO, you can only store the balance of Bitcoin, while in a Cell, you can store any type of data, generalizing the amount and integer value of Bitcoin UTXO into "Capacity" to specify the maximum storage capacity of a Cell.

In this way, we bind the number and size of native assets on CKB together. The space occupied by any Cell cannot exceed its capacity limit, so the total amount of data will remain within a certain range.

Moreover, we ensure that the size of state data does not interfere with node operators through a suitable token inflation rate. Anyone can participate in the CKB network; they can verify historical data and also verify whether the final state is valid. This is the solution CKB proposes to the storage problem in blockchain.

2. The Layer1 Starvation Problem

If we expand on Layer2 and move a large number of transaction activities to Layer2, it will inevitably lead to a decrease in the number of transactions on Layer1, and the economic rewards for Layer1 miners/node operators will correspondingly decrease. In this case, the motivation of Layer1 miners/node operators will decline, ultimately leading to a decrease in the security of Layer1. This is known as the Layer1 starvation problem.

To give an extreme example, if we move all transaction activities to L2, then L1, as its foundation, will become unsustainable. So how can we solve this problem?

In this regard, we need to distinguish between the types of users in the blockchain network, which can be simply divided into Store of Value Users (SoV users) and Utility Users (application users).

Taking CKB as an example, SoV Users use the native asset CKB token as a means of value storage, while Utility Users utilize Cells to store state. SoV Users are resistant to the price dilution caused by CKB token inflation, while Utility Users must pay miners for state storage fees, which are proportional to the duration of data storage and the space occupied.

We will continuously issue new CKB tokens in the network to create a fixed inflation rate and pay it to miners, which effectively dilutes the token value held by Utility Users (this is one of the "secondary issuance" models in the CKB economic model, where 1.344 billion CKB tokens are issued annually; for more details, please refer to "Interpreting Stable++: The First Stablecoin Protocol of RGB++ Layer Officially Launches").

In this process, the assets of SoV Users are also diluted, so we can provide them with certain subsidies to offset inflation losses (this is what later became the NervosDAO profit-sharing). In other words, the benefits miners gain from CKB inflation are actually paid solely by Utility Users. We will soon release a token economics paper for CKB, where related issues will be explained in detail.

Based on this token economics design, even if there are no transaction activities on the CKB chain, miners can still receive rewards, allowing us to be compatible with any "value storage layer" or Layer2. In summary, we address the Layer1 starvation problem through intentional fixed inflation.

3. Lack of Cryptographic Primitives

Users need different cryptographic primitives to use various encryption methods or different signature algorithms, such as Schnorr, BLS, etc.

To become a Layer1 blockchain, one must consider how to interoperate with Layer2. Some in the Ethereum community have proposed using ZK or Plasma methods to achieve Layer2, but without ZK-related primitives, how can you complete verification on Layer1?

Additionally, Layer1 must also consider interoperability with other Layer1s. Using Ethereum as an example, some have requested the Ethereum team to precompile the Blake2b hash function as an EVM-compatible opcode. The purpose of this proposal is to bridge Zcash and Ethereum, allowing users to trade between the two. Although this proposal was made two years ago, it has yet to be implemented, primarily due to the lack of corresponding cryptographic primitives, which has severely hindered the development of Layer1.

To address this issue, CKB has built a highly abstract virtual machine, the CKB-VM, which is distinctly different from the Bitcoin virtual machine and EVM. For example, Bitcoin has a dedicated OP_CHECKSIG opcode for verifying secp256k1 signatures in Bitcoin transactions. In CKB-VM, secp256k1 signatures do not require special handling; they can be verified using user-defined scripts or smart contracts.

CKB also uses secp256k1 as its default signature algorithm, but it runs in CKB-VM rather than as a hardcoded cryptographic primitive.

The intention behind building the virtual machine in CKB is that running cryptographic primitives in other virtual machines like EVM is very slow, so we aimed to improve this situation. Verifying a single secp256k1 signature in EVM takes about 9 milliseconds, while using the same algorithm in CKB-VM takes only 1 millisecond, which is nearly a tenfold efficiency improvement.

Thus, the value of CKB-VM lies in the fact that users can now customize cryptographic primitives within it, and the vast majority can be compatible with CKB-VM because CKB-VM adopts the RISC-V instruction set, allowing any language compiled by GCC (GNU Compiler Collection, a widely used compiler collection) to run on CKB.

Moreover, the high compatibility of CKB-VM also enhances the security of CKB. As developers often say, "Don't implement your own version of crypto algorithms; you will always do it wrong," defining cryptographic algorithms on your own often brings unforeseen security risks.

In summary, the CKB network uses various methods to address the three issues I raised that L1 networks face, which is why CKB can be considered a qualified Layer1 network.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。