OP_RETURN 及近期争论

作者：Jeffrey Hu

关于近期取消 OP_RETURN 输出转发限制的争论，相关人员在各个渠道（邮件组、Github、论坛、社交媒体等等）有了非常多的激烈讨论，也有不少机构、媒体、KOL 的总结和解读，也不可避免地带有一定的支持或反对的立场。尽管放宽限制的修改已敲定，但遗憾的是，其中的一些内容对于客观情况的理解在笔者看来并不准确。

笔者希望本文能为读者尽可能准确地介绍（科普） OP_RETURN 的原理及比特币网络的相关情况、总结此次争论正反双方的观点，并提出一些重要但未解决的问题。

OP_RETURN 是什么？

可能很多朋友，包括笔者在内，一开始知道 OP_RETURN，是因为它可以让用户任意记录数据在比特币链上。那么，这个类似交易附言（memo）的功能和它名字是怎么联系到一起的呢？

从“OP”这个前缀不难看出， OP_RETURN 是比特币脚本中的一个操作码。但它怎么携带数据呢？这需要从比特币脚本层面来看。

OP_RETURN <data>

OP_RETURN 是一个控制流终止操作码，正如其他编程语言中的 return 关键词会从函数返回跳出一样，比特币脚本一旦执行到该操作就会立即停止执行，并将结果标记为 false，即失败（而至于为什么会设计成 false，笔者会在下文解释）。

由于比特币的共识规则规定：所有输入引用的输出脚本执行后必须返回 true，因此任何包含 OP_RETURN 的输出在尝试花费时都会失败，进而成为“不可花费输出”。

重要的是，这一验证行为 只在尝试花费该输出时才会触发。而在创建交易时，创建带有 OP_RETURN 脚本的输出并不会影响交易的有效性。并且，只要符合节点的标准策略（如大小限制），这样的交易就会被节点转发。由于这些输出永远无法被花费，它们也就 不需要存储到 UTXO 集，因此不会增加全节点的热存储负担。

这样就相当于给比特币提供了一个写入数据（或涂鸦）的功能。

中本聪也资辞么？

或许读者会说，往比特币链上写内容是天经地义、“自古以来”就有的事情。中本聪的第一个区块不就写了那句著名的话嘛 “Chancellor on the brink of second bailout for banks.”。

不过很遗憾，中本聪当时还没有用上这个 OP_RETURN 这么高级的功能。前述 OP_RETURN 的完整功能是 Bitcoin Core v0.9.0 版本重新定义的。

尽管在中本聪时代的早期版本就有 OP_RETURN，但在 v0.3.5 版本以前，其动作是跳过尚未执行的脚本部分，并将栈顶元素返回。是不是更像通常意义上的 return 语句？但这会带来极大的 安全隐患。例如攻击者可以在解锁脚本里构造出来如下内容：

OP_TRUE OP_RETURN

当执行到 OP_RETURN 时，脚本就会把栈顶的 OP_TRUE 返回，而忽略所有锁定脚本里的检查条件，从而可以盗窃任何人的比特币！所以中本聪很快 修复，将 OP_RETURN 结果改为总是失败（false），也就是我们现在看到的“携带数据、不可花费”的基础。

而进一步定义 OP_RETURN <data> 为标准化脚本，从而数据体积在限制内的 OP_RETURN 输出得以在网络中转发，则是在中本聪隐退之后、2014 年的 Bitcoin Core v0.9.0 版本中。

这里，笔者将这段 OP_RETURN 的修改历史简要总结如下：

各种涂鸦方法

那么中本聪是怎么写那句话的？还有哪些将数据上链的方法？

scriptSig

中本聪使用的是 scriptSig（脚本签名）字段。尽管 scriptSig 需要和解锁中的输出脚本（公钥）对应才能成功花费，但只要精心构造脚本（如在解锁验证前用 OP_DROP 丢弃掉涂鸦数据等），仍然可以实现在正常花费的同时携带任意数据的效果。

