链上钱包大致实现了交易对交易的 1:1 映射：用户执行的每一笔经济交易，通常都需要对应一笔区块链交易。虽然聚合、coinjoin、剪切支付等技术对此有一些影响，但这一说法大体上是正确的。

闪电网络实现了交易对交易的多对一映射：闪电网络的“魔力”在于，一个有效的闪电通道可以进行无限多的经济交易，而这个通道本身只与一个未花费交易输出（UTXO）绑定。本质上，我们已经通过压缩“时间”维度（即交易）实现了显著的扩容。

然而，即便是为每个用户创建一个 UTXO，或许仍然不足。因此，有很多提案旨在通过让多个用户以自我主权的方式共享单个 UTXO，以实现更大的扩容。这再一次通过将另一个扩容的“空间”维度——用户——压缩到一个 UTXO 中。

我们的目标是对所有这些提案进行概述，找出它们共享的技术模式，分析它们需要哪些新的操作码及其他软分叉升级来实现功能，并创建一个比较表来展示各部分如何协同工作。在此过程中，我们还将定义什么是 L2 协议，了解闪电网络目前具备的扩展能力，并探讨为实现这一切，我们需要对内存池（mempool）做出哪些改进。

感谢 Fulgur Ventures 赞助了这项研究。他们对这篇文章的内容没有任何编辑控制权，也没有在发布前进行审查。

也感谢 Daniela Brozzoni、Sarah Cox 和其他人在发布前的审查工作。

定义

什么是 Layer 2？

“Layer 2” 通常被广泛定义，甚至像 Liquid 这样的类银行实体也能被定义为 Layer 2。然而，本文将采用严格定义：Layer 2 (L2) 是一个以比特币为计价单位的系统，其目的是允许比特币 (BTC) 在不增加链上交易次数的情况下，与其他方进行更多的交易。符合以下条件之一：

1. 在考虑系统内的惩罚和成本时，系统中的任何人都无法通过窃取资金获利。系统外的成本和惩罚（如声誉损失、法律后果等）不在我们的定义范围内。
2. （首选）资金的真实所有者可以在不依赖任何第三方合作的情况下，单方面提取他们的资金，扣除交易费用。

第一个选项是必要的，因为我们希望 L2 系统能够处理小到无法在链上表示的金额和交易。例如，在闪电网络中，哈希时间锁定合约（HTLCs）的金额可能小到无法在链上表示。在这种情况下，HTLC 的价值被加入到承诺交易的交易费用中。虽然一个闪电节点可以通过在适当时机关闭通道来“窃取”一个微尘 HTLC，但这样做的成本高于 HTLC 本身的价值，使得窃取无利可图。

尽管如此，单方面提款始终是我们首要的设计目标。

基于此定义，像闪电网络这样的系统被视为 L2 系统。然而，像 Liquid、Cashu 和 Fedimint 这样的系统并不属于 L2，因为它们的资金控制权在其他方手中。客户端验证方案（如 RGB）也不被视为 L2，因为它们无法无信任地直接交易 BTC。最后，Statechains 也不符合要求，因为如果不遵循协议，Statechain 实体可以窃取资金。

什么是 Covenants？

为什么更具扩展性的 L2 系统需要它们？

在比特币脚本中，covenants 是一种机制，预先限制了 txout（交易输出）如何被花费，使得花费该 txout 的交易形式被预定义或以某种方式受到限制，而不仅仅依赖于签名。L2 系统在多个用户共享 UTXO 时需要 covenants，因为它们需要通过某种方式约束 UTXO 的使用规则和激励机制，以实现 L2 协议的运行。

递归 Covenants

递归 covenant 是指其规则可以无限递归地应用于支出交易的子 UTXO，限制其花费方式。递归 covenants 长期以来被认为具有潜在问题，因为它们可能会无限期地束缚资金，至少在没有第三方（如政府）的许可下是如此。

目标

目前，闪电网络是最先进的 Layer 2 系统，但它仍然有一些限制，具体如下：

扩展性 - 闪电网络目前要求每个终端用户至少拥有一个 UTXO。

流动性 - 闪电网络要求资金锁定在通道中。

交互性 - 闪电网络要求接收方在线才能无信任地接收付款。

在评估 Layer 2 系统时，我们的目标是改进这些关键限制，理想情况下不引入新的限制。

闪电网络的扩展性限制

“每个终端用户一个 UTXO”在实践中意味着什么？由于闪电网络通道可以无限期地运行，一种看法是思考每年可以创建多少个新的通道。创建一个 taproot 输出的边际成本为 43 vB；如果通道创建的成本分摊到多通道上，并且在单个交易中创建多个通道，其他交易开销可以变得微不足道，从而每年可以为新用户打开大量通道。

例如，假设 90% 的区块容量用于创建新的 taproot 闪电通道：

据估计，全球大约有一半人口拥有智能手机，约43亿人。因此，实际上每年可以为相当大比例的全球人口建立闪电网络通道，使他们能够使用该通道进行交易。

然而，通道并不是永久性的。用户有时会想要更换钱包、增加或减少通道容量等。改变通道容量的最有效方法是通过“拼接”（splicing），这在 Phoenix Wallet 中已经实现。拼接与通道开启类似，也可以通过摊销方式来提高效率，即多个拼接操作共享一个交易，从而减少添加和移除资金所需的输入和输出数量。

因此，假设使用 musig 签名方案，每个用户的拼接所需的区块空间增量为 43vB 的 taproot 输出加上 57.5vB 的 taproot 关键路径支出，总计 100.5vB。如果我们再次假设区块空间的 90% 用于此操作，我们可以计算出：

最后需要注意的是，用户在切换闪电网络通道至新钱包时，可以通过一笔交易完成。具体而言，用户可以选择信任新钱包，在资金发送至承诺地址后由其签署承诺交易，或者双方钱包实现支持合作关闭并开启新通道。

当然，除了闪电网络通道外，比特币还有其他竞争性的使用场景，而这会如何影响交易费用率（fee-rate）目前难以预测。不过，这些数据为我们提供了一个大致的范围，表明使用当前技术，至少在技术上可以支持数亿自我主权的闪电网络用户。

Layer 2 概述

根据我们对 Layer 2 系统的定义，比特币开发社区讨论的主要设计模式有两种：

通道（Channels）

虚拟 UTXO（Virtual UTXOs）

通道设计模式

在通道设计模式中，闪电网络是最典型的例子。该协议通过在各方之间交换预签名交易来运行，这些交易可以被挖掘，但通常不在“正常路径”（happy path）中。这些预签名交易将一个 UTXO 在各方之间分割；交易通过不断改变这个分割的余额，并创建新的预签名交易来实现。由于存在多个可能有效的交易花费同一个 UTXO，因此需要某种激励机制来确保最终被挖掘的是正确的交易。

虚拟 UTXO（V-UTXO）设计模式

在虚拟 UTXO 设计模式中，以 Ark 为最突出的例子。V-UTXO 通过 covenants（契约）或多方协议创建，允许生成可以将 V-UTXO 资金提取到链上的交易，但这通常不在“正常路径”中。在这一点上，V-UTXO 与通道类似。但是，与通道不同，V-UTXO 方案通过花费 V-UTXO 本身来完成交易，这在概念上是在单一的预签名交易中进行的。

