读者对《契约的崇拜》作出回应

Reader response to The Worship of Contracts

Shinobi的草稿是一个每周系列，我们的技术编辑Shinobi挑战比特币社区，旨在引发关于激烈技术争论的讨论。

_________________________________________________________________

上周，我发布了一个简短的提示，希望听听读者对不同契约提案的看法。在过去的两年左右中，契约的设计空间迅速发展，从仅有两个提案（CTV和APO）发展到近十几个不同的提案，为冷存储方案或闪电网络等离线协议等现有用例提供了大幅度的优化。对于这个空间中的社区来说，评估他们应该支持还是不支持哪个提案是非常困难的。特别是对于支持或不支持任何特定提案的原因可能是不希望或认为它启用了危险的功能，或者是实现了相同功能的两个提案之间的效率差异。

我认为，虽然开发者和更技术的用户社区正在逐渐接近对什么是或不是可取的以及哪些提案能够更高效地实现特定用例的共识，但活跃用户的更大社区却更加不确定或犹豫不决。考虑到这一点，我将在这里分段回应第一个回复。

• 比特币无法解决美联储的问题
• “远离SBF审判，一个非常不同的Web3叙事正在展开”
• Web3游戏的最新动态：与Cointelegraph Accelerator、Animoca Brands、BGA、Metaera、Cipholio和Sandbox一起举办的游戏演示日

REARDEN

模板密钥的提案者Rearden通过Twitter发送了以下内容：

BIP119/CTV/OP_CHECKTEMPLATEVERIFY是最彻底探索、最合理推理、最适合激活的契约提案。它单独使比特币能够进行一系列的扩展优化（其中Ark就是一个例子）。CTV之所以成为比特币的一个明显的补充，是因为它与其他提议的变化完美地结合在一起，就像在OP_VAULT中所看到的那样。 CTV对于比特币来说是一个构建块，可能比CLTV或CSV更基础。

OP_VAULT还包括CTV之外的两个契约操作码：一个将花费限制为只能通过相同的taptree进行，并且只能修改所选叶子（OP_UNVAULT）；另一个将花费限制为特定输出脚本（地址）（OP_VAULT_RECOVER）。虽然这些是在OP_VAULT提案中引入的，但它们也被设计为可组合，并且可能比OP_VAULT实现了更广泛的自托管改进生态系统。

OP_VAULT自原始提案以来已经发生了很大变化，实际上在某些方面看起来完全不同，但实现的目标是相同的。首先，没有了OP_UNVAULT，取而代之的是一个单独的OP_VAULT_RECOVER操作码。其次，OP_VAULT现在完全在tapscript中完成。这意味着从保险库中支出的每个OP_VAULT限制，而不是作为UTXO中自己的裸脚本，现在都作为taptree路径进行。它需要很多数据值作为参数，但它最终要实现的三个限制是：用于替换要支出的taptree路径的描述新脚本的数据（作为第一个支出的输出），以及必须返回到保险库的金额（作为第二个支出的输出）。第一个输出的脚本，即设置从保险库中提取资金的脚本，必须与整个taptree完全相同，除了要支出的一个叶子节点（被替换）。这个新叶子节点使用CTV本身来承诺一个时间锁交易，限制提款最终将去哪里。除了在保险库树中存在的被支出的路径外，其他路径仍然存在于该输出中。其中包括使用OP_VAULT_RECOVER的路径，它只是指定了恢复冷存储路径，并且支出交易中的哪个输出必须与该脚本匹配。它还强制执行整个输入金额必须去到该输出。讨论中的第二个输出完全复制了要支出的taptree，并要求将定义的金额放回保险库。

这个重构版本的OP_VAULT不仅利用了CTV本身，以便可以在不需要不必要的低效率的情况下单独使用，而且使用taproot来实现OP_VAULT允许在保险库构建中更加灵活。不同的路径可以允许越来越少的重新入库，但例如使用更长的时间锁定。在先前的提案中，使用CTV而不是将其内置到OP_UNVAULT中，还为未来如果有其他替代CTV的方法填补保险库方案的角色打开了大门。

我认为Rearden完全正确，这两个提案都具有非常明确和明显的使用案例，几乎没有任何不利因素，而且每个提案的当前状态已经达到了它们之间没有不必要的冗余，并且彼此相辅相成的地步。

BIP118/APO/SIGHASH_ANYPREVOUT是减少运行闪电节点和看守塔负担问题的一种非常依赖路径的解决方案。它始于一个简单的想法，即让输入不承诺其prevout点；但是，如果没有新的密钥版本，就无法添加新的签名哈希标志，因此我们得到了一个新的密钥版本；如果仅跳过此输入的prevout，可能会导致验证过程中的二次散列工作，因此我们得到了暗示的ANYONECANPAY；由于taproot内部密钥，导致了较大的交易大小；可能等等。结果是一个变化，被销售为“只是添加了一个签名哈希标志”，但实际上添加了一个新的密钥版本，然后重用了大部分现有的签名哈希，并无意中通过预签名输出脚本添加了一种低效契约品牌。

