Nervos CKB2021 Mainnet Upgrade AMA Review

Original Source: Nervos

Original Compilation: nervosyixiu.bit, CKBFans Chinese Community

This article was organized by CKBFans Chinese community nervosyixiu.bit since April 2022 On the evening of March 21, Nervos architect Jan Xie (Twitter: @janhxie) shared an AMA on the CKB2021 mainnet upgrade on Twitter Space. The live broadcast lasted for 2 hours, and Jan answered 12 questions raised by the community, with 24,000 words in text.

(this CKB mainnet upgrade is called For CKB2021, because it was planned and developed from 2021, and the verification work of the early version was completed in 2021)

TLDR:

What CKB wants to do is to extend the concept of SoV, from a single store of value (SoV, Store of Value) to a store of value for multiple assets (SoA, Store of Value) of Assets).

The features of this upgrade include the following parts: virtual machine, block structure, consensus rules, P2P network. For users, there is basically no perception.

As the kernel on the Nervos layer, CKB should be kept as small, streamlined, stable, safe, and more It should be put into the 2nd, 3rd, upper layer, and application layer. This is the consistent philosophy of Nervos.

The bottleneck of public chain performance throughput is the average bandwidth of the global network. The most efficient blockchain, or the best "performing" blockchain is the one that makes the most efficient use of bandwidth.

This hard fork is a kind of hard fork that everyone has already expected and agreed to, so there will be no Two chains come out, because only when the community opinions are very divided will a situation like ETH and ETC be formed, which is actually very, very rare in the history of the entire blockchain.

The Nervos Network composed of CKB, Godwoken, and Axon is based on security, performance, and decentralization. Make different trade-offs:

· If you really want security and decentralization, you should develop on CKB.  

· If you want high performance very much, you may go to Axon for applications.  

· If you think you want something in the middle, you can choose Godwoken.

Nervos will have an overall upgrade from bottom to top, from 1st to 2nd floor in 2022, CKB hard fork It was the beginning, then Godwoken, and then Axon went live.

This year's Nervos ecology, more development may appear on Godwoken V1; in addition, Axon is also fully compatible with the EVM Layer 2. If it goes online, the ecology will develop rapidly.

The following is the content of the live broadcast

Brother Yixiu (hereinafter referred to as the host) : Friends in the live broadcast room, good evening everyone, I am your old friend Brother Yixiu, first of all, I would like to thank you for taking your precious time to participate in our event tonight.

Last week, Nervos announced the timing of the mainnet upgrade, and plans to officially launch the mainnet upgrade when the 5,414 epoch arrives (already on May 10 Upgrade completed successfully). We only know that this is the first network upgrade since the launch of the Nervos mainnet on November 16, 2019, but many people may not know that this upgrade involves a wide range of areas, if you look at the GitHub submission record , You will see that basically all core components have been optimized and upgraded, and in order to ensure a safe and stable upgrade, the core development team spent almost a whole year preparing for this upgrade.

Tonight, our CKB Chinese community invited Nervos chief architect & core development team member Jan to our live broadcast room , he will answer one by one the relevant questions about this mainnet upgrade collected on Twitter and discord.

Jan, first say hello to the friends in the community!

Jan:Hello, everyone, I am Jan, the architect of Nervos.

Moderator: Thank you Jan for coming, considering that there are some newcomers in the community, before officially starting the AMA, please introduce your personal experience.

It may be the same as many people, or different from many people. When you first saw Bitcoin, you thought it was a scam, right? If you go back in time, you can hardly imagine that as programmers, we can build a new currency. That is a crazy idea, and this thing is too unreal.

However, you will see some very interesting aspects of Bitcoin in terms of technology and design. The design of the Internet is completely different, and it is completely reversed. For example, the Internet pursues high performance and high efficiency, while Bitcoin’s PoW pursues low efficiency (you need to do this if you want to be safe); Internet products need to be exquisite, and Bitcoin is special. "Roughness", the roughness mentioned here means that the early bitcoin software is very rough.

For example, if a new node of Bitcoin wants to join the Bitcoin network, it must first be able to find a node already in the Bitcoin network to connect. called seed nodes. So how do you find a seed node in Bitcoin? You cannot obtain that information through the P2P network, you must have an initial method, otherwise there will be an endless loop. The early Bitcoin was very simple and crude. It used the IRC protocol to allow the nodes of the Bitcoin network to join a specific IRC chat room. When you enter this chat room, the people in the chat room are your seed nodes. (Remarks when finishing the manuscript: IRC, the full name of Internet Relay Chat, IRC is characterized by the ability to establish channels between chat partners, people in the channel can receive information, people outside the channel cannot, it is equivalent to a chat room. ) This is a very rough and tricky method, because on the Internet, such a method is definitely not used in our production environment, and Bitcoin uses it.

So you will feel that Bitcoin is a very rough thing in terms of engineering, but it shines with wisdom in design. It fascinates and starts researching. I first went deep into it, and then I was attracted by a friend to start a business. After that, I have been settled in this industry and done a lot of things.

At first it was a trading platform. You can go to see an open source project on GitHub called peatio (Pixiu), That was written by me. I believe it was the first open-source trading platform, because I searched GitHub for a long time, but couldn’t find any useful trading platform code, so I had to write it myself in the end. I believe peatio's code should have promoted the development of this industry, because I know that many trading platforms have used it, and I even know that some very large trading platforms are written in Ruby on Rails at the beginning, and there are actually Many origins. (Ruby on Rails, officially referred to as Rails, also referred to as RoR, is an open source web application framework written in the Ruby language. It is developed strictly according to the MVC structure, trying to keep itself simple, so that the actual application development code is less , with minimal configuration.)

( peatio github homepage)

After doing the trading platform, I started to try new things again. Because the trading platform is not so close to the blockchain, it is still at the application layer in essence, and then I want to study in a lower-level direction, so I went to study Ethereum. When I was working as a trading platform, Ethereum just came out, and it was still very new, mainly abroad. When Ethereum came out, many people in the Bitcoin community thought it was a scam because there were a lot of altcoins at that time. But I think it is very interesting, because from a technical point of view, compared with Bitcoin, Ethereum has obviously taken a step forward: from a pure Crypto Currency to a platform, from a mobile phone that can only make calls to I installed an iOS, so I started to study its code on the one hand, and then tried to write an Ethereum client by myself.

On the other hand, a few friends and I started the EthFans community in China. You may or may not know this community, because it is gone now due to various reasons. But EthFans used to be the most professional and largest Ethereum community in China, and it has grown together with Ethereum from the very beginning.

