CKB co-founder Jan: What is L1 starvation problem? How to design L2 and L1

Translated by: Wu Yue & Bai 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 states that modular blockchain will be the right direction. He also talked about the issue of blockchain data storage mechanism. At the same time, Jan also raised a very interesting topic: How to solve the problem if the rise of Layer2 leads to Layer1 starvation.

As one of the earliest teams to support the Layer2 and modular blockchain narratives, Nervos's proposition was quite forward-looking in 2018 and 2019. At that time, the Ethereum community still had unrealistic fantasies about sharding, and the narrative of high-performance monolithic chains was also in a state of clamor and had not yet been fully falsified.

But today in 2024, looking back at the problems exposed by Ethereum Layer2 in practice, and the drawbacks of "high-performance public chains" represented by Solana in terms of decentralization and trustlessness, we have to say that Jan's views five years ago were very prescient. Out of interest in Layer2 itself, "Geek Web3" compiled Jan's lecture in a text version and published it here. Layer2 enthusiasts from Nervos, Ethereum, and Bitcoin communities are welcome to study 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 (second-layer network), as shown in the figure.

First of all, it should be emphasized that Nerovs is just a blockchain network that strives to meet the needs 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. The L1 network must have the broadest consensus, that is, "global consensus". Through a permissionless global consensus, anyone in the world can participate in the L1 consensus process, and ultimately Layer1 can serve as the "anchor" of the decentralized economy. From this perspective, we can call L1 the "consensus layer".

In contrast, the consensus scope of the L2 network will be smaller, and its participants may only come from a certain country, or a certain industry, or even a certain company or institution, or a very small community. L2's sacrifice in the scope of consensus is a price in exchange for progress in other areas, such as higher TPS, lower latency, and better scalability. We can call L2 the "protocol layer", and L1 and L2 are often connected through cross-chain bridges.

It must be emphasized that the purpose of building an L2 network is not only to solve the scalability problem of blockchain, but because the layered architecture is the easiest way to implement "modular blockchain". The so-called modular blockchain is to put different types of problems into different modules for solution.

Many people have been discussing the compliance and regulatory issues of blockchain, so how can we incorporate Bitcoin or Ethereum into the existing regulatory framework? Layered architecture may be an answer to this problem. Directly adding business logic that caters to regulatory requirements at the Layer1 level may undermine 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 building a small blockchain based on a permission system, or a state channel network, etc. This achieves compliance without affecting the decentralization and neutrality of Layer1.

In addition, we can also resolve 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 a certain degree of convenience, and the same is true for blockchain. If you want to ensure the absolute security of the blockchain, you have to sacrifice some things, such as the performance of the chain, etc.

But if we use a layered architecture, we can pursue security completely on the L1 network, and sacrifice 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 nothing more than a trade-off between security and user experience.

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

The answer is no. First of all, we must make it clear that the decentralization and security of the Layer1 network are above all else, because we must achieve anti-censorship through decentralization. The pursuit of Layer1 security is fundamentally because L1 is the root of the entire blockchain network and the anchor of the entire crypto-economic system.

Under such criteria, Bitcoin and Ethereum are undoubtedly the most classic L1 networks, which have a very strong consensus range. Apart from these two, most blockchains do not meet the L1 standard and have a low degree of consensus. For example, EOS's consensus does not meet the standard and can only act as an L2 network, not to mention that some of its rules only apply to itself.

Problems with current Layer1 networks

After clarifying the definition of Layer1, we should point out that some existing L1 networks have three problems, which exist to a certain extent even in Bitcoin and Ethereum:

1. The tragedy of the commons problem of data storage

We need to pay a certain fee when using blockchain, but in Bitcoin's economic model, the fee structure design only considers the computing cost and network bandwidth cost, and does not maturely consider the data storage cost.

