Для разработчиков

Rand — проект с открытым исходным кодом. Полный узел, обозреватель, мост, исследования по доказательствам и клиенты кошелька находятся каждый в своём репозитории на GitHub. Читайте код, запускайте тесты, присылайте патчи. Эта страница — карта: где живёт каждый компонент, на чём он построен, как далеко продвинулась система доказательств и где она останавливается сегодня.

Репозитории

Стек

Rust от начала до конца. Rand — самостоятельная цепочка: узел HotStuff BFT со слоем gossip на libp2p, полностью экранированный пул нот в роли реестра, постквантовые подписи и шифрование нот, а также zkVM Rand для конфиденциальных вычислений — всё это в репозитории fullnode. Сама система доказательств — та часть, над которой идёт активное исследование; о ней ниже.

Одно отношение для каждой программы

Универсальное отношение исполнения R_exec из whitepaper существует в виде кода: rand_zkvm — машина RV32IM, доказываемая единым пакетным STARK на Plonky3 над полем Goldilocks. Оно доказывает, что некоторая трасса выполнила программу hc с данными публичными выходами на входах, зафиксированных посоленным H_IN, и ничто в программе никогда не является параметром верификатора. Публикация конфиденциальной программы означает регистрацию хеша, а не создание специальной схемы.

Система доказательств прозрачна: без доверенной настройки и без кривой со спариванием, а её допущение — устойчивая к коллизиям хеш-функция. Ожидается, что все остальные компоненты, работающие с доказательствами, сойдутся на этом крейте, а не обзаведутся собственным. Крейт находится в zkp-circuits/research и вендорится в fullnode на наборе ограничений 8 (circuits aeacf31, fullnode v0.6.7 и v0.6.8). Таблицы и измерения ниже описывают набор ограничений 5 (этап M4.2), если строка не называет более поздний набор; они взяты из docs/zkvm.md, docs/zkvm-milestones.md и docs/confidential.md fullnode по состоянию на 2026-09-13, а измерения приведены такими, какими были получены на ноутбуке с Apple Silicon, а не как целевые значения.

Восемь таблиц на именованных шинах, девятая по требованию

Одно обязательство, одно открытие FRI. Таблицы никогда не вызывают друг друга; они обмениваются фактами по именованным шинам LogUp (PROGRAM, PROGRAM_WORD, MEMORY, ALU, POSEIDON2, INPUT_DIGEST, INPUT_READ, KECCAK и таблицы поиска для диапазонов и ниблов), а верификатор проверяет, что каждая шина сбалансирована глобально. Максимальная степень ограничений каждой таблицы закреплена тестом под пределом 8, который допускает коэффициент расширения FRI.

С тех пор появились ещё три набора ограничений. Набор 6 добавил обязательную таблицу public для публичного входа программы, задаваемого при развёртывании и привязанного к несоленому дайджесту H_PUB, а также опциональную таблицу sha256 рядом с keccak. Набор 7 (chain 16) ослепляет каждый терминал LogUp на новой шине BLIND, устанавливает нижнюю границу 2⁷ строк для каждой объявленной таблицы и добавляет системный вызов POSEIDON2_LEN с привязкой к длине. Набор 8 (chain 18) добавляет столбец GAS в таблицу cpu и одно публичное значение — объявленный GAS_LIMIT.

Что раскрывает доказательство

Публично: хеш кода hc (восемь слов дайджеста в схеме), посоленное обязательство входа H_IN (восемь слов), уровень газа и восемь слов выхода. Начиная с набора ограничений 6 также H_PUB — дайджест публичного входа, а начиная с набора ограничений 8 — объявленный лимит газа. Заголовок доказательства объявляет высоты таблиц Keccak и SHA-256, поэтому он показывает, выполнялось ли хеширование и, выше нижней границы 2⁷, примерно в каком объёме.

Скрыто: приватные входы (H_IN посолен, поэтому он не только связывающий, но и скрывающий); каждое слово инструкции, потому что верификатор проверяет hc, а не программу; каждое значение регистров и памяти; каждая выбранная ветвь; точное число тактов и точный израсходованный газ; и то, какие системные вызовы выполнялись, помимо того, что показывают высоты двух хеш-таблиц.

Уровень публичен для каждого доказательства, потому что размер STARK и так раскрывает высоту его трассы; скрытие индекса ничего бы не дало. hc является связывающим, но не скрывающим: см. где он останавливается сегодня.

Измерено, на наборе ограничений 5

Ноутбук с Apple Silicon, релизная сборка. Время доказательства сдвинуло разделение байтовых таблиц в M2.3; размер доказательства вернул наверх профиль с 80 запросами. Ключ верификатора не зависит от содержимого программы: он определяется уровнем и объявленными в доказательстве высотами таблиц программы, входа и keccak, поэтому узел прогревает один ключ и использует его повторно.