So I wrote the code while doing the community, and later when the Ethereum research team needed to recruit people, I sent an email to Vitalik directly. This is actually a normal situation in open source projects. Not only Ethereum, but any open source project on GitHub, you can actively contribute code and communicate with developers. If a developer needs help, he may come to you . Before the research team recruited people, I had already written a client version of Ethereum called ruby-ethereum in Ruby, which was fully compatible with Ethereum at that time, and completely passed the test of Ethereum's own set of dedicated test cases. , Passing that test means that your compatibility is already very good, and it is a normal client. So at that time ruby-ethereum was also added to the official documentation, which is one of the 7 clients. Since I have done these things, I already know Ethereum very well, and Vitalik also knows about my work, and I am interested in research, so I joined the research team very smoothly. Then I participated in a few things in the Ethereum team: one is the research and prototype design of Sharding, and the other is Casper.

On the other hand, I established a company in Hangzhou called Secret Ape Technology. At the beginning, Secret Ape Technology actually did the licensing chain. We made a project called CITA, which is a licensed chain, mainly for performance and scalability, and is also compatible with EVM. Later, the main members of the CITA project left Secret Ape and established another company, Xita, which is also developing very well now.

The blockchain system needs to scale. This is a problem that all of us have been trying to solve. There are actually two ways to scale. One is that you make every node in the entire network more powerful. If all nodes are more powerful, for example, from a laptop to a supercomputer, then the throughput of your network is very high. It will naturally rise, and you don’t need to do anything in system design; another way is that the network is full of notebooks, but the more notebooks are added to it, the better the throughput or processing power of the network. This is another way of scaling. The former is called Scale Up (vertical expansion), and the latter is called Scale Out (horizontal expansion).

If we want to scale up, there are actually two ways: one is that we replace the notebook with a supercomputer; the other is to replace the notebook with a 1 A group of servers, a Cluster cluster, this cluster together forms a logical node, there are actually many machines inside this logical node, but externally, it is just a node. In fact, this can also form a Scale Up effect, and the network throughput can be improved, but this method can only be used in the permission chain. We started with Scale Up, and we have also done some very interesting projects, including cooperation with banks and various institutions. Therefore, we also have a lot of accumulation and experience in high-performance permissioned chains.

At this stage, I also helped Spark Mining Pool design and implement the first version of the mining pool. You may not know that the Spark Mining Pool is actually a project that grew out of the EthFans community, and later became the largest Ethereum mining pool in the world. It was closed last year due to well-known reasons, which is a pity.

（Secret Ape Technology project list)

Because of my previous experiences, I I have accumulated a lot of ideas, and finally when all conditions are ripe, I still want to challenge the public chain, because in my opinion, the public chain is the most challenging and interesting thing in the entire Crypto industry.

Moderator: Thanks Jan for sharing. Let's start answering questions from the community.

Q1: This is the first important upgrade of the Nervos mainnet. For this upgrade, the team has put in a lot of effort. Can you introduce it? The background of this network upgrade.

Jan: First of all, upgrading is an inevitable thing. A long-running software always needs to be upgraded, because it is impossible to predict all the needs at the beginning. As the needs change, the software will also change accordingly; the same is true for the public chain, the blockchain is also a software system, and the upgrade is certain.

Secondly, Nervos is a brand new system with a new set of ideas. At the beginning, only 40% or 60% of the things that are determined may be left. groping. On the one hand, because it is difficult for us to predict how developers will use this system in the future, after the mainnet launch, many developers have done development on the mainnet and pointed out some unreasonable design. These feedbacks have accumulated a certain amount and need to be adjusted. To accommodate the needs of developers, this is something that needs to be upgraded. On the other hand, we knew very well when the mainnet Lina was released that this is only the first phase of Nervos, and there is still a long list of things to do, and there are many things in line that can only be done step by step. Those more complex and advanced things that we originally wanted to do also need to be upgraded to complete.

Q2: What problems can the upgrade solve? What changes will it bring about? What should we pay attention to after upgrading?

Jan:OK, let me introduce the hard fork of CKB. First of all, I think everyone needs to understand that CKB may be different from many blockchain projects, because I often see some problems. I think it may be due to some misunderstandings about Nervos and CKB, so there are such problems. Therefore, we must first understand that different public chain concepts are actually very different.

CKB is a continuation of Bitcoin both in terms of design and concept. For example, CKB chose PoW when PoS was popular, using optimized Nakamoto Satoshi consensus rather than BFT-like consensus, the state programming model is an extended UTXO model, and various design choices, all of which illustrate this point. These choices are made consciously, not put together unconsciously.

I know both Bitcoin and Ethereum well, and these choices have their own reasons. The mainstream view in the industry now recognizes that Bitcoin is a store of value, it needs to be very safe, and we would rather it stay the same. Therefore, it can be seen that Bitcoin is very conservative in technological development, which is actually the attitude of Bitcoin; what CKB wants to do is to extend the concept of SoV, from a single value store (SoV, Store of Value) to multiple The value storage of assets (SoA, Store of Assets), you can safely put various assets on the chain, which is an extension. The realization of value storage requires corresponding choices, which is not a natural thing.

At the same time, Bitcoin has very good usability. To put it simply, you haven’t seen Bitcoin downtime, but today’s various blockchains are either down due to bugs, or down due to upgrades. In my eyes, this is not the same as Bitcoin. Plant something. Because such a chain is actually similar to an Internet service or a cloud database; Bitcoin is not like this at all. Of course, no one can guarantee that Bitcoin will never stop for 10,000 years, because after all, it is written by people and it may always have bugs, but its concept is very clear. We need to ensure that it cannot be stopped after just one change; It hasn't stopped for several years, and time is the best proof of Bitcoin's design philosophy. There are many chains that have only been in operation for a year or two and have been stopped countless times, so I say they are different things, but they just happen to be caught in the vague definition of "public chain". CKB has been online for more than two years and has not stopped. This is also a continuation of the concept of Bitcoin. this is very important. This is a background.

CKB wants to go from SoV to SoA on the basis of Bitcoin, in addition to the need to ensure that the degree of decentralization remains unchanged and the nature of liveness (keep the network running continuously) In addition to being good enough, there must be extensions, otherwise it will be Litecoin. However, the expansion must have continuity, and it cannot change from UTXO to Account model like Ethereum. In other words, we still need to make the first layer more powerful and flexible, but only a little bit stronger. If Bitcoin is from 0 to 1, Ethereum is from 1 to 10, and some projects behind it want to go from 10 to 20, or even to 100, then CKB wants to go from 1 to 5, which sounds counterintuitive : Ethereum has gone from 1 to 10, and you have only reached 5, so you are not as good as Ethereum? ! It needs to be understood that technology development has many directions. If Ethereum goes from 1 to 10 along the X axis, Nervos at this stage can be said to go from 1 to 5 along the X/Y axis at the same time. In the work that Nervos has completed at this stage, the first layer is the PoW + UTXO model, and the second layer is the PoS + Account model, which can be said to be an annotation.

