Janx: CKB2021 主网升级 AMA，全方位解读

（之所以这次 CKB 主网升级称为 CKB2021，是因为它是从 2021 年就规划和开发，并在 2021 年完成了早期版本的验证工作）

TLDR:

CKB 想要做的是需要延伸 SoV 的理念，从单一的价值存储（SoV，Store of Value），扩展成多种资产的价值存储（SoA，Store of Assets）。

这次升级的 feature，变动比较大的有以下几个部分：虚拟机、区块结构、共识规则、P2P网络。对于用户而言，基本无感知。

CKB 作为 Nervos 一层上的内核，要尽可能的保持小、精简、稳定、安全，更多的事情要放到 2 层、3 层、更上层、应用层去做，这是 Nervos 一以贯之的理念。

公链性能吞吐量的瓶颈是全球网络的平均带宽。最高效的区块链，或者「性能」最好的区块链是最能够有效利用带宽的区块链。

本次 hard fork 是一种大家已经有预期的、都同意的一种硬分叉，所以不会有两个链出来，因为只有在社区意见非常割裂的时候才会形成像一一ETH、ETC 那样的情况，那种情况从整个区块链的历史来看其实非常非常少见的。

由 CKB、Godwoken、Axon 组成的 Nervos Network，它们是在安全、性能、去中心化这几个点之间来做不同的权衡：

• 如果你非常想要安全性，想要去中心化，你就在 CKB 上面做开发。
• 如果你非常想要高性能，你可能要去 Axon 上面做应用。
• 如果你觉得你就想中间一点，你可以选择 Godwoken。

Nervos 在 2022 年是有一个从下到上，从 1 层到 2 层整体的一个升级，CKB hard fork 是开始，接着是 Godwoken，再然后是 Axon 上线。

今年 Nervos 的生态，更多的发展可能会出现在 Godwoken V1 上面；另外，Axon 也是完全兼容 EVM 的 Layer 2，如果上线，生态也会发展得很快。

以下为直播实录内容，enjoy。

---

一休哥（以下简称主持人）：

直播间的朋友们，大家晚上好，我是你们的老朋友一休哥，首先要感谢大家抽出宝贵的时间来参加我们今晚的活动。

上周，Nervos 公布了主网升级的时间点，计划在第 5,414 epoch 到来的时候正式启动主网升级（已于 5 月 10 日顺利完成升级）。我们只知道，这是自 2019 年 11 月 16 号 Nervos 主网上线以来的第一次网络升级，但可能很多人不知道，这次升级涉及到的面之广，如果去看 GitHub 的提交记录的话，会看到基本所有的核心组件都做了优化升级，并且为了确保安全、稳定地升级，核心开发团队几乎花了整整一年的时间来准备这次升级。

今天晚上，我们 CKB 中文社区邀请了 Nervos 首席架构师&核心开发团队成员 Jan 来到我们的直播间，他将对此前推特、discord上收集到关于本次主网升级的相关问题进行一一解答。

Jan，先给社区里的小伙伴打个招呼吧！

Jan：Hello，大家好，我是 Jan，Nervos 的架构师。

主持人：感谢 Jan 的到来，考虑到社区里有一些新人，在正式开始 AMA 之前，请你先介绍一下你的个人经历。

Jan：我自己是计算机专业背景，在 13、14 年接触到 Bitcoin，然后对比特币非常感兴趣，所以一直在研究这个领域。

很可能和很多人一样，或者说和很多人不一样，一开始看到 Bitcoin 的时候，觉得这东西是骗钱的吧？如果把时间回拨到过去，你很难想象，作为程序员，我们可以去构建一个新的货币，那是一个很疯狂的想法，这件事情太不真实了。

不过，你又会看到比特币在技术上、设计上一些非常有意思的地方，它的整个设计的思路完全和我们那时在做互联网时的设计完全不同，完全是反着来的，比如，互联网追求性能高、效率高，比特币的 PoW 追求效率低（你要安全需要这么做）；互联网产品要精致，比特币就特别“粗糙”，这里所说的粗糙是指早起的比特币软件是非常粗糙的。

比如说比特币的一个新节点如果想要加入比特币网络，首先要能够找到一个已经在比特币网络中的节点进行连接，我们称为种子节点。那么要怎样才能找到一个比特币中的种子节点呢？ 你不能通过 P2P 网络去获得那个信息，你必须有一个最初始的办法，否则就死循环了。早期的比特币就非常简单粗暴，它利用 IRC 协议让比特币网络的节点加入一个特定 IRC 聊天室中，你进到这个聊天室，在聊天室里面的人就是你的种子节点。（整理文稿时备注：IRC，全称 Internet Relay Chat，IRC的特点是能够在聊天对象之间建立频道，频道内的人都能够收到信息，频道外的人则不能，就相当于一个聊天室。）这种就是非常粗糙、取巧的方法，因为在互联网上，我们的生产环境中肯定是不会用这样的方法，而比特币它就用了。

所以你会觉得，比特币是一个从工程各方面看非常粗糙但在设计上又闪耀着智慧光芒的东西，你会不由自主的被它吸引然后就开始研究。我先是深入其中，后被朋友拉来创业，之后就一直在这个行业沉淀下来，做了很多事情。

一开始是做交易所。 大家可以去看 GitHub 上有一个开源项目，叫 peatio （貔貅），那个是我写的。我相信那是第一个开源的交易所，因为我在 GitHub 上找了很久，没有找到任何有用的交易所的代码，所以最后只能自己写。我相信 peatio 的代码应该是推动了这个行业发展，因为我知道很多交易所用过，甚至我知道某些现在非常大的交易所，他们一开始是用 Ruby on Rails 写的，这里面其实是有很多渊源。（Ruby on Rails，官方简称为 Rails，亦被简称为 RoR，是一个使用 Ruby 语言写的开源 Web 应用框架，它严格按照 MVC 结构开发，努力使自身保持简单，使实际应用开发时的代码更少，使用最少的配置。）

(peatio github 主页)

在做了交易所之后，我又开始去尝试新的事情。因为交易所离区块链不是那么近，其本质上还在应用层，之后就想往更加底层的方向去研究，所以我就去研究 Ethereum。我做交易所那会儿， Ethereum 刚好出来，还非常新主要还是在国外。以太坊出来的时候，比特币社区很多人觉得它是骗人的，因为当时 altcoins 很多。但是我觉得很有意思，因为从技术的眼光看，相较于 Bitcoin，以太坊很明显往前走了一步：从一个单纯的 Crypto Currency 变成了一个平台，从一个只能打电话的手机变成了一个 iOS，于是就开始一方面去研究它的代码，然后尝试自己去写 Ethereum 客户端。

另一方面，我和几个朋友在中国成立了 EthFans 社区。这个社区大家也许知道也许不知道，因为现在由于种种原因已经没了。但是EthFans 曾经是中国最专业的也是最大的以太坊社区，而且是从以太坊一开始就随着以太坊一起成长。

