Участие

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

Эталонный полный узел и его кошелёк написаны на Rust и собираются из исходного кода. На выходе получаются два бинарных файла: rand-node — узел и инструменты оператора, и rand — кошелёк, который хранит ключ расходования экранированных средств, обращается к любому узлу по JSON-RPC и локально запускает prover zkVM для каждого перевода и каждого конфиденциального вызова. Экспериментальный testnet, цепочка 21, работает на 26 валидаторах на дроплетах DigitalOcean. Он не проходил аудит и не несёт реальной стоимости. Бинарные файлы обеих программ для Linux x86_64 приложены к релизу v0.8.0 — сборке, до которой обновлён весь парк узлов.

Сборка и локальный запуск

bash

# 1. Rust (rustup подхватит закреплённый тулчейн 1.98.1) и зависимости сборки RocksDB
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
sudo apt install build-essential clang cmake pkg-config libssl-dev   # Linux

# 2. Клонирование и сборка (10–20 мин при первом запуске)
git clone https://github.com/randprotocol/fullnode.git
cd fullnode
cargo build --release        # target/release/rand-node, target/release/rand

# 3. Цепочка из двух валидаторов на этой машине (RPC на 8545 и 8546)
scripts/local-testnet.sh
target/release/rand --rpc http://127.0.0.1:8545 status

# 4. Тесты; в режиме release, поскольку STARK-доказательство в debug медленное (678 тестов, около 43 минут по замеру от 2026-09-14)
cargo test --workspace --release

Подключение к публичному testnet в роли наблюдателя

цепочка 21

# Релиз v0.8.0 (c0878c3f) работает с chain 21, и ни один более ранний релиз не работает: chain 21 использует набор ограничений 9, чьих ключей верификатора и кодировки доказательств нет ни в одной более старой версии. Соберите его из тега или на Linux x86_64
# возьмите готовые бинарные файлы релиза и сверьте их с SHA256SUMS, опубликованным вместе с ним
git checkout v0.8.0 && cargo build --release
curl -LO https://github.com/randprotocol/fullnode/releases/download/v0.8.0/rand-node -LO https://github.com/randprotocol/fullnode/releases/download/v0.8.0/rand \
     -LO https://github.com/randprotocol/fullnode/releases/download/v0.8.0/msauth-vk-production.bin# закреплённый ключ верификатора multisig: rand-node загружает его из каталога своего бинарного файла и отказывается запускаться без него
sha256sum rand-node rand msauth-vk-production.bin   # должен вывести значения релиза (SHA256SUMS, подписан как SHA256SUMS.sig):
# 324a4ab1029d39e67fc2de36b036341b0f88f13089997d7fe24c596363a58278  rand-node
# e3a38e74ee28743a960fc1c3eb1ac6c538e18dc259411e10afff7f54e268bbf4  rand
# 68facb06c7f321aaf1d4d541acf6b5c0e9d7f17788ed1c9add6c5a8a8f7acd30  msauth-vk-production.bin

# Идентичность вашего узла: ключ валидатора Dilithium2 и идентификатор пира p2p в одном файле. Сгенерируйте свой
# и храните его вне checkout; репозиторий больше не отслеживает ни одного ключа
rand-node keygen --out node.key.json

# Genesis поставляется в репозитории; у каждого узла должен быть идентичный файл.
# init выводит его хеш, который должен совпадать с приведённым ниже
rand-node init --datadir ./data --genesis deploy/genesis-chain21.json

# Подключитесь к публичным валидаторам (chain 21 сохранила ключи chain 14, а значит, её идентификаторы пиров и IP-адреса).
# Опустите --validator: вашего ключа нет в наборе валидаторов. Валидатору также нужен NTP
rand-node run --datadir ./data --key node.key.json \
    --listen /ip4/0.0.0.0/tcp/30303 --rpc 127.0.0.1:8545 --no-mdns \
    --bootstrap /ip4/164.90.239.200/tcp/30303/p2p/12D3KooWEQEbUwZRgqhDPXhW7vNBmcRcnhUDGUADe81VFdv3ALYe \
    --bootstrap /ip4/165.245.173.74/tcp/30303/p2p/12D3KooWJyc5oDHggAr89e9QrRFBy9Tg8TxXh18yzrb1SM6KKLYw \
    --bootstrap /ip4/188.166.235.187/tcp/30303/p2p/12D3KooWSyX84P1DAbWByLHpRBMLRWD53r3Jj4aqVt6tHoF8B2ZQ

# Кошелёк — это отдельный экранированный ключ. Его адрес rand1… — это около 1,6 КБ текста
rand keygen && rand address

# Минт из фаусета подписывается валидатором, поэтому ему нужен RPC валидатора: он работает в
# локальной сети из двух валидаторов как есть; наблюдатель отвечает «ask a validator node». В chain 21
# фаусет минтит только на 16 кошельков, которые внесены в allowlist его genesis, и только от валидаторов, которых он называет
rand faucet                                  # 100 RAND в ноту, которую можете открыть только вы
rand balance                                 # сканирует дерево вашим ключом; больше никто не может
rand send <rand1 address> 1.5              # запрашивает подтверждение, строит доказательство (~2 мин), ждёт коммита

Валидаторы

Кворум

