2021.04 BSV 开发技术与工具概览 (v2)

Overview

这是我在 2021-04-12 BSV Bootcamp 上关于 BSV 开发技术与工具的介绍，可看作是去年10月同主题演讲的升级版。

2021.04 BSV 开发技术与工具概览 (v2)

去年 10 月份，比特币协会在深圳主办了一次 BSV 的开发者活动。我本人在那次活动上做了一场名为 “BSV 开发工具和技术概览” 的分享，介绍了一些 BSV 开发相关的工具和技术。

半年后，在今年 4 月，比特币协会在东澳岛主办了 BSV 的第一届训练营 (Bootcamp)，我也接到了延续上一次的讲解 “BSV 开发工具和技术概览” 的任务，就在继承了框架的基础上，对分享的内容作了整理和更新。以下是分享的简略文字稿。

大家好，我是顾露，是比元科技的创始人，也是小聪游戏的开发者，也是 Sensible Contract 的参与者，非常荣幸我们小聪游戏能协助比特币协会举办本次 Bootcamp 的活动。要是算上次在深圳的创新会的话，我们是第二次有机会作为协办方，跟比特币协会一起为开发者组织这样的线下活动，非常高兴。

解释一下题目。半年前，我们做了一个这样的技术和工具的分享，但是因为更新很快，当时的分享包含了一些已经过时的内容，我就对内容作了适当的调整和优化，也增补了一些新出来的信息。(对这个调整版) 我给它升了个版本叫 2.0。如果有可能的话，我希望这个系列能够做下去，以便于及时淘汰掉一些不合适的内容，然后加进来一些更高质量的，我们认为对开发者更有帮助的内容。

今天的内容框架大概是这样的：屏幕上左边的这一列是比较常规的思路，就是从协议，到工具，到服务 (数据服务，API服务等)，到框架。就是构造一个 bitcoin 程序，需要的方方面面的开发资料和工具，以及如果想深入的话，理论知识需要从哪里获取。这是左边的常规提纲。然后在右边，我列了几个可能对开发者有所帮助的技术，来自几家独立的公司和团队，一个是 nChain，一个是 Xoken，一个是 Sensible。

常规的工具和库

好，现在我们进入第一个主题，协议部分。

在上次分享技术概览的时候，我没有列出最重要的协议——就是所谓 “协议的协议” ，也就是比特币的白皮书。

白皮书的重要性，可以说怎么强调都不过分，之前没重视这点是不对的。可能不少人觉得，白皮书没多少内容，像 POW，矿工网络，这些内容，都是大家已经滚瓜烂熟，天天都在聊的内容，好像没什么特殊的东西吧。但是其实白皮书挺深的，如果过一段时间，你读一次白皮书，发现自己读出了新东西，那说明对比特币的认知是有进步的。对比特币的白皮书，如果缺乏深入的理解的话，是非常制约在比特币上做开发，尤其是长期的工程化的实践了。

前段时间我的好朋友蒋杰，闲聊的时候他问我，白皮书里有啥内容，你还记得不？我回想了一下，然后说了一些我觉得比较重要的点，他听完了以后，神秘一笑。但说实在的，其实我挺慌的。因为我发现，我并没有自己以为的那么理解白皮书的内容，更别说抽丝剥茧，理解背后的脉络了。

(这里我们现场互动了一下，听了下几位观众对白皮书的理解)

非常感谢两位同学的发言。那么我们来看白皮书最先引入，也是最先被讨论的概念，某种意义上对比特币系统来说最根本的概念，就是 交易。

对，你没看错，既不是区块，也不是链，更不是矿工，挖矿，激励…而是交易。

你就会问了，为什么是交易？ 白皮书为什么上来就讨论交易？

原因很简单，因为 交易，以及对交易的处理，就是比特币的核心目的。

在那之后描述的链状签名只是一种实现机制， Alice 签了以后给 Bob， Bob 签了以后再给 Carl，依次往后传递… 也就是说，链状的签名只是它的一种软件实现。

白皮书从交易谈起，说明它是符合 “第一性原理” 的。关于第一性原理，我来举个例子吧。

什么是第一性原理？

比如说马斯克造火箭对吧，他是什么思路，他一上来不是要改良现有的系统，不是说看现在的火箭是怎么造的，我怎么能优化一下，把哪个地方做得更好。

他思考的第一步是什么？是组成火箭的原料有哪些，这个材料是否合理，是否可回收，这些都是非常根本的问题，决定了马斯克的火箭跟传统火箭有质的不同。按照这个思路，把问题一项一项往前推，倒推到根上去，从头开始分析这个问题，所以才能做到自底向上，从最小的碎片拼凑起来，最终形成的，是一个我们认为是突破常规的这样一个方案。

