以太坊开发社区在以太坊的早期阶段做出了许多决定，这些决定对项目的发展轨迹产生了巨大的影响。在某些情况下，以太坊开发者有意识地做出决定，在我们认为比特币存在问题的地方进行改进。在其他地方，我们正在创造一些全新的东西，我们只是必须想出一些东西来填补空白，但有很多东西可以选择。还有一些地方，我们需要在更复杂和更简单的东西之间进行权衡。有时候，我们会选择比较简单的东西，但有时候，我们也会选择比较复杂的东西。

这篇文章将着眼于我记忆中以太坊的这些路线岔路口。许多这些功能在核心开发圈内被认真讨论过；有些几乎没有被考虑过，但也许真的应该考虑一下。但即便如此，我们还是有必要看看一个不同的以太坊会是什么样子，以及我们可以从中学到什么。

我们是否应该采用更简单的 PoS 机制？

以太坊即将合并的 Gasper PoS 机制是一个复杂的系统，但也是一个非常强大的系统。它的一些属性包括：

非常强大的单区块确认：一旦交易被纳入区块，通常在几秒钟内，该区块就会被最终确定，除非有很大一部分节点是不诚实的，或者有极端的网络延迟，否则它是无法被逆转的。

经济最终性：一旦一个区块被最终确认，它就不能被逆转，除非攻击者能顶住损失数百万 ETH 被罚没。

非常可预测的奖励：验证者在每个 epoch（6.4 分钟）都能可靠地获得奖励。

支持非常高的验证器数量：与其他大多数具有上述特性的链不同，以太坊信标链支持数十万个验证器（例如：Tendermint 提供了比以太坊更快的最终性，但它只支持几百个验证器）

但是创造一个具有这些特性的系统是困难的。这需要数年的研究，数年的失败实验，通常需要大量的努力，最终的输出相当复杂。

如果我们的研究人员不需要担心那么多的共识，有更多的空闲思考时间，那么也许，只是也许，rollups 可以在 2016 年被发明出来。这就引发了我们的一个思考：我们真的应该对我们的 PoS 要求如此高的标准吗？因为即使是一个更简单和更弱的 PoS 也会比 PoW 的现状有很大的改进。

许多人有一个误解，认为 PoS 本身就很复杂，但实际上有很多 PoS 算法几乎和 中本聪 PoW 共识一样简单。NXT 的 PoS 自 2013 年以来就存在，本来也是一个现成的候选；虽然它存在一些问题，但这些问题很容易被修补，我们可以从 2017 年，甚至从一开始就有一个合理可行的 PoS。Gasper 之所以比这些算法更复杂，只是因为它试图完成的任务比它们多得多。但是，如果我们在一开始就不要好高骛远，我们可以先专注于实现一套更有限的目标。

在我看来，从一开始实施 PoS 是一个错误；PoW 对于扩大初始发行量分发和使以太坊更具可访问性方面是有帮助的，并且能够鼓励爱好者社区。但在 2017 年，甚至 2020 年，改用更简单的 PoS，可能会导致更少的环境破坏（以及因环境破坏而产生的反加密货币心态）,并有更多的研究人才可以自由思考扩展问题。我们最终会不会不得不花费大量的资源来制作一个更好的 PoS 呢？我看还是会的，但现在看来，无论如何，我们最终都会这样做。

分片的去复杂化

以太坊分片自 2014 年开始研究以来，一直在朝着越来越不复杂的方向发展。首先，我们有内置执行和跨分片交易的复杂分片；然后，我们通过将更多的责任转移给用户来简化协议，在跨分片交易中，用户必须分别为两个分片支付 Gas 费用；接着，我们切换到以 Rollup 为中心的路线图，其中，从协议的角度来看，分片只是数据分片。最后，通过 danksharding，分片费用市场被合并成一个整体，最终的设计看起来就像一个非分片链，但在这里，数据可用性采样能够实现分片验证。

