1个月后，ETH2030的Devnet已运行

一个月前，我们拥有 80 万行 Go 代码，涵盖了整个 以太坊 L1 Strawmap。它编译通过了。它通过了 36,126 个状态测试。它以 9,000/秒的速度同步区块头。但没有人能指着它说：这是一个在实时网络上运行下一代功能的、可工作的以太坊客户端。

在对 eth2030.com 进行 30 天的调试之后——包括共识分歧、状态根分歧、时序竞争，以及那种让你质疑职业选择的堆栈跟踪——开发网络终于运行起来了。3 个 Lighthouse + 3 个 ETH2030 节点，分阶段分叉激活（Fulu → Gloas → Heze），强制执行 FOCIL 包含列表，执行 Frame 交易，启用 BAL 预取。以太坊核心开发者仍在规范中讨论的功能？我们已经让它们生成区块了。

但“运行”和“工作”是两码事。以下是坦诚列出的出了什么问题，我们修补了什么，以及仍然根本未解决的问题。

什么不工作：跨 EIP 鸿沟

每个 EIP 都有一个规范。没有规范描述 EIP 之间如何交互。这并非文档的缺失——而是以太坊升级设计方式的结构性问题。EIP 由不同的团队在不同的时间，基于不同的假设编写。只有当有人尝试将它们一起运行时，交互才会浮出水面。

那个人就是我们。以下是没有规范预测到的三种交互。

什么不工作：静默故障

跨 EIP 集成是一个有趣的问题。但开发网络也暴露了一类更令人担忧的错误：产生错误结果而不是报错的静默故障。

Engine API 错误

5 个 Engine API 错误 (PR #12)，每个错误在开发网络运行之前都是不可见的：

• 首次读取后 Payload map 被删除：区块一旦构建，便消失了。
• GlamsterdamTime 从创世加载器中缺失：整个 Glamsterdam 分叉被静默忽略，在应该是一个 Glamsterdam 后开发网络上运行着 Deneb 时代的共识。
• big.Int.Uint64() 静默截断：大值被截断为零。
• JSON SetString 失败：默认为零而不是报错。
• Engine API 端口没有 CORS：Dora 始终无法连接，但从 EL 端看开发网络是健康的。

模式：每个错误都产生了一个看起来能工作的客户端。它编译通过了，通过了单元测试，甚至处理了一些区块。故障只在单元测试未覆盖的特定开发网络条件下显现。这是大规模 AI 生成代码的根本问题——测试通过，因为测试是与代码一起生成的，源于同样不完整的理解。

CL 对等节点消失

这是最持久的问题，花了一整周时间。Lighthouse 节点下降到零对等节点，并构建了独立的链。PeerDAS/Fulu gossip 评分正在惩罚 ETH2030 节点并断开它们的连接。没有错误消息——CL 只是悄悄地停止与所有人通信。修复进展：禁用 PeerDAS → 重新启用并进行调整 → --disable-peer-scoring + genesis_delay=60。

RWMutex 死锁

evictOldBlocks() 在现有 blocksMu.Lock 下获取 blocksMu.RLock。测试永远挂起。Geth 上游 (PR #40) 在几周后独立合并了相同的修复——这是一个并发模型中的真实架构问题，而不是 AI 生成的产物。当你的 AI 生成代码与人类编写的参考客户端存在相同的错误时，问题出在设计，而不是生成器。

Geth 兼容性错误

通过针对参考 Geth 节点运行相同场景，才发现了 10+ 个 Geth 兼容性错误：

• 收据中区块范围的日志索引错误。
• debug_traceTransaction callTracer 格式不正确。
• estimateGas intrinsic gas 错误。

规范描述了正确的行为。但实现在未文档化的边缘情况上有所不同，这些情况只在生产环境中才会显现。

什么不工作：这种规模的 Agent 工程

6 天编写 80 万行代码。30 天使其保持共识。5:1 的比率是一个发现，它告诉你关于软件工程未来的重要信息：瓶颈从来都不是编写代码。它始终是理解代码如何交互。AI 只是让这一点变得明显。

Agent 在明确描述要检查什么之后，编写了 FrameVerifier 接口。但它无法识别出需要进行此检查。FOCIL 规范没有提及 Frame 交易。Frame 交易规范没有提及包含列表。Agent 忠实地阅读规范并精确实现它们所说的——遗漏了规范中没有描述的每一个交互。

这才是真正的教训：集成鸿沟存在于规范之间的空白中，而所有艰巨的工程都发生在这个空白中。不是在编写函数。不是在实现算法。而是在理解为什么区块 4,217 处的共识分歧意味着 FOCIL 满足度检查无法处理 0x06 类型支付方解析。

我们的 CLAUDE.md 增长到 500 多行——这不是文档，而是为患有失忆症的 Agent 准备的持久记忆：

## 来之不易的规则（每条都花了数天时间才发现）在验证 IL 交易时，首先检查交易类型。如果类型为 0x06，则在余额检查之前从 APPROVE Frame 中提取支付方。BAL 不匹配是调试级别，而不是无效——仅为建议性提示。Frame 交易收据使用 ContractAddress 字段作为支付方。不要将其设为 null。根据 EIP-7701，AA 交易类型为 0x05，而不是 0x06。不要与 Frame 交易混淆。

如果没有这个文件，每次新的会话都会重新发现相同的错误。有了它，Agent 可以 95% 的自主性修复代码库中有限的问题。这个指令文件才是实际的规范——它描述了系统的现状，而不是任何单个 EIP 设想的系统应有的样子。

多 Agent 协作部分成功，部分失败。4 个并行 Agent 在 5 个冲刺中构建了区块构建管道（20 个文件）。然后会话遇到了 403 session_binding_error，我们丢失了上下文。多个会话以“从之前失去上下文的对话继续”结束。洞察：ePBS、FOCIL、PeerDAS 和 Frame 交易之间的依赖关系图比任何单独的实现都更重要。AI 可以并行化叶子节点。而根——理解这棵树如何连接在一起——仍然是顺序的，仍然是人类的，仍然很困难。

那么，究竟什么有效呢？

开发网络生成区块。FOCIL 强制执行具有 Frame 交易感知的包含列表。Frame 交易通过自定义验证和按 Frame 收据执行。BAL 预取启用了并行执行提示。367+ 个插槽，9+ 个已最终确定的 epoch，15-200 毫秒的区块处理时间。

它还没有达到生产就绪状态。它也没有经过优化。Slashing 的边缘情况尚不完善。但它是一个与 Geth 完全不同的替代方案，实现了 EIP-7805、EIP-8141 和 EIP-7928 之间的集成，而这种集成在任何生产客户端中都不存在。集成分支上的 1,764 行代码是唯一处理 FOCIL 包含列表中 Frame 交易的代码。

ETH2030 最初是一个问题：你能用 Agent 编码构建整个以太坊路线图吗？两个月后，更有趣的答案是关于你不能用它构建什么。你可以在 6 天内生成 80 万行代码。但你无法生成这些代码如何交互的知识。这些知识需要 30 天的时间观察开发网络以规范中未曾预测的方式出现故障。

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