Запуск валидатора и агрегатора

Используйте эту страницу, чтобы подобрать машину до запуска. Валидатор обходится дёшево. Доказательство — нет: память для доказательства быстро растёт с его уровнем, и именно это число определяет, справится ли машина. Каждая цифра здесь — результат измерения на testnet или по записям fullnode. Цифры, которые ещё не окончательны, помечены.

Что делает каждая роль

Валидаторы и наблюдатели никогда не доказывают. Экранированный перевод или вызов доказывает кошелёк, который его отправляет, а само доказательство пакета — прувер, с которым этот кошелёк связан (Запуск узла). Валидаторы флота сегодня ничего не доказывают.

Агрегация блоков реализована, но не активна. Для неё нужна секция aggregation в genesis. В chain 20 её нет: агрегация выключена, как и в chain 9–19, а сборка отказывается запускаться на genesis, содержащем эту секцию.

Подбор ресурсов вкратце

Сегодня прувер однопоточный. 16-vCPU дроплет работал на 99% одного ядра. Больше ядер не ускоряет одно доказательство; завершится ли оно, решает объём RAM.

Валидаторы и наблюдатели

Память и CPU

Исходные восемнадцать валидаторов работают на дроплетах по 2 GB. Проверка доказательства обходится дёшево:

Память, нужная валидатору для проверки доказательства вызова уровня 18 или 20, теперь частично измерена на 48-GB ноутбуке Apple Silicon, независимо от дроплета DigitalOcean, который породил каждое доказательство: проверка доказательства transfer уровня 18 заняла 50,2 s при пиковом RSS 3,66 GB (транслированное) или 49,6 s (интерпретатор, RSS отдельно не записывался); проверка доказательства approve уровня 16 заняла 12,2 s (RSS отдельно не записывался). Уровень 20 не измерен — доказательства уровня 20 для проверки пока не существует. Начиная с v0.5.6 валидатор никогда не строит настолько большой ключ: заголовок доказательства вызова проверяется до построения любого ключа верификатора, а вызов выше уровня 14 (или с таблицей keccak больше 2^12, или с таблицей sha256 больше 2^13) отклоняется — при приёме и как правило валидности блока. Худший допустимый заголовок вызова проверялся за 4,7 s и 312 MB.

Дроплет с 1 vCPU и 2 GB не может собрать бинарные файлы. Собирайте на более мощной машине и копируйте их (см. настройка).

Диск

В chain 20, как и в chain 19, 24 из 26 валидаторов работают с --prune-history 24h и хранят около суток блоков; сам реестр состояния (ноты, нуллификаторы, якоря, реестр) никогда не обрезается. Архивы, obs1 и rand-archive-2 (оба также являются валидаторами), работают без этого флага. Узел mainnet никогда его не передаёт. Узел отказывается запускаться, если на файловой системе его каталога данных свободно меньше --min-free-disk-mb (по умолчанию 1 024 MB), а rand_getHealth отвечает disk_low, когда свободно меньше четырёхкратного значения; выкатка, ожидающая ok, останавливается на заполняющемся узле. О том, на что отвечает обрезанный узел, см. Обрезка истории.

Удаляйте каталог данных выведенной из обращения цепочки после переключения. Каталоги данных именуются по хешу генезиса (data-<name>-<hash8>: -6210cf07 для цепочки 20, -a3defc93 для цепочки 19; шесть хостов-хранителей используют /var/lib/randnode/data-20), поэтому старые остаются, пока вы их не удалите. При переключении на цепочку 20 один региональный валидатор (syd1) поднялся в состоянии disk_low при 3,9 GB свободного места и задержал запуск на 25 из 26, потому что на нём ещё лежали каталоги цепочек с 14 по 17; их удаление освободило 22 GB. Каталог предыдущей цепочки держите сутки как цель отката, затем удаляйте. При полных блоках каждое необработанное доказательство пакета занимает около 1,42 MB начиная с цепочки 14 (около 1,3 MB до цепочки 13). Начиная с цепочки 17 каждый пакет несёт ещё и доказательство авторизации, так что перевод — это около 2,85 MB доказательств: около 1,49 MB на доказательство пакета и 1,36 MB на доказательство авторизации (производственный профиль, измерено 2026-09-29). Агрегация после активации сокращает доказательство запечатанного пакета примерно до 3 KB, если только узел не запущен с --keep-raw-proofs. На доказательство авторизации она не распространяется: оно остаётся полного размера.