“正常路径”设计模式

“正常路径”是指各方通过一个“全体同意”的脚本路径（如 N-of-N 多签）来完成交易。Taproot 专为此设计，允许关键路径使用 musig 来实现 N-of-N 多签。在各方同意的情况下，正常路径可以高效且隐私地花费资金。

有趣的是，由于虚拟 UTXO 在许多方面都是“真实的”，因此很容易在虚拟 UTXO 上构建通道。只需创建虚拟 UTXO，如果被挖掘，将导致为通道创建所需的 UTXO。因此，虚拟 UTXO 方案实际上是比通道略低一层的设计。

闪电网络

当前已在生产环境中实施的闪电网络，主要基于 BOLTs 标准。闪电网络结合了多种技术，包括闪电通道、HTLC（哈希时间锁定合约）、P2P 路由网络、洋葱路由和发票标准等。值得注意的是，闪电网络不是一个共识系统，因此“闪电系统”的不同元素不需要被所有用户以完全相同的方式采用。在本文中，当我们提到“闪电网络”时，我们将广义地使用这个术语，包括当前广泛使用的闪电协议中可以预见的升级。

如前所述，闪电网络的一个关键特性是其终端用户的扩展性受限，这是由于每个用户至少需要一个 UTXO。不过，对于闪电网络的“核心”路由元素——用于路由大多数交易的公共闪电节点——这些扩展性限制并不是主要问题，因为即使终端用户远多于路由节点，闪电网络仍然能够正常运作。每个用于支付路由的公共通道可以轻松支持大量每秒交易。因此，许多未来的 Layer 2 系统也预期参与到闪电网络中。我们可以看到，现有的非 Layer 2 系统（如 Cashu）也大量依赖闪电网络才能真正发挥作用：Cashu 的主要用途可能就是发送和接收闪电支付。

非交互式通道

这一设计通过使用 OP_CTV 减少了交互需求，从而改进了闪电通道。然而，由于它未能改善“每个用户一个 UTXO”的扩展性限制，因此我们不作进一步讨论。

通道工厂

通道工厂的构建方式是由多个参与方协商一个 n-of-n 多签地址，并生成一笔交易来花费该多签地址，从而创建 n 个 UTXO，将资金分割开来。这些 UTXO 反过来用于支付通道。这些通道可以像直接在链上开设的通道一样使用，具有相同的安全性，因为如果通道状态需要上链，分割交易可以被挖掘。这种方式可以节省关闭通道时的链上空间，因为理论上 n 个参与方可以协同关闭所有 nn 通道。

由于通道工厂协商的是可被挖掘的 UTXO，但在正常路径中并不期望被挖掘，它们是 V-UTXO 的一种非常原始的例子。通道工厂本身并不需要任何软分叉就可以实现。然而，简单的通道工厂设计可能不适用于大量参与方，因为协调所需的复杂性会影响扩展性。为了解决这一问题，类似 OP_Evict 或 CTV（通过 txout 树）的契约提案旨在允许更精细的结果，其中可以强制将个别参与方上链，而不需要所有人同时上链。

Eltoo/LN-Symmetry

由于 “Eltoo” 这个名称容易引起混淆，我们将改用更新后的名称 LN-Symmetry。

Poon-Dryja 通道通过惩罚发布错误状态的行为，鼓励正确的状态上链，而 LN-Symmetry 则允许通过额外的交易来更新错误状态。这简化了闪电网络通道，去除了与惩罚相关的复杂性。然而，在不受信任的场景中，这可能是一种劣势，因为惩罚机制在一定程度上能够抑制欺诈行为。

LN-Symmetry 需要通过软分叉启用 SIGHASH_ANYPREVOUT，这允许状态交易在更新时重新花费其他状态交易。

LN-Symmetry 本身并没有提供相较于传统闪电通道的扩展性改进，但其支持者认为它可以使通道工厂（channel factories）等机制更容易实现。

Ark

Ark 采用了一种全新的交易扩展方法：完全可转让的虚拟 UTXOs (V-UTXOs)，这些 V-UTXOs 可以在链下通过原子交易进行合并和拆分。在 Ark 中，一个中心协调者，即 Ark 服务提供商 (ASP)，为用户提供具有限定生命周期的 V-UTXOs，例如 4 周。这些周期称为 轮次 (rounds)。V-UTXOs 通过某种机制（如 CTV）创建的池 txouts 生成，每轮对应一个池 txout，使一个链上 txout 能够承诺一个 V-UTXOs 树。Ark 的扩展性优势在于轮次的到期：在轮次结束时，池 txout 解锁，允许 ASP 通过一个带有单一签名的小型交易来单方面花费它。由于轮次到期时间，V-UTXOs 本身在池 txouts 到期时也会失效：拥有 V-UTXO 的用户必须在池 txout 到期前花费 V-UTXO，或将其上链（单方面提款）。

为了在各方之间交易 V-UTXOs，Ark 协调者共同签署了花费一个或多个 V-UTXO 的交易，只有在不同轮次中创建一个或多个新的 V-UTXO 时，这些交易才有效。结合一些精心设计的超时机制（详见 Ark 文档），这种依赖关系使得花费 V-UTXO 是无信任的：除非新的 V-UTXO 在另一个池交易中创建，否则无法在链上认领 V-UTXO。虽然实现这种依赖关系的方式有多种选择，但具体细节对于本文并不重要。

值得注意的是，一个给定的 ASP 同时会有许多不同的活跃轮次。为了允许现有轮次中的资金被转移，新轮次会不断被创建。然而，现有轮次会与新轮次重叠，因为它们通常会在新轮次和新池 txouts 创建之后才过期。

Ark 经济学

当一个 V-UTXO 被花费时，ASP（Ark 服务提供商）必须在新的轮次中提供等量的 BTC 来生成一个新的池 txout。但 ASP 不能立即回收已花费的 V-UTXO 的价值，直到该轮次到期。因此，V-UTXO 交易涉及时间价值成本，因为 ASP 需要提供流动性。

具体来说，这个成本在 V-UTXO 被花费时产生。在 V-UTXO 未被花费之前，它代表了一个潜在的可以上链的 UTXO，用户可以单方面提取资金，用户拥有这些资金的所有权。然而，为了花费 V-UTXO，ASP 必须创建一个新的池 txout，使用从其他来源获得的资金，而在此期间，已花费的 V-UTXO 中的资金直到到期时间才可供 ASP 使用。

因此，花费 V-UTXO 相当于短期贷款，ASP 需要借入资金来覆盖从现在到轮次到期之间的时间间隔。这意味着花费 V-UTXO 的流动性成本会随着 V-UTXO 的老化和到期时间的接近而下降，理论上在轮次到期时流动性成本会降至零。

需要注意的是，花费 V-UTXO 的成本与所花费的 V-UTXO 的总规模有关，而不是支付给接收方的金额。这意味着，专门用于直接交易 V-UTXO 的钱包（与管理一个 V-UTXO 用于其他目的的情况不同，如基于 V-UTXO 的闪电网络通道）需要在如何将资金拆分为 V-UTXO 上进行权衡。单一 V-UTXO 最小化了单方面提款的成本，但最大化了基于流动性的交易费用；而将资金拆分为多个 V-UTXO 则相反。这与链上比特币或闪电交易的经济模型完全不同。

