MPC-разделение приватных ключей против горячих кошельков: шестой обязательный критерий безопасности при выборе биржи

После кражи 6,3 млрд долларов с горячего кошелька Binance многие задаются вопросом: почему у Coinbase никогда не было инцидентов подобного масштаба? О…

Официальная страница безопасности Coinbase

Почему у Coinbase до сих пор не было масштабных краж? MPC-разделение приватных ключей против горячих кошельков бирж: шестой показатель, на который стоит обратить внимание перед выбором площадки

29 октября в результате атаки «делегированного захвата» по стандарту EIP-7702 из горячего кошелька Binance было похищено 6,3 млрд долларов США — это второй по объёму ущерба инцидент в истории криптобезопасности. 1 ноября ФБР официально назвало организатором атаки северокорейскую группировку «Trader Traitor», а Binance объявила, что около 90 % убытков покрыты за счёт собственных средств и фонда SAFU (подробная хронология событий — в этом обновлении).

Вчера мы опубликовали статью «Северокорейские хакеры украли у Binance 6,3 млрд — пять показателей безопасности, на которые стоит ориентироваться при регистрации на криптобирже в 2026 году». В ней мы разобрали пять критериев выбора площадки: историю инцидентов, наличие защитного фонда, доказательства резервов (PoR), лицензирование и безопасность со стороны пользователей. Чаще всего нам задавали вопрос: почему у Coinbase, существующей уже много лет, никогда не происходило краж такого масштаба, как у Binance?

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

1. Четыре модели кастодиального хранения: различия — не в «холоде» и «тепле»

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

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

Холодный кошелёк: приватный ключ хранится автономно, вне сети и без физического подключения к интернету. Чтобы получить к нему доступ, злоумышленнику нужно либо физически завладеть устройством, либо проникнуть через цепочку поставок — значительно более высокий порог входа. Однако и здесь остаётся «точка отказа»: один целостный приватный ключ всё ещё сосредоточен в одном месте.

Мультиподпись (Multisig): контроль над активами делится на N полных приватных ключей, причём для подписи требуется одновременное участие M из них — например, 3 из 5. Любой отдельный ключ сам по себе позволяет подписывать транзакции, но без набора из M ключей активы недоступны. Эта модель исключает ситуацию «один человек решает всё», однако каждый ключ остаётся полноценным: потеря хотя бы одного снижает общий уровень защиты.

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

Кратко: мультиподпись — это «несколько полных ключей», MPC — это «один ключ, разбитый на части, и никто не видит его целиком». Не обязательно понимать математику — достаточно запомнить: горячий кошелёк ставит на один сервер, холодный — на одну точку хранения, мультиподпись — на то, что M человек не предадут одновременно, а MPC — на то, что несколько изолированных сред не будут взломаны одновременно.

2. Как работает MPC: три фрагмента ключа, никогда не собирающиеся вместе

Официальная документация Fireblocks: пояснение разделения приватных ключей и совместной подписи по MPC

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

При подписи участники не «передают фрагменты друг другу для сборки», а выполняют криптографические вычисления в своих изолированных средах, совместно генерируя итоговую подпись. Если любой из трёх участников выходит из процесса — подпись становится недействительной; если любой фрагмент покидает свою среду, он превращается в бесполезный набор данных, неспособный к самостоятельному использованию. Такой подход называется пороговой подписью (threshold signature): подпись, попадающая в блокчейн, выглядит как обычная, но полный приватный ключ никогда не воссоздаётся.

Именно в этом и заключается принципиальное отличие от горячего кошелька: при краже горячего кошелька злоумышленник получает целостный приватный ключ и может сразу перевести все активы; при компрометации одного сервера MPC-кошелька злоумышленник получает лишь один фрагмент, который не позволяет ни восстановить ключ, ни самостоятельно подписать транзакцию.