For example, users only need to pay once to store data on the chain, but the storage period is permanent, so people can abuse storage resources and put everything on the chain permanently, and eventually all nodes in the network will have to bear higher and higher storage costs. This brings a problem: the cost for any node operator to participate in the network will be maximized.

Assuming that the state/account data of a blockchain exceeds 1TB in total, 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 verify the corresponding transaction history by yourself, which will weaken the trustlessness of the blockchain, and trustlessness is precisely the core value of the blockchain.

The Ethereum Foundation is aware of the above problems and has added a design for storage leasing in EIP-103, but we believe that this is not the best 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 value of Bitcoin, while Cell can store any type of data, and generalize the amount and integer value of Bitcoin UTXO to "Capacity" to specify the maximum storage capacity of Cell.

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

And we use a more appropriate token inflation rate to ensure that the size of the state data does not interfere with the node operator. Anyone can participate in the CKB network, they can verify historical data, and they can also verify whether the final state is valid. This is CKB's solution to the storage problem in the blockchain.

2. Layer1 starvation problem

If we expand on Layer2 and put a large number of transaction activities on Layer2, it will inevitably lead to a decrease in the number of transactions on Layer1, and the economic rewards of Layer1 miners/node operators will also decrease accordingly. In this case, the enthusiasm of Layer1 miners/node operators will decrease, and eventually the security of Layer1 will decrease. This is the so-called Layer1 starvation problem.

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

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

Take CKB as an example. SoV Users use the native asset CKB token as a means of value storage, while Utility Users use Cell to store status. SoV Users are averse 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 and space occupied by 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 the tokens in the hands of Utility Users (this is the "secondary issuance" of one of the three issuance modes in the CKB economic model, which issues 1.344 billion CKB tokens every year. For details, please refer to "Interpretation of Stable++: RGB++ Layer's First Stablecoin Protocol Officially Set 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 (this is the later NervosDAO share). In other words, the benefits that miners get from CKB inflation are actually only paid by Utility Users. We will soon issue a CKB token economic paper, in which related issues will be explained in detail.

Based on such a token economic design, miners can get paid even if there is no transaction activity on the CKB chain, and then we can be compatible with any "value storage layer" or Layer2. In summary, we solve the Layer1 hunger problem through intentional fixed inflation.

3. Lack of cryptographic primitives

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

If you want to be a Layer1 blockchain, you must consider how to interoperate with Layer2. Some people in the Ethereum community have proposed to use ZK or Plasma to implement Layer2, but if there are no ZK-related primitives, how can you complete verification on Layer1?

In addition, Layer1 also needs to consider interoperability with other Layer1s. Using Ethereum as an example, some people asked the Ethereum team to precompile the Blake2b hash function into EVM-compatible opcodes. The purpose of this proposal is to bridge Zcash and Ethereum so that users can trade between the two. Although the above proposal was proposed two years ago, it has not been implemented until now. The reason is the lack of corresponding cryptographic primitives, which has seriously hindered the development of Layer1.

To solve this problem, CKB built a highly abstract virtual machine, CKB-VM, which is completely 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 processing, and only user-defined scripts or smart contracts are required for verification.

CKB also uses secp256k1 as its default signature algorithm, but it runs in CKB-VM instead of as a hard-coded cryptographic primitive.

The original intention of CKB to build a virtual machine is that running cryptographic primitives in other virtual machines such as EVM is very slow, so this situation needs to be improved. The verification of a single secp256k1 signature in EVM takes about 9 milliseconds, while using the same algorithm to calculate in CKB-VM, it takes only 1 millisecond, which is nearly ten times the efficiency improvement.

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

In addition, the high compatibility of CKB-VM also improves the security of CKB. As developers always say, "Don't implement your own version of crypto algorithms, you will always do it wrong", self-defined cryptographic algorithms often bring unforeseen security risks.

To sum up, the CKB network uses various methods to solve the three problems faced by the L1 network that I mentioned. This is why CKB can be called a qualified Layer 1 network.