于是我一边做社区一边写代码，后来当以太坊研究团队需要招人的时候，我就直接发邮件给 Vitalik了。在开源项目中这其实很正常的情况，不光是以太坊，GitHub上任何的开源项目，你都可以去主动贡献代码、跟开发者交流，如果开发者需要帮助的时候，他可能会来找你。在研究团队招人之前，我已经用 Ruby 写了一个以太坊的客户端版本叫 ruby-ethereum，它当时和以太坊已经做到了完全兼容，完全通过了以太坊自己的一套专用测试用例的测试，通过那个测试，说明你的兼容性就已经非常好了，就是一个正常的客户端。因此那个时候 ruby-ethereum 也被添加到了官方文档里面，是7种客户端中的一个。由于我是做了这些事情，对 Ethereum 已经非常了解，Vitalik 也知道我的这些工作，而且我感兴趣的就是Research，所以很顺利就加入 research team 了。然后就在以太坊团队里参与的几个事情：一个是分片 Sharding 的研究和原型的设计，另一个是 Casper。

另外一方面我在杭州成立了一家公司，叫秘猿科技。秘猿科技当时最开始其实做的是许可链的事情。我们做了个项目叫CITA，它是一个许可链，主要是追求性能和可扩展性，也兼容 EVM。后来 CITA 项目的主要成员离开了秘猿成立了另一个公司溪塔，现在也发展得非常好。

区块链的系统要 scale，这个是我们所有人一直都在尝试解决的问题。Scale 其实有两种方式，一种是你把整个网络里面的每一个节点都变得更强大，如果所有节点都更强大，比如说从笔记本变成了巨型机，那你这个网络的吞吐量很自然就上升了，你在系统设计上其实什么都不用做；另外一种方式是这个网络都里面都是笔记本，但是往里面加越多的笔记本，这个网络的吞吐量或者处理能力就越好，这是另外一种 scale 的方式。前面那种叫Scale Up（纵向扩展），后面这种叫Scale Out（横向扩展）。

如果我们要 Scale Up，其实又分两种方式：一种是我们把笔记本换成巨型机；另外一种是把笔记本换成 1 个服务器的群组，一个Cluster 集群，这个集群共同形成一个逻辑节点，这个逻辑节点内部其实是有很多台机器，但是对外来说，它就是一个节点。那这样其实也可以形成一种Scale Up的效果，这个网络吞吐量就能变好，但这个方法只能在许可链里面用。我们一开始是做 Scale Up 方向的，也做了一些非常有意思的项目，有跟银行合作的、有跟各种机构合作。所以在高性能的许可链方面，我们也是有很多积累和经验。

然后在这个阶段还顺便帮星火矿池设计和实现了第一版的矿池。大家可能不知道，星火矿池其实是从 EthFans 社区成长出来的一个项目，后来变成了全世界最大的以太坊矿池，然后在去年由于众所周知的原因关掉了，很可惜。

（秘猿科技 项目列表）

由于我之前的这些经历，自己就积累了很多想法，最终在各方面条件都成熟的时候，还是想要挑战做公链，因为在我看来，公链在整个Crypto行业里面是最有挑战最有意思的事情。

主持人：感谢 Jan 的分享。让我们开始回复社区里的问题。

Q1：这是Nervos主网的第一次重要升级，为了这次升级，团队为之做了非常多的努力，能否介绍一下这次网络升级的背景。

Jan：首先，升级是一个必然的事情。一个长期运行的软件总是需要升级的，因为一开始不可能预料到所有的需求，需求在变，软件也要跟着变；对于公链来说也一样，区块链也是一个软件系统，升级是必然的。

其次，Nervos 是一个全新的系统，有一套全新的思路，一开始确定的东西可能只有 40% 或者 60%，剩下的都是在摸索。一方面，因为我们很难预料未来开发者会怎样使用这个系统，主网上线之后，很多开发者在主网上做开发，指出了一些设计不合理的地方，这些反馈积累了一定量所以需要调整，以适应开发者的需求，这是需要升级的东西。另外一方面，我们在主网 Lina 发布的时候就非常清楚，这只是 Nervos 的第一阶段，后面还有一长串的事情要去做，有很多排着队的事情只能一步一步来。那些我们本来就想要去做的更复杂更高级的东西，也是需要升级来完成的。

Q2：升级能解决的问题是哪些？会带来一些什么改变呢？ 升级之后我们需要注意一些什么？

Jan：OK，我介绍一下 CKB 的 hard fork。首先我觉得大家需要理解 CKB 可能和很多的区块链项目不一样，因为我经常能看到一些问题，我觉得可能是出于对 Nervos 和 CKB 的一些误解，所以才会有这样的问题。所以先要明白不同的公链理念其实很不一样。

CKB 不论是从设计还是理念上来说都是比特币的延续， 例如，CKB 在 PoS 盛行的时候选择了 PoW， 使用优化的中本聪共识而不是类 BFT 的共识，状态编程模型是拓展的 UTXO 模型，还有各种各样的设计选择，其实都说明了这一点。这些选择是有意识做出的，不是无意识的拼凑。

我对 Bitcoin 和 Ethereum 都很了解，这些选择有自己的原因。现在行业内的主流观点认可比特币是一个价值存储，它需要非常安全，我们宁可它什么都不变。因此可以看到比特币在技术发展上非常保守，这其实是比特币的态度； CKB 想要做的是需要延伸 SoV 的理念，从单一的价值存储（SoV，Store of Value），扩展成多种资产的价值存储（SoA，Store of Assets），你可以放心地把各种各样的资产放到链上，这是一个延伸。 价值存储的实现是需要相应的选择的，不是一个天然的事情。

同时，比特币具有非常好的可用性。简单来说，你没有看过比特币停机吧，但是今天各种各样的区块链，它要么就是出 BUG 停机了，要么是因为升级停机一下，在我眼里这种和 Bitcoin 就不是一种东西了。因为这样的链跟互联网服务或者云数据库其实差不多；比特币完全不是这样。当然没有人可以保证比特币永远绝对一万年不停机，因为毕竟是人写的它总有可能出BUG，但是它的理念很清楚，我们需要保证不能随便一个改动它就停了；比特币十几年了都没有停过，时间是对比特币设计理念的最好的证明。有很多只运行了一两年的链都停过无数次了，因此我说它们是不同的东西，只是刚好被套在了“公链”这样一个模糊的定义里面。CKB 上线两年多了其实也没有停过，这一点上也是延续 Bitcoin 的理念。这是非常重要的。这是一个背景。

CKB 在比特币的基础上想要从 SoV 到 SoA，除了需要保证去中心化程度不变、保证 liveness（保持网络持续运行）性质足够好之外，还要有扩展，不然就是 Litecoin 了。但是扩展还要有延续性，不能像 Ethereum 一样从 UTXO 变到 Account 模型。也就是说，我们还是要把一层变得更加强大和灵活一点，但是只是变强大一点点。如果说比特币是从 0 到 1，以太坊是从 1 到 10，再后面一些项目是想从 10 到 20，甚至到 100，那么 CKB 则是想从 1 走到 5，这个听起来有点反直觉：以太坊都从 1 走到 10 了，你才走到 5，那你还不如以太坊？！需要理解的是，技术发展有很多的方向。如果说以太坊是沿着X轴从1到10，那么 Nervos 在现阶段可以说是同时沿着X/Y轴从1到5。Nervos 现阶段已经完成的工作中， 一层是 PoW + UTXO 模型，二层是 PoS + Account 模型，可以说是一个注解。

