This article will explain in detail Nervos’ generalized UTXO model- the Cell model

The Cell model combines the best of 2 worlds-the programmability of the Account model with the scalability & flexibility of UTXOs

It’s abstract nature provides devs & users new possibilities

An interesting caveat of the Cell model is that it’s focused on state (on-chain data)

Cells contain arbitrary data, which could be simple, such as a token amount and an owner, or more complex, such as code specifying verification conditions for a token transfer.

CKB’s virtual machine (CKB VM) executes scripts associated with cells to ensure the integrity of transactions.

In addition to storing data of their own, cells can reference data in other cells, allowing for assets and the logic governing them to be separated

This is in contrast to Account-based blockchains, where on-chain data is an internal property of a smart contract & is accessed through smart contract interfaces.

On CKB, cells are independent state objects that are owned by users & can be referenced and passed around directly

Consequently, Account Abstraction comes by default on CKB, providing a superior experience for users & flexibility for developers

The Cell model is abstract, where cells are simple storage without any internal structure. Their layout is completely left to developers to customize

Moreover, the Cell model perfectly complements Nervos’ modular design, allowing the capabilities of CKB to evolve without disruptive hard forks

Almost all algorithms, cryptographic primitives, and data structures can be implemented on CKB as scripts stored within cells.

This means that cryptographic primitives aren’t hardcoded or baked into the virtual machine like in all other blockchains, making CKB the most flexible and future-proof Layer 1 in the blockchain industry.

In other words, dApp developers on CKB can use all crypto primitives, including Schnorr signatures, BLS signatures, zkSNARKs, and zkSTARKs, to build their dApps without affecting anything else running on-chain.

To see this in practice we can take the case of the threat of quantum computers breaking commonly used cryptography.

CKB is the only chain that can allow users to move their assets to be secured by quantum-resistant cryptography without requiring a hard fork, permissionlessly.

This is due to how the Cell model works. All assets, including user-defined tokens & NFTs, are first-class citizens on-chain

Assets aren’t subject to overriding control by smart contracts. They’re secured by conditions specified by their owners.

Token contracts only store a token’s operating logic, such as “issuance cap=1,000,000” or “inflation rate=50 tokens per block”

A user’s asset balance “Alice owns 100 tokens” is contained in a cell controlled by Alice

This significantly increases security of assets held on CKB

In contrast, if a hacker manages to break a smart contract controlling an ERC-20 token (code is law), they can steal/alter token owners’ balances

On CKB, this isn’t possible. Assets are not controlled by smart contracts but owned by users directly.

In summary:

→ On CKB, a cell is a “first-class citizen,” meaning user assets are solely the property of a user, not subject to loss via a smart contract

→ A cell is simply storage without any internal structure, with its layout completely left to developers.

The Cell Model — A Generalized UTXO Model was originally published in Nervos Network on Medium, where people are continuing the conversation by highlighting and responding to this story.

5. PoS mining pools are more inclined to embrace regulations and censorship of transactions.

Terry: You mentioned earlier that early all PoS proponents, even the most aggressive defenders, have to admit that PoW works better in terms of permissionless. Some audiences will not agree with you, as they think PoS never weakens the permissionless. Cipher, can you give us some examples to illustrate this point?

Cipher: There are mining pools for PoW and PoS blockchain projects, where you can provide a hash rate or stake your tokens. There was a time when someone attempted to create an anti-mining pool mechanism for PoW and PoS but failed because it was impossible to achieve both technically and economically. A system will undoubtedly have a division of labor once it reaches a particular stage, with someone providing the hash rate, packing the transactions, providing delegate services, etc. It’s very typical.

PoW and PoS both have mining pools that regulators may shut down; hence some people would claim that they are equivalent in decentralization to each other. This is not correct.

For example, over 66% of the beacon chain validators will adhere to OFAC regulations. It’s easy to understand why. Why? Because PoS mining pools are more likely to be exchanges, institutions, wallets, and other types of financial organizations. They have a lot of tokens from their users. Thus, they can immediately become validators to produce blocks or serve as a PoS mining pool. Moreover, as a third party, you also prefer to trust these validators and mining pools, as they are less likely to have a rug pull.

For the PoW mechanism, if you don’t like the mining pool, you can switch your hash rate and use the service of another pool very quickly. The settlement cycle of PoW pools is also concise, probably daily or even shorter.

The settlement cycle of the PoS mining pool is much longer, probably 30 days before you can withdraw. In this case, users favor mining pools with a better reputation, as they are less likely to have a rug pull. These mining pools (usually the exchanges, institutions, wallets, and financial organizations) are more inclined to embrace regulations, as it brings no harm but more benefits and protection.

So, from the perspective of mining pools, you will find that PoS mining pools are naturally more inclined to embrace regulations and censor your transactions than PoW mining pools.

Some may ask, “Why are adopting regulations bad? Money laundering, terrorism, and the use of child pornography are all unacceptable practices. Blockchain initiatives sooner or later must embrace regulations if they are to go mainstream.” This argument has a flaw: when you embrace regulations, whose nation’s rules will you adopt? U.S., Russia, North Korea, or Iran? The problem is that these regulations are often in conflict, which will lead to many issues.

6. What will happen when Ethereum is censored at the protocol level?

Terry: I’d like to expand a little bit on Tornado Cash. A poll on Twitter asks, “If regulators ask you to censor at the Ethereum protocol level with your validators, will you comply and censor at the protocol level, or shut down the staking service and preserve network integrity?” In this statement, let’s focus on protocol-level censorship. I think there are two possibilities. One possibility is that these validators are not allowed to, and will not, pack transactions connected to Tornado Cash; another option is that even if they do not pack such transactions, other validators always do, and these validators refuse to accept them. The second possibility would probably lead to a soft fork. Cipher, what do you think of these two possibilities? Does the first possibility also belong to protocol-level censorship?

Cipher: I believe so. It is protocol level if it interferes with the block or the consensus. Because the process of creating blocks could be quicker without intervention, or the system might react to your transactions more rapidly. If the validator doesn’t respond to your request for asset liquidation timely, you may suffer a significant loss.

Terry: OK. On that basis, let’s move on to the next question. If protocol-level censorship happens, what do you think it means for Ethereum?

Cipher: Well, it’s entirely possible that it has already occurred, and we’re just unaware. Although you may be aware that your transaction is constantly pending, a third party cannot see it since it is not included in the block, and there are no methods to see your pending transactions. There is no way for us to know if protocol-level censorship is being employed.

If protocol-level censorship happens, let’s make a reasonable deduction. First of all, governments will publish censorship policies. The problem is which government you will obey. The U.S. said Russia was terrible during the Russia-Ukraine conflict, and Russia claimed the contrary. When the situation between Russia and Ukraine broke out, I was in Thailand, where there were many Russians. They were irritated when their credit cards were suddenly restricted due to financial restrictions. If it is censored at the protocol level in the future, it will have a significant impact. For instance, if country B imposed restrictions on country A, no one could use their Ethereum accounts. In reaction, country A will begin to impose restrictions on country B and ask to block all accounts created by people in country A. This may sound awkward, but it will happen if protocol-level censorship exists.

Another possibility is that the blockchain becomes Wall Street under protocol-level censorship, where financial applications run on it. These financial applications must be compliant. Therefore, anonymous accounts are no longer valid, and everyone must undergo the KYC procedure. Even the DIDs are transparent to the authorities. In this scenario, all public blockchains will become consortium blockchains in essence.

Terry: Well, this sounds like a road to slavery?

Cipher: Yes, but some people may disagree.

Terry: So, in your opinion, if the protocol level censorship is applied and we go down in that direction, is there a chance that the blockchain will become the next Wall Street, with a slighter improvement?

Cipher: Indeed. It all depends on which perspective you’re speaking from. If you look at it from the standpoint of permissionless, which I care about most, then it’s only slightly better. But in the eyes of traditional financial institutions, it is much better since it increases the financial system’s openness, transparency, and efficiency. An obvious example is the USDC. The encrypted dollar USDC is more advanced than traditional dollars in terms of competitive advantages.

Terry: For me, protocol censorship is a terrifying thing. But, some people consider it a good thing because censorship will help the blockchain project go mainstream. What’s your opinion?

Cipher: I think blockchain initiatives need to be regulated in some way and should go mainstream, but I don’t want regulations or censorship to apply to layer one blockchains. I’ve said several times that accepting censorship or restrictions makes it reasonable to wonder whose principles you accept, as the regulations of different countries may be conflicting.

There shouldn’t be value judgments or right and wrong conclusions on layer one blockchains. Right and wrong are relative, not absolute, just as good and bad are. The consequences of a value judgment error are severe.

Because of this, I believe that we should at least maintain total freedom, justice, inviolability, and unrestricted and uncensored rights on layer one blockchains or layer 1 of a particular public blockchain. I believe it is possible to embrace regulations and go mainstream on layer two or other higher layers.

7. Using Social Consensus to Ban Validators

Terry: Someone launched a survey poll in the Ethereum community. If validators comply and censor at the protocol level as requested by the regulator, will you consider the censorship an attack on Ethereum and burn their stake via social consensus or tolerate it? Vitalik chose the former one. What do you think of Vitalik’s choice?

