主页 > token.im钱包下载 > 首页> imtoken地址查询> Tapscript将如何让比特币受益？
首页> imtoken地址查询> Tapscript将如何让比特币受益？
原始帖子发布于 2020 年 3 月 19 日。
这是我们关于 BIP 340 ~ 342 系列的最后一篇文章。本文介绍了 Tapscript 是什么以及该提案的好处。
本系列的前两篇文章分别介绍了 Schnorr 和 Taproot。
本文还将讲解如何激活比特币改进协议（BIP）并实现升级加入比特币。
Tapscript (BIP 342)
BIP 342 的第 3 部分提出了一种称为 Tapscript 的升级，作为对 Schnorr 和 Taproot 的补充。 根据一篇介绍 Schnorr/Taproot/Tapscript 的文章，Bitcoin Script 用于定义比特币支出规则。
BIP 342 允许我们通过改进签名哈希方法来验证主根脚本，支持添加操作码以增强比特币的智能合约能力，并改变了对资源要求的一些限制。
什么是操作码
一个操作码（opcode）实际上是一种脚本语言或命令。 对于成功的发送/接收事务，这些命令可能会返回“TRUE”或“FALSE”。
例如，这些命令指定解锁脚本所需的签名数。 它们还表明转移的比特币数量，以及收款人的地址。
操作码可用于从堆栈中移除元素并执行计算，将计算结果添加到堆栈中。 不要忘记，因为 Script 是一种基于堆栈的编程语言。 脚本命令按顺序执行，从栈顶开始，到栈底结束。
什么是 Tapscript
Tapscript 是比特币编程语言 Script 的升级版，建立在 Schnorr 签名的批量可验证性之上，可以更轻松地添加新功能。
不知道什么是批量验证？ 单击此处阅读我们对 Schnorr/Taproot/Tapscript 的介绍。
Tapscript也是对BIP 341中提出的Bitcoin Script结构改进（Taproot）的补充。Taproot需要改变的操作码是BIP 342的重点。
你也可以这样理解 Tapscript：想象一下 Taproot 的 Merkle 树，其中每个叶节点都是一个脚本，结合所谓的叶版本（SegWit-like script versioning）。
但是，特别是，这些脚本不会在收到付款时显示，仅在付款时显示。 不同的叶子节点可以有不同的版本，但只会显示实际使用的版本。 Tapscript 是 Taproot Merkel Leaf Edition 的推荐版本 0。
Tapscript 的操作与传统比特币脚本和 SegWit 比特币脚本大致相同，但有一些不同之处：
由于签名验证是比特币脚本中 CPU 最密集的操作，因此这些操作码对于帮助提高基于 Schnorr 的多重签名方案的效率至关重要。
当前2/3多重签名交易的脚本如下：
2 3 CHECKMULTISIG
使用Taproot/Tapscript，我们也可以批量可验证的方式创建2/3的多重签名交易，脚本如下：
OP_CHECKSIG OP_CSADD OP_CHECKSIGADD OP_2 OP_EQUAL
OP_SUCCESS 允许添加新的操作码比当前机制中使用的 OP_NOP 容易得多。
Tapscript 将以前不可用的操作码从返回“FALSE”更改为返回“TRUE”。 只要脚本中存在这些操作码，就可以无条件地使用脚本。 这样做的好处是操作码可以重新定义为任何东西，不需要向后兼容。
与目前的SegWit版本控制相比，新机制可以使用新的操作码扩展脚本，因此协调和使用起来要简单得多。 因此，多亏了新机制，我们可以轻松地向比特币脚本添加更多有用的操作码。
现有的 NOP 操作码可能会创建一种升级机制，使我们能够轻松地将新的操作码添加到比特币的脚本语言中。
然而，到目前为止，NOP 操作码仅用于 CHECKLOCKTIMEVERIFY 和 CHECKSEQUENCEVERIFY。 为了与软分叉兼容，这些 NOP 操作码要么导致异常，要么什么都不做。
由于 NOP（无操作）的重新定义，操作码 CHECKLOCKTIMEVERIFY 和 CHECKSEQUENCEVERIFY 不能以任何方式修改堆栈。 因此，这两个操作码不会将参数弹出堆栈，在这种情况下用户必须使用 OP_DROP。
为了解决无效操作码（即 NOP）的问题，Tapscript 引入了一个新的操作码 OP_SUCCESS，它只“返回 TRUE”。 这样的操作码在实际使用之前不会被使用，并且只有当它们具有已经在网络上定义的不可变语义时才会被使用。
这导致禁用和未定义的操作码“return TRUE”。 之后，这些操作码可以被重新定义为任何东西，因为“only TRUE”操作码与任何软分叉兼容。
什么是签名哈希？ 简而言之，签名哈希是比特币上的签名，表明交易的哪些部分是由签名签名的。
使用scriptsig（解锁签名），签名证明你有使用比特币的权利。 这些签名以特定方式构建，每个签名附加一个字节，指示交易是如何签名的。 一些 SIGHASH 标志现在在比特币中实现。
最常用的标志是SIGHASH_ALL，表示除scriptsig以外的所有部分都被签名。 其他标志，例如 SIGHASH_ANYONECANPAY，仅在当前输入已签名且交易的其余部分未签名且未包装在 Promise 中时使用。
已经对现有的 SIGHASH 标志提出了许多改进建议，以及许多新的 SIGHASH 标志，以满足用户只签署交易的某些部分的需求，并表明他们希望（并执行）的条件不希望）花费比特币。 ，包括 SIGHASH_NOINPUT。
这些不同的 SIGHASH 标志如何工作：交易的不同部分被阻止。 SIGHASH_NOINPUT标志的原理是用户不关心具体的输入及其来源交易ID，只关心转账次数。 该代币于 2015 年先于 SegWit 提出（也是为了解决交易延展性问题）。 然而，围绕 SIGHASH_NOINPUT 标志的担忧和风险意味着比特币社区没有采用它（但 SegWit 再次为这次升级打开了大门）。
SIGHASH_NOINPUT 标志的主要优点是它可以更轻松地使用闪电网络等方案的支付渠道。 还有另一个提案elto，它也让支付渠道的使用变得更容易。 它将改变闪电网络的工作方式：如果一方试图通过提交已过期的旧状态来关闭通道，则将不再触发惩罚机制。
eltoo 要求我们更改比特币脚本，特别是签名应用于交易的方式（即 sighash 系统），允许用户重新平衡不同的输入。
虽然一些现有的 sighash 类型只是略微调整，但 Schnorr/Taproot/Tapscript 提议不会提供任何类似 BIP 118（即 SIGHASH_NOINPUT）的东西（因为已经讨论了各种实现和保护。）
虽然不支持 SIGHASH_NOINPUT，但 Tapscript 提供了一些灵活的机制（即标记化公钥），可以在未来实现而无需引入 SIGHASH_NOINPUT 函数的额外成本。 使用 Tapscript，我们可以在未来添加新的 sighash 类型或通过软分叉进行其他更改，以扩展签名检查操作码。
使用 Tapscript，即使以未定义字节开头的公钥也被自动视为有效。 因此，我们不需要通过引入新的签名方案或新的 sighash 方案来添加新的检查操作码。 SIGHASH_NOINPUT 等标志可以直接用作新的公钥版本，无需额外费用。
例如，Tapscript 不仅将比特币脚本从当前的 10,000 字节大小限制中解放出来，而且还取消了操作码限制。
由于 scriptCode 不直接包含在签名哈希中（而是通过预先计算的 tapleaf 哈希间接包含），因此签名验证消耗的 CPU 时间不再与执行脚本的大小成正比。
在 Tapscript 中，签名操作码的数量不计入 BIP141 或遗留签名操作码限制。 之前的签名操作码限制使得构建区块时的交易选择变得很麻烦，因为它在区块权重之上添加了新的限制。 相比之下，Tapscript 的签名操作码数量仅受见证数据权重的限制。
在Tapscript和BIP 340/341的配合下比特币如何增加，比特币有望迎来更多有趣的应用。 一个例子是富有表现力的 Taproot 合约，它不仅支持更复杂的多方合约，还支持基于比特币的 DAO（去中心化自治组织）。
激活比特币BIP 340 ~ 342
如何对比特币协议进行升级？
BIP提议者在提交BIP后需要编写符合规范的代码，然后通过pull request提交代码。 在此阶段之后，用户和开发人员对拉取请求进行投票。 尽管 BIP 已被纳入比特币协议，但用户可以通过选择是否运行新代码来表态。
Schnorr/Taproot/Tapscript 升级目前处于生态反馈阶段（如下图）。 后续阶段需要编写代码来提交拉取请求和准备测试网。
虽然下图中显示的流程是线性的，但在生态反馈和协议实施阶段之间可能存在反馈循环（例如，提案可能在将规范转化为代码的过程中发生变化）。
- BIP 是如何添加到比特币协议中的 -
正如我们在 2017 年的 SegWit 升级中看到的那样，BIP 9（需要 95% 的矿工支持）的使用可能会导致生态系统中不同参与者（包括开发者、用户和矿工）之间的利益之争。
一些人认为比特币矿工可能会使用 BIP 9 在比特币协议中获得优势。 例如，SegWit 没有被 BIP 9 激活，而是转向了由 shaolinfry 创建的另一个激活方案，这是一个用户激活的软分叉 (BIP 148)。
为了激活BIP 340~342，比特币开发者Matt Carallo吸取了SegWit升级的教训，提出了名为“Great Consensus Clean Up”的解决方案。 提案集 BIP 8 和 BIP 9 的长度：
激活最初将与标准 BIP 9 部署过程相同（需要 1 年内 95% 的矿工支持）。
如果升级激活失败，社区有6个月时间讨论失败原因。
用户还可以选择激活两年的 BIP 8 部署流程。
这种激活方式试图在坚持社区意愿和允许激活时间足够长以确保对比特币协议所做的任何更改都不会产生负面影响之间取得平衡。
激活时间不确定，因为尚不清楚这些提案将如何写入代码以及是否会出现意想不到的问题。 BIP 340~342预计2020年底启动，大概率延期。
Schnorr/Taproot/Tapscript 是迄今为止对比特币的最大改革，这将有助于增强可扩展性、支出政策隐私和智能合约功能。 虽然这些升级预计需要两年或更长时间才能大规模实施比特币如何增加，但它们将对比特币产生深远影响。
（结束）
