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

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

Проследите EVM-блок через размещение данных в Solana, доказывание ZisK и окончательное завершение.

Ваш секвенсер принимает EVM-транзакции через JSON-RPC. Он проверяет подпись, nonce, средства и газ, а затем выполняет принятые транзакции в порядке поступления. Перед выдачей предварительного подтверждения он записывает подписанные субблоки и их транзакции в устойчивый упорядоченный журнал. Секвенсер встраивает reth для формирования блоков цепочки.

Предварительное подтверждение сообщает, что секвенсер принял и упорядочил. Это не финальный корень Solana. Остальная часть пути публикует данные и доказывает, что их выполнение дает заявленное состояние.

```
EVM-транзакция -> секвенсер -> упорядоченный журнал -> батчер -> Solana inbox
Solana inbox -> derive -> reth-verifier -> блоки + свидетельства
блоки + свидетельства -> доказыватель (гостевой модуль пакета ZisK) -> доказательство + корень
доказательство + корень -> урегулирование в Solana (PostRootProved) -> финальный корень
```

## От блоков к пакету inbox

Батчер читает последовательные блоки из упорядоченного журнала. В примере `chain.toml` пакет закрывается на 60 блоках или через 60 секунд после первого блока — в зависимости от того, что наступит раньше. Он сжимает пакет в фреймы, публикует фреймы как inbox-чанки в Solana, затем финализирует мерклово обязательство пакета.

Обязательство inbox охватывает идентификаторы цепочки и пакета, начальный слот, число чанков, корень Меркла чанков и диапазон депозитов пакета. Финализация пакета inbox означает, что его данные были опубликованы. Она не делает финальным корень его состояния. Оператор цепочки подписывает финализацию пакета.

Батчер не может пропустить номер блока. Урегулирование также берет следующий пакет по порядку. Поэтому зависший или брошенный пакет блокирует последующие корни. После перезапуска батчер возобновляет частично записанный пакет под тем же номером, когда может его восстановить.

## Вывод, проверка и доказательство

`вывод` читает финализированные пакеты inbox из Solana. Он восстанавливает блоки и запускает отдельный `reth-verifier` узел для повторного выполнения их. Этот узел предоставляет свидетельства выполнения, необходимые доказывателю пакета, и доказательства состояния, необходимые доказывателю выхода. Он использует тестовый API reth, поэтому должен быть изолирован от публичной сети.

Доказыватель читает каждый финализированный пакет inbox, получает блоки и свидетельства от узла-верификатора и запускает в ZisK гостевой модуль пакета этой цепочки. Гостевой модуль проверяет, что блоки соответствуют данным inbox и выполняются корректно. Он фиксирует публичные значения пакета, включая полученный корень состояния. Ваши genesis и получатель комиссий скомпилированы в этот гостевой модуль, поэтому у каждой цепочки есть свой гостевой модуль и `programVK`.

Доказыватель локально проверяет доказательство, затем отправляет `PostRootProved`. Программа урегулирования проверяет активный ключ верификации, зарегистрированный для этой цепочки, и релиз ZisK, указанный этим ключом. Она также сверяет публичные значения доказательства с идентификатором цепочки, диапазоном блоков, предшественником, обязательством inbox и заявленным корнем.

Veritas — это верификатор Rome для доказательств ZisK PLONK. Урегулирование связывает его код верификации и запускает его внутри `PostRootProved`; оно не вызывает отдельно развернутую программу Veritas. Корректное доказательство записывает `Финальный` корень и сдвигает голову финальности в той же транзакции Solana. Корень genesis цепочки без разрешений сам по себе не является финальным. Для его первого финального корня нужен доказанный пакет.

## Средства, пересекающие границу

Депозит начинается в Solana. Программа моста перемещает внесенный токен от депозитора в хранилище этой цепочки и добавляет пронумерованную запись о депозите. Секвенсер читает финализированные депозиты Solana и по порядку зачисляет указанный EVM-адрес. Батчер включает диапазон депозитов в пакет. Баланс появляется в цепочке, когда ее блок фиксируется, но его зачисление окончательно только тогда, когда корень этого пакета доказан в Solana.

Вывод начинается в цепочке в ее exit portal. Портал записывает сообщение и сжигает нативный актив. Доказатель выхода отслеживает это сообщение и получает от узла-верификатора доказательство хранилища Ethereum относительно финального корня. Он локально проверяет это доказательство, затем отправляет `ДокажиВыход` в урегулирование Solana.

Урегулирование проверяет портал, сообщение, финальный корень и лимит выхода и не позволяет доказать один и тот же выход дважды. Затем доказатель выхода отправляет транзакцию выпуска моста. Мост потребляет доказанный выход и выплачивает получателю средства из хранилища этой цепочки в одной атомарной транзакции. Получатель берется из доказанной записи, поэтому отправитель транзакции выпуска не может его изменить.

Ознакомьтесь с полной [архитектурой v0.3.0](https://github.com/rome-protocol/solana-zk-evm/blob/v0.3.0/docs/ARCHITECTURE.md) чтобы узнать форматы передачи, границы компонентов и проверки каждой инструкции.


---

# 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/rome-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.