**Linea - research notes for the EPF** * Website: https://linea.build * Docs: https://docs.linea.build Linea **Mainnet Alpha** is live. **Decentralization roadmap:** Source: https://docs.linea.build/decentralization-roadmap ![](https://hackmd.io/_uploads/r1qc7Go03.png) **Technical summary:** Source: https://eprint.iacr.org/2022/1633.pdf Looking to build a **Type-2 zkEVM**: EVM-equivalent * **Proof system**: SNARK – relying on the Ring Short Integer Solution problem (Ring-SIS) which makes it **quantum-resistant**. * **Commitment scheme**: Vortex, a lattice-based Batchable Linear Commitment (BLC) * Vortex uses a hash function based on Ring-SIS * **Compiler framework**: Arcane * Self-recursion and Random Oracle is used to make the proof non-interactive **Protocol data** (The below data reflects the status on 4 Sept 2023.) Dashboards: https://linea.l2scan.co/charts Network status: https://linea.statuspage.io * Avg block time: 12 sec * Txs total on 4 Sept: 141K * Txs – all time: 5.19M * Blocks – all time: ~351K * Batches – all time: ~63K * Avg txs per block: ~20 * Unique addresses – daily: 12.6K * Unique addresses – all time: 719K * Total unique sequencers: 1 * Total unique provers: * Avg block size: 11.1K bytes * Avg gas price: 1.29 Gwei * Gas limit: 61M * Total daily gas used: 18.720M * Total daily block reward: 20.59 ETH * Avg tx fee: ~0.000145 ETH * Network utilization (avg gas used/gas limit): 4.45% **Blocks** include an average of 15-20 txs **Batches** include 3-4-5 blocks on average **Architecture:** Source: https://docs.linea.build/architecture Main components: * Sequencer * Prover * Bridge Relayer **Linea’s goal:** building a fully decentralized, permissionless network. **Current state** of the alpha mainnet: * Centralized sequencer & prover (they are ~ rolled into one) * Bridge Relayer **Summary of action flow** (Ethereum => Linea => Ethereum) Ethereum bridge contract -> Linea bridge contract -> Coordinator -> Sequencer (Block building -> Execution > Trace data generation) -> Coordinator -> Trace Conflation -> EVM State Manager -> Trace Expansion and Proving (Corset > gnark) -> Coordinator -> zk-proof and updated Merkle tree -> Linea bridge contract -> Ethereum bridge contract -> Ethereum blockchain **Linea Canonical Message Service** It is a combination of smart contracts and other protocols to pass user-specified data (messages) between Linea and other networks. * General purpose, public infra, with broader use-case than a normal bridge * A system through which data and assets can be permissionlessly and reliably transferred from one blockchain to another. * It transmits rollup-data; transfers information about the current state of the Ethereum network, from Ethereum to Linea, and also the updated Merkle tree and a zk-proof from Linea to Ethereum. * Three components: two smart contracts (one on Linea and one on Ethereum), and the Postbots service in between. * Postbots service to be decentralized on mainnet: anyone can become a Postbot **Coordinator** Coordination module through which information on the state passes from Ethereum to Linea and vice versa. * moves information * internally: between different parts of Linea’s execution client * externally: with other blockchains, Linea’s data availability stack, and the nodes syncing its own network state * It is **Linea’s Consensus client**. **Sequencer** It is the heart of Linea’s execution client, responsible for **ordering, building, and executing blocks**. Linea’s execution client is **zkGeth** but the protocol is building **zkBesu**. It helps the Linea stack with compatibility, reliability, ease of maintenance. * The sequencer determines the order of txs * Builds blocks * Executes those blocks * Prepares certain data relating to the traces of that execution for the zero-knowledge prover. The sequencer also has *two submodules*: *Traces Generator:* * responsible for generating the data used by the prover to create ZK proofs and making them as compact as possible * executes blocks that have been built by the sequencer, and preserves data relating to the traces of each transaction. * These traces specify the state of the network, and the state of the accounts involved in the transaction; this is also called the Infinite Improbability Drive *Conflator:* By conflating multiple blocks into one, Linea's proving system becomes much more efficient. Conflation is the process of taking two or more blocks’ worth of transactions and combining them into one data set, which can then be used to produce a ‘before and after’ map of the network state (a Merkle tree, in technical terms) as well as a zero-knowledge proof, which is published to Ethereum. * Ethereum: transaction data must be published in discrete blocks, one by one in order, before the next block can be published * In a zkEVM environment, the ‘source of truth’ from Ethereum’s perspective is the data submitted to it: * the ZK proof, * the list of transactions proved by it, * and the Merkle tree Conflation occurs within the execution client, but through a process of communication with the Coordinator: * The conflator waits for a traces file to appear * Marks that blocks' worth of traces as "merged" * Waits a certain amount of time in case more block data comes in * If it does, it checks to see if the number of lines in the block and the length of the data would exceed the limit * If it's within the limit, the conflator marks it as merged as well The conflator continues this cycle, until the time limit is reached, at which point it passes the conflated trace data back to the Coordinator, for subsequent Merkle tree and proof generation. **EVM State Manager:** It is part of the execution client and is responsible for updating the state of the network, and the state of every account. It does this by hashes (respresenting the state of each account) and Merkle tree. 1. Receives executed blocks, and uses the trace data to update the state of the network. 2. Then passes this updated network state information to the prover, for subsequent submission to Ethereum zkBesu uses *Sparse Merkle Tree* for optimized data storage * it uses default values for certain levels of branching in the tree * no change to the default value means no state change for that => no need to store data The state manager in zkBesu has two function: 1. updating the state of the network, and 2. proof generation Sequencer executes a block -> sends it to the trace generator and also the state manager -> the state manager updates the state in the Merkle tree for every account that was affected -> new hash values represent the new state -> sent to the prover to generate the proof for submission to Ethereum. **Prover** Main tasks: Trace Expansion and Proving It receives sets of information from the Coordinator and zkBesu, and produces a zk-SNARK. Two modules: 1. **Corset**: takes in conflated trace data from the Coordinator, and prepares it for Gnark. 2. **Gnark**: takes in that expanded trace data, and uses it to produce a proof that can be submitted to Ethereum. *Corset* – circuit building: * Corset (written in Rust) uses a DSL written in Lisp to create a constraint system (circuits) designed for Linea’s zkEVM which is then compiled into Go. This constraint system is the input for Gnark which converts it into a constraint system needed to generate a zk-SNARK. * Corset also processes trace data generated with every block, and (with the help of Lisp) uses “trace expansion” to derive sets of data to be processed by Gnark. *Gnark* – circuit execution and runtime * it prepares a set of “circuits” (constraint system) that will crete a zkSNARK and * actually prepares the proof Has two separate APIs: * frontend API translates Corset’s precompiled Go constraint system into a final set of circuits or constraints * backend API consumes data from the frontend API and produces a proof. Finally the Prover send the proof back to the Coordinator. **The Prover in more details** Sources: * https://linea.mirror.xyz/B3b1lUK8--UKZ_Qehk7SfOyvdcGbcuoyvNsSukHgOY8 * https://eprint.iacr.org/2022/1633.pdf **Proof system:** SNARK relying on the Ring Short Integer Solution problem (**Ring-SIS**) which makes it quantum-resistant. Commitment scheme: Vortex, a lattice-based Batchable Linear Commitment (BLC) * Lattice hashing is optimized for recursion and efficient for hardware acceleration and parallel processing * Vortex uses a hash function based on Ring-SIS * the linear structure of this hash function allows crafting an efficient self-recursion technique that recursively shrinks the size of the proof to the square root at each step. Thereafter, the obtained SNARK can optionally be compressed further to O(1) using existing proof systems such as Groth16[36] or Plonk[5] whose concrete proof size and verification time are tiny. The advantage of combining self-recursion together with simple recursion is that it greatly reduces the prover time compared to going for a simple recursion with Groth16 or Plonk. * Random Oracle is used to make the proof non-interactive * **Compiler** framework: **Arcane** ![](https://hackmd.io/_uploads/S10BbmsRh.png) Prover flow: 1. **Arithmetization**, a process by which a transaction is turned into traces and a set of constraints that must be satisfied to prove that the computation is correct. 2. The **inner-proof system** recursively shrinks down the proof 3. we go through a final compression step in an **outer-proof system** using **PlonK** 4. The proof, state commitment, and calldata are sent to the **verifier** contract.