流动性成本是多少？

以当前闪电钱包 Phoenix 为例，该钱包为保留 1 年的通道流动性收取 1% 的费用；在最糟糕的情况下，Phoenix 需要将其资金锁定 1 年。然而，这假设流动性未被使用。实际上，Phoenix 的资金成本可能更高，且假设客户平均在不到 1 年的时间内使用其预留的流动性。此外，Phoenix 还通过交易手续费赚钱，可能会对通道流动性进行补贴。最后，Phoenix 也可能未实现盈利！

另一个参考值是美国国债利率。当前，3 个月期国债的年利率约为 5%。由于美元的通货膨胀可能导致该利率被高估，我们可以假设 BTC 计价资金的流动性成本为每年 3%，以此作为分析的基础。

如果 Ark 的轮次间隔为 4 周，这意味着交易开始时的流动性成本为

，并最终逐渐下降至零。假设用户在轮次到期前两周将资金转移至新轮次，那么用户大约每年支付 1.5% 的流动性成本来实现对其资金的自主管理。另一方面，如果用户等到最后一刻才行动，成本几乎可以降为零，但面临错过到期时间的风险。

用户可能不会认为这是一个微不足道的成本。并且这一成本假设了通过将交易费用和其他成本分摊到大量参与者上，使每轮的固定成本微不足道。

如果固定成本并不小呢？

假设一个 ASP 有 1000 名用户，平均每小时创建一个池 txout。4 周内，这意味着需要 672 笔链上交易。也就是说，ASP 的用户仅仅为了持有他们的资金，总共需要支付几乎与用户数量相同的交易费用。在这种情况下，可能所有用户自己开设闪电网络通道会更便宜，尽管 ASP 要求他们等待一个小时的确认时间。

Ark 的启动难题

对于一个拥有少量用户的新 ASP 来说，面临的两难境地是：要么 ASP 轮次发生得很少，用户必须等待很长时间才能汇集足够的 V-UTXOs 以实现有效的扩展和交易费用降低；要么 ASP 的池交易发生得很频繁，但每个用户支付的交易费用也很高。正如我们在上一部分所示，需要大量用户来分摊频繁轮次和池 txout 的费用。

由于轮次会到期，这个问题是持续存在的，甚至比闪电通道面临的情况更糟糕：至少闪电通道可以无限期地保持有用，允许通道现在开设并在几个月内逐步摊销其成本。其次，由于轮次到期，创建支持这些轮次的新 txout 的时间灵活性较小：如果一两周内费用很高，池 txout 即将到期的用户别无选择，只能（集体）支付高额费用来维持他们对资金的托管。而在闪电通道中，用户可以灵活地选择何时真正开设通道。

尽管 Ark 的作者最初设想了一个非常乐观的场景，即每隔几秒就有新轮次，但在启动阶段，若交易费用没有补贴，Ark 可能需要等待多个小时才能确认一笔交易的用例才能真正实现。

交互性

非托管的 Ark 是一个高度交互式的协议：由于 V-UTXO 有到期时间，用户必须在到期前与 ASP 交互，否则 ASP 可能会选择夺取用户的资金。这种交互无法外包处理：尽管闪电网络有瞭望塔（watchtowers）来防止对手方在你离线时试图欺诈，但 Ark 的持币者必须使用自己的私钥在到期前刷新资金，保持对资金的控制。Ark 最接近瞭望塔的机制可能是签署允许瞭望塔在临近到期时单方面将资金提取到链上的交易，但这会产生显著的交易费用。

如果 V-UTXO 的所有者离线会发生什么？在轮次到期后，ASP 需要回收资金以继续支持后续轮次的流动性。如果 V-UTXO 所有者离线，将 V-UTXO 上链会产生高昂的交易成本，因为 ASP 需要在 V-UTXO 树的多个层次回收资金。虽然 ASP 可以在新轮次中重新创建未花费的 V-UTXO，但这对 V-UTXO 所有者来说并不是无信任的，因为他们无法在没有从 ASP 获取数据的情况下花费这些 V-UTXO。此外，ASP 可能会记录未花费的 V-UTXO 作为托管余额，甚至可能有没收资金的政策。

考虑到在 Ark 中自我托管的非小成本，我怀疑许多用户可能会选择那些将资金自动转入新轮次并接受每轮结束时潜在欺诈风险的 ASP。这比用户主动提早转移资金以确保在某些情况下（例如他们的手机无法及时打开）资金安全要便宜得多。

先进的 Ark

通过更先进的契约（covenants），有可能减少 Ark 的流动性需求，特别是在轮次期间部分流动性被耗尽的情况下。例如，假设一个轮次的池 txout 中 50% 的 V-UTXO 价值已被花费，如果 ASP 能够仅兑换该轮次池 txout 的这部分价值，他们可以更快回收流动性，从而降低总体流动性成本。尽管目前还没有具体的提案来实现这一点，但通过足够先进的契约技术，这应该是可行的，很可能需要通过某种脚本复兴软分叉，一次性添加许多有用的操作码。

同样，通过足够先进的契约，整个 txout 树结构可能被某种循环提款方案所取代，从而提供空间节省。这一技术在其他方案中也可能具有潜在的用途，我们将在后续章节中详细讨论。

轮次结束时的托管问题也是一个可以通过先进契约解决的例子：特别是零知识证明（ZK-proof）契约，可以强制 ASP 在下一个轮次中重新创建所有未花费的 V-UTXO，从而避免托管在轮次结束时回归到 ASP。虽然这可能无法实现完全的无信任，因为用户可能仍然需要从 ASP 获取一些数据才能在新轮次中花费他们的 V-UTXO，但这可以防止 ASP 因离线用户的欺诈行为获得经济利益。

单方面提款中的链上费用支付

类似于闪电网络，链上费用支付的经济学以及扣除费用后的 V-UTXO 实际价值决定了 Ark 使用是否符合我们对 L2 的定义，即通过单方面提款实现资金安全，或防止 ASP 因欺诈获利。我们将在讨论 txout 树设计模式时进一步探讨这一点。

Validity Rollups

Validity Rollups 是一类类似侧链的设计，通常使用各种零知识（ZK）证明技术来强制执行链上的规则。与其他侧链形式的关键区别在于 ZK 证明技术：如果 ZK 证明方案有效，交易的有效性可以通过数学来保证，而无需信任第三方。在这种场景中，“零知识”本身并不是必需的，证明中“泄露”一些信息也没有问题。只是大多数这种类型的数学证明方案恰好是零知识证明。

从比特币的角度来看，Validity Rollup 方案需要一个 契约（covenant），因为我们希望创建的 UTXO 只能在符合方案规则时被花费。这并不一定是一个去中心化的过程，事实上，许多 Validity Rollup 方案完全是中心化的：rollup 证明只是验证中心化的交易排序器是否遵循了一定的规则。

关于使用什么样的契约，目前零知识证明技术仍然非常新，频繁有新的进展。因此，极不可能看到比特币中直接添加任何验证特定 ZK 证明方案的操作码。相反，通常认为这些特定方案会通过更通用的操作码（特别是 OP_CAT）来通过脚本验证 ZK 证明。例如，StarkWare 正在推动 OP_CAT 的采用。