Более поздние наборы изменили размеры. При наборе ограничений 7 доказательство яруса 10 занимает 1,367,688 байт в производственном профиле, а доказательство яруса 10 с Keccak — 3,283,898 (измерено 2026-09-28). Начиная с цепочки 17 перевод несёт два доказательства: доказательство пакета яруса 14, около 1.49 MB, и доказательство авторизации яруса 10, около 1.37 MB, на построение которого уходит около 7 с. Генезис цепочки 20 задаёт блок в 20 MiB и предел доказательства в 4 MiB, а вызов не может превышать ярус 14.

Три цели, одна схема

Нативно исполняется только RISC-V. Программы на Solidity и Solana либо работают на гостевом интерпретаторе внутри того же отношения, а их байткод подаётся на вход, либо транслируются вне цепочки в программы RISC-V, выходы которых слово в слово совпадают с выходами интерпретатора. Дорогие опкоды требуют выделенных таблиц сопроцессоров, а не побитовой симуляции.

Вехи

Веха 1 доказала машину общего назначения. Веха 3 превратила её в экранированный пул: перевод с проверкой принадлежности внутри схемы доказывается в рамках R_exec, а верификатор проверяет hc, ни разу не увидев ни одного слова программы. Веха 4 — это совместимость: её загрузчик, обязательство на вход и таблица Keccak поставлены как наборы ограничений 4 и 5, а таблица SHA-256 — с набором 6. Гостевые интерпретаторы EVM и sBPF, инструментарий rand-guest и два транслятора построены. Перевод ERC-20 доказан на машине со 128 GB; доказательство SPL Token на ярусе 20 — нет. Веха 5 — это рекурсивная ВМ, на которой строится агрегация блоков; она построена и отключена во всех цепочках. Наборы ограничений 7 и 8 последовали за сентябрьскими ревью и моделью газа.

Фазы экранированного пула

Реестр fullnode был внесён в три фазы, каждая — хард-форк (docs/shielded.md §7). S1 заменил реестр счетов пулом нот; S3 вернул мост в виде нот и был внесён первым; S2 поставил поверх него стейкинг. Все три в main и в текущей цепочке.

Строки ниже S2 — это работа v0.5. Каждая строка является хард-форком. Их взяли вместе как одну новую цепочку, chain 14, выпущенную 2026-09-20 из сборки b3c594c и помеченную тегом v0.5 в тот же день, после живого круга zUSD через развёрнутые конечные точки источника. Chain 15, работающая с 2026-09-26 на v0.5.8 и позднее, несла всё это с включёнными по genesis исправлениями аудитов v4 и v5: кран из белого списка с бюджетом на эпоху, отложенная активация залога, ограничение веса стейка, регистрации, привязанные к genesis, consensus_domain 1, правила моста v2, а также лимит реестра токенов, сжигаемая плата за регистрацию и граница 2⁶³ для нот. Chain 20, работающая с 2026-10-01 06:17 UTC на v0.6.8 (c9c9bd3c), хард-форк chain 19, сохраняет всё это и добавляет работу релизов v0.6, перечисленную ниже.

Релизы после v0.5

Каждый релиз — это git-тег с записью в CHANGELOG.md полного узла. Релиз, который меняет консенсус, формат передачи или ключ верификатора, выходит с новой цепочкой; остальные накатываются на живую цепочку по одному узлу за раз.

Границы на сегодня

Отступления от whitepaper изложены прямо, без сглаживания. Каждое отслеживается в собственной документации крейта вместе с вехой, которая его закрывает.

