作者：Rich Apodaca

来源：https://bitzuma.com/posts/op-return-and-the-future-of-bitcoin/

原文出版于 2017 年。

比特币网络将交易打包到名为区块链的分布式数据库中。从网络内部视角来看，这些交易只是电子现金付款。从网络外部视角来看，可以进行更复杂的解读。将应用专属数据添加到交易上可以让比特币的用途不再局限于电子现金付款，而是进一步拓展至金融、财产和法律事务。我们是否应该支持这些应用场景？如何支持它们？这些问题经过数年的激烈的讨论，依然未有定论。

Bitcoin Core 0.9.0 版本迈出了解决新交易类型标准化争议的第一步。本文回顾了区块链的延展性问题，及其解决方案的重要性。

早在 2010 年，bitcointalk 论坛上就出现了关于在比特币上构建去中心化域名服务的提案。该提案包含两个部分：

1. BitX 将扩展比特币协议，支持在比特币区块链上运行的多个微型应用。
2. BitDNS 就是其中一种应用，专门解决域名注册问题。

BitX 需要对比特币协议进行彻头彻尾的改造。久而久之，人们对提案的 BitX 部分失去了兴趣。后来，这个构想成为了以太坊和其它项目的核心组成部分，再度引起了人们的关注。

BitDNS 甫一出现就大受关注。这里是关于如何实现 BitDNS 的详细计划，需要将去中心化域名服务紧密集成到比特币区块链上。域名记录将被编码到普通的比特币交易中。

BitDNS 也遭到了抵制。反对者的理由是不想让比特币区块链被只有少数用户关心的数据塞满。连中本聪本人都就此发表了自己的看法：

将世界上所有基于法定人数投票制的 PoW 系统通通放入同一个数据集中会影响可扩展性。

比特币和 BitDNS 可以分开使用。我们不应该要求那些只想使用其中一个系统的用户必须将两个系统都下载下来。如果今后有其它不相关的网络想要集成到比特币上，BitDNS 用户也不见得愿意将它们的数据下载下来。

中本聪认为 BitDNS 应该有独立运行一条自己的区块链。他甚至提出了意思保护新链的方法：合并挖矿（这也是第一种合并挖矿提案）。虽然实现这一构想需要一些时间，但是 BitDNS 最终发展成了首个山寨币 Namecoin。

可编程的货币

BitDNS 之后，又有人提出了一些关于将新功能整合到比特币区块链上的方案。一部分已经实现了。但是，这些系统都面临同一个难题：缺少一个标准方法可以让交易携带数据负载。

比特币的交易比表面上看起来的要灵活和复杂得多。每个交易中都有一个用自定义语言编写的小程序或脚本。更准确地说，交易内的脚本是一个由两部分组成的脚本中的一部分。付款交易定义了一个挑战脚本（challenge script），用来设置取款条件。取款交易则提供了一个满足挑战脚本内条件的响应脚本。

全节点（例如，运行 Bitcoin Core 的节点）通过将挑战脚本和响应脚本合并成 验证脚本 的方式验证交易。验证脚本会在验证期间执行，就像一个程序那样。如果脚本运行完毕时没有报错或返回非真结果，则交易被视为有效。

显然，验证脚本提供了一种编码应用专属数据的方法，但别的技术也已经有人采用过。例如，有一种方案通过将数据写入两个付款地址来存储它们。

虽然这些方法暂时解决了将应用专属数据添加至区块链的问题，但是长期成本令人担忧。例如，区块链呈指数增长，其体积仅去年一年就翻了一番。如此增势给存储空间以及网络带宽带来了上行压力。

还有一个更严重的问题是，应用专属数据需要存储在未花费交易输出（UTXO）集内。UTXO 集包含对所有可花费比特币的引用，因此其体积越小越好，这样才方便快速进行交易验证。如果将应用数据嵌入地址或挑战脚本，每个全节点都得在 UTXO 集中添加一个引用。

OP_RETURN

验证脚本可以从多种预定义函数中进行选择。出于安全考虑，标准交易中只能有少数函数。由于矿工只能转发标准交易，很多有用的脚本函数都无法使用。（译者注：此说不准确。节点只转发标准交易，但是矿工可以挖掘任何有效的交易，即使它们不会被节点转发也可以。）

