.bit : 我们为什么运行在 Nervos CKB 上

.bit 是由去中心化身份服务提供商 （d.id团队）开发的去中心化名字协议。.bit 致力于为每个组织和个人提供全局唯一的、完全由用户掌控的去中心化名字。.bit 协议作为 d.id 去中心化身份蓝图的核心拼图，于2020年11月启动，2021年7月上线 Nervos CKB 主网，累计融资金额 1800 万美金。

众所周知，尽管 Nervos CKB 团队有顶级的架构能力，项目本身也有豪华的投资人阵容，但在相当长的一段时间里，Nervos CKB 都是处于市场关注少、市值偏低、生态应用少的状态。.bit 一度是 Nervos CKB 上最主要的生态应用，所以也被朋友们戏称为“荒漠中建高楼”。那么，是什么原因导致过去几年 Nervos CKB 少被市场所关注，又是什么原因让我们坚持将 .bit 运行在 Nervos CKB 上呢？我将从一个开发者的视角，谈谈我的看法。

过去 Nervos CKB 少被市场关注的原因

在我看来，Nervos CKB 之所以在过去几年少被市场关注，关键在于其选择了与以太坊完全不同的技术路线：坚持 UTXO + PoW；保持与 Bitcoin 同构；作为 Bitcoin 的 Contract Kernel。而这种技术路线背后的思想在过去几年 EVM 独霸天下的市场环境中，显得格格不入。选择与主流不同的技术路线带来的影响是：1. 市场理解它需要时间；2. 开发者熟悉新的编程模型需要时间。这些影响进而导致 Nervos CKB 团队过去几年的创新性的工作，并未得到关注和认可。

然而如今整个市场气候已经发生变化，Bitcoin 生态开始成为市场关注的重点。市场也开始意识到，Nervos CKB 的那些曾经看来与主流格格不入的设计，在今天看来是如此地具有前瞻性。

.bit 为什么运行在 Nervos CKB 上

1. Nervos 与 Bitcoin 同构，坚持 PoW + UTXO

我们现有团队核心成员之所以离开互联网公司进入 Web3 行业，很大程度上是出于对 Bitcoin 开宗立派的叙事认同，以及对其简洁精妙的设计的欣赏。我们喜欢与比特币更相近的东西。

.bit 要成为完全由用户掌控的名字系统，就必须运行在足够坚固可靠的基础上，因此 PoW 公链是必然的选择。在 PoS 及其变种为主流的今天，我们坚持认为 PoW 机制更加坚固。 在我看来，PoS 及其变种之所以成为主流，并不是因为 PoS 更加合理。其中一个重要的原因是，要成功启动一条 PoW 公链，难度要大得多得多。构建 PoW 生态是一个复杂工程。到目前，Nervos CKB 是少数成功启动的 PoW 智能合约公链，并且矿机已经进化到 ASIC 阶段，挖矿产出也完成了一次减半。

Nervos CKB 和 Bitcoin 是同构的，是指同样都是 UTXO 模型。Nervos CKB 中的 UTXO 称之为 Cell，它本质是增强版的 UTXO。在 Bitcoin 的 UTXO 模型中，只能通过表达能力有限的简单脚本控制 UTXO 的花费条件；而在 Cell 模型中，可以使用图灵完备的语言对 Cell 的花费条件进行更高级的编程控制。因此，Nervos CKB 在延续了 Bitcoin 简洁精妙设计的同时，为开发者提供了极强的可编程能力。后面我们还会谈到，UTXO 模型还能帮助应用更容易地做到 Mass Adaption。

2. 自定义密码学原语 + Cell 作为资产容器 - 能够帮助应用实现 Mass Adaption

严格地说，并不是 .bit 启动时选择了运行在 Nervos CKB 上。而是 .bit 是一个原本被放弃了的内部项目，因为 Nervos CKB 的出现而被重新启动。

.bit 最早启动于2019年初，原本是准备运行在 Bitcoin 上，应用数据存储到 OP_RETURN 中。我们完成了测试版本的开发和部署，但最终还是选择毙掉这个项目。我们目标是让 .bit 能服务广泛的组织和个人，因此，其依赖的平台必须同时满足两个条件：1. 足够坚固可靠；2. 使用门槛极低。Bitcoin 足够坚固可靠，但门槛是极高的。

这些门槛是所有新用户进入 Web3 都要克服的困难，也是优秀的 Dapp 应用很难大规模出圈的障碍。它们包括：

1. 用户需要理解并保管好私钥

2. 用户需要先拥有用于支付交易费用的代币

例如，你在以太坊上发行了新的 NFT，一个没有 Web3 经验的用户被你的理念所吸引决定购买的你的 NFT。他接下来将经历一系列陌生的任务：下载钱包、备份助记词、到某个交易所完成 KYC 并完成法币入金、再回到你的网站来购买。绝大部分的用户都没办法自主的完成这些任务，到备份助记词这一步基本都放弃了。

再比如，你把 NFT 送给了一个刚创建好以太坊地址的用户，但由于他的地址上没有 ETH，结果他无法对这个 NFT 进行任何操作。尽管 EVM 存在一些 Gas 代付解决方案，但依然是一个较复杂的解决办法。

我们可以做这样总结过去的局面：所有 Dapp 的用户都必须首先成为公链的用户；所有 Dapp 都要先帮公链获取用户，才能从公链用户池中转化出自己的用户。

那 Nervos CKB 上是如何解决这些问题的呢？答案是：

1. 支持自定义密码学原语，使得用户无需再关心私钥

