Технологии смарт‑контрактов: как мы видим развитие платформы цифрового рубля

Привет, Хабр! Я Антон Боганов, в команде РСХБ.Цифра занимаюсь внедрением и развитием платформы цифрового рубля, а также управлением цифровыми услугами. В предыдущей статье мы разбирались в том, что такое цифровой рубль, горячо подискутировали, а в этой статье мы с Константином Белкиным, Teamlead SRE в команде РСХБ.Цифра, Quadexx, проведём анализ и выбор технологии для построения платформы смарт‑контрактов, интегрированной с платформой цифрового рубля. Почему это актуально? Совсем недавно Центральный Банк опубликовал Концепцию Платформы коммерческих смарт‑контрактов.

Цифровой рубль — это платежное средство. Сейчас его нельзя положить под процент, с ним нельзя зарабатывать на инвестициях. С помощью цифрового рубля можно что‑то оплатить, ну вот и все.

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

Да‑да, мы сейчас говорим про смарт‑контракты. Концепция смарт‑контрактов была придумана Ником Сабо в далеком 1994 году и описана в статье Smart Contracts 1994 by Nick Szabo: простейшим смарт‑контрактом является общение с вендоматом (торговым автоматом), вы даете ему деньги, а он вам — товар. Все происходит без участия посредника, только вы и бездушная машина.

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

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

Мы смотрим на вариант реализации собственных платформ для выпуска "обернутого" (wrapped) цифрового рубля и создания коммерческих смарт‑контрактов под банковские продукты и интеграцию их в клиентские сценарии. При этом взаимодействие платформ коммерческих смарт‑контрактов между собой и с платформой цифрового рубля можно было бы организовать через стандартизованные API, например по стандарту Банка России СТО БР ФАПИ.СЕК.

Мы решили начать с ряда технических вопросов: на чем можно реализовать платформу, какие функции могут стать быстродоступными, чтобы показать потенциал применения платформы смарт‑контрактов.

Бум систем смарт‑контрактов начался в середине 2010-х, а массовый интерес резко вырос после запуска Ethereum в 2015 году. Именно тогда смарт‑контракты стали практической частью блокчейн‑платформ, а не только теоретической идеей. Стоит отметить основополагающие документы для развития идеи цифровых активов:

• В октябре 2018 года Банк России выпускает "Аналитический обзор на тему Смарт‑Контрактов"
• В апреле 2019 года Банк России выпускает Аналитическую записку на тему "Есть ли будущее у цифровых валют центральных банков?"

И дальше все закрутилось‑завертелось:

• Концепция и прототип — декабрь 2021 года: Банк России создал прототип платформы цифрового рубля;
• Тестирование прототипа — 2022 год: отладка платформы и подготовка дорожной карты внедрения;
• Базовый закон — 11 июля 2023 года: Госдума приняла закон о внедрении цифрового рубля, а 1 августа 2023 года основные положения вступили в силу;
• Пилот с реальными операциями — с 15 августа 2023 года: началось пилотирование на ограниченном круге банков, клиентов и операций;
• Расширение пилота — с 1 сентября 2024 года: число участников заметно выросло, включая тысячи физлиц и более тысячи компаний;
• Подготовка к массовому внедрению — 2025–2028 годы: законодательно закреплены поэтапные сроки подключения банков и бизнеса;
• В июне 2026 года Банк России выпускает концепцию Платформы коммерческих смарт‑контрактов в цифровых рублях
• Вы находитесь здесь>
• Массовый старт — 1 сентября 2026 года для крупнейших банков и ритейла, затем поэтапно до 1 сентября 2028 года для остальных участников.

Думая о перспективах коммерческих смарт‑контрактов, мы решили проверить, возможно ли построить платформу смарт‑контрактов на блокчейне, чтобы выполнялся ряд серьезных требований, включающих в себя:

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

Нам важно, чтобы платформа смарт‑контрактов имела следующие характеристики:

1. Разрешённая сеть. Все участники известны, проходят идентификацию и получают сертификаты через иерархию удостоверяющих центров с CA в лице ЦБ РФ.
2. Конфиденциальность сделок. В своей основе блокчейн‑сети — это платформы с возможностью открытого чтения информации о сделках и переводах. Нам же необходимо, чтобы условия каждой сделки были скрыты от конкурентов и не связанных со сделкой сторон. Поэтому необходима изоляция данных на уровне отдельных сделок или групп участников. Банковская тайна — это очень важно: конкуренты не видят условия сделок друг друга, клиенты получают гибкий выбор без раскрытия своей стратегии всем участникам рынка.
3. Поддержка цифрового рубля (CBDC). Использование цифрового рубля как третьей формы денег на платформе Банка России с возможностью эмиссии только ЦБ, перевода средств и применения смарт‑контрактов, доступ к платформе осуществляется через банки‑участники, а архитектура предполагает высокий уровень безопасности и контролируемые операции.
4. Сложные смарт‑контракты. Возможность оркестрации нескольких контрактов в рамках одной сделки, лизинг, страхование, факторинг, оплата, субсидирование, подтверждение поставки — всё объединяется в одном потоке, снижая операционные риски и время обработки.
5. Высокая пропускная способность. Сотни‑тысячи транзакций в секунду, возможность масштабирования по числу участников и сделок.
6. Интеграция с внешними системами. API, события, множество вариантов интеграции с системами‑оракулами, возможность задания политик подтверждения транзакций.
7. Масштабируемость. Добавление новых участников (новые банки, лизинговые компании, страховщики) без изменения ядра сети.
8. Поддержка стандартных языков разработки. Go, Java, Kotlin для быстрого входа в платформу смарт‑контрактов.
9. Юридическая значимость. Использование квалифицированной электронной подписи, возможность аудита, соответствие регуляторным требованиям (в т. ч. 115-ФЗ).
10. Управление и регуляторика. Прозрачность для регулятора, чёткое разделение ролей (эмитент, операторы, регулятор, участники), ЦБ, ФНС, Росфинмониторинг и еще ряд некоторых регуляторных ведомств должны иметь картину с отчетностью по сделкам (в рамках регуляторного канала), что упрощает надзор и сбор статистики.

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

Так выглядит ролевая модель участников сети смарт‑контрактов.

Центральный банк (ЦБ) должен выступать владельцем корневой инфраструктуры, он же является эмитентом цифрового рубля, и роль регулятора никуда не девается. Если эту роль переложить на архитектуру распределенных реестров, то получается, что Центральный Банк управляет корневым удостоверяющим центром (Root CA), задаёт политики сети, владеет узлами ордереров, обеспечивающих консенсус. Также ЦБ контролирует цифровой рубль и эмитирует его в блокчейне.

Коммерческие банки являются операторами счетов, финансовыми посредниками, которые предоставляют доступ к счету цифрового рубля, банки совместно с клиентами формируют смарт‑контракты (например, аккредитивы) и открывают кредитные линии. В случае с блокчейном банки выступают как пиры (peers), могут иметь свои каналы с клиентами, а также участвовать в общих каналах для расчётов.

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

Страховые компании предоставляют страховку предмета лизинга, грузов, ответственности. Участвуют в каналах сделок, подписывают транзакции подтверждения страхового покрытия, автоматизируют выплаты при страховых случаях (через оракулов), сами используют системы‑оракулы для принятия решений.

Продавцы и участники рынка, дилеры, которые предлагают оборудование (сельхозтехника, серверы, станки), через свои узлы или API регистрируют предложения, заключают смарт‑контракты на поставку, получают оплату в цифровых рублях.

Юридические лица (покупатели/лизингополучатели) — это клиенты, приобретающие оборудование с использованием комплексных условий. Что касается клиентов, то они подключаются через SDK или веб‑интерфейсы банков/лизинговых компаний.

Субсидирующий орган (эмитент субсидии/Казначейство), выпускает специализированные серии цифрового рубля для частичного погашения долга покупателя /лизингополучателя. Выступают как узлы (peers), имеют отдельный канал связи с ЦБ для подтверждения выполнения условий по субсидии для выпуска специальной серии цифровых рублей.

Такие роли мы подобрали, чтобы реализовать различные сценарии из повседневной жизни и положить блокчейн на сделки. В сети смарт‑контракты становятся "оркестраторами" сложных сделок. Пример жизненного цикла:

1. Покупатель выбирает в маркетплейсе сельхозоборудование, лизинговую компанию и страховщика.
2. Приложение (клиент) инициирует создание нового смарт‑контракта и развёртывание набора:
   • Лизинговый контракт — график платежей, условия досрочного выкупа;
   • Страховой полис — объект страхования, премия, порядок выплат;
   • Аккредитив/кредитный договор.
3. После подписания всеми сторонами (цифровыми подписями через платформу Госключа) контракты активируются.
4. Оплата продавцу инициируется лизинговой компанией путём вызова смарт‑контракта с цифровым рублем и указанием суммы, получателя (продавца) и ссылки на договор лизинга: ЦБ проверяет, что лизинговая компания имеет достаточно цифровых рублей на своём кошельке.
5. Страхование может быть оплачено единоразово или включено в лизинговые платежи, смарт‑контракт страховой компании подписывает факт наступления страхового случая (возможно, с привлечением оракулов или данных от производителя оборудования).
6. Все статусы (оплачено, отгружено, застраховано) фиксируются в блокчейне и доступны участникам сделки, при необходимости регуляторы получают сводные отчёты.

ЦБ выступает не просто участником, а корневым оператором сети. Это накладывает особые требования:

• Удостоверяющий центр (CA): ЦБ может управлять корневым CA, а банки, лизинговые компании и страховщики имеют подчинённые CA для выдачи сертификатов своим сотрудникам и клиентам (отражение взаимодействия УЦ и ПУЦ при работе с цифровым рублем для сертификатов TLS и ЭЦ).
• Узлы ордереров: ЦБ может развернуть кластер orderer (например, Raft) на своей инфраструктуре, обеспечивая высокую доступность, банки или другие крупные игроки могут иметь дополнительные узлы orderer для отказоустойчивости, но под контролем ЦБ.
• Политики подтверждения: для операций с цифровым рублём может быть установлено правило, что эндорсерами должны быть ЦБ и платёжный банк, а для обычных коммерческих транзакций достаточно подписей сторон сделки.
• Обновление смарт‑контракта: ЦБ как владелец сети утверждает обновления смарт‑контракта цифрового рубля, обновления коммерческих смарт‑контрактов (лизинговых, страховых) могут проводиться по согласованию соответствующими участниками.

Данная централизованная, но при этом распределённая модель соответствует концепции цифрового рубля — ЦБ является эмитентом и оператором платформы, но банки и другие участники имеют собственные узлы, создают свои контракты и управляют сделками раздельно от друг от друга, формируя только условия реализации и используя цифровой рубль как платежное средство.

Такой подход с архитектурой, ролевой моделью и сценариями показал ряд преимуществ и выявил ряд вызовов.

Обобщив требования и сопоставив с ними образ целевого результата в виде сценариев, мы определили ряд блокчейн‑платформ, которые взяли для проверки на предмет пригодности их архитектуры:

1. Hyperledger Fabric
2. Corda R3
3. Quorum ConsenSys
4. Hyperledger Besu

Одним из лидеров среди платформ оказался Hyperledger Fabric. Корни владения платформой уходят в IBM. Хотя она и поставляется как опенсорс, племя IBM ставит жирный крест на использовании платформы в государственной инфраструктуре. Тем не менее интересно рассмотреть плюсы и минусы этой платформы, так как её применимость была бы оптимальна для сложных государственных или частных проектов с участием ЦБ и надзорных органов. Fabric широко применяется в сообществе российских разработчиков.Смарт‑контракты на этой платформе представлены в виде специализированного chaincode, подходящего для цифрового рубля. Инструменты платформы позволяют сделать так, чтобы только ЦБ мог эмитировать новые токены (выпуск в обращение) и сжигать их. При этом для работы со смарт‑контрактами можно выбрать что‑то из Gо, Java, JS.

Fabric позволяет выбрать либо модель работы UTXO (Unspent Transaction Output или неизрасходованный выход транзакции — базовый архитектурный принцип Биткоина, где баланс пользователя хранится не в виде единого счета, как сейчас в банках, а как набор отдельных дискретных "купюр" разного номинала, которые можно использовать ровно один раз), либо account‑based (где баланс пользователя хранится в виде единого счета, как раз как сейчас в банках). Account‑based применяется как раз в цифровом рубле и его удобнее использовать для проверки балансов при каждом переводе.

Что касается конфиденциальности, то суммы переводов могут быть скрыты от третьих лиц с помощью встроенного механизма Private Data Collections или криптографических методов (например, анонимные платежи, но в корпоративной сети часто достаточно ограничения доступа по каналам). Для выхода за пределы платформы цифрового рубля есть варианты проведения интеграции с банковскими системами: узлы ЦБ и банков подключаются к системе быстрых платежей или к системе межбанковских расчетов для "шлюзования" между цифровым рублём и обычными деньгами (on‑ramp/off‑ramp).

Что хорошего в Hyperledger Fabric, так это гибкие политики подтверждения, высокая масштабируемость, сильная экспертиза интеграторов в РФ. Fabric не требует нативной криптовалюты, поэтому цифровой рубль реализуется как обычный актив, управляемый смарт‑контрактом. Транзакции по переводу цифровых рублей будут подтверждаться эндорсерами (обычно это ЦБ + банк плательщика/получателя) и попадать в блоки ордереров ЦБ.

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

Как вариант, можно испольность Private Data Collections внутри одного канала, изолируя данные сделок, но для чёткого разделения эндорсеров и конфиденциальности часто всё же предпочтительны каналы. Fabric позволяет автоматизировать создание каналов через системный чейнкод (например, FabLo или кастомные решения).

Есть вопросы в части юридической силы. Смарт‑контракты и цифровой рубль регулируются ФЗ "О цифровом рубле". Использование Fabric в качестве платформы для CBDC потребует соответствия требованиям регулятора к технической защите, непрерывности, аудиту. Потребуется провести дополнительную работу по адаптации TLS под ГОСТ — TLS‑слой использует стандартный Go TLS, а вот для внедрения именно ГОСТ требуется замена TLS‑стеков или использование прокси между узлами (например, Nginx с ГОСТ‑модулями).

Corda (R3)

Поэтому выгоднее для применения технологии платформы смарт‑контрактов, умеющей работать с цифровым рублем, смотрится второе место, отведенное нами платформе Corda (R3).

Потому что Corda уже специализирована разработчиками для финансовых и межорганизационных сценариев. Это для нее прям база‑база. Конфиденциальность сделок на платформе достигается не каналами, а уже за счёт модели "потоков" (flows) — данные видят только стороны сделки и обязательные регуляторы. У них каналы, у нас потоки! Corda не ведет глобального блокчейна, каждая сделка имеет свой логический "список" участников.

Еще из особенностей — используются нотариальные узлы для консенсуса. Правда, выбор для работы со смарт‑контрактами поменьше, их можно писать на Kotlin/Java. Видим, что архитектура Corda идеально подходит для финансовых консорциумов, банковских и страховых сценариев со многими участниками, у платформы внутри реализована естественная приватность сделок без необходимости создавать каналы (напомним, у Fabric — каналы, которые требуют отдельных блокчейнов). Широкое применение платформы в финтехе на старте дает преимущества сформированной сильной экосистемы секторе, доступно много готовых решений (например, для торгового финансирования), ее легко интегрировать с существующими банковскими системами.

Из нехорошего, мы нащупали меньше гибкости в управлении сетевыми политиками по сравнению с Fabric, но для консорциума гибкости такой тоже может быть достаточно, также встроенный механизм "системного" токена у Corda отсутствует, но цифровой рубль можно реализовать как обычный актив, а еще сообщество и поддержка в России не так развиты, как у Fabric. Но Corda используется в ряде крупных проектов, наконец, порог входа для разработчиков выше из‑за специфичной модели потоков с нотариусами, но это влияет на время реализации.

Применимость Corda в поставленных нами условиях высокая, особенно если фокус на финансах и приватности. Требуется доработка для роли ЦБ как эмитента токена и для управления субсидиями.

Quorum (ConsenSys)

Конечно, мы не могли не рассмотреть Эфир, но он у нас вышел на третье место в виде Quorum (ConsenSys) — ответвление от Ethereum.

Quorum (ConsenSys) основан на Ethereum, но с добавлением фокуса на приватности (private transactions) и консенсуса без майнинга (IBFT, Raft), поддерживает разработку смарт‑контрактов уже только на одном Solidity, но это означает и простоту разработки для команд, знакомых с Solidity. Есть два режима: публичная цепочка с приватными транзакциями (через enclave) и полностью приватная сеть. Благодаря генетике, уходящей корнями к Ethereum, есть большая экосистема Ethereum, для платформы доступно много готовых инструментов (Truffle, MetaMask для корпоративных сетей). Приватные транзакции позволяют скрывать данные между участниками, но требуют настройки Tessera/Enclave. Базово присутствует поддержка токенов (ERC-20, ERC-721) прямо из коробки, что упрощает привязку к цифровому рублю.

Оценив все эти плюсы и посмотрев на частоту применения платформы, мы пришли к выводу, что проект кажется погибшим: последняя версия выпущена в 2024 году.

Еще из нехорошего: мы определили, что приватность реализована менее гибко, чем в Fabric или Corda: данные делятся на публичные и приватные, но изоляция на уровне отдельных сделок требует аккуратного управления группами участников. Кошмар для оператора и админов платформы. При большом количестве приватных транзакций падает производительность, она ниже, чем у Fabric. Мы нашли меньше встроенных механизмов для сложных политик подтверждения (в Fabric можно задать, какие организации должны подписывать транзакцию).

Применимость в поставленных условиях: средняя, требует дополнительной проработки изоляции сделок и роли ЦБ.

Besu, Hyperledger Besu

Есть еще один кандидат в лице Ethereum для бизнеса. Его называют Besu, Hyperledger Besu.

Что примечательного в Hyperledger Besu, так это то, что он клиент Ethereum, поддерживающий как публичные, так и приватные сети с консенсусом IBFT 2.0, Clique, Raft. Конфиденциальность на платформе обеспечивается через приватные транзакции (как в платформе Quorum) или через частные сети с разделением. Для разработки смарт‑контрактов доступны на выбор Solidity и Vyper.

Из хорошего, в отличие от Quorum, активно развивается в рамках Hyperledger и имеет хорошую интеграцию с экосистемой Ethereum. Более современный и поддерживаемый проект, чем Quorum. Механизм консенсуса IBFT дает высокую производительность, до тысяч транзакций в секунду. Платформа подходит для токенизации и сценариев с использованием цифровых финансовых активов.

Из нехорошего: приватность хромает. На уровне отдельных сделок она сложнее, чем в Corda и Fabric (нет концепции каналов, но можно использовать отдельные сети для каждой сделки, что накладно). Встроенная система ролей и политик подтверждения отсутствует, а ее нужно реализовывать на уровне смарт‑контрактов. Относительно других платформ у Besu меньше готовых решений для сложного межорганизационного взаимодействия с госорганами.

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

При анализе безопасности работы на платформах смарт‑контрактов мы опирались на основные регуляторные требования и рассматривали платформы с высокой применимостью для работы с цифровым рублем, чтобы сосредоточиться на их возможностях и соответствии требованиям как основных кандидатов. Так что платформы Quorum и Besu были исключены из исследования соответствия требованиям информационной безопасности, а Fabric оставили, чтобы посмотреть как там с ИБ в условиях потенциального "подглядывания" со стороны IBM.

С точки зрения использования сертифицированных СКЗИ предъявляется требование, чтобывся криптография выполнялась средствами, сертифицированными ФСБ России. Требование закреплено в Положении Банка России № 833-П "О требованиях к обеспечению защиты информации для участников платформы цифрового рубля", а также в Стандарте ЦБ РФ по программному модулю цифрового рубля. В этой части выявили критическое ограничение: Hyperledger Fabric и Corda используют встроенные криптобиблиотеки (BouncyCastle, OpenSSL). Для применения сертифицированных СКЗИ (например, ViPNet, КриптоПро) требуется интеграция на уровне TLS‑соединений и подписания транзакций через внешние криптопровайдеры. Возможна реализация через HSM (аппаратные модули безопасности). Fabric и Corda поддерживают внешние HSM.

Использование российских стандартов электронной подписи обязательно. Требуется поддержка ГОСТ Р 34.10–2012/2018 (электронная подпись). Тут Corda документально поддерживает GOST3411 с GOST3410 и SM3 с SM2 в своём cryptoAPI. Это нативная поддержка. Fabric же требует доработки — в платформу встроена только поддержка стандартных алгоритмов (ECDSA, RSA). Тут еще возможна интеграция через внешний HSM и модификация MSP (Membership Service Provider).

Идем дальше по требованиям к шифрованию в соответствии с ГОСТ Р 34.12–2015. Требуется установление защищенного канала связи. Между узлами должно использоваться ГОСТ‑шифрование (TLS 1.2/1.3 с российскими криптографическими алгоритмами согласно Р 1323565.1.020–2020 и Р 1323565.1.030–2020). В документации на Corda указана поддержка GOST3411 c GOST3410 для подписей, но поддержка ГОСТ в TLS‑слое требует проверки. Исторически (2018 год) были сложности с ГОСТ в TLS для Corda, но современные версии могут работать с OpenSSL 3.0 и провайдерами ГОСТ. Fabric для TLS‑слоя использует стандартный GoTLS. Для внедрения ГОСТ требуется замена TLS‑стеков или использование прокси (например, Nginx с ГОСТ‑модулями) между узлами.

