> For the complete documentation index, see [llms.txt](https://docs.rome.builders/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.rome.builders/es/canton-zk-evm/run-it-locally.md).

# Ejecutarlo localmente

Ejecuta las comprobaciones, el ensayo sin GPU y la demo local de Ostia en una GPU.

Los scripts suministrados ejecutan una red de pruebas local. Canton guarda su estado en memoria, por lo que cada reinicio descarta ese estado y crea una nueva red. La demo de GPU demuestra bloques. El ensayo usa una prueba de sustitución y no necesita GPU.

Esta página describe commit `a84e84e439a5cc669c0ae61facf7c8c995d9d564`. Lea el texto completo [guía de la red](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/network/README.md) y [guía de demostración](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/demo/README.md). Ejecuta los comandos de abajo desde la `canton-zk-evm` raíz del repositorio.

## Lo que necesitas

| Trabajo                          | Requisitos                                                                                                                        |
| -------------------------------- | --------------------------------------------------------------------------------------------------------------------------------- |
| Comprobaciones del repositorio   | Docker, `bash`, `curl`, `jq`, `openssl` y Python 3. Las pruebas de Rust usan `rust-toolchain.toml`.                               |
| Pruebas de integración de Canton | Linux x86-64, Java 21 y acceso a la red.                                                                                          |
| Ensayo de la demo                | Linux x86-64, Docker, Java 21, Rust y Python 3.12 o posterior.                                                                    |
| Pruebas del explorador           | Node 22.18 o posterior.                                                                                                           |
| Red GPU y demo                   | Linux x86-64, una GPU NVIDIA con su controlador instalado, Docker, Rust, Python 3.12 o posterior, `jq`, `curl`, `openssl` y ZisK. |

La [README del repositorio](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/README.md#running-the-tests) enumera los prerrequisitos de las pruebas. El instalador de GPU usa `sudo` y `apt` en Debian o Ubuntu y necesita unos 100 GB de espacio libre en disco. Instala paquetes del sistema y cambia los límites de bloqueo de memoria. El obtenedor de herramientas de la red instala Java 21 si falta. Véase [Host de pruebas](/es/canton-zk-evm/prover-host.md) para el hardware probado; no se ha establecido la memoria mínima de la GPU.

## Ejecuta las pruebas

Empieza con las comprobaciones rápidas de [CONTRIBUTING.md](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/CONTRIBUTING.md#building-and-testing):

```sh
tests/static.sh                  # los pines, genesis y las líneas de licencia coinciden
tests/refuses_missing_flag.sh    # el lanzamiento de reth rechaza una bandera ausente o incorrecta
tests/fixtures.sh                # la prueba registrada es coherente
gateway/build.sh --check         # el código de gateway incluido en el repositorio es lo que compila Gateway.sol (Docker)
```

El README del repositorio también ofrece estas comprobaciones. No necesitan GPU:

```sh
tests/udp_control.sh             # la comprobación UDP falla en un contenedor con un listener UDP (sin reth)
tests/discovery.sh               # inicia el reth fijado, comprueba que no tiene pares, lo detiene
tests/network_static.sh          # reth solo a través de launch.sh, la config de Canton, el resultado de humo registrado
tests/network_checks.sh          # la comprobación del pin del compilador, el id del DAR, la detención ante otro programVK (sin GPU)
tests/canton_network.sh          # el Canton fijado, el paquete Daml real y un Advance (Linux x86-64, Java 21, Python 3; sin GPU)
gateway/tests/run.sh             # el gateway sobre un reth real, iniciado con el descubrimiento de pares desactivado (Docker, curl, jq, Python 3 con los paquetes de demo/requirements.txt)
tests/guest-repro.sh             # la compilación del guest se ejecuta en una carpeta fija, así que la carpeta fuente no cambia el ELF (sustitutos para las herramientas de ZisK; la misma comprobación en ZisK real pasó el 2026-10-04, véase guest/README.md)
tests/demo_static.sh             # los pines de la demo, el interruptor de manipulación y la anulación de genesis, y sus resultados registrados (sin GPU)
tests/demo_explorer_static.sh    # las imágenes del explorador están fijadas, y lo que se le da a su contenedor (sin Docker)
(cd explorer && npm ci && npm test)  # las pruebas del explorador, contra sustitutos (Node 22.18+; CI usa EXPLORER_NODE_IMAGE en PINS)
(cd guest/rules && cargo test)   # las reglas de la cadena y su hash (necesita Rust)
```

## Ensayar sin GPU

```sh
tests/demo_rehearsal.sh          # la demo y el explorador con una prueba de sustitución (Linux x86-64, Docker, Java 21, Rust, Python 3.12+; sin GPU)
```

Esto ejecuta el reth real, Canton, el paquete Daml, el estándar de tokens y el builder. El sidecar comprueba las piernas del gateway contra pruebas de almacenamiento, mientras un sustituto responde a la `verificar` llamada. El ensayo no demuestra un bloque ni verifica una prueba real de conocimiento cero.

También comprueba el explorador y el faucet. La comprobación Verify del explorador debe rechazar la prueba de sustitución. El [README de la demo](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/demo/README.md#the-rehearsal) describe la cobertura del ensayo.

## Iniciar la red local en una GPU

Instala ZisK con `prover/install.sh` antes de iniciar la red. Inicia siempre reth mediante el lanzador suministrado; `network/up.sh` lo usa.

```sh
network/up.sh       # herramientas, compilación del guest, reth, sidecars, prover, Canton, la cadena
CZE_SOURCE_COMMIT=$(git rev-parse HEAD) network/smoke.sh    # un bloque vacío, probado y confirmado
network/down.sh
```

`up.sh` compila el guest y rechaza una clave de programa, raíz de ZisK o hash de reglas que difiera de los valores registrados. La red tiene un sincronizador y tres participantes. Los participantes operador y confirmador ejecutan cada uno un sidecar. El participante llamado users aloja las partes de prueba y el lector.

La prueba de humo confirma un bloque vacío, comprueba la cabeza de la cadena y el registro de bloque del lector, y comprueba que reth lo marcó como final. El estado y los registros van a `state/`, o `CZE_STATE_DIR` cuando está establecido.

## Ejecuta los cinco casos de la demo en una GPU

Usa una nueva red local para la demo:

```sh
demo/prepare.sh
CZE_GENESIS_FILE=$PWD/state/demo/genesis.json network/up.sh
CZE_SOURCE_COMMIT=$(git rev-parse HEAD) network/smoke.sh      # opcional: primero un bloque vacío
CZE_SOURCE_COMMIT=$(git rev-parse HEAD) demo/run.sh
network/down.sh
```

El script de preparación crea claves de prueba y un genesis financiado para la ejecución. La demo ejecuta su bloque de configuración, depósito, pago, retirada, rechazo de asignación y rechazo de prueba manipulada. El script se detiene si falla una comprobación y escribe sus resultados en `demo/results/`.

Para una exportación del código fuente sin `.git`, establece `CZE_SOURCE_COMMIT` en el hash completo del commit usado para la exportación. Para incluir el faucet, su genesis financiado debe prepararse antes de que la red arranque; véase [Explorador](/es/canton-zk-evm/explorer.md) y la guía completa de la demo.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.rome.builders/es/canton-zk-evm/run-it-locally.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.