Optimism Kona v1.8.0 修复派生过程中的对齐和批次处理问题

Optimism 于 10 月 1 日发布了 Kona v1.8.0，为其基于 Rust 的故障证明栈带来了派生、证明执行、TLS 依赖项和原像处理方面的修复。此次更新解决了一个狭窄的边缘情况：在特定的故障批次提交者场景下，格式错误的批次可能导致 Kona 派生出与 op-node 不同的链。Optimism 建议所有链使用此版本，并明确指出，kona-host 必须与匹配的 kona-client v1.8.0 严格配套运行，以维持整个 OP Stack 中的派生一致性。

Kona v1.8.0 在 Holocene 之后执行更严格的父哈希验证

在 Holocene 升级之后，Kona 现在会以与 op-node 相同的方式，针对安全头验证每个批次的父哈希。Optimism 指出，之前的检查始终会通过，这造成了一种情况：生成格式错误批次的故障批次提交者可能导致 Kona 派生出与 op-node 不同的链。该团队澄清，除非批次提交者确实出现异常，否则故障证明不会受到影响；但跨客户端保持一致的派生行为，是故障证明系统的核心一致性要求。这种一致性也延伸至 Super Root 争议游戏治理中体现的故障证明路线图，以及 Superchain 互操作性测试。

执行错误现在可区分无效载荷与缺失数据

Kona v1.8.0 改变了证明执行处理区块处理期间错误的方式。只有在载荷确实无效时，区块才会根据早期条件被替换为仅包含存款的区块或被丢弃。现在，缺少原像或见证数据等错误会停止执行，而不会被视为载荷本身无效的证据。这一区分将计算不完整性与载荷无效性分开，对于必须区分“我无法完成这项计算”和“这项计算证明该区块无效”的故障证明系统而言，这是关键要求。该版本还更新了以太坊虚拟机实现，修补了一个 TLS 依赖项，并改进了原像服务器的错误处理。

客户端多样性提高了验证一致性要求

Optimism 的基础设施日益采用多种实现和证明系统，而不是单一的规范软件栈。客户端多样性提高了韧性，但也带来了新的要求：独立实现必须在状态转型和边缘情况下精确达成一致。同样的维护负担也出现在 Optimism 要求的 op-batcher 版本发布和其他运营者更新中。Kona v1.8.0 专注于确保验证层在输入格式错误时仍能以可预测的方式运行，从故障证明基础设施层面解决可靠性问题，因为一致性在这一层面最为重要。

常见问题

Optimism 于 10 月 1 日发布了什么？
Optimism 发布了 Kona v1.8.0，这是其基于 Rust 的故障证明栈的一次维护更新，修复了派生、证明执行、TLS 依赖项和原像处理问题。

为什么 Kona v1.8.0 要改变父哈希验证？
在 Holocene 升级之后，Kona 现在会像 op-node 一样，针对安全头检查每个批次的父哈希，从而防止格式错误的批次在故障批次提交者场景下导致 Kona 派生出与 op-node 不同的链。

Kona v1.8.0 如何以不同方式处理执行错误？
Kona v1.8.0 现在仅在载荷确实无效时替换或丢弃区块，而缺少原像或见证数据等错误会停止执行，而不会被视为载荷无效的证据。