Cipher: I guess it’s best not to comment. “Consider the censorship an attack on Ethereum and burn their stake via social consensus” if Vitalik had not chosen this, but someone else did, he would have been under attack because the logic is very muddled. Burning validators’ stake via social consensus is impossible and not feasible.

First, there is no answer to what social consensus means. How do you organize the vote if it’s a community vote or a decision made by the majority? How do you guarantee that the vote is fair and accurate?

The crypto community has outstanding checks and balances. For instance, there are several independent checks and balances in the Bitcoin community, including miners, developers, wallets, and exchanges. The community acts as a check on one another. If the developers submit a feature that miners want to reject, miners can do a hard fork.

There used to be checks and balances in the Ethereum community. The mines were weakened by EIP-1559 and will be ruined by the Merge. In other words, the Ethereum community lacks the potential to build social consensus, as there is no such check and balance power. Ethereum developers lack control since validators can reject them and won’t vote against them. Therefore, in the end, only Vitalik can stand out and inform the community of which validators should be prohibited since they are enforcing censorship. Calling this social consensus is ridiculous, as it is not the consensus but the will of Vitalik. Why would Vitalik choose this option on the poll? Because the second option, tolerating censorship, is unacceptable for Vitalik. So burning validators’ stakes via social consensus is not possible and feasible.

Terry: I was baffled when I saw the word social consensus. It seems that you are also confused.

Cipher: I guess Vitalik doesn’t know what social consensus means either.

Terry: The CEO of Coinbase said that they would shut down the staking service if the validators were to apply censorship. Although it hasn’t happened yet, I think he’s making a very noble choice. If protocol-level censorship occurs, and all validators must make a noble choice, isn’t that a problem?

Cipher: Yes, it is. It’s a moral choice, not an economic one. The most significant appeal of blockchain is that it takes advantage of the selfishness of all people to achieve a public good. You can’t ask validators to be selfless and noble and not let them earn money because of censorship or unreasonable demands.

I’m sure Coinbase is sincere about this, but it doesn’t help nor solve the problem of avoiding Ethereum being censored at the protocol level.

Terry: Would things be different if it happened with PoW?

Cipher: I think it would be different. Firstly, shifting from one PoS mining pool to another is difficult, as the settlement cycle is very long. However, shutting down one PoW mining pool and creating a new one is very easy. So if the PoW mining pool doesn’t want to obey the regulation of censoring, it can shut down and create a new one in other regions.

Secondly, the connection between miners and the mining pool is weaker than that of PoS. Miners don’t deal with transactions, they are working hard to solve the mining puzzles, and therefore they are not capable of applying sanctions. Moreover, miners can switch their hash rate from one mining pool to another at any time.

To conclude, it’s more difficult for regulators to ask PoW mining pools to censor transactions at the protocol level.

One more thing, Ethereum employs the account model, not the UTXO model. The UTXO model used by bitcoin makes censorship more difficult. Because one UTXO blockchain address can derive a list of new addresses, making it more challenging to track as the sanctions are often lagging. The OFAC published a list of banned bitcoin addresses, but it had little effect.

MEV and Flashbots can potentially weaken the decentralization of Ethereum. MEV, which refers to Maximum Extractable Value, is built to extract value from Ethereum users through block production. Above MEV, there are Flashbots, which can arbitrarily include, exclude, or re-order transactions from the blocks. Flashbots is centralized, although it is open source now. Forcing it to censor transactions is much easier as many Ethereum mining pools use it to maximize profits.

Terry: My friends think it’s possible to decentralize the Flashbots since many PoW mining pools used to provide tools similar to Flashbots, which allows you to send transactions anonymously. After the open-source of Flashbots, they might upgrade the tools. We skip this topic as we are not experts on this. I’m wondering if miners’ revenue will also incentivize them to be more proactive in switching PoW mining pools. If one mining pool has to ban several types of transactions, the fees paid by these transactions will not be gained by this mining pool. So, in this case, will miners switch to a pool that doesn’t need to censor transactions to maximize profit?

Cipher: I think they will. The gas fee paid by these banned addresses will be much higher to attract mining pools (without censorship) to pack and confirm their transactions. Rational miners will likely switch their hash rate to these pools for higher profits.

Recap of PoW vs PoS discussion on Fork It Podcast — Part 2 was originally published in Nervos Network on Medium, where people are continuing the conversation by highlighting and responding to this story.

Crypto currency mixer Tornado Cash has been sanctioned by the U.S. Department of the Treasury’s Office of Foreign Assets Control (OFAC). Currently it looks like over 66% of the beacon chain validators will adhere to OFAC regulations.

The Merge is on the horizon and Ethereum is about to move its consensus mechanism to Proof of Stake (PoS). Will Ethereum face protocol level censorship after the Merge? If so, what will this mean? Would it be different if its consensus mechanism was PoW?

In this episode of Fork It, a Chinese podcast program for blockchain technology, our host Terry (co-founder of Nervos Network) invited Cipher, founder of Nervina Labs, to talk about PoW and PoS in depth.

Here is the full recap:

1. Introduction

Terry: Good day to everybody. In this episode, we’ll discuss what you might consider a cliché, PoW vs. PoS. It has become a hot topic due to recent events like the sanction against Tornado Cash and the upcoming merge of Ethereum. We have our old friend Cipher here to discuss this topic this time. Cipher, please say hi to everyone.

Cipher: Hello, everyone. I’m Cipher.

Terry: Although Cipher is an old friend, there could be some new listeners; therefore, I’d prefer if you started by sharing your blockchain-related experiences.

Cipher: I am a veteran, although a pretty inexperienced one. I learned about Bitcoin in 2013, but I was not a believer then. I regarded bitcoin as a practical T+0 investment at the time because I was working on other endeavors full-time. I created a trading bot at the time and earned about ¥300,000 from only a few thousand.

Terry: A quick question. Were you superior, or were the trading competitors too weak then?

Cipher: At the time, there were few trading bots. Hence there weren’t many rivals in the market. My approach was fairly simple: purchase after two consecutive upswings and sell after two straight downturns. I earned money that way. There was a window of time, perhaps two or three months, after which this tactic ceased to be effective. Then, I stopped for several reasons, including regulatory concerns.

I didn’t enter the blockchain industry until 2016 when I started to work on research and products of a consortium blockchain project. After that, I joined the public blockchain project until last year; then I began working on an independent NFT project. I started a new project this year and have moved to Singapore to do something big.

Terry: Cool! I will first provide some background information to set the stage for our discussion on PoW vs. PoS today. The recent sanction against Tornado Cash protocol by the Office of Foreign Assets Control (OFAC) of the US Treasury Department and the arrest of one of its core developers in the Netherlands caused a stir. It’s a big deal, and some centralized organizations, including exchanges, wallets, and even the front ends of some blockchain applications, are active in banning addresses that connect with Tornado Cash.

Another background is the upcoming merge of Ethereum, where its consensus mechanism will be upgraded to PoS.

The third background is that it currently looks like over 66% of the beacon chain validators will adhere to OFAC regulations. A poll was launched on Twitter on the possibility of these validators censoring Ethereum at the protocol level in the future. Since there is a significant difference between the two in terms of how they handle protocol-level censorship, the debate between PoW and PoS has become more intense.

Therefore, there is a necessity to produce an episode to talk about PoW and PoS. This is also an opportunity to dispel some common misunderstandings regarding PoW.

2. The Relationship Between PoW and PoS

Terry: First, let’s limit the scope to layer 1 because there may be different choices beyond this scope. Cipher, should our future global money be built on PoW or PoS? What is the relationship between PoW and PoS? Is PoS a progressive, a regressive, or are they not progressive or regressive, but rather like left and right?

Cipher: I think PoS and PoW are two choices of the path. There is no progress or regression.

I want to clarify that PoS and PoW are two methods of selecting the node to produce blocks. They are not the entire consensus mechanism. The consensus mechanism should include at least other equally important things, such as which chain is the right one when there are forks, block rewards, punishment, etc.

From the perspective of selecting the node to produce blocks, PoW is connected to off-chain variables, such as hash rate, energy consumption, chips, electricity prices, local regulations, etc. In contrast, PoS is more connected to on-chain factors, such as token distribution, staking percentage, etc.

So it is easy to understand that PoW and PoS have nothing to do with who replaces whom or who is more advanced. They choose two separate paths, one relying on off-chain variables and the other depending on on-chain factors to determine which node will produce the next block. They are designed to fit different use cases.

I wrote a blog post titled Mining to the Left, Staking to the Right a few years ago, and I used left and right to describe the relationship between PoW and PoS. My opinion is unchanged.

2. Two Types of Public Blockchains

Terry: I vaguely remember you mentioning two types of public blockchains in that blog post. Can you explain a bit more?

Cipher: There are two typical application scenarios for blockchains. One is anti-censorship, similar to bitcoin fundamentalism, which entails seizing control of your property rights. The ability to build dApps or DeFi applications on the blockchain and improve TPS is less important than the core task — anti-censorship. This is one direction for public blockchains.

