Данная статья является продолжением нашей первой статьи про LayerZero, но на более глубоком уровне.

Объяснение уровень Advanced

Шаг 1. Communicator smart-contract

Из dApp вызов приходит сначала в этот смарт-контракт. Он берет транзакцию, парсит ее содержимое на следующие компоненты:

• t - уникальный ID транзакции. На самом деле это объект уникальным образом идентифицирует транзакцию (chainID, blockID и тд), а не просто хэш.
• Packet - содержит ровно то, что нужно для кросс-чейн вызова: dst - уникальный идентификатор смарт-контракта в сети назначения. По сути это chainID+smart-contract_address payload, который нужно скормить смарт-контракту в сети назначения
• Relayer args - информация для оплаты кросс-чейн вызова.

Далее Communicator отправляет все эти три объекта данных в смарт-контракт Validator.

Шаг 2. Validator smart-contract

Получив все 3 объекта (Packet, Relayer args, t) с предыдущего шага, смарт-контракт Validator делает следующие 2 действия:

• Смарт-контракт Validator эмитит ивент[3] , где содержится data всех объектов (Packet, Relayer args, t), которые пришли ему от Communicator. Именно этот ивент ждет Relayer.

ВАЖНО ПОНИМАТЬ! Сразу после получения этого ивента Relayer начинает формировать доказательство существования транзакции t. Каждый новый кросс-чейн вызов означает +1 доказательство в памяти релеера. Таким образом, Relayer копит в памяти объекты [Packet, t, proof]. Более того, так как в t содержится blockID, Relayer всегда точно знает к какому блоку source сети какие объекты [Packet, t, proof] относятся. Накопление Relayer таких объектов - непрерывный процесс.

• Смарт-контракт Validator прокидывает t и dst, которые пришли от Communicator, далее по цепочке в смарт-контракт Network.

Шаг 3. Network smart-contract

• Смарт-контракт Network принимает от валидатора объекты t (где содержится blockID) и dst (где содержится chainID)
• Отправляет dst и blockID оракулу Oracle.

По сути Network говорит Oracle: “В блоке blockID есть функции кросс-чейн вызовов LayerZero, прокинь пожалуйста заголовок для blockID в эндпоинт сети, которая соответствует dst”

Теперь мяч на стороне Oracle и Relayer, они получили всю необходимую информацию от эндпоинта source сети.

Шаг 4. Oracle оповещает эндпоинт в destination сети, что появился блок с blockID и хорошо бы подтянуть из Relayer транзакции с кросс-чейн вызовами для этого блока.

• Oracle ждет финализации блока с полученным на предыдущем шаге blockID (получен от смарт-контракта Network), после читает заголовок блока blockID и отправляет заголовок в смарт-контракт Network, который относится к эндпоинту destination сети.

• Смарт-контракт Network, во-первых, сохраняет заголовок блока во внутреннее хранилище, а, во-вторых, хэширует заголовок блока и проталкивает его в смарт-контракт Validator (этот хэш обозначен blk_hdr_hash).

Шаг 5. Relayer отдает все доказательства транзакций для запрашиваемого блока

Все это время Relayer копил в памяти объекты [Packet, t, proof] кросс-чейн вызов, содержащие в себе в том числе доказательства существования транзакции. Пришло время что-то сделать с этими объектами :)

После того, как как Relayer получает blk_hdr_hash от валидатора, он отправляет все накопленные объекты [Packet, t, proof] для соответствующего блока в смарт-контракт Validator.

Шаг 6. Валидация смарт-контрактом Validator

Смарт-контракт Validator проверяет существование транзакций t в блоке, используя 2 сущности:

• Заголовок блока , хранящийся в хранилище смарт-контракта Network
• Доказательства существования транзакции proof из объектов [Packet, t, proof], присланного Relayer для блока BlockID.

Если все хорошо, то Packet улетает по назначению в целевой смарт-контракт.