一、合并（The Merge）目标：拥有一个理想的、简单的、健壮的以及去中心化的权益证明（PoS）共识。 已经完成了什么1、2020 年 12 月 1 日 - 信标链启动。

引入由验证者质押的 ETH 保护的以太坊共识层；

在共识规范中称为阶段 0‌（Vitalik 以及 Danny Ryan 的注释版本）；2、2021 年 10 月 27 日 - 预热分叉 (Altair) - 共识客户端开发人员试运行了一次协调硬分叉升级。

Altair 引入了同步委员会‌来支持轻客户端，并调整了一些惩罚措施；

Altair 公告；‌

Altair 规范‌（注释版‌）；

关于 Altair 的“ What’s new in ETH2” 文章；3、2022 年 9 月 15 日 - 合并！ 不再有 PoW——共识层和执行层在区块高度达到 15,537,394‌ 时进行了大合并。 下一步是什么1、提款 – 使验证者能够提取全部或部分质押 ETH 权益。

Capella 分叉‌指定共识层的变化；

EIP-4895‌ 指定了执行层的变化；

Tim Beiko 关于提款的常见问题解答‌；

带有其他信息的提款元规范‌；2、分布式验证器——引入多重签名，其中 n 个人共享同一个验证器，m-of-n 必须就其行为方式达成一致。

通过防止意外罚没使其更易于访问（例如，通过在多个参与者之间无需信任地分配所需的 32 ETH）来增强质押；

这不是协议内的事情，SSV‌ 和 Obol‌ 等团队正在为此而努力；3、视图合并——调整分叉选择规则(验证器投票的方式)，以减轻一类攻击。

本质上使诚实的验证者能够“强加”他们对链的正确 head 的看法，以减少恶意验证者分裂投票并在之后按照自己的意愿重组区块的机会；

ethresear.ch 帖子‌有很多（非常技术性的）研究背景；4、改进聚合 —— 以太坊努力支持尽可能多的验证者，但让每个验证者对每个区块进行投票（并验证其他所有验证者的投票）过于占用带宽。下一个最好的事情是聚合签名，但这也有其局限性，并且可以做得更好。

关于 BLS 聚合好​​处的科普贴；‌

潜在候选方案：Horn；‌5、单 slot 最终性（SSF）——每个 slot （12 秒）确定链，而不是按 epoch （12.8 分钟）来确定。

通往 SSF 的路径；‌

除了改进的签名聚合，我们还需要解决另外两件事:（1）SSF 共识算法——现有与 SSF 兼容的算法是不够的，我们想要一个即使超过 1/3 的验证器离线，也能保持链活跃的算法； （2）SSF 验证者经济学——如果我们最终不得不限制验证器的数量，我们如何限制参与，我们会做出什么牺牲？ 6、秘密 leader 选举（SLE）

今天，被选中提议一个区块的验证者（slot 的 leader）会提前被知道，这使得潜在的 DoS 攻击能够专门针对即将到来的区块的 leader。

ethresear.ch‌ 关于随机洗牌的单一 SLE 协议的帖子：除了 leader 自己，没有人知道谁将成为 slot 的 leader，直到他们揭示他们的区块以及他们的领导力证明。

非单一秘密 leader 选举‌也可能是一种选择。7、支持更多的验证器——持续的长期努力：安全地支持更多验证器总是可取的。 8、量子安全的聚合友好签名 —— 使以太坊免受量子计算机攻击。

众所周知，以太坊所使用的 BLS 签名方案背后的密码学被量子计算机破解了，但已知的量子安全的替代签名方案不如 BLS 签名方案那样有效地聚合（因此需要一种既量子安全又对聚合友好的方案）；

两种领先的量子安全方法是基于 STARK‌ 以及 基于 Lattice；9、实施 EIP-4844 —— 将 EIP-4844 应用到以太坊主网。

将需要一个“仪式”来创建可信设置：解释‌、预计时间表‌、规范；‌

EIP-4844 实施时间表概述‌；10、基础 rollup 扩容 —— 依赖于以下内容：

EIP-4844 - 由于“每个节点下载所有数据”的性质限制了 blobspace 的可用容量，扩容仍然被认为是基本的/有限的；

Rollup 有限的辅助轮（参见提议的里程碑‌）；11、完整 rollup 扩容 —— 依赖于以下内容：

数据可用性采样的 P2P 设计：涉及对数据分片所需网络的所有努力和研究

DA 采样客户端：开发轻量级客户端，可以通过几千字节的随机采样快速判断数据是否可用

高效的 DA 自我修复：能够在最恶劣的网络条件下有效地重构所有数据（例如恶意验证者攻击，或大量节点的长时间停机）

摘除辅助轮的 rollup：完全去中心化的排序器、无需信任的欺诈证明者、不可变的合约等。12、量子安全以及无可信设置的承诺 —— 让以太坊免受量子计算机影响。