Another direction is designed for open finance, which is not necessarily decentralized finance. Compared with the current financial system, open finance is already a very revolutionary thing. We can build incredible financial applications on it, and third parties can be added to the monetary system. The so-called DeFi can significantly improve productivity and economic efficiency. Users may not be so concerned about whether it is resistant to censorship and may even embrace the regulation.

In short, the first type of public blockchain mainly solves the problem of how to resist censorship. In contrast, the other type mainly solves the problem of global collaboration via open finance. Can these two types of public blockchains be merged? It is possible, but they must be in different layers. If you want to merge them all in the same layer, such as in layer 1, I don’t think you will succeed as there is a technical limit. There must be a trade-off.

Terry: When you wrote that blog post, you must have classified Ethereum as the first type of blockchain, right?

Cipher: Yes, at least the notion that Ethereum Foundation and Vitalik were promoting to the public tells us that Ethereum belongs to the first type. However, it turns out to be more like the second type of blockchain. The result speaks louder.

Terry: So, after the merge to PoS, Ethereum is more likely to be the second type of public blockchain, right?

Cipher: Yes. The reason why there are now so many arguments about Ethereum is due to the path it chooses. It is not a technical problem but a choice problem from different approaches. For example, there’s also a lot of controversy on Ethereum EIP-1559. You can find out that EIP-1559 does not help to improve TPS, nor does it reduce the gas fee. It only weakens the rights of miners. This is the choice Ethereum made, and it has nothing to do with technology but political things.

4. PoW or PoS, which is more suitable for layer 1 blockchain?

Terry: We narrowed down the topic to layer 1; we want to serve as global money and be the first type of public blockchain you mentioned above. I believe you also favor PoW over PoS; am I correct? What are your thoughts about that?

Cipher: Yes. I need audiences to think about one question: What is blockchain’s core value? Or, what kind of problems does blockchain solve?

This question was discussed frequently before the massive emergence of DeFi applications. At that time, the blockchain only had a payment function, which was largely weakened due to various reasons. For example, many users regarded bitcoin as a SoV (store of value) and were less willing to pay for things in bitcoin. There were few applications, and users repeatedly asked “why should I use Bitcoin?.”

The application layer has been the center of attention for the previous two years. As NFT and DeFi applications grow in scope, users appear to be less concerned with blockchain’s core value. That is a meta question and one of the most important ones in the blockchain world. Many later things are genuinely in the air if that question is not fully discussed.

In the past years, there were many labels for the blockchain, such as a non-reversible public database, a global computer, etc. All these labels are right, but one definite key word is missing: no permission is required. Blockchain is a license-less, tamper-evident global public database, a license-less global computer. All of these labels are accurate but missing one important word — permissionless. Blockchain is a permissionless non-reversible public database and a permissionless global computer.

If you remove the word “permissionless,” you’ll find that you don’t need a blockchain to achieve it. A non-reversible public database can be created via hashed digital signatures, and a global computer can be achieved with the help of Amazon cloud service or some open APIs. Permissionless can only be achieved through a blockchain.

I believe that the blockchain system is the first and only open system created by humans that is permissionless. All other systems require permissions; to use them, you must, for instance, use your ID card to create an account or have someone else make an account on your behalf. Therefore, things like performance improvements, privacy protection, cross-chain bridges, sharding, NFTs, and so on are the tall buildings sitting on top of the foundation of blockchain technology, which must first be established well.

PoS outperforms PoW in several aspects, including performance, energy consumption, etc.

However, nearly all PoS proponents, even the most aggressive defenders, have to admit that PoW works better in terms of permissionless. Anyone can send a transaction in PoW since there is a considerably lower entrance barrier, while PoS weakens the permissionless for various reasons. So, in my opinion, PoW maintains the ideological stance of permissionless, and it has to make sacrifices in other aspects.

PoS has gone farther and farther down the road of practicality. Delegate service was unavailable in the early PoS blockchain projects, but it was eventually added. The later PoS blockchain projects, like Solana, are becoming increasingly centralized. You will find out that they have started to operate more and more like the traditional financial systems.

I think PoS blockchain projects are more like the next generation of central banks or Wall Street, with greater openness. Data is more accessible as anybody can access and read it on-chain, but there is no assurance that you can write data on-chain or won’t be censored when you write the data.

The PoW mechanism has always represented a rebellious force against financial tyranny. You can go to Wikipedia and search for “Cantillon Effect,” an effect related to the money supply, for a better understanding of economic tyranny.

Therefore, I believe that the PoW mechanism will probably never become mainstream because of its limited performance, even though it is incredibly hardcore. However, I would find it quite dull if PoS were the only consensus mechanism surviving in a decentralized world. That’s why I am firmly in favor of PoW.

Recap of PoW vs PoS discussion on Fork It Podcast — Part 1 was originally published in Nervos Network on Medium, where people are continuing the conversation by highlighting and responding to this story.

Q5: According to the introduction, the CKB address will be unified to a new format after the mainnet upgrade. Does this mean that the CKB wallet address of all dApps will be the same in the future, and there will no longer be a situation where one application has one unique wallet address?

Jan: This is an interesting question because it has something to do with the design of CKB.

First of all, after this mainnet upgrade, the address format will be unified into a fixed-length format, at least for the default address. Why should I emphasize the word “default”? Because the address format used by the developers and applications is decided by them, they have the freedom to choose, and there is no way to force it. The address format is just a standard, and everyone is free to choose whether to use this standard or not. What has changed this time is the default standard: the previous problem is that the default standard contains two formats, a long address and a short address, and the new standard has only one format.

However, this does not mean that the CKB wallet address of all dApps will be the same.

If the address is not the same, it does not necessarily mean that the user experience will be bad. The two issues are separate and independent.

From community feedback, we know the reason why people hate long addresses and short addresses so much. It is the user experience, which is not good. But this problem is not caused by the address format alone. For example, let’s look at the SDK layer. Assuming that our ecosystem is mature, the SDK is complete, Mercury and Lumos are all complete, then no matter what address format there is, these intermediate layers can support it all. So for wallets , developers of dApps and exchanges, as they use SDKs such as Mercury and Lumos instead of CKB RPC directly, they can ultimately achieve a good user experience.

If the middle layer is well done, you may not feel it even if the bottom layer has 100 addresses. This is the advantage of layering, because the middle layer can hide the details of the bottom layer. The previous problem is caused by the immaturity of the middle layer as the details of the bottom layer can bubble up. This is my perspective on the problem.

So, when the ecosystem is still immature, should we wait for the middle layer to mature and find a perfect solution to solve this problem, or shouldn’t we wait and just change the address format to a unified one?

We discussed this with the core team and the community, including UniPass, .bit. Finally, we decided to change the address to a unified one, at least to solve the problem at hand. In this way, no matter whether the SDK in the middle layer is doing well or not, at least the problems we encountered before can be avoided.

But in the future, there will still be multiple addresses on the CKB, and there may even be different addresses for each dApp. This is a feature of the UTXO model. The bad user experience caused by multiple addresses needs to be solved by the middle layer. So when we design Mercury and SDK, we will pay great attention to consider what kind of address it will map to if a new script comes out. If the same address is mapped, of course there is no problem. If a different address is mapped and it is shown on the surface, should the user know about this or not? How do we design it so that users are unaware of this and will no longer encounter the troubles between long addresses and short addresses? This is an issue we have to consider in the future.

So in short, we have actually adopted a temporary solution that everyone is satisfied with — a unified address with fixed length. In the future, we should discuss how the address format should evolve while still having a good user experience.

Why is it possible to have multiple addresses? This is a very interesting thing. I don’t know if you have used a bitcoin wallet. A truly authentic Bitcoin wallet, such as Electrum, or the wallet with the official client, will generate a lot of addresses for you by default. So why do bitcoin wallets do this? Won’t this cause trouble? On the one hand, this is because addresses and accounts are inherently different concepts. Because of the popularity of Ethereum, many people don’t know the differences between 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 transaction.

I don’t know if you are using one address or more 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 automatically change addresses all the time. Once you use one, it will generate a new address for you, and once you receive money, it will also generate a new address for you. In the system design of Bitcoin, addresses and accounts are two concepts: accounts do not correspond one-to-one with addresses in Bitcoin, but they correspond one-to-one in Ethereum.

In Bitcoin’s design, an account can have an infinite number of addresses. In fact, we can do it through the 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 corresponding to his account, as long as the middle layer below can help him handle it automatically. From the perspective of the account, the assets of all addresses are in the one account, although the transfer and receipt uses different addresses. So the user experience is the same.

The relationship between address and account becoming one-to-one is a shift that has occurred after the success of Ethereum. However, if you can decouple the address from the account, there are actually many benefits, one of which is privacy as mentioned earlier. Another benefit is that because I can have different addresses, my address itself is able to encode information, and this encoded information can prompt the wallet what to do accordingly. In this way, it will make the protocol between the wallet and the application more powerful.

To conclude, having several addresses under the same account is actually not critical and we can explore it gradually. It deserves research and exploration, because everyone is so used to the design of Ethereum. We improve the user experience first, and in the future, we’ll explore how the underlying design should be while maintaining a good user experience as well.

I hope you will not simply conclude that one address is good, which in fact is not. There is actually a lot of space to design. At present, we have a clear principle: when exploring the new design, we must maintain a good user experience. This is a win-win outcome that everyone will be satisfied with.

