Notice: Function _load_textdomain_just_in_time was called incorrectly. Translation loading for the redux-framework domain was triggered too early. This is usually an indicator for some code in the plugin or theme running too early. Translations should be loaded at the init action or later. Please see Debugging in WordPress for more information. (This message was added in version 6.7.0.) in /home/mmsteam/public_html/wp-includes/functions.php on line 6121

Notice: Function _load_textdomain_just_in_time was called incorrectly. Translation loading for the betterdocs domain was triggered too early. This is usually an indicator for some code in the plugin or theme running too early. Translations should be loaded at the init action or later. Please see Debugging in WordPress for more information. (This message was added in version 6.7.0.) in /home/mmsteam/public_html/wp-includes/functions.php on line 6121

Notice: Function _load_textdomain_just_in_time was called incorrectly. Translation loading for the cyr2lat domain was triggered too early. This is usually an indicator for some code in the plugin or theme running too early. Translations should be loaded at the init action or later. Please see Debugging in WordPress for more information. (This message was added in version 6.7.0.) in /home/mmsteam/public_html/wp-includes/functions.php on line 6121

Notice: Function _load_textdomain_just_in_time was called incorrectly. Translation loading for the yandex-metrica domain was triggered too early. This is usually an indicator for some code in the plugin or theme running too early. Translations should be loaded at the init action or later. Please see Debugging in WordPress for more information. (This message was added in version 6.7.0.) in /home/mmsteam/public_html/wp-includes/functions.php on line 6121

Notice: Function _load_textdomain_just_in_time was called incorrectly. Translation loading for the ultimate-blocks domain was triggered too early. This is usually an indicator for some code in the plugin or theme running too early. Translations should be loaded at the init action or later. Please see Debugging in WordPress for more information. (This message was added in version 6.7.0.) in /home/mmsteam/public_html/wp-includes/functions.php on line 6121

Notice: Function _load_textdomain_just_in_time was called incorrectly. Translation loading for the teknolab domain was triggered too early. This is usually an indicator for some code in the plugin or theme running too early. Translations should be loaded at the init action or later. Please see Debugging in WordPress for more information. (This message was added in version 6.7.0.) in /home/mmsteam/public_html/wp-includes/functions.php on line 6121
Как создать кроссчейн DApp: архитектура взаимодействия 101 – MMS
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 *