Nervos 作为一个分层网络整体上想要从 1 走到 100 ，但 CKB 作为这个分层网络的核心，这个内核应该是刚刚好最精简的状态，因为如果把越多的东西塞到内核里面它会非常臃肿，代码越多越复杂越容易出 BUG 从而不安全，这是它的后果。如果走的不够多，就会像比特币一样非常难改，很难在比特币上开发二层网络，非常难在比特币上实现各种各样的资产，所以我们需要找到那个平衡点，不能走多，也不能走少了，找到一个刚刚恰好的点，在此基础上去构建二层网络、三层网络，然后整个分层的网络体系它是一个可以走到 100 的体系，这是 CKB 和其他很多链不一样的地方。所以你可以把 CKB 理解为一个把比特币稍微延伸了一下的内核。就像你用的 Windows 操作系统，它有个内核；你用 Linux 系统，它也有个内核，苹果 iOS 也有它自己的内核，内核都很小。你平常使用的应用软件，那个不是内核，它们是内核上层的应用。应用软件与内核之间还有中间层，系统调用库。（后期整理文稿时备注：应用程序一般不直接与内核打交道，而是通过调用中间层封装好的 SDK 接口，去与内核通信执行相应指令）

很多区块链试图把所有的东西都塞到内核里面，这也很正常，因为现在还是在技术发展的早期。当我们回顾操作系统发展的时候也能看到，早期的操作系统也是这样，就是什么东西都放在一块。

CKB，其实是比较聚焦在内核这个事情上，或者说汽车的引擎、飞机的引擎上，这是 CKB 的定位，所以CKB，从定位上、设计的理念上来说，它可能会离普通用户甚至是一般的应用开发者都有点远。这个点其实和比特币也很像，因为大家如果关注比特币和以太坊生态的不同的话，圈子里有一个流行的观察：大家都说以太网上的开发者都是 hipster，写应用跟玩似的，一天就能蹦出 100 个应用；比特币的开发者则是苦哈哈的，可能要写两年才能写出个应用，写应用之前可能还要先发个 paper。这两种社区是非常不一样的。CKB 会更接近比特币社区一些。在 CKB 上的编程非常接近在操作系统上做系统级的编程，而不是做网页开发。这是两种非常不一样的平台，定位理念设计通通不一样。

说这么多是为了回答这样一个问题：这次升级有多少是用户能感知的？

这个问题实话说非常难回答。

因为升级本身离用户非常远，你可能无法直接感知到，但会间接感受到这些升级。因为中间是有一层或者二层开发者在中间做这个桥的工作，把底层的改动吸收到他们的应用，吸收到他们的工具，吸收到他们的库里面，这样用户在使用这些应用的时候才会感觉到这个好像比以前更好用了，它是一种间接的关系。这次升级大家可以把它理解为一个操作系统内核升级，应用可能还要滞后一段时间。（就像汽车引擎从第 1 代升级到第 2 代了，你不会有直接的感知的，只有等到汽车制造商将它安装到汽车里，你才能感受到变化，比如说，它的动力比第1代更足了。）

下面来说一下这次升级的 feature，变动比较大的有以下几个部分：

• 虚拟机
• 区块结构
• 共识规则
• P2P网络

其中，共识规则和 P2P 网络的改变对用户应该是基本透明的。共识规则的改变大部分是在解决一些之前定义不好的规则或者说有 BUG 的地方。

共识规则里面有一条比较重要的，也是对开发者特别有用的是 RFC0036。

如果你想要在你的合约里面去引用前面区块 block header的数据的话，在这次硬分叉之前，你只能引用 4 个 epoch （大约 16 个小时）以前的区块，在这次硬分叉之后，你能够引用上一个区块的数据，甚至链上任何一个区块的数据，这个对于很多应用写合约的开发者来说，这是一个巨大的区别。因为他们可以在合约内，在合约运行的时候获得最新的 CKB 链上的信息，这里就会带来提升用户体验的一个变化。

作为用户来说，此前你在使用一个应用的时候，你不知道为什么要等这么久，那这次升级之后，你可能就不需要等那么久。因为之前这个应用需要去等这个区块成熟，要等 16 个小时，升级之后它不用等了。

我印象里，UniPass 和 .bit 应该遇到过这个问题。那为什么一开始要设计成要等 4 个 epoch？这其实是一个纠结了非常久的设计。

也许有些朋友知道，在比特币系统里面，新挖出来的比特币也是要等一个成熟期的，所谓的成熟期大概是 20 个小时还是多少小时，具体我忘记了。它是说，你刚挖出来的比特币，在 20 小时之内你是不能花的。为什么呢？因为担心如果你马上就花了，但是在那之后有可能那个先挖出来的块变成 Uncle，变成叔块，然后那些新挖出来的币刚挖出来又消失了。也就是说，如果你允许那些币马上被花掉的话，后面所有依赖这个刚挖出来的币的这些交易全都要回滚，这可能会给用户带来麻烦，并且可能会导致一些非常奇怪的后果。

CKB 里加上这么一个限制，其实也是因为同样的原因。这其实是涉及到安全和好用的平衡点，我们到底是要安全还是要好用，到底是要跟 Bitcoin 保持一致，还是要跟 Ethereum 保持一致？Ethereum 以及其他的区块链根本不考虑这些东西。在设计上比较难确定我们的平衡点放在什么地方才是好，反正讨论了很久，然后正好社区的开发团队也遇到了问题，也提出了需求，最终的结论就是，我们就放宽这个引用区块头 header 限制，不需要等 4 个小时，但是像其他的一些限制还是保持。

这是一个非常典型的例子，我们需要在比特币的理念和以太坊的理念之间找平衡——我们不希望变得像以太坊和其他的区块链那样，Move fast and break things；但也不希望像比特币那样变得很呆滞死板，非常难以前进。这是共识层规则变化的部分。

这次升级最重要的其实是虚拟机的改变。

虚拟机包含了3个RFC：0032、0033、0034。

先说 RFC0032，它引入了虚拟机版本这个概念，这是一个非常有意思的事情，我还不知道哪个区块链的虚拟机是带版本的，CKB有可能是第一个，我确实还没有看到，大家如果有知道其它的可以指出来。以太坊以前曾经讨论过把在虚拟机也即 EVM 里面引入版本，但是发现有各种各样的问题，所以没有做。

那 CKB 为什么要做这件事情？ 其实有非常实际的原因。

首先，CKB 的 VM 是 RISC-V 的指令集，我们是跟着 RISC-V 的标准走的， RISC-V 是一个业界已经广泛使用、发展迅速的一个指令集的标准，我们得跟着它的标准走。RISC-V 的标准是会不停地更新的，如果我们不跟着走的话，就和规范不兼容，那从兼容上获得的各种好处都没有了。所以 CKB-VM 也必须是能升级跟着 RISC-V 走的，这一个需求。

另一方面，回到刚才讲到的 CKB 希望能和 Bitcoin 一样：成为 SOV 价值存储。 成为价值存储的一个很重要的因素是：作为这个区块链的用户，他们能够确信，我在今天用一个公钥，或者一个合约保管起来的资产，在几十年后甚至百年后，它依然是归属于我。

这个是一个非常自然、非常正义的需求，听起来好像也没什么难的，但是其实它不是那么容易实现的。为什么呢？因为如何保证区块链升级不会改变之前合约或者账户逻辑？你是否确信未来不管经过怎样的升级，你的资产依然属于你？这是一个值得辩论值得讨论的问题，因为一段代码或者一个合约的意义，是由两方面决定的，一个是代码或者说数据本身，另一个是解释这段代码或者阐释数据的“容器”。区块链就是那个解释代码的容器，在区块链上存下来的合约、资产都是数据。区块链升级不会改变链上数据，但是会修改那个解释数据的容器，从而有可能改变某段代码某个合约的含义，因此可能影响某些资产的归属。