Nervos as a layered network as a whole wants to go from 1 to 100, but as the core of this layered network, CKB should be just the best A streamlined state, because if more things are stuffed into the kernel, it will be very bloated, and the more and more complex the code, the easier it is to have bugs and thus be unsafe. This is its consequence. If you don’t go far enough, it will be very difficult to change like Bitcoin. It is very difficult to develop a two-layer network on Bitcoin, and it is very difficult to realize various assets on Bitcoin, so we need to find that balance point, we cannot If you go more, you can’t go less, find a just right point, build a layer-2 network and a layer-3 network on this basis, and then the entire layered network system is a system that can reach 100. This is the CKB and Many other chains are different. So you can understand CKB as a core that extends Bitcoin a little bit. Just like the Windows operating system you use, it has a kernel; the Linux system you use also has a kernel, and Apple iOS also has its own kernel, and the kernels are very small. The application software you usually use is not the kernel, they are applications on the upper layer of the kernel. There is an intermediate layer between the application software and the kernel, the system call library. (Remarks when finishing the manuscript later: the application generally does not directly deal with the kernel, but communicates with the kernel to execute corresponding instructions by calling the SDK interface encapsulated in the middle layer)

Many blockchains try to cram everything into the kernel, which is also normal, because it is still in the early stages of technology development. When we look back at the development of the operating system, we can also see that the same is true for the early operating systems, that is, everything is put together.

CKB actually focuses on the kernel, or the engine of a car or an airplane. This is the positioning of CKB, so CKB, from In terms of positioning and design concepts, it may be a little far away from ordinary users and even ordinary application developers. This point is actually very similar to Bitcoin, because if you pay attention to the difference between Bitcoin and Ethereum ecology, there is a popular observation in the circle: Everyone says that developers on Ethereum are hipsters, and writing applications is like playing , 100 applications can pop up in one day; Bitcoin developers are bitter, it may take two years to write an application, and they may have to publish a paper before writing an application. These two communities are very different. CKB will be closer to the Bitcoin community. Programming on CKB is very close to doing system-level programming on an operating system, rather than doing web development. These are two very different platforms, and the positioning concepts and designs are all different.

The purpose of saying so much is to answer such a question: How much of this upgrade can be perceived by users?

This question is very difficult to answer.

Because the upgrade itself is very far away from the user, you may not be able to perceive it directly, but you will feel these upgrades indirectly. Because there are one-tier or two-tier developers in the middle doing the work of the bridge, absorbing the bottom-level changes into their applications, tools, and libraries, so that users can use these applications without difficulty. You will feel that this seems to be more useful than before, it is an indirect relationship. You can understand this upgrade as an operating system kernel upgrade, and the application may still lag for a while. (Just like a car engine is upgraded from the first generation to the second generation, you will not have a direct perception, you will only feel the change when the car manufacturer installs it in the car, for example, its power ratio The first generation is more sufficient.)

Let’s talk about the features of this upgrade, the following parts have changed a lot:

·Virtual Machine 

·Block Structure 

·Consensus Rules 

· P2P network

Among them, the consensus rules and changes of P2P network should be basically transparent to users. Most of the changes in the consensus rules are to solve some badly defined rules or places with bugs.

One of the more important consensus rules, which is also particularly useful for developers is RFC0036 .

If you want to refer to the previous block header data in your contract, before this hard fork, you can only refer to 4 epoch (about 16 hours) before the block, after this hard fork, you can refer to the data of the previous block, or even the data of any block on the chain, this is for developers who write contracts for many applications This is a huge difference. Because they can obtain the latest information on the CKB chain within the contract when the contract is running, this will bring about a change that improves the user experience.

As a user, when you were using an application before, you didn’t know why you had to wait so long, then after this upgrade, you may not Need to wait that long. Because before this application needs to wait for this block to mature, it takes 16 hours to wait. After the upgrade, it does not have to wait.

In my impression, UniPass and .bit should have encountered this problem. So why was it designed to wait 4 epochs in the first place? This is actually a design that has been entangled for a long time.

Maybe some friends know that in the Bitcoin system, the newly mined Bitcoin also has to wait for a maturity period, the so-called maturity period is about 20 Hours or how many hours, I forgot. It means that you cannot spend the bitcoin you just mined within 20 hours. why? Because I am worried that if you spend it right away, but after that, it is possible that the block that was dug out first will become Uncle, become an uncle block, and then those newly mined coins will disappear as soon as they are dug out. In other words, if you allow those coins to be spent immediately, all subsequent transactions that depend on this newly mined coin will all be rolled back, which may cause trouble for users, and may lead to some very strange consequences. .

The fact that such a restriction is added to CKB is actually for the same reason. This actually involves a balance between security and ease of use. Do we want to be safe or easy to use, and should we be consistent with Bitcoin or Ethereum? Ethereum and other blockchains don't think about these things at all. In terms of design, it is difficult to determine where our balance point should be placed. Anyway, after a long discussion, the development team of the community also encountered problems and raised requirements. The final conclusion is that we will relax this reference area There is no need to wait for 4 hours for block header restrictions, but some other restrictions are still maintained.

This is a very typical example, we need to find a balance between the concept of Bitcoin and the concept of Ethereum - we don't want to become like Ethereum Like Fang and other blockchains, Move fast and break things; but we don’t want to become sluggish and rigid like Bitcoin, making it very difficult to move forward. This is the part where the rules of the consensus layer change.

The most important thing about this upgrade is actually the change of the virtual machine.

The virtual machine contains 3 RFCs: 0032, 0033 , 0034.

Let’s talk about RFC0032 first, it introduces the concept of virtual machine version, which is a very interesting thing, I don’t know which blockchain’s virtual machine is With version, CKB may be the first one, I really haven't seen it yet, if you know others, you can point them out. Ethereum has previously discussed introducing a version into the virtual machine, that is, the EVM, but found various problems, so it did not do it.

Why does CKB do this? There are actually very practical reasons.

First of all, CKB's VM is the instruction set of RISC-V, we follow the standard of RISC-V, RISC-V is a widely used in the industry , An instruction set standard that is developing rapidly, we have to follow its standard. The RISC-V standard will be constantly updated. If we don’t follow suit, it will be incompatible with the specification, and all the benefits gained from compatibility will be lost. Therefore, CKB-VM must also be able to upgrade and follow RISC-V. This is a requirement.

On the other hand, back to what I just mentioned, CKB hopes to be the same as Bitcoin: to become a SOV store of value. A very important factor for becoming a store of value is: as a user of this blockchain, they can be sure that the assets I keep with a public key or a contract today will still be safe after decades or even a hundred years. It belongs to me.

