Чи можна усунути ризик змови та підвищити безпеку крос-ланцюгового мосту без шкоди для продуктивності, масштабованості та універсальності крос-ланцюгового мосту?
Автор: MiddleX
З розвитком багатоланцюжкового шаблону крос-ланцюговий міст став важливою інфраструктурою в області Web3.Незалежно від того, як розвивався шаблон публічного ланцюга, крос-ланцюг завжди є постійним жорстким попитом. Учасникам проекту Dapp їм потрібно розширити сферу діяльності до якомога більшої кількості ланцюгів, від Dapp з одним ланцюгом до Dapp із повним ланцюгом; для учасників проекту публічного ланцюга кожен має мотивацію поєднати біткойн і Ethereum Square, щоб імпортувати активи та трафік для власної екології; для зашифрованих користувачів вони також сподіваються дозволити їхнім зашифрованим активам подорожувати по різних ланцюгах у децентралізований спосіб, замість того, щоб покладатися на централізовані обміни.
Однак ланцюговий міст, як «транспортний засіб для перевезення готівки» між ланцюгами, неодноразово «грабували». Протягом останніх двох років, майже без винятку, основні проекти міжланцюгових мостів протегували хакерам. Серед усіх типів інцидентів із безпекою шифрування інцидент міжланцюгового мосту очолив список зі збитками майже 2 мільярди доларів США. Щоб вирішити проблему безпеки поперечного ланцюгового мосту, неминуче до цього «відкритого» «грошового носія» додати броню.
Як зламати гру?
Загалом, існує два типи інцидентів безпеки в крос-ланцюжкових мостах: один спричинений лазівками в коді контракту, як-от відсутність перевірки адреси контракту маркера, через що події депозиту підробленої валюти, підроблені зловмисниками, не фільтруються, а інший прикладом є відсутність контролю доступу, що призводить до того, що список набору валідатора було підроблено; іншим є змова вузлів валідатора з метою викрадення приватного ключа, а потім викрадення коштів, заблокованих перехресним мостом або монетним двором фальшиві монети, щоб пограбувати LP.
Основна причина першого полягає в тому, що кодова база міжланцюгового мосту ще не є зрілою, і такі проблеми поступово зменшаться з накопиченням досвіду галузі. Основною причиною останнього є властиві недоліки в конструкції поперечно-ланцюгових мостів.
Перехресний ланцюговий міст по суті вирішує проблему того, як один ланцюг дізнається про події в іншому ланцюзі. Ця проблема поділяється на два аспекти: один – це передача, а інший – перевірка. У міжланцюжковому мості будь-хто може передавати міжланцюгові події, ключовим є те, як цільовий ланцюжок перевіряє, що подія справді сталася у вихідному ланцюжку. **
Відповідно до різних механізмів верифікації міжланцюгові мости поділяються на три типи: нативно перевірені, локально перевірені та зовнішні перевірені.
Власна перевірка означає, що всі верифікатори цільового ланцюга проводять консенсусну перевірку подій вихідного ланцюга, що зазвичай реалізується шляхом розгортання легкого клієнта вихідного ланцюга в цільовому ланцюзі. Цей легкий клієнт постійно зберігає та оновлює заголовок блоку вихідного ланцюжка, а потім виконує SPV перевірку подій вихідного ланцюжка.
Локальна перевірка стосується прямої перевірки транзакції контрагентом, також відомої як точка-точка перевірки. Типовою парадигмою є атомарний своп на основі хешованих блокувань часу. Оскільки економічні інтереси сторін угоди антагоністичні, можливість змови відсутня.
Зовнішня перевірка означає введення групи зовнішніх свідків, відповідальних за перевірку міжланцюжкових повідомлень. Набір зовнішніх свідків виконує консенсусний підпис щодо подій міжланцюга. Після того, як цільовий ланцюг перевірить підпис, він вважає подію достовірною.
Вартість нативної перевірки висока, що в основному відображається в двох пунктах. По-перше, висока вартість перевірки в ланцюжку. Запуск легкого клієнта в ланцюжку та виконання SPV перевірки подій споживає багато газу. По-друге, вартість розробки сумісності з новими ланцюгами висока.Для забезпечення сумісності з новим ланцюгом необхідно розробити принаймні одну пару легких клієнтів. У зв’язку з розвитком наративів ZK на ринку в даний час з’явилися рішення для покращення нативної верифікації за допомогою технології ZK, яка може ефективно зменшити вищезазначені витрати.Однак, незалежно від того, наскільки оптимізовано, принаймні одне підтвердження ZK має бути перевірено в ланцюжку, і вартість становить близько 500 тис. Гвей. Для перевірки потрібно лише перевірити підпис (21 тис. Гвей), який є зовсім іншим. Таким чином, рідна перевірка не може отримати перевагу в ціновій конкуренції міжланцюгових мостів і не може реалізувати справжній «повний ланцюг».
Локальну автентифікацію колись використовували відомі проекти, такі як Celer і Connext, але ці проекти, без винятку, змінили свій тон і більше не використовують локальну автентифікацію. Причина полягає в тому, що локальна верифікація транзакцій надзвичайно погана. Незалежно від того, наскільки вона оптимізована, вона завжди вимагає від користувача принаймні двох дій (ініціювання транзакції, розблокування хеш-блокування). Крім того, локальна перевірка застосовна лише до перехресних ланцюжків активів і не може бути розширена до будь-якого перехресного ланцюга повідомлень.
Вартість реалізації зовнішньої верифікації низька, міжланцюгові накладні витрати низькі, її можна легко адаптувати до кількох ланцюжків і підтримує крос-ланцюжок довільних повідомлень. Наразі це рішення прийнято більшістю крос-ланцюжків проекти мостів. Однак зовнішні міжланцюгові мости створюють потенційні ризики змови через впровадження нових припущень про довіру. Більшість перехресних мостів зовнішньої перевірки використовують технологію MPC (захищене багатостороннє обчислення) для фрагментації закритого ключа, щоб кожен зовнішній вузол перевірки міг керувати фрагментом. Порівняно зі звичайною технологією MutiSig (багатопідписів), технологія MPC є більш універсальною (немає вимог до схеми підпису, прийнятої ланцюжком), вартість перевірки нижча (лише один підпис потрібно перевірити в ланцюжку), і це зручно для передачі повноважень підпису (потрібно лише оновити шард, не потрібно змінювати адресу) та інші переваги, але це не змінює суті централізації зовнішньої перевірки та не може запобігти змові.
Отже, яке крос-ланцюгове рішення можна використати для усунення ризику змови та підвищення безпеки крос-ланцюгового мосту без шкоди для продуктивності, масштабованості та універсальності крос-ланцюгового мосту?
Схема мережі BOOL
BOOL Network — це міжланцюговий мостовий продукт, запущений LayerBase Labs. LayerBase Labs проводила дослідження в області крос-ланцюгів протягом майже 4 років, протягом яких вона випустила деякі мінімально життєздатні продукти, але через недосконалість цих продуктів вони не отримали широкого використання. Нещодавно LayerBase Labs запустила перехресний міст на основі динамічного прихованого комітету (DHC): Мережа BOOL Це рішення вважається достатньо досконалим, тому воно готове до представлення громадськості.
Міжланцюгове рішення BOOL Network інтегрує технологію ZK і технологію TEE на основі технології MPC і перетворює зовнішній набір верифікаторів на невідомий і невідомий динамічний прихований комітет, досягаючи високого рівня антизмовних атрибутів, таким чином досягаючи високий ступінь безпеки.
Давайте використаємо приклад, щоб проілюструвати, що таке «динамічний клуб прихованих учасників».
Припустімо, що ви генерал, який командує 1000 солдатами і має наказ охороняти 50 зерносховищ, як ви розставите своїх солдатів?
Якщо припустити, що всі зерносховища однаково важливі, найкращим було б розділити 1000 солдатів на 50 загонів по 20 чоловік у кожному для охорони зерносховища.
Але поділ військ несе в собі приховану небезпеку. Якщо більше половини солдатів у певній команді змовляються, відповідний зерносховище може впасти. Тобто, якщо 11 солдатів у команді змовляються, вони можуть зрадити вас і пограбувати зерносховище. .
Це те, чого ви терпіти не можете.Щоб запобігти подібного роду змови і забезпечити безпеку зерносховища, ви можете вжити наступних заходів:
Динамічний: усі солдати перегруповуються, а загони перерозподіляються щодня, так що комора, яку охороняє кожен солдат і його товариші по команді, не буде виправленою;
Прихований: зав’яжіть очі солдатам, щоб вони не знали, який зерносховище вони охороняють або хто їхні товариші по команді.
Таким чином повсталі солдати не знатимуть, з ким вступати в змову. Навіть якщо є заздалегідь домовлені зрадники, вони не можуть контролювати і не можуть знати, чи є зрадники в одній команді.
Якщо припустити, що для забезпечення високої ймовірності успіху змови, зрадник повинен вступити в змову з більшістю всієї вашої команди з 1000 чоловік. Це, безсумнівно, так само важко, як піднятися в небо. За допомогою «динамічних» і «прихованих» методів ви досягаєте надійності кожного загону на рівні всієї команди.
Саме таку схему прийняла мережа BOOL.
TEE - Зав'яжіть очі кожному солдату
Мережа BOOL вимагає, щоб вузли в мережі використовували пристрої TEE для участі в перевірці подій крос-ланцюга. Мережа BOOL є повністю відкритою та доступною, і будь-який суб’єкт із пристроєм TEE може стати вузлом перевірки, зробивши $BOOL.
Повна назва TEE — довірене середовище виконання (Trusted ute Environment). Це обчислювальне середовище, що працює на певному пристрої, яке ізольовано від основної операційної системи, як анклав. Ця ізоляція забезпечується апаратним забезпеченням. Процес виконання програм у TEE прихований, зовнішній світ його не сприймає чи не втручається в нього. Це унеможливлює атаку хакерів.
TEE може запускати програми з високим рівнем безпеки, такі як біометрична автентифікація, безпечне керування платежами тощо. У нашому повсякденному житті TEE не чужий, і перевірка відбитків пальців на мобільних телефонах виконується в TEE. Це може гарантувати, що інші програми мобільного телефону не зможуть отримати інформацію про відбитки пальців під час використання результату перевірки відбитків пальців.
Під час процесу перевірки міжланцюжкових подій зовнішні верифікаційні вузли повинні виконувати підписи консенсусу.У цей час приватний ключ має бути відкритий для мережі, що дуже легко стати об’єктом хакерських атак. Атака на офіційний міст Axie Infinity Ronin Bridge у березні 2022 року та атака на офіційний міст Horizen Bridge публічної мережі Harmony у червні 2022 року були спричинені хакерами, отриманими закритим ключем вузла мосту. Використання TEE для зберігання фрагментів приватного ключа та виконання консенсусних підписів значно покращить безпеку та запобіжить отриманню приватних ключів хакерами. Виходячи з цього, мережа BOOL вимагає, щоб увесь зв’язок між вузлами TEE також був повністю зашифрований, щоб хакери не могли перехопити будь-яку інформацію з вмісту зв’язку між вузлами.
Кільце VRF - Нехай солдати чергуються випадковим чином
Мережа BOOL розроблена як інструмент для створення крос-ланцюжкового мосту, який підтримує будь-яку третю сторону для створення крос-ланцюжкового мосту на ньому. Коли третя сторона створює крос-ланцюжковий міст у мережі BOOL, їй потрібно створити Спочатку DHC (Dynamic Hidden Membership Club). Якщо припустити, що третя сторона хоче, щоб міжланцюговий міст, який вона створює, підтримував 10 ланцюгів, їй потрібно створити 10 DHC, кожен ланцюг відповідає DHC, і всі міжланцюгові повідомлення надсилаються до ланцюга перевіряються DHC.
Кожного разу, коли третя сторона створює перехресний міст через мережу BOOL, буде створено кілька DHC. Оскільки кількість перехресних мостів, створених у мережі BOOL, продовжує збільшуватися, DHC можуть бути тисячі. Третя сторона може встановити порогове значення підпису DHC, і загальні порогові значення підпису: 5 з 9, 13 з 19 і 15 з 21.
Слід зазначити, що учасники в кожному DHC не фіксовані, а постійно змінюються, і кожна епоха перемішується один раз. На основі технології ZK мережа BOOL розробила протокол Ring VRF, який може призначати учасників до кожного DHC абсолютно випадковим чином. Ring VRF згенерує підтвердження ZK для учасників DHC. Це підтвердження ZK представляє тимчасову особу учасників. Учасники DHC використовують тимчасові ідентифікаційні дані для ідентифікації та спілкування один з одним, щоб співпрацювати для виконання певної роботи (наприклад, підпис порогового значення MPC). ; Це забезпечує анонімність учасників DHC як зовні, так і один з одним.
В одній епосі вузли TEE у різних DHC можуть перекриватися, або деякі вузли TEE можуть бути неактивними, не ввійшовши до жодного DHC. Ці ситуації дозволені, але RIng VRF надасть кожному вузлу TEE однакові можливості.
Коротше кажучи, **Завдяки динамічному приховуванню механізму членства комітету BOOL Network створила непорушну чорну скриньку. Якщо вузол TEE знаходиться в робочому стані, ніхто (включно з оператором вузла, іншими вузлами та зовнішніми зловмисниками) не може дізнатися про робочий стан вузла. У якому DHC знаходиться вузол? На тому ж DHC, що й інші вузли? Які консенсусні комунікації мали місце? Які повідомлення підписані? Немає способу дізнатися правду. Це згадані вище «непізнаваність» і «незнання». За такої передумови, поки сама мережа BOOL безпечна, кожен динамічний прихований учасник є безпечним. Щоб забезпечити високу ймовірність успіху атаки, зловмисник повинен оволодіти більшістю вузлів мережі BOOL. Однак, оскільки програми, запущені в TEE, неможливо змінити, зловмисники можуть лише вимкнути мережу та не можуть викрасти активи в мережі.
Як оцінити крос-ланцюгове рішення
Хоча безпека є найбільш актуальною проблемою, яку необхідно вирішити для перехресних ланцюгових мостів, безпека не є єдиним критерієм для оцінки перехресних ланцюгових мостів. Якщо для вирішення проблеми створюється нова проблема, це не є її вирішенням.
LayerBase Labs довго вивчала різні рішення розширення на основі легких клієнтів, включаючи рішення ZK Client. Основний принцип ZK-клієнта полягає в тому, щоб розширити легкий клієнт за допомогою технології ZK, вивести перевірку заголовка блоку та перевірку SPV події вихідного ланцюга поза ланцюжком, створити сертифікат ZK і надіслати його в ланцюжок, і потрібно лише щоб перевірити сертифікат ZK у ланцюжку. Це еквівалентно перевірці заголовків блоків і подій вихідного ланцюга. Хоча ця схема досить безпечна, споживання газу в ланцюжку все ще високе. По-друге, ланцюг ZK під ланцюгом і легкий клієнт на ланцюжок є відносно хорошим з точки зору інженерної реалізації.Складність, яка може призвести до більшої вразливості на рівні коду, таким чином впливаючи на безпеку крос-ланцюжкового мосту. Крім того, щоб уникнути потреби кожного ланцюжка розгортати легкі клієнти всіх інших ланцюгів, це рішення часто має запроваджувати ланцюг ретрансляції (див. малюнок нижче), і існування ланцюга ретрансляції зробить крос-ланцюг, який може бути завершеним за один крок. Процес доставки повідомлення довелося розділити на два етапи, що призвело до збільшення затримки (затримки) міжланцюжкової доставки повідомлення.
У галузі є багато людей, які підтримують технологію ZK Client і навіть стверджують, що ZK Client є найкращим рішенням для міжланцюгових мостів. Ми хочемо сказати, що технології не для показухи, не кажучи вже про моду, а для реального вирішення проблем.Клієнт ZK створює набагато більше проблем, ніж вирішує.
Ми також вивчали так зване рішення Ultra Light Client від LayerZero. LayerZero поміщає легкого клієнта в оракул поза ланцюгом, щоб вирішити проблему накладних витрат газу в ланцюзі, але ви передаєте відповідальність за перевірку верифікатору цілі. chain Враховуючи оракул поза ланцюгом, це вже не рідна перевірка, а зовнішня перевірка, і існує припущення безпеки для оракула поза ланцюгом. Що стосується передумови безпеки, заявленої LayerZero Labs: «Ретранслятор і машина Oracle незалежні одна від одної», вона насправді не існує, і експеримент з атаками L2BEAT Labs підтвердив цю думку.
Ми також помітили оптимістичну схему перевірки, прийняту Nomad і Celer. Додавши роль претендента на основі зовнішньої перевірки, безпеку m-of-n можна успішно покращити до 1-of-n. Хоча ця схема добре задумано, вартість становить приблизно 30 хвилин, що обмежить сферу застосування схеми.
Ми також виявили крутий дизайн Avalanche Bridge, який використовує вузли TEE як зовнішні верифікатори для перевірки крос-чейн подій і забезпечує ефективний і дешевий крос-чейн досвід завдяки мінімалістичному дизайну контракту. Але ми також побачили, що хоча Avalanche Bridge може безпечно зберігати приватний ключ, щоб запобігти зовнішнім зловмисникам, він не може запобігти атаці змови між внутрішніми вузлами TEE.
Зрештою, ми запропонували поточну схему динамічного прихованого комітету BOOL Network. З точки зору безпеки, вона може запобігти зовнішнім атакам хакерів і внутрішній змові. З точки зору продуктивності та досвіду, досвід крос-ланцюжків BOOL Network не є одним із жертвує на основі зовнішньої перевірки та підтримує той самий рівень, що й міст зовнішньої перевірки.
Щоб оцінити міжланцюговий міст, ми вважаємо, що на основі неможливого трикутника його слід розкласти на шість аспектів для комплексної оцінки, а саме вартість (Cost), швидкість (Speed), безпека (Security), зручність використання (Liveness), загальність і Scarablity**.
Вартість: вартість міжланцюжкової перевірки в основному залежить від вартості газу в ланцюзі. Вартість міжланцюжної перевірки повідомлень мережі BOOL насправді полягає лише в одній перевірці підпису, яка є на тому ж рівні, що й зовнішній перевірочний міст;
Швидкість: тут ми оцінюємо лише затримку самого ланцюжкового мосту, не беручи до уваги остаточність самого ланцюжка. На даний момент, оскільки немає надлишкових обчислень у ланцюзі та поза ланцюгом, а також немає дизайну ланцюга реле (ланцюг реле призведе до надлишкової перевірки другого порядку), швидкість крос-ланцюга BOOL Network також може досягти граничного рівня ;
Безпека: ми повністю обговорили, що мережа BOOL може запобігти зовнішнім атакам і внутрішній змові. *
Доступність: Простіше кажучи, уникайте збоїв. BOOL Nework дозволить кожному DHC бути обладнаним одним або декількома резервними DHC під час його створення, щоб запобігти проблемам доступності, спричиненим, коли більше половини вузлів TEE у певному DHC знаходяться в автономному режимі.
Загальність: необхідно не лише підтримувати крос-ланцюжок активів, але й підтримувати крос-ланцюг довільних повідомлень, що також задовольняє мережа BOOL.
Масштабованість: чи може він швидко підтримувати нові ланцюжки. Мережі BOOL потрібно лише розгорнути набір простих контрактів для підтримки нового ланцюга (можна витратити 1 людино-місяць на розробку людино-годин), і тепер ми завершили підтримку всіх основних блокчейнів. Крім того, мережа BOOL не обмежена повнотою ланцюжка за Тьюрингом і може підтримувати повні ланцюжки без Тьюринга, такі як BTC, без додавання нових припущень довіри.
Можна сказати, що мережа BOOL є шестикутним воїном у перехресному ланцюжковому мосту.
Варто зазначити, що документи про технічні рішення BOOL Network були включені до IEEE TIFS, провідного журналу в галузі криптографії (посилання: Це означає визнання технічних рішень BOOL Network спільнотою криптографів.
Майбутній напрямок
BOOL Network наразі надає безпечну міжланцюгову платформу побудови мостів, і будь-яка третя сторона може створити повну ланцюжкову програму на основі Bool Network. Мережа BOOL стане найнадійнішою базовою підтримкою для всієї ланцюжкової програми.
Дивлячись на це з іншої точки зору, BOOL Network по суті будує децентралізовану машину підпису, яку можна використовувати не лише для перевірки повідомлень у ланцюжку, але й для перевірки повідомлень поза ланцюгом, що означає, що BOOL Network стане безпечною та надійною повноланцюговий оракул. Крім того, децентралізована мережа TEE, створена BOOL Network, також надаватиме конфіденційні обчислювальні послуги в майбутньому.
Переглянути оригінал
Контент має виключно довідковий характер і не є запрошенням до участі або пропозицією. Інвестиційні, податкові чи юридичні консультації не надаються. Перегляньте Відмову від відповідальності , щоб дізнатися більше про ризики.
Зрозумійте Bool Network за три хвилини: шестикутні воїни в перехресних ланцюжкових мостах
Автор: MiddleX
З розвитком багатоланцюжкового шаблону крос-ланцюговий міст став важливою інфраструктурою в області Web3.Незалежно від того, як розвивався шаблон публічного ланцюга, крос-ланцюг завжди є постійним жорстким попитом. Учасникам проекту Dapp їм потрібно розширити сферу діяльності до якомога більшої кількості ланцюгів, від Dapp з одним ланцюгом до Dapp із повним ланцюгом; для учасників проекту публічного ланцюга кожен має мотивацію поєднати біткойн і Ethereum Square, щоб імпортувати активи та трафік для власної екології; для зашифрованих користувачів вони також сподіваються дозволити їхнім зашифрованим активам подорожувати по різних ланцюгах у децентралізований спосіб, замість того, щоб покладатися на централізовані обміни.
Однак ланцюговий міст, як «транспортний засіб для перевезення готівки» між ланцюгами, неодноразово «грабували». Протягом останніх двох років, майже без винятку, основні проекти міжланцюгових мостів протегували хакерам. Серед усіх типів інцидентів із безпекою шифрування інцидент міжланцюгового мосту очолив список зі збитками майже 2 мільярди доларів США. Щоб вирішити проблему безпеки поперечного ланцюгового мосту, неминуче до цього «відкритого» «грошового носія» додати броню.
Як зламати гру?
Загалом, існує два типи інцидентів безпеки в крос-ланцюжкових мостах: один спричинений лазівками в коді контракту, як-от відсутність перевірки адреси контракту маркера, через що події депозиту підробленої валюти, підроблені зловмисниками, не фільтруються, а інший прикладом є відсутність контролю доступу, що призводить до того, що список набору валідатора було підроблено; іншим є змова вузлів валідатора з метою викрадення приватного ключа, а потім викрадення коштів, заблокованих перехресним мостом або монетним двором фальшиві монети, щоб пограбувати LP.
Основна причина першого полягає в тому, що кодова база міжланцюгового мосту ще не є зрілою, і такі проблеми поступово зменшаться з накопиченням досвіду галузі. Основною причиною останнього є властиві недоліки в конструкції поперечно-ланцюгових мостів.
Перехресний ланцюговий міст по суті вирішує проблему того, як один ланцюг дізнається про події в іншому ланцюзі. Ця проблема поділяється на два аспекти: один – це передача, а інший – перевірка. У міжланцюжковому мості будь-хто може передавати міжланцюгові події, ключовим є те, як цільовий ланцюжок перевіряє, що подія справді сталася у вихідному ланцюжку. **
Відповідно до різних механізмів верифікації міжланцюгові мости поділяються на три типи: нативно перевірені, локально перевірені та зовнішні перевірені.
Вартість нативної перевірки висока, що в основному відображається в двох пунктах. По-перше, висока вартість перевірки в ланцюжку. Запуск легкого клієнта в ланцюжку та виконання SPV перевірки подій споживає багато газу. По-друге, вартість розробки сумісності з новими ланцюгами висока.Для забезпечення сумісності з новим ланцюгом необхідно розробити принаймні одну пару легких клієнтів. У зв’язку з розвитком наративів ZK на ринку в даний час з’явилися рішення для покращення нативної верифікації за допомогою технології ZK, яка може ефективно зменшити вищезазначені витрати.Однак, незалежно від того, наскільки оптимізовано, принаймні одне підтвердження ZK має бути перевірено в ланцюжку, і вартість становить близько 500 тис. Гвей. Для перевірки потрібно лише перевірити підпис (21 тис. Гвей), який є зовсім іншим. Таким чином, рідна перевірка не може отримати перевагу в ціновій конкуренції міжланцюгових мостів і не може реалізувати справжній «повний ланцюг».
Локальну автентифікацію колись використовували відомі проекти, такі як Celer і Connext, але ці проекти, без винятку, змінили свій тон і більше не використовують локальну автентифікацію. Причина полягає в тому, що локальна верифікація транзакцій надзвичайно погана. Незалежно від того, наскільки вона оптимізована, вона завжди вимагає від користувача принаймні двох дій (ініціювання транзакції, розблокування хеш-блокування). Крім того, локальна перевірка застосовна лише до перехресних ланцюжків активів і не може бути розширена до будь-якого перехресного ланцюга повідомлень.
Вартість реалізації зовнішньої верифікації низька, міжланцюгові накладні витрати низькі, її можна легко адаптувати до кількох ланцюжків і підтримує крос-ланцюжок довільних повідомлень. Наразі це рішення прийнято більшістю крос-ланцюжків проекти мостів. Однак зовнішні міжланцюгові мости створюють потенційні ризики змови через впровадження нових припущень про довіру. Більшість перехресних мостів зовнішньої перевірки використовують технологію MPC (захищене багатостороннє обчислення) для фрагментації закритого ключа, щоб кожен зовнішній вузол перевірки міг керувати фрагментом. Порівняно зі звичайною технологією MutiSig (багатопідписів), технологія MPC є більш універсальною (немає вимог до схеми підпису, прийнятої ланцюжком), вартість перевірки нижча (лише один підпис потрібно перевірити в ланцюжку), і це зручно для передачі повноважень підпису (потрібно лише оновити шард, не потрібно змінювати адресу) та інші переваги, але це не змінює суті централізації зовнішньої перевірки та не може запобігти змові.
Отже, яке крос-ланцюгове рішення можна використати для усунення ризику змови та підвищення безпеки крос-ланцюгового мосту без шкоди для продуктивності, масштабованості та універсальності крос-ланцюгового мосту?
Схема мережі BOOL
BOOL Network — це міжланцюговий мостовий продукт, запущений LayerBase Labs. LayerBase Labs проводила дослідження в області крос-ланцюгів протягом майже 4 років, протягом яких вона випустила деякі мінімально життєздатні продукти, але через недосконалість цих продуктів вони не отримали широкого використання. Нещодавно LayerBase Labs запустила перехресний міст на основі динамічного прихованого комітету (DHC): Мережа BOOL Це рішення вважається достатньо досконалим, тому воно готове до представлення громадськості.
Міжланцюгове рішення BOOL Network інтегрує технологію ZK і технологію TEE на основі технології MPC і перетворює зовнішній набір верифікаторів на невідомий і невідомий динамічний прихований комітет, досягаючи високого рівня антизмовних атрибутів, таким чином досягаючи високий ступінь безпеки.
Давайте використаємо приклад, щоб проілюструвати, що таке «динамічний клуб прихованих учасників».
Припустімо, що ви генерал, який командує 1000 солдатами і має наказ охороняти 50 зерносховищ, як ви розставите своїх солдатів?
Якщо припустити, що всі зерносховища однаково важливі, найкращим було б розділити 1000 солдатів на 50 загонів по 20 чоловік у кожному для охорони зерносховища.
Але поділ військ несе в собі приховану небезпеку. Якщо більше половини солдатів у певній команді змовляються, відповідний зерносховище може впасти. Тобто, якщо 11 солдатів у команді змовляються, вони можуть зрадити вас і пограбувати зерносховище. .
Це те, чого ви терпіти не можете.Щоб запобігти подібного роду змови і забезпечити безпеку зерносховища, ви можете вжити наступних заходів:
Таким чином повсталі солдати не знатимуть, з ким вступати в змову. Навіть якщо є заздалегідь домовлені зрадники, вони не можуть контролювати і не можуть знати, чи є зрадники в одній команді.
Якщо припустити, що для забезпечення високої ймовірності успіху змови, зрадник повинен вступити в змову з більшістю всієї вашої команди з 1000 чоловік. Це, безсумнівно, так само важко, як піднятися в небо. За допомогою «динамічних» і «прихованих» методів ви досягаєте надійності кожного загону на рівні всієї команди.
Саме таку схему прийняла мережа BOOL.
TEE - Зав'яжіть очі кожному солдату
Мережа BOOL вимагає, щоб вузли в мережі використовували пристрої TEE для участі в перевірці подій крос-ланцюга. Мережа BOOL є повністю відкритою та доступною, і будь-який суб’єкт із пристроєм TEE може стати вузлом перевірки, зробивши $BOOL.
Повна назва TEE — довірене середовище виконання (Trusted ute Environment). Це обчислювальне середовище, що працює на певному пристрої, яке ізольовано від основної операційної системи, як анклав. Ця ізоляція забезпечується апаратним забезпеченням. Процес виконання програм у TEE прихований, зовнішній світ його не сприймає чи не втручається в нього. Це унеможливлює атаку хакерів.
TEE може запускати програми з високим рівнем безпеки, такі як біометрична автентифікація, безпечне керування платежами тощо. У нашому повсякденному житті TEE не чужий, і перевірка відбитків пальців на мобільних телефонах виконується в TEE. Це може гарантувати, що інші програми мобільного телефону не зможуть отримати інформацію про відбитки пальців під час використання результату перевірки відбитків пальців.
Під час процесу перевірки міжланцюжкових подій зовнішні верифікаційні вузли повинні виконувати підписи консенсусу.У цей час приватний ключ має бути відкритий для мережі, що дуже легко стати об’єктом хакерських атак. Атака на офіційний міст Axie Infinity Ronin Bridge у березні 2022 року та атака на офіційний міст Horizen Bridge публічної мережі Harmony у червні 2022 року були спричинені хакерами, отриманими закритим ключем вузла мосту. Використання TEE для зберігання фрагментів приватного ключа та виконання консенсусних підписів значно покращить безпеку та запобіжить отриманню приватних ключів хакерами. Виходячи з цього, мережа BOOL вимагає, щоб увесь зв’язок між вузлами TEE також був повністю зашифрований, щоб хакери не могли перехопити будь-яку інформацію з вмісту зв’язку між вузлами.
Кільце VRF - Нехай солдати чергуються випадковим чином
Мережа BOOL розроблена як інструмент для створення крос-ланцюжкового мосту, який підтримує будь-яку третю сторону для створення крос-ланцюжкового мосту на ньому. Коли третя сторона створює крос-ланцюжковий міст у мережі BOOL, їй потрібно створити Спочатку DHC (Dynamic Hidden Membership Club). Якщо припустити, що третя сторона хоче, щоб міжланцюговий міст, який вона створює, підтримував 10 ланцюгів, їй потрібно створити 10 DHC, кожен ланцюг відповідає DHC, і всі міжланцюгові повідомлення надсилаються до ланцюга перевіряються DHC.
Кожного разу, коли третя сторона створює перехресний міст через мережу BOOL, буде створено кілька DHC. Оскільки кількість перехресних мостів, створених у мережі BOOL, продовжує збільшуватися, DHC можуть бути тисячі. Третя сторона може встановити порогове значення підпису DHC, і загальні порогові значення підпису: 5 з 9, 13 з 19 і 15 з 21.
Слід зазначити, що учасники в кожному DHC не фіксовані, а постійно змінюються, і кожна епоха перемішується один раз. На основі технології ZK мережа BOOL розробила протокол Ring VRF, який може призначати учасників до кожного DHC абсолютно випадковим чином. Ring VRF згенерує підтвердження ZK для учасників DHC. Це підтвердження ZK представляє тимчасову особу учасників. Учасники DHC використовують тимчасові ідентифікаційні дані для ідентифікації та спілкування один з одним, щоб співпрацювати для виконання певної роботи (наприклад, підпис порогового значення MPC). ; Це забезпечує анонімність учасників DHC як зовні, так і один з одним.
В одній епосі вузли TEE у різних DHC можуть перекриватися, або деякі вузли TEE можуть бути неактивними, не ввійшовши до жодного DHC. Ці ситуації дозволені, але RIng VRF надасть кожному вузлу TEE однакові можливості.
Коротше кажучи, **Завдяки динамічному приховуванню механізму членства комітету BOOL Network створила непорушну чорну скриньку. Якщо вузол TEE знаходиться в робочому стані, ніхто (включно з оператором вузла, іншими вузлами та зовнішніми зловмисниками) не може дізнатися про робочий стан вузла. У якому DHC знаходиться вузол? На тому ж DHC, що й інші вузли? Які консенсусні комунікації мали місце? Які повідомлення підписані? Немає способу дізнатися правду. Це згадані вище «непізнаваність» і «незнання». За такої передумови, поки сама мережа BOOL безпечна, кожен динамічний прихований учасник є безпечним. Щоб забезпечити високу ймовірність успіху атаки, зловмисник повинен оволодіти більшістю вузлів мережі BOOL. Однак, оскільки програми, запущені в TEE, неможливо змінити, зловмисники можуть лише вимкнути мережу та не можуть викрасти активи в мережі.
Як оцінити крос-ланцюгове рішення
Хоча безпека є найбільш актуальною проблемою, яку необхідно вирішити для перехресних ланцюгових мостів, безпека не є єдиним критерієм для оцінки перехресних ланцюгових мостів. Якщо для вирішення проблеми створюється нова проблема, це не є її вирішенням.
LayerBase Labs довго вивчала різні рішення розширення на основі легких клієнтів, включаючи рішення ZK Client. Основний принцип ZK-клієнта полягає в тому, щоб розширити легкий клієнт за допомогою технології ZK, вивести перевірку заголовка блоку та перевірку SPV події вихідного ланцюга поза ланцюжком, створити сертифікат ZK і надіслати його в ланцюжок, і потрібно лише щоб перевірити сертифікат ZK у ланцюжку. Це еквівалентно перевірці заголовків блоків і подій вихідного ланцюга. Хоча ця схема досить безпечна, споживання газу в ланцюжку все ще високе. По-друге, ланцюг ZK під ланцюгом і легкий клієнт на ланцюжок є відносно хорошим з точки зору інженерної реалізації.Складність, яка може призвести до більшої вразливості на рівні коду, таким чином впливаючи на безпеку крос-ланцюжкового мосту. Крім того, щоб уникнути потреби кожного ланцюжка розгортати легкі клієнти всіх інших ланцюгів, це рішення часто має запроваджувати ланцюг ретрансляції (див. малюнок нижче), і існування ланцюга ретрансляції зробить крос-ланцюг, який може бути завершеним за один крок. Процес доставки повідомлення довелося розділити на два етапи, що призвело до збільшення затримки (затримки) міжланцюжкової доставки повідомлення.
У галузі є багато людей, які підтримують технологію ZK Client і навіть стверджують, що ZK Client є найкращим рішенням для міжланцюгових мостів. Ми хочемо сказати, що технології не для показухи, не кажучи вже про моду, а для реального вирішення проблем.Клієнт ZK створює набагато більше проблем, ніж вирішує.
Ми також вивчали так зване рішення Ultra Light Client від LayerZero. LayerZero поміщає легкого клієнта в оракул поза ланцюгом, щоб вирішити проблему накладних витрат газу в ланцюзі, але ви передаєте відповідальність за перевірку верифікатору цілі. chain Враховуючи оракул поза ланцюгом, це вже не рідна перевірка, а зовнішня перевірка, і існує припущення безпеки для оракула поза ланцюгом. Що стосується передумови безпеки, заявленої LayerZero Labs: «Ретранслятор і машина Oracle незалежні одна від одної», вона насправді не існує, і експеримент з атаками L2BEAT Labs підтвердив цю думку.
Ми також помітили оптимістичну схему перевірки, прийняту Nomad і Celer. Додавши роль претендента на основі зовнішньої перевірки, безпеку m-of-n можна успішно покращити до 1-of-n. Хоча ця схема добре задумано, вартість становить приблизно 30 хвилин, що обмежить сферу застосування схеми.
Ми також виявили крутий дизайн Avalanche Bridge, який використовує вузли TEE як зовнішні верифікатори для перевірки крос-чейн подій і забезпечує ефективний і дешевий крос-чейн досвід завдяки мінімалістичному дизайну контракту. Але ми також побачили, що хоча Avalanche Bridge може безпечно зберігати приватний ключ, щоб запобігти зовнішнім зловмисникам, він не може запобігти атаці змови між внутрішніми вузлами TEE.
Зрештою, ми запропонували поточну схему динамічного прихованого комітету BOOL Network. З точки зору безпеки, вона може запобігти зовнішнім атакам хакерів і внутрішній змові. З точки зору продуктивності та досвіду, досвід крос-ланцюжків BOOL Network не є одним із жертвує на основі зовнішньої перевірки та підтримує той самий рівень, що й міст зовнішньої перевірки.
Щоб оцінити міжланцюговий міст, ми вважаємо, що на основі неможливого трикутника його слід розкласти на шість аспектів для комплексної оцінки, а саме вартість (Cost), швидкість (Speed), безпека (Security), зручність використання (Liveness), загальність і Scarablity**.
Можна сказати, що мережа BOOL є шестикутним воїном у перехресному ланцюжковому мосту.
Варто зазначити, що документи про технічні рішення BOOL Network були включені до IEEE TIFS, провідного журналу в галузі криптографії (посилання: Це означає визнання технічних рішень BOOL Network спільнотою криптографів.
Майбутній напрямок
BOOL Network наразі надає безпечну міжланцюгову платформу побудови мостів, і будь-яка третя сторона може створити повну ланцюжкову програму на основі Bool Network. Мережа BOOL стане найнадійнішою базовою підтримкою для всієї ланцюжкової програми.
Дивлячись на це з іншої точки зору, BOOL Network по суті будує децентралізовану машину підпису, яку можна використовувати не лише для перевірки повідомлень у ланцюжку, але й для перевірки повідомлень поза ланцюгом, що означає, що BOOL Network стане безпечною та надійною повноланцюговий оракул. Крім того, децентралізована мережа TEE, створена BOOL Network, також надаватиме конфіденційні обчислювальні послуги в майбутньому.