但如果我们走的是相反的道路呢？实际上有一些以太坊的研究人员，他们深入探索了一个更复杂的分片系统：分片将作为链，会有分叉选择规则，其中子链依赖于父链，跨分片消息将由协议路由，验证器将在分片之间轮换，甚至 DApp 将在分片之间自动获得负载平衡。

这种方法的问题是：这些形式的分片在很大程度上只是想法和数学模型，而 Danksharding 是一个完整的、几乎可以实施的规范。因此，鉴于以太坊的情况和限制，在我看来，分片的简化和去歧义化绝对是正确之举。也就是说，更雄心勃勃的研究也有非常重要的作用：它确定了有前途的研究方向，即使是非常复杂的想法往往也有 "合理的简单 "版本，这些想法仍然提供了很多好处，而且很有可能在未来几年内大大影响以太坊的发展（甚至是二层协议）。

EVM 中功能的选择

现实上，除了安全审计之外，EVM 的规范基本上在 2014 年中期就可以推出。然而，在当时接下来的几个月里，我们继续积极探索我们认为可能对去中心化区块链真正重要的新功能。有些功能加进 EVM 了，有些没有。

我们曾考虑增加一个 POST 操作码，但决定不这样做。POST 操作码会进行异步调用，会在交易完成后被执行。

我们曾考虑过添加一个 ALARM 操作码，但决定不这样做。ALARM 的功能类似于 POST，只是在未来的某个块中执行异步调用，允许合同安排操作。

我们添加了日志（logs），它允许合约输出不触及状态的记录，但可以被 DApp 接口和钱包解释。值得注意的是，我们也考虑过让 ETH 转账发出日志，但决定不这样做，理由是 "反正人们很快就会转到智能合约钱包"。

我们考虑过扩大 SSTORE 以支持字节数组，但由于担心复杂性和安全性而决定不这样做。

我们增加了预编译（precompiles），这是一种使用本地实现执行专用加密操作的合约，比在 EVM 中执行要便宜得多。

在上线后的几个月里，我们反复考虑了状态租金（state rent），但从未包括在内。这实在是太复杂了。今天，人们正在积极探索更好的状态过期（state expiry）方案，尽管无状态验证和提议者/构建者分离（PBS）意味着它现在是一个低得多的优先级。

如今来看，大多数不增加功能的决定都被证明是非常好的决定。没有明显的理由来增加一个 POST 操作码。ALARM 操作码实际上是很难安全实现的：如果 1...9999 区块中的每个人都设置了一个 ALARM，在 100000 区块执行大量的代码，会发生什么？那个区块会不会花几个小时来处理？一些预定的操作会被推到后面的区块吗？但是如果这种情况发生了，那么 ALARM 还能保留什么保证呢？字节数组的 SSTORE 很难安全地做到，而且会大大扩展最坏情况下的见证大小。

状态租金问题更具挑战性：如果我们从第一天起就真正实现了某种状态租金，以太坊就不需总是围绕持久化状态的正常化假设而发展。以太坊会更难构建，但它可能会更有扩展性和可持续性。同时，我们当时的状态过期计划确实比我们现在的要差得多。有时候，好的想法就是要花上几年的时间才能达成，没有更好的办法。

LOG 的备选方案

LOG 可以通过两种不同的方式来完成。

我们可以让 ETH 转账自动发出一个 LOG。这将为交易所和许多其他用户节省大量的精力和软件错误问题，并将加速每个人对 LOG 的依赖，这将有助于智能合约钱包的采用。

我们完全可以不需要 LOG 操作码，而把它变成一个 ERC：会有一个标准合约，它有一个函数 submitLog，并使用以太坊存款合约的技术来计算该区块中所有日志的 Merkle 根。无论是 EIP-2929 还是区块范围的存储（相当于 TSTORE，但在区块之后被清除）都会使这个便宜。