Идентификация юридических и физических лиц и их уполномоченных представителей должна осуществляться через ЕСИА. Данное требование относится к уровню клиентских приложений (SDK, web‑интерфейсы). Fabric, Corda и Besu могут быть интегрированы с любыми внешними IdP через OAuth2/OIDC.

Подписание транзакций и юридически значимых документов должно выполняться КЭП, выпущенной аккредитованным удостоверяющим центром. Проверяем использование Госключа. Технически КЭП хранится на токене или в HSM. При инициировании транзакции клиентское приложение должно вызвать функцию подписания через КриптоПро или другой СКЗИ, а затем передать подписанную транзакцию в сеть. Fabric и Corda позволяют передавать подпись как внешний артефакт, но в стандартных конфигурациях ожидают, что узел сам подписывает транзакции своим ключом. Необходима архитектурная доработка для использования внешней КЭП клиента.

Ключи, используемые для подписания транзакций и TLS‑соединений, должны храниться в аппаратных модулях безопасности (HSM) с сертификацией ФСБ. Fabric поддерживает HSM через PKCS#11. Corda также поддерживает HSM (интеграция с BouncyCastle). Besu/Quorum — аналогично через PKCS#11.

Банк России требует развертывания двух УЦ: один для ключей подписи транзакций, другой для ключей TLS. Все платформы позволяют использовать несколько корневых CA. Fabric CA может быть настроена в иерархической модели. Corda использует свои X.509-сертификаты, допускает разделение.

По части аппаратного обеспечения, согласно требованиям Банка России, для работы с цифровым рублём компоненты ИТ‑инфраструктуры должны быть изолированы от остальной ИТ‑инфраструктуры банка и участников. Все рассматриваемые платформы могут быть развёрнуты в изолированных сегментах сети, на выделенных серверах с использованием средств виртуализации и контейнеризации (Kubernetes с соответствующими политиками сетевой изоляции).

По части программного обеспечения, оно должно пройти оценку влияния встраиваемых компонентов (например, модуля ЦБ) на функционирование средств защиты информации. Требуется сертификация по 4-му уровню доверия (ОУД4). На самом деле, это требование предъявляется к процессу внедрения, а не к самой платформе. Выбранное решение (Fabric, Corda, Besu) должно быть развёрнуто с использованием сертифицированных СКЗИ и операционных систем (Astra Linux, Alt Linux и др.), а также сертифицированных платформ контейнеризации.

Обязательное логирование всех операций с цифровым рублём и действий администраторов для соответствия требованиям 115-ФЗ (ПОД/ФТ). Все платформы предоставляют детальные логи. Fabric и Corda поддерживают аудиторские узлы (audit nodes), которые могут получать все транзакции (включая приватные) при наличии соответствующих прав.

Итак, ключевые выводы по безопасности:

1. Нормативная база задаёт жёсткие рамки: положение № 833-П, стандарт платформы цифрового рубля ЦБ РФ, требования к СКЗИ — всё это делает обязательным использование ГОСТ‑криптографии на всех уровнях (подпись транзакций, TLS‑каналы, хранение ключей).
2. Corda нативно поддерживает ГОСТ: наличие GOST3411 с GOST3410 в документации на Corda 5.2.
3. Fabric требует доработок: Hyperledger Fabric может быть приведён к соответствию, но потребует:
   • Замены стандартного MSP на кастомный с интеграцией через КриптоПро или ViPNet;
   • Использования прокси для TLS‑соединений с ГОСТ‑поддержкой (например, Nginx с ГОСТ‑модулями);
   • Доработки клиентских SDK для работы с внешней КЭП (Госключ).