这就是所谓第一性原理。就是你思考问题，不受已有框架的束缚，回到这个系统想要解决的根本问题上来，从根本出发，然后再去一步步构造你的系统。所以大家才会看到白皮书，觉得惊为天人，竟然构造了一个前人完全没想过的系统。它深刻地反映了第一性原理，从最根本的事物，这个系统要解决的问题，也就是交易本身出发。这是值得大家留意的。

好，说完了作为核心的交易，我们来看第二层，也就是白皮书里提到的，或者说他引入的第二个被重点阐述的概念，是时间。

那么 “时间” 对比特币系统为什么这么重要？

这是因为 时间的自然流逝，才是比特币系统的内在的本质。利用这个时间的 不可逆 的特性，我们才有了区块链这样一个链状的数据结构。区块链每 10 分钟出一个块，最后形成一个链。它为什么很自然的形成一个链呢？因为它就是时间的表现。

区块链是怎么来的？

你沿着头部的创世区块往后看，就能发现，这个系统整体上是时间从物理世界到在数字世界的一种模拟，这个链条就是时间本身。

其实就是无穷的，海量的，没有终结的交易序列，随着时间的流逝，逐渐凝结到一个接一个区块里，这样一个过程。而这个凝结的过程就是由所谓的 POW 来保证的。

如果你明白这个时间对这个系统的意义的话，你忽然就能明白，为啥不仅仅是区块是按照时间顺序往后排的，而且忽然也能理解为什么我们要求区块里的交易也一定要是按照时间顺序依次排列。

好，到这里，从白皮书第一个引入的概念 “交易”，我们往外推了一层，讲解了第二层 “时间”。

大家注意，“交易”和“时间”这两个概念，已经可以把比特币这个系统给撑起来了。后面的若干层也是系统的重要组成部分，但是他们不是系统核心概念。

接下来我们看白皮书的第三层，这是一个 P2P 的节点网络。

那么 P2P 节点网络实际上已经被讨论得非常多了，因为大家关心矿工的行为，怎么去挖矿，获得收益，被系统设计的激励机制，然后怎么样让自己的算力更多，然后跟其他人竞争，以及在竞争当中为了保持收益，或者说扩大收益，他们要诚实，累积自己的信誉，等等。

那么，这一部分内容是在说什么呢？ P2P 网络也好，激励系统也好，诚实也好，是想表达什么意思呢？

白皮书是在告诉你，这个系统的可增长性。它是通过设计了这样一个 P2P 的网络，以及附着其上的激励机制，来确保网络本身有足够的可成长性。不仅仅是在过去的初期，到了现在的中期，未来的长期，以及 2140 年甚至更久远的以后，系统以 P2P 网络的形式保持增长。

白皮书对矿工网络的基本行为和激励机制都做了一定的描述，但是我们知道，不管是后来的矿工专门硬件也好，所谓小世界也好，都是系统不断演化的结果，未必是一开始完全规定好的，以后也必然会继续演化。

比如说，系统激励如果降低的比较快，跟咱们预期的不一样，手续费没跟上，怎么办？

如果以后人类能星际航行，行星之间的延时，怎么办？

如果需要考虑，到时候戴森球上太阳挖矿，那怎么办呢？

诸如此类的发展带来的问题，就需要在发展中解决，而系统作为一个整体，也得以在一次次解决问题的过程中一步步发展。

这就是比特币这个系统里白皮书描述的第三层——P2P 节点网络以及所谓的激励机制。

他们虽然重要，是系统的重要组成部分，但不是系统的核心概念，是系统关于增长性的一种设计和实现。

好了，说完了白皮书的前三层，我们进入第四层。大家可以留意，我讲述的顺序是按照白皮书的原始讲述顺序。

白皮书讲了由内及外的三层了之后，它的第四层是什么？

是关于系统的可持续性的，也就是通过 “效率” 和 “优化” 来保证系统的可持续发展。

这个可持续性，主要有三个方面：

1. 可以对它做磁盘空间的优化，丢弃掉一些东西。
2. 可以通过 SPV 来保证，即使交易量非常大了，也可以用很简单的硬件来验证，来确保交易的有效性。
3. 怎么去管理 utxo，也就是拆分 utxo 和合并 utxo。

前不久还有一个优化是说把大量小的 utxo 合并起来，可以不收矿工费，这都是优化的一个体现。关于 utxo 结构可以多说两句，因为这个结构太精巧了。平常别人说区块链有独创性，实际上 utxo 结构才是真正精妙的设计，我们可以说对 utxo 的管理，才是比特币技术的非常令人惊叹的部分。很多后来的公链抛弃了 utxo 这个结构，具体怎么样我们也不评价，我们只能说，比特币的原始设计是非常优雅的。

前面从内到外讲了四个层次之后，白皮书的最后，也就是最外的这一环，说到了用户体验，具体涉及两个方面，一个是隐私，一个是信任。

隐私这块，通过刚才 aaron 讲的每次换地址，公私钥转换，等等，通过一些机制来确保隐私是友好的。对普通人来说，有很好的私密性，不用太担心自己付款被别人知道。当然想知道的时候，你也可以向别人证明自己交过这笔钱。

