{"id":25047718,"url":"https://github.com/distributed-lab/linea-dev-edition","last_synced_at":"2025-07-18T17:34:57.934Z","repository":{"id":274638634,"uuid":"923568039","full_name":"distributed-lab/linea-dev-edition","owner":"distributed-lab","description":"Here you can find the ready and easy for use Linea Rollup dev setup with full prover, all the configs and tips how to run that.","archived":false,"fork":false,"pushed_at":"2025-04-24T14:01:36.000Z","size":440,"stargazers_count":4,"open_issues_count":1,"forks_count":0,"subscribers_count":2,"default_branch":"main","last_synced_at":"2025-06-04T12:44:56.355Z","etag":null,"topics":["docker-compose","linea","zk-rollup"],"latest_commit_sha":null,"homepage":"","language":"Solidity","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/distributed-lab.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null}},"created_at":"2025-01-28T13:37:24.000Z","updated_at":"2025-03-27T15:51:41.000Z","dependencies_parsed_at":"2025-01-28T14:42:01.155Z","dependency_job_id":"ac5d0de0-6e08-4b58-915a-41c9c59efe58","html_url":"https://github.com/distributed-lab/linea-dev-edition","commit_stats":null,"previous_names":["distributed-lab/linea-dev-edition"],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/distributed-lab/linea-dev-edition","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/distributed-lab%2Flinea-dev-edition","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/distributed-lab%2Flinea-dev-edition/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/distributed-lab%2Flinea-dev-edition/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/distributed-lab%2Flinea-dev-edition/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/distributed-lab","download_url":"https://codeload.github.com/distributed-lab/linea-dev-edition/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/distributed-lab%2Flinea-dev-edition/sbom","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":265802016,"owners_count":23830506,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["docker-compose","linea","zk-rollup"],"created_at":"2025-02-06T07:18:08.707Z","updated_at":"2025-07-18T17:34:57.914Z","avatar_url":"https://github.com/distributed-lab.png","language":"Solidity","funding_links":[],"categories":[],"sub_categories":[],"readme":"# Linea Rollup Dev Edition\n\n\u003e [!CAUTION]\n\u003e This README outlines the steps to set up a development environment. For production use, configuration settings\n\u003e must be updated, private keys replaced, and other security considerations applied.\n\n- [Environment overview](#environment-overview)\n- [How to run](#how-to-run)\n    - [1. Clone the repository](#1-clone-the-repository)\n    - [2. Run the nodes](#2-run-the-nodes)\n    - [3. Deploy L1 and L2 contracts](#3-deploy-l1-l2-contracts)\n    - [4. Run the services](#4-run-the-services)\n    - [5. Obtain \"trusted\" setup files](#5-obtain-trusted-setup-files)\n        - [Option 1: Download setup files from S3](#a-if-you-have-access-download-the-setup-files-from-our-s3-bucket)\n        - [Option 2: Generate setup files from scratch](#b-generate-the-setup-files-from-scratch)\n    - [6. Run the prover](#6-run-the-prover)\n- [Proof types](#proof-types)\n  - [Execution](#execution)\n  - [Compression](#compression)\n  - [Aggregation](#aggregation)\n  - [Emulation](#emulation)\n- [L2 Stack Overview](#l2-stack-overview)\n  - [Sequencer](#sequencer)\n  - [Shomei](#shomei)\n  - [Tracer](#tracer)\n  - [Prover](#prover)\n  - [Coordinator](#coordinator)\n- [Trace limits](#trace-limits)\n- [The flow](#the-flow)\n- [References](#references)\n\n## Environment overview\n\nThe entry point is a `docker-compose.yaml` file that describes all the necessary services. It contains several profiles\nthat are useful at different steps:\n\n- `nodes` - run several L2 nodes. Three mandatory Besu nodes:\n    - `sequencer`,\n    - `traces-node`,\n    - `shomei-node`.\n\n  And an optional geth `l2-node`.\n- `services` - runs L2 services, such as:\n    - `shomei` - responsible for the zk-evm state management.\n    - `coordinator` - responsible for actions coordination between all the L2 services, and L1.\n- `full-prover` - runs the prover controller, which spawns provers as requests arrive from the coordinator service. It\n  is a heavy service that requires a lot of resources.\n\n## How to run\n\nTo run the dev edition, you should install `docker` and `docker-compose`.\n\n### 1. Clone the repository:\n\n```bash\ngit clone https://github.com/distributed-lab/linea-dev-edition\ncd linea-dev-edition\n```\n\n### 2. Run the nodes:\n\n```bash\ndocker compose --profile nodes up -d\n```\n\nNow, the L2 RPC (essentially default ETH RPC) should be available at `http://localhost:8845`, as well as `8545`,\n`8745`, and `8945`.\n\n### 3. Deploy L1, L2 contracts:\n\nThe mandatory L2 contract is the L2MessageService, and the LineaRollup contract for L1, that requires PlonkVerifier,\nwhich can be found at `./prover-assets/3.0.0/devnet/emulation/Verifier.sol`.\n\nYou can find the deployment scripts in the [linea-monorepo](https://github.com/Consensys/linea-monorepo) repo,\nthe `./contracts` directory with well-documented instructions. It is recommended to use the same version as the\nprover for compatibility.\n\n\u003e [!IMPORTANT]  \n\u003e If you don't want to re-generate a trusted setup in the future, set the next values for the L2MessageService\n\u003e deployment:\n\u003e\n\u003e ```env\n\u003e L2MSGSERVICE_SECURITY_COUNCIL=\"0x3E4837e19201A914738eB50131Dd8Cb5bDA400B3\" # sequencer address\n\u003e L2MSGSERVICE_L1L2_MESSAGE_SETTER=\"0x3E4837e19201A914738eB50131Dd8Cb5bDA400B3\" # sequencer address\n\u003e L2MSGSERVICE_RATE_LIMIT_PERIOD=\"86400\" # 24Hours in seconds\n\u003e L2MSGSERVICE_RATE_LIMIT_AMOUNT=\"1000000000000000000000\" # 1000ETH\n\u003e ```\n\u003e\n\u003e And use this private key for deployment: `c9e119d9e6bfa0291265191aea48b6e538ff74e2e41a2e735850b29eb5c0c422`. So,\n\u003e the deployed L2MessageService address should be `0x22A4913037A2079fada1b9BfBdc5C81c85781264`.\n\nAfter the contracts are deployed, you need to use a `setVerifierAddress (0xc2116974)` method of the LineaRollup\ncontract to set the address of the just deployed PlonkVerifier contract for a `_proofType` `0x1`.\n\n### 4. Run the services:\n\nFirst of all, one needs to fill missing values in config files, you can find them with \"\u003cYOUR_*\u003e\" placeholder in\nthis project. Currently, they are:\n\n- `./config/coordinator/coordinator-docker.config.toml`:\n    - l1.rpc-endpoint - your L1 RPC endpoint\n    - l1.zk-evm-contract-address - just deployed LineaRollup contract address\n    - l2.message-service-address - just deployed L2MessageService contract address\n- `./config/prover/v3/prover-config-full.toml`:\n    - layer2.message_service_contract - just deployed L2MessageService contract address\n\nThen, run the services:\n\n```bash\ndocker compose --profile services up -d\n```\n\nAfter some short period of time, you should find the zk-evm traces files at `./local.dev/data/traces/l2/conflated`\ndirectory, as well as proof generation requests at `./local.dev/data/prover`.\n\n### 5. Obtain trusted setup files:\n\nYou can find dummy example in the `./prover-assets` directory.\n\n\u003e [!WARNING]\n\u003e This trusted setup should be used only for development purposes.\n\nHere you have two options:\n\n#### a. If you have access, download the setup files from our S3 bucket:\n\n\u003e [!IMPORTANT]\n\u003e This will be suitable only if the trace limits weren't changed and the L2MessageService contract has an\n\u003e address `0x22A4913037A2079fada1b9BfBdc5C81c85781264`.\n\n```bash\naws s3 cp s3://linea-bucket/linea/dev-edition/prover-assets ./prover-assets --recursive\n```\n\n#### b. Generate the setup files from scratch:\n\n1. Generate KZG SRS using [gnark-crypto](https://github.com/Consensys/gnark-crypto) tools, that is required for\n   the next curves: bls12-377 (size 268435459), bn254 (size 67108864), bw6761 (size 16777216). The files should be\n   placed in the `./prover-assets/kzgsrs` directory, and named according to the example there.\n2. Generate the circuit-specific setup using `prover setup` command (see the\n   [prover](https://github.com/Consensys/linea-monorepo) for details) and config file from\n   `linea-dev-edition/config/prover/v3/prover-config-full.toml`.\n\n### 6. Run the prover:\n\nThis step isn't possible before the trusted setup files are generated.\n\n\u003e [!Warning]\n\u003e\n\u003e The prover is configured to use 1100 GB of RAM and 64 CPU. You can change the resources in the\n\u003e `docker-compose.yaml` in the `full-prover` service section.\n\n```bash\ndocker compose --profile full-prover up -d\n```\n\nThe prover should start processing the proof generation requests, one by one they will be renamed with \"inprogress\"\nstatuses. The proof generation process with default parameters takes about an hour, but it depends heavily on the \nused hardware.\n\n\u003e [!Tip]\n\u003e The prover uses caches generated once and stored in the `./tmp.dev/prover-artefacts` directory. The\n\u003e process of cache generation is time-consuming, but you can download them from the S3 bucket:\n\u003e\n\u003e ```bash\n\u003e aws s3 cp s3://linea-bucket/linea/dev-edition/prover-artefacts ./tmp.dev/prover-artefacts --recursive\n\u003e ```\n\n### Possible problems\n\nIf the proving failed with a similar log:\n\n```log\nprover  | 22:18:08 ERR error=\"constraint #21921531 is not satisfied: qL⋅xa + qR⋅xb + qO⋅xc + qM⋅(xaxb) + qC != 0 → 0 + -12345 + 0 + 0 + 0 != 0\" nbConstraints=36407863\n```\n\nSome of the constraints are not satisfied.\n\nMost likely something was changed in your configs and you need to either re-setup the environment with values provided\nin this repo or [re-generate trusted setup](#b-generate-the-setup-files-from-scratch). If this didn't help - good luck!\n\n## Proof types\n\n\u003cp align=\"center\"\u003e\n  \u003cimg src=\"./img/linea-arch.webp\" alt=\"drawing\" width=\"600\"/\u003e\n\u003c/p\u003e\n\nIf we discard the \"*-dummy*\" ones the Linea has 4 types of proofs that prover can generate:\n\n- *execution* (or with\n  bigger [trace limits](#trace-limits)\n  *execution-large*)\n- *compression*\n- *aggregation*\n- *emulation*\n\n### Execution\n\nThe execution proof validates the correct execution of the Ethereum Virtual Machine (EVM) transactions. The proof system\nfor the execution has a complex structure:\n\n\u003e Execution Trace → Arithmetization → Arcane + Vortex (*using the Wizard-IOP it creates the polynomial commitments and\nthe corresponding IOP based on lattice-based cryptography and error-correcting codes*) → PLONK\n\nThe final proof is a BLS12-377-based PLONK proof.\n\n### Compression\n\nLinea prover defines the data compression algorithm applied to the conflated trace. The resulting compressed value is\nthen submitted to the L1. The compression proof ensures that the compressed data submitted on Ethereum (\nas [EIP-](https://eips.ethereum.org/EIPS/eip-4844)[4844](https://www.eip4844.com/) blob) can be accurately decompressed,\nrevealing the necessary inputs for validation. The proof system used for generating the compression proof is PLONK and\nis based on the curve BLS12-377.\n\n### Aggregation\n\nServes as the cornerstone of Linea's proof system, recursively verifying proofs from N execution circuits and M\ncompression circuit instances.\n\nMore precisely, during the generation of this type of proofs, the prover verifies several smaller execution/compression\nproofs (done over the BLS12-377 curve) using the PLONK circuit over BW6-761.\n\n\u003e The aggregation proof system uses a combination of several PLONK circuits on BW6, BLS12-377 which tactically profits\n\u003e from the 2-chained curves BLS12-377 and BW6 to efficiently recurse the proofs.\n\n### Emulation\n\nThe final proof verifies an aggregation proof over the BW6-761 curve in a circuit over the BN254 curve, which can be\nefficiently verified on Ethereum thanks to the available precompiles.\n\n## L2 Stack Overview\n\nThe Linea stack can be divided into the following logical pieces:\n\n- Sequencer (and other plain nodes)\n- Shomei (the Shomei service itself and a Besu node with the corresponding plugin)\n- Tracer\n- Prover\n- Coordinator (coordinator service itself and web3signer)\n\n### Sequencer\n\n\u003e [!Tip]\n\u003e - Sequencer plugin: https://github.com/Consensys/linea-sequencer\n\u003e - Besu: https://github.com/Consensys/linea-besu\n\nThe sequencer is a Besu node launched in the miner (validator) mode. The Linea uses the CLique consensus mechanism, so\nthe miner (sequencer, validator) address must be specified in the genesis’ `extraData` field.\n\nSequencer node also requires sequencer plugin to be enabled and configured. In the following\ndocumentation https://github.com/Consensys/linea-sequencer/blob/main/docs/plugins.md#sequencer you can read about how to\nconfigure sequencer plugin.\n\n#### Configuring genesis\n\nThe following documentation can be used to configure the genesis\nfile: https://besu.hyperledger.org/private-networks/tutorials/clique\n\nThere are several important fields that should be mentioned:\n\n- `\"blockperiodseconds\"` determines how often blocks in the network will be generated. Decreasing of this value may\n  require increasing the number of provers or/and increasing the prover CPU because the L2 network will have to produce\n  proofs more frequently.\n- `\"createemptyblocks\"`  determines if the empty blocks (if no transactions have been submitted to the network) should\n  be produced. Setting to true may also cause additional load on the tracer and prover. The recommended value\n  is `false`.\n- `\"extraData\"` you can read about how to configure extra data in the following\n  documentation: https://besu.hyperledger.org/private-networks/how-to/configure/consensus/clique#extra-data. Basically,\n  extra data specifies the address of the initial validator in the network.\n- `\"alloc\"` determines the initial base token allocations and smart contracts deployed in the genesis block.\n- Other fields that specify gas parameters, chain ID, start block, etc. can be explored in the Besu documentation.\n\n### Shomei\n\n\u003e [!Tip]\n\u003e - Shomei: https://github.com/Consensys/shomei\n\u003e - Besu plugin: https://github.com/Consensys/besu-shomei-plugin\n\nEthereum uses a modified Patricia Merkle Trie for network state storage, but this structure isn't well-suited for\nproving systems in a ZK-Rollup context. Therefore, Shomei handles blockchain state collection in a \"ZK-friendly\" format.\n\nThe Besu plugin replicates the state into a Sparse Merkle tree (SMT), using MIMC as the hash function.\n\nThe shomei service (launched in two separate instances: shomei itself and API aka shomei-frontend) provides a simple\ninterface for state retrieval.\n\nAdditionally, Shomei plugin provides several RPC methods to request a Merkle Tree Proof of the inclusion of some data\ninto the state. This proof can be used to prove some statements about the state of L2 on L1.\n\n### Tracer\n\n\u003e [!Tip]\n\u003e - Tracer Besu plugin: https://github.com/Consensys/linea-tracer\n\nWhile Shomei manages the current state, the Tracer (*basically the Tracer is referred to the Besu node with the tracer\nplugin*) generates a record of the transactions' changes. This is a step-by-step proof of the state transitions from\npoint A to the point B.\n\nUnlike Shomei, this functionality is implemented entirely through the Tracer and is accessible via several RPC methods:\n\n- `linea_getConflatedTracesCountersV2`- returns the total count of elements in each column for trace blocks\n  from `startBlockNumber` to `endBlockNumber`.\n  \u003cdetails\u003e\n    \u003csummary\u003eResponse example\u003c/summary\u003e\n\n        {\n            \"jsonrpc\": \"2.0\",\n            \"id\": 1,\n            \"result\": {\n                \"tracesEngineVersion\": \"v0.8.0-rc6\",\n                \"from\": 253,\n                \"to\": 1422,\n                \"tracesCounters\": {\n                    \"ADD\": 9,\n                    \"BIN\": 15,\n                    \"BIN_REFERENCE_TABLE\": 196864,\n                    \"BLAKE_MODEXP_DATA\": 1,\n                    \"BLOCK_DATA\": 8196,\n                    \"BLOCK_HASH\": 1,\n                    \"BLOCK_KECCAK\": 7,\n                    \"BLOCK_L1_SIZE\": 400,\n                    \"BLOCK_L2_L1_LOGS\": 0,\n                    \"BLOCK_TRANSACTIONS\": 2325,\n                    \"EC_DATA\": 11,\n                    \"EUC\": 14,\n                    \"EXP\": 5,\n                    \"EXT\": 7,\n                    \"GAS\": 3499,\n                    \"HUB\": 143062,\n                    \"INSTRUCTION_DECODER\": 256,\n                    \"LOG_DATA\": 1,\n                    \"LOG_INFO\": 2330,\n                    \"MMIO\": 57374,\n                    \"MMU\": 32660,\n                    \"MOD\": 7,\n                    \"MUL\": 9,\n                    \"MXP\": 4667,\n                    \"OOB\": 20761,\n                    \"PRECOMPILE_BLAKE_EFFECTIVE_CALLS\": 0,\n                    \"PRECOMPILE_BLAKE_ROUNDS\": 0,\n                    \"PRECOMPILE_ECADD_EFFECTIVE_CALLS\": 0,\n                    \"PRECOMPILE_ECMUL_EFFECTIVE_CALLS\": 0,\n                    \"PRECOMPILE_ECPAIRING_FINAL_EXPONENTIATIONS\": 0,\n                    \"PRECOMPILE_ECPAIRING_G2_MEMBERSHIP_CALLS\": 0,\n                    \"PRECOMPILE_ECPAIRING_MILLER_LOOPS\": 0,\n                    \"PRECOMPILE_ECRECOVER_EFFECTIVE_CALLS\": 0,\n                    \"PRECOMPILE_MODEXP_EFFECTIVE_CALLS\": 0,\n                    \"PRECOMPILE_RIPEMD_BLOCKS\": 0,\n                    \"PRECOMPILE_SHA2_BLOCKS\": 0,\n                    \"RLP_ADDR\": 7,\n                    \"RLP_TXN\": 347313,\n                    \"RLP_TXN_RCPT\": 195307,\n                    \"ROM\": 513,\n                    \"ROM_LEX\": 3,\n                    \"SHAKIRA_DATA\": 2,\n                    \"SHF\": 47,\n                    \"SHF_REFERENCE_TABLE\": 2304,\n                    \"STP\": 4,\n                    \"TRM\": 18615,\n                    \"TXN_DATA\": 19778,\n                    \"WCP\": 42079\n                }\n            }\n        }\n\n      \u003c/details\u003e\n\n- `linea_generateConflatedTracesToFileV2` - generates conflated traces to the directory defined in the config and\n  filename in the next format: `\u003cstartBlock\u003e-\u003cendBlock\u003e.conflated.\u003ctracseEngineVersion\u003e.lt`\n  e.g. `1-83.conflated.v0.8.0-rc6.lt`.\n\n\u003e The “**conflated**” refers to the blocks that are grouped together into batches; basically, the conflated file\n\u003e represents the traces for the batches of blocks.\n\u003e\n\u003e More precisely, the conflated file specifies the columns with names, length and other parameters that represents the\n\u003e trace. You can read about how the trace is generated and its constraints in the following\n\u003e doc: https://cdn.consensys.io/uploads/2022/10/07104712/a_specification_for_a_zk_evm.pdf\n\n### Prover\n\n\u003e [!Tip]\n\u003e - Prover: https://github.com/Consensys/linea-monorepo\n\nThe prover takes conflated traces (witness) and generates a proof of the state transition that can be efficiently\nverified (e.g. on-chain).\n\nThis is the most computationally intensive and resource-demanding service within the entire system architecture. Due to\nthe complex mathematical operations and cryptographic calculations involved in the proof generation process, Linea has\nspecific hardware requirements for optimal performance.\n\n\u003e The recommended system specification is 1 TB of memory and 32+ CPUs. The actual proof generation time heavily depends\n\u003e on the trace limits used. For example: with default trace limits, which you can find in\n\u003e the [Traces Limits](#trace-limits) section, and 64\n\u003e CPU cores, you can expect execution proof generation to take approximately 1750 seconds.\n\n#### Controller\n\nThe Prover repository also includes a Controller service that handles filesystem polling automatically. So, when a new\nproving request appears, the Controller starts the prover without requiring manual interaction.\n\n### Coordinator\n\nFrom the name, it is obvious that it’s responsible for the coordination of the work of all the components. The\ncoordinator starts by listening to new blocks in the network. When a new block appears it checks whether it can be added\nto the current conflation. After some trigger, coordinator requests the new conflation. There are several triggers for\nconflated trace generation:\n\n1. [**Trace limits**](#trace-limits)\n   If adding the new block to the current conflation would cause the number of elements in any column to exceed the\n   specified [trace limits](#trace-limits).\n\n  \u003e [!Warning]\n  \u003e Although all services use the same trace limits, the coordinator requires several values to be adjusted in its\n  \u003e version:\n  \u003e\n  \u003e ```toml\n  \u003e  BIN_REFERENCE_TABLE = 2147483648 \n  \u003e  SHF_REFERENCE_TABLE = 2147483648\n  \u003e  INSTRUCTION_DECODER = 2147483648\n  \u003e  BLOCK_HASH = 2147483648\n  \u003e  ```\n  \u003e These columns have fixed sizes, but due to some peculiarities of the coordinator's calculations, they are set to the\n  \u003e maximum possible value to prevent overflow.\n\n2. **Target block**\n\n  The target blocks in which traces will be generated can be specified in the configuration file.\n\n  ```toml\n  [proof-aggregation]\n  target-end-blocks=[1024, 2048, 4096]\n  ```\n\n3. **Data limit**\n\n  The final proof is submitted on-chain in a couple with the [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844) blob(s).\n  Since the blob has a size limit of 128 kB and contains compressed RLP-encoded blocks, it can only contain a finite\n  number of blocks.\n\n  \u003e [!NOTE]\n  \u003e When conflated traces are generated by another trigger but the data limit hasn't been reached, the data size continues\n  \u003e to accumulate conflations for the compression proof. This allows the blob to contain multiple conflations, preventing\n  \u003e unnecessary compression proof generation.\n\n\n4. **Blocks limit (optional)**\n\n  Using config you can set the maximum number of blocks in conflated traces.\n  \n  ```toml\n  [conflation]\n  blocks-limit=512\n  ```\n\n5. **Time limit**\n\n  You can configure the system to generate conflated traces after a specified time has elapsed since the last\n  generation.\n  \n  ```toml\n  [conflation]\n  conflation-deadline=\"PT6H\"\n  conflation-deadline-check-interval=\"PT10S\"\n  ```\n\nWhen the trigger is reached the coordinator executes the `generateConflatedTracesToFileV2` request on the Tracer,\nwhich generates the conflated trace into a shared folder, and an actual ZK-state from the Shomei service to generate \na request(s) for proof generation. An execution proof request is generated for any trigger, while a compression proof \nrequest is only generated when the data limit is reached.\n\n#### Aggregation request trigger\nIt is also important to mention the triggers for aggregation proof request generation:\n\n1. **Number of proofs** — if the number of proofs to be aggregated exceeds a given threshold.\n2. **Deadline** — if no new blocks have appeared for longer than a specified deadline. This deadline is defined in the`[conflation]`config section\n  ```toml\n  [conflation]\n  conflation-deadline-last-block-confirmation-delay=\"PT20M\"\n  ```\n\n3. **Target block**\n  \u003e [!NOTE]\n  \u003e The same parameter is used as a trigger for the conflation trace generation.\n  \n  The target blocks in which aggregation will be generated can be specified in the configuration file.\n  \n  ```toml\n  [proof-aggregation]\n  target-end-blocks=[1024, 2048, 4096]\n  ```\n\n## Trace limits\n\nThe *traces-limits-v2.toml* example. You can notice the *_large* one, where some of the values are increased, for the\nexecution-large proof type.\n\n\u003cdetails\u003e\n  \u003csummary\u003eExpand\u003c/summary\u003e\n\n    [traces_limits]\n    ADD = 524288\n    BIN = 262144\n    BLAKE_MODEXP_DATA = 16384\n    BLOCK_DATA = 1024\n    BLOCK_HASH = 512\n    EC_DATA = 262144\n    EUC = 65536\n    EXP = 8192\n    EXT = 1048576\n    GAS = 65536\n    HUB = 2097152\n    LOG_DATA = 65536\n    LOG_INFO = 4096\n    MMIO = 4194304\n    MMU = 4194304\n    MOD = 131072\n    MUL = 65536\n    MXP = 524288\n    OOB = 262144\n    RLP_ADDR = 4096\n    RLP_TXN = 131072\n    RLP_TXN_RCPT = 65536\n    ROM = 4194304\n    ROM_LEX = 1024\n    SHAKIRA_DATA = 32768\n    SHF = 65536\n    STP = 16384\n    TRM = 32768\n    TXN_DATA = 8192\n    WCP = 262144\n    PRECOMPILE_ECRECOVER_EFFECTIVE_CALLS = 128\n    PRECOMPILE_SHA2_BLOCKS = 671\n    PRECOMPILE_RIPEMD_BLOCKS = 671\n    PRECOMPILE_MODEXP_EFFECTIVE_CALLS = 4\n    PRECOMPILE_ECADD_EFFECTIVE_CALLS = 16384\n    PRECOMPILE_ECMUL_EFFECTIVE_CALLS = 32\n    PRECOMPILE_ECPAIRING_FINAL_EXPONENTIATIONS = 16\n    PRECOMPILE_ECPAIRING_MILLER_LOOPS = 64\n    PRECOMPILE_ECPAIRING_G2_MEMBERSHIP_CALLS = 64\n    PRECOMPILE_BLAKE_EFFECTIVE_CALLS = 600\n    PRECOMPILE_BLAKE_ROUNDS = 600\n    BLOCK_KECCAK = 8192\n    BLOCK_L1_SIZE = 1000000\n    BLOCK_L2_L1_LOGS = 16\n    BLOCK_TRANSACTIONS = 200\n    BIN_REFERENCE_TABLE = 262144\n    SHF_REFERENCE_TABLE = 4096\n    INSTRUCTION_DECODER = 512\n    \n    [traces_limits_large]\n    ADD = 1048576\n    BIN = 524288\n    BLAKE_MODEXP_DATA = 32768\n    BLOCK_DATA = 2048\n    BLOCK_HASH = 1024\n    EC_DATA = 524288\n    EUC = 131072\n    EXP = 16384\n    EXT = 2097152\n    GAS = 131072\n    HUB = 4194304\n    LOG_DATA = 131072\n    LOG_INFO = 8192\n    MMIO = 8388608\n    MMU = 8388608\n    MOD = 262144\n    MUL = 131072\n    MXP = 1048576\n    OOB = 524288\n    RLP_ADDR = 8192\n    RLP_TXN = 262144\n    RLP_TXN_RCPT = 131072\n    ROM = 8388608\n    ROM_LEX = 2048\n    SHAKIRA_DATA = 65536\n    SHF = 131072\n    STP = 32768\n    TRM = 65536\n    TXN_DATA = 16384\n    WCP = 524288\n    PRECOMPILE_ECRECOVER_EFFECTIVE_CALLS = 256\n    PRECOMPILE_SHA2_BLOCKS = 671\n    PRECOMPILE_RIPEMD_BLOCKS = 671\n    PRECOMPILE_MODEXP_EFFECTIVE_CALLS = 8\n    PRECOMPILE_ECADD_EFFECTIVE_CALLS = 32768\n    PRECOMPILE_ECMUL_EFFECTIVE_CALLS = 64\n    PRECOMPILE_ECPAIRING_FINAL_EXPONENTIATIONS = 32\n    PRECOMPILE_ECPAIRING_MILLER_LOOPS = 128\n    PRECOMPILE_ECPAIRING_G2_MEMBERSHIP_CALLS = 128\n    PRECOMPILE_BLAKE_EFFECTIVE_CALLS = 600\n    PRECOMPILE_BLAKE_ROUNDS = 600\n    BLOCK_KECCAK = 8192\n    BLOCK_L1_SIZE = 1000000\n    BLOCK_L2_L1_LOGS = 16\n    BLOCK_TRANSACTIONS = 200\n    BIN_REFERENCE_TABLE = 262144\n    SHF_REFERENCE_TABLE = 4096\n    INSTRUCTION_DECODER = 512\n\n\u003c/details\u003e\n\nSome columns have a constant size that should not be changed, such as  `BIN_REFERENCE_TABLE`, `SHF_REFERENCE_TABLE`, and `INSTRUCTION_DECODER`.\n\n```toml\nBIN_REFERENCE_TABLE = 196864\nSHF_REFERENCE_TABLE = 2304\nINSTRUCTION_DECODER = 256\n```\n\nNote, that in the trace-limits file, corresponding limits has to be equal to the closest next power of two.\n\nAlso, as were mentioned before, in the coordinator trace-limits, the limit for these columns equals to the maximum possible value.\n\n```toml\nBIN_REFERENCE_TABLE = 2147483648\nSHF_REFERENCE_TABLE = 2147483648\nINSTRUCTION_DECODER = 2147483648\n```\n\n## The flow\n\n\u003cp align=\"center\"\u003e\n  \u003cimg src=\"./img/Linea_architecture_mobile.svg\" alt=\"drawing\" width=\"600\"/\u003e\n\u003c/p\u003e\n\n1. The user sends a transaction to the Layer 2 nodes. Since these nodes are interconnected, the transaction is broadcast across the network until it reaches the sequencer node. The sequencer then includes this transaction in the new block and broadcasts it to the other nodes.\n\n   At this point, the first step is complete — the transaction is included in a block within the L2 sequencer.\n\n2. Meanwhile, the Coordinator polls the network for new blocks. When the block arrives, the service adds it to the conflation and checks for triggers. When one of [the triggers](#aggregation-request-trigger) is reached, the Coordinator requests the Tracer to generate conflated traces and the Shomei for the corresponding blockchain state.\n\n   The block and user's transaction are saved to the conflated traces file in a folder shared with the prover, along with requests to generate execution and compression proofs.\n\n3. The Prover calculates execution and compression proofs. \n   a. When the coordinator accumulates the target number of compression proofs (ready blobs), it can publish a submit blob transaction without waiting for the next step. The default target is 6 blobs—the maximum number of blobs allowed per block as defined in [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844#throughput) (Throughput section).\n\n4. The Coordinator waits for [the aggregation trigger](#aggregation-request-trigger) and places a request for the proof generation.\n\n5. Once the emulation proof is ready, the coordinator submits all pending blobs up to the latest block in the aggregated proofs and then the emulation proof to L1 — finalizing all the previous blob submissions.\n\n## References\n\n[1] [Linea monorepo](https://github.com/consensys/linea-monorepo)\n\n[2] [Linea Prover Documentation](https://eprint.iacr.org/2022/1633.pdf)\n\n[3] [Linea documentation](https://docs.linea.build/)\n\n[4] [EIP-4844 documentation](https://eips.ethereum.org/EIPS/eip-4844)","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fdistributed-lab%2Flinea-dev-edition","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fdistributed-lab%2Flinea-dev-edition","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fdistributed-lab%2Flinea-dev-edition/lists"}