十年变通之路

Spiral 的时事通讯分为五个系列，涵盖从毛绒玩具到非常深奥的技术内容。不喜欢其中一个？跳过它，伙计。直接滑走就行。

通过订阅，你同意 Substack 的使用条款，并确认其信息收集通知和隐私政策。

十年的权宜之计

Bitcoin Core 的 Mempool 策略如何演变以支持 Lightning（以及其他 Layer 2），以及为什么花了将近十年才做好。

由 Spiral 的比特币巫师 @theinstagibbs 撰写

想象你正在比特币上构建一个 Layer 2 协议，其系统支持时间敏感型交易。如果这些交易在一定数量的区块内没有得到确认，就会有人赔钱。你围绕子支付父 (CPFP) 设计了系统，因此当费用意外飙升时，用户会附加一个高费用的子交易，将父交易拖入下一个区块。

不幸的是，你的交易对手可以先附加 他们自己的 子交易：一个巨大的、低费率的子交易，它符合最低中继费用（从而进入矿工的 Mempool），但近期内不会被开采。或者可能是一串垃圾费率的子交易。现在由于父交易已达到其后代限制，你无法附加自己的子交易了！你的时间敏感型交易被卡住了，而你对此无能为力。

这就是交易钉选 (Pinning)。在比特币的大部分历史中，对此都没有很好的对策。

在随后的十年中出现的解决方案是一系列的权宜之计：专门为修补最紧急的漏洞而设计的特殊案例、排除条款和拓扑限制。这些都不一定是工程上的失败。其中一些是必要的脚手架，在构建更原则性的解决方案时，保持了 Lightning 和其他协议的功能。然而，它们的局限性塑造了 L2 协议的设计方式，并且有几条规则注定要被扔进历史的垃圾堆。

这就是那十年的故事：为什么权宜之计是必要的，它们实际上做了什么，以及 Bitcoin Core 最终如何交付工具来替换它们。

订阅

第一幕：启发式时代

Bitcoin Core v0.12 的基础 (2015-2016)

要理解为什么最初存在后代限制，我们需要回到 2015 年底。