Jan Xie AMA: Part Three — The Nervos Address System Addressed was originally published in Nervos Network on Medium, where people are continuing the conversation by highlighting and responding to this story.

Q2: This is the first major protocol upgrade for Nervos layer 1 and your team has made a lot of efforts for it. Can you introduce the background of this upgrade? In other words, why does Nervos CKB need a major protocol upgrade?

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.

Q3: What problems will this upgrade solve, and what changes will it bring? What should we pay attention to after the upgrade?

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 crypto 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 VM
• block structure
• consensus rules
• P2P 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.

Q4: After the Major Protocol Upgrade, what impact will it have on projects based on Nervos?

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.

Jan Xie AMA: Part Two — A Chief Architect’s View of Nervos Network L1 Major Protocol Upgrade was originally published in Nervos Network on Medium, where people are continuing the conversation by highlighting and responding to this story.

On April 21, Jan Xie, chief architect and member of core development team of Nervos Network, was invited to attend the Major Protocol Upgrade AMA hosted by @yixiu_yx on Twitter Spaces, answering questions gathered from several community channels.

The AMA replay is available at https://twitter.com/i/spaces/1gqxvlYdPyAGB?s=20.

TL;DR

Here is a brief summary of the AMA:

• CKB seeks to extend the notion of SoV, from a store of value (SoV) to a store of assets (SoA).
• The main improvements of the Major Protocol Upgrade include: VM, block structure, consensus rules, and P2P network. The upgrade is almost undetectable to users.
• As the kernel of layer 1, CKB should be maintained as minimal, streamlined, reliable, and safe as possible. More things should be done on the second, third, or the application layer. This has always been Nervos’ mindset.
• The average bandwidth of the global network is the bottleneck of performance of public chains. The most efficient blockchain is the one that makes the most efficient use of bandwidth.
• The Major Protocol Upgrade is a type of hard fork that everyone expected and agreed to, therefore there won’t be two blockchains. Two blockchains will only occur when the community’s opinions are extremely divided, such as ETH and ETC, which is quite uncommon in history.
• The Nervos Network, which includes CKB, Godwoken and Axon, makes different trade-offs between security, performance, and decentralization:
• You may choose to build on CKB if you really care about security and decentralization;
• You may choose to build on Axon if you really care about performance;
• You may choose to build on Godwoken if you want to find a balance in the trade-offs.
• Nervos will be upgraded from layer 1 to layer 2 in 2022. The CKB hard fork comes first, followed by Godwoken, and then Axon.
• More projects will be launched on Godwoken V1 this year. Axon is completely compatible with EVM layer 2, so the number of projects on Axon will grow fast once it is released.

Q1: Jan, could you please introduce yourself and your blockchain experience to our newbies?

Jan: I come from a computer science background and first learned about Bitcoin in 2013. Since then, I’ve been doing research on cryptocurrencies and blockchain technology out of curiosity.

Many people thought Bitcoin was a hoax the first time they heard of it. This is very natural as it’s very difficult to convince that we, as computer programmers, could create a new currency back in the year 2013. That was a crazy idea, even ridiculous.

However, in terms of technology and design, I’ve noticed several really unique characteristics of Bitcoin. Its design is very different from what we were doing at the time with the Internet.

The Internet, for example, strives for greater performance and efficiency, while Bitcoin’s PoW is in poor efficiency (which is necessary if you want to keep it safe); The products of the Internet need to be polished while Bitcoin is particularly rough.

In the beginning, Bitcoin’s software was quite rough. For example, if a new node of Bitcoin wanted to join the Bitcoin network, it must first be able to find a node that was already in the Bitcoin network to connect, which we call a seed node. How did you find a seed node in Bitcoin? You couldn’t get that information through a P2P network, so you had to have an initial approach, otherwise it was an infinite loop.

Bitcoin used the IRC protocol to let the nodes of the Bitcoin network join a specific IRC chat room. You entered this chat room, and the person in the chat room was your seed node. This was a very rough and tricky method. It will almost certainly not be used in a real Internet product, but it was used in Bitcoin.

(Note: IRC, or the Internet Relay Chat, is a text-based chat system for instant messaging. IRC is designed for group communication in discussion forums, called channels, but also allows one-on-one communication via private messages as well as chat and data transfer, including file sharing. )

So, Bitcoin is such a product that is very crude in engineering yet so brilliant in design, that you can’t help being attracted and begin to study it.

After a while, my friends persuaded me to start a business together. As a result, I shifted my focus from initial interest in blockchains to the identity of builders. We overcame several barriers, and have been working in this field ever since.

At first, we built a crypto exchange named Peatio and made it open source on GitHub. My motivation to build an exchange is that I had searched GitHub for a long time and found no helpful exchange code. As the first open source crypto exchange, Peatio accelerated the development of the industry to some extent because many exchanges used our code. Some of the top exchanges nowadays were using the programming language of Ruby on Rails in the beginning. There were many connections.

(Note: Ruby on Rails, or Rails, is a server-side web application framework written in Ruby under the MIT License. Rails is a model–view–controller (MVC) framework, providing default structures for a database, a web service, and web pages. Rails emphasizes the use of other well-known software engineering patterns and paradigms, including convention over configuration (CoC), don’t repeat yourself (DRY), and the active record pattern.)

When Peatio was finished, we started to try new things, as the exchange is still on the application layer in essence, not so close to the underlying blockchain technology. We decided to do something more in-depth, so we proceeded to look into Ethereum.

At that time, Ethereum had just been released and it was very new. A lot of members from the Bitcoin community assumed it was a hoax, as there were too many altcoins. But for me, I regarded it as an exciting thing.

From a technological standpoint, Ethereum is unquestionably a step ahead if we compare it with Bitcoin, as it evolves from a crypto currency to a platform, like a phone that can only make calls to a smartphone. So I started to study Ethereum’s code, and tried to write an Ethereum client myself.

Meanwhile, I built a community named EthFans in China with my friends. EthFans used to be the most professional and largest Ethereum community in China. It was shut down for various reasons last year.

In short, I was coding and working on the EthFans community. When the research team of Ethereum was recruiting, I emailed Vitalik directly. This is a common occurrence with open source projects. You can actively contribute code and connect with developers on any open source project on GitHub, not only Ethereum. If a developer requires assistance, he may approach you. Before the research team started recruitment, I had built a client in Ruby called ruby-ethereum, which was compatible with Ethereum at the time. The ruby-ethereum successfully passed Ethereum’s own test, signifying that the compatibility of the client was so excellent that it could be used as an alternative to other clients. As a result, ruby-ethereum was included in the official documentation as one of the seven Ethereum clients at the time. I had done many things and Vitalik was aware of my work. My interest was research and I had a solid grasp of Ethereum, so I joined the research team. As a member of the Ethereum research team, I was involved in several projects — research and prototype design of sharding, Casper, etc.

At the same time, I set up a company named Cryptape in Hangzhou, China. At first, the company worked on permissioned blockchains. We built CITA, a permissioned chain that focused on performance and scalability while also being compatible with EVM. Later, the core members of CITA project left Cryptape and set up a company called Rivtower themselves. Rivtower is doing well now.

The blockchain system needs scalability, and this is what all of us have been trying to solve. There are actually two methods. One is to make every node in the network more powerful. If all nodes are more powerful, like from a laptop to a supercomputer, then the performance of the network will be much better naturally. With this method, you don’t have to do anything in system design. Another method is to have more laptops. More laptops will bring better performance and more computing power to the network. The former method is called Scale Up (vertical scaling) while the latter is called Scale Out (horizontal expansion).

If we want to Scale Up, there are actually two ways: one is to replace the laptop with a jumbo; the other is to replace the laptop with a cluster of servers. A Cluster will become a logical node, although there are actually many machines inside this logical node. This can actually form a kind of Scale Up effect, and the scalability of the network will become better. This method can only be used in the permissioned chains. We started with Scale Up and have done some very interesting projects, including working with banks and various organizations. So we have a lot of experience in high-performance permissioned chains.

We also helped SparkPool to design and implement the first version of the mining pool. Some of you may know that SparkPool is a project built by the EthFans community. Later, SparkPool became the largest Ethereum mining pool in the world, and it was shut down last year due to regulation concerns, which is a pity.

It is exactly because of my prior personal experience and ideas that we believe we may attempt to build a permissionless public blockchain, as all conditions appear to be mature. In my opinion, the public blockchain is the most challenging and exciting thing in the whole sector, because it not only needs advanced programming skills but also the integration of diverse competencies. So we initiated the Nervos project with several partners and have been working on it since then.

Jan Xie AMA: Part One — An Introduction to Jan Xie and Nervos Origin Stories was originally published in Nervos Network on Medium, where people are continuing the conversation by highlighting and responding to this story.

How can I store and transact CKB using a Ledger Nano S?

Before we begin, you will need 2 Apps: Ledger live and Neuron wallet.

Part 1: How do I use my Ledger Nano S?

Note: If you already have your ledger wallet set up, you can skip to Part 2 where I will teach you how to use it in combination with the Neuron wallet to keep your CKB safe and make transactions.

In order to start using your Ledger Nano S, you will have to download the “Ledger Live App”. Go to ledger.com/start, press on the Download button and choose the corresponding operating system, like in the pic below. After the download has completed, simply install the ledger live app.

Click on the Ledger Live App, and connect your hardware wallet to your computer with the usb that is in the package.

After you press on Get Started and accept T&C, you will need to choose your device type, in our case, Ledger Nano S.

Now, because it is your first time using this product, press on “Set up a new Nano S” like in the pic below.

You will need approximately 30 minutes to set up your ledger, and make sure you have a pen and your cards to write the 24 words.

NEVER put these words online under any circumstances.

Simply follow the instructions that are shown to you. You will need to have your Nano S connected to your computer through the whole process. If you press the left button by itself you can navigate to the left in the menu, the same goes for the right button, and if you press both buttons at the same time, you choose to activate the function that you currently have on the screen.

Click more times on your device on the right button until you get to “Set up a new device”, then press both buttons simultaneously.

The first step in setting up a new device is creating a password that will be required every time you plug in your nano S into any computer (it unlocks the device) called the PIN. This PIN is 4 to 8 digits long. The more, the better. Try to use a PIN that is easy to remember.

The left button will go through the values in a descending manner, while the right button will go through the values in an ascending manner. By pressing both buttons at the same time you choose that value that is displayed at that moment.

After the PIN is selected, the most important part of your set-up is writing the 24 words that compose your seed phrase.

All the 24 words will be shown on YOUR Nano S (on the device itself, not on your PC). Go through each word, one by one, and write it down, in the EXACT order that the Nano S shows you. Make sure they are in the correct order, otherwise you will have a nasty time in the next step.

After writing down the Seed Phrase, the Ledger Nano S will test you to check if you really have your words written. You will have to navigate through the words shown on the DEVICE, one by one, searching with left/right buttons the right words for their spot, and when you are sure about their position in the order, press both buttons to confirm. Do this for every word in the seed phrase. It is a long process, and maybe a little annoying, but it is for your own good and safety.

With your Seed phrase completed and checked, you now can create multiple copies of it and put it in more SAFE places. Never put it on anything online.

Ledger Live App will also conduct a test on your device to see if the hardware have been tampered with. Just wait for it to do its thing. If everything is fine, you should be good to go.

Usually, when you first enter in the Ledger Live App, you will have a pop-up that will require you to update your Firmware. ALWAYS update your firmware to the latest version, but do not forget that you need both your PIN and Seed Phrase for this action.

Just approve to update your firmware on your device, and it will install the new version automatically.

Now that you have the latest firmware installed, seed phrase in a safe place and you know your PIN, it is the time to install the Nervos App.

Part 2: How do I use the Ledger Nano S to store and transact CKB?

You will need to install the Nervos Network’s app from the Ledger Manager. The Ledger Nano S has a total storage room of about 138 kb. The Nervos app is 44 kb, so after the installation, you will have 98 kb left for other apps.

After you installed your Nervos App on the Ledger Live, you can see the app itself in the menu on your Nano S. Use both buttons simultaneously to open the menu on your Nano S.

Go to the Configuration option and press both buttons at the same time. You can choose what Addresses you want (mainnet or testnet), and for the more advanced users, you can choose to enable Hash Sign and Contract Data.

NOTE: Every action you do from this moment, make sure that you Nano S is already plugged in, so you do not miss any important steps.

Now you want to connect your Ledger Nano S to your Neuron. After you set up your Neuron, go to Help, and then press Settings.

The following should be showed:

IMPORTANT!: Before you go any further, go to your Nano S Nervos app and press both buttons at the same time, thus entering in the Nervos App. Without this step, your Neuron Wallet WILL NOT recognize the Nano S.

After you do this step, go back to Neuron Wallet. Click on Select your Model, and press Nano S, while being in the Nervos App in your Nano S.

REMEMBER! : before you press NEXT, you need your Nano S hardware wallet to already be in the Nervos App like I just showed you.

Press Next. If you respect the steps, you should see something like this.

You will need to confirm the connection between Nano S and Neuron Wallet.

Check your Nano S: you should see the public key, and the possibility to REJECT or ACCEPT the connection. Press both buttons at the same time on ACCEPT.

You will need to choose a name for the imported Nano S public Key.

After you successfully imported your Nano S public address to your Neuron wallet, you should see both your wallets on the main menu, just like this:

From now on make sure that you are always sending CKB to the Nano S public address, by choosing the Nano S wallet as the default. Always double check.

Go to Receive: you can see your Nano S public address. UNLIKE the neuron wallet’s public address, the Nano S public address will NEVER change. It will always remain the same, because the extra security is offered by the hardware wallet itself.

This is what you should see on your Nano S when you Press Verify:

And this is what you should see after you successfully verified your Nano S public address on your Neuron Wallet:

Now that you fully verified your public address, you are ready to do your first transactions. Of course, to deposit is a very easy task and does not involve the use of your hardware wallet at all. You just need your public address (that has just been confirmed in the previous step) and copy-paste it, like any normal transaction.

Ledger Nano S keeps your funds safe, because it does not let you SEND CKB from Neuron wallet WITHOUT hardware confirmation.

Press Send. You have to confirm this transaction on your Nano S by pressing both buttons at the same time on the ACCEPT option.

Press Sign, and sign the transaction on your Nano S. It should look like this:

Remember that your hardware wallet is not storing your CKB, but it is storing the KEY to access your CKB on the blockchain. Always keep your seed phrase in MULTIPLE places and ALWAYS offline (no photos, video, cloud, notes, anything).

Try to memorize your seed phrase.

The combination between a hardware wallet like Nano S and a full node wallet like Neuron is the most powerful, security wise, because every hardware wallet signed transaction will also be validated by your own full node.

Thank you for reading, I hope it made your life easier!

~The Nervos Doc

Nervos x Ledger Nano S Tutorial was originally published in Nervos Network on Medium, where people are continuing the conversation by highlighting and responding to this story.

Following on from our partnership announcement with NFT protocol IAMM, Flow, one of our community members, decided to take a deeper dive into what makes Nervos a good platform for NFTs.

Below is the comprehensive write-up from Flow that we think makes some good points. Enjoy!

Why Nervos is the best platform for NFTs

“The chart below shows the Google trends for Bitcoin and NFT from Jan 2021 to April 2021, NFT interest was very low before Feb 1 and started to explode in March, NFT clearly becoming popular among more people.

On the one hand, it may be because NFT is new enough for people outside the crypto space, and the concepts of ”unique” and ” “scarcity and collection” is very interesting.

On the other hand, there are some iconic events. On March 11 the artwork “Everyday: The First 5000 Days ”by surreal artist Beeple sold for $69.53 million at Christie’s; Celebrities such as Elon Musk, the CEO of Twitter, and mainstream media such as the New York Times and CCTV are paying attention to this field.

Although NFTs are getting popular and more people are starting to know about it, we have to recognize the reality that only a small percentage of people can really participate in NFT, and the threshold of using and understanding NFT is still too high, and most of it is still an insider’s game.

Whatever it is OpenSea or Rarible, when it comes to the login process, the user still has to log in using an Ethereum wallet, and that means that the user needs to understand what the public and private keys and mnemonic word are, and that part alone will keep a lot of people away. Likewise, the recipient needs an Ethereum wallet and needs to be familiar with these concepts.

For example, if an artist sends an NFT and he wants to transfer it to his supporters that may have never tried blockchain before, in this case, it is very complicated to educate them to create a wallet and understand how the process works, which is not conducive to interaction between the artist and his supporters, and it is also difficult to create a network effect.

In addition, the vast majority of NFTs are currently focused on digital art and games, which are simply incomprehensible to the average person, hard for them to get involved in.

Even if outsiders initially understand what NFT is, limited by the threshold of NFT use and the limitations of the scope of NFT creation, it is difficult for new users to come in if nothing is improved, NFT is likely to become a game that entertains themselves.

So, is there an optimized way to make NFT acceptable and easy to use for the general public and truly go mainstream?

Nervos has a better solution

Throughout, I think Nervos is the best platform for NFT creation and circulation, for the following reasons, which will be fully analyzed in this article.

1. Completely no threshold to use NFT

2. Send and receive NFT with no fees

3. NFT can be circulated between different blockchains

Completely no threshold to use NFT

Remember the interoperability 2.0 proposed by Nervos?

With the compatibility of the Internet infrastructure, users can enter the crypto space without threshold and perception, and creating wallets directly through biological information such as Face ID and Fingerprints ID, without the concept of complex mnemonic, which is convenient and simple. Applied to the NFT space, the user experience is as follows.

The user logs into a platform that uses Nervos Interoperability 2.0 components (e.g. PW-Core), creating and logging into a wallet using biological information such as Face ID and Fingerprint ID, and can send and receive NFTs. For example, he can use the wallet to connect to the NFT trading platform and purchase the NFT on it.

Compare the process of using Internet shopping applications, the user can use WeChat, Alipay, etc., to create a corresponding account within the application, and then through this account to buy goods, when the end of the purchase needs to pay, he can jump to the Alipay, WeChat page to pay for the goods.

