什么是Taproot（BIP 341）？

BIP 341是Schnorr/Taproot/Tapscript提案的第二部分，它扩展了Schnorr的功能，以实现更大的扩展性、效率和支付隐私性。

正如我们在第一篇文章中所解释的那样，Schnorr使比特币多签名交易看起来像是区块链上的标准交易，即付款到公钥哈希（Pay-to-Public-Key-Hash, P2PKH）。

当与Schnorr结合使用时，Taproot（BIP 341）将进一步扩大交易的隐私性，这些交易有：

1.使用P2PKH和P2WPKH的单笔支付，

2.MuSig的n-of-n或等价的支付（类似于当前使用的P2SH和P2WSH 2-of-2多签），

3.最常见的k-of-n多签

4.闪电通道关闭，原子交换和其他可能需要各方就结果达成共识的合约协议。

这四个交易类别代表了迄今为止比特币的大部分交易。无论合约多么复杂，Taproot都能使协作输出结果看起来与区块链上的单笔支付相同。描述其他合约结果的脚本不添加到区块链中，从而为区块中更复杂的交易释放了空间。

在解释Taproot工作原理之前，了解它是MAST协议的实现很有用。下面进行详细介绍。

什么是MAST？

MAST是默克尔化抽象语法树（Merkelised Abstract Syntax Trees）的简称，最初由比特币开发者Johnson Lau博士于2016年提出。

MAST使用新的见证程序，并使用Merkle树编码脚本中独立的分支。Merkle树是一种数据结构，树这一术语用于描述分支结构。它通常把图表顶部称为根，而图表底部称为叶，如下图所示。

图1：Merkelized抽象语法树（MAST）

MAST可用于创建具有许多不同条款的复杂合约。仅显示执行的脚本，从而节省区块链上的空间并允许更复杂的脚本或者合约。

Merkle树是通过分别哈希每个脚本以获得简短的唯一标识符而创建的。然后，将这些标识符中的每一个与另一个标识符配对并再次进行哈希处理，从而生成另一个简短的唯一标识符。

这是一个交互过程，一直持续到只有一个标识符。在上图中称为Merkle根 — 地址=哈希（1，2） ，可以在仅几个字节的数据中唯一标识整个集合。我们可以将Merkle根视为比特币的密码箱。

与支付到脚本哈希（P2SH）相比，MAST允许在Merkle树中构造多个支出条件。仅显示满足的条件，其中使用Merkle根和路径来验证条件是否位于Merkle树中，同时将其余树隐藏起来。

例如，如果我们有一个复杂的脚本说，某人不能花掉比特币，直到一个月后（即一个时间锁）或者可以用3-of-5的多重签名来花费。在现在的比特币中，一旦比特币被花掉，这两种情况都会显示出来。

MAST的独特优势在于，如果揭示了Merkle树中的任何数据，则可以使用Merkle根和一些其他数据（称为Merkle路径）来验证该特定数据是否包含在Merkle树中。树的其余部分（以及其他条件）仍保持散列和隐藏状态。这意味着，如果所有参与者都同意，则仅需要透露所满足的条件。

有复杂交易任务的用户可以创建较小的交易，而带有大量亚脚本（sub-script）的更复杂的合约的效率收益则更大。与使用任何其他当前机制相比，MAST使得更多的条件分支成为可能。这打开了对更高级的智能合约的支持，而不必向比特币节点没有额外费用。

在上面的图1中，Alice甚至可以将更长的受益者添加到MAST结构中，而不会影响她交易的字节数。支付给矿工的费用没有增加，因此她仍然可以仅使用32个字节来花费她的比特币。在网络尺度上，区块将能够容纳更多的复杂的交易。

缺点是，默认情况下，每个人都必须使用MAST结构来维护隐私集。Merkle树的顶部分支始终可见，这意味着观察者可以确定存在其他支出条件。而且，对于大多数不需要应急脚本的交易来说，这也是一个负担，增加了成本。

到目前为止，MAST尚未部署到比特币中，因为所需的升级影响深远且复杂。这是Schnorr/Taproot/Tapscript提案的目的，在简单性和额外功能之间平衡。

Taproot如何改善MAST？

Taproot是最初由Greg Maxwell，Peter Wuille和Andrew Poelstra提出的比特币提案。后来，IRC和bitcoin-dev邮件列表上的十个主要贡献者都接受了它。Schnorr增加了一个新的签名类型，Taproot在此基础上又推出了一个新的交易输出类型以及确定支付条件的新方法。

Taproot具有自己的Merkle树版本，称为脚本树（script tree）。参与者可以选择以下使用：1）作为常规签名的公钥，或2）与脚本一起使用。

首先，是默认的支出路径，在此路径上无法区分单方或多方公钥。对于替代的支出途径，除非我们支出，否则不会显示隐藏的脚本。可以将不同的脚本组织到Merkle树中，也可以通过显示其中一个子句来使用输出。

如果我们使用主支出脚本花费交易，则只需提供Merkle证明，该证明由主支出脚本和替代支出脚本的哈希组成，足以证明主支出脚本在脚本树中。