Сеть

Откройте входящий TCP 30303 на публичном узле. Узлы за NAT подключаются наружу с помощью --bootstrap. При полных блоках по 4 MiB канал валидатора передаёт около 2 MB/s.

Часы

Валидатору нужен NTP. Цепочка 14 — первая, в которой системное время входит в консенсус (усиление моста, B2):

Валидатор, чьи часы отстают на 20 s, молча перестаёт голосовать: каждый честный блок он видит опережающим его часы и не отдаёт голос, при этом ничего не сообщает об ошибке. В цепочке 20 для фиксации чего-либо должны проголосовать восемнадцать из двадцати шести. Проверьте каждый валидатор и установите chrony там, где часы не синхронизированы:

timedatectl                     # want "System clock synchronized: yes" and "NTP service: active"
chronyc tracking 2>/dev/null || timedatectl show-timesync --all 2>/dev/null
apt-get install -y chrony && systemctl enable --now chrony

Тот же предел в 15 s действует для генезиса. Задавайте timestamp_ms близко ко времени запуска и никогда не позже него: генезис, лежащий в будущем более чем на 15 s, не зафиксирует блок 1, пока системное время не дойдёт до него, а генезис из далёкого прошлого оставляет время блока позади системных часов, и оно догоняет их не быстрее чем на 60 s за блок (docs/deploy.md). Наблюдатель не голосует, поэтому правило голосования его не связывает.

Размеры DigitalOcean, на которых работает testnet

Эта таблица охватывает первоначальные восемнадцать валидаторов. С 2026-09-27 валидатор A тоже работает на droplet (sgp1), а не на ноутбуке. Ещё восемь валидаторов внесли залог в цепочке 15 (2026-09-27): два архивных, obs1 и rand-archive-2 (fra1), и шесть хостов-хранителей. Размеры их droplet здесь не записаны, как и то, были ли mkc1 и mem1 увеличены. Все 26 — валидаторы генезиса цепочки 20, как и цепочки 19, по 1 000 RAND каждый, и по состоянию на 2026-09-30 все 26 ключей находятся у одного оператора.

Память для доказательств

Кошелёк доказывает каждую отправляемую транзакцию, поэтому вызывающему программу нужна память под ярус этой программы. Ниже приведены измеренные границы. Прогоны яруса 18 завершились, доказательства построены и проверены на DigitalOcean; ярус 20 — нет. Начиная с v0.5.6 цепочка отклоняет доказательство вызова выше яруса 14 (MAX_CALL_TIER), поэтому строки ярусов 16, 18 и 20 ниже — это измерения, а не вызовы, которые допускает цепочка 20; каждый вызов, зафиксированный в цепочке 14, был яруса 10.

Вызовы ERC-20 приходятся на ярусы 16 и 18, а SPL Token — на ярус 20 (Ethereum, Solana). Ни одно доказательство яруса 18 или 20 не построено на машине с 48 GB.

Агрегаторы

Агрегатор следит за цепочкой, берёт доказательства пакетов из окна финализированных блоков, строит по ним одно рекурсивное агрегированное доказательство и отправляет его. Блок, который его включает, — запечатывающий блок. Агрегатору выплачивается доля за доказательство охваченных пакетов плюс субсидия блока в новых RAND на его зарегистрированный адрес выплат. Агрегация не требует разрешений: зарегистрироваться может любой оператор с залогом.

Она существует только в цепочке, генезис которой содержит секцию aggregation. В цепочке 20 такой секции нет, и её сборка отказывается запускаться на генезисе, который её содержит.

Оборудование

Значения для N = 2 и N = 3 измерены на droplet DigitalOcean с 256 GB 2026-09-28/29 при наборе ограничений 7, а производственному доказательству выхода потребовалось больше, чем 256 GB этой машины. Ни одно из них не измерялось заново при наборе ограничений 8, который используют цепочки с 18 по 20, поэтому строку N = 1 следует считать нижней границей. Бэкенд CUDA впервые запустился на реальном оборудовании 2026-09-28, на NVIDIA H100: его ядра собираются в PTX для sm_80 и sm_90 и совпадают с эталоном на CPU. Производственное измерение на GPU-узле парка ещё предстоит сделать. Кроме того, каждый узел один раз при запуске платит за сборку ключей для программы агрегации: от 13,0 до 13,4 s в тестовом профиле (2¹⁹) и ожидаемые от 30 до 70 s в производственном (2²¹).