This is a very natural and just requirement, which sounds like nothing difficult, but in fact it is not so easy to achieve. why? Because how to ensure that the blockchain upgrade will not change the previous contract or account logic? Are you sure that no matter how you upgrade in the future, your assets still belong to you? This is a question worthy of debate and discussion, because the meaning of a piece of code or a contract is determined by two aspects, one is the code or the data itself, and the other is the "container" that interprets the code or the data. The blockchain is the container that interprets 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 it will modify the container that interprets the data, which may change the meaning of a certain piece of code and a certain contract, which may affect the ownership of certain assets.

Bitcoin avoids this problem easily. He said that we never do hard forks, and this problem does not exist to a large extent. Whether hard fork is possible is guaranteed by community consensus. But if hard fork is required, as we just said, we need to upgrade the VM, and how can we ensure that the semantics of the contract will not be changed by the upgrade? The goal we want to achieve is that even if you keep upgrading, you can guarantee that you have saved an asset today. After decades or 100 years, no matter how many times you upgrade in the middle, it will still be yours. This is a relatively simple description, and the implementation is not as simple as it seems.

The most famous example of this is, I think everyone knows, what happened on Ethereum - The DAO. The hard fork created to fix The DAO was essentially a group of people voting to strip one person of their assets. The attacker transferred the money in the DAO, and then the community formed a consensus through an informal governance process, and finally decided to carry out 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 does is that it directly changes the data.

In fact, there is another (possibly smarter) way to not change the data, but to change the interpreter that interprets the data. We can keep adding new explanations.

So having said that, if we want to upgrade the VM, we actually face such a conflict. On the one hand, we need to upgrade the VM. On the other hand, we don’t want to give developers too much power, because once we have this power, it may eventually develop into the VM, that is, the interpretation container, which can be modified arbitrarily, resulting in the previous code /Contract semantics change, the possibility that this could damage people's confidence in whether this chain can become a SoV.

So what should we do?

CKB has found a solution that I think is ingenious. CKB has a feature that most users may not know, but developers are very clear. When referencing a smart contract on CKB, there are two ways. One is through the address of the smart contract. On CKB we call it Type id, just understand it as an address, just like the contract address of Ethereum, you can refer to it by address. Another way is that you can use the code hash of the contract to refer to it, that is, what is the code of the contract, and use the hash calculated by the code to refer to the contract.

So what is RFC0032 about? 0032 means that if you refer to the contract through type id or address, then when the contract is running, after the hard fork, it will automatically upgrade to the V1 version of the virtual machine, and use the new virtual machine to implement. why? Because you use the address to refer to the contract, this behavior or usage itself means that you have given the right to interpret the contract to the developer of the contract, because type is the same as the address, it is a name, and it has nothing to do with the intrinsic properties of the contract itself. associated. Contracts referenced by name can keep changing, just like you keep growing, you can grow from 3 years old to 12 years old, you still have the name, but as you grow older, something has happened inside your body many internal changes. "It's just a name, and it can be changed internally." This is what the choice itself conveys when you make the choice to use an address or type id to refer to a contract.

Another way is that you refer to it through the hash of the contract code. At this time, what you mean is: "I don't want the referenced object to change at any time, and I want to always get the same result." - I just want to use this code, in my current virtual machine run this contract under the interpretation rules of . I know you may upgrade in the future, I don’t care, even if you do 100 upgrades, I still hope to use the code I wrote when sending the transaction now and the virtual machine I wrote when sending the transaction now to execute this contract, I want to get same result.

Because you are not using a name at this time, you have specified a piece of code very clearly, and the corresponding execution environment version, you have specified very clearly a semantic. If you refer to the contract in this way, the execution result of your contract will not change after the hard fork, even after the hard fork, your contract will still be executed with the version of the virtual machine before the hard fork , the code you wrote at that time will still be executed with the version value of the previous virtual machine. In this way, it can be guaranteed that no matter how hard the fork is, your contract is still the same as the previous contract, without any change.

Therefore, through these two different citation methods, CKB leaves the choice to users and developers to choose:

· want to get the benefits of automatic upgrades, but are willing to give up some semantic changes; 

· unwilling to accept semantic changes without your consent If there are changes, I would rather give up the benefits of automatic upgrades, and upgrade myself if necessary.

This is what 0032 solves. In short, 0032 implements a multi-version virtual machine model, while ensuring the semantics of SoV value storage, while solving the technical challenges of coexistence of various multi-version virtual machines. This is a very big change. I haven’t seen other chains implement this. Most chains may not care about it and have no way to solve this problem-just upgrade the virtual machine. Why do you have multiple versions? Everyone is together The upgrade is over. Users of these chains actually gave up some rights intentionally or unintentionally. This is not the same as CKB's philosophy. This is the first big change to the VM.

The second big change to the VM is written at RFC0033. 0033 specifies the virtual machine version.

Includes all changes, both bug fixes and internal command formatting redesigns. Although it is also to explain the RISC-V instruction device, there are actually many internal practices.

There are some new changes made from the virtual machine level for the convenience of debugging, for the convenience of system developers and contract developers on CKB to do debugging . There are also changes made to improve performance, such as Lazy initialization memory, MOP.

The most noteworthy is that in order to better implement, or improve the changes made in the interpretation of cryptographic primitives, the new virtual machine version first For the first time, a RISC-V Extension was introduced, which is the extended instruction set of RISC-V. 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 time to introduce an extension package, which first proves that this thing is feasible. Second, it happens to work with multi-version virtual machine architectures.

The extension package we introduced this time is B Extension, which is the extended instruction for the calculation of large numbers, only 4 instructions, of course it verifies the design and model It is feasible. We also tried to optimize some cryptographic algorithms with the B command, and verified that it can indeed improve performance. This is another very important improvement, and more extension instructions will be introduced in the next hard fork. In this hard fork, we will first insert a small improvement, and then verify the results. If successful, we can insert a bigger change in the next hard fork. In the next hard fork, we plan to fortify What went in was RVV - the vector instruction set (RISC-V Vector).

The performance improvement that the vector instruction set can bring to the cryptographic primitives will be even greater. If the performance improvement of cryptographic primitives brought by the B extended instruction set may be 10% to 20%, then the vector instruction set is very likely to bring a performance improvement of several hundred percent, and this difference will be very large.

If the VM version in 0033 verifies that all of these are feasible, then just follow the methods that have been stepped out before. The only difference is in workload, B extension has only 4 instructions, RVV may have 200 instructions.

The above is the second big change in the virtual machine VM.

The third relatively large change in the virtual machine is at RFC0034, it introduces a new syscall (system call), adding Three new syscalls were introduced, the most important of which is a system call called exec. If you regard CKB as a kernel, exec is the same as the exec in Unix.

So, what does it mean to use exec in CKB? In fact, it allows a contract to refer to another contract through the contract address reference method just mentioned or the hash reference method of the contract code during the execution process, and jump there for execution. Just replace the code executed by the current process with the code of another contract, in simple terms.

So why is it useful? It enhances the composability of contracts. I can now have 3 contracts of ABC, and they can finally use the contract D to combine the 3 contracts of ABC and run them together. Then we can design the previous lock script as a module, use exec to call these modules, to call, for example, signature algorithm A, signature algorithm B, and signature calculation C, and then add some business logic of our own. It was not convenient to write such a function before, but after the upgrade, it will be very convenient to write this kind of thing. Previously, methods such as dynamic link libraries were somewhat lacking in ease of use and security. This hard fork takes composability one step further. After two years of development, in terms of composability, the community put forward a lot of opinions, and finally fell on such a solution.

The above are VM changes.

Another change that has a relatively large impact is on the structure of the block. In fact, the specific changes in the structure of the block are very small from the code level. A new field called extension is introduced and added to the block structure. This is for better scalability of CKB in the future.

This extension is an optional field, which can hold up to 96 bytes of data, or at least no data. With such an expandable field, we will have a foothold in the next step to do the light node client. Because it is necessary to add a light node protocol to the CKB protocol, in fact, the block producing nodes need to do some extra calculations during the consensus, and then put the calculation results somewhere. If there is no such extension field. Those auxiliary data, that is, data that is very useful for the light node protocol, cannot be placed anywhere.

Before the implementation of this plan, we thought about many methods, including whether it is possible to reuse these existing fields to solve the problem. Very reluctantly, a field was added to it. However, having this field will bring better scalability. It is not only applicable to the light node protocol, but there will be more improvements related to the protocol level in the future. If some data needs to be added to the block, this field will also Can use. Therefore, it can not only meet the requirements of the next light node protocol, but also meet the further requirements.

Looking back at the final plan, let’s go back to the concept I just mentioned at the beginning, we are always looking for the plan with the least change. If it is just right to go from 1 to 2, we will never go to 5, because more things need to be done on the 2nd, 3rd, upper layer, and application layer, and we need to keep the kernel as small as possible , streamlined, stable, safe, this is a consistent concept.

If we put aside this concept, we can actually change very quickly. We could just stuff whatever we want, but over the years you end up with a really bloated design. A very typical example is C++. As you can see from the name, the C language was very streamlined at the beginning, and then I felt that there was still something missing in the C language, so I added it and kept adding it every year. Now C++ is all-encompassing. You will get such a thing, it is actually not a good design, and C++ is not so popular now, it has a lot to do with the development concept. Friends who know the underlying details may know that after 10 years of development, the Bitcoin block header is still only 80 bytes, and the internal structure is very compact. CKB is slightly larger, 208 bytes. Ethereum is 508 bytes, and it is also well maintained. Others who are interested can do their own research. Why are these details important? The larger the block header, the more data that needs to be synchronized by the light nodes after years and months.

In short, because CKB adheres to such a concept, we will be very careful in making some design choices when doing hard fork design, and these designs The choice, the effect produced is actually very low-level. They are the minimum necessary changes, and we believe that these changes can meet the needs of community developers, contract developers, application developers, and system developers, and solve their problems. After this hard fork, what upgrades do we need? If you have any new problems or new requirements, we can discuss, design, and plan what we should do for the next upgrade.

Q3: After the mainnet upgrade, what impact will it have on ecological projects?

Jan:First of all, for the dapp layer, these upgrade changes need to be absorbed by application developers, and then will affect users. This question may be best asked by the application development team on Nervos to see how they take advantage of these changes, what new features are implemented, or what user experience improvements they bring.

For the wallet trading platform, the biggest change actually involves an address change. For them, upgrading the node is actually very easy, because upgrading the node is nothing more than replacing the binary file and the upgrade is complete. Everything is automatic, and the SDK has already been done. It's easy to do.

What needs to be noted here is that there is a change in the address format address standard. This hard fork is being upgraded with the address standard. Everyone knew before that we have long addresses and short addresses. After the hard fork, a unified format is adopted by default, which is a new long address (strictly speaking, the address format is not an underlying change that requires hard fork, but an application layer standard change, just for the convenience of merging into this hard fork upgrade. Done). This may have a relatively large impact on ecological projects, wallets, and trading platforms.

For the mining pool, it is good to upgrade, but it does not have much impact.

Q4: According to the introduction, the CKB address will be unified into a fixed-length format after the mainnet upgrade. Does this mean that the CKB wallet address of all dapp applications in the future will be the only one? , there will no longer be a situation where one application has one wallet address?

Jan: This is a very interesting question, because it involves the design ideas of CKB.

First of all, after this mainnet upgrade, the address specification will be unified into a fixed-length format, at least the default address. Why do I emphasize the default? Because the address format used by the developer and the address format used by the application side are the freedom of the application itself, and there is no way to force this. This is just a standard, and everyone is free to choose whether to use this standard. What has changed this time is the default standard: the previous problem was that the default standard contained two formats, one long address and one short address, and the new standard only has one format.

However, this does not mean that the CKB wallet address of all dapp applications will be the only address.

Although the address is not the only one, it does not necessarily mean that the user experience will be bad. These problems are separate and independent problems.

From the feedback, the reason why everyone hates the long address and short address is because the user experience is not good, but the user experience is not good , it is a problem of many layers, maybe not just a problem of address format. For example, let’s say we’re at the SDK layer. Assume that after our ecology matures, the SDK is perfect, Mercury and Lumos are all perfect, no matter what address format there is, these intermediate layers can support it, so for the wallet , trading platform and dApp application developers, because they actually use Mercury, Lumos these middleware SDK, instead of using CKB RPC directly, can also finally achieve a good user experience.

If the middle layer is done well, even if there are 100 addresses in the bottom layer, you may not feel it. This is the benefit of layering, because the middle layer can hide the details of the bottom layer. The problem before the hard fork was that because the middle layer was immature, the details of the bottom layer appeared before the eyes of users, which caused a lot of trouble for users. Here is my definition of the problem.

So, when the ecology is not yet mature, should we wait for the middle layer to mature and find a perfect solution to solve this problem, or Say we don't have to wait until the middle layer matures, and first change the address format to a uniform-length format?

After everyone's discussion, the core team and community team, including UniPass and .bit teams, have had meetings and discussions, and then we decided to change the address to Unify one, at least solve the immediate problem first. In this way, no matter whether the SDK middle layer is well done or not, at least the problems we encountered before can be eliminated.

