> 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/prover-host.md).

# Host de pruebas

Los requisitos del host del probador, el trabajador persistente y la compilación del guest fijada.

El demostrador ejecuta ZisK con un trabajador de GPU. El coordinador y el trabajador permanecen en ejecución entre solicitudes, con la clave PLONK ya cargada. Para cada bloque, el generador envía la entrada y recibe una prueba envuelta.

Esta página describe commit `a84e84e439a5cc669c0ae61facf7c8c995d9d564`. Lea el texto completo [README del demostrador](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/prover/README.md) y [mediciones](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/docs/METRICS.md).

## Requisitos del host

El instalador se dirige a Linux x86-64 con `apt`, `sudo`, un controlador NVIDIA instalado y unos 100 GB de espacio libre en disco. Instala paquetes del sistema y cambia los límites de bloqueo de memoria.

El punto de referencia del 2026-10-03 utilizó una NVIDIA RTX PRO 6000 Blackwell Server Edition con 96 GB de memoria de GPU, 48 vCPU en un AMD EPYC 9B45 y 176 GiB de RAM del host. Se ejecutó en Ubuntu 22.04.5 con el controlador 580.178.04. Estas especificaciones describen la máquina probada; no establecen el hardware mínimo necesario para ejecutar el demostrador.

El punto de referencia registró 22,9 GiB de memoria compartida del emulador. Solo el envoltorio PLONK informó un requisito de GPU de 30.054.767.337 bytes, unos 28,0 GiB. El uso máximo de memoria de GPU fue de 93,2 GiB, pero el demostrador dimensiona un gran búfer para la tarjeta. Ese pico refleja la asignación del búfer y no muestra cuánta memoria de GPU necesita como mínimo todo el demostrador. Vea [Mediciones](/es/canton-zk-evm/measurements.md) para el alcance de cada número.

## Compilar y ejecutar

Los scripts usan las versiones en [PINS](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/PINS). El demostrador usa ZisK 1.3.1-alpha, Node 20.20.2 y snarkjs 0.7.6. La versión de Node del explorador es independiente.

| Script                  | Qué hace                                                                                                                                    |
| ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- |
| `prover/install.sh`     | Compruebe la suma de verificación fijada del instalador y luego instale la compilación de GPU, la clave de prueba y la configuración PLONK. |
| `prover/build-guest.sh` | Compila el ELF invitado e imprime su SHA-256, programVK, rootC y hash de reglas.                                                            |
| `prover/start.sh`       | Inicia el coordinador y un trabajador de GPU con la clave PLONK cargada.                                                                    |
| `prover/make-input.sh`  | Convierte un bloque guardado, una prueba de ejecución y genesis en entrada para el demostrador.                                             |
| `prover/prove-one.sh`   | Demuestra una entrada, verifica la prueba con `cargo-zisk`y escribe la prueba envuelta como hex.                                            |

`ZISK_COORDINATOR_URL` selecciona el coordinador. Su valor predeterminado es el coordinador en la misma máquina. `network/up.sh` compila el invitado e inicia el demostrador como parte de la red local; siga [Ejecutarlo localmente](/es/canton-zk-evm/run-it-locally.md) para esa secuencia.

El generador usa por defecto `prover/prove-one.sh` a través de `CZE_PROVE_CMD`. Ese comando recibe un archivo de entrada y una carpeta de salida y debe dejar `wrapped-proof.hex`. Su `cargo-zisk` comprobación local no aplica las fijaciones de programVK y rootC de la cadena. Los sidecars de los confirmadores aplican esas fijaciones. Vea las [configuraciones del generador](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/builder/README.md#settings).

## Reproducir la clave del invitado

El script de compilación usa una carpeta de compilación fija y rechaza un ELF que todavía contenga una ruta de compilación. Ejecute una compilación de invitado a la vez porque cada compilación vacía esa carpeta compartida.

El 2026-10-04, dos repositorios recién clonados compilados secuencialmente por un usuario en una máquina produjeron el mismo ELF y programVK. Las compilaciones tardaron 133 s y 126 s. Para reproducir la compilación como otro usuario o en otra máquina, compruebe que el programVK resultante coincida con el valor registrado. `network/up.sh` se detiene si las fijaciones de la compilación difieren. El [README del invitado](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/guest/README.md#building) describe la compilación y sus límites.

## Salida de la prueba

El formato wire es de 1.344 bytes: 768 bytes de prueba PLONK, 32 bytes de programVK, 32 bytes de rootC y 512 bytes de valores públicos. `prove-one.sh` escribe la forma hex y el JSON producido por `cargo-zisk-dev export-solidity-calldata`.


---

# 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/prover-host.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.