> 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/run-a-rollup.md).

# Запустить rollup

Зарегистрируйте и запустите собственную цепочку Rome ZK EVM в devnet Solana с помощью исполнителя rollup v0.3.0.

Названия `./rollup` runner запускает одну цепочку поверх общих программ Solana devnet Rome. Вы запускаете ее узел и оплачиваете расходы Solana. Вы сами не разворачиваете программы расчетов. Регистрация не требует разрешений, но для подтвержденных корней нужен ключ верификации, специфичный для цепочки, зарегистрированный Rome.

Эта страница использует **v0.3.0**.  [полное руководство по devnet](https://github.com/rome-protocol/solana-zk-evm/blob/v0.3.0/docs/RUN-ON-DEVNET.md) охватывает все настройки, а также шаги при сбоях и восстановлении.

## Перед началом

Используйте машину Linux x86-64 с bash 4 или новее, Git, Docker Engine 28 или новее с Compose, curl, jq, openssl, Solana CLI и Python 3.11 или новее. Вам нужен RPC-эндпоинт Solana devnet, пополненная пара ключей payer Solana, которая также является полномочием вашей цепочки, и ключ подписи sequencer. Храните оба файла в секрете и обеспечьте их чтение пользователем контейнера 999. В руководстве объясняется, как их создать.

Заложите около **7 SOL в devnet** для payer. Регистрация блокирует 5 SOL; `./rollup check` ожидает, что останется как минимум 1 SOL на размещение данных и аренду. Депозит становится возвратным после первого финального корня или десяти опубликованных корней. Если цепочка будет изъята до этого, депозит поступит в казну. Цепочке также нужен адрес получателя комиссии EVM, которым вы управляете.

Для финализации корней вам нужен хост prover с одной NVIDIA GPU и более чем 30 ГБ памяти. Карты с 24 ГБ недостаточно для финального шага доказательства. [Хост prover](/ru/rome-zk-evm/prover-host.md) определяет бюджет по ОЗУ и диску. Узел может работать и публиковать батчи до готовности prover, но ни один из его корней не будет финальным.

## Запустите узел

Склонируйте релиз и работайте из его каталога rollup:

```sh
git clone --branch v0.3.0 https://github.com/rome-protocol/solana-zk-evm.git
cd solana-zk-evm/deploy/rollup
cp .env.example .env
cp chain.toml.example chain.toml
```

Укажите Solana RPC, расположения подписантов и `ROME_ZK_TAG=v0.3.0` из `.env`. Сохраните `PROGRAMS_JSON=programs.devnet.json`. Укажите `ROME_ZK_GUEST_TAG=v0.3.0` и `ZISK_RELEASE=1.3.1-alpha` для последующей сборки guest. Для первого локального запуска привяжите RPC к loopback. Оставьте `PROVER` не заданным, пока guest и его ключ не будут готовы.

Установите `genesis.fee_recipient` из `chain.toml` на ваш адрес EVM. Не выбирайте идентификатор цепочки. Механизм settlement выводит его из payer и количества его регистраций; `init` считывает его перед отправкой чего-либо. Примерно половина всех идентификаторов слишком велика для MetaMask. Если ваш из них, `init` завершается с `ChainIdNotWalletSafe`; создайте новый ключ payer, укажите `PAYER_KEYPAIR_PATH` на него и выполните `init` снова.

Новая цепочка начинается с нулевых балансов. Если вы объявляете один обеспеченный баланс, чтобы получить газ до открытия депозитов, заблокируйте ту же сумму wrapped SOL в хранилище цепочки, прежде чем запрашивать ключ верификации.

```sh
./rollup init
./rollup register --dry-run
./rollup register --confirm
./rollup up
./rollup check
```

`init` формирует genesis и конфигурацию сервиса. `register --confirm` блокирует депозит 5 SOL и создает курсор батчей. `up` запускает узел sequencer, batcher, derive и verifier. `check` укажет отсутствующую службу, а затем сравнит chain ID, heads, ход batcher, inbox и roots. Запустите его снова после того, как батчи успеют закрыться; его первая проверка хода батчей лишь фиксирует образец.

Без prover sequencer обслуживает RPC, batcher отправляет данные транзакций в inbox, а derive реконструирует цепочку. Батч в inbox не является финальным корнем settlement. Даже корень genesis ожидает доказательства.

## Переход от батчей к финальным корням

Соберите guest для genesis вашей цепочки:

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

Сборка использует guest v0.3.0 и ZisK 1.3.1-alpha. Она создает guest-программу цепочки и метаданные ключа верификации. Вычисление `programVK` требует proving keys ZisK и около 36 ГБ ОЗУ. Регистрация цепочки не регистрирует ключ верификации. Отправьте [запрос на ключ верификации](/ru/rome-zk-evm/verification-key.md) после сборки. Rome проверяет ваш genesis и guest, а затем регистрирует ключ с слотом активации.

На хосте prover установите `PROVER=on` и guest, метаданные верификации и настройки ZisK, описанные в полном runbook. После активации ключа:

```sh
./rollup init
./rollup up
./rollup check
```

Проверьте, что `служба prover` и `ключ верификации` элементы проходят проверку. Prover обрабатывает батчи inbox по порядку. Каждое корректное доказательство публикует корень, который становится финальным сразу после попадания его транзакции Solana в блокчейн.

## Создайте первый блок

Без обеспеченного баланса genesis у цепочки нет газа для транзакции до открытия депозитов. Для депозитов нужен первый доказанный корень. Значение по умолчанию `empty_block_interval_secs = 0` оставляет бездействующую цепочку без блоков, поэтому установите его в `60` меньше `[profile]` из `chain.toml` после активации ключа и запуска prover. Сгенерируйте конфигурацию и перезапустите:

```sh
./rollup init
./rollup up
./rollup check
```

Как только первый корень станет финальным, верните интервал обратно на `0` и снова выполните `init` и `up` если только вам не нужны регулярные пустые блоки. Включение их во время ожидания регистрации ключа в Rome создает очередь. Каждый батч должен доказываться по порядку.

При интервале пустого блока 60 секунд и закрытии батча каждые 60 секунд цепочка создает примерно один батч в минуту, то есть около 1 440 в день. В devnet доказанный корень обходился payer примерно в **0.003 SOL**: около 0,002 SOL на аренду pending-account, 0,001 SOL в виде комиссии settlement и дополнительную комиссию за транзакцию. При такой частоте это около 4,4 SOL в день до учета затрат на публикацию в inbox. Аренда pending-account остается заблокированной при настройках по умолчанию. При отключенных пустых блоках бездействующая цепочка не закрывает батчи и не несет затрат на публикацию.

Чтобы принимать депозиты, сначала создайте хранилище, активируйте конфигурацию выхода после ее задержки и откройте очередь депозитов. Эти команды и проверки находятся в [Депозиты и выводы](/ru/rome-zk-evm/deposits-and-withdrawals.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/run-a-rollup.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.