黄金硬核 | 比特币或将迎来2020年最大升级 什么是Tapscript？

金色财经近期推出硬核专栏，为读者提供热门项目的介绍或深度解读。

虽然比特币在3月12日大跌，但币圈人士却很受伤。 但作为投资者，还是要多关注技术进步。 毕竟，技术进步是比特币价值的源泉。 正如2017年的“隔离见证”见证了2017年的比特币牛市一样，希望比特币新技术的突破能够带领比特币走出泥潭。

正如我们在《BTC第三次减半全解读》中所说，2020年比特币值得关注的进展之一就是Schnorr/Taproot/Tapscript软分叉。 这个计划中的分叉将包括三个比特币改进。 协议 BIP 340、341 和 342。我们将对这三个 BIP 进行一系列解读。 上两期Hardcore，我们解读了Schnorr签名的BIP340和Taproot签名的BIP341。

本期重点关注 Tapscript。 查看什么是 Tapscript 协议以及如何激活比特币改进协议（或 BIP），享受它

Tapscript (BIP 342)

该升级提案的第三部分 BIP 342 描述了对 Schnorr 和 Taproot 的补充升级，称为 Tapscript。 正如我们在 Schnorr/Taproot/Tapscript 上的第一篇文章中所述，比特币脚本用于确定比特币支出策略。

BIP 342 改进了签名的哈希算法，因此我们可以验证 taproot 脚本，引入灵活性，添加新的操作码以增强比特币的智能合约功能，还改变了对资源要求的一些限制。

什么是操作码？

操作码是操作代码的缩写，基本上是脚本语句或命令。 这些命令可以为发送/接收事务返回“TRUE”或“FALSE”。

例如，脚本指令指定解锁脚本所需的签名数。 它们还指示交易的比特币数量和收件人地址。

操作码可用于从堆栈中删除项目并执行计算，然后将结果添加回堆栈。 请记住，作为一种基于堆栈的编程语言，脚本指令是按照从堆栈顶部到底部的顺序执行的。

什么是 TapScript？

作为比特币编程语言（脚本）的升级版，Tapscript 更易于添加新功能，并提供基于 Schnorr 签名的批量可验证性。

什么是批量验证？ Schnorr/Taproot/Tapscript 系列的第一篇文章。

Tapscript 还对 BIP 341 (Taproot) 中提出的比特币脚本结构的改进进行了补充，BIP 341 (Taproot) 需要更改某些操作码，而 BIP 342 则解决了需要进行的更改。

理解 Tapscript 的另一种方式是考虑 Taproot 的 Merkle 树，其中每个叶子（叶子）是一个脚本，可以称为叶子版本，类似于 SegWit 的脚本版本控制。

但不同的是，脚本在支付时不显示，只在消费时显示。 不同的叶子可以有不同的版本，这里只显示实际使用的叶子。 Tapscript 是 Taproot 下版本 0 的叶版本。

Tapscript 与传统和 SegWit 比特币脚本共享大部分操作，但有一些区别：

签名操作码验证 Schnorr 签名（而不是 ECDSA 签名）。

多重签名操作码 OP_CHECKMULTISIG 和 OP_CHECKMULTISIGVERIFY 被操作码 OP_CHECKSIGADD 取代，允许使用 Schnorr 批量验证签名。

由于签名验证是比特币脚本中 CPU 最密集的操作，因此这些操作码对于实现与基于 Schnorr 的多重签名方案相关的效率提升至关重要。

目前，2-of-3 多重签名交易的脚本如下所示：

2 3 检查多重信号

使用Taproot/Tapscript，可以批量验证的方式创建同一个多重签名策略，脚本为：

OP_CHECKSIG OP_CSADD OP_CHECKSIGADD OP_2 OP_EQUAL

许多操作码被重新定义为 OP_SUCCESS 操作码，它无条件地验证整个脚本以简化软分叉升级。