18 of 26

Genesis

ca76c2766ed6090ac6ba5dad86b724dd5d2b80c0edfaed287cd8b129e663ca9a

Конфиденциальный вызов

rand

# Соберите встроенный guest: выплатить остаток сверх 1000, если четыре приватных баланса его покрывают
rand program build --guest private_payment --arg 1000 --out pp.json
rand program deploy pp.json                  # выводит идентификатор программы (хеш её содержимого)

# Докажите локально; в цепочку попадают только доказательство, восемь выходных слов и запечатанный транскрипт входов
rand call <program id> --input 400 --input 250 --input 300 --input 75
rand receipt <tx>                            # выходы [1, 0, 25, 0, ...]: остаток, опубликованный как данные

# Позже откройте транскрипт и сверьте его с H_IN, опубликованным доказательством
rand open-call <tx>                          # входы: [400, 250, 300, 75] — вердикт: faithful

Цепочка видит идентификатор программы, уровень gas и восемь выходных слов. Балансов она не видит, а поскольку комиссия оплачивается экранированным бандлом, она не узнаёт и того, кто вызывал; выходы — это данные, а любой платёж — бандл, который составляет вызывающий. Замеры на Apple Silicon: доказательство около 7 с на уровне 10, размер доказательства около 1,2 МБ при профиле FRI с 80 запросами и проверка около 16 мс при прогретом ключе verifier, который узел вычисляет один раз для каждого уровня и использует повторно для разных программ.

Требования

ОС: Linux x86_64 или macOS arm64
Rust: 1.98.1, закреплён в rust-toolchain.toml; его установит rustup
Зависимости сборки: Компилятор C++, cmake, pkg-config, заголовочные файлы OpenSSL (RocksDB)
Первая сборка: От 10 до 20 минут: RocksDB и Plonky3 собираются из исходного кода
Порты: TCP 30303 для входящих соединений на публичных узлах; RPC на 127.0.0.1:8545
Сервер: Облачный экземпляр с 1–2 vCPU справляется с валидатором testnet
Часы: NTP (chrony) на валидаторе: он не голосует за блок, опережающий его собственные часы более чем на 15 с, поэтому отстающие часы незаметно прекращают голосование
Доказательство: Сегодня только на CPU: экранированный перевод занимает около двух минут на ноутбуке (доказательство авторизации 7 с и доказательство бандла около 110 с) и около 6 ГБ памяти; небольшой вызов добавляет около 30 с

Выберите роль

Наблюдатель открыто для всех

Тот же бинарный файл без --validator. Синхронизирует цепочку, проверяет каждый сертификат и каждое доказательство бандла и вызова, заново выполняет каждый блок, сравнивает квитанции и обслуживает JSON-RPC. Именно это запускает новый ключ в публичном testnet.
Валидатор с залогом

Голосует и предлагает блоки в рамках chained HotStuff. В chain 21, как и в chain 20, нового валидатора сначала допускают голосованием: валидаторы, держащие более двух третей стейка, подписывают действие AdmitValidator для его ключа. Затем он регистрирует ключ узла (rand-node register --v2), вносит в залог не менее 1,000 RAND из кошелька и входит в набор на границе третьей 1,000-блочной эпохи после внесения залога (задержка залога в две эпохи, как в chain 18). Chain 18 стартовала с 26 валидаторов по 1,000 RAND у каждого; для коммита более двух третей стейка, 18 из 26, должны быть в сети и голосовать. Сгенерируйте свой ключ: ни один ключ валидатора больше не хранится в репозитории, а файлы ключей, закоммиченные для более ранних chain, — это опубликованные seed-значения.
Кошелёк и prover локально

Клиент rand хранит 256-битный ключ расходования и ничего не подписывает: авторизацией служат два доказательства — небольшое, выполненное ключом расходования, и доказательство бандла 4-in-4-out. Он сканирует дерево в поисках собственных нот, строит оба доказательства на вашей машине — одинаково для RAND и для любого токена RPL — а при конфиденциальном вызове доказывает и саму программу. В цепочку попадают только доказательства, обязательства, нуллификаторы и запечатанные конверты.

Не запускаете узел? Тот же кошелёк доступен как приложение для iOS, Android, Chrome и Firefox: Кошельки.

Исходный код

randprotocol/fullnode

GPL-3.0-only · testnet работает на v0.8.0, последнем релизе

Проверка

Каждый узел проверяет всё

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

# Узел остановлен: хеши, QC, подписи, доказательства, повторное выполнение
rand-node verify --datadir ./data --mode full
rand-node verify --datadir ./data --repair

Тесты отказов выполняются на действующем testnet

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

Пока не реализовано

Перечислено, чтобы разрыв между статьёй и узлом был виден, а не угадывался.

›Постоянное состояние отдельных программ и вызовы между программами
›Компилятор в самом кошельке: программа — это либо встроенный собранный гостевой образ, либо образ, собранный отдельным инструментарием rand-guest
›Слэшинг и джейлинг, награды за блоки, рынки комиссий, маяк лидера на основе хеш-сортиции
›Аккумулятор нуллификаторов, отсечение доказательств после финализации, пакетирование доказательств
›Доказательство tier-20 для перевода SPL Token и рынок GPU-провers из статьи