BitMEX Research:比特币为什么在Dapp争夺战中输给以太坊?

原文作者:BitMEX Research

原文编译:DeFi之道

摘要:在这篇文章中,我们探讨了为什么 Dapps 通常建立在以太坊而不是比特币上,我们将一直追溯到 2014 年 3 月。我们研究了关于名为 Counterparty 的 Dapp 协议是否以及如何使用比特币区块链的辩论。这有时被称为“OP_Return 之争”。我们解释了比特币中 OP_Return 使用和侧链的历史。最后,无论人们喜不喜欢,我们都认为这是 2014 年比特币开发社区的文化以及将比特币交易数据用于替代用例的负面观点,这在推动这些 Dapps 的开发人员进入以太坊等替代系统方面发挥了重要作用。

BitMEX Research:比特币为什么在Dapp争夺战中输给以太坊?

概述

我们经常被问到这样一个问题:为什么去中心化交易所等 Dapp 通常在以太坊而不是比特币上?毕竟,当然在比特币之上构建 Dapp 是可能的,例如去中心化交易所、域名系统或替代代币。这当然有几个原因,例如:i. 以太坊更灵活的原生脚本语言使得构建 Dapps 变得更容易;ii. 以太坊更快的出块时间,使 Dapps 更加用户友好,或者 iii. 比特币选择比以太坊更保守的区块大小限制,导致比特币的潜在费用更高。上述所有因素确实产生了影响,但我们认为它们的影响往往被夸大了。最重要的因素是文化。一些比特币爱好者和比特币开发者根本不希望在比特币区块链上进行此类活动,他们成功地阻止了这种活动。这似乎主要发生在 2014 年 3 月左右,而那段时间发生的事情是本文的主题。

Counterparty 协议

正如我们在 2020 年 9 月的报告中提到的,在 2014 年初,Counterparty 推出。Counterparty 是比特币之上的一个协议层,它支持诸如创建新代币和在分布式交易所交易这些代币等功能。该系统通过使用部分比特币交易数据并在交易对手协议中使用它作为一项功能来工作,例如创建代币、发送代币或在分布式交易所上对代币进行市场投标。

更简洁地说,一开始,Counterparty 使用比特币操作码 OP_CHECKMULTISIG 将 Counterparty 相关数据包含到比特币区块链中。该操作码本应用于验证支付脚本哈希 (P2 SH) 多签名交易的签名。可以在此处查看 2014 年 7 月的 Counterpaty 交易示例。该交易将比特币发送回它来自的地址,并且还具有三个额外的输出,其中输出脚本是与交易对手协议相关的数据。在这种情况下,它是创建一个名为 TICKET 的新代币。使用 OP_CHECKMULTISIG 可以被认为是一种 hack,因为这不是操作码的预期用途。Counterparty 现在使用比特币的 OP_Return 操作码来存储数据,这在某种程度上更符合开发人员的意图。例如,请参阅这个更新的 Counterparty 交易,它使用 OP_Return。

在 2014 年初,围绕 Counterparty 进行了大量的实验、开发者活动、创新和兴奋,其领先于一个名为 Mastercoin 的竞争对手平台。

什么是 OP_Return?

OP_Return 是比特币中可证明不可花费的交易输出。该功能可用于燃烧比特币或在比特币区块链中存储任意数据。由于数据不是 UTXO 集的一部分,因此据说以这种方式存储数据有助于扩展比特币,因为参与剪枝的节点不需要存储 OP_Return 数据。

比特币的共识规则允许最大 10,000 字节的 OP_Return 大小。例如,2013 年 5 月,有人在以下交易中利用了此功能。此交易中的 OP_Return 输出包含 Rick Astley 1987 年歌曲“Never Gonna Give You Up”的歌词,该歌曲与 Rickrolling meme 相关。

在 2014 年之前,包含 OP_Return 的交易是非标准的,不被普通比特币节点中继。但是,如果矿工包含这些交易,则它们被认为是有效的。2014 年 3 月,Bitcoin Core 0.9.0 发布,其中包含 OP_Return 功能作为标准交易类型,因此交易将默认中继。当时的发行说明如下:

