提议的扩容闭环包括三步：提前发现瓶颈，使用性能监测工具识别问题。对瓶颈分类：客户端实现、扩容封装手段或协议重构。在触及上限前采取对策，提前优化系统表现这套流程能够实现更平滑、更安全的网络升级。 三类缓解路径被明确提出：1）纯工程优化：仅限于客户端的优化，不需分叉。2）封装微调：轻量级的分叉调整，比如 gas 价格重新定价。3）协议重构：较大的改动，如 slot 重组或 ePBS（去中心化提议者 / 构建者分离）。不同阶段可灵活选择不同路径。路线图被划分为三个阶段：现在至 2025 Q4（Glamsterdam 升级）：聚焦客户端调优与小幅协议修补。2025–2027：基于真实数据推进协议级升级。2027 年以后：zkEVM 改写规则，重构状态、数据与执行模型。 一个重要但仍缺失的主题：并行化（Parallelism）。当前以太坊的执行流程仍然是串行的。真正的扩容必须实现确定性的并行执行。相关工作包括 Block Access List（区块访问列表）。Long Access List（长访问列表）。Optimistic Concurrency（乐观并发执行）。这需要规范制定与客户端同步推进。为此，一个性能仪表板已上线：每个执行层客户端在独立的 perf 分支上运行基准测试。目标是最坏情况下也能达到 ≥ 20 Mgas/s 的执行速度若达不到这个标准，提升 L1 gas 上限至 60–100 Mgas 就是不安全的。测试已将 Devnet-1 与主网 Shadow Fork 推至 100 Mgas：结果发现了真实的 CPU 与状态访问瓶颈，验证了工具有效性，并揭示了哪些客户端性能落后。 有一种设想：让共识层动态发布「安全 gas 上限」，根据近期网络情况做出调整，避免在高负载时发生传播失败。要在 3 秒内验证一个 60 Mgas 区块，客户端必须维持约 20 Mgas/s 的处理速度。如果是 100 Mgas 区块，则需要达到 33 Mgas/s。这些数据直接决定客户端性能目标。未来基准测试将整合更多场景：Re-org（重组）情形。混合状态 + 计算压力测试。高负载下的 RPC tip 延迟测试。目标是定义一个统一的区块处理超时时间（当前 Geth/Erigon 默认为 2 秒）。【原文为英文】\n原文链接