Важно также понимать: MPC — это не «копирование приватного ключа в трёх экземплярах и размещение их в трёх сейфах». Фрагменты связаны между собой протоколами вывода ключей и подписи: утечка одного фрагмента не ослабляет защиту остальных. А если просто сохранить приватный ключ в открытом виде в трёх копиях на трёх серверах — это будет не MPC, а «три резервные копии», и утечка любой из них может привести к потере всех средств.

3. Почему это объясняет, почему Coinbase труднее «взломать целиком»

Публичные раскрытия Coinbase идеально согласуются с описанной выше моделью. В её годовом отчёте 10-K за октябрь 2025 года, представленном в SEC, прямо указано: доля активов в горячих кошельках обычно составляет не более ~2 % от общего объёма кастодиальных средств; материалы приватных ключей для холодных кошельков хранятся в объектах в США и за рубежом; приватные ключи не хранятся в открытом виде, а их расшифровка требует «криптографического консенсуса» нескольких уполномоченных сотрудников, и никакое отдельное лицо не может контролировать или использовать приватные ключи кошельков Coinbase. Грег Тусар (Greg Tusar), сопредседатель Coinbase Institutional, в 2025 году публично заявил, что благодаря MPC полный приватный ключ никогда не существует в статичном виде и не появляется целиком ни на одном устройстве даже во время подписи.

Чтобы повторить «взлом целиком», злоумышленнику нужно не просто захватить один сервер с горячим кошельком, а одновременно проникнуть в несколько изолированных объектов, получить несколько фрагментов и пройти многоступенчатую процедуру одобрения. Каждый этап — отдельная точка отказа, и стоимость атаки возрастает в разы; социальная инженерия может обмануть «одно звено», но не «все звенья» одновременно.

Поэтому отсутствие крупных краж нельзя объяснять лишь удачей. Держа долю горячих кошельков ниже 2 %, Coinbase структурно ограничивает максимальный возможный ущерб даже при успешной атаке; а разделение ключей в холодных кошельках и многоуровневое одобрение превращают задачу «украсть всё» из простого взлома одного сервера в сложнейший захват всей операционной цепочки. Только совокупность этих двух мер даёт полное объяснение.

В отчёте 10-K за 2023 год также говорится, что Coinbase уже внедряет MPC и другие криптографические технологии для защиты средств пользователей. Это не постфактум-пиар, а архитектурный выбор, многократно подтверждённый в публичных отчётах. Однако в официальных документах не раскрываются количество фрагментов, используемые облачные провайдеры и точные места хранения — эту информацию можно считать «непубличной»: мы можем принимать факт использования MPC как достоверный, но не вправе придумывать детали вроде «где именно лежат три фрагмента».

4. Границы MPC: что он защищает, а что — нет

MPC очень эффективен, но не является «абсолютной защитой». Он решает проблему утечки единого приватного ключа, но не устраняет риски, связанные с людьми и бизнес-процессами.

  • Он защищает от взлома одного сервера, подкупа одного оператора с последующим прямым экспортом полного закрытого ключа, утечки одной резервной копии, ведущей к краже всего объёма средств, а также от сбоев или злонамеренных действий одного облачного провайдера, из-за которых ключи становятся напрямую доступны;
  • Он НЕ защищает от сговора нескольких сотрудников, обхода процедур одобрения методами социальной инженерии, чрезмерно широких прав API-ключей без настройки белого списка IP-адресов, фишинга для получения данных входа и прав на одобрение операций, замены адреса вывода средств и злоупотребления разрешениями смарт-контрактов.

На практике всё чаще крупные кражи происходят не из-за «взлома криптографии», а потому что «люди сами передают ключи». В случае Binance это был комбинированный инцидент: захват делегирования по EIP-7702 и атака методами социальной инженерии; аналогичным образом в инциденте Bybit 2025 года также задействовали социальную инженерию и проникновение в инфраструктуру. MPC повышает сложность «кражи одного ключа», но не может помешать уполномоченному сотруднику нажать кнопку «Подтвердить».

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

Пять. Перед регистрацией уточните у службы поддержки или на официальном сайте эти 5 пунктов

