docs(l2): update L2 docs #5358
Merged
docs(l2): update L2 docs #5358
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Updated validation steps to clarify state trie root comparison and merkle proof verification.
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Contributor
There was a problem hiding this comment.
Pull Request Overview
This PR restructures and updates the ethrex L2 documentation, focusing on deployment guides and prover setup. The changes include reorganizing existing content, adding comprehensive guides for running different types of provers (SP1, RISC0, TDX), and providing detailed documentation on core prover concepts like stateless execution, execution witnesses, and data availability.
Key Changes
- Reorganized deployment documentation into a structured hierarchy with guides for vanilla, validium, and based (TBD) L2 configurations
- Added comprehensive prover documentation including setup guides for SP1, RISC0, and TDX proving backends
- Enhanced technical documentation with new sections on execution witnesses, data availability, and guest program details
Reviewed Changes
Copilot reviewed 20 out of 21 changed files in this pull request and generated 12 comments.
Show a summary per file
| File | Description |
|---|---|
| docs/prover/prover.md | New comprehensive prover documentation explaining stateless execution and ZK proof generation |
| docs/prover/guest_program.md | Detailed documentation of the zkVM guest program execution flow and validation steps |
| docs/l2/fundamentals/execution_witness.md | Technical explanation of execution witnesses and state reconstruction |
| docs/l2/fundamentals/data_availability.md | Documentation on rollup data availability using state diffs and blobs |
| docs/l2/deployment/vanilla.md | Step-by-step guide for deploying a vanilla ethrex L2 |
| docs/l2/deployment/validium.md | Step-by-step guide for deploying a validium ethrex L2 |
| docs/l2/deployment/based.md | Placeholder for based deployment guide (TBD) |
| docs/l2/deployment/overview.md | Overview of L2 deployment options and build instructions |
| docs/l2/deployment/README.md | Index for deployment guides with incorrect relative links |
| docs/l2/deployment/prover/*.md | Comprehensive guides for running SP1, RISC0, and TDX provers |
| docs/l2/architecture/prover.md | Simplified prover architecture documentation with updated workflow |
| docs/l2/architecture/overview.md | Updated batch commitment structure and L1 contract checks |
| docs/l2/aligned_integration.md | New guide for running ethrex in Aligned mode |
| docs/developers/l2/prover.md | Developer-focused prover setup instructions |
| docs/SUMMARY.md | Updated documentation structure with new sections and broken file references |
| docs/l2/deploy.md | Removed old deployment guide in favor of restructured documentation |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| > `--risc0.verifier-address` to use an existing verifier instead of deploying one on the public network. RISC0 recommends their deployed canonical verifier gateways; see the list here. | ||
| > `--tdx true` to require TEE proofs for validating batch execution and state settlement. | ||
| > `--tdx.verifier-address` to use an existing verifier instead of deploying one on the public network. Do not pass this flag if you want to deploy a new verifier. | ||
| > Enabling multiple proving backend will require running multiple provers, one for each backend. Refer to the [Run multiple provers](./prover/multi-prover.md) section for more details. |
There was a problem hiding this comment.
Grammar error: "backend" should be "backends" (plural) to agree with "multiple proving". Should be: "Enabling multiple proving backends will require..."
Suggested change
| > Enabling multiple proving backend will require running multiple provers, one for each backend. Refer to the [Run multiple provers](./prover/multi-prover.md) section for more details. | |
| > Enabling multiple proving backends will require running multiple provers, one for each backend. Refer to the [Run multiple provers](./prover/multi-prover.md) section for more details. |
docs/l2/architecture/prover.md
Outdated
| #### Step 6: state diff calculation and commitment | ||
|
|
||
| Finally, the program calculates the state diffs (changes between initial and final state) intended for publication to L1 as blob data. It creates a commitment to this data (a Merkle root hash), which is committed as a public input. Using proof of equivalence logic within the L1 bridge contract, this Merkle commitment can be verified against the KZG commitment of the corresponding blob data. | ||
| For running the prover, see [Deploy an L2](../../l2/deploy.md). |
There was a problem hiding this comment.
The reference link is incorrect. It points to ../../l2/deploy.md but based on the PR changes, the deployment guide has been restructured into ../../l2/deployment/README.md.
This should be updated to: [Deploy an L2](../../l2/deployment/README.md) or possibly [Deploy an L2](../deployment/README.md) depending on the intended path.
Suggested change
| For running the prover, see [Deploy an L2](../../l2/deploy.md). | |
| For running the prover, see [Deploy an L2](../../l2/deployment/README.md). |
|
|
||
| 1. The `ExecutionWitness` (collected during pre-execution) is converted to `GuestProgramState`. | ||
| 2. A `GuestProgramStateWrapper` is created to provide database functionality. | ||
| 3. For each state value in the database (account state and storage slots), the program verifies merkle proofs of the inclusion (or exclusion, in the case of accounts that didn't exist before this batch) of the value in the state trie |
There was a problem hiding this comment.
Grammar issue: "merkle proofs" should be capitalized as "Merkle proofs" (named after Ralph Merkle).
Suggested change
| 3. For each state value in the database (account state and storage slots), the program verifies merkle proofs of the inclusion (or exclusion, in the case of accounts that didn't exist before this batch) of the value in the state trie | |
| 3. For each state value in the database (account state and storage slots), the program verifies Merkle proofs of the inclusion (or exclusion, in the case of accounts that didn't exist before this batch) of the value in the state trie |
| ``` | ||
|
|
||
| > [!IMPORTANT] | ||
| > Cualquiera haya sido el metodo de instalacion de ethrex, asegurate de que el binario que estas utilizando tiene soporte para SP1, y tambien para GPU si es que tu intencion es correr un prover SP1 GPU. |
There was a problem hiding this comment.
This sentence contains Spanish text instead of English: "Cualquiera haya sido el metodo de instalacion de ethrex, asegurate de que el binario que estas utilizando tiene soporte para SP1, y tambien para GPU si es que tu intencion es correr un prover SP1 GPU."
This should be translated to English to maintain consistency with the rest of the documentation.
Suggested change
| > Cualquiera haya sido el metodo de instalacion de ethrex, asegurate de que el binario que estas utilizando tiene soporte para SP1, y tambien para GPU si es que tu intencion es correr un prover SP1 GPU. | |
| > Regardless of the method you used to install ethrex, make sure that the binary you are using has support for SP1, and also for GPU if your intention is to run an SP1 GPU prover. |
| ``` | ||
|
|
||
| > [!IMPORTANT] | ||
| > Cualquiera haya sido el metodo de instalacion de ethrex, asegurate de que el binario que estas utilizando tiene soporte para RISC0, y tambien para GPU si es que tu intencion es correr un prover RISC0 GPU. |
There was a problem hiding this comment.
This sentence contains Spanish text instead of English: "Cualquiera haya sido el metodo de instalacion de ethrex, asegurate de que el binario que estas utilizando tiene soporte para RISC0, y tambien para GPU si es que tu intencion es correr un prover RISC0 GPU."
This should be translated to English to maintain consistency with the rest of the documentation.
Suggested change
| > Cualquiera haya sido el metodo de instalacion de ethrex, asegurate de que el binario que estas utilizando tiene soporte para RISC0, y tambien para GPU si es que tu intencion es correr un prover RISC0 GPU. | |
| > Regardless of the installation method you used for ethrex, make sure that the binary you are using has support for RISC0, and also for GPU if your intention is to run a RISC0 GPU prover. |
Comment on lines
3
to
9
| Deployar los contratos de ethrex L2 en la L1 y levantar el nodo no lo es todo a la hora de levantar tu ethrex L2 stack. | ||
|
|
||
| Si venis siguiendo la guia de deployment, ya tendrias que tener un nodo ethrex L2 corriendo y conectado a la L1. Si este no es el caso, te recomiendo volver a esa guia antes de continuar. | ||
|
|
||
| El siguiente paso es correr el prover, que es el componente encargado de generar las pruebas ZK para los bloques de la L2. Pruebas que luego seran enviadas a la L1 para su verificacion y asi dar por finalizado el estado de tu L2. | ||
|
|
||
| En esta seccion, vamos a cubrir como correr uno o varios provers de ethrex L2. |
There was a problem hiding this comment.
These paragraphs contain Spanish text instead of English:
- "Deployar los contratos de ethrex L2 en la L1 y levantar el nodo no lo es todo a la hora de levantar tu ethrex L2 stack."
- "Si venis siguiendo la guia de deployment, ya tendrias que tener un nodo ethrex L2 corriendo y conectado a la L1. Si este no es el caso, te recomiendo volver a esa guia antes de continuar."
- "El siguiente paso es correr el prover, que es el componente encargado de generar las pruebas ZK para los bloques de la L2. Pruebas que luego seran enviadas a la L1 para su verificacion y asi dar por finalizado el estado de tu L2."
- "En esta seccion, vamos a cubrir como correr uno o varios provers de ethrex L2."
These should be translated to English to maintain consistency with the rest of the documentation.
Suggested change
| Deployar los contratos de ethrex L2 en la L1 y levantar el nodo no lo es todo a la hora de levantar tu ethrex L2 stack. | |
| Si venis siguiendo la guia de deployment, ya tendrias que tener un nodo ethrex L2 corriendo y conectado a la L1. Si este no es el caso, te recomiendo volver a esa guia antes de continuar. | |
| El siguiente paso es correr el prover, que es el componente encargado de generar las pruebas ZK para los bloques de la L2. Pruebas que luego seran enviadas a la L1 para su verificacion y asi dar por finalizado el estado de tu L2. | |
| En esta seccion, vamos a cubrir como correr uno o varios provers de ethrex L2. | |
| Deploying the ethrex L2 contracts on L1 and starting the node is not all that's required to set up your ethrex L2 stack. | |
| If you have been following the deployment guide, you should already have an ethrex L2 node running and connected to L1. If that's not the case, we recommend returning to that guide before continuing. | |
| The next step is to run the prover, which is the component responsible for generating ZK proofs for L2 blocks. These proofs are then sent to L1 for verification, finalizing the state of your L2. | |
| In this section, we will cover how to run one or more ethrex L2 provers. |
Contributor
There was a problem hiding this comment.
+1
We should change it to english
docs/l2/deployment/prover/README.md
Outdated
| - [Overview](./overview.md) | ||
| - [Running an ethrex L2 SP1 prover](./sp1.md) | ||
| - [Running an ethrex L2 RISC0 prover](./risc0.md) | ||
| - [Running an ethrex L2 TDX prover](./tdx.md) |
There was a problem hiding this comment.
The link text has an inconsistent filename reference. It says "tdx.md" in the link but the actual file is "tee.md" (as shown in the diff for docs/l2/deployment/prover/tee.md).
This should be:
- [Running an ethrex L2 TDX prover](./tee.md) (not ./tdx.md)
Suggested change
| - [Running an ethrex L2 TDX prover](./tdx.md) | |
| - [Running an ethrex L2 TDX prover](./tee.md) |
docs/SUMMARY.md
Outdated
| - [Overview](./l2/deployment/prover/overview.md) | ||
| - [Run an ethrex SP1 prover](./l2/deployment/prover/sp1.md) | ||
| - [Run an ethrex RISC0 prover](./l2/deployment/prover/risc0.md) | ||
| - [Run an ethrex TDX prover](./l2/deployment/prover/tdx.md) |
There was a problem hiding this comment.
The link references tdx.md but the actual file is named tee.md (as shown in the diff). This should be:
- [Run an ethrex TDX prover](./l2/deployment/prover/tee.md) (not ./l2/deployment/prover/tdx.md)
Suggested change
| - [Run an ethrex TDX prover](./l2/deployment/prover/tdx.md) | |
| - [Run an ethrex TDX prover](./l2/deployment/prover/tee.md) |
| > | ||
| > - Replace `L1_RPC_URL` with your preferred RPC provider endpoint. | ||
| > - Replace `PRIVATE_KEY` with the private key of an account funded on the target L1. This key will sign the transactions during deployment. | ||
| > - Replace `PATH_TO_L2_GENESIS_FILE` with the path to your L2 genesis file.A genesis example is available in the fixtures directory of the [official GitHub repository](https://github.com/lambdaclass/ethrex/blob/main/fixtures/genesis/l2.json). This file initializes the `OnChainProposer` contract with the genesis state root. |
There was a problem hiding this comment.
Missing space after period. Should be: "...L2 genesis file. A genesis example..." (note the space after the period before "A").
Suggested change
| > - Replace `PATH_TO_L2_GENESIS_FILE` with the path to your L2 genesis file.A genesis example is available in the fixtures directory of the [official GitHub repository](https://github.com/lambdaclass/ethrex/blob/main/fixtures/genesis/l2.json). This file initializes the `OnChainProposer` contract with the genesis state root. | |
| > - Replace `PATH_TO_L2_GENESIS_FILE` with the path to your L2 genesis file. A genesis example is available in the fixtures directory of the [official GitHub repository](https://github.com/lambdaclass/ethrex/blob/main/fixtures/genesis/l2.json). This file initializes the `OnChainProposer` contract with the genesis state root. |
| > `--risc0.verifier-address` to use an existing verifier instead of deploying one on the public network. RISC0 recommends their deployed canonical verifier gateways; see the list here. | ||
| > `--tdx true` to require TEE proofs for validating batch execution and state settlement. | ||
| > `--tdx.verifier-address` to use an existing verifier instead of deploying one on the public network. Do not pass this flag if you want to deploy a new verifier. | ||
| > Enabling multiple proving backend will require running multiple provers, one for each backend. Refer to the [Run multiple provers](./prover/multi-prover.md) section for more details. |
There was a problem hiding this comment.
Grammar error: "backend" should be "backends" (plural) to agree with "multiple proving". Should be: "Enabling multiple proving backends will require..."
Suggested change
| > Enabling multiple proving backend will require running multiple provers, one for each backend. Refer to the [Run multiple provers](./prover/multi-prover.md) section for more details. | |
| > Enabling multiple proving backends will require running multiple provers, one for each backend. Refer to the [Run multiple provers](./prover/multi-prover.md) section for more details. |
added 2 commits
November 14, 2025 21:19
Contributor
There was a problem hiding this comment.
This is missing the command to run the prover
tomip01
reviewed
Nov 17, 2025
| - Start the L2 locally on port `1729`. | ||
| 4. In a new terminal → `make init-prover-<sp1|risc0|exec> # GPU=true`. | ||
|
|
||
| After this initialization we should have the prover running in `dev_mode` → No real proofs. |
Contributor
There was a problem hiding this comment.
sp1 and risc0 actually generates proofs
| > Used for development purposes. | ||
| 1. `cd crates/l2` | ||
| 2. `make rm-db-l2 && make down` |
Contributor
There was a problem hiding this comment.
We could use this:
Suggested change
| 2. `make rm-db-l2 && make down` | |
| 2. `make rm-db-l2 down` |
|
|
||
| ### L1 block proving | ||
|
|
||
| ethrex-prover is able to generate execution proofs of Ethereum Mainnet/Testnet blocks. An example binary was created for this purpose in `crates/l2/prover/bench`. Refer to its README for usage. |
Contributor
There was a problem hiding this comment.
The path crates/l2/prover/bench does not exists.
| ETHREX_L2_SP1=true | ||
| # Check the if the verification contract is present on your preferred network. Don't define this if you want it to be deployed automatically. | ||
| ETHREX_DEPLOYER_SP1_VERIFIER_ADDRESS=<address> | ||
| # Set to true if you want proofs to be required |
Contributor
There was a problem hiding this comment.
Suggested change
| # Set to true if you want proofs to be required | |
| # Set to true if you want RISC0 proofs to be required |
Comment on lines
+118
to
+119
| - `make rm-db-l2 && make down` | ||
| - `make deploy-l1 && make init-l2` (if running a risc0 prover, see the next step before invoking the L1 contract deployer) |
Contributor
There was a problem hiding this comment.
Same here, the make is redundant:
Suggested change
| - `make rm-db-l2 && make down` | |
| - `make deploy-l1 && make init-l2` (if running a risc0 prover, see the next step before invoking the L1 contract deployer) | |
| - `make rm-db-l2 down` | |
| - `make deploy-l1 init-l2` (if running a risc0 prover, see the next step before invoking the L1 contract deployer) |
| ``` | ||
|
|
||
| > [!IMPORTANT] | ||
| > Cualquiera haya sido el metodo de instalacion de ethrex, asegurate de que el binario que estas utilizando tiene soporte para RISC0, y tambien para GPU si es que tu intencion es correr un prover RISC0 GPU. |
| ``` | ||
|
|
||
| > [!IMPORTANT] | ||
| > Cualquiera haya sido el metodo de instalacion de ethrex, asegurate de que el binario que estas utilizando tiene soporte para SP1, y tambien para GPU si es que tu intencion es correr un prover SP1 GPU. |
| > `--risc0.verifier-address` to use an existing verifier instead of deploying one on the public network. RISC0 recommends their deployed canonical verifier gateways; see the list here. | ||
| > `--tdx true` to require TEE proofs for validating batch execution and state settlement. | ||
| > `--tdx.verifier-address` to use an existing verifier instead of deploying one on the public network. Do not pass this flag if you want to deploy a new verifier. | ||
| > Enabling multiple proving backend will require running multiple provers, one for each backend. Refer to the [Run multiple provers](./prover/multi-prover.md) section for more details. |
Comment on lines
+61
to
+62
| --proof-coordinator.l1-private-key <L1_PROOF_SENDER_PRIVATE_KEY> \ | ||
| --committer.l1-private-key <L1_COMMITTER_PRIVATE_KEY> \ |
Contributor
There was a problem hiding this comment.
Should we can add:
Suggested change
| --proof-coordinator.l1-private-key <L1_PROOF_SENDER_PRIVATE_KEY> \ | |
| --committer.l1-private-key <L1_COMMITTER_PRIVATE_KEY> \ | |
| --proof-coordinator.l1-private-key <L1_PROOF_SENDER_PRIVATE_KEY> \ | |
| --committer.l1-private-key <L1_COMMITTER_PRIVATE_KEY> \ | |
| --block-producer.base-fee-vault-address <BASE_FEE_VAUÑT_ADDRESS> \ | |
| --block-producer.operator-fee-vault-address <OPERATOR_FEE_VAULT> \ | |
| --block-producer.operator-fee-per-gas <FEE_PER_GAS> \ | |
| --osaka-activation-time <OSAKA_ACTIVATION_TIME> \ |
Contributor
There was a problem hiding this comment.
We have to update this, we no longer use state diffs and now we use the list of transactions. The rest is good
| - **Interested in deploying your own L2?** | ||
|
|
||
| See [L2 rollup deployment](../l2/deploy.md) for launching your own rollup, deploying contracts, and interacting with your L2. | ||
| See [L2 rollup deployment](../l2/deployment/overview.md) for launching your own rollup, deploying contracts, and interacting with your L2. |
Contributor
There was a problem hiding this comment.
Maybe point to the readme instead?
Suggested change
| See [L2 rollup deployment](../l2/deployment/overview.md) for launching your own rollup, deploying contracts, and interacting with your L2. | |
| See [L2 rollup deployment](../l2/deployment/README.md) for launching your own rollup, deploying contracts, and interacting with your L2. |
Contributor
There was a problem hiding this comment.
Shouldn't this directory be under fundamentals instead?
| @@ -0,0 +1,84 @@ | |||
| # Deploying a validium ethrex L2 | |||
|
|
|||
| In this section, we'll cover how to deploy a validium ethrex L2 on a public network such as Holesky, Sepolia, or Mainnet. | |||
Contributor
There was a problem hiding this comment.
Holesky is not functioning anymore, let's change it to Hoodi
| - `execution_witness`: A structure containing the necessary state data (like account and storage values with their Merkle proofs) required for the execution of the blocks. It includes the parent header of the first block. | ||
| - `elasticity_multiplier`: A parameter for block validation. | ||
| - `fee_configs`: L2-specific fee configurations for each block. | ||
| - `blob_commitment` and `blob_proof`: L2-specific data for verifying the state diff blob. |
Contributor
There was a problem hiding this comment.
Suggested change
| - `blob_commitment` and `blob_proof`: L2-specific data for verifying the state diff blob. | |
| - `blob_commitment` and `blob_proof`: L2-specific data for verifying the blob. |
| - `final_state_hash`: The state root from the header of the last block. | ||
| - `l1messages_merkle_root`: The Merkle root of L1 messages (withdrawals) generated during block execution. | ||
| - `privileged_transactions_hash`: A hash representing all privileged transactions processed in the blocks. | ||
| - `blob_versioned_hash`: The versioned hash of the state diff blob, derived from its KZG commitment. |
Contributor
There was a problem hiding this comment.
Suggested change
| - `blob_versioned_hash`: The versioned hash of the state diff blob, derived from its KZG commitment. | |
| - `blob_versioned_hash`: The versioned hash of the blob, derived from its KZG commitment. |
| 2. Exclusion proofs: Prove that `key` does not exist in the MPT with root hash `h`. | ||
| These proofs allow verifying that a value is included (or its key doesn't exist) in a specific state. | ||
|
|
||
| ### Prelude 2: privileged transactions, L1 messages and state diffs |
Contributor
There was a problem hiding this comment.
Should we still include state diffs here?
Comment on lines
+11
to
+15
| Going a bit further, instead of posting the entire transaction, we could just post which accounts have been modified and their new values (this includes deployed contracts and their bytecode of course). This can reduce the size a lot for most cases; in the case of a regular transfer as above, we only need to record balance updates of two accounts, which requires sending just two `(address, balance)` pairs, so (20 + 32) * 2 = 104 bytes, or around half as before. Some other clever techniques and compression algorithms can push down the publishing cost of this and other transactions much further. | ||
|
|
||
| This is called `state diffs`. Instead of publishing entire transactions for data availability, we only publish whatever state they modified. This is enough for anyone to reconstruct the entire state of the chain. | ||
|
|
||
| Detailed documentation on [the state diffs spec](./state_diffs.md). |
Contributor
There was a problem hiding this comment.
We don't do this anymore
|
|
||
| Similarly, the program constructs a binary Merkle tree of all L2->L1 messages (withdrawals) initiated in the blocks and calculates its root hash. This hash is also committed as a public input. Later, L1 accounts can claim their withdrawals by providing a Merkle proof of inclusion that validates against this root hash on the L1 bridge contract. | ||
|
|
||
| ### Step 6: state diff calculation and commitment |
|
|
||
| ## Start multiple ethrex L2 provers | ||
|
|
||
| Once you have your ethrex L2 deployed with multiple proving backends enabled (SP1, RISC0, TDX), refer to the following guides to start each prover: |
Contributor
There was a problem hiding this comment.
Remove this file. A similar version is in deployment/overview.md
docs/l2/deployment/prover/risc0.md
Outdated
|
|
||
| ## Prerequisites | ||
|
|
||
| - This guide assumes that you have ethrex installed and available in your PATH. If you haven't installed it yet, follow one of the methods in the Installation Guide. If you want to build the binary from source, refer to the [Building from source](./overview.md#building-from-source-skip-if-ethrex-is-already-installed) section and select the appropriate build option. |
Contributor
There was a problem hiding this comment.
We have to clarify that ethrex should be installed with the risc0 feature flag
|
|
||
| ### Data availability | ||
|
|
||
| Rollups publish state diffs as blob data to the L1 so that users can reconstruct the L2 state and rescue their funds if the sequencing were to fail or censors data. This published data needs to be part of the zk proof the prover generated. For this it calculates the valid state diffs and verifies a KZG proof, whose commitment can later be compared to the one published to the L1 using the `BLOBHASH` EVM opcode. See [data availability](../l2/fundamentals/data_availability.md) for more details. |
Contributor
There was a problem hiding this comment.
We don't publish state diffs anymore but the list of transactions
docs/l2/deployment/prover/sp1.md
Outdated
|
|
||
| ## Prerequisites | ||
|
|
||
| - This guide assumes that you have ethrex installed and available in your PATH. If you haven't installed it yet, follow one of the methods in the Installation Guide. If you want to build the binary from source, refer to the [Building from source](./overview.md#building-from-source-skip-if-ethrex-is-already-installed) section and select the appropriate build option. |
Contributor
There was a problem hiding this comment.
We have to clarify that ethrex should be installed with the sp1 feature flag
Contributor
There was a problem hiding this comment.
In the docs in main, I added to these sections some warnings clarifying that we are not currently using state diffs. We should add them here too.
MegaRedHand
reviewed
Nov 17, 2025
Comment on lines
+30
to
+37
| > If you plan to prove your L2 using SP1, RISC0, or TDX, add the following extra arguments to the command above: | ||
| > `--sp1 true` to require SP1 proofs for validating batch execution and state settlement. | ||
| > `--sp1.verifier-address` to use an existing verifier instead of deploying one on the public network. Succinct Labs recommends their deployed canonical verifier gateways; see the list here. | ||
| > `--risc0 true` to require RISC0 proofs for validating batch execution and state settlement. | ||
| > `--risc0.verifier-address` to use an existing verifier instead of deploying one on the public network. RISC0 recommends their deployed canonical verifier gateways; see the list here. | ||
| > `--tdx true` to require TEE proofs for validating batch execution and state settlement. | ||
| > `--tdx.verifier-address` to use an existing verifier instead of deploying one on the public network. Do not pass this flag if you want to deploy a new verifier. | ||
| > Enabling multiple proving backend will require running multiple provers, one for each backend. Refer to the [Run multiple provers](./prover/multi-prover.md) section for more details. |
Collaborator
There was a problem hiding this comment.
This looks cluttered when rendered. Maybe it'd be better to display this as a list:
Suggested change
| > If you plan to prove your L2 using SP1, RISC0, or TDX, add the following extra arguments to the command above: | |
| > `--sp1 true` to require SP1 proofs for validating batch execution and state settlement. | |
| > `--sp1.verifier-address` to use an existing verifier instead of deploying one on the public network. Succinct Labs recommends their deployed canonical verifier gateways; see the list here. | |
| > `--risc0 true` to require RISC0 proofs for validating batch execution and state settlement. | |
| > `--risc0.verifier-address` to use an existing verifier instead of deploying one on the public network. RISC0 recommends their deployed canonical verifier gateways; see the list here. | |
| > `--tdx true` to require TEE proofs for validating batch execution and state settlement. | |
| > `--tdx.verifier-address` to use an existing verifier instead of deploying one on the public network. Do not pass this flag if you want to deploy a new verifier. | |
| > Enabling multiple proving backend will require running multiple provers, one for each backend. Refer to the [Run multiple provers](./prover/multi-prover.md) section for more details. | |
| > If you plan to prove your L2 using SP1, RISC0, or TDX, add the following extra arguments to the command above: | |
| > - `--sp1 true` to require SP1 proofs for validating batch execution and state settlement. | |
| > - `--sp1.verifier-address` to use an existing verifier instead of deploying one on the public network. Succinct Labs recommends their deployed canonical verifier gateways; see the list here. | |
| > - `--risc0 true` to require RISC0 proofs for validating batch execution and state settlement. | |
| > - `--risc0.verifier-address` to use an existing verifier instead of deploying one on the public network. RISC0 recommends their deployed canonical verifier gateways; see the list here. | |
| > - `--tdx true` to require TEE proofs for validating batch execution and state settlement. | |
| > - `--tdx.verifier-address` to use an existing verifier instead of deploying one on the public network. Do not pass this flag if you want to deploy a new verifier. | |
| > | |
| > Enabling multiple proving backends will require running multiple provers, one for each backend. Refer to the [Run multiple provers](./prover/multi-prover.md) section for more details. |
jrchatruc
approved these changes
Nov 19, 2025
avilagaston9
approved these changes
Nov 19, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Motivation