Команды

# print a signed registration; the bond burns out of a wallet bundle as the register bundle's burn
rand-node aggregator register --key agg.key.json --bond <RAND> --payout rand1… --rpc http://127.0.0.1:8545

# the daemon: poll rand_getUnsealed, fetch the raw bundles, prove, seal the payment note, submit
rand-node aggregate --key agg.key.json --rpc http://127.0.0.1:8545 --watch

# leave, then withdraw the released bond into a note at the payout address
rand-node aggregator unbond --key agg.key.json --rpc http://127.0.0.1:8545
rand-node aggregator withdraw --key agg.key.json --rpc http://127.0.0.1:8545

В такой цепочке rand status показывает раздел aggregation: зарегистрированные агрегаторы, незапечатанные блоки и индекс графика субсидий. rand_getUnsealed возвращает список работы.

Установка

Эти шаги повторяют скрипты, которыми пользуется testnet (deploy/vps-setup.sh, deploy/update-droplet.sh). В результате получается Linux-валидатор или наблюдатель.

1. Сборка на сборочном хосте

Для сборки нужны build-essential clang cmake pkg-config libssl-dev, Rust 1.98.1 (закреплён в rust-toolchain.toml) и репозиторий circuits рядом с репозиторием fullnode. Первая сборка занимает от 10 до 20 минут.

git clone https://github.com/randprotocol/fullnode
git clone https://github.com/randprotocol/zkp-circuits circuits
cd fullnode
git checkout v0.6.8                       # c9c9bd3c, the build chain 20 runs
git -C ../circuits checkout "$(sed -n 's/^circuits: //p' crates/randprotocol-zkvm/guests-compiled/PROVENANCE.md)"   # aeacf31 for v0.6.8
git show origin/main:deploy/genesis-chain20.json > deploy/genesis-chain20.json   # committed after the tag
cargo build --release -p randprotocol-node -p randprotocol-client
sha256sum target/release/rand-node         # compare on every node you copy it to

Цепочке 20 требуется v0.6.8 на каждом узле до init. Её genesis содержит поля, которых не читает ни одна более ранняя сборка (testnet, binding_domain, proof_window_blocks, program_state, группы rotation и fees моста, потолки gas, допуск в стейкинг по голосованию), а v0.6.8 включает изменения консенсуса CON-4 и CH-1 из аудита v6. Доказательства по-прежнему строятся по набору ограничений 8, как в цепочках 18 и 19, и рядом с каждым доказательством пакета идёт доказательство авторизации (hc_auth). Сборка v0.6.8 отказывается принимать genesis цепочек с 14 по 17 при run и verify. Собирайте ту же сборку, что и весь парк узлов. Файл genesis лежит в ветке main репозитория fullnode (коммит 74cfaca0), а не в теге v0.6.8, отсюда третья строка git. Репозиторий circuits должен находиться на коммите, из которого был взят вендоринг релиза; его читает вторая строка git выше из дерева fullnode. Добавьте -p randprotocol-prover, чтобы собрать и rand-prover.

2. Установка бинарных файлов на узел

scp target/release/rand-node target/release/rand deploy/genesis-chain20.json root@<node>:/root/
ssh root@<node> 'install -m 755 /root/rand-node /root/rand /usr/local/bin/'

3. Ключ, genesis, брандмауэр

На узле:

install -d -m 700 /root/keys
test -e /root/keys/node.key.json || rand-node keygen --out /root/keys/node.key.json   # prints the address; keep the seed secret
rand-node init --datadir /root/data-6210cf07 --genesis /root/genesis-chain20.json
timedatectl                                        # "System clock synchronized: yes" (see Clock)
ufw allow 22/tcp && ufw allow 30303/tcp && ufw enable

