OP_RETURN 的门从八十三抬到十万：-datacarriersize 在 v30 的改制 图 1
OP_RETURN 的门从八十三抬到十万：-datacarriersize 在 v30 的改制 · 图 1

在比特币里，往链上刻一小段数据有个专门的出口：以 OP_RETURN 开头的输出。它天生花不掉，因此被当作”数据存证”的通道，也因此在节点政策里享受了十年的特殊限额。v30 把这道门从八十三字节抬到了一个近乎不设防的数字。本文按 v31.0 源码与 v30.0 发布说明，把这道门的开关、量法和副作用讲清楚。

默认值：从八十三到十万

src/policy/policy.h 里的常量 MAX_OP_RETURN_RELAY 在 v31.0 中不再是八十三，而是由标准交易最大权重折算而来的十万——也就是命令行参数 -datacarriersize 的默认值。v30.0 发布说明对此的表述很直白：抬到十万等于实际解除了限制，因为交易本身的尺寸天花板会先到来；想退回旧规矩，可以显式写 -datacarriersize=83。

这条说明同时交代了配套变化：v30 起，一笔交易可以携带多个数据承载输出，中继与打包一并按新规则放行；此前多年，节点只认单个 OP_RETURN 输出，且整个输出脚本不得长于八十三字节。

上限量的是什么

参数帮助文本的说法是：中继并打包那些数据承载脚本合计尺寸不超过该值的交易，允许多个输出。也就是说闸门按整笔交易中所有 OP_RETURN 输出的脚本总长来量，不区分这些字节是协议前缀还是有效载荷。源码里的单元测试把这件事测得很精确：两个输出脚本长度之和恰好等于上限时判标准，短一分则判非标准。因此对使用者而言，估算公式就是”所有数据输出的脚本长度求和，再与该值比较”，而不是只看某一枚输出。

配置读取路径在 src/node/mempool_args.cpp：只有数据承载总开关处于开启状态时，-datacarriersize 的取值才会被读进内存池选项；一旦总开关关掉，这项配置直接失效，任何数据交易都不再中继。换句话说，先有开关，再有大小的问题。

怎么核对当前生效值

v30.0 起，内存池信息 RPC 增加了两个反映政策配置的字段：permitbaremultisig 与 maxdatacarriersize，后者正是 -datacarriersize 的生效值。这意味着无需翻配置文件，问一句节点就能确认眼前这台机器对数据交易的尺度；两台节点对同一笔数据交易态度不同时，先比这两个字段往往比猜快得多。

对使用者的实际含义

门槛解除不等于费用消失。数据输出的脚本要占权重，权重决定手续费；把一百千虚拟字节塞进链上，等于用真金白银买区块空间，拥堵时段尤其昂贵。也不等于隐私改善：数据公开可见，脚本内容对全网广播。更不等于政策统一：任何运营者都能把这台节点的值改回 83 甚至更低，你的交易能否顺利传播，取决于路径上的节点各自设了多少。评估一笔数据类交易的可行性，应当先看目标费率与尺寸账，再核对手里节点的这两个字段，而不是假定默认值全网一致。

八十三这个数字的来历

旧门槛的由来是一笔粗糙的预算：以 OP_RETURN 打头的脚本总要为操作码与长度前缀付出开销，把有效载荷定为八十字节，加上封装余量凑成八十三。它从来不是”链上最多能写多少字”的物理极限——共识层并不给数据脚本设单独上限，愿意付费的交易本可以塞进更多字节，只是大多数中继节点在八十三这条线上默认关着门。理解了这层关系，也就理解了 v30 改制的真实含义：策略默认值放开了一道大多数节点自愿执行的中继门槛，而不是修改任何共识规则；数据能否最终进块，依旧由出价和块空间说了算。

风险提示：本文讨论节点中继政策与交易结构，不构成投资建议或对任何数据存证服务的评价；参数默认值与语义以比特币核心 v31.0 源码及 v30.0 发布说明为准，具体取值可能随版本变化。

参考来源