> 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/releases.md). # Versiones Qué añade v0.3.0 y cómo una cadena pasa entre las versiones de prueba ZisK compatibles. Esta sección documenta **Rome ZK EVM v0.3.0**. Usa la fuente v0.3.0, la imagen del nodo y el guest por lotes correspondientes. El guest usa ZisK 1.3.1-alpha. La etiqueta de la versión nombra el árbol de código fuente usado para la imagen. La `principal` rama puede haber cambiado desde la versión. La [registro completo de cambios de v0.3.0](https://github.com/rome-protocol/solana-zk-evm/blob/v0.3.0/CHANGELOG.md#v030) recoge los comandos, las correcciones y los límites detrás de la versión. La [política de versiones de ZisK](https://github.com/rome-protocol/solana-zk-evm/blob/v0.3.0/docs/ZISK-RELEASES.md) describe el registro en cadena y el proceso de migración. ## En v0.3.0 las cadenas de devnet ahora pueden recibir depósitos y pagar retiros desde sus propias bóvedas de SOL envuelto. La autoridad de la cadena puede abrir una cola de depósitos, establecer sus límites y comisiones, y cambiarlos después de una activación diferida. El secuenciador acredita los depósitos de Solana finalizados en bloques EVM; el batcher confirma su rango ordenado en el lote de la bandeja de entrada. La imagen del nodo incluye un generador de pruebas de salida. Con `EXITS=on`, vigila el portal de salidas de la cadena, demuestra los retiros contra las raíces finales de Solana y envía él mismo la liberación de la bóveda. Usa su propio pagador. De forma predeterminada, un pequeño pago a un destinatario sin una cuenta de token de SOL envuelto espera una liberación manual. `./rollup check` informa la configuración de salida, el estado del servicio, las salidas atascadas y el saldo del pagador de salidas. Las pruebas usan ZisK 1.3.1-alpha. Settlement y Veritas ahora mantienen una clave de verificación y una raíz de recursión fijada por cada versión de ZisK. La configuración del host del generador de pruebas descarga y comprueba los archivos de claves de esta versión, verifica los binarios de GPU y prepara los archivos de constantes usados por la agregación. La versión también añade los formularios de solicitud de clave de verificación y de informe de errores. La guía de devnet enlaza las transacciones del explorador desde la propia ejecución de Rome, desde el registro hasta el pago. Esta versión todavía deja abiertos los antiguos lotes de la bandeja de entrada y las cuentas de fragmentos. Las cuentas de raíz pendiente permanecen abiertas por defecto; su renta se acumula. Rome aún no ha decidido cuánto tiempo deben permanecer en Solana los datos antiguos de los lotes. ## Las versiones de ZisK pertenecen a la clave de cada cadena Cada cadena tiene un registro de claves de verificación. Una entrada contiene `programVK`, una disposición de valores públicos, un slot de activación y un número de esquema. Ese número nombra la versión de ZisK usada para construir el guest y la clave; la prueba no elige su versión. El registro tiene cuatro slots de entrada. | Esquema | Versión de ZisK | Estado de v0.3.0 | | ------- | --------------- | ---------------------------------------------- | | `1` | `1.2.0-alpha` | Retirada; sus pruebas son rechazadas. | | `2` | `1.3.1-alpha` | Abierta; se aceptan nuevas entradas y pruebas. | Settlement busca la entrada activa que coincida con la `programVK`. La entrada selecciona la clave de Veritas y la raíz de recursión fijada de esa versión. Una prueba con la raíz incorrecta se rechaza antes de las comprobaciones de valores públicos y emparejamiento. Una versión retirada no tiene clave de verificación en la compilación de producción. ## Migrar una cadena a una nueva versión Instala la nueva cadena de herramientas de ZisK y las claves de prueba, manteniendo disponible la instalación anterior. Establece juntos la etiqueta de origen del rollup, la etiqueta del guest y la versión de ZisK, y luego ejecuta `./rollup guest-build` para compilar un nuevo guest y `programVK` para el mismo génesis. El generador de pruebas necesita la instalación de ZisK, el guest y los metadatos de verificación correspondientes. Envía a Rome el génesis de la cadena, la etiqueta del guest, el hash ELF y `programVK`. Rome recompila y verifica el guest y registra la nueva clave con un slot de activación futuro. Si la cadena ha publicado una raíz, Rome también necesita el guest y la versión anteriores. Comprueba la nueva entrada en cadena y el slot de activación, y luego cambia el generador de pruebas cuando llegue ese slot. Rome retira la entrada antigua después del cambio. Una entrada futura no puede verificarse antes de tiempo. La política de soporte de Rome mantiene abiertas como máximo dos versiones de ZisK a la vez. Una versión en cierre no acepta nuevas entradas, pero las entradas existentes aún pueden verificarse mientras las cadenas migran. Cuando Rome anuncia que una versión se está cerrando, las cadenas de devnet y testnet tienen 30 días para migrar. Esa ventana forma parte de la política de soporte de Rome, no de un temporizador en cadena. Rome puede retirar entradas de inmediato por una retirada de seguridad. Una versión retirada no acepta ni nuevas entradas ni pruebas, por lo que una cadena que siga en 1.2.0-alpha necesita una entrada activa de 1.3.1-alpha antes de poder publicar otra raíz. --- # 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/releases.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.