对于比特币来说，它很容易就避免了这个问题。他说，我们永远不做 hard fork，很大程度上就不存在这个问题。而是否可以 hard fork 是社区共识保证的。但是如果需要 hard fork，就像我们刚才说的，我们需要去升级 VM，并且又如何做到使用能够保证合约的语义不会被升级改变？我们想实现的目标是，即使一直升级，也能保证你在今天存下了一笔资产，在几十年、100年之后，无论中间升级多少次，它依然是你的。 这是一个比较简单的描述，实现起来没有看起来那么简单。

这方面最有名的例子是，我想大家都知道，就是在以太坊上面发生过的事情——The DAO。为了修复 The DAO 而制造的硬分叉，实质上是一群人投票，剥夺了一个人的资产。攻击者把 DAO 里面的钱转移走，然后社区通过一种非正式的治理过程形成了一个共识，最终决定进行 hard fork 直接改链上数据，把资产给拿回来。这个其实跟我说的例子还不太一样，因为以太坊所做的事情是他直接把数据改了。

其实还有一种（可能更聪明的）做法就是不改数据，把解释数据的解释器给改了。我们可以不停地增加新的解释。

所以话说回来，如果我们要升级 VM，其实就面临这样一个冲突。一方面我们需要去升级 VM，另外一方面，我们又不希望给开发者太多权力，因为一旦有了这个权力之后，最后也许会发展成对 VM 也就是解释容器可以任意修改，导致之前的代码/合约语义变化，这种可能性会损害人们对这条链能是否能够成为 SoV 的信心。

那怎么办？

CKB 找到了一个我觉得是很巧妙的方案。CKB 有一个特性大部分用户可能不知道，但开发者是非常清楚的，在 CKB 上面引用一个智能合约的时候，有两种方式，一种是通过那个智能合约的地址，在 CKB 上我们叫它 type id，就把它理解为地址吧，就跟以太坊的合约地址一样，你可以通过地址去引用。另外一种方式是你可以通过这个合约的代码 hash 去引用， 也就是说，这个合约的代码是什么，通过代码计算出来的hash去引用这个合约。

那么 RFC0032 讲的是什么呢？0032 是说如果你是通过type id或者说地址去引用合约的，那么合约在运行的时候的时候，在硬分叉之后，它会自动升级到用 V1 版本的虚拟机，用新的虚拟机去执行。 为什么呢？因为你用地址去引用合约，这个行为或者用法本身代表你把合约的解释权已经交给这个合约的开发者，因为 type 它和地址一样，是一个名字，它和这个合约本身的内在属性没有任何关联。通过名字引用的合约可以不停地变，就像你在不停地长大，你可以从 3 岁长到 12 岁，你还是叫这个名字，但随着年龄的增长，你的身体内部已经发生了很多内在的变化。「它只是一个名字，内在是可以变的」，这是当你做出 用地址或者type id去引用一个合约 这个选择的时候，选择本身传递的意思。

另外一种方式是你通过合约代码的hash去引用。 此时你表达的意思是：「无论什么时候我都不希望引用的对象有变化，我希望总是得到相同的结果。」——我就想要用这段代码，在我现在的这个虚拟机的解释规则下跑这个合约。我知道你未来可能会升级，我不管，就算你做了 100 次升级，我还希望用我现在发交易时候所写的代码和我现在发交易时候所写的虚拟机来执行这个合约，我想得到一样的结果。

因为你这时候你使用的不是名字了，你非常明确地指定了一段代码，以及相应的执行环境版本，你非常明确的指定了一个语义。如果你是通过这种方式引用合约的，你的合约的执行结果在 hard fork 之后是不会变的，即使在 hard fork 之后，你的合约依然会用 hard fork 之前的那个虚拟机的版本来执行，依然会用之前的虚拟机的版本值执行你当时写好的代码。这样就能够保证，不管怎么 hard fork，你这个合约依然是当年那个合约，没有一丝丝改变。

因此，CKB 通过这两种引用不同的引用方式，把选择全留给用户和开发者自己去选择：

• 想要获得自动升级的好处，同时愿意放弃一些语义上的变化；
• 不愿意接受语义在不经过你同意的情况下有变化，宁愿放弃自动升级的好处，有需要自己再去升级。

这是 0032 解决的问题。简而言之，0032 实现了一个多版本虚拟机的模型，在保证 SoV 价值存储的语义下，同时解决各种各样的多版本虚拟机共存的技术挑战。 这是一个非常大的改动，我没有看到其他链有实现这个，大部分链可能都不关心也没有方法解决这个问题——虚拟机升级就好了，为什么要有多版本，所有人就一起升级就完了。这些链的用户其实是有意或者无意地放弃了一些权利的。这个和 CKB 的理念是不太一样。这是 VM 的第一个大的改动。

VM 的第 2 个大的改动是写在 RFC0033 里的。0033 规定的是虚拟机版本。

包含了所有的变化，有已修复的 bug，也有内部指令格式的重新设计。虽然同样是去解释 RISC-V 指令器，但是内部其实有很多做法。

还有一些是为了方便 debugging，为了方便 CKB 上的系统开发者、合约开发者去做调试而从虚拟机层面做的新的改动。还有的是为了提高性能做的改动，比如说 Lazy initialization memory，MOP。

其中最值得注意的是，为了更好地实现，或者提高密码学原语解释能力所做的改动，新的虚拟机版本第一次引入了一个 RISC-V Extension，也即 RISC-V 的扩展指令集。RISC-V 它有一堆核心指令集，它还有很多扩展包，CKB 新版本 VM 是第一次引入了一个扩展包，首先证明这件事情是可行的。其次，刚好和多版本的虚拟机架构一起使用。

这次我们引入的扩展包是 B Extension，就是大数的计算的扩展指令，就 4 个指令，当然它验证了这个设计和模型是可行的，我们也用 B 指令尝试去优化了一些密码学的算法，也验证了确实能够带来性能的提升。这是另一个非常重要的改进，而更多扩展指令会在下一次hard fork的时候引入。这次hard fork 里面，我们先把一个小的改进塞进去，然后验证成果，如果成功的话，我们在下一个 hard fork 的时候就可以塞进去一个更大的改变，下一个 hard fork 我们计划要塞进去的就是RVV——向量指令集（RISC-V Vector）。

向量指令集能够给密码学原语带来的性能的提升会更大。如果说 B 扩展指令集带来的密码学原语性能提升可能是10% 到 20% ，那么向量指令集极有可能带来百分之几百的性能提升，这个差别会非常大。

如果 0033 里的这个 VM 版本验证了说这这一切都是可行的，那么后面就是按照前面踏出来的这些方法往下走就行，只是在工作量上会有差别，B 扩展只有 4 条指令，RVV 则可能有 200 条指令。

以上是虚拟机 VM 里面的第 2 个大的改动。

虚拟机里面第 3 个比较大的改动在 RFC0034 里，它引入了新的 syscall（系统调用），加入了 3 个新的 syscall，其中最重要的是一个叫做 exec 的系统调用。如果你把 CKB 当做是一个 kernel 的话，exec 就和 Unix 里面的那个 exec 一样。

那么，在 CKB 里面使用 exec 是什么意思呢？其实是允许一个合约在执行过程中，通过刚才说的合约地址引用的方式，或者合约代码的hash引用的方式，去引用另外一个合约，跳到那边去执行。就把当前进程执行的代码替换为另外一个合约的代码，简单来说就是这样。

