Эта страница фиксирует обоснование каждого крупного проектного решения в Rand: свойство, которое должен обеспечивать компонент, допущение, при котором он его обеспечивает, и цену, принятую взамен. Страница составлена 29 сентября 2026 года по материалам этого сайта, краткого изложения whitepaper и эталонного полного узла (github.com/randprotocol/fullnode: его README, docs/ и docs/superpowers/specs/). Каждый ответ ссылается на документ, в котором изложено обоснование; пути относятся к репозиторию fullnode, если не начинаются с randprotocol.org.
Статус. Rand работает в testnet, которую эксплуатирует команда основателей, а протокол не проходил независимого аудита. Ряд описанных ниже решений реализуется поэтапно, от одного среза цепи к другому. Все цифры получены измерениями работающего узла на момент составления; ожидается, что они изменятся, и перед цитированием их следует измерить заново.
Криптографические примитивы
1. Почему ML-KEM-768 (Kyber) для шифрования нот?
Открытый текст ноты шифруется для получателя в конверте, который остаётся в публичном реестре бессрочно. Поэтому его конфиденциальность — необратимое свойство (вопрос 8): противник, получивший в любой более поздний момент криптографически значимый квантовый компьютер, смог бы расшифровать каждый исторический конверт, запечатанный эллиптической KEM, поскольку алгоритм Шора решает дискретный логарифм за полиномиальное время. ML-KEM стандартизирован в NIST FIPS 203, а его стойкость сводится к Module-LWE, для которой эффективный квантовый алгоритм неизвестен. Набор параметров 768 (категория 3 по NIST) выбран как компромисс между запасом стойкости и 1184-байтовым ключом инкапсуляции, который должен нести каждый адрес. Конверт — это ML-KEM-768 в сочетании с ChaCha20-Poly1305: 1348 байт, или 1860 байт с полем memo фиксированного размера.
Источник: randprotocol.org (раздел о постквантовой стойкости); README fullnode; docs/shielded.md §2
2. Почему коммитменты Poseidon2, а не Pedersen?
Коммитменты Pedersen обладают совершенным скрытием, но лишь вычислительной связыванием, причём их связывание сводится к допущению о дискретном логарифме, которое квантовый противник нарушает; противник, способный вычислять дискретные логарифмы, может раскрыть коммитмент как другое значение. Поскольку опубликованный сегодня коммитмент должен оставаться корректным и скрывающим в течение всего срока жизни реестра, схема должна опираться на допущения, которые, как считается, выдерживают квантового противника, а на практике это означает хеш-функцию. Poseidon2 — арифметизационно-ориентированный хеш, определённый над полем Goldilocks, поэтому его вычисление внутри STARK обходится в небольшое число ограничений. Один и тот же хеш реализует коммитмент ноты, дерево Merkle глубины 32 и нуллификатор.
Источник: randprotocol.org (раздел о постквантовой стойкости); docs/shielded.md §1–2
3. Почему две хеш-функции — BLAKE3 и Poseidon2?
Эти две функции оптимизированы под разные модели стоимости. Poseidon2 применяется везде, где хеш необходимо вычислять внутри доказательства, — в нотах, дереве коммитментов, нуллификаторах и внутренних таблицах zkVM, — поскольку его стоимость измеряется в ограничениях. BLAKE3 применяется везде, где доказательство не участвует и определяющей является нативная пропускная способность: хеши блоков, корень состояния по дереву, множеству нуллификаторов, реестру валидаторов и таблице программ, а также адреса валидаторов (дайджест BLAKE3 от открытого ключа). Poseidon2 сравнительно медленен на CPU; BLAKE3 сравнительно дорог для арифметизации. Каждая из функций используется только там, где применима её модель стоимости.
Источник: README fullnode (строка о подписях и хешах); docs/architecture.md
4. Почему Dilithium2 (ML-DSA) для подписей валидаторов?
Подписи консенсуса обеспечивают возобновляемое свойство (вопрос 8): последующий взлом схемы позволяет подделывать будущие сообщения, но не аннулирует задним числом уже финализированные блоки, поэтому схему в принципе можно заменить до появления квантового противника. Тем не менее решётчатая схема принята с генезиса, чтобы голоса консенсуса, соподписи хранителей моста и реестр валидаторов использовали один постквантовый тип ключа. Узел реализует набор параметров Dilithium2 третьего раунда (крейт crystals-dilithium), который отличается от итогового FIPS 204 ML-DSA-44; открытые ключи занимают 1312 байт, подписи — 2420 байт.
Источник: docs/superpowers/specs/2026-09-19-pq-cosignature-bridge.md §2; randprotocol.org
5. Почему прозрачный STARK (FRI над Goldilocks), а не SNARK?
Выбор следует из трёх требований. Во-первых, отсутствие доверенной настройки: корректность опирается только на стойкость хеш-функции к коллизиям, а не на структурированную опорную строку или дружественную к спариваниям кривую. Во-вторых, правдоподобная постквантовая корректность: аргумент не использует допущений о дискретном логарифме или спариваниях. В-третьих, совместимость со схемой коммитментов на основе хеша из вопроса 2. Цена — размер доказательства: доказательство пакета занимает примерно 1,3 МБ, что в 300–600 раз больше экранированной транзакции Zcash или Monero. Эта цена была принята и решается отдельно агрегацией на уровне блока (вопросы 31 и 34).
Источник: randprotocol.org; docs/block-space.md §1; docs/zkvm.md
6. Почему профиль FRI с 80 запросами, а не с 27?
Производственный профиль (80 запросов, коэффициент расширения 8, 20 бит proof-of-work grinding) даёт примерно 86 бит доказуемой корректности против примерно 42 бит у профиля с 27 запросами, при размере доказательства в 2,75 раза больше. Время проверки почти не меняется: с 809 мс до 838 мс на холодную и около 16 мс на прогретую. Доказуемой корректности отдан приоритет перед размером доказательства, а цена в размере перенесена на проект пространства блока и агрегации.
Источник: docs/block-space.md §1, §3
7. Почему постквантовая стойкость заявляется для каждого примитива, а не как «128 бит на весь протокол»?
В ранних редакциях утверждалась 128-битная постквантовая стойкость протокола в целом. Это утверждение несовместимо с границей Brassard–Høyer–Tapp, согласно которой квантовый противник находит коллизии в 256-битном хеше примерно за 2^85 запросов, поэтому от него отказались, а не уточняли. Теперь в статье стойкость указана для каждого примитива и каждой роли — 384-битный хеш транскрипта, 256-битные хеши там, где требуется лишь стойкость к прообразу, Dilithium2, ML-KEM-768 и FRI над расширением поля — при допущениях Module-LWE и Module-SIS, а хеш-функции моделируются как квантовые случайные оракулы. Хеш транскрипта в узле сейчас — Poseidon2; в документации это названо открытым расхождением в конфигурации.
Источник: randprotocol.org (раздел о постквантовой стойкости)
8. Что такое классификация «необратимое или возобновляемое» и почему она определяет выбор?
Свойство безопасности необратимо, если противник, получивший новую возможность в любой момент в будущем, может нарушить его задним числом для уже опубликованных данных; конфиденциальность нот и скрытие коммитментов относятся к этому виду, поэтому они должны быть квантово-стойкими уже в момент публикации. Свойство возобновляемо, если оно восстанавливается при каждом использовании, так что схему можно заменить до наступления угрозы; к этому виду относятся подписи и корректность доказательств. Каждый выбор примитива в этом разделе следует из классификации свойства, которое он защищает.
Источник: randprotocol.org (раздел о постквантовой стойкости)
Экранированный пул
9. Почему модель нот/UTXO без счетов и балансов?
Реестр на основе счетов публикует балансы по своей конструкции; чтобы скрыть их, нужно шифровать состояние и доказывать утверждения над шифртекстами, что существенно дороже. Пул нот хранит только коммитменты и нуллификаторы, ни один из которых не раскрывает ни владельца, ни сумму, так что публичное состояние не содержит информации о балансах. Единственное исключение — реестр валидаторов, веса стейка в котором должны быть публичными, чтобы реплики согласовывали состав кворума (вопрос 29).
Источник: docs/shielded.md §1–2; docs/staking.md §1
10. Почему адрес занимает ~1,6 КБ?
Экранированный адрес состоит из 32-байтового поля владельца pk и 1184-байтового ключа инкапсуляции ML-KEM-768, который нужен отправителю, чтобы запечатать конверт; в кодировке base58 это примерно 1667 символов. Длина — прямое следствие постквантовой KEM. Утверждённый проект (короткие экранированные адреса, 2026-09-17) заменяет адрес идентификатором получателя примерно в 256 бит, который разрешается в обновляемую запись, подписанную ключом траты и отдаваемую обозревателем, так что ключ инкапсуляции загружается, а не переписывается вручную.
Источник: docs/shielded.md §1; docs/superpowers/specs/2026-09-17-short-shielded-address.md
11. Почему каждый ключ выводится из одного 256-битного ключа траты?
Весь остальной ключевой материал — детерминированная функция единственного секрета sk: ключ просмотра nk = H(NK, sk), поле владельца pk = H(PK, nk), нуллификатор H(NF, nk, cm), исходящий ключ просмотра и ключ декапсуляции ML-KEM, каждый со своим разделителем доменов. Поэтому файл ключа хранит только sk, резервная копия — это одно значение, а повторное сканирование дерева с листа 0 восстанавливает каждую ноту. Поскольку второй копии для восстановления нет, кошелёк отказывается перезаписывать существующий файл ключа.
Источник: docs/shielded.md §1
12. Почему фиксированная форма пакета «4 входа — 4 выхода»?
Фиксированная форма делает каждый пакет одинакового размера и структуры независимо от того, что он переносит. Каждый пакет публикует ровно четыре нуллификатора и четыре коммитмента; неиспользуемые слоты — это ноты нулевой стоимости (dummy), а выход со сдачей публикуется, даже когда его значение равно нулю, поскольку его отсутствие выделяло бы транзакцию. Исходная спецификация предусматривала 2 входа и 2 выхода по образцу Sapling. С пакетом скрытого актива она расширена до 4 входов и 4 выходов: слоты 0–1 несут приватный актив, а слоты 2–3 — RAND для комиссии; четыре слота вместо трёх позволяют переводу токена оплатить комиссию не более чем из двух нот RAND.
Источник: docs/shielded.md §2; docs/superpowers/specs/2026-09-19-hidden-asset-bundle-design.md §3
13. Почему одно доказательство переводит любой актив (RAND, zUSD, токены RPL)?
Перед chain 14 перевод токена содержал два пакета (bundle): один для комиссии в RAND, другой для актива. Это требовало двух доказательств и показывало любому наблюдателю, какой токен был перемещён. Guest со скрытым активом принимает идентификатор актива как закрытый вход, поэтому перевод zUSD неотличим от платежа в RAND. Guest укладывается в tier 14 (примерно 100 с и 5,7 ГБ памяти) только потому, что читает свои входные данные в цикле и объединяет с ним проверку принадлежности к дереву Меркла. Полностью развёрнутая реализация требует tier 16 (примерно 400 с и 21 ГБ), что превышает память машины с 16 ГБ.
Источник: docs/superpowers/specs/2026-09-19-hidden-asset-bundle-design.md §1–3
14. Почему комиссия публична и выплачивается пропозеру?
Публичная комиссия согласуется с публичным реестром стейка и делает допуск транзакций недорогим: узел может проверить минимальную комиссию до выполнения какой-либо верификации. Доказательство пакета обеспечивает выполнение уравнения баланса Σ входов = Σ выходов + комиссия + сжигание, поэтому комиссия оплачивается из скрытых нот без раскрытия того, какие именно ноты использованы. Принятая цена такого решения состоит в том, что размер комиссии может раскрывать класс транзакции (перевод или вызов программы).
Источник: docs/superpowers/specs/2026-09-11-shielded-pool-design.md (таблица решений); docs/fees.md §1
15. Почему у депозитов (mint, bridge attest) сумма публична?
Стоимость, поступающая в пул, должна учитываться публично, а аттестация моста является публичным свидетельством того, что в исходной сети произошла соответствующая блокировка. Возникающая видимость ограничена шагом входа и аналогична транзакции из прозрачного адреса в экранированный (t-to-z) в Zcash; последующие траты внесённой ноты скрыты.
Источник: docs/superpowers/specs/2026-09-11-shielded-pool-design.md; docs/shielded.md (таблица публичных данных)
16. Почему memo представляет собой поле фиксированного размера в 512 байт?
Поле фиксированной длины гарантирует, что реестр не раскрывает ни наличие memo, ни его длину: в сети с поддержкой memo каждый конверт, создающий ноту, включая фиктивные и сдачу, занимает ровно 1 860 байт. Memo передаётся только внутри зашифрованного конверта, но не в ноте, не в обязательстве и не в доказательстве, и доступно ровно тем сторонам, которые уже могут расшифровать ноту. Некорректное memo декодируется как пустое, чтобы оно не могло сделать саму ноту невосстановимой.
Источник: docs/shielded.md §2; docs/superpowers/specs/2026-09-26-address-sharing-and-memo-design.md
17. Почему доказательство строится локально и как делегированный доказывающий не нарушает это свойство?
Само доказательство является авторизацией траты: пакет не содержит ни подписи, ни поля отправителя, поэтому ключ траты никогда не должен покидать кошелёк. Доказательство пакета tier 14 требует примерно 5,7 ГБ памяти, что превышает возможности телефонов и браузеров, отсюда и делегированный доказывающий. Раздельная авторизация (bundle guest v3, параметр генезиса hc_auth) разделяет эти две роли: доказывающий получает только ключ просмотра nk и строит доказательство пакета, а кошелёк с помощью sk строит небольшое доказательство авторизации tier 10. Таким образом, доказывающий может построить доказательство пакета, но не может авторизовать трату (вопрос 36).
Источник: docs/prover.md §1; docs/shielded.md (раздельная авторизация); docs/superpowers/specs/2026-09-28-delegated-proving-design.md
18. Почему окно якорей составляет 256 блоков?
Доказательство строится относительно определённого корня дерева обязательств (его якоря), а построение доказательства пакета tier 14 занимает примерно 100 с. Поэтому реестр должен принимать якоря, которые на момент отправки устарели на несколько минут. В исходной спецификации окно составляло 64 блока; оно было расширено до 256 блоков по мере сокращения интервала между блоками, чтобы его длительность в реальном времени оставалась больше времени построения доказательства.
Источник: docs/shielded.md; docs/superpowers/specs/2026-09-11-shielded-pool-design.md
zkVM и конфиденциальные вычисления
19. Почему в качестве ISA для guest выбрана RV32I, а не RV64?
32-битное слово раскладывается ровно на четыре байтовых лимба, а простое число Goldilocks p = 2^64 − 2^32 + 1 достаточно велико, чтобы произведение двух 32-битных значений никогда не переполняло поле. RV64 удвоила бы число столбцов лимбов в таблицах ALU и памяти. Кроме того, RISC-V является целевой платформой существующих распространённых компиляторов, поэтому программы guest представляют собой обычные скомпилированные бинарные файлы, а не программы на специально созданном языке.
Источник: docs/zkvm.md §2; research/docs/01-isa.md («Why RV32, not RV64»)
20. Почему Goldilocks, а не 256-битное поле?
Goldilocks — это 64-битное простое число, арифметика которого эффективно отображается на нативные 64-битные инструкции процессора и мультипликативная группа которого содержит большую подгруппу порядка степени двойки, как того требует FRI. Вместе с 32-битными словами это делает каждую строку трассы узкой, благодаря чему доказательство в производственном профиле осуществимо на ноутбуке. Корректность, теряемая при работе в малом поле, восстанавливается выбором challenge-значений FRI из расширения поля.
Источник: docs/zkvm.md §2; randprotocol.org (раздел о производительности)
21. Почему используются уровни газа (gas tiers), а не учёт газа по каждому опкоду?
Газ по опкодам существует в Ethereum потому, что каждый узел заново выполняет каждую транзакцию, а длина исполнения заранее не ограничена. В Rand ни один узел не выполняет программу: отправитель выполняет её один раз, вне сети, а узлы проверяют единственный STARK, стоимость верификации которого зависит только от tier, но не от выполненных вычислений. Завершение исполнения обеспечивается самим tier: исполнение, не остановившееся за 2^t циклов, не допускает доказательства на tier t. Цена складывается из фиксированного минимума и оценки газа, ограниченной заголовком, а ёмкость блока задаётся бюджетом в байтах. Газ появляется только внутри guest-интерпретаторов EVM и sBPF, как закрытое состояние, где он необходим для воспроизведения семантики исходной сети.
Источник: docs/fees.md §3–4; docs/superpowers/specs/2026-09-28-gas-model-design.md
22. Почему трасса разделена на девять таблиц, связанных шинами LogUp?
Единая монолитная таблица дополняла бы каждую строку до ширины самой широкой операции. Разделение трассы на девять таблиц — CPU, memory, ALU, range, nibble, Poseidon2, program, input и public, — каждая из которых дополняется лишь до собственной высоты, сохраняет малый общий размер трассы. Аргументы LogUp устанавливают отношения между мультимножествами разных таблиц. Таблицы Keccak и SHA-256 необязательны и включаются только тогда, когда guest вызывает соответствующий системный вызов.
Источник: docs/zkvm.md §5
23. Почему вызов программы публикует только восемь выходных слов?
Вызов программы — это доказательство того, что публичный код был корректно выполнен на закрытых входных данных; реестр фиксирует только квитанцию (receipt). Восьми 32-битных слов достаточно, чтобы связать результат, обязательство или решение, а фиксированный размер выхода гарантирует, что форма квитанции ничего не раскрывает о программе. В настоящее время выходы являются только данными: сама программа не может переводить стоимость.
Источник: randprotocol.org/usecases (примечание о платформе); docs/confidential.md
24. Зачем нужен конверт входных данных вызова?
Вызывающая сторона, сохранившая закрытые входные данные, впоследствии может продемонстрировать, над чем был произведён вызов. Конверт входных данных вызова делает это устойчивым: входные данные хранятся в зашифрованном виде рядом с вызовом, и назначенный аудитор может расшифровать их с помощью ключа. Это распространяет избирательное раскрытие — конфиденциальность для рынка, открытость для назначенного регулятора — с платежей на исполнение программ.
Источник: docs/confidential.md («Конверты входных данных вызова»)
25. Почему изменение набора ограничений является хард-форком?
Каждый узел заново проверяет каждое доказательство при синхронизации, а доказательство допустимо только относительно того набора ограничений (AIR), при котором оно было построено. Поэтому изменение AIR меняет множество допустимых цепочек и вводится при разрезе генезиса, а не принимается узлами по одному.
Источник: docs/architecture.md («Почему изменение набора ограничений является хард-форком»)
26. Почему эталоном является эмулятор, а не AIR?
Эмулятор — это читаемая спецификация машины, а AIR — кодировка этой спецификации в виде полиномиальных ограничений. Если они расходятся, ошибка по определению в AIR. Это помещает нормативное определение в тот артефакт, который человеку удобнее всего проверять.
Источник: docs/zkvm.md §5
Консенсус и узел
27. Почему именно chained HotStuff BFT?
Chained HotStuff обеспечивает детерминированную финальность: при кворумах, взвешенных по стейку и превышающих две трети, блок становится финальным, когда над ним сформированы три последовательных сертификата кворума, а финальный блок никогда не реорганизуется. Измеренный интервал между блоками составляет 1,2 с, а время до финальности — примерно 3,6 с. Предполагаемым институциональным пользователям нужна финальность расчётов, под которую можно проводить записи в учёте, а цепочка с вероятностной финальностью её не обеспечивает.
Источник: README fullnode; randprotocol.org (раздел о производительности); docs/architecture.md §6
28. Почему верификация доказательств вынесена из цикла консенсуса?
Узел проверяет каждый STARK при допуске транзакции (примерно 32 мс в прогретом состоянии), до её ретрансляции, поэтому верификация никогда не лежит на критическом пути предложения блока. Интервал между блоками определяется задержкой консенсуса, а не размером доказательства. Проверки упорядочены по стоимости, а STARK проверяется последним, так что некорректная транзакция отклоняется до самого дорогого шага.
Источник: randprotocol.org; docs/architecture.md («Как это работает»)
29. Почему реестр валидаторов публичен, если всё остальное экранировано?
Все реплики должны согласовать, какие валидаторы вправе предлагать блоки и какие голоса составляют кворум, а это требует публичности весов стейка. Поэтому реестр хранит суммы стейка в открытом виде. Связь с владением остаётся скрытой: бонд финансируется из экранированной ноты, а вывод выплачивается в неё, и ни одна из этих операций не раскрывает, чья это нота.
Источник: docs/staking.md §1
30. Почему синхронизирующийся узел заново исполняет каждый блок, а не доверяет сертификатам?
Узел, присоединяющийся с опозданием, проверяет каждый кворумный сертификат, заново проверяет каждое доказательство bundle и каждое доказательство вызова и сравнивает полученные квитанции, прежде чем принять цепочку. Поскольку корректность устанавливается доказательствами, а не одними лишь подписями, эта процедура не подвержена атакам дальнего диапазона (long-range attacks), которые затрагивают цепочки, защищённые только подписями. Удаление доказательств из истории было отвергнуто, так как оно лишило бы систему этой гарантии.
Источник: docs/architecture.md; docs/aggregation.md (introduction)
31. Почему лимит блока остаётся равным 4 MiB, если доказательство превышает 1 MB?
При фиксированном лимите размер блока расти не может; когда спрос превышает ёмкость, ограничивается пропускная способность (до трёх экранированных переводов на блок при профиле с 80 запросами). Ограничение пропускной способности было признано более безопасным режимом отказа, чем неограниченный рост блока. Выбранное решение — агрегация на уровне блока, одно рекурсивное доказательство на блок, а не повышение лимита или снижение уровня стойкости (soundness).
Источник: docs/block-space.md §1, §6
32. Почему testnet обрезает историю до одних суток?
Кворумный сертификат с 18 подписями Dilithium2 занимает примерно 44 KB и хранится дважды на каждый блок. При преимущественно пустых блоках каждые 1,4 с это давало примерно 6,6 GB на узел в сутки; диски узлов заполнились, и цепочка потеряла кворум на высоте 248 953. Теперь полные узлы testnet хранят историю за одни сутки, один архивный узел хранит её целиком, а узлы mainnet-beta будут хранить её целиком. Состояние реестра — дерево, множество нуллификаторов, регистр и программы — не обрезается никогда.
Источник: docs/superpowers/specs/2026-09-24-history-pruning-design.md
33. Почему libp2p?
Узел использует TCP с Noise и Yamux, gossipsub для транзакций и голосов, Kademlia со списком начальной загрузки для обнаружения пиров, mDNS в локальных сетях и запрос–ответ для синхронизации блоков. Это стандартные, широко распространённые компоненты, поэтому узел наследует оценку пиров, переподключение и обновления транспорта, а не поддерживает собственные реализации.
Источник: fullnode README (networking row)
Рынок доказательств и агрегация
34. Почему агрегация доказательств на уровне блока?
Если каждый bundle несёт собственное доказательство размером примерно 1,3 MB, объём блока растёт линейно с числом bundle. Одно рекурсивное доказательство STARK на блок, проверяющее все N доказательств bundle, сохраняет стоимость доказательства в цепочке постоянной по N. Тогда валидаторы проверяют одно агрегированное доказательство (примерно 16 ms в прогретом состоянии) на CPU, так что валидировать по-прежнему может обычное оборудование, а агрегаторы с GPU конкурируют на отдельном рынке без разрешений за долю комиссий, выделяемую на доказательство, и за субсидию за блок.
Источник: docs/aggregation.md §1
35. Почему три роли — валидатор, агрегатор, делегированный прувер?
У трёх ролей разные требования к оборудованию, и оплачивают их разные стороны. Валидатор упорядочивает и проверяет транзакции на CPU, и ему платят из доли комиссий, выделяемой на проверку. Агрегатор строит рекурсивное доказательство блока на GPU, и ему платят из доли на доказательство и из субсидии. Делегированный прувер строит одно доказательство bundle для отправителя, чьё устройство на это не способно (телефон или браузер), и получает оплату от этого отправителя приватно. Разделение ролей сохраняет проверку недорогой, а доказательство делает конкурентным.
Источник: docs/prover.md §1
36. Почему делегированный прувер не может украсть средства?
При раздельной авторизации прувер получает ключ просмотра nk, но не ключ расходования sk. Доказательство bundle фиксирует c = H(AUTH, nk || salt), а отдельное доказательство авторизации кошелька демонстрирует знание sk для того же c. Без sk прувер может вычислить доказательство bundle, но не может построить корректную авторизацию, а кошелёк проверяет возвращённое доказательство перед его отправкой.
Источник: docs/shielded.md (split authorisation); docs/prover.md §8
Мост и zUSD
37. Почему блокировать USDT/USDC в их родных цепочках, а не выпускать новый стейблкоин?
Нативный выпуск в Rand поставил бы ёмкость резервов в зависимость от решений эмитентов о развёртывании, которые находятся вне контроля проекта. Блокировка USDT и USDC в Ethereum, BSC, Tron и Solana привлекает резервы из цепочек, где эти активы уже обращаются, и не вводит нового эмитента: каждая единица zUSD является требованием на USDT или USDC, хранящиеся в общедоступном для чтения кастодиальном контракте.
Источник: randprotocol.org (reserve section)
38. Почему набор хранителей t-из-n и почему об этом говорится прямо?
Аттестация — единственное свидетельство, доступное Rand, о том, что блокировка произошла в другой цепочке, поэтому она должна быть подписана пороговой группой; для действительной аттестации требуются подписи более чем двух третей хранителей. Возникающее допущение о доверии заявлено явно. Фактическая гарантия определяется более слабым из двух свойств: платёжеспособности резервов и целостности моста; коалиция из t хранителей может санкционировать выпуск без соответствующей блокировки; а риск ограничен объёмом активов в кастодиальном хранении в каждой цепочке. Это допущение изначально было аргументом против создания моста. Оно не снято, а принято в обмен на ёмкость резервов.
Источник: randprotocol.org (reserve section, «Чего это стоит»)
39. Почему сопровождать аттестацию ECDSA соподписью Dilithium2?
В исходных цепочках нет верификатора решётчатых подписей, поэтому выпуски в этих цепочках остаются защищены классической ECDSA, а риск ограничен объёмом хранимых активов и лимитами. Каждое сообщение, которое реестр Rand принимает от хранителей, — депозиты и ротации набора хранителей — должно дополнительно нести кворум подписей Dilithium2 от тех же хранителей. Поэтому путь выпуска (mint) устойчив к квантовым атакам, хотя внешние конечные точки таковыми не являются. Соподписи передаются вместе с аттестацией и не требуют изменений в развёрнутых контрактах.
Источник: docs/superpowers/specs/2026-09-19-pq-cosignature-bridge.md §1
40. Почему множитель ослепления ноты депозита выводится, а не выбирается?
Раньше обязательство ноты депозита не определялось до тех пор, пока релеер не отправлял аттестацию, поэтому два релеера могли отправить одну и ту же аттестацию с разными нотами. Детерминированный вывод множителя ослепления r из аттестации фиксирует обязательство, так что конкурирующие отправки сходятся на одном обязательстве, и депозит не может быть выпущен дважды.
Источник: docs/bridge.md (F1, chain 14)
41. Почему USDT, заблокированный в Tron, может выйти как USDT в Ethereum?
zUSD взаимозаменяем: каждая единица является требованием на совокупный резерв, а не на цепочку, через которую она поступила. Разделение входа и выхода позволяет ликвидности перемещаться туда, где на неё есть спрос, при условии что в цепочке назначения достаточно резервов. В работе о стейблкоине доказано, что инвариант S ≤ Σ_c R_c — совокупное предложение ограничено суммой резервов по цепочкам — сохраняется при каждом переходе состояния.
Источник: randprotocol.org (reserve section)
42. Почему экранирование скрывает распределение, но не количество?
Совокупное предложение zUSD публично в реестре токенов, а резерв каждой цепочки — публичный баланс, поэтому платёжеспособность может проверить любой; скрыто распределение активов между владельцами. Действует одно ограничение: четыре резервных баланса нельзя наблюдать атомарно в один момент времени, поэтому для этих цепочек проверка обнаруживает неплатёжеспособность постфактум, а не предотвращает её.
Источник: randprotocol.org (reserve section)
43. Почему сжигание — единственная транзакция, которая называет свой актив?
Сжигание высвобождает конкретный актив в конкретной цепочке, поэтому кастодиальный контракт должен узнать, какой это актив и какая цепочка. Все остальные транзакции переводят неопознанный актив. Сжигание также несёт комиссию моста, поскольку это единственная транзакция моста, отправитель которой является бенефициаром.
Источник: docs/architecture.md; docs/shielded.md §2
Соблюдение требований и раскрытие информации
44. Почему ключи просмотра, а не «приватность от всех»?
Регуляторы не приняли системы приватности, в которых раскрытие зависит от сотрудничества проверяемой стороны, о чём свидетельствует случай Tornado Cash. Поэтому Rand рассматривает раскрытие как объект протокола. Владелец или регулируемый посредник хранит ключ просмотра; аудитор может расшифровать транзакции, указанные в законном запросе; а проектная цель — ключи ограниченной области действия, которые раскрывают контрагента и сумму, не раскрывая торговую стратегию. Для таких приложений, как расчёт заработной платы, эта возможность аудита — требование, а не ограничение.
Источник: randprotocol.org/usecases (regulation section; payroll case)
45. Почему исходящий ключ просмотра отделён от входящего?
Разделение позволяет отправителю доказать, что он заплатил, не получая доступа к истории получателя, и наоборот. Исходящий ключ просмотра ovk расшифровывает конверты, которые отправил кошелёк; ключ декапсуляции ML-KEM расшифровывает конверты, отправленные на него; а ключ отдельной транзакции раскрывает ровно один выход третьей стороне.
Источник: docs/shielded.md §1–2
Известные ограничения
46. Что доказательства раскрывают сегодня и почему это задокументировано?
Обзор от 2026-09-27 показал, что при гостевой программе v1 (chains 14–15) каждое доказательство bundle раскрывает, какие входные слоты содержат реальные ноты, и вес Хэмминга индекса каждого потраченного листа. Причина двойная: итоги LogUp по таблицам публикуются без ослепления, а поток управления гостевой программы ветвится в зависимости от того, является ли вход фиктивным. Решение — гостевая программа без ветвлений (v2), которую выберут при следующем генезисе. Это замечание опубликовано, потому что сеть является testnet, а документация служит её журналом аудита.
Источник: docs/shielded.md («Что доказательства раскрывают сегодня»)
47. Почему рост состояния оценивается слишком низко?
Ethereum тарифицирует запись в хранилище, потому что сохранённое состояние накладывает постоянные издержки на каждый узел. Rand в настоящее время тарифицирует рост дерева обязательств, множества нуллификаторов и хранилища программ только через сбор за слово при развёртывании и фиксированный сбор за bundle. Для testnet этого достаточно, но вопрос ценообразования записан как открытый и подлежит решению до mainnet; для его решения не требуется учёт стоимости по каждому опкоду.
Источник: docs/fees.md §3 (оговорки)
48. Почему независимый аудит до сих пор не завершён?
Протокол находится в активной разработке в testnet, которым управляет команда, и до стабилизации конструкции ожидаются дополнительные наборы ограничений и новые срезы цепочки. Сайт сообщает об этом на каждой странице. Внутренние раунды аудита (v3–v5) опубликованы в docs/consensus.md и в спецификациях конструкции, чтобы у будущего внешнего аудита была полная запись для работы.
Источник: randprotocol.org (нижний колонтитул); docs/consensus.md