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