ETH2030：智能体编程以太坊客户端，面向 2030+ 路线图

ETH2030: Agentic Coding ETH 客户端 2030+ 路线图

我们希望开诚布公：这不是一个生产客户端。我们不是客户端开发者。我们拥有的是一个粗略的草稿——702,000 行 Go 代码，它们可以编译、通过测试并与网络同步。验证此路线图的竞争压力是真实存在的。Firedancer 已经在 Solana 上投入生产。MegaETH 旨在实现 10 万 TPS。Monad 的并行 EVM 已在主网上线。以太坊的路线图比它们任何一个都更具雄心，但我们不能等到 2030 年才发现这些组件无法协同工作。我们需要深入了解此领域的人士来查看代码，找出我们的错误之处，并帮助社区了解在客户端团队投入多年的生产工程之前，哪些部分需要重新思考。

路线图实际内容

L1 路线图将以太坊的路线图组织成三个层级——共识、数据和执行——跨越八个命名的升级阶段。战略框架采用了五大支柱：野兽模式 (Beast Mode)（原始吞吐量）、精简模式 (Lean Mode)（通过 Verkle 和历史数据过期实现节点效率）、堡垒模式 (Fort Mode)（后量子硬化）、去中心化 (Decentralization)（1 ETH 独立质押、分布式构建）和快速终结性 (Fast Finality)（3-slot 终结性、快速插槽）。每个阶段同时在所有三个层级引入功能，这使得路线图既雄心勃勃又具有架构风险。如果没有 BALs，就无法实现 3SF；如果没有 Gas 重新定价，就无法实现 BALs；如果没有同时调整 Blob 调度和 PeerDAS 参数，就无法实现 Gas 重新定价。这种耦合是真实存在的。

经得起考验的架构

ETH2030 中最明智的决定是它如何与 go-ethereum 集成。该项目没有分叉 geth，而是将 go-ethereum v1.17.0 作为 Go 模块导入，并通过 pkg/geth/ 中的单个适配器包对其进行封装——这是整个 50 个包的代码库中唯一导入 go-ethereum 的位置。该适配器有四个文件：processor.go（通过 gethcore.ApplyMessage 进行区块处理）、extensions.go（通过 evm.SetPrecompiles() 实现 13 个自定义预编译）、statedb.go（由 geth 真实的 trie DB 支持的状态创建）和 config.go（分叉名称映射）。此层级之上的一切——共识、数据可用性、Rollups、zkVM、后量子密码学——都是 eth2030 原生代码。

正是这种分离使得 100% EF 状态测试符合性成为可能。36,126 个测试向量通过 go-ethereum 的生产 EVM 运行，eth2030 的类型通过适配器进行映射。eth2030-geth 二进制文件更进一步：它嵌入了一个完整的 go-ethereum 节点——Pebble 数据库、RLPx P2P、devp2p 发现、快照同步——并在 Glamsterdam、Hogota 和 I+ 分叉时间戳注入 13 个自定义预编译。结果是与 Sepolia 测试网同步（经证实约 9,000 个区块头/秒）并连接到主网，同时在此之上实现了完整的路线图。

实际构建所有 65 个项目教会了我的事

有些知识你可以通过阅读规范获得，有些知识你只能通过实现规范才能获得。这八个发现是从在一个代码库中编写、编译和测试 94+ 个 EIP 相互对抗中得出的。

失败之处

最直接的生产差距是密码学性能。ETH2030 使用纯 Go 实现 BLS12-381、KZG、ZK 证明、Verkle IPA 和后量子格运算。生产客户端使用优化的 C 语言 (supranational/blst)、Rust 语言 (go-eth-kzg) 和混合 C/Go 语言 (gnark)。性能差异通常是 10-100 倍。运行 eth2030 纯 Go BLS 的验证者将错过一个数量级的证明截止日期。

