Conflation

Conflation is the process of combining two or more blocks' worth of transactions into one data set, which 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. proves as a single batch. Each batch produces one "before and after" map of the network state (a Merkle tree) and one ZK proofZero-knowledge proof A cryptographic method that allows an individual to prove that a statement is true without conveying any additional information. This is useful for scaling blockchain networks through rollups, because it reduces the amount of information you have to provide to lower layers., published to 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..

Ethereum publishes transaction data in discrete blocks, one at a time and in order. In a zkEVMzkEVM A virtual machine that executes smart contracts and proves the correctness of execution using zero-knowledge proofs. zkEVMs recreate aspects of Ethereum's design, which provides an "Ethereum-like" experience for developers and users. environment, the source of truth from Ethereum's perspective is the data submitted to it: the ZK proof, the transactions it proves, and the Merkle tree. The constraint is therefore not how many transactions fit in a block, but how many fit in a proof. Conflating blocks into batches lets Lineth generate one Merkle tree update and one proof for many blocks, which makes the proving system more efficient.

How it works

Conflation is driven by the coordinator, using trace data from the tracer:

1. As the sequencer produces each block, the coordinator requests that block's trace counts from the tracer.
2. The coordinator adds the block to the batch it's assembling, and keeps adding blocks while the batch stays within the proving limits.
3. The coordinator closes the batch when the next block would breach a limit, or when another boundary condition applies. Batches close on trace line limits, compressed data size limits, block count limits, a time deadline, or a required boundary such as a hard fork or a forced transaction.
4. The coordinator requests the conflated traces for the closed block range. The tracer re-executes those blocks and writes a single trace file, which the coordinator passes on for Merkle tree and proof generation.

Generating trace data requires an execution client, so it runs inside Linea Besu, but deciding where batch boundaries fall is a coordinator responsibility.

See also

• See the coordinator for how conflated batches become proofs and reach the finalization layer.
• See module limits for the trace line limits that constrain how many blocks fit in a batch.
• See the coordinator source code in the lineth-monorepo.