虽然多项式承诺(KZG)高效而强大，但它们不是量子安全的，并且需要一个可信设置。对更理想的长期承诺的研究正在进行中，最终目标是在底层“热插拔”KZG；二、The Scourge 目标：确保可靠可信的中立交易包含，并避免 MEV 的中心化以及其他协议风险。 相关链接：

以可靠的中立为指导原则‌；

关于 MEV 的各种推特帖‌；

关于 MEV 和 PBS 的文章‌；

关于 PBS 的链接列表‌；已经完成了什么1、协议外 MEV 市场——MEV-Boost‌ 中间件允许普通验证者从 MEV 中获利，而无需自己运行复杂的 MEV 策略。

该解决方案本身并不完整，因为它存在审查问题‌；

请参阅弹性成本‌以及 SUAVE‌，了解使这些协议外市场更具弹性的想法和计划；下一步是什么1、包含列表或替代方案——让区块提议者对区块构建者施加限制，即强制他们包含交易。 （1）包含列表注释‌； （2）研究在不给区块提议者增加负担的情况下约束区块构建者‌； 2、协议内 PBS – 将区块构建者的市场直接纳入协议中。 3、MEV 销毁——让区块链捕获从链上经济中提取的价值。 （1）通过提议者拍卖的直接销毁 MEV 提案‌； （2）委员会驱动的 MEV 平滑‌将使协议能够感知 MEV； （3）通过经济激励限制验证者集‌，将通过负发行间接燃烧 MEV； 4、应用层 MEV 最小化——不直接与 L1 相关，该项目涉及开发人员在设计 dapp 时将 MEV 考虑在内。这里是一些采用 MEV 最小化策略的 dapp 示例‌。 分布式 builder 轨道随着区块提案保持去中心化，我们现在有一个单独的问题，即区块构建变得中心化。即使路线图上的所有其他项目，都旨在最大限度地减少集中式区块构建的最坏可能负面影响，但能够跨多个节点分发区块构建仍然是一个主要的好处。

Blob 构建 - 寻找方法，以减轻在普通消费硬件可以运行的多个节点上进行数据分片的高带宽和处理需求；

预确认服务 - 给用户强有力的保证，他们的交易将被包括在下一个区块；

领先保护 - 最大限度地减少有毒的 MEV，例如三明治交易，以保持分布式构建可靠的中性；它仍然是一个活跃的研究领域，具有非常开放的设计考虑，因此不清楚前两项是否应该包含在协议当中（因此在路线图上是问号状态）。 以下是一些相关链接：

谈合并后的区块构建‌，其中提到了去中心化的区块构建；

谈谈去中心化区块构建者；‌

关于分布式区块构建的一些想法；‌ 三、The Verge 目标：验证区块应该超级简单——下载 N 字节数据，执行一些基本计算，验证一个 SNARK 就完成了。 这个阶段本质上是通过最终实现轻客户端来填补“客户端空白‌”：不是每个人都想或能够运行一个全节点。 The Verge 的目标是引入无需信任或信任最小化的替代方案，这些替代方案易于运行且不需要大量存储和带宽。 The Verge 的最终目标是让这些轻客户端提供与今天的全节点相同的安全保证。 一切都依赖于零知识技术，例如 SNARKs 和 STARKs，而它们本身依赖于多项式承诺方案。以下是一些相关链接：

大概介绍 zk-SNARKs 是如何实现的‌；

关于 STARK 的剖析‌；

如果你懂一些数学和编程，这篇文章就可以让你明白什么是 zk-SNARKs‌；

关于多项式承诺（Polynomial Commitment）方案在扩容以太坊中的作用‌；已经完成了什么1、解决了最严重的 EVM DoS 问题——主要是 gas 定价问题，已在柏林升级中修复‌。 2、基本的轻客户端支持（同步委员会）——多亏了同步委员会，很容易构建遵循共识层的轻客户端。

