The following content is reproduced from Nervos Talk, written by Tim, the founder of d.id. The original article can be found at: https://talk.nervos.org/t/bit-nervos-ckb/7835
.bit is a decentralized naming protocol developed by the decentralized identity service provider (d.id) team. .bit is committed to providing globally unique, fully user-controlled decentralized names for every organization and individual. As the core puzzle of the decentralized identity blueprint of d.id, the .bit protocol was launched in November 2020 and went live on the Nervos CKB mainnet in July 2021, with a total funding amount of 18 million USD.
As we all know, despite the top-notch architectural capabilities of the Nervos CKB team and the impressive lineup of investors, Nervos CKB has been in a state of low market attention, low market value, and few ecological applications for quite some time. .bit was once the most important ecological application on Nervos CKB, so it was jokingly referred to as "building tall buildings in the desert" by friends. So, what are the reasons that have led to the lack of market attention to Nervos CKB in the past few years, and what are the reasons that have made us insist on running .bit on Nervos CKB? I will share my views from a developer's perspective.
Reasons for the lack of market attention to Nervos CKB in the past#
In my opinion, the key reason why Nervos CKB has received little market attention in the past few years is that it has chosen a completely different technical path from Ethereum: sticking to UTXO + PoW, maintaining compatibility with Bitcoin, and serving as the Contract Kernel of Bitcoin. The ideas behind this technical path have appeared out of place in the market environment dominated by EVM in the past few years. The impact of choosing a different technical path is: 1. It takes time for the market to understand it; 2. It takes time for developers to become familiar with the new programming model. These impacts have resulted in the innovative work of the Nervos CKB team in the past few years not receiving attention and recognition.
However, the market climate has now changed, and the Bitcoin ecosystem has become the focus of market attention. The market has also realized that the designs of Nervos CKB, which once seemed out of place, are now highly forward-looking.
Why .bit runs on Nervos CKB#
1. Nervos is isomorphic to Bitcoin, sticking to PoW + UTXO#
The reason why our core team members left internet companies and entered the Web3 industry is largely due to their recognition of Bitcoin's pioneering narrative and appreciation of its simplicity and elegance. We prefer things that are closer to Bitcoin.
For .bit to become a fully user-controlled naming system, it must run on a sufficiently robust and reliable foundation, so a PoW public chain is the inevitable choice. In today's mainstream where PoS and its variants are dominant, we insist that the PoW mechanism is more robust. In my opinion, the reason why PoS and its variants have become mainstream is not because PoS is more reasonable. One important reason is that it is much more difficult to successfully launch a PoW public chain. Building a PoW ecosystem is a complex engineering task. So far, Nervos CKB is one of the few PoW smart contract public chains that have been successfully launched, and mining machines have evolved to the ASIC stage, and mining output has also undergone a halving.
Nervos CKB and Bitcoin are isomorphic, which means that they both use the UTXO model. In Nervos CKB, UTXOs are called Cells, which are essentially enhanced UTXOs. In Bitcoin's UTXO model, the spending conditions of UTXOs can only be controlled by simple scripts with limited expressive power. In the Cell model, more advanced programming control of the spending conditions of Cells can be achieved using Turing-complete languages. Therefore, while inheriting the simplicity and elegance of Bitcoin's design, Nervos CKB provides developers with extremely strong programmability. Later, we will also discuss how the UTXO model can help applications achieve mass adoption more easily.
2. Custom cryptographic primitives + Cell as an asset container - helping applications achieve mass adoption#
Strictly speaking, .bit did not choose to run on Nervos CKB when it was launched. Instead, .bit was an internal project that had been abandoned and was restarted because of the emergence of Nervos CKB.
.bit was initially launched in early 2019 and was originally intended to run on Bitcoin, with application data stored in OP_RETURN. We completed the development and deployment of the test version, but eventually chose to abandon this project. Our goal is to make .bit serve a wide range of organizations and individuals, so the platform it relies on must meet two conditions at the same time: 1. It must be robust and reliable; 2. It must have a very low barrier to entry. Bitcoin is robust and reliable, but the barrier to entry is extremely high.
These barriers are difficulties that all new users entering Web3 have to overcome, and they are also obstacles that make it difficult for excellent Dapp applications to break through on a large scale. They include:
- Users need to understand and keep their private keys safe.
- Users need to have tokens for paying transaction fees in advance.
For example, if you issue a new NFT on Ethereum, a user without Web3 experience is attracted by your concept and decides to buy your NFT. They will then go through a series of unfamiliar tasks: downloading a wallet, backing up a mnemonic phrase, completing KYC and fiat currency deposit on an exchange, and then returning to your website to make the purchase. Most users cannot independently complete these tasks, and they usually give up at the step of backing up the mnemonic phrase.
Another example is when you send an NFT to a user who has just created an Ethereum address, but they cannot perform any operations on this NFT because they don't have any ETH in their address. Although there are some gas proxy solutions in the EVM, it is still a complex solution.
We can summarize the situation as follows: all users of Dapps must first become users of public chains; all Dapps must help public chains acquire users before they can convert their own users from the pool of public chain users.
So how does Nervos CKB solve these problems? The answer is:
- Support for custom cryptographic primitives, so that users no longer need to worry about private keys.
- Cell as an asset container, ingeniously allowing users to operate assets without worrying about transaction fees.
- Custom cryptographic primitives#
In other words, unlike other public chains that hardcode cryptographic algorithms into the consensus layer, developers can deploy any cryptographic algorithm on Nervos CKB and call these algorithms for verification when necessary. For example, you can deploy Bitcoin's signature verification algorithm on Nervos CKB, so that your application can verify the signatures of Bitcoin private keys. This means that Bitcoin users can directly use Bitcoin addresses to manage assets on Nervos CKB. The same principle applies to addresses of all public chains such as Ethereum and Dogecoin, which can directly manage assets on Nervos CKB. We can summarize it as: all users of public chains are naturally users of Nervos CKB.
Furthermore, we can also deploy widely adopted cryptographic algorithms from the internet world on Nervos CKB, such as secp256r1. All modern browsers already support the W3C Webauthn standard, and the secp256r1 algorithm is part of Webauthn. This means that the private keys in a user's phone/computer/tablet secure chip can directly manage assets on Nervos CKB. This is a brilliant idea! Users without any Web3 technical knowledge can sign transactions through simple face or fingerprint recognition, and it is completely decentralized. In other words, all internet users are naturally users of Nervos CKB.
I believe this is the most brilliant part of Nervos CKB's design! This is also the direct reason why the .bit project was restarted. Currently, the Passkey is fully supported in the .bit business process, which allows users without Web3 foundation to directly use .bit.
- Cell as an asset container#
In the account model of the EVM, each asset corresponds to a contract, and the contract has a data table that records how much of that asset each user owns. When you need to send an asset, you need to initiate a transaction that calls the contract and pay the transaction fee from your account. The common problem is that the accounts of new users often do not have any tokens, so they cannot pay the transaction fee. The EVM ecosystem has come up with solutions for transaction fee proxy, but overall it is still a complex solution. This solution also cannot effectively solve the problem of new users.
In the Cell model of Nervos CKB, each asset also has a corresponding contract, but how much of that asset a user owns is stored in a Cell controlled by the user. In other words, there is no unified data table to record how much of a certain asset each user holds; instead, each user's "safe" (i.e., Cell) records how much asset they hold.
The interesting point is that a Cell itself is composed of CKB tokens. The amount of CKB contained in a Cell determines its data storage capacity. This data can be a certain amount of tokens or the metadata and image data of an NFT, and the meaning of the data is defined and interpreted by the developer. At the same time, network transaction fees are also paid in CKB. This means that when constructing a Cell, in addition to storing data related to assets, additional CKB can be attached to the Cell, and the additional CKB serves as the source of transaction fees for operating the asset in the future.
This means that even for a completely new user, when we send an asset to them, they don't need to do any other preparations and can operate the asset directly! They don't need to worry about transaction fees because the received asset already includes the transaction fee. This is an extremely ingenious design!
@zhixian once made an apt analogy: assets on the EVM are like cars without fuel tanks, and you need to bring a bucket of fuel every time you drive. When you give the car to someone else, they also need to prepare fuel to use the car. On the other hand, assets on CKB are like cars filled with fuel, and anyone can drive them directly. And because of the abstract cryptographic design, this car does not require any technical expertise from the driver (i.e., users don't need to understand and manage private keys), and everyone can drive it.
In summary, the reason why .bit chooses to run on Nervos CKB is that only Nervos CKB can provide a robust and reliable operating platform for .bit while greatly reducing the barrier to entry for .bit, making .bit truly capable of targeting a large-scale user base. I believe that any developer who wants to build a great product hopes that their product can target a larger market, and in my opinion, Nervos CKB is the best choice.
The rise of the UTXO programming paradigm#
New developers entering the ecosystem may easily view Nervos CKB's programming model (i.e., the extended UTXO model) with their account model experience and feel uncomfortable. For example, they may find global state management too complex and have headaches about Cell preemption. My view on this is that both the account model and the UTXO model have their own advantages and disadvantages. The account model is efficient in certain scenarios, such as managing global state, while the UTXO model is more efficient in certain scenarios, such as the aforementioned assets with built-in transaction fees. If you always stand in the account model's perspective when looking at the UTXO model, it's like looking at a monster. In fact, in the early days of Ethereum's birth, many developers who were accustomed to internet application development also found it difficult to adapt to the programming on the EVM; for quite a long time after Bitcoin's birth, it was regarded as a monster by those accustomed to fiat systems.
When you first encounter UTXO programming, you may face some challenging problems. But there is no need to worry, you can often find corresponding solutions and discussions on the Nervos CKB forum. In my previous series of articles "Understanding CKB Application Development Starting from DAS", I discussed some challenges we encountered and their corresponding solutions.
I believe that as UTXO public chains carry more and more assets, the significance and necessity of UTXO programming will increase, and developers' understanding of UTXO will deepen. UTXO programming will eventually become a popular programming paradigm. Nervos CKB, which is isomorphic to Bitcoin and has powerful scalability, will also exist as the Contract Kernel of Bitcoin.