Командам, які порівнюють інфраструктуру MPC-гаманців, потрібно знати, хто може схвалити транзакцію, де працює кожна частка ключа, як відновити доступ у разі збою учасника підписання та які операційні записи отримає застосунок. Позначка в таблиці не відповідає на ці питання. Цей посібник порівнює задокументовані моделі контролю й допомагає перевірити їх на реальному платіжному процесі.
Ширший огляд провайдерів є у порівнянні інституційних рішень для зберігання криптоактивів.
Що змінює MPC у роботі з гаманцями
Багатосторонні обчислення (MPC) дають змогу створити дійсний підпис для блокчейну без відновлення повного приватного ключа в одному місці. Поріг підписання, власники часток, порядок схвалення та відновлення залежать від продукту й конфігурації. Один провайдер може пропонувати кілька моделей гаманців, тому запитуйте про конкретну модель у запропонованому договорі.
MPC — лише частина операційної системи. Продуктовій команді також потрібні створення гаманців, правила транзакцій, підтримка мереж, події життєвого циклу й операційний журнал для звірки. Якщо головна вимога — юридично визначене зберігання активів клієнтів, регульований зберігач може відповідати їй краще за інфраструктуру вбудованих гаманців.
Що перевірити перед вибором провайдера
- Контроль підписання: визначте власника кожної частки та кворум для звичайних транзакцій.
- Застосування правил: перевірте, хто може відхилити виплату і чи самого доступу до API достатньо для підписання.
- Відновлення: з'ясуйте, що станеться, якщо провайдер, Co-Signer клієнта або мережа недоступні.
- Операції з гаманцями: випробуйте потрібні активи, мережі, отримання депозиту та відправлення коштів.
- Записи й події: звірте депозит, невдале відправлення та повторну спробу з журналом і потоком подій.
- Комерційні умови: письмово зіставте ліміти тарифу, оплату понад ліміт, підтримку й обсяг інтеграційної роботи.
Варіанти інфраструктури MPC-гаманців
BroSettlement
BroSettlement надає вбудовані гаманці, MPC-підписання 2-з-3 із генерацією ключа через DKG, розгорнутий у клієнта Co-Signer, операційний журнал із послідовним додаванням записів і WebSocket-події життєвого циклу. У звичайному підписанні беруть участь частка платформи й частка Co-Signer клієнта. Окрема клієнтська частка утворює другий кворум для відновлення; доступну процедуру й підтримку активу потрібно перевіряти для обраної мережі.
Безкоштовний тариф працює лише в тестових мережах. Тариф Agent для основних мереж зазначений як $30 на місяць із визначеними лімітами гаманців та обсягу. Перед комерційною пропозицією перевірте чинну сторінку тарифів.
Fireblocks
Fireblocks пропонує кілька продуктів із різними моделями ключів і гаманців, зокрема Direct Custody та Embedded Wallets. Документація описує API Co-Signer під керуванням клієнта для відповідних конфігурацій. Порівнюйте запропонований продукт і розподіл часток, а не приписуйте всій платформі одну модель зберігання активів.
Dfns і Utila
Dfns документує API гаманців і механізм правил, який контролює підписання. Utila документує API гаманців, вебхуки й автоматизований Co-Signer. Це різні продукти: окремо перевіряйте виконання правил, контроль ключів, охоплення подій і комерційні умови.
Blockdaemon Institutional Vault
Blockdaemon документує Institutional Vault, який можна розгорнути у власній інфраструктурі, з MPC-вузлами правил, схваленнями, API транзакцій і відправленням у мережу. Зіставте відповідальність за розгортання та експлуатацію з можливостями власної команди безпеки й інфраструктури.
Порівнюйте моделі контролю, а не назви функцій
| Платформа | Задокументована модель | Питання для перевірки |
|---|---|---|
| BroSettlement | DKG/MPC 2-з-3, Co-Signer клієнта, окрема частка відновлення, журнал і WebSocket-події | Які активи та процедури відновлення доступні для цього розгортання? |
| Fireblocks | Кілька продуктів гаманців; API Co-Signer під керуванням клієнта задокументований для відповідних конфігурацій | Які продукт, розподіл часток, правила та сервіс подій входять до пропозиції? |
| Dfns | API гаманців; підписання контролює механізм правил | Де застосовуються правила схвалення і як експортуються рішення? |
| Utila | API гаманців, вебхуки й автоматизований Co-Signer | Хто запускає Co-Signer і що його правила можуть відхилити до підписання? |
| Blockdaemon Institutional Vault | MPC-гаманці та вузли правил із можливістю розгортання й доступом через API | Хто експлуатує вузли, резервні копії, схвалення та процедуру відновлення? |
Джерела: довідка BroSettlement API, Fireblocks API Co-Signer, механізм правил Dfns, огляд API Utila та посібник із розгортання Blockdaemon. Доступність функцій і договірні умови можуть змінюватися; перевіряйте конфігурацію, яку пропонують вашій організації.
Межі підписання й відновлення в BroSettlement
Три частки й два різні процеси
| Частка | Власник | Роль в операціях |
|---|---|---|
| A | Платформа BroSettlement | Бере участь у звичайному підписанні A+B |
| B | Co-Signer, розгорнутий у клієнта | Зберігає клієнтську частку й перевіряє правила підписання |
| C | Клієнт, окремо від активного Co-Signer | Утворює кворум відновлення B+C за підтримуваною процедурою |
Однієї частки недостатньо для підписання. Звичайний процес A+B і відновлення B+C мають різні передумови й відповідальних сторін. Публічні інструменти незалежного відновлення зараз охоплюють перекази нативного TRX і стандартних TRC-20 токенів в основній мережі TRON або Nile; вони не відновлюють API BroSettlement, операційний журнал чи сервіс подій. Ознайомтеся з посібником із відновлення, перш ніж покладатися на цей механізм в операційній моделі.
Перевірте одну транзакцію від початку до кінця
Почніть із гаманця в тестовій мережі та API-доступу з обмеженими правами. Запустіть Co-Signer клієнта, підтвердьте готовність MPC, створіть один рахунок в операційному журналі й один гаманець. Поповніть гаманець, перевірте подію депозиту та звірте запис у журналі. Далі випробуйте невелике дозволене відправлення й відхилення правилами. Переконайтеся, що повторний запит з тим самим ключем ідемпотентності не створює другу логічну транзакцію.
API автентифікує запит, але автентифікація не є схваленням витрат. Co-Signer і його правила залишаються частиною процесу підписання. Після підписання перевірте відправлення в мережу, підтвердження, обробку помилок і кінцевий стан журналу. Довідка API описує поточні команди; підтримку мережі й активу звіряйте з чинним контрактом.
Який варіант підходить?
Обирайте провайдера, чиї задокументовані межі контролю відповідають обов'язкам бізнесу й можливостям інтеграції. BroSettlement варто розглянути, коли застосунку потрібні вбудовані гаманці, участь клієнта в підписанні, звірка журналу й події транзакцій в одному інфраструктурному шарі. Fireblocks, Dfns, Utila і Blockdaemon по-різному поєднують контроль гаманців, правила, зберігання активів і розгортання. Демонстрація конкретного продукту та письмові комерційні умови корисніші за універсальний рейтинг без доказів.
