Порівняння рішень для управління активами Web3: мультипідпис, MPC та CRVA

Автор: Shew, Сяньранг

У світі Web3 управління приватними ключами є питанням життя і смерті. Якщо приватний ключ гаманця буде вкрадено або втрачено, мільйони доларів активів можуть зникнути в одну мить. Проте більшість людей звикли використовувати однопунктове управління приватними ключами, що є таким же ризикованим, як покласти всі яйця в один кошик, адже можна в будь-який момент натрапити на рибальське посилання і віддати всі активи хакерам.

Щоб впоратися з цією проблемою, у сфері блокчейну з'являлися різноманітні рішення. Від мультипідписних гаманців до MPC, а також до CRVA, запропонованого проектом DeepSafe, кожен технологічний прогрес відкриває нові шляхи для управління активами. У цій статті буде розглянуто принципи, особливості та сфери застосування цих трьох рішень для управління активами, щоб допомогти читачеві вибрати найбільш підходящий для себе шлях.

Мультипідписний гаманець: задовільно, але не відмінно

Ідея мультипідписного гаманця походить від простої мудрості: не концентруйте всі повноваження в одному місці. Ця ідея давно знайшла широке застосування в реальності, наприклад, у розподілі влади та голосуванні ради директорів.

Аналогічно, в Web3 мультипідписні гаманці створюють кілька незалежних ключів для розподілу ризиків. Найпоширенішим є режим “M-of-N”, наприклад, у налаштуванні “2-of-3” система генерує три приватні ключі, але лише за умови, що будь-які два з них підписують, можна дозволити зазначеному рахунку виконати транзакцію.

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

Загалом, мультипідписні гаманці технічно діляться на два типи: один — це звичайний мультипідпис, який зазвичай реалізується за допомогою смарт-контрактів на ланцюгу або супутніх компонентів базового рівня публічного ланцюга, часто не покладаючись на конкретні криптографічні інструменти. Інший тип — це мультипідписний гаманець, який залежить від спеціальних криптографічних алгоритмів, безпека якого залежить від конкретного алгоритму, іноді можна зовсім не залучати участь смарт-контрактів на ланцюгу. Нижче ми по черзі обговоримо обидва рішення.

Звичайне мультипідписне рішення представляє: гаманець Safe та Taproot Bitcoin

Гаманець Safe, як один з найпопулярніших варіантів мультипідпису, використовує звичайний смарт-контракт Solidity для реалізації мультипідпису. У структурі гаманця Safe кожен учасник мультипідпису контролює окремий ключ, а смарт-контракт на ланцюгу виконує роль “арбітра”, і лише при зборі достатньої кількості дійсних підписів контракт дозволяє пов'язаним з мультипідписом рахункам виконувати транзакції.

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

Окрім відомої мультипідписної схеми Safe Wallet в екосистемі Ethereum, у мережі Bitcoin також існують мультипідписні гаманці, створені на основі BTC-скриптів, наприклад, схеми, основані на операції OP_CHECKMULTISIG. Ця операція може перевірити, чи задовольняє кількість підписів, що містяться у скрипті розблокування UTXO, вимогам.

Варто зазначити, що вищезгадані звичайні алгоритми мультипідпису підтримують “M-of-N”, але в подальшому обговоренні мультипідпису на основі певних криптографічних алгоритмів деякі з них підтримують лише режим “M-of-M”, тобто користувач повинен надати всі ключі, щоб здійснити транзакцію.

Реалізація багатопідпису на рівні криптографії

На криптографічному рівні можна реалізувати ефект багатопідпису за допомогою специфічних криптографічних алгоритмів, і цей варіант іноді може обійти участь смарт-контрактів на ланцюзі. Ми зазвичай проводимо таку класифікацію:

1. Мультипідписи (. Цей алгоритм підпису підтримує лише режим “M-of-M”, користувач повинен одночасно подати підписи для всіх ключів.

2. Порогові сигнальні алгоритми ) Threshold Signatures (. Цей алгоритм підтримує режим “M-of-N”, але взагалі кажучи, його конструкція є складнішою порівняно з вищезгаданими алгоритмами багатопідпису.

3. Алгоритм розподілу ключів ) Secret sharing (. У дизайні цього алгоритму користувач може розділити один приватний ключ на кілька частин, і коли користувач збереться достатню кількість фрагментів приватного ключа, він зможе відновити оригінальний приватний ключ і створити підпис.

Біткойн після оновлення SegWit ), що включає ізольоване свідчення (, впровадив алгоритм Шнорра, що дозволяє природно реалізувати мультипідписні перевірки. У консенсусному шарі ефірі використовується алгоритм BLS порогового підпису для реалізації найосновнішої функції голосування в системі PoS.

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

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

Реальні виклики технології багатопідпису

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

Ще більш серйозною проблемою є те, що багатопідписні гаманці часто переносять ризик з управління приватними ключами на етапи координації та перевірки підписів. Як показує нещодавній випадок крадіжки на Bybit, зловмисники успішно обманули багатопідписних керівників Bybit, вставивши фішинговий код інтерфейсу Safe на об'єктах AWS, від яких залежав Safe, і змусили їх підписати фішингові транзакції. Це свідчить про те, що навіть із застосуванням більш сучасних технологій багатопідпису, безпека інтерфейсу та етапів перевірки та координації підписів залишається вкрай вразливою.

Крім того, не всі алгоритми підпису, що використовуються в блокчейні, нативно підтримують мультипідпис. Наприклад, на кривій secp 256 k 1, що використовується у виконавчому шарі Ethereum, мультипідписних алгоритмів існує дуже мало, що обмежує використання мультипідписних гаманців в різних екосистемах. Для мереж, які потребують реалізації мультипідпису через смарт-контракти, також існують додаткові ризики, такі як вразливості контрактів та ризики оновлення.

MPC: Революційний прорив

Якщо багаторазовий гаманець підвищує безпеку шляхом розподілу приватних ключів, то технологія MPC (мультипартійні обчислення безпеки) йде ще далі, оскільки вона принципово усуває наявність повного приватного ключа. У світі MPC повний приватний ключ ніколи не з'являється в жодному окремому місці, навіть під час процесу генерації ключів. Крім того, MPC часто підтримує більш розширені функції, такі як оновлення приватного ключа або налаштування прав.

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

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

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

Суттєва різниця між MPC та мультипідписом

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

Ця різниця також проявляється у сумісності. Мультипідписні гаманці потребують рідної підтримки блокчейн-мережі або покладаються на смарт-контракти, що обмежує їх використання в деяких місцях. У той же час, підписи, згенеровані MPC, використовують стандартний формат ECDSA, який можна використовувати в будь-якому місці, що підтримує цей алгоритм підпису, включаючи біткойн, ефір та різні платформи DeFi.

Технологія MPC також забезпечує більшу гнучкість для налаштування параметрів безпеки. У традиційних мультипідписних гаманцях зміна порогу підпису або кількості учасників зазвичай вимагає створення нової адреси гаманця, що створює ризики. ) Звичайно, мультипідписний гаманець на основі смарт-контрактів може зручно змінювати учасників та їхні права (, тоді як у системі MPC ці параметри можна налаштувати більш гнучко та просто, не змінюючи облікові записи в ланцюгу та код контрактів, що забезпечує більшу зручність для управління активами.

Виклики, з якими стикається MPC

Проте, хоча MPC є більш досконалим, ніж звичайні мультипідписи, все ж існують відповідні виклики. По-перше, це складність реалізації. Протокол MPC передбачає складні криптографічні обчислення та багатосторонню комунікацію, що ускладнює реалізацію та обслуговування системи. Будь-яка помилка може призвести до серйозних вразливостей безпеки. У лютому 2025 року Ніколаос Макріяніс та інші виявили спосіб викрадення своїх ключів у гаманці MPC.

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

Крім того, MPC все ще не може забезпечити децентралізацію. У справі Multichain 2023 року 21 вузол, який брав участь у розрахунках MPC, контролювався однією особою, що є типовою атакою відьмака. Цей випадок достатньо доводить, що лише кілька десятків вузлів на поверхні не можуть забезпечити високий рівень децентралізованості.

DeepSafe: побудова мережі безпечної верифікації наступного покоління

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

Багатофакторна аутентифікація CRVA

Основна ідея DeepSafe полягає в “подвійній страховці”: користувачі можуть продовжувати використовувати свої звичні гаманцеві рішення, такі як гаманець Safe, коли транзакція з багатостороннім підписом подається в мережу, вона автоматично надсилається в мережу CRVA для додаткової перевірки, подібно до 2FA багатоетапної перевірки Alipay.

У цій архітектурі CRVA виконує роль воротаря, перевіряючи кожну транзакцію відповідно до правил, встановлених користувачем заздалегідь. Наприклад, обмеження на одну транзакцію, білий список адрес одержувачів, частота транзакцій тощо, у разі виникнення аномальних ситуацій транзакцію можна в будь-який момент перервати.

Перевага цього 2FA багатофакторного підтвердження полягає в тому, що навіть якщо процес мультипідпису буде скомпрометований (як у випадку з атакою фішингу на фронтенді Bybit), страховий CRVA все ще може відмовити у ризиковій угоді відповідно до заздалегідь визначених правил, захищаючи активи користувача.

Технологічне вдосконалення на основі традиційних рішень MPC

У відповідь на недоліки традиційних рішень з управління активами на основі MPC, рішення CRVA від DeepSafe здійснило значні вдосконалення. По-перше, вузли мережі CRVA використовують форму доступу на основі застави активів, і основна мережа буде офіційно запущена лише після досягнення приблизно 500 вузлів. За оцінками, активи, заставлені цими вузлами, надалі залишаться на рівні десятків мільйонів доларів або навіть вище.

По-друге, для підвищення ефективності обчислень MPC/TSS CRVA буде випадковим чином обирати вузли за допомогою алгоритму жеребкування, наприклад, кожні півгодини обираючи 10 вузлів, які будуть виступати в ролі валідаторів, перевіряючи, чи слід затверджувати запити користувачів, а потім генеруючи відповідні підписи для їхнього проходження. Щоб запобігти внутрішнім змовам або зовнішнім хакерським атакам, алгоритм жеребкування CRVA використовує оригінальний кільцевий VRF у поєднанні з ZK, щоб приховати особу обраного, що унеможливлює зовнішнє спостереження за обраними.

Звичайно, просто досягти цього рівня недостатньо. Хоча зовнішній світ не знає, хто був обраний, але на даний момент обраний знає про це, тому все ще існує шлях для змови. Щоб ще більше виключити змову, всі вузли CRVA повинні запускати основний код в середовищі апаратного забезпечення TEE, що еквівалентно виконанню основної роботи в чорному ящику. Таким чином, ніхто не може знати, чи був він обраний, якщо тільки він не зможе зламати апаратне забезпечення TEE, звичайно, згідно з поточними технологічними умовами, це вкрай важко зробити.

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

1. Усі вузли перед входом до мережі CRVA повинні спочатку закласти активи в ланцюзі, залишивши публічний ключ як реєстраційну інформацію. Цей публічний ключ також відомий як «постійний публічний ключ».

2. Кожну годину мережа CRVA випадковим чином обирає кілька вузлів. Але перед цим усі кандидати повинні локально згенерувати одноразовий «тимчасовий публічний ключ», одночасно створюючи ZKP, щоб довести, що «тимчасовий публічний ключ» пов'язаний з «постійним публічним ключем», зафіксованим в ланцюгу; іншими словами, кожен повинен за допомогою ZK довести свою присутність у списку кандидатів, але не розкривати, хто саме він.

3. “Тимчасовий відкритий ключ” має значення в захисті приватності. Якщо провести жеребкування безпосередньо з набору “Постійних відкритих ключів”, під час публікації результатів всі одразу дізнаються, хто був обраний. Якщо ж всі розкриють лише одноразовий “Тимчасовий відкритий ключ”, а потім виберуть кілька осіб з набору “Тимчасових відкритих ключів”, ви зможете дізнатися лише про свою перемогу, але не будете знати, кому відповідає інший виграшний тимчасовий відкритий ключ.

4. Щоб далі запобігти витоку ідентичності, CRVA планує зробити так, щоб ви навіть не знали, що таке ваш «тимчасовий публічний ключ». Процес генерації тимчасового публічного ключа відбувається в середовищі TEE вузла, і ви, запустивши TEE, не зможете побачити, що відбувається всередині.

5. Потім у TEE тимчасовий відкритий ключ шифрується в «незрозумілий текст» і надсилається зовнішньому світу, тільки певні Relayer вузли можуть його відновити. Звичайно, процес відновлення також виконується в TEE середовищі Relayer, і Relayer не знає, до яких кандидатів відповідають ці тимчасові відкриті ключі.

6. Релейер відновлює всі «тимчасові відкриті ключі», після чого об'єднує їх і подає до VRF-функції на ланцюгу, звідки обираються переможці. Ці особи перевіряють запити на транзакції, надіслані з фронтенду користувача, а потім на основі результатів перевірки генерують підпис за пороговим значенням, і, зрештою, знову подають його на ланцюг. (Слід зазначити, що тут Релейер також приховує свою особистість і періодично обирається.)

Можливо, хтось запитає, якщо кожен вузол не знає, чи був він вибраний, то як же продовжувати роботу? Насправді, як згадувалося раніше, кожен генерує «тимчасовий публічний ключ» у локальному середовищі TEE, після того як результати жеребкування оголошуються, ми просто транслюємо список, і кожен може ввести список у TEE, щоб перевірити, чи був він вибраний.

Ядром рішення DeepSafe є те, що майже всі важливі дії відбуваються всередині апаратного забезпечення TEE, ззовні TEE неможливо спостерігати, що відбувається. Кожен вузол не знає, хто є обраним валідатором, що запобігає змові та значно підвищує вартість зовнішніх атак. Щоб атакувати комітет CRVA, заснований на DeepSafe, в теорії потрібно атакувати всю мережу CRVA, оскільки кожен вузол має захист TEE, складність атаки значно зростає.

Щодо ситуації з CRVA, оскільки CRVA є автоматизованою мережею вузлів, якщо код, що використовується під час первинного запуску, не містить шкідливих логік, то ситуація, коли CRVA активно відмовляється співпрацювати з користувачем, не виникне, тому її в основному можна ігнорувати.

Якщо CRVA через вимушені обставини, такі як відключення електроенергії або повінь, призведе до масового простою вузлів, відповідно до процесу, згаданого в наведеному вище плані, користувачі все ще матимуть можливість безпечно вивести свої активи. При цьому ми довіряємо CRVA настільки, що вона достатньо децентралізована і не буде навмисно завдавати шкоди (причини вже були достатньо пояснені раніше).

підсумок

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

Проте, прогрес у технологіях не означає усунення ризиків. Кожна нова технологія, вирішуючи наявні проблеми, може також вводити нову складність і ризики. З події на Bybit ми бачимо, що навіть використовуючи сучасні технології багатопідпису, зловмисники все ще можуть обійти технічний захист через соціальну інженерію та атаки на постачальників. Це нагадує нам, що технологічні рішення повинні поєднуватися з належними операційними практиками та усвідомленням безпеки.

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