2022 更新版以太坊路线图内容注解

巴山号小编 2023年03月08日 17:28 185 0

欧易 OKX 交易所

注册送6万元盲盒奖励，100%中奖

点击欧易注册，还可获得永久20%手续费返佣

APP下载欧易注册

邀请好友 注册并登录 ，获取价值高达 60000 元的数字货币盲盒，100%中奖！

2022 更新版以太坊路线图内容注解。

译者注：本文基于最新以太坊路线图进行内容注解，下图为 ECN 译制的中文版。

文中有许多链接，进入网页版查看更多：https://www.ethereum.cn/Eth2/annotated-ethereum-roadmap

作者 | @domothy

来源 |notes.ethereum.org

本文档旨在为读者了解以太坊路线图上各个部分提供入口点，每一部分都做了简单的概要介绍，如想深入了解，文内亦附上了详细的链接。

注意：如路线图上箭头所示，所列出的各个部分并非连续进行的工作，它们的推进是并行的。

目标：实现一个理想化的、简洁的、拥有鲁棒性的以及去中心化的 PoS 共识机制

已完成工作

2020 年 12 月 1 日 — 信标链启动

引入以太坊 PoS 共识层，由验证者质押 ETH 来维护该层网络安全
信标链在共识规范中被称为阶段 0 (Vitalik 的注释版本以及 Danny Ryan 的注释版本)

2021 年 10 月 27 日 — 热身分叉 (Altair) - 共识层客户端开发者们在协调硬分叉升级方面进行了一次试运行

Altair 引入了同步委员会来支持轻客户端，并对惩罚进行了一些调整
Altair 主网升级公告
Altair 规范 (注释版本)
“What’s new in ETH2” 中对 Altair 进行解释的那期

2022 年 9 月 15 日，— 合并！PoW 退休 - 在区块高度 15,537,394 处完成共识层和执行层的合并。

下一步的工作

提款 — 允许验证者提取全部或者部分质押金

Capella 分叉指定共识层中的变更
EIP-4895 指定执行层中的变更
Tim Beiko 关于提款的 FAQ
提款元规范和其他信息

分布式验证者 — “多签，不过是用于质押的”，这项技术中，n 人共享同一个验证者并且 m-of-n 必须就其行为方式达成共识

通过防止意外的罚没来强化质押机制，并使其更加容易参与 (比如，通过在多个参与者之间去信任地切分所需的 32 个 ETH)
这并非协议内的工作，SSV 和 Obol 等团队正致力于这项研究

视域合并 (View merge) — 调整分叉选择规则 (验证者投票的方式) 以减轻一类攻击

本质上就是 “强制” 诚实的验证者能够看到正确的链头，以减少作恶验证者分裂投票并重组对其有利的区块的机会。
ethresear.ch post 中有许多关于这项研究的 (非常技术性的) 背景

改良的聚合 — 以太坊努力支持尽可能多的验证者，但是让每个验证者对每个区块投票 (并验证每个其他验证者的投票) 太占用带宽了。退而求其次就是聚合签名，但这也有其局限性，而且可以做得更好

关于 BLS 聚合签名的好处的解释帖子
潜在的候选签名技术：Horn

单个 slot 实现最终确定性 (SSF) — 每隔一个 slot (12 秒) 敲定一次链状态，而不是每隔一个 epoch (12.8 分钟)

通往单个 slot 实现最终确定性之路 (中文版)
除了改良签名聚合之外，我们还必须弄清楚两件事：

- SSF 共识算法 - 现有的与 SSF 兼容的算法是不够的，我们想要一个即便是超过 1313 名验证者离线也能保持链的活性的算法。

- SSF 验证者经济学 - 如果我们最终不得不限制验证者的数量，我们如何限制参与率，以及我们需要做出什么牺牲？

秘密领导选举 (SLE)

目前，被选中提议一个区块的验证者 (单个 slot 的领导者) 是稍微提前知道的，这使得潜在的 DoS 攻击能够专门针对即将到来的区块的领导者
ethresear.ch 有一篇帖子是关于基于随机混洗的单一秘密领导选举的协议：除了领导者自己，没有人知道谁将是这个 slot 的领导者，直到他们将自己的区块与领导者证明一起公布出来。
非单一秘密领导者选举可能也是一种选择

支持更多验证者 — 正在进行的长期努力：安全地支持更多的验证者始终是我们的目标

量子安全的、聚合友好的签名 — 在量子计算机成为一个合理的担忧之前，使以太坊成为量子安全的是我们长期努力的一部分

所用的 BLS 签名方案基于的密码学已知会被量子计算机破解，但已知是量子安全的替代签名方案并不像 BLS 那样有效地聚合签名 (因此需要一个既量子安全又聚合友好的方案)。
两个主要的量子安全方案是基于 STARK 的和基于 Lattice 的

目标：确保可靠且可信中立的交易打包过程，避免 MEV 带来的中心化以及其他协议上的风险。

相关链接：