4. HSM — обязательный компонент: независимо от выбора платформы, потребуется интеграция с сертифицированными HSM (например, "КриптоПро HSM", ViPNet HSM) для хранения корневых ключей ЦБ, ключей узлов и ключей участников.
5. ЕСИА и Госключ — на уровне приложений: интеграция с ЕСИА и использование КЭП Госключ реализуется в клиентском слое (мобильные приложения, web‑ДБО) и не конфликтует с базовыми возможностями Fabric/Corda.
6. Сертификация платформы в целом: для внедрения в государственных и финансовых системах потребуется, чтобы всё решение (включая блокчейн‑платформу, СКЗИ, операционную систему, контейнеризацию) было сертифицировано по требованиям ФСТЭК России, что делает привлекательным использование готовых сертифицированных платформ российских вендоров, построенных на основе Corda, но уже адаптированной под ГОСТ и имеющей необходимые сертификаты.

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

По характеристикам отказоустойчивости, критическая инфраструктура (ЦБ, банки, госорганы) не допускает простоев. Требуется кластеризация всех типов узлов блокчейн‑платформы (peer, orderer, notary). У Fabric обеспечивается поддержка кластеризации peer‑узлов и orderer‑узлов (Raft). У Corda есть поддержка кластеризации notary‑сервисов и worker‑узлов.

Следующий фокус на возможностях построения геораспределенной ИТ‑инфраструктуры. Участники сети физически распределены по территории страны. Необходима работа в условиях разделения ЦОДов. В этой части все платформы поддерживают геораспределённое развёртывание при корректной настройке сетевых задержек.

Мощность платформ рассмотрели как способность устойчиво работать в условиях масштабируемости по числу участников и сделок. Участники сделок могут быть не только геораспределены, но увеличиваться по количеству. Сеть может включать сотни организаций и тысячи юридических лиц‑клиентов. У Fabric логическое масштабирование обеспечивают каналы. Для Corda применяется модель "каждая сделка — свой подграф участников", естественно она масштабируется. А в части пропускной способности и задержек: необходимо обрабатывать тысячи транзакций в секунду, время на подтверждения — секунды (не минуты). Fabric: 1000 — 3000 TPS в типовых конфигурациях. Corda показала сопоставимые возможности, платформы оптимизирована для финансовых транзакций.

Далее смотрим на поддержку резервного копирования и восстановления (DRP). Для этого были проанализированы доступные процедуры восстановления состояния блокчейна и ключевой информации. Fabric обеспечивает резервирование ledger‑данных и MSP‑материалов. Corda резервирует vault и node‑директории.

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

Подводим итог с учётом требований к надёжности и безопасности (ГОСТ/КЭП/ЕСИА). Обобщенные результаты выглядят вот так:

Corda и с некоторыми оговорками Hyperledger Besu (Enterprise Ethereum) — наиболее подходящие альтернативы Hyperledger Fabric для применения в финансовом секторе. Quorum также способен остаться в обойме развития.

Corda идеален для смарт‑контрактов, в которых важна максимальная конфиденциальность сделок и естественная изоляция данных между участниками с фокусом на финансовом секторе.

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

Идея смарт‑контрактов прошла долгий путь, и уже существуют игроки, которые предлагают готовые решения для реализации таких инициатив, поэтому у нас есть для вас четыре тезиса:

1. Платформа цифрового рубля стоит на пороге больших событий в финансовой отрасли: можно следить за ее развитием и создавать полезные сервисы, которые будут компенсировать банкам ликвидность, выпадающую из‑за отхода в сторону государственных денег. Надо иметь в виду вопросы безопасности и надёжности, чтобы пройти требования.
2. Идея создать государственно‑частную экосистему на базе платформ блокчейн с участием ЦБ, лизинговых и страховых компаний, банков и продавцов крупного оборудования полностью реализуема, потому что имеющиеся платформы предоставляют все необходимые механизмы: изоляцию данных (каналы, private data), гибкие политики подписания, поддержку цифровых активов (включая CBDC) и масштабируемость, а Центральный Банк при этом может выступать как владелец корневой инфраструктуры и эмитент цифрового рубля, оставаясь в распределённой среде, что соответствует принципам цифровых валют центральных банков.
3. Ключевой фактор успеха — качество проработки модели управления консорциумом, юридической стороны смарт‑контрактов и интеграции с существующими системами участников. Качественная сеть способна стать основой для национальной платформы финансирования инвестиционных товаров с минимальными рисками и высокой скоростью обслуживания. За счет платформ смарт‑контрактов повышаются шансы победить бюрократию.
4. Участниками процесса оплаты помимо банков могут стать лизинговые компании, страховые и другие финансовые институты, которые часто предлагают клиентам более быстрые услуги.