Фінтех-команда запустила виплати у блокчейні. MPC-церемонію завершено, гаманець поповнено, а API повертає запит на підписання. О третій ночі виведення відхиляється. Операційна команда запитує, хто може його схвалити. Команда безпеки — якому сервісу належить частка ключа. Команда з відповідності просить рішення політики та аудиторський слід. Інженери з'ясовують: усі розуміють пороговий протокол, але ніхто не відповідає за Co-Signer.
Саме ця прогалина розкриває практичне значення обов'язків Co-Signer. У кредитуванні співпідписувач може відповідати за погашення. В MPC-інфраструктурі Co-Signer — це учасник порогової схеми, відповідальний за безпечну участь, виконання політик, доступність, фіксацію доказів і відновлення без реконструкції приватного ключа. Технологія може бути розподіленою, але відповідальність усе одно потребує визначеного власника.
Зміст
- Чому команді потрібна визначена роль Co-Signer
- Що насправді робить Co-Signer у MPC
- Основні обов'язки кожного Co-Signer
- Co-Signer під контролем клієнта або постачальника
- Обов'язки Co-Signer у некастодіальному процесі
- Ризики, контроль і поширені сценарії збою
- Операційний список перевірки та запитання покупця
Чому команді потрібна визначена роль Co-Signer
Проблему зазвичай виявляє перший інцидент у робочому середовищі. Транзакція не виконується, бо Co-Signer недоступний, адреса призначення не входить до списку дозволених або пакет політик відрізняється від версії, схваленої командою з відповідності. Система поводиться правильно, але команда не може швидко відповісти: хто розслідує, хто може призупинити підписання, хто оновлює частку і хто пояснює рішення аудитору?
Пороговий протокол не розподіляє ці обов'язки автоматично. Інженери можуть відповідати за MPC-бібліотеку, безпека — за хост, операційна команда — за черги виплат, а команда з відповідності — за правила транзакцій. Без задокументованих меж кожна команда вважатиме, що за поведінку Co-Signer відповідає хтось інший.
Відповідальність потребує власника
Власник Co-Signer має бути зазначений у регламенті, каталозі сервісів, матриці інцидентів і договорі з постачальником. Це не обов'язково одна людина, яка постійно керує вузлом. Власником може бути сервісна команда з чергуванням, якщо сфери відповідальності визначено явно.
Власник має без реконструкції системи з журналів відповісти на п'ять запитань:
- Хто експлуатує: яка команда відповідає за розгортання, доступність, оновлення та доступ операторів?
- Хто контролює політику: хто схвалює дозволені блокчейни, активи, адреси, ліміти й аварійні зупинки?
- Хто отримує сповіщення: який маршрут ескалації обробляє втрату кворуму, підозрілі запити й затримку підписання?
- Хто доводить виконання: які незмінні записи показують запит, результат політики, частковий підпис, подію кворуму й відправлення в мережу?
- Хто керує відновленням: хто може розпочати оновлення частки, відновити сервіс або провести задокументовану резервну церемонію?
Фінансове зобов'язання зі співпідписанням створює пряму відповідальність, а не символічну обіцянку. Рекомендації FTC щодо співпідписання кредитів пояснюють, що співпідписувач може нести рівну відповідальність за погашення. Аналогія з MPC є операційною, а не юридичною, але висновок схожий: допоміжний учасник — не пасивна резервна копія.
Практичне правило: якщо поруч із доступністю, політикою, аудитом і відновленням немає імені відповідального, Co-Signer не має операційного власника.
Решта архітектури випливає з цього правила. Визначте функції Co-Signer, призначте відповідального за кожен обов'язок, оберіть модель контролю та перевірте сценарій збою до того, як клієнт залежатиме від процесу виведення.
Що насправді робить Co-Signer у MPC
Корисною відправною точкою є MPC-схема 2-з-3. Три сторони мають окремі частки ключа. Повний приватний ключ ніколи не існує на одному пристрої. Дійсний підпис транзакції потребує співпраці двох дозволених сторін, тому одна недоступна або скомпрометована сторона не може підписати самостійно.
Co-Signer — одна із цих порогових сторін. Це може бути сервіс у середовищі клієнта, процес із підтримкою HSM або вузол постачальника. Він не є самим гаманцем і не зберігає кошти клієнтів як традиційний кастодіан. Він має частку ключа та виконує визначені протокольні й політичні функції.
Протокольні обов'язки Co-Signer
Під час розподіленої генерації ключа Co-Signer створює або отримує свою частку в межах церемонії та зберігає її в захищеному середовищі. Під час підписання він перевіряє сесію, виконує свою частину криптографічного протоколу й повертає частковий результат лише тоді, коли запит відповідає призначеним правилам.
Обов'язки найпростіше побачити як послідовність:
- Участь у генерації ключа: Co-Signer долучається до DKG без розкриття повного приватного ключа.
- Захист частки: зберігає її в HSM або захищеному середовищі з обмеженим доступом операторів.
- Перевірка запиту: перевіряє автентифікацію, версію політики, мережу, актив, отримувача, суму та контекст сесії.
- Раунд підписання: виконує криптографічний внесок і відхиляє некоректні або неавторизовані сесії.
- Збереження доказів: фіксує запит, рішення, результат протоколу та потрібні ідентифікатори.
- Підтримка життєвого циклу: бере участь в оновленні, ротації, призупиненні частки та церемоніях відновлення.
Різниця між зберіганням частки та експлуатацією Co-Signer принципова. Частка, яка не перевіряє політику, є лише криптографічним компонентом. Робочий Co-Signer має бути також точкою застосування правил і сервісом, придатним до аудиту.
Ширше пояснення архітектури гаманця наведено в огляді MPC-гаманців. Воно допомагає розрізняти інтерфейси гаманця, сервіси політик, учасників підписання, відправлення в мережу та операційні журнали, які команди часто об'єднують словом «гаманець».
Co-Signer також потребує чітких меж. Він не повинен одноосібно змінювати правила транзакцій, обходити автентифікацію чи схвалювати запит лише тому, що інший сервіс називає його терміновим. Його повноваження походять із політики підписання та структури кворуму, а не з неформального доступу до консолі оператора.
Основні обов'язки кожного Co-Signer
Робочий Co-Signer має шість окремих напрямів відповідальності. Кожен має власний сценарій збою, вимоги до доказів та операційного власника. Якщо вважати роль одним параметром конфігурації, прогалини проявляться під час інциденту, аудиту або відновлення.
Зберігання частки ключа
Co-Signer відповідає за безпечний життєвий цикл частки ключа: від генерації та захищеного зберігання до контролю доступу, резервних церемоній, оновлення, ротації та виведення з використання. HSM або захищене середовище може захистити матеріал частки, але команда все одно має визначити, хто ініціює підписання, які засоби контролю діють і як схвалюється кожна подія життєвого циклу.
Витік часто починається поза сервісом підписання. Частка в артефакті збірки, журналі налагодження, ноутбуці розробника або некерованій резервній копії послаблює порогову модель. Тому зберігання охоплює межі сховища, дозволи операторів і докази того, що старий або замінений матеріал більше не придатний до використання.
Політика підписання
До створення часткового підпису Co-Signer оцінює контекст транзакції: блокчейн, актив, адресу, контракт, суму, частоту, статус схвалення, аварійну зупинку та результат перевірок відповідності.
Самої синтаксичної перевірки недостатньо для дотримання бізнес-наміру. Рівень політик має визначити, чи дозволена транзакція, і зберегти точну версію правил, використану для рішення. Так слідчий може пов'язати схвалення з набором правил, активним у момент підписання.
Доступність
Недоступний Co-Signer може зупинити кворум. Власник керує доступністю, перевірками стану, потужністю, затримкою, вікнами обслуговування та керованим погіршенням. Резервні вузли й перевірене перемикання надійніші за декларацію доступності: дозволене виведення має завершитися навіть у разі інфраструктурного збою.
Сюди належить і поведінка залежностей. Здоровий вузол може заблокувати підписання, якщо нескінченно очікує сервіс політик, провайдера автентифікації чи мережевий маршрут. Обмеження часу, явні стани помилки й визначені власники не дають цим залежностям стати непомітними блокерами.
Безпека
Межа безпеки охоплює хост, середовище виконання, залежності, облікові записи операторів, конвеєр розгортання та моніторинг. Засоби контролю мають включати ідентичність робочого навантаження, сильну автентифікацію операторів, найменші привілеї, оновлення, контроль втручання, перевірку ланцюга постачання й запобігання витоку часток.
Моніторинг має охоплювати не лише успішні підписи. Незвичні запити політик, повторні відхилення, неочікувані зміни розгортання і спроби доступу до захищеного сховища можуть виявити зловживання до серйознішого інциденту.
Аудит
Co-Signer має створювати докази, що пояснюють рішення. Журнали повинні пов'язувати намір підписання з результатом автентифікації, рішенням і версією політики, подією часткового підпису, результатом кворуму та відправленням у мережу.
Записи мають додаватися послідовно або бути інакше захищеними від змін. Самого хешу фінальної транзакції недостатньо, щоб показати, чому запит схвалили, хто його ініціював та яка політика діяла.
Відновлення
Відновлення повертає порогову систему до роботи без реконструкції приватного ключа. Регламент має охоплювати оновлення частки, заміну несправного хоста, резервні соціальні або інституційні церемонії, зміну кворуму, аварійну зупинку та контрольовану реєстрацію нового Co-Signer.
Навчання з відновлення мають моделювати і втрату хоста, і підозру на компрометацію. Неперевірена резервна копія залишається припущенням, а не дієвим контролем.
| Обов'язок | За що відповідає Co-Signer | Основний сценарій збою |
|---|---|---|
| Зберігання | Генерація, захищене зберігання, життєвий цикл і ротація частки | Витік або неконтрольоване повторне використання |
| Політика підписання | Перевірки транзакцій і застосування версії політики | Неавторизоване підписання або порушення вимог |
| Доступність | Стан вузла, участь у кворумі та перемикання | Зупинка виведень |
| Безпека | Контроль хоста, ідентичностей, конвеєра та моніторингу | Витік або компрометація оператора |
| Аудит | Незмінні докази підписання та політики | Неможливість довести рішення |
| Відновлення | Оновлення частки, заміна та аварійні процедури | Тривалий простій або небезпечна реконструкція |
Co-Signer під контролем клієнта або постачальника
Модель розгортання визначає, хто несе операційне навантаження. У моделі під контролем клієнта клієнт запускає Co-Signer у власному VPC або середовищі з HSM і безпосередньо контролює частку, застосування політик, конвеєр розгортання, журнали й процедури відновлення.
У моделі під контролем постачальника провайдер розміщує Co-Signer як керований сервіс. Клієнт зменшує обсяг інфраструктурної роботи, але має вимагати доказів експлуатації вузла, ключових церемоній, виконання політик, реагування на інциденти й відновлення. Керування постачальником не обов'язково означає наявність повного ключа чи одноосібного права підпису, але постачальник відповідає за недоступність вузла або компрометацію середовища частки.
| Сфера відповідальності | Co-Signer клієнта | Co-Signer постачальника |
|---|---|---|
| Зберігання частки | Захищене середовище клієнта | Захищене середовище постачальника за договором |
| Застосування політик | Клієнт розгортає та керує правилами | Постачальник виконує, клієнт визначає або схвалює межі |
| Оновлення ключа | Клієнт планує і проводить церемонію | Постачальник проводить або координує церемонію |
| Звітність SOC 2 | Клієнт надає власні докази контролю | Постачальник надає відповідні звіти та зіставлення |
| Аварійне відновлення | Клієнт відповідає за топологію і тест | Постачальник відновлює сервіс, клієнт перевіряє зобов'язання |
| Відповідальність за інцидент | Клієнт веде технічне реагування | Постачальник реагує на рівні платформи, клієнт — на вплив на продукт |
Запитання про контроль корисніше за етикетку моделі зберігання. З'ясуйте, хто може схвалити нову адресу, призупинити підписання, змінити пакет політик, ротувати частку, читати журнали й оголосити інцидент. Рекомендації Sokko щодо гранулярності допомагають спроєктувати дозволи так, щоб ці повноваження не злилися в одну адміністративну роль.
Для самостійного DeFi-продукту часто підходить Co-Signer під контролем клієнта, якщо команда може експлуатувати захищену інфраструктуру й потребує прямої влади над політиками. Регульований продукт зі зберігання активів може обрати керований сервіс, але лише з чіткими доказами, договірною відповідальністю, доступом до аудиту та SLA для інцидентів. Матеріал про значення некастодіальної моделі корисний тут, бо некастодіальна архітектура не усуває операційної відповідальності — вона її перерозподіляє.
Обов'язки Co-Signer у некастодіальному процесі
Розгляньмо виведення USDC із некастодіального MPC-гаманця. Користувач контролює відносини з гаманцем, але продукту все одно потрібен безпечний шлях підписання. У Co-Signer поєднуються автентифікація, політика транзакції, порогова участь і докази.
Шлях виведення коштів
- Користувач ініціює виведення. Застосунок створює намір підписання з мережею, активом, адресою, сумою, контекстом nonce та автентифікованою ідентичністю користувача або агента. Co-Signer отримує ідентифікатор запиту, а не неформальну вказівку.
- Co-Signer автентифікує запит. Перевіряє потрібний чинник або довірену ідентичність сервісу. Запит із недозволеної сесії, застарілими даними чи невідомим навантаженням зупиняється до криптографічної участі.
- Рушій політик оцінює транзакцію. Перевіряє список адрес, контракт, поріг суми, частоту, ID блокчейну, актив, схвалення й результати перевірок відповідності. Запит можна схвалити, відхилити або передати на ручний розгляд.
- Виконується протокол підписання. Інша MPC-сторона та Co-Signer обмінюються повідомленнями; кожна виконує лише обчислення зі своєю часткою. Повний ключ не складається ніде.
- Транзакція агрегується та відправляється. Повністю підписані дані надсилаються в мережу. Події WebSocket повідомляють результати політик, прогрес підписання, статус відправлення та підтвердження.
- Co-Signer зберігає докази. Аудиторський запис пов'язує запит, ідентичність, версію політики, рішення, сесію протоколу, хеш транзакції та результат відправлення. Фінансова команда звіряє результат з операційним журналом, а не з екраном гаманця.
Депозит проходить іншим шляхом. Co-Signer може брати участь у виведенні адрес і веденні стану кворуму, але не підписує вхідний переказ. Система все одно має створити події спостереження й підтвердження депозиту, записати рух в операційному журналі та звірити очікувану адресу з рахунком або користувачем.
Автономне підписання потребує суворіших меж
У виплаті AI-агента людську MFA замінює дозволена ідентичність навантаження та визначений політиками контур. Co-Signer перевіряє сферу агента, набір адрес, ліміти й контекст дії. Агент може запитати платіж, але не має розширювати власні дозволи чи змінювати політику оцінювання.
Ідемпотентність також належить до обов'язків Co-Signer. Повторна спроба має зберегти початковий намір або повернути чіткий результат про дублікат, а не створити другу виплату. Прив'яжіть запит до унікального ID, nonce, блокчейну й версії політики, а кожну зміну стану зробіть видимою через події та записи журналу.
Ризики, контроль і поширені сценарії збою
Уявлення про пасивну частку ключа не працює в робочому середовищі. Co-Signer може бути криптографічно нездатним підписати, операційно готовим підписати неправильну транзакцію або технічно здоровим, коли його докази й стан політик непридатні.
Надійність і кворум
Відмова вузла може зупинити виведення, навіть якщо застосунок, інтерфейс гаманця й блокчейн працюють. Використовуйте географічно рознесені резервні вузли, моніторинг, обмежені повторні спроби й явний режим погіршення. Оператори мають знати, чи система відхиляє нові запити, ставить їх у чергу або призупиняє все підписання без кворуму.
Мережева затримка створює суміжний збій. Сесіям потрібні обмеження часу, кореляційні ID та безпечні повторні спроби. Завершення часу очікування не повинно залишати команду без відповіді: транзакцію відхилено, частково підписано, відправлено чи просто втрачено подію.
Компрометація частки та політики
Скомпрометований конвеєр CI/CD може розкрити частку або розгорнути код, що змінює поведінку підписання. Захищайте частки апаратним шифруванням, обмежуйте право розгортання, скануйте артефакти й журнали на чутливі дані та відстежуйте незвичний доступ.
Дрейф політик тихіший і часто небезпечніший. Використовуйте підписані пакети, фіксацію версій, процеси схвалення та запис точного пакета, який оцінювався. Прив'язуйте дані підписання до потрібного chain ID, nonce, активу й контракту, щоб дійсний підпис не можна було повторно використати в іншому контексті.
Практики процесу кредиторської заборгованості Loopfour дають корисне порівняння для розподілу схвалень, доказів, винятків і звірки. Ці засоби контролю застосовні до криптовалютних виплат, навіть якщо фінальне схвалення є пороговим підписом.
Команди вже стикалися з простоями порогових гаманців і витоками часток, що вимагали аварійного оновлення ключів. Висновок не в тому, що MPC усуває ризик. Воно обмежує одноосібні повноваження лише тоді, коли оператори захищають кожну частку, виконують правила кворуму та підтримують відновлення.
Використовуйте процес аудиторської перевірки, що пов'язує технічні події з бізнес-рішеннями. Недбалість Co-Signer має виявлятися в записах, а не списуватися на абстрактний криптографічний збій.
Операційний список перевірки та запитання покупця
До вибору або розгортання Co-Signer внесіть до регламенту й анкети постачальника:
- Назвіть власника: призначте відповідальних за доступність, політики, безпеку, аудит і відновлення.
- Перевірте SLA: визначте поведінку кворуму, доставку подій, обслуговування й ескалацію інцидентів.
- Перевірте життєвий цикл ключа: задокументуйте DKG, оновлення частки, ротацію, відкликання й заміну хоста.
- Фіксуйте версії політик: вимагайте схвалення, підписані пакети й докази кожного рішення.
- Пов'яжіть записи: звіряйте події WebSocket, сесії підписання, хеші транзакцій та записи журналу.
- Перевірте збої: змоделюйте втрату вузла, відхилення політикою, дублікати й підозру на компрометацію частки.
Запитання покупця
Хто відповідає за доступність Co-Signer? Сторона, названа у SLA та регламенті. Відповідь «платформа» недостатня: потрібні команда, маршрут ескалації та поведінка кворуму.
Що доводить участь Co-Signer у підписанні? Вимагайте пов'язані докази рішення політики, сесії протоколу, часткового підпису, фінального хешу й результату відправлення.
Що станеться після втрати хоста? Перевірена процедура відновлення або оновлення частки має замінити хост без реконструкції повного ключа.
Хто відповідає за політики, пов'язані з KYC? Договір має визначати, чи клієнт формує та схвалює правила, постачальник їх виконує, або відповідальність спільна.
Як порівнювати MPC-провайдерів? Порівнюйте межі контролю, докази політик, тести відновлення, семантику подій, звірку операційного журналу та зобов'язання під час інцидентів. Протокольна термінологія йде після цих операційних відповідей.
BroLabel надає вбудовані MPC-гаманці, контрольований клієнтом Co-Signer у BroSettlement, підписання з урахуванням політик, події WebSocket, операційний журнал із послідовним додаванням, підтримку звірки та гаманці AI-агентів із рольовим контролем. Якщо ваша команда перетворює обов'язки Co-Signer на робочий регламент, відвідайте BroLabel, щоб оцінити інфраструктуру й перейти від проєктування у пісочниці до контрольованого запуску.
