> 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/verification-key.md).

# Ключ верификации

Соберите пакетный гостевой артефакт, специфичный для цепочки, и запросите регистрацию его ключа верификации ZisK.

У каждой цепочки есть свой batch-гость. Гость содержит genesis цепочки и получателя комиссии. Он проверяет данные batch и выполнение, затем фиксирует публичные значения, которые проверяет settlement Solana. У гостя `programVK` идентифицирует программу, для которой выполняется доказательство.

Цепочка без разрешений регистрируется с пустым реестром ключей верификации. Она не может опубликовать итоговый корень, пока Rome не добавит ключ для этой цепочки. Владелец цепочки не может включить ключ в свою транзакцию регистрации. Это процесс v0.3.0 в Solana devnet.

## Соберите гостевую программу

Из `deploy/rollup` в checkout версии v0.3.0 используйте настройки релиза `ROME_ZK_TAG=v0.3.0`, `ROME_ZK_GUEST_TAG=v0.3.0` и `ZISK_RELEASE=1.3.1-alpha`. Выполните `./rollup init` сначала, чтобы были сформированы genesis и идентификатор цепочки. Цепочка должна быть зарегистрирована до отправки запроса. Затем выполните:

```sh
./rollup guest-build
```

Команда собирает образ с toolchain ZisK, клонирует исходники rollup и guest по этим тегам, собирает guest на основе вашего genesis и проверяет, что он содержит идентификатор вашей цепочки. Она выводит SHA-256 ELF-файла guest. Сгенерированные метаданные фиксируют этот хэш, хэш genesis, идентификатор цепочки, релиз ZisK и номер его схемы. Для этого релиза последние два значения — `1.3.1-alpha` и `2`.

Чтобы вычислить `programVK` локально, при сборке требуются соответствующие ключи доказательства ZisK и около 36 ГБ ОЗУ. Этот этап занимает примерно 40 секунд. Если вы пропустите этот этап или у вас нет ключей, сборка сообщает `ProgramVkNotComputed`. Доказыватель отвергает метаданные без `programVK`; вычислите его с соответствующими ключами или запросите его у Rome до начала доказательства.

Две машины, собирающие один и тот же genesis с этими тегами, получают одинаковый хэш ELF. Изменённый genesis означает другой guest, а genesis нельзя изменить после регистрации цепочки. Сборка отклоняет genesis, чей идентификатор цепочки отличается от идентификатора вашей цепочки (`ChainIdMismatch`) и genesis, который даёт баланс более чем одному аккаунту (`GenesisFundedAccountLimit`).

## Попросите Rome зарегистрировать его

Используйте [форму запроса ключа верификации](https://github.com/rome-protocol/solana-zk-evm/issues/new?template=vkey-request.yml). Подготовьте идентификатор вашей цепочки, открытый ключ владельца цепочки и подпись транзакции, зарегистрировавшей цепочку. Укажите тег guest и сгенерированные метаданные: хэш ELF, хэш genesis, `programVK`, `zisk` и `схема`. Приложите или вставьте сформированный genesis. Если genesis объявляет обеспеченный баланс, подготовьте соответствующее пополненное хранилище. Включите `./rollup check` результат, который проходит, за исключением элементов, ожидающих ключ.

Rome пересобирает guest по тегу и genesis. Он проверяет идентификатор цепочки, genesis, хэш ELF и `programVK` с вашим запросом, затем регистрирует ключ под соответствующим релизом ZisK. Rome отвечает в issue подписью транзакции регистрации ключа. Ключ становится доступным для использования в записанном слоте активации; выполните `./rollup check` после этого слота. При включённом доказывателе `ключ верификации` проверка должна пройти. Проверка ключа, допускающего депозит, тоже должна пройти.

Rome регистрирует **полный запрос в течение двух рабочих дней**. Если запрос неполный, Rome отвечает, чего не хватает. Отсчёт двух рабочих дней начинается, когда запрос становится полным.

Сроки имеют значение, поскольку окно возврата начинается, когда вы регистрируете цепочку, а не когда её ключ становится активным. Окно v0.3.0 для devnet составляет 6 480 000 слотов, примерно 30 дней. Если по окончании этого окна корень не опубликован, любое лицо может инициировать возврат цепочки, а её депозит в 5 SOL поступит в казну. Административный орган реестра Rome может изменить глобальное окно при минимуме в 216 000 слотов.

После активации передайте доказывателю соответствующий guest, метаданные и ключи доказательства ZisK, включите `PROVER=on`, затем выполните `./rollup init`, `./rollup up` и `./rollup check`. Доказательство должно использовать активный ключ, зарегистрированный для этой цепочки. Переход позже на другой релиз ZisK требует новой сборки guest и новой зарегистрированной записи; см. [Релизы](/ru/rome-zk-evm/releases.md).

Полные поля запроса и действия оператора приведены в [Запуск в devnet на версии v0.3.0](https://github.com/rome-protocol/solana-zk-evm/blob/v0.3.0/docs/RUN-ON-DEVNET.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/verification-key.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.