查看 Helios 客户端‌如何利用同步委员会（以及关于这些委员会如何工作的精彩文章）下一步是什么1、SNARK / STARK ASIC——专为创建证明而构建的硬件。 2、Verkle 树 - 用更高效的数据结构替换用于全局状态的数据结构 （1）关于 Verkle 树的链接列表‌； （2）关键的好处是拥有非常短的证明，轻客户端可以轻松地验证这些证明，以仅使用区块头来验证账户余额之类的东西——他们已经可以利用同步委员会来验证给定的区块头实际上是主链的一部分； （3）依赖于找出正确的规范，如何安全过渡，以及它将如何影响更新/编辑状态的 EVM gas 成本（也依赖于禁止 The Purge 中的 SELF-DESTRUCT ）； 3、基于 SNARK 的轻客户端 – SNARKify 同步委员会过渡以快速证明当前同步委员会由哪些验证者组成 4、完全 SNARKed 的以太坊 – 以下 3 项加在一起构成了以太坊拥有极其高效和无需信任的区块验证终局阶段的一个重要里程碑： （1）用于 Verkle 证明的 SNARK——通过将 Verkle 证明合并到一个 SNARK 中，区块将包含一个关于它们修改的部分状态的简短独立证明，因此无需验证区块 N-1 的整个状态来验证区块 N 是否正确修改了它。 （2）用于共识状态转换的 SNARK——从信任最小化的同步委员会转移到对共识层上发生的一切进行完全无需信任的验证。 （3）L1 EVM 的 SNARK——通过将 zk-EVM 直接集成到 L1 中，利用 rollup 团队在 zk-EVM 上所做的努力（请参阅有关 enhrined rollups ‌的帖子）。 5、增加 L1 gas 限制——通过消除今天“每个节点都需要存储所有东西”的负担以无需信任的方式验证区块，拥有更大的区块将更容易获得更多的 L1 可扩展性（这将自动复合所有 L2 扩展） 6、转向量子安全的 SNARK（例如 STARK）——使以太坊免受量子计算机攻击（SNARK 的有效性，依赖于已知被量子计算机破解的密码学，而 STARK 则不然）。 四、The Purge 目标：简化协议，消除技术债务，并通过清除旧历史限制参与网络的成本。 已经完成了什么1、消除大部分 gas 退款——柏林升级中完成的所有 gas 重新定价‌。 2、信标链快速同步——所有的开发工作都是从最近完成的 epoch 开始同步，而不是从起源同步(在大多数共识客户端中称为“检查点同步”)。 3、EIP-4444规范—参见 EIP 规范‌ 。 下一步是什么1、历史过期——通过让旧历史过期来减少存储要求、同步时间以及代码复杂性。 （1）看这个推特贴‌； （2）依赖于 EIP-4444 的实现，这取决于通过其他方式（如 Portal Network）访问替代历史记录 （3）Vitalik 关于历史到期的 AMA；‌ 2、状态过期——解决关于状态的整个“支付一次，数据永久存储”问题。 （1）这个想法是自动使状态的未使用部分过期，并且只保留一个 verkle 树根，用户可以在需要时使用它来恢复过期状态； （2）Vitalik 关于状态过期的 AMA‌； （3）依靠：基本状态到期规范——我们实际上是如何做到的，查看潜在的路线图‌（和其他选项‌）；

地址空间扩展——将地址大小从 20 字节增加到 32 字节‌，以防止冲突并添加有关状态周期的数据；

应用程序分析——找出它可能如何破坏当前的应用程序/合约以及它们如何适应；3、日志改革——简化事件日志‌的工作方式，以更有效地搜索历史事件。 4、序列化协调——执行层使用 RLP‌ 进行数据序列化，而共识层使用 SSZ‌，这将摆脱 RLP，而在所有地方使用SSZ。 5、删除旧的事务类型——停止支持旧的事务类型（参见 EIP-2718‌），以从客户端删除代码复杂性(以一些向后兼容为代价)。 6、EVM 简化轨道。 （1）禁止 SELFDESTRUCT——这个操作码是许多问题的根源（相关 EIP：EIP-4758‌ 和 EIP-4760‌ 及讨论‌）； （2）简化 gas 机制——涉及删除此处‌提到的许多与 gas 相关的 EVM 特性； （3）预编译——> EVM实现——摆脱预编译合约‌，支持直接 EVM 实现（即大模块化运算，参见 The Splurge）； 五、The Splurge 目标：修复其他一切 所有更高优先级升级所不需要的美好改进，都属于 The Splurge。最大的改进项目是帐户抽象‌，但也是对现有事物的小调整。 已经完成了什么1、EIP-1559‌——这个著名的 EIP 除了燃烧 ETH 之外还有很多好处‌。 2、ERC-4337 规范‌——该 ERC 旨在在不修改核心协议的情况下引入账户抽象（ERC-4337 的初始解释文章‌）。 下一步是什么1、最终阶段的 EIP-1559 – 通过多维‌增强 EIP-1559。 2、EVM 改进轨道以及从 The Purge 到 EVM 最终阶段的简化轨道。 （1）EVM 对象格式 (EOF) — 一组 EIP，允许在部署 EVM 字节码时进行验证和版本控制。请看这篇解释文章‌和推特帖‌； （2）大模块化运算——路线图中的很多密码学都依赖于非常大的数字进行模运算，这可以直接在 EVM 中更有效地完成； （3）进一步的 EVM 改进——任何其他值得添加以改进 EVM 的东西——或者为了消除复杂性‌而删除的任何东西； 3、导致最终阶段帐户抽象的帐户抽象轨道。有关详细信息，请参阅 Vitalik 对以下项目的描述‌： （1）ERC-4337 – 开发真正获得采用的兼容智能钱包； （2）自愿 EOA 转换——通过 EIP，让普通账户不可逆地添加代码将其转换成合约账户，即成为符合 4337 标准的智能钱包； （3）协议内转换——使所有现有帐户都必须进行上述转换； 4、可验证延迟函数（VDF）——本质上是“不可并行的工作量证明”，它将增强 PoS 以及其他事物的随机性‌（请参阅关于 VDF 及其潜在用途的 ethresear.ch 帖子‌） 5、探索粉尘账户的解决方案——拯救“粉尘资金”，这些资金的移动成本高于其价值。在这里有一堆想法‌。