新操作码 OP_SUCCESS 的引入比当前使用的机制 OP_NOP 更容易验证。

以前不可用的操作码通常返回“FALSE”状态，Tapscript 将以“TRUE”状态返回它们。 只要操作码存在于脚本中，您就可以无条件地使用它，实际好处是能够将操作码重新定义为任意值并且不需要向后兼容。

这种使用新操作码扩展脚本的新机制比现有的见证版本控制机制更容易协调和使用。 因此，它有望为将来将更有用的操作码添加到比特币脚本开辟道路。

现有的 NOP 操作码可能已专门添加以具有升级机制，以便我们可以轻松地向比特币脚本语言添加新的操作码。

但到目前为止，它们仅用于 CHECKLOCKTIMEVERIFY 和 CHECKSEQUENCEVERIFY。 为了与软分叉兼容，这些 NOP 只能做以下两件事之一：1) 中止或 2) 什么都不做。

目前，CHECKLOCKTIMEVERIFY 和 CHECKSEQUENCEVERIFY 操作码无法以任何方式修改堆栈，因为它们重新定义了 NOP。 因此，它们不会将参数从堆栈中弹出，并且您始终需要在其后跟一个 OP_DROPafter。

操作码什么都不做（即 NOP），Tapscript 是一种引入新操作码 OP_SUCCESS 的解决方案，它“返回 TRUE”。 这些操作码仅在使用时使用，直到它们在网络上定义锁定语义后才会使用。

结果，禁用和未定义的操作码数字将“返回 TRUE”。 随后，这些操作码可以被重新定义为任何东西，因为一切都是软分叉的，与“return TRUE”兼容。

签名哈希 (SIGHASH) 的计算方式不同于旧脚本或 BIP143 v0 隔离见证。

什么是签名哈希？ 简而言之，签名哈希是比特币签名的标志，指示交易的哪些部分已签名。

使用 scriptsigs，签名证明您有权使用某些比特币。 这些签名的构造方式是在签名后附加一个字节，指定交易的签名方式。 因此，已经有一些 SIGHASH 正在部署和实施。

最常用的是 SIGHASH_ALL，其中除 scriptsigs 之外的所有内容都已签名。 而当只有当前输入被签名并且交易中的其他所有内容都不被视为签名的一部分时，使用 SIGHASH_ANYONECANPAY 之类的东西时，不包括承诺。

已经针对这些 SIGHASH 类型提出了许多改进，例如您只想签署交易的某些方面的条件，以及您可以指定您在花费比特币时对（和不）感兴趣的条件的条件。 SIGHASH 已经提出了一些关于如何做到这一点的标志，包括 SIGHASH_NOINPUT。

它通过屏蔽交易的不同部分来工作。 SIGHASH_NOINPUT 背后的想法是你不关心提供了什么具体输入，你不关心为交易提供输入的交易 ID 是什么，但你关心金额。 在 SegWit 之前，这是 2015 年提议的延展性修复，它本身就是一个延展性修复。 由于对 SIGHASH_NOINPUT 的担忧和风险，社区没有将其纳入比特币协议（但 SegWit 的引入为此次升级重新打开了大门）。

SIGHASH_NOINPUT 的主要好处是它极大地简化了闪电网络等支付渠道。 一项改变闪电网络工作方式的提议是 eltoo，它通过转移之前已经过期的状态来简化通道的使用，这样当有人试图作弊时通道受到惩罚时就不必再关闭它。

这需要更改比特币脚本。 特别是，这些变化涉及签名应用于交易的方式（即 Sighash 系统），它允许用户重新平衡其他输入。

尽管对一些现有的 sighash 类型进行了一些调整，但 Schnorr/Taproot/Tapscript 提议提供了与 BIP 118 完全不同的功能2020比特币减半时间，即 SIGHASH_NOINPUT（已经有很多关于使其安全的各种方法的讨论）。