Генерируйте ключ на самом узле, как показано выше, и храните его вне любого checkout. В репозитории fullnode больше не отслеживается ни один ключ (аудит v3, OPS-1). Файлы deploy/node-*.key.json, закоммиченные для цепочек с 8 по 13, — это опубликованные seed; ключи валидаторов цепочки 20 (восемнадцать, созданных для цепочки 14, и восемь, вошедших в залог в цепочке 15) были сгенерированы вне репозитория, а парк узлов хранит ключ каждого droplet в /root/keys/node-<name>.key.json, за пределами дерева исходников. Расположение важно на узле, развёрнутом скриптами парка: deploy/rebuild-vps.sh и deploy/push-to-vps.sh синхронизируют /root/fullnode через rsync с --delete, поэтому ключ внутри этого дерева будет удалён при следующей пересборке, и после этого юнит не сможет перезапуститься. Начиная с v0.6.8 keygen отказывается перезаписывать существующий файл (v0.6.7 перезаписывал его без предупреждения); test -e делает строку безопасной для повторного запуска в любом случае. Сделайте резервную копию ключа вне хоста, прежде чем вносить его в залог.

init печатает хеш genesis. Он должен быть равен 6210cf071a390d7ac61d8cbea5dd9d139d1a493a862b54a45a498f36af2d5135 (цепочка 20). Файл genesis называется genesis-chain20.json и лежит в deploy/ репозитория fullnode в ветке main. Назовите каталог данных по первым восьми символам хеша, как это делает парк узлов (data-<name>-6210cf07), чтобы он никогда не совпал с каталогом цепочки 19 (-a3defc93) или более поздней цепочки. Genesis задаёт следующие лимиты. Предел размера доказательства составлял 8 MiB в цепочках с 13 по 16 и равен 4 MiB начиная с цепочки 17, где транзакция стала нести до трёх доказательств:

Genesis цепочки 20 также содержит consensus_domain: 1, binding_domain: 1, testnet: true, раздел staking с допуском по голосованию, раздел gas с потолками цен, группы моста rotation и fees, hardening_v6 и две привязки guest-программ hc_bundle и hc_auth; что именно они задают, перечислено в Running a node.

4. Юнит systemd

Это юнит, который записывает deploy/vps-setup.sh, с указанными выше путями:

[Unit]
Description=RAND full node
After=network-online.target
[Service]
Environment=RUST_LOG=info,libp2p=warn,libp2p_mdns=off
ExecStart=/usr/local/bin/rand-node run --datadir /root/data-6210cf07 --key /root/keys/node.key.json --validator --listen /ip4/0.0.0.0/tcp/30303 --rpc 127.0.0.1:8545 --no-mdns --prune-history 24h --bootstrap <multiaddr> --bootstrap <multiaddr>
Restart=always
RestartSec=3
[Install]
WantedBy=multi-user.target

Для наблюдателя уберите --validator. --prune-history 24h — то, с чем работают валидаторы testnet, кроме архивных; уберите его для узла, хранящего полную историю, и никогда не передавайте его на mainnet-beta. Bootstrap-мультиадреса цепочки 20 — узлы C (fra1), D (ric1) и E (sgp1), без изменений по сравнению с цепочкой 19. Цепочка 20 работает на ключах валидаторов, созданных для цепочки 14, а p2p-идентификатор выводится из ключа валидатора, поэтому эти peer id — те же, что использовались в цепочке 14. Новому узлу, синхронизирующемуся с genesis, также нужен пир с полной историей, поэтому добавьте один из двух архивов (obs1, затем rand-archive-2):

/ip4/164.90.239.200/tcp/30303/p2p/12D3KooWEQEbUwZRgqhDPXhW7vNBmcRcnhUDGUADe81VFdv3ALYe
/ip4/165.245.173.74/tcp/30303/p2p/12D3KooWJyc5oDHggAr89e9QrRFBy9Tg8TxXh18yzrb1SM6KKLYw
/ip4/188.166.235.187/tcp/30303/p2p/12D3KooWSyX84P1DAbWByLHpRBMLRWD53r3Jj4aqVt6tHoF8B2ZQ
/ip4/168.144.46.203/tcp/30303/p2p/12D3KooWS5usdMPvsbaWSaT2xtKndHvDYurwmueoNvaRRarb2wRf
/ip4/206.81.29.236/tcp/30303/p2p/12D3KooWPocyZGcNB9Vp68VSfgVvNXhSzBBoJa4h9R1yMkp71XHh

Держите RPC на 127.0.0.1, если его не защищает брандмауэр. Узел, который должен обслуживать публику, открывает рядом с ним публичный listener v0.6.8 (--public-rpc <ADDR>) и ставит прокси перед ним, но никогда не перед --rpc (JSON-RPC). Юнит, перенесённый из v0.6.7, не должен передавать --prover-accept-spend-key: v0.6.8 отказывается стартовать с этим флагом.

