Мультиланцюжок — це майбутня тенденція розвитку, і прагнення до масштабованості привело Ethereum до створення технології Rollup. У переході на модульні блокчейни увагу знову приділено Lisk. І в недалекому майбутньому до нас дійдуть чутки про зведені програми, L3 та суверенні ланцюжки. Але все це відбуватиметься за рахунок фрагментації, а поточні крос-ланцюгові мости часто мають обмежену функціональність і покладаються на довірених підписувачів для безпеки.
Отже, як зрештою виглядатиме підключений Web3? Ми віримо, що міжланцюгові мости з часом перетворяться на міжланцюговий обмін повідомленнями або протоколи «довільного обміну повідомленнями» (AMP), щоб розблокувати нові сценарії додатків, дозволяючи програмам передавати довільні повідомлення між вихідним ланцюгом і цільовим ланцюгом. Ми також станемо свідками появи «ландшафту механізму довіри», де розробники будуть йти на різні компроміси між зручністю використання, складністю та безпекою.
Кожне рішення AMP має реалізовувати дві ключові функції:
Перевірка: можливість перевірити дійсність повідомлень із вихідного ланцюжка в цільовому ланцюжку
Жвавість: здатність передавати інформацію від вихідного ланцюга до цільового ланцюга
На жаль, 100% надійна перевірка нереалістична, користувачі повинні вибрати довіру коду, теорії ігор, людям (або об’єктам) або їх поєднанню, залежно від того, чи є перевірка в мережі чи поза мережею.
У цій статті ми вертикально розділяємо загальну область взаємодії на механізми, засновані на довірі, і архітектури, засновані на інтеграції.
Механізм довіри:
Код довіри та математика: для цих рішень існує доказ у мережі, який може перевірити кожен. Ці рішення зазвичай покладаються на легких клієнтів для перевірки консенсусу вихідного ланцюга щодо цільового ланцюга або перевірки дійсності переходу стану вихідного ланцюга до цільового ланцюга. Перевірка за допомогою легких клієнтів може підвищити ефективність завдяки доказам із нульовим знанням, стискаючи довільно довгі обчислення, які потрібно виконувати в автономному режимі, одночасно забезпечуючи просту перевірку в ланцюжку для підтвердження результатів обчислень.
Теорія гри довіри: коли користувачеві/додатку потрібно довіряти третій стороні або сторонній мережі, щоб гарантувати автентичність транзакції, застосовуються додаткові припущення про довіру. Безпеку цих механізмів можна покращити, використовуючи мережі без дозволу та теорію ігор, таку як економічні стимули та оптимістичний захист.
Довіра до людей: ці рішення покладаються на чесність або незалежність більшості валідаторів, які передають різну інформацію. Окрім довіри консенсусу двох інтерактивних ланцюжків, вам також потрібно довіряти третій стороні. У цьому випадку єдиний ризик – це репутація суб’єктів-учасників. Транзакція вважається дійсною, якщо достатньо суб’єктів-учасників погоджуються, що вона є дійсною.
Варто зазначити, що всі рішення певною мірою вимагають довіри до коду та людей. Будь-яке рішення з помилковим кодом може бути використане хакерами, і кожне рішення має певний людський елемент у налаштуванні, оновленні або обслуговуванні бази коду.
Інтегрована архітектура:
Модель «точка-точка»: між кожним вихідним ланцюгом і цільовим ланцюгом необхідно встановити спеціальний канал зв’язку.
Модель центрального концентратора: необхідно встановити канал зв’язку з центральним концентратором, щоб досягти взаємозв’язку з усіма іншими блокчейнами, підключеними до концентратора.
Рівнорангову модель відносно важко масштабувати, оскільки для кожного підключеного блокчейну потрібен парний канал зв’язку. Розробка цих каналів може бути складною для блокчейнів із різними консенсусами та фреймворками. Однак спарені мости пропонують більшу гнучкість для налаштування конфігурації за бажанням. Також можливі гібридні підходи, такі як маршрутизація з кількома переходами через ретранслятори з використанням протоколу Inter-Blockchain Communication (IBC), який усуває необхідність прямого однорангового зв’язку, але вносить більше складнощів з точки зору безпеки, затримки та вартість.
Код довіри та математика
Щоб покладатися лише на код/математику для припущень про довіру, легкі клієнти можна використовувати для перевірки консенсусу вихідного ланцюга щодо цільового ланцюга. Легкі клієнти/вузли — це програмне забезпечення, яке підключається до повних вузлів для взаємодії з блокчейном. Легкі клієнти в цільовому ланцюжку зазвичай зберігають історію (в порядку) заголовків блоків вихідного ланцюга, чого достатньо для перевірки транзакцій. Проксі-сервер поза ланцюгом (наприклад, реле) відстежує події у вихідному ланцюжку, генерує криптографічні докази включення та пересилає їх разом із заголовками блоків легким клієнтам у цільовому ланцюжку. Оскільки легкі клієнти зберігають заголовки блоків послідовно, кожен з яких містить кореневий хеш Merkle, який можна використовувати для підтвердження стану, вони можуть перевіряти транзакції. Ось огляд основних особливостей цього підходу:
безпеки
Під час ініціалізації легких клієнтів вводяться припущення довіри. Під час створення нового легкого клієнта його буде ініціалізовано заголовком блоку з певної висоти в іншому ланцюжку. Однак існує ймовірність того, що надані заголовки блоків можуть бути неправильними, що дає можливість обдурити легких клієнтів підробленими заголовками блоків. Після ініціалізації легкого клієнта подальші припущення довіри не вводяться. Однак варто зазначити, що цей процес ініціалізації базується на припущенні про слабку довіру, оскільки його може перевірити будь-хто. Крім того, існує припущення про живучість безперервної передачі інформації реле.
реалізувати
Реалізація легких клієнтів залежить від наявності криптографічних примітивів, необхідних для автентифікації. Якщо з’єднано один і той самий тип ланцюжків, тобто вони спільно використовують ту саму структуру додатків і алгоритм консенсусу, реалізації легкого клієнта на обох кінцях будуть однаковими. Наприклад, усі ланцюжки на основі Cosmos SDK використовують протокол Inter-Blockchain Communication (IBC). З іншого боку, такі реалізації, як полегшені клієнти, залежать від підтримки криптографічних примітивів, необхідних для автентифікації. Якщо з’єднано один і той самий тип ланцюжків, тобто вони спільно використовують ту саму структуру додатків і алгоритм консенсусу, тоді реалізації легкого клієнта з обох сторін будуть однаковими. Наприклад, протокол Inter-Blockchain Communication (IBC) використовується для всіх ланцюжків на основі Cosmos SDK. З іншого боку, якщо з’єднано два різних типи ланцюжків, наприклад різні фреймворки додатків або типи консенсусу, реалізація легкого клієнта буде іншою. Прикладом є компанія Composable Finance, яка працює над підключенням ланцюга Cosmos SDK до фреймворку додатків Substrate екосистеми Polkadot через IBC. Для цього потрібен легкий клієнт Tendermint у ланцюжку Substrate та «сильний» легкий клієнт у ланцюжку Cosmos SDK. Нещодавно вони встановили перший зв’язок між Полкадотом і Кусамою через IBC.
виклик
Важливою проблемою є ресурсомісткість. Запуск пар легких клієнтів у всіх ланцюгах може бути дорогим, оскільки записи в блокчейні дорогі. Крім того, інтенсивність ресурсів із динамічними верифікаторами є важливою проблемою. Запуск спарених легких клієнтів у всіх ланцюгах може бути дорогим, оскільки записи в блокчейні дорогі. Крім того, для ланцюжків із наборами динамічних валідаторів (наприклад, Ethereum) неможливо запускати легкі клієнти.
Масштабованість — ще одна проблема. Реалізація легких клієнтів залежить від архітектури ланцюга, що ускладнює масштабування та підключення різних екосистем.
Уразливості коду є потенційним ризиком, оскільки помилки в коді можуть призвести до вразливостей. Наприклад, злом мережі BNB у жовтні 2022 року виявив критичну помилку в безпеці, яка вплинула на всі мережі з підтримкою IBC.
Щоб зменшити вартість і практичність запуску попарних легких клієнтів у всіх мережах, можна використовувати альтернативні рішення, такі як докази з нульовими знаннями (ZK), щоб усунути потребу в довірі третьої сторони.
Докази з нульовим знанням як рішення для довіри третіх сторін
Докази з нульовим знанням можна використовувати для перевірки дійсності переходів станів вихідного ланцюга на цільовий ланцюг. Порівняно з виконанням усього обчислення в ланцюжку, ZK-докази виконують лише перевірочну частину обчислень у ланцюзі, тоді як фактичне обчислення відбувається поза ланцюгом. Цей підхід забезпечує швидшу та ефективнішу перевірку, ніж повторний запуск вихідного обчислення. Деякі приклади включають Polymer Labs; Polymer ZK-IBC; і Succinct Labs; Telepathy. Polymer розробляє IBC з кількома переходами, щоб покращити підключення та зменшити кількість необхідних парних з’єднань.
Основні аспекти механізму включають:
безпеки
Безпека zk-SNARK покладається на еліптичні криві, тоді як zk-STARK покладається на хеш-функції. Для zk-SNARK може знадобитися довірене налаштування, включаючи створення початкових ключів, які використовуються для створення доказів, які використовуються під час перевірки. Ключ полягає в тому, щоб знищити секрет події налаштування, щоб запобігти автентифікації транзакцій шляхом підробки. Після завершення довіреного налаштування додаткові припущення довіри не вводяться. Крім того, новіші фреймворки ZK (наприклад, Halo та Halo;2;) повністю усувають потребу в довіреній установці.
реалізувати
Існують різноманітні схеми підтвердження ZK, такі як SNARK, STARK, VPD і SNARG, і SNARK зараз є найбільш широко використовуваною. Різні фреймворки перевірки SNARK, такі як Groth;16, Plonk, Marlin, Halo та Halo;2;, пропонують компроміси щодо розміру перевірки, часу перевірки, часу перевірки, вимог до пам’яті та вимог до надійного налаштування. Також з’явилися рекурсивні ZK-докази, що дозволяють розподілити робоче навантаження для перевірки між кількома комп’ютерами, а не одним. Щоб створити докази дійсності, необхідно реалізувати наступні базові примітиви: перевірка схеми підпису, що використовується валідатором, збереження доказів відкритого ключа валідатора в зобов’язанні набору валідатора, що зберігається в ланцюжку, і відстеження набору валідатора, який може часто змінювати.
виклик
Реалізація різних схем підпису в zkSNARK вимагає реалізації арифметики поза доменом і складних операцій еліптичної кривої, що не є тривіальним і може вимагати різних реалізацій залежно від фреймворку та консенсусу різних ланцюжків. Аудит ланцюгів ZK є складним і схильним до помилок завданням. Розробники повинні бути знайомі з предметно-спеціальними мовами, такими як Circom, Cairo та Noir, або безпосередньо впроваджувати схеми, обидві з яких можуть бути складними та сповільнити впровадження. Якщо часу та зусиль виявилося дуже багато, це може виконуватися лише виділеними командами та спеціальним обладнанням, що потенційно може призвести до централізації. Довший час створення доказів також спричиняє затримки. Такі методи, як інкрементально перевірені обчислення (IVC), можуть оптимізувати час перевірки, але багато з них все ще знаходяться на стадії дослідження, очікуючи впровадження. Довший час перевірки та робоче навантаження збільшать витрати на мережу.
Теорія ігор довіри
Протоколи сумісності, засновані на теорії ігор, можна загалом розділити на дві категорії відповідно до того, як вони стимулюють чесну поведінку учасників:
Перша категорія — це механізм економічної безпеки, у якому кілька зовнішніх учасників (наприклад, валідатори) співпрацюють, щоб досягти консенсусу для визначення оновленого стану вихідного ланцюга. Щоб стати валідатором, учасники повинні поставити певну кількість токенів, яка може бути зменшена у разі зловмисної діяльності. У налаштуваннях без дозволу будь-хто може накопичувати ставки та стати валідатором. Крім того, валідаторам, які дотримуються протоколу, надаються економічні стимули, такі як винагороди за блокування, щоб забезпечити економічні стимули для чесної поведінки. Однак, якщо потенційно вкрадена сума перевищує поставлену суму, учасники можуть вступити в змову з метою крадіжки коштів. Приклади протоколів, які використовують економічні механізми безпеки, включають: Axelar і Celer IM.
Друга категорія — це оптимістичні механізми безпеки, де рішення ґрунтується на припущенні, що лише невелика кількість учасників блокчейну є чесними та підкоряються правилам протоколу. При такому підході гарантією виступає чесний учасник. Наприклад, оптимальне рішення дозволяє будь-кому надати докази шахрайства. Хоча є фінансовий стимул, чесний спостерігач може пропустити шахрайську операцію. Optimistic Rollups також використовують цей механізм. Nomad і ChainLink CCIP; приклади протоколів, які використовують оптимістичні механізми безпеки. У випадку Nomad спостерігачі змогли довести шахрайство, хоча на момент написання статті вони були в білому списку. ChainLink CCIP планує використовувати мережу боротьби з шахрайством, яка складається з розподіленої мережі оракулів для виявлення зловмисної діяльності, хоча реалізація мережі CCIP для боротьби з шахрайством невідома.
безпеки
З точки зору безпеки, обидва механізми покладаються на участь верифікаторів і спостерігачів без дозволу для забезпечення теоретико-ігрової валідності. У механізмі економічної безпеки кошти є більш вразливими, якщо поставлена сума нижча за суму, яку можна вкрасти. З іншого боку, в оптимістичних механізмах безпеки можна використати припущення про довіру меншості, якщо ніхто не надасть доказів шахрайства або якщо спостерігачі дозволу скомпрометовані або видалені. Навпаки, механізми економічної безпеки менше залежать від життєдіяльності для підтримки безпеки.
реалізувати
З точки зору реалізації, один підхід передбачає проміжний ланцюжок з власними валідаторами. У цьому налаштуванні група зовнішніх валідаторів контролює вихідний ланцюжок і досягає консенсусу щодо дійсності транзакції, коли виявлено виклик. Після досягнення консенсусу вони надають докази цільового ланцюжка. Від валідаторів зазвичай вимагається поставити певну кількість токенів, яка може бути зменшена, якщо буде виявлено зловмисну активність. Приклади протоколів, які використовують цей метод реалізації, включають Axelar Network і Celer IM.
Інший спосіб реалізації передбачає використання позаланцюжкових проксі. Проксі-сервери поза мережею використовуються для реалізації оптимістичних рішень, подібних до Rollups. Протягом попередньо визначеного часового вікна ці проксі-сервери поза ланцюгом можуть надати докази шахрайства та скасувати транзакції, якщо це необхідно. Наприклад, Nomad покладається на незалежні позамережні проксі для передачі заголовків і криптографічних доказів. З іншого боку, ChainLink CCIP планує використовувати свою існуючу мережу оракулів для моніторингу та підтвердження міжланцюжкових транзакцій.
Сильні сторони та проблеми
Ключовою перевагою теоретико-ігрових рішень AMP є оптимізація ресурсів, оскільки процес перевірки, як правило, відбувається поза мережею, що зменшує потреби в ресурсах. Крім того, ці механізми можна масштабувати, оскільки механізм консенсусу залишається незмінним для різних типів ланцюгів і може бути легко розширений на різнорідні блокчейни.
З цими механізмами також пов’язано кілька проблем. Якщо більшість валідаторів вступає в змову, припущення про довіру можуть бути використані для крадіжки коштів, що потребує контрзаходів, таких як квадратичне голосування та докази шахрайства. Крім того, рішення, засновані на оптимістичній безпеці, створюють складності з точки зору остаточності та живучості, оскільки користувачам і програмам потрібно чекати шахрайських вікон, щоб забезпечити дійсність транзакцій.
Довіряйте людям
Рішення, які вимагають довіри до людських об’єктів, також можна розділити на дві категорії:
Репутаційна безпека: ці рішення покладаються на реалізацію мультипідпису, де кілька суб’єктів перевіряють і підписують транзакції. Після досягнення мінімального порогу транзакція вважається дійсною. Тут припускається, що більшість суб’єктів є чесними, і якщо більшість із цих суб’єктів підпишуть певну транзакцію, тоді ця транзакція є дійсною. Єдине, що тут під загрозою, – це репутація залучених організацій. Деякі приклади: Multichain (Anycall V;6;) і Wormhole. Уразливості все ще можуть існувати через уразливості смарт-контрактів, як продемонстрував злом Wormhole на початку 2022 року.
Незалежність: ці рішення розділяють весь процес обміну повідомленнями на дві частини та покладаються на різні незалежні організації для керування цими двома процесами. Тут припускається, що ці дві організації незалежні одна від одної та не можуть вступати в змову. Прикладом є LayerZero. Заголовки блоків передаються на вимогу через розподілені оракули, а докази транзакцій надсилаються через ретранслятори. Якщо підтвердження відповідає заголовку, транзакція вважається дійсною. Хоча підтвердження відповідності залежить від коду/математики, учасники повинні бути впевнені, що ці сутності залишаються незалежними та не мають злих намірів. Програми, створені на LayerZero, можуть вибирати свої оракули та реле (або розміщувати власні оракули/реле), таким чином обмежуючи ризик для окремих оракулів/реле. Кінцеві користувачі повинні вірити, що LayerZero, треті сторони або сама програма запускають оракули та ретранслюють незалежно, без зловмисних намірів.
В обох підходах репутація залучених сторонніх організацій стримує зловмисну поведінку. Зазвичай це авторитетні організації серед валідаторів і спільноти Oracle, і якщо вони поводяться зловмисно, вони ризикують завдати шкоди репутації та негативно вплинути на іншу бізнес-діяльність.
Додаткові міркування щодо рішень AMP
Розглядаючи безпеку та зручність використання рішення AMP, нам також потрібно враховувати деталі, окрім базової механіки. Оскільки ці компоненти можуть змінюватися з часом, ми не включили їх у загальне порівняння.
цілісність коду
Останні хаки використовували помилки коду, підкреслюючи потребу в надійному аудиті, винагородах за помилки та різноманітних клієнтських реалізаціях. Якщо всі верифікатори (в економічній/оптимістичній/репутаційній безпеці) запускають той самий клієнт (програмне забезпечення для перевірки), це збільшує залежність від єдиної кодової бази та зменшує різноманітність клієнтів. Наприклад, Ethereum покладається на кілька клієнтів виконання, таких як geth, netermind, erigon, besu, akula. Кілька реалізацій на різних мовах можуть збільшити різноманітність, при цьому жоден клієнт не домінує в мережі, усуваючи потенційну єдину точку збою. Наявність кількох клієнтів також може допомогти підтримувати життєдіяльність, якщо невелика кількість валідаторів/підписувачів/легких клієнтів виходить з ладу через помилку/атаку в конкретній реалізації.
Налаштування та можливість оновлення
Користувачі та розробники повинні знати, чи можуть валідатори/спостерігачі приєднуватися до мережі без дозволу, інакше довіра буде прихована особами, які вибирають дозвіл. Оновлення смарт-контрактів також може створити вразливі місця, які можуть призвести до атак і, можливо, навіть змінити припущення про довіру. Щоб зменшити ці ризики, можна застосувати різні рішення. Наприклад, у поточному екземплярі шлюз Axelar можна оновити, але вимагає схвалення офлайн-комітету (порогове значення 4/8), однак у найближчому майбутньому Axelar планує вимагати від усіх валідаторів колективного схвалення будь-яких оновлень шлюзу. Основні контракти Wormhole можна оновлювати та керувати ними через мережеву систему управління Wormhole. LayerZero покладається на незмінні смарт-контракти та незмінні бібліотеки, щоб уникнути будь-яких оновлень, але нові бібліотеки можна надсилати, прикладні програми, які встановлюють параметри за замовчуванням, отримають нові версії, прикладні програми, які встановлюють версію вручну, повинні встановити її на нову версію.
Максимальна видобута вартість (MEV)
Різні блокчейни не синхронізуються загальним годинником і мають різні часи завершення. Таким чином, порядок виконання та час у цільовому ланцюжку можуть відрізнятися від ланцюга до ланцюжка. У міжланцюжковому світі MEV важко чітко визначити. Це вводить компроміс між жвавістю та порядком виконання. Упорядкований канал забезпечить доставку повідомлень у порядку, але якщо повідомлення закінчиться, канал буде закрито. Інша програма може віддати перевагу без замовлення, але це не вплине на доставку інших повідомлень.
надійність ланцюга джерела
В ідеалі рішення AMP повинні чекати, поки вихідний ланцюжок досягне завершеності, перш ніж передавати інформацію про стан вихідного ланцюга в один або кілька цільових ланцюжків. Це забезпечить те, що блоки вихідного ланцюга навряд чи можна скасувати або змінити. Однак багато рішень забезпечують обмін миттєвими повідомленнями та роблять довірчі припущення щодо остаточності, щоб забезпечити найкращу взаємодію з користувачем. У цьому випадку, якщо вихідний ланцюжок піддається відкату стану після того, як повідомлення доставлено та передано мостовий актив, це може призвести до таких ситуацій, як подвійне витрачання коштів мосту. Рішення AMP можуть керувати цим ризиком кількома способами, наприклад, встановлюючи різні припущення щодо завершеності для різних ланцюжків залежно від того, наскільки децентралізовано ланцюжок, або встановлюючи компроміс між швидкістю та безпекою. Місти, які використовують рішення AMP, можуть установлювати обмеження на кількість активів, що передаються до того, як вихідний ланцюжок досягне завершеності.
Тенденції та перспективи на майбутнє Безпека, що налаштовується та підключається
Щоб краще обслуговувати різноманітні випадки використання, рішення AMP стимулюються, щоб надати розробникам більше гнучкості. Axelar представляє метод для забезпечення масштабованості обміну повідомленнями та перевірки без зміни логіки прикладного рівня. HyperLane V2 представляє модулі, які дозволяють розробникам вибирати з кількох варіантів, таких як економічна безпека, оптимістична безпека, динамічна безпека та гібридна безпека. CelerIM забезпечує додаткову оптимістичну безпеку на додаток до економічної безпеки. Багато рішень чекають попередньо визначеної мінімальної кількості підтверджень блокування в вихідному ланцюжку, перш ніж доставити повідомлення. LayerZero дозволяє розробникам оновлювати ці параметри. Ми очікуємо, що деякі рішення AMP і надалі пропонуватимуть більшу гнучкість, але ці варіанти дизайну потребують обговорення. Чи повинні додатки мати можливість налаштовувати свою безпеку, якою мірою та що станеться, якщо архітектура додатків буде неоптимальною? Поінформованість користувачів про фундаментальні концепції безпеки, ймовірно, ставатиме дедалі важливішою. Зрештою, ми передбачаємо агрегацію та абстракцію рішень AMP, можливо, у формі певної форми композиції або «надбудови» безпеки.
Зрілість механізму «Довірчий код і математика».
В ідеальному кінцевому етапі всі міжланцюгові повідомлення будуть зведені до мінімуму завдяки використанню доказів нульового знання (ZK). Ми бачили, як з’являлися подібні проекти, такі як Polymer Labs і Succinct Labs. Multichain також опублікував офіційний документ zkRouter щодо сумісності через ZK-proofs. З нещодавно оголошеною віртуальною машиною Axelar розробники можуть використовувати Interchain Amplifier для встановлення нових з’єднань з мережею Axelar без дозволу. Наприклад, коли для стану Ethereum розроблені клієнти сильного світла та докази ZK, розробники можуть легко інтегрувати їх у мережу Axelar, щоб замінити або покращити існуючі з’єднання. Celer Network анонсувала Brevis, крос-ланцюжкову платформу захисту даних ZK, яка дозволяє dApps і смарт-контрактам отримувати доступ, обчислювати та використовувати довільні дані в кількох блокчейнах. Celer реалізував орієнтований на користувача ресурс zkBridge, використовуючи схему клієнта ZK light для крос-ланцюга між тестовою мережею Ethereum Goerli та тестовою мережею BNB Chain. LayerZero обговорює у своїй документації можливість додавання нових оптимізованих бібліотек доказових повідомлень у майбутньому. Новіші проекти, такі як Lagrange, досліджують агрегування кількох доказів із кількох вихідних ланцюжків, тоді як Геродот робить можливим зберігання доказів за допомогою доказів ZK. Однак цей перехід займе час, оскільки цей підхід важко масштабувати між блокчейнами, які покладаються на різні консенсусні механізми та фреймворки.
ZK є відносно новою та складною технологією, яку важко перевірити, а поточні витрати на перевірку та створення доказів не є оптимальними. Ми вважаємо, що в довгостроковій перспективі для підтримки широкомасштабованих міжланцюжкових додатків на блокчейнах багато рішень AMP, ймовірно, поєднуватимуть верифіковане програмне забезпечення з довіреними людьми та організаціями, оскільки:
Завдяки аудиту та винагородам за помилки можна звести до мінімуму можливість використання коду. З часом довіряти цим системам стане легше, оскільки їхня історія стане доказом їх безпеки.
Зменшиться вартість генерації доказів ZK. Завдяки більшим дослідженням і розробкам ZKP, рекурсивних ZKP, агрегації доказів, схем згортання та спеціалізованого обладнання ми очікуємо, що витрати часу на створення доказів і перевірку суттєво зменшаться, що зробить цей підхід економічно ефективнішим.
Блокчейн стане більш підтримувати ZK. У майбутньому zkEVM зможе надавати стислі докази дійсності виконання, а легкі клієнтські рішення зможуть легко перевіряти виконання вихідного ланцюга та консенсус. На завершальному етапі Ethereum також планується «zk-SNARK все», включаючи механізм консенсусу.
Облікові дані людини, репутація та особистість
Безпека складної системи, як-от рішення AMP, не може бути інкапсульована лише однією структурою, і вимагає багаторівневого рішення. Наприклад, на додаток до економічних стимулів, Axelar реалізує квадратичний механізм голосування, щоб запобігти концентрації прав голосу серед підмножини вузлів і сприяти децентралізації. Інші людські докази, репутація та ідентифікаційні дані також можуть доповнювати механізми налаштування та дозволу.
на закінчення
У відкритому дусі Web3 ми можемо побачити плюралістичне майбутнє, де співіснують численні підходи. Насправді програма може вибрати використання кількох рішень сумісності, або в надлишковому вигляді, або для користувача, щоб вибрати комбінацію на основі компромісів. Між маршрутами з «високим трафіком» рішення «точка-точка» можуть мати пріоритет, тоді як моделі зі спицями можуть домінувати в довгому хвості ланцюга. Зрештою, ми, як спільнота користувачів, розробників і учасників, сформуємо основну форму Інтернету Web3.
Оригінальне посилання
Переглянути оригінал
Контент має виключно довідковий характер і не є запрошенням до участі або пропозицією. Інвестиційні, податкові чи юридичні консультації не надаються. Перегляньте Відмову від відповідальності , щоб дізнатися більше про ризики.
Як поглиблена інтерпретація довільних протоколів обміну повідомленнями вирішує проблему довіри взаємодії?
Автор оригіналу: Ши Кхай Вей, Рагав Агарвал
Оригінальний збірник: Kxp, BlockBeats
Вступ
Мультиланцюжок — це майбутня тенденція розвитку, і прагнення до масштабованості привело Ethereum до створення технології Rollup. У переході на модульні блокчейни увагу знову приділено Lisk. І в недалекому майбутньому до нас дійдуть чутки про зведені програми, L3 та суверенні ланцюжки. Але все це відбуватиметься за рахунок фрагментації, а поточні крос-ланцюгові мости часто мають обмежену функціональність і покладаються на довірених підписувачів для безпеки.
Отже, як зрештою виглядатиме підключений Web3? Ми віримо, що міжланцюгові мости з часом перетворяться на міжланцюговий обмін повідомленнями або протоколи «довільного обміну повідомленнями» (AMP), щоб розблокувати нові сценарії додатків, дозволяючи програмам передавати довільні повідомлення між вихідним ланцюгом і цільовим ланцюгом. Ми також станемо свідками появи «ландшафту механізму довіри», де розробники будуть йти на різні компроміси між зручністю використання, складністю та безпекою.
Кожне рішення AMP має реалізовувати дві ключові функції:
На жаль, 100% надійна перевірка нереалістична, користувачі повинні вибрати довіру коду, теорії ігор, людям (або об’єктам) або їх поєднанню, залежно від того, чи є перевірка в мережі чи поза мережею.
У цій статті ми вертикально розділяємо загальну область взаємодії на механізми, засновані на довірі, і архітектури, засновані на інтеграції.
Механізм довіри:
Код довіри та математика: для цих рішень існує доказ у мережі, який може перевірити кожен. Ці рішення зазвичай покладаються на легких клієнтів для перевірки консенсусу вихідного ланцюга щодо цільового ланцюга або перевірки дійсності переходу стану вихідного ланцюга до цільового ланцюга. Перевірка за допомогою легких клієнтів може підвищити ефективність завдяки доказам із нульовим знанням, стискаючи довільно довгі обчислення, які потрібно виконувати в автономному режимі, одночасно забезпечуючи просту перевірку в ланцюжку для підтвердження результатів обчислень.
Теорія гри довіри: коли користувачеві/додатку потрібно довіряти третій стороні або сторонній мережі, щоб гарантувати автентичність транзакції, застосовуються додаткові припущення про довіру. Безпеку цих механізмів можна покращити, використовуючи мережі без дозволу та теорію ігор, таку як економічні стимули та оптимістичний захист.
Довіра до людей: ці рішення покладаються на чесність або незалежність більшості валідаторів, які передають різну інформацію. Окрім довіри консенсусу двох інтерактивних ланцюжків, вам також потрібно довіряти третій стороні. У цьому випадку єдиний ризик – це репутація суб’єктів-учасників. Транзакція вважається дійсною, якщо достатньо суб’єктів-учасників погоджуються, що вона є дійсною.
Варто зазначити, що всі рішення певною мірою вимагають довіри до коду та людей. Будь-яке рішення з помилковим кодом може бути використане хакерами, і кожне рішення має певний людський елемент у налаштуванні, оновленні або обслуговуванні бази коду.
Інтегрована архітектура:
Модель «точка-точка»: між кожним вихідним ланцюгом і цільовим ланцюгом необхідно встановити спеціальний канал зв’язку.
Модель центрального концентратора: необхідно встановити канал зв’язку з центральним концентратором, щоб досягти взаємозв’язку з усіма іншими блокчейнами, підключеними до концентратора.
Рівнорангову модель відносно важко масштабувати, оскільки для кожного підключеного блокчейну потрібен парний канал зв’язку. Розробка цих каналів може бути складною для блокчейнів із різними консенсусами та фреймворками. Однак спарені мости пропонують більшу гнучкість для налаштування конфігурації за бажанням. Також можливі гібридні підходи, такі як маршрутизація з кількома переходами через ретранслятори з використанням протоколу Inter-Blockchain Communication (IBC), який усуває необхідність прямого однорангового зв’язку, але вносить більше складнощів з точки зору безпеки, затримки та вартість.
Код довіри та математика
Щоб покладатися лише на код/математику для припущень про довіру, легкі клієнти можна використовувати для перевірки консенсусу вихідного ланцюга щодо цільового ланцюга. Легкі клієнти/вузли — це програмне забезпечення, яке підключається до повних вузлів для взаємодії з блокчейном. Легкі клієнти в цільовому ланцюжку зазвичай зберігають історію (в порядку) заголовків блоків вихідного ланцюга, чого достатньо для перевірки транзакцій. Проксі-сервер поза ланцюгом (наприклад, реле) відстежує події у вихідному ланцюжку, генерує криптографічні докази включення та пересилає їх разом із заголовками блоків легким клієнтам у цільовому ланцюжку. Оскільки легкі клієнти зберігають заголовки блоків послідовно, кожен з яких містить кореневий хеш Merkle, який можна використовувати для підтвердження стану, вони можуть перевіряти транзакції. Ось огляд основних особливостей цього підходу:
безпеки
Під час ініціалізації легких клієнтів вводяться припущення довіри. Під час створення нового легкого клієнта його буде ініціалізовано заголовком блоку з певної висоти в іншому ланцюжку. Однак існує ймовірність того, що надані заголовки блоків можуть бути неправильними, що дає можливість обдурити легких клієнтів підробленими заголовками блоків. Після ініціалізації легкого клієнта подальші припущення довіри не вводяться. Однак варто зазначити, що цей процес ініціалізації базується на припущенні про слабку довіру, оскільки його може перевірити будь-хто. Крім того, існує припущення про живучість безперервної передачі інформації реле.
реалізувати
Реалізація легких клієнтів залежить від наявності криптографічних примітивів, необхідних для автентифікації. Якщо з’єднано один і той самий тип ланцюжків, тобто вони спільно використовують ту саму структуру додатків і алгоритм консенсусу, реалізації легкого клієнта на обох кінцях будуть однаковими. Наприклад, усі ланцюжки на основі Cosmos SDK використовують протокол Inter-Blockchain Communication (IBC). З іншого боку, такі реалізації, як полегшені клієнти, залежать від підтримки криптографічних примітивів, необхідних для автентифікації. Якщо з’єднано один і той самий тип ланцюжків, тобто вони спільно використовують ту саму структуру додатків і алгоритм консенсусу, тоді реалізації легкого клієнта з обох сторін будуть однаковими. Наприклад, протокол Inter-Blockchain Communication (IBC) використовується для всіх ланцюжків на основі Cosmos SDK. З іншого боку, якщо з’єднано два різних типи ланцюжків, наприклад різні фреймворки додатків або типи консенсусу, реалізація легкого клієнта буде іншою. Прикладом є компанія Composable Finance, яка працює над підключенням ланцюга Cosmos SDK до фреймворку додатків Substrate екосистеми Polkadot через IBC. Для цього потрібен легкий клієнт Tendermint у ланцюжку Substrate та «сильний» легкий клієнт у ланцюжку Cosmos SDK. Нещодавно вони встановили перший зв’язок між Полкадотом і Кусамою через IBC.
виклик
Важливою проблемою є ресурсомісткість. Запуск пар легких клієнтів у всіх ланцюгах може бути дорогим, оскільки записи в блокчейні дорогі. Крім того, інтенсивність ресурсів із динамічними верифікаторами є важливою проблемою. Запуск спарених легких клієнтів у всіх ланцюгах може бути дорогим, оскільки записи в блокчейні дорогі. Крім того, для ланцюжків із наборами динамічних валідаторів (наприклад, Ethereum) неможливо запускати легкі клієнти.
Масштабованість — ще одна проблема. Реалізація легких клієнтів залежить від архітектури ланцюга, що ускладнює масштабування та підключення різних екосистем.
Уразливості коду є потенційним ризиком, оскільки помилки в коді можуть призвести до вразливостей. Наприклад, злом мережі BNB у жовтні 2022 року виявив критичну помилку в безпеці, яка вплинула на всі мережі з підтримкою IBC.
Щоб зменшити вартість і практичність запуску попарних легких клієнтів у всіх мережах, можна використовувати альтернативні рішення, такі як докази з нульовими знаннями (ZK), щоб усунути потребу в довірі третьої сторони.
Докази з нульовим знанням як рішення для довіри третіх сторін
Докази з нульовим знанням можна використовувати для перевірки дійсності переходів станів вихідного ланцюга на цільовий ланцюг. Порівняно з виконанням усього обчислення в ланцюжку, ZK-докази виконують лише перевірочну частину обчислень у ланцюзі, тоді як фактичне обчислення відбувається поза ланцюгом. Цей підхід забезпечує швидшу та ефективнішу перевірку, ніж повторний запуск вихідного обчислення. Деякі приклади включають Polymer Labs; Polymer ZK-IBC; і Succinct Labs; Telepathy. Polymer розробляє IBC з кількома переходами, щоб покращити підключення та зменшити кількість необхідних парних з’єднань.
Основні аспекти механізму включають:
безпеки
Безпека zk-SNARK покладається на еліптичні криві, тоді як zk-STARK покладається на хеш-функції. Для zk-SNARK може знадобитися довірене налаштування, включаючи створення початкових ключів, які використовуються для створення доказів, які використовуються під час перевірки. Ключ полягає в тому, щоб знищити секрет події налаштування, щоб запобігти автентифікації транзакцій шляхом підробки. Після завершення довіреного налаштування додаткові припущення довіри не вводяться. Крім того, новіші фреймворки ZK (наприклад, Halo та Halo;2;) повністю усувають потребу в довіреній установці.
реалізувати
Існують різноманітні схеми підтвердження ZK, такі як SNARK, STARK, VPD і SNARG, і SNARK зараз є найбільш широко використовуваною. Різні фреймворки перевірки SNARK, такі як Groth;16, Plonk, Marlin, Halo та Halo;2;, пропонують компроміси щодо розміру перевірки, часу перевірки, часу перевірки, вимог до пам’яті та вимог до надійного налаштування. Також з’явилися рекурсивні ZK-докази, що дозволяють розподілити робоче навантаження для перевірки між кількома комп’ютерами, а не одним. Щоб створити докази дійсності, необхідно реалізувати наступні базові примітиви: перевірка схеми підпису, що використовується валідатором, збереження доказів відкритого ключа валідатора в зобов’язанні набору валідатора, що зберігається в ланцюжку, і відстеження набору валідатора, який може часто змінювати.
виклик
Реалізація різних схем підпису в zkSNARK вимагає реалізації арифметики поза доменом і складних операцій еліптичної кривої, що не є тривіальним і може вимагати різних реалізацій залежно від фреймворку та консенсусу різних ланцюжків. Аудит ланцюгів ZK є складним і схильним до помилок завданням. Розробники повинні бути знайомі з предметно-спеціальними мовами, такими як Circom, Cairo та Noir, або безпосередньо впроваджувати схеми, обидві з яких можуть бути складними та сповільнити впровадження. Якщо часу та зусиль виявилося дуже багато, це може виконуватися лише виділеними командами та спеціальним обладнанням, що потенційно може призвести до централізації. Довший час створення доказів також спричиняє затримки. Такі методи, як інкрементально перевірені обчислення (IVC), можуть оптимізувати час перевірки, але багато з них все ще знаходяться на стадії дослідження, очікуючи впровадження. Довший час перевірки та робоче навантаження збільшать витрати на мережу.
Теорія ігор довіри
Протоколи сумісності, засновані на теорії ігор, можна загалом розділити на дві категорії відповідно до того, як вони стимулюють чесну поведінку учасників:
Перша категорія — це механізм економічної безпеки, у якому кілька зовнішніх учасників (наприклад, валідатори) співпрацюють, щоб досягти консенсусу для визначення оновленого стану вихідного ланцюга. Щоб стати валідатором, учасники повинні поставити певну кількість токенів, яка може бути зменшена у разі зловмисної діяльності. У налаштуваннях без дозволу будь-хто може накопичувати ставки та стати валідатором. Крім того, валідаторам, які дотримуються протоколу, надаються економічні стимули, такі як винагороди за блокування, щоб забезпечити економічні стимули для чесної поведінки. Однак, якщо потенційно вкрадена сума перевищує поставлену суму, учасники можуть вступити в змову з метою крадіжки коштів. Приклади протоколів, які використовують економічні механізми безпеки, включають: Axelar і Celer IM.
Друга категорія — це оптимістичні механізми безпеки, де рішення ґрунтується на припущенні, що лише невелика кількість учасників блокчейну є чесними та підкоряються правилам протоколу. При такому підході гарантією виступає чесний учасник. Наприклад, оптимальне рішення дозволяє будь-кому надати докази шахрайства. Хоча є фінансовий стимул, чесний спостерігач може пропустити шахрайську операцію. Optimistic Rollups також використовують цей механізм. Nomad і ChainLink CCIP; приклади протоколів, які використовують оптимістичні механізми безпеки. У випадку Nomad спостерігачі змогли довести шахрайство, хоча на момент написання статті вони були в білому списку. ChainLink CCIP планує використовувати мережу боротьби з шахрайством, яка складається з розподіленої мережі оракулів для виявлення зловмисної діяльності, хоча реалізація мережі CCIP для боротьби з шахрайством невідома.
безпеки
З точки зору безпеки, обидва механізми покладаються на участь верифікаторів і спостерігачів без дозволу для забезпечення теоретико-ігрової валідності. У механізмі економічної безпеки кошти є більш вразливими, якщо поставлена сума нижча за суму, яку можна вкрасти. З іншого боку, в оптимістичних механізмах безпеки можна використати припущення про довіру меншості, якщо ніхто не надасть доказів шахрайства або якщо спостерігачі дозволу скомпрометовані або видалені. Навпаки, механізми економічної безпеки менше залежать від життєдіяльності для підтримки безпеки.
реалізувати
З точки зору реалізації, один підхід передбачає проміжний ланцюжок з власними валідаторами. У цьому налаштуванні група зовнішніх валідаторів контролює вихідний ланцюжок і досягає консенсусу щодо дійсності транзакції, коли виявлено виклик. Після досягнення консенсусу вони надають докази цільового ланцюжка. Від валідаторів зазвичай вимагається поставити певну кількість токенів, яка може бути зменшена, якщо буде виявлено зловмисну активність. Приклади протоколів, які використовують цей метод реалізації, включають Axelar Network і Celer IM.
Інший спосіб реалізації передбачає використання позаланцюжкових проксі. Проксі-сервери поза мережею використовуються для реалізації оптимістичних рішень, подібних до Rollups. Протягом попередньо визначеного часового вікна ці проксі-сервери поза ланцюгом можуть надати докази шахрайства та скасувати транзакції, якщо це необхідно. Наприклад, Nomad покладається на незалежні позамережні проксі для передачі заголовків і криптографічних доказів. З іншого боку, ChainLink CCIP планує використовувати свою існуючу мережу оракулів для моніторингу та підтвердження міжланцюжкових транзакцій.
Сильні сторони та проблеми
Ключовою перевагою теоретико-ігрових рішень AMP є оптимізація ресурсів, оскільки процес перевірки, як правило, відбувається поза мережею, що зменшує потреби в ресурсах. Крім того, ці механізми можна масштабувати, оскільки механізм консенсусу залишається незмінним для різних типів ланцюгів і може бути легко розширений на різнорідні блокчейни.
З цими механізмами також пов’язано кілька проблем. Якщо більшість валідаторів вступає в змову, припущення про довіру можуть бути використані для крадіжки коштів, що потребує контрзаходів, таких як квадратичне голосування та докази шахрайства. Крім того, рішення, засновані на оптимістичній безпеці, створюють складності з точки зору остаточності та живучості, оскільки користувачам і програмам потрібно чекати шахрайських вікон, щоб забезпечити дійсність транзакцій.
Довіряйте людям
Рішення, які вимагають довіри до людських об’єктів, також можна розділити на дві категорії:
Репутаційна безпека: ці рішення покладаються на реалізацію мультипідпису, де кілька суб’єктів перевіряють і підписують транзакції. Після досягнення мінімального порогу транзакція вважається дійсною. Тут припускається, що більшість суб’єктів є чесними, і якщо більшість із цих суб’єктів підпишуть певну транзакцію, тоді ця транзакція є дійсною. Єдине, що тут під загрозою, – це репутація залучених організацій. Деякі приклади: Multichain (Anycall V;6;) і Wormhole. Уразливості все ще можуть існувати через уразливості смарт-контрактів, як продемонстрував злом Wormhole на початку 2022 року.
Незалежність: ці рішення розділяють весь процес обміну повідомленнями на дві частини та покладаються на різні незалежні організації для керування цими двома процесами. Тут припускається, що ці дві організації незалежні одна від одної та не можуть вступати в змову. Прикладом є LayerZero. Заголовки блоків передаються на вимогу через розподілені оракули, а докази транзакцій надсилаються через ретранслятори. Якщо підтвердження відповідає заголовку, транзакція вважається дійсною. Хоча підтвердження відповідності залежить від коду/математики, учасники повинні бути впевнені, що ці сутності залишаються незалежними та не мають злих намірів. Програми, створені на LayerZero, можуть вибирати свої оракули та реле (або розміщувати власні оракули/реле), таким чином обмежуючи ризик для окремих оракулів/реле. Кінцеві користувачі повинні вірити, що LayerZero, треті сторони або сама програма запускають оракули та ретранслюють незалежно, без зловмисних намірів.
В обох підходах репутація залучених сторонніх організацій стримує зловмисну поведінку. Зазвичай це авторитетні організації серед валідаторів і спільноти Oracle, і якщо вони поводяться зловмисно, вони ризикують завдати шкоди репутації та негативно вплинути на іншу бізнес-діяльність.
Додаткові міркування щодо рішень AMP
Розглядаючи безпеку та зручність використання рішення AMP, нам також потрібно враховувати деталі, окрім базової механіки. Оскільки ці компоненти можуть змінюватися з часом, ми не включили їх у загальне порівняння.
цілісність коду
Останні хаки використовували помилки коду, підкреслюючи потребу в надійному аудиті, винагородах за помилки та різноманітних клієнтських реалізаціях. Якщо всі верифікатори (в економічній/оптимістичній/репутаційній безпеці) запускають той самий клієнт (програмне забезпечення для перевірки), це збільшує залежність від єдиної кодової бази та зменшує різноманітність клієнтів. Наприклад, Ethereum покладається на кілька клієнтів виконання, таких як geth, netermind, erigon, besu, akula. Кілька реалізацій на різних мовах можуть збільшити різноманітність, при цьому жоден клієнт не домінує в мережі, усуваючи потенційну єдину точку збою. Наявність кількох клієнтів також може допомогти підтримувати життєдіяльність, якщо невелика кількість валідаторів/підписувачів/легких клієнтів виходить з ладу через помилку/атаку в конкретній реалізації.
Налаштування та можливість оновлення
Користувачі та розробники повинні знати, чи можуть валідатори/спостерігачі приєднуватися до мережі без дозволу, інакше довіра буде прихована особами, які вибирають дозвіл. Оновлення смарт-контрактів також може створити вразливі місця, які можуть призвести до атак і, можливо, навіть змінити припущення про довіру. Щоб зменшити ці ризики, можна застосувати різні рішення. Наприклад, у поточному екземплярі шлюз Axelar можна оновити, але вимагає схвалення офлайн-комітету (порогове значення 4/8), однак у найближчому майбутньому Axelar планує вимагати від усіх валідаторів колективного схвалення будь-яких оновлень шлюзу. Основні контракти Wormhole можна оновлювати та керувати ними через мережеву систему управління Wormhole. LayerZero покладається на незмінні смарт-контракти та незмінні бібліотеки, щоб уникнути будь-яких оновлень, але нові бібліотеки можна надсилати, прикладні програми, які встановлюють параметри за замовчуванням, отримають нові версії, прикладні програми, які встановлюють версію вручну, повинні встановити її на нову версію.
Максимальна видобута вартість (MEV)
Різні блокчейни не синхронізуються загальним годинником і мають різні часи завершення. Таким чином, порядок виконання та час у цільовому ланцюжку можуть відрізнятися від ланцюга до ланцюжка. У міжланцюжковому світі MEV важко чітко визначити. Це вводить компроміс між жвавістю та порядком виконання. Упорядкований канал забезпечить доставку повідомлень у порядку, але якщо повідомлення закінчиться, канал буде закрито. Інша програма може віддати перевагу без замовлення, але це не вплине на доставку інших повідомлень.
надійність ланцюга джерела
В ідеалі рішення AMP повинні чекати, поки вихідний ланцюжок досягне завершеності, перш ніж передавати інформацію про стан вихідного ланцюга в один або кілька цільових ланцюжків. Це забезпечить те, що блоки вихідного ланцюга навряд чи можна скасувати або змінити. Однак багато рішень забезпечують обмін миттєвими повідомленнями та роблять довірчі припущення щодо остаточності, щоб забезпечити найкращу взаємодію з користувачем. У цьому випадку, якщо вихідний ланцюжок піддається відкату стану після того, як повідомлення доставлено та передано мостовий актив, це може призвести до таких ситуацій, як подвійне витрачання коштів мосту. Рішення AMP можуть керувати цим ризиком кількома способами, наприклад, встановлюючи різні припущення щодо завершеності для різних ланцюжків залежно від того, наскільки децентралізовано ланцюжок, або встановлюючи компроміс між швидкістю та безпекою. Місти, які використовують рішення AMP, можуть установлювати обмеження на кількість активів, що передаються до того, як вихідний ланцюжок досягне завершеності.
Тенденції та перспективи на майбутнє Безпека, що налаштовується та підключається
Щоб краще обслуговувати різноманітні випадки використання, рішення AMP стимулюються, щоб надати розробникам більше гнучкості. Axelar представляє метод для забезпечення масштабованості обміну повідомленнями та перевірки без зміни логіки прикладного рівня. HyperLane V2 представляє модулі, які дозволяють розробникам вибирати з кількох варіантів, таких як економічна безпека, оптимістична безпека, динамічна безпека та гібридна безпека. CelerIM забезпечує додаткову оптимістичну безпеку на додаток до економічної безпеки. Багато рішень чекають попередньо визначеної мінімальної кількості підтверджень блокування в вихідному ланцюжку, перш ніж доставити повідомлення. LayerZero дозволяє розробникам оновлювати ці параметри. Ми очікуємо, що деякі рішення AMP і надалі пропонуватимуть більшу гнучкість, але ці варіанти дизайну потребують обговорення. Чи повинні додатки мати можливість налаштовувати свою безпеку, якою мірою та що станеться, якщо архітектура додатків буде неоптимальною? Поінформованість користувачів про фундаментальні концепції безпеки, ймовірно, ставатиме дедалі важливішою. Зрештою, ми передбачаємо агрегацію та абстракцію рішень AMP, можливо, у формі певної форми композиції або «надбудови» безпеки.
Зрілість механізму «Довірчий код і математика».
В ідеальному кінцевому етапі всі міжланцюгові повідомлення будуть зведені до мінімуму завдяки використанню доказів нульового знання (ZK). Ми бачили, як з’являлися подібні проекти, такі як Polymer Labs і Succinct Labs. Multichain також опублікував офіційний документ zkRouter щодо сумісності через ZK-proofs. З нещодавно оголошеною віртуальною машиною Axelar розробники можуть використовувати Interchain Amplifier для встановлення нових з’єднань з мережею Axelar без дозволу. Наприклад, коли для стану Ethereum розроблені клієнти сильного світла та докази ZK, розробники можуть легко інтегрувати їх у мережу Axelar, щоб замінити або покращити існуючі з’єднання. Celer Network анонсувала Brevis, крос-ланцюжкову платформу захисту даних ZK, яка дозволяє dApps і смарт-контрактам отримувати доступ, обчислювати та використовувати довільні дані в кількох блокчейнах. Celer реалізував орієнтований на користувача ресурс zkBridge, використовуючи схему клієнта ZK light для крос-ланцюга між тестовою мережею Ethereum Goerli та тестовою мережею BNB Chain. LayerZero обговорює у своїй документації можливість додавання нових оптимізованих бібліотек доказових повідомлень у майбутньому. Новіші проекти, такі як Lagrange, досліджують агрегування кількох доказів із кількох вихідних ланцюжків, тоді як Геродот робить можливим зберігання доказів за допомогою доказів ZK. Однак цей перехід займе час, оскільки цей підхід важко масштабувати між блокчейнами, які покладаються на різні консенсусні механізми та фреймворки.
ZK є відносно новою та складною технологією, яку важко перевірити, а поточні витрати на перевірку та створення доказів не є оптимальними. Ми вважаємо, що в довгостроковій перспективі для підтримки широкомасштабованих міжланцюжкових додатків на блокчейнах багато рішень AMP, ймовірно, поєднуватимуть верифіковане програмне забезпечення з довіреними людьми та організаціями, оскільки:
Завдяки аудиту та винагородам за помилки можна звести до мінімуму можливість використання коду. З часом довіряти цим системам стане легше, оскільки їхня історія стане доказом їх безпеки.
Зменшиться вартість генерації доказів ZK. Завдяки більшим дослідженням і розробкам ZKP, рекурсивних ZKP, агрегації доказів, схем згортання та спеціалізованого обладнання ми очікуємо, що витрати часу на створення доказів і перевірку суттєво зменшаться, що зробить цей підхід економічно ефективнішим.
Блокчейн стане більш підтримувати ZK. У майбутньому zkEVM зможе надавати стислі докази дійсності виконання, а легкі клієнтські рішення зможуть легко перевіряти виконання вихідного ланцюга та консенсус. На завершальному етапі Ethereum також планується «zk-SNARK все», включаючи механізм консенсусу.
Облікові дані людини, репутація та особистість
Безпека складної системи, як-от рішення AMP, не може бути інкапсульована лише однією структурою, і вимагає багаторівневого рішення. Наприклад, на додаток до економічних стимулів, Axelar реалізує квадратичний механізм голосування, щоб запобігти концентрації прав голосу серед підмножини вузлів і сприяти децентралізації. Інші людські докази, репутація та ідентифікаційні дані також можуть доповнювати механізми налаштування та дозволу.
на закінчення
У відкритому дусі Web3 ми можемо побачити плюралістичне майбутнє, де співіснують численні підходи. Насправді програма може вибрати використання кількох рішень сумісності, або в надлишковому вигляді, або для користувача, щоб вибрати комбінацію на основі компромісів. Між маршрутами з «високим трафіком» рішення «точка-точка» можуть мати пріоритет, тоді як моделі зі спицями можуть домінувати в довгому хвості ланцюга. Зрештою, ми, як спільнота користувачів, розробників і учасників, сформуємо основну форму Інтернету Web3.
Оригінальне посилання