比特币二层网络可行性探讨（上）：Ordinals vs Taro

Bitcoin 作为最早、最安全的区块链，所使用的 UTxO 账户模型导致它很难支持像 Ethereum 的智能合约功能，只能支持一些有限的基于脚本语言的功能。所以自 Bitcoin 诞生的 15 年间，它没有被用来实现像 Ethereum 上的各种让人眼花缭乱的 DeFi 协议、NFT，通常被用于点对点转账和价值存储。

2022 年 12 月 14 日被正式启动的 Ordinals 协议改变了这一切，它将使用者所需要存放到链上的元数据放入交易输入中，并基于序数理论[^1]实现了一套程序来追踪并记录这些“铭文 (Inscriptions)”。这样的“铭刻”所实现的是记录了静态的元数据，而不是如 Ethereum 智能合约一样的可动态执行的链上程序。这也使得“铭文”天然地成为了 Bitcoin 上的 NFT。而基于序数理论，人们也能够构建交易来实现这些铭文之间的转移、交易。

此后，在 2023 年 3 月 6 日，基于 Ordinals 的 BRC-20 协议被提出，它被用于实现 Bitcoin 上的同质化代币，对应了 Ethereum 上的 ERC-20 协议。而这样基于 Ordinals 的协议很简单，以 Json 的格式将代币的铸造、转移的过程写到铭文上，最为形象的比喻就是一张张写上转账记录的纸，而记账的事情交给第三方机构去做。

这样的 BRC-20 协议颇有暴力美学的美感，也是一种在各种因素下的妥协。在此前 Bitcoin 也曾出现过像彩色币的同质化代币，这不能证伪 BRC-20 是失败的应用，但似乎也能说明它或许不是一种长久的协议。至此，进入本文的主题，基于闪电网络的主根资产（Taproot Assets）。

闪电网络是建立在 Bitcoin 上的 Layer 2 解决方案，其目的是在 Bitcoin 的支付场景下帮助用户节省成本、提高效率。而闪电网络所依赖的思想也很简单，即构建资金池，这样的资金池也被称为交易双方的微支付通道。更具体一点，涉及到两个核心概念：

· Revocable Sequence Maturity Contract（RSMC）：序列到期可撤销合影

· Hashed Timelock Contract（HTLC）：哈希时间锁定合约

RSMC 假定了交易双方之间存在一个微支付通道，双方先存放一部分资金到这个通道中，初始情况下双方的分配方案就是预先存放的金额。在每一次发生交易时，双方都需要对交易后产生的分配结果进行确认，同时把原有的分配方案作废。这个过程涉及到的概念较多，而且比较巧妙，具体可参阅 [A Dive into Lightning Network (Part One)][^14]，而它在闪电网络中的作用是构建双方之间的支付通道。

HTLC 是一种带事件的哈希锁定，它要求某一方在一定时间内提交某个哈希值 $h=H(m)$ 的原像 $m$ 以取得使用某一笔 UTxO 使用权。它在闪电网络中被用于构建支付路由，具体的实现过程见 [Lightning network in depth, part 2: HTLC and payment routing][^15]。

闪电网络整合了这两种机制，使得交易可以在闪电网络中的任意两个节点间能够在链下完成。

Taproot 是三个比特币改进提案（Bitcoin Improvement Proposal, BIP）BIP-0340 （Schnorr 签名）、BIP-0341 （Taproot）和 BIP-0342 （TapScript）的汇编，它也是 Taro 资产能够实现的基础。在这里，对 Taro 资产的实现中所涉及到的 MAST 进行说明：

MAST

BIP-0341 中引入了默克尔抽象语法树（Merklized Abstract Syntax Tree, MAST）[^7][^8][^9]，其目的是隐藏 UTxO 的支出条件，并且减少信息的大小。这是 Taproot 升级的一部分，Taproot 升级将原有的 P2SH（Pay-to-Script-Hash） 和 P2PKH（Pay-to-Public-Key-Hash）结合在一起，使得一笔数输出可以直接通过私钥使用，也可以提供花费输出的脚本和默克尔证明来使用。

MAST 结合了抽象语义树和默克尔树，默克尔树作为一种在区块链中常见的数据结构，在这里不再进行赘述。而抽象语法树（AST）是一种把程序分割为独立的小块以描述程序的方法，这样会让程序变得容易分析和优化，具体可查阅[Abstract syntax tree]。MAST 结合了 AST 的将程序划分为多个小块的思想，再把程序每个小块进行哈希，利用默克尔哈希树的思想把这些哈希结果构建为默克尔树。

考虑这样一个脚本[^9]:Alice 希望可以随时花费她的比特币，但是如果她连续三个月没有花费，那么她的兄弟姐妹 Bob 和 Charlie 就可以花费这笔 UTxO，其脚本实现如下

