Google запустит платформу институционального криптокошелька в 2027 году: как работает ее технология MPC

2026/11/01 11:01:00

Google Cloud представила Google Multi-Party Compute (MPC) — специализированное решение для управления и хранения ключей цифровых активов, разработанное для глобальных банков, управляющих активами и регулируемых финансовых институтов. В настоящее время решение находится в частном предварительном доступе по приглашению, а коммерческий выпуск (GA) запланирован на начало 2027 года. До масштабного коммерческого запуска Google протестировала архитектуру в внутренних производственных средах, поддерживающих крупные экосистемы блокчейн, включая ethereum и Solana.

Эта инициатива представляет собой значительное расширение корпоративной облачной инфраструктуры Web3. В течение нескольких лет основные облачные провайдеры сосредотачивали свои услуги по цифровым активам преимущественно на размещении RPC-нод, индексировании публичных наборов данных блокчейна в BigQuery и изучении корпоративных сетей расчетов.

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

Компрометация ключей и компромиссы при институциональном хранении

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

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

Устаревшие аппаратные модули безопасности и риски единой точки отказа

Традиционное управление ключами в финансовой сфере в значительной степени зависит от физических аппаратных модулей безопасности (HSM) и изолированных холодных хранилищ. Хотя HSM изолируют криптографические ключи внутри защищённого от вмешательства оборудования, стандартные конфигурации с одним ключом всё ещё могут создавать структурную единую точку отказа (SPOF).

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

Ограничения мультиподписи на цепочке

Чтобы избежать зависимости от одного ключа, многие веб-3 протоколы используют блокчейн-многоподписные (Multi-Sig) смарт-контракты, такие как Safe. В стандартной структуре M из N Multi-Sig несколько независимых закрытых ключей должны предоставить отдельные подтверждения, чтобы выполнить правила исполнения смарт-контракта.

Хотя он высокоэффективен для децентрализованных казначейств, он-чейн Multi-Sig создает три практические трудности для традиционных банковских рабочих процессов:

Несовместимость между блокчейнами: Логика мультиподписи смарт-контрактов не является единой в различных гетерогенных блокчейнах уровня 1. Хотя на сетях Ethereum Virtual Machine (EVM) она широко стандартизирована, реализация идентичной governance смарт-контрактов в не-EVM блокчейнах (таких как Bitcoin или Solana) требует использования различных нативных скриптов и отдельных операционных конвейеров.

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

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

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

Как работает многопартийный вычислительный процесс Google

Google Cloud Multi-Party Compute устраняет риски, связанные с единой точкой хранения ключей, внедряя пороговые схемы подписи (TSS), основанные на многопартийных вычислениях (MPC). В рамках этой криптографической модели полный закрытый ключ никогда не собирается на одном устройстве, в памяти сервера или в центре обработки данных на любом этапе генерации, хранения или подписи транзакции.

Протокол жесткой пороговой подписи DKLs23

Согласно техническим спецификациям платформы, signing-движок Google ECDSA включает защищенную реализацию протокола DKLs23. Названный в честь криптографов Дётлинг, Комаргодски, Лай и Шен, DKLs23 — это современный пороговый протокол подписи, предназначенный для безопасного вычисления подписей на эллиптических кривых между распределенными участниками с минимальными накладными расходами на коммуникацию.

Реализация Google сосредоточена на трех операционных приоритетах:

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

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

Поддержка нескольких кривых блокчейна: архитектура нативно поддерживает алгоритм цифровой подписи на эллиптических кривых (ECDSA) на кривой secp256k1 — стандарт для Bitcoin, Ethereum и сетей Layer-2, совместимых с EVM, а также промежуточную поддержку алгоритма цифровой подписи на кривых Эдвардса (EdDSA) на Ed25519 для покрытия высокопроизводительных сетей, таких как Solana.

Гетерогенное разделение ключей: модель кворума 2 из 3