However, in the future, there will still be multiple addresses on CKB, and there may even be different addresses for each dAPP. This is a feature of the UTXO model , the resulting user experience problem needs to be solved by the middle layer. Therefore, when we design Mercury and SDK, we will pay great attention to considering what kind of script it will map out if there is a new script. the address of. If the same address is mapped, of course there is no problem. If a different address is mapped to the surface, should the user know about it or not? How do we design this whole link so that users have no perception of this, and will not encounter the troubles between long and short addresses before. This is something we will consider in the future.

So in short, we have actually adopted a temporary plan that everyone is satisfied with, and unified it into a fixed length, and everyone has no opinion. In the future, we should discuss with the entire community how to evolve the address format while ensuring user experience.

Why may there still be multiple addresses? This is a very interesting thing. I wonder if you have ever used a Bitcoin wallet. A truly authentic bitcoin wallet, such as Electrum, or an official client with wallet, you will find that it will generate a lot of addresses for you by default. Maybe many people who came into contact with crypto later did not do so in the wallets they made. So why do real bitcoin wallets do this? Isn't this asking for trouble? On the one hand, this is because addresses and accounts are inherently different concepts, but because the popularity of Ethereum has blurred the definitions of the two. Secondly, there are actually many benefits to doing so, such as better privacy protection. If there is only one address, and all your activities are associated with this address, it is very easy to find out who you are with big data analysis. If you want to protect your privacy, the best way is to use a different new address for each operation. address.

I don’t know whether you usually use one address or 3 addresses in your wallet at the same time. In fact, the account system is not very good in terms of privacy. Bitcoin wallets like Electrum will always change addresses automatically. Once you use one, it will generate a new address for you, and if you collect money again, it will generate a new address for you. In the Bitcoin system design, addresses and accounts are two concepts: accounts are not in one-to-one correspondence with addresses, but accounts and addresses are in one-to-one correspondence, which is the design of Ethereum.

In the design of Bitcoin, an account can have countless addresses. In fact, we can do it through system design. The user only needs to remember the account. In fact, he doesn’t need to care whether there are 10 addresses or 100 addresses under his account, as long as the middle layer at the bottom can help him automatically handle it. The generation, change, transfer and collection of each address, from the perspective of the account, the assets of all addresses are in this account. In fact, for users, the experience is the same. (Remarks when finishing the manuscript: If you have used the official Nervos wallet Neuron, You will find that a new address will be generated every time you receive money, and when you receive money next time, it will pick out an address from your account that has never had a transaction for you, which allows you to use it with the Ethereum wallet The experience is the same, but it can better protect your personal privacy)

The relationship between address and account becomes one-to-one only after the success of Ethereum of a transformation. However, if the address and account can be decoupled, there are actually many benefits, the privacy just mentioned is one. Another advantage is that because I can have different addresses, my address itself can encode information, and this encoded information can prompt the wallet to do corresponding actions. In doing so, it makes the protocol between wallets and applications much stronger.

Finally, to sum up, the number of addresses under the same account is not the key, we can explore step by step. This point is actually very lack of research and exploration, because everyone is now brought there by the design of Ethereum. Let's make everyone's user experience better first. In the future, while maintaining a good user experience, how should we explore the underlying design? Step by step to improve the relevant design.

I hope that everyone will not simply conclude that only one address is good, but it is not, and there is actually a lot of room for design. If we have a clear principle now, it is that we should explore this design space while ensuring the user experience. This is a win-win result that everyone is satisfied with.

Q5: Will light wallet support be provided in this mainnet upgrade? In addition, is there an official plan to develop a light wallet?

Jan: This upgrade will not have the support of light wallets, because light wallets need the support of light nodes, light wallets and light The node is two things, and the light wallet uses the light node to realize the function of the wallet.

Then there will be no light node protocol in this upgrade. We just said that this time we need to make some changes in the Block structure and add an extension field , to prepare for the next hard fork to join the light node protocol.

Is there a plan to develop a light wallet? What we have determined is that we have a plan to develop a light node protocol this year. I actually hope that the development of light wallets can be achieved through the community. Maybe there are other blockchains that have done all kinds of things officially, but I think Nervos needs to be built by the community, and everyone should work together to do this. This is also related to the concept. Open source and decentralization are actually very important.

Q6: There are many questions that users are more concerned about. Are there any ecological projects ready to be released after the mainnet upgrade?

Jan: Should I answer yes or no?

In terms of time, yes. After the mainnet is upgraded, there must be new projects to come out, and then new projects to be upgraded, because as I said just now, this is a kernel upgrade, and the application needs to make some adjustments at the same time in order to be able to take advantage of the benefits of the kernel upgrade.

But logically speaking, it may not have much to do with the mainnet upgrade, it just happens to be in a sequence, and there is no necessary connection.

Q7: Will there be a hard fork for the mainnet upgrade? Will the upgrade affect NFT transfers on Secret Treasure? Does it affect mining efficiency?

Jan: It will not affect the mining efficiency, because the mining algorithm has not changed, so there will be no impact.

Will the upgrade affect the NFT transfer on Mi Treasure? The upgrade itself will not have any impact, it mainly depends on what the secret treasure's own plan is.

Will there be a hard fork? The mainnet upgrade is a hard fork. It is not a hard fork like The DAO where the opinions of the entire community are divided, but a hard fork that everyone has already expected and everyone agrees with. So I don’t think there will be a hard fork. Two chains come out, because only when the community opinions are very divided will a situation like ETH and ETC be formed, which is actually very, very rare in the history of the entire blockchain.

Q8: Judging from the official mainnet upgrade content, the new cryptography standards have been updated, which can improve the efficiency and performance of the Nervos network. Nervos has always put security first, so this performance is to sacrifice part of security in exchange for better performance. Should we make a trade-off between these two points, or pursue better performance while ensuring security? In addition, some community users are not satisfied with the performance of the Nervos network. Is the performance improvement of the main network obvious to ordinary users?

Jan: I think for users, the perception is very, very small, or even non-perceptual.

Because we added 4 instructions of Risc-V B extension this time, we only use these instruction sets at the level of VM cryptography for better performance. And cryptography may be a small part of the entire application, because as a dApp, there are front-end, CDN, back-end, contracts on the chain, and the user's network environment. The system performance is determined by the entire link. of.

After we launch the RVV instruction set, it may bring obvious perceived performance, because that has a great effect on cryptography. But this goes back to what I just said that the dApp is composed of a long series of links. It has many components. Even if the performance of a certain group is increased by 10 times, the performance of the entire application in terms of user experience may be different. Only feel like a 10% improvement.

For users, the most obvious performance may be the processing speed of the chain, that is, when I send a transaction, when the transaction can be confirmed, But this performance is not what CKB pursues. I have been emphasizing that CKB is completely different from other chains, and the concept is fundamentally different. In this regard, I suggest that everyone read Zhang Ren’s explanation of the consensus. I think that after several years of practice in the industry, we basically agree with our point of view. A simple description is that the bottleneck of public chain performance and throughput is the average bandwidth of the global network. That's the bottleneck.

