Як працює міст Axelar

Axelar забезпечує безпечний кросс-чейн зв’язок для Web3. Безпека означає, що Axelar побудовано на основі підходу proof-of-stake, перевіреного в боях підходу, який використовується Avalanche, Cosmos, Eth2 тощо. Комунікація між ланцюжками означає, що ви можете створити повний досвід для своїх користувачів, що дозволяє їм взаємодіяти з будь-яким активом, будь-яким додаток, на будь-якому ланцюжку в один клік

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

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

По-друге, це шлюзи, які фактично є смарт-контрактами, які забезпечують зв’язок між мережею Axelar та її взаємопов’язаними зовнішніми ланцюгами. Валідатори відстежують шлюзи для вхідних транзакцій, які вони ЧИТАЮТЬ. Потім вони приходять до консенсусу щодо дійсності цієї транзакції, і після узгодження вони ПИШУТЬ на шлюз ланцюга призначення для виконання міжланцюжкової транзакції. Кошти надсилаються на згенеровану адресу в ланцюжку джерела та блокуються, а відповідний актив карбується в ланцюжку призначення. Валідатори та шлюзи складають базовий рівень інфраструктури.

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

Axelar захищено набором динамічних перевірок. Делеговане підтвердження участі не обов’язково збільшує розмір набору валідатора. Це робить набір валідатора динамічним: валідатори входять і виходять з активного набору без дозволу, на основі рішень учасників.

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

Мережа Axelar базується на Cosmos SDK і має аналогічні гарантії живучості та безпеки PoS (поріг корупції 67%).
Функціональність крос-ланцюжків є модульною, що дозволяє налаштувати для максимальної масштабованості, витрат і оптимізації безпеки.
Наприклад, контракти шлюзу розгортаються з двома наборами ключів: головним ключем і вторинним ключем. Кожен ключ має пов’язану з ним «політику», яка визначає, які валідатори включено до набору ключів. У поточному екземплярі головний набір ключів у існуючих ланцюжках EVM має політику «частка за вагою та все та 55% безпеки», що означає, що всі валідатори зважені за часткою та включені для захисту набору ключів із порогом безпеки 55%. Тільки цей ключ може виконувати ротацію ключів у мережі. Додатковий ключ із політикою «одна акція на кожного, топ-20 і 55% безпеки» використовується для авторизації окремих опіків і монетних дворів. Для його підтримки обираються 20 найкращих валідаторів з активного набору, кожен з яких отримує одну частку; 11 з них повинні авторизувати кожен запит. Вторинний ключ дозволяє нам мінімізувати витрати на газ, водночас гарантуючи, що навіть якщо частка в кінцевому підсумку буде надто зосереджена серед провідних валідаторів, ми матимемо багато вузлів, які все ще повинні затверджувати запити.
Усі ключові політики/параметри можна налаштувати в мережі за допомогою протоколів керування.