В России появятся смарт-контракты на цифровых рублях

Архитектура: оператор остаётся централизованным

Концепция предполагает, что финансовые организации и физлица смогут создавать и размещать собственные смарт‑контракты. Доступ — через «интерфейсы финансовых организаций», то есть напрямую в открытую среду пользователя не пустят. Оператором платформы на старте выступит сам ЦБ, позже возможен отдельный оператор. Это принципиально: мы имеем дело не с permissionless‑средой, а с витриной, где публикация контролируется на уровне инфраструктуры. Архитектура ближе к корпоративному блокчейну с централизованным гейткипером, чем к Ethereum или Solana, где деплой смарт‑контракта — это транзакция без предварительного одобрения.

На данный момент все смарт‑контракты на платформе цифрового рубля создаёт и контролирует сам Центробанк. Базовые сценарии для розничных клиентов уже реализованы: регулярные переводы в заданную дату и разовые переводы с указанием даты и времени исполнения. По состоянию на 1 июня исполнено 37 400 таких контрактов — объём скромный, но для пилота показывает, что платформа хотя бы работает в продакшене, а не на тестнете.

Модель безопасности: whitelist вместо открытого рынка

ЦБ явно осознаёт риски. В концепции заложены несколько уровней защиты: тестирование контрактов перед публикацией, проверка соответствия бизнес‑логике, требованиям законодательства и нормам информационной безопасности. Для предотвращения несанкционированных переводов и сбоев обещаны «технологии безопасной разработки» и инструменты проверки кода. Доступ из открытых сетей будет ограничен.

Интересен механизм контроля нагрузки: в случае неоптимального кода регулятор оставляет за собой право лимитировать количество допустимых операций. Это фактически признание того, что газовая модель (как в EVM) здесь не применяется — вместо экономического стимула для оптимизации кода используется административный рычаг. Разработчик, привыкший к тому, что неэффективный контракт просто дороже в исполнении, здесь столкнётся с жёстким rate‑лимитом на уровне оператора.

Для защиты от ошибок, вызванных багами или сбоями внешних источников данных, ЦБ намерен использовать предпубликационную верификацию кода. Как именно будут обрабатываться оракулы и внешние данные — в концепции не уточняется. Это критический пробел: без понятной модели интеграции off‑chain данных любая сколько‑нибудь сложная бизнес‑логика остаётся нерабочей.

Вердикт: контролируемая программируемость, а не децентрализация

С точки зрения архитектуры это не открытие smart‑contract layer для рынка — это расширение внутренней среды ЦБ с делегированием части логики внешним разработчикам. Permissioned доступ, централизованный оператор, административное управление нагрузкой, предмодерация контрактов — всё это укладывается в парадигму CBDC как инструмента государственного контроля, о чём глава ЦБ Эльвира Набиуллина говорила прямо: цифровой рубль нужен для контроля за расходами по госконтрактам.

Для разработчиков смарт‑контрактов это означает: забудьте про permissionless‑деплой, gas‑оптимизацию и открытый доступ к среде исполнения. Рабочая среда будет ближе к enterprise‑блокчейну с корпоративным governance. Те, кто планирует строить продукты на этой платформе, должны быть готовы к полной прозрачности кода перед регулятором и к тому, что производительность контракта будет регулироваться не рынком, а решением оператора.