记录 | 以太坊协议的历史

（提示：由于本文包含大量链接，建议您点击阅读原文以获得更好的阅读体验。）

虽然当前以太坊协议背后的想法在两年内基本稳定，但以太坊当前的概念和形式并非一次性事件。 该协议在区块链推出之前经历了一些重大的演变和设计决策。 本文的目的是讨论协议从开始到发布的演变过程； 但是，我不会提及在协议实现方面所做的无数工作，例如 Geth、cppethereum、pyethereum 和 EthereumJ，以及以太坊生态系统中的应用程序和企业。 历史。

本文中也没有提到 Casper 和分片研究的历史。 我们当然可以在博客上更多地介绍 Vlad、Gavin、我自己和其他人提出并最终放弃的各种观点，包括“工作量证明”、轴辐式链）、“超立方体”、影子链（可以说是前身到 Plasma）、链式纤维和 Casper 的各种迭代，以及 Vlad 关于共识协议的动机和属性的推理思想的快速演化。 在博客文章中讨论这些内容太复杂了，所以我们不会在这里进一步讨论它们。

让我们从最早的版本开始，它最终成为以太坊，但当时甚至不叫以太坊。 当我在 2013 年 10 月访问以色列时，我花了很多时间与 Mastercoin 团队在一起，甚至向他们推荐了一些功能。 在花了一些时间思考他们做了什么之后，我向团队提出了一个建议，那就是让他们的协议更通用，能够支持更多类型的合约，而无需添加同样庞大而复杂的功能集：

://vbuterin.com/ultimatescripting.html

请注意，这个版本与后来更广泛的以太坊版本有很大不同：它纯粹关注 Mastercoin 当时试图做的事情，即双方合约，这意味着 A 和 B 双方都将投入资金，并且然后根据合同规定了一些公式，他们可以从中取钱（例如，一个赌注写着“如果X发生，所有的钱都给A，否则给B”）。 脚本语言不是图灵完备的。

Mastercoin 团队印象深刻，但他们没有兴趣放弃他们所做的一切并朝这个方向前进，我越来越觉得这是正确的选择。 然后，大约在 12 月，我更新了第二个版本：

https://vitalik.ca/ethereum.html

在这里你可以看到大量重构的结果，这主要是我 11 月在旧金山散步的结果，当时我意识到智能合约有可能完全推广。 合约本身是一个完整的账户，而不是像脚本语言那样简单地描述双方之间的关系。 合约具有持有、发送和接收资产的能力，甚至可以保持永久存储（当时永久存储被称为“内存”，而这唯一的临时“内存”是256个寄存器）。 语言从基于堆栈的机器转变为基于寄存器的任性机器； 我对此没什么意见，只是它看起来更复杂。

另外可以注意到，这个版本还内置了收费机制：

在这个阶段，Ether 的字面意思是气体； 每计算一步，交易调用的合约余额都会减少一些，如果合约余额耗尽，将停止执行。 注意，这种“接收者付费”机制是指合约本身要求发送者必须向合约支付费用或立即退出执行； 该协议分配了 16 个自由执行步骤的权限，以允许合约拒绝交易。

上述阶段的以太坊协议完全是我自己创造的。 然而，从这里开始，新玩家开始加入。 到目前为止，在协议方面最突出的是 Gavin Wood，他于 2013 年 12 月开始通过网站上的私人消息在 about.me 上与我联系。

Go 客户端（当时称为“ethereal”）的首席开发人员 Jeffrey Wilcke 大约在同一时间联系了我并开始编程。 他在客户端开发方面的贡献比协议研究更多。

“嗨杰里米，很高兴看到你对以太坊的兴趣”

加文早期的贡献是双重的。 首先，你可能会注意到最初设计时的合约调用模型是异步的：而合约A可以创建一个“内部交易”给合约B（“内部交易”是以太坊的行话，最初只是称为“交易”，后来“消息调用”或“调用”），但内部事务直到第一个事务完全完成后才开始执行。 这意味着这意味着交易不能使用内部交易作为从其他合约获取信息的方式； 唯一的方法是使用 EXTRO 操作码（类似于 SLOAD，您可以使用它来读取其他合约存储的内容），后来被 Gavin 和其他人支持 以下被删除。

在实现我最初的规范时，Gavin 自然地同步了内部交易，甚至没有意识到它与最初的设计不同——也就是说，在 Gavin 的实现中，当一个合约调用另一个合约时，内部交易立即执行，一旦执行完成，虚拟机返回创建内部交易的合约并转到下一个操作码。 这种方法似乎对我们双方都有好处，所以我们决定将其作为规范的一部分。

然后，我和他之间的一次讨论（那是在旧金山散步时发生的，所以确切的细节将在历史的洪流中丢失，但也可能存在于 NSA 的深层档案中的一两个文件中）打开了 Restructured the交易手续费模式，从“合约支付”方式转向“发送方支付”方式，切换到“gas”架构。 不是在执行每个单独的交易步骤后立即消耗一点以太币，而是向交易发起者支付并分配一些来自气体津贴的“气体”（大致是计算步骤的计数器）。 如果没有足够的 gas 进行交易，剩余的 gas 仍将被没收，但整个执行将被恢复； 这似乎是最安全的做法，因为它消除了您之前不得不担心的整个“部分执行”类型的攻击。 交易执行完成后，将退还任何未使用的汽油费。