systemctl daemon-reload && systemctl enable --now rand-node
journalctl -u rand-node -f
rand status                       # height climbing, peer_count rising

5. Вход в набор валидаторов

Новый ключ не входит в набор ни одной эпохи. В цепочке 20 его сначала нужно принять голосованием: её genesis задаёт staking.admission_by_vote, поэтому валидаторы, держащие более двух третей веса голосов, подписывают его каждый командой rand-node admit sign --candidate <key or registration> --key <validator key> --genesis-hash <chain 20's hash>, а один из них отправляет голоса командой rand-node admit submit; после этого rand_getAdmitted показывает ключ в списке. Затем внесите в залог за него не менее 1,000 RAND: напечатайте регистрацию командой rand-node register --key /root/keys/node.key.json --payout rand1… --v2 (цепочка 20 отклоняет регистрацию v1), затем внесите залог из кошелька командой rand bond <address> 1000 --registration <hex>. Залог ждёт своей эпохи активации, не раньше чем через три границы по 1,000 блоков после его фиксации, и на каждой границе новым весом может стать не более 2,500 bps активного веса (цепочка 19 ограничивала это фиксированными 10,000 RAND). Пошаговый разбор — в Staking.

6. Обновление

Это относится к сборке, работающей в той же цепочке. Переход с более ранней цепочки на цепочку 20 обновлением не является: он требует нового бинарного файла, нового genesis и нового каталога данных, а каталог данных старой цепочки после этого можно удалить (deploy/retire-chain-dirs.sh; парк узлов хранит его сутки на случай отката). Чтобы выкатить новую сборку без смены цепочки, соберите её один раз, сравните sha256 у rand-node и rand, остановите сервис, установите и перезапустите, по одному узлу за раз. Некоторые релизы выкатываются иначе: все узлы останавливаются, затем все запускаются (правило уровня вызовов в v0.5.6, изменение wire-формата Status в v0.5.7, более строгая проверка доказательств в v0.6); в примечаниях к каждому релизу сказано, как именно. v0.6.7 выкатывался на цепочку 18 по одному узлу; v0.6.8 пришёл вместе с цепочкой 20 по схеме «остановить все, запустить все», потому что его изменения консенсуса CON-4 и CH-1 ни в коем случае нельзя выкатывать узел за узлом. Дожидайтесь, пока каждый узел вернётся в сеть, прежде чем переходить к следующему, чтобы кворум никогда не оказывался неполным больше чем на один узел. deploy/update-droplet.sh <ip> [build-host] делает именно это по SSH.

Релизы до v0.6.8 включительно собирались вручную на одном хосте и не подписаны. Релиз v0.6.8 на GitHub содержит rand-node, rand, rand-prover и SHA256SUMS, собранные на узле E; эта контрольная сумма выявляет повреждённую загрузку, но не ручается за сборочный хост. v0.6.8 поставляется с release workflow, который собирает бинарные файлы из тега, а deploy/update-droplet.sh отказывается от установки без подписанного SHA256SUMS, если не задано ALLOW_UNSIGNED=1. deploy/release-signers пока не содержит ни одного ключа, поэтому подписанный путь ещё не использовался.

Цепочки 15, 16, 17 и 18 были запущены за 2.7 суток (с 2026-09-26 по 2026-09-29), и каждая означала остановку всего парка узлов. Цепочка 19 последовала 2026-10-01 в 03:43 UTC как повторный genesis цепочки 18 на той же сборке, а цепочка 20 — в тот же день в 06:17 UTC, вырезанная из снимка цепочки 19 при хардфорке v0.6.8; все узлы остановились на высоте 7,700 цепочки 19. Письменная политика смены цепочки (2026-09-30) действует начиная с цепочки 20; запись о смене цепочки 20 освободила от пересборки вторым оператором, потому что все ключи держит один оператор. Смена цепочки требует причины, которую не может устранить поэтапное обновление, опубликованного списка того, что она вносит и что убирает, заранее выполненного чек-листа пересборки клиентов, второго оператора, который пересобирает genesis до того же хеша, плана отката и идентификатора цепочки, никогда прежде не использовавшегося.