由于 Validity Rollups 是一个极具潜力的话题，并且有很多项目带有过多的炒作而实质内容较少，因此我们不会进一步讨论这一点，仅指出哪些操作码可能使这种设计模式可行。

BitVM

粗略地说，BitVM 是一种在两方之间构建闪电网络通道的方法，通道的规则通过零知识证明来强制执行。由于它在现有的比特币上实现时不需要契约，且无法直接用于创建超越“每个用户一个 UTXO”限制的 Layer 2 系统，我们不会进一步讨论它。

分层通道（Hierarchical Channels）

分层通道旨在使通道容量的调整变得快速且廉价：“分层通道在通道容量上做的事情，就像闪电网络在比特币上做的一样”。然而，它仍然无法突破“每个用户一个 UTXO”的基本限制。此外，它也不需要对比特币协议做任何修改，因此我们不会进一步讨论这一点。其支持者应该继续实施它们的方案——他们不需要我们的许可。

CoinPool

CoinPool 允许多个用户共享一个 UTXO、在不同用户之间转移资金，并单方面提款。CoinPool 的论文提案要求三个新的软分叉特性：SIGHASH_ANYPREVOUT、SIGHASH_GROUP（允许签名仅适用于特定的 UTXO），以及 OP_MerkleSub（用于验证从 Merkle 树中移除特定分支）。最后一项功能也可以通过 OP_CAT 实现。

目前，CoinPool 的开发似乎已经停滞，最后一次提交到其规范网站的更新是在两年前。

Enigma Network

尽管有人要求我们讨论 Enigma Network，但该提案似乎缺乏明确的文档说明。Bitfinex 的博客文章做了很多声明，而 MIT 页面却是空白的。由于博客文章并未清楚地说明其方案的具体内容，因此我们不会进一步讨论它。

内存池（Mempool）考虑

当前比特币 Core 中的内存池策略并不完全适用于 Layer 2 系统。以下我们将讨论一些 L2 系统面临的主要挑战及潜在的改进方案。

交易钉住（Transaction Pinning）

交易钉住是一种经济性攻击，指的是在某些情况下，由于之前广播的冲突交易未被挖掘，导致期望的交易难以被矿工确认。这是一种经济性攻击，因为在真实的交易钉住情境中，存在一笔矿工挖掘后会获利的交易，但由于钉住交易的存在，该交易无法及时被挖掘。

一个最简单的交易钉住例子是，在没有启用全局替换（full-RBF，replace-by-fee）的情况下，交易替换功能可以被关闭。因此，可以存在一笔低费用率且不被替换的交易，虽然它不会被挖掘，但也无法被替换。基本上，100% 的算力已经通过启用 full-RBF 解决了这一问题，截至目前，下一版本的比特币 Core 将默认启用 full-RBF（这一改进花了 11 年才完成！）。

BIP-125 规则 #3 钉住

目前，剩下的唯一相关且尚未在比特币 Core 中解决的钉住问题是 BIP-125 规则 #3。BIP-125 规则 #3 规定：

替换交易必须支付更高的绝对费用（而不仅仅是费用率），以替换所有被取代交易的总费用。

这个规则可以被利用来广播一笔大额、低费用率的钉住交易，花费与多方协议相关的输出（或者是一组交易）。由于这笔交易的费用率很低，它不会及时被挖掘，甚至可能永远不会被挖掘。但因为它的总费用很高，用另一笔交易替换它在经济上并不可行。

解决方案：基于费用率的替换（Replace-by-Fee-Rate）

规则 #3 钉住问题可以通过基于费用率的替换（replace-by-fee-rate, RBFR）相对简单地解决，该解决方案适用于所有情况。不幸的是，比特币 Core 是否会在近期采用 RBFR 还不明确，因为开发团队已经投入了大量精力在一个较差的部分解决方案上，即 TRUC/V3 交易。

通过实现 RBFR，可以更有效地解决多方协议中的交易钉住问题，从而提高 L2 系统的交易灵活性和安全性。

费用支付：RBF、CPFP、SIGHASH_ANYONECANPAY、锚点输出（Anchors）和赞助支付

由于费用率难以预测，在预签名交易中可靠且经济地支付费用变得困难。最理想的费用支付方式是使用 Replace-by-Fee (RBF)，从初始低估的费用开始，然后根据需要用更高费用版本替换交易，直到交易被挖掘。例如，OpenTimestamps 日历软件多年来一直以这种方式使用 RBF，而 LND 在 v0.18 中加入了支持截止时间的 RBF 功能。

RBF：费用支付的黄金标准

RBF 是费用支付的黄金标准，因为它在几乎所有情况下都是最有效的。替换交易不需要额外的输入或输出，只要最初正确估算了费用，它的区块空间使用是最优的。

效率很重要，因为费用支付中的低效操作可能使链外费用支付成为大矿工的盈利来源。小型去中心化矿工由于无法从链外费用支付中获利，很难在交易确认中竞争。此外，链外费用支付还可能带来反洗钱（AML）和了解你的客户（KYC）问题。目前，大多数链外费用支付系统都要求某种形式的 AML/KYC 认证（例如 mempool.space 加速器），尽管它接受闪电网络支付，不需要账号。

要在预签名交易中直接使用 RBF，你需要预先签署覆盖潜在费用范围的多个费用变体。虽然在许多情况下，这种变体的数量较少且可行，但目前生产中的闪电协议（以及其他提议的协议）通常选择使用 Child-Pays-For-Parent (CPFP)，通常通过锚点输出（anchor outputs）来实现。

锚点输出与 CPFP

锚点输出的原理是为交易添加一个或多个最小值或零值的输出，目的是通过 CPFP 机制在次级交易中花费这些输出来支付费用。这种方式在像闪电网络这样的小型链上交易协议中是非常低效的，因为它几乎使 LN 承诺交易的总大小增加了一倍。然而，对于使用更大交易的协议（例如使用 OP_CAT 实现的契约），这种问题的影响较小。

锚点输出的另一个问题是需要保留额外的 UTXO 以支付费用。在典型的“客户端”应用程序中，这可能是一个显著的负担，因为没有锚点输出时，通常只需要维持一个 UTXO。实际上，一些现有的面向消费者的闪电钱包在高费用环境中，可能会因为无法支付费用而容易被通道另一端的对手方盗取。

SIGHASH_ANYONECANPAY 和 SIGHASH_SINGLE

SIGHASH_ANYONECANPAY 可以在某些情况下用于费用支付，它允许在签名交易中添加额外的输入；而 SIGHASH_SINGLE 则允许添加输出。闪电网络在 HTLC 交易中使用了这种方式。当前，这种做法可能容易受到交易钉住攻击的影响，如果处理不当，攻击者可以通过添加大量输入或输出，制造高费用/低费用率的钉住交易。RBFR 可以解决这个问题，而 TRUC/V3 交易中的方法无法解决该问题。这种费用支付方式虽然没有 RBF 高效，但可以比锚点输出更高效。

费用赞助系统

最后，已经有各种软分叉提案提出添加一种费用赞助系统（fee sponsorship）到比特币协议中。这种系统允许交易声明对其他交易的依赖，赞助交易（sponsor transaction）只有在受赞助交易（sponsored transaction）被挖掘时才会被挖掘（很可能在同一个区块中）。这种方式可能比传统的 CPFP 更高效，因为赞助交易可以用远少于一个输入大小的 vbytes 来声明这种依赖关系。

