> 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/prover-host.md). # Хост prover Подготовьте GPU-хост нужного размера для доказательства пакетов Rome ZK EVM с помощью ZisK 1.3.1-alpha. Узел может упорядочивать транзакции и отправлять батчи без GPU. Для того чтобы любое корневое состояние стало финальным в Solana, ему нужен провeр. В версии v0.3.0 провeр работает на ZisK 1.3.1-alpha с guest, собранным для генезиса вашей цепочки. Он доказывает входящие батчи по одному, локально проверяет каждое доказательство, а затем отправляет его в settlement. Названия [полное руководство по хосту провера](https://github.com/rome-protocol/solana-zk-evm/blob/v0.3.0/docs/PROVER-HOST.md) содержит шаги установки и восстановления. Используйте его вместе с [регламентом для devnet](https://github.com/rome-protocol/solana-zk-evm/blob/v0.3.0/docs/RUN-ON-DEVNET.md). ## Подберите параметры хоста Используйте x86-64 Ubuntu 22.04 или новее и одну NVIDIA GPU с объёмом памяти более 30 ГБ. Скрипт настройки принимает GPU примерно с 32,2 ГБ или больше. Финальный этап построения доказательства требует около 30 ГБ, поэтому карта на 24 ГБ слишком мала. Версия драйвера NVIDIA должна быть не ниже 525.60.13. Выделите не менее **128 ГБ ОЗУ** и **125 ГБ свободного места на диске** в каталоге установки ZisK. Архив proving-ключей 1.3.1-alpha занимает 5,1 ГБ, а архив PLONK-ключей — 21,9 ГБ. После того как setup сгенерировал постоянные файлы, размеры двух каталогов с ключами составили 21 GiB и 26 GiB. Первое доказательство добавляет файлы кэша. На CPU-хосте после одного доказательства было измерено 102,1 ГБ в сумме, а рост кэша GPU пока не измерялся. Библиотека построения доказательств 1.3.1-alpha сообщила о 24,7 ГБ для своего основного рабочего буфера и 5,6 ГБ для рекурсии на батче примерно из 3 миллионов шагов. Пиковое потребление всего процесса в этом выпуске не было зафиксировано. В GPU-прогоне devnet использовался хост с 176 ГБ ОЗУ; его пиковое использование памяти также не было зафиксировано. Используйте 128 ГБ как ориентир для подбора размера, а не как измеренный пик. ## Что было измерено Один почти пустой батч занял около **17 секунд**включая обёртку PLONK, на хосте с одной **RTX PRO 6000 с 96 ГБ**и 48 CPU-ядрами и 176 ГБ ОЗУ. Было видно, что используется около 95 ГБ памяти GPU. Это то, что данный запуск занял, а не минимальный объём памяти GPU для каждого батча. Более крупные батчи на GPU пока не засекались по времени. Rome обработал 116 почти пустых батчей devnet примерно за 35 минут на этом GPU. Это важно, когда цепочка сгенерировала пустые блоки в ожидании своего ключа верификации: проверу нужно последовательно пройти их, прежде чем он сможет дойти до более нового состояния. ## Запустите скрипт настройки Установите драйвер NVIDIA и при необходимости перезагрузите систему. Из корня репозитория запустите скрипт этого релиза от имени root. Установите `ZISK_HOME` в каталог, где будут размещены ZisK и его ключи. Используйте то же значение в вашей конфигурации rollup `.env`: ```sh sudo ZISK_HOME=/opt/zisk bash deploy/rollup/prover/setup-prover-host.sh sudo ZISK_HOME=/opt/zisk bash deploy/rollup/prover/setup-prover-host.sh --check ``` Скрипт устанавливает GPU-сборку ZisK, её proving- и PLONK-ключи, необходимые системные библиотеки и NVIDIA runtime для Docker. Он устанавливает лимит заблокированной памяти как неограниченный. Выйдите из системы и войдите снова, чтобы этот лимит применился к вашей оболочке. Затем он проверяет GPU и драйвер, установленные бинарные файлы, ключи, лимит памяти и runtime контейнеров. Перед запуском установщика он проверяет SHA-256 установщика. Он проверяет оба архива ключей перед распаковкой каждого из них, а также проверяет установленный `cargo-zisk` и `cargo-zisk-dev` GPU-бинарные файлы перед их запуском скриптом. Он генерирует постоянные файлы, необходимые для агрегации и proving PLONK. Если запуск завершается сбоем, выполните скрипт ещё раз. Загрузка ключей пропускается, если установленные ключи уже соответствуют закреплённому манифесту. Скрипт не проверяет каждую часть установки ZisK. Установщик загружает бинарный пакет и запускает его установщик toolchain до того, как скрипт проверит два установленных GPU-бинарника. Другие исполняемые файлы и исходные файлы в этом пакете этим скриптом не проверяются по хэшу. В полном руководстве это ограничение указано, а также приведены команды для проверки каждой загрузки по отдельности. ## Подключите его к вашей цепочке Проверу требуются соответствующий guest ELF, его метаданные верификации и те же proving-ключи 1.3.1-alpha. Укажите `PROVER=on` и настройки guest и ZisK в конфигурации rollup, затем выполните `./rollup init` и `./rollup up`. Первый запуск собирает образ провера из исходного кода v0.3.0. Один только образ узла не содержит провера. Перед каждым запуском провeр проверяет установленные proving-ключи на соответствие закреплённому манифесту SHA-256. Эта проверка охватывает имена файлов и их содержимое. Сгенерированные файлы constant-tree и GPU constant исключаются, поскольку они различаются в зависимости от хоста. Несоответствие останавливает провeр с `KeysShaMismatch`. Не изменяйте манифест только для того, чтобы запустить несовместимую установку; установите выпуск, который соответствует guest цепочки и зарегистрированному ключу. Выполните `./rollup check` после запуска. Он проверяет службу провера, активный ключ верификации, а также задержку settlement и провера. [руководство по мониторингу](https://github.com/rome-protocol/solana-zk-evm/blob/v0.3.0/docs/MONITORING.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/prover-host.md?ask=&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.