Виртуальная машина XCM (XCVM) / Исполнитель XCM

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

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

Пожалуйста, имейте в виду, в основе XCM лежит виртуальная машина кросс-консенсуса (XCVM). Сообщение» в XCM - это программа XCVM. "XCM" или "XCMs" для нескольких сообщений. XCVM представляет собой машину состояний на основе регистров. Состояние отслеживается в специфических для домена регистрах, которые хранят информацию, которая используется и изменяется во время выполнения конкретного сообщения. Большая часть XCM состоит из этих регистров и инструкций, используемых для составления XCVM-программ.

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

Первая реализация XCVM - это xcm-исполнитель. Он соответствует спецификации XCVM, предоставленной GSB. Он спроектирован как расширяемый, что обеспечивает максимальную настраиваемость при конфигурировании XCM. Поскольку xcm-исполнитель это всего лишь реализация XCVM, при желании можно создать другую реализацию.

XCM - это программы XCVM

Кросс-согласованное сообщение (XCM) - это просто программа, которая запускается на XCVM: другими словами, одна или несколько инструкций XCM, которые выполняются реализацией XCVM, такой как xcm-исполнитель.

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

Исполнитель и конфигурация XCM

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

Анатомия и поток перекрестных сообщений консенсуса (XCM)

XCM состоит из списка инструкций, которые выполняются по порядку. Существует четыре различных видов инструкций XCM:

1. Инструкции - Приводит к изменению состояния локальной системы консенсуса или к некоторому изменению состояния.
2. Индикатор доверия - Сообщает XCVM или исполнителю, что некоторое действие уже было выполнено, это означает, что теперь это действие доверено и может быть выполнено, например, в сценарии телепортации.
3. Информация - Предоставляет дополнительную информацию о конкретном источнике, обычно являющемся результатом запроса, т.е. QueryResponse иинструкция.
4. Системное уведомление - Обычно используется в контексте открытия канала HRMP, закрыт или принят.

Как правило, XCM проходит следующий путь через XCVM:

1. Инструкции в XCM считываются XCVM по одной. XCM может содержать одну или несколько инструкций.
2. Инструкция выполняется. Это означает, что текущие значения XCVM регистров, тип инструкции, и операнды команд все они используются для выполнения некоторой операции, в результате чего некоторые регистры могут изменить свое значение или возникнет ошибка, которая остановит выполнение.
3. Каждая последующая инструкция внутри XCM считывается до тех пор, пока не будет достигнут конец сообщения.

Пример регистра: Регистр удержания

Существует множество инструкций, которые зависят от Регистра удержания. Регистр удержания это XCVM регистр, который предоставляет место для хранения любых активов, находящихся в промежуточном состоянии, пока они не будут извлечены из регистра Holding. Для размещения активов в нем требуется инструкция, а для другой - для их изъятия. Простейшим примером этого является DepositAsset инструкция, которая в форме Rust выглядит следующим образом:

перечисление Инструкция {
    DepositAsset {
        активы: MultiAssetFilter,
        бенефициар: MultiLocation,
    },
    /* snip */
}

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

Пример: TransferAsset

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

перечисление Инструкция {
    TransferAsset {
        активы: MultiAssets,
        бенефициар: MultiLocation,
    }
    /* snip */
}

• A MultiAsset это общий идентификатор актива. Он может представлять как сменные, так и неплатежеспособные активы, а в случае с платежеспособным активом он представляет собой определенную сумму актива.

• MultiLocation это относительный идентификатор, то есть он может использоваться только для определения относительного пути между двумя местоположениями и не может использоваться для ссылки на местоположение универсально.

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

Расположение в XCM

Общая природа XCM предполагает определение широкого спектра "расположений", или любой орган, который управляется консенсусом (синочейны, солочейны, смарт-контракты, аккаунты и т. д.). Это относительно абстрактные понятия, которые указывают на где но также кому которые может повлиять то или иное действие. MulitLocation Тип - это то, что XCM использует для определения этих расположений.

A MultiLocation это относительный идентификатор, определяющий относительный путь в некую несущую управленческую консенсусную систему.

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

MultiLocation имеет два основных поля:

• Ряд дорожек, называемых Развязки, которые определяют внутреннюю часть состояния, чтобы спуститься в (иногда это называют "убконсенсусной" системой, такой как смарт-контракт или бочка). Внутреннее может также использоваться для обозначения перекрестка, например, в контексте "синочейн - это внутреннее расположение релейной цепиn", или как UTXO является внутренней частью консенсуса Bitcoin.
• Количество родительских узлов в начале MultiLocation формирования - другими словами, количество родительских консенсусных систем над ним.

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

Пример сценария с несколькими локациями

В этом сценарии предположим, что XCM должен быть отправлен из нашего синочейна в Asset Hub (Синочейн 1000). Этот XCM ссылается на учетную запись в Asset Hub. Как правило, в качестве общего пути используется MultiLocation будет выглядеть следующим образом:

../Synochain(1000)/AccountId32(<some_account_id>)

или сценарий на Rust:

MultiLocation {
  родители: 1,
  интерьер: X2(Синочейн(1000), <some_account_id>.в())
}

• В первом поле, родители, существует родитель 1. Это происходит потому, что наш синочейн имеет релейную цепь в качестве родителя - другими словами, она будет идти вверх одной системой консенсуса в ретрансляционную цепочку. Это также иллюстрирует ../ представление "пути к файлу" представительства.

• Второе поле, интерьер, определяет, куда переходить после релейной цепочки. В данном случае из ретрансляционной цепочки это сообщение попадет в концентратор активов (Синочейн 1000), затем ссылайтесь на учетную запись (some_account_id) расположенный внутри.

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

Универсальное расположение в XCM

UniversalLocation относится к любой системе глобального консенсуса. Система глобального консенсуса - это организация которая обеспечивает консенсус на верхнем уровне с помощью некоторого непроизводного алгоритма консенсуса, который может существовать без привязки к какой-либо другой одноуровневой системе данных. К таким системам глобального консенсуса относятся Bitzal (или другие релейные цепочки), Bitcoin или Ethereum. Она обеспечивает точку отсчета для всеобъемлющих консенсусных систем.

GlobalConsensus развязка относится к системе глобального консенсуса и принимает NetworkId что определяет конкретную удаленную сеть. UniversalLocation позволяет всеохватывающим системам консенсуса общаться с помощью этого узла. Субконсенсусные системы (например, синочейн на Bitzal) могут обращаться к другим удаленным субконсенсусным системам (например, синочейн на Ogona), используя относительный путь, определенный через a MultiLocation.

Моделирование XCVM с помощью xcm-simulator

В хранилище Bitzal существует xcm-симулятор, который позволяет разработчикам экспериментировать с созданием, выполнением и моделированием различных сценариев использования XCM.