替换循环攻击（Replacement Cycling Attack）

替换循环攻击利用交易替换机制，试图长时间替换掉一个期望的 Layer 2 交易，最终使一个不期望的交易得以被挖掘。这种攻击方式与交易钉住（Transaction Pinning）类似，目的是阻止一个诚实交易被挖掘，以便让一个不诚实的交易得以挖掘。不同的是，替换循环攻击不能偶然发生，而是攻击者有意为之。

经典示例：HTLC

一个典型的替换循环攻击场景是针对 Hashed-Time-Locked-Contract (HTLC)。通常情况下，我们认为 HTLC 是通过揭示预映像（preimage）来花费交易，或通过超时机制进行花费。然而，由于比特币脚本的限制，HTLC 实际上允许交易始终通过揭示预映像来花费，并且在超时后，交易可以通过超时机制额外地进行花费。

替换循环攻击利用这一点，在超时后使用预映像替换试图通过超时机制花费 HTLC 输出的交易，而受害者并未获知该预映像。成功的替换循环攻击可以使这种情况持续足够长的时间，直到其他通道中的 HTLC 过期。

替换循环的挑战

要成功实施替换循环攻击并获利，面临的一个主要挑战是每次替换都会产生费用。一个具有截止时间感知的闪电网络实现会尝试支付越来越高的费用，试图在下一个 HTLC 输出过期之前花费已过期的 HTLC 输出。此外，一旦替换周期结束，任何人都可以通过重新广播被替换的交易来击败攻击。

与交易钉住类似，替换循环攻击也是一种经济性攻击，针对的是矿工。在每次替换周期结束时，存在一笔已从内存池中移除的有效交易，矿工若仍保留这笔交易则可以挖掘并获利。

软分叉功能与设计模式

在概述了依赖契约的 L2 系统及内存池挑战后，我们将总结这些系统所共享的一些重要的软分叉特性（主要是新操作码）和设计模式。对于软分叉提案，我们还将讨论部署这些提案时面临的技术风险和挑战。

OP_Expire

OP_Expire 被提出作为一种解决替换循环攻击的简单方法，通过从源头解决问题：HTLC 同时可以通过两种不同的方式花费。在 L2 系统中，任何使用类似 HTLC 机制的场景，以及可能的其他应用场景，都会涉及这个问题。OP_Expire 允许某笔交易输出在某个时间点之后无法被花费，使得 HTLC 的花费条件变为真正的互斥选择（exclusive-OR），而不是“程序员的 OR”（允许多个条件同时成立）。

一个实际的 OP_Expire 软分叉大概由两个特性组成，类似于 OP_CheckLockTimeVerify 和 OP_CheckSequenceVerify 的双重结构：

1. 一个交易的到期高度字段，可能会在 Taproot 附件 中实现。
2. 一个 OP_Expire 操作码，用于检查到期高度是否至少设定为所需高度。

尽管 OP_Expire 本身几乎不算是一个契约（covenant），但它对于许多依赖契约的 L2 系统可能会非常有用。不过，它的实用性或许不足以单独部署，因为替换循环攻击也可以通过重新广播交易来缓解。

部署 OP_Expire 的挑战

一个明显的挑战是与 重组（reorgs） 相关：从中本聪开始，比特币技术社区一直试图确保比特币共识协议的设计使得在深度重组之后，之前已被挖掘的交易可以重新被包含在新的区块中。这一设计原则是为了避免出现大规模已确认的币突然变得永久无效的情况——在共识失败导致的大规模重组中，这种情况可能会让依赖这些币的人损失惨重。OP_Expire 的使用可能会与这一原则产生冲突，因此部署时需要特别小心。

OP_Expire 与重组（Reorg）

在发生大规模重组的情况下，使用 OP_Expire 的交易可能会因为达到其到期高度而变得无法被挖掘。为此，OP_Expire 提案建议将使用到期交易的输出类似于 coinbase 交易对待，使其在约 100 个区块内不可花费，以缓解这个问题。

交易到期 面临的一个主要障碍是围绕是否接受这一权衡进行的共识达成，甚至要决定这一机制是否真正必要。使用 OP_Expire 的交易类型已经涉及较长的超时时间，用户的资金在此期间被冻结，进一步增加超时时间对用户来说并不理想。此外，双花（double-spends）一直是重组后使币失效的另一种方式。随着 RBF 的更多使用以及 keyless anchor 输出的提议，交易到期是否会显著改变现状仍存在疑问。

SIGHASH_ANYPREVOUT

BIP-118 提出了两种新的签名哈希模式，允许签名不依赖于具体的 UTXO。SIGHASH_ANYPREVOUT 基本上是对 scriptPubKey 的承诺，而 SIGHASH_ANYPREVOUTANYSCRIPT 则允许任何脚本。最初，这个提案是为了支持 LN-Symmetry，以避免对每个可能的通道状态单独签署。

SIGHASH_ANYPREVOUT 还可能在预签名 RBF 费用率变体中发挥作用，因为签名不再依赖于特定的交易 ID，这避免了费用率变体的组合爆炸。然而，当前的 BIP-118 提案并未针对这一用例，且可能与其不兼容，因为 SIGHASH_ANYPREVOUT 也承诺了 UTXO 的具体数值。

早期对 SIGHASH_ANYPREVOUT 的反对意见主要来自于钱包可能在不适当的情况下使用它，导致问题。因为一旦发布了 SIGHASH_ANYPREVOUT 签名，它可以花费任何带有相同 script 的 txout。如果意外创建了具有相同 script 的第二个输出，可能发生重放攻击。然而，随着钱包和 Layer 2 实现中其他潜在问题的增多，这一担忧似乎已经淡化。

目前，技术社区对实施 BIP-118 持相对积极的态度。不过，正如我们在讨论 LN-Symmetry 时提到的，关于其主要用例——LN-Symmetry——是否合理，仍存在争论。

OP_CheckTemplateVerify (CTV)

OP_CheckTemplateVerify (CTV) 是第一个特定于契约的操作码提案，它的目标是创建一个非常具体、受限的契约操作码，专注于执行一项功能：以特定方式哈希花费交易，而不承诺输入的 UTXO，并将结果摘要与堆栈顶部的元素进行比对。这使得可以提前约束花费交易，但不会导致真正的递归契约限制。

CTV 的设计非常简洁，专注于为复杂的 Layer 2 方案提供基础支持，但避免了引入过多的复杂性。它可能是 Layer 2 系统中更广泛使用的契约操作码的基础之一。

为什么 CTV 不支持递归契约？

OP_CheckTemplateVerify (CTV) 之所以无法支持递归契约，是因为它依赖于哈希函数。CTV 检查的是花费交易与模板哈希的匹配，而没有办法创建一个包含自身哈希的 CTV 模板。这意味着 CTV 只能对静态的模板进行验证，无法嵌套或者递归地进行自我引用。

不过，这未必是一个实际的限制。通过链式哈希函数，你可以在现代计算机上在几秒钟内生成深度达到数千万的 CTV 模板哈希链。通过使用相对的 nSequence 时间锁（timelocks） 和比特币的有限区块大小，实际要执行完如此长的链条可能需要数千年。