那么它为什么很有用呢？ 它增强了合约的可组合性。 我现在可以有 ABC 3个合约，它们最终可以通过 D 这个合约把 ABC 3个合约组合在一起跑起来了。那我们就可以把之前 lock script 设计成一个模块，利用 exec 去调用这些模块，去调用比如说签名算法 A、签名算法 B、签名算 C，然后再加一点自己的业务逻辑。之前要写这样的功能不太方便，但升级之后，写这种东西会非常方便。之前也有动态链接库之类的方式在易用性和安全性方面有些欠缺。这次 hard fork 就把可组合性又往前推了一步。经过两年的发展，在可组合性方面，社区提了很多意见，然后最后落到这样一个方案上面。

上面这些是 VM 的改动。

另外一个影响比较大的改动是在区块的结构上，区块的结构上其实从代码层面来说具体的改动非常小，只引入了一个名叫 extension 的新字段，加到 block 结构里，这样做是为了 CKB 未来有更好的扩展性。

这个 extension 是个可选的字段，最多能放96字节的数据，最少也可以不放数据。有了这样一个可以扩展的字段之后，我们下一步要做轻节点客户端就有了落脚点。因为要往 CKB 协议里面加入轻节点的协议，其实需要出块节点在共识的时候去做一些额外的计算，然后把计算结果放到某个地方。如果没有这样一个扩展字段的话。那些辅助的数据，也就是对于轻节点协议非常有用的数据就找不到地方放。

在这个方案落地前，我们想了很多种方法，包括是不是可以重用现有的这些字段来解决，发现都行不通之后，最终非常不情愿地往里面加了一个字段。不过有了这个字段后将带来更好的扩展性，它不光光是轻节点协议可以用，未来还有更多的涉及到协议级别的改进需要在区块里面加一些数据的话，这个字段也可以用。所以它既能满足接下来轻节点协议的需求，也能够满足更远的需求。

回过头来看最终落地的方案，就回到刚才一开始我说的那个理念上来，

我们总是在寻求改动最小的方案。如果从 1 只需要走到 2 就刚刚好，我们绝对不会走到 5，因为更多的事情要放到 2 层、3层、更上层、应用层去做，内核我们要尽可能的保持小、精简、稳定、安全，这是一以贯之的理念。

如果抛开这个理念，其实我们也可以改得非常快。我们可以想到什么就往里面塞就完了，但是那样经年累月之后，你其实会得到一个非常臃肿的设计。一个非常典型的例子就是 C++，名字就可以看出，一开始 C 语言，C 语言非常精简，然后觉得 C 语言还缺东西，就往里面加，一直加，每年都在加。现在 C++ 已经包罗万象。你就会得到这样一个东西，它其实不是一个好的设计，到现在 C++ 也不是那么流行了，与发展理念有很大的关系。对底层细节了解的朋友可能知道，Bitcoin block header 经过了 10 年发展还是只有 80 bytes, 内部结构非常紧凑。CKB 稍微大一些，208 bytes. Ethereum 508 bytes, 保持的也是不错的。其他的大家有兴趣可以自己研究一下。这些细节为什么重要？越大的 block header，经年累月之后，就是越多需要轻节点同步的数据。

总而言之，因为 CKB 秉承这样一个理念，导致了我们在做 hard fork 设计的时候会非常小心的去做一些设计的选择，而这些设计的选择，产生的效果其实是非常底层的。它们是一些最小的必要改动，我们相信通过这些改动能够满足社区开发者、合约开发者、应用开发者、系统开发者他们的需求，能够解决他们的问题。这次 hard fork 之后，我们还需要做什么升级？大家又有什么新的问题冒出来，有什么新的需求提出来，我们可以再讨论，再去设计，然后去计划下一次升级我们应该做什么。

Q3：主网升级之后，对生态项目有什么影响？

Jan： 首先对于 dapp 这一层来说，这些升级的变动需要应用开发者把它吸收进去，然后才会对用户产生影响。这个问题可能最好是要用问一问，Nervos 上的应用开发团队，看他们怎么去利用这些变动，实现什么新的feature，或者带来哪些用户体验的提升。

对于钱包交易所而言，最大的改动其实是涉及到一个地址改动。对于他们来说，升级节点其实是非常容易的，因为对节点升级，无非就是把这个二进制文件替换一下就升级完了，所有东西都是自动的，SDK 也已经做完了，只要升级一下版本也都是很容易完成。

这里需要注意的地方就是地址格式地址的标准有有一个变化，这次 hard fork 是连带着地址标准一起在升级。之前大家都知道就是说我们有长地址短地址。hard fork 之后，默认了统一的格式，就是一种新的长地址（严格说地址格式不是一个需要 hard fork 的底层变化，而是一个应用层标准变化，只是为了方便合并到这次 hard fork 升级一起做了）。这个可能是对生态项目、钱包、交易所一个比较大的影响。

对于矿池来说，也是升级就好了，其实没有太多的影响。

Q4：看介绍说主网升级后 CKB 地址会统一成固定长度格式 这是否意味着以后所有 dapp 应用的 CKB 钱包地址都会是唯一一个，不再会出现现在一个应用一个钱包地址的情况？

Jan： 这是一个很有意思的问题，因为它又涉及到 CKB 的设计思路。

首先，这次主网升级之后，地址规范会统一成一个固定长度格式，至少是默认地址是这样。 为什么我要强调默认呢？因为开发者用什么地址格式、应用方用什么地址格式，是应用自己的自由，这个是没有办法强迫的。这只是一个标准，大家自由选择是不是用这个标准。这次有变化的是默认的标准：之前的问题是默认的标准包含两个格式，一个长地址，一个短地址，新标准只有一种格式。

但是，这并不意味着所有dapp应用的 CKB 钱包地址都会是唯一一个地址。

虽然地址不是唯一一个，也并不一定意味着用户体验就会不好，这些问题都是分开的、独立的问题。

我们从反馈来看，大家之所以对对长地址短地址这个事情这么讨厌，是因为用户体验不好嘛，但是用户体验不好，它是很多层的问题，可能不光是地址格式的问题。举个例子来说，比如说我们在 SDK 这一层，假设我们生态成熟以后，SDK 非常完善，Mercury、Lumos 通通非常完善，无论有什么样的地址格式，这些中间层都能够支持，那么对于钱包、交易所以及 dApp 应用的开发者，因为他们其实都是用 Mercury、Lumos 这些中间件 SDK ，而不是直接使用 CKB RPC，最终也可以实现良好的用户体验。

中间层如果做得比较完善，即使底层有 100 个地址，你可能也没有感觉。 这是分层的好处，因为中间层可以把底层的细节给隐藏掉。hard fork 之前的问题是，因为中间层不成熟，导致底层的细节冒到了用户的眼前，给用户造成了很大的麻烦。这是我对这个问题的定义。

那么，在生态还不成熟的时候，我们是应该慢慢等中间层成熟，找到一个很完美的方案去解决这个问题呢，还是说我们不必等到中间层成熟了，先把地址格式改为统一长度的格式？

经过大家的讨论，核心团队、社区团队，包括 UniPass、.bit 团队，我们都有开会讨论过，然后我们决定先把地址改成统一一个，至少解决先解决眼前的问题。这样不管 SDK 中间层做得好不好，那至少我们之前遇到的问题可以没有。