Gavin 还为以太坊逐渐成为一个平台做出了巨大贡献，该平台使用基于区块链的合约构建可编程货币，持有数字资产并根据预设规则将其转移到通用计算平台。 这种变化始于焦点和术语的微妙转变，此后随着对“Web3”集成的日益重视而加剧，它将以太坊视为一套分布式技术的一部分，另外两个是 Whisper 协议和 Swarm 协议。

2014年初，也根据别人的建议做了一些改动。 在 Andrew Miller 等人提出这个想法后，我们最终回到了基于堆栈的架构。

Charles Hoskinson 建议从比特币的 SHA256 切换到更新的 SHA3（或更准确地说，keccak256）。 虽然一直存在争议，但最终还是由Gavin、Andrew等人讨论决定。 堆栈中值的大小应限制为 32 个字节； 另一个考虑过的替代方案是无限整数，该解决方案的一个问题是很难计算加法、乘法和其他运算所需的气体量。

我们首先想到的挖矿算法，可以追溯到 2014 年 2 月，是一个叫做 Dagger 的东西：

Dagger 以“有向无环图”（DAG）命名，这是算法中使用的一种数学结构。 Dagger 的思想是每 N 个区块从种子值生成一个伪随机 DAG。 DAG 的底层将是需要数 GB 存储空间的节点集合。 然而，在 DAG 中生成任何单个值只需要计算几千个条目，而“计算匕首”包括在这个最低级别的数据集中生成一系列随机数以太坊交易信息获取，然后对它们进行哈希处理。 这意味着有一种快速的方法可以进行 Dagger 计算——已经将数据存储在内存中，还有一种速度较慢但内存不紧张的方法——从 DAG 中重新获取每个数据，而不是从其他节点下载。

该算法的目的是与当时流行的算法一样具有“内存困难”的特性，就像Scrypt算法一样，并且要求对轻客户端友好。 矿工会采用快速的方式，所以他们的挖矿速度会受到内存带宽的制约（理论上普通内存已经很优化了，所以很难在ASIC上进一步优化），但是轻客户端会在一个没有内存限制的慢 CPU 环境。 快速方式可能需要几微秒，但慢速无界方式可能需要几毫秒，因此对于轻客户端也是可行的。

从那时起，该算法在以太坊的发展过程中经历了几次重大变化。 我们接下来的想法是“自适应工作量证明”，其中工作量证明涉及执行随机选择的以太坊合约，它抗 ASIC 的原因非常聪明：如果应用 ASIC，竞争矿工有一个激励创建和发行 ASIC 不擅长计算的合约。 没有 ASIC 可以用于通用计算。 故事还在继续，因为它只是一个 CPU，我们可以使用这种对抗性激励机制来使用通用计算来做本质上是工作量证明的事情。

这个想法被拒绝的原因很简单：远程攻击。 攻击者可以从区块1开始一条链，填充简单的合约，而这种合约比较特殊，可以为其创建专门的硬件，从而使这条链能够快速超越主链。 所以。 . . . 回到起点。

下一个算法称为随机电路，在这篇谷歌文档中有详细描述，该文档由我和 Vlad Zamfir 提出，并由 Matthew Wampler-Doty 和其他几个人分析。 我们这里的想法是模拟挖矿算法中的普通计算，模拟的方法是执行一些随机生成的电路。 这里没有任何确凿的证据表明这些原则不起作用，但我们在 2014 年咨询的计算机硬件专家中没有一个对此持乐观态度。 Matthew Wampler-Doty 提出了基于 SAT 的 POW 机制，但最终没有奏效。

最后，我们投身于“Dagger Hashimoto”算法以太坊交易信息获取，简称“Dashimoto”，它大量借鉴了 Thaddeus Dryja 开创的工作量证明机制 Hashimoto，它开创了“I/O-bound”工作量证明概念，其中挖掘速度的主要限制因素不是散列速度，而是每秒可访问的 RAM 兆字节数。但是，Dagger Hashimoto 将上述工作量证明机制与 Dagger 的概念相结合轻客户端友好的 DAG 生成数据集。经过我、Matthew、Tim 和其他人的多次调整，这些想法最终融合到我们现在称为“Ethash”的算法中。

到 2014 年夏天，协议已经相当稳定，除了 Ethash 工作量证明算法，直到 2015 年初才完成，半正式的规范已经以 Gavin 的黄皮书形式发布。

2014年8月，我开发并引入了叔叔机制，使得以太坊区块链在降低中心化风险的同时，拥有更短的出块时间和更高的容量。 PoC6 发布了叔叔机制的引入。

我们和Bitshare团队讨论过，我们考虑过使用堆作为主要的数据结构，但是由于时间紧迫，我们最终没有这样做，后来的安全审计和DoS攻击表明，它在安全性上其实更安全比我们当时想象的要灾难。

