Listen to v-god talk about the road ethereum did not take

The Roads Not Taken

Vitalik Buterin

Source: Vitalik Buterin

原文编译：Kxp，律动 BlockBeats

Ethereum 协议开发社区在 Ethereum 的早期阶段做出了很多决定，对项目的发展轨迹产生了重大影响。在有些情况下，Ethereum 开发者做出了理智的决定，解决了 Bitcoin 遇到的一些问题。而在其它一些情况中，我们也在创造全新的东西，利用诸多选择填补过往的空白。还有些时候，我们需要在复杂与简易之间做出权衡，因为二者分别适用于不同的情景。

本篇文章我将介绍一些分叉功能，其中很多都在核心开发者的圈子当中认真讨论过；但剩下没有讨论的功能此时此刻也应该被提上日程。同时，我们也期待看到一个不同的 Ethereum，并从中学到新的东西。

Should we use a simplified version of the proof of interest

Ethereum will soon merge into...Gasper 权益证明系统虽然复杂，但却功能强大，具有以下特性：

Powerful single block validationOnce a transaction is incorporated into a block, the block is solidified, usually within seconds. It cannot be reversed unless there is a high percentage of nodes with low integrity or extreme network latency.  

Economic certainty-- Once the block is finalized, it is also irreversible without the attacker losing millions of ETH.  

High predictable returnsVerifiers are reliably rewarded for each cycle (6.4 minutes), reducing incentives to the pool.  

Support a large number of verifiers——与其他大多数具有上述特性的链不同，Ethereum 信标链支持数十万的验证者（例如，Tendermint 提供比 Ethereum 更快的确定性，但它只支持数百个验证者）。

But building a system with these features is difficult, requires years of research, numerous failures, and a lot of effort, and the end result can be complex.

如果我们的研究人员不需要太考虑共识，并且有足够多的精力的话，那么也许 rollup 在 2016 年就已经被发明出来了。这就让我们不禁反思：我们的权益证明真的应该有这么高的标准吗，因为即使是一个简单弱化版本的权益证明就会比我们目前的工作证明要好得多。

很多人都存在一个误解，认为权益证明本身就相当复杂，但实际上有很多权益证明算法几乎和 Nakamoto PoW 一样简单。NXT 的权益证明在 2013 年就出现了，是一个天然的候选方案；虽然它也有问题，但这些问题很容易被修补，而且我们本可以从 2017 年，甚至从一开始就有一个运作良好的权益证明。Gasper 之所以比这些算法更复杂，只是因为它尝试完成的任务比它们多得多。但是，如果我们在一开始就加以谨慎，我们本可以先集中精力实现一些更可能完成的目标。

In my opinion, it's not the right thing to do to start with proof of equity; PoW helps expand the initial distribution of releases, improves accessibility of Ethereum, and promotes the amateur community. But in 2017, or even 2020, switching to simpler proof-of-claim could do more to protect the environment (and the anti-crypto backlash from environmental damage) and allow researchers to focus more on scaling issues. We will eventually have to spend a lot of resources to produce a better proof of equity, which is a natural outcome from the current situation.

分片的去复杂化

Since we started working on Ethereum sharding in 2014, we have been working on de-complicating issues. Whereas previous complex shards had built-in execution and cross-shard transactions, we simplified the protocol and shifted more responsibility to the user (for example, in cross-shard transactions, the user had to pay Gas on both shards). We then moved to a rollup-centric roadmap, where sharding is just a collection of data from a protocol perspective. Finally, throughdankshardingWe can combine the sharding market. In this way, the final design looks like a non-sharded chain, but the data availability sampling behind it makes sharding verification a reality.

但如果我们选择了一条与之相反的路径呢？实际上 Ethereum 的研究人员曾花大量时间探索了一个更复杂的分片系统：分片将成为链，在分叉选择规则中子链依赖于主链，跨分片消息会被协议路由，验证者会在分片之间轮换，甚至应用程序也会在分片之间自动完成负载平衡。

The problem with this approach is that this form of sharding is basically just ideas and mathematical models, whereas Danksharding is a complete specification that can be implemented. Therefore, given the limitations of Ethereum, simplifying and disambiguating sharding is definitely the right move in my opinion. Still, we should put more effort into research because it can help us identify promising research areas. In general, even very complex ideas have simple versions that still help us a lot, and are likely to shape Ethereum protocols (even Layer2 protocols) for years to come.

Should we add or subtract functionality from EVM

除了安全审计功能之外，EVM 的规范在 2014 年中之前就可以推出。不过，在之后的几个月里，我们一直在积极探索对去中心化应用区块链有用的新功能，具体如下：

1. We wanted to add a POST opcode, but decided not to. The POST opcode makes an asynchronous call that will not be executed until the transaction is complete.

2. We also wanted to add an ALARM opcode, but we gave it up. ALARM functions like POST, except that it can make asynchronous calls in a future block, allowing the contract to plan operations in advance.  