You will find that there is no difference between the two parts, the user experience is the same, as long as the user can use the Internet, he can play NFT on CKB smoothly.

Send and receive NFT with no fees

In addition to the high barrier for users to enter into the NFT world, there is currently a relatively large problem: when transferring an NFT, you usually have to pay a high fee which is denominated in ETH.

For a user who has never known NFTs, understanding what the wallet and the mnemonic word are all about is a hassle in itself. It’s even harder for him to transfer the NFT to someone else and pay a high fee in ETH, because it means he has to buy enough ETH, which in turn adds a lot of barriers to using NFT.

The whole process is very counterintuitive and puts up a lot of barriers for users, but Nervos has come up with a very elegant solution to this.

NFT created on Nervos CKB are self-packaged, which means that the circulation of NFT on CKB does not require the user to pay an additional CKB fee. Even if Alice doesn’t have any other digital currency in her account and she receives an NFT created on CKB, she can still transfer the NFT to user Bob.

This is possible thanks to Nervos’ unique Cell programming model, which is currently only available on Nervos.

The sUDT Coffee Token released by the Lay2 team last year is a good example of this feature. sUDT actually requires only 142 CKBs to create, but there are 143 CKB in the Coffee Token, and the cost of a single transfer on CKB is 0.00000X CKB, This means that 1 CKB can handle tens of thousands of transfer transactions, which may be enough for a lifetime.

NFT can be circulated between different blockchains

Through these two powerful features above, the threshold for users outside the crypto space to play NFT has been reduced to the lowest, no annoying blockchain jargon, no abstract understanding, no complicated operation process, everything is smooth and simple.

In addition, there is another valuable advantage of creating NFT on CKB, that is, it can fully release the liquidity of NFT and allow it to circulate between different blockchain

NFT actually needs to be liquid, and it shouldn’t be trapped in one platform, otherwise, it’s not much different from the various special props in computer games. As with money, the more platforms NFT can circulate, the greater its value will be, and liquidity is a very important characteristic of the asset.

But the current solution, not to mention NFT, is that even ordinary assets across chains are a cumbersome and trivial matter, requiring two wallets to complete the cross-chain operation (like the Rainbow Bridge recently launched on Near).

Nervos’ Interoperability 2.0 allows users to avoid the hassle of switching between wallets and operating different assets on different blockchains.

Currently, you can transfer CKB mainnet Token to an Ethereum address in ckb.pw; And on CKB testnet, you can transfer CKB to Tron or Ethereum addresses with an EOS address via CKB’s PW Payment Demo; in CKB orderbook version of test DEX GliaDex, you can exchange assets(e.g.ETH-CKB) across chains with a single transaction through a single wallet.

And specifically in the NFT field, users create a wallet through biological information such as Face ID and Fingerprint ID, and he can make the NFT on CKB circulate between different blockchains through just one wallet, and the NFT liquidity will be fully released, which will bring great value to the assets.

As a practical example, through a wallet, users can make NFT on Ethereum to be collateralized on CKB and participate in DeFi project on CKB, and if users want to transfer NFT to more platforms such as EOS and Tron, they just need to sign and transfer it, there are no more complicated operations.

Note: There are already some NFT-based DeFi projects, such as NFTfi, a peer-to-peer NFT mortgage marketplace that allows NFT holders to use their NFT as collateral to borrow assets and loans, mainly to solve the problem of low liquidity of NFT assets.

At present, the blockchain project Flow, which mainly focuses on the NFT field, does not support EVM compatibility, and developers can only use Cadence to write apps, a resource-oriented programming language launched by the official team, which raises the threshold for Ethereum developers to enter the Flow ecosystem. The NFT trading platform VIV3 based on Flow, although it can be logged in by email, essentially it only binds the email and Flow account, and the logic behind it is still centralized, and the NFT created on the platform cannot be circulated on multiple blockchains through only one wallet.

So I think it would be more appropriate to make NFT on CKB than Flow. How valuable would a platform that can fully release NFT liquidity and make it easy for users to operate be?

NFT’s next trigger point: fans economy

The user threshold has been reduced to the lowest, now all that needs to do is to attract users outside the crypto space to become interested in NFT and participate in it. Speaking of this, the first NFT field that fits best in CKB has already emerged — the fans economy.

Unlike the niche market of digital art and its solitary appreciation, the power of fans united would make non-fans jaw-dropping.

The 2019 data incident for Jay Chou. The incident started when a netizen questioned Jay’s poor Weibo data and why tickets were still hard to buy, which later caused group mockery as well as Jay’s fans to fight back, ultimately allowing Jay’s Weibo super talk influence value to surge from almost negligible to 110 million in less than a week, significantly ahead of Cai Xu Kun by more than 40 million, with a total of 2.529 million posts and 42.33 billion reads in Weibo statistics.

If Jay Chou is going to release an exclusive NFT of his classic album on CKB with his signature, and a total of 10,000 copies being released, how many fans will participate in it?

The scale of participation could be hundreds of thousands, or even millions, which is not at all in the same order of magnitude compared to the tens of thousands of users in the current NFT space, and CKB does not require users to do any complicated operations.

In 2020, VeChain cooperated with the superstar Chengyu Hua to provide a product traceability solution for Chengyu Hua’s own trendy brand, and the product will be built with a blockchain NFC encrypted chip with data written in the specific production process, which will permanently bind the user’s name with the identity proof so that all purchasers have “one-to-one” ownership of the product. After that, the electronic ID card will be uploaded to VeChain, unlocking the exclusive rights of users that cannot be copied.

The “uniqueness” of the product is actually very similar to the concept of NFT, because of Chengyu Hua’s personal influence, fans were very active in participating, and the 20,000 products distributed were sold out immediately. The number of reads of relative articles by VeChain reached 180,000+, the number of retweets was 2500+, and the number of comments was 1300 plus+.

The effect of creating NFT on CKB is much better than that achieved on VeChain, because the product of VeChain is essentially just put simple data on the blockchain and then can be queried, which is something any blockchain project can do, while the NFT created on CKB is the real asset belonging to users, and it is also the “first-class citizen” of the asset, which can get the maximum protection in terms of asset security.

On the user experience side, the user could truly enjoy control and ownership of this product. “This is something unique and relative to the idol that really belongs to me”. And there is no threshold for users to participate in NFT, whether it’s logging in the wallet, buying NFT, or transferring NFT, all that gets involved is just the user signing with biological information and not feeling any part of the blockchain.

No complex concepts, no barriers at all, a truly internet-like silky smooth experience, that’s how NFT really gets out of the loop!

If Nervos plans to start from the fans economy, it is actually very advantageous. Nervos private sale in 2018 took a lot of investment from traditional investment institutions, like Sequoia China, Matrix Partners China, CMBI, etc. These institutions have invested in many film and music projects in the Internet industry, and have many stars and resources under them. As all walks of life pay more and more attention to NFT and want to participate in it, Nervos NFT eco-project is very likely to cooperate with these resources.

The opportunity of CKB go to rising

Many people complained that the CKB economic model was too complicated to understand, but we can understand its considerations better with the NFT application scenario.

As more NFT are created on CKB, more CKBytes are locked and fewer CKBytes are circulated, which has a stabilizing or even raising effect on the CKB price. This brings us back to the key point of our discussion of the CKB economic model — value capture. The higher the value of the top layer, the more value the bottom layer can capture, which constitutes a secure, stable, and sustainable economic system.

To be honest, NFT is not a logically complex technology product, it emphasizes user experience and platform resources (IP), both of which Nervos fits perfectly. Actually, Nervos solves the contradiction between the high enthusiasm of traditional organizations and media for NFT and the too high threshold of participation.

So I think Nervos is really in the right place at the right time to catch the NFT opportunity, and it could be a great weapon for Nervos to attract users from the Internet Internet and really go mainstream.

According to Cipher’s statement at the Coindesk NFT event a few days ago, the first NFT creation platform on CKB developed by his Nervina Labs will soon be online and available to everyone, so the NFT field progress in CKB is also very fast.

With the resources, the ability, the right technical direction, and the fact that no one else can copy it, I’ll see what the future holds for Nervos!

To stay updated on all things Nervos:

Join our community: Discord — Github — Nervos Talk Forum — Twitter

For discussions or questions join the conversation on Discord or check out one of our community Telegram channels: English, Korean, Russian, Japanese, Spanish, Vietnamese and Chinese

Nervos for NFTs: How Nervos is Positioned to Change the NFT Game was originally published in Nervos Network on Medium, where people are continuing the conversation by highlighting and responding to this story.

In a new series dedicated to introducing you to more of our community and team, we will be meeting some of our developers and people behind the scenes looking to make the Nervos Network expand and reach its full potential.

In this first episode, we will be chatting with Ren Zhang, the lead Researcher at Nervos, to understand what excites him in the world of blockchain and crypto and what changes need to be made in the space.

Q: How did you start your journey in blockchain and cryptocurrency?

Ren: I was mesmerized by Cryptography during my bachelor studies. It is the mathematical discipline with the strongest smell of gunpowder.

Geniuses propose system designs and destroy each other’s designs from previously unexplored angles. I enjoy reading about these dramas. Strangely, despite studying at one of the world’s centers in Cryptography, I’ve never used heavy cryptography in my research.

