比特币盟约提案：深入解析OP_VAULT（BIP 345）

这是第四篇深入研究各个盟约提案，这些提案已达到了成熟度，值得深入探讨。

由詹姆斯·奥比恩（James O’Beirne）在BIP 345中提出（格雷格·桑德斯（Greg Sanders）后来担任合著者），是一份旨在实施库的盟约。这还取决于（或TXHASH或其他类似的Opcodes）来完成保险库的构造。

在了解建议本身的工作原理之前，先看看保险柜要完成的工作。

保险库的目的是提高比特币存储的安全性。这是通过从保险库中的任何尝试中引入延迟期来完成的。保管库不得直接从金库中发送您的比特币，而是将它们限制为限制，以便它们只能发送到“中间”地址。虽然从保险库中撤回的硬币处于这种中间地面状态，但它们可以在您控制下的任何时间都花在深层的冷藏钱包中（理想情况下是地理上分布的保险库Multisig）和仅有的深层冷藏。在预定义的时间表之后，可以将硬币继续前进到最终的目的地。

目前可以通过预先签署的交易来做到这一点，但这带来了很大程度的复杂性，效率低下，缺乏灵活性和损失资金的风险。

使用预先签名的交易要求您提前决定一次会撤回多少钱，从保险库中撤回的交易的费用将支付，在完全撤回之前的临时地址是什么，然后您有要安全删除用于预先签名所有这些交易的私钥。

除了预先决定、费用等的总体限制外，这种架构的一个大问题是，地址再利用是不安全的。在预先签名的交易保险库方案中，将存款发送到用于预先签名初始保险库事务的地址，并且在签署保管库交易后将删除所涉及的所有密钥。地址重用是不好的做法，但是您不能阻止其他人将资金发送到他们以前使用的地址。任何这样的后来存款的资金将永远丢失，因为金库钥匙都已被删除。

同样，每个存款中的每笔存款都需要新的新钥匙设置，再次进行预先签名的仪式，以确保将新的钥匙牢固地删除，并管理所有这些信息，包括冗余备份，并管理所有这些信息。每个存款都为在设置保险库中弄乱的东西都会为某些东西弄乱，每次存款都为自上次押金以来一直妥协的人或设备损害您的资金的人提供了机会。

预先签名的交易库是一种笨拙且复杂的结构，并且表现出足够的复杂性，每种用途的确具有不可忽视的风险，即以一种导致资金损失的方式混乱。

可以使用CTV进行改进，例如消除需要安全删除密钥的需求，但其余的复杂性和风险仍然存在。金额和费用仍然必须预先定义。地址再利用仍然会导致基金损失。

OP_VAULT的工作原理

OP_VAULT建立在Taproot上，这意味着整个设计使用Tapscript，并取决于Taptrees的存在和脚本支出路径。这也取决于使用CTV（或TXHASH/类似功能）来构建完整保险库。

该提案实际上是两个opcodes，op_vault和op_vault_recover。 OP_VAULT用于触发从保险库中的提款，OP_VAULT_RECOVE被用来将触发提款触发到深层恢复钱包中。这个想法是构造一个带有op_vault路径的taptree进行提取，然后up_vault_recover路径将任何资金扫除到中间的任何资金到安全的冷钱包。此taptree是您的保险库。

OP_VAULT的工作原理是限制了交易支出的输出如何看待OP_VAULT扣硬币。 OpCode在证人中期望：

• Tapleaf脚本主体
• 脚本更新的数据件数
• 提取的输出索引
• 任何资金回到保险库的输出索引
• 一量萨托斯回到保险库中

OP_VAULT确保将正确的资金发送回保险库是正确的，并且该输出的输出脚本为完全相同的到taptree。它还需要Tapleaf脚本主体，并提供了数据变量，并将它们组合成完整的Tapleaf脚本。然后，它确保指定提取的输出具有一个相同的脚本，其中taptree的输入是所用的输入，除了从中用的tapleaf替换为Tapleaf脚本与证人的数据一起替换。

最后的技巧是可能的，因为要验证tapleaf是taptree的一部分，首先必须存在默克尔树的内部节点才能验证。用树的其余部分的已知内部叶子将新脚本放置，可确保只有树的叶子才能改变。动态填充的脚本的模板是在创建保险库时定义的。对于典型的保险库用例，脚本模板将仅是触发提款时提供的哈希的时间表的CTV支出路径。

op_vault_recover要简单得多。它需要恢复脚本的哈希，以及用于恢复事务的输出索引。该输出必须包含一个与预定义哈希相匹配的脚本，并且要恢复的输入中的全部资金数量必须转到该输出。

这两个脚本都可以用授权脚本“封闭”，即从特定键提供签名以触发提款或启动恢复。这有一些交易折扣。如果您丢失了恢复授权密钥，则在盗窃提款触发键的情况下，无法再触发恢复交易。但是，它确实允许您在同一交易中从多个Vault UTXO启动恢复，这是由于指定每个输入相应的输出。

什么是op_vault对

显然是金库。 OP_VAULT干净地解决了预先签名的事务或基于CTV的金库的所有主要限制。没有限制性预先决定的教派或预先决定的费用，没有重复地址的危险，也无需每次存款时处理诸如密钥删除之类的高安全问题。

不过，它比仅仅是保险库更灵活。那是设计时的预期用例，但这是一项更一般的盟约，可以确保Taptree在需要时实际上将其转移到下一个UTXO，并具有具有一定灵活性的预定义出口条件。

您可以使用OP_VAULT使某些内容非常接近。创建一个在3-6个月（类似于Drivechain撤回）的订单下，该模板具有令人难以置信的较长时间脉冲。没有任何脚本的授权门，并将模板公开。现在，人们可以通过将资金寄给该保险库脚本来将资金存入“ Drivechain”。任何人都可以通过简单地从OP_VAULT路径上花费并包括其提款交易的CTV哈希人来提议提款。矿工可以通过简单地拒绝开采任何无效的撤回交易来实施这一问题，如果恶意矿工曾经挖掘出恶意撤离触发器，那么下一个诚实的矿工就可以简单地兑现资金。

这就是只需使用BIP中建议的相同脚本模板即可完成的操作。用于提款的脚本模板是任意的，因此，就哪种类型的自我持续合同OP_VAULT可以启用，这可能是非常通用的。

结束思想

OP_VAULT清楚地实现了实现不带有预先签名的交易库（甚至更简单的与CTV之类的契约库）所带来的限制，复杂性和风险的适当库的目标。但是，这样做的过程中，它引入了一组相当广泛而广义的功能，以实现该目标。

该提案绝对可以实现相对平稳且安全的保险库功能，但也可以打开许多其他门。 Drivechains是围绕矿工提取价值（MEV）的集中的东西。能够使这种功能的缺点以及它可能拥有的激励问题和后果，应与实现良好结构库的上行相比。

OP_VAULT是一个相对成熟的建议，但是启用的功能程度不应轻视。