Мультичейн теперь неподвластен времени: представляем перспективную интероперабельность

7 min readMar 5, 2023

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

Опубликовано 9 февраля 2023 г.
Автор статьи: Сергей Горбунов CEO Axelar

ПОДЕЛИТЬСЯ ЭТОЙ СТАТЬЕЙ

Введение:

Мы предлагаем концепцию функциональной совместимости, ориентированную на будущее: разработчики легко настраивают безопасность с несколькими цепочками , адаптируясь к особым потребностям и новым технологиям, не меняя логику приложения .
Ключом к пониманию структуры является разделение уровней стека взаимодействия: проверка (безопасность), транспорт (например, маршрутизация) и семантика сообщений (структура, используемая для отправки пакетов из одной сети в другую).
Приложения настраивают возможности кроссчейна, используя фиксированный набор семантики сообщений. Базовая логика проверки и транспорта может развиваться, позволяя разработчику приложения выбирать и обновлять свой подход к безопасности по мере необходимости.
Внедрить новые/индивидуальные подходы к обеспечению безопасности несложно: транспорт и маршрутизация «многие ко многим» облегчают быстрое подключение новых источников проверки к сети Axelar; возможность программирования на сетевом уровне поддерживает настраиваемые правила проверки. Приложения, построенные поверх них, могут извлечь выгоду из этих улучшений без дополнительных изменений.

История
Интернет был разработан для создания надежной коммуникационной сети, способной «выдержать» такие масштабные бедствия, как ядерные атаки. Ученые и инженеры десятилетиями обсуждали различные методы связи, прежде чем остановились на платформе TCP/IP. Таким образом, потребность во взаимосвязи в первых версиях Интернета была решена до того, как кто-либо начал использовать стек TCP/IP в коммерческих целях.

В эпоху блокчейна все развивается наоборот. Спрос на межсетевую коммуникацию уже существует. Его использование растет, а технологии строятся параллельно. Это, к сожалению, привело к тому, что за последние несколько лет были созданы десятки централизованных решений и потеряны миллиарды долларов.

Единственный способ вырастить Web3 — это научиться создавать надежные, децентрализованные и масштабируемые протоколы взаимодействия, которые могут работать десятилетиями.

Как разработчикам следует создавать свои межсетевые децентрализованные приложения с учетом спроса и развивающихся технологий?

Помимо проблем с безопасностью и надежностью, необходимо пересмотреть архитектуру межсетевых приложений dApp с нуля. Например, многие приложения для передачи токенов страдают от сильной зависимости от пути. Актив, путешествующий по пути A → B, часто отличается от того же актива, если он движется по пути A → C → B. Это связано с тем, что приложения должны полагаться на определенный шлюз для авторизации операций чеканки/записи/блокировки/разблокировки. Сообщение, проходящее по одному пути, часто имеет другой шлюз авторизации, чем сообщение, проходящее по другому пути. В блокчейнах источник сообщения эквивалентен установлению его корня доверия.Поэтому крайне важно выбрать правильный «шлюз», поскольку от него зависит безопасность приложений. (Напротив, TCP/IP не обеспечивает никакой безопасности по умолчанию; следовательно, сообщения могут поступать из любого «шлюза», и протоколы прикладного уровня, находящиеся сверху [такие как HTTPS], должны установить безопасные каналы связи с использованием криптографических методов. .)

Чтобы увидеть, как мы можем решить эти проблемы и упростить межсетевое развертывание, давайте сначала разделим уровни функциональной совместимости и определим понятие функциональной совместимости, ориентированной на будущее. После этого мы покажем, как сеть Axelar адаптируется, позволяя приложениям настраивать безопасность таким образом, чтобы повысить надежность отдельных соединений, используя при этом согласованную семантику сообщений и свойства маршрутизации «многие ко многим». Затем мы обсудим, как создавать экземпляры межсетевых токенов и развертываний dApp, следуя принципам совместимости в будущем.

3 уровня функциональной совместимости блокчейна

Чтобы понять, как должна развиваться интероперабельность, полезно различать семантику сообщений , проверку и транспортировку .

Семантика сообщений просто относится к структуре сообщений или пакетов (API), которые приложения могут использовать для отправки сообщений из одной сети в другую. Они просты и часто включают такие поля, как исходная сеть, исходный адрес, сеть назначения, адрес назначения и полезная нагрузка. Приложения отправляют и получают сообщения в соответствии с семантикой.
Проверка относится к уровню доверия. Его можно создать, используя прямое соединение на основе легкого клиента, внешнюю проверку или любую другую технологию. Безопасность приложения держится до тех пор, пока держится уровень проверки.
Транспорт: транспортный уровень отвечает за определение маршрута от источника к месту назначения и его следование. Это определяется свойствами маршрутизации (попарно, многие ко многим) и механикой ретрансляции (с разрешениями и без разрешений). Он может полагаться на таблицу маршрутизации в сети или реестр вне сети.

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

Более конкретно:

Приложение должно создаваться в соответствии с фиксированным набором семантики сообщений. Семантика сообщений для межсетевого взаимодействия должна меняться как можно реже.
Базовые протоколы функциональной совместимости могут быть обновлены для улучшения проверки (например, внешняя проверка заменяется проверкой облегченного клиента) или транспорта (например, найден лучший путь маршрутизации), и приложение может автоматически и немедленно извлечь выгоду из изменений.

Создание с несколькими путями

По сравнению с большинством «протоколов» взаимодействия, которые предлагают парное подключение, сеть Axelar предлагает транспортный уровень «многие ко многим». То есть любое подключение к сети Axelar автоматически совместимо со всеми другими взаимосвязанными блокчейнами. Таким образом, за счет одной интеграции разработчик протокола может получить доступ к N количеству соединений.

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

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

Эти пути могут быть составлены по-разному. Например, если доступна внешняя проверка, облегченный клиент и проверка на основе ZK, приложение может принимать сообщения тогда и только тогда, когда 2/3 пути (шлюзы) авторизуют запросы. Или он может принять сообщение для передачи с низким значением от любого из путей, но передачи с более высоким значением принимаются, если и только если несколько путей авторизуют сообщения.

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

Далее мы опишем, как создавать экземпляры приложений с перспективной функциональной совместимостью для межсетевого токена и общих межсетевых развертываний dApp.

Межсетевые токены

Мы описываем многопутевые инстанцирования в качестве примера передачи активов . Для передачи активов проблема зависимости от пути привела к значительной фрагментации ликвидности и болезненному пользовательскому опыту. То есть пользователь, перемещающий актив X по пути A → B, часто получает другой актив, чем если бы он выбрал путь A → C → B , передавая тот же актив. Это относится к IBC и большинству других парных протоколов. Центры взаимодействия, такие как Axelar, решают эту проблему, имея каноническое представление актива в каждой цепочке.

Чтобы сделать еще один шаг, мы покажем, как разработать приложение для передачи активов со следующими свойствами:

Путь-агностик . Все передачи по путям, которым доверяет приложение, и по всем сетям приводят к одному и тому же активу X в цепочке назначения.
Независимый от сети . Разработчики приложений, желающие дополнительно настроить свою безопасность, могут объявить несколько корней доверия. Например, в приложении может быть указано: «Я доверяю Axelar Gateway I, II и III, но желаю авторизовать сообщения только в том случае, если они одобрены 2/3 шлюзами». Приложение также может заменить адреса шлюза, если для проверки на сетевом уровне используются новые, более совершенные механизмы.

Простой проект, отвечающий обоим вышеуказанным ограничениям, может быть реализован следующим образом:

Контракты межсетевых токенов, ITC, развернуты, скажем, во всех EVM сетях и имеют один и тот же адрес, addr . (Вы можете увидеть, как это сделать, используя службу развертывания постоянных адресов Axelar .)
ITC ссылается на контракт Auth . Контракт аутентификации определяет шлюзы, которым доверяют контракты токенов, и политики доступа к ним ( утверждение 1/1 , одобрение 2/3 и т. д.).

Сообщение считается доверенным тогда и только тогда, когда:

Он поступает от шлюза (или ряда шлюзов), которым доверяет контракт аутентификации , и
Адрес отправителя совпадает с адресом получателя. (То есть по умолчанию компоновщик токенов доверяет «своему собственному коду», но в контракт аутентификации могут быть включены дополнительные доверенные адреса .)

Для сетей, отличных от EVM, к условию (1) могут быть добавлены дополнительные кортежи (сеть, адрес), которые не используют тот же адрес, что и контракт назначения. По мере появления новых подключений контракты аутентификации могут быть заменены или обновлены для авторизации этих подключений.

Создание децентрализованных приложений, не зависящие от пути

Как и межсетевые токены, общее приложение может быть создано, чтобы извлечь выгоду из много-путевой проверки и логики маршрутизации.

Приложению предоставляется несколько шлюзов, поддерживаемых различной логикой проверки.
Контракт аутентификации может быть создан для авторизации проверяющих шлюзов и политики утверждения. (Запросы формы X требуют однократного утверждения, запросы формы Y требуют не менее двух утверждающих лиц и т. д.)
По мере обнаружения новых путей приложение может авторизовать новые соединения или удалять разорванные соединения.

Обратите внимание, что контракты аутентификации должны поддерживать обновления в этой модели. Безопасный способ их создания может включать комбинацию:

Использование держателей токенов dApp для добавления/удаления новых путей подключения посредством управления.
Использование внешнего автономного комитета.
Добавление временных задержек к путям обновления для предотвращения наихудших атак.

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

Наконец, разработчики могут создать систему безопасности на уровне приложений, полагаясь на многоканальные утверждения, основанные на различных моделях безопасности. В сочетании с децентрализованными обновлениями для добавления/удаления путей этот дизайн приводит к долгосрочной совместимости с прямой передачей, которая может масштабироваться для соединения всего Web3.

Website — https://axelar.network

Discord — https://discord.gg/aRZ3Ra6f7D

Twitter — https://twitter.com/axelarcore

Telegram — https://t.me/axelarcommunity
Telegram на русском языке — https://t.me/ru_Axelar