2. Cell 作为资产容器，巧妙地使用户在操作资产时无需再关心交易手续费

- 自定义密码学原语

也就是说，与其他公链都将密码学算法硬编码到共识层不同，开发者可以在 Nervos CKB 上部署任意的密码学算法，并在必要的时候调用这些算法进行验证。比如，你可以把 Bitcoin 的验签算法部署在 Nervos CKB，这样你的应用就可以验证 Bitcoin 私钥的签名了。也就是说比特币的用户可以直接使用比特币地址管理 Nerovs CKB 上的资产。同样的原理，以太坊狗狗币等所有公链的地址都可以直接管理 Nervos CKB 上的资产。我们可以总结为，所有公链的用户，天然就是 Nervos CKB 的用户。

更进一步，我们还可以将已经在互联网世界中被广泛采用的加密算法部署到 Nervos CKB 上，比如 secp256r1。所有的现代浏览器都已支持 W3C 的 Webauthn 标准，而 secp256r1 算法正是 Webauthn 的一部分。这意味着，用户的手机/电脑/平板安全芯片中的私钥，可以直接管理 Nervos CKB 上的资产。这是天才般的想法！那些没有任何 Web3 技术知识的用户，通过简单的人脸或指纹识别即可签署交易，并且是完全去中心化的。也就是说，所有的互联网用户，天然就是 Nervos CKB 的用户。

我认为这是 Nervos CKB 设计中最天才的部分！这也是 .bit 项目被重启的直接原因。目前，.bit 业务流程中已经全面支持 Passkey，这使得那些没有 Web3 基础的用户也可以直接使用 .bit。

-Cell 作为资产容器

在 EVM 的账户模型中，每一项资产都对应一个合约，合约中有一个数据表，记录了每个用户分别拥有多少该资产。你需要发送资产时，就需要发起一笔调用该合约的交易，并从你的账户中支付交易费。常见的问题是，新用户的账户中往往没有任何代币，无法支付交易费。EVM 生态已经出现了交易费代付的解决方案，但整体来说还是一个较复杂的方案。这种方案也不能有效解决全新用户的问题。

在 Nervos CKB 的 Cell 模型中，每项资产也有对应的合约，但用户拥有多少该资产是存储在由用户控制的 Cell 中的。也就是说，没有一个统一的数据表去记录每个用户分别持有某项资产的多少；而是每个用户自己手上的“保险柜”（也就是 Cell）中记录了用户持有多少资产。

有意思的点在于，Cell 本身就是由 CKB 这个代币构成的。一个 Cell 包含的 CKB 数量决定了它的数据存储量上限。这些数据可能是某种代币数量，也可能是 NFT 的 metadata 和图片数据，数据的含义由开发者定义和解释。同时，网络交易费也是以 CKB 来进行支付的。那就意味着，在构造 Cell 时，除了把资产相关的数据存放到 Cell 里，还可以给 Cell 多附加一些 CKB，多附加的 CKB 就作为以后操作该资产时的交易费来源。

这就意味着，即便是一个全新的用户，当我们把一个资产发送给他后，他不需要做任何其他准备，就可以操作这个资产了！他不需要关心什么是交易手续费，因为他收到的资产里面已经包含了交易收费了。这是极其巧妙的设计！

@zhixian曾做出过一个形象的比喻：EVM 上的资产就像是一个没有油箱的汽车，你每次开车都需要带一桶油上去，你把车送给别人时，别人也得准备好汽油才能使用这个车；而 CKB 上的资产是装满了油的汽车，任何人都可以直接上手开。同时，又由于抽象密码学的设计，使得这辆车完全不挑驾驶员的技术（即，不需要用户具备理解和管理私钥），人人都能开。

总结起来，.bit 之所以选择运行在 Nervos CKB 上，是因为只有 Nervos CKB 才能做到在为 .bit 提供坚固可靠的运行平台的同时，还能极大降低 .bit 的使用门槛，使得 .bit 真正具有面向大规模用户的能力。我相信，任何想构建伟大产品的开发者，都希望自己的产品能面向更大规模的市场，而 Nervos CKB 在我看来是最佳的选择。

UTXO 编程范式兴起

新进入生态的开发者很容易带着账户模型的经验来看 Nervos CKB 的编程模型（即扩展的 UTXO 模型），然后感觉到各种不适应。比如，全局状态管理怎么这么复杂，Cell 抢占问题好头疼。对此我的看法是，账户模型和 UTXO 模型各有优劣。在某些场景下账户模型是高效的，比如对全局状态的管理；在某些场景下 UTXO 模型是更高效的，比如前面提到的资产内置交易费。如果始终站在账户模型本位，看 UTXO 模型，就像是看怪物。事实上，在以太坊诞生的初期里，许多习惯了互联网应用开发的开发者也会不习惯 EVM 上面的编程；比特币诞生之后的相当长的时间里，都被习惯了法币系统的人们视为怪物。

刚开始接触 UTXO 编程，可能会面临一些棘手的挑战。但不必担心，这些往往都可以在 Nervos CKB 的论坛上找到相应的解决方案和讨论。我在之前的系列文章《从 DAS 开始了解 CKB 应用开发》中，探讨了一些我们曾经遇到过的挑战和对应的解决方案。

我认为，随着 UTXO 公链承载的资产越来越多，基于 UTXO 编程的意义和必要性开始变大，开发者对 UTXO 的理解也会加深。UTXO 编程终将成为一种流行的编程范式。与 Bitcoin 同构的，具有强大可扩展性的 Nervos CKB 也将作为 Contract Kernel of Bitcoin 而存在。