Автор: STANFORD BLOCKCHAIN ​​​​CLUB. Упорядник: Cointime: QDD.

вступ

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

Як виглядатиме кінцева форма взаємозв’язку в Інтернеті 3.0? Ми віримо, що з часом мости перетворяться на міжланцюговий обмін повідомленнями або протоколи довільної передачі повідомлень (AMP), щоб розблокувати нові випадки використання, дозволяючи програмам передавати довільні повідомлення між вихідним і цільовим ланцюгами. Ми також побачимо зростання «ландшафту довіри», де будівельники йдуть на різноманітні компроміси щодо простоти використання, складності та безпеки.

Кожне рішення AMP вимагає двох ключових можливостей:

1. Перевірка: Перевірте дійсність повідомлення вихідного ланцюжка в цільовому ланцюжку.

2. Живучість: здатність передавати інформацію від вихідного ланцюга до цільового ланцюга.

На жаль, 100% надійна перевірка нереальна, і користувачам потрібно довіряти коду, теорії ігор, людям (або об’єктам) або їх комбінації, залежно від того, чи перевірка відбувається в ланцюзі чи поза ланцюгом.

У цій статті ми розділимо загальний ландшафт взаємодії по вертикалі та горизонталі на основі механізмів довіри та використаної архітектури інтеграції.

Механізм довіри:

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

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

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

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

Інтегрована архітектура:

1. Однорангова модель: між кожним вихідним ланцюгом і кожним цільовим ланцюгом необхідно встановити спеціальний канал зв’язку.

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

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

Код довіри та математика

Щоб покладатися лише на код/математику для припущень довіри, легкий клієнт може бути використаний для перевірки консенсусу вихідного ланцюга щодо цільового ланцюга. Легкий клієнт/вузол — це частина програмного забезпечення, яка підключається до повного вузла для взаємодії з блокчейном. Легкі клієнти в цільовому ланцюжку зазвичай зберігають заголовки блоків вихідного ланцюга (в порядку), яких достатньо для перевірки транзакцій. Подібним чином агенти поза ланцюгом (такі як ретранслятори) у вихідному ланцюжку відстежують події, генерують криптографічні докази включення та пересилають їх разом із заголовками блоків легким клієнтам у цільовому ланцюзі. Оскільки легкі клієнти зберігають заголовки блоків у порядку, вони можуть перевіряти транзакції, оскільки кожен заголовок блоку містить кореневий хеш Merkle, який використовується для підтвердження стану. Нижче наведено огляд ключових особливостей цього підходу.

безпеки

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

виконати

Реалізація легкого клієнта залежить від наявності криптографічних примітивів, необхідних для автентифікації. Якщо ви підключаєтеся до одного типу ланцюга, тобто вони спільно використовують ту саму структуру додатків і алгоритм консенсусу, тоді реалізації легких клієнтів обох сторін будуть однаковими. Наприклад, усі ланцюжки на основі Cosmos SDK використовують протокол Inter-Blockchain Communication (IBC). З іншого боку, якщо з’єднано два різних типи ланцюжків, наприклад різні фреймворки додатків або типи консенсусу, реалізація легкого клієнта буде іншою. Одним із прикладів є компанія Composable Finance, яка працює над підключенням ланцюга Cosmos SDK до Substrate екосистеми Polkadot через IBC. Для цього потрібно додати легкий клієнт Tendermint у ланцюжок Substrate та «потужний» легкий клієнт у ланцюг Cosmos SDK. Нещодавно вони встановили перший зв’язок між Полкадотом і Кусамою через IBC.

виклик

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

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

Експлуатація коду є потенційним ризиком, оскільки помилки в коді можуть призвести до вразливостей. Одним із прикладів є вразливість ланцюжка BNB у жовтні 2022 року, яка виявила критичну вразливість у безпеці, що впливає на всі ланцюжки з підтримкою IBC [1].

Щоб зменшити вартість і практичність роботи пар легких клієнтів у всіх мережах, альтернативи, такі як докази з нульовим знанням (ZK), забезпечують спосіб усунути довіру до третіх сторін.

Докази з нульовим знанням як рішення для довіри третіх сторін