目前直接在 scriptSig 里写数据的方式已经不太流行，但仍然会有使用，主要是在 coinbase 交易中。原因可能在于 coinbase 交易不需要解锁之前的输出，可更自由地填充一些内容，用来记录区块高度、扩展 nonce、矿工标识、信号等。

那么，scriptSig 有什么问题导致后来不流行了呢？一部分原因可能是 成本：因为 scriptSig 是在交易的输入中，所以必须先创建一个输出，然后在花费这个输出时携带数据，因此除了数据本身的体积，还需要为额外的输出和交易的体积支付手续费（比特币交易的手续费与其体积正相关）。另一部分则在于编程上的复杂性，同样来自于必须先创建带有专门构造的输出。

P2FK

所以后来人们就想出了一个办法来简化：既然创建输出本身不是为了 保存资金/花费（只是作为揭晓数据的桥梁），那么可以直接把要写的内容当作接收公钥，即 Pay-to-Fake-Key。不再需要发起新的花费交易，需要额外付费体积自然就更小了，手续费成本也就降低了。

OP_PUSHBYTES_65 <fake-pubkey-data> OP_CHECKSIG

而因为这个地址是没有有效的私钥可以花费的，这个 UTXO 永远无法花费，其中的比特币也就相当于是燃烧掉了；但交易从外表来看一切正常，节点还需要存储，毕竟万一真有一个对应的私钥呢？所以 代价自然就是 UTXO 集的膨胀，和节点存储的成本提升。

类似的，还有 P2FKH（类似 P2PKH，将希望写入的数据作为脚本中的哈希值）、P2FMS（Pay-to-Fake-Multisig，伪装成裸多签名脚本中的公钥）等。

实际上，重新定义 OP_RETURN 为标准化脚本的一大目的就是提供替代方案，希望人们不再使用这些会引发 UTXO 集膨胀的假输出。

Ordinals/Inscriptions

近些年开始了解比特币的朋友可能对 Ordinals 及其数据写入方法（“inscriptions”）更为熟悉。Inscriptions 是将任意文件数据放到了 Taproot 输入的见证数据中。

这种实现方式的最终效果与 OP_RETURN 差别较大：OP_RETURN 输出中的数据，在创建它的交易中就已经揭晓；inscriptions 则 需要另一笔额外交易 来揭示 witness 数据（与 scriptSig 方法相似，但经济性更好）。此外，inscriptions 所受到的全网络通行的 交易池转发策略 较少，而大多数节点都不转发数据体积超过 80 字节的 OP_RETURN 输出。

尽管还有其他的技巧来实现数据的写入，笔者在此对上述几种流行或曾经流行的方式进行小结。

转发策略 vs 共识规则

在上文及之前的表格中，笔者都提到了一个关键词 “交易转发策略”。近期的 OP_RETURN 风波的很大一部分讨论焦点就集中在交易池转发策略上。

交易转发策略是指一个比特币节点（如 Bitcoin Core）在转发和接受未确认交易时执行的一系列非共识规则。 这些策略 通常用于防范 DoS 攻击、预留日后升级空间或引导鼓励某种更优行为。如果一笔交易符合节点本地的转发策略规定（包括输入输出类型、大小、费用、脚本行为等），节点就会默认接受并转发。

此处还有一个概念是 “标准交易”，这本身是 Bitcoin Core 软件中的一个定义：当一笔交易并非本版软件定义的标准交易时，节点就不会保存和转发。

与之相对，是共识规则。 共识规则是指所有节点对区块和交易有效性的硬性判定标准，只有违反共识的交易才会被全网拒绝。

转发策略与共识规则的重要区别在于： 一笔交易可以“不标准”但仍然“合法”。也就是说，若某交易不符合默认的标准政策，节点会选择不转发、不纳入交易池甚至不打包，但一旦它出现在区块内（由矿工打包），其它节点仍会根据共识规则认定区块有效。