我们强烈考虑过第一种方式，但拒绝了它。主要原因是，日志只来自于 LOG 操作码，这更容易。我们还非常错误地预计大多数用户会迅速迁移到智能合约钱包，这可以明确使用操作码来记录转账。

我们没有考虑第二种方式，但回过头来看，这其实也是一个选择。第二种方式的主要缺点是缺乏一个快速扫描日志的布隆过滤器机制（Bloom filter）。但事实证明，布隆过滤器机制太慢了，对 DApp 来说并不友好，所以现在越来越多的人使用 TheGraph 来进行查询。

总的来说，这些方法中的任何一种都有可能优于现状。不纳入 LOG 会使事情更简单，但如果纳入 LOG，自动记录所有 ETH 的转移会使它更有用。

今天，我可能会赞成最终取消 EVM 的 LOG 操作码。

如果当前 EVM 选择了完全不同的路，会怎样？

当初 EVM 有两条非常不同的路可以选：

使 EVM 成为一种更高级的语言，具有变量、if 语句、循环等内置结构。

使 EVM 成为某些现有虚拟机（LLVM、WASM 等）的副本。

第一条路从未被真正考虑过。这条路的吸引力在于，它可以使编译器更简单，并允许更多的开发者直接在 EVM 中编码。它还可以使 ZK-EVM 的结构更加简单。这条路的弱点是它会使 EVM 代码在结构上更加复杂：它不再是一排简单的操作码列表，而是一个更复杂的数据结构，必须以某种方式进行存储。也就是说，我们错过了一个两全其美的机会：一些 EVM 的改变可以给我们带来很多好处，同时保持基本的 EVM 结构不变：禁止动态跳转，增加一些旨在支持子程序的操作码（另见：EIP-2315），只允许在 32 字节的字边界访问内存等等。

第二条路被建议过很多次，也被拒绝过很多次。支持它的论点通常是，它将允许程序从现有语言（C、Rust 等）编译到 EVM 中。反对的观点一直是，鉴于以太坊独特的限制，它实际上不会提供任何好处：

现有的高级语言的编译器往往不关心总的代码大小，而区块链代码必须大量优化以减少每一个字节的代码大小。

我们需要虚拟机的多种实现，并严格要求两个实现不能以不同方式处理相同的代码。在我们没有编写的代码上进行安全审计和验证会更难。

如果虚拟机规范发生变化，以太坊将不得不始终与它一起更新，或者越来越不同步。

因此，EVM 可能永远不会出现与我们今天所拥有的完全不同的可行路径，尽管有许多更小的细节（跳转，64 位 vs 256 位等），如果它们能够以不同的方式进行，将会带来更好的结果。

ETH 供应是否应该以不同方式分配？

目前的 ETH 供应量大致可以用 Etherscan 的这个图来表示：

目前大约有一半的 ETH 是在以太坊公募中出售的，任何人都可以将 BTC 发送到一个比特币地址，最初的 ETH 供应分配是通过一个开源脚本计算出来的。其余的大部分基本也已通过挖矿产出。黑色部分的 1200 万 ETH 标记为“other”，其实是预挖部分，在以太坊基金会和大约 100 位以太坊协议的早期贡献者之间分配的额度。

对于这个过程有两个主要的批评：