而信任这块，就回到了白皮书一开始的摘要开头就说明的，设计这个系统，就是为了能够去掉信任第三方，可以降低所有交易的成本，这对用户体验是非常好的。

我们每个人，作为个体，在面对非常大的信任实体的时候，是非常无力的，我们没有那么多的时间和资源去跟他们对抗。中本聪设计出来这样一个系统，使得我们作为一个普通的个体，有机会跟所有的庞然大物，平等地，无许可地，无法篡改地交易，这是一个非常重要的事情。某种意义上，这使得比特币系统从一个孤立的系统，成为一个建设更美好的人类社会的重要工具。

在白皮书里，隐私和信任放在最后一部分讲，它是系统最外部的第五环，是关于用户体验的。

好，梳理完白皮书的结构，现在我们放到一块，整体上看一下。

白皮书就是分成这五个层次，从内向外，展示了整个系统的全貌。它深入浅出地在很短的篇幅内塞入了大量的信息，而且还说得异常清楚。这里，我们整体上梳理一下。

首先它谈到了比特币系统的目的。从交易根本出发，是使用链状的签名来实现的。

然后，白皮书描述了怎么实现这个东西，就是利用了时间的不可逆性，把交易源源不断的凝结到了区块里，这个过程由 POW 来保证。

第三环，怎么样保证这个系统能持续增长，对应的方案是这样一个 P2P 的网络，对网络里边的积极的，诚实的节点，进行了有效的激励，能够让他们获得更多的收益，并为了获取更高的收益愿意去改进系统，这是一个成功的长期有效的激励。

后面更外的两层，白皮书讲到了，怎么去优化系统，保证它即使在超大的规模下，甚至是亿万人使用的情况下，比特币系统仍然能够安全有效的工作；以及对用户的影响，也就是用户体验。

好，这是我对白皮书的梳理，希望对各位开发者能有所启发。

其他协议和工具

好，现在我们开始白皮书之后的内容。

协议协议这块，我列举了两类协议，第一类，是我曾在去年的 BSV 的线上研讨会里讲过的一篇应用层协议，那里对所有的应用层协议做了一个梳理。大家如果想知道更多的细节，可以去翻出去年的视频看，如果觉得视频一个小时太耽误时间，可以看我总结的一张脑图，大概 10 秒钟就可以看完，里边把所有应用层协议都列了。应用层协议非常重要，但因为时间有限，在这里我就不展开了。大家可以看到这里列了 B、C、D、BCAT 还有一些其他的协议。都是关于数据的存储和索引的。

另外一类协议就是 metanet 相关的协议，这也非常重要。如果希望在比特币上做开发，metanet 是必须必须深入研究和考察的内容。其实坦率讲，我自己一开始也没有太重视这个东西，但是后来我发现它非常有用，它是一种粘合剂。你在 bitcoin 上设计的系统，写的合约也好，做的支付也好，当你发现它不能充分的表达你的意图的时候，就需要 metanet 来帮助你，帮助你修补这个系统的一些缺失结构，把它们填满，成为一个更好的产品。

举个例子吧，我们设计的 token，狙击大作战的 OVTS，在现在还没有浏览器的情况下，我们怎么知道某一笔转账里这个余额是谁的呢？这一笔是谁的，是谁转给谁的，其实是看不出来的，因为典型的比特币交易有一个进来地址，出去的地址，你一看就知道这个是自己的，对吧，收到多少钱，一看就知道是自己的。但如果这些信息全部在合约里，需要你打开比特币脚本浏览器，自己把合约粘进去，然后找到数据段，然后往前数若干个偏移，然后再去把相关的信息提取出来，这个是非常痛苦的，一般人也是不可能去做这个。

但用 metanet 就很容易解决这个问题，你每次一笔交易发生的时候，你就输出一个 metanet 的节点，就完事了。

metanet 的节点里边你还可以存其他各种信息。就像你去买咖啡时人家给你的小条一样，你可以存上你任何想要的信息，他们都是一一对应的，而且 metanet 还会自动帮你维护版本。多么完美。这只是一个很小的例子。包括刚才 aaron 讲的视频流，不断付费，张三给李四打工，你可以想象一下，本身这个系统是无法自说明的，大家在这里那里签名提交，其实是个黑盒，其实从外面根本看不出来是发生了什么。但是如果你有个 metanet 节点，就可以更新它的状态，把这些状态同步更新到 metanet 的子节点里，对所有的人都是立刻链上可见的信息，这是非常友好的。

所以，可能 metanet 的应用空间，远远比我原先预想的要广阔的多，之后我可能会再花更多的篇幅去深入讲这个问题，为了不耽误时间，我继续往后讲。