但是往未来看，CKB上依然会有多个地址，甚至对于每一个 dAPP 可能会有不同的地址，这个是 UTXO 模型的一个特点，由此带来的用户体验的问题，是需要中间层去解决的，因此我们在设计 Mercury 和 SDK 的时候，会非常注重去考虑如果有了一个新的 script 出来，它会映射出一个什么样的地址。如果映射出了一个相同的地址，那当然没有问题。如果映射出了一个不同的地址要反映到表面上，是应该让用户知道这件事情还是不知道这件事情？我们要怎么样去把这整个环节都设计好，让用户对这个没有感知，不会再遇到之前长地址短地址之间的那些麻烦。 这个是未来我们要去考虑的问题。

所以简短来说，我们现在其实是采取了一个大家都满意的临时方案，统一成一个固定长度，大家都没有意见。未来，我们应该在保证用户体验的情况下，整个社区共同去探讨地址的格式该如何去演进。

为什么还是可能会有多个地址呢？ 这是非常有意思的事情，不知道大家有没有用过比特币的钱包。真正原汁原味的比特币钱包，比如 Electrum，或者是官方客户端带的钱包，你会发现它默认会给你生成一大堆地址。可能很多比较晚接触 crypto 的人他们做的钱包就没有这么做了。那真正的比特币钱包为什么要这么做呢？这不是自找麻烦吗？一方面这是因为地址和账户本来就是不同的概念，只是因为以太坊的流行模糊了两者的定义。其次这样做其实有很多好处，例如更好的隐私保护。如果只有一个地址，你所有的活动都和这一个地址关联，用大数据分析非常容易发现你是谁，如果想要保护自己的隐私的话，最好的方法是每次操作都用一个不同的新地址。

我不知道大家平时钱包里，同时在用是一个地址还是有 3 个地址，其实账户系统在隐私这一点上不是很好。像 Electrum 这样的比特币钱包是会一直自动更换地址的，你用过一个它就给你生成一个新的地址，再收一次钱，它又给你生成一个新的地址。在比特币的系统设计里面，地址和账户是 2 个概念：账户不是和地址一一对应的，账户和地址一一对应，是以太坊的设计。

比特币的设计里，一个账户可以有无数个地址。那其实我们完全可以通过系统设计做到，用户只需要记住账户就行，他其实不用关心他这个账户下面对应了 10 个地址，还是 100 个地址，只要底下的这个中间层能够帮他自动处理好他每个地址的生成、找零、转帐和收钱，他从账户这个视角看，所有地址的资产都在这个账户里面，其实对于用户来说，体验是一样的。（后期整理文稿时备注：如果你用过 Nervos 官方的钱包 Neuron，你会发现每次收款之后都会生成新的地址，你下次收款时，它会从你这个账户下挑出一个从未有过交易的地址给你，这让你用起来与以太坊钱包的体验一致，不过能更好地保护你的个人隐私）

地址和账户变成一对一的这个关系是以太坊成功之后才出现的一个转变。 但是，如果能够把地址和账户解藕，其实是有很多好处的，刚才讲的隐私就是一个。另外一个好处是，因为我可以有不同的地址，我的地址本身是能够编码信息的，这个编码的信息能够提示钱包应该做什么相应的动作。这样一来，它会把钱包和应用之间的协议变得更加强大。

最后总结一下，同一个账户下有几个地址其实不是关键，我们可以逐步去探索。这个点其实是非常缺乏研究和探索的，因为大家现在都被以太坊那个设计给带到那边去了。我们先让大家的用户体验变得更好一点，未来，我们在保持用户体验还是很好的情况下，去探索底层的设计应该是怎么样？逐步地去完善相关的设计。

我希望大家不要简单的下结论说只需要一个地址就是好的，其实不是的，里面其实有很大的设计空间。如果说我们现在有一个明确的原则，那就是我们要在保证用户体验的情况下去探索这个设计空间。这样是一个大家都满意的双赢结果。

Q5：本次主网升级，是否会提供轻钱包支持？另外官方是否有开发轻钱包计划？

Jan： 本次升级不会有轻钱包的支持，因为轻钱包需要轻节点的支持，轻钱包和轻节点是两个东西，轻钱包是利用了轻节点实现了钱包的功能。

那么本次升级也不会有轻节点协议，我们刚才说了，这次先要在 Block 结构里面做一些改动，增加一个扩展字段，为下一次 hard fork 加入轻节点协议做准备。

是否有开发轻钱包的计划？我们确定的是我们今年有开发轻节点协议的计划。开发轻钱包这件事情我其实更希望通过社区实现。也许有些其他的区块链，官方把各种东西都做了，但 Nervos 我觉得是需要社区共建，大家一起来做这件事情的。这个也是和理念相关，开源和去中心化，其实非常重要。

Q6：有很多用户比较关心的问题，主网升级后有生态项目准备发布吗？

Jan： 这个我应该回答有还是没有呢？

就时间关系上来说，有。主网升级后一定有新的项目要出来，然后有新的项目要升级，因为刚才也说了，这是内核升级，应用需要同时去做一些调整，才能够把内核升级的好处发挥出来。

但是从逻辑上来说，它和主网升级可能也没有太大关系，只是刚好一个先后顺序罢了，没有必然的联系。

Q7： 主网升级会硬分叉吗？升级会不会影响秘宝上的NFT转账？对于挖矿效率有影响吗？

Jan： 对挖矿效率不会有影响，因为挖矿的算法没有变，就不会有任何影响。

升级会不会影秘宝上的 NFT 转账？升级本身不会有什么影响，主要还是看秘宝自己的计划是怎样的。

会硬分叉吗？主网升级就是硬分叉，它不是像 The DAO 那样整个社区意见很割裂的硬分叉，而是一种大家已经有预期的，大家都同意的一种硬分叉，所以我觉得不会有两个链出来，因为只有在社区意见非常割裂的时候才会形成像一一ETH、ETC那样的情况，那种情况从整个区块链的历史来看其实非常非常少见的。

Q8：从官方公布的主网升级内容来看，更新了新的密码学标准，可以提高 Nervos 网络的效率和性能。Nervos 一直把安全性放到首位，那本次性能的是牺牲了部分安全性来换取更好的性能，在这两点之中进行权衡呢，还是在确保安全性的同时追求更好的性能？ 另外就是有一些社区用户对 Nervos 网络的性能不太满意，那本次主网在性能方面的提升对普通用户的感知是否明显？

Jan： 我觉得对于用户来说，感知是非常非常小的，甚至是无感知的。

因为我们这次新增了Risc-V B 扩展的 4 个指令，只是在 VM 的密码学层面去使用这些指令集换来更好的性能。而密码学在整个应用里面，可能又是一小部分，因为作为一个 dApp，有前端，有CDN，有后端，还有链上的合约，以及用户的网络环境，系统性能是整个链路决定的。

等我们上线了 RVV 指令集之后，可能会带来明显感知的性能，因为那个对于密码学的作用非常大。但是这又回到我刚才说的 dApp 是由一长串的链路组成的，它是有很多组件，即使某一个组的性能翻了 10 倍，整个应用的性能在用户体验来说，他可能只感觉到进步了 10%。

