EP-079 《2023年，我的“不明白” 》

非常感谢不明白播客的听众朋友们一起参与制作了这期节目，来信很多，我念的只是其中一部分。谢谢大家一年来的支持。在2024年希望我们都能像哈维尔说的那样，生活在真实中Living in truth.

谢谢大家收听，我们2024年再见。

看完了这本书，非常值得一读，看完后会对万维网当初发明的目、这项新技术流行开来的过程会有一个不一样的印象。以目前网络现状来说，还远没有实现其期望，还有很长的路要走，甚至可能是镜花水月就是条不可能的路。

有几个出乎我印象的点：

万维网发明不是想干电视、报纸这类媒体的工作的，它是想让人更好的**协作**。它其实类似现在的双向链接笔记软件RoamResearch之类的，而不是ePub这样一个静态的内容展示。所以它最初的浏览器是有富媒体编辑功能的。

最开始流行的比我想象中的慢，向别人介绍展示，别人大都嗤之以鼻。两三年过去了也就100台服务器，浏览器全是个人爱好者写的，写完也就没动力了。

94年之后流行的比想象中的快得多，94年网景创立（1年后就上市，创造了当时历史上最大IPO）、微软（95年底盖茨才说要all in互联网，发布了IE）等一些类熟悉的名字粉墨登场。到99年互联网科技泡沫，万维网才发明10年，这么一比，比特币的流行速度其实不是很突出（也许是比特币的利益相关性牵扯太大）。而且99年到09年比特币发明，其实也只有10年，它们俩时间没有差很远。

URI>HTTP>HTML，最重要的是信息的标识，其次是网络传输，再次是描述语言。信息空间是想包含所有信息。域名、证书体系是早就知道的弱点，对于这样分布式、无许可的系统又要怎么解决信任问题还是老大难。作者更偏向哈希+公钥，要找权威机构在证书里填上你是谁、是什么公司的，作者对这套方案其实是不感冒的。W3C提供的协议标准仅是推荐级，并非强制。

最后展望的语义万维网是有点类似今天的元宇宙+LLM的，每个人运行自己的服务器，充当永远在线赛博助手，它能理解万维网上的信息，也有推理智能。

问：没看过这本书影响码农写web代码？

答：不影响。

但是只追求成为一个码农吗？不应该更高级一点吗？

开始看所谓客户端验证是什么范式，于是感觉我可能理解错了如何利用 taproot 交易来减少数据上链的方式：它似乎是用方式一（私钥签名）花掉 taproot UTXO，在链上进行转账，但同时在链下要揭露 tapscript 这棵树等内容作为证据，这些证据不用上链，而是由接收方保管整个证据历史，并且通过一个客户端进行验证每一个证据（跟链上通过方式二脚本路径花掉 taproot UTXO类似地验证方式）。

这样一个 UTXO 语法上是否有效由链上保证，而语义（合约的含义）上是否有效由链下的跟 UTXO 流转过程中产生的一连串证据历史来保证。客户端侧需要验证整个历史

。

那这样每个 UTXO 随着转手次数增长，并且和别的 UTXO 同时花费过，附加在它身上的证据历史不是越来越庞大？它的历史证据跟一条区块链本身类似了。

文档还是太模糊了，打算把环境搭建起来实际跑一下，看它的交易到底是怎么样的。

#TaprootAssets 这几天在看 taproot assets 的资料，想弄懂它到底是怎么运作的。不得不说，这是个相当复杂的协议，转账时双方协商的细节还是没很清楚。网上的资料其实相当缺乏，大都只是泛泛而谈。而官方文档的英语用词偏学术化，各种概念零落，读起来费劲。

Taproot assets 本质上是 taproot 的一种应用方式，也就是一种构造 tapscript 的惯例。所以需要从 taproot 交易是什么开始讲起。传统的比特币交易可以把一个公钥放到交易的 output 里面，要求花费这个 UTXO 时需要使用对应的私钥去签名一段信息，把签名结果放到交易的 input 里来证明自己确实拥有这个公钥，有花掉这个 UTXO 的所有权。Taproot 将这个 output 的公钥变了一下，`Taproot publick key Q = owner public key P + Hash(P | tapscript tree root) * G`，这个公钥 Q 对应的私钥显然就是 `owner private key p + Hash(P | tapscript tree root)`，可以直接用这个私钥按传统方式花掉 UTXO。

但还有另外一种方式花掉 taproot 的 UTXO。计算 Q 时只有两个变量 P 和 tapscript tree root，而如果这个 UTXO 是发给我的，那 P 就是我的公钥，唯一未知的就是 tapscript tree root。如果可以证明自己同时也知道这个 root，就能证明这个 UTXO 的所有者就是自己。这个 root 是一个被叫做 tapscript 的 merkle tree 的 root，而且叶子节点都是一段代码。所以只需揭露某个叶子节点的代码内容、加上对应的 merkle path 这一哈希数组，就能构造出 root，然后再按公式计算出 Q，看是不是同一个 Q 即可。另外一般还要提供一段解锁代码去配合叶子节点的代码，让它们运行之后为真（当然你也可以让叶子节点的代码自己单独运行就为真，这样 input 提供的解锁代码就是空），就跟传统模式的 output script 需要一段 input script 配合去解锁一样。总结一下这种花费方式下，交易的 input script 里面需要包括：P、一段解锁代码、merkle tree 某个叶子处的内容、merkle path。

然后看看 taproot asset 是如何构建 tapscript 这棵树的，它相当复杂，带有 3 重（更复杂时有 4 重）的 merkle tree。最上层一重跟普通的 tapscript tree 一样，只是叶子节点不再是一段代码，而是下面一重 merkle tree（叫做 taproot assets tree） 的 root，而 taproot assets tree 的叶子节点是更下一重 merkle tree（叫做 asset MS-SMT tree）的root。