以 OP_RETURN 输出举例， 该操作码自始至终存在，不论其脚本中携带的数据体积有多大，都不违反共识规则。只是，在本次争议发生之前，大部分比特币节点都采用 80 字节的数据体积限制作为一种交易转发策略：数据体积小于 80 字节的 OP_RETURN 输出会被自由转发，超出的则不转发。

所以读者看到这里应该就可以知道，一些媒体将此次修改称为“比特币 OP_RETURN 升级”显然是不合适的。而笔者也对于一些项目期待基于此次 OP_RETURN 的修改来开发新项目 持怀疑态度，因为此前也可以通过各种方法去发送一个携带更大体积数据的 OP_RETURN 交易上链，并无本质不同。

但在修改生效前，目前 Bitcoin Core 对于标准交易大致有以下规定：

• 标准脚本类型：如 P2PKH / P2SH / P2WPKH / P2WSH / P2TR（Taproot）等等 1、不使用未定义的 opcode 等。
• 签名脚本大小：每个输入的 scriptSig 长度不得超过 1,650 byte。
• 交易总大小：不超过 100,000 vByte。
• 输出金额：输出的面额有下限，比如 P2PKH 输出需至少大于 546 sat 2（粉尘限制）、OP_RETURN 的输出为 0 sat。
• 签名脚本约束
• 费用费率约束：符合节点设定的最低 fee
• 版本号及对应规则：如 v2、v3。另外，还有 RBF、包中继等规则。

注 1：通过花费条件，用户可以构造各种类型的交易形式，上文的 P2FK 就是一个很好的例子。因此标准化对于应用间相互理解其输出的含义十分有用。

注 2：郎教授可以理直气壮地说：你给我 ( BIP-177 下的) 1 bitcoin，我是不要的，因为有 546 bitcoin 的粉尘限制。

为什么这些限制很重要，甚至是这次争论的焦点呢？标准交易的主要作用包括以下几个方面：

• 防止滥用： 限制无效数据、过大交易或垃圾输出进一步传播。这样可以有助于控制 mempool 中的交易格式，降低验证与存储压力，也便于节点有效地防范 DDoS 攻击。
• 控制链上膨胀： 主要是控制 UTXO 集大小。因为节点理论上需要一直保存所有的 UTXO，即未来任何时刻都有可能要花费的资金。滥用或无必要地扩大 UTXO 集（例如粉尘攻击）会严重影响节点的性能，进而影响整个网络的安全性和去中心化。
• 提升效率和预测性： 转发策略不仅限制不符合规则的交易，同时也会有利于符合规则的交易。矿工收到符合标准的交易（如符合费率、清晰的输出结构、签名合理）时，更倾向于将其打包进区块中。这为钱包实现费用估算和 RBF 提供了稳定依据，也让用户对交易确认时间更有预期。
• 提升可交互性： 通过比特币的签名、脚本形式，用户可以构建出来各种各样的交易，但如果规定好若干类标准的交易，可以更方便钱包等应用针对这些交易格式进行开发，提升用户在使用不同应用时的可迁移和可交互性。

近期争议的时间线

有了前文略显冗长的介绍后，下面我们可以来梳理近期 OP_RETURN 的争议了。

正反观点整理

尽管 PR 32406 已经合并，似乎一切已盖棺定论，笔者仍希望再次整理正反双方的观点。一方面是希望读者通过文章前半部分的科普介绍来重新审视这些讨论及观点，另一方面是通过这些观点，我们可能引发更多的思考和洞见。笔者个人的意见则留待下一章。

支持放宽 OP_RETURN 限制的观点

• 尊重用户需求，承认既成现实： 支持者指出，转发策略中的 OP_RETURN 相关限制并不能阻止链上存储行为，因为市场对此已有真实需求且用户愿意付费实现。以 Ordinals 热潮为例，大量图片等非金融数据通过见证字段写入区块，并未受到任何标准策略限制。据 统计，Ordinals 自推出以来总计已产生超过 8800 万次铭文，支付了逾 7000 BTC 的手续费，说明很多用户乐意为链上存储买单。与其继续坚持一条形同虚设的限制，不如顺应现实解除它——因为“ 马已经跑出栅栏”，就算没有 OP_RETURN，这些数据依然会以别的方式上链。