此更改不是对在区块链中存储数据的认可。OP_RETURN 更改创建了可证明可修剪的输出,以避免数据存储方案(其中一些已经部署)将任意数据(例如图像)存储为永远不可用的 TX 输出,从而使比特币的 UTXO 数据库膨胀。在区块链中存储任意数据仍然是个坏主意;将非货币数据存储在其他地方成本更低,效率更高。

来源:https://bitcoin.org/en/release/v0.9.0#opreturn-and-data-in-the-block-chain

Bitcoin Core 0.9.0 只会中继 OP_Return 为 40 字节或更少的交易,如果数据大于此,它仍然是有效的交易,但不会被中继。最初的限制是 80 字节,但经过多次争论,开发人员最终选择了 40 字节。

2016 年,Bitcoin Core 0.11.1 最终将中继限制增加到 80 字节,并在 2016 年底的 Bitcoin Core 0.12.0 版本中增加到 83 字节,即我们今天的限制。这意味着,如果今天想要一笔 OP_Return 输出超过 83 字节的交易,则必须自己挖掘区块或直接发送给矿工。

OP_Return 战争

2014 年 3 月 20 日,当时比特币的主要贡献者之一 Jeff Garzik 开始在 Bitcointalk 论坛的 Counterparty 版块上发帖。Jeff 批评了 Counterparty 对区块链空间的使用。

迄今为止,我还没有看到无法用简单的哈希安全替换的区块链数据转储方案。您不需要将数据存储在区块链中。那纯粹是智力上的懒惰。时间戳哈希(数据)同样安全,同时更有效。此外,一条二级链可以被证明与比特币挂钩:

来源:https://bitcointalk.org/index.PHP?topic=395761.msg5796379#msg5796379

Jeff 接着说:

CheckMultiSig 显然适用于 ECDSA 公钥,而不是任意数据。将操作用于其预期目的以外的某些事情会产生负面的、可能是意外的或未知的后果,这不足为奇。Counterparty 交易不是“根据比特币协议”,它们会通过,因为它从未期望以这种方式使用该功能。

来源:https://bitcointalk.org/index.PHP?topic=395761.msg5827189#msg5827189

有人可能会认为 Jeff 有这种观点很奇怪,因为在 2017 年他似乎是“大区块支持者”,而且这种关于保守使用区块空间的观点似乎与大区块观点不一致。然而,这种明显的矛盾在 2014 年根本没有出现。当时 Jeff 的观点在一定程度上得到了当时几乎所有活跃的开发者的认同,包括后来成为大区块头头的那些。据我们所知,人们对区块大小限制的看法和这个问题之间根本没有简单的映射。Jeff 当时是一位备受尊敬的开发人员,这篇文章引起了 Counterparty 开发人员和用户的极大关注。

一位化名为“BitcoinTangibleTrust”的 Counterparty 开发人员回复 Jeff 如下:

你是绝对正确的。您不需要将数据存储在区块链中。时间戳哈希(数据)同样安全,同时更有效。一条二级链可以被证明与比特币挂钩。然而,根据下面 PhantomPhreak 的 [Counterparty 联合创始人和首席开发人员] 的说明,Counterparty IS 在每三个多重签名交易之一中使用 256 个字节在区块链中存储数据。此外,所有这些多重签名交易都由矿工处理。

开发人员继续批评比特币开发人员计划将 OP_Return 限制为 40 字节而不是 80 字节:

如果 OP_RETURN 旨在停止/减少多重签名行为(未使用的输出)并因此减少区块链膨胀,那么我担心通过将 OP_RETURN 的大小从 80 字节减少到 40 个字节,您会无意中使多重签名对所有元协议更具吸引力,而您 ' 已经使 OP_RETURN 的吸引力降低了。

名为“PhantomPhreak”的首席 Counterparty 开发人员和联合创始人插话道:

