Сеть Axelar — это децентрализованный конечный автомат, отвечающий за облегчение запросов между цепочками. Сеть поддерживает несколько ключевых протоколов, таких как Cross-Chain Gateway Protocol (CGP). CGP лежит в основе системы и позволяет нам легко подключать новые цепочки без ограничений правил консенсуса и передавать информацию между ними. В этом посте мы рассмотрим, что заставляет CGP работать, и углубимся в некоторые детали, лежащие в основе стека. Но сначала попробуем понять, что привело нас к этой архитектуре.
Для начала, вот ключевые компоненты Axelar Network:
- Консенсус
- Пороговая криптография
- Контракты шлюза
- Валидаторы
- Демоны кроссчейна (также известные как ретрансляторы)
Почему сети Axelar нужен консенсус для обработки межсетевых запросов?
Правила подтверждения кроссчейн-запросов и их обработки закодированы в распределенном протоколе, который выполняется всеми валидаторами коллективно. Вы можете думать о сети Axelar как о децентрализованной машине перехода состояний, и запросы, отправленные в сеть, вызывают переходы из одного состояния в другое. Таким образом, консенсус позволяет нам:
- Для достижения соглашения о состоянии системы и выполнения CGP,
- Согласовать состояние других цепочек для подтверждения межсетевых запросов,
- Выполнение распределенной логики для инициализации многостороннего протокола генерации ключей и подписи,
- Обрабатывайте изменения членства, ротацию ключей и поощрения.
Наконец, консенсус является необходимым условием для ряда протоколов многосторонней пороговой криптографии, которые мы опишем ниже.
Зачем сети Axelar нужна пороговая криптография?
Шлюзы Axelar совместно управляются валидаторами Axelar с помощью пороговой криптографии. То есть большинству валидаторов необходимо согласовать и коллективно одобрить любую транзакцию, которая будет выполняться через шлюзы. Это похоже на то, как большинству валидаторов необходимо согласовать переходы состояний в стандартных блокчейнах, чтобы авторизовать передачу базовых активов от одного пользователя к другому. Результатом соглашения является подписанная компактная транзакция. Наличие единой подписи (совместно созданной большинством валидаторов), авторизующей транзакции, позволяет нам поддерживать небольшой размер транзакций, поддерживать низкие комиссии и устранять любые требования к межсетевым соединениям сети Axelar (например, поддержка мультиподписи, лимиты транзакций, легкие клиенты и др.). Многие пороговые протоколы (например, ECDSA, используемый Биткойном сегодня), предполагает наличие надежного широковещательного канала и одноранговых частных каналов между сторонами. Здесь консенсус также очень удобен :).
Должен ли каждый валидатор запускать ноды всех остальных цепочек?
Валидаторы сети Axelar запускают ноды или легкие клиенты других цепей. Для этого не нужно кодировать специальную логику — валидаторы просто загружают программные клиенты, предоставленные разработчиками блокчейна, выставляют конечные точки RPC и указывают узлы Axelar на эти конечные точки. Валидаторам будет разрешено выбирать, для каких сетей они будут проверять запросы, и поощрения будут структурированы соответствующим образом. Важно отметить, что пороговые ключи будут распределены между всеми валидаторами для большей безопасности (у нас также есть вторичные ключи, которые будут распределены между меньшим количеством валидаторов с гораздо более ограниченной мощностью).
Какие типы команд поддерживает сеть?
- Создайте новую пару ключей цепочки. Протокол распределенного порога выполняется среди всех валидаторов для создания пары мастер-ключей для цепочки, которая будет соединяться с протоколом Axelar.
- Разверните новый контракт шлюза в новой цепочке. После этого события, при условии, что достаточное количество валидаторов может проверять транзакции в этой цепочке, она становится взаимосвязанной через инфраструктуру Axelar со всеми другими цепочками. [Для сети Биткойн вместо этого используются пользовательские сценарии и система управления 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,
б) Запрос состояния бухгалтерской книги,
c) Наблюдение за событиями, генерируемыми узлами Axelar и контрактами шлюза,
г) Подписка на метрики, предоставляемые через Prometheus.
Какие интересные события можно наблюдать?
- Многосторонние вызовы генерации ключей, созданные ключи, неудачные попытки.
- Вызовы многосторонней подписи.
- Учетные записи ключей и шлюзов развернуты в каждой цепочке.
- Активные валидаторы, их доля, делегирование, пропускают ли они создание блоков, или голосование по событиям из внешней цепочки, или участвуют в церемониях кейгена/подписания.
- Статус валидаторов в сети: например, если валидатор хочет покинуть сеть, он сначала «отменяет регистрацию» и ждет, пока его акции не будут удалены из системы. После того, как их акции будут удалены из системы, они могут разъединиться.
Как я могу принять участие в проекте?
Мы расширяем экосистему операторов узлов, поставщиков кошельков и инфраструктуры мониторинга, разработчиков и нанимаем сотрудников на различные технические и экосистемные должности ( https://axelar.network/careers )
Кроме того, свяжитесь с разработчиком Discord и следите за нашими социальными каналами: