Виведення коштів із казначейства очікує на схвалення. Фінансова команда підтвердила суму, команда з відповідності перевірила контрагента, а операційна команда стежить за чергою розрахунків. Потім стається тайм-аут API. Один підписант повторює запит, інший надсилає частково підписану транзакцію, а операційний журнал фіксує подію ще до того, як блокчейн щось підтвердив. Криптографія може бути надійною, але операційна система навколо неї — ні.
Саме в цьому полягає вибір MPC проти multisig. Питання не в тому, який метод краще захищає приватний ключ. Питання в тому, яка модель авторизації дає продуктовій, фінансовій, операційній командам і команді з відповідності надійний спосіб схвалювати, відправляти в мережу, звіряти, відновлювати й перевіряти переміщення активів.
Очевидний ворог — операційна неоднозначність. Вона виникає, коли підписання, перевірка правил, обробка подій і бухгалтерський облік існують у різних системах із нечітким розподілом відповідальності. Безпечна церемонія підписання не компенсує дубльовані виведення коштів, відсутні дані Travel Rule або процес звірки, що залежить від ручного порівняння електронних таблиць.
Зміст
- Дилема інституційного підписання
- Архітектурні основи розподіленої авторизації
- Оцінювання моделей безпеки та поверхонь атак
- Інтеграція регуляторних вимог і стійкості API
- Вибір архітектури відповідно до операційних сценаріїв
- Реалізація моделі Co-Signer під контролем клієнта
- Поширені запитання технічних покупців
Дилема інституційного підписання
Інституційний гаманець рідко існує ізольовано. Клієнт ініціює виведення коштів через застосунок, внутрішній механізм правил перевіряє запит, фінансова команда підтверджує бухгалтерське відображення, команда з відповідності оцінює контрагента, підписант або Co-Signer авторизує транзакцію, а сервіс відправлення передає її в мережу. Після цього події підтвердження мають надійти до операційного журналу та клієнтського продукту.
Архітектура підписання міститься посередині цього ланцюга. Якщо вона створює громіздкий процес схвалення, витрати несе операційна команда. Якщо вона приховує забагато логіки авторизації, витрати несуть команди з відповідності й аудиту. Якщо вона погано інтегрується з ідемпотентними API та журналами, у яких записи лише додаються, витрати несе фінансова команда.
Команди часто виявляють це вже після запуску. Продукт може починатися з помірної та передбачуваної казначейської активності, а потім додати вбудовані гаманці, автоматизовані розрахунки, поповнення карток, виведення у фіаті або платіжні потоки для кожного користувача. Початкова схема зберігання активів стає обмеженням, оскільки кожен новий процес має проходити через той самий жорсткий порядок схвалення.
Тому практичний огляд зберігання активів має дати відповіді на такі запитання:
- Хто може створити запит на транзакцію? Відповідь має бути пов'язана з ролями в застосунку, а не лише з володінням ключем або часткою ключа.
- Хто може її схвалити? Схвалення має враховувати суму, актив, адресу призначення, клієнта та контекст ризику.
- Що станеться в разі збою мережі? Повторний запит не повинен створити друге виведення або другу спробу підписання.
- Що звіряє фінансова команда? Операційний журнал має зберігати стійкі стани для запитаних, схвалених, підписаних, відправлених у мережу, підтверджених, відхилених і невдалих операцій.
- Що може довести аудитор? Система має зберігати рішення за правилами, учасників, часові позначки, ідентифікатори подій і остаточне посилання на транзакцію.
| Сфера рішення | Multisig | MPC |
|---|---|---|
| Місце авторизації | Скрипт у блокчейні або логіка смартконтракту | Розподілені обчислення до відправлення в мережу |
| Вигляд транзакції | Можуть бути видимі кілька підписів або явні умови витрачання | Стандартна транзакція з одним підписом |
| Головна операційна перевага | Прозоре застосування кворуму | Гнучке підписання в сумісних блокчейнах |
| Головне операційне навантаження | Координація незалежних підписантів і частково підписаних транзакцій | Експлуатація й перевірка складної інфраструктури порогового підписання |
| Найкраще початкове запитання | Чи потрібні учасникам публічно перевірні правила схвалення? | Чи потрібні продукту стандартна транзакція та гнучкий рівень виконання? |
Посібник зі зберігання цифрових активів стане корисною основою для команд, які документують ці обов'язки. Головний висновок простий: обирайте модель підписання разом з операційною моделлю. Гаманець, який захищає активи, але ускладнює звірку, розв'язує проблему зберігання лише частково.
Архітектурні основи розподіленої авторизації
І multisig, і MPC розподіляють авторизацію, але роблять це в різних місцях.
Система скриптів Bitcoin підтримувала умови, що вимагали кількох приватних ключів. Pay-to-Script-Hash, формалізований у BIP16, спростив використання таких умов у звичайних транзакціях. Типова схема — 2-з-3, у якій будь-які два з трьох незалежних ключів мають авторизувати витрачання. BitGo запустила перший широко відомий multisig-гаманець у серпні 2013 року, а протягом наступного року цю модель упровадили BitPay, Circle, Coinbase, CoinKite, Armory і GreenAddress. До кінця 2014 року частка біткоїнів, захищених multisig-схемами, зросла з 0,02% на початку року до понад 5% у грудні, а кількість щоденних multisig-транзакцій за попередній рік збільшилася в 79 разів, як повідомляє історичний огляд упровадження multisig від CoinDesk.
Multisig робить кворум правилом блокчейну
У нативному Bitcoin multisig m позначає мінімальну кількість потрібних підписів, а n — кількість наданих публічних ключів. Схема 2-з-3 записує три публічні ключі в умові витрачання та вимагає два відповідні підписи, перш ніж транзакцію можна буде перевірити. Порогове значення застосовує скрипт блокчейну.
Така видимість цінна. Спостерігач може перевірити структуру транзакції й зрозуміти, що авторизація вимагала визначеного кворуму. Компроміс полягає в тому, що власникам ключів зазвичай потрібно координувати частково підписану транзакцію. Вона переходить між відповідними сторонами, доки не буде досягнуто потрібного порога, що створює вимоги до процесів і передавання роботи між казначейською та операційною командами.
Отже, multisig — це більше, ніж вибір способу керування ключами. Це модель рахунку й урядування. Блокчейн, протокол або смартконтракт стає частиною рівня керування.
MPC залишає авторизацію в розподілених обчисленнях
Дослідження безпечних багатосторонніх обчислень беруть початок на початку 1980-х років. Роботи над пороговими підписами розвивалися від пропозицій 1990-х до двосторонніх протоколів 2000-х і практичніших протоколів 2010-х. Серед відомих етапів — практичний двосторонній протокол Лінделла 2017 року та багатосторонні розширення 2018 року, описані в огляді порогових підписів.
MPC використовує розподілення секрету та розподілені обчислення, щоб учасники могли спільно створити підпис без відновлення або розкриття повного приватного ключа. Результатом є сумісний підпис, який можна надіслати як стандартну транзакцію. Блокчейн бачить вихідний підпис, а не multisig-політику з окремими учасниками.
Ця відмінність впливає на конфіденційність, сумісність із блокчейнами, процедури відновлення та аудиторські докази. MPC не змушує авторизацію зникнути. Він переносить порогове рішення до криптографічних протоколів і систем, що їх виконують.
Командам, які переносять ці засоби контролю в програму аудиту, матеріал про контроль доступу в аудиті SOC 2 допоможе пов'язати технічні рішення щодо авторизації з керуванням доступом і збором доказів. Команди, що оцінюють деталі реалізації, також можуть розглядати інфраструктуру багатосторонніх обчислень як продуктову архітектуру, а не як ізольований криптографічний компонент.
Оцінювання моделей безпеки та поверхонь атак
Жодна з моделей не усуває ризиків. Кожна змінює те, де ризик зосереджений, як команди його спостерігають і який вигляд має відновлення.
У multisig кожен підписант зазвичай контролює незалежний приватний ключ. Компрометація одного підписанта не задовольняє автоматично правило 2-з-3, але цей ключ залишається повноцінними обліковими даними для підписання. Організація має захищати кожен ключ, зберігати незалежність підписантів, координувати схвалення та планувати дії на випадок втрати або недоступності.
У MPC учасники зберігають частки ключа та спільно створюють підпис без відновлення повного ключа. Одна частка не повинна самостійно авторизувати транзакцію. Модель безпеки значною мірою залежить від порогового протоколу, якості реалізації, ізоляції учасників, структури резервного копіювання та доступності інфраструктури підписання.
Матриця рішень
Матриця інфраструктури MPC проти multisig
| Критерій оцінювання | Мультипідпис (multisig) | Багатосторонні обчислення (MPC) |
|---|---|---|
| Застосування кворуму | Застосовується скриптом блокчейну або смартконтрактом | Застосовується через розподілені обчислення підписання |
| Ключовий матеріал | Кілька незалежних приватних ключів | Розподілені частки ключа, створені для уникнення відновлення повного ключа |
| Представлення в блокчейні | Публічні ключі та умова витрачання m-з-n можуть бути видимими | Стандартний вихідний підпис без multisig-політики в транзакції |
| Сумісність із блокчейнами | Залежить від підтримки нативних скриптів або смартконтрактів | Створює підписи, які приймають підтримувані блокчейни |
| Слід транзакції | Може показувати кілька підписів або складні умови витрачання | Нагадує стандартну транзакцію з одним підписом |
| Координація | Частково підписані транзакції переходять між власниками ключів | Учасники підписання координуються через протокол |
| Відновлення | Потребує задокументованого процесу заміни, резервного копіювання або міграції втрачених ключів | Потребує процедур резервного копіювання, оновлення, заміни часток і відновлення протоколу |
| Модель аудиту | Кворум і структуру схвалення можна перевірити в блокчейні | Докази авторизації потрібно зберігати в системах поза блокчейном |
| Основна поверхня відмови | Втрачені ключі, координація підписантів, неправильно налаштовані пороги й компрометація підписантів | Дефекти протоколу, відмови інфраструктури, компрометація часток і слабкі операційні засоби контролю |
| Відповідність урядуванню | Висока, коли учасникам потрібні видимі детерміновані правила схвалення | Висока, коли важливі гнучкість виконання та стандартні транзакції |
Практична відмінність — не в протиставленні «прозоре чи безпечне». Вона полягає в тому, де організація має створювати докази й засоби контролю. Multisig виносить більше правил на рівень транзакції, тоді як MPC вимагає від оператора зберігати надійні записи про перевірку правил, учасників, стан протоколу та результати підписання.
Команда, яка керує казначейством у Bitcoin зі стабільною групою підписантів, може цінувати нативний multisig, оскільки правило явне, а структура транзакції знайома. Команда, що керує гаманцями користувачів у кількох мережах, може віддати перевагу MPC, бо застосунок зберігає узгоджений інтерфейс підписання, а транзакція базової мережі залишається стандартною.
Відновлення потребує особливої уваги. Втрачений multisig-ключ може заблокувати досягнення порога або вимагати міграції гаманця залежно від правил і доступних резервних копій. Втрата частки MPC також може перервати підписання, хоча повний ключ ніколи не зберігався в одному місці. Оновлення й заміна часток не усувають потреби в перевірених процедурах відновлення.
Практичне правило: ставтеся до відновлення як до транзакційного шляху в робочому режимі. Перевіряйте, хто його ініціює, хто схвалює, які докази зберігаються та як операційний журнал фіксує перехід.
Докладніше про проєктування правил і роботу гаманця для Bitcoin дивіться в посібнику з multisig-гаманців Bitcoin. Правильний вибір залежить не стільки від назв, скільки від здатності організації послідовно керувати відповідною моделлю загроз і відновлення.
Інтеграція регуляторних вимог і стійкості API
Запит на підписання ніколи не повинен бути першим засобом контролю в регульованому процесі виведення коштів. Застосунок має вирішити, чи дозволене виведення, перш ніж будь-який процес порогового підписання авторизує відправлення в мережу.
Рекомендація FATF 16 вимагає від постачальників послуг віртуальних активів негайно й безпечно отримувати, зберігати та передавати необхідні дані про відправника й одержувача під час охоплених вимогами переказів віртуальних активів, згідно з настановами FATF щодо віртуальних активів і VASP. Регуляторне впровадження може відрізнятися, а пов'язані настанови вказують поріг у 1 000 доларів США/євро для охоплених переказів між зобов'язаними суб'єктами, як-от два VASP або VASP і традиційна фінансова установа.
Застосовуйте правила до підписання
Процес виведення коштів відокремлює бізнес-авторизацію від криптографічної авторизації.
- Прийміть команду. Перевірте автентифікованого викликувача, API-ключ з обмеженими правами, актив, мережу, суму, адресу призначення та стійкий ключ ідемпотентності.
- Створіть намір в операційному журналі. Запишіть запитану операцію до виклику сервісу підписання. Запис повинен мати стабільний внутрішній ідентифікатор і явний стан.
- Перевірте правила. Перевірте статус клієнта, санкційні ризики, юрисдикцію, ліміти транзакції, дані відправника й одержувача та потрібні ролі схвалення.
- Авторизуйте підписання. До процесу MPC або multisig потрапляє лише схвалений запит. Відхилені запити не повинні доходити до підписанта.
- Відправте в мережу та звірте. Збережіть посилання на підписану транзакцію, результат відправлення, події підтвердження й остаточний стан в операційному журналі.
Захист від повторного відтворення та ідемпотентність розв'язують різні проблеми. Захист від повторного відтворення використовує унікальний, бажано непередбачуваний nonce із часовою позначкою або вікном дійсності. Сервер записує прийняті nonce та відхиляє повторно використані або прострочені запити. Ключі ідемпотентності обробляють правомірні повторні спроби після тайм-ауту або мережевого збою, пов'язуючи повторні надсилання з тією самою операцією.
Та сама дисципліна має поширюватися на події. Споживачі подій депозитів і підтверджень повинні зберігати ідентифікатори оброблених подій перед підтвердженням виконання. Це захищає операційний журнал у разі повторного підключення WebSocket, затримки відповіді API або перезапуску обробника.
Закладіть спостережуваність у шлях розрахунку
Події WebSocket слід вважати механізмами доставки, а не самим операційним журналом. Споживачу потрібні стійка обробка подій, логіка повторного відтворення або відновлення та звірка з авторитетним станом транзакції. Виведення зі станом «підписано, але не відправлено» має залишатися відмінним від стану «відправлено, але не підтверджено».
Командам, які перевіряють рівень застосунку, може бути корисний практичний матеріал про 10 найкращих практик безпеки API. Головне запитання покупця: чи показує постачальник достатньо даних про події та правила, щоб інженерна, фінансова й команда з відповідності могли дослідити невдалу операцію без припущень.
Вибір архітектури відповідно до операційних сценаріїв
Найсильніша архітектура залежить від того, що робить гаманець, а не від того, яка технологія зараз модніша.
Розгляньмо iGaming-платформу, яка створює депозитну адресу для кожного гравця та отримує часті операції зі стейблкоїнами. Продукту потрібні спостереження за депозитами, події підтвердження, пов'язування з гравцем, контроль виплат та операційний журнал, здатний відрізнити помічений депозит від зарахованого балансу. Рівень підписання — лише один компонент. Платформі також потрібні операторські правила до схвалення виплати, особливо коли змінюються адреса призначення, статус клієнта або контекст відповідності вимогам.
Рівень виконання MPC може підходити для такого сценарію, коли бізнесу потрібні стандартні транзакції, автоматизовані процеси та узгоджений API для підтримуваних мереж. Платформа може відокремити ідентичності гаманців окремих гравців і засоби контролю застосунку від протоколу підписання. Це не усуває потреби в правилах схвалення. Це робить правила явними в пов'язаних сервісах правил та операційного журналу.
Казначейська команда має іншу проблему. Для неї пріоритетом можуть бути видимі правила кворуму, чітке схвалення зацікавлених сторін і публічно перевірне виконання. Нативний Bitcoin multisig може добре підходити, коли актив, блокчейн, група підписантів і процес урядування стабільні. Команді однаково потрібно документувати резервні копії, заміну підписантів, координацію транзакцій та екстрене відновлення.
Використовуйте операційний профіль як фільтр
| Операційна вимога | Імовірний вибір | Причина |
|---|---|---|
| Публічно перевірні казначейські схвалення | Multisig | Кворум можна представити в правилах витрачання в блокчейні |
| Автоматизовані потоки клієнтів або гравців | MPC | Стандартний вихідний підпис може відповідати керованому застосунком шляху виконання |
| Стабільна група підписантів у підтримуваному блокчейні | Multisig | Правило безпосереднє та простіше для перевірки зацікавленими сторонами |
| Кілька мереж і мінливі продуктові процеси | MPC | Застосунок може використовувати узгоджений інтерфейс підписання там, де він підтримується |
| Урядування, яке має бути видимим зовнішнім сторонам | Multisig | Структуру схвалення представлено на рівні рахунку або транзакції |
| Висока операційна залежність від API та потоків подій | Будь-який, за наявності сильних засобів контролю | Архітектура підписання не замінює ідемпотентність, правила або звірку |
AI Agents додають ще один вимір. Автономний агент не повинен отримувати необмежені повноваження над гаманцем лише тому, що йому потрібно оплатити послугу або виконати завдання. Застосунок має створити некастодіальний гаманець для кожного агента, застосувати рольовий контроль доступу, визначити дозволені дії та зберігати аудиторський слід, який пов'язує рішення агента з отриманою транзакцією.
Гаманець агента може використовувати MPC для розподіленого підписання, тоді як рівень керування обмежує адреси призначення, активи, типи транзакцій та умови схвалення. Multisig-схема може підходити агентові, який працює під видимим людським або організаційним кворумом. Рішення залежить від того, чи потрібні агентові автоматизоване виконання, видима для зацікавлених сторін авторизація або обидва елементи.
Практичний висновок: зіставте кожен гаманець із бізнес-роллю, перш ніж зіставляти його з технологією підписання.
Реалізація моделі Co-Signer під контролем клієнта
Командам, які запускають продукт до появи передбачуваного обсягу, потрібна модель зберігання активів без обох крайнощів. Повністю централізований сервіс підписання зосереджує операційні повноваження. Жорстка багатостороння схема може зробити розвиток продукту, відновлення та інтеграцію складнішими, ніж потрібно.
Co-Signer під контролем клієнта створює корисний проміжний варіант. У схемі MPC 2-з-3 клієнт зберігає одну частку, постачальник інфраструктури — другу, а окремий компонент відновлення або контролю — третю відповідно до моделі розгортання. Будь-які дві частки можуть авторизувати транзакцію, тоді як одна частка не здатна завершити процес підписання.
Контроль клієнта важливий, бо замовник може розгорнути й експлуатувати Co-Signer у власному середовищі. Постачальник може надати протокол підписання та транзакційну інфраструктуру, не стаючи єдиним органом, що контролює переміщення активів. Це підтримує некастодіальну операційну модель за умови, що клієнт контролює свою частку, правила доступу, дозволи розгортання та процедури відновлення.
Тримайте рівень керування окремо
Co-Signer не слід вважати самостійною політикою схвалення. Застосунку однаково потрібні API-ключі з обмеженими правами, рольовий контроль доступу, правила для адрес призначення, санкційні перевірки, черги схвалення та операційний журнал, у якому записи лише додаються.
Надійний процес має такий вигляд:
- Продукт створює запит: API гаманця або розрахунків записує заплановану операцію та її ключ ідемпотентності.
- Правила оцінюють запит: правила відповідності, фінансів і ризиків визначають, чи може відбутися виведення коштів.
- Co-Signer під контролем клієнта бере участь: середовище клієнта схвалює або відхиляє сеанс підписання відповідно до власних засобів контролю.
- Сервіс підписання досягає порога: протокол MPC створює сумісний підпис без відновлення повного приватного ключа.
- Події оновлюють операційний запис: повідомлення WebSocket визначають результати депозиту, підтвердження, виведення та перевірки правил, а споживачі захищаються від дубльованої обробки.
Ця модульна структура дає команді змогу вбудовувати гаманці для користувачів, гравців або AI Agents, зберігаючи баланси гаманців, інтеграції для фіатного вводу/виводу, карткові потоки й розрахункові операції пов'язаними з однією моделлю контролю. Такий продукт, як BroSettlement, може забезпечувати DKG і підписання MPC 2-з-3 з Co-Signer під контролем клієнта, а BroWallet — підтримувати взаємодії з гаманцями, біржами, банками й картками як частину ширшого процесу застосунку.
Модель працює лише тоді, коли клієнт відповідає за операційну дисципліну. Перевіряйте доступність Co-Signer, відкликайте скомпрометовані облікові дані, відпрацьовуйте відновлення часток, переглядайте зміни правил і звіряйте кожен результат підписання з операційним журналом. Розподілена авторизація зменшує ризик зосередження ключа, але не виправдовує слабке керування доступом або незадокументовану обробку винятків.
Поширені запитання технічних покупців
Чи безпечніший MPC за multisig?
Жоден варіант не є автоматично безпечнішим. Multisig робить кворум видимим і застосовує його в скрипті блокчейну або смартконтракті. MPC розподіляє повноваження підписання між частками ключа та створює стандартний підпис. Безпечніший вибір залежить від моделі загроз, якості реалізації, структури відновлення, вимог блокчейну й здатності організації керувати засобами контролю.
Чи забезпечує multisig кращі можливості аудиту?
Він забезпечує кращу видимість у блокчейні щодо умови витрачання, а залежно від реалізації — також підписів або структури схвалення. MPC вимагає від організації зберігати поза блокчейном докази перевірки правил, учасників підписання, результатів протоколу й рішень щодо транзакцій. Отже, в обох моделях можливість аудиту є відповідальністю архітектури системи.
Чи може організація перейти з multisig на MPC?
Так, але до міграції слід ставитися як до контрольованого переходу активів і правил. Інвентаризуйте баланси, адреси призначення, ролі підписантів, правила схвалення та залежності звірки. Створіть новий гаманець або відносини підписання, перевірте депозити й виведення в контрольованому середовищі, виконайте схвалене переміщення активів і збережіть чіткий зв'язок між старими та новими записами.
Як командам керувати затримкою підписання?
Вимірюйте повний процес, а не лише криптографічні обчислення. Враховуйте перевірку правил, доступність Co-Signer, черги схвалення, повторні запити API, відповідь на відправлення в мережу та обробку підтверджень. Швидкий підпис не допоможе, якщо справжню затримку створює перевірка відповідності вимогам або звірка подій.
Що робить операційний журнал придатним для звірки?
Використовуйте операційний журнал, у якому записи лише додаються, зі стабільними ідентифікаторами операцій і явними переходами стану. Записуйте початкову команду, ключ ідемпотентності, результат перевірки правил, результат підписання, відповідь на відправлення в мережу, події підтвердження та всі винятки або сторнування. Фінансова команда повинна мати змогу звірити журнал із мережевою активністю, не покладаючись на тимчасові повідомлення WebSocket.
Чи повинні AI Agents користуватися власними гаманцями?
Вони повинні мати гаманці й дозволи з вузькою сферою дії, а не необмежений доступ до спільного казначейства. Застосовуйте рольовий контроль, обмеження адрес призначення, правила витрачання, шляхи передавання рішення людині й стійкі аудиторські сліди. Архітектура підписання підтримує ці засоби контролю, але визначати й застосовувати їх має застосунок.
BroLabel надає API-first інфраструктуру для вбудованих MPC-гаманців, спільного підписання під контролем клієнта, розрахунків, відправлення в мережі, операційного журналу, у якому записи лише додаються, подій WebSocket, карток і фіатних процесів. Якщо вашій команді потрібно пов'язати архітектуру підписання з регуляторними вимогами, ідемпотентністю та звіркою, ознайомтеся з BroLabel й оцініть шлях від тестування в ізольованому середовищі до операцій у робочому режимі.