对用户而言，可能感受最明显的性能是链的处理速度，就是我从发一个交易开始，什么时候这个交易能够被确认，但是这个性能不是 CKB 追求的点。我一直在强调，CKB 和其他的链其实完全不一样，理念上就根本就是不一样。这方面建议大家去看张韧对共识的解释，我觉得经过行业几年的实践基本上也认同我们的观点了。简单描述就是，公链性能吞吐量的瓶颈是全球网络的平均带宽。 那才是瓶颈。

为什么呢？因为如果希望一条链每秒钟处理 1 万笔交易，假设 1 笔交易是 200 字节，1 万笔交易，就是 2 Mb，这就意味着你必须至少提供平均 2Mb 每秒的网络带宽。10 万笔，那就是 20 Mb 的带宽，100 万笔就必须提供至少 200 Mb 每秒的网络带宽。这还只是理论极限值没有任何损耗的情况下。

但是，你还得花很多带宽，比如说 30%、40% 的带宽花在共识消息上面。因为你不可能把所有的带宽用来只传递你的交易，没有共识对吧？这些是物理的限制。这不是你设计共识或者怎么写软件，或者怎么设计区块链能够改变的，这是物理条件的瓶颈。

所以在我们看来，最有效最高效的区块链，或者「性能」最好的区块链是最能够有效利用带宽的区块链。同样给你 20 兆的带宽，你的 TPS 能做到多少？这是我们一开始就定义清楚的。

有些区块链宣称自己的 TPS 达到多少万，你要去研究它的测试环境是什么？测试机器、测试节点的硬件条件是什么？它放弃了什么东西？

我们确实可以把性能做上去，我们需要放弃去中心化。没关系，我们可以放弃这些东西，我们追求更好的用户体验，我们就要 1 秒钟 1万笔。

要保留什么，放弃什么，就是理念的不同。放弃去中心化和安全，不是CKB的理念。比如说比特币，就不这么做，以太坊其实也没有这么做。大家都有自己的准则，CKB其实也有自己的选择。比较的前提是要明确一个链的理念和有意识的选择是什么。把做了同样选择的链放到一起去比，这样才是一个合理的对比。

CKB 的定位是一层，内核，SoA，它必须要保证去中心化。 CKB 的 NC-Max 实现，已经是性能最好了。如果你让大家把前提摆平，NC-Max是效率非常高的共识。

NC-Max 是经过科学的研究方法评议，并在 CKB 主网实践中得到验证的共识算法，刚好最近发了论文，已被信息安全界的四大顶会之一 NDSS 接收。

相比来说，某些区块链的 paper ，在我们看来是既没有经过实际的网络考验，也没有经过任何同行评议的预印本网站上的草稿而已。

我们也可以去追求用户体验，也可以为了用户体验去放弃一些东西。但那个可能就不是 Nervos 或者 CKB 想要选择的路了。而且 Crypto 市场这么大，百花齐放，都挺好，如果欣赏那条路，可以加入其中，我觉得这样做没什么问题。现在有非常多的公链项目，大家都有各自的想法和定位。我认为要避免做的一件事情是，我喜欢想法 A，然后找了一个想法是B的团队，然后不停地试图说服这个团队，说你们应该把想法改成A。 除非这个团队一开始就没有想清楚要做什么，随波逐流，有可能会这么做，但如果团队思路是清晰的，不可能做这样的改变。注意我说的是核心理念的改变，不是表层体验的改变。

再说回来，虽然 CKB 要追求安全，在这个前提下再追求最大化性能，这并不代表说 Nervos 整个网络就很慢。这是因为 Nervos 是分层网络，性能是放在2层而不是1层解决。我们现在看到的 Godwoken 是一个例子，它带来的体验应该说是有进步，但还不是很高，这是为什么我们还需要 Axon 等等。所以，你可以看到CKB、Godwoken、Axon，它们是在安全、性能、去中心化这几个点之间来做不同的权衡。（安全、性能、去中心化是区块链领域著名的不可能三角，在同一个组件里，你想要任何两项特性达到极致，一定会牺牲掉另一项特性的能力。）

对于 Nervos 来说，需要呈现就是，不管我们做了什么样的权衡，你都能找到一个对应的方案加入到网络中来：

• 如果你非常想要安全性，想要去中心化，你就在 CKB 上面做开发。
• 如果你非常想要高性能，你可能要去 Axon 上面做应用。
• 如果你觉得你就想中间一点，你可以选择 Godwoken 。

这是整个分层网络的意义。如果单看每个组件。它不会是满足所有需求的那个东西，但是当这些组件组合起来时，是一个能满足所有需求的东西。

Q9：升级工作中最大的难点是什么？团队是如何克服的呢？如何让市场认可项目在技术方面的产出？（如何把我们的技术成果传导到外界）接下来在生态应用方面的动作是？

Jan： 升级工作中最大的难点是什么，我前面其实也讲了，就是在依然保持去中心化、保持 SoV 语义，在保持这些东西的前提下去做这些升级是很难的。

如何克服的？我觉得不存在克服，因为也花了很多时间去研究方案，去讨论，最后能够想出一个最终落地的方案，整个过程下来，大家还是比较努力在琢磨这个事情该怎么做对。

如何让市场认可项目在技术方面的产出？我觉得如果能够把这些改动吸收到应用层，让用户感知到，这是很重要的。

另外一方面就是要去做更多的技术解释、技术的宣传，把我们做的事情给传递出去。就像今天我在这儿做 AMA （谢谢一休哥组织！），这些我觉得是必须要去做的，然后大家如果关注的话，也可以注意到最近我们也写了很多blog，花了很多精力写文章解释 CKB 的技术细节，我们希望能让更多的人看到我们做的事情，能够吸引更多的开发者来研究 CKB，来在 Nervos 上做事情。

Nervos Foundation 也做了很多事情，开发者关系团队也不停地参加各种开发者的会议。虽然疫情会对整个事情有一些影响，但是我觉得，2022年是会更加多地去参加这些会议，相信大家最近也在 Nervos 官方的 Twitter 上看到最近参加的会议。（Nervos 在 2022 年举办了多场 Hackthon，还有一些是正在或者即将进行的，通过一个又一个的 Hackthon，不断地吸引开发者到 Nervos 上来开发）

Q10：接下来在生态应用方面的动作有哪些呢？

Jan： 接下来有 2 个重点，都是在 Layer 2 上的。

总体上来说，大家可以认为 Nervos 在 2022 年是有一个从下到上，从1层到2层整体的一个升级 ，CKB 的 hard fork 可能是一个开始，接下来就是 Godwoken 从 V0 到 V1 的升级，这也是一个非常大的升级，有非常非常多的改动，这些改动的一个核心的目的是要让 Godwoken 整体上和以太坊的兼容性更加好。这个兼容性，我们之前可能做到 95%，还剩下 5% 没有做好，这次想要把这些问题一起都 fix 掉。

（Godwoken V0 版本）剩下 5% 没有做到确实是因为这个事情有点难，因为我们是在一个新的 PoW 链上，在 UTXO 模型上做兼容，其实是有一些挑战的。

但是这次我们觉得它将是一个比较大的提升，今年的生态，更多的发展可能会出现在 Godwoken V1 上面，而不是在 CKB 上面，因为我刚才说了 CKB 是内核，它离应用就比较远，你得有比较硬核的技能，才能够在 CKB 上写东西，因为你可能要用到 Rust，你要去理解 CKB 的编程模型、syscall 这些东西，但是在 Godwoken 上，因为它和以太坊是完全兼容的，已经有一整套现成的工具了，你会更容易地去做这件事情。目前在 Godwoken 上做开发是比较容易的，V1 会进一步降低这个开发门槛。