3. We have added logging, which allows the contract to output records that do not involve state but can be read by the DApp interface and wallet. However, we also considered logging ETH Transfer, but decided against it because "people will soon switch to smart contract wallets anyway".  

4. We considered expanding SSTORE to support byte arrays, but chose not to because of concerns about complexity and security.

5. We have added precompiled contracts that can perform certain Crypto operations natively at lower Gas rates than EVM.

6. In the months following launch, we thought about state renting a lot, but we didn't include it due to its complexity. Better state expiration schemes are being actively explored today, although stateless validation and proposer/builder separation are far more important.

今天来看，我们基本上都做出了正确的决定，我们也确实不需要增加 POST 操作码，也很难保证 ALARM 操作码的安全性（如果每个人在 1 到 99999 个区块中都设置了一个 ALARM，那么在第 100000 个区块中执行大量代码，会发生什么？那个区块会不会花几个小时来处理这些代码？一些预定的操作会被推到后面的区块吗？如果这种情况发生了，那么 ALARM 还能保留什么安全保证呢？）字节数组 SSTORE 的安全性也很难实现，而且会扩大最坏情况下的见证规模。

The state rental problem is even more challenging: if we actually implement some kind of state rental from day one, then we have any smart contract ecosystem that can evolve around the normalized assumption of persistent states. Ethereum will become harder to build, even though it may be more scalable and sustainable. At the same time, our status expiration plan was much worse than what we have now. Sometimes good ideas take years to come to fruition. There are no shortcuts.

LOG 的替代路径

LOG 可以用两种不同的方式来完成：

1. We can make ETH transfer automatically send a LOG. This will save exchanges and many other users a lot of time and reduce the occurrence of software errors. People will rely more on LOG, and smart contract wallets will be more widely used.  

2. 我们完全可以不用 LOG 操作码，而把它变成一个 ERC：会有一个配置 submitLog 函数的标准合约，它可以使用 Ethereum 存款合约技术来计算该区块中所有日志的 Merkle 根。无论是 EIP-2929 还是区块上的存储（相当于 TSTORE，但在之后会被清空）都将降低它的成本。

我们曾认真考虑过第一种方式，但最后还是没有采用，主要原因还是它的简易性不足：使用 LOG 操作码直接生成日志会更为便捷。我们还做了错误的估计，认为大多数用户会迅速迁移到智能合约钱包，并使用操作码来记录转账。

We hadn't really thought about the second option, but in retrospect it was pretty good. The main drawback is that it lacks a Bloom filter mechanism to scan logs quickly. But the Bloom filter has proven to be too slow and dApp-friendly, so more and more people are using it now.TheGraph 来进行查询。

总的来说，采用任何一个方法都会使情况变得更好。将 LOG 保留在协议之外会使事情变得更简单，但如果它在协议之内，它自动记录所有 ETH 转移的功能也非常实用。

时至今日，我会赞成取消 EVM 中的 LOG 操作码。

What if EVM is completely different

EVM 可以选择两条截然不同的路径：

1. Make EVM a more advanced language with built-in variables, if statements, loops, etc.

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