这是两个入门的库，去年我也有讲，我推荐刚刚开始学习比特币的同学，从这两个库入手，可以做一些基本的操作，比如说创建私钥，然后给某个地址发交易。为什么用这两个库？因为他们有代码，如果不懂的话，你可以往里跟，然后一笔交易发出去有没有成功，到底是谁失败了？它里边的加密算法究竟是怎么做的，你都可以一步一步看出来，这样的话你一边做，一边就把比特币的系统从内到外的都了解了。

而且他们有一个特点是非常有弹性，如果你不想了解的时候，你用他给你提供了很恰当的默认值，你不需要做什么事，就可以用最小的代价完成你要的功能。

所以我推荐大部分没有接触过比特币的同学，可以从这两个库入手。

当你更深入的时候，想希望了解比特币上合约的开发，推荐你了解一下 scrypt，看看他能做些什么。因为这次训练营我们有一天是 scrypt 的专场，这里我就不展开了，留给 scrypt 的同学，介绍他们的产品应该怎样使用。

服务这块我列了三个，一个是旺仔的 MetaSV。刚才 aaron 也有讲，MetaSV 提供的一般的功能我就不细说了，就是查地址，查区块，查交易，通过 API 查各种你想查的区块链上的信息。我这里说一下 MetaSV 新发的一个功能叫 xpub 的监控。如果你有一个 HD 的钱包，可以把 HD 的 xpub 拿出来，利用 MetaSV 查看跟它关联的路径下的所有地址的余额。为什么 xpub 监控以及它对应的云钱包这么重要，之前据我所知好像没有人把它真正做好过，这个功能因为它非常难，他的难度比我们想的更难，需要你监控很多地址，而且这些地址可能是杂乱无章的，可能是跳跃性的，这个系统做到90分是没问题的，但是要想真正做好这个系统，要做到 95 分甚至 98 分，是要消耗巨量的资源来检查并做大量的优化。

具体的我不再展开，如果再展开今天讲不完了。大家读一下旺仔在知乎上的文章，就对 xpub 监控更有了解，功能推荐大家试一下。还有 whatsonchain 还没讲，whatsonchain 为什么我们用它？因为有时候旺仔在更新系统用不了，就用 whatsonchain 来替代一下。其实我还用了另外一个服务叫 blockchair。 blockchair 跟 whatsonchain 的不同在于，whatsonchain 当前的这笔交易的输出，你是不知道他有没有被花的，他被谁花了你也不知道，在他网页上看不出来啥东西，而 blockchair 上你可以前后追索，还是非常方便的，所以我推荐大家什么都去了解一下，你会发现有些地方你被卡住了，然后在另一个工具里其实很简单，可能就点点鼠标就完成了。

最后一个API，是我们蒋杰同学实现的 Sensible API。它是专门针对于 Sensible 上面的这个 FT 也好， NFT 也好，还有其他日后我们做的所有的扩展，都可以用这个 API 来快速的进行查询。 如果应用支持Sensible 的话，可以直接调这个API 为你的服务提供支持，不用再重新自己去区块里交易里去分析，能省很多事。

接下来是更大一点的框架，我列了三个框架，是我在开发当中觉得比较好的三样东西。

runonbitcoin 是一个在跑在比特币上的二层的 JavaScript 虚拟机，实际上方便了很多不太想去接触一层脚本开发的同学，因为总有这样的需求。我们不是说所有事情都需要在矿工共识矿工这一层共识来完成，一定有那么一些有意思的东西是通过典型的 JavaScript 脚本，甚至是，我之前说的 Lua 的 OperateBSV 那样在二层来实现的，甚至我自己还想搞一个 Python 的，因为这是实际开发者会面对的需求，你想如果你有一个 Python 的虚拟机跑在比特币上，你现有的 Python 代码不需要做太大的改动，就能运行在比特币上，这是一件很酷的事情，对吧？

然后第二个是 MetaID。MetaID 在周三的时候会有一整天的时间讲，这里我也不展开了。然后 Sensible Contract 我也不展开了，因为周四的时候大家会深入了解 Sensible Contract 也就是感应合约的相关信息。

他们这三个的共同点，就是他们不是为某一个特殊的应用场景设计的，他们是为一个更通用的目标，也就是帮助大家做各种不同类型的 APP 来服务的，是框架性的，相对通用的，三个我认为值得大家了解的东西。

接下来是理论这块，如果你从开发上升一层，希望了解更深入的比特币内在机制，也就是这么做背后的原因。咱们刚刚说白皮书里不是有5层，他是这样设计没错，但是他为什么要这么设计呢？那么如果你想弄清楚的话，你可以看一下 Craig 的 blog 和 Youtube 上搜 Theory of bitcoin，就可以看到比特币背后的理论性的知识。

好，左边的5列就是常规的介绍，已经说完了。在右边我挑了三个技术，同大家分享一下，对一个单独的技术点，我提取了哪些信息，希望这些信息能够帮助到你们。先来讲 nChain 的技术。

