> 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/how-it-works.md). # Cómo funciona Sigue un bloque EVM a través de la publicación de datos en Solana, la prueba con ZisK y la liquidación final. Tu secuenciador acepta transacciones EVM a través de JSON-RPC. Verifica la firma, el nonce, los fondos y el gas, y luego ejecuta las transacciones aceptadas en orden de llegada. Escribe subbloques firmados y sus transacciones en un registro ordenado y durable antes de devolver una preconfirmación. El secuenciador integra reth para producir los bloques de la cadena. Una preconfirmación te dice qué aceptó y ordenó el secuenciador. No es una raíz final de Solana. El resto del recorrido publica los datos y demuestra que ejecutarlos produce el estado reclamado. ``` Transacción EVM -> secuenciador -> registro ordenado -> agrupador -> bandeja de entrada de Solana Bandeja de entrada de Solana -> derivar -> reth-verifier -> bloques + testigos bloques + testigos -> demostrador (guest por lotes de ZisK) -> prueba + raíz prueba + raíz -> liquidación en Solana (PostRootProved) -> raíz final ``` ## De los bloques a un lote de la bandeja de entrada El agrupador lee bloques consecutivos del registro ordenado. El ejemplo `chain.toml` cierra un lote a los 60 bloques, o 60 segundos después de su primer bloque, lo que ocurra primero. Comprime el lote en marcos, publica los marcos como fragmentos de inbox en Solana y luego finaliza el compromiso de Merkle del lote. El compromiso de inbox cubre la cadena y los IDs de lote, el slot de apertura, el recuento de fragmentos, la raíz de Merkle de los fragmentos y el rango de depósitos del lote. Finalizar un lote de inbox significa que sus datos han sido publicados. No hace final su raíz de estado. La autoridad de la cadena firma la finalización del lote. El agrupador no puede saltarse un número de bloque. La liquidación también toma el siguiente lote en orden. Por eso un lote atascado o abandonado bloquea raíces posteriores. El agrupador reanuda un lote parcialmente escrito bajo el mismo número después de un reinicio cuando puede reconstruirlo. ## Derivar, verificar y demostrar `derivar` lee lotes de inbox finalizados desde Solana. Reconstruye los bloques y activa un `verificador de reth` separado para ejecutarlos de nuevo. Este nodo sirve los testigos de ejecución que necesita el demostrador del lote y las pruebas de estado que necesita el demostrador de salidas. Ejecuta la API de pruebas de reth, así que debe permanecer fuera de la red pública. El demostrador lee cada lote de inbox finalizado, obtiene bloques y testigos del nodo verificador y ejecuta el guest por lotes de la cadena en ZisK. El guest verifica que los bloques coincidan con los datos del inbox y se ejecuten correctamente. Registra los valores públicos del lote, incluida la raíz de estado resultante. Tu génesis y el receptor de comisiones se compilan en este guest, así que cada cadena tiene su propio guest y `programVK`. El demostrador verifica la prueba localmente y luego envía `PostRootProved`. El programa de liquidación comprueba la clave de verificación activa registrada para esta cadena y la versión de ZisK nombrada por esa clave. También comprueba los valores públicos de la prueba frente al ID de la cadena, el rango de bloques, el predecesor, el compromiso del inbox y la raíz reclamada. Veritas es el verificador de Rome para pruebas PLONK de ZisK. La liquidación enlaza su código verificador y lo ejecuta dentro `PostRootProved`; no llama al programa Veritas desplegado por separado. Una prueba válida escribe una `Final` raíz y avanza la cabeza de finalización en la misma transacción de Solana. La raíz génesis de una cadena sin permisos no es final por sí sola. Su primera raíz final necesita un lote probado. ## Fondos que cruzan la frontera Un depósito comienza en Solana. El programa puente mueve el token depositado del depositante al vault de esa cadena y añade un registro de depósito numerado. El secuenciador lee depósitos de Solana finalizados y acredita la dirección EVM nombrada en orden. El agrupador compromete el rango de depósitos con el lote. El saldo aparece en la cadena cuando se cierra su bloque, pero su acreditación solo es final cuando la raíz de ese lote se demuestra en Solana. Un retiro comienza en la cadena en su portal de salida. El portal registra un mensaje y quema el activo nativo. El demostrador de salidas observa ese mensaje y obtiene una prueba de almacenamiento de Ethereum del nodo verificador contra una raíz final. Comprueba esa prueba localmente y luego envía `ProveExit` a la liquidación de Solana. La liquidación comprueba el portal, el mensaje, la raíz final y el tope de salida, y evita que la misma salida se demuestre dos veces. Luego el demostrador de salidas envía la transacción de liberación del puente. El puente consume la salida probada y paga al destinatario desde la bóveda de esa cadena en una sola transacción atómica. El destinatario proviene del registro probado, por lo que la persona que envía la liberación no puede cambiarlo. Lee la completa [arquitectura v0.3.0](https://github.com/rome-protocol/solana-zk-evm/blob/v0.3.0/docs/ARCHITECTURE.md) para los formatos de cable, los límites entre componentes y las comprobaciones de cada instrucción. --- # 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/how-it-works.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.