2010年时的从业者如何看待十年后的BTC建设之路

作者：比特币播客 Block Digest联创Shinobi；编译：五铢，金色财经

本文是Shinobi写于十年前的文章，探讨了2020年时比特币是什么样的。

本系列文章的第一篇可点击查看《2010年时的从业者如何看待十年后的BTC生态？》

我们已经开始看到第二层潜力的种子从第一个十年的基础层原语中发展出来。闪电网络虽然仍受到一些相当大的限制，但确实开始蓬勃发展。这只是目前指定和部署的有限第一个版本。现在已经部署了各种类型的侧链：Liquid、RSK，甚至还有 Commerceblock 开发的与比特币绑定的代币链。这只是一个开始。

SCHNORR 和 TAPROT

不久之后，我们就有了 Schnorr 和 Taproot 的组合。从 Schnorr 的角度来看，这是一种批量验证签名方案，成本更低，也是优化比特币多重签名脚本构造的下一个重大飞跃。多重签名最初只是将所有公钥和多重签名脚本塞入交易输出中发送给它，并且必须将所有这些包含在输入中才能使用它。P2SH 通过包含多重签名的公钥和脚本的恒定长度哈希值来优化输出方面，为任何发送到多重签名地址的人节省费用，只为发送者增加成本。SegWit 可以说通过见证折扣使花费多重签名 UTXO 更便宜而进一步“优化”。Schnorr 将所有这些增量优化发挥到了极致。您将各个公钥组合成一个密钥，每个人都可以协作为其制作一个签名，然后检查一下。这为所有使用多重签名的技术（包括闪电网络 (Lightning) 和联合侧链等第二层）节省了大量成本，并且通过使所有这些多重签名 UTXO 与单签名 UTXO 无法区分，也带来了隐私优势。

现在，这并不能神奇地让一切都完全保密。闪电通道状态（交易）仍然需要单独的密钥路径，以便其惩罚交易对旧状态的提交做出反应。这意味着这些必须在创建指纹的输出脚本中。Taproot 通过其加密魔法解决了这个问题，允许您提交一个具有不同支出条件的 merkle 树，只需要使用的条件和 merkle 证明到 merkle 根即可支出，到看起来正常的 Schnorr 公钥。现在，您可以使用 taproot 隐藏该惩罚脚本路径。您可以使用 Taproot 隐藏任何条件脚本路径，隐藏在看起来非常正常的 Schnorr 密钥之下，该密钥允许所有参与者就某事达成一致并进行看起来非常正常的交易。

SIGHASH_ANYPREVOUTPUT

SIGHASH_ANYPREVOUTPUT（以前为 SIGHASH_NOINPUT）有望成为下一个新原语。它是新的公钥格式/sighash 标志升级。Sighash 标志指定签名将提交到交易的哪些部分。此功能的存在是为了让您可以执行诸如仅签署您的输入和输出之类的操作，但允许其他人将自己的输入和输出添加到交易中而不会使其无效。但目前，签名必须提交到来自确切交易的确切 UTXO。除其他外，SIGHASH_ANYPREVOUT 可以将签名提交到 UTXO 脚本，而不是实际的特定 UTXO。这允许一种新的方式（eltoo）来构建闪电通道状态，不需要惩罚密钥或处理旧状态，允许受骗方没收所有资金。相反，如果当前通道状态在双重支付竞争中失败，它可以简单地重新使用旧通道状态，从而保证每个人都能在链上获得他们当前的通道余额，而不是之前的过期余额。您只需在正确的位置重新使用相同的脚本并使用 SIGHASH_ANYPREVOUT 即可实现这一点。

这消除了许多风险，例如您丢失当前通道状态，导致因无意之失而使罚款交易扣留您的资金。它还可以实现更多功能。现在，我们可以拥有超过 2 个参与者的闪电通道，甚至可以在这些通道之上堆叠“子通道”。此外，SIGHASH_ANYPREVOUT 和 eltoo 可以创建 Statechains，这是一种联合通道构造，允许新参与者完全在链下进入和退出，并假设联盟不会与过去的参与者合谋欺骗任何人。这为我一直称之为“多方静态 UTXO 协议”的协议打开了很多潜力。

OP_CHECKTEMPLATEVERIFY

OP_CTV 是 Jeremy Rubin 提出的一项提案，旨在在比特币上实现一种非常基本的“契约”。契约是对使用一枚BTC的更复杂的限制，而不仅仅是某些密钥的签名。Rubin 的提案将实施的契约类型是“模板”。本质上，这允许 UTXO 的脚本要求支出交易创建特定的精确输出。因此，一旦使用 OP_CTV 创建了 UTXO，就会通过共识强制执行，即必须将 UTXO 花费到特定地址，金额在该 UTXO 的脚本中定义。您甚至可以将它们链接在一起，以便其中一个 UTXO 被迫再生成几个，然后这些 UTXO 又被迫生成几个，如此反复。

这在任何地方都具有广泛的普遍适用性。在高费用环境中，托管实体可以制作单个 UTXO，该实体 100% 按照共识规则保证其所有客户的资金最终都将由客户控制，即使他们目前无法立即访问这些资金。这与多方渠道（渠道工厂）具有很大的潜在协同作用，因为像这样进行的大规模“提款”也可以同时创建并用作渠道工厂。OP_CTV 可用于创建至少单向工作的支付渠道，而无需接收端参与或在线拥有密钥来接收付款（请记住，您可以将渠道堆叠在一起）。它甚至可以用于允许单个渠道一次处理更多 HTLC，方法是将它们捆绑在一起，使用与第一个托管提款示例相同的技巧。甚至可能为新类型的 coinjoin 创造一些潜力。

整合所有要素

假设上述所有提议都被采纳并纳入比特币，我真的认为，除了实际从事这些前沿工作的开发人员之外，人们甚至不知道使用这些原语将构建哪些类型的协议和服务。或者服务或协议之间没有明确分界线的奇怪事物。

它们将启用理论上参与者数量不受限制的多方渠道，这些渠道可以在基础渠道参与者的较小子组之上堆叠子渠道。可以在这些“渠道工厂”之上构建渠道，让人们无需在线拥有热钱包的密钥即可收款。这些多方渠道本身可以堆叠在联合渠道（状态链）之上，允许参与者在链上活动为零的情况下进入或退出！渠道“拼接”的构造将允许流动性在不同渠道之间相对无缝地移动，从而实现人们甚至还没有真正开始考虑的各种事情。

我在本节中的最后一句话是：这只是考虑了可以对我认为是比特币协议栈本身的直接组成部分的东西做些什么。如果你开始研究中心化托管服务，以及这些服务可以提供比特币的哪些子集，而不受监管或法律障碍的影响，那么你可以做更多的事情。