CTV 提案的当前状态

根据 BIP-119 的提案，当前的 CTV 只有一种哈希模式，即 DefaultCheckTemplateVerifyHash，它本质上对花费交易的每个方面都进行承诺。在实际操作中，这意味着在许多情况下，唯一可用的费用支付机制是 Child-Pays-For-Parent (CPFP)。如前所述，CPFP 的一个潜在问题是，当 CTV 交易较小时，链外费用支付可能会成为一种非小的成本节省。

尽管如此，CTV 由于其相对简单性和广泛的应用场景，得到了技术社区最广泛的支持。

LNHANCE 提案

有一个提案建议将 CTV 与两个其他操作码 OP_CheckSigFromStack(Verify) 和 OP_InternalKey 结合使用。然而，截止目前，与该提案相关的文档和提案（BIP）尚不足以详细讨论其优点或缺点。这些 BIP 并未提供这些操作码在实际场景中的使用理由或具体的脚本示例。

因此，虽然该提案的作者可能有很好的理由支持这一想法，但他们需要更清楚地解释并合理地证明其可行性。因此，我们在这里不做进一步讨论。

OP_TXHASH

类似于 CTV，OP_TXHASH 通过哈希花费交易的数据来实现非递归契约功能。然而，与 CTV 不同，TXHASH 提案提供了一个 “字段选择器” 机制，允许灵活地控制花费交易的具体约束方式。这种灵活性实现了两个主要目标：

1. 允许向交易添加费用而不会破坏多交易协议。
2. 支持多用户协议，在这些协议中，用户只约束自己的输入和输出。

OP_TXHASH 的主要问题是字段选择器机制增加了相当大的复杂性，使得审查和测试相比于更简单的 CTV 提案更具挑战性。目前，关于字段选择器机制的具体好处和使用方式，设计分析还不充分。因此，我们暂时不对其进行进一步讨论。

OP_CAT 操作码

OP_CAT 是一个连接操作符，它将栈顶的两个元素连接起来，并将结果重新推入栈中。比特币最初启用了 OP_CAT，但 中本聪 在 2010 年悄悄地移除了它，可能是因为早期的实现容易受到 拒绝服务（DoS）攻击 的影响，原因是连接后的脚本元素大小没有限制。考虑以下脚本：

DUP CAT DUP CAT...

在没有元素大小限制的情况下，每次 DUP CAT 迭代都会将栈顶元素的大小加倍，最终耗尽所有可用的内存。

OP_CAT 的用途

连接操作对于实现多种契约（covenants）足够有用，甚至包括递归契约。可以通过以下步骤实现：

1. 使用一个或多个 OP_CAT（和任何契约相关的逻辑）将一个部分交易（不含见证数据）组装到栈中。
2. 验证栈中的交易是否与花费交易相匹配。

令人惊讶的是，通过滥用 Schnorr 签名 的数学特性，能够通过精心构建的签名使用 OP_CheckSig 来完成第二步。然而，更可能的情况是，OP_CAT 软分叉会与 OP_CheckSigFromStack 结合使用，从而允许通过验证栈上的签名是否为交易的有效签名来完成第二步，然后重用该签名通过 OP_CheckSig 验证花费交易是否匹配。

不需要见证数据

一个关键点在于，契约只需要验证交易的操作——即其输入和输出——而不需要验证实际使其有效的见证数据。因此，交易仅需在不含见证数据的情况下组装即可。

结合脚本大小限制，OP_CAT 和 OP_CheckSigFromStack 的组合足以构建多种类型的契约，包括递归契约。与更高效的解决方案（如 CTV）相比，使用 OP_CAT 的成本更高，但差异比预期的要小。

大致来说，使用 OP_CAT 实现此功能需要将花费交易的非见证部分通过见证数据放入栈中。对于 CTV 的典型用例，如 txout 树，花费交易不会有见证数据。由于见证空间的折扣为 75%，这将使子交易的有效交易费用只增加约 25%。考虑到其功能性，这并不算差！

OP_CAT 是否过于强大？

OP_CAT 的部署面临的最大政治和技术障碍之一在于，它的强大能力可能引发许多不可预见的使用场景。一旦 OP_CAT 被启用，就很难撤销其影响。其广泛应用可能会带来一些无法预测的后果，这些后果可能对比特币生态系统产生深远影响。

STARK 验证的潜力

一个典型的例子是，OP_CAT 被认为足够支持在比特币脚本中实现合理高效且安全的 STARK（可扩展透明知识论证）验证。STARK 能够证明非常通用的命题，如果能够高效地在比特币上实现 STARK，将带来巨大的影响，超越了 L2 系统的范围。它将允许在比特币上构建许多不同的系统。然而，反对 OP_CAT 的一个有力论据是，这些用例整体上可能对比特币用户并不利。

MEV 与 MEVil 的风险

矿工可提取价值（MEV） 是另一个关键潜在问题，特别是由 Matt Corallo 所称的“邪恶的 MEV”（MEVil）。简而言之，MEVil 指的是大型矿工/矿池可以通过采用复杂的交易挖掘策略来提取额外的价值，而不仅仅是最大化总费用。这些策略对小型矿工/矿池来说是不可行的。OP_CAT 带来的复杂金融工具的潜在使用场景非常广泛，使得很难排除 MEVil 的风险。

比特币上已经出现了一些 MEVil 的实例，比如 代币拍卖协议 造成的中心化风险。幸运的是，通过全局替换（Full-RBF）的采用，这个特定问题得到了缓解。

其他有害的 OP_CAT 用例

除了 MEVil，OP_CAT 还可能带来其他具体的、有害的使用场景。例如，Drivechains 提案已经在多个场合受到审查，并且被广泛认为对比特币有害。相信可以通过 OP_CAT 实现 Drivechain。此外，像 Taproot Assets 这样的代币提案也是潜在的风险。尽管一般情况下无法完全阻止它们通过客户端验证实现，但有些提案试图通过 OP_CAT 实现更具吸引力的代币协议，这不仅可能消耗更多的区块空间，还可能对合法的比特币交易形成竞争，导致出价上升。

这些用例还可能带来法律问题，特别是代币协议经常被用于金融欺诈。例如，证券型代币的使用涉及到合规和法律风险，而通过 OP_CAT 实现这些代币可能使其更容易在比特币网络上运行，从而增加了比特币的法律风险。

增量哈希（Incremental Hashing）

对于契约（covenants），OP_CAT 主要用于连接数据并对其进行哈希。另一种实现相同目标的方法是使用某种 增量哈希操作码，它通过接收 SHA256 中间状态（midstate）并继续对新数据进行哈希计算。SHA256 本身在 64 字节块上运行，因此有许多不同的设计可能用于增量哈希操作码。

设计考量

一个重要的设计决策是是否将实际的中间状态字节以某种标准形式暴露在栈上，或者用一种新的不可见类型表示其中间状态，从而无法直接操控其字节值。SHA256 的初始化向量（initialization vector, IV）是固定的，尚不清楚允许任意中间状态或初始化向量是否会影响 SHA256 的密码学特性。

由于增量哈希可以完成 OP_CAT 所做的事情，只是更加高效，它也面临着与 OP_CAT 类似的关于功能过强的担忧。

