Крипто-кастоди с MPC: как безопасно хранить активы клиентов

Крипто-кастоди с MPC (multiparty computation) стало стандартом для fintech-компаний, хранящих активы клиентов: технология разбивает ключ на части и подписывает транзакции без сборки ключа в одном месте.Разбираем подробно: MPC кошельки, кастодиальный сервис, хранение криптоактивов, безопасность крипто кошельков. В статье разбираем, как работает MPC-кастоди, чем оно отличается от мультиподписи, какие требования предъявляют регуляторы и как выбрать провайдера кастоди для крипто-банка или обменника.

Что такое MPC-кастоди и как оно работает?

MPC — криптографическая технология, при которой приватный ключ никогда не существует целиком: его части распределены между несколькими участниками (серверами, устройствами). Подпись транзакции вычисляется распределённо, поэтому компрометация одного узла не даёт злоумышленнику ключ.

В отличие от мультиподписи (multisig), где требуется несколько разных ключей, MPC использует один логический ключ, разделённый на шарды. Это упрощает интеграцию с кошельками и смарт-контрактами и обеспечивает более тонкую политику подтверждений: лимиты, роли, двухфакторное подтверждение.

MPC против мультиподписи

Какие требования предъявляют регуляторы к кастоди?

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

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

1. Раздельный учёт активов клиентов и собственных средств
2. Субучёт по клиентам: отдельные адреса или чёткая привязка
3. Лимиты на горячие кошельки, основная масса — в холодном хранении
4. Страхование или гарантии покрытия рисков кастоди
5. Аудит безопасности и процедуры восстановления
6. Политика возврата активов клиентам по требованию

Как устроена архитектура кастоди в крипто-банке?

Типовая архитектура: операционный слой (горячие кошельки MPC для выводов и свопов, лимиты), резервный слой (тёплые кошельки со средними объёмами и таймерами), холодное хранение (офлайн-ключи для основной массы активов). Между слоями — процедуры пополнения и вывода с многоуровневыми подтверждениями.

Кастоди-слой интегрируется с core banking через API: создание депозитных адресов, запрос балансов, инициирование выводов. Ключевое правило — банковские сервисы не имеют прямого доступа к ключам: любые операции проходят через политику кастоди с лимитами и ролями.

Как выбрать провайдера кастоди?

Основные варианты: коммерческие провайдеры (Fireblocks, BitGo, Copper), self-hosted решения на основе open-source MPC (ZenGo, open-source библиотеки) и гибрид. Коммерческие провайдеры дают скорость запуска, страхование и соответствие требованиям регуляторов, но создают зависимость от вендора.

Критерии выбора: поддерживаемые блокчейны, модель страхового покрытия, соответствие требованиям MiCA/DORA, лимиты и политики подтверждений, API и возможность интеграции с вашим core banking, аудит безопасности и прозрачность. Для запуска MVP большинство команд выбирает Fireblocks или BitGo, а собственный кастоди строят при масштабировании.

Сравнение провайдеров кастоди

Как обеспечить соответствие DORA при кастоди?

DORA требует управления рисками ИКТ, тестирования и планов восстановления. Для кастоди это значит: резервные узлы подписи в разных регионах, процедуры восстановления шардов ключей, регулярные тесты вывода средств и планы на случай отказа провайдера кастоди.

Критично: документировать RTO (время восстановления) и RPO (допустимую потерю данных) для кастоди-операций и иметь exit-план на смену провайдера. Регулятор при аудите запросит результаты тестов восстановления и актуальные контракты с вендорами кастоди.

Какие ошибки допускают при внедрении кастоди?

Частые ошибки: хранение всех средств в горячих кошельках (риск взлома), отсутствие субучёта по клиентам (невозможность сверки), единая точка отказа в кастоди-провайдере, игнорирование требований регулятора к страхованию и слабое логирование операций подписи.

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

Частые вопросы

Что такое MPC в крипто-кастоди?

Технология multiparty computation: ключ разделён на части между узлами, подпись вычисляется распределённо, ключ целиком не существует нигде. Компрометация одного узла не даёт доступ к активам.

Чем MPC отличается от мультиподписи?

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

Какие требования предъявляет MiCA к кастоди?

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

Какой провайдер кастоди лучше?

Для MVP — Fireblocks или BitGo (скорость, страхование, соответствие). При масштабировании — собственный MPC-кастоди. Выбор зависит от объёмов, блокчейнов и требований регулятора.

Что такое горячие и холодные кошельки?

Горячие — подключены к сети, для операционных операций, с лимитами. Холодные — офлайн, для резервов. Основная масса активов должна храниться в холодном хранении.

Как восстановить доступ к средствам при сбое?

MPC-кастоди с избыточностью шардов и процедурами восстановления. Регулярные тесты вывода и планы восстановления — обязательное условие соответствия DORA.

Источники и методология

Техническое описание MPC — из открытой документации Fireblocks, ZenGo и академических материалов по secure multiparty computation. Требования регуляторов — MiCA (EU) 2023/1114 и DORA (EU) 2022/2554.

Автор: Дмитрий Орлов (CTO) — CTO, Konomic. 10+ лет в разработке: core banking, платёжные системы, блокчейн-архитектура, безопасность. Актуальность: 2026-08-20.

Explore: [Крипто-банкинг](https://konomic.com/) · [Разработка платформ](https://konomic.com/)