> 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/verification-key.md).

# Clave de verificación

Construye un guest por lotes específico de la cadena y solicita el registro de su clave de verificación de ZisK.

Cada cadena tiene su propio guest de lote. El guest contiene el genesis de la cadena y el receptor de comisiones. Comprueba los datos y la ejecución del lote, y luego confirma los valores públicos que verifica la conciliación de Solana. Del guest `programVK` identifica el programa que se está demostrando.

Una cadena sin permisos se registra con un registro de claves de verificación vacío. No puede publicar una raíz final hasta que Rome añada una clave para esa cadena. La autoridad de la cadena no puede incluir una clave en su transacción de registro. Este es el proceso v0.3.0 en Solana devnet.

## Construye el guest

Desde `deploy/rollup` en el checkout v0.3.0, usa la configuración de lanzamiento `ROME_ZK_TAG=v0.3.0`, `ROME_ZK_GUEST_TAG=v0.3.0` y `ZISK_RELEASE=1.3.1-alpha`. Ejecuta `./rollup init` primero para que se rendericen el genesis y el ID de la cadena. Necesitas que la cadena esté registrada antes de enviar la solicitud. Luego ejecuta:

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

El comando construye una imagen con la cadena de herramientas de ZisK, clona las fuentes del rollup y del guest en esas etiquetas, construye el guest a partir de tu genesis y verifica que lleve tu ID de cadena. Imprime el SHA-256 del ELF del guest. Los metadatos generados registran ese hash, el hash del genesis, el ID de cadena, la versión de ZisK y su número de esquema. Para esta versión, esos dos últimos valores son `1.3.1-alpha` y `2`.

Para calcular `programVK` localmente, la compilación necesita las claves de prueba de ZisK correspondientes y unos 36 GB de RAM. Esa etapa tarda unos 40 segundos. Si omites esa etapa o no tienes las claves, la compilación informa `ProgramVkNotComputed`. El probador rechaza metadatos sin `programVK`; calcúlalo con las claves correspondientes o pídeselo a Rome antes de empezar a demostrar.

Dos máquinas que construyan el mismo genesis con esas etiquetas obtienen el mismo hash ELF. Un genesis cambiado implica un guest diferente, y el genesis no puede cambiarse después del registro de la cadena. La compilación rechaza un genesis cuyo ID de cadena difiere del ID de tu cadena (`ChainIdMismatch`) y un genesis que da saldo a más de una cuenta (`GenesisFundedAccountLimit`).

## Pídele a Rome que lo registre

Usa el [formulario de solicitud de clave de verificación](https://github.com/rome-protocol/solana-zk-evm/issues/new?template=vkey-request.yml). Ten listos tu ID de cadena, la clave pública de la autoridad de la cadena y la firma de la transacción que registró la cadena. Incluye la etiqueta del guest y los metadatos generados: hash ELF, hash del genesis, `programVK`, `zisk` y `esquema`. Adjunta o pega el genesis renderizado. Si el genesis declara un saldo respaldado, ten listo el vault financiado correspondiente. Incluye un `./rollup check` resultado que pasa excepto por los elementos que esperan la clave.

Rome reconstruye el guest a partir de la etiqueta y el genesis. Comprueba el ID de cadena, el genesis, el hash ELF y `programVK` frente a tu solicitud, y luego registra la clave bajo la versión de ZisK correspondiente. Rome responde en la incidencia con la firma de la transacción de registro de la clave. La clave se vuelve utilizable en su slot de activación registrado; ejecuta `./rollup check` después de ese slot. Con el probador activado, la `clave de verificación` comprobación debería pasar. La comprobación de la clave que admite depósitos también debería pasar.

Rome registra un **requerimiento completo en un plazo de dos días hábiles**. Si una solicitud está incompleta, Rome responde con lo que falta. Los dos días hábiles comienzan cuando la solicitud está completa.

La sincronización importa porque la ventana de reclamación comienza cuando registras la cadena, no cuando su clave se vuelve activa. La ventana de la devnet v0.3.0 es de 6.480.000 slots, unos 30 días. Si no se publica una raíz cuando termina esa ventana, cualquiera puede reclamar la cadena y su depósito de 5 SOL va al tesoro. La autoridad del registro de Rome puede cambiar la ventana global, sujeta a un mínimo de 216.000 slots.

Después de la activación, dale al probador el guest correspondiente, los metadatos y las claves de prueba de ZisK, activa `PROVER=on`, luego ejecute `./rollup init`, `./rollup up` y `./rollup check`. La prueba debe usar una clave activa registrada para esta cadena. Cambiar más adelante a una versión distinta de ZisK requiere otra compilación del guest y otra entrada registrada; consulta [Versiones](/es/rome-zk-evm/releases.md).

Los campos completos de la solicitud y los pasos del operador están en [Ejecuta en devnet con v0.3.0](https://github.com/rome-protocol/solana-zk-evm/blob/v0.3.0/docs/RUN-ON-DEVNET.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/verification-key.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.