> 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/rome-zk-evm/prover-host.md). # Host de pruebas Dimensiona y prepara el host con GPU que prueba lotes Rome ZK EVM con ZisK 1.3.1-alpha. El nodo puede secuenciar transacciones y publicar lotes sin una GPU. Necesita un probador para hacer definitiva cualquier raíz en Solana. En v0.3.0 el probador ejecuta ZisK 1.3.1-alpha con el guest compilado para el génesis de tu cadena. Demuestra los lotes de inbox de uno en uno, verifica cada prueba localmente y luego la publica en liquidación. La [guía completa del probador-host](https://github.com/rome-protocol/solana-zk-evm/blob/v0.3.0/docs/PROVER-HOST.md) tiene los pasos de configuración y recuperación. Úsalo con el [manual de ejecución de devnet](https://github.com/rome-protocol/solana-zk-evm/blob/v0.3.0/docs/RUN-ON-DEVNET.md). ## Dimensiona el host Usa Ubuntu 22.04 x86-64 o posterior y una GPU NVIDIA con más de 30 GB de memoria. El script de configuración acepta una GPU con unos 32,2 GB o más. El paso final de la prueba pide unos 30 GB, así que una tarjeta de 24 GB es demasiado pequeña. El controlador de NVIDIA debe ser como mínimo 525.60.13. Permite al menos **128 GB de RAM** y **125 GB de disco libre** en la ubicación de instalación de ZisK. El archivo de claves de prueba 1.3.1-alpha tiene 5,1 GB y el archivo de claves PLONK tiene 21,9 GB. Después de que la configuración generó sus archivos constantes, los dos directorios de claves ocuparon 21 GiB y 26 GiB. La primera prueba añade archivos de caché. Un host con CPU midió 102,1 GB en total tras una prueba, y el crecimiento de la caché de GPU no se ha medido. La biblioteca de prueba 1.3.1-alpha informó 24,7 GB para su búfer de trabajo principal y 5,6 GB para la recursión en un lote de unos 3 millones de pasos. El pico de todo el proceso en esta versión no se registró. La ejecución de GPU de devnet usó un host con 176 GB de RAM; tampoco se registró su uso máximo de RAM. Usa 128 GB como estimación de dimensionamiento, no como un pico medido. ## Qué se midió Un lote casi vacío tardó unos **17 segundos**, incluyendo el envoltorio PLONK, en un host con una **RTX PRO 6000 de 96 GB**, 48 núcleos de CPU y 176 GB de RAM. Se mostró que se estaban usando unos 95 GB de memoria de GPU. Eso es lo que mantuvo esta ejecución, no la memoria mínima de GPU para cada lote. Los lotes más grandes no se han medido en una GPU. Rome procesó 116 lotes de devnet casi vacíos en unos 35 minutos en esa GPU. Eso importa cuando una cadena ha producido bloques vacíos mientras esperaba su clave de verificación: el probador debe procesarlos en orden antes de poder alcanzar el estado más reciente. ## Ejecuta el script de configuración Instala el controlador de NVIDIA y reinicia si hace falta. Desde la raíz del repositorio, ejecuta el script de la versión como root. Define `ZISK_HOME` en el directorio donde vivirán ZisK y sus claves. Usa el mismo valor en tu rollup `.env`: ```sh sudo ZISK_HOME=/opt/zisk bash deploy/rollup/prover/setup-prover-host.sh sudo ZISK_HOME=/opt/zisk bash deploy/rollup/prover/setup-prover-host.sh --check ``` El script instala la compilación GPU de ZisK, sus claves de prueba y PLONK, las bibliotecas del sistema que necesita y el runtime NVIDIA de Docker. Establece el límite de memoria bloqueada en ilimitado. Cierra sesión y vuelve a entrar para que ese límite se aplique a tu shell. Luego comprueba la GPU y el controlador, los binarios instalados, las claves, el límite de memoria y el runtime del contenedor. Antes de ejecutar el instalador, comprueba el SHA-256 del instalador. Comprueba ambos archivos de claves antes de descomprimir cualquiera de ellos, y comprueba el `cargo-zisk` y `cargo-zisk-dev` binarios de GPU antes de que el script los ejecute. Genera los archivos constantes necesarios para la agregación y la prueba PLONK. Si una ejecución falla, vuelve a ejecutar el script. Omite la descarga de claves cuando las claves instaladas ya coinciden con el manifiesto fijado. El script no comprueba todas las partes de la instalación de ZisK. El instalador descarga un paquete binario y ejecuta su instalador de la cadena de herramientas antes de que el script compruebe los dos binarios de GPU instalados. Otros ejecutables y archivos fuente de ese paquete no se comprueban mediante hash con este script. La guía completa indica esta limitación y tiene los comandos para comprobar cada descarga por separado. ## Conéctalo a tu cadena El probador necesita el ELF del guest correspondiente, sus metadatos de verificación y las mismas claves de prueba 1.3.1-alpha. Establece `PROVER=on` y la configuración del guest y de ZisK en la configuración del rollup, y luego ejecuta `./rollup init` y `./rollup up`. La primera ejecución construye la imagen del probador a partir del código fuente v0.3.0. La imagen del nodo por sí sola no contiene el probador. Antes de cada arranque, el probador compara las claves de prueba instaladas con el manifiesto SHA-256 fijado. Esa comprobación cubre los nombres de archivo y el contenido. Los archivos constantes generados por el árbol y los archivos constantes de la GPU se excluyen porque difieren según el host. Una discrepancia detiene el probador con `KeysShaMismatch`. No cambies el manifiesto solo para que arranque una instalación que no coincide; instala la versión que corresponda al guest y a la clave registrada de la cadena. Ejecute `./rollup check` después de iniciar. Comprueba el servicio del probador, la clave de verificación activa y el retraso entre liquidación y probador. La [guía de monitoreo](https://github.com/rome-protocol/solana-zk-evm/blob/v0.3.0/docs/MONITORING.md) enumera las métricas locales y las condiciones de alerta útiles. --- # 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/rome-zk-evm/prover-host.md?ask=&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.