nChain Tech

其实 nChain 的技术刚刚 aaron 已经讲了很多了，把我想基本上讲的差不多了。那就以我的方式复述一下。第一个 MAPI 我认为它最重要的两点，一个就是可以去矿工那里查费用，你可以去矿工那里查实时的真正的现在网络上能够被接受的费用，你甚至可以一直查，有时矿工会高一些，有时候矿工会低一些，甚至有时候矿工明明说自己只接受 0.5 的，但它实际上接受 0.2 甚至更低。有时他说自己能接受 0.2 的，但实际上只能接受0.5的或者更高，这都是有可能发生的。这是它的第一个功能，去查网络上的真实费率。

第二个功能是交易提交，交易提交功能分为两种，一个是单个交易提交，一个是批量交易提交。我个人觉得，从矿工这里，如果你批量交易提交的话会更管用一些，因为大家都可以在上面做优化。但是我们其实没没有太用好这个功能，我们自己也需要研究，怎么样去把它给用的更好，因为我们经常有时候还发现一些奇怪的情况，这就不细说了，这里面有些坑，感兴趣的同学可以私下找我聊。

接下来是 SPV。SPV 是对一笔交易的快速验证，你不需要下载所有区块链上的信息，就能快速对它验证，也是对你想要花的那笔钱的快速验证。

它分为两个方面，一个是人家给你付了人家付的钱，你付钱的那笔交易你能验证，第二个是人家想付的那笔钱，确切的说，那一笔 utxo 是否来自于一个有效的交易，这笔交易可以快速在区块链上验证。这个场景对应的是刚才说到 bip270 里，人家来咖啡馆买一杯咖啡，你拿到了一笔人家签名的交易，凭什么就是相信对方给的是有效的 utxo，就会去拿着它的 utxo 找到它的前序交易，用 SPV 验证一下，看看这个交易是不是有效的，如果它的前序交易是有效的，我们就认为它交易本身是有效的，所以 SPV 还可以用在这个地方，是一体两面的，一个是交易前的，一个是交易后的。

SPV 很好，大家都知道很好，它节省大量资源，但是它也有不好的地方，这里我提一下。SPV 不好的地方在于它需要区块的支持，需要区块支持的意思就是只有入块了才有默克尔根，你才能去做 SPV 验证。比如说刚才那个场景，你需要检查一个 utxo 是否有效，那么找到它来源的交易还没入块，就只能继续往前追索，假设这个人就是来要搞破坏，他搞无穷多个子孙交易，然后对你来说其实是非常大的困扰。这是 SPV 目前的一个限制，它只能对已经入块产生了默克尔根的东西来验证它的有效性。

好，这是 SPV 我提到的它的两个特点和一个不足，当然不足可能也是一个特性，需要区块支持。

那么第三个是 nakasendo 的门限签名，相关的技术可以了解一下，如果不了解，你可能不会知道他可能会用在哪些地方。你了解他之后，就会发现好像自己需要这么个东西，就是这样一个神奇的东西。它跟metanet一样，你不了解你会觉得它就是个偏门技术，了解了就会发现它的通用性比你想的更大，可能用在很多地方，这里就不展开说了。

这是去年10月份的时候，我分享时的一页 PPT 上我写了 SPV Channels，也就是所谓 SPV 通道，是依托于矿工网络的高效 P2P 通信，这个信息是不准确的。我讲完以后，那个礼拜，老刘找到我说，不对，我看了SPV Channels 不是基于矿工网络的，它是一个中心化的服务器。

这里非常抱歉，所以在这里我给大家专门注明一下，我当时提供了一个错误的信息，非常抱歉。我给大家跟老刘鞠一个躬，非常感谢老刘指出问题。

真实的 SPV Channels 是这样的，你可以看到，下面的几个特性仍然保留，但是最重要的，我当时认为是非常重要的，“通过矿工网络来传播” 这个特性，其实是没有的，它是一个非常典型的，中心化的消息业务服务。可以这么说，它就是一个像QQ聊天服务器一样的东西。本质上，我们说它就是一个中心化的东西。这是一个修正。

但是，此处有反转。

昨天晚上跟哲明大哥交流了一下，哲明大哥告诉我，TouchStone，这个是打点钱包的一个开源项目。

这个项目里提供了我想要的东西，真正依托于矿工网络的P2P的点对点的加密通信，这个事情是可以做成非常大的一件事情，可以被用于很多方面。

因为我也是刚了解到这一点，只是听说，还没动手试试，所以我也不敢说太多，以免下次又要鞠躬。但是我推荐大家了解一下。

Xoken Tech

好。说完 nChain 的这一部分，我来讲一下 xoken。xoken 是我偶然间了解到的，为什么我会对他产生兴趣，因为我们都知道 nChain 有一个非常厉害的项目叫 TeraNode，但因为释放出来的信息很少，我们其实并不知道 TeraNode 的实现细节，但是我们可以通过跟 TeraNode 竞争的另外一个，也就是非官方的超大区块处理项目，来侧面的了解他们做了些什么。

