CKB联创Jan: What is the L1 starvation problem and how should L2 and L1 be designed?

Compilation: Fog Yue & White Ding, Geek web3

This article is a speech by Nervos co-founder Jan at the 2019 HBS Blockchain+Crypto Club Conference. The theme revolves around the relationship between Layer2 and Layer1, and clearly proposes that modular blockchain is the right direction. It also discusses the issue of blockchain data storage mechanism. At the same time, Jan also raised an interesting question: How to solve the problem if the rise of Layer2 leads to hunger in Layer1.

As one of the early supporters of Layer2 and modular blockchain narratives, Nervos’ proposition was forward-looking in 2018 and 2019. At that time, the ETH community still harbored unrealistic fantasies about Sharding, and the narrative of high-performance single-chain was also in a highly contentious state, yet to be fully disproved.

However, looking back at the problems exposed by ETH 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 five years ago were very foresighted. Out of interest in Layer2 itself, ‘Geek Web3’ has compiled Jan’s lecture into text form and published it here. Layer2 enthusiasts from the Nervos, ETH, and BTC communities are welcome to learn and discuss together.

The following is the original text of Jan’s lecture.

Definition of Layer1 and Layer2

This is my definition of L1 and L2 (Layer 2 network) as shown in the figure.

First of all, it is important to emphasize that Nerovs is simply a Block chain network striving to meet the needs of the Decentralization 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. The L1 network must have the most extensive Consensus, namely “global Consensus”. Through permissionless global Consensus, anyone in the world can participate in the Consensus process of L1, and ultimately Layer1 can serve as the “anchor” of the Decentralization economy. From this perspective, we can refer to L1 as the “Consensus layer”.

In contrast, the Consensus scope of the L2 network will be smaller, with participants possibly only coming from a single country, or a specific industry, or even a single company or institution, or a very small community. The sacrifice of the Consensus scope on L2 is a cost, in exchange for progress in other aspects, such as higher TPS, lower latency, and better scalability, etc. We can refer to L2 as the “protocol layer”, and connectivity between L1 and L2 is often achieved through cross-chain bridges.

It must be emphasized that our purpose in building the L2 network is not only to solve the scalability problem of the blockchain, but also because the layered architecture is the easiest way to implement the modular blockchain. The so-called modular blockchain refers to solving different types of problems by putting them into different modules.

Many people have been discussing the Compliance and regulatory issues of blockchain, so how do we incorporate BTC or ETH into the existing regulatory framework? Layered architecture may be one answer to solve this problem. Adding business logic that meets regulatory requirements directly at the Layer1 level may compromise its Decentralization and neutrality, so the logic related to Compliance can be implemented separately on Layer2.

Layer2 can be customized according to specific regulations or standards, such as establishing a permissioned small-scale blockchain or a State Channels network. This achieves compliance without affecting the Decentralization and neutrality of Layer1.

In addition, we can also solve the conflict between security and user experience through a layered architecture. By analogy, if you want to ensure the security of your Private Key, you have to sacrifice some convenience, and the blockchain is the same. If you want to ensure the absolute security of the blockchain, you have to sacrifice something, such as the performance of the chain, etc.

But if we use a layered architecture, we can pursue security completely on the L1 network, while sacrificing a little security on the L2 network for a better user experience. For example, we can use State Channels on L2 to optimize network performance, drop latency. So, the design of Layer2 is nothing more than a balance between security and user experience.

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

The answer is negative. First and foremost, we must be clear that Decentralization and security of Layer1 networks are paramount, because we must achieve resistance to censorship through Decentralization. The pursuit of security in Layer1, fundamentally, is because L1 is the root of the entire blockchain network and the anchor of the entire encryption economic system.

Under such criteria, Bitcoin and Ethereum are undoubtedly the most classic L1 networks with strong Consensus. Apart from these two, most blockchains do not meet the L1 standard and have lower Consensus. For example, EOS’ Consensus falls short and can only serve as an L2 network. Moreover, some of its rules only apply to itself.

Current issues with the Layer1 network

After defining the concept of Layer1, we need to point out that some existing L1 networks have three issues, which certainly exist to some extent even in the BTC and ETH communities:

1. The Tragedy of the Commons in Data Storage

When we use the Block chain, we need to pay a certain fee, but in the BTC economic model, the fee structure design only considers the cost of computation and network bandwidth, without maturely considering the cost of data storage.

For example, users only need to pay a one-time fee to store data on-chain, but the storage period is permanent, so people can abuse storage resources and permanently put anything on the chain. As a result, the full nodes in the network will bear increasingly high storage costs. This brings a problem: any node operator who wants to participate in the cost of the network will be maximally increased.

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

