Frost on Nostr: #TaprootAssets 这几天在看 taproot assets ...

#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 联系起来了。

资料：

[Taproot assets bip](https://github.com/Roasbeef/bips/blob/bip-tap/bip-tap.mediawiki)

[Taproot assets universe bip](https://github.com/Roasbeef/bips/blob/bip-tap/bip-tap-universe.mediawiki)

[Nayuta 团队写的最通俗的博客文章，里面的图可视化非常好](https://medium.com/nayuta-inc/taro-ed6b93b09a75)