据我所知，这两个东西，提供的最核心的价值，就是大规模的分布式的并行的交易处理，也就是说把对交易的处理给彻底的打散了，又不像我们比特币的原始的处理方式是在一个系统内部处理，而是把它分散成为一个更现代化的系统，不在一个实例里，不好意思，我终于想到那个词了，不在一个 instance 里面处理，而是分散到多个服务，多个物理服务，多个逻辑服务上去做真正的现代意义上的比特币服务了，这是我认为他们带来的最大意义。

Xoken 的核心技术是 TMT。Transpose Merkle Tree。它是啥意思呢？它是把默克尔树的中间的缓存的节点，默克尔树中间不是有很多层，从底下交易往上一层一层验证，最后到默克尔根，他把中间的这些缓存节点通过转置，使得你从叶节点到根节点的遍历直接就包含了相关的默克尔证明。所有的原始交易，和最后的默克尔根，仍然保持在他们原来的位置上不变，但是中间已经预处理了一遍了。

那么通过对默克尔树的中间节点做预处理，并且存到一个 Graph DB 里边去，它有什么好处呢？它能降低你处理 T 级区块的内存占用，按照他们的广告词，据说树莓派也能处理 T 级区块了，当然它可能处理得很慢，但是它能处理，因为它内存的需求降下来了，可以变成一个流式的处理。

这是它的一个组件，是刚刚讲的 NEXA。可以看到我列了几个它的特性，比如说它的 Grape DB 是天生适合用来存 TMT 的。然后他为什么用了 Haskell，因为这个东西的惰性求值，使得它对流式处理非常友好。

接下来是 VEGA，这是它的一个比较核心的内部技术，刚才说的 NEXA 是它的外部技术，而 VEGA 是它的内部技术，它做了完全的分布式的交易处理。下面的英文就不细说了，但是从上面我提取的关键词，可以知道它是针对比特币在大规模的交易处理下的一些优化。其中他提到几个点，当发生重组的时候，就是 re-org 的时候，它能够瞬间切换。然后他有一个分片技术又有广告嫌疑了，sharding done right，号称是实现了正确的分片。在比特币系统上，针对比特币的结构来做的分片，还有刚说的 TMT，都是值得一看的技术。大家感兴趣的话，可以自己去他的官网上看，它提供的资料有限，但是它是开源的，但是代码是 Haskell 的。

好，那么回到 Xoken，为什么我关心这个事情？

因为它是我所见到的第一个，就是真正的针对大规模交易处理的解决方案。它就是典型的从 “第一性原理” 出发，我就去想怎么处理交易本身，怎样才能有效处理超大规模的交易，别的不管。我管你是用什么实现的，你是用什么默克尔，或者是什么其他数据结构，我不管，怎么样能大量地快速处理比特币交易，才是我唯一关心的。这是从第一性出发来解决问题的，这是一个很好的案例。

你看，他就呼应了我们之前说的白皮书。交易，才是比特币的核心目的，不要被其他的干扰了。它的物理存储也好，它是拿什么存的，拓扑结构也好，它是怎么实现的，用了什么数据结构，用了哪个语言，这都不重要，这些全都不重要。

Sensible Tech

好，最后我来讲一下感应合约。因为周四我们会讲感应合约内部的东西，这里我只是简单讲一下 Sensible 的特点，即使你对它的内部实现不感兴趣，你可能对它表现出来的一些外部特性会感兴趣，方便你了解一下。

总得说来，感应合约有4个小特点，第一个特点是，完整的交易合约的逻辑封装在里面。它外部依赖的签名器是没有状态的，它的状态都是靠 contract 来传递的。没有，也不需要第三方的认证，实际上是有别于目前已有的其他这些方案的。

第二个特点，full featured contract data payload。就是说他通过 contract 可以来携带需要的信息，不需要去你再去其他地方拼凑信息了，这些信息可以验证，不需要用 op-return 来做这件事。当然你可以用 op-return 来辅助它来做一些事情，但是这不是必须的。其实技术上讲不是这样，我这里说的 op-return 是指一个独立的 op-return 输出。

第三点，它是完全去中心化的，是由矿工来验证，不需要一个鉴权者，也不需要一个验证者。

第四点，它是使用比特币的特性来实现的，我们叫它 “bitcoinic”，就像 python 的方式我们叫 pythonic 那样，它是跟 metanet 能够非常良好的匹配的。而且它是跟比特币一样支持 SPV 的。应该这么说，它没有比比特币做得更多，也没有比特币做得更少，它只是跟比特币保持一样。

好，这是它的4个小特点，更多的特点，如果你感兴趣的话，周四可以听我们讲，或者是看官网上的介绍都可以。

