ENG
Технический вопрос, сможет ли Россия построить репозиторий программируемых смарт-контрактов без зарубежных решений, я считаю закрытым: ядро цифрового рубля уже работает, и надстройка над ним создается в той же инженерной логике. На мой взгляд, главная развилка проекта лежит не в плоскости импортозамещения, а в трёх сферах, которые пока проработаны слабее собственно ядра, а именно — в безопасности исполняемого кода, юридической значимости контрактов и экономике участников процесса. До какой степени и что в этом проекте суверенно, где в аппаратной части подозреваются узкие места, кто отвечает за ошибку в шаблоне и почему приватность расчётов физлиц лучше зафиксировать до, а не после запуска, обсудим в этой статье.
Повод для разговора — намеченное на 1 сентября 2026 года массовое внедрение цифрового рубля и сбор замечаний к концепции платформы коммерческих смарт-контрактов (ПКСК), который Банк России планирует проводить до 30 сентября 2026 года. Сам сбор замечаний занимает считанные недели, но реальное окно шире: по моей оценке, ближайшие полтора года — до тех пор, пока обсуждаемые нюансы не превратятся в нормативы и первую рабочую версию платформы, которые и определят качество будущей финансовой инфраструктуры. Поэтому заявить свою позицию нужно сейчас, до того, как закончится обсуждение.
Суверенность: по софту вопрос закрыт, по железу — остался
Платформа цифрового рубля построена как закрытая система с элементами распределенного реестра под управлением регулятора. На пути от концепции до внедрения её основной программный стек строили российские специалисты. По данным Банка России, к 1 июня 2026 года на платформе работали 15 банков, было создано порядка 2500 корпоративных кошельков и реализовано 17 базовых смарт-контрактов, по которым прошло свыше 37 тысяч операций. Таким образом, вопрос о принципиальной возможности реализации снят: ядро уже функционирует.
ПКСК — надстройка над этим ядром. В плане ПО она создается по той же схеме, без принципиальной привязки к иностранным продуктам. Криптография строится на алгоритмах, описанных в ГОСТах, — значит, зависимости от иностранных сертификационных центров нет. Для суверенного контура это важная деталь.
Сложнее с аппаратной частью. Серверы под высокую нагрузку, специализированные криптомодули, сетевое оборудование высокого класса в значительной части либо лицензируются, либо ввозится по параллельному импорту. Это удорожает инфраструктуру и удлиняет сроки поставок. Задача суверенной реализации ПКСК решаема: сложность сконцентрирована в качестве и стоимости конкретных компонентов, а не в самой возможности построить такую платформу.
Смарт-контракт — это исполняемый код, и у него тоже есть уязвимости
Это та область, которую я как специалист по кибербезопасности считаю недооцененной в ведущейся публичной дискуссии. Смарт-контракт для расчетов — не юридическая абстракция, а работающая программа. У любой программы бывают дефекты, а в финансовой инфраструктуре цена дефекта измеряется деньгами и потерянным доверием.
Международная история программируемых денег и токенов даёт жёсткий урок: крупнейшие потери индустрии случались не из-за взлома, а благодаря ошибкам в логике самих контрактов. Код исполнялся так, как написан, — а иногда он оказывался написан неверно. Переносить этот риск на уровень национальной платежной инфраструктуры нельзя.
Жизненный цикл шаблона смарт-контракта
Механизм работы с шаблонами смарт-контрактов должен быть описан не рамочно, а на уровне процедур. Хочу отметить три важнейшие связки.
- Аудит кода до запуска шаблона в оборот: обязательная независимая проверка логики, а не только формальная регистрация.
- Версионирование: каждый шаблон должен иметь прослеживаемую историю изменений, чтобы в спорной ситуации было ясно, какая именно версия исполнялась.
- Управляемое обновление: регламент, по которому уязвимость в уже работающем шаблоне закрывается без остановки расчётов без риска сломать данные зависящих от него сделок.
Отдельный слой — распределение ответственности при некорректном срабатывании. Между разработчиком шаблона, оператором платформы, банком-посредником и поставщиком данных (оракулом) должна быть заранее прописана схема, определяющая, кто отвечает за ошибку в коде, кто — за ложные входные данные, кто — за сбой в процессе исполнения. Без этого первая же спорная транзакция превратится в долгое и трудоёмкое разбирательство.
Юридическая сила: что главнее — документ или код
Второй не до конца проработанный узел — правовой. Смарт-контракт исполняет условия автоматически, но за ним стоит юридически значимый договор между сторонами. Концепция пока недостаточно чётко отвечает на вопрос, что считать основным обязательством, а что вспомогательным, и как разрешать спор, если письменный договор и логика кода вдруг разошлись.
Это не просто теоретическая проблема. Как только объёмы сделок вырастут, расхождения проявятся неизбежно, особенно если формулировка в договоре допускает толкования, а код исполняет один-единственный сценарий. Нужно заранее решить, где приоритет и в каком порядке можно оспорить результат автоматического исполнения. Правовую рамку разумнее выстроить сейчас, на этапе обсуждения, чем достраивать её впоследствии судебными прецедентами по факту понесённых убытков.
Приватность расчётов физлиц — вопрос, который нужно обсуждать заранее
Программируемость денег полезна там, где нужна прозрачность. В бюджетных платежах и госзакупках такой контроль разумен: целевое расходование можно отслеживать на уровне самого инструмента, а не по отчетности постфактум. Для расчетов между юрлицами — поставка против платежа, эскроу, многосторонние сделки — она тоже хорошо автоматизирует рутину и снижает издержки.
С расчётами физических лиц ситуация куда деликатнее. Здесь важно сразу очертить сценарии и прописать гарантии, при которых программируемые свойства цифрового рубля не сужают свободу распоряжаться деньгами по своему усмотрению так же просто, как с обычными наличной и безналичной формами. Я считаю, что этот вопрос стоит вынести в публичную плоскость и заранее зафиксировать в нормативном слое. Тогда дискуссия пойдёт вокруг конкретных норм, а не вокруг гипотетических опасений, — и снизит риск потери доверия к данному инструменту со стороны широкого круга граждан.
Комиссии, стимулы и банковский интерес
Чтобы платформа федерального масштаба не испытывала трудностей с масштабированием и внедрением, она должна покрывать стоимость собственного содержания. Бесконечно финансировать её из эмиссионных источников регулятора — очень неустойчивая схема. Логичным выглядит принцип cost recovery: минимальная комиссия, покрывающая операционные затраты и бюджет развития, без задачи по извлечению прибыли.
Стимулы для рынка концепция задаёт верно — разработчики шаблонов и поставщики данных смогут на них зарабатывать, типовые шаблоны станут самостоятельным товаром. А вот интерес банков-посредников проработан слабее, в отраслевой дискуссии на это уже указывали. Банки несут затраты на интеграцию и сопровождение, но источник, за счёт которого они покрывают свои расходы в приведённой схеме, неочевиден. Если экономику всех участников не сбалансировать, то банки будут подключаться неохотно или только формально — и вся система замедлится на этапе «последней мили».
Вопрос с оператором я бы решал поэтапно. На стадии становления роль регулятора как оператора системы вполне оправдана: проект инфраструктурно сложный и требует прямого контроля. Но в перспективе разумно вынести операторские функции в отдельное юрлицо по образцу Национальной системы платежных карт, которая тоже в своё время была выделена из ЦБ и развивает СБП и универсальные QR-коды самостоятельно. Такой подход разделяет роли регулятора и оператора, даёт необходимую операционную гибкость и снимает потенциальный конфликт интересов, оставляя государству стратегический контроль за критической инфраструктурой. Возможно, это вопрос не первого года эксплуатации платформы, а третьего или четвертого, но так или иначе он возникнет.
Международный контекст: опыт бразильского Drex
Опыт других юрисдикций стоит внимательно изучить. Бразильская система Drex, идейно близкая по программируемости, изначально строилась как CBDC на распределенном реестре с использованием платформы Hyperledger Besu. Столкнувшись с трилеммой одновременного обеспечения конфиденциальности, масштабируемости и программируемости, проект, по данным академического разбора в World Journal of Advanced Research and Reviews (2026), отошел от блокчейн-модели и сместился к централизованной разрешенной архитектуре под контролем центрального банка.
Российская модель централизована изначально — это снимает часть проблем, с которыми Бразилия столкнулась при реализации пилота. Но снятие архитектурной трилеммы не упраздняет инженерных вызовов: юридические аспекты, вопросы безопасности кода и баланса экономических интересов участников остаются независимо от выбранной архитектуры платформы.
Чем определяется успех проекта
Технически платформа реализуема силами российских специалистов — это уже не гипотеза, а факт. Но реальный успех проекта зависит от трёх факторов:
- насколько точно с инженерной точки зрения пропишут аудит, версионирование и обновление шаблонов;
- насколько ясно распределят юридическую силу и ответственность участников;
- насколько грамотно сбалансируют экономику банков-посредников и обеспечат гарантии приватности для физлиц.
Заметный экономический эффект от внедрения репозитория я ожидаю для отдельных отраслей в 2027–2028 годах. И проявится он не в статистике использования самой платформы, а в перестройке операционных моделей компаний: переходе от ручных согласований и сверок к автоматическим триггерам, который ускорит оборачиваемость капитала. Темп будет зависеть от того, насколько предметно будут проработаны спорные пункты концепции в ближайшие год-полтора. Поэтому банкам и крупным корпоративным игрокам имеет смысл не ждать запуска, а участвовать в обсуждении уже сейчас — со своими сценариями, требованиями к безопасности шаблонов и вопросами относительно ответственности. Когда эти пункты закрепятся в нормативах, менять их будет сложнее и дороже.