Доказ ZK можна використовувати для перевірки дійсності переходу стану вихідного ланцюга на цільовий ланцюг. Замість того, щоб виконувати всі обчислення в ланцюжку, краще виконати лише перевірку обчислень у ланцюжку, а фактичний процес обчислень вивести за межі ланцюжка. Цей метод є швидшим і дешевшим, ніж повторне виконання початкового розрахунку. Деякі приклади включають Polymer ZK-IBC від Polymer Labs і Telepathy від Succinct Labs. Polymer розробляє IBC з підтримкою кількох переходів, щоб покращити підключення та зменшити кількість необхідних парних з’єднань.

Основні аспекти механізму включають:

безпеки

Безпека zk-SNARK покладається на еліптичні криві, тоді як zk-STARK покладається на хеш-функції. Для zk-SNARK може знадобитися довірений процес налаштування, у якому створюються початкові ключі для доказів, які використовуються під час перевірки. Вкрай важливо зберігати секретність ключа для події налаштування знищення, щоб запобігти транзакціям через підроблену перевірку. Після завершення довіреного налаштування додаткові припущення довіри не вводяться. Крім того, нові фреймворки ZK, такі як Halo та Halo2, повністю усувають потребу в довіреній установці.

виконати

Існують різні схеми перевірки ZK, такі як SNARK, STARK, VPD і SNARG, і найбільш широко використовуваною на даний момент є SNARK. Різні фреймворки перевірки SNARK, такі як Groth16, Plonk, Marlin, Halo та Halo2, мають компроміси щодо розміру перевірки, часу перевірки, часу перевірки, вимог до пам’яті та необхідності надійного налаштування. Також з’явилися рекурсивні ZK-докази, що дозволяють розподіляти робочі навантаження для підтвердження на кількох комп’ютерах, а не лише на одному. Щоб створити підтвердження дійсності, необхідно реалізувати такі базові примітиви: перевірити схему підпису, що використовується валідатором, включити підтвердження відкритого ключа валідатора в зобов’язання набору валідатора, що зберігається в ланцюжку, і відстежувати набір валідатора , які можуть Зміни відбуваються часто.

виклик

Реалізація різних схем підпису в zkSNARK вимагає реалізації арифметики поза доменом і складних операцій еліптичної кривої, що непросто і може вимагати різних реалізацій для кожного ланцюга на основі структури ланцюга та консенсусу. Аудит ланцюгів ZK є складним і схильним до помилок завданням. Розробники повинні бути знайомі з предметно-спеціальними мовами, такими як Circom, Cairo та Noir, або просто реалізувати схеми самостійно, обидві з яких можуть бути складними та потенційно повільними. Якщо часу та зусиль виявиться дуже багато, лише спеціальна команда зі спеціальним апаратним забезпеченням зможе впоратися з цим, що може призвести до централізації. Довший час створення доказів також спричиняє затримки. Такі методи, як Інкрементальне перевірене обчислення (IVC), можуть оптимізувати час перевірки, але багато з них все ще знаходяться на стадії дослідження, очікуючи впровадження. Довший час і зусилля на перевірку збільшать витрати на мережу.

теорія ігор довіри

Протоколи сумісності, засновані на теорії ігор, можна загалом розділити на дві категорії залежно від того, як вони стимулюють чесну поведінку учасників:

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

Друга категорія — це оптимістична безпека, де рішення базуються на припущенні, що лише кілька учасників блокчейну є чесними та дотримуються правил протоколу. При такому підході гарантією виступає єдиний чесний учасник. Наприклад, оптимальне рішення дозволяє будь-кому надати докази шахрайства. Хоча є фінансовий стимул, чесні спостерігачі можуть пропустити шахрайські операції. Optimistic Roll-up також використовує цей механізм. Nomad і ChainLink CCIP є прикладами протоколів, які використовують оптимістичну безпеку. У випадку з Nomad спостерігачам вдалося довести шахрайство, хоча вони були в білому списку на момент написання статті. ChainLink CCIP планує використовувати мережу боротьби з шахрайством, що складається з децентралізованої мережі Oracle для моніторингу зловмисної діяльності, хоча реалізація мережі боротьби з шахрайством CCIP ще невідома.

безпеки

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

реалізувати

З точки зору реалізації, один підхід передбачає проміжний ланцюжок з власними валідаторами. У цьому налаштуванні набір зовнішніх валідаторів відстежує вихідний ланцюжок і досягає консенсусу щодо дійсності транзакції, коли виявлено виклик. Після досягнення консенсусу вони надають доказ у цільовому ланцюжку. Від валідаторів зазвичай вимагається ставка певної кількості токенів, яка може бути скорочена, якщо буде виявлено зловмисну ​​активність. Приклади протоколів, які використовують цей метод реалізації, включають Axelar Network і Celer IM.

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

