MMS

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

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

На высоком уровне есть две модели кроссчейн-архитектуры:

  • Одноранговая архитектура.
  • Архитектура «база-спутник».

Давайте взглянем на примеры этих архитектур и рассмотрим их компромиссы.

Одноранговая межсетевая архитектура

В модели одноранговой кроссчейн-архитектуры вы можете развернуть идентичную «симметричную» версию своих смарт-контрактов в нескольких цепочках для запуска одной и той же функциональности. Хорошим примером этого является токен 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 .

Изображение обложки в общественном достоянии: Источник 

Tags:

Leave a Reply

Your email address will not be published. Required fields are marked *