这个想法是我们将数据存储在第二个区块链中,并将该时间戳数据的哈希值放入比特币中,这些哈希值也将小于 40 字节。我们没有这样做的原因不是“智力上的懒惰”,而是实现的复杂性。Counterparty 不是计算机科学的项目;为了提高开发速度,它被设计得尽可能简单。即使我们必须将数据存储在多重签名输出中,而不是太小的 OP_RETURN 输出中。在这个领域,更糟肯定更好。

第二天 Jeff 回应:

这就是搭便车。鉴于绝大多数(>90%)比特币区块链的应用是货币使用,使用全节点作为哑数据存储终端只是在滥用全自愿网络资源。网络复制交易数据,为什么不搭便车呢?mastercoin 和 Counterparty 并没有参与现有的社区,而是简单地按下“开启”开关并开始使用比特币 P2 P 节点作为不需要的数据存储。未使用的交易输出决不打算用作任意数据存储。它可以被滥用的事实并不能使它正确,或远程有效,或最佳解决方案。UTXO(未使用的交易输出)数据库是全网的快速访问数据库。每个节点都需要该数据库尽可能小,以便最好地处理网络事务。将任意数据编码为未使用的输出是网络范围内的滥用,简单明了。整个网络承担这个代价。

来源:https://bitcointalk.org/index.PHP?topic=395761.msg5815887#msg5815887

由于 Jeff 在社区中的地位很高,Counterparty 社区中的大多数人似乎都热衷于参与并解决该问题。例如,BitcoinTangibleTrust 回应说:

感谢您分享您的想法,Jeff。那么,你会帮助我们开始与现有的比特币核心开发社区互动吗?充当负责任的合作伙伴符合 Counterparty 的利益,因为如果我们要生存,我们就需要比特币区块链。您能告诉我们如何开始就这些问题开展合作吗?

来源:https://bitcointalk.org/index.PHP?topic=395761.msg5816031#msg5816031

另一位 Counterparty 开发人员提出了另一点:

比特币协议有没有办法阻止 XCP 使用它的方式,而不会破坏其他任何东西?

如果比特币开发者没有办法阻止交易对手相关交易,或许这种反对并不重要,Counterparty 可以在未经许可的情况下继续使用比特币。比特币开发商和当时的矿池运营商 Luke-Jr 随后进入了辩论:

矿工应该过滤掉滥用行为。

来源:https://bitcointalk.org/index.PHP?topic=395761.msg5816503#msg5816503

Luke-Jr 然后建议可以使用合并挖掘的侧链类型结构来构建这些类型的系统,这可以避免区块链膨胀。

问题不在于新的层,而是违背人们的意愿强加于人。新层可以在选择加入的基础上完成,而不会污染区块链并迫使非参与者存储数据。

Luke 还被问到为什么比特币开发人员将预期的 OP_Return 中继大小减少到 40 字节,而最初提出的限制是 80 字节。Luke 回应了以下三点:

  1. 太多的人认为 OP_RETURN 是一个功能,应该被使用。它从来没有这样的意图,只是一种“让窗户保持解锁状态,这样当有人闯入时我们不需要更换玻璃”的方式。也就是说,减少人们滥用比特币造成的损害。

  2. 40 个字节足以满足将数据绑定到交易的所有合法需求:您获得 32 个字节用于哈希,再加上 8 个字节用于某种唯一标识符(这实际上也没有必要!)。

  3. 最初的 80 字节提案旨在用于 512 位哈希,但被确定为没有必要。

Luke-Jr 继续说道:

希望随着挖矿回归去中心化,我们将看到对滥用/垃圾邮件交易的容忍度降低,无论是 OP_RETURN 变体还是其他变体。现在,如果有人有一个有效的、必要的用例来实际存储带有交易的哈希值,那么显然矿工应该认真考虑挖矿。

来源:https://bitcointalk.org/index.PHP?topic=395761.msg5817170#msg5817170

