3月29日，Vitalik Buterin发表文章《The roads not taken》，着眼于以太坊发展路上的各种猜想与落实路径。我们有必要看看不同的以太坊可能是什么样子，以及我们可以从中学到什么
作者：Vitalik Buterin/ 罐罐儿 编译 / 来源：金色财经
原文链接：https://vitalik.ca/general/2022/03/29/road.html
以太坊协议开发社区在以太坊早期阶段做出了很多决定，这些决定对项目的发展轨迹产生了很大的影响。在某些情况下，以太坊开发人员有意识地决定在我们认为比特币犯错的地方进行改进。在其他地方，我们正在创造一些全新的东西，我们只需要想出一些东西来填补空白——但有很多东西可供选择。还有一些其他地方，我们在更复杂的东西和更简单的东西之间进行了权衡。有时，我们选择了更简单的东西，但有时，我们也选择了更复杂的东西。
这篇文章将着眼于我记忆中的一些岔路口。其中许多功能在核心开发圈内得到了认真讨论；其他人几乎没有考虑过，但也许真的应该考虑过。但即便如此，还是有必要看看不同的以太坊可能是什么样子，以及我们可以从中学到什么。
我们是否应该使用更简单的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，分片费用市场合二为一，最终设计看起来就像一条非分片链，但在幕后发生了一些数据可用性抽样魔术（data availability sampling magic）以进行分片验证。
但是，如果我们走相反的道路呢？实际上有以太坊研究人员深入探索了一个更复杂的分片系统：分片将会产生链，会有子链依赖于父链的分叉选择规则，跨分片消息将由协议路由，验证者将是在分片之间轮转，甚至应用程序也会在分片之间自动实现负载平衡！
这种方法的问题是：这些分片形式在很大程度上只是想法和数学模型，而Danksharding是一个完整且几乎可以实现的规范。因此，考虑到以太坊的环境和限制，在我看来，分片的简化和去野心化绝对是正确的举措。也就是说，更雄心勃勃的研究也有一个非常重要的作用：它确定有前途的研究方向，即使是非常复杂的想法通常也有那些仍然提供很多好处的想法的“相当简单”的版本，而且很有可能它将在未来几年显著影响以太坊的协议开发（甚至是Layer-2协议）。
EVM中的更多或更少的功能？
实际上，除了安全审计之外，EVM的规范基本上可以在 2014 年年中推出。然而，在接下来的几个月里，我们继续积极探索我们认为可能对去中心化应用程序非常重要的新功能。有的没添加进去，有的添加进去了。
- 我们考虑添加一个「POST」 操作码，但决定反对。POST操作码将进行异步调用，该调用将在其余事务完成后执行。
- 我们考虑添加一个「ALARM 」操作码，但决定反对。 除了在未来的某个块中执行异步调用外，「ALARM」的功能类似于「POST」。
- 我们添加了日志功能，允许合约输出不涉及状态但可以被 dapp 接口和钱包解释的记录。值得注意的是，我们还考虑过让 ETH 转账发出日志，但最终决定不这么做——理由是“人们很快就会转向智能合约钱包”。
- 我们考虑扩展「SSTORE 」以支持字节数组，但出于对复杂性和安全性的担忧而决定反对。
- 我们添加了预编译，这些合约使用本机实现执行专门的加密操作，其 gas 成本比 EVM 中的成本低得多。
- 在推出后的几个月里，状态租金（state rent）一次又一次的被考虑，但从未包括在内。这太复杂了。今天，正在积极探索更好的状态到期方案（state expiry schemes），尽管无状态验证（stateless verfication）和提议者/构建者分离意味着它现在的优先级要低得多。
今天来看，大多数不添加更多功能的决定已被证明是非常好的决定。没有明显的理由添加「POST」操作码。「ALARM」操作码实际上很难安全地实现：如果区块 1…99999 中的每个人都设置一个「 ALARM」 在区块 100000 处执行大量代码会发生什么？该区块需要几个小时来处理吗？一些预定的操作会被推迟到以后的区块吗？但如果发生这种情况，那么还有什么保证「ALARM」可以保留呢？「SSTORE」对于字节数组很难安全地完成，并且会大大扩展最坏情况的见证大小。
状态租金问题更具挑战性：如果我们实际上从第一天开始实施某种状态租金，我们就不会让智能合约生态系统围绕持久状态的规范化假设发展。以太坊本来会更难构建，但它本来可以更具可扩展性和可持续性。同时，我们当时的状态租金计划确实比我们现在的要糟糕得多。有时，好主意需要数年时间才能得出，没有更好的解决方法。
「LOG」的替代路径
LOG可以通过两种不同的方式以不同的方式完成：
1，我们可以让 ETH 转账自动发出一个「LOG」。这将为交易平台和许多其他用户节省大量精力和软件错误问题，并加速每个人对日志的依赖，这具有讽刺意味的是，有助于智能合约钱包的采用。
2，我们完全可以不用「LOG」操作码，而是把它变成一个 ERC：会有一个标准合约，它有一个函数submitLog，并使用以太坊存款合约中的技术来计算该区块中所有日志的 Merkle 根。EIP-2929或区块范围的存储（相当于「TSTORE」 但在出块之后清除）都会使这个便宜。
我们强烈考虑过（1），但拒绝了。主要原因是简单：日志更容易来自「LOG」操作码。
我们还（非常错误地！）期望大多数用户能够快速迁移到智能合约钱包，这可能已经使用操作码显式记录了转账。
（2）没有考虑过，但回想起来，它始终是一种选择。(2) 的主要缺点是缺少用于快速扫描日志的 Bloom 过滤器机制。但事实证明，Bloom 过滤器机制对于 dapp 来说太慢了，对用户来说是友好的，所以现在越来越多的人使用 TheGraph进行查询。
总体而言，这两种方法中的任何一种都可能优于现状。保持「LOG」在协议之外会让事情变得更简单，但如果它在协议内部自动记录所有 ETH 传输，它会更有用。
今天，我可能会赞成最终取消来自EVM 中的「LOG 」操作码。
如果 EVM 完全不同怎么办？
EVM 可以采用两种非常不同的自然路径：
1，使 EVM 成为一种高级语言，内置变量、if 语句、循环等结构。
2，使 EVM 成为一些现有 VM（LLVM、WASM 等）的副本。
第一条路径从未被真正考虑过。这条路径的吸引力在于它可以使编译器更简单，并允许更多的开发人员直接在 EVM 中编码。它还可以使 ZK-EVM 结构更简单。该路径的弱点在于它会使 EVM 代码在结构上更加复杂：它不是一个简单的连续操作码列表，而是一个必须以某种方式存储的更复杂的数据结构。也就是说，错过了两全其美的机会：一些 EVM 更改本可以给我们带来很多好处，同时保持基本 EVM 结构大致原样：禁止动态跳转并添加一些旨在支持的操作码子程序（ ban dynamic jumps and add some opcodes designed to support subroutines 另见：EIP-2315)，只允许在 32 字节字边界上访问内存，等等。
第二条路径被建议了很多次，也被拒绝了很多次。通常的论点是它允许程序从现有语言（C、Rust 等）编译到 EVM 中。反对的论点一直是，鉴于以太坊的独特限制，它实际上不会提供任何好处：
- 来自高级语言的现有编译器往往不关心总代码大小，而区块链代码必须进行大量优化以减少每个字节的代码大小。
- 我们需要 VM 的多个实现，并有一个硬性要求，即两个实现永远不会以不同的方式处理相同的代码。在我们没有编写的代码上进行安全审计和验证会更加困难。
- 如果虚拟机规范发生变化，以太坊要么总是随之更新，要么越来越不同步。
因此，对于 EVM 来说，可能从来没有一条可行的路径与我们今天所拥有的完全不同，尽管有很多较小的细节（跳转、64 位 vs 256 位等）如果完成的话可能会带来更好的结果不同。
ETH 供应是否应该以不同的方式分配？
Etherscan的这张图表大致代表了当前的 ETH 供应量：
今天存在的大约一半的 ETH 是在公开的以太坊销售中出售的，任何人都可以将 BTC 发送到标准化的比特币地址，并且最初的 ETH 供应分配是由一个开源脚本计算的，该脚本扫描比特币区块链以进行交易到那个地址。其余大部分已开采。黑色部分-标记为“其他”的 1200 万 ETH，是预挖矿（premine），为分配给以太坊基金会和大约 100 名以太坊协议的早期贡献者的。
这个过程有两个主要的批评：
- premine以及以太坊基金会收到销售资金的事实并不是可信的中立。一些收件人地址是通过一个封闭的过程手工挑选出来的，必须相信以太坊基金会不会借钱来回收收到的资金，以便将出售重新投入到出售中，以给自己更多的 ETH（我们没有，也没有人认真地声称我们有，但即使是完全信任的要求也会冒犯一些人）。
- premine 过度奖励了早期的贡献者，而留给后来的贡献者的太少了。75% 的 premine 在启动前用于奖励贡献者的工作，而在启动后，以太坊基金会只剩下 300 万个 ETH。在 6 个月内，为了经济生存而出售的需求减少到大约 100 万 ETH。
在某种程度上，这些问题是相关的：尽量减少对中心化的看法的愿望导致了较小的预挖矿，而较小的预挖矿更快地耗尽了。
这不是事情可以完成的唯一方式。Zcash有一种不同的方法：固定 20% 的区块奖励分配给协议中硬编码的一组接收者，并且每 4 年重新协商一组接收者（到目前为止，这种情况已经发生过一次）。这本来会更可持续，但它会因为中心化而受到更严厉的批评（Zcash 社区似乎比以太坊社区更公开地接受更多的技术领导）。
一种可能的替代路径类似于当今某些DeFi 项目中流行的“从第一天开始的 DAO”路线。这是一个可能的易受攻击的建议：
- 我们同意在 2 年内，每个区块奖励中的 2 ETH 进入开发者基金。
- 任何在以太坊销售中购买 ETH 的人都可以指定他们对开发者基金的首选分配投票（例如，“每个区块 1 ETH 给以太坊基金会，0.4 ETH 给 Consensys 研究团队，0.2 ETH 给 Vlad Zamfir ……” )
- 被投票支持的接收者从开发基金中获得的份额等于每个人投票的中位数，按比例计算，每个区块的总数等于 2 ETH（中位数是为了防止自我交易：如果你为自己投票，除非你得到至少有一半的其他购买者提到你）
销售可以由一个法律实体进行，该实体承诺按照与 ETH 开发基金相同的比例分配销售期间收到的比特币（或者烧毁，如果我们真的想让比特币持有人高兴的话）。这可能会导致以太坊基金会获得大量资金，非以太坊基金会同样也会获得大量资金（从而建立更多的去中心化生态系统），所有这些都不会破坏可信的中立性。主要的缺点当然是代币投票真的很糟糕，但实际上我们本可以意识到 2014 年仍然是一个早期和理想主义的时期，代币投票最严重的缺点只会在销售结束后很久才开始发挥作用。
这会是一个更好的主意并开创一个更好的先例吗？可能是！尽管实际上即使开发基金完全可信中立，但今天对以太坊的预挖矿大喊大叫的人很可能刚刚开始对 DAO 分叉提出更大的反对声音。
我们可以从这一切中学到什么？
总的来说，我有时觉得以太坊最大的挑战来自于两种愿景之间的平衡——一个重视安全性和简单性的纯粹而简单的区块链，以及一个用于构建高级应用程序的高性能和功能性平台。上面的许多示例只是其中的一个方面：我们是功能更少但更像比特币，还是功能更多但对开发人员更友好？我们是否非常担心使开发资金可信地中立并更像比特币，还是我们首先担心的是确保开发人员获得足够的奖励以使以太坊变得更好？
我个人的梦想是尝试同时实现这两个愿景——一个规范每年比前一年更小的基础层，以及一个以Layer2协议为中心的强大的开发人员友好的高级应用程序生态系统。也就是说，到达这样一个理想的世界需要很长时间，更明确地意识到这需要时间，我们需要逐步考虑路线图可能会对我们有很大帮助。
今天，有很多事情是我们无法改变的，但还有很多事情我们仍然可以改变，而且仍然有一条道路可以在功能性和简单性方面得到充分的改善。有时路径是曲折的：我们需要先增加一些复杂性以启用分片，这反过来又在顶部启用了许多Layer2可扩展性。也就是说，降低复杂性是可能的，以太坊的历史已经证明了这一点：
- EIP-150使调用堆栈深度限制不再相关，减少了合约开发人员的安全担忧。
- EIP-161将“空账户”的概念作为与字段为零的账户分开的东西不再存在。
- EIP-3529删除了部分退款机制，使 gas 代币不再可行。
正在酝酿中的想法，如Verkle 树，可以进一步降低了复杂性。但未来如何更好地平衡这两种愿景是我们应该开始更积极思考的问题。