整体来说，我们既要去探索新的道路，同时在当前我们又要去兼容以太坊，至少先把眼前能吸引的开发者先吸引过来，逐渐地通过 Layer 2 的繁荣将更多开发者引导到 Layer 1。开发者在熟悉了 Layer 2 之后，他可能也不可避免地要去接触 Layer 1 的一些概念，要去接触 CKB 的概念，CKB 的技术栈。这样先有一个庞大的 Layer 2 的开发者群体，其中逐渐会出来一些对 Layer 1 有兴趣的开发者，他自然会慢慢去钻研更底层更深的东西。就像你做应用开发，你写 iOS App，你写着写着你的 App 变成了有 1000 万用户，你可能不可避免的要去琢磨 iOS 内部的设计，底层到底如何运作的？你不可能一开始就去关心这些东西，因为你只服务 100 个用户，只需要关注应用本身就可以了，这个门槛是很低的。

所以说，现在这个阶段，我觉得 Godwoken 上的生态会发展更快。

在 Layer 1上，也有一些非常硬核的团队，.bit（升级品牌前叫 DAS）、UniPass、Kollect、秘宝，他们面临的挑战会更大，或者反过来说，CKB 给他们的挑战更大，但是这些项目也可以更直接地利用 CKB 的特点带来的好处，有利有弊。总体上 Layer 1 这边的生态会发展慢一些。

另外一个重点是，Axon 可能在下半年会上线，这取决于有没有项目去使用它。Axon 的特点是性能好，它的性能可能好过现在市面上所有的链。（作为 Nervos 的 Layer 2解决方案，Axon 通过使用 Overlord 这个高性能的共识算法，可以轻松实现数千 TPS。这为 Nervos dApp 开发人员提供了另一个选择。Godwoken 非常适合低吞吐量和高价值的情况，比如 DeFi，在这种情况下，安全性通常比速度更重要。在去中心化游戏或社交网络等面向消费者的应用程序方面，Axon 提供了最佳的性能。）

这就是分层的好处，Layer 2 的好处，你不用像有一些链一样，既要性能好，又要考虑一些 Layer 1 的东西，就很中庸。既然我是 Layer 2，我就可以在性能上面去做优化。

如果 Axon 上线，其生态应该也会发展比较快，因为 Axon 也是和 EVM 完全兼容的。我们在 Godwoken V0 的这个开发里面学到了非常多的经验和教训，并且这些经验和教训都被吸纳在 Godwoken V1 以及 Axon 的设计思路里面。

生态的发展这方面的动作，我知道 Nervos Foundation 开发者关系团队，他们最近非常活跃，找了很多项目在聊，不过具体项目我不太清楚。

Q11：能否透露一下 Godwoken V1 版本的升级计划？

Jan： 我估计测试网在 5 月中旬会出来，然后测试网出来之后，会有很多项目开始在测试网上开发测试；预计测试网阶段会是一个月左右，如果一个月没有遇到大的问题，就可以主网上线，所以主网上线可能会在 6 月份。

Q12：能否举例说明下，当下有哪些热门应用或者您觉得可能未来会比较热门的应用，是 ETH 或者其他公链上实现不了的或者实现起来非常困难的，只有基于 CKB 开发才能实现的吗？

Jan： 首先这个要分理论和实践两方面。

首先，理论上现在所谓的新一代公链，都可以实现任意的东西，因为新的链基本都是准图灵完备的。

但实际上，每个链会有自己擅长的方向，会有自己独特的地方，或者说更容易去做的东西。比如说以太坊，它更容易做的就是 DeFi 类的应用，这是非常明显的，因为它整个合约模型的设计非常适合做 DeFi。它记账，它有账户，账户里有余额，这个非常适合金融那套体系。

CKB 上也有非常适合的东西，比如 NFT，在 UTXO 模型上是非常合适的，本质上每一个 UTXO 就是一个 NFT。比如说在 CKB 上面能做到的一个非常有意思的点，就是你在转让 NFT 的时候，不需要额外支付手续费，或者说，如果我把我的 NFT 给送给你，你再把这个 NFT 送给别人，你直接转就完了，在这个 NFT 的用户体验里，它可能没有 CKB 的这个概念，他没有意识到他其实支付了 CKB，他看到的只有 NFT，这对于用户其实是非常友好的。

比如说我送你一张球星卡，你觉得这个球星卡特别好，你就把它送给你的朋友给她作生日礼物。这个时候，如果我对你说：「等等，你还不能转，你得去先买点 ETH 才能转，否则你没有钱支付手续费，没有钱支付gas！」这个用户体验是非常差的。

大家注意到了吗？你可能没有意识，因为你已经习惯以太坊给你定下的这套规则。

但是如果从第一性原理来说，或者说你是从互联网世界来的人，你会觉得这个很别扭。

互联网不是这样的，我在现实里面也不是这样的。我在现实里面给你送一张贺卡做礼物的时候，不会有美联储跳出来说，来来来，你先从我这获得1美元用来付手续费，这是一个很奇怪的模型。

如果说 NFT 非常适合 CKB 或者 CKB 这个模型的话，我觉得很有意思的一个探索方向是，我们其实可以在 Layer 2 上去做一个 Cell 模型的链。因为我们现在时间有限，只能优先去做 account model 的 Layer 2。如果有更多的时间的话，其实我们可以做 UTXO 或者cell model 的 Layer 2，然后在 cell model 的 Layer 2 之上再去做 account model。这些都是可以做的，并且这些不同的设计有同的好处。

再举另外一个例子。

因为 CKB 是比特币这种模型，不知道大家注意到没有，比特币和 CKB 都有一个特点是失败的交易是不上链。 以太坊上即使你使用一个 dApp，你失败了，你的交易还是上链，你还是会被扣手续费。比特币和 CKB 都不是这样的，失败的交易不会上链，你也不用为你失败的交易付额外的手续费。

你从自然人的角度来看，这才是合理的，以太坊的设计是不合理的——如果今天你的银行告诉你说：「呃，不好意思，我给你开银行账户失败了，但是我还是要收你 100 块的手续费」，或者说「不好意思，你要买这个理财产品卖完了，你的额度没有了，把钱退给你，但是我要从中扣 1% 的手续费。」

你会觉得合理吗？你肯定觉得不合理！真实世界是不会这么做的。

但是以太网这么做，有他的理由：因为基于账户模型很难安全实现上链之前的执行分析。 如果不让失败交易上链的话就会存在 DoS 的风险，其后面有一整套基于安全的理由，从技术角度来说，它是合理的；只不过在用户体验角度，它并不合理。

上面这些是基于 CKB 开发应用的一些有意思的点。总的来说，当你基于一个非常不同的原则去重新设计一套完全不同的系统。比如有一个系统往左走，另一个系统往右走，它们在上层一定是会有非常非常多不同的细节和不同的能力。所以你问有什么是别的链上实现不了或者实现起来非常困难，简单来说就是有。刚才给了 2 个例子，有没有更多的？需要大家一起去探索。比如说 NFT 这个很有意思的特性，是 UniPass 的知县告诉我的，我当时也没有想到。

我们整个社区其实在一边开发，一边探索一边摸索，具体能摸索出什么出来，我觉得现在谁也说不清楚。唯一清楚的一点就是，我们很明显在走一条不同的路！

（END）

---