获得上面这四个好处，要付出两点代价。第一个是，需要一个外部的极小化的签名器，来对一些重要的字段做签名，这是一个外部服务。

虽然这个服务非常小，可以做到任何地方，包括钱包，或者是其他任何地方，但是确实需要这样一个东西。

以前我们曾说，是不是能够通过改 PreImage 来去掉这个东西，因为如果 PreImage 把这个字段加上了，就不需要签名器再去生成了。

但是修改 PreImage，这个是牵涉面非常广，我们也并不是说打算靠嘴推动，天天把精力都花在怎么游说别人这件事上，我们更希望它这个系统本身，不管你升不升级，它都能很好的工作。之前说要修改 PreImage，造成了很大的误解。因为我被问到的最多的问题，就是，听说你们这个玩意要改协议，大动静，要把别人房子拆了，回答了几次了之后，我也不知道该怎么回应才是有效。那么今天我可以明确地说一下，实际上我们不会去提改 PreImage 这个方案，简单说我们就暂时不考虑这个选项。

这是它第一个代价，需要一个外部的小的签名器。

第二个代价就是，由于它的逻辑是在合约中实现的，导致它比那些需要在外部去维护一个 utxo 集，或者说维护其他的状态和做一些其他事情，比如说鉴权，校验等等外部功能，它的脚本尺寸要更大一些，为什么？这个很好理解，因为我们的关键业务逻辑是在脚本里做的，而别人是在链外做的，那么代码尺寸自然会有一些区别。

那么具体大到什么程度呢？其实也不是很大，因为我们一开始没意识到尺寸问题，就写得有点奔放，但是后来经过优化，我们的一个 FT 的输出，现在是 8k。然后我们狙击大作战前两天上了新的合约版，在中午12点的时候会给大家结算，这些结算单笔交易会产生 100 个输出，每个输出 8k 然后加起来就是 800k，听起来其实也还好，毕竟一次性处理一百个人 0.8 兆。

我们还会继续优化，我们也知道 scrypt 实际上是有很多空间是可以优化的。我们一起努力，把尺寸变得更小。小到什么程度，小到你把逻辑放在合约里，你也不会觉得有什么心理负担，要小到这个程度才行。

好，这是感应合约的两个不足。

这些 BCP 是我们基于感应合约开发的一些，我们认为可以直接对标以太坊上的一些协议。

这样做的话，大家都能省力一些。每个相关的参与方，都可以直接用这个来实现自己要的功能，同样的接口，同样的操作，能极大地降低成本。这个事情我们还在推进之中，之后还会加入更多的 BCP，但是我们加这个东西要谨慎，要维护一个良好的，正交的，解耦合的状态，不能说是到最后成了一团乱麻，然后 A 引用 B，B 引用 C，到最后自己也分不清。最好是每一个都是彼此独立的，正交的，每一个都能独自发挥有效的作用。

从官方的宣传材料里得到的信息，也就是右边列出来的部分，这种对智能合约的叙事是我认为说的比较准确的，“automation of agreements with easily definable transaction step”。是什么意思呢？就是说，合约的本质，是一种关于契约或者说约定的自动化，是怎么自动化的呢？通过比较容易被定义的多个交易步骤，连起来说就是 “通过 (容易被定义的) 多个交易步骤来实现的契约自动化”。BCP 是符合这个定义的。我们希望把一些双方达成的协议，形成一个固定格式的交易模板。你看到的左边的 BCP 123 等就是模板。之后还会有更多的模板，就好像去豆丁网上搜 “某某某合同模板” 一样的。我们会形成越来越多这样的模板，这样的话以后就不用自己，从头开始写一个合同，直接拿模板，把合同金额和银行改一下就完事了。当然了可能要审查一下。

好，这是我们认为的 BCP 的目标是什么，也就是给大家提供尽可能方便的可以直接用的合同模板。

好，这差不多是我今天的全部内容。还有一些没有列出来的技术，其实也是非常有价值的，我们希望这个是一个系列，以后会有一个迭代。

Take Away

2021-04-bsv-dev-overview-2

最后还有一页 Take Away 这一页不用细看，是我刚刚讲的所有的内容的一个回顾，一个快速查阅的脑图，可以当作弊条看一眼。

好，今天的分享就到这里，谢谢大家。

(主持人) 好，不知道大家有多少人看过顾露的 1.0 版本的演讲，在我们 B 站上，稍后我们同事会发到群里面去，然后看到顾露真的是说是程序员 2.0 就是 2.0，1.0 里的很多内容都没有讲，2.0 这个里面基本上都是全新的内容。我们离午饭还有一点点的时间，如果大家有问题的话请举手。

Sensible 与以太坊的合约对比

刚才您提到 Sensible 的合约有一些代价。对，Sensible 合约跟以太坊上的合约的差异还有优势在哪里？