• 中立性与抗审查原则： Bitcoin Core 开发者 强调，比特币网络的抗审查性是首要属性，节点软件应保持中立，不因交易内容或用途而区别对待。他们同样不喜欢垃圾数据或乱用链空间的行为，但 信奉交易手续费机制是过滤交易的最终手段：只要有人愿意为某笔交易付出高于他人的手续费，矿工就有经济动机打包它。正如早期比特币开发者 Eric Voskuil 所言：“ 对抗审查的能力归根结底来自交易费率”。因此，与其尝试在转发层面进行控制，不如让费用市场发挥作用——只要垃圾交易无法持续补贴高额手续费，它们自会因为无利可图而逐渐消失。这种观点认为，节点人为过滤虽然在道德上 与内容审查有所区别，但技术效果上相近，同时还很难在有经济动力的情况与其对抗。

• 两害相权取其轻： 这类观点 认为，当前不允许携带大体积数据的 OP_RETURN 输出得到自由转发，导致开发者和用户转而使用更“损害”网络的方式存储数据，例如上文提到的 P2FK、scriptSig 等造成 UTXO 永久膨胀。既然 数据无论如何都会上链，那么让它们以 对节点危害更小 的方式存在就是合理的。OP_RETURN 输出 不进入UTXO集合，验证时也无需执行复杂脚本，比起假输出占用资源要友好得多。当区块空间被填满时，大量使用 OP_RETURN 反而可能降低节点负担：由于见证折扣的存在，一个区块若全是见证数据，实际体积接近 4MB；但如果全是 OP_RETURN 则因没有折扣，区块字节上限约 1MB。同时 OP_RETURN 数据可被修剪（pruned）（不进入 UTXO 集合），这对减少全节点运营成本有利。因此，解除 OP_RETURN 转发限制反而能够 避免更坏的链上数据利用方式，优化全网资源占用。

• 与矿工行为保持一致，提升网络效率： BitMEX 的 研究指出，如果节点默认不转发这类实际会被矿工接受的交易，用户就会被迫求助于矿池的私有通道提交交易。例如 MARA 等矿池提供的接受非标准交易的服务。这样的后果是：区块内容和公开交易池渐行渐远，节点难以及时知道区块包含的所有交易，进而破坏致密区块（Compact Blocks）等加速区块传播的机制， 导致区块传播延迟增加。传播变慢将提高小矿工出块后被孤立的概率，从而 进一步加剧矿业中心化。相反，如果节点政策与矿工实际行为一致，公开的 P2P 网络就能容纳所有类型的交易，矿工就不需要架设私有渠道，交易也能更高效地广播和打包。同时，每个节点的交易池更准确地反映待确认交易，全网对下一块的预期更一致，有助于 改进手续费估计 和用户体验。总而言之，取消 OP_RETURN 限制可以让比特币网络在透明度和效率上更胜一筹，而不是把大笔交易挤到幕后进行。

• 用户选择权与开发过程透明： 支持者也 回应 了“强制所有人接受”这一指责，强调用户依然拥有充分的选择权 。 Bitcoin Core 软件本身是开源的，任何人都可以复制修改。“Bitcoin Core 只是众多协议实现之一，它之所以特别，只因为其贡献者的决策方式”。如果强烈反对，用户也完全可以 用脚投票 ，继续运行旧版本，或切换到其他客户端，比如维持更严格策略的 Bitcoin Knots 等。另一方面，Core 开发者认为在整个决策过程中公开透明地讨论和沟通了此提案：从邮件列表到 GitHub，再到 6 月的联合声明，信息都是公开可审阅的。据此，支持者认为此次修改遵循了比特币开发一贯的开源协作精神，并无“不经讨论强推”之嫌。

反对放宽 OP_RETURN 限制的观点

