В этой статье предлагаются некоторые начальные варианты проектирования архитектуры при составлении кроссчейн-приложений и исследуются виды функций, которые можно создать с использованием каждого из них.
Предположим, вы знаете, что хотите использовать кроссчейн, чтобы обеспечить глобальную доступность, ликвидность и распространение для вашего децентрализованного приложения. Как вам следует разрабатывать архитектуру кроссчейна?
На высоком уровне есть две модели кроссчейн-архитектуры:
- Одноранговая архитектура.
- Архитектура «база-спутник».
Давайте взглянем на примеры этих архитектур и рассмотрим их компромиссы.
Одноранговая межсетевая архитектура
В модели одноранговой кроссчейн-архитектуры вы можете развернуть идентичную «симметричную» версию своих смарт-контрактов в нескольких цепочках для запуска одной и той же функциональности. Хорошим примером этого является токен omnichain, такой как токен ERC-20, который может работать в любой цепочке, совместимой с виртуальной машиной Ethereum (EVM).
Ваш одноранговый контракт может кодировать следующую семантику:
- Он может получить сообщение от любого из своих братьев и сестер.
- В сообщении будет сказано: «Пользователь X отправляет свой токен на сумму Z из цепочки A в цепочку B».
- Контракт в цепочке B проверит, что он доверяет сообщениям из цепочки A и адресу контракта, который отправил сообщение. Если это так, он разрешит операцию «минет» в цепочке B для кошелька пользователя (до этого токен сжигается в цепочке A по соответствующему контракту).
Все контракты выполняют одинаковые функции. Сообщения могут отправляться асинхронно и даже выполняться не по порядку. Такие инструменты, как сервисы развертывания адресов контрактов, позволяют децентрализованным приложениям масштабироваться до новых цепочек без особых проблем. (Каждый контракт имеет адрес контракта C во всех цепочках, и сообщения проверяются, если они исходят от C и их одобряет базовый протокол взаимодействия.)
Основным преимуществом использования этой кроссчейн-архитектуры является простота и легкость масштабирования в нескольких сетях. Однако это не работает, когда операция не может быть выполнена без «глобальной» видимости состояния приложения.
Межсетевая архитектура домашней базы и спутника
Вот тут-то и появляется «домашняя база и спутник». По сути, это кросс-цепочная модель архитектуры «звезда-звезда», в которой большая часть логики вашего контракта живет в одной цепочке. Разработчик может выбрать лучшую цепочку для своего варианта использования и создать среду, оптимизированную для обеспечения высокой безопасности, задержки, сборов или любых других требований. Затем спутниковые контракты в подключенных цепях несут ответственность за отправку сообщений на базовую базу для выполнения переходов между состояниями.
Например, предположим, что вы хотите создать торговую площадку NFT в цепочке A. Вы можете разрешить пользователям покупать/продавать NFT из любого кошелька, в любой цепочке, в любой валюте. Затем пользователь из цепочки B отправит свой актив на вспомогательный контракт, который свяжется с базовым контрактом в цепочке A и отправит NFT на кошелек пользователя. Выпуск NFT, таблица заказов и цены определяются в цепочке A. В результате транзакция пользователя не может быть завершена до тех пор, пока сообщение из цепочки A в цепочку B не будет завершено и доставлено.
Пользователи могут управлять общим состоянием приложения в нескольких цепочках. Некоторым приложениям потребуется «атомарность» их запросов. Вы можете создать уровень протоколов прикладного уровня для реализации этих свойств. Например:
- Вы можете добавить одноразовые номера к своим сообщениям, чтобы убедиться, что они всегда выполняются по порядку, используя одноразовое выполнение .
- Вы можете реализовать шаблон отправки-подтверждения (подтверждения-получения) для синхронизации состояний между контрактами ( пример dApp ).
Вывод
С одной стороны, безопасная межсетевая связь позволяет существующим приложениям dApp связываться с активами, пользователями и функциями между блокчейнами. С другой стороны, это позволяет использовать новые типы приложений.
Axelar предоставляет универсальную оверлейную сеть, которая связывает любой актив, любое dApp, любого пользователя в любой подключенной цепочке со всей децентрализованной сетью. Разработчики могут объединять активы или создавать функциональные возможности в этой сети, используя общую передачу сообщений для вызова любой функции в любой подключенной цепочке.
Варианты межцепочечной архитектуры, обсуждаемые в этой статье, — это некоторые из решений, которые приходят при создании приложений, изначально использующих преимущества этих возможностей.
Чтобы узнать больше: - Прочтите документацию Axelar .
- Посмотрите обучающие видео по программированию (мы всегда добавляем новые).
- Клонируйте репозиторий GitHub с примерами dApps
Изображение обложки в общественном достоянии: Источник