Taproot使用MAST结构将条件隐藏在Merkle根下面。Merkle根本身会被密钥承诺（key commitment）隐藏起来，并可以通过密钥直接花费。只有一个密钥进入区块链，没有人能看到存在的其他条件。

与Schnorr结合使用时，Tastroot输出隐藏了MAST结构。在Merkle树的顶部，有一个用于发布单个公钥和签名的选项。实际上，这使P2PKH和P2SH交易看起来相同。

用一个例子来说明，比如关闭一个闪电网络通道。

闪电网络通道是2-of-2多重签名的变体。和需要复杂脚本来关闭闪电网络通道相比，Schnorr使人们可以把签名作为Taproot公钥/签名一起呈现。当双方都同意时，看起来就像，有人将带有常规签名的输入支付到两个地址上一样。观察者将无法分辨出它是一个闪电网络通道。

图2 TapBranch

用于关闭闪电网络通道的TapBranch脚本树（或TapTree）

为了隐藏MAST结构，上面图2中的TapBranch哈希对聚合的公钥进行了哈希处理（请记住，由于Schnorr，Alice和Bob可以将其公钥加在一起以创建taproot内部密钥）。

所得的哈希用作私钥，从该私钥派生另一个公钥（已调整的公钥）。调整密钥（也称为密钥对隐藏）嵌入脚本1和2。

然后将经过调整的公钥添加到taproot内部密钥中，以创建taproot输出密钥。该过程的简化图见下图3。

图3：Taproot里的调整公钥

如前所述，有两种支出方式。默认的支出路径是当Alice和Bob都同意关闭闪电网络通道，Taproot输出密钥确保该交易看起来像标准的P2PKH交易。在其他情况下，一旦花费比特币并且所有其他选项隐藏，所使用的脚本会被显示。

Taproot输出密钥可用于支付三个条件中的任何一个。在上面的示例中，如果Alice和Bob都同意闪电网络支付，则他们可以一起协作Schnorr签名，创建主公钥，将签名添加在一起并生成主签名。

双方各自以自己的签名进行部分签名，关闭闪电通道就像是是对公钥的直接支付。

在不协作的情况下，仅显示所使用的脚本。验证者将能够知道阈值公钥已通过MAST结构的Merkle根进行了调整。但是，所有其他选项/脚本保持隐藏。

从图3中，我们还可以看到脚本树为比特币提供了一个新的恢复选项。Taproot让丢失的比特币有了新的恢复选项（适用于钱包升级的用户）。就单个私钥而言，如果你丢失了它，比特币将永远丢失。相反，如果你丢失了私钥，但是你的资金是以Taproot的形式输出的，则可以有另一条途径可以找回比特币，比如你可以通过由你家人持有恢复的3-of-5备份密钥找回比特币。

总结

总之，Taproot（BIP 341）提高了比特币脚本功能的隐私性、效率以及灵活性，使开发人员可以编写复杂的脚本，同时最大程度地减少对链上的影响。

在扩容方面，可节省复杂交易大量的交易费用，因为数据密集型脚本不再需要支付比标准的“支付到公钥哈希”交易更高的费用。网络上的交易越复杂，效率上的收益就越大。

由于我们仅使用一个签名就可以执行复杂的交易，因此无论涉及多少签名者，用于聚合密钥和签名的字节数都完全相同。相比之下，使用“ 付款至见证脚本哈希（P2WSH）”的多重签名，每附加一个密钥添加8.5 vbytes，每附加一个签名添加大约18.25 vbytes。

在隐私方面，BIP 341旨在最大程度地减少链上交易透露出的关于交易输出花费条件的信息。大多数使用Taproot的应用程序都可以使用基于密钥的支出路径，该路径是私有的，并且可以推广到m-of-n多重签名策略。

尽管Schnorr使多重签名交易看起来像“常规”的“支付至公钥哈希”交易，但Taproot的加入扩展了看起来类似的交易类型，使“支付至公钥哈希”和“支付到脚本哈希”无法区分。

和SegWit和Schnorr一起，钱包和服务也必须升级才能有Taproot功能。随着越来越多的用户利用Taproot功能，对效率和隐私的积极影响也随之放大。

Taproot还为获得其他隐私好处打开了大门。例如，它将带有适配器签名的原子交换成为可能，这将使原子交换和其他类型的交易无法区别。这些交换最终可能被用作混币机制（类似于CoinJoin），但是其好处取决于钱包和服务提供商广泛采用Taproot输出。

Taproot带来的另一件有趣的事情是跨输入聚合（Cross-input aggregation），但它未包含在BIP 340–342中。虽然密钥聚合对于花费单个输入的多重签名交易很有用，但是大多数交易将多个输入组合在一起。使用跨输入聚合时，需要单个签名来同时花费交易中的所有输入，这将激励CoinJoin的使用。对于外部人来说，基于Schnorr的CoinJoin交易也将看起来像常规的单签名者交易。

由于需要进行广泛的更改和检查，因此BIP 341中不包括跨输入聚合。开发人员希望避免新功能对比特币安全性造成任何不利影响，同时仍为进一步升级和功能（例如跨输入聚合）提供坚实基础。

在有关Schnorr/Taproot/Tapscript系列文章的第三篇，我们将解释什么是Tapscript（BIP 342）以及BIP 340-342激活的可能方法。