为什么 BIP-110 无法阻止 Alkanes

在比特币政治中有一个反复出现的幻想：认为“正确”的软分叉终将让元协议消失。BIP-110，这个最新的“减少数据”提案，就是这一幻想的当前版本。它无法对付 alkanes，而且值得精确地说明为什么，因为原因是结构性的，而非巧妙的。

BIP-110 实际提出了什么

BIP-110 是一次针对承载数据的见证脚本的中继/共识收紧。在其当前形态下，它做了两件事：

1. 在花费中禁止脚本流程控制：OP_IF、OP_NOTIF 以及其余条件族在见证/tapscript 执行中变为非标准（并且，在临时软分叉下，变为无效）。
2. **限制单个 push 的大小：**每个数据 push 被限制为 ≤ 256 字节。

对任何看过铭文的人来说，其目标都是显而易见的。ord 风格的封装，以及直到现在的 alkanes 部署封装，都是如下形式的见证脚本：

OP_FALSE OP_IF "BIN" <chunk_0> <chunk_1> ... OP_ENDIF

这种构造正是由 BIP-110 所移除的那两样东西所定义的：它把负载藏在一个从不执行的 OP_IF 之后，并依赖大量的数据 push。杀死流程控制并缩小 push，经典封装在新规则下就变得无法被挖出。纸面上看，这是“把任意数据挡在链外”阵营的一场胜利。

问题：审查需要一个模式

任何数据过滤规则实质上都是一个模式匹配器。BIP-110 并没有、也无法禁止“数据”。它禁止的是一个形状：带有大 push 的 OP_IF … OP_ENDIF 铭文封装。一旦负载不再具有那种形状，规则就无从下手。

alkanes-rs 的 kungfuflex/bip110 分支正好演示了这一点。它引入了一种新的部署封装，承载相同的经过 gzip 压缩的合约字节码，但将其包裹在一个与普通 Lightning 风格 HTLC 无法区分的结构中，因此按构造就是 BIP-110 合规的。

哈希锁封装

负载不再嵌入铭文封装，而是嵌入到一个形状像哈希时间锁合约的 Taproot 脚本路径叶子中。压缩后的 WASM 被切分为 ≤ 256 字节的块，每个块经过 SHA-256 处理，这些哈希值成为一连串哈希锁门：

OP_SHA256 <sha256(chunk_0)> OP_EQUALVERIFY
OP_SHA256 <sha256(chunk_1)> OP_EQUALVERIFY
...
<reveal_key> OP_CHECKSIG

这些块本身作为见证栈元素（即“原像”）被提供，正如一个 Lightning 节点为了领取 HTLC 而揭示原像那样。Taproot 内部密钥是 BIP-341 的 NUMS 点，因此密钥路径可被证明不可花费，脚本叶子是唯一的花费方式，这是纯粹为承载脚本而存在的承诺的标准技巧。

再读一遍那个叶子，注意它不是什么：

• **没有 OP_IF / OP_NOTIF。**只有 OP_SHA256、OP_EQUALVERIFY 和 OP_CHECKSIG。该分支甚至附带一个 hashlock_is_bip110_clean 测试，断言该叶子不包含任何被禁止的操作码。
• **没有超过 256 字节的 push。**负载切块被固定为 HASHLOCK_MAX_ELEMENT_SIZE = 256，且该测试断言每个见证元素都在限额之内。
• **没有协议标签。**旧封装用一个字面上的 "BIN" 标记来宣告自己。哈希锁封装什么都不宣告。唯一的标记是重组负载最前面的两个 gzip 魔术字节（0x1f 0x8b），而在你把原像拼接并解压之前，它们都是不可见的。

索引器通过从叶子中读取有序的哈希、对每个见证元素做哈希以构建哈希 → 原像的映射、并按门的顺序重组，来恢复合约。恢复过程与顺序无关，并忽略签名、叶子和控制块。如果重组后的字节并不以 gzip 魔术字节开头，它就被简单地当作它看上去的样子——一个真正的 HTLC——并被跳过。

为什么这实际上无法审查

这是关键所在，而它不是一个漏洞，而是 BIP-110 前提中的一个范畴错误。

哈希锁花费是比特币上最关键的脚本模板之一。它是 Lightning 通道、潜艇互换、跨链原子互换和 discreet log contracts 背后的原子原语。以这种方式构建的 alkanes 部署交易，其形状逐字节都与一笔常规 Lightning HTLC 的领取相同。没有任何字段、操作码、标签或 push 大小特征能把“某人领取一笔付款”与“某人部署一个合约”区分开来。

因此过滤器的作者们面临一个真正的两难：

• 禁止该模式，你就禁止了 HTLC，也就是说，你破坏了 Lightning、互换以及网络上每一个哈希锁合约。这在政治和经济上根本行不通；它造成的损害将远超它试图阻止的数据。
• 不禁止该模式，那么 alkanes 就毫发无损地通行，因为它就是那个模式。

中间不存在能抓住其一而放过其二的阈值，因为二者是同一个对象。这就是“搭乘一个类闪电容器”的含义：负载在网络自身最本质、最受守护的脚本模板中穿行。你无法在不击毁载具的情况下审查乘客。

结论

BIP-110 对它所做的事情并没有错；它错在它所能达成的目标上。它移除了一种可识别的把数据放进见证的方式。它对可编程见证区块链的一个结构性属性——数据可用性——毫无作为，反而给了元协议一个强烈的动机去不再可被识别，而这正是哈希锁封装所做的。

Alkanes 不需要比特币的许可来承载状态，也不需要流程控制操作码或超大 push 来做到这一点。如果 BIP-110 明天激活，部署路径只需切换到 kungfuflex/bip110 分支上的哈希锁封装，每一个新合约都作为一个 HTTP……抱歉，作为一个没人承担得起去过滤的 HTLC 来部署。

软分叉可以改变比特币交易被允许看起来是什么样子。它们无法让比特币无法分辨一个哈希锁是在支付给 Alice 还是在部署一个合约，因为它做不到，审查者也做不到。