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

# Como funciona

Acompanhe um bloco do Ostia desde o reth, passando pela prova, até seu commit no Canton.

Cada execução do builder gera, prova e submete um bloco. O Canton decide se esse bloco se torna a próxima cabeça da cadeia. Um bloco EVM e as pernas do Canton que ele registrou são confirmados na mesma transação.

Esta página descreve o commit `a84e84e439a5cc669c0ae61facf7c8c995d9d564`. Leia o completo [design](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/docs/DESIGN.md).

```mermaid
flowchart TD
    W["Transações EVM"] --> R["reth constrói sob demanda"]
    R --> B["O builder lê as pernas do gateway e encontra os contratos Canton delas"]
    B -->|"Uma perna não pode ser liquidada: deixe sua transação de fora e reconstrua"| R
    B -->|"Toda perna pode ser liquidada"| P["ZisK prova o bloco"]
    P --> A["Avançar: bloco, prova e pernas em uma única transação Canton"]
    A --> S["Chamada externa: sidecars verificam a prova e o estado do gateway"]
    S --> D["Daml verifica a cabeça e liquida as pernas"]
    D --> C["Canton confirma o bloco e suas pernas juntos"]
    C --> F["reth marca o bloco como final"]
```

## Construa sobre a cabeça do Canton

As carteiras enviam transações EVM para o reth. O iniciador fornecido mantém a descoberta de peers desativada. O reth cria um bloco quando o builder pede um.

O builder primeiro lê o `ZkChain` contrato ativo no Canton. Ele move a cabeça, o bloco seguro e o bloco finalizado do reth para essa cabeça confirmada. Ele escolhe as transações pendentes por preço, mantendo a ordem do nonce de cada remetente e ficando dentro do limite de gás. Ele pede ao reth para construir com essa lista explícita de transações.

Uma transação EVM que exige uma ação Canton chama o gateway. O gateway registra uma perna e a incorpora a um hash em andamento para o bloco. O builder lê os eventos do gateway em ordem de log e encontra os contratos Canton necessários para cada perna.

Se uma alocação tiver desaparecido, se um receptor não tiver aceitado retiradas ou se outro contrato necessário estiver faltando, o builder omite a transação e as transações posteriores daquele remetente. Ele retorna o reth para a cabeça do Canton e constrói novamente. Essas verificações acontecem antes da prova. O [README do construtor](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/builder/README.md) lista as verificações para cada perna.

## Provar o bloco

O builder salva o bloco e a testemunha de execução do reth. A ferramenta de entrada combina o bloco, a testemunha e o genesis na entrada do provador. O ZisK executa o guest, que valida o bloco sob as regras fixas da cadeia.

O provador retorna uma prova encapsulada de 1.344 bytes que se compromete com o hash do bloco. O builder submete `Avançar` com o cabeçalho, as transações, a prova, as pernas e as provas de conta e armazenamento do gateway na raiz de estado do bloco.

## Verificar e liquidar em uma única transação

Cada participante que confirma executa um sidecar. A chamada externa do Canton envia o bloco para o sidecar desse participante para `verificar`. Ele verifica a prova, a chave do programa fixada e a versão do ZisK, o hash do cabeçalho e a raiz da lista de transações.

Daml verifica a resposta contra `ZkChain`: o pai deve ser a cabeça atual, o número deve ser o próximo, e o limite de gás e o gás usado devem caber no teto. O Daml compara as respostas do sidecar; ele não verifica a própria prova de conhecimento zero.

O Daml então escreve uma linha para cada perna dos contratos Canton que ele nomeia. O id, o burner e o valor de uma retirada vêm do builder; o hash provado os vincula ao que o bloco registrou. A `pernas` função do sidecar verifica as provas de conta e armazenamento do gateway, faz hash dessas linhas em ordem e compara o resultado com o valor do gateway no estado provado. Um bloco sem pernas deve passar na mesma verificação com uma lista vazia.

O Daml liquida as pernas em ordem e cria o `BlockRecord` e o próximo `ZkChain`. O Canton confirma essas mudanças em conjunto. Se uma verificação ou liquidação falhar, nada é confirmado. Consumir o único contrato de estado da cadeia faz do Canton a autoridade sobre a ordem dos blocos. Veja as [interface Daml](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/daml/README.md) e [verificações do sidecar](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/sidecar/README.md).

## Quando o Canton recusa

Depois que o Canton confirma o bloco, o builder o marca como final no reth. Se o Canton o recusar, o builder retorna o reth ao último bloco confirmado do Canton e envia as transações do bloco recusado de volta para o pool. A próxima execução verifica novamente suas pernas. Um pagamento cuja alocação foi retomada é omitido.

Se o builder perder a resposta da submissão, ele lê a cabeça do Canton novamente para determinar se o bloco foi confirmado. Se essa leitura também falhar, ele informa um resultado desconhecido e deixa o reth onde está. A próxima execução começa a partir da cabeça do Canton. Essas regras de recuperação estão no [README do construtor](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/pt-br/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.