以可信的中立为指导原则

关于 MEV 的多条推串

关于 MEV 和 PBS 的文章

关于 PBS 的链接清单

已完成工作

协议外的 MEV 市场 — MEV-Boost 中间件允许普通验证者从 MEV 中获利，而无需自己运行复杂的 MEV 策略

这个解决方案本身不完整，因为它有审查问题
阅读文章 "The Cost of Resilience" 和 "The Future of MEV is SUAVE"，了解使得这些协议外的 MEV 市场更加有弹性的计划

下一步的工作

打包列表或者备选方案 — 让区块提议者对区块构建者进行限制，即强迫他们纳入交易

打包列表相关笔记
研究如何在不增加提议者负担的情况下约束构建者

协议内 PBS — 将区块构建市场直接写入协议内

MEV 销毁 — 让区块链获取原本从链上经济中提取的价值

通过提议者拍卖来直接进行 MEV 销毁的提案
委员会驱动 MEV 均匀分配让协议意识到 MEV
通过经济激励措施设置验证者子集的上限，将通过负增发间接销毁 MEV

应用层 MEV 最小化 — 这个工作与 L1 没有直接关系，它涉及到开发者在设计他们的 dapp 时需要记住 MEV。这里有几个采用 MEV 最小化策略的 dapp 的例子

分布式构建者路线

由于区块提议过程是保持去中心化的，我们现在有一个单独的问题，即区块构建变得中心化。即便路线图上的所有其他部分都旨在最大限度地减少区块构建中心化可能带来的最坏情况，能够将区块构建分布在许多节点中仍然是一个很大的好处。

Blob 结构 - 寻找方法来减轻数据分片在许多节点上的高带宽和处理要求，而这些节点是普通消费者级别的硬件可以运行的。
预确认服务 - 给予用户强有力的保证，他们的交易将被打包进下一个区块中
抢跑保护 - 尽量减少有毒的 MEV，如三明治攻击，使得分布式的构建过程保持可信的中立

这依然是一个活跃的研究领域，具有非常开放的设计考虑，所以目前还不清楚前面两个框框是否应该被写入协议内 (因此路线图上有问号)

这里是相关的链接：

关于合并后区块构建的演讲，提到了去中心化区块构建
关于去中心化构建者的演讲
关于分布式区块构建的一些想法

目标：验证区块应当超级容易 — 下载 N 个字节数据、执行一些基本计算、验证一个 SNARK 然后你就完成验证了。

这一部分基本上是关于通过使得轻客户端最终可行，以填补 “客户端方面的不足”：并非每个人都想或者能够运行一个全节点。The Verge 的目标是引入去信任或者信任最小化的替代方案，这种节点易于运行，不需要大量的存储和带宽。The Verge 的最终目标是让这些轻客户端提供与目前全节点相同的安全保障。

这一切都依赖于零知识技术，如 SNARKs 和 STARKs，它们本身依赖于多项式承诺方案。这里有一些关于这方面的链接：

介绍 zk-SNARK 何以可能中文版
剖析 STARK
假设你是懂一些数学和编程的人，向你解释 zkSNARK
论多项式承诺方案在扩容以太坊中的作用

已完成的工作

解决了最严重的 EVM DoS 问题 — 主要是 gas 定价问题，已在柏林升级中解决

基本的轻客户端支持 (同步委员会) — 多亏了同步委员会，很容易构建遵循共识层的轻客户端

了解 Helios 客户端是如何利用同步委员会的 (很好地解释了这些委员会是如何运作的)

下一步的工作

EIP-4844 实现 — 在主网部署 EIP-4844

将需要一个 “仪式” 来创建受信任初始化：解释、预估时间线、规范
EIP-4844 实现时间线概览

基本的 rollup 扩容 — 依赖于接下来的工作：

EIP-4844 - 所实现的可扩展性依然被认为较基础/有限，这是因为 “每一个节点下载所有数据” 的性质限制了 blobspace 的可用容量
rollup 的有限辅助轮阶段 (文章中提议了去掉 rollup 辅助轮的路线图) (中文版)

完整的 rollup 扩容 — 依赖于接下来的工作：

DAS (数据可用性采样) 的 P2P 设计：涉及数据分片网络连接问题的一些工作以及研究
数据可用性采样客户端：开发轻量级客户端，可以通过对几千字节的随机采样快速判断数据是否可用
有效的 DA 自我恢复：能够在最恶劣的网络条件下有效地重建所有数据 (比如，恶意验证者攻击、或者大块节点的长时间停机)
不使用辅助轮的 rollup：完全去中心化的定序者、去信任的欺诈证明、不可变的合约等等

量子安全的、无需受信任初始化的承诺 — 在量子计算机成为一个合理的担忧之前，使以太坊成为量子安全的是我们长期努力的一部分

虽然高效且强大，但到处使用的多项式承诺 (KZG) 并不是量子安全的，并需要一个受信任初始化。对更理想的长期使用的承诺的研究正在进行中，最终目标是在底层对 KZG 进行热转换 (hot swap)

