Web3 Tech: новости

Сколько раз я сталкивался с тем, что закрытый ключ или сид-фраза просто лежит в переменных окружения, в базе данных, где-нибудь в секретах Kubernetes. Все это очень плохие способы защиты, которые, может быть, применимы где-то в Web2-мире для хранения логина и пароля от БД или ключа от внешнего сервиса. Но для защиты криптографических ключей это совсем не подходит.

Если цифровой анализ войдет в общий контур исполнения требований Федерального закона № 115-ФЗ, для клиента могут применяться действующие механизмы обжалования ограничений и реабилитации, которые уже используются в банковской сфере. При этом способы оценки и результаты цифрового анализа будет сложно оспорить, поскольку они являются конфиденциальными.

В изолированном аппаратном модуле HSM (Hardware Security Module), который обеспечивает защиту от компрометации. Закрытые ключи являются неизвлекаемыми и никогда не покидают пределы HSM. Даже при физическом доступе к серверу получить или скопировать их невозможно.

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

Здесь сочетаются три фактора:

Неизменяемость кода. Ошибки в смарт-контракте нельзя просто поправить патчем. Требуется продуманная архитектура обновлений, прокси-механизмы и строгая дисциплина разработки.
Интеграция с внешними системами. Смарт-контракт по своей природе изолирован. Любая внешняя логика требует использования оракулов, шлюзов и криптографически проверяемых источников данных.
Корректная формализация бизнес-логики. Заказчик не всегда изначально понимает, что именно должно быть зафиксировано на уровне неизменяемого кода. Поэтому значительная часть работы — это перевод юридических и бизнес-требований в строгую формальную модель.

Фактически это не только программирование, а архитектурная и методологическая задача.

Правильное внедрение блокчейн-технологий вообще всегда про изменение механики доверия и исполнения обязательств, а не про улучшение показателей на условные 10%. Если компания использует смарт-контракт просто как дополнительную базу данных, эффект будет минимальным.

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

Для запуска продуктов с цифровой валютой банкам, брокерам и депозитариям нужны не «криптоэнтузиасты», а новые компетенции внутри продуктовых, риск-, комплаенс-, ИБ- и операционных команд. Рынку нужны специалисты, которые умеют перевести работу криптоинфраструктуры на язык регулируемой финансовой организации: лимитов, процедур, риск-аппетита, проверки операций, договорной модели, учета, аудита, хранения ключей и ответственности за операцию.

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

Российский рынок развивается не через публичный DeFi, а через регулируемые закрытые контуры — операторы информационных систем ЦФА, цифровой рубль, отдельные государственные распределенные реестры и экспериментальные режимы. Это снижает открытость и компонуемость по сравнению с глобальными public chains, но дает юридическую определенность, контроль участников и понятную ответственность операторов.

Главный практический сегмент — ЦФА. В 2025 году объем их размещений составил около 1,65 трлн рублей.

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

Внедрение цифрового рубля добавит в российскую финансовую систему программируемый суверенный рублевый settlement layer. Он может стать базой для программируемых бюджетных, B2B и розничных расчетов; во внешней торговле будут развиваться гибридные схемы с национальными валютами, цифровыми правами, CBDC-шлюзами и стейблкоинами.

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

Новая волна атак является следствием эволюции и коммерциализации криптопреступности.

В первую очередь происходит стремительная индустриализация мошенничества — криптодрейнеры теперь предлагаются по модели Drainer-as-a-Service. Разработчики продают готовые инструменты и сопровождение хакерам с низкой квалификацией, получая процент от украденного. Это делает вход в киберпреступность максимально низким.

Вместе с этим происходит развитие хакерской инфраструктуры — преступные группы предлагают полностью автоматизированную инфраструктуру с Telegram-ботами и лендингами, трекингом кампаний и инструментами уклонения от обнаружения. Это позволяет быстро масштабировать атаки и менять тактику.

А увеличение числа русскоязычных инвесторов и общий рост крипторынка делают конкретно нашу аудиторию привлекательной целью.

К 2026 году архитектура кастодиального хранения Web3 смещается от модели «храним private key в холодном сейфе» к распределенной системе управления подписью.

Главный технологический тренд — гибрид HSM и MPC/TSS.

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

MPC закрывает более динамичные Web3-сценарии: горячие/теплые кошельки, массовые операции, DeFi-операции, multi-chain-инфраструктуру. Полный приватный ключ не хранится ни на одном сервере и не собирается в памяти. Вместо этого подпись создается распределенно между несколькими узлами по кворуму, например 2-of-3 или 3-of-5. Это снижает риск компрометации одного администратора, сервера, региона или облака.