Банк может доказать, что токенизация работает, с помощью прототипа.

Самый сложный вопрос — что произойдёт, когда этот прототип должен будет взаимодействовать с системами, от которых банк уже зависит.

Коpбанкинг. Казначейство. Цифровой банкинг. Системы идентификации и KYC.

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

Это та часть Rayls Sovereign, которая мне кажется самой интересной.

Механизм: Sovereign предоставляет доступ к реестру через привычные интерфейсы

Rayls Sovereign — это частный блокчейн, совместимый с EVM, который организация устанавливает и эксплуатирует в собственной среде.

Распределенный реестр обрабатывает onchain-активность учреждения, а приложения могут подключаться к нему через стандартные интерфейсы.

Самый прямой вариант — Ethereum JSON-RPC.

Это означает, что существующие инструменты Ethereum — например, ethers.js, web3.js, viem, Hardhat и Foundry — могут взаимодействовать с распределенным реестром Sovereign без необходимости в отдельном специализированном клиенте блокчейна.

Существуют и другие пути интеграции.

Backend Rayls может предоставлять REST API для построения транзакций и интеграции хранения (custody), а соединения WebSocket — передавать события в реальном времени из распределенного реестра.

То есть интеграции не обязательно выглядеть так:

Системы банка → полностью новый стек блокчейна

Это может выглядеть так:

Системы банка → существующий слой интеграции → распределенный реестр Sovereign

Этот нюанс важен.

В документации Rayls Sovereign описывается именно как решение, способное интегрироваться с основными банковскими платформами, системами ERP, фидами котировок, хранилищами идентификации и KYC.

Тогда распределенный реестр может подключаться наружу

Как только актив или транзакция оказывается в распределенном реестре Sovereign учреждения, учреждение может выбрать, куда ему нужно идти дальше.

Для приватной институциональной транзакции:

Sovereign → Private Network Hub → другой распределенный реестр Sovereign

Для активности в публичной цепочке:

Sovereign → Rayls Public Chain

Это не один и тот же маршрут.

Подключение к Public Chain — это прямой путь «один к одному»: используются собственные контракты и процесс relayer. Оно не проходит через Private Network Hub.

Такое разделение полезно, потому что учреждению не нужно раскрывать весь свой внутренний распределенный реестр только потому, что одному токенизированному активу нужно взаимодействовать с внешней сетью.

Практический пример

Представьте, что банк токенизирует депозит.

Банк может выпускать и управлять этим активом в собственном распределенном реестре Sovereign, при этом сохраняя распределенный реестр внутри своей собственной среды.

Его существующие системы могут взаимодействовать с распределенным реестром через доступные интерфейсы.

Если позже депозит понадобится взаимодействовать с другим учреждением, он может воспользоваться маршрутом Private Network.

Если ему нужно обратиться к приложению или ликвидности в Public Chain, для этого предусмотрен отдельный маршрут.

Важно то, что внутренний распределенный реестр банка остается собственным распределенным реестром учреждения.

Меняется то, насколько легко можно подключить этот распределенный реестр к другим средам, когда для этого есть бизнес-причина.

Почему это важно для промышленной эксплуатации

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

Прототип задает вопрос:

«Можно ли разместить этот актив onchain?»

В промышленной эксплуатации требуется:

«Смогут ли наши существующие системы работать с этим активом без того, чтобы перестраивать банк вокруг нового стека?»

Sovereign разработан вокруг второго вопроса.

Он дает учреждению собственный EVM-распределенный реестр, привычные интерфейсы интеграции и контролируемые маршруты к Rayls Private Networks и Public Chain.

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

Мой вывод

Для институционального блокчейна интеграция — часть продукта.

Интересное в Sovereign заключается не только в том, что банк получает свою собственную блокчейн-сеть.

Суть в том, что блокчейн спроектирован так, чтобы находиться внутри существующей среды банка, но при этом иметь заранее определенные пути к приватным и публичным onchain-сетям.

CTA: Если вы оцениваете инфраструктуру блокчейна для учреждения, архитектуру @Rayls Sovereign стоит рассмотреть в первую очередь — начиная со слоя интеграции.