LineaConsensys

Description

Linea prover implements a zkEVM by creating a custom arithmetizationA part of zk proving system, a process that transforms the computation to be proven into a set of polynomials with particular properties. of EVM state transition (including precompiles) and proving it in a series of recursive SNARKs (i.e. without implementing a zkVMA special type of zk proving system that proves the correctness of state transitions of a virtual machine. Computation is represented by a program in a specific instruction language, it can have private and public inputs and public outputs. Most of zkVMs are STARKs.). The proof is wrapped into a PlonkA zk-SNARK proving system introduced by Gabizon, Williamson and Ciobotaru in 2019 that allows proving custom circuits. Plonk is based on KZG polynomial commitments and thus requires a universal trusted setup. with KZGA polynomial commitment scheme that allows a prover to compute a commitment to a polynomial, with the properties that this commitment can later be opened at any position: the prover shows that the value of the polynomial at a certain position is equal to a claimed value. KZG is widely used as it’s applicable both for univariate and k-variate polynomials, is efficient for batch proofs, and is able to generate many proofs at once relatively fast. It is also proof generation time efficient: the time for prover to commit to a polynomial is linear on the degree of the polynomial. for efficient onchain verification. Linea proverAn entity that generates the cryptographic proof to convince the verifier that the statement is true. In a ZK-Rollup, the prover generates the ZK (validity) proof to submit to the verifier contract. targets 128 bits of security.

Proof systemThe infrastructure that allows projects to verify their state transitions. It is composed by onchain verifiers and offchain provers. The main two flavors are optimistic and ZK proof systems, but they can be combined in a hybrid model. In general though, if a system is able to accept state roots optimistically, even if it has a ZK component, it is considered an optimistic proof system.

Linea prover includes Wizard-IOP framework for extending polynomial IOPs with more powerful queries, Arcane compiler of Wizard-IOP into polynomial IOP and Vortex list polynomial commitmentA commitment scheme that commits to a polynomial and allows generating the proof of opening the polynomial at a given point against the commitment. (LPC) scheme.

Wizard-IOP represents an extension of polynomial IOP with a wider range of queries, including inclusion check, permutation check, range check etc. Vortex LPC is a batchable polynomial commitment that is based on Ligero with lattice-based hashA fixed-length fingerprint of variable-size input, produced by a hash function. functions. To achieve succinct proof size, Linea prover performs multiple rounds of self-recursion by arithmetizing the Vortex verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. in the Wizard-IOP framework.

Since April 2026, the zkEVM arithmetization is done over KoalaBear 31-bit field for performance reasons, utilizing its degree 4 extension for commitment openings. During the recursive rounds Plonk+KZG schemes over curves BW6, BLS12-377, and BN254 are used, creating a dependency on 3 trusted setups, see below for more details.

Linea prover also introduces limitless mode, which segments the proving process into parallelizable jobs.

EVM circuits

This level of Linea prover produces execution proof and data availabilityThe property of a rollup's data being reachable by any node retrieving the data that were rolled up and executed to reach the proposed state. Data availability (DA), specifically decoupling it from the rollup nodes themselves, is one of the preeminent factors which allows a rollup to scale securely. A rollup is faced with a decision of what to use as a DA layer to guarantee that any node can retrieve this data--permissionlessly under any circumstance. For this reason, using Ethereum for DA currently provides the strongest security guarantees. If data is stored somewhere other than a permissionless L1, then the project is not a rollup, but rather a validium or an optimium. proof after several rounds of self-recursive compression. Both of these are Plonk based proofs over KoalaBear field and BLS12-377 curve.

Execution proof validates the correct execution of transactions within the EVM, including knowledge of correct EVM traces, correctness of precompiles and consistency of public inputs.

Data availability proof links compressed blobThe data that a rollup publishes to its L1/data availability (DA) layer. They consist of the L2 transactions that are rolled up, along with some metadata. Blobs are introduced as a new transaction type within Ethereum with EIP-4844, and has rollup scaling specifically in mind. Blobs persist on Ethereum’s Beacon Chain ephemerally. data, decompressed payloads, and execution-data commitments for EVM execution circuits.

Aggregation circuits

At this stage several proofs generated by execution and compression circuits are recursively verified within the aggregation circuitA program written for the purpose of being proven within a proving system. A circuit is a mathematical representation of the computation to be executed, arithmetic circuits and zkVM execution trace are examples of circuits. Circuits can be written in different languages, ranging from low-level to high-level., which also checks the “connection” of all public inputs across all circuits. It leverages a composite proof system that combines several Plonk circuits on the BW6 and BLS12-377 curves with a goal of performant recursion.

Final wrap

In the end the Linea proof is wrapped in a gnark implementation of Plonk over BN254 curve for even more efficiency onchain. For Plonk, Aztec Ignition trusted setupGeneration of a piece of data that must then be used for some cryptographic protocol to run. Generating this data requires some secret information. The "trust" comes from the fact the secret must be destroyed after the ceremony, otherwise cryptographic properties of the protocol could be broken. Once the data is generated, and the secrets are forgotten, no further participation from the creators of the ceremony is required. There are two types of trusted setups for SNARKs: (i) trusted setup per circuit where it is generated from scratch for each circuit, (ii) trusted universal setup per proving system where it can be used for several circuits. ceremony is used, see below for more details.