Axelar сеть

Проектирование открытой кросс-цепной сети

Мосты, поддерживаемые сетью Axelar, поддерживаются пограничными учетными записями, поэтому (почти) все валидаторы должны совместно авторизовать любой межсетевой запрос. Проектирование сети, где каждый может участвовать в обеспечении этих мостов, требует следующих технических требований:

• Открытое членство. Каждый пользователь должен иметь возможность стать валидатором (следуя правилам сети).
• Возобновление членства. Когда валидаторы честно покидают систему, их ключи должны быть отозваны.
• Поощрения и жесткие репрессии. Вредные валидаторы должны быть идентифицированы, их действия идентифицированы и устранены с помощью протокола.
• Консенсус. Самая пороговая схема определяется как независимый протокол. Для передачи сообщений между узлами нам нужны широковещательные и двухточечные каналы. Кроме того, валидаторы должны согласовать последнее состояние для каждого вызова порога, поскольку у них есть несколько раундов взаимодействия.
• Управление ключами. Так же, как обычные валидаторы в любой системе PoS должны быть осторожны, чтобы защитить свои ключи, валидаторы Axelar также должны защищать свои границы. Клавиши нужно вращать, разделять между онлайн и офлайн.
Axelar начинается с модели делегированного подтверждения, где сообщество выбирает набор валидаторов для достижения консенсуса. Обратите внимание, что стандартная схема пороговых значений все равно применяется к каждому участнику, и в консенсусе нет понятия «веса». Поэтому сеть должна адаптировать их к весам валидатора. Простой способ — назначить несколько пороговых значений для больших валидаторов. Вот три основных функции, которые валидаторы выполняют вместе.
• Генерация порогового ключа. Имеющиеся алгоритмы генерации пороговых ключей для стандартных схем подписи блокчейна (ECDSA, Ed25519) являются интерактивными протоколами между несколькими участниками.

Специальная транзакция в сети Axelar инструктирует валидаторов приступить к выполнению протокола по состоянию отслеживания. Каждый валидатор запускает пороговый демон, отвечающий за сохранность секретов. Для каждой фазы протокола:
1. Валидаторы сохраняют состояние протокола в локальной памяти.
2. Он вызывает секретный демон для создания уведомлений для других валидаторов в соответствии с описанием протокола.
3. Он передает сообщения другим валидаторам через широковещательные или частные каналы.
4. Каждый валидатор выполняет функцию перехода состояния, чтобы обновить свое состояние, переходит к следующему шагу протокола и повторяет следующие шаги.

В конце протокола пороговый открытый ключ генерируется в цепочке Axelar и может быть отображен пользователю (например, депозиту) или программе, которая сгенерировала исходный запрос.

• Пороговая подпись. Запросы на подписание в сети Axelar обрабатываются так же, как запросы на создание ключей.
Например, они вызываются, когда пользователь хочет изъять активы из одного из интерактивных протоколов, а переходы состояния между раундами осуществляются в виде сообщений, передаваемых через представление блокчейна Axelar и локальную память каждого запускаемого функцией валидатора.

• Обработка изменений в составе валидатора. Набор валидаторов необходимо периодически изменять, чтобы новые заинтересованные стороны могли присоединиться к набору. После обновления набора валидатора нам нужно обновить ключ, который будет использоваться в новом наборе. Поэтому если мы позволим кому-то присоединиться в любое время, нам придется часто обновлять пороговый ключ. Во избежание этого мы изменили валидатор для каждого блока T. Во временном интервале T раундов фиксируется набор Vr и пороговый ключ. В каждом раунде, являющемся целым кратным T, мы обновляем набор валидатора следующим образом:
1. В любом раунде R состояние Axelar отслеживает текущий набор валидаторов V^r. V^r+1 = V^r еще не R+1 умножен на T.
2. Во время (i — 1) раундов T, iT] пользователь публикует сообщение о привязке/разъединении.
3. В конце раунда эти сообщения применяются к V^(iT−1), чтобы получить V^iT.

• Пороговая генерация и подписание ключа при наличии сменных валидаторов. Блокчейн Axelar может запросить новый ключ или подпись подписи в раунде R. Процесс подписания занимает не один раунд, и мы не хотим замедлять консенсус, поэтому требуем подписания к началу раунда R+10. В частности, валидатор начинает этот раунд.

R+10 только после просмотра сертификата для раунда R+9 и подписи каждого запроса на создание ключа/подписи, выданного этим раундом. Резюме запроса о раунде рождения должно быть включено в блок R+11. Другими словами, предложение, блокирующее раунд p, не содержащее результата раунда R — 11, считается недействительным, и валидаторы не будут голосовать.

✅Telegram Axelar RU — https://t.me/axelarcore_ru

✅Cайт проекта: axelar.network

✅Telegram RU — https://t.me/axelar_ru

✅Telegram ENG — https://t.me/axelarcommunity

✅Telegram Announcement — https://t.me/axelarnetwork

✅Discord — https://discord.gg/aRZ3Ra6f7D