The first path has never been properly considered, and its advantage is that it simplifies the compiler and allows more developers to code directly in EVM. At the same time, it can also make the structure of ZK-EVM simpler. The weakness of this path, however, is that it makes the EVM code structurally more complex: it is no longer a simple list of opcodes, but a more complex data structure that must be stored in a certain way. In other words, we missed an opportunity to have the best of both worlds: making some changes to EVM while keeping its basic structure unchanged would have given us many benefits, including disabling dynamic jumps and adding opcodes designed to support subroutines (see also:EIP-2315）、只允许在 32 字节的词汇边界上访问存储器，等等。

第二条路径好坏参半，支持的人认为它可以让程序从现有语言（C、Rust 等）编译到 EVM 中，而反对的人则认为，鉴于 Ethereum 特殊的限制因素，它实际上不会提供任何好处：

1. Existing high-level language compilers tend not to care about the total code size, while blockchain code must be greatly optimized to reduce the code size per byte.

2. We need to implement multiple functions of the VIRTUAL machine, and strictly require the two functions not to process the same code in different ways, but this will also make it difficult to conduct security audit and verification on the code that is not written by us.  

3. 如果虚拟机规范发生变化，Ethereum 将不得不一直随着它进行更新，否则将很难同步。

因此，尽管当初一些细节得到改善可能会产出更好的结果，但和现在情况不同的是，EVM 在以前可能还是从来没有过一个可行的路径。

Whether ETH supply should be allocated differently

We can get this from the following slide from  Etherscan  The chart shows the current ETH supply:

今天大约一半的 ETH 是在公开的 Ethereum 销售中售出的，任何人都可以向一个标准化的 Bitcoin 地址发送 BTC，而最初的 ETH 供应分布是由一个开源脚本计算得出的，该脚本通过扫描 Bitcoin 区块链上的交易获得地址。其余的 ETH 基本都是靠挖矿得到的，其中标有「其他」的 1200 万 ETH，是「预挖矿」的部分——即在 Ethereum 基金会和约 100 个 Ethereum 协议的早期贡献者之间分配的部分。

人们对该过程提出了两点批评意见：

1. Pre-mining, and the fact that the Ethereum Foundation receives sales funds, is not credibly neutral. Some recipient addresses are manually selected in a closed loop, and we have to trust that the Ethereum fund will not provide itself with more ETH by lending the money received from the sale back into the sale process.  

2. 预挖矿过度地奖励了早期的贡献者，这让后来的贡献者只能分得较少的奖励。75% 的预挖矿用于奖励贡献者在启动前的工作，而启动后，Ethereum 基金会只剩下 300 万 ETH。在之后的半年时间内，由于财务上的需要，该数字又下降到约 100 万 ETH。

在某种程度上，这些问题是相互关联的：人们为了最大限度地减少中心化，缩小了预挖矿的规模，而这也会让它更快耗尽。

Zcash 采取了另一种不同的方法：协议中一组硬编码的接收地址将收到恒定的 20% 区块奖励，并这一名单每 4 年就会重新协商一次（到目前为止已经做了一次调整）。虽然这种方法具有更高的可持续性，但也会因为中心化而受到更多的批评（Zcash 社区似乎比 Ethereum 社区更愿意接受技术专家的领导）。

我们可以采用如今在一些 defi 项目中流行的「DAO from day 1」作为替代路线，草案提议如下：

1. We agree to put 2 ETH in each block into the development fund within 2 years.  

2. Anyone who buys ETH in the Ethereum sale can specify to vote their preferred development fund for ETH allocation (e.g. "1ETH per block for Ethereum Foundation, 0.4ETH for Consensys Research team, 0.2ETH for Vlad Zamfir, etc.")

3. 得到投票的接受者从开发基金中获得的份额将等于每个人投票的中位数，并将按按比例进行计算，从而保证其总数等于每个区块 2 个 ETH（设置中位数是为了防止自我交易：为自己投票毫无用处，除非你让其他购买者中至少有一半人为你投票）。

这一销售可以由法律实体运作完成，该实体承诺将销售期间收到的 Bitcoin 按照与 ETH 开发基金相同的比例进行分配（或销毁，如果我们想让 Bitcoin 玩家高兴的话）。这可能会导致 Ethereum 基金会和其他团体在不破坏可信中立性的情况下得到大量的资金，加快生态系统去中心化的进程。当然，这一做法的缺点在于，投币投票真的很糟糕，但务实地说，2014 年仍然是一个较早和理想化的阶段，投币投票最严重的缺点在销售结束很久以后才会开始显现。

That might be a better idea, and set a better precedent. Although from a realistic point of view, even if the development fund were completely credibly neutral, it is likely that those unhappy with Ethereum miners today will turn their fire on the DAO fork.

启发

总的来说，有时我觉得 Ethereum 最大的挑战在于保持两个愿景之间的平衡——一个重视安全性和简洁性，纯粹简单的区块链，以及一个用于构建先进应用程序的高性能平台。上面的诸多例子只是这个问题的一个方面：我们是减少功能数量从而更类似 Bitcoin，还是创造更多功能以方便开发者？我们应该担心让开发资金更加可信中立会使其更像 Bitcoin，还是应该先关心如何确保开发者得到足够的奖励，从而让 Ethereum 变得更好？

在我个人看来，我们可以同时实现这两个愿景——一个规格逐渐缩小的基础层，以及一个以 Layer2 协议为中心，功能强大的开发者友好型高级应用生态系统。即便如此，要达到这样一个理想的状态还是需要很长的时间。所以说，我们只有一步步地考虑如何制定路线图，才能取得一定的成果。

虽然我们现在已经无法改变很多事情，但也并不是全部，而且我们依然可以着手提高功能性和简易性。不过，在这个过程中我们有时也会遇到一些困难：为了提高分片上 Layer2 的可扩展性，我们需要先增加一些复杂性以实现分片。但即便如此，复杂性的降低也是可能的，Ethereum 的历史已经证明了这一点：

Ip-150 eliminates the call stack depth limit, reducing security concerns for contract developers.  

2. IP-161 makes "empty accounts" no longer distinguishable from accounts with field zero.  

3.EIP-3529 删除了部分退款机制，使得 Gas Token 不再可行。

With ideas like the Verkle tree still in the works, we can reduce complexity even further. But how to better balance these two visions in the future is something we should start thinking about.

The original link

Welcome to join the official BlockBeats community:

Telegram Subscription Group: https://t.me/theblockbeats

Telegram Discussion Group: https://t.me/BlockBeats_App

Official Twitter Account: https://twitter.com/BlockBeatsAsia