脚本复兴（Script Revival）

OP_CAT 是中本聪禁用的 15 个操作码之一。除了恢复 OP_CAT，Rusty Russell 提议通过重新启用大多数被禁用的操作码，以及增加 DoS 限制，基本上恢复比特币脚本到“中本聪的初衷”。此外，可能会引入 OP_CheckSigFromStack。

尽管 OP_CAT 本身可以使（递归）契约成为可能，但全面的“脚本复兴”会使更复杂的契约变得可能，并且更容易实现。例如，可以想象一个契约脚本使用算术操作码来确保交易输出的总价值符合某种预期的属性。

然而，脚本复兴引发了与 OP_CAT 类似的关于功能过强的担忧，甚至更多。

Simplicity

类似于脚本复兴，Simplicity 也与 Layer 2 和契约相关，使其几乎可以实现任何操作。与脚本复兴不同，Simplicity 通过引入基于九个基本操作符（组合子）的全新编程语言到比特币脚本系统。

在实践中，Simplicity 看似“简单”，实则并不简单。它的基本组合子过于低级，连基本操作如加法都需要从头开始实现，导致原始 Simplicity 代码极为冗长。因此，实际使用 Simplicity 时会依赖一套代码替代系统，类似于库函数调用，称为 jets。这带来了实际和政治上的问题：如何决定实现哪些 jets？大多数 jets 可能会像其他操作码一样用 C++ 实现，并且每个新 jet 都需要软分叉。

OP_FancyTreeManipulationStuff

还有一系列相对专门的操作码被提议用于 树操作，以更高效地进行依赖契约的 Layer 2 提案。例如，Coinpools 提议了 TAPLEAF_UPDATE_VERIFY 和 OP_MERKLESUB，用于操作 Taproot 树，MATT 提案则提出了 OP_CheckContractVerify，主要用于验证 Merkle 树的某些声明。

这些提案总体上都是针对特定用例的，它们使某一类 Layer 2 系统成为可能，同时避免了不必要的副作用。它们的优势在于效率——相对于使用 OP_CAT 这样的通用操作码，专用操作码能使用更少的区块空间。然而，它们的劣势在于增加了脚本系统的复杂性，而这些复杂性可能只适用于少数用例。

如果比特币采用了 Simplicity 脚本系统，同样的动态也会发生。Simplicity 中操作码的等价物是为常用模式添加 jet。实现专门操作（如树操作）的 jets，其优缺点与为特定用例添加复杂操作码类似。

资金池（Fund Pools）

所有尝试让多个用户共享一个 UTXO 的 Layer 2 系统，都可以被视为某种 多用户资金池（fund pool），用户持有某种 提款权。通常，这种系统还会包括一种机制，允许用户向资金池中添加资金（不仅仅是预分配资金来创建资金池）。

资金池的状态变化

要使资金池有用，它必须与某种“共享数据状态”相关联：txout 的价值如何在用户之间分配？如果资金池随着时间的推移而演变，该状态也必须发生变化，因为资金会被添加或移除。由于我们构建在比特币之上，向资金池中添加或移除资金必然涉及花费资金池控制的 UTXO。

比特币的共识系统本质上基于状态变化的验证：交易通过见证证明对 UTXO 集合状态的更改是有效的，工作量证明（PoW）则帮助我们在哪些交易是正确的上达成共识。这意味着，资金池本身也将基于状态变化的验证：我们需要向每一个比特币节点证明，资金池的规则在每次状态变化时都得到了遵守。

去信任的资金池

另一个信任最小化的 Layer 2 资金池关键点是，当资金池的状态发生变化时，系统必须公开足够的数据，以便参与资金池的用户能够提取他们的资金。如果我们无法做到这一点，系统将无法在没有第三方合作的情况下提供单方面提款的功能。

许多基于 Rollup 的方案在这里失效了：它们容易受到 数据可用性问题 的影响，如果第三方协调器下线，用户将无法恢复其资金，因为他们无法获得构建有效资金恢复交易所需的数据。

资金池的数据结构

在这些约束下，资金池的数据结构不可避免地是某种树形结构，具体来说是某种 Merkle 树。这是因为树几乎是计算机科学中唯一可扩展的数据结构，而采用 Merkle 化是进行加密承诺的唯一合理方式。此外，树的更新必然会发布到比特币区块链上，因为这是所有 L2 用户共享的唯一发布媒介，也是我们可以强制用户发布以移动资金的唯一媒介。由于契约的实施需要验证树的部分，以确保契约规则得到遵守，树结构显得尤为重要。

比特币脚本与交易中的应用

1. 预签名交易（Individual Pre-Signed Transactions）

这是树的退化情况，只有一个叶节点。资金池的状态只能变化一次。例如，标准的闪电网络通道就属于这种情况，通道一旦打开，只能关闭。当通道关闭时发布的数据是交易本身，这足以让通道中的对手方从区块链数据中获知交易 ID，并通过花费这笔交易来恢复他们的资金。

此类情况只需要最基本的“契约”：预签名交易。

2. Txout 树（Txout Trees）

资金池更复杂的设计模式是 txout 树，例如 Ark 就是一个典型的例子。在这种情况下，资金池可以通过花费根 UTXO，使用简单的契约（如预签名交易或 OP_CheckTemplateVerify（CTV））将该 UTXO 拆分成越来越小的部分，直到叶节点达到可以由合法所有者花费的状态。

txout 树的目的是为用户提供恢复其资金的选项，但这些选项是有代价的：与通过单笔交易拆分 UTXO 并将其返还给所有者相比，txout 树总是更昂贵。每一层树结构都增加了创建该层所需的 txout 和 txin 字节成本。

Txout 树的用例

Ark 是一个很好的例子：我们不希望链上的单个 V-UTXO 赎回要求将每个 V-UTXO 都上链。通过使用树结构，赎回可以将树拆分为更小的部分，直到需要的 V-UTXO 上链为止。

类似于预签名交易的情况，发布的信息是交易本身，这使得其他用户的钱包在需要时知道如何花费他们的资金。

Txout 树 在共享 UTXO 的 L2 系统中提供了有趣的规模经济。对于包含 n 个 V-UTXO 的资金池来说，将第一个 V-UTXO 上链的成本大约是单笔交易成本的 log2(n) 倍，因为需要在链上处理 log2(n) 层的拆分交易。然而，一旦第一个 V-UTXO 被上链，随后 V-UTXO 的赎回成本会降低，因为中间交易的费用已经由其他用户支付。

规模经济的限制

在理想情况下，整个树的节点总数为 2n，因此将所有 V-UTXO 上链的总成本只会比单笔交易略高一些，展示出令人惊讶的高效性。然而，如果资金池的规模足够大，可能会对整个区块空间的总需求产生重大影响。区块空间是一个供需系统，需求过高时费用将上涨。在极端情况下，可能会创建如此庞大而复杂的 txout 树，以至于实际上无法将树中的每一个 V-UTXO 赎回上链。

费用支付问题

一个未解的问题是，谁支付费用，以及如何支付？一种明显的解决方案是使用 无密钥锚点输出（keyless anchor outputs）在叶节点交易中，允许想让叶节点交易上链的任何人通过 CPFP（Child Pays for Parent）支付费用。在某些用例中，V-UTXO 本身可以在创建后立即花费，这样也可以通过 CPFP 机制添加费用。

