Що таке мережа Axelar?
Мережа Axelar — це децентралізований кінцевий автомат, відповідальний за полегшення міжланцюгових запитів. Мережа підтримує кілька ключових протоколів, таких як протокол кросс-ланцюгового шлюзу (CGP). CGP знаходиться в центрі системи і дозволяє нам легко впроваджувати нові ланцюги без обмежень щодо правил консенсусу та передавати інформацію між ними. У цій публікації ми подивимося, що змушує CGP працювати, і зануримося в деякі деталі за стеком. Але спочатку спробуємо зрозуміти, що привело нас до цієї архітектури.
Для початку ось ключові компоненти мережі Axelar:
•Консенсус •Порогова криптографія •Контракти шлюзу •Валідатори •Перехресні демони (він же ретранслятори)
Чому мережі Axelar потрібен консенсус для обробки крос-ланцюжкових запитів?
Правила підтвердження крос-ланцюжкових запитів та їх обробки закодовані в розподіленому протоколі, що виконується спільно всіма валідаторами. Ви можете думати про мережу Axelar як про децентралізовану машину переходу станів, а запити, надіслані в мережі, ініціюють перехід з одного стану в інший. Таким чином, консенсус дозволяє нам:
1.Щоб досягти згоди щодо стану системи та виконати CGP, 2. Узгодити стан інших мереж для підтвердження міжланцюжних запитів, 3.Виконати розподілену логіку для ініціалізації багатостороннього протоколу генерації ключів і підписання, 4.Обробляйте зміни членства, ротацію ключів і заохочення. Нарешті, консенсус є передумовою для кількох багатосторонніх протоколів порогової криптографії, які ми описуємо нижче.
Чому мережі Axelar потрібна порогова криптографія?
Шлюзи Axelar спільно керуються валідаторами Axelar за допомогою порогової криптографії. Тобто більшість валідаторів повинні погодитися та спільно схвалити будь-яку транзакцію, яка буде виконана через шлюзи. Це схоже на те, як більшість валідаторів повинні узгодити перехід станів у стандартних блокчейнах, щоб дозволити передачу основних активів від одного користувача до іншого. Результатом угоди є підписана компактна угода. Наявність єдиного підпису (сукупно створеного більшістю валідаторів), що авторизує транзакції, дозволяє нам зберігати транзакції невеликими, підтримувати низькі комісійні та усунути будь-які вимоги з ланцюжків мережевих з’єднань Axelar (наприклад, підтримка кількох підписів, обмеження транзакцій, легкі клієнти тощо). Багато порогових протоколів (наприклад, ECDSA, який сьогодні використовує біткойн) передбачають надійний канал мовлення та приватні однорангові канали між сторонами. Тут консенсус також дуже корисний :).
Чи кожен валідатор повинен запускати вузли всіх інших ланцюжків?
Валідатори мережі Axelar запускають вузли або легкі клієнти інших ланцюжків. Для цього не потрібно кодувати користувацьку логіку — валідатори просто завантажують програмні клієнти, надані розробниками блокчейну, відкривають кінцеві точки RPC і направляють вузли Axelar на ці кінцеві точки. Валідаторам буде дозволено вибирати, для яких ланцюжків вони перевірятимуть запити, і стимули будуть структуровані відповідно. Важливо зазначити, що порогові ключі будуть розподілені між усіма валідаторами для більшої безпеки (у нас також є вторинні ключі, які будуть розподілені між меншою кількістю валідаторів із набагато більш обмеженою потужністю).
Які типи команд підтримує мережа?
•Створіть нову пару ключів ланцюга. Протокол розподіленого порогового значення виконується між усіма валідаторами, щоб створити головну пару ключів для ланцюга, який буде з’єднуватися з протоколом Axelar. •Розгорніть новий контракт шлюзу в новому ланцюжку. Після цієї події, припускаючи, що достатня кількість валідаторів може перевірити транзакції в цьому ланцюжку, він стає взаємопов’язаним через інфраструктуру Axelar з усіма іншими ланцюжками. [Для мережі Bitcoin замість них використовуються спеціальні сценарії та система керування UTXO. Докладніше про це пізніше.] •Згенеруйте адресу посилання для транзакції від вихідного ланцюга X до ланцюга призначення Y. Ця команда повертає нову адресу, за якою можна здійснити транзакції, і згодом мережа відобразить їх у ланцюжку призначення Y. •Перевірка депозитів у вихідному ланцюжку X. Це запускає протокол консенсусу 2-го рівня на вершині мережі Axelar, щоб завершити депозит у вихідному ланцюжку. По суті, усі валідатори запитують свої кінцеві точки RPC, щоб перевірити, чи є транзакція «остаточною» згідно з деякими правилами (для ланцюгів PoW вона повинна бути достатньо глибокою в ланцюжку, для ланцюгів PoS з миттєвою остаточністю — так, ви отримуєте миттєву завершеність) .
Як зростає стан у мережі Axelar?
Мережа Axelar відстежує лише інформацію, пов’язану з контрактами шлюзу та міжланцюговими транзакціями. Таким чином, дані зростають лише з кількістю міжланцюгових передач, а не з розміром блокчейнів, які підключаються до мережі Axelar. Крім того, кілька крос-ланцюжкових транзакцій обробляються пакетами.
Що потрібно для підтримки нового ланцюга на Axelar?
Контракти шлюзу Axelar потрібно перенести на мову смарт-контрактів цієї платформи. Контракти є «універсальними», оскільки не залежать від консенсусу чи стану будь-яких інших ланцюжків. Наприклад, в основному одні й ті ж контракти повторно використовуються в усіх ланцюгах EVM. Далі, певний мінімальний поріг мережевих валідаторів Axelar потрібен для запуску вузлів, щоб мати можливість перевіряти запити в/вихід із контрактів шлюзу. Порогове значення є параметром, який можна налаштувати в системі, і буде встановлено на основі експериментів у тестовій мережі.
Як інформація передається через різні блокчейни?
Коли транзакція в ланцюжку A надходить до контракту шлюзу, її потрібно передати в мережу Axelar. Ретранслятори або міжланцюгові демони/процеси відповідають за моніторинг цих контрактів шлюзу та, побачивши вхідний запит, пересилають його до мережі Axelar. Згодом валідатори запитують свої кінцеві точки RPC для ланцюга A, голосують за транзакцію, ініціюють перехід внутрішнього стану для обробки транзакції. Наприклад, якщо транзакція вносить певні кошти до контракту шлюзу, то валідитори записують це та поміщають у резерв, звідки його можуть підписати всі валідитори Axelar. Нарешті, будь-хто може передати підписану транзакцію в ланцюжок призначення.
Важливо зазначити, що ретранслятори не є надійними для безпеки протоколу. Децентралізований протокол, що виконується валідатором Axelar, перевіряє (де це можливо) кожен запит, поданий ретрансляторами. Крім того, для підтримки працездатності протоколу достатньо мати 1 функціональний ретранслятор.
Крім того, багато переходів стану може ініціювати будь-хто в мережі. Наприклад, коли кілька крос-ланцюжкових транзакцій очікують на відставання до цільового ланцюга, один запит на підпис у мережі обробить їх усі.
Що потрібно для моніторингу працездатності мережевих вузлів і валідаторів Axelar?
Інформацію про працездатність мережі можуть спостерігати:
а) моніторинг журналів, що випускаються вузлами Axelar,
b) Запит про стан книги,
c) Спостерігаючи за подіями, що випромінюються вузлами Axelar і на контрактах шлюзу,
d) Підписка на метрики, надані через Prometheus.
Які цікаві події можна спостерігати?
•Багатосторонні виклики генерації ключів, створені ключі, невдалі спроби. •Заклики на багатостороннє підписання. •Ключі та облікові записи шлюзів розгорнуті в кожному ланцюжку. •Активні валідатори, їхня частка, делегації, незалежно від того, чи не вистачає їм створення блоків, голосування за події із зовнішнього ланцюга чи участі в церемоніях створення ключів/знаків. •Статус валідаторів у мережі: наприклад, якщо валідатор хоче вийти з мережі, він спочатку має «скасувати реєстрацію» і чекати, поки їхні частки не будуть виведені з системи. Після ротації їхніх акцій із системи вони можуть розлучитися.
Як я можу долучитися до проекту?
Ми розвиваємо екосистему операторів вузлів, постачальників інфраструктури гаманців і моніторингу, розробників і найму на різні технічні та екосистемні ролі (https://axelar.network/careers)
Також зв’яжіться з розробником Discord і слідкуйте за нашими соціальними каналами: