Я начал делать стейкинг RLS ещё с этапа предварительных обещаний, читать официальный блог — это, по сути, вошло в привычку. 12 сентября в этой статье про проверяемость (auditable) во второй половине перечислены шесть стандартов, и сказано, что они все выполняются математическим образом по построению. Я с этим согласен, но фраза «выполняется по построению» — это утверждение, которое можно проверить, а не то, что нужно просто принимать на веру. Поэтому я потратил неделю: по каждой из этих шести позиций я искал соответствующие вещи в публичном исходном коде, технической документации и в ончейн-интерфейсах; теперь делюсь этим с вами.
Сначала — о классификации. Я считаю, что это полезнее, чем большинство дискуссий на тему «приватность или прозрачность». Для проверяемости есть три пути: математическое принуждение — когда всё заложено прямо в криптографических конструкциях; аппаратное доверие — опираясь на целостность доверенной среды исполнения (trusted execution environment); и стратегический контроль доступа — то, кто что может увидеть, определяется настройками со стороны оператора сети.
На этом основании она выводит шесть стандартов институциональной проверяемости, а затем утверждает, что математика обеспечивает выполнение всех шести через конструкцию.
Чтобы не уходить в туман, зафиксирую сценарий: банк участвует в пилоте CBDC, и аудитору ЦБ нужно просмотреть транзакции этого банка в сети. Бразильский Drex — это как раз такой сценарий, Rayls как раз проводит в нём пилот. Вопрос здесь всего один: почему то, что видит аудитор, вообще заслуживает доверия.
Первая и вторая: выборочное раскрытие и ограничение диапазона (scope limitation).
Смысл этих двух пунктов сводится к одному и тому же: ключ наблюдения.
Публичный GitHub Rayls: в каталоге cryptography репозитория relayer есть mlkem.go. Там GenerateSalt использует наблюдаемую публичную ключевую инкапсуляцию ML-KEM-768 принимающей стороны для общего секрета; RecoverSalt использует локальный ML-KEM-768 ключ наблюдения, чтобы раскрыть (decapsulate) секрет. Вызваются стандартные функции Go NewEncapsulationKey768 и NewDecapsulationKey768. Имена переменных прямо: view public key и view secret key.
Поэтому криптографический базис ключа наблюдения — это ML-KEM-768, и этот пункт можно проверить по источникам.
Скажу ещё одну вещь о смысле. В статье Rayls от 30 августа про квантовую подготовку отдельно подчёркивалось: если в утверждении «квантобезопасно» не указаны параметры уровня, то это не позиция, а просто ярлык. И приведённые примеры как раз не одно и то же: ML-KEM-512 и ML-KEM-1024. В той статье про своё обновление они написали только «заменено на ML-KEM». В коде же это указано как 768. Это не дефект: 768 — официальный NIST параметрический набор, и именно он в индустрии рекомендуется как дефолт для корпоративных развёртываний. Это просто факт, который раньше нужно было читать в коде, а сейчас можно напрямую цитировать.
Раз раз уровни определены, то стоимость смены уровня можно посчитать. FIPS 203 фиксирует размеры: у 768 — упаковочный публичный ключ 1184 байта, шифртекст 1088 байт; у 1024 обе величины — 1568 байт.
Ключевое — частота, и в документе по управлению ключами это тоже прописано: упаковка (encapsulation) выполняется один раз для каждой пары участвующих сторон при развёртывании сети; шифртекст хранится на private network hub, и после этого каждое сообщение несёт только небольшой тэг. Поэтому оно не растёт с объёмом транзакций. Сеть из 30 организаций имеет 435 пар, разница между двумя уровнями — примерно 215 КБ; даже если 60 организаций и 1770 пар, разница всё равно меньше 1 МБ, и она одноразовая.
Этот размер настолько мал, что не имеет смысла, и именно в этом заключается вывод: если конкретное развёртывание требует более высокого уровня, сопротивление не будет исходить ни от пропускной способности, ни от хранилища — это просто разовая правка кода. В общих обсуждениях миграции на постквантовые решения выбор параметров обычно является компромиссом по производительности, а здесь — не так.
Границы ограничены этой конкретной позицией: техническая документация дополнила вторую половину — возможности наблюдения можно ограничивать по временным окнам и по аккаунтам.
Третий пункт: разделение видимости и полномочий
Фраза в технической документации звучит жёстче, чем в блоге: ключ расходования и ключ наблюдения математически независимы и нельзя вывести один из другого. В резюме по security review сказано ещё прямее: права на наблюдение отделены от прав на расходование криптографией, а не настройками, поэтому одна ошибка конфигурации не может превратить право чтения в право записи.
Документ по управлению ключами ещё и исправил моё само собой разумеющееся. Со стороны организаций все ключевые материалы обрабатываются единым компонентом под названием Cryptographic Trust Suite, работающим в границах самой организации. Relayer никогда не хранит никаких ключей — он лишь предоставляет сервисы шифрования/дешифрования по запросу. Права аудитора на чтение основаны на следующем: каждая организация шифрует свой ключ наблюдения публичным ключом оператора, вместе с кодом аутентификации сохраняет это на private network hub как часть записи участника; затем аудиторский сервис при запуске забирает это.
Тут есть побочный документ, который сам это проговаривает: организации на хабе видят, какие записи участников там существуют, а значит, знают, что у них есть в доступном для чтения виде. Сам факт выдачи видимости — тоже видимая вещь.
Кстати, эта страница с тремя типами таблиц ключей подтверждает то, что я видел в коде: ключи подписи ECDSA на secp256k1, ключи наблюдения ML-KEM, ключи оплаты трат BN254 с Baby JubJub. Документация и исходники полностью совпадают.
Четвёртый пункт, проверяемая корректность
Этот блог держится на zero-knowledge proofs: у Rayls есть специальный gnark-api-сервис для генерации и верификации Groth16-доказательств.
В документе по транзакциям Enygma приведены несколько конкретных параметров, на которые обычно никто не ссылается. Размер анонимной группы — 2 или 6, то есть каждая передача пакуется вместе ещё с одной или с пятью передачами, наблюдатель не различает, кто инициировал. Одна crossTransfer максимум указывает на 5 целевых цепочек и несёт до 5 вызываемых действий. Атомарность батча гарантируется смарт-контрактом Enygma на private network hub: он сначала проверяет доказательства всего батча, и только если все цели проходят, чеканятся соответствующие монеты.
Есть ещё один операционный «ценник», и документ об этом говорит прямолинейно: суммарно батчинг, генерация доказательств и проверка хабом — это порядок десятков секунд. Значит, планировать нужно так, а не как при внутриорганизационной транзакционной финальности на миллисекунды/субсекунды. Проверяемая корректность не бесплатна — её цена и есть эти десятки секунд.
Но есть одно место, которое стоит отдельно вынести, потому что оно затрагивает четыре материала.
Техническая документация говорит о том, что обязательство (commitment) Pedersen «скрывает одно значение, одновременно связывая коммитера с этим значением, так что впоследствии изменить его невозможно». Связность трактуется как свойство, которое следует из утверждения. Статья про квантовую подготовку за август пометила это как «не требующее обработки», то есть по сути оно уже устойчиво к квантам. В коде enygma_math.go видно, что используются два независимых генератора на кривой BabyJubJub; вычисляется v*G + r*H — это стандартная и корректная конструкция Pedersen. А две академические статьи Rayls — IACR с номерами 2025/1639 и 2025/1638 — описывают весь дизайн словом quantum-private (то есть «квантовая конфиденциальность»): объяснение в том, что квантовый противник не может вывести платёжщика, получателя и сумму транзакции. Это чистое утверждение про конфиденциальность.
Моё прочтение такое: из четырёх материалов только формулировки статьи точные. BabyJubJub построена на BN254 в скалярном поле, поэтому свойство скрытности (hiding) выполняется против квантового противника — это как раз та часть утверждения статьи. Связность (binding) зависит от дискретного логарифма — и это как раз та часть, которую статья не утверждает.
Для организации, которая должна уметь доказывать свою комплаенс-позицию и выдерживать противодействующий аудит, утверждения «квантовый противник не видит мой баланс» и «квантовый противник не может подделать фальшивый баланс» — разные вещи, а в документации и в блоге их написали как одно и то же. В статье это не свалено в одно.
Пятый пункт, отзыв (revoke)
Я долго искал: в документации Rayls есть страница с ответом в документе про параметры «Private Network Design Options». Но это не то же самое, что описано в блоге, и, на мой взгляд, тут есть даже более интересный аспект.
Аудитор — это назначаемая операторами роль; параллельно с ней есть участники и эмитент. Ключевое: видимость аудитора — не выключатель, а уровень (уровень/grade). В этой документации уровни показаны через три примера.
На уровне сети CBDC: аудиторы могут расшифровывать транзакции между узлами. На уровне платформы токенизированных активов: аудиторы отслеживают, проверяя решения Pedersen, опубликованные каждым узлом в хаб; в документации прямо написано, что у аудитора нет прямого доступа к данным зашифрованной транзакционной нагрузки — он видит только доказательства, а не содержимое. Самый крайний уровень — NFT-рынок, который ведётся DAO: роль аудитора выполняет верификатор, подтверждаемый сетью; по умолчанию доступ равен нулю, и расшифровка для конкретной транзакции включается только тогда, когда проверка доказательства показывает мошенничество.
Три уровня поставлены рядом: строка про аудитора в браузере — «степень расшифровки настраивается на этапе сборки» — и реализована.
Вернёмся к пункту из блога. Блог утверждает, что видимость можно отозвать, а отзыв обеспечивается криптографией. Документация предлагает другой дизайн: видимость задаётся по уровням во время развёртывания сети, а не происходит отзыв постфактум. Оба варианта ограничивают аудитора: один — это предварительное ограничение, другой — постфактум отмена.
Средства отзыва действительно есть: роль можно обновлять, состояние участника может быть активным, замороженным, отключённым; заморозка выполняется операторами через смарт-контракт управления ParticipantStorage. Но отозвать видимость, которую один аудитор уже получил, — реализации с таким описанием я не нашёл. Есть деталь, из-за которой этот вопрос становится очень конкретным: в документе сказано, что аудитору при каждом новом подключении узла выполняется обмен ключами Diffie-Hellman, и возможности доступа передаются в форме ключевых материалов. Отзыв роли может помешать будущим выдачам, но можно ли сделать недействительными уже переданные ключевые материалы — это ещё предмет моего исследования.
Шестой пункт, персистентность
Этот пункт — наоборот к пятому: в блоге его описали слишком скромно.
Там сказано, что персистентность относится к управлению ключами и это решаемо; читается как оставленный «пробел». Но документация по управлению ключами уже превращает это «можно решить» в конкретное решение. Хранилище ключей подключается как модуль к тому, что уже есть у организации: AWS KMS, Google Cloud KMS, Azure Key Vault, локальные HSM; в среде разработки используются локальные файлы. Для статики используется шифрование «конвертом», и персистентно сохраняется шифртекст, а не материалы ключей.
Самое ключевое — эта строка. Потому что каждый раз шифрование/дешифрование проходит через сервис управления ключами, принадлежащий самой организации: эти сервисы и сами по себе порождают аудиторские следы (audit trails), и покрытие ключевых операций Rayls по сути совпадает с покрытием любых других операций, которые делает сама организация. Вывод для отдела комплаенса из документа такой: не нужно создавать для этого отдельную поверхность аудита. Именно этого хочет персистентность: аудиторский след висит в собственной системе организации, а не в «закрытых» логах какого-то вендора.
Поворот ключей (ротация) тоже описан очень детально: у каждой цепочки может быть несколько ключей подписи, они ротируются по сценариям использования; для каждой пары ключей отдельно отслеживается nonce. Ключ, которым уже подписали ожидающую транзакцию, остаётся валидным до тех пор, пока эти транзакции не будут завершены (settled). Это решает ровно ту щель, которая чаще всего «ломается» в ротации.
Но есть одно ограничение границы: в том разделе, где описана ротация, речь идёт о ключах подписи; ротацию ключей наблюдения на этих страницах я не видел. А вопрос персистентности как раз в том, сможет ли аудит просматривать следы спустя годы — и это больше зависит от того, что происходит на стороне ключей наблюдения.
Тот инструмент, которым аудиторы реально пользуются
До этого я в основном читал про криптографию, но аудиторы на практике садятся и используют инструмент. Документация прямо говорит: браузер private network аудитора доступен только аудитору, операторы и другие участники не имеют доступа; он даёт декодированное backview-визуализацию кроссчейн-транзакций.
Ограничение по scope: это покрывает только кроссчейн-транзакции, записи которых попадают в private network hub; аудиторы не могут получить доступ к транзакциям, которые происходят внутри собственного Sovereign-лёджера конкретной организации. Поэтому видимость аудита — между организациями, а не внутри одной организации.
Тогда есть ли пример, который можно проверить полностью
Да, и только один — потому что сама архитектура заранее определяет, что большая часть вещей будет недоступна для просмотра.
Официальная документация объясняет причину: транзакции Enygma исходят из собственного Sovereign-реестра каждой организации; каждая организация самостоятельно разворачивает браузер для мониторинга только этого реестра; кроссчейн-компонента попадает в private network hub и её просматривает браузер аудитора. Активности организации по дизайну не находятся в публичной сети, поэтому на браузере public chain не найти транзакции Enygma. Это не «пропуск», а неизбежный результат трёхуровневой архитектуры.
Но тот контракт на блокировку Parfin размещён в публичной сети и как раз является полным примером «математического принуждения».
Тот адрес, который начинается с 0x1463889D: имя контракта RlsTokenLock, исходный код верифицирован, это не прокси-контракт. Это означает, что он — один из немногих объектов, где можно и читать код, и проверять текущие состояния. Я сопоставил оба источника.
В объявлении constructor totalAmount = 1,070,493,535 RLS. Количество RLS, которое контракт реально держит сейчас, равно 1,070,493,535. Ни на одну wei не отличается — полностью в полном объёме.
Про график разблокировок стоит говорить отдельно. В конструкторе — 48 временных отметок, я все их декодировал: первый уровень — 1 декабря 2027 года, затем каждый 1-е число каждого месяца, последний уровень — 1 ноября 2031 года. Период примерно 3,92 года, на уровень приходится около 22,30 млн RLS. Ранее публичные материалы подчёркивали блокировку до 1 декабря 2027 года — это первый уровень, точно; полный каркас из конструктора показывает: после первого уровня ещё почти четыре года ежемесячных высвобождений.
Комментарии прямо в самом контракте описывают намерение дизайна: неизменяемый (неапгрейдируемый), условия развёртывания — навсегда; без предварительной разблокировки любые ключи не могут быть перемещены на следующий уровень до наступления срока. Я сопоставил эти два пункта с кодом по отдельности: график прописан в constructor без setter, а контракт действительно не является прокси.
Вот как выглядит «математическое принуждение» на одном примере, который я могу полностью проверить: формулировки совпадают с кодом, и при этом код ещё более конкретен, чем слова. Вещи из шести стандартов, которые я мог увидеть только по следам в исходниках и документах, здесь можно наблюдать до самого конца.
Ещё две точки внешней ссылки
Когда блог говорит про TEE, он упоминает, что Intel SGX имел зафиксированные уязвимости, которые разрушали гарантии изоляции. Эта часть верна, но блог недооценивает собственный аргумент. У изоляционного класса есть Foreshadow, Plundervolt, EPIC Leak, SmashEx; номера соответственно: CVE-2018-3615, CVE-2019-11157, CVE-2022-21233, CVE-2021-0186 и CVE-2021-33767. Самое критичное всё же — SGAxe за 2020 год: он, используя CVE-2020-0549, извлёк сам сертификатный (attestation) ключ непосредственно из сертификационной enclave в производственной среде Intel. После этого он может выдавать любые произвольные утверждения, которые Intel-сервис сертификации затем считает легитимными.
Аргументация в блоге такова: гарантии TEE обеспечиваются доказательствами, которые выдаёт аппаратная часть, а SGAxe как раз взламывает тот этап, где это доказательство выдаётся. Самая тяжёлая поломка — не в том, что украли данные, а в том, что подделали саму гарантию. Справедливости ради: всё это уже было исправлено микрокод-апдейтами и recovery для TCB — сегодня SGX уже не тот, что в 2018 году. Точная формулировка такая: аппаратный root of trust имеет «площадку скользящей» уязвимости, которая периодически вскрывается.
Другая точка: он говорит, что BIS Project Agora сходится к той же архитектуре. Я прочитал прототипный отчёт BIS от 27 мая: по топологии действительно похоже — двухслойная структура, общий реестр и отдельные реестры в каждой юрисдикции. Но граница в Agora проводится через полномочия (jurisdiction); отчёт не объясняет, как реализован контроль доступа внутри реестра юрисдикции. Поэтому непонятно, распространяется ли «сходимость» до уровня trust-модели — по текущим публичным материалам это не видно.
Что подтверждено, а что является моими предположениями
Подтверждено: ML-KEM-768 используется для ключей наблюдения; см. relayer/cryptography/mlkem.go. Pedersen для конструктора с двумя генераторами BabyJubJub; см. enygma_math.go. Аудиторский приватный ключ шифруется и выдаётся через relayer; см. governance service/cryptography/service.go. Показано, что ключ расходования (spending) и ключ наблюдения математически независимы, область наблюдения можно ограничивать по времени и по аккаунтам, браузер аудитора покрывает только кроссчейн-транзакции, а степень расшифровки настраивается на этапе сборки; всё это видно в официальной технической документации. Cryptographic Trust Suite хранит ключи единообразно, а Relayer никогда не хранит ключи; хранилище ключей подключаемо к KMS или HSM; используется статическое шифрование «конвертом»; журналы аудита операций с ключами в системе управления ключами организации — это и есть след аудита ключевых операций; ключи подписи ротируются по использованию и ключ, которым подписана ожидающая транзакция, остаётся валидным до её settlement; инкапсуляции (encapsulation) выполняются один раз на стадии постройки сети по отношению к каждому участнику; размер анонимной группы — 2 или 6; одна crossTransfer максимум на 5 целевых цепочек; финальность — порядок десятков секунд; заморозка участников через governance contract ParticipantStorage выполняется операторами; всё это — в официальной технической документации. Проверяемый статус у RlsTokenLock, не-прокси-атрибуты, 48-уровневый (档位) таймтейбл, заявленные суммы и фактические балансы — считываются через публичный браузерный интерфейс 12 сентября 2026 года. Номера уязвимостей SGX взяты из CVE-реестра и из статьи SGAxe. Структура и данные Agorá — из публичных материалов BIS.
Моё предположение: из четырёх материалов только статья формулирует слова про Pedersen достаточно точно. Описание «границы задаются математикой принудительно» — это про выполнение, а не про распределение. SGAxe лучше поддерживает аргументы блога, чем изоляционные уязвимости. В этих трёх материалах так не написано.
Не удалось верифицировать: механизм «послеотзыва» из пятого пункта. Я просмотрел шесть документов: управление ключами, браузер аудитора, базу криптографии Enygma, заморозку со стороны участников, параметры private network design options и private network hub; плюс два репозитория кода — для relayer и для governance service. Нашёл конфигурации трёх уровней видимости, механизм выдачи, а также заморозку и отключение со стороны участников, но не нашёл реализации, которая бы обеспечивала отзыв уже выданной видимости с помощью криптографии. Долгосрочная ротация ключа наблюдения тоже не нашлась: раздел, где описана ротация, говорит о ключах подписи.
В конце — одна вещь, не связанная с технологией
В ту же неделю, когда пишут эту статью, официально объявили, что 55% лимита по стейкинг-уровням продлевают до 15 сентября, и что в период корректировки механизма стейкинга ранние сторонники продолжат получать доходность по этой части; дальнейшие обновления по стейкингу и более широкой токеномике, включая выжигание, будут опубликованы отдельно.
Я заложил с этапа предварительного обязательства и полностью участвовал три месяца. Изначальная планка заканчивалась 9 сентября: в те дни на интерфейсе я видел, что лимит исчерпан и добавить уже нельзя — сначала даже подумал, что проблема на фронтенде. Сейчас, судя по всему, это идёт корректировка механизма.
Это моё личное мнение, не утверждение как факт: в период окна изменения механизма выбрали продление, а не прямое отключение, и при этом чётко указали даты — я считаю, что это выглядит добросовестно. В период корректировок механизма чаще всего возникает размытость; наличие конкретной даты означает, что по истечении срока либо нужно выполнить обязательства, либо снова всё объяснять.
Это всего лишь конкретный случай; он не является оценкой каких-либо долгосрочных договорённостей. Я не прогнозирую доходность и не советую никому принимать решения на их основе.
Источник(и для справки): официальный блог Rayls Auditability without surveillance: why mathematical enforcement beats trusting the code, 12 сентября 2026; две страницы официальной техдокументации Rayls — базис криптографии Enygma и браузер private network аудитора; репозитории GitHub-организации raylsnetwork rayls-sovereign-relayer и rayls-sovereign-pnh-governance; интерфейсы addresses и smart-contracts публичного блокчейн-эксплорера Rayls explorer.rayls.com, время извлечения данных — 12 сентября 2026; NIST FIPS 203; CVE-записи 2018-3615, 2019-11157, 2020-0549, 2021-0186, 2021-33767, 2022-21233 и статья SGAxe; BIS Project Agorá прототип отчёта othp110; IACR криптографический электронный архив 2025/1638 и 2025/1639; официальное объявление в X-аккаунте Rayls от 12 сентября 2026.
