> 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/run-a-rollup.md).

# Ejecuta un rollup

Registra y ejecuta tu propia cadena Rome ZK EVM en el devnet de Solana con el lanzador de rollups v0.3.0.

La `./rollup` runner inicia una cadena contra los programas compartidos de la devnet de Solana de Rome. Tú ejecutas su nodo y pagas sus costos en Solana. No despliegas tú mismo los programas de liquidación. El registro no requiere permisos, pero las raíces demostradas necesitan una clave de verificación específica de la cadena registrada por Rome.

Esta página usa **v0.3.0**. El [guía completa de la devnet](https://github.com/rome-protocol/solana-zk-evm/blob/v0.3.0/docs/RUN-ON-DEVNET.md) cubre cada ajuste, fallo y paso de recuperación.

## Antes de empezar

Usa una máquina Linux x86-64 con bash 4 o superior, Git, Docker Engine 28 o superior con Compose, curl, jq, openssl, la CLI de Solana y Python 3.11 o superior. Necesitas un endpoint RPC de la devnet de Solana, un par de claves de pagador de Solana financiado, que también es la autoridad de tu cadena, y una clave de firma del secuenciador. Mantén ambos archivos privados y legibles por el usuario 999 del contenedor. La guía explica cómo crearlos.

Presupuesta unos **7 SOL en la devnet** para el pagador. El registro bloquea 5 SOL; `./rollup check` se esperan al menos 1 SOL restantes para publicar y alquilar. El depósito pasa a ser reembolsable después de la primera raíz final o de diez raíces publicadas. Si la cadena se reclama antes de eso, el depósito va al tesoro. La cadena también necesita una dirección receptora de comisiones de EVM que controles.

Para liquidar raíces, necesitas un host de pruebas con una GPU NVIDIA de más de 30 GB de memoria. Una tarjeta de 24 GB es demasiado pequeña para el paso final de la prueba. [Host de pruebas](/es/rome-zk-evm/prover-host.md) aporta el presupuesto de RAM y disco. El nodo puede ejecutarse y publicar lotes antes de que el probador esté listo, pero ninguna de sus raíces será final.

## Inicia el nodo

Clona la versión y trabaja desde su directorio rollup:

```sh
git clone --branch v0.3.0 https://github.com/rome-protocol/solana-zk-evm.git
cd solana-zk-evm/deploy/rollup
cp .env.example .env
cp chain.toml.example chain.toml
```

Configura el RPC de Solana, las ubicaciones del firmante y `ROME_ZK_TAG=v0.3.0` en `.env`. Mantén `PROGRAMS_JSON=programs.devnet.json`. Establece `ROME_ZK_GUEST_TAG=v0.3.0` y `ZISK_RELEASE=1.3.1-alpha` para la compilación posterior del guest. Mantén el RPC vinculado a loopback para una primera ejecución local. Deja `PROVER` sin definir hasta que el guest y su clave estén listos.

Establezca `genesis.fee_recipient` en `chain.toml` a tu dirección de EVM. No elijas un ID de cadena. La liquidación deriva uno del pagador y de su recuento de registros; `init` lo lee antes de enviar nada. Aproximadamente la mitad de todos los IDs son demasiado grandes para MetaMask. Si el tuyo es uno, `init` se detiene con `ChainIdNotWalletSafe`; crea una nueva clave de pagador, apunta `PAYER_KEYPAIR_PATH` hacia ella y ejecuta `init` de nuevo.

Una cadena nueva comienza con saldos cero. Si declaras un saldo respaldado para obtener gas antes de que se abran los depósitos, bloquea la misma cantidad de SOL envuelto en la bóveda de la cadena antes de solicitar la clave de verificación.

```sh
./rollup init
./rollup register --dry-run
./rollup register --confirm
./rollup up
./rollup check
```

`init` renderiza la génesis y la configuración del servicio. `register --confirm` bloquea el depósito de 5 SOL y crea el cursor de lotes. `up` inicia el secuenciador, el procesador de lotes, derive y el nodo verificador. `check` nombra cualquier servicio que falte, luego compara el ID de la cadena, las cabeceras, el progreso del procesador de lotes, la bandeja de entrada y las raíces. Vuelve a ejecutarlo después de que los lotes hayan tenido tiempo de cerrarse; su primera comprobación del progreso de lotes solo registra una muestra.

Sin un probador, el secuenciador sirve RPC, el procesador de lotes publica los datos de transacción en la bandeja de entrada, y derive reconstruye la cadena. Un lote de la bandeja de entrada no es una raíz final de liquidación. Incluso la raíz de génesis espera una prueba.

## Pasa de los lotes a las raíces finales

Compila el guest para la génesis de tu cadena:

```sh
./rollup guest-build
```

La compilación usa el guest v0.3.0 y ZisK 1.3.1-alpha. Produce el programa guest de la cadena y los metadatos de la clave de verificación. Calcular `programVK` necesita las claves de prueba de ZisK y unos 36 GB de RAM. Registrar la cadena no registra una clave de verificación. Envía la [solicitud de clave de verificación](/es/rome-zk-evm/verification-key.md) después de la compilación. Rome comprueba tu génesis y tu guest, luego registra la clave con un slot de activación.

En el host de pruebas, establece `PROVER=on` y el guest, los metadatos de verificación y los ajustes de ZisK descritos en la guía completa de ejecución. Después de que la clave esté activa:

```sh
./rollup init
./rollup up
./rollup check
```

Comprueba que el `servicio prover` y `clave de verificación` elementos pasan. El probador procesa los lotes de la bandeja de entrada en orden. Cada prueba válida publica una raíz que es final en cuanto su transacción de Solana se confirma.

## Genera el primer bloque

Sin un saldo de génesis respaldado, la cadena no tiene gas para una transacción hasta que se abran los depósitos. Los depósitos necesitan una primera raíz demostrada. El valor predeterminado `empty_block_interval_secs = 0` deja una cadena inactiva sin bloques, así que establécelo en `60` menos de `[profile]` en `chain.toml` después de que la clave esté activa y el probador esté en ejecución. Renderiza y reinicia:

```sh
./rollup init
./rollup up
./rollup check
```

Una vez que la primera raíz sea final, vuelve a establecer el intervalo en `0` y vuelve a ejecutar `init` y `up` a menos que quieras bloques vacíos regulares. Activarlos mientras esperas a que Rome registre la clave crea un atasco. Cada lote debe probarse en orden.

Con un intervalo de bloques vacíos de 60 segundos y un cierre de lotes de 60 segundos, la cadena genera aproximadamente un lote por minuto, o unos 1.440 al día. En la devnet, una raíz demostrada costó al pagador unos **0.003 SOL**: unos 0,002 SOL en alquiler de cuenta pendiente, la tarifa de liquidación de 0,001 SOL y además una tarifa de transacción. Ese ritmo supone unos 4,4 SOL al día antes de los costos de publicación en la bandeja de entrada. El alquiler de cuentas pendientes permanece bloqueado con la configuración predeterminada. Con los bloques vacíos desactivados, una cadena inactiva no sella lotes ni paga costos de publicación.

Para aceptar depósitos, a continuación crea la bóveda, activa la configuración de salida después de su retardo y abre una cola de depósitos. Esos comandos y las comprobaciones están en [Depósitos y retiros](/es/rome-zk-evm/deposits-and-withdrawals.md).


---

# 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/run-a-rollup.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.