23 квітня 2025 року, користувач на ім'я Brain попросив допомоги в Twitter через свого друга, заявивши, що під час арбітражних операцій на одному з Bitcoin Layer2 ланцюгів активи unibtc на суму понад 100 тисяч доларів були заблоковані офіційним Bedrock і не можуть бути виведені.
Згідно з розкриттям сторони W, 17 квітня він виявив аномалію цін на unibtc, випущений Bedrock, на певній L2-ланці біткоїна, де він відв'язався від BTC. W вважає, що відв'язка є тимчасовою і незабаром повернеться до прив'язки, тому тут є хороша можливість для арбітражу, і він частину BTC перевів на цю L2-ланку біткоїна, обмінявши їх на unibtc, і чекає, поки вони повернуться до прив'язки, щоб продати.
Лише через 24 години після відв'язання unibtc вже повернувся до якоря, але коли W спробував продати свій unibtc, він виявив, що ліквідний пул unibtc-BTC на цій ланцюзі був вилучений офіційно Bedrock, а ця токенна пара є єдиним виходом на вторинний ринок unibtc на цій ланцюзі. W не зміг продати свій unibtc, тому спробував перенести unibtc на інші ланцюги.
Коли він знайшов єдиний кросчейн-міст на цій ланцюзі, що підтримує unibtc (названий Free), він отримав повідомлення - "Транзакція потребує підпису авторизації від проекту". W звернувся до служби підтримки кросчейн-мосту Free, де йому пояснили: "Мультипідписний ключ для кросчейну unibtc управляється Bedrock, без їхнього дозволу користувач не може перевести unibtc на інші ланцюги."
Немає виходу, W може лише звернутися до відповідних осіб з Bedrock з цього питання, і первинна відповідь з їхнього боку була: "Ми можемо дозволити вам вивести основний капітал, але чи можна вивести прибуток від арбітражу, потрібно ще перевірити."
На цьому етапі W усвідомив, що шлях виходу unibtc на цьому ланцюзі повністю перекритий, а його unibtc вартістю близько 200 тисяч U "тимчасово заморожено" — він не може продати їх на цьому ланцюзі і не може перейти на інші ланцюги. У цей момент він відчував велику безпорадність, сподіваючись просто повернути свій капітал.
Однак ставлення осіб, що пов'язані з BedRock, стало неоднозначним - вони не уточнюють, коли W може повернути свій капітал, і не надають жодних письмових зобов'язань, затримуючи процес з причин "перевірки ризиків", "технічної перевірки" та інших.
Після деякого затримки BedRock стверджує, що відключення unibtc сталося через те, що на платформі LayerBank хтось масово позичив активи unibtc і здійснив маніпуляції на ринку, після чого люди з BedRock запропонували W "пред'явити претензії до LayerBank". А W, знайшовши LayerBank, довгий час не отримував відповіді.
В безвихідній ситуації W змушений був знайти друзів у Твіттері для допомоги, після більше ніж двох тижнів переговорів, він нарешті отримав позитивну відповідь від офіційних представників LayerBank і BedRock, успішно повернувши активи.
У遭遇 не є одиничним випадком. Згідно з відгуками інших учасників, минулого року BedRock також використовував подібні методи для блокування виходу користувачів з unibtc, що призвело до «суттєвого замороження» цих unibtc. Звичайно, ця стаття не має наміру спекулювати на причинах зазначених подій, а лише з технічної точки зору пояснити, як уникнути та запобігти подібним централізованим зловживанням.
По-перше, переглядаючи вищезгадані події, ми можемо побачити, що BedRock, будучи емітентом unibtc та початковим LP ліквідного пулу на вторинному ринку, природно має право на вихід з вторинного ринку unibtc. Якщо потрібно обмежити його повноваження, це більше потрібно робити через управління, а не технічні засоби;
Однак, згадане раніше про те, що Free мост між ланцюгами та BedRock змовлялися, щоб відмовити користувачам, виявляє очевидні технічні недоліки unibtc на етапах "випуску — одно-ланцюгового обігу — багато-ланцюгового обігу": Free міст між ланцюгами, будучи партнером BedRock, очевидно, є високо централізованим.
Справжній бездокументний міст має гарантувати, що офіційний міст не може перешкоджати виходу користувачів, тоді як у справі з замороженням unibtc, як BedRock, так і Free кросс-ланцюгові мости мають потужні централізовані повноваження і не забезпечують канали виходу, які б були стійкими до цензури.
Звісно, подібні випадки, як unibtc, не є рідкістю, і випадки, коли користувачам закривають шлях до виходу, часто трапляються на різних біржах, а для кросчейн мостів або інших типів проектів таких випадків також чимало. У червні 2022 року Harmony Horizon Bridge був змушений призупинити канали виведення 57 активів через хакерську атаку; хоча ця дія має "обґрунтовані причини", це все ж викликало у деяких людей відчуття тривоги.
У події StableMagnet 2021 року команда проекту через заздалегідь залишену уразливість програми вкрала 24 мільйони доларів. Врешті-решт, в Гонконзі та Великій Британії було залучено велику кількість сил поліції, і лише завдяки допомозі громади було повернуто 91% викрадених коштів. Різноманітні випадки чітко показують, що якщо платформа зберігання активів не може надати послуги без довіри, то в кінцевому підсумку це призведе до негативних наслідків.
Однак, Trustless не є чимось, що можна отримати просто так. Від платіжних каналів та DLC до BitVM і ZK Rollup люди намагалися реалізувати різні способи, хоча це може значною мірою забезпечити автономію користувачів і надати надійні виходи для виведення активів, проте за цим все ще стоять невідворотні недоліки.
Наприклад, платіжний канал потребує від сторін моніторингу потенційно злочинних дій контрагента, DLC покладається на оракули; в той час як BitVM має високі витрати і в практичній частині є інші припущення щодо довіри; для активації рятувальної капсули ZK Rollup потрібно пройти довгий період вікна, а також спочатку необхідно зупинити Rollup, що має величезну ціну.
З огляду на поточний стан реалізації основних технологічних рішень, не було представлено ідеального рішення для зберігання активів та виходу з них, ринок все ще потребує нововведень. У наступному тексті DeepSafe Research на прикладі офіційної програми зберігання активів DeepSafe пояснить рішення без довіри для перевірки повідомлень, яке поєднує TEE, ZK та MPC. Це рішення досягає балансу між такими показниками, як вартість, безпека та користувацький досвід, що може забезпечити надійні базові послуги для торгових платформ, кросчейн-мостів або будь-яких сценаріїв зберігання активів.
CRVA: мережа криптографічної випадкової верифікації
В даний час більшість найбільш широко використовуваних рішень для управління активами на ринку використовують мультипідпис або MPC/TSS для визначення того, чи є запит на передачу активів обґрунтованим, що має переваги простого впровадження, низької вартості та швидкої перевірки повідомлень, тоді як недоліки очевидні - вони недостатньо безпечні і, як правило, централізовані. У випадку Multichain 2023 року 21 вузол, який бере участь у обчисленнях MPC, контролюється однією людиною, що є типовою атакою Sybil. Цього достатньо, щоб довести, що одні лише кілька десятків вузлів на поверхні не можуть забезпечити високий рівень гарантії децентралізації.
Щодо недоліків традиційних рішень з управління активами MPC/TSS, рішення CRVA від DeepSafe внесло численні покращення. По-перше, мережеві вузли CRVA використовують модель допуску на основі застави активів, і основна мережа буде офіційно запущена лише після досягнення приблизно 500 вузлів; за оцінками, заставлені активи цих вузлів будуть протягом тривалого часу підтримуватися на рівні кількох десятків мільйонів доларів або вище;
По-друге, для підвищення ефективності розрахунків MPC/TSS, CRVA буде випадковим чином вибирати вузли за допомогою алгоритму вибору, наприклад, кожні півгодини вибирати 10 вузлів, які виконуватимуть роль валідаторів, перевіряючи, чи має запит користувача бути схвалений, а потім генеруючи відповідний пороговий підпис для його затвердження. Щоб запобігти внутрішньому змові або зовнішнім атакам хакерів, алгоритм вибору CRVA використовує оригінальний кільцевий VRF у поєднанні з ZK для приховування особи обраних, щоб зовнішній світ не міг безпосередньо спостерігати за вибраними.
Звичайно, просто цього недостатньо. Хоча зовнішній світ не знає, хто був обраний, обраний знає про це, тому все ще існує шлях для змови. Щоб ще більше запобігти змові, всі вузли CRVA повинні виконувати основний код у середовищі TEE, що еквівалентно виконанню основної роботи в чорній скрині. Таким чином, ніхто не може дізнатися, чи був він обраний, якщо тільки він не зможе зламати довірене апаратне забезпечення TEE, хоча, судячи з нинішніх технологічних можливостей, це надзвичайно важко зробити.
Вищезазначене є основною ідеєю рішення CRVA від DeepSafe. У реальному робочому процесі між вузлами в мережі CRVA має відбуватися велика кількість широкомовних комунікацій та обміну інформацією, конкретний процес виглядає наступним чином:
Усі вузли перед входом у мережу CRVA повинні спочатку заблокувати активи в ланцюзі, залишивши відкритий ключ як реєстраційну інформацію. Цей відкритий ключ також називають "постійним відкритим ключем".
Кожну годину мережа CRVA випадковим чином обирає кілька вузлів. Але перед цим усі кандидати повинні локально згенерувати одноразовий "тимчасовий публічний ключ", одночасно згенерувавши ZKP, щоб довести, що "тимчасовий публічний ключ" має зв'язок з "постійним публічним ключем", записаним в ланцюзі; іншими словами, кожен повинен за допомогою ZK довести свою присутність у списку кандидатів, але не розкривати, хто він.
"Тимчасовий публічний ключ" відіграє роль у захисті приватності. Якщо прямо обирати з набору "постійних публічних ключів", під час публікації результатів всі відразу дізнаються, хто був обраний. Якщо ж усі розкривають лише одноразовий "тимчасовий публічний ключ", а потім вибирають кількох людей з набору "тимчасових публічних ключів", ви зможете дізнатися лише про свою виграшну квоту, але не будете знати, кому відповідають інші виграшні тимчасові публічні ключі.
Щоб далі запобігти витоку особистості, CRVA має намір зробити так, щоб ви навіть не знали, що таке ваш "тимчасовий публічний ключ". Процес генерації тимчасового публічного ключа відбувається в середовищі TEE вузла, і ви, працюючи в TEE, не можете бачити, що там відбувається.
Потім у TEE тимчасовий відкритий ключ шифрується в "незрозумілий текст" і надсилається зовнішньому світу, тільки певні вузли Relayer можуть його відновити. Звичайно, процес відновлення також виконується у середовищі TEE вузлів Relayer, і Relayer не знає, яким кандидатам відповідають ці тимчасові відкриті ключі.
Relayer після відновлення всіх "тимчасових публічних ключів" об'єднує їх і подає до VRF-функції на ланцюгу, звідки обираються переможці. Ці люди перевіряють запити на транзакції, що надіслані з фронтенду користувача, а потім на основі результатів перевірки генерують пороговий підпис, який в кінцевому підсумку знову подається на ланцюг. (Слід зауважити, що Relayer тут також є анонімним і періодично обирається.)
Можливо, хтось запитає, якщо кожен вузол не знає, чи був він обраний, то як продовжується робота? Насправді, як уже згадувалося раніше, кожен генерує "тимчасовий відкритий ключ" у своєму локальному середовищі TEE, і після оголошення результатів жеребкування ми просто транслюємо список, і кожен може передати список в TEE, щоб перевірити, чи був він обраний.
Основна суть рішення DeepSafe полягає в тому, що майже всі важливі дії виконуються в апаратному середовищі TEE, і ззовні TEE неможливо спостерігати, що відбувається. Кожен вузол не знає, хто є обраним валідатором, що запобігає змовам і значно підвищує вартість зовнішніх атак. Щоб атакувати комітет CRVA, заснований на DeepSafe, теоретично потрібно атакувати всю мережу CRVA, і, оскільки кожен вузол має захист TEE, складність атаки значно зростає.
Реалізація рішення з самостійного зберігання активів CRVA
Вгорі ми представили загальний принцип CRVA, пояснивши, як CRVA реалізує децентралізовану без довіри. Далі ми розглянемо випадок стабільної монети на основі біткойна під назвою HelloBTU, щоб детальніше розглянути застосування CRVA в схемах зберігання активів.
Відомо, що через відсутність у біткоїн-ланцюга середовища, що підтримує Тюрінг, неможливо безпосередньо реалізувати складну логіку смарт-контрактів, таких як DeFi, тому основна маса BTCFi з'єднує біткоїн з іншими ланцюгами, а потім взаємодіє зі смарт-контрактами. Смарт-контракт частини HelloBTU розміщено на Ethereum, користувачі можуть вносити BTC на вказану HelloBTU адресу для отримання, а потім офіційний міст переносить BTC на ланцюг Ethereum, після чого можна взаємодіяти зі смарт-контрактом HelloBTU.
Припустимо, що зараз користувач хоче заблокувати 10 BTC на платформі HelloBTU. Конкретна операція полягає в тому, щоб спочатку перевести 10 BTC на адресу Taproot на блокчейні Bitcoin, для розблокування якої потрібен 2/2 мультипідпис. Один з підписів генерує користувач, а інший - CRVA.
Тут йдеться про кілька ситуацій:
Припустимо, що 10 BTC надійшли на вказану адресу Taproot, після чого користувач використав ці 10 BTC для випуску стейблкоїн, і тепер має намір активувати викуп BTC. У цей момент користувач і CRVA генерують один підпис, щоб розблокувати ці 10 BTC і повернути їх на адресу користувача. Якщо CRVA тривалий час не співпрацює з користувачем, після закінчення терміну заморожування користувач може в односторонньому порядку повернути ці 10 BTC, ця функція називається "активний викуп користувачем".
З іншого боку, BTC користувача як застава була ліквідована, і тепер він повинен співпрацювати з CRVA для переказу цих BTC і передачі їх в односторонній канал CRVA. Але користувач може відмовитися від співпраці, і в цей час BTC тимчасово застрягає, і ніхто не може його забрати; Після закінчення вікна блокування часу гроші можуть бути переказані CRVA та введені в односторонній канал ( під адресою Taproot, контрольованою CRVA )CRVA;
Є один нюанс: часова блокування для входу BTC в односторонній канал CRVA є коротшою, в той час як часова блокування для самостійного викупу користувачем є довшою. Іншими словами, якщо між CRVA та користувачем не буде співпраці, ці BTC в кінцевому підсумку будуть пріоритетно входити в односторонній канал CRVA. Це дозволить ефективно обмежити поведінку користувачів, які намагаються ухилитися від відповідальності.
Що стосується випадків злочинної діяльності CRVA, то оскільки CRVA є автоматизованою системою мережі вузлів, якщо в початковому коді, з якого вона запускається, немає зловмисної логіки, то не виникне ситуації, коли CRVA активно відмовляється співпрацювати з користувачами, тому це можна вважати практично незначним;
Якщо CRVA через відключення електроенергії, повені та інші непереборні обставини призведе до масового простою вузлів, користувачі все ще мають можливість безпечно вивести свої активи відповідно до процесу, згаданого в наведеній схемі. При цьому довірча припущення полягає в тому, що ми достатньо довіряємо CRVA, що вона достатньо децентралізована і не буде навмисно завдавати шкоди (причини вже були достатньо пояснені раніше).
Якщо BTC переводиться в односторонній канал CRVA, це зазвичай означає, що відповідна ланцюгова позиція була ліквідована. У цьому випадку фактичне право власності на BTC належить ліквідатору. Ліквідатор може подати запит на виведення коштів, який розгляне CRVA. Якщо запит буде схвалено, CRVA створить підпис і переведе відповідну суму BTC ліквідатору.
У цей час, якщо CRVA довгий час не відповідає, після закінчення терміну блокування ці BTC будуть переведені на адресу, контрольовану DAO. Цю операцію ініціює мультипідпис, а подальше вирішення питань здійснюється за допомогою управління DAO. Це DAO складається з відомих проектів, безпекових компаній та інвестиційних установ і було створено з метою стримування злочинних дій окремих суб'єктів.
Отже, ми в загальних рисах висвітлили рішення DeepSafe щодо самостійного зберігання активів біткоїна, а для активів ERC-20 його принцип аналогічний, тому тут не будемо повторюватись. Щодо згаданої раніше справи з замороженням unibtc, якщо міжмережевий міст unibtc використовує рішення CRVA для самостійного зберігання, малоймовірно, що емітент активів зможе одноосібно контролювати ситуацію.
Контент має виключно довідковий характер і не є запрошенням до участі або пропозицією. Інвестиційні, податкові чи юридичні консультації не надаються. Перегляньте Відмову від відповідальності , щоб дізнатися більше про ризики.
1 лайків
Нагородити
1
1
Поділіться
Прокоментувати
0/400
GetRichByHoardingCoi
· 05-06 08:50
Будь ласка, пам'ятайте, що будь-яка справа, пов'язана з експлуатацією вразливостей вечірки проєкту, має дев'яносто відсотків ймовірності призвести до повної втрати. Це називається користуванням чужими труднощами. Якщо проблема з вразливістю буде вирішена, і ви випадково стали багатим, але рано чи пізно ці гроші також будуть втрачені.
Більше 100 тисяч доларів заблоковано: важливість безпідставного зберігання на прикладі ситуації з замороженням unibtc
Оригінальний автор:仙壤GodRealmX
23 квітня 2025 року, користувач на ім'я Brain попросив допомоги в Twitter через свого друга, заявивши, що під час арбітражних операцій на одному з Bitcoin Layer2 ланцюгів активи unibtc на суму понад 100 тисяч доларів були заблоковані офіційним Bedrock і не можуть бути виведені.
Згідно з розкриттям сторони W, 17 квітня він виявив аномалію цін на unibtc, випущений Bedrock, на певній L2-ланці біткоїна, де він відв'язався від BTC. W вважає, що відв'язка є тимчасовою і незабаром повернеться до прив'язки, тому тут є хороша можливість для арбітражу, і він частину BTC перевів на цю L2-ланку біткоїна, обмінявши їх на unibtc, і чекає, поки вони повернуться до прив'язки, щоб продати.
Лише через 24 години після відв'язання unibtc вже повернувся до якоря, але коли W спробував продати свій unibtc, він виявив, що ліквідний пул unibtc-BTC на цій ланцюзі був вилучений офіційно Bedrock, а ця токенна пара є єдиним виходом на вторинний ринок unibtc на цій ланцюзі. W не зміг продати свій unibtc, тому спробував перенести unibtc на інші ланцюги.
Коли він знайшов єдиний кросчейн-міст на цій ланцюзі, що підтримує unibtc (названий Free), він отримав повідомлення - "Транзакція потребує підпису авторизації від проекту". W звернувся до служби підтримки кросчейн-мосту Free, де йому пояснили: "Мультипідписний ключ для кросчейну unibtc управляється Bedrock, без їхнього дозволу користувач не може перевести unibtc на інші ланцюги."
Немає виходу, W може лише звернутися до відповідних осіб з Bedrock з цього питання, і первинна відповідь з їхнього боку була: "Ми можемо дозволити вам вивести основний капітал, але чи можна вивести прибуток від арбітражу, потрібно ще перевірити."
На цьому етапі W усвідомив, що шлях виходу unibtc на цьому ланцюзі повністю перекритий, а його unibtc вартістю близько 200 тисяч U "тимчасово заморожено" — він не може продати їх на цьому ланцюзі і не може перейти на інші ланцюги. У цей момент він відчував велику безпорадність, сподіваючись просто повернути свій капітал.
Однак ставлення осіб, що пов'язані з BedRock, стало неоднозначним - вони не уточнюють, коли W може повернути свій капітал, і не надають жодних письмових зобов'язань, затримуючи процес з причин "перевірки ризиків", "технічної перевірки" та інших.
Після деякого затримки BedRock стверджує, що відключення unibtc сталося через те, що на платформі LayerBank хтось масово позичив активи unibtc і здійснив маніпуляції на ринку, після чого люди з BedRock запропонували W "пред'явити претензії до LayerBank". А W, знайшовши LayerBank, довгий час не отримував відповіді.
В безвихідній ситуації W змушений був знайти друзів у Твіттері для допомоги, після більше ніж двох тижнів переговорів, він нарешті отримав позитивну відповідь від офіційних представників LayerBank і BedRock, успішно повернувши активи.
У遭遇 не є одиничним випадком. Згідно з відгуками інших учасників, минулого року BedRock також використовував подібні методи для блокування виходу користувачів з unibtc, що призвело до «суттєвого замороження» цих unibtc. Звичайно, ця стаття не має наміру спекулювати на причинах зазначених подій, а лише з технічної точки зору пояснити, як уникнути та запобігти подібним централізованим зловживанням.
По-перше, переглядаючи вищезгадані події, ми можемо побачити, що BedRock, будучи емітентом unibtc та початковим LP ліквідного пулу на вторинному ринку, природно має право на вихід з вторинного ринку unibtc. Якщо потрібно обмежити його повноваження, це більше потрібно робити через управління, а не технічні засоби;
Однак, згадане раніше про те, що Free мост між ланцюгами та BedRock змовлялися, щоб відмовити користувачам, виявляє очевидні технічні недоліки unibtc на етапах "випуску — одно-ланцюгового обігу — багато-ланцюгового обігу": Free міст між ланцюгами, будучи партнером BedRock, очевидно, є високо централізованим.
Справжній бездокументний міст має гарантувати, що офіційний міст не може перешкоджати виходу користувачів, тоді як у справі з замороженням unibtc, як BedRock, так і Free кросс-ланцюгові мости мають потужні централізовані повноваження і не забезпечують канали виходу, які б були стійкими до цензури.
Звісно, подібні випадки, як unibtc, не є рідкістю, і випадки, коли користувачам закривають шлях до виходу, часто трапляються на різних біржах, а для кросчейн мостів або інших типів проектів таких випадків також чимало. У червні 2022 року Harmony Horizon Bridge був змушений призупинити канали виведення 57 активів через хакерську атаку; хоча ця дія має "обґрунтовані причини", це все ж викликало у деяких людей відчуття тривоги.
У події StableMagnet 2021 року команда проекту через заздалегідь залишену уразливість програми вкрала 24 мільйони доларів. Врешті-решт, в Гонконзі та Великій Британії було залучено велику кількість сил поліції, і лише завдяки допомозі громади було повернуто 91% викрадених коштів. Різноманітні випадки чітко показують, що якщо платформа зберігання активів не може надати послуги без довіри, то в кінцевому підсумку це призведе до негативних наслідків.
Однак, Trustless не є чимось, що можна отримати просто так. Від платіжних каналів та DLC до BitVM і ZK Rollup люди намагалися реалізувати різні способи, хоча це може значною мірою забезпечити автономію користувачів і надати надійні виходи для виведення активів, проте за цим все ще стоять невідворотні недоліки.
Наприклад, платіжний канал потребує від сторін моніторингу потенційно злочинних дій контрагента, DLC покладається на оракули; в той час як BitVM має високі витрати і в практичній частині є інші припущення щодо довіри; для активації рятувальної капсули ZK Rollup потрібно пройти довгий період вікна, а також спочатку необхідно зупинити Rollup, що має величезну ціну.
З огляду на поточний стан реалізації основних технологічних рішень, не було представлено ідеального рішення для зберігання активів та виходу з них, ринок все ще потребує нововведень. У наступному тексті DeepSafe Research на прикладі офіційної програми зберігання активів DeepSafe пояснить рішення без довіри для перевірки повідомлень, яке поєднує TEE, ZK та MPC. Це рішення досягає балансу між такими показниками, як вартість, безпека та користувацький досвід, що може забезпечити надійні базові послуги для торгових платформ, кросчейн-мостів або будь-яких сценаріїв зберігання активів.
CRVA: мережа криптографічної випадкової верифікації
В даний час більшість найбільш широко використовуваних рішень для управління активами на ринку використовують мультипідпис або MPC/TSS для визначення того, чи є запит на передачу активів обґрунтованим, що має переваги простого впровадження, низької вартості та швидкої перевірки повідомлень, тоді як недоліки очевидні - вони недостатньо безпечні і, як правило, централізовані. У випадку Multichain 2023 року 21 вузол, який бере участь у обчисленнях MPC, контролюється однією людиною, що є типовою атакою Sybil. Цього достатньо, щоб довести, що одні лише кілька десятків вузлів на поверхні не можуть забезпечити високий рівень гарантії децентралізації.
Щодо недоліків традиційних рішень з управління активами MPC/TSS, рішення CRVA від DeepSafe внесло численні покращення. По-перше, мережеві вузли CRVA використовують модель допуску на основі застави активів, і основна мережа буде офіційно запущена лише після досягнення приблизно 500 вузлів; за оцінками, заставлені активи цих вузлів будуть протягом тривалого часу підтримуватися на рівні кількох десятків мільйонів доларів або вище;
По-друге, для підвищення ефективності розрахунків MPC/TSS, CRVA буде випадковим чином вибирати вузли за допомогою алгоритму вибору, наприклад, кожні півгодини вибирати 10 вузлів, які виконуватимуть роль валідаторів, перевіряючи, чи має запит користувача бути схвалений, а потім генеруючи відповідний пороговий підпис для його затвердження. Щоб запобігти внутрішньому змові або зовнішнім атакам хакерів, алгоритм вибору CRVA використовує оригінальний кільцевий VRF у поєднанні з ZK для приховування особи обраних, щоб зовнішній світ не міг безпосередньо спостерігати за вибраними.
Звичайно, просто цього недостатньо. Хоча зовнішній світ не знає, хто був обраний, обраний знає про це, тому все ще існує шлях для змови. Щоб ще більше запобігти змові, всі вузли CRVA повинні виконувати основний код у середовищі TEE, що еквівалентно виконанню основної роботи в чорній скрині. Таким чином, ніхто не може дізнатися, чи був він обраний, якщо тільки він не зможе зламати довірене апаратне забезпечення TEE, хоча, судячи з нинішніх технологічних можливостей, це надзвичайно важко зробити.
Вищезазначене є основною ідеєю рішення CRVA від DeepSafe. У реальному робочому процесі між вузлами в мережі CRVA має відбуватися велика кількість широкомовних комунікацій та обміну інформацією, конкретний процес виглядає наступним чином:
Усі вузли перед входом у мережу CRVA повинні спочатку заблокувати активи в ланцюзі, залишивши відкритий ключ як реєстраційну інформацію. Цей відкритий ключ також називають "постійним відкритим ключем".
Кожну годину мережа CRVA випадковим чином обирає кілька вузлів. Але перед цим усі кандидати повинні локально згенерувати одноразовий "тимчасовий публічний ключ", одночасно згенерувавши ZKP, щоб довести, що "тимчасовий публічний ключ" має зв'язок з "постійним публічним ключем", записаним в ланцюзі; іншими словами, кожен повинен за допомогою ZK довести свою присутність у списку кандидатів, але не розкривати, хто він.
"Тимчасовий публічний ключ" відіграє роль у захисті приватності. Якщо прямо обирати з набору "постійних публічних ключів", під час публікації результатів всі відразу дізнаються, хто був обраний. Якщо ж усі розкривають лише одноразовий "тимчасовий публічний ключ", а потім вибирають кількох людей з набору "тимчасових публічних ключів", ви зможете дізнатися лише про свою виграшну квоту, але не будете знати, кому відповідають інші виграшні тимчасові публічні ключі.
Щоб далі запобігти витоку особистості, CRVA має намір зробити так, щоб ви навіть не знали, що таке ваш "тимчасовий публічний ключ". Процес генерації тимчасового публічного ключа відбувається в середовищі TEE вузла, і ви, працюючи в TEE, не можете бачити, що там відбувається.
Потім у TEE тимчасовий відкритий ключ шифрується в "незрозумілий текст" і надсилається зовнішньому світу, тільки певні вузли Relayer можуть його відновити. Звичайно, процес відновлення також виконується у середовищі TEE вузлів Relayer, і Relayer не знає, яким кандидатам відповідають ці тимчасові відкриті ключі.
Relayer після відновлення всіх "тимчасових публічних ключів" об'єднує їх і подає до VRF-функції на ланцюгу, звідки обираються переможці. Ці люди перевіряють запити на транзакції, що надіслані з фронтенду користувача, а потім на основі результатів перевірки генерують пороговий підпис, який в кінцевому підсумку знову подається на ланцюг. (Слід зауважити, що Relayer тут також є анонімним і періодично обирається.)
Можливо, хтось запитає, якщо кожен вузол не знає, чи був він обраний, то як продовжується робота? Насправді, як уже згадувалося раніше, кожен генерує "тимчасовий відкритий ключ" у своєму локальному середовищі TEE, і після оголошення результатів жеребкування ми просто транслюємо список, і кожен може передати список в TEE, щоб перевірити, чи був він обраний.
Основна суть рішення DeepSafe полягає в тому, що майже всі важливі дії виконуються в апаратному середовищі TEE, і ззовні TEE неможливо спостерігати, що відбувається. Кожен вузол не знає, хто є обраним валідатором, що запобігає змовам і значно підвищує вартість зовнішніх атак. Щоб атакувати комітет CRVA, заснований на DeepSafe, теоретично потрібно атакувати всю мережу CRVA, і, оскільки кожен вузол має захист TEE, складність атаки значно зростає.
Реалізація рішення з самостійного зберігання активів CRVA
Вгорі ми представили загальний принцип CRVA, пояснивши, як CRVA реалізує децентралізовану без довіри. Далі ми розглянемо випадок стабільної монети на основі біткойна під назвою HelloBTU, щоб детальніше розглянути застосування CRVA в схемах зберігання активів.
Відомо, що через відсутність у біткоїн-ланцюга середовища, що підтримує Тюрінг, неможливо безпосередньо реалізувати складну логіку смарт-контрактів, таких як DeFi, тому основна маса BTCFi з'єднує біткоїн з іншими ланцюгами, а потім взаємодіє зі смарт-контрактами. Смарт-контракт частини HelloBTU розміщено на Ethereum, користувачі можуть вносити BTC на вказану HelloBTU адресу для отримання, а потім офіційний міст переносить BTC на ланцюг Ethereum, після чого можна взаємодіяти зі смарт-контрактом HelloBTU.
Припустимо, що зараз користувач хоче заблокувати 10 BTC на платформі HelloBTU. Конкретна операція полягає в тому, щоб спочатку перевести 10 BTC на адресу Taproot на блокчейні Bitcoin, для розблокування якої потрібен 2/2 мультипідпис. Один з підписів генерує користувач, а інший - CRVA.
Тут йдеться про кілька ситуацій:
Припустимо, що 10 BTC надійшли на вказану адресу Taproot, після чого користувач використав ці 10 BTC для випуску стейблкоїн, і тепер має намір активувати викуп BTC. У цей момент користувач і CRVA генерують один підпис, щоб розблокувати ці 10 BTC і повернути їх на адресу користувача. Якщо CRVA тривалий час не співпрацює з користувачем, після закінчення терміну заморожування користувач може в односторонньому порядку повернути ці 10 BTC, ця функція називається "активний викуп користувачем".
З іншого боку, BTC користувача як застава була ліквідована, і тепер він повинен співпрацювати з CRVA для переказу цих BTC і передачі їх в односторонній канал CRVA. Але користувач може відмовитися від співпраці, і в цей час BTC тимчасово застрягає, і ніхто не може його забрати; Після закінчення вікна блокування часу гроші можуть бути переказані CRVA та введені в односторонній канал ( під адресою Taproot, контрольованою CRVA )CRVA;
Є один нюанс: часова блокування для входу BTC в односторонній канал CRVA є коротшою, в той час як часова блокування для самостійного викупу користувачем є довшою. Іншими словами, якщо між CRVA та користувачем не буде співпраці, ці BTC в кінцевому підсумку будуть пріоритетно входити в односторонній канал CRVA. Це дозволить ефективно обмежити поведінку користувачів, які намагаються ухилитися від відповідальності.
Що стосується випадків злочинної діяльності CRVA, то оскільки CRVA є автоматизованою системою мережі вузлів, якщо в початковому коді, з якого вона запускається, немає зловмисної логіки, то не виникне ситуації, коли CRVA активно відмовляється співпрацювати з користувачами, тому це можна вважати практично незначним;
Якщо CRVA через відключення електроенергії, повені та інші непереборні обставини призведе до масового простою вузлів, користувачі все ще мають можливість безпечно вивести свої активи відповідно до процесу, згаданого в наведеній схемі. При цьому довірча припущення полягає в тому, що ми достатньо довіряємо CRVA, що вона достатньо децентралізована і не буде навмисно завдавати шкоди (причини вже були достатньо пояснені раніше).
Якщо BTC переводиться в односторонній канал CRVA, це зазвичай означає, що відповідна ланцюгова позиція була ліквідована. У цьому випадку фактичне право власності на BTC належить ліквідатору. Ліквідатор може подати запит на виведення коштів, який розгляне CRVA. Якщо запит буде схвалено, CRVA створить підпис і переведе відповідну суму BTC ліквідатору.
У цей час, якщо CRVA довгий час не відповідає, після закінчення терміну блокування ці BTC будуть переведені на адресу, контрольовану DAO. Цю операцію ініціює мультипідпис, а подальше вирішення питань здійснюється за допомогою управління DAO. Це DAO складається з відомих проектів, безпекових компаній та інвестиційних установ і було створено з метою стримування злочинних дій окремих суб'єктів.
Отже, ми в загальних рисах висвітлили рішення DeepSafe щодо самостійного зберігання активів біткоїна, а для активів ERC-20 його принцип аналогічний, тому тут не будемо повторюватись. Щодо згаданої раніше справи з замороженням unibtc, якщо міжмережевий міст unibtc використовує рішення CRVA для самостійного зберігання, малоймовірно, що емітент активів зможе одноосібно контролювати ситуацію.
Якщо проблема з вразливістю буде вирішена, і ви випадково стали багатим, але рано чи пізно ці гроші також будуть втрачені.