Like many other researchers, I joined the field of cryptocurrencies via both by accident and destiny. During my master’s study, I published a paper about using PoW to strengthen P2P networks, which eventually led to the PhD position at COSIC.

After two years of exploration in various research topics, I ended up in the nascent field of cryptocurrencies, which involve PoW, P2P, and designing and breaking systems. From hindsight, I was lucky to find an emerging field that matches well with my skill set during my doctoral study.

I learned only recently that Len Sassaman, a former PhD student of my supervisor Bart Preneel, is a strong candidate of Satoshi Nakamoto. He also had a background in P2P and committed suicide right after Satoshi disappeared and one year before I joined COSIC!

Q: What parts of the space are you most excited about in your research right now?

Ren: In the past few years, the primary focus of my research is to analyze PoW consensus protocols via tools from artificial intelligence. There is still tons of work to be done in this area.

New consensus protocols based on radical ideas are published without rigorous security analysis, which calls for justification, verification, or disenchantment. Meanwhile, existing results are constantly improved by new observations and new proving techniques, revealing insights on the theoretical limits, which may further lead us to more secure protocol designs.

Another focus of my recent research is comparing UTXO- and account-based models. This is a collaboration with the Cardano research team. I am enthusiastic about this topic as it involves so many different perspectives and seems impossible to tackle at first glance. Unlike the previous line of research where I try to strengthen every step and to pursue preciseness, in this study I would like to explore the best efforts by connecting various areas.

I will also work with my colleagues to strengthen the security and privacy of Nervos Layer two network. Who knows what the future can bring!

Q: What are the changes do you think we need to see to take blockchain to the next level?

Ren: I will limit my answer to permissionless blockchains. I think the answer lies in the social and political context, rather than the technology itself.

The necessary changes to take blockchain further: the world getting more multilateral with the US focusing more on its domestic issues and China taking a more active role in the world, and the continuous downfall of the US dollar’s supremacy as the world currency.

These changes may result in scenarios that call for a trustless platform to settle critical international issues and non-sovereign currencies to settle certain agreements. These scenarios are unimaginable to most people.

However, we have plenty of examples where the course of history changes drastically within one generation: the 20th century has witnessed the international monetary system transforming from the gold standard to the Bretton Woods system and gradually to the current US dollar’s supremacy. I don’t think the US dollar’s supremacy is the ultimate step in history.

Q: What’s the most interesting thing about blockchain that makes you want to work in the sector? Anything you dislike?

Ren: If I didn’t enter this field, I may be a postdoc at a distant university working on some obsolete ancient math problems. This rapidly-changing field of blockchain pushes me to think deeper, act faster and communicate more often, which is beneficial for my personal growth.

I sincerely appreciate it. The world-leading developers of Nervos and our impressive development and deployment productivity allow me to learn new challenges as they emerge, which is another treasure vault for a researcher.

Q: What aspect of Nervos do you think has the most power to impact the blockchain space?

Ren: I am optimistic about the future of Nervos simply because of its rational and solid design. Nervos is an ambitious project that tries to make the right choices in every aspect. It is ambitious in that we aim to offer the strongest functionalities among the competitors, and we have the skills to implement our ambition, which can be testified by the track records of our members. Its value is not abducted by any radical idea — which could be proven impractical — -or technology — which could be proven outdated as new technologies emerge.

To stay updated on all things Nervos:

Join our community: Discord — Github — Nervos Talk Forum — Twitter

For discussions or questions join the conversation on Discord or check out one of our community Telegram channels: English, Korean, Russian, Japanese, Spanish, Vietnamese and Chinese

Meet the Devs! — #1 Ren Zhang was originally published in Nervos Network on Medium, where people are continuing the conversation by highlighting and responding to this story.

Written by Jan Xie, Chief Architect and Researcher at Nervos

Shortly after the birth of Bitcoin in 2009, we ushered in an era of so-called “altcoin”, in which people experimented with various ideas to extend Bitcoin. Thousands of cryptocurrencies were created. Some of the altcoins survived, while others disappeared. Among them, the most successful is Ethereum. Why Ethereum? Prior to Ethereum, each time a new blockchain application was proposed, a new “altcoin” was created to implement that particular application. Ethereum ended that cumbersome way of evolution and introduced a generic programming model that allows developers to build any decentralized application on it. Ethereum emancipated developers from the burden of building consensus and p2p network and granted developers the privilege to allocate their precious time to business logic. Ethereum acts like an iPhone comparing to its feature phone predecessors 2, brings us the Cambrian explosion of DApps.

In retrospect, Ethereum has grown into the most valuable blockchain because it solved thousands of problems systematically while others were trying to solve only one at a time. Ethereum provides a systematic solution by asking the question at a different level — instead of thinking about how to build the next big application, Ethereum asked how to make it easier to build the next 10000 applications — is there a way better than “one application one blockchain”? That is to take a dimension reduction strike 3 against “altcoins”, which results in the birth of a new era, Ethereum’s era. The cost of decentralized application development reduced a lot, DApps boomed. Today, almost all decentralized applications live on Ethereum, they make Ethereum stronger than any other “altcoin”.

A frequently asked question is whether Ethereum is the ultimate form of blockchain or will there be a blockchain X to Ethereum as Ethereum to Bitcoin? What does the next era look like?

Blockchain Abstraction

Ethereum’s key break-through is a generic programming model (or smart contract model, interchangeable in this post) consisting of EVM and Account model on which developers can implement all sorts of application logic. The smart contract model is a middle layer that insulates developers from unnecessary underlying blockchain details and provides high programming flexibility to developers. What Ethereum does is abstraction, as its definition on Wikipedia 1 says:

In software engineering and computer science, abstraction is:

• the process of removing physical, spatial, or temporal details or attributes in the study of objects or systems to focus attention on details of greater importance; it is similar in nature to the process of generalization;
• the creation of abstract concept-objects by mirroring common features or attributes of various non-abstract objects or systems of study — the result of the process of abstraction.

From this point of view, Ethereum is an abstraction of Bitcoin and “altcoins”. Abstraction is an eternal theme of system evolution and had repeated many times before. Back in the early days of programming, we wrote assembly code, then we created high-level languages and compilers that liberated us from machine trivial and focused on more important issues. At first, we managed hardware resources directly in our own program, then we built operating systems as a middle layer and delegated those onerous tasks onto them, later we added hardware virtualization, and applications now live on the cloud. The adolescent Internet had only a few protocol layers such as TCP/IP, then there comes the application layer and we get HTTP, FTP, SMTP, etc. As you can see, examples are everywhere.

That’s why I would argue that new abstraction is the hallmark of evolution and that the next-generation blockchain must be more abstract than its predecessor. The Bitcoin to Ethereum leap was the first blockchain abstraction, and I believe it won’t be the last. As for how the post-Ethereum era might resemble, one should initially think about what can be abstracted further away from Ethereum.

New Abstractions

Ethereum’s generic smart contract model is a step forward from Bitcoin. One direction for further abstraction is to create an even more abstract one based on what Ethereum presents. As we examine the Ethereum model deeper, we can find many specific design choices embedded in it. Here’re some of the most prominent ones:

1. Account address. An EOA (Externally Owned Account) is required for a user to initiate a transaction. The address of EOA is the Keccak256 hash of the public key.
2. Sender authentication. Ethereum authenticates the sender of a transaction with two specific cryptographic algorithms, Secp256k1 and Keccak256. To create a valid Ethereum transaction, a client (e.g. wallet) must implement Secp256k1 and Keccak256 to sign the transaction. It also means the client needs a secure way to manage Secp256k1 keypairs.
3. Cryptographic primitives (algorithms used as basic building blocks in applications). Ethereum’s virtual machine, EVM, hard-coded several cryptographic primitives in it as precompiles, such as ECDSA signature verification and SHA256 hash function for developers’ convenience. Hardcoded precompiles are much more efficient than the same algorithm implemented in Solidity and thus are practical for real-world applications.
4. World state structure. Ethereum’s world state is organized as a gigantic Merkle Patricia Tree (MPT) with accounts as leaves. Each account also maintains its own key-value storage as an MPT. MPT is one of many authenticatable data structures.

These technical choices are quite esoteric to non-technical users, but nothing makes them less important than the choice of consensus algorithm or economical parameters. These choices affect Ethereum in every aspect, just like a small tweak to the Planck constant 2 could change our universe drastically 2. To build a new decentralized ecosystem would akin to creating a new universe, and these design choices are like the physical rules embedded in that universe.

The design choices were made to help Ethereum fulfil its initial goals, but they were not the best choices. For example, the chosen sender authentication algorithm secp256k1 is convenient for designers but posed unnecessary obstacles for using Ethereum in environments without Secp256k1 support. The precompiles selected is a small whitelist which basically omitted the most widely used primitives today. The MPT used in state structure was proven to be very inefficient, exacerbated the state explosion problem and induced difficulties in pricing IO-related EVM opcodes, while mispricing could lead to security problems such as DoS attacks.

