> 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/canton-zk-evm/how-it-works.md).

# Cómo funciona

Sigue un bloque de Ostia desde reth, pasando por la prueba, hasta su confirmación en Canton.

Cada ejecución del builder crea, demuestra y envía un bloque. Canton decide si ese bloque se convierte en la siguiente cabeza de la cadena. Un bloque EVM y los tramos de Canton que registró se confirman en la misma transacción.

Esta página describe commit `a84e84e439a5cc669c0ae61facf7c8c995d9d564`. Lea el texto completo [diseño](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/docs/DESIGN.md).

```mermaid
flowchart TD
    W["Transacciones EVM"] --> R["reth construye bajo demanda"]
    R --> B["El builder lee los tramos del gateway y encuentra sus contratos de Canton"]
    B -->|"Un tramo no puede liquidarse: deja su transacción fuera y reconstruye"| R
    B -->|"Cada tramo puede liquidarse"| P["ZisK demuestra el bloque"]
    P --> A["Avanzar: bloque, prueba y tramos en una transacción de Canton"]
    A --> S["Llamada externa: los sidecars comprueban la prueba y el estado del gateway"]
    S --> D["Daml comprueba la cabeza y liquida los tramos"]
    D --> C["Canton confirma el bloque y sus tramos juntos"]
    C --> F["reth marca el bloque como final"]
```

## Construye sobre la cabeza de Canton

Las carteras envían transacciones EVM a reth. El lanzador suministrado mantiene desactivado el descubrimiento de pares. reth crea un bloque cuando el builder pide uno.

El builder primero lee el activo `ZkChain` contrato en Canton. Mueve la cabeza de reth, el bloque seguro y el bloque finalizado a esa cabeza confirmada. Elige las transacciones pendientes por precio, manteniendo el orden de nonce de cada remitente y sin superar el límite de gas. Pide a reth que construya con esa lista explícita de transacciones.

Una transacción EVM que requiere una acción de Canton llama al gateway. El gateway registra un tramo y lo incorpora en un hash acumulado para el bloque. El builder lee los eventos del gateway en orden de registro y encuentra los contratos de Canton necesarios para cada tramo.

Si una asignación ya no existe, un receptor no ha aceptado los retiros, o falta otro contrato requerido, el builder omite la transacción y las transacciones posteriores de ese remitente. Devuelve reth a la cabeza de Canton y vuelve a construir. Estas comprobaciones ocurren antes de demostrar. El [README del builder](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/builder/README.md) enumera las comprobaciones para cada tramo.

## Demuestra el bloque

El builder guarda el bloque y el testigo de ejecución de reth. La herramienta de entrada combina el bloque, el testigo y el genesis en la entrada del demostrador. ZisK ejecuta el guest, que valida el bloque bajo las reglas fijas de la cadena.

El demostrador devuelve una prueba envuelta de 1.344 bytes que se compromete con el hash del bloque. El builder envía `Avanzar` con el encabezado, las transacciones, la prueba, los tramos y las pruebas de cuenta y almacenamiento del gateway en la raíz de estado del bloque.

## Comprobar y liquidar en una sola transacción

Cada participante confirmante ejecuta un sidecar. La llamada externa de Canton envía el bloque al sidecar de ese participante para `verificar`. Comprueba la prueba, la clave de programa fijada y la versión de ZisK, el hash del encabezado y la raíz de la lista de transacciones.

Daml compara la respuesta contra `ZkChain`: el padre debe ser la cabeza actual, el número debe ser el siguiente, y el límite de gas y el gas usado deben ajustarse al tope. Daml compara las respuestas del sidecar; no verifica la prueba de conocimiento cero en sí misma.

Luego Daml escribe una línea por cada tramo de los contratos de Canton que nombra. El id, el quemador y el importe de un retiro provienen del builder; el hash demostrado los vincula con lo que registró el bloque. La `tramos` función comprueba las pruebas de cuenta y almacenamiento del gateway, hashea esas líneas en orden y compara el resultado con el valor del gateway en el estado probado. Un bloque sin tramos debe pasar la misma comprobación con una lista vacía.

Daml liquida los tramos en orden y crea el `Registro de bloque` y el siguiente `ZkChain`. Canton confirma estos cambios juntos. Si una comprobación o liquidación falla, no se confirma nada. Consumir el único contrato de estado de la cadena convierte a Canton en la autoridad sobre el orden de los bloques. Vea el [interfaz Daml](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/daml/README.md) y [comprobaciones del sidecar](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/sidecar/README.md).

## Cuando Canton rechaza

Después de que Canton confirma el bloque, el builder lo marca como final en reth. Si Canton lo rechaza, el builder devuelve reth al último bloque confirmado de Canton y envía las transacciones del bloque rechazado de vuelta al pool. La siguiente ejecución vuelve a comprobar sus tramos. Se deja fuera un pago cuya asignación fue retirada.

Si el builder pierde la respuesta del envío, lee de nuevo la cabeza de Canton para determinar si el bloque se confirmó. Si esa lectura también falla, informa de un resultado desconocido y deja reth donde está. La siguiente ejecución comienza desde la cabeza de Canton. Estas reglas de recuperación están en el [README del builder](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/builder/README.md#what-one-run-does).


---

# 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/canton-zk-evm/how-it-works.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.