Bitcoin Core 的 Mempool 变得越来越复杂。为了允许在繁忙时期修剪 Mempool，开发人员引入了后代包追踪 (Descendant package tracking) (PR #6654)，让 Mempool 能够理解交易之间的关系，即哪些交易依赖于哪些交易。不久之后，开发人员将每个链的祖先和后代限制降低到 25 笔交易和 101 KB (PR #6771)。几个月后，祖先包和费率追踪到来 (PR #7594)，使矿工在为区块选择交易时能够考虑 CPFP。

这些限制是基于基本的计算约束。每当一笔交易进入或离开 Mempool 时，受影响的统计数据都需要更新。每当矿工构建一个区块时，都需要评估交易链。深链意味着更多的计算，而无限制的计算可能导致拒绝服务，但限制使问题变得可控。

大约在同一时间，选择性费用替代 (RBF) 落地 (PR #6871)。这在一定程度上是一种政治妥协，因为商家担心可替代的交易会引发欺诈，因此替代需要用户和钱包通过交易的 nSequence 字段进行明确的信号传递。被称为 BIP125 的一套替代规则要求新交易支付更高的总费用 以及 更高的费率，并禁止引入新的未确认父交易；这是一系列的启发式方法。

最后一条规则很有启发性。我们拒绝新的未确认父交易作为一种预防措施；我们根本无法判断新交易是否有可能在短期内被挖掘，同样地，我们也无法判断我们是否在浪费人们的中继带宽和 CPU。这种带有新依赖关系的替代是否真的改善了 Mempool？在不了解完整的交易图及其对采矿的影响的情况下，我们无法确定，所以我们将其作为预防措施予以拒绝。

链限制和 RBF 规则都源于同一个潜在问题：我们不知道如何高效地计算什么对矿工才是真正最好的。因此，我们施加了一些看似合理且能启用有用功能、而又不会明显恶化情况的约束和启发式方法。

这于 2016 年 2 月在 Bitcoin Core v0.12.0 中发布。Lightning 仍在酝酿中，支持它的各种共识变更正在进行中。

钉选变得真实 (2017-2018)

在背景中，OP_CHECKLOCKTIMEVERIFY、OP_CHECKSEQUENCEVERIFY 和 SegWit 在主网上激活。

Lightning Network 于 2018 年初在主网上线。期待已久的理论上的 L2 现在已投入运行。

钉选向量并非无人知晓，因为研究人员已经讨论了多年。但带有真金白银的实时系统迫使问题浮出水面。仅仅知道攻击是 可能 的是不够的；协议开发人员需要准确了解哪些攻击是 实际 的，以及在现有的 Mempool 策略下可以做些什么。

2018 年 11 月，我们自己的 Matt Corallo 在比特币开发邮件列表中发布了标题委婉的“用于合约应用中费率预测问题的 CPFP 排除条款”。实质内容很简单：Lightning 的承诺交易 (Commitment transactions) 可能会被钉选，即使不能解决所有问题，也需要一个快速修复方案。

攻击非常简单。Lightning 的承诺交易是共同拥有的；任何一方都可以广播。如果你的交易对手广播并立即附加了一树低费率的子交易，他们就可以耗尽后代限制。现在你无法附加自己的 CPFP。你的时间敏感型交易被卡在签署时的费率上，那可能是几周甚至几个月前。

邮件列表的讨论将问题系统化了。L2 协议实际上需要什么样的拓扑结构？我们可以通过策略变更来保护这些拓扑结构中的哪些子集？答案不是“所有这些”，而是“Lightning 使用的一种非常特定的形状”。

排除条款 (v0.19, 2019)

修复方案在 Bitcoin Core v0.19.0 中到来：“CPFP 排除条款 (CPFP carveout)”。

该规则的设计非常狭隘。如果一笔交易已经达到其后代限制，则允许再增加一个从原始父交易延伸出来的子交易，前提是该子交易很小（小于 10 kvB）且只有一个祖先（即被提升的交易）。这对 Lightning 来说已经足够了：即使你的对手通过大量后代链使限制饱和，你仍然可以附加一个小的 CPFP 交易。

一个有趣的史实：Corallo 最初的邮件列表帖子建议限制为 1 kvB。PR 实现的是 10 kvB。似乎没有人对这十倍的增加发表评论。

一个配套规则，单冲突 RBF 排除条款 (PR #16421)，解决了一个后续问题：如果攻击者的子交易本身可以通过 RBF 规则钉选你的排除条款子交易怎么办？糟糕！该修复允许在刚刚超尺寸的“多一个子交易”包限制下进行替代，但仅限于驱逐正好一笔交易时。

如果你深究这些排除条款，会感到有些不适。它们不是通用的原则，而是嵌入 Bitcoin Core Mempool 策略中的 Lightning 特定黑科技 (Hacks)。它们之所以奏效，是因为 Lightning 承诺交易具有已知的拓扑结构：一个父交易，有限的子交易，两名（且只有两名！）需要能够提升费用的参与者。改变这种拓扑结构，这些排除条款就帮不了你了。

但它们在某种程度上起作用了，只要你不去深究矿工在面对半强大的对手时如何能一致地获取这些交易。Lightning 找到了一条出路，即使这条路比任何人预想的都要窄。

第二幕：缩小问题 (2019-2024)

漫长的等待

排除条款或许争取了时间，但潜在的问题依然存在，且排除条款不适用于更通用的 UTXO 共享未来。

L2 开发者忍受着这些已知的局限。排除条款只对特定的双人、单父拓扑有帮助。其他的钉选向量依然存在。RBF 规则中的“禁止新的未确认父交易”意味着你无法通过添加一个高费用父交易来提升交易；你只能完全替换它或添加一个子交易。而根本性的矛盾依然存在：策略是启发式方法，因为我们无法计算出最优解。

邮件列表积累了各种提案。包中继 (Package relay) 可以原子地提交父交易和子交易，允许在转发时进行 CPFP，而不仅仅是在挖掘时。被称为“交易赞助商” (Transaction sponsors) 的软分叉允许第三方为任意交易附加费用。各种交易内省操作码可能让合约能够推理其费用背景。

大多数想法都停滞不前或被放弃了。根本的阻碍不是缺乏想法，而是 Mempool 的数据结构无法回答这些提案需要询问的问题。“这个包是否比它替换的更好？”听起来很简单。但对于任意交易图，高效地计算这一点却并非易事。

TRUC 洞察

如果我们无法计算任意拓扑结构的激励相容性，那么如果我们限制拓扑结构直到我们可以计算为止呢？

这就是在确认前受拓扑限制 (TRUC)，也称为 v3 交易 (BIP 431) 背后的见解。限制是严苛的：一笔 TRUC 交易最多只能有一个未确认的祖先和一个未确认的后代。子交易被限制在 1000 虚拟字节以内（讽刺的是，这正是最初 CPFP 排除条款提议的“多一个”规则）。

TRUC 处理计算问题的方式与排除条款不同。排除条款说：“我们无法解决通用情况，所以这里有一个针对 Lightning 交易结构的特殊例外。” TRUC 则说：“我们无法解决通用情况，所以让我们定义一种受限的拓扑结构，在其中我们 可以 解决它，从而支持尽可能多的 L2。”

在 TRUC 拓扑结构中，问题变得易于处理。这个子交易比现有的子交易更好吗？当各方只有一个子交易时，比较起来很容易。我们应该允许这次替代吗？交易图足够小，可以直接推理。

折衷方案是灵活性。TRUC 交易不能有复杂的祖先。但对于只需要“一笔承诺交易，可能是 0 费用，外加任何交易对手的一笔费用提升”的 L2 协议来说，这没问题。你放弃了通用性，换取了实际的安全保证，而不是基于启发式方法的希望。

订阅

基于受限拓扑构建 (v28, 2024)

以 TRUC 为基础，一系列互补功能在 Bitcoin Core v28 中落地。

1P1C 包中继 (PR #28970)：低于 Mempool 最低费率的父交易现在可以与其提升费用的子交易一起提交。这对交易会被原子地评估。这终于实现了 L2 开发者一直想要的模式：广播一个带有陈旧费率的承诺交易，附加一个提升费用的子交易，并将该包一起中继和挖掘。

兄弟驱逐 (PR #29306)：对于 TRUC 交易，一个新的子交易即使不双花共同的输入，也可以驱逐现有的兄弟交易。如果你的交易对手在承诺交易上附加了一个低费用的子交易，你的高费用子交易可以替换它，无论花费的是哪个输出。由 CPFP 排除条款解决的钉选向量现在在 TRUC 模型中得到了更清晰的处理。

付费至锚点 (P2A) (PR #30352)：一种标准化的任何人都可以花费的输出类型，使用 SegWit v1 见证程序（OP_1 <0x4e73>，地址 bc1pfeessrawgf）。与 Lightning 现有的需要签名或 16 个区块延迟的有密钥锚点输出不同，P2A 是无密钥且极简的。没有需要满足的脚本，只有一个空的见证数据。结合 TRUC 和 1P1C，这提供了一个清晰的费用提升模式：承诺交易包含一个 P2A 输出，任何需要提升它的人都会在 CPFP 子交易中花费该输出，从而在锚点开销上浪费更少的字节。特别是当交易对手的数量远大于 2 时，这非常有意义。

默认全量 RBF (PR #30493)：在这一点上几乎只是一个脚注。在选择性替代妥协达成八年后，默认设置切换到了全量 RBF (Full RBF)。政治斗争虽然激烈，但已缓慢解决：网络已经向前迈进，大多数算力已在其区块中接受它们。

临时粉尘 (v29, 2025)

一个悬而未决的问题：锚点输出应该是 0 值的粉尘 (Dust)。它们在经济上无法独立花费，存在仅是为了启用 CPFP。在正常策略下，粉尘输出是不被中继的。权宜之计是将锚点输出设置为粉尘阈值以上，但这在链上留下了没人真正想要的 UTXO，并耗尽了智能合约层的价值。

在 v29 中发布的临时粉尘 (Ephemeral dust) 解决了这个问题。如果一个粉尘输出在同一个包中被花费，交易就可以包含该输出。锚点的存在仅有一个目的：被费用提升子交易花费，然后它就消失了。UTXO 集中不会留下粉尘。

至此，TRUC 技术栈已完备：TRUC + 1P1C + P2A + 临时粉尘。L2 协议拥有了一条连贯的、有原则的费用提升路径，而不依赖于 L2 特定的排除条款。

TRUC 的限制是易处理性（以及更强大的抗钉选能力）的代价。任意拓扑和替代的通用问题仍未解决。

第三幕：正确计算 (v31, 2026)

集群 Mempool (Cluster Mempool)

多年来，“这次替代是否让 Mempool 变得更好？”这个问题一直无法得到高效回答。Mempool 追踪祖先-后代关系，但推理变更如何影响采矿收入所需的计算无法扩展。

集群 Mempool：在 Bitcoin Core v31 中发布。改变了这一点。集群 Mempool 使用完全不同的数据结构重新组织了 Mempool。

核心思想：将 Mempool 分组成 集群 (Clusters)，其中一个集群是一个 严格限制 (少于 64) 的交易连接组件集（任何两笔在 Mempool 中有关系的交易）。在每个集群内，维持一个最优的 线性化 (Linearization)，即交易的有效排序，如果按此顺序挖掘，可以最大限度地提高费用收入。一旦设定了这些线性化，节点的整个 Mempool 就实现了全排序。

这种结构使得棘手的问题变得可以回答。当一笔新交易到达时，计算其集群费率。当提出替代方案时，计算有无该替代方案时 Mempool 的样子。它更好吗？接受它。线性化告诉你挖掘优先级；比较线性化告诉你哪个 Mempool 状态更好。

技术细节非常详尽：线性化算法、处理集群拆分与合并、以及性能边界。对于感兴趣的人，Pieter Wuille 在 Delving into Bitcoin 上的帖子和集群 Mempool 追踪议题提供了深入的论述。对于这个故事来说，重要的是新结构启用了什么。

费率图表 (Feerate Diagram)

核心概念是 费率图表。可以将其视为代表 Mempool 采矿价值的曲线：在每个点上，你为多少累计大小收集了多少累计费用？一个拥有优质交易的 Mempool 具有陡峭上升的图表；一个充满低费率垃圾交易的 Mempool，其图表上升缓慢。

有了集群 Mempool，每一个提议的变更都可以根据单一标准进行评估：该替代方案是否产生了比被驱逐的方案更好的费率图表？

这就是“激励相容”的意思。如果一个替代方案 肯定 能给矿工带来更多收入，它就是好的。在拥有正确的工具之前，我们只是无法高效地进行计算比较。

被删除的内容

通过更精确的计算，几个替代和策略规则被移除了。

替代期间的“禁止新的未确认父交易”规则： 消失了。我们现在可以评估新的依赖关系是改善还是恶化了 Mempool。如果你的替代方案引入了新的父交易，但整体包对采矿更有利，它就会被接受。

CPFP 排除条款： 消失了。“后代限制处多出一个子交易”的特殊情况不再需要。包评估能妥善处理底层用例。

单冲突 RBF 排除条款： 消失了。启发式方法被直接计算取代。

包 RBF 的拓扑限制： 消失了。TRUC 的限制是旧 Mempool 下易处理性的代价。有了集群 Mempool，可以正确评估更复杂的拓扑结构。

这些启发式方法和限制完成了它们的使命，现在可以退役了。

遗留问题

集群 Mempool 解决了评估问题：给定一个提议的变更，我们现在可以计算它是否改善了 Mempool。但有两个相关问题仍然悬而未决。

通用情况下的包中继。 1P1C 之所以奏效，是因为拓扑简单：一个父交易，一个子交易，一起尝试。但更复杂的情况呢？如果一笔交易有三个未确认的父交易，我们应该把这四个一起评估吗？如果只有其中两个父交易对于该子交易的挖掘价值是必要的呢？

费率图表告诉我们给定的包是否改善了 Mempool。但它没有告诉我们，从一组对等节点发送的交易中，应该把哪些子集放在 一起 尝试。对于 1P1C，答案很明显：如果父交易低于浮动 Mempool 最低费用，请（再次）连同其子交易一起尝试。对于任意拓扑，这是一个尚未解决的发现问题。接收低费率交易以及未确认祖先和祖先后代的节点不知道哪些子集会构成最有吸引力的包，也不知道如何以抗带宽和 CPU DoS 的方式将其传达给另一个节点。

通用拓扑结构的抗钉选能力。 TRUC 的拓扑限制不仅仅是为了使评估变得容易处理；它们也是使抗钉选能力得以实现的原因。由于最多只有一个父交易和一个子交易，攻击者附加垃圾交易的空间有限。兄弟驱逐处理了明显的攻击。

对于任意拓扑结构，钉选仍然是一个问题。即使我们现在可以正确评估提议的替代是否更好，拥有共享交易访问权限的攻击者仍然可以附加使替代复杂化的后代交易。计算正确答案的能力并不能阻止对手在比特币费用方面增加计算成本。

对于需要强大抗钉选能力的协议，TRUC 仍然是答案。集群 Mempool 使通用情况变得 正确，因为改善 Mempool 的替代方案会被接受，但在对抗环境下对于时间敏感的交易者来说不一定 安全。拓扑限制不再是计算易处理性的要求，但对于安全性而言，它们可能仍然具有价值。

回顾

十年的权宜之计让 L2 协议得以生存。

排除条款是 Bitcoin Core Mempool 策略中令人不适的 Lightning 特定黑科技。但在更好的解决方案开发出来之前，它们在足够长的时间内运行得足够好。TRUC 技术栈将拓扑约束正式化，使问题变得易于处理，并为 L2 开发者提供了连贯的前进路径。而集群 Mempool 终于实现了数据结构的突破，让策略可以建立在实际的激励相容性而非启发式方法之上。

这种模式值得注意。有时你无法直接解决一个问题，你只有两个选择：约束问题直到它可以解决 (TRUC)，或者构建更好的工具直到你可以妥善解决它 (集群 Mempool)。Bitcoin Core 依次做了这两件事，结果是一个比以前更有原则、能力更强的系统。

对于 L2 开发者来说，实践经验很简单。如果你今天需要强大的抗钉选能力，请使用 TRUC。限制本身就是功能。而对于其他一切，无论钱包是否采用任何变更，你节点的 Mempool 仍然会变得更好。

订阅

时间线

参考文献

BIPs

• BIP 125 — 选择性全量费用替代信号

• BIP 431 — 在确认前受拓扑限制 (TRUC) 交易

邮件列表

• CPFP 排除条款提案 (2018) — Matt Corallo

Delving Bitcoin

• 集群 Mempool 介绍 — Suhas Daftuar

• 集群 Mempool 线性化 — Pieter Wuille

Pull Requests

• #6654 — Mempool 包追踪

• #6771 — 降低默认交易链限制

• #6871 — 选择性 RBF

• #7594 — 祖先包追踪

• #15681 — CPFP 排除条款

• #16421 — 单冲突 RBF 排除条款

• #28970 — 1P1C 包中继

• #29306 — 兄弟驱逐

• #29496 — TRUC 交易

• #30352 — 付费至锚点

• #30493 — 默认全量 RBF

• #33629 — 集群 Mempool

• #30239 — 临时粉尘

• 原文链接： spiralbtc.substack.com/p...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～