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 кілька незалежних приватних ключів повинні надіслати окремі схвалення, щоб задовольнити правила виконання смартконтракту.

Хоча це дуже ефективно для децентралізованих скарбниць, on-chain Multi-Sig створює три практичні перешкоди для традиційних банківських процесів:

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

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

Громадська видимість правил управління: Оскільки правила багатопідписових транзакцій виконуються через публічні смартконтракти, пороги кворуму, адреси підписантів та шаблони схвалення організації є видимими у публічному реєстрі.

Ці обмеження сприяли зростанню інституційного попиту на позаблочкову порогову криптографію, яка об’єднує політики безпеки на кількох блокчейнах.

Як працює багатоуступчастевий обчислювальний процес Google

Google Cloud Multi-Party Compute вирішує ризики, пов’язані з одноточковим ключем, за допомогою порогових схем підпису (TSS), побудованих на основі багатоучасникових обчислень (MPC). У цій криптографічній моделі повний приватний ключ ніколи не збирається на будь-якому окремому пристрої, сервері, шині пам’яті чи центрі обробки даних на жодному етапі генерації, зберігання чи підписання транзакцій.

Протокол підпису з жорстким порогом DKLs23

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

Реалізація Google зосереджена на трьох операційних пріоритетах:

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

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

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

Гетерогенне розбиття ключів: Модель кворуму 2 з 3

Замість генерації приватного ключа в одному місці та його подальшого розбиття, платформа використовує Розподілене генерування ключів (DKG), де незалежні ноди математично обчислюють свої частини ключа, ніколи не бачачи повного ключа.

Щоб уникнути концентрації ризику в одному хмарному провайдері, інституційні розгортання зазвичай використовують гетерогенну кворумну структуру 2 з 3:

Поділ 1 (середовище, що контролюється клієнтом): Розміщений безпосередньо в локальному центрі обробки даних фінансової установи або в виділеному середовищі HSM.

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

Поділ 3 (Незалежне відновлення або хмарне сховище третьої сторони): Розміщений у зовнішньому хмарному середовищі (наприклад, AWS або Azure) або зберігається офлайн незалежним агентом відновлення.

За цією структурою порогу 2 з 3 будь-які дві авторизовані частки можуть співпрацювати поза ланцюгом, щоб створити стандартний криптографічний підпис. Для базового блокчейну результатова транзакція виглядає ідентично нормальній транзакції з однією ключовою адресою.

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

Ізоляція на рівні апаратного забезпечення: Google Cloud Confidential Space (TEE)

Історичною проблемою з управлінням ключами у хмарі є підвищення привілеїв на рівні хоста: якщо операційна система або гіпервізор хмарного сервера будуть скомпрометовані, адміністратор з привілеями може спробувати перевірити криптографічні дані, збережені у системній пам’яті (RAM).

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.

Відмова від відповідальності: Для вашої зручності цю сторінку було перекладено за допомогою технології ШІ. Для отримання найточнішої інформації дивіться оригінальну англійську версію.