Переваги та проблеми

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

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

довіряти людям

Рішення, які потребують довіри до людських об’єктів, також можна розділити на дві категорії:

1. Безпека репутації: ці рішення покладаються на реалізацію мультипідпису, де кілька суб’єктів перевіряють і підписують транзакції. Після досягнення мінімального порогу транзакція вважається дійсною. Припущення полягає в тому, що більшість суб’єктів є чесними, і якщо більшість із цих суб’єктів підпишуть певну транзакцію, вона є дійсною. Деякі приклади включають Multichain (Anycall V6) і Wormhole. Уразливості смарт-контрактів все ще можна використати, як продемонстрував злом Wormhole на початку 2022 року.

2. Незалежність: ці рішення розділяють весь процес обміну повідомленнями на дві частини та покладаються на різні незалежні організації для керування цими двома процесами. Тут припускається, що дві організації незалежні одна від одної і не можуть вступати в змову. Прикладом є LayerZero. Заголовки блоків можуть передаватися на вимогу децентралізованими оракулами, а докази транзакцій надсилаються через ретранслятори. Якщо підтвердження відповідає заголовку блоку, транзакція вважається дійсною. Хоча підтвердження відповідності залежить від коду/математики, учасники повинні вірити, що ці сутності можуть залишатися незалежними. Програми, створені на LayerZero, можуть вибирати свої оракули та ретранслятори (або розміщувати власні оракули/ретранслятори), обмежуючи ризик змови окремих оракулів/ретрансляторів. Кінцеві користувачі повинні бути впевнені, що LayerZero, треті сторони або самі програми запускають оракули та реле незалежно один від одного і не мають зловмисних намірів.

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

Припущення поза довірою: додаткові міркування щодо рішень AMP

Розглядаючи безпеку та зручність використання рішення AMP, нам також потрібно враховувати деталі, окрім базової механіки. Оскільки це рухомі частини, які можуть змінюватися з часом, ми не включили їх у загальне порівняння.

цілісність коду

Нещодавні хаки, що використовують помилки кодування, підкреслюють необхідність надійного аудиту, винагород за помилки та різноманітних клієнтських реалізацій. Якщо всі валідатори (в економічній/оптимістичній/репутаційній безпеці) запускають той самий клієнт (програмне забезпечення, яке використовується для перевірки), це збільшить залежність від єдиної кодової бази та зменшить різноманітність клієнтів. Наприклад, Ethereum покладається на кілька клієнтів виконання, таких як geth, nethermind, erigon, besu та akula. Кілька реалізацій кількома мовами можуть збільшити різноманітність без домінування будь-якого клієнта в мережі, таким чином усуваючи потенційні окремі точки відмови. Наявність кількох клієнтів також може підвищити продуктивність, якщо кілька валідаторів/підписувачів/легких клієнтів буде закрито через уразливості/атаки в певній реалізації, інші залишаться доступними.

Налаштування та можливість оновлення

Користувачі та розробники повинні розуміти, чи можуть валідатори/спостерігачі приєднуватися до мережі без дозволу, інакше довіра буде прихована вибраною авторизованою організацією. Оновлення смарт-контрактів також може викликати помилки, які призводять до атак або можуть навіть змінити припущення про довіру. Щоб зменшити ці ризики, можна застосувати різні рішення. Наприклад, у поточному екземплярі шлюз Axelar можна оновити на основі схвалення офлайн-комісії (порогове значення 4/8), однак у найближчому майбутньому Axelar планує вимагати від усіх валідаторів колективного схвалення будь-яких оновлень шлюзу. Основні контракти Wormhole можна оновлювати та керувати ними через мережеву систему управління Wormhole. LayerZero покладається на незмінні смарт-контракти та незмінні бібліотеки, щоб уникнути будь-яких оновлень, але нові бібліотеки можна розгортати, dApps, які використовують налаштування за замовчуванням, отримають оновлені версії, dApps із встановленими вручну версіями потрібно буде встановити нову версію.

Максимальна видобута вартість (MEV)

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

кінцевість вихідного ланцюга

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

