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 organizations and individuals. 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 a "high-rise building in the desert" by friends. So, what are the reasons for the lack of market attention to Nervos CKB in the past few years, and why do we 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 seemed 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 led to 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 visionary.
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 like things that are more similar to Bitcoin.
In order for .bit to become a name system fully controlled by users, it must run on a solid 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 project. So far, Nervos CKB is one of the few successfully launched PoW smart contract public chains, 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 they both use the UTXO model. The UTXO in Nervos CKB is called a Cell, which is essentially an enhanced version of UTXO. In the UTXO model of Bitcoin, the spending conditions of UTXOs can only be controlled by simple scripts with limited expressive power. In the Cell model, Turing-complete languages can be used to control the spending conditions of Cells with more advanced programming control. Therefore, while inheriting the elegant design of Bitcoin, Nervos CKB provides developers with strong programmability. Later, we will also discuss how the UTXO model can help applications achieve mass adoption.
2. Custom cryptographic primitives + Cell as asset containers - enabling applications to 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 solid and reliable; 2. The entry barrier must be extremely low. Bitcoin is solid and reliable, but the entry barrier 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 gain a large user base. They include:
- Users need to understand and keep their private keys safe.
- Users need to have tokens for paying transaction fees.
For example, if you issue a new NFT on Ethereum, a user without Web3 experience who is attracted by your idea and decides to buy your NFT will go through a series of unfamiliar tasks: downloading a wallet, backing up a mnemonic phrase, completing KYC and fiat 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 their address does not have any ETH. Although there are some gas fee sponsorship solutions in the EVM, they are still relatively complex solutions.
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 asset containers, 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 arbitrary cryptographic algorithms 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. In other words, 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 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 with 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 asset containers#
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 and cannot pay transaction fees. The EVM ecosystem has come up with solutions for transaction fee sponsorship, but overall it is a more 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" (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 can 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 due to the abstract cryptographic design, this car does not require the technical expertise of the driver (i.e., users do not 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 solid and reliable operating platform for .bit while greatly reducing the entry barrier for .bit, making it 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 the management of global state too complex and struggle with Cell preemption. My view on this is that both the account model and the UTXO model have their advantages and disadvantages. The account model is efficient in certain scenarios, such as managing global state, while the UTXO model is more efficient in other scenarios, such as the aforementioned assets with built-in transaction fees. If one always stands in the account model 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 accustomed to internet application development also found the programming on EVM unfamiliar, and for quite a long time after Bitcoin's birth, it was regarded as a monster by people accustomed to fiat systems.
When starting to learn UTXO programming, you may face some challenging tasks. 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 strong scalability, will also exist as the Contract Kernel of Bitcoin.