1/我们很高兴在#ConsensusAtSBC上宣布 Specular ，这是第一个 *EVM-native* optimistic rollup (ORU)。Specular 提供了比现有的 EVM 等效 ORU 更强大的安全性和去中心化属性。让我们深入挖掘。
2/在 EVM 原生的 ORU 范式中，欺诈证明是在 EVM 指令级生成和验证的。也就是说，链上防欺诈验证者严格执行以太坊规范。
3/相比之下，当前与 EVM 等效的 ORU 将 Geth 编译为特定的 ISA (WASM/MIPS) 二进制文件，并在其 VM 上生成欺诈证明。他们的链上验证器强制正确执行 ISA 指令，而不是以太坊规范。
4/需要对已编译的 Geth 二进制文件进行额外的链上承诺（Merkle 根），以确保它正在验证 Geth，而不是编译到自定义 ISA 的任意程序。
5/这导致可信计算库（TCB）庞大，缺乏对 L2 客户端多样性的支持，升级透明度差，升级频繁。EVM 原生设计优雅地解决了这些问题。
6/ ORU 防欺诈设计的 TCB 是符合以太坊规范的安全关键代码库。
7/对于 EVM 等效的 ORU，TCB 包括链上验证者、链下客户端和整个编译工具链。
8/与 EVM 原生 ORU 中的验证者相比，与 EVM 原生 ORU 中的验证者相比，必须检查 TCB 内的更多组件，因为验证者只是执行以太坊规范，并且与任何特定的客户端实现。
9/ EVM 等效的 ORU 仅允许特定客户端（当前仅 Geth）参与争议解决，因为不同的类型 + 版本编译为不同的二进制文件，并具有不同的执行跟踪/欺诈证明。必须明确*支持*客户才能参与。
10/在 EVM 原生 ORU 中，由于所有客户端（无论类型如何）都实现了相同的状态转换（根据以太坊规范），它们自然会生成相同的欺诈证明。验证者只验证规范，并且与客户端实现无关。
11/对于 EVM-native ORU，任何符合以太坊规范的客户端都可以参与链上验证者的挑战，包括未来用新语言编写的新客户端。
12/ Wrt 升级，当向客户端或编译工具链引入*任何*更改时，等效于 EVM 的 ORU 需要更新验证器中的链上二进制提交。庞大的 TCB 基础可能还需要进行广泛的审计，以确保不会引入新的漏洞。
13/对于 EVM 原生的 ORU，仅当 L2 以太坊规范发生变化时才需要升级，升级的本质是智能合约的形式，这使得哈希承诺具有更好的透明度。
14/我们很乐意让您参与构建 Specular！查看specular.network并在@SpecularL2关注我们以获取更多信息。