Тенденції та прогнози на майбутнє

Безпека, що налаштовується та додається

Щоб краще обслуговувати різні варіанти використання, рішення AMP стимулюються, щоб забезпечити більшу гнучкість розробки. Axelar представляє метод для оновлення обміну повідомленнями та перевірки без зміни логіки прикладного рівня. HyperLane V2 представляє модулі, які дозволяють розробникам вибирати з кількох варіантів, включаючи економічну безпеку, оптимістичну безпеку, динамічну безпеку та гібридну безпеку. CelerIM забезпечує додаткову оптимістичну безпеку на додаток до фінансової безпеки. Багато рішень чекають попередньо визначеної мінімальної кількості підтверджень блоків у вихідному ланцюжку перед передачею повідомлення. LayerZero дозволяє розробникам оновлювати ці параметри. Ми очікуємо, що деякі рішення AMP і надалі пропонуватимуть більшу гнучкість, але ці варіанти дизайну потребують обговорення. Чи можуть програми налаштовувати свою безпеку, якою мірою та що станеться, якщо архітектура програми буде неоптимальною? Поінформованість користувачів про основні концепції безпеки, ймовірно, ставатиме дедалі важливішою. Зрештою, ми передбачаємо агрегацію та абстракцію рішень AMP, можливо, у формі певної комбінації або «доданої» безпеки.

Зрілість механізму «код довіри та математика».

В ідеальній кінцевій меті всі міжланцюгові повідомлення будуть мінімізовані довірою через використання доказів з нульовим знанням. Ми вже бачимо цей зсув у таких проектах, як Polymer Labs і Succinct Labs. Multichain також опублікував білий документ під назвою zkRouter, щоб забезпечити взаємодію через ZK-докази. З нещодавно оголошеною віртуальною машиною Axelar розробники можуть використовувати Interchain Amplifier для встановлення нових з’єднань з мережею Axelar без дозволу. Наприклад, після розробки потужних легких клієнтів і ZK-доказів стану Ethereum розробники можуть легко інтегрувати їх у мережу Axelar, щоб замінити або покращити існуючі з’єднання. Celer Network анонсувала крос-ланцюжкову платформу захисту даних ZK під назвою Brevis, яка дозволяє dApps і смарт-контрактам отримувати доступ, обчислювати та використовувати довільні дані в кількох блокчейнах. Celer використовує схему клієнта ZK light для реалізації zkBridge, видимого для користувача ресурсу, який з’єднує тестові мережі Ethereum Goerli та BNB Chain. LayerZero говорить у своїй документації про можливість додавання нових оптимізаційних бібліотек обміну повідомленнями в майбутньому. Нові проекти, такі як Lagrange, досліджують можливість агрегування кількох доказів із кількох вихідних ланцюжків, тоді як Геродот робить можливим зберігання доказів за допомогою ZK-доказів. Однак цей перехід займе час, оскільки цей підхід важко масштабувати між блокчейнами, які покладаються на різні консенсусні механізми та фреймворки.

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

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

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

3. Блокчейн буде більш дружнім до ЗК. У майбутньому zkEVM зможе надавати стислі докази дійсності виконання, а легкі клієнтські рішення зможуть легко перевіряти виконання та консенсус вихідного ланцюжка. На останньому етапі Ethereum також є плани «перетворити все на zk-SNARK», включаючи консенсус.

Людяність, репутація та ідентичність

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

на закінчення

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

посилання

https://forum.cosmos.network/t/ibc-security-advisory-dragonberry/7702 

https://polymerlabs.medium.com/the-multi-hop-ibc-upgrade-will-take-ibc-to-ethereum-and-beyond-b4bee43523e 

https://cointelegraph.com/news/wormhole-hack-illustrates-danger-of-defi-cross-chain-bridges 

https://axelar.network/blog/future-proof-interop-path-adaptability-for-cross-chain-dapps 

https://ethresear.ch/t/hashi-a-principled-approach-to-bridges/14725 

https://twitter.com/MultichainOrg/status/1613830754458533888?s=20&t=MoDGESqOdcjMQDMFQqzTyQ

https://axelar.network/blog/axelar-virtual-machine-future-of-interoperability 

https://twitter.com/CelerNetwork/status/1638330932603109379?s=20

https://axelar.network/blog/axelar-implements-quadratic-voting-with-maeve-upgrade