Thread by @SpecularL2

1/ We are excited to announce Specular at #ConsensusAtSBC, the first *EVM-native* optimistic rollup (ORU). Specular provides stronger security and decentralization properties than existing EVM-equivalent ORUs. Let’s dig in. 1/N 🧵

2/ In the EVM-native ORU paradigm, fraud proofs are generated and verified at the EVM instruction-level. That is, the on-chain fraud proof verifier strictly enforces the Ethereum specification.

3/ In contrast, current EVM-equivalent ORUs compile Geth to a specific ISA (WASM/MIPS) binary, and generate fraud proofs on its VM. Their on-chain verifier enforces the correct execution of ISA instructions rather than the Ethereum specification.

4/ An additional on-chain commitment (Merkle root) to the compiled Geth binary is required to ensure it is verifying Geth, rather than an arbitrary program compiled to the custom ISA.

5/ This leads to a large trusted computing base (TCB), a lack of support for L2 client diversity, poor upgrade transparency and frequent upgrades. An EVM-native design elegantly solves these issues.

6/ The TCB of an ORU fraud proof design is the security-critical codebase that is compliant with the Ethereum specification.

7/ For an EVM-equivalent ORU, the TCB includes the on-chain verifier, off-chain client, and entire compilation toolchain.

8/ EVM-equivalent ORUs impose a heavier burden on auditors as more components inside the TCB have to be inspected, vs. just the verifier in the EVM-native ORU, since the verifier is just enforcing the Ethereum spec and is not tied to any particular client implementation.

9/ EVM-equivalent ORUs allow only specific client(s)—currently only Geth—to participate in dispute resolution, since different types + versions compile to different binaries, and have different exec traces/fraud proofs. A client has to be explicitly *supported* to participate.

10/ In EVM-native ORUs, since all clients (regardless of type) implement the same state transitions (according to Ethereum spec), they are naturally generating the same fraud proofs. The verifier verifies nothing more than the spec and is agnostic to the client implementation.

11/ For the EVM-native ORU, any client that conforms to the Ethereum spec can participate in challenges with the on-chain verifier, including future new clients written in new languages.

12/ Wrt upgrades, EVM-equivalent ORUs require an update to the on-chain binary commitment in the verifier when *any* changes are introduced to the client or compile toolchain. The large TCB base may also require an extensive audit to ensure no new vulnerabilities are introduced.

13/ For EVM-native ORUs, upgrades are only needed when L2 Ethereum spec changes, and the nature of the upgrade is in the form of a smart contract, which allows for better transparency over a hash commitment.

14/ We would love to get you involved in building Specular! Check out specular.network and follow us at @SpecularL2 for more information.