共识实现架构上完整，但操作上未经测试。3-slot 终结性、快速插槽、PQ 证明、100 万证明扩展器、jeanVM 聚合——所有这些都有 Go 实现和验证函数。但它们都没有处理过来自实时信标链的真实证明。从“ValidateAttestation() 返回 nil”到“在 MEV 高峰期间的重组攻击中幸存下来”的差距是以多年的工程时间来衡量的。

千兆 Gas 目标值得特别审查。GigagasConfig 指定 1B Gas/秒，具有 16 个并行执行插槽。当前以太坊总共处理约 5M Gas/秒。BAL 并行执行框架具有冲突检测器、调度器管道和依赖图。理论上它能工作。但在实践中，针对真实状态的并行执行——带有重入保护、跨合约回调、MEV 捆绑依赖以及强制序列化的 ERC-20 批准模式——是一个比针对合成测试进行并行执行更基本困难的问题。

完成的路线图会带来什么

如果路线图上的每个项目都按计划发布——所有八个阶段，共 65 个项目——以太坊会变成什么样子？来自 eth2030 实现的数据，与 EF 预测和参考客户端中硬编码的规范参数交叉引用，描述了一台与今天运行的机器几乎无法识别的机器。每个主要维度都提高了 1 到 3 个数量级，只有一个值得注意的例外情况变得更糟——而这个例外告诉我们一些关于真实安全成本的重要信息。

对比

这个领域的其他项目都只构建难题的一部分。ETH2030 是唯一一个涵盖整个以太坊路线图——所有八个阶段、所有三个层级、所有 65 个项目——的实现。这种广度既是其独特的价值，也是其根本局限性。

五年之问

有些知识只能通过构建东西才能获得。阅读 EIP-7928 规范会告诉你区块访问列表 (Block Access Lists) 跟踪并行执行的状态依赖关系。而实现它则会告诉你，回滚调用、空账户的 EXTCODEHASH 查找和系统合约交互都会生成需要跟踪的状态访问——而且冲突图比任何仅通过阅读交易池所预期的都要密集。一个参考实现生成的不是生产质量的代码，而是生产质量的问题。

从每秒 500 万 Gas 到 10 亿 Gas 的距离不仅仅是数量上的。这是以太坊作为一个结算层和以太坊作为一个全球执行平台之间的距离。这个差距能否在 2030 年之前弥合，取决于四个工程现实，这些现实是任何规范或参考实现都无法解决的。对抗性 MEV 下的并行执行，其中搜索者故意构建旨在强制序列化的状态访问模式。2 亿现有 ECDSA 账户的后量子迁移，不破坏向后兼容性。ZK 证明延迟——当前最先进的技术是在 24 个 GPU 上实现 7.4 秒，但快速插槽每 6 秒运行一次。以及以太坊社区能否同时在所有三个层级保持协调一致的进展，因为路线图不是菜单——如果没有 BALs，就无法获得千兆 Gas；如果没有快速插槽，就无法获得 3SF；如果没有底层的 ZK 堆栈，就无法实现原生 Rollups。

eth2030 实现中在其 E2E 测试中揭示的耦合，正是使得路线图对延迟敏感的同样原因。如果 Glamsterdam 延迟发布，Hogota 的多维 Gas 就没有基础。如果 PeerDAS 延期，原生 Rollups 将失去其数据可用性。当所有项目都按计划发布时，路线图会完美地组合起来。路线图很少按计划发布。

然而。所有 65 个项目都适配到一个代码库中。类型对齐。接口连接。三万六千个状态测试通过。节点与主网同步。这比大多数五年技术路线图在任何人编写一行代码之前所能达到的成就都要多。完成路线图的以太坊——PayPal 规模的 L1 吞吐量、秒级终结性、3,000 美元的独立质押、商品硬件上的无状态验证、抗量子密码学——是一个真正引人注目的愿景。它构成了整体。它能否发布是另一个问题，现在通过代码提出这个问题，而不是等到 2030 年答案变得更昂贵时，对社区来说是正确的。

• 原文链接： x.com/yq_acc/status/2026...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～