The Ethereum community and other new projects have also noticed these problems and have tried different solutions. For instance, Ethereum added useful precompiles and re-priced opcodes via series of hard-forks, Tezos added support for secp256r1 for sender authentication, etc. The problem is that it’s similar to how we tackled application requirements here and there in the “altcoin” era. Furthermore, these design decisions can be more intricate than applications, and usually, no optimal solution exists, we may prefer different options in different cases. Even in the rare cases where the best choice does exist today, there’s no guarantee that it will still be the best tomorrow. A better solution, therefore, is to think at a different level, again — instead of adding new features by the core team coordinated hard-forks, can we create new abstractions and let smart contract developers do whatever they want?

Nervos CKB answered the question and created a new level of abstraction 4. For example, a CKB transaction is abstract where users and developers are not limited to the default blake2b-secp256k1 authentication, anyone can replace it 1 with blake2b-secp256r1, keccak256-ed25519 or blake2b-sha3-schnorr. CKB-VM is abstract and has zero precompiles in it, even the default cryptographic primitives like hash function blake2b and signing verification secp256k1 are just smart contracts running in the virtual machine. They run in the same environment as smart contracts created by application developers, with no special privileges. The cell model is abstract where a cell is simply storage without any internal structure and its layout is completely left to developers, as we witnessed in sUDT and xUDT. Since CKB is abstract in many regards, developers are granted greater freedoms and new abilities. CKB is an abstraction of Ethereum, just as Ethereum is an abstraction of Bitcoin. Abstraction makes CKB a simpler yet more powerful blockchain and shifts much of the work off-chain, some of which will be done on layer 2. The abstraction of Bitcoin split developers into blockchain developers who work on the underlying blockchain and smart contract developers who build applications. The abstraction of Ethereum will split smart contract developers into system contract developers and application contract developers, while the former will focus on system-level smart contracts, such as cryptographic primitives, lock scripts, and even memory management modules.

The importance of abstraction has been recognized by the Ethereum community recently 4. If accomplished I think it could make Ethereum more abstract than it is now, gives it an edge over those unable to keep up. Nevertheless, I also doubt that proposals such as account abstraction could attain the same level of abstraction as CKB did, since it would be extremely difficult to introduce radical changes to a running ecosystem, just like it’s impossible to tweak the Planck constant without tearing down the universe. For example, account abstraction will introduce new security complexity to critical modules like transaction pool, as a validator would need to handle arbitrary computation rather than fixed signature verification each time a new transaction is signed.

The other direction of abstraction goes for scalability. Both sharding and layer 2 solutions share a common problem — they change application development in certain ways. For example, it may be completely different to handle cross-shard calls or cross-layer2 transactions from contract calls on layer 1. Layer 2 application developers may also face different smart contract models on different layers (e.g. a UTXO-model layer 2 chain over an Account model layer 1, or vice versa). How to conceal these details and render a smooth experience for application developers as if they were building on layer 1 is still an open question. It’s one of the challenging problems we’re actively working on. The first channel construction on CKB, Generic Payment Channel 3, is an example under this line of thought. GPC aims to provide a “transparent” scalability layer to UDTs on layer 1 so that any UDT can be channelized from day 1 without any extra effort from developers. In GPC, we abstract the details of the payment channel protocol out from UDT developers. An alternative attempt can be found in our works on Godwoken and Polyjuice, which can be considered as both computation and scalability abstraction on top of CKB.

Interoperability 2.0

Each blockchain abstraction will bring us something new, something we’ve never seen at the previous abstraction levels. The first blockchain abstraction presented us with general programmability and inter-connected decentralized applications, what will the next blockchain abstraction bring us?

Interoperability 2.0 (a concept first mentioned here 2) is definitely an apple that will grow out on new abstractions. We envisage a digital economy future with multiple permissionless blockchains, permissioned blockchains, and centralized systems. Interoperability allows digital assets to be moved and smart contracts to be called across these independent systems. In recent years, numerous 1 studies / researches 1 on interoperability have been conducted 1 and it is believed that the problem can be solved with an array of basic primitives, such as multi-sig notary, relay and hash-locking.

Although blockchain interoperability is technically possible today, there’re other missing pieces between technical feasibility and the realization of a seamless interoperable digital economy. First, our interoperability initiatives will only create more split networks. Projects like Polkadot and Cosmos have defined each their own standards and attempted to build a multi-chain network around their own “hub”. There’re also parallel efforts building bridges between Bitcoin and Ethereum directly. It’s inconceivable sometime in the future the core teams and communities of these separate networks could come to the table and agree on a common interoperability standard for all to follow. Second but more critically, even if these blockchain networks were perfectly interoperable, lousy interoperation user experiences would still prevent users from using them. From a user’s perspective, if I were a Bitcoin user who wanted to transfer my BTCs to Ethereum to engage in DeFi applications, I have to first run my Bitcoin wallet and then cross-chain, then to use a separate Ethereum wallet. To complete such a cross-chain operation, I had to install two wallet applications, kept two sets of mnemonics and used two addresses. This process itself is very fractious and only applies to two chains. As users want to interact with more blockchains, the more mnemonics/addresses/keypairs they need to manage. This user experience problem not only hinders the adoption of DApps, but also sabotages decentralization, the core value of blockchain, because users would be forced to rely on centralized custody services to avoid all the hassles.

Solving these two problems requires a new type of interoperability, something we call Interoperability 2.0. A blockchain with this new interoperability would be like a “universal hub” which could interact with any other blockchain without being noticed by other blockchains. A “universal hub” must be capable of understanding and executing the protocols of other blockchains, rather than inventing its own and requiring everyone else to learn. A universal hub would be similar to a multilingual individual who can speak other people’ languages so that the hub could talk to everyone and everyone would be willing to dialogue with the hub. In the crypto world, all protocols (the language used by blockchains) are composed of cryptography, which means such a universal hub must support a wide range of cryptographic primitives used in the blockchains we would see today and tomorrow. The universal hub must be able to understand the transactions signed by all kinds of blockchain wallets, allowing users to stick with a single wallet alongside being able to use any applications running on the universal hub.

These requirements of Interoperability 2.0 are exactly what the new abstractions, cryptographic primitives and sender authentication, provided. That’s why an Ethereum user can use his/her Metamask wallet to operate assets or dapps on Nervos CKB 2 today, without any manual settings, without even notice he/she is using Nervos applications. Not only Ethereum users, EOS/Tron/… users can also operate assets or dapps on Nervos CKB. No worries if you find out that your favourite chain is not in the list yet, you can simply create and deploy smart contracts for it (or wait/pay a smart contract developer to do it for you). No pleas to the core team and/or hard fork needed, all can be done with smart contracts.

For applications running on Nervos, they get interoperability 2.0 for free. Thus a Nervos application can be widely accessed by users from every blockchain community, such an application is referred to by us as a Universal Application. As a developer, you can reach to a larger user base than elsewhere by learning how to build applications on Nervos. As a user, all you need to do is to use your current wallet and account to access universal applications on Nervos, no need to install or learn anything new. You may think you’re using an Ethereum or EOS DApp, while the underlying pipeline and infrastructure have been replaced by Nervos. And I believe that’s the way things should be. Like the fact that a user who visits a website doesn’t care whether the website is written in PHP or JAVA, using MySQL or PostgreSQL. Users simply don’t care, rightfully so. We as developers have the responsibility to create abstractions and hide implementation details from users, so we can replace implementations in use with better ones, for a superior and better user experience. Interoperability 2.0 will make the crypto world resemble the Internet of today, and it’s enabled by new blockchain abstractions.

Even better, universal applications can be accessed by a far more audience than blockchain users. The crypto world is a relatively small circle, and we can go much further. Blockchain wallet and account are nothing more than another account/identity system. Yet in the Internet world, numerous established standards for identity/account and authentication exist, such as OpenID, face recognition, fingerprint recognition, etc. With cryptographic primitive and sender authentication abstraction, Nervos CKB can also understand the widely used Internet protocols. Users are able to access universal applications by using browsers and mobile phones, with no need to install any blockchain wallets, generate any keypairs, not even remember any mnemonics. In this way, we cater to the existing Internet ecosystem, rather than creating a completely new one. We wouldn’t require our grandma to learn some magic that she has no idea about. The barriers preventing Internet users from entering the crypto world no longer exist here.

A New Metropolis

Many modern metropolises sprung from being hubs of trade routes or harbours. Venice, New York, Hongkong, Shanghai and Singapore all emerged as highly commercialized cities by virtue of their harbours. GPS, freighters and containers are the interoperate technology we use to shift assets between cities in the industrial age, but now we have crypto assets, blockchains and interoperability 2.0. Better interoperability brings more immigrants, more businesses, and more vitality to cities. Skyscrapers will pop up, cargos will be shipped, assets will be kept, people will stay, and a new metropolis will be born.

This article was originally published on Nervos Talk.

To stay updated on all things Nervos:

Join our community: Discord — Github — Nervos Talk Forum — Twitter

For discussions or questions join the conversation on Discord or check out one of our community Telegram channels: English, Korean, Russian, Japanese, Spanish, Vietnamese and Chinese

Blockchain Abstraction and Interoperability 2.0 was originally published in Nervos Network on Medium, where people are continuing the conversation by highlighting and responding to this story.