预挖以及以太坊基金掌管公募资金这两件事，都不具备可信的中立性。一些收款人地址是通过一个封闭的过程人工挑选的，以太坊基金会必须被信任，不能通过贷款来进一步利用公募所得的资金，以获得更多的 ETH (我们没有，也没有人声称我们有，但即使是被信任的要求也冒犯了一些人）。

预挖过分奖励了非常早期的贡献者，而留给后来的贡献者的太少。75%的预挖用于奖励上线前贡献者的工作，而在上线后，以太坊基金会只剩下 300 万个 ETH。在 6 个月的时间里，为了生存而出售的需求使存量减少到 100 万 ETH 左右。

在某种程度上，这些问题是相关的：希望尽量减少对中心化的看法促成了较小的预挖，但较小的预挖会更快地耗尽。

这并不是唯一的解决方法。Zcash 则采用了一个不同的方法：区块奖励的 20%固定分配给协议中硬编码的一组接受者，这组接受者每四年重新协商一次(到目前为止，这种情况已经发生过一次)。这将更加可持续，但它会因为过于中心化而受到更严厉的批评（Zcash 社区似乎比以太坊社区更公开地接受更多的技术专家领导）。

一个可能的替代路径是类似于今天在一些 DeFi 项目中流行的 "DAO from day 1" 路线。这里是一个可能的稻草人提议：

我们同意在 2 年内，从每个区块奖励中划分 2 ETH 投入到开发基金中。

任何在以太坊公募中购买 ETH 的人都可以为他们喜欢的开发基金分配投票（例如："每个区块奖励中 1ETH 给以太坊基金会，0.4ETH 给 Consensys 研究团队，0.2 个 ETH 给 Vlad Zamfir..."）

被投票支持的接受者得到的发展基金份额等于每个人投票的中位数，按比例计算，总数等于每区块 2ETH（中位数是为了防止自我交易：如果你为自己投票，你什么也得不到，除非你让其他购买者中至少有一半人提到你）。

公募可以由一个法律实体来运作，承诺按照 ETH 开发基金的相同比例来分配公募过程中收到的比特币（或者烧掉，如果我们真的想让比特币玩家高兴的话）。这可能会导致以太坊基金会得到大量的资金，非以太坊基金会的团体也得到大量的资金（导致更多的生态系统去中心化），所有这些都没有破坏可信的中立性一丝一毫。当然，主要的缺点是，通证投票真的很糟糕，但务实地说，我们可以意识到，2014 年仍然是一个早期和理想化的时间，通证投票最严重的缺点在公募结束后很久才会开始发挥作用。

这样做会不会是一个更好的想法，并树立一个更好的先例？也许！尽管从现实的角度来看，即使开发基金是完全可信的中立的，今天那些对以太坊的矿工大喊大叫的人，很可能反而会对 DAO 分叉开始加倍地大喊大叫。

我们能从这一切中学到什么？

总的来说，有时我觉得以太坊最大的挑战来自于在两个愿景之间的平衡：一个重视安全和简单纯粹的区块链，以及一个用于构建高级应用程序的高度性能和功能的平台。上面的许多例子只是其中的一个方面：我们是拥有更少的功能而更像比特币，还是拥有更多的功能而更适合开发者？我们是担心让开发资金变得更中立，更像比特币，还是我们首先担心的是确保开发者获得足够的奖励，让以太坊变得更好？

我个人的梦想是试图同时实现这两个愿景。一个基础层，其规范每年都比前一年小，以及一个以二层协议为中心，强大的开发者友好的高级应用生态系统。也就是说，要达到这样一个理想的世界需要很长的时间，如果能更明确地认识到这需要时间，我们需要一步步地考虑路线规划，可能会对我们有很大的帮助。

今天，有很多事情我们无法改变，但也有很多事情我们仍然可以改变，而且仍然有一条坚实的道路来改善功能和简单性。有时这条道路是曲折的：我们需要先增加一些复杂性以实现分片，而分片又能在上面实现大量的二层可扩展性。也就是说，降低复杂性是可能的，以太坊的历史已经证明了这一点。

EIP-150 使调用堆栈深度限制不再相关，减少了合约开发者的安全担忧。

EIP-161 使“空帐户”的概念与字段为零的帐户分离开来。

EIP-3529 删除了部分退款机制，使 Gas 代币不再可行。

酝酿中的想法，如 Verkle 树，甚至也能进一步降低复杂性。但如何在未来更好地平衡这两种愿景，是我们应该开始更积极思考的问题。