Данная статья является продолжением статьи LayerZero (beginner) на более глубоком уровне.

Два основных документа, после прочтения которых появляется понимание принципа работы протокола LayerZero:

• Whitepaper

• Статья с Medium

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

1.t - уникальный ID транзакции. На самом деле, как я понял, это объект уникальным образом идентифицирующих транзакцию (chainID, blockID итд), а не просто хэш.

2. Packet - содержит ровно то, что нужно для кросс-чейн вызова:

• dst - уникальный идентификатор смарт-контракта в сети назначения. По сути это chainID+smart-contract_address

• payload, который нужно скормить смарт-контракту в сети назначения

3.  Relayer args - информация для оплаты кросс-чейн вызова.

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

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

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

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

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

Шаг 3. Network smart-contract

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

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

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

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

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

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

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

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

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

• Заголовок блока , хранящийся в хранилище смарт-контракта Network,

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

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