我的“模板密钥”草案旨在通过退后一步并思考在需要新密钥版本时可以做些什么来解决APO的大部分依赖路径选择。模板密钥对签名哈希模式进行了全新的审视，并放弃了现有的模式，采用了更灵活的新模式集，特别是可以与签名操作码或CTV（大多数情况下）一起使用。我非常确定在模板密钥的设计中错过了一些重要的考虑，但我认为它的方向比APO更加正确。

尽管如此，我不会阻止社区努力激活APO；它并不邪恶，只是可以更好。

同样，我在这里基本上同意Rearden的观点。APO创建一个具有不同语义的新签名哈希标志，如果您只是尝试将其应用于所有内容，那么它是无法以向后兼容的方式实现的，因此只有新的密钥版本才能真正使用它。多年来已经进行了许多不同的微调和设计更改/认识，最终所有这些都针对了签名哈希标志的单个新用途：拥有一个可以重新附加到任何正确版本化的输入上的签名，使用相同的脚本并保持相同的价值金额。

如果我们要扩展签名哈希标志系统，除了APO之外还有更有用的事情可以做。我还没有深入研究过他的“模板密钥”提案，但在签名对于哪些输入和输出进行承诺或不承诺方面拥有更多灵活性的一个好处是，它可以更容易地在多方协议中稍后更改输出金额以增加费用。一些协议可以通过更多的签名哈希选项来实现这一点，而不需要每个人都协调进行操作。

最后，我认为APO绝对是一种期望的功能，但在我看来，还有余地来寻求更高效和/或更灵活的方式，以实现不仅仅是APO的目标。

另外两个问题：与你类似，我最初对契约（特别是递归契约）有一种直觉上的负面反应；但归根结底，比特币的每个“收款人”都可以选择他们的接收输出脚本（地址），并且如果他们愿意，可以选择永久性地以某种愚蠢的方式锁定它们。这已经是可能的，契约只是以新颖和创造性的方式使其成为可能，这种方式还能实现有用的/智能的功能。即使我们关心递归，目前唯一准备激活的提案是APO，对于APO可能实现递归和Spookchains的潜力已经受到了很多关注。然而，正如我在我的“模板密钥”草案中所说的那样，这些只是学术上的好奇；因为它们需要已删除密钥的可信设置，并且仍然只能在完全预映射的状态集合内部进行递归。

我目前对递归契约的唯一担忧不是政府黑名单或审查控制的潜力，而是通过引入太多复杂功能而扭曲整个系统激励的可能性。再次，我同意Rearden的观点。迄今为止，迄今公开发表的具体契约提案并没有提供足够的复杂性，以令人信服地打开任何严重的激励扭曲之门。

ANON

一个匿名用户在Telegram上发送了以下消息：

嗨，忍者，

几年前，当Jeremy提出OP_CTV激活时，比特币Twitter上的大多数声音联合起来喊着僵化的成语，总体上阻止了任何积极的对话进展。据我所知，对契约的负面情绪主要基于两个因素：担心大型监管机构限制未来的币花费，以及速审的使用。我从来没有真正理解第一个部分，因为契约本质上是自愿加入的，任何从契约中支出的行为都会解除对交易的前向限制。担心政府以某种方式强制并要求每个人加入契约并限制未来支付的情况似乎是毫无根据的，更不用说这种情况可以在一个巧妙的多签名方案中复制得更多或更少。至于速审的担忧，我稍微理解，但只是从元立场上理解，而不是特指OP_CTV本身的任何元素。

现在尘埃落定，你对昨天的契约否定者的恐惧有任何同情吗？他们的社会排斥是否有任何价值？为什么OP_CTV在技术共识方面取得如此高的水平，但在社会接受方面未能达到同样的水平？

祝好，

困惑的契约信徒

当然，在一定程度上，我理解。对于活跃的比特币用户来说，默认情况下对他们不完全理解的提案或变化持怀疑态度是非常健康的信号，无论是在其工作方式还是目的方面。我认为，当Jeremy讨论激活时，很多人的反应远远超越了这个范围，有很多人在明确解释并明确证明这些担忧是毫无根据之后，仍然恶意发声。然而，正如你所说，其中很多问题都涉及使用Speedy Trial作为激活机制。

直言不讳地说，我认为在很大程度上，这只是因为人们不喜欢Jeremy个人，或者至少是他在公开讨论CTV及其激活问题时的方式。这很可悲，绝对是不应该的，但我认为整个事件是一个案例，人们对信息本身并没有问题（如果他们理解了），只是对信息传递者有问题。

下周见，再见。

We will continue to update 算娘; if you have any questions or suggestions, please contact us!