# LayerZero (advanced)

By [92ikonostasov](https://paragraph.com/@92ikonostasov) · 2024-01-07

---

![](https://storage.googleapis.com/papyrus_images/0f4a04d7ac67841c8510963d06c5b7e6856530e592de8c9d87d8c3c2124c6d18.jpg)

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

**Материалы**
=============

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

*   [Whitepaper](https://layerzero.network/pdf/LayerZero_Whitepaper_Release.pdf)
    
*   С[татья](https://medium.com/layerzero-official/layerzero-an-omnichain-interoperability-protocol-b43d2ae975b6) с Medium
    

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

**Шаг 1. Communicator smart-contract**
--------------------------------------

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

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

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

*   **dst** - уникальный идентификатор смарт-контракта в сети назначения. По сути это **chainID**+**smart-contract\_address**
    
*   **payload**, который нужно скормить смарт-контракту в сети назначения
    

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

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

**Шаг 2. Validator smart-contract**
-----------------------------------

Получив все 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** таких объектов - непрерывный процесс.

![](https://storage.googleapis.com/papyrus_images/752911ffd8883699a131777b0b0c6f9245e40b7ff85922ea1639a5aecfedd097.jpg)

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

![](https://storage.googleapis.com/papyrus_images/d57f3b70189810c3fc046af2cbb2c22e17b185e182f4c1e78bf28827a584cf8f.jpg)

Шаг 3. Network smart-contract

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

![](https://storage.googleapis.com/papyrus_images/2614c2b0872e45368c2792183a290ac215c429e4dbbb88e28947d992c8b9d2dd.jpg)

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

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

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

![](https://storage.googleapis.com/papyrus_images/e8615093afa2161d13b6e0ada1283be8926ccb297c834ec34c8b96b609cf5f1f.jpg)

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

![](https://storage.googleapis.com/papyrus_images/4a7735dc9a0444944dfdf4ba86b3aa28397cd78f70b07bd6ac910d2a91dd3065.jpg)

**Шаг 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 улетает по назначению в целевой смарт-контракт.

---

*Originally published on [92ikonostasov](https://paragraph.com/@92ikonostasov/layerzero-advanced)*