这是一个大问题。简单说它 (Sensible Contract) 试图使得比特币的脚本拥有更多的能力，不是瞄着以太坊去的。之前跟别人解释过，从本质上讲，以太坊的计算模型跟比特币是有差异的。以太坊是一个全球中心的计算机，所有的机器都是计算机的一部分，而比特币的原始设计，还是第一性原则，它是处理交易的，它根本不是用来提供什么计算的，计算只是它提供的一个附加的组件。所以比特币的设计是分散的，utxo 是分散的，每一个 utxo 理论上跟其他 utxo 不应该有太多的关联，这跟以太网是完全两个思路。(打比方的话) 一个是单核单进程，一个是微服务多进程。

对，我其实以前也做过那种并发处理，其实对于我们这些对理论不是那么了解的人，可能他更多想知道的就是在哪一些应用可以把它比特币化，比如说以太坊上一些应用可以把它比特币化，或者说哪些又不能比特币化，这个是我们很想知道的一个。

对，这个问题非常好。这个问题我谈一下我自己的理解，可能是非常初级的。

哪些应用能被比特币化？

为什么我们会有这个问题？是因为我们比任何人都希望以太坊上的应用在比特币上，不仅能做，而且能做得更好。

但是我想说的是，在以太坊上大量的已有的应用，他们经历过大量的迭代。这些迭代不仅是有针对用户体验的，针对功能的，更多的有一部分迭代，目标是使它更匹配以太坊计算模型。

你现在只有单核，你就尽量想好怎么样用单核的特性，用好单核，这就会导致你的程序更难被多线程化，这很容易理解，对吧。

这会导致一个趋势——在以太坊上越成熟越完备，越适应以太坊的东西，反而越难以被移植到基于 utxo 的系统。不是说它不可能，当然可能了，也可以做到，但是会发现，对于一个非常适配以太坊模型的应用，把它迁移到 utxo 上，会花费比你针对 utxo 去设计一个 utxo 友好的这样一个系统，要花费更多的心力。当以后 scrypt 足够成熟 Sensible 也足够成熟的时候，也许我们会提供一个东西让你相对无痛的转过来，但是这种无痛的转换，背后是有代价的。

比如说那天 Angus 就问了一个这个问题，swap 从以太坊上转过来会有问题。人家以太网上你只管给他交易发，然后它自动就线性处理了。到了比特币上了以后，有一个 utxo 专门来维护所有的状态，岂不是大家都要指着这个 utxo，你用完了给我，我用完给他，这个东西谁能保证有那么高的实时性，如果成千上万人参加的话，大家一顿猛提，那整个系统不就各种卡死，这就是一个很重要的，这是一个非常好的问题。

然后我当时给他回复，还是之前老刘的观点，就是说，比特币它的目的，不是在于比你专门设计一个系统要表现的更好，它不是这样，他的目标是给你提供更多的选择。

比如说你可以由开发这个功能的主体，由他去管理 utxo 我就是做 swap 的人，你们的 swap 需求都提给我，我来负责，哪怕再多的人，10万人，我也会把它 stream 到一个 tx 序列里面去，我来把这个事情处理的很好，这是一种方案了。

但是这种方案你会说，你这个中心化，都是你来搞，你不搞怎么办？人家以太坊上都是去中心化的，你会有这样的疑问。

那么这种情况怎么办呢？我们可以退一步，不要由我作为一个主体，我来操心所有的细节。我挂了所有人都挂了，而是交给像旺仔这样的通用数据，大家都去他那儿获取有效的 utxo 获取到了你就 swap 成功，获取不到你就 swap 不成功，获取到过时了的，那是你自己获取的问题，自己想办法解决就好。

这样的话，你就可以通过多个数据访问商来实现这个功能，实现了一点点的去中心化，但是牺牲了一点点实时性，因为所有的交易都来你这儿的话，你可以对它做很好的优化，因为大家都从你这儿过，你有这个队列你可以对它做很多优化，但是使用一个通用的服务，你就只能只依赖通用的服务了。当然了，后来我又补充了一句，我说你依赖通用服务也没关系，因为你依赖这样的通用服务其实是还好的，因为旺仔会做大量的优化，确保它的DB和它的区块链状态是高度同步的。你不用太担心 utxo不够及时，因为他 (旺仔) 的优化搞不好比你自己优化的好，因为人家就是就是干这个的。他能保证他的 DB 跟区块链能够尽可能小的延迟。

所以你其实只牺牲了一点点延迟，换来了一点点去中心化，你也可以牺牲更多的延时，然后换来更多的去中心化，在比特币上你永远有选择。这是老刘给我的最大的启发，就是在比特币上你永远有这样的选择。

在去中心化和高效处理之间，按照你自己的需求，定制出来一个平衡的方案。

这就是我想说的，就是你可以选择从以太坊上迁移，但是这取决于你愿意怎么去做 (trade-off)。

---

• 顾露 (Gu Lu) 于免成居
• 时间: 2021-04-29
• 编号: Bt-008-2104

---

（全文完）