Compiled 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, clearly proposing that modular blockchain will be the right direction, and also talks about the problem of blockchain data storage mechanism. At the same time, Jan also raised a very interesting topic: if the rise of Layer2 leads to Layer1 starvation, how to solve it.
As one of the earliest teams to support 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 rage 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 (Layer 2 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 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 is smaller, and its participants may only come from a certain country, 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 price to pay in exchange for other improvements, 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 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 "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 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. Adding business logic that caters to regulatory requirements directly at the Layer1 level may undermine its decentralization and neutrality, so the 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. 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.
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 fundamental reason for pursuing the security of Layer1 is that L1 is the root of the entire blockchain network and the anchor of the entire crypto-economic system.
Under this criterion, 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 serve as an L2 network, not to mention that some of its rules only apply to itself.
Problems with the current Layer1 network
After clarifying the definition of Layer1, we would like 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 commons problem of data storage
We need to pay certain fees when using blockchain, but in the economic model of Bitcoin, the fee structure design only considers the computing cost and network bandwidth cost, without maturely considering 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 up 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 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 storage rental system design to EIP-103, but we believe that 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 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 and the state size on CKB together. The space occupied by any one Cell cannot exceed its capacity limit, so the total amount of data will be kept 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 node operators. 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. Layer 1 starvation problem
If we expand on Layer2 and put a lot 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 ultimately the security of Layer1 will decrease. This is the so-called Layer1 starvation problem.
To take an extreme example, if we move all transaction activities to L2, then L1, which is its foundation, will not be sustainable. So how can we solve this problem?
To this end, we need to distinguish the types of users in the blockchain network. Simply put, they can be divided into Store of Value Users (SoV users) and Utility Users.
Still taking 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 the state. SoV Users are averse to the price dilution caused by CKB token inflation, while Utility Users must pay state storage fees to miners, 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 them to miners, which is equivalent to diluting the value of tokens in the hands of Utility Users (this is the "secondary issuance" of one of the three issuance modes in the CKB economic model. This method issues 1.344 billion CKB tokens every year. For details, please refer to (Interpretation of Stable++: RGB++ Layer's first stablecoin protocol officially launched)).
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 income that miners get from CKB inflation is actually only paid by Utility Users. We will soon release CKB's token economics paper, which will explain the relevant issues in detail.
Based on this token economic design, miners can get paid even if there is no transaction activity on the CKB chain, and 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 become a Layer 1 blockchain, you must consider how to interoperate with Layer 2. Some people in the Ethereum community have proposed using ZK or Plasma to implement Layer 2, but if there are no ZK-related primitives, how can you complete verification on Layer 1?
In addition, Layer1 also needs to consider interoperability with other Layer1s. Using Ethereum as an example, someone 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 can be verified by user-defined scripts or smart contracts.
CKB also uses secp256k1 as its default signature algorithm, but 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 time of a single secp256k1 signature in EVM is about 9 milliseconds, while the same algorithm is used in CKB-VM. It takes only 1 millisecond, which is nearly ten times the efficiency improvement.
Therefore, the value of CKB-VM lies in 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. 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 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 encryption 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, which is why CKB can be called a qualified Layer1 network.