Не нужно вникать в криптографические научные статьи — пять простых вопросов помогут отсеять большинство платформ, которые «просто упоминают холодные кошельки»:

  1. Разделяется ли закрытый ключ между несколькими сторонами при кастодиальном хранении? Используется ли MPC или мультиподпись? Располагаются ли фрагменты ключа в разных географических регионах и у разных облачных провайдеров? Если служба поддержки отвечает лишь «У нас есть холодные кошельки», значит, архитектура не раскрыта.
  2. Поддерживается ли белый список адресов для вывода средств? При включении этой функции вывод возможен только на предварительно сохранённые адреса; для добавления новых адресов предусмотрен период охлаждения в 24 часа. Это последний барьер, препятствующий немедленному выводу средств сразу после кражи.
  3. Публикуется ли независимое доказательство резервов? Речь не о маркетинговом лозунге «резервы 1:1», а о проверяемых данных: Merkle-дерево, ончейн-адреса или письмо от независимого аудитора — желательно с возможностью для пользователей самостоятельно проверить свой баланс.
  4. Публикуются ли отчёты независимых аудитов? В том числе аудиты доказательства резервов, SOC 2, ISO 27001 и другие проверки безопасности. Обращайте внимание на дату отчёта и охватываемые им области — а не на логотипы на главной странице.
  5. Каков суточный лимит вывода средств? Чем ниже лимит, тем меньше максимальный ущерб при единичной краже; лимиты, белые списки и двухфакторная аутентификация (2FA) гораздо эффективнее, чем общие заявления вроде «мы очень безопасны».

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

Шесть. Сравнение пяти бирж: только данные, подтверждённые публично

В таблице указаны только те сведения, которые можно подтвердить в официальных документах, разделах помощи или на страницах официального доказательства резервов (PoR). Неподтверждённые данные указаны как «не раскрывается публично». «Использование MPC при кастодиальном хранении на бирже» и «использование MPC в самодостаточных (self-custody) кошельках» — это два разных вопроса, и в таблице они отмечены отдельно.

БиржаОфициально раскрытый способ кастодиального храненияСвязано ли с MPCДоказательство резервов (PoR)Белый список для вывода средств
BinanceРазделение на горячие и холодные кошельки; публикуются PoR и адреса части холодных кошельков; доля горячих кошельков не раскрываетсяСпособ кастодиального хранения на бирже не раскрывается; самохранимый кошелёк Binance Web3 использует MPC-схему 2 из 3Да, используется дерево Меркла + самостоятельная проверка пользователем; официальная страница PoR обновляется регулярноПоддерживается белый список адресов (адресная книга); для новых адресов действует период ожидания
OKXРазделение на горячие и холодные кошельки; точное соотношение не раскрываетсяСпособ кастодиального хранения на бирже не раскрывается; самохранимый продукт OKX Keyless Wallet использует трёхфрагментную MPC-схемуДа, используется дерево Меркла + zk-STARK; обновления ежемесячные, поддерживается самостоятельная проверка пользователемПоддерживается Allowlist: вывод возможен только на адреса из адресной книги
Gate.ioРазделение на горячие и холодные кошельки; в официальном отчёте PoR указан общий уровень резервов — 118 %; применяются дерево Меркла и zk-SNARKsСпособ кастодиального хранения на бирже не раскрывается; самохранимый продукт Gate Vault использует MPCДа, ежемесячный аудит с использованием дерева Меркла и zk-SNARK; пользователи могут провести самостоятельную проверкуПоддерживается белый список адресов для вывода средств
CoinbaseВ отчёте 10-K указано: доля активов в горячих кошельках не превышает ~2 % от всех хранимых активов; материалы закрытых ключей холодных кошельков хранятся в США и за рубежомДа, официально подтверждено использование MPC (в отчёте 10-K за 2023 г. и заявлениях руководства в 2025 г.); количество фрагментов и места их хранения не раскрываютсяНет возможности самостоятельной проверки через дерево Меркла для розничных пользователей; основная информация публикуется в отчётах SEC 10-K/10-Q; отдельный отчёт PoR не публикуетсяПоддерживается Address Allowlist и доверенная адресная книга
KrakenБольшинство активов хранится в холодном хранилище; Kraken Financial — банк с полным резервированием; точное соотношение горячих и холодных кошельков не раскрываетсяНе раскрываетсяДа, регулярные аудиты доказательств резервов совместно с независимыми аудиторами; пользователи могут войти в аккаунт и проверить данные самостоятельноРаботает механизм адресной книги; для новых адресов требуется подтверждение; наличие строгого переключателя «белый список» не раскрывается

