Jan: First of all, protocol upgrade is unavoidable. Upgrades are often required for nearly all software projects, because you can’t predict all requirements at the beginning. When the need changes, the software must adapt as well. blockchain is also the same.
Secondly, Nervos Network is a brand-new design. Only 60% of the variables were known at the start, with the remaining 40% was groping. On the one hand, it is difficult for us to predict how developers will use it in the future. In fact, many developers who build applications on the Nervos mainnet after launch, told us some unreasonable designs. When we receive enough feedback from developers, we need to make an adjustment. On the other hand, we are very clear that the mainnet launch is only the first step. There is still a long list of things to be done in the future, and those more advanced and complex features need to be done step by step via major protocol upgrades.
Jan: OK, I will introduce the hard fork of CKB. But first of all, we need to understand that CKB is very different from many other blockchain projects. Some confusions arise because of misunderstandings about Nervos and CKB, so the first step is to clarify these.
Nervos CKB is the extended Bitcoin in terms of design and notion. Nervos CKB chooses to use PoW when PoS prevails. The consensus algorithm of CKB is the optimized Nakamoto Consensus instead of BFT-style consensus. Nervos’ Cell model is the extended UTXO model. All of these choices are made consciously, not an unconscious patchwork.
Bitcoin is now regarded as a store of value (SoV) by the majority in the cripto industry, so it needs to be very secure, and we’d rather it stay the same for everything. Therefore, Bitcoin is very conservative in its technical development. CKB seeks to extend the idea of SoV, from a store of value (SoV) to a store of multiple assets (SoA), where you can store all kinds of assets on the chain with confidence. The implementation of a store of value requires appropriate choices and is not a natural thing.
Meanwhile, the usability of Bitcoin is excellent. To put it simply, we haven’t seen the downtime of Bitcoin, but many new blockchains nowadays often come across outages due to a bug or due to upgrades. In my eyes, these new blockchains are not the same as Bitcoin. They are more similar to Internet services or cloud databases. Bitcoin is not like that at all. Of course, no one can guarantee that Bitcoin will never shut down for 10,000 years. After all, it is built by human beings, and it may have bugs. But its concept is very clear — ensure that it won’t shut down due to small changes or upgrades. Bitcoin has run smoothly for more than ten years without any outages, and time is the best proof of Bitcoin’s design. In contrast, many new blockchains have experienced several outages in the past one or two years. This is why I say they are different things from Bitcoin, and they just happen to be called “public chain”, a name with a vague definition.
CKB seeks to go from SoV to SoA on the basis of Bitcoin. In addition to ensuring that the degree of decentralization remains unchanged and that the liveness (maintaining the network to run smoothly) is good enough, CKB also needs to have more, otherwise it is Litecoin. However, the extension also needs to have continuity, and we cannot change from UTXO to an Account model like Ethereum. That said, we still need to make layer 1 more powerful, more flexible and a bit more powerful. If Bitcoin is from 0 to 1, then Ethereum is from 1 to 10, and some later blockchains want to go from 10 to 20, or even 100. For CKB, it wants to go from 1 to 5, which sounds a bit counterintuitive: Ethereum has gone from 1 to 10, and CKB is only to reach 5, then CKB is not as good as Ethereum? It is important to understand that technological development can go in many directions. If Ethereum goes from 1 to 10 along the X axis, Nervos can be said to go from 1 to 5 along the X/Y axis at the same time. Layer 1 with PoW and UTXO model, and layer 2 with PoS and Account model, are annotations to what I said.
As a layered network, Nervos as a whole aims to go from 1 to 100, while the core layer CKB should remain the most simplified state. Because the more features you add to the network, the more bloated it will become, and too much code will be vulnerable to flaws. But if Nervos CKB doesn’t go far enough, it will end up like Bitcoin — hard to make a change, impossible to construct a layer 2 network, and difficult to support other assets. Therefore, what we need is to find a balance. We can’t go too far, or not far enough. We need to find a balance, where we can create layer 2 networks on layer 1, and layer 3 networks on layer 2. With layered networks, Nervos can go from 1 to 100. This is the distinction between Nervos and many other blockchains. So you can think of CKB as a kernel that makes extensions of Bitcoin. Just like the Windows operating system, it has a kernel; if you use a Linux system, it also has a kernel; so does the Apple iOS. Kernels are very small. The application you use is not the kernel. Applications are on the upper layers of the kernel. There is also an intermediate layer between the application and the kernel, which is called a library in the system.
CKB, in fact, is more focused on the kernel, like the engine of the car or aircraft. This is the positioning of CKB. So in terms of positioning and design, CKB may be far away from ordinary users or even application developers. This is actually very similar to Bitcoin. If you pay attention to the difference between the ecosystem of Bitcoin and Ethereum, you will notice that Ethereum developers are hipsters, as they can create100 applications in a short time. For Bitcoin developers, it may take two years to create an application, and a paper may be issued before they start to work on the application. So the two communities are very different. CKB is closer to the Bitcoin community. Building applications directly on CKB is similar to system-level programming, not front-end programming. These are two very different platforms with different positioning and designs.
To say so much is to answer the question, “How much of this upgrade can be perceived by users?” This is a tough question to answer.
The protocol upgrade itself is far away from users. You may not directly perceive, but will indirectly notice the improvements. Because there are first or second layer developers in the middle, absorbing the underlying changes into their Apps, tools, and libraries. As a result, users will notice improvements when they use the applications. The protocol upgrade can be interpreted as an operating system upgrade, and improvements of applications may lag for a short period of time.
Next, let’s talk about features and major changes of this upgrade.
CKB VMblock structureconsensus rulesP2P protocol.
Changes in consensus rules and P2P protocol have nothing to do with ordinary users. The improvements of consensus rules are to solve some poorly defined rules or bugs.
An important part of consensus rules, which is especially useful to developers, can be found on RFC0036.
If you want to refer to the data of the block header of previous blocks in your contract, before this hard fork, you can only refer to blocks 4 epochs (about 16 hours) ago. After the hard fork, you can refer to the data of the previous block, or even the data of any block on the chain. This is a huge difference for developers who write contracts for many applications. Because they can get the latest information on the CKB chain in the contract when the contract is running, which will improve user experiences.
As a user, you may not know why you have to wait so long when you are using an application. When the major protocol is completed, you may not need to wait so long. Because after the hard fork, the application doesn’t need to wait 16 hours until the block becomes mature. UniPass and .bit have encountered this problem in my memory.
So why is it designed to wait 4 epochs in the first place? This is actually a design that has been tangled for a long time.
Some of you may know the block maturation time. In the Bitcoin system, newly mined coins have to wait a maturity period of 100 blocks before you can spend them. Why? Because if you spend them right away, there is a possibility that the transactions are in an orphan block, which is invalid. In other words, if you allow those coins to be spent right away, all subsequent transactions that rely on the newly mined coins will have to be rolled back, which will cause huge trouble for users and will lead to some very strange consequences .
For the same reason, we added a restriction to newly mined CKB coins. The restriction has something to do with the balance between security and ease of use. Do we want to be safe or easy to use, and do we want to be consistent with Bitcoin or consistent with Ethereum? Ethereum and other blockchains don’t think about this at all. In terms of design, it is difficult for us to find the balance. So we had a long discussion, and community developers told us their requirements when they encountered this problem. The final conclusion is that we will lower the limitation of reference of block header so that you don’t need to wait 4 epochs anymore, although there are still some other restrictions.
This is a very typical example. We need to find a balance between Bitcoin and Ethereum. Nervos CKB doesn’t want to become Ethereum or other blockchains — move fast and break things; nor to become as stagnant and rigid as Bitcoin and very difficult to move forward. This is the part where the rules of the consensus layer change.
The most important part of the Major Protocol Upgrade is the virtual machine (VM).
There are 3 RFCs about VM: 0032, 0033, 0034.
Let’s talk about RFC0032 first. It introduces the concept of VM’s version. This is a very interesting thing. I haven’t seen other blockchains whose VM has a version. CKB may be the first one. Previously, Ethereum used to discuss the introduction of the EVM version, but found that there were various problems, so it was abandoned.
So why is CKB doing this? There are practical reasons.
First of all, CKB’s VM is the instruction set of RISC-V. RISC-V is an instruction standard that has been widely used and evolving rapidly in the industry. We have to follow its standard. The standard of RISC-V will be constantly updated, so if we don’t follow it, it will be incompatible with the specification and benefits from compatibility will be lost. Therefore, CKB-VM must also be able to upgrade and follow the newest standard of RISC-V.
Secondly, as I’ve said, CKB seeks to become a store of value (SoV), the same as Bitcoin. Users need to make sure that the assets they stored on blockchain today will always be theirs decades later or even a hundred years later. This is a very important thing to a blockchain that wants to be a store of value.
This is a very natural and very righteous demand. It sounds not difficult, but in fact it is not so easy to achieve. Why? How can you ensure that the blockchain upgrade will not change the previous contracts or the logic of accounts? Are you sure that your assets will still belong to you no matter what future upgrades are made? This is an issue worth debating and discussing because the meaning of a piece of code or a contract is determined by two things: the code or data itself and the “container” that interprets the code or interprets the data. The blockchain is the container that explains the code, and the contracts and assets stored on the blockchain are all data. The blockchain upgrade will not change the data on the chain, but will modify the container that interprets the data, which may change the meaning of a certain piece of code or contract, and therefore may affect the ownership of certain assets.
For Bitcoin, it easily avoids this problem. It never makes a hard fork, so to some extent the problem doesn’t exist. Whether or not to make a hard fork is determined by community consensus. If a hard fork is needed, as we said earlier we need to upgrade the VM, how do we guarantee that the contract will not be changed by the upgrade? The goal we want to achieve is to ensure that even if CKB keeps upgrading, the asset you stored on the chain today will still be yours decades or 100 years later. This is a plain description, and the implementation is not as simple as it seems.
A well-known example is The DAO in Ethereum. The hard fork was made to fix The DAO after voting and to deprive the hacker’s assets. At that time, the hacker stole ETH in the DAO, so the community formed a consensus through an informal governance process, and finally decided to make a hard fork to directly change the data on the chain and get the assets back. This is actually not the same as the example I mentioned, because what Ethereum did at that time was to change the data directly.
In fact, there is another (possibly smarter) way to do it without changing the data. That is to change the interpreter which interprets the data. We can keep adding new explanations.
So again, if we want to upgrade the VM, we are actually facing such a conflict. On the one hand, we need to upgrade the VM, and on the other hand, we don’t want to give too much power to the developers, because once they have this power, they may end up with a VM that can be modified arbitrarily, leading to changes in the semantics of the previous code/contract. This possibility will undermine people’s confidence in whether this chain can become SoV.
So how to do it?
CKB has found an ingenious solution. CKB has a feature that most users may not know, but developers are very clear about it. When referencing a smart contract on CKB, there are two ways. One is through the type id that you can regard it as the address of the smart contract, just like the contract address of Ethereum. Another way is through the code hash of the contract, that is, we use the hash calculated by the code to refer to this contract.
Next, what is RFC0032 about? RFC0032 says that if you refer to the contract by type id or address, when the contract is running, it will be automatically upgraded to the VM V1 after the hard fork, and the new VM will be used to implement. Why? Because you use the address to refer to the contract, this behavior means that you have given the contract interpretation right to the developer of the contract, as the type id is the same as the address. As a name, type id has nothing to do with the intrinsic properties of the contract itself. Contracts referenced by name can keep changing, just like you keep growing up, from 3 to 12 while your name is still the same. As you get older, many internal changes happen inside your body. “It’s just a name, and it can be changed internally.” This is what the choice itself means when you make the choice to refer to a contract with an address or type id.
Another way is that you refer to it through the hash of the contract code. At this point you mean: “I don’t want the referenced object to change at any time, I want to get the same result forever.” I want to run this contract in my current VM under the interpretation rules. I know you may upgrade in the future, but I don’t care. Even if you do 100 upgrades, I still hope to use the code and the VM I write when I send transactions to execute this contract, and I want to get the same result.
In this case, you are not using a name or type id, you have specified a piece of code very clearly and the corresponding execution environment version, and you have specified a semantics very clearly. If you refer to the contract in this way, the execution result of your contract will not change after the hard fork. Your contract will still be executed with the version of the VM before the hard fork. This ensures that no matter how the hard fork is made, your contract will still be the same.
Therefore, CKB leaves the choice to users and developers:
Want to gain the benefits of automatic upgrades, while being willing to give up some semantic changes;Not willing to accept that the semantics have changed without your consent, preferring to forgo the benefits of automatic upgrades and upgrade them yourself if needed.
This is the problem solved by RFC0032. In short, it implements a model of multi-version virtual machines, which simultaneously solves the technical challenges of coexistence of various multi-version virtual machines while ensuring the semantics of SoV. This is a very big change. I haven’t seen other blockchains implement this. Most chains probably don’t care or have no way to solve this problem, as they just upgrade the VM. Users of these chains are actually giving up some rights, either intentionally or unintentionally, which is not the case with CKB. This is the first big change to the VM.
The second big change to the VM is written in RFC0033. It specifies the virtual machine version, which includes all the changes, fixed bugs, redesigns of internal instruction format. To interpret RISC-V instructors, there are actually many internal approaches.
There are also some new changes made from the VM level for the convenience of debugging for system developers and contract developers on CKB. There are also changes to improve performance, such as Lazy initialization memory, MOP.
The most notable thing is that, in order to better implement and improve the ability to interpret cryptographic primitives, the new VM version introduces a RISC-V Extension for the first time. RISC-V has a bunch of core instruction sets, and it also has many extension packages. The new version of CKB VM is the first to introduce an extension package, which proves the feasibility. Moreover, it happens to work with multi-version virtual machine architectures.
The extension package we introduced this time is B Extension. It is an extended instruction for the calculation of large numbers, with only 4 instructions. Of course, it verifies that the design and model are feasible. We also use the B Extension to optimize some cryptography and it indeed will bring a performance improvement. More extended directives will be introduced in the next hard fork. In this hard fork, we will make a small improvement, and then verify the results. If successful, we can make a bigger change in the next hard fork — adding RVV (RISC-V Vector).
The performance improvement that RISC-V Vector brings to cryptographic primitives will be much greater. If B Extension brings improvement of 10% to 20%, then RISC-V Vector is likely to bring performance improvement for multiple times. The difference will be very huge.
If the VM version in RFC0033 proves that all the above is possible, then we will follow previous methods. There will be differences in the workload, as the B Extension has only 4 instructions, while RVV has about 200 instructions.
That is the second major change in CKB-VM.
The third major change in the VM is written in RFC0034, which introduces a new syscall (system call) and adds 3 new syscalls, the most important of which is the one called exec. If you think of CKB as a kernel, exec is the same as exec in Unix.
So, what does it mean to use exec in CKB? In fact, it is to allow a contract to refer to another contract during the execution process through the reference of the contract address or the hash, and then to execute. In other words, replace the code executed by the current process with the code of another contract.
Why is it useful? It enhances the combinability of contracts. I now have 3 contracts — A, B and C. We can use contract D to run contract A, B and C together. Therefore, we can change the previous lock script to a module, and then use exec to call these modules, such as signature algorithm A, signature algorithm B, signature count C, and then add some business logic. Writing such a function is not very convenient, but after the upgrade, it will be very easy. There are also dynamic link libraries and other methods that are a bit lacking in ease of use and security. The hard fork has taken combinability one step further. This is the outcome we made with feedback from the community in the past two years.
Above are the changes to the VM.
Another major change of this hard fork is the block structure. In fact, the block structure doesn’t have many specific changes at the code level. Only a new field named extension is introduced and added to the block structure, which will increase the scalability of CKB in the future.
This extension is an optional field that can store up to 96 bytes of data. With this extensible field, we will lay a foundation for a light node client. As the light node protocol needs to be added to the CKB protocol, the block producer needs to do some additional calculations during consensus, and then store the calculation results somewhere. If there is no such extension field, the auxiliary data and the data that is very useful for the light node protocol, cannot find a place to store it.
Before this solution was implemented, we thought of many ways to solve the problem, including the possibility of reusing the existing fields, and found that none of them worked, so we finally reluctantly added a field to it. With this field, it will bring better scalability, not only for light node protocols, but also for more protocol-level improvements that require some data to be added to the block in the future. So it can meet the needs of the next light node protocol and meet the further needs.
Looking back at the final solution, we go back to the idea I mentioned at the beginning, that we are always looking for the solution with the least changes. If we only need to go from 1 to 2, we will never go to 5, because more things can be done in layer 2, layer 3, other higher layers or application layers.
If we put aside this idea, we can actually change it very quickly. We can just stuff whatever we think of into it, but over the years, you’ll actually get a very bloated design. A very typical example is C++. Its name shows that C was a very streamlined language at the beginning, and then when we felt that C was still lacking, we added to it, and kept adding every year. Now C++ is all-encompassing. If you get something like this, it will not be a really good design. That’s why C++ is not so popular now, and it has a lot to do with the development notion. Developers who know the underlying details may know that the block header of Bitcoin is still 80 bytes after 10 years of development, and the internal structure is very compact; CKB is slightly larger, 208 bytes. Why are these details important? The larger the block header, the more data that needs to be synchronized with light nodes in the future.
In a nutshell, because of CKB’s notion, we are very careful to make choices in the design of the hard fork, and the effect of these choices is actually at the system level. There are the smallest necessary changes that we believe will meet the needs of community developers, contract developers, application developers, and system developers, and solve their problems. What other upgrades do we need after this hard fork? If you have any questions, new requirements, we can discuss them, design together, and plan what we should do for the next upgrade.
Jan: For the dApp layer, these changes need to be absorbed by application developers before they have an impact on users. So it’s better to ask application developers how they will take advantage of these improvements, implement new features, or improve user experience.
For wallets and exchanges, the biggest change is the new address format. For them, it is very easy to upgrade the node, because the upgrade of the node is nothing more than replacing the files. Everything is automatic, and the SDK has been completed. It’s easy to do that.
There is one thing to note here. We have made a change in the address format and standard. The hard fork will be done with a new address standard. Previously, we had long addresses and short addresses. After the hard fork, we set a unified address format as default, which is a new long address. Strictly speaking, the change of address format doesn’t require a hard fork, but a standard change of the application layer. For convenience, we merge it into this hard fork. This may have a relatively large impact on DeFi projects, wallets, and exchanges.
For mining pools, the upgrade doesn’t have much of an impact.