OP_IF

<Alice's pubkey> OP_CheckSig

OP_ELSE

"3 months" OP_CSV OP_DROP

2 <Bob's pubkey> <Charlie's pubkey> 2 OP_CHECKMULTISIG

OP_ENDIF

在 P2SH 下，这样的脚本是需要在花费时完全暴露在交易中的，Alice 在花费这笔 UTxO 的同时需要提供该脚本，以及包含在其中的 Bob 和 Charlie 的公钥。

而在有了 MAST 后，对该脚本的两个条件进行划分，得到一个简单的 MAST

此时，Alice 在花费的时候只需要选择提供她的公钥验证脚本和 Hash2 作为默克尔证明即可，而不需要暴露 Hash 2 下的具体脚本，这部分信息不会上链。而这样也进一步降低了类似交易的开销，这是很自然的，提供完整的脚本总是比提供脚本的哈希值的数据量少。而这样的结构也给智能合约的实现提供了可能，这样的方式正如 EVM 中的字节码一样，在运行前可以根据输入数据的前 4 个字节来选取将要调用的函数。不同地方在于，这样的脚本调用需要用户提供具体的脚本，以及默克尔证明来证明脚本是合法的。

主根资产（Taproot Assets，后续简称为 Taro）[^2][^3][^5]是一种还在提议阶段的协议，它可以实现在 Bitcoin 上发行资产，这样的资产可以通过链上的交易通过比特币网络转移（对 NFT 的交易、转移已经被 Ordinals 实现）。特别地，同质化的 Taro 资产可以在存入闪电通道后在闪电网络上以更低的手续费、更为隐私地转移，类似的还有尝试在闪电网络上运行智能合约的 RGB 协议[^4]。

Taro 可以在 Bitcoin 主网或二层的闪电网络上流通。先考虑在 Bitcoin 网络的情况，Taro 是附加在交易上的哈希化元数据形式，使用哈希化的目的在于降低交易的占用空间以节省手续费。而这样的哈希化元数据形式则是 Taro 的核心，这样的一条哈希值甚至可以代表实际上的几百万次交易，它的原理会在后续进行介绍。

其次是 Taro 在闪电网络上的情况，使用闪电网络可以让同质化的 Taro 资产实现更快的交易速度，这类似于使用闪电网络可以更快、成本更低地转移比特币。在 Taro 的提议中，闪电网络自身不需要改变，为了实现一笔某种 Taro 资产的交易，只需要整条支付路径的第一条通道和最后一条通道可以识别 Taro 资产即可，而中途的路由通道则是正常的闪电网络转账方法，它们转账等价的比特币，这也导致 Taro 资产通常会在网络的边缘和其他资产交换。

Taro 协议

既然了解了 Taro 所能带来的好处，那么接下来需要介绍的是，它是什么？以及如何实现？正如需要了解 BRC-20 就是一堆写好转账记录需要第三方机构来记账的纸片，ERC-20 是智能合约所记录和维护的一串余额信息一样。Taro 又是如何实现资产的发行、转移的？

资产树

资产树是 Taro 中的一种两级默克尔树结构，它被用来代表 Taro 资产。第一级是由 Taro 信息作为叶子节点而构成的默克尔树，而第二级则是通过 MS-SMT 构成的表示每个账户所具有的该资产的树，MS-SMT 的思想较为简单，它在默克尔哈希树基于哈希来构成树形结构的同时，每个节点还存放了左右两个子节点的和来实现（进行哈希运算本身也算一种求和），这样的资产树和 MS-SMT 树被用来构建 Taro 的 UTxO。

资产叶（Aseet Leaft）是资产树中的最底层结构，它表现为资产树示意图中的淡蓝色节点，它以 assetScriptKey （assetScriptKey 可以类比 P2SH 交易中对交易脚本的哈希值）作为键。每个资产叶表示 Taro 资产的一个 UTxO，资产叶中包含的可选项可参见 [Understanding Taproot Assets Protocol]。

MS-SMT

默克尔总和稀疏树（Merkle Sum Sparse Merkle Tree）[^11]是在 [bip-tap-ms-smt] 中定义的数据结构，它是稀疏默克尔树的增强版本，目前是 bips 中一个仍未被接收的提案。由于键（key）是 256 bits 长的，所以这样的 MS-SMT 有 $2^{256}$ 个叶子节点，其中的大部分是空的，所以它是稀疏的默克尔树。

每个叶子包含了一个数量，每个分支向上提交叶子中的总量，这样可以在不知道每个子树的内容的情况下知道分支中包含的总和。而和一般的默克尔树一样，包含任何叶子的被修剪过的树可以提供成员存在证明（这是密码累加器中的一个概念，它是一种“证明”用于证实一个元素在一个集合中）。而 MS-SMT 也支持成员不存在证明（它通过显式地指示不存在的键的叶子为 None 来实现），即证明这样的键在树中为 None 来证实它不存在，这样的结构可以高效地验证树上存储的数值和分布是否存在改变。

