想把自己的哈希、一句话或一个编号“永远刻进比特币”，不需要发币给任何人——比特币脚本里的 OP_RETURN 操作码就是为此设计的正规通道。Bitcoin Core 0.9（2014 年 3 月发布）把它确立为默认中继、打包的标准通道，从此“数据上链”与“转账”在客户端政策层被分开对待。需要澄清：这是一条客户端政策演进线，没有任何 BIP 或共识规则为可携带数据的容量定下统一标准。
原理：一个永远花不掉的输出
比特币交易输出通常附带“如何解锁”的脚本；OP_RETURN 输出的脚本开头就是这条操作码，脚本规则规定它立即失败——任何人都永远无法花费它。既然注定花不掉，节点就不必把它当作待消费的 UTXO 长期记在“活跃账单”（UTXO 集合）里，只需随区块历史归档。这正是设计初衷：在 OP_RETURN 出现前，想上链写数据的人用“向自己地址发 0.00000001 个比特币”的土办法，那些小额输出会永久增加全网节点的活跃状态负担（参见 比特币脚本是什么？为什么它不需要图灵完备）。OP_RETURN 把这种数据明确标记为“非 UTXO”，主流客户端允许这类输出在“数据载体大小”限额内随交易携带（standardness 政策，不是共识规则）。这个默认限额随版本演进过：0.9 引入时默认限 40 字节数据，2015 年初的更新把它提高到 80 字节数据——在源码层面它写作 83 的脚本总额度（80 字节数据、1 字节 OP_RETURN、2 字节推送操作码），常被引用成“83 字节上限”的正是这个组合值；节点操作员还能用 -datacarriersize 参数自行调整，替代客户端（如 Bitcoin Knots）长期维持自己的默认值，而这一默认值本身近年仍是社区争论话题。因此不存在一条全版本统一、现行有效的上限，任何“X 字节铁律”都要先对齐软件与版本；超过本机限额的交易会被该节点视为非标准而拒绝转发。
谁在用它
- 时间戳存证：把文档哈希写进比特币链，借助链的不可篡改做“某数据在某时刻已存在”的证明，学术与企业存证系统都曾用它；
- 协议标记：早期色币（Colored Coins）、部分质押协议用前缀字节标识元数据；
- 铭文早期形态：部分 Ordinals 实践用 OP_RETURN 存放部分元数据，另有相当比例直接写在见证字段里——这提醒我们“上链写字”从来不止一条路；
- 多链锚定：跨链协议把承诺哈希锚到比特币上做轻额证明。
快速问答
- “写 OP_RETURN 要花多少钱？“手续费按交易总体积计价：存证交易只多了一个数据输出与少量脚本开销，体积很小，费用高低取决于提交时的链上费率，费率本身随拥堵大幅波动，这里不给具体数字。它占的是区块空间，与转账金额无关。
- “数据真能被查到吗？“能。交易一旦确认，任何人用全节点或区块链浏览器都能检索到该输出及其内容，前提是这段数据没有被后来“剪枝”的第三方索引遗忘——链本身永久保留。
- “和粉尘攻击什么关系？“粉尘攻击用大量小额可花 UTXO 骚扰目标（见 粉尘攻击是什么？收到小额转账该怎么处理），OP_RETURN 是协议认可的书写方式，两者动机与形态都不同，但都体现了“链空间可被低成本占用”的两面。
- “以太坊有对应物吗？“以太坊不需要特殊操作码——交易的 calldata 或日志天然可携带数据并永久可检索，费用机制（gas 与 EIP-4444 类的历史膨胀讨论）承担了同样的成本核算角色。
常见误区
- 误区一：以为某个字节数（40、80，或加上脚本开销凑出的 83）是共识铁律。它们都是标准性策略：随客户端版本更迭，也随 -datacarriersize 配置而异。矿工理论上可以打包更大的 OP_RETURN 输出，但多数公共节点会拒绝转发，实践中交易能走多远由主流节点政策决定。
- 误区二：以为写了数据就“拥有”数据。链上只有字节，没有文件；哈希存证能证明存在性，不能替你保管原文，原文丢失时链上记录只剩指纹。
- 误区三：把 OP_RETURN 当作隐私渠道。链上数据全网公开永久，任何敏感内容都不应直接写入，只能写哈希或密文。
小结
OP_RETURN 是比特币为“写字”开的窄门：载荷微小、不可花费、不膨胀活跃状态；门框的宽度（数据上限的默认政策）从 40 字节到 80 字节一路调整、随客户端与版本而异，但始终停留在标准性政策而非共识规则的层面。它让比特币同时是账本和档案馆——只不过档案馆的书架按字节收费，且对所有读者敞开。
风险提示：本文不构成投资建议。链上数据内容公开永久，存证请只写入哈希或脱敏标识。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。