Я начал стейкать RLS ещё с этапа предварительного обещания, так что читать официальные материалы — скорее привычка. После появления названия Sovereign большинство обсуждений сводилось к вопросу: «это просто сменили имя?». Я думаю, что вопрос задан наоборот. Неважно, как называется, важно, что именно поменялось внизу, а также сколько сама контролирующая организация может получить из того, что она сможет самостоятельно проверить во время due diligence. В этой статье для каждого числа я указал точный источник; вы можете воспроизвести всё по шагам.
Сначала про одну вещь: на прошлой неделе я писал статью про аудируемость, и некоторые читатели, возможно, её уже видели.
В этой статье большая часть материала — новая: она взята из репозитория кода Axyl, из аудит- директории в этом репозитории, а также со страницы документа Axyl с бенчмарками производительности — с этими местами я ранее не работал. Лишь небольшой раздел про управление ключами продолжает выводы из предыдущей публикации; там я отмечу это отдельно. Разделять «новое» и «старое» я буду потому, что «что я нашёл на этой неделе» и «что я уже проверял раньше» должны быть для читателя различимы.
Сначала расставим таймлайн по местам.
Это не переименование.
Axyl был развернут в конце апреля 2026 года сначала на основной сети Rayls; миграция Sovereign в Axyl — в июле 2026 года, то есть после выхода публичной сети. Официальная документация прямо указывает, что миграция проводится поэтапно, в течение этого периода организации продолжают работать как обычно. После замены базового уровня появляется новое имя.
Раздел What changed в документации перечисляет пять пунктов; ниже я выберу два, потому что именно эти изменения меняют положение организаций, а не только параметры технологического стека.
Изменение 1: из одного узла — в комитет.
Прямая цитата из документации: более ранний Rayls Sovereign ledger работал в форме отдельного Geth-нода и отдельного валидатора. Axyl запускает консенсус BFT через несколько комитетов, поэтому риск доступности одного нода больше не применим. В этом же фрагменте также написано: EVM-ноды были заменены с Geth на Reth; Clique (authority proof) — с заменой на Axyl.
Я сходил в репозиторий и проверил, что такое Axyl. Это протокол-клиент на Rust; один бинарник rayls-network одновременно запускает две части: консенсусный слой — реализация Narwhal и Bullshark, работает поверх libp2p и QUIC; исполнительный слой построен на reth и alloy, а результат — стандартные блоки Ethereum EVM. Ноды делятся на валидаторов и наблюдателей: наблюдатели следуют за цепочкой через синхронизацию состояния, но не входят в комитет. Toolchain фиксирован на Rust 1.91.
Для банка смысл этого пункта не в пропускной способности — в операционной устойчивости. Бухгалтерская книга (ledger) у одного узла и одного валидатора: отказ одной машины = остановка ledger, без реального резервирования, а это как раз тот тип дизайна, который сложнее всего объяснить регулятору. После перехода к комитету эта проблема перестает быть «без ответа» и становится стандартным ответом; Byzantine Fault Tolerance — это язык, который одинаково хорошо понимают и риск-контроллеры, и регулятор.
И цена тоже конкретная. В README репозитория рекомендованная минимальная конфигурация: 8 физических ядер, 16 GiB памяти, 500 GiB твердотельного накопителя, пропускная способность от 10 Gbps — и это требования к каждому члену комитета, а не к одной машине. Документация также отдельно дает двухуровневую конфигурацию деплоя самого реестра Sovereign: облегченный уровень — 2 vCPU, 4 GB, 100 GB; корпоративный — от 4 ядер, 16 GB, 500 GB.
И еще одно место, которое легко пропустить: приватный network hub не был заменен вместе с остальным; в документации отдельно сказано, что он продолжает работать с Besu и доказательством авторитетности и не зависит от миграции Axyl. Их «свой» слой сейчас — это Byzantine Fault Tolerance, а между-организационным слоем по-прежнему используется доказательство авторитетности; у двух слоев разные модели доверия — при оценке их нужно смотреть отдельно.
Изменение 2: ключи вынесли из транспортного компонента.
Этот раздел продолжает вывод из моей предыдущей статьи — это не новые находки этой недели; я оставил его здесь, потому что по требованию brief нужно привести два изменения, и этот пункт как раз входит в число пяти.
Один из пунктов в документации говорит, что модуль управления ключами стал Cryptographic Trust Suite — это декуплированный компонент для хранения ключей; relayer больше не обрабатывает напрямую и не хранит ключи. Я проверял эту строчку в исходниках: в двух репозиториях relayer и governance services папка cryptography совпадает.
Значение для организации в двух аспектах. Relayer — это коммуникационный компонент «наружу» и самый уязвимый; в старой структуре он одновременно трогал ключи, а в новой — он до них не добирается: компрометация транспортного слоя больше не равнозначна компрометации ключей. Вторая вещь — что хранение ключей сделано подстановочным (plug-in) и может быть подключено к KMS или аппаратному модулю безопасности, которыми организация уже пользуется; поэтому уже существующая у организации траектория аудитов закрывает операции с ключами Rayls, и не нужно создавать для этого отдельную аудитную поверхность.
Главный действительно новый материал на этой неделе: папка аудитов.
В репозитории Axyl есть папка audits/, внутри — один README и три PDF. Я прочитал тот README: по содержанию он намного конкретнее, чем фраза «проведен третий сторонний аудит».
Все три отчета выданы Halborn; окно выполнения — с февраля по март 2026 года; повторная проверка исправлений завершится в апреле–мае.
Имя файла документа по консенсусному протоколу — halborn-2026-03-consensus-protocol.pdf; охват — Rust-кодовые пути, связанные с консенсусом, синхронизация сертификатов, обработка gossip и управление ключами валидаторов; сроки выполнения — с 2 марта по 20 марта; 5 обнаружений, из них 1 критическое, 3 среднего, 1 низкого; все исправлено.
Версия для сетевых узлов — halborn-2026-03-network-node.pdf; охват — модули сеть, worker, синхронизация состояния, выполнение, оркестрация и хранилище; сроки выполнения — с 18 февраля по 24 марта; 22 обнаружения, из них 1 критическое, 2 высокого уровня, 7 среднего, 6 низкого, 6 рекомендательных; 20 исправлений, принятие риска для 2 случаев низкого уровня.
Контрактная часть смарт-контрактов — halborn-2026-03-smart-contracts.pdf; охват — контракты в rayls-contracts/src/ (ConsensusRegistry, StakeManager, DelegationPool и распределение комиссий и т. п.); сроки выполнения — с 2 марта по 13 марта; 15 обнаружений, из них 1 критическое, 2 высокого уровня, 7 среднего, 2 низкого, 3 носящих рекомендательный характер; 14 исправлений, принятие риска для 1 случая среднего уровня.
В сумме получилось 42 обнаружения: 3 критических, 4 высокого уровня, 17 среднего, 9 низкого, 9 рекомендательных. 39 исправлений, принятие риска для 3 случаев. Все три критических уровня исправлены.
Я перечислил эти цифры по одной, потому что для закупок вопрос «делали ли аудит» и вопрос «что именно проверяли, сколько времени проверяли, сколько обнаружений, и сколько из них не исправили» — это совершенно разные вопросы. Первый вопрос почти любой проект может честно ответить «да», а вот со вторым может справиться немногие; здесь же по каждому пункту есть открытая проверяемость. Все три критических уровня исправлены — это железобетонный положительный факт.
В той же версии README еще раскрывается одна вещь
Эта часть, как мне кажется, самая полезная для due diligence во всем документе.
В том README есть раздел, который специально посвящен проблеме: привязки к submit record (записи отправки) и ссылкам на pull request. Смысл исходного текста такой: эти аудиты проводились для приватного репозитория до его публикации; когда проект стал open source, история репозитория была сжата в один начальный commit. Поэтому хеши коммитов и ссылки на pull request, которые в отчете приведены как доказательства исправлений, в этом публичном репозитории не разбираются.
Rayls также уточняет: все исправления, проверенные Halborn, включены в initial commit (начальный коммит) публичного репозитория, а время этого коммита позже, чем повторная проверка исправлений; PDF публикуется в точности в исходном виде, как выдано Halborn, без изменений.
Для организации, которая делает due diligence, это конкретное и реальное ограничение: отчет можно прочитать и он не изменен, но цепочка доказательств исправлений, на которую указывает отчет, в публичном репозитории не проходит. Вы можете видеть, что Halborn говорит: «проблема исправлена», но вы не можете перейти по ссылке, которую он приводит, и посмотреть реальные изменения кода в том исправлении.
Я хочу подчеркнуть: это не сокрытие, наоборот — Rayls сам по собственной инициативе все подробно написал в README, с указанием причин и пояснений по компенсациям. Я просто вынес это наружу, потому что это первый вопрос, который задает команда по безопасности, а ответ уже там — просто в файле, который большинство людей не открывает.
Те цифры по пропускной способности; условия тоже публичные.
Этот пункт я отдельно отмечаю, потому что в августовском итоговом отчете сообщества его прямо назвали: два числа TPS ходят по рукам, и люди цитируют то, что побольше.
Я просмотрел все три источника. Официальная документация, когда говорит о производительности Sovereign, пишет: Axyl — это 15,000+ TPS и финализация на уровне долей секунды. README репозитория Axyl пишет: цель протокола — 10,000+ TPS; формулировка — targets, то есть цель, а не измерения. А условия — в третьем месте: документ на одной странице Axyl Performance Benchmarks. Там прямо написано, что это прототипные тесты бенчмарки именно консенсусного слоя; условия записи: комитет из четырех нод, транзакции размером 512 байт, пакетный размер 500 KB, максимальная задержка batched latency 50 мс; кроме того, отдельно приведены консенсусные данные для тестовой сети.
Поэтому полная формулировка должна звучать так: прототипные бенчмарки консенсусного слоя при этих четырех условиях — это не сквозное production-измерение. Важно пояснить: конкретные значения на той странице приведены в виде картинки; я не могу прочитать цифры с картинки, но могу подтвердить сами условия.
Заодно приведу побочное подтверждение, которое я прогнал сам. 12 сентября я дернул stats-интерфейс блокчейн-эксплорера, среднее время создания блока возвращалось около 500 мс. Это согласуется с утверждением про «доли секунды», и любой может дернуть тот же интерфейс и проверить сам. Время создания блока не равно окончательной финализации транзакций, но это хотя бы независимо измеряемое значение, а не пересказ.
Деталь, которую спросит отдел закупок, но которую обычно редко поднимают.
Лицензия Axyl — BUSL-1.1, коммерческая лицензия на исходный код; это не открытый исходный код в обычном смысле.
В разделе о лицензии репозитория написано очень конкретно: разрешенное производственное использование — запуск узлов в основной сети Rayls и на ее официальных тестовых сетях, включая четыре типа: валидаторы, наблюдатели, relayer и RPC; другие варианты производственного использования требуют коммерческой лицензии. Через четыре года после первого публичного релиза каждой версии дата изменений становится датой, после чего лицензия будет преобразована в Apache 2.0.
Если читать дальше, то в своей Sovereign-деплой одна из банковских организаций запускает Axyl, что относится к другим вариантам производственного использования.
Это не критика. Rayls и раньше публично заявлял: ядро платформы open source, а Axyl и Enygma — коммерческие компоненты; переход BUSL + 4 года в Apache — это зрелая практика в индустрии. Я написал это потому, что слово «open source» в распространении часто воспринимают как будто его можно применять «куда угодно», а границы лицензии прописаны в лицензионных файлах очень четко.
Откуда код — сам репозиторий это говорит.
В разделе благодарностей репозитория Axyl откровенность встречается редко. Консенсусная часть — Rust workspace, происходящий от Telcoin Network; а Telcoin Network построена на Narwhal и Bullshark от Sui. Rayls на этой основе провела существенную реорганизацию и модификации; реализация Bullshark сильно деривативна относительно репозитория Sui от Mysten Labs — в соответствии с Apache 2.0. Исполнительный слой — reth и alloy; интерфейс OFT из LayerZero сохраняет исходную лицензию MIT.
Описать родословную (источник) кода проще, чем заявлять, что все разработано полностью с нуля — так команда инженеров охотнее доверяет, потому что аудитор может проследить по этой линии зрелость исходных компонентов.
Что новое, что продолжение, что не удалось проверить.
Новые проверки на этой неделе: весь контент README репозитория Axyl — включая архитектуру, роли, конфигурации, лицензию и благодарности; в audits/README.md — таблицы из трех отчетов и объяснение сжатия истории коммитов; doc/index.md — системный обзор; базовые условия на странице Axyl Performance Benchmarks; в официальной документации раздел Rayls Sovereign — пять пунктов What changed и конфигурация деплоя в двух уровнях.
Продолжение предыдущего: границы ключей в Cryptographic Trust Suite и то, что relayer не владеет ключами — это то, что я на прошлой неделе проверял в исходниках двух репозиториев relayer и governance services. В этом разделе новых доказательств нет.
Моя гипотеза: основная ценность перехода от одного узла к комитету — в операционной устойчивости, а не в пропускной способности; то, что цепочка доказательств исправлений не проходит в публичном репозитории, — это реальное ограничение на уровне due diligence; прописать родословную кода — это позитивно.
Сигнал. В этих трех материалах так не написано.
Не смог подтвердить: у меня нет доказательств, что какая-либо конкретная организация действительно запустила эту конфигурацию на практике; все, о чем идет речь в этой статье, описывает способности, зафиксированные в документации и коде.
Путь для воспроизведения: найдите на GitHub raylsnetwork/axyl; в двух файлах в корне README и audits/README.md покрываются почти все цифры в этой статье; в официальной документации поищите Rayls Sovereign и Axyl Performance Benchmarks — это две страницы; время выпуска (создание блока) можно посмотреть через /api/v2/stats в блокчейн-эксплорере основной сети.
