Compiled by: Wuyue & Bai Ding, Geek web3
This article is based on the speech delivered by Nervos co-founder Jan at the 2019 HBS Blockchain+Crypto Club Conference, focusing on the relationship between Layer2 and Layer1, clearly proposing that modular blockchain will be the right direction, and also discussing the issue of blockchain data storage mechanism. At the same time, Jan also raised an interesting topic: if the rise of Layer2 leads to the starvation of Layer1, how to solve it.
As one of the earliest teams to support the narrative of Layer2 and modular blockchain, Nervos' proposition was quite forward-looking in 2018 and 2019, when the Ethereum community still had unrealistic fantasies about sharding, and the narrative of high-performance monolithic chains was also in full swing, not yet fully refuted.
But in 2024, looking back at the problems exposed by Ethereum Layer2 in practice, as well as the drawbacks of "high-performance public chains" represented by Solana in terms of decentralization and trustlessness, Jan's views from 5 years ago seem to have been quite insightful. Out of interest in Layer2 itself, "Geek web3" has compiled Jan's lecture into a text version and published it here, welcome Nervos, Ethereum and Bitcoin community Layer2 enthusiasts 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 (second layer network), as shown in the figure.
First of all, it must be emphasized that Nervos 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. L1 network must have the most extensive consensus, that is, "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 decentralized economy. From this perspective, we can call L1 the "Consensus Layer".
In comparison, the consensus scope of L2 network will be a little 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. The sacrifice of L2 in the scope of consensus is a kind of cost, in exchange for progress in other aspects, 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 our purpose of building L2 network is not just to solve the scalability problem of blockchain, but because a 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 to solve.
Many people have been discussing the compliance and regulation 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 meets regulatory requirements at the Layer1 level may undermine its decentralization and neutrality, so compliance-related logic can be implemented separately at Layer2.
Layer2 can be customized according to specific laws or standards, such as establishing a small permissioned blockchain or state channel network. In this way, compliance is achieved 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 a certain degree of convenience, and it is the same with blockchain. If you want to ensure the absolute security of the blockchain, you have to sacrifice something, such as its performance.
But if we use a layered architecture, we can fully pursue security on the L1 network, while sacrificing a little security on the L2 network to obtain better user experience. For example, we can use state channels on L2 to optimize network performance and reduce latency. So, the design of Layer2 is essentially 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, we must be clear that the decentralization and security of Layer1 network are above all else, because we must achieve censorship resistance through decentralization. The pursuit of Layer1 security is fundamentally because L1 is the root of the entire blockchain network, the anchor of the entire crypto-economic system.
Under this evaluation criteria, Bitcoin and Ethereum are undoubtedly the most classic L1 networks, with extremely strong consensus range. Except for these two, most blockchains do not meet the standard of L1, with relatively low consensus. For example, the consensus of EOS does not meet the standard, so it can only serve as an L2 network, let alone its some rules only apply to itself.
Current problems of Layer1 networks
After clarifying the definition of Layer1, we need to 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 data storage commons
When we use blockchain, we need to pay a certain fee, but in the economic model of Bitcoin, the fee structure design only considers the computational cost and network bandwidth cost, and does not mature the consideration of data storage cost.
For example, users only need to pay a one-time fee to store data on the chain, but the storage period is permanent, so people can abuse the storage resources and permanently store anything on the chain, ultimately causing the full nodes in the network to bear increasingly high storage costs. This brings a problem: the cost for any node operator to participate in the network will be maximized.
Suppose the total state/account data of a certain blockchain exceeds 1TB, then not everyone can easily synchronize the complete state and transaction history. In this case, even if you can synchronize 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 the core value of blockchain.
The Ethereum Foundation is aware of the above problem, and has included the design of a storage leasing system in EIP-103, but we believe this is not the optimal solution.
We have proposed a new state model called "Cell" in Nervos, 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 in Cell you can store any type of data, and the amount and integer value of Bitcoin UTXO are generalized into "Capacity" to specify the maximum storage capacity of the Cell.
In this way, we have bound the quantity of native assets on CKB and the size of the state together. No Cell can occupy more space than its capacity limit, so the total data volume will be kept within a certain range.
And we ensure that the size of the state data will not interfere with the operation of nodes through a relatively appropriate token inflation rate. Anyone can participate in the CKB network, they can verify the historical data, and they can also verify whether the final state is valid, which is the solution proposed by CKB to the storage problem in the blockchain.
2. The Layer1 starvation problem
If we expand on Layer2 and move a large amount of transaction activity 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 also decrease accordingly. In this way, the enthusiasm of Layer1 miners/node operators will decline, ultimately leading to a decline in the security of Layer1. This is the so-called Layer1 starvation problem.
Take an extreme example, if we move all transaction activity to L2, then the L1 that serves as its foundation will not be sustainable. So how can we solve this problem?
For this, we need to distinguish what types of users there are in the blockchain network, simply put, they can be 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 use Cells to store state. SoV Users are averse to the price dilution caused by CKB token inflation, while Utility Users must pay the state storage fee to miners, which is proportional to the duration and occupied space of the data storage.
We will continue to issue new CKB tokens in the network to create a fixed inflation rate, and pay them to the miners, which is equivalent to diluting the token value held by Utility Users (this is the "secondary issuance" of the three issuance modes in the CKB economic model, which issues 1.344 billion CKB tokens annually, the details of which can be found in the article "Interpreting Stable++: The First Stable Coin Protocol of RGB++ Layer is Officially Launched").
In this process, the assets of SoV users are also diluted, so we can give them certain subsidies to offset the inflation loss (this is the later NervosDAO distribution). In other words, the profits that miners obtain from CKB inflation are actually paid by Utility Users. We will soon release the CKB token economic whitepaper, where relevant issues will be explained in detail.
Based on this token economic design, even if there is no transaction activity on the CKB chain, miners can still get rewards, so we can be compatible with any "value storage layer" or Layer2.
3. Lack of Cryptographic Primitives
Users need different cryptographic primitives to use different encryption methods or different signature algorithms, such as Schnorr, BLS, etc.
To become a Layer1 blockchain, you must consider how to interoperate with Layer2. Some people in the Ethereum community have proposed using ZK or Plasma to implement Layer2, but if there are no ZK-related primitives, how can you complete the verification on Layer1?
In addition, Layer1 also needs to consider interoperability with other Layer1s. Still using Ethereum as an example, some people have asked the Ethereum team to pre-compile the Blake2b hash function into an EVM-compatible opcode. The purpose of this proposal is to bridge Zcash and Ethereum, so that users can trade between the two. Although this proposal was made two years ago, it has not been realized until now, the reason for which is the lack of corresponding cryptographic primitives, which has seriously hindered the development of Layer1.
To solve this problem, CKB has 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 handling, users can simply use their own scripts or smart contracts to perform the verification.
CKB also uses secp256k1 as its default signature algorithm, but it runs in the CKB-VM, rather than as a hardcoded cryptographic primitive.
The original intention of CKB to build a virtual machine is that running cryptographic primitives in EVM and other virtual machines is very slow, so it needs to be improved. A single secp256k1 signature verification in EVM takes about 9 milliseconds, while using the same algorithm in CKB-VM, it only takes 1 millisecond, which is nearly a tenfold efficiency improvement.
So the value of CKB-VM lies in the fact that now users can customize cryptographic primitives in it, and most of them can be compatible with CKB-VM, because CKB-VM adopts the RISC-V instruction set, and 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 the developers always say, "Don't implement your own version of crypto algorithms, you will always do it wrong", defining your own encryption algorithms often brings unpredictable security risks.
In summary, the CKB network uses various methods to solve the three problems I have raised for L1 networks, which is why CKB can be called a qualified Layer1 network.