Вместо генерации частного ключа в одном месте и последующего его разделения платформа использует распределённую генерацию ключей (DKG), при которой независимые ноды математически вычисляют свои соответствующие доли ключа, причём ни одна нода никогда не видит полный ключ.

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

Share 1 (клиент-контролируемая среда): Размещена непосредственно в собственном центре обработки данных финансового учреждения или в выделенной среде HSM.

Поделиться 2 (Google Cloud Enclave): Размещено в среде Confidential Space с аппаратной изоляцией Google Cloud.

Share 3 (Независимое восстановление или облачное хранилище третьей стороны): Размещено во внешней облачной среде (например, AWS или Azure) или хранится оффлайн независимым доверенным лицом для восстановления.

При этой пороговой структуре 2 из 3 любые две авторизованные доли могут сотрудничать офф-чейн для создания стандартной криптографической подписи. Для базового блокчейна результирующая транзакция выглядит идентично обычной транзакции с одним ключом.

Если злоумышленник проникнет в одну среду, он получит только одну изолированную долю ключа — которая математически не раскрывает ничего о полном закрытом ключе и не может самостоятельно авторизовывать транзакции. Напротив, если локальная рабочая станция учреждения будет скомпрометирована, злоумышленник все равно не сможет перемещать средства без согласия, если Google Cloud не подтвердит независимо, что транзакция соответствует заранее заданным политикам безопасности.

Изоляция на уровне аппаратного обеспечения: Google Cloud Confidential Space (TEE)

Исторической проблемой при управлении ключами в облачной среде является повышение привилегий на уровне хоста: если операционная система или гипервизор облачного сервера будут скомпрометированы, администратор с повышенными привилегиями может попытаться просмотреть криптографические данные, хранящиеся в системной памяти (ОЗУ).

Google снижает этот риск, запуская свои MPC-узлы для подписи внутри Google Cloud Confidential Space — защищенной среды выполнения (TEE), основанной на оборудовании для конфиденциальных вычислений:

Шифрование памяти на аппаратном уровне: Confidential Space использует шифрование памяти на уровне процессора (например, AMD SEV-SNP), обеспечивая шифрование ключевых фрагментов и промежуточных вычислений подписи в ОЗУ с использованием аппаратных ключей, недоступных для хостовой операционной системы.

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

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

Принудительное применение политики транзакций и механизмы обновления ключевых фрагментов

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

Движки проверки политики предварительной подписи

Для защиты от неавторизованных переводов на уровне приложения Google Cloud встраивает детерминированный движок проверки политик непосредственно внутрь анклава Confidential Space. Прежде чем нода MPC от Google участвует в цикле пороговой подписи, предлагаемая нагрузка транзакции проверяется против установленных институциональных правил управления — таких как белые списки адресов назначения, лимиты максимальной стоимости транзакции, ограничения скорости, временные окна и подписи кворума с несколькими утверждающими.

Если скомпрометированный конечный терминал пытается запросить перевод на неодобренный адрес или сверх разрешенных лимитов, анклав отклоняет запрос на подпись до начала вычисления криптографических долей.

Проактивное разделение секретов (обновление ключевых фрагментов)

Чтобы снизить риск того, что изощренный злоумышленник постепенно скомпрометирует несколько нод в течение длительного периода, архитектура поддерживает проактивное разделение секрета (PSS), обычно называемое вращением или обновлением ключевых фрагментов.

На регулярной основе или после изменений в персонале участвующие ноды запускают математический протокол обновления:

Ноды совместно вычисляют совершенно новый набор криптографических долей.

Предыдущие ключевые фрагменты постоянно недействительны и перезаписаны.

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

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

Постквантовая гибкость и коммерческая готовность к 2027 году

