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

# Как это работает

Проследите один блок Ostia от reth через доказательство до фиксации в Canton.

Каждый запуск сборщика формирует, доказывает и отправляет один блок. Canton решает, станет ли этот блок следующей головой цепочки. Блок EVM и зафиксированные в нём операции Canton подтверждаются в одной транзакции.

Эта страница описывает коммит `a84e84e439a5cc669c0ae61facf7c8c995d9d564`. Прочтите полный [проектирование](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/docs/DESIGN.md).

```mermaid
flowchart TD
    W["Транзакции EVM"] --> R["reth строит по требованию"]
    R --> B["Сборщик считывает операции шлюза и находит соответствующие им Canton-контракты"]
    B -->|"Одна операция не может быть урегулирована: исключите её транзакцию и пересоберите"| R
    B -->|"Каждая операция может быть урегулирована"| P["ZisK доказывает блок"]
    P --> A["Advance: блок, доказательство и операции в одной транзакции Canton"]
    A --> S["Внешний вызов: сайдкары проверяют доказательство и состояние шлюза"]
    S --> D["Daml проверяет голову и урегулирует операции"]
    D --> C["Canton фиксирует блок и его операции вместе"]
    C --> F["reth помечает блок как финальный"]
```

## Сборка на голове Canton

Кошельки отправляют транзакции EVM в reth. Поставляемый запускатель отключает обнаружение узлов. reth формирует блок, когда сборщик запрашивает его.

Сборщик сначала считывает активный `ZkChain` контракт в Canton. Он переносит голову reth, безопасный блок и финализированный блок к этой зафиксированной голове. Он выбирает ожидающие транзакции по цене, сохраняя порядок nonce каждого отправителя и не выходя за пределы лимита газа. Он просит reth собрать блок с этим явным списком транзакций.

Транзакция EVM, требующая действия в Canton, вызывает шлюз. Шлюз записывает операцию и включает её в накапливаемый хэш блока. Сборщик читает события шлюза в порядке журнала и находит Canton-контракты, необходимые для каждой операции.

Если распределение отсутствует, получатель не принял выводы средств или отсутствует другой необходимый контракт, сборщик исключает транзакцию и все последующие транзакции этого отправителя. Он возвращает reth к голове Canton и собирает заново. Эти проверки выполняются до доказательства. The [README сборщика](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/builder/README.md) перечисляет проверки для каждой операции.

## Докажите блок

Сборщик сохраняет блок и свидетель исполнения reth. Инструмент ввода объединяет блок, свидетель и genesis во входные данные для доказчика. ZisK запускает гостевой код, который проверяет блок в соответствии с фиксированными правилами цепочки.

Доказчик возвращает обёрнутое доказательство размером 1 344 байта, которое фиксируется на хеше блока. Сборщик отправляет `Аванс` его вместе с заголовком, транзакциями, доказательством, операциями и доказательствами аккаунта и хранилища шлюза на корне состояния блока.

## Проверка и урегулирование в одной транзакции

Каждый подтверждающий участник запускает сайдкар. Внешний вызов Canton отправляет блок в сайдкар этого участника для `проверить`проверки. Он проверяет доказательство, закреплённый ключ программы и версию ZisK, хеш заголовка и корень списка транзакций.

Daml сверяет ответ с `ZkChain`: родитель должен быть текущей головой, номер — следующим, а лимит газа и использованный газ должны укладываться в предел. Daml сравнивает ответы сайдкара; само доказательство с нулевым разглашением оно не проверяет.

Затем Daml записывает строку для каждой операции из названных им Canton-контрактов. Идентификатор, burner и сумма вывода поступают от сборщика; подтверждённый хеш связывает их с тем, что записал блок. Сайдкара `части` функция проверяет доказательства аккаунта и хранилища шлюза, хеширует эти строки по порядку и сравнивает результат со значением шлюза в подтверждённом состоянии. Блок без операций должен пройти ту же проверку с пустым списком.

Daml урегулирует операции по порядку и создаёт `BlockRecord` и следующий `ZkChain`. Canton фиксирует эти изменения вместе. Если проверка или урегулирование не удаются, ничего не фиксируется. Потребление единственного контракта состояния цепочки делает Canton авторитетом в вопросе порядка блоков. См. полный [интерфейс Daml](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/daml/README.md) и [проверки сайдкара](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/sidecar/README.md).

## Когда Canton отклоняет

После того как Canton фиксирует блок, сборщик помечает его как финальный в reth. Если Canton его отклоняет, сборщик возвращает reth к последнему зафиксированному блоку Canton и отправляет транзакции отклонённого блока обратно в пул. Следующий запуск снова проверяет их операции. Платёж, чьё распределение было отозвано, исключается.

Если сборщик теряет ответ на отправку, он снова читает голову Canton, чтобы определить, был ли блок зафиксирован. Если и это чтение не удаётся, он сообщает о неизвестном результате и оставляет reth без изменений. Следующий запуск начинается с головы Canton. Эти правила восстановления описаны в [README сборщика](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/ru/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.