• 滥用链上空间，偏离比特币本旨： 许多反对者认为，比特币区块链宝贵的空间应主要服务于货币交易，过度允许非金融数据嵌入将把比特币变成“ 数据存储网络”，模糊其作为点对点电子现金系统的定位。正如有用户 讽刺 的那样：“这叫比特 币 (Bit‘Coin’)，不是比特 存 (Bit‘Store’)”。大量图片、音频等数据占据区块，将挤压正常金融交易的空间， 损害比特币作为货币网络的价值支撑。而 OP_RETURN 在 v0.9.0 修改为可携带数据时也专门提到并不鼓励在区块链写入非金融数据。

• 引发垃圾交易（Spam）和潜在 DoS 风险： 解除限制后，攻击者或投机者可能因为实际门槛降低而发送更多垃圾交易。这不仅会 推高正常用户的手续费（因为需与垃圾数据竞争空间），还可能 拖慢节点处理速度，对网络造成拒绝服务（DoS）攻击隐患。持此观点者将开发者认为“垃圾数据终究会被矿工打包”的态度视作一种妥协和 失败主义，认为不应向恶意行为“缴械投降”。在他们看来，更积极的做法是加强节点过滤和社区文化来阻止垃圾数据上链。

• 破坏交易池转发策略的自治： 反对者强调， 比特币的去中心化不仅体现在共识层，节点对自身交易池（mempool）和转发策略 的自主控制也很重要。而取消 OP_RETURN 限制将使用户 失去一项自主选择：过去节点可以通过 -datacarrier 等参数设置拒收超出特定大小的交易，但新版本中该选项将被移除或失效。这意味着所有运行新版 Core 的节点都被 强制接受并转发 含有大数据负载的交易，不再允许个人依据偏好过滤。这一改变引发对“节点策略单一化”的担忧和质疑：Core 开发团队是否在 以软件更新之名行改变网络用途之实？知名开发者 Luke Dashjr 等 公开呼吁 用户拒绝升级或转用能够坚持原有过滤策略的节点实现（如他维护的 Bitcoin Knots 软件）。

• 决策过程与价值观争议： 除了技术顾虑，许多反对者对这一更改的 决策流程 表达了异议。在 GitHub 相应 PR 下，有大量用户给出了大量的 👎 emoji。尽管 Core 团队声明流程是公开透明的，但很多人仍然认为开发者是在 共识尚未充分达成、社区存在明显分歧的情况下贸然合并代码，有违“慎重避免争议”的原则。一些 评论 直言：这种做法做开了很坏的先例。还有人质疑这一改动背后的动机，认为是部分开发者受到一些“比特币生态”项目的影响，例如 Citrea 等。

个人观点

从上面的讨论，许多媒体都有不同的进一步解读，例如比特币是不是去中心化、是不是抗审查等。但笔者认为，只要对比特币原理有进一步了解，（至少从目前的状态来看）就不会太担心，进而像对其他密码货币一样来纠结于 是否去中心化。这次的争论在一定程度上也是证伪了这些担忧。

回顾整个事件，我很同意 Olaoluwa 的说法，这很像一次 非受迫性失误：没人主动要求来变更；有的话也是开发者基于还没部署的某个东西来做了一次抢先动作，而且近期也没有太多非标准交易需求。但现在倒好了，开发者陷入到了进退两难的境地。

抗审查 vs 垃圾交易

支持放宽限制的一个很重要观点是，我们不应该对比特币上有什么交易做限制，让市场来决定，否则就会造成事实上的交易审查。

笔者对此说法同意其中一部分。比特币一个很优秀的经济特性，不仅在于宏观上的稳定（2100 万发行上限），还在于微观层面上 交易手续费政策的统一（总是以交易体积大小来计算）。而反观以太坊，不仅经济体总量会变化（PoS、EIP-1559 修改整个经济模型），手续费政策也会经常变化（Dencun 升级降低写入数据操作的成本）。所以如果“看不见的手”能起作用，就不要让“看得见的手”来搀和，因为它经常会变成“管不住的手”。