The ETH Foundation has realized the above issues, and therefore incorporated the design of storage leasing system in EIP-103. However, we believe this is not the optimal solution.

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

In this way, we bind the quantity and status 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 be kept within a certain range.

And we ensure that the size of state data will not interfere with Node operators through a more appropriate Token inflation rate. Anyone can participate in the CKB network, they can verify historical data, and they can also verify whether the final state is valid, which is the solution proposed by CKB for the storage problem in the Block chain.

2. Layer1 Hunger Issue

If we expand on Layer2 and move a large amount of trading activity to Layer2, it will inevitably lead to a drop in the number of transactions on Layer1, and the corresponding drop in economic rewards for Layer1 Miners/Nodes. In this case, the enthusiasm of Layer1 Miners/Node operators will decrease, ultimately leading to a decrease in the security of Layer1. This is the so-called Layer1 starvation problem.

Take an extreme example, If we move all trading 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 the types of users in the blockchain network, which can be simply divided into Store of Value Users (SoV user, value storage user) and Utility Users (application users).

Using CKB as an example, SoV Users use the native asset CKB Token as a means of value storage, while Utility Users use Cells to store states. SoV Users are opposed to the price dilution caused by CKB Token inflation, while Utility Users must pay storage fees to Miners, which are proportional to the duration and space occupied by the data storage.

We will continue to issue new CKB Tokens in the network to create a fixed inflation rate and pay it to Miners, which is equivalent to diluting the value of Tokens in the hands of Utility Users (This is one of the three issuance modes in the CKB economic model, known as the “secondary issuance”, which issues 1.344 billion CKB Tokens annually. For more details, please refer to “Interpreting Stable++: The first stablecoin protocol of RGB++ Layer officially sets sail”).

In this process, the assets of SoV users are also diluted, so we can give them a certain subsidy to offset the inflation loss (which is later NervosDAO split). That is to say, the income obtained by Miners from CKB inflation is actually paid only by Utility Users. Soon we will issue a Token Economics paper on issuance CKB, and the relevant issues will be explained in detail.

Based on such a tokenomics design, even if there is no transaction activity on the CKB chain, Miners can still receive rewards, and thus we can be compatible with any “value storage layer” or Layer2. In summary, we solve the Layer1 starvation problem through intentional fixed inflation.

3. Lack of encryption primitives

Users need different encryption primitives to use different encryption methods or different Signature Algorithm, such as Schnorr, BLS, etc.

To become a Layer1 blockchain, one must consider how to interact with Layer2. Some people in the Ethereum community have proposed using ZK or Plasma to achieve Layer2, but if there are no ZK-related primitives, how do you perform verification on Layer1?

Additionally, **Layer1 also needs to consider interoperability with other Layer1s. Taking Ethereum as an example, there have been requests for the Ethereum team to precompile the Blake2b hashing function into EVM-compatible opcodes. The purpose of this proposal is to bridge Zcash and Ethereum to enable users to transact between the two. Although the above proposal was put forward two years ago, it has not been implemented yet due to the lack of corresponding encryption primitives, which has severely hindered the development of Layer1.

To address this issue, CKB has built a highly abstract Virtual Machine, known as CKB-VM, which is quite different from BTC’s Virtual Machine and EVM. For example, BTC has a dedicated OP_CHECKSIG opcode for verifying secp256k1 signatures in BTC transactions. In CKB-VM, however, secp256k1 signatures do not require special handling and can be verified with user-defined scripts or smart contracts.

CKB also uses secp256k1 as its default Signature Algorithm, just running in CKB-VM instead of being hard-coded encryption primitive.

The original intention of CKB building the Virtual Machine is to improve the slow execution of encryption primitives in other Virtual Machines such as EVM. The verification time for a single secp256k1 signature in EVM is about 9 milliseconds, while using the same algorithm for computation in CKB-VM only takes 1 millisecond, which is nearly ten times more efficient.

So the value of CKB-VM is that users can now customize encryption primitives in it, and the majority of them can be compatible with CKB-VM because CKB-VM adopts the RISC-V instruction set. Any language compiled by GCC (GNU Compiler Collection, a widely used compiler collection) can run on CKB.

In addition, the high compatibility of CKB-VM also enhances the security of CKB. As developers always say, “Don’t implement your own version of crypto algorithms, you will always do it wrong”, defining Encryption Algorithm on your own often brings unforeseeable security risks.

In summary, the CKB network has addressed the three problems faced by the L1 network I identified using various methods, which is why CKB can be called a qualified Layer1 network.