9 月，Gavin 和我计划对协议设计进行以下两项重要更改。 首先，每个区块除了状态树和交易树之外，还会包含一个“收据树”。 收据树将包含每个交易的所有交易日志的哈希值，以及中间状态根。 交易日志允许交易创建可以保存在区块链上的输出，轻客户端可以访问这些输出，但未来的状态计算无法访问。 这可用于分布式应用程序轻松查询交易，例如令牌传输、购买、正在创建和执行的交易票、正在进行的拍卖等。

我们还有一些其他的想法，比如从整个交易执行中提取 merkle 树来证明任意事物。 在权衡了简单性和完备性之后，我们选择了日志，.

二是预编译的思想，它解决了让复杂的加密计算在以太坊虚拟机中可用的问题，而不必处理虚拟机的开销。 我们也经历了很多关于“原生合约”的雄心勃勃的想法，如果矿工对某些合约有更优化的执行方式，他们会“投票”降低gas费，所以对于大多数矿工可以快速执行的合约来说，gas成本自然会更低; 然而，所有这些想法都被拒绝了，因为我们无法想出一种加密经济安全的方式来实现它。 攻击者可以随时创建一些合约来进行主动加密操作，然后将陷阱门分发给自己和朋友，这样可以更快地执行合约，从而降低gas price，进行DoS攻击。 相反，我们选择了一种不太雄心勃勃的方法，即在协议中简单地指定少量预编译器，例如用于哈希和签名方案等常见操作。

Gavin 也是“协议抽象”背后的最初关键人物。 协议抽象就是将协议的很多部分，如以太坊余额、交易签名算法、Nounce（一次性随机数）等，作为合约迁移到协议本身中，理论上最终要达到的目标是实现一个状态：整个以太坊协议可以描述为一个状态，在这个状态下，一个函数调用函数被添加到一个具有某种预初始化状态的虚拟机中。 我们没有足够的时间在最初的 Frontier 中实现所有这些想法，但这些原则有望通过君士坦丁堡分叉、Casper 合约和分片规范逐渐融入其中。

这一切都是在 PoC7 中实现的，之后协议除了一些小的变化外没有太大变化，尽管在某些情况下相对重要。 这些详细信息将在通过安全审核后呈现给您。

2015 年初，Jutta Steiner 等人。 组织发布前的安全审计，包括软件代码审计和学术审计。 软件代码审计主要用 C++ 和 Go 实现，分别由 Gavin Wood 和 Jeffrey Wilcke 领导。 其实我的Pyethereum实现也有一个简单的审计。 在两次学术审计中，一次由 Ittay Eyal（以提出“自私挖矿”攻击而闻名）进行，另一次由 Andrew Miller 和 Least Authority 的其他成员进行。 通过Eyal审计，我们对协议做了一个小改动，链的难度值不包括叔节点。 第二次审计的重点是智能合约、合约费用和帕特里夏树。 我们还通过此次审核对协议进行了多项更改。 一种是直接使用sha3(addr)和sha3(key)作为键，而不是直接使用地址和键； 这将使对树进行最坏情况下的攻击变得更加困难。

有一个警告可能有点超前。 . . . . .

我们讨论的另一个重要问题是 gas limit 投票机制。 当时，我们已经担心比特币区块大小的讨论缺乏进展，并希望在以太坊中有一个灵活的设计，可以根据需要进行调整。 但这里的挑战是：最好的约束是什么？ 我最初的想法是做一个动态限制，它是实际 gas 使用的长期指数移动平均线 (EMA) 的 1.5 倍，这样从长远来看，区块平均有 2/3 满。 但是，Andrew 证明可以通过某些方式利用此限制，具体而言：想要提高限制的矿工，他们只需要发送需要大量气体但需要很少处理时间的交易。 都包含在自己的区块中，从而创建一个完整的区块而不会对自己造成损失。 因此，这种机制的安全模型相当于只是让矿工对gas limit进行投票，这可能不如矿工投票。

我们没有想出更好的 gas limit 策略。 Andrew的建议是明确让矿工对gas limit进行投票，默认为EMA投票规则的1.5倍。 原因是我们还不知道设置最大 gas 限制的具体方法，这样做的风险似乎远高于矿工滥用投票权的风险。 因此，我们还不如让矿工直接对gas limit进行投票，接受gas limit过高或过低的风险。 这样可以更加灵活，矿工也可以联合起来，根据需要快速调整gas limit。

在与 Gavin 和 Jeff 进行了一次小型黑客马拉松之后，PoC9 于 3 月推出，旨在成为最终的概念证明。 我们使用将在真实网络中使用的协议运行了一个名为 Olympic 的测试网四个月，并为以太坊制定了长期计划。 Vinay Gupta 写了一篇博客文章“以太坊的演变”，描述了以太坊发展的四个预期阶段，并将它们命名为：Frontier、Homestead、Metropolis 和 Serenity（和平）。

奥运会运行了 4 个月。 前两个月，在各种实施中发现了很多错误，并出现了共识失败，但到 6 月左右，网络已经明显稳定下来。 我们决定在 7 月冻结代码，然后在 7 月 30 日首次发布。

原文链接：