最底层的 asset MS-SMT tree 用来存储某个资产的余额，一个叶子就相当于一个 UTXO，里面记录这个叶子代表的 amount、所有者的**公钥**等信息。这个 merkle tree 是带总和的稀疏 merkle tree（简称 MS-SMT），所以它往上层做哈希计算 root 时，为空的叶子节点也要哈希，并且需要带上 amount 的加和（可以很方便察觉资产的总发行量变没变）。而它上层的 taproot assets tree 的每个叶子都可以是一个资产，它是用来管理多个资产的，它的 root 叫做 taproot assets commitment。

创建资产时，需要往主网发送一个 taproot 交易（叫做 genesis tx），里面 output 的公钥按上面的公式计算，里面的 tapscrip tree root 就是 3 重 merkle tree 的 root。这个 genesis tx 上链之后，要发送第二个交易上链，揭露创建资产的元信息（叫什么名字、总额、url、文档等等），要不然 genesis tx 外表看起来和最普通的 taproot 交易一模一样，外人不从得知这个交易实际上创建了其他类型的资产。

转账时，双方需要复杂的协调。总的有两个层面，tapscript tree 层面和 tx 层面。对于 tapscript tree，要重新构建，在最底层 asset MS-SMT tree 下把 sender 要花的那个叶子节点整个删除（类似 UTXO 的花费，无论数额多少，都需要整个删除，然后新建另一个**找零** UTXO），然后新建自己的找零叶子节点和 receiver 的叶子节点。叶子节点的任何变更，往上层哈希最终计算出新的 tapscript tree root。然后可以进行 tx 层面的协调，需要保证 receiver 应得的叶子节点的tapscript tree root 用来生成了一个 taproot output，保证 sender 自己找零的叶子节点的 tapscript tree root 用来生成了找零的 taproot output。两个 output，而且代表的其实是不同的 tapscript tree 视角（所以 root 肯定不同），因为这里不是使用一棵 tapscript tree 来保存全局的账户余额（类似 Ethereum 的账户模型方式），而仍然是 UTXO 模式，资产在 MS-SMT tree 下的一个叶子节点和某个 UTXO 是一一对应的。

所以一个 taproot assets 转账交易的 input 里会包含什么？跟普通的 taproot 交易一样，它包括：所有者公钥 P、asset MS-SMT tree 叶子节点指示的所有者公钥的签名（用来证明所有权）、**叶子节点的内容本身**、3 重的 merkle path。

为了保证每个转账往前追溯是都能追溯到 genesis tx，asset MS-SMT tree 的叶子节点记录的信息里面还有个 prev asset witness 字段，它存的是当前 UTXO 的父 UTXO（通过花掉了父 UTXO 而创建了当前 UTXO） 位置、asset id、asset witness（花掉父 UTXO 的凭证）。genesis tx 里这项为空。这个字段就建立了这些 UTXO 的树式关系（并非链式关系），最终可以追溯到 genesis tx 的那个 UTXO，并且所有 witness 是可以验证的。

显然，叶子节点的内容太大了，如果每次转账交易的 input 都要附带这么多数据上链，那比特币的硬盘增长会上升非常迅速。所以就有了 Universe 服务，有几个功能：1. 监视链上交易，一旦发现是 taproot assets 的创建或者转账，就把数据索引好存起来。2. 存储数据，它存的数据包括：asset meta 信息（名字、数量之类的，它不能变更，因为 asset id 的生成里用到了它的哈希值）、genesis tx、转账交易。3. 响应查询，一般的客户端没有能力从链上交易里检索的话，直接向 Univserse 服务查询，并且它可以提供 witness 来证明。genesis tx 的 tapscript 里可以有 canonical_universe 这个字段，规定官方的 Universe 地址。

如果 Universe 服务仅是这样的话，那它**根本没有任何减少上链数据的功能**，只有一种叫 Pocket Universe 的特种 Universe 才提供**上链交易批量聚合**的功能：每转账一次，就需要重新生成 taproot assets tree 发交易上链，如果将多次的 tree 变更批量成一次变更，就只需上链一个交易。它需要信任运营方，还需要锁定 sender 的 taproot assets UTXO，否则 sender 在任何时候都有退路去链上转账，就会出现双花，所以它其实是一种 channel。

Taproot assets 还有很多复杂的设计，比如 asset MS-SMT tree 叶子节点在发花费时可以 merge 和 split（这会让 tapscrit tree 变成 4 重 merkle）、基于闪电网络 HTLC 的转账、一个 genesis tx 创建多个 asset（group assets） 后跨 asset 的 swap 转账（跨 asset MS-SMT tree 叶子节点的删除和创建，这可以实现多资产的原子交换，甚至实现去中心化交易所）、Universe 数据存储的格式（一棵 MS—SMT tree，它的叶子叫做 proof，一个 proof 包含全部用来证明转账确实合法的息，叶子的内容是 append-only 的文本）

上面没提到的细节有：

Q1：关于 3 重的 tapscript tree 每重之间的叶子节点是怎么和下一重的 root 对应的?

首先，`asset id = sha256(genesis tx 花的UTXO outpint | asset tag | asset meta hash | output index | asset type)`。第二重 taproot asset tree 的叶子节点就对应 asset id，并且里面存的是（asset sum，[Asset MS-SMT 树 root、asset sum]。这样某项 asset 对应的发行数量和它的 MS-SMT tree 就能找到。

最上层 tapscript tree 的叶子对应的是 `tagged_hash("TapLeaf", leaf version | taproot assert maker | taprrot asset version | asset tree root)`。这样也和 asset tree root 联系起来了。

资料：