大约两周后，比特币将迎来它最重要的技术升级之一：Taproot。
什么是Taproot？维基百科上给出的普通定义是：
“主根（taproot）是一个大的、中心的、占优势的根，而其它的根会从其侧面发芽。通常，主根有些直，然后形状逐渐变细，并直接向下生长。在例如胡萝卜这样的植物中，主根是一种非常发达的贮藏器官，其已被作为蔬菜栽培。”
那比特币即将采用的Taproot技术方案到底是什么？它的名字是如何来的？
比特币Taproot名字的由来
“我一直认为这个名字的由来是‘利用Merkle根‘，但我实际上并不知道Gregory Maxwell的想法是什么。’ —— Pieter Wuille（来源）
“我最初不得不查这个词，但我把它理解成了关键路径，因为它是你制作美味的胡萝卜汤的核心，而默克尔化的脚本将是你希望忽略的其他较小的根。” —— Anthony Towns （来源）
而Taproot方案提出者Gregory Maxwell给出的答案则是：
“这个词起源于一棵树的形象化，这颗树的中央有一个像蒲公英主根一样粗壮的中心（这项技术非常有用，因为假设有一条高概率路径，其余的路径就模糊化了）。我认为这是一个很好的方法，因为它通过利用根中隐藏的commitment来验证脚本路径的花费。
……唉，将具有已排序内部节点的哈希树称为“桃金娘树”（Myrtle tree）并没有流行起来。 （Myrtle tree是包括Melaleuca树、茶树（tea-tree）在内的树家族，这听起来像’merkle’。:p)”
因此，当谈论比特币taproot时，我们脑海中浮现出来的图像应该是下面这个样子的：
来源：SHUTTERSTOCK
Taproot升级对比特币的影响是什么？
早在18年初，在Gregory Maxwell提出Taproot方案之后，国内比特币社区便对该方案进行了早期的报道，当时社区的关注点在于：
“实施taproot升级后，闪电网络将变得更加私密，这使得LN交易与所有比特币交易无法区分开来，因此人们将无法区分比特币的链上交易和闪电网络的链下交易”。
而要应用Taproot的前提，是需要先让Schnorr签名方案落地。
到了2019年，除了提高比特币的隐私性之外，Taproot方案又被社区赋予了新的使命 —— 扩展比特币智能合约的灵活性。也因此，Taproot升级以及Schnorr签名被提升为“比特币在下一阶段的重要技术”。
2020年1月份，Bitcoin core代码库维护者之一Pieter Wuille 正式发布了包含Taproot/Schnorr 软分叉升级的BIP 340、BIP 341以及BIP 342，由此，这两个升级提案开始逐渐进入比特币用户们的视野。
今年6月份，比特币全网支持Taproot升级的算力超过了90%，达到了锁定升级的最低要求，这也意味着 Taproot将在比特币区块高度达到709,632（预计将在北京时间11月13日前后）时正式与大家见面。
关于Taproot和Schnorr签名的一些趣事
1、比特币最初使用的是ECDSA签名方案，但实际上Schnorr签名要比ECDSA签名更早诞生，我们说Schnorr 签名是对比特币原始 ECDSA 签名的升级，是因为其可以更容易地实现各种密码学技巧。在时间顺序上，Schnorr签名算法的诞生，要早于ECDSA 所基于的 DSA 算法。而中本聪使用DSA的部分目的是为了规避 Claus Peter Schnorr 的 Schnorr签名专利，而他的专利在 2011 年到期了。
2、虽然没有成功，但在比特币采用Schnorr签名的早期发展中，有人建议不应将Claus-Peter Schnorr的名字与比特币关联起来，因为他的专利导致这种有价值的密码学技术在20多年的时间里没有被广泛使用。Pieter Wuille曾表示：
“我们确实考虑过用DLS（离散对数签名）来称呼BIP340，但我们最终没有这样做，因为Schnorr的名字已经被谈论得太多了。”
3、Pay to contract：Ilja Gerhardt 和 Timo Hanke 创建了一个名为Pay to contract的协议，该协议由Hanke 在 2013 年的圣何塞比特币会议上提出，其允许一笔支付承诺其合约的哈希值。任何拥有该合约副本和用于避免某些攻击的nonce的人，都可以验证这个承诺（commitment），但对其他人来说，这种付款看起来与其他的比特币付款类似。
2014 年关于侧链的论文中包含了对这种pay-to-contract (P2C)协议的轻微改进，其中承诺还包括原始的支付公钥，而Taproot 使用了相同的结构。
Taproot落地之后，未来可能的比特币共识改变
那在激活Taproot之后，开发者们会在它的基础之上对比特币进行哪些共识层的改进呢？
1、交叉输入（Cross-input）签名聚合：Schnorr签名使几个不同的公钥和私钥对的所有者可轻松地创建单个签名，以证明所有密钥所有者在创建签名时都进行了协作。随着未来共识的变化，这可能允许交易包含单个签名，该签名可用于证明在该交易中使用的所有UTXO的所有者已授权使用。在第一次输入后，这将为每个密钥路径（keypath） 花费节省大约 16 虚拟字节（vbytes），从而为整合以及coinjoin节省开销。它甚至可使基于coinjoin的支出比常规的支出更便宜，从而提供一种温和的激励，以鼓励人们更多地去使用隐私交易。
2、SIGHASH_ANYPREVOUT：每一笔正常的比特币交易都包含一个或多个输入，并且这些输入中的每一个都使用其 txid 引用前一笔交易的输出。这告诉了全验证节点（例如Bitcoin Core）这笔交易可以花费多少钱，以及需要满足哪些条件才能证明支出是经过授权的。为比特币交易生成签名的所有方式，无论有没有taproot，要么提交到prevout中的txid，要么根本不牵扯到prevout。对于不想使用精确的预先安排的一系列交易的多用户协议来说，这是一个问题。如果任何用户可以跳过特定交易，或更改除witness验证数据之外的任何交易的任何细节，这将更改任何后续交易的 txid。而更改 txid 会使之前为以后交易创建的任何签名无效。这迫使链下协议实施机制来惩罚任何提交旧交易的用户（例如 LN 的惩罚机制）。
而SIGHASH_ANYPREVOUT可通过允许签名跳过提交到prevout txid 来消除这个问题。这使得为闪电网络（LN） 实施 eltoo 层以及对vault金库和其他合约协议的改进成为可能。
3、委托（Delegation）和归纳：在你创建一个脚本（taproot或其它）之后，除了将私钥授予其他人（非常危险），你几乎无法授权他人使用该脚本。此外，对于想要使用密钥路径（keypath）花费加上少量基于脚本条件的用户来说，可以使taproot变得更经济。开发者们已经提出了几种通过归纳和提供签名者委托来增强 taproot的方法：
（1）Graftroot：在taproot的想法诞生后不久，Graftroot就被提出了，该方案将为任何能够制作taproot路径的人提供一项额外的功能。密钥路径（keypath）签名者可以签署一个脚本，描述资金可使用的新条件，将支出权限委托给任何能够满足该脚本要求的人，而不是直接支出资金。签名、脚本以及满足脚本所需的任何数据，都将在支出交易中提供。 密钥路径（keypath）签名者可通过这种方式委托给无限数量的脚本，而无需创建任何链上数据，直到发生实际支出。
（2）广义taproot (g’root): 几个月后，Anthony Towns提出了一种使用公钥点（public key points）来承诺多种不同支出条件的方法，而不必使用类似 MAST 的结构。这种广义taproot (g’root)构造“在taproot假设不成立的情况下可能更有效”，此外，它还提供了一种构建软分叉安全交叉输入聚合系统的简单方法。
（3）Entroot：Graftroot和g’root的最新合成方案，它简化了许多情况，使它们更具带宽效率。
4、新的和旧的操作码（opcode）：taproot 软分叉包含了对tapscript 的支持，它提供了一种向比特币添加新操作码的改进方法，即 OP_SUCCESSx 操作码。一些拟议的新操作码包括：
（1）恢复旧操作码：由于担心安全漏洞，2010 年开发者禁用了一些数学和字符串操作的操作码。许多开发人员希望在安全审查后重新启用这些操作码，并且（在某些情况下）可能会扩展操作码以处理更大的数字。
（2）OP_CAT：值得特别提及的一个先前禁用的操作码是OP_CAT，研究人员发现它可单独在比特币上实现各种有趣的行为，或者它还能以有趣的方式与其他新操作码进行组合。
（3）OP_TAPLEAF_UPDATE_VERIFY：当与taproot的密钥路径和脚本路径功能一起使用时，OP_TLUV操作码能以一种特别高效和强大的方式启用契约（covenants）。这可用于实现JoinPool、Vault以及其他安全和隐私改进。它还可以与OP_CHECKTEMPLATEVERIFY很好地结合。
注意，以上所有的想法仍然只是提议，没有人能保证它们会成功应用，这需要研究人员和开发人员完成每一项提案，然后由用户决定这些功能是否值得去改变比特币的共识规则。
相关资料：
1、https://bitcoinops.org/en/newsletters/2021/10/27/
2、https://bitcoinops.org/en/newsletters/2021/10/20/
3、https://www.8btc.com/article/223681
4、https://www.8btc.com/article/351969