下图是一个默克尔总和树以及它发送改变后的结构，而默克尔总和稀疏树则是结合了稀疏树的特点，将空元素节点修建掉，只存放有意义的信息，空节点使用 None 表示。

Taro 资产发行

Taro 资产的发行需要一个标识符，正如 ERC-20 代币的智能合约会拥有一个地址一样，Taro 协议定义了标识符的生成方式：ID = SHA256(genesisPoint||assetTag||assetMeta) ，它将铸造资产所使用的交易输出信息、资产标签（例如资产名称的哈希值）以及资产的元数据（图片、链接或文档）进行哈希，从而得到一个标识符。

Taro 资产的转移脚本可以有类似比特币交易的输入输出，而创建资产的交易不需要包含任何的 Taro 资产的输入，由此可见，Taro 资产沿用了比特币的 UTxO 模型，资产的发行就是发布一笔 Taro 资产的交易，它没有输入，只有输出。

Taro 的输入和输出是基于资产树来实现的，正如前文所述，资产树的第一级代表了该笔 UTxO* （后面会继续沿用这种写法，* 表明这样的结构是在 Taro 资产中而非 Bitcoin 中）中存放的 Taro 资产有哪些，而 Taro 资产 ID 所对应的 MS-SMT 中所存放的是该笔 UTxO* 输出的 Trao 资产的信息。

构建一笔 Taro 资产的发行交易如下图所示，以一笔 Bitcoin 的 UTxO 作为输入，输出一笔正常的 Bitcoin UTxO 以及附加的 Taro 资产 A 的 UTxO*。这样的 UTxO* 在 Bitcoin 上表现为一个默克尔根的形式，而它在链下表现为资产树的形式，资产树中记录了 Taro 资产 A 的 assetId 以及资产 A 对应的 MS-SMT 中的记录。

Taro 资产转移

如果能理解上一小节中资产的创建，那么就可以更快地理解资产的转移过程。资产的转移和 Bitcoin 中的一笔交易是类似的，选择一系列的可用 UTxO 作为输入，然后再输出一系列的 UTxO。在 Taro 资产中则是选择一系列可用的 UTxO* 作为输入，并输出一系列的 UTxO*。

在这笔交易中，A 将自己的 Trao 资产 X 全部转移给 B，并且不进行拆分。在 B 接收到该交易时，需要验证资产是否满足支付条件且没有产生多余的输出来确认收到资产。

所需要验证的条件包括但不限于：

· 为 B 所创建的资产树是否包含满足付款条件的新 UTxO？

· 输入 UTxO 是否已经从已经更新了的 A 的资产树中删除？

· 如果交易中还有其他的输出，那么它们是否包含另外的资产树？

这些信息可以由 MS-SMT 的成员 / 非成员证明以及 Trproot 输出的前像以及证明来进行验证。对资产的合并、拆分不再进行赘述，它们的过程和资产转移的过程类似，但是在输出的 UTxO* 中包含了拆分证明或合并证明。

Universe 是一种为资产的持有人提供有关资产信息以及证明的服务 [^6]，其作用类似于比特币区块浏览器[^13]，但是它会展示与 Taro 资产客户端一起存储在链下的 Taproot 资产的交易数据。Universe 可以由资产的发行人自己运营，也可以由发行人任命某个运营商，可以想象的是由社区运营的 Universe 汇总来资产持有者提交的信息。

上篇到此为止，我们简单地介绍了 Taro 资产实现所基于的技术，以及它本身的实现原理。在下篇中，我们将会介绍 Ordinals 及 Taro 资产发展现状 。

资料引用：

[^1]: [Ordinal Theory Handbook]

[^2]:[What Is Taro in Bitcoin?]

[^3]:[Taproot Assets]

[^4]:[A BRIEF INTRODUCTION TO RGB PROTOCOLS]

[^5]:[Taproot Assets: A New Protocol for Multi-Asset Bitcoin and Lightning]

[^6]:[Taproot Assets Protocol]

[^7]:[Merklized Abstract Syntax Tree]

[^8]:[Merklized Abstract Syntax Tree]

[^9]:[What is a Bitcoin Merklized Abstract Syntax Tree (MAST)?]

[^10]:[Understanding Taproot Assets Protocol]

[^11]:[bip-tap-ms-smt]

[^12]:[Fixing The Privacy Gap In Proof Of Liability Protocols]

[^13]:[Blockstream Explorer]

[^14]:[A Dive into Lightning Network (Part One)](A Dive into Lightning Network (Part One))

[^15]:[Lightning network in depth, part 2: HTLC and payment routing]