• hc является связывающим, но не скрывающим: в нём нет соли, поэтому угаданную программу можно подтвердить, а два развёртывания одной и той же программы можно связать между собой. М3.4 устранил другое: то, что верификатор держит всю программу в открытом виде.
• Кошелёк, собранный до 2026-09-21, запрашивает у своего узла свидетелей (witness), а запрос свидетеля называет лист, который будет потрачен. Текущий rand хранит собственную копию дерева и никогда не спрашивает; узел по-прежнему отдаёт rand_getWitness для старых кошельков.
• Депозиты публичны на границе: минт из фаucet, нота генезиса и депозит через мост несут сумму в открытом виде (начиная с цепочки 14 минт и нота генезиса несут также своё раскрытие, так что ключ владельца тоже публичен); это та же видимость в один переход, что и у депозита из прозрачного пула в экранированный где бы то ни было.
• Нулевое разглашение статистическое, а не идеальное. Именно это свойство на деле обеспечивает скрывающий FRI в Plonky3 0.7, и крейт говорит об этом прямо.
• Хеш транскрипта — Poseidon2 с девелоперскими круглыми константами, а не SHA3-384 / BLAKE3-384 из статей. Это замена конфигурации, а не переписывание.
• При 80 запросах FRI доказательство bundle занимало около 1,42 MB в цепочках 14 и 15 (около 1,3 MB до цепочки 13). Начиная с цепочки 17 перевод несёт около 2,85 MB доказательств: доказательство bundle, около 1,49 MB, и auth-доказательство, около 1,37 MB. В цепочке по умолчанию, с блоками 4 MiB и лимитом доказательства 2 MiB, доказательство с Keccak сразу превышает этот лимит; генезис цепочки 20 задаёт блоки 20 MiB и лимит доказательства 4 MiB (цепочки 13–16 задавали 8 MiB).
• Заголовок доказательства вызова не скрыт. Он объявляет уровень и высоты таблиц Keccak и SHA-256, так что видно, использовался ли хеш в вызове. Вызовы, зафиксированные в цепочке 15 до нижней границы prover v0.6, раскрывали больше: приватную таблицу менее 2⁷ строк можно было прочитать из доказательства. Нижняя граница prover v0.6 закрыла это для новых вызовов, а набор ограничений 7 с hardening_v6 сделал это правилом цепочки начиная с цепочки 16.
• Вызов ограничен уровнем 14, не более чем 2¹² строк Keccak (128 перестановок) и 2¹³ строк SHA-256 (128 сжатий), а при hardening_v6 программу длиннее 8 180 слов развернуть нельзя. Гостевые интерпретаторы EVM и sBPF, а также переведённые образы ERC-20 и SPL Token все выше этого предела.
• Тот, кто владеет свидетелем, видит всё. ZK защищает обзор верификатора, а не доказывающего. Начиная с цепочки 17 кошелёк может передать доказательство bundle спаренному rand-prover, не передавая ключ траты, но этот доказывающий по-прежнему держит ключ просмотра и видит ноты. Бэкенд CUDA впервые запущен на оборудовании 2026-09-28 и пока не имеет производственных измерений.

Структура репозитория

Cargo workspace полного узла в том виде, как он описан в его README и каталоге crates/.

Описано, но ещё не выпущено

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

Сборка и тестирование

Стандартный рабочий процесс Rust в каждом репозитории. Fullnode — это один рабочий пакет Cargo (workspace) с закреплённой версией toolchain и набором кластерных тестов, который запускает реальные узлы по TCP. Для его сборки репозиторий circuits должен быть извлечён рядом, в каталог с именем circuits, на том коммите, с которого были синхронизированы вендорные крейты (aeacf31 для v0.6.7 и v0.6.8). zkVM — это самостоятельный крейт в zkp-circuits со своим закреплением toolchain и демонстрацией, которая показывает, что конфиденциальный вызов раскрывает, а что нет.

Fullnode:

git clone https://github.com/randprotocol/fullnode.git
git clone https://github.com/randprotocol/zkp-circuits.git circuits   # the sibling directory must be named circuits
git -C circuits checkout "$(sed -n 's/^circuits: //p' fullnode/crates/randprotocol-zkvm/guests-compiled/PROVENANCE.md)"
cd fullnode

# Rust 1.98.1 is pinned by rust-toolchain.toml; first build pulls RocksDB and Plonky3, 10 to 20 minutes
cargo build --release        # target/release/rand-node, target/release/rand, target/release/rand-prover

# All crates; release because STARK proving is slow in debug. One to two hours, mostly proving
cargo test --release

# One machine, two validators
scripts/local-testnet.sh
target/release/rand --rpc http://127.0.0.1:8545 status

Исследовательская zkVM, в zkp-circuits/research:

# Toolchain is pinned by rust-toolchain.toml; the first build pulls Plonky3
cargo build --release

# Narrated demo: thirteen proofs, one at production FRI parameters (~6-7 min)
cargo run --release

# Emulator, per-table constraints, cheating provers, ZK, end-to-end, viewing keys, compiled guests (395 tests, ~17 min)
cargo test

Набор тестов fullnode по замерам на v0.6.1 на машине с 16 vCPU: core — 521 тест, node — 373, client — 117, набор для проверки злонамеренного доказывающего (cheating-prover) — 116, проверки злонамеренного поведения со скрытым пакетом — 21 (75 мин), сценарий кошелька — 6 (53 мин), кластер — 26 (44 мин) и сквозной тест zUSD — 2 (51 мин). Производственные доказательства рекурсивной VM в него не входят, и для них нужен объём памяти, указанный выше.

Running a node описывает, как присоединиться к публичному testnet с этой сборкой; генезис testnet, начальные пиры и скрипты запуска поставляются в каталоге deploy/ репозитория fullnode, а краткая версия есть на странице загрузки.

Участие в разработке

Fullnode распространяется по лицензии GNU General Public License v3.0 (GPL-3.0-only); ранее это была Apache-2.0. Сообщайте об ошибках и предложениях по дизайну через issues в репозитории, которого касается изменение. Pull request’ы приветствуются: перед отправкой запустите cargo fmt && cargo clippy и держите изменения узкими по объёму. Начать стоит со страницы fullnode issues.

Архитектура, схема приватности, доказательство токена комиссии и компромисс в отношении постквантовой стойкости описаны в whitepaper на странице papers. Собственный каталог docs/ в репозитории fullnode — это источник, с которым сверяется каждая страница этой документации.