比特币最近的 Op_Return 讨论和 Bitcoin Core 节点政策

最近比特币关于Op_Return输出讨论非常激烈，又激发了我的好奇心，我决定写一篇文章总结。其实这样的文章，主要是写给自己看，除非特别关心协议和技术，大家没必要浪费时间读。

甚至，现在AI这么强了，我觉得让chatgpt o3或者让gemini 2.5 pro deep research给各位写，要比我写的好太多。

在前几天，有一位朋友要做空Ordi，恰好是 31 位 Core 贡献者联合发布《交易转发政策声明》的时间后。

我非常想告诉他这些关于Op_Return和往UTXO里塞数据的讨论，以及潜在的和铭文的关系。

但鉴于我对价格的预测真是烂到家了，我还是没说，不能影响别人发财啊。而且我真心觉得技术和价格现在是完全脱离了，没啥关系了。

一直以来，Core 开发组，作为比特币的“官方”，对往比特币区块链上塞各种和比特币作为货币属性无关的数据，都是严防死守的。这个政策是从2014年Op_return被引入Bitcoin开始，一直延续到最近的31位Core贡献者联合声明之前，都是妥妥的严防死守。Core 一直对“非金融数据”抱持最小化立场：1）每笔交易最多 1 个 OP_RETURN；2）单条数据不能超过 80 字节；3）允许节点用-datacarriersize 手动调大，b 也就是这本质上不是共识规则。

一直以来，Core 官方的态度和代码实践上都是严格限制“非金融”数据上链的。

但最近Bitcoin Core的代码仓库更新了对这些“非金融”数据的态度，一下子放开了对这些数据的限制，而且步子迈的特别大。

Core 开发者 Peter Todd（这哥们现在到处称自己不是Core 贡献者，只是研究者了，哈）在2025年4月份搞一个 PR #32359 “Remove arbitrary limits on OP_RETURN outputs”，提议：1）

删除单条 80 字节和“单输出”检查；2）废弃 -datacarriersize 相关选项；3）其余 DoS 防护交由市场费用 + 带宽综合判断。

需要说明的是这个 PR 尚未合并进Bitcoin core主代码仓库，但 最近的31名开发者的联合声明等于给放宽政策“背书”，看起来要合并这个PR。

另外，在2021年5月BCH的升级是做了类似的规则更新，但这次BTC的规则更激进，BCH到现在为止在代码层次上还是限制单笔交易的op_return总字节尺寸不能超过223字节，在一笔 bch 交易里可以有多个op_return输出，但总字节数不能超过223字节。

而BTC的这次PR是没有对Op_return在单笔交易的总字节量做出限制，但比特币的单笔交易有1M字节的限制，所以也可以认为单笔交易对Op_return的字节限制是1M。

以上就是这一次Bitcoin Core节点软件在代码层面上对“非金融数据”上链的政策更改。

为什么会有这一更改？

从铭文在2022年火起来后，比特币区块链的总数据量（节点软件需要下载的文件总量）以及UTXO数量（节点软件里必须常驻内存的数据）都大规模膨胀。

下面是我使用chatgpt o3模型调研数据，并画出来的铭文火起来后比特币区块链数据膨胀的历史。

区块链总数据量从 ≈ 430 GB（2022-10）膨胀到 ≈ 665 GB（2025-06）；

UTXO 集合一度冲到 1.88 亿条（2024-12），是 2022 年的两倍多；

（OP_RETURN 本身不进 UTXO，但碎片化 Taproot 输出会显著拉高。）

让比特币链上“胖身材 + 多碎片”同时出现，磁盘胀 60%、UTXO 翻 2 倍，这让很多开发者担心去中心化的成本了。

Core 开发组从2022年以来，对铭文这些的应用就抱有非常大的敌意，强烈要求在规则层面进一步限制这些数据。Core 开发者的主流观点是比特币区块链要去中心化，就要限制这些非金融数据，以让节点运行成本不会膨胀。

这里以Lukejr为代表，Lukejr自己开发的节点软件Knots 就直接限制了对将数据塞进op_return的铭文类应用的交易的中继，就是Knote 作为比特币的节点软件在收到铭文交易后是不转发的。

Op_return本身在比特币规则里是可以被节点软件裁剪的，也就是不具备区块链常见的数据永久保存的能力。

很多其他铭文类的应用，就担心自己的数据被比特币规则限制，使用了各种hack手段来设计协议，从利用Op_return，进化到了将数据塞进 taproot脚本里，保存在交易的见证数据（witness）里。

在见证数据里，受益于 segwit的手续费打折，以及见证数据区块的3M上限，让这些铭文类数据的矿工费又便宜，设计起来还比op_return还简单，并且受比特币协议保护，不会被裁剪。

这下就更惹火了Core 开发组的很多开发者。

但除了少部分Core 开发者，好像整个生态都挺欢迎这些铭文类应用的，包括矿工和交易所，都是明牌支持。

交易大量上架各种铭文类代币。

矿工甚至大量打包非标准脚本交易，以配合很多铭文类协议产生的更大更复杂的交易，这在实事上就突破了op_return数据的限制，因为本质上这种限制并不是共识层面的限制，只要有矿池打包了，其它矿池不会拒绝的。

上述两种情况，对比特币区块链数据的影响的区别是很大的。Op_return类数据和 taproot脚本都会显著增加区块数据量，也会大量增加UTXO的数量。然而在完整节点运营视角来看，Op_return数据是可裁减的，但 taproot脚本是不可裁减的。

这样的局势发展，大约是到了要倒逼协议做出变更了。

如果铭文类应用无法阻挡，那在协议层如果放开对Op_return数据的限制，给铭文类应用放开一个口子，引导它们使用Op_return，而不是 taproot脚本，或许对比特币的节点运营来说是更友好的。

就让Core 开发者产生了两派，少量的坚定认为应该在协议层堵死铭文类应用产生的“垃圾数据”，他们坚定认为铭文类应用就是对比特币发动的DDOS。

而更多的开发者是觉得两权相害取其轻，引导数据往 op_return发展，而不是可花费的脚本。

这就是，目前我看到的情况。

我觉得目前局势发展下去会产生什么结果呢？

对Op_return数据的协议层更改，并不会产生比特币链的分裂，这是非共识层的。而且目前像Luke jr这样的强烈反对“非金融数据”上链的一方，采取的最极端的做法也仅仅是限制节点对铭文类交易的中继，而不是直接在协议里做设定其为非法。

所以这一次争议完全没有分裂的风险。

但我觉得Bitcoin core节点软件会朝着放宽Op_return数据限制方向发展。Luke jr这一派估计是要认了，按我读到的文章，Luke jr可是坚定的斗士，对自己的理念极其坚定，但这一次我觉得Luke jr要么做好长期战斗准备，要么认了。

铭文类，二层类应用，可能会迎来更友好的比特币底层协议开发环境。

但我对价格，是真不知道。