Поскольку финансовые учреждения оценивают инфраструктуру хранения с многолетней перспективой, долгосрочная криптографическая гибкость, включая подготовку к квантовым вычислениям, стала важным архитектурным соображением. Стандартные схемы на эллиптических кривых (secp256k1 и Ed25519) основаны на математических задачах, которые в конечном итоге могут оказаться уязвимыми перед достаточно мощными, устойчивыми к сбоям квантовыми компьютерами.

Хотя первоначальный запуск MPC от Google Cloud направлен на устранение немедленных операционных угроз, таких как кража учетных данных, единственные точки отказа и сговор внутри компании, платформа разработана с учетом криптографической модульности. Разделяя оркестрацию политик и API-слои от базовых механизмов подписи, архитектура создана так, чтобы поддерживать будущие постквантовые криптографические (PQC) и квантово-безопасные протоколы передачи по мере завершения спецификаций постквантовых подписей блокчейн-сетями и международными стандартными организациями (такими как NIST).

Заключение

Развертывание Google Cloud инфраструктуры многопартийных вычислений для институциональных клиентов подчеркивает продолжающееся созревание корпоративной безопасности цифровых активов. Объединяя протокол пороговой подписи DKLs23 с аппаратно подтвержденными анклавами Confidential Space и гетерогенным распределением ключей 2 из 3, платформа помогает финансовым учреждениям снизить риски, связанные с единой точкой отказа ключей, не жертвуя скоростью подписи или гибкостью работы с несколькими блокчейнами. По мере приближения сервиса к коммерческому запуску в 2027 году облачные MPC-решения будут играть все более важную роль в обеспечении безопасности токенизированных активов в масштабе.

ЧаВо

Что такое Google Cloud Multi-Party Compute?

Google Cloud Multi-Party Compute (MPC) — это институциональная платформа для управления и подписи ключей цифровых активов, которая в настоящее время находится в закрытом предварительном доступе перед запланированным коммерческим запуском в начале 2027 года. Она использует пороговую криптографию для разделения контроля над частными ключами между отдельными средами, исключая единственные точки отказа при подписании транзакций в блокчейне.

Почему Google нацеливается на коммерческую доступность в 2027 году?

Запуск закрытого предварительного просмотра по приглашению в конце 2026 года позволяет партнерским банкам и институциональным управляющим активами проводить аудит безопасности, интеграцию политик и тестирование соответствия. Цель общего доступа в начале 2027 года согласована с растущим внедрением со стороны институциональных участников в рамках зрелых регуляторных рамок, таких как режим MiCA ЕС и развивающиеся стандарты Базельского комитета по экспозициям банков к криптоактивам.

В чем различие между MPC от Google и мультиподписью на цепочке?

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

Устраняет ли технология MPC все риски хранения криптовалют?

Никакая архитектура безопасности не может устранить все риски. Хотя MPC устраняет единую точку отказа, связанную с хранением полного закрытого ключа в одном месте, учреждениям все еще необходимо защищаться от фишинга, компрометации конечных точек и несовершенной внутренней управления. Дизайн Google помогает снизить эти операционные риски, сочетая гетерогенно разделенные фрагменты ключа с аппаратно изолированными анклавами Confidential Space и проверками политик перед подписью.

Отказ от ответственности

Эта общая рыночная информация, возможно, из сторонних, коммерческих или спонсорских источников, предоставлена исключительно в справочных и образовательных целях и не является финансовой или инвестиционной консультацией, предложением, запросом или гарантией. Мы отказываемся от ответственности за её точность, полноту, надежность и любые возникшие потери. Инвестиции/торговля сопряжены с риском; прошлые результаты не гарантируют будущих. Пользователи должны проводить собственные исследования, принимать взвешенные решения и нести полную ответственность. Для получения дополнительной информации ознакомьтесь с Условиями использования и Раскрытием рисков KuCoin.

Отказ от ответственности: Эта страница была переведена для вашего удобства с использованием технологии искусственного интеллекта. Для получения наиболее точной информации обратитесь к оригинальной английской версии.