Luke 当时的矿池也开始过滤掉 Counterparty 相关的交易。此时恐惧和不确定性开始在 Counterparty 社区中建立。他们需要 OP_Return 为 80 字节,否则他们将被迫继续使用 OP_CHECKMULTISIG 操作码。鉴于 Luke 的评论,它似乎不太可能达到 80 字节。除此之外,一些人担心开发人员甚至会进一步降低限制,可能会导致 Counterparty 脱离网络。比特币开发者似乎对 Counterparty 不是特别友好,因此有些人可能认为继续使用比特币协议可能很困难。

2014 年 3 月 25 日,以太坊的主要创始人 Vitalik Buterin 插话,他认为辩论应该更多地围绕费用,如果你支付足够的费用,那么你的交易应该被合法地包括在区块内。今天,以太坊的费用算法非常复杂,对于许多不同的区块链用途有不同的费用桶和费率,这从根本上解决了 OP_Return 问题。有人可以争辩说,比特币上的 SegWit 也在一定程度上缓解了这个问题。

这是协议的错误,OPRETURN 战斗就是这样一个问题。在理想的世界里,“虐待”的概念根本不存在;费用将是强制性的,并经过精心设计,以密切匹配给定交易对网络施加的实际成本,”他说。“如果你可以为你正在做的事情支付费用,那么你应该能够做到,不问任何问题。”

来源:https://www.coindesk.com/markets/2014/03/25/developers-battle-over-bitcoin-block-chain/

2014 年 3 月 27 日,Counterparty 改变了交易方式以绕过 Luke-Jr 的挖矿过滤器。然而,第二天 Luke 评论说:

好消息!在不到 5 分钟的时间内以及 1 行代码,就可以添加过滤器以阻止这种无用的东西。

来源:https://bitcointalk.org/index.PHP?topic=395761.msg5955613#msg5955613

Luke-Jr 还将 Counterparty 比作一种滥用形式:

这是滥用行为,因为您强迫他人根据他们的自由选择下载/存储您的数据。每个完整节点都必须下载完整的区块链(可修剪与否!)。每个完整节点都同意下载和存储金融交易。并非每个完整节点都同意存储其他任何内容。为此,您需要 100% 的共识,而不仅仅是某些子集(即,不是矿工;不是开发人员)甚至是多数。此外,每个人都可以自由存储不在区块链中的数据。把它放在区块链中没有任何好处,只是你把它强加给那些不想要它的人。你来解释这怎么就不是滥用……

来源:https://bitcointalk.org/index.PHP?topic=395761.msg5826443#msg5826443

对比特币开发者的愤怒

正如人们所预料的那样,比特币开发者的担忧最终遭到了一些 Counterparty 开发者和用户的沮丧和愤怒。我们在下面包含了他们的一些评论。首先来自一个名为“porqupine”的用户评论 Luke-Jr 的矿池阻止 Counterparty 交易:

与其负责任地致力于寻找解决方案的开发人员相比,这很好——你在宣传猫捉老鼠游戏。你意识到你也在说网络中立?并试图将人们应该和不应该在区块链上进行的交易交到私人手中。对您不喜欢的某些人的下一步制裁是什么?在您不赞成政府外交政策的国家/地区的节点广播交易的制裁?

来源:https://bitcointalk.org/index.PHP?topic=395761.msg5955738#msg5955738

2014 年 3 月 21 日,porqupine 继续说:

等一下,当它决定:每个节点都同意存储 X 类型数据而不是 Y 类型数据时。也许我也不同意存储洗钱、非法毒品和武器、人类奴役等交易。你基本上是在否定协议中立性,并决定协议应该和不应该用来存储什么,而不仅仅是你 ' 不是以第一人称说话,而是使用代词 Us,给人的印象是你是在代表所有矿工或协议用户作为一个整体说话。

来源:https://bitcointalk.org/index.PHP?topic=395761.msg5826584#msg5826584

其他人表示担心为什么 Jeff 和 Luke 有权越过其他人来阻止某些用例。

我无法相信这种态度。我不知道比特币有所有者。我以为我和大约一百万其他人是所有者

如有疑问联系邮箱:微信:ETH_88889
*本文转载自网络转载,版权归原作者所有。本站只是转载分享,不代表赞同其中观点。请自行判断风险,本文不构成投资建议。*