Tapscript 没有包含 SIGHASH_NOINPUT，而是提供了几种灵活的机制（例如标记的公钥），允许在不增加成本的情况下开放此功能。 这种机制将使未来的软分叉更容易使用新的 sighash 类型或其他更改来扩展签名检查操作码。

使用 Tapscript，以您不知道的字节开头的公钥会自动得到验证。 因此，可以引入新型签名方案和新的 sighash 方案，而无需为每个方案添加新的 Checkig 操作码。 SIGHASH_NOINPUT 等功能可以作为新的公钥版本免费包含在内。

Tapscript 还会更改资源限制。

例如，今天的比特币脚本有 10,000 字节的脚本大小限制，该限制将被删除。 它还消除了对操作码数量的限制。

由于 scriptCode 未直接包含在签名哈希中（仅通过预先计算的 tapleaf 哈希间接包含），因此用于签名检查的 CPU 时间不再与执行脚本的大小成正比。

在 Tapscript 中，签名操作码的数量不计入 BIP141 或旧的 sigop 限制。 旧的 sigop 限制使得在创建区块时选择交易变得很麻烦，因为它是一个附加了权重的约束。 相反，Tapscript 签名操作码的数量受见证权的限制。

Tapscript 与 BIP 340/341 一起扩展了比特币可能的有趣应用的数量，例如特殊的 Taproot 合约。 特殊的 Taproot 合约允许执行更复杂的多方合约，并为基于比特币的去中心化自治组织 (DAO) 开辟了可能性。

在比特币上激活 BIP 340–342

升级是如何添加到比特币协议中的？

提交 BIP 后，将编写代码以匹配规范，然后将其作为拉取请求提交。 在此阶段之后，用户和开发人员对拉取请求进行投票。 即使合并后，用户实际上也可以通过运行新代码（或不运行并坚持使用旧代码）来投票。

Schnorr/Taproot/Tapscript 升级目前正处于社区反馈阶段（如下图）。 下一步是编写代码，获取对比特币的拉取请求，并让网络准备好进行测试。

尽管下图显示进展是线性发生的，但社区反馈和协议实施阶段之间可能存在一些反馈循环（例如，随着规范过渡到工作代码，提案可能会进行进一步的更改）。

BIP 如何融入比特币协议的概述

正如 2017 年 SegWit 升级所见，BIP 9（要求 95% 的矿工表示他们已准备好激活）的使用可能会导致社区中不同参与者、开发者/用户和矿工之间的拉锯战。

一些人认为，比特币矿工可能会使用 BIP 9 作为一种强大的工具来打造对他们有利的协议。 例如，SegWit 无法通过 BIP 9 激活，而是转移到由 shaolinfry 创建的变体，即用户激活的软分叉或 BIP 148。

为了激活 BIP 340–342，比特币开发者 Matt Carallo 吸取了 SegWit 升级的经验教训，提出“大共识清理”作为一种可能的方法。 该提案结合了 BIP 8 和 BIP 9 的理想属性，如下所示：

1. 激活方法最初以类似于标准 BIP 9 的方式部署（通常需要 95% 的矿工在一年的时间内准备就绪），

2.如果此方法激活失败，社区需要六个月的时间来讨论未激活升级的原因，

3、用户可选择BIP 8部署2020比特币减半时间，激活期为2年。

这种激活方法试图根据社区的意愿进行平衡，但同时使激活期足够长，以确保对比特币协议的更改不会开创负面先例。

时间不确定，因为不知道在将这些建议转换为工作代码时是否会出现意外问题。 我们要到 2020 年底或更晚才能看到 BIP 340-342 的激活。

Schnorr/Taproot/Tapscript 可以说是迄今为止对比特币最重要的改变，改进了可扩展性、隐私和智能合约功能。 以采用 SegWit 作为标准，比特币的收益将是深远的，尽管至少需要两年时间，甚至更长的时间才能看到它们的广泛采用。