使用 RBF（Replace-by-Fee）来支付费用比较复杂，尤其是涉及权限管理：显然的费用来源是 V-UTXO 的价值，但如何确保只有所有者能够签署更高费用的交易？在许多情况下，要做到这一点比使用无密钥锚点输出更复杂。如果 V-UTXO 本身不能立即花费，这将给用户钱包的设计带来严重挑战，尤其是当钱包没有 UTXO 来执行 CPFP 时。

激励机制与潜在攻击

在设计 txout 树系统时，还需仔细考虑费用支付的激励机制。例如，在 Ark 类似的系统中，如果某些 V-UTXO 赎回上链的成本太高，协调者可能会拒绝离线用户的链下赎回请求，并通过在超时后将所有 V-UTXO 的价值合并为单个 UTXO 来获利。这样一种情况会导致该系统无法满足 L2 系统的基本要求，尤其是对于小额 V-UTXO 的用户。

基于余额的方案

相比于简单的 txout 树，基于余额的方案 可以更复杂。它将资金池视为一个不断变化的余额，允许添加和移除资金。这需要一个复杂的状态机，还需要一个共享数据库，因为目标是让多个所有者共享一个 UTXO。为了提高扩展性，必须尽量减少将所有权数据写入链上。

这些需求自然会引导我们使用类似 Merkle 树 的数据结构，例如 Merkle 和树。操控这种数据结构需要类似 OP_CAT 的操作码，某种 零知识证明（ZKP） 验证操作码，或者专门的树操作操作码。

可扩展性的限制

即使使用最先进的数学技术，例如假设我们有一个只需 32 字节的 OP_ZKP 来证明任意命题，我们仍然无法打破 log(n) 级别的扩展性限制。为什么？即便 ZK 证明可以证明 Merkle 化数据结构的操作遵循 L2 系统规则，它也无法提供下一用户进行状态更新所需的数据。这样，虽然可能有一个用户能够实现无条件提款，但其他用户无法继续操作。

相比之下，如果通过契约脚本将 Merkle 树的修改部分（例如 Merkle 树中的兄弟摘要）发布，下一用户将获得足够的数据来更新他们对系统状态的理解，从而也能实现无条件提款。

将 Txout 树与余额方案结合

基于余额的方案和 txout 树 可以结合使用。如果正在操控的数据结构是 txout 树，资金可以通过花费输出并添加新资金的方式加入到 txout 树中，契约脚本可以验证资金的确已加入。同样，资金可以通过 txout 树的常规机制移除。高级 Ark 就是这种结合方案的一个例子。

故障数据率

L2通过在对抗性场景中增加交互性要求来实现扩展。在几乎所有情况下，这意味着协议中的诚实方需要在截止日期之前将交易上链；如果未能在截止日期前完成，资金可能会被盗。 \
所有去中心化（和中心化）区块链的最大区块容量都受到技术限制。在比特币中，最大区块大小使得比特币几乎始终在接近100%的容量下运行。由于比特币挖矿是通过竞拍系统进行的，将区块空间拍卖给出价最高的人，因此实际上，随着需求的增加和减少，最低交易费率也随之上下波动。

费用率始终是L2经济和故障模式的一个重要因素。例如，在闪电网络中，”dust-sized”（尘埃大小的）HTLCs（哈希时间锁合约）由于金额过小，无法通过链上赎回盈利，因此使用了与较大HTLC不同的安全模型。虽然闪电网络协议尚未正确实现这一点，但理论上，这一阈值应根据费用率的波动动态调整，理想情况下，应该允许一方根据费用率的高低决定HTLC是否在给定的承诺交易中存在。

已有多种攻击方案被提出，旨在通过故意触发这种情况攻击闪电网络，比如“洪水与掠夺”攻击和“大规模退出攻击”。由于比特币区块链的容量是所有使用场景共享的，不同L2系统之间的攻击也是可能的：例如，通过在Ark中触发大规模退出从闪电通道中获利。 \
共享UTXO（未花费交易输出）的L2由于多个用户共享，因此在故障期间对区块空间的最坏需求可能会更高。截至撰写本文时，尚未在闪电网络中看到大规模的故障，即大量通道需要同时关闭的情况。有人认为，在进一步推动UTXO共享方案之前，应该首先通过闪电网络的每用户1个UTXO扩展方式获得更多的实际操作经验。

其次，在广泛采用新的UTXO共享方案之前，应对区块空间高需求期间攻击的潜在盈利性进行仔细研究。例如，在像Ark这样的系统中，ASP（应用服务提供商）可以使用比其他方更少的区块空间赎回资金，因此有可能故意触发高费率并抓取那些无法通过单方面赎回而盈利的资金，这种情况可能是一种盈利性欺诈，违反了我们对真正L2系统的要求。

共识清理

中本聪在最初的比特币协议中做错了很多事情，特别是脚本的DoS攻击、时间扭曲攻击以及Merkle树的问题。此前，已经通过软分叉修复了其他一些共识漏洞，例如评估基于时间的nLockTime时切换为与过去中位时间对比、（试图）修复重复txid问题等。

最近的一次软分叉——Taproot的部署过程相对具有争议，实际部署花费了很长时间。主张首先进行一次共识清理软分叉的论点是，在启用任何新操作码或L2新特性之前，我们可以了解更广泛的社区在实施这种相对无争议、对所有人都有利的软分叉时的意愿。

潜在的软分叉

未来的路径是什么？在这里，我们将列出所有主要的第二层方案（L2）以及为使这些L2方案成功而有用（U）或必要（R）的软分叉。如上所述，OP_CAT（以及其扩展功能，包括OP_CAT的Script Revival）可以模拟列表中所有其他软分叉——除了OP_Expire和Fee Sponsorship。因此，当某个项目的需求更有效地通过其他软分叉直接满足时，我们将不再包括OP_CAT。

我们还将忽略所有提议的默克尔树操作码。这些操作码都过于小众、特定于用例，在目前的情况下，它们被广泛采用的可能性不大。在这些操作码有用的情况下，通过OP_CAT和/或Script Revival实现它们的效果更有可能被采纳。

CTV（CheckTemplateVerify）是这里的明显赢家，其次是SIGHASH_ANYPREVOUT（OP_Expire通过提供替代循环修复对很多项目有用，但并非必需）。CTV获胜的原因是，许多事情都可以符合“确保支付交易与此模板匹配”的设计模式；即使是OP_CAT构造也可以高效地利用CTV。

与OP_CAT不同，CTV似乎不会带来超出某些情况下鼓励带外支付费用的意外后果。这并不理想，但目前还没有人提出一个广泛支持的替代方案。

我个人的建议是：首先进行一次共识清理软分叉，然后实施CTV。

声明：

1. 本文转载自[petertodd]，转发原标题《基于软分叉和 Covenant 的 Layer 2 解决方案评析》，版权所有原作者[petertodd]。若对本次转载有异议，请联系Gate Learn团队，他们会及时处理。

2. 免责声明：本文所表达的观点和意见仅代表作者个人观点，不构成任何投资建议。

3. Gate Learn 团队将文章翻译成其他语言。除非另有说明，否则禁止复制、分发或抄袭翻译文章。