Why? Because if you want a chain to process 10,000 transactions per second, assuming that 1 transaction is 200 bytes, 10,000 transactions is 2 Mb, which means you must provide at least an average of 2Mb per second of network bandwidth. 100,000 transactions, that is 20 Mb bandwidth, 1 million transactions must provide at least 200 Mb per second of network bandwidth. And this is only at the theoretical limit without any losses.

However, you still have to spend a lot of bandwidth, for example, 30%, 40% of the bandwidth is spent on consensus messages. Because you can't use all the bandwidth to just pass your transaction, there is no consensus, right? These are physical limitations. This is not something that can be changed by your design consensus or how to write software, or how to design blockchain. This is the bottleneck of physical conditions.

So in our opinion, the most effective and efficient blockchain, or the blockchain with the best "performance" is the most effective use of bandwidth blockchain. Also give you 20 megabytes of bandwidth, how much can your TPS do? This is what we defined clearly from the beginning.

Some blockchains claim that their TPS has reached tens of thousands. What is the test environment for you to study it? What are the hardware conditions of the test machine and test node? What does it give up?

We can indeed improve performance, but we need to give up decentralization. It doesn't matter, we can give up these things, we pursue a better user experience, we need 10,000 transactions per second.

What to keep and what to give up is the difference in concept. Abandoning decentralization and security is not the idea of CKB. For example, Bitcoin does not do this, and Ethereum does not actually do this. Everyone has their own standards, and CKB actually has its own choices. The premise of comparison is to clarify what a chain's philosophy and conscious choice is. Putting the chains that have made the same choice together for comparison is a reasonable comparison.

The positioning of CKB is a layer, core, SoA, it must ensure decentralization. CKB's NC-Max implementation has the best performance. If you let everyone settle the premise, NC-Max is a very efficient consensus.

NC-Max is a consensus algorithm that has been reviewed by scientific research methods and verified in the practice of the CKB main network. It just recently published a paper, Has been accepted by NDSS, one of the four top conferences in the information security industry .

In comparison, some blockchain papers, in our opinion, have neither been tested by the actual network nor reviewed by any peers Drafts on the preprint site only.

We can also pursue user experience, or we can give up some things for user experience. But that may not be the path Nervos or CKB want to choose. Moreover, the Crypto market is so big, and a hundred flowers are blooming, which is very good. If you appreciate that road, you can join it. I don’t think there is any problem in doing so. Now there are a lot of public chain projects, and everyone has their own ideas and positioning. One of the things I think to avoid doing is I like idea A, then I find a team that has idea B, and then keep trying to convince that team that you should change idea A. Unless the team didn't think clearly about what to do at the beginning and followed the trend, it is possible to do so, but if the team's thinking is clear, it is impossible to make such a change. Note that I am talking about the change of the core concept, not the change of the superficial experience.

Furthermore, although CKB pursues security and maximizes performance under this premise, this does not mean that the entire network of Nervos is very slow. This is because Nervos is a layered network, and performance is solved on 2 layers instead of 1 layer. The Godwoken we are seeing now is an example. The experience it brings should be said to have improved, but it is not very high. This is why we still need Axon and so on. Therefore, you can see that CKB, Godwoken, and Axon make different trade-offs between security, performance, and decentralization. (Security, performance, and decentralization are the famous impossible triangle in the blockchain field. In the same component, if you want to achieve the ultimate in any two features, you will definitely sacrifice the ability of the other feature.)

For Nervos, what needs to be presented is that no matter what kind of trade-offs we have made, you can find a corresponding solution to join the network:

· If you really want security and decentralization, you should develop on CKB.  

· If you want high performance very much, you may go to Axon for applications.  

· If you think you want something in the middle, you can choose Godwoken.

This is the meaning of the entire layered network. If you look at each component alone. It won't be one thing that fits all, but when the components are combined, it's one thing that fits all.

Q9: What is the biggest difficulty in the upgrading work? How did the team overcome it? How to let the market recognize the technical output of the project? (How to transmit our technological achievements to the outside world) What is the next move in terms of ecological applications?

Jan: What is the biggest difficulty in the upgrade work? It's hard to do these upgrades while maintaining the SoV semantics.

How to overcome? I don't think there is any overcoming, because I spent a lot of time researching and discussing the plan, and finally I was able to come up with a final plan. After the whole process, everyone is still working hard to figure out how to do this right.

How to let the market recognize the technical output of the project? I think it is very important if these changes can be absorbed into the application layer so that users can perceive them.

On the other hand, we need to do more technical explanations and publicity, and pass on what we do. Just like I am doing AMA here today (thank you Yixiu for organizing!), I think these must be done, and if you pay attention, you can also notice that we have written a lot of blogs recently and spent a lot of energy writing articles By explaining the technical details of CKB, we hope that more people can see what we do, and attract more developers to study CKB and do things on Nervos.

The Nervos Foundation also does a lot, and the developer relations team is constantly attending various developer conferences. Although the epidemic will have some impact on the whole thing, I think more people will attend these meetings in 2022. I believe you have recently seen the most recent meetings on Nervos official Twitter. (Nervos has held many Hackthons in 2022, and some are ongoing or about to be conducted. Through one Hackthon after another, developers are constantly attracted to Nervos to develop)

Q10: What are the next actions in terms of ecological applications?

Jan: Next, there are 2 key points, both of which are on Layer 2.

In general, you can think that Nervos will have an overall upgrade from bottom to top, from 1st floor to 2nd floor in 2022, CKB’s hard Fork may be the beginning, and the next step is Godwoken's upgrade from V0 to V1. This is also a very large upgrade, with many, many changes. One of the core purposes of these changes is to make Godwoken as a whole compatible with Ethereum Sex is better. We may have achieved 95% of this compatibility before, and the remaining 5% has not been done well. This time we want to fix all these problems together.

(Godwoken V0 version) The remaining 5% did not do it because it is a bit difficult, because we are on a new PoW chain, in UTXO There are actually some challenges in making models compatible.

But this time we think it will be a relatively big improvement. This year's ecology, more development may appear on Godwoken V1, not on Godwoken V1 CKB, because I just said that CKB is the kernel, it is far away from the application, you have to have more hard-core skills to be able to write on CKB, because you may need to use Rust, you have to understand CKB Programming model, syscall, etc., but on Godwoken, because it is fully compatible with Ethereum, there is already a whole set of ready-made tools, and it will be easier for you to do this. It is relatively easy to develop on Godwoken at present, and V1 will further lower the development threshold.

