Prover

The prover is a LinethLineth (Formerly the Linea Stack) The open-source ZK-rollup stack, codebase, and technical protocol that's the foundation of Linea Mainnet. Operators can deploy this stack to launch their own Ethereum-compatible L2 or L3 networks. module that turns execution traces into

zk-SNARKszk-SNARK (Zero-Knowledge Succinct Non-interactive Argument of Knowledge) A type of ZK proof where the prover and verifier don't have to interact. With zk-SNARKs, you can verify 1 transaction or 1 billion transactions in the same amount of time.. These zk-SNARKs enable the finalization layerFinalization layer The blockchain where a Lineth deployment submits proofs and state commitments for verification and hard finality. If the finalization layer is Ethereum (an L1), the deployment is an L2. If the finalization layer is Linea (an L2), the deployment is an L3. to accept a Lineth state transition without re-executing any transactions.

Proof generation is computationally intensive, so deployments run the prover as one or more dedicated instances rather than inside the execution client.

Evolving toward RISC-V

Lineth is evolving toward a RISC-V proving architecture, in which guest programs define the computation to prove. It is in development and is not yet part of any Lineth deployment.

How it works

The coordinatorCoordinator Lineth's coordination module for batching, proof generation, and finality submission. The coordinator monitors block production, manages conflation deadlines, batches blocks, combines batches into blobs, orchestrates execution, compression, and aggregation proofs, and submits proofs and data to the finalization layer. drives the prover. It writes each proof request, along with the conflatedConflation The process of combining two or more blocks' worth of transactions into one data set before proof generation. Conflation lets Lineth produce one Merkle tree update and one zero-knowledge proof per batch instead of per block, which makes the proving system more efficient. The coordinator decides where batch boundaries fall, using trace counts from the tracer, and the trace data itself is generated inside the execution client. traces produced by the

tracerTracer The Linea Besu plugin, part of the sequencer, that generates the execution traces the prover needs to create zero-knowledge proofs. The tracer provides trace counts for batch-size calculations and produces conflated trace files as prover input., to the directories the prover watches, and collects the finished proof from the same place. Those traces stay within the module limits that keep a batch provable.

The prover produces three kinds of proofs:

• Execution proofs show that the transactions in a batch executed correctly.
• Compression proofs show that a blob's compressed data expands to the batches it stands for.
• Aggregation proofs combine the proofs for several blobs into the single proof submitted at finalization.

Each proof is built in two stages:

1. Corset expands the trace data into the full constraint system, the arithmetization the prover proves against.
2. The proving system reduces that expanded data to an inner proof, then wraps it with the gnark library into an outer proof: the zk-SNARK that a verifier contract on the finalization layer can check cheaply.

Because the proof accompanies the data it proves, anyone can confirm that a state transition is correct by checking the proof onchain, instead of trusting the operator or re-executing the transactions themselves.

info

The proving system uses reference strings from the trusted setup.

See also

• Configure prover behavior using the Prover options.
• See the prover source code in the lineth-monorepo.