На следующем скриншоте — официальная страница доказательства резервов OKX с возможностью ончейн-проверки: пользователи могут по пути в дереве Меркла убедиться, что их баланс включён в снимок. Такая «самостоятельная проверка» ценнее, чем просто публикация одного показателя уровня резервов.

Скриншот страницы ончейн-проверки доказательства резервов OKX

Обратите внимание на три момента при чтении таблицы: во-первых, MPC-решение Coinbase основано на публично раскрытой информации, однако детали фрагментации не раскрываются — не стоит считать его идентичным решению Fireblocks; во-вторых, информация об MPC от Binance, OKX и Gate.io в основном относится к их кошелькам с самостоятельным управлением, и из этого нельзя делать вывод, что те же самые решения используются и для кастодиального хранения на биржах; в-третьих, доказательство резервов подтверждает лишь «покрытие обязательств активами на определённый момент времени», но не подтверждает контроль над закрытыми ключами и не исключает наличие скрытых обязательств — оно дополняет архитектуру кастодиального хранения, а не заменяет её.

Седьмое. Тем, кто ещё не зарегистрировался: сначала — архитектура, потом — комиссии

Если у вас пока нет аккаунта: начните с отсеивания платформ, у которых явные недостатки в плане истории безопасности и соответствия требованиям — используйте для этого 5 показателей безопасности. Затем примените шестой показатель — архитектуру кастодиального хранения — чтобы проверить, реализована ли там модель «распределённого контроля над закрытым ключом» (без единой точки отказа). Только после этого обращайте внимание на комиссии и возврат комиссии.

Если вы хотите начать с крупнейших бирж, обратите внимание на две: страницу регистрации Binance — здесь самая высокая ликвидность и самый широкий выбор торговых пар, однако после последнего инцидента убедитесь, что включены белый список и двухфакторная аутентификация (2FA); страница регистрации Gate.io — у этой биржи есть лицензии в Азии и подробно раскрыто доказательство резервов (PoR), поэтому она хорошо подходит в качестве контрольного образца. Указанные на страницах размеры возврата комиссии, тарифы и действующие акции актуальны на момент посещения страницы — в данной статье никаких гарантий доходности не даётся.

На уровне кошельков можно вернуться к материалу «Как выбрать горячий, холодный или аппаратный кошелёк». Кастодиальное хранение на бирже обеспечивает удобство торговли, тогда как самостоятельное управление кошельком гарантирует, что ваши активы останутся в ваших руках даже в случае проблем с биржей. Это вопрос распределения ответственности, а не выбора одного из двух вариантов.

BlokWiki (blokwiki.com) будет регулярно отслеживать раскрытие информации о кастодиальных решениях, доказательствах резервов и инцидентах безопасности на всех биржах — это ваш долгосрочный ориентир при выборе площадки.

⚠️ Данная статья составлена на основе открытых источников и технической документации и не является инвестиционной рекомендацией. Ни MPC, ни мультиподпись, ни доказательство резервов не устраняют все риски полностью; цены криптовалют крайне волатильны — принимайте решения самостоятельно, исходя из вашей ситуации.
⚠️ В статье описаны только технологии и порядок действий; это не инвестиционная рекомендация. Криптоактивы крайне волатильны, риски есть и у бирж, и у кошельков. Проверяйте лицензии, делайте резервные копии ключей и сначала тестируйте небольшую сумму.