SNARK / STARK 专用集成电路 — 专门用来创建证明的硬件

Verkle tree — 将用于全局状态的数据结构替换成一个更高效的版本

Verkle Tree 的链接清单
关键的好处是能够生成非常简洁的证明，轻客户端可以只通过区块头很容易地验证这些证明，以核实像账户余额这样的东西 - 它们已经可以利用同步委员会来验证给定区块头实际上是主链的一部分
需要编写出合适的规范、确保安全地迁移，以及搞清楚它将如何影响更新/编辑状态的 EVM gas 开销 (这也取决于 The Purge 那部分中取消 “SELF-DESTRUCT” 的工作)

基于 SNARK 的轻客户端 — 对同步委员会的状态转换生成 SNARK 证明，以快速证明哪些验证者组成当前的同步委员会

完全基于 SNARK 的以太坊 — 以下 3 项加在一起构成了 “以太坊最终图景”(中文版) 的一个重要里程碑，即实现极其高效以及去信任的区块验证：

用于 Verkle 证明的 SNARK - 通过将 Verkle 证明合并进单个 SNARK 中，区块将包含一个关于它们修改的部分状态的简短独立证明，因此不需要验证区块 N-1 的整个状态来验证区块 N 是否正确修改了它。
用于共识状态转换的 SNARK — 从信任最小化的同步委员会转变为对共识层上发生的所有事情进行完全去信任的验证
用于 L1 EVM 的 SNARK — 利用 rollup 团队在 zk-EVM 上所做的工作，将 zk-EVM 直接集成到 L1 中

-阅读关于写入协议内的 rollup 的帖子

提高 L1 gas 上限 — 通过消除目前 “每个节点都需要存储所有东西” 的负担来实现去信任地验证区块，这将更容易地形成更大的区块以获得更多 L1 可扩展性 (这会自动地加强所有 L2 扩容的效果)

转向量子安全的 SNARK (如 STARK) — 在量子计算机成为一个合理的担忧之前，使以太坊成为量子安全的是我们长期努力的一部分

SNARK 基于的密码学是已知能够被量子计算机破解的，而 STARK 不是

目标：简化协议、清楚技术债和通过清理历史数据限制参与网络的成本

已完成工作

清除大多数 gas 返还 — 所有的 gas 重新定价工作已在柏林升级完成

信标链快速同步 — 从最近敲定的 epoch 同步 (在大多数共识层客户端中称为 "检查点同步") 而不是从创世开始同步，这方面的所有开发工作已完成

EIP-4444 规范 — 阅读 EIP 规范了解

下一步的工作

历史数据休眠 — 通过让旧的历史状态休眠来降低存储需求、减少同步时间和代码复杂性

阅读此条推特长文
依赖于 EIP-4444 的实现，即通过其他方式 (如门户网络) 来访问历史状态的替代方案
Vitalik 针对历史数据休眠的 AMA

状态休眠 — 关于状态，修复 “一次性支付，数据永久储存” 的问题

这个想法主要关于让状态未使用的部分自动休眠，只保留一个 verkle tree 根，如果需要的话，用户可以用它来激活休眠的状态
Vitalik 针对状态休眠机制的 AMA
依赖于这些工作：

- 基本的状态休眠规范：我们打算如何实现它，请看这个潜在的路线图 (和其他选项)

- 地址空间扩展：增加地址尺寸大小，从 20 字节增加到 32 字节，以防止冲突，并增加关于状态周期的数据

- 应用分析：搞清楚它会如何破坏当前的应用/合约，以及这些应用/合约需要如何适应

日志改革 — 简化事件日志的工作方式，以便更有效地搜索历史事件

序列化协调 — 执行层使用 RLP 进行数据序列化，而共识层使用 SSZ，这将会使得逐渐抛弃 RLP，而使用 SSZ

移除旧的交易类型 — 停止支持旧的交易类型 (参阅 EIP-2718) 以移除客户端的代码复杂性 (牺牲一些向后兼容性)

EVM 简化路线

取消 SELFDESTRUCT — 这个操作码是许多问题的根源

- 消除 SELFDESTRUCT 的实用解决方法解释了为什么以及怎么样移除这个操作码

- 相关 EIP：EIP-4758、 EIP-4760 以及讨论
简化 gas 机制 — 涉及移除许多与 gas 相关的 EVM 功能，在此处提及过
预编译 -> EVM 实现 — 舍弃预编译合约，采用直接 EVM 实现 (即大型模运算，见 The Splurge)

目标：完善其他东西

所有那些不需要更高优先级的好东西都属于 The Splurge 这一部分中。最大的一项就是账户抽象，但也有对现有内容的小调整。

已完成的工作

EIP-1559 — 这个著名的 EIP 带来了许多好处，而不仅仅是销毁 ETH

ERC-4337 规范 — 这个ERC 旨在不修改核心协议的情况下引入账户抽象