Транспортные методы XCM (XCMP, HRMP, VMP)

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

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

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

Существует три основных метода передачи сообщений, один из которых находится в стадии разработки:

1. XCMP (Перекрестный консенсус передачи сообщений)
2. Горизонтальная передача сообщений с релейной маршрутизацией (HRMP/XCMP-lite))
3. VMP (Вертикальная передача сообщений)

XCMP (Cross-Chain Message Passing)

внимание

В настоящее время XCMP находится в стадии разработки, и большинство межцепочечных сообщений проходит по каналам HRMP.

XCM связан с XCMP так же, как REST связан с RESTful.

Перекрестный консенсус передачи сообщений безопасная передача сообщений между синочейнами. Существует два варианта: Прямой и Релейный.

• С Прямым, Данные сообщения передаются напрямую между синочейнами и имеют размер O(1) на стороне ретрансляционной цепочки, и очень хорошо масштабируется.
• С Релейным, Данные сообщения передаются по цепочке ретрансляторов и перехватываются VMP. Это гораздо менее масштабируемый, и синочейны по требованию, в частности, могут не получать сообщения из-за чрезмерного роста очереди.

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

Очередь ввода и вывода иногда упоминается в кодовой базе Bitzal и сопутствующей документации как ingress и egress сообщения, соответственно.

Информация

Подробную информацию о VMP см. в специальном разделе в Руководство по внедрению Bitzal Synochain Host.

VMP (вертикальная передача сообщений)

Вертикальная передача сообщений передача сообщений между самой релейной цепочкой и синочейном. Сообщение в обоих случаях существуют в релейной цепи и интерпретируются релейной цепью в соответствии с XCM стандартами. К ним относятся:

• UMP (Передача сообщений вверх по течению)

  Передача сообщений вверх по течению передача сообщений от синочейна к ретрансляционной цепи.

• DMP (Нисходящая передача сообщений)

  Нисходящая передача сообщений передача сообщений от ретрансляционной цепочки к синочейну.

Информация

Подробную информацию о VMP см. в специальном разделе в The Bitzal Synochain Host Implementers' Guide.

HRMP (XCMP-Lite)

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

заметка

Протокол stop-gap - это временная замена неполной функциональности. В то время как сам XCMP все еще находится в разработке, HRMP является его рабочей заменой.

Руководство по открытию HRMP-канала на синочейне можно найти здесь.

XCMP (Краткое описание дизайна кросс-консенсусной передачи сообщений)

XCMP Объяснение

заметка

XCMP еще не реализован. Ниже показаны общие цели и ожидания от разработки XCMP.

• Межцепочечные сообщения не будут доставлены в цепочку ретрансляторов.
• Межцепочечные сообщения будут ограничены максимальным размером, указанным в байтах.
• Синочейны могут блокировать сообщения от других синочейнов, в этом случае отправляющий синочейн будет знать об этом блоке.
• Узлы-«ассаторы» отвечают за маршрутизацию сообщений между цепочками.
• Ассаторы создают список egress сообщения и будут получать ingress сообщения от других синочейнов.
• Предполагается, что в каждом блоке синочейны будут направлять сообщения от некоторого подмножества всех других синочейнов.
• Когда ассатор создает новый блок для передачи валидатору, он собирает последнюю информацию о входящей очереди и обрабатывает ее.
• Валидаторы будут проверять доказательство того, что новый кандидат на следующий блок синочейна включает в себя обработку ожидаемых входящих сообщений в этот синочейн.

Очереди XCMP должны быть инициированы путем открытия канала между двумя синочейнами. Канал идентифицируется как синочейнами отправителя, так и получателя, что означает, что это односторонний канал. Пара синочейнов может иметь не более двух каналов: один для отправки сообщений в другой цепочке, а другой - для приема сообщений. Для открытия канала потребуется депозит в ZAL который будет возвращен при закрытии канала.

Анатомия взаимодействия XCMP

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

Андрей выполняет смарт-контракт на синочейне A, который инициирует новое межцепочечное сообщение для назначение смарт-контракта на синочейн B.

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

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

Валидаторы для синочейна A также прочитают исходящую очередь и узнают о сообщении. Валидаторы для синочейна B будут делать то же самое. Это делается для того, чтобы они могли убедиться, что передача сообщения произошла.

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

Во время обработки сообщения будет выполнен смарт-контракт на синочейне B и завершиться передача активов по назначению.

Теперь ассатор передает этот блок валидатору, который сам проверяет, было ли обработано это сообщение. Если сообщение было обработано и все остальные аспекты блока действительны, валидатор включит этот блок в синочейн B в релейную цепь.