On the whole, we are not only going to explore new paths, but at the same time we are going to be compatible with Ethereum. Attract them first, and gradually guide more developers to Layer 1 through the prosperity of Layer 2. After a developer is familiar with Layer 2, he may inevitably have to get in touch with some concepts of Layer 1, the concept of CKB, and the technology stack of CKB. In this way, first there is a huge group of Layer 2 developers, and some developers who are interested in Layer 1 will gradually come out, and they will naturally delve into the lower and deeper things slowly. Just like you do application development, you write iOS App, you write and write that your App has become 10 million users, you may inevitably have to think about the internal design of iOS, how does the bottom layer work? It is impossible for you to care about these things from the beginning, because you only serve 100 users, and you only need to pay attention to the application itself. This threshold is very low.

So, at this stage, I think the ecology on Godwoken will develop faster.

On Layer 1, there are also some very hardcore teams, .bit (called DAS before brand upgrade), UniPass, Kollect, < a href="https://learnblockchain.cn/article/mibao.net" target="_blank" rel="noopener noreferrer">mibao, the challenges they face will be greater, or conversely, CKB The challenges for them are greater, but these projects can also take advantage of the benefits brought by the characteristics of CKB more directly, which has advantages and disadvantages. Generally speaking, the ecology of Layer 1 will develop more slowly.

Another important point is, Axon may be launched in the second half of the year, depending on whether there are projects to use it. Axon is characterized by good performance, and its performance may be better than all chains currently on the market. (As a Layer 2 solution of Nervos, Axon can easily achieve thousands of TPS by using Overlord, a high-performance consensus algorithm. This provides another choice for Nervos dApp developers. Godwoken is very suitable for low throughput and high value situations , such as DeFi, where security is often more important than speed. In consumer-facing applications such as decentralized games or social networks, Axon provides the best performance.)

This is the benefit of layering, the benefit of Layer 2, you don’t need to have good performance and consider some Layer 1 things like some chains, it’s very moderate. Since I am Layer 2, I can optimize performance.

If Axon goes online, its ecology should also develop faster, because Axon is also fully compatible with EVM. We have learned a lot of experience and lessons in the development of Godwoken V0, and these experiences and lessons have been absorbed into the design ideas of Godwoken V1 and Axon.

I know the developer relations team of Nervos Foundation. They have been very active recently and have talked about many projects. not sure.

Q11: Could you tell us about the Godwoken V1 upgrade plan?

Jan:I estimate that the testnet will come out in mid-May, and after the testnet comes out, many projects will start testing Online development and testing; it is estimated that the test network stage will last for about a month. If no major problems are encountered within a month, the main network can be launched, so the main network launch may be in June.

Q12: Can you give an example, what are the current popular applications or applications that you think may be more popular in the future, which cannot be implemented on ETH or other public chains? Or is it very difficult to implement, and can only be realized based on CKB development?

Jan:First of all, this should be divided into two aspects: theory and practice.

First of all, in theory, the so-called new generation of public chains can achieve anything, because the new chains are basically quasi-Turing complete.

But in fact, each chain will have its own good direction, its own unique place, or something that is easier to do. For example, Ethereum, it is easier to do DeFi applications, which is very obvious, because the design of its entire contract model is very suitable for DeFi. It keeps accounts, it has accounts, and there are balances in the accounts. This is very suitable for the financial system.

There are also very suitable things on CKB, such as NFT, which is very suitable for the UTXO model. Essentially, every UTXO is an NFT. For example, a very interesting point that can be achieved on CKB is that when you transfer NFT, you don’t need to pay additional handling fees, or if I give you my NFT, you can send this NFT To others, you just transfer it directly. In this NFT user experience, it may not have the concept of CKB. He did not realize that he actually paid for CKB. All he sees is NFT, which is actually very friendly to users. .

For example, I gave you a football card, and you think this football card is very good, so you give it to your friend as her birthday present. At this time, if I say to you: "Wait, you can't transfer yet, you have to buy some ETH before you can transfer, otherwise you have no money to pay the handling fee, no money to pay the gas!" This user experience is very bad.

Have you noticed? You may not be aware of it, because you are used to the set of rules set by Ethereum for you.

But if you are from the first principle, or if you are from the Internet world, you will find this very awkward.

The Internet is not like this, and I am not like this in reality. When I send you a greeting card as a gift in reality, no Fed will jump out and say, come on, you get $1 from me to pay the handling fee first, which is a very strange model.

If NFT is very suitable for CKB or the CKB model, I think an interesting direction of exploration is that we can actually make a Cell model on Layer 2 chain. Because we have limited time now, we can only give priority to Layer 2 of the account model. If we have more time, we can actually do UTXO or Layer 2 of the cell model, and then build the account model on top of Layer 2 of the cell model. These can all be done, and these different designs have different benefits.

Another example.

Because CKB is a model of Bitcoin, I don’t know if you have noticed, but both Bitcoin and CKB have a feature that failed transactions are not on the chain. Even if you use a dApp on Ethereum, if you fail, your transaction will still be on the chain, and you will still be charged a handling fee. This is not the case with Bitcoin and CKB. Failed transactions will not be uploaded to the chain, and you do not have to pay extra fees for your failed transactions.

From the perspective of a natural person, this is reasonable, and the design of Ethereum is unreasonable-if your bank tells you today: "Uh, I'm sorry, I failed to open a bank account for you, but I still have to charge you a handling fee of 100 yuan", or "Sorry, the wealth management product you want to buy is sold out, and your quota is gone, take the money Refunded to you, but I will deduct 1% of the handling fee."

Do you think it is reasonable? You must feel unreasonable! The real world doesn't do that.

But there is a reason why Ethereum does this: because it is difficult to safely implement execution analysis before going to the chain based on the account model. If the failed transactions are not allowed to be uploaded to the chain, there will be a risk of DoS. There is a whole set of security-based reasons behind it. From a technical point of view, it is reasonable; but from a user experience point of view, it is not reasonable.

The above are some interesting points of developing applications based on CKB. In general, when you redesign a completely different system based on a very different principle. For example, if one system goes to the left and another system goes to the right, they must have many, many different details and different capabilities at the upper level. So you ask what is impossible or very difficult to achieve on other chains, simply put, there is. Just gave 2 examples, are there more? We need to explore together. For example, the very interesting feature of NFT was told to me by the magistrate of UniPass, and I didn't think of it at the time.

Our entire community is actually developing and exploring while exploring. I don’t think anyone can tell what can be found out. The only thing that is clear is that we are clearly going down a different path.

Welcome to join the official BlockBeats community:

Telegram Subscription Group: https://t.me/theblockbeats

Telegram Discussion Group: https://t.me/BlockBeats_App

Official Twitter Account: https://twitter.com/BlockBeatsAsia