OP_RETURN 这次也没有修改手续费政策，但修改的过程更多是通过“写代码的手”而不是通过“写帖子的手”来推动的。

但审查交易的说法在笔者看来则站不住脚， 核心区别是在于对内容还是对形式、对他人还是对自己。

比较典型的审查交易行为是，节点得知了发交易人的身份（攻击者、洗钱团队等）或资金来源（不符合一些法律规定），而不让其发布上链。也就是获知了交易的 内容、“语义”后， 对他人 主动造成影响。

而节点策略对 OP_RETURN 的限制，则是出于 形式 上的规范，只转发上文提到的符合规范的标准交易，防止对网络的滥用。一个比较典型的反例是区块战争时期，Bitcoin 网络曾遭受了严重的 粉尘攻击。如果你极端秉承“只要有人愿意付费就行”的观念，粉尘攻击是不是也可以不算一种攻击而是合理使用了？

另一方面，节点策略也更多是 对自己 的节点进行处理，比如过滤掉自己不关心的交易，来降低网络和存储压力。

节点自治 vs 网络效率

另一个争论的焦点则是，是否应该更多支持节点自定义转发与交易池策略，还是最好能一致以便提升网络效率（矿工激励相容、区块传播更快、费率更可预测）。

从效率上来说，更快的区块传播效率在技术上是令人信服的。尽管 没有统一的交易池，但如果节点间的交易池内容更一致，则节点自身就会保留更多未来会上链的交易，在致密区块（compact block）的机制下就会降低网络开销，让区块同步更快。同时，对于费率的预估也会更准确，这对于一些费率敏感的交易（如闪电网络上预签的交易）更加关键。

但问题是在于目前 OP_RETURN 类的交易是否很多，多到已经显著影响到了致密区块传播或费率预估？或者说迫切到需要用写代码的这种“看得见的手”来推动，而不是发帖呼吁大家修改默认配置？

这里笔者也不想进一步上纲上线地扩展到节点多样性对于网络的重要性。仅作为一个节点运行者， PR #32406 就对笔者来说更可接受一些，起码暂时保留了节点自主配置的选项。

节点实现 vs 网络公共政策

正如前文所述，我们不能将这次修改称为“比特币的 OP_RETURN 升级”，这只是 Bitcoin Core 自身的策略的一次修改，其它一些客户端实现并未跟进同样的策略变更。但为什么会引起如此大范围内的争论？恐怕一个原因仍然在于 Bitcoin Core 是目前最广泛使用的客户端，是事实标准。

一个可能不甚恰当的例子是美元，它既是美国国内的货币，也是事实上的国际通用货币。美国可以通过美元来对全球施加影响力，但在制定货币政策时，也自然需要考虑国内经济状况。

Bitcoin Core 在“事实标准”这个层面也有类似的矛盾情况：

一方面，Bitcoin Core 受制于此类定位，自身的策略（交易池管理、交易转发）等都无法只考虑节点本身，而需要兼顾到整个网络的情况。新的策略可能就会引起足够大的影响，例如 v3 的交易转发 等。而这些策略也会很大程度上影响到其他的应用开发，例如闪电网络等等。

另一方面，这种事实标准也有能力裹挟网络协议。例如，Bitcoin Core 会按照 规则 来公开此前版本的漏洞。因此虽然用户在理论上 可以运行很久之前的客户端，但这些安全漏洞会迫使用户升级到新版本，接受的新功能，尤其在配置选项也被移除的情况下。

从这次的事件来看，Bitcoin Core 未来仍会在这两种角色间进行平衡。而运行节点的用户并不如一些开发者所想的，能那么容易地用脚投票：指望每个运行节点的人都能修改代码并不现实，而换用其他客户端也要考虑到其他客户端的开发和测试资源可能较少，并不足够健壮和安全。那么，留给异见用户的选择就比较尴尬。

这个问题目前看仍悬而未决。

（完）

• 本文转载自： btcstudy.org/2025/06/26/... , 如有侵权请联系管理员删除。