Bitcoin Core 0.9.0 新增了一个标准交易类型，解除对脚本函数 OP_RETURN 的禁用。该函数接受不超过 40 个字节的用户定义序列。如果打包上链的交易包含一个带有 OP_RETURN 函数的挑战脚本，附带的字节序列会存储到区块链上。

虽然 OP_RETURN 字节存储在区块链上，但是它们不存储在 UTXO 集合内，从而节省了稀缺资源。伴随而来的副作用是，使用了 OP_RETURN 挑战脚本的输出无法花费。因此， OP_RETURN 输出的值通常被设为 0。

（译者注：现在的 OP_RETURN 可以接受长达 80字节的数据。）

折中

OP_RETURN 及其 40 字节限制其实是对两种截然相反的比特币愿景的折中。

一方阵营认为区块链是安全的去中心化数据库，可以在上面构建大量金融和社交应用。这些新型应用的繁荣发展有助于巩固比特币的重要地位。找到一个可以让交易携带应用专属数据的标准方法有利于实现这一目标。

另一方阵营认为比特币区块链是记录电子现金付款的媒介。即便如此，可扩展性问题迟早都得解决。试图满足任意应用层的数据存储需求只会增加网络的维护成本，最终走向末日。

对 OP_RETURN 数据的 40 字节上限限制了区块链作为数据库的用途。例如，OP_RETURN 原定支持 80 字节的数据。Counterparty 是 40 字节上限的强烈反对者之一，称 40 字节不足以满足比特币区块链上的点对点市场和金融工具的需求。

但是，一个长度为 40 字节的序列足以用来对标识符（如，哈希值）进行编码。哈希值可以作为任何数字文档（包括图片、诗歌、抽象数据结构等）的唯一标识。被嵌入的哈希值可以用来将区块链链接到其它数据库，如分布式哈希表。

Bitcoin Core 0.9.0 版本说明试图阐明 OP_RETURN 的目的：

关于 OP_RETURN ：社区内部对于 0.9 版本中的 OP_RETURN 功能和区块链中的数据存有困惑和误解。对 OP_RETURN 的解禁并不代表我们支持在区块链上存储数据。 OP_RETURN 可以创建可修剪的输出，从而避免比特币的 UTXO 数据库因有些数据存储方案（其中一些已部署）将任意数据（如图片）存储为永远无法花费的交易输出而急剧增长。

在区块链上存储任意数据依然是个坏主意。将非货币数据存储在其它地方更加便宜高效。

这些说明重申了中本聪关于外部数据不应该存储在区块链上的观点。

OP_RETURN 的用途

自 2014 年 3 月引入以来，人们已经从多个方面对 OP_RETURN 进行了探索。例如，存在证明（Proof of Existence）使用 OP_RETURN 将数字文档永久链接到区块链上。Counterparty 的首席开发者宣布找到了一种可以使用 40 字节的 OP_RETURN 数据运行系统的方法。另一个依赖嵌入式数据的项目 Mastercoin 也发起了一场讨论，旨在找到使用 OP_RETURN 的方法。

隐身地址（Stealth addressers）提供了另一个 OP_RETURN 的用例。此方案可以让收款方在收款时不公开透露其公钥和地址。运行该系统所需的数据被编码到 OP_RETURN 的调用内。从本质上来说，这赋予了比特币另一个职责：作为安全的消息传递协议。

尽管 OP_RETURN 的最佳用例可能需要一段时间才能实现，但是有一点很清楚。很多比特币用户看到了将数据负载添加到交易内的价值，有的人已经开始利用 OP_RETURN 实现这一目的。

我们可以通过 Coin Secrets 监控使用 OP_RETURN 的交易。

结论

我们已经对比特币社区内关于区块链应用场景的争论作了说明。现在，应用已经可以使用 OP_RETURN 脚本函数以极低的成本将 40 字节大小的数据负载添加到交易内。从技术层面上来说，OP_RETURN 不会实现新的功能，而是提供一个可以在比特币上构建新服务的标准接口，并成为未来开发集成工具的焦点。

此举推动比特币向着解决复杂合约之需的通用平台更进了一步。比特币社区是否愿意接受这一愿景仍是个悬而未决的问题。

（完）