Перейти к основному содержанию

Обзор бочки XCM FRAME

Документация XCM

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

The XCM barrel (бочка-xcm) предоставляет набор предопределенных, часто используемых XCVM-программ в виде набора экстринсиков, использующих FRAME.

Этот бочонок предоставляет некоторые реализации по умолчанию для признаков, необходимых для XcmConfig. XCM Исполнитель также включен как ассоциированный тип в конфигурацию бочек.

Где формат XCM определяет набор инструкций, используемых для построения программ XCVM, barrel-xcm определяет набор экстринсиков, которые могут быть использованы для построения XCVM-программ, как для локальных либо на внешние цепочки. barrel-xcm Функциональность делится на три категории:

заметка

Помните, что все XCM - это программы XCVM, которые следуют за форматом XCM. Работа исполнителя XCM заключается в том, чтобы обрабатывать и выполнять эти программы.

  1. Примитивные, диспетчеризируемые функции для локального выполнения XCM.
  2. Высокоуровневые, диспетчерские функции для передачи активов.
  3. Диспетчерские функции, специфичные для согласования версий.

Примитивные экстринсики

Существует два основных примитивных экстринсика. Эти экстринсики управляют отправкой и выполнением XCVM в качестве диспетчеризируемых функций внутри бочки.

  1. execute - Этот вызов содержит прямой доступ к исполнителю XCM. Задача исполнителя - проверить сообщение и убедиться, что никакие барьеры/фильтры не блокируют выполнение XCM. Как только сообщение будет признано действительным, сообщение будет локально выполняется, возвращая результат в виде события. Эта операция выполняется от имени той учетной записи, которая подписала экстерн. Возможно может произойти только частичное выполнение.
  2. send - Этот вызов определяет, куда должно быть отправлено сообщение (методом транспортировки) извне к определенному месту назначения, т.е. синочейн, смарт-контракт или любая система, управляемая консенсусом. В отличие от execute, исполнитель не вызывается локально, так как выполнение будет происходить на целевой цепочке.
Информация

Бочка XCM нуждается вXcmRouter для отправки XCM. Он используется для определения того, куда разрешено отправлять XCM и какой транспортный протокол XCM использовать. Например, Ogona, пионерская сеть, использует протокол ChildSynochainRouter что позволяет только передавать нисходящие сообщения от релейной сети к синочейнам.

Вы можете узнать больше о XCM транспортные протоколы здесь.

Передача активов Экстринсикс

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

В противном случае плата берется по мере необходимости из передаваемого актива.

  1. reserve_transfer_assets - Переведите некоторые активы из локальной цепочки на суверенный счет цепочки назначения и переслать XCM, содержащий ReserveAssetDeposited инструкция, которая служит в качестве уведомления.

  2. teleport_assets - Телепортируйте некоторые активы из локальной цепочки в некоторую целевую цепочку.

Трансферный резерв против телепорта

Хотя оба экстринсика имеют дело с передачей активов, они демонстрируют принципиально разное поведение.

  • Телепортация актива подразумевает двухэтапный процесс: активы изымаются из оборота предложения (обычно путем сжигания/уничтожения) в цепочке происхождения и повторно отчеканиваются на любой счет указанный в пункте назначения. Телепортация должна осуществляться только при наличии неотъемлемого и двустороннего доверия между двумя цепочками, поскольку токены, уничтоженные в исходной цепочке не могут гарантированно обладать теми же свойствами при чеканке в месте назначения. Должны быть доверенными что та или иная сеть сожгла или перечеканила активы.

  • Перевод или резервирование актива подразумевает, что эквивалент активы (т.е. родная валюта, например ZAL или OGG) изымаются из основного счёта цепочки происхождения и зачисляется на суверенный счет в цепочке назначения. В отличие от телепортации актива, он не уничтожается и не создается заново, а используется доверенная третья организация (т. е. Asset Hub), чтобы зарезервировать активы, при этом суверенный счет цепочки назначения в резерве цепочка получает право собственности на эти активы.

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

Информация

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

Экстринсики для определения версий

Следующие экстринсики требуют root, поскольку они используются только при обходе согласования версий XCM. Они изменяют все соответствующие аспекты хранения, которые имеют отношение к переговорам о версии XCM.

  1. force_xcm_version - Модифицирует SupportedVersion хранилище для изменения указанной версии XCM для конкретного места назначения.
  2. force_default_xcm_version - Модифицирует SafeXcmVersion хранилище, которое хранит версию XCM по умолчанию для использования, когда версия назначения неизвестна.
  3. force_subscribe_version_notify - Отправляет XCM с SubscribeVersion инструкция к назначению.
  4. force_unsubscribe_version_notify - Отправляет XCM с UnsubscribeVersion инструкция в пункт назначения.

Плата за бочку XCM

Плата за сообщение взимается только в том случае, если внутреннее расположение не совпадает с системой консенсуса переводчика (известной как Here в контексте XCM Multilocation). В противном случае все расходы берет на себя цепочка. Если если это применимо, сборы снимаются с активов из указанного MultiLocation и используется как оплаты для выполнения любых последующих инструкций в XCM.

Комиссионные, как правило, зависят от нескольких факторов в рамках XcmConfig. Например, барьер может вообще не платить никаких сборов.

Перед отправкой любого XCM и если барьер цепочки назначения требует этого, то BuyExecution инструкция используется для покупки необходимый объем для XCM. Расчет комиссии XCM осуществляется трейдером, который итеративно рассчитывает общую комиссию на основе количества инструкций.

Трейдер, используемый для вычисления значения веса (время вычисления в консенсусе) для включения в сообщение. Расчет вознаграждения в XCM является очень настраиваемым и, по этой причине, зависит от того, какая конфигурация задействована.