Автор: Lisa A., Taiko Labs; переклад: Jinse Finance xiaozou
У цій статті обговорюватимуться різні методи міжланцюгового обміну повідомленнями L2 з точки зору зведення, зосереджуючись на міжланцюжному зв’язку без довіри. Ми коротко розглянемо підхід прямого читання стану, підхід легкого клієнта та підтвердження зберігання. Ми також розглянемо механізм агрегування доказів, довірену передачу міжланцюжкових повідомлень третьої сторони та основні крос-ланцюгові рішення ZK. Нарешті, давайте подивимося, як різні L2 реалізують міжланцюговий обмін повідомленнями сьогодні.
1. Вступ до міжланцюжкового обміну повідомленнями
Для перехресного зв’язку всі сторони (L2, L3 тощо) повинні мати прямий доступ до останнього кореня стану Ethereum.
Усі депозитні рівні мають «вбудований» крос-чейн механізм, який можна використовувати для доступу до кореня стану L1, який буде передано L2 як повідомлення про депозит.
1**.1** Два типи доступу до кореня стану
Тип 1: Читати кореневий стан напряму - це можна зробити через код операції або попередньо скомпільований. Однак він досі не реалізований, тому докази не потрібні.
Брехт Девос описує можливий метод прямого зчитування стану в дослідницькій статті: "...ми можемо представити попередньо скомпільований контракт, який може безпосередньо викликати смарт-контракт у цільовому ланцюжку. Цей попередньо скомпільований безпосередньо в вихідному ланцюжку вставляє та виконує код смарт-контракту іншого ланцюга Це гарантує, що смарт-контракти завжди матимуть доступ до останнього доступного стану ефективним і легко доведеним способом».
· Також описано в RFP компанії Optimism «Доказ концепції віддаленого статичного виклику».
Тип 2: Генерація доказів - тобто підтвердження твердження про один блокчейн на іншому блокчейні.
«Крос-ланцюжок обміну повідомленнями з доказами» має два підходи:
· Ненадійний міжланцюговий зв’язок — тобто відсутність надійних третіх сторін (наприклад, використання легких клієнтів або підтвердження зберігання). Підхід без довіри може використовуватися як для сторонньої генерації доказів, так і для того, щоб учасники міжланцюгового зв’язку генерували докази самостійно.
Докази розподіляються між різними зведеннями для забезпечення міжланцюжкових операцій. Цей підхід, який мало обговорюється в цій статті, зараз знаходиться на стадії дослідження та не вважається потенційно широко застосовним рішенням.
1**.2** Метод «Міжланцюговий обмін повідомленнями з доказом»
1.2.1Легкий міжланковий обмін повідомленнями
Доведіть дані про ланцюжок В
Отримайте дані перевірки Merkle від повного вузла ланцюга B (вузол архівування архіву, якщо потрібне підтвердження зберігання для певних історичних станів);
Надішліть заголовок блоку та перевірочні дані, що відповідають блоку ланцюжка B, що містить стан, який ми хочемо перевірити, до контракту перевірки на ланцюжку A як дані виклику;
Контракт перевірки обчислює хеш-значення блоку на основі даних заголовка блоку, запитує інтелектуальний контракт легкого клієнта в ланцюжку A (відстежує хеш-значення блоку в ланцюжку B) і перевіряє, чи дійсне хеш-значення;
Дані підтвердження перевіряються на корінь стану bytes32 у заголовку блоку.
1**.2.2** Доказ зберігання
Proof of Storage має два варіанти «робочого процесу»:
· Згенеруйте підтвердження зберігання → використовуйте в ланцюжку
· Створити доказ зберігання → створити доказ zk → використовувати в ланцюжку
Суб’єкт також може упакувати кілька колекцій доказів в єдиний доказ (як доказ зберігання, так і доказ zk). Це необов’язковий крок оптимізації, який ще не обговорюється.
Давайте розглянемо три основні етапи «робочого процесу» підтвердження зберігання: генерація підтвердження зберігання, генерація підтвердження zk і використання його в ланцюжку.
(1) Створення підтвердження зберігання
· Підтвердження зберігання дозволяє нам використовувати конфіденційне зобов’язання, щоб довести, що певна інформація існує в блокчейні та є правдивою;
Підтвердження зберігання є частиною криптопростору з моменту появи дерев Merkle у 1979 році. Однак ванільні стійки до зберігання зазвичай досить великі. Сучасна інновація полягає в поєднанні підтвердження зберігання з перевіреними обчисленнями для створення коротких доказів, які можна перевірити в мережі.
Щоб згенерувати підтвердження зберігання, необхідно надати певний блок даних і пов’язаний із ним шлях Merkle або Verkle у дереві Merkle. Шлях складається з однорідних хешів, необхідних для реконструкції кореневого хешу за допомогою того самого алгоритму хешування.
Щоб підтвердити підтвердження зберігання, одержувач може використати надані дані та шлях Merkle або Verkle для повторного обчислення кореневого хешу. Якщо перерахований кореневий хеш відповідає відомому кореневому хешу, одержувач може бути впевнений, що дані автентичні та є частиною наданого набору даних.
(2) Створення ZKP (доказ нульового знання)
Однак підтвердження зберігання типу Ethereum становить близько 4 Кб — це досить великий розмір для розміщення всього підтвердження зберігання в цільовому ланцюжку, оскільки перевірка підтвердження буде дуже дорогою. Тому для стиснення доцільно використовувати ЗКП (наприклад, ЗК-СНАРК), що може зробити доказ меншим і дешевшим у перевірці.
（3）A****rollZKP
Після отримання ZKP користувачі в цільовому ланцюжку можуть розгортати свої зароблені докази (наприклад, отримати доступ до історичного стану через заголовки блоків або хеші блоків).
Розгорнути можна наступним чином:
Накопичення в ланцюжку: Весь процес реконструкції заголовків блоків із доказів виконується безпосередньо в ланцюжку блоків. Недоліки: висока комісія за газ, споживання обчислювальних ресурсів; переваги: відсутність додаткового часу на підтвердження, низька затримка, оскільки немає необхідності генерувати підтвердження поза блокчейном.
Стиснення в ланцюжку: видаліть зайву або непотрібну інформацію з даних або використовуйте структури даних, оптимізовані для економії простору. Стиснуті дані надсилаються в блокчейн і можуть бути розпаковані за потреби. Мінуси: стиснення та розпакування даних може означати додаткові обчислення, але ця затримка може бути незначною. Використаний алгоритм стиснення може мати негативний вплив на безпеку даних; перевага: зменшити витрати на дані.
Зберігання поза мережею: Зберігайте дані поза мережею та розміщуйте певні блоки даних у мережі за запитом. Це актуально для рішень, яким з якихось причин потрібно зберігати великі обсяги даних (наприклад, вузли архіву Ethereum з блоку genesis). Мінуси: те саме, що й стиснення в ланцюжку; Плюси: подальше зниження витрат на дані.
1**.2.3** Довірена третя сторона
Повне крос-чейн рішення також має включати рішення для перехресного обміну повідомленнями з довіреними третіми сторонами (такими як оракули, централізовані мости тощо).
1**.2.4** «Універсальна» система перевірки
У випадку спільного механізму платформи підтвердження агрегації обмін повідомленнями можна пришвидшити, отримуючи хеші блоків, які встановлюються на платформі агрегації, і тут також оброблятиметься обмін повідомленнями (але якщо є проблема з платформою агрегації, що робити?).
1**.2.5 Деякі невідомі проблеми ZK****міжланцюжкового обміну повідомленнями**
Чи можливий міжланцюговий обмін повідомленнями без довіреної третьої сторони (яка може бути однією організацією або кількома сутностями)? Що таке ефективний механізм передачі повідомлень між ланцюжками? Загалом, для Ethereum L2 (з прямим доступом до блокових хешів L1) і самого Ethereum, якщо один ланцюжок може запускати легкий клієнт тощо, чого достатньо для безнадійного обміну повідомленнями між ланцюжками.
Чи належним чином масштабовано схему ZK, яка використовується для генерації доказів крос-ланцюгів? У деяких випадках, особливо коли рівень консенсусу (який потрібно перевірити для міжланцюжкових операцій) дуже великий, схема, яка використовується для передачі повідомлень між ланцюжками ZK, може бути на порядки більшою, ніж зведення та зберігання в ланцюжку, і накладні витрати на обчислення також дуже великі. Ймовірно, цю проблему можна подолати за допомогою більш централізованого підходу.
2**、Приклад рішення міжланцюжкового обміну повідомленнями**
· Su****ccinct Labs використовує легкий клієнт для перевірки консенсусу від вихідного ланцюга до рівня консенсусу цільового ланцюга. Ідея полягає в тому, що існує легкий клієнтський протокол, який гарантує, що вузли можуть синхронізувати заголовки блоків остаточного стану блокчейну. ZKP використовується для створення консенсусних доказів.
· La****grange Labs створює неінтерактивне підтвердження стану крос-ланцюга. Лагранж доводить, що мережа відповідає за створення кореня стану. Кожен вузол Лагранжа містить частину закритого ключа фрагмента, який засвідчує стан певного ланцюжка. Кожен корінь стану — це пороговий корінь Verkle зі знаком, який можна використовувати для підтвердження стану певного ланцюга в певний час. Корінь стану є абсолютно загальним і може використовуватися в підтвердженні стану, щоб підтвердити поточний стан будь-якого одного контракту або гаманця в ланцюжку.
· He****rodotus використовує підтвердження зберігання ZKP, щоб надавати розумні контракти та синхронно отримувати доступ до даних у ланцюжку інших рівнів Ethereum. Для перевірки він використовує власні повідомлення L1<>L2 для синхронізації хешів блоків між зведеними пакетами Ethereum.
=нуль; Foundation (Mina, L1) дозволяє розумним контрактам на Ethereum перевіряти дійсність стану Mina. Створюйте спеціальні підтвердження стану, дешеві для перевірки на Ethereum (локальні підтвердження Mina на Ethereum дорогі). Гіпотетично (десь у майбутньому) додатки зможуть напряму використовувати інструмент створення доказів Mina для перевірки дійсності міжланцюжкових транзакцій. = нуль; Foundation також має Ринок доказів, де користувачі/проекти можуть переважно купувати/продавати докази SNARK, які забезпечують надійний доступ до даних.
Axiom: якщо Axiom наразі згенерувала ZKP для книги, їй не потрібно генерувати ZKP для певного блоку, вона може передати цю ZKP у ланцюжок (як ретранслятор) або навіть надає доступ до цього ЖКП.
3. Межланцюгова передача повідомлень L2
*Відмова від відповідальності: міжланцюговий обмін повідомленнями все ще розвивається для більшої частини L2. Весь наведений нижче аналіз базується на інформації з відкритих джерел. Тим не менш, рішення, згадані в статті, можуть перебувати на стадії дослідження та тестування, а зведений пакет може з часом застосувати інші методи. *
**（1）**Тайко
Taiko зберігає блочні хеші для кожного ланцюжка. Для кожної пари ланцюжків він розгортає два смарт-контракти, які зберігають хеші один одного. У прикладі L2←→L1, кожного разу, коли блок L2 створюється на Taiko, хеш-значення периферійних блоків на L1 зберігаються в контракті TaikoL2. Також у випадку L1←→L2 режим роботи такий самий.
Останній відомий корінь Merkle, що зберігається в цільовому ланцюжку, можна отримати, викликавши getCrossChainBlockHash(0) у контракті TaikoL1/TaikoL2 і отримавши значення/повідомлення для перевірки. Хеш-сестер останнього відомого кореня Merkle можна отримати, викликавши запит eth_getProof за допомогою стандартного RPC у «вихідному ланцюжку».
Потім просто надішліть їх на перевірку щодо останніх відомих хешів блоків, які зберігаються в списку в «цільовому ланцюжку». Валідатор візьме значення (листок на дереві Merkle) і однорідні хеші, щоб повторно обчислити корінь Merkle і перевірити, чи він відповідає кореню, збереженому в списку хешів блоків цільового ланцюга.
**（2）**Starknet
Starknet використовує Proof of Storage для надійного міжланкового обміну повідомленнями.
L2→L1 протокол обміну повідомленнями
· Під час виконання транзакції Starknet контракт на Starknet надсилає повідомлення L2→L1.
Параметри повідомлення (що містять договір одержувача та відповідні дані на L1) потім додаються до відповідного оновлення стану (основне дерево зберігання).
· Повідомлення L2 зберігаються на L1 смарт-контракту.
· Видавати подію на L1 (зберігати параметри повідомлення).
Адреси одержувачів на L1 можуть отримати доступ і використовувати повідомлення як частину транзакції L1 шляхом повторного надання параметрів повідомлення.
· Міжланцюгові повідомлення зберігаються в дереві стовбура.
L2 → L1
L1 → L2
**（3）**Оптимізм
Зв'язок між L1 і L2 реалізується за допомогою двох спеціальних смарт-контрактів, які називаються «месенджерами».
· Для транзакцій Optimism (L2) до Ethereum (L1) необхідно надати підтвердження Merkle повідомлення на L1 після запису кореня стану. Після того, як ця перевірна транзакція стане частиною ланцюга L1, починається період перевірки помилок. Після цього періоду очікування будь-який користувач може «завершити» транзакцію, запустивши другу транзакцію в Ethereum, надіславши повідомлення цільовому контракту L1.
· Міжланцюгові повідомлення зберігаються в дереві стовбура.
（4）Ar****бітрум
Квитки з можливістю повторної спроби — це канонічний метод, який Arbitrum використовує для створення повідомлень L1-L2, тобто транзакцій L1, які ініціалізують повідомлення для виконання на L2. Retryable можна надіслати на L1 за фіксовану плату (залежить лише від розміру даних виклику). Основне дерево станів використовується для перехресного обміну користувацькими форматами даних у смарт-контрактах. Надсилання повторного квитка на L1 є відокремленим/асинхронним від виконання на L2. Повторні спроби забезпечують атомарність між міжланцюжковими операціями. Якщо запит на транзакцію L1 подано успішно (тобто без відкоту), то повторне виконання на L2 має сильну гарантію того, що врешті-решт воно буде успішним.
Arbitrum має два стовбури: ланцюг Nitro підтримується у форматі дерева стану Ethereum, дереві Merkle. Дерево тверджень зберігає стан ланцюга Arbitrum, підтвердженого на Ethereum за допомогою «твердження». Правила, які просувають ланцюг Arbitrum, є детермінованими. Це означає, що враховуючи стан ланцюга та деякі нові вхідні значення, є лише один дійсний вихід. Таким чином, якщо дерево доказів містить кілька листів, щонайбільше один лист може представляти дійсний стан ланцюга.
Система вихідних повідомлень Arbitrum дозволяє будь-який договірний виклик від L2 до L1, тобто повідомлення ініціюється з L2 і остаточно виконується на L1. Повідомлення з рівня L2 на L1 (так звані «вихідні повідомлення») мають багато спільного з повідомленнями Arbitrum L1 на L2 (Retryable), хоча є деякі помітні відмінності. Частина стану L2 ланцюга Arbitrum, тобто частина, засвідчена в кожному RBlock, є коренем Merkle усіх повідомлень L2 до L1 в історії ланцюга. Після підтвердження перевіреного RBlock (зазвичай приблизно через тиждень після підтвердження), корінь Merkle включається в контракт Outbox і публікується в L1. Потім контракт «Вихідні» дозволяє користувачам виконувати свої повідомлення.
**（5）**Полігон zkEVM
· Bridge SC цього zkEVM використовує спеціальне дерево Merkle під назвою Exit Tree для кожної мережі, яка бере участь у комунікації або транзакції активів.
Він використовує коріння Merkle (в окремому дереві станів), діаграму архітектури мосту можна знайти на github.
Розгортання zkEVM Bridge SC внесло кілька змін на основі депозитного контракту Ethereum 2.0. Наприклад, він використовує спеціально розроблене дерево Merkle лише для додавання, але використовує ту ж логіку, що й депозитний контракт Ethereum 2.0. Інші відмінності стосуються базових хешів і листових вузлів.
Основною особливістю смарт-контракту Polygon zkEVM Bridge є використання дерева виходу та глобального дерева виходу, де корінь глобального дерева виходу є основним джерелом істинного стану. Тому L1 і L2 мають два різних глобальних кореневих менеджера виходу, а Bridge SC має окрему логіку.
（6）S****прокрутка
· Містові контракти, розгорнуті на Ethereum і Scroll, дозволяють користувачам передавати довільні повідомлення між L1 і L2. На додаток до цього протоколу обміну повідомленнями ми також створили безнадійний протокол з’єднання, щоб дозволити користувачам з’єднувати ресурси ERC-20 між L1 і L2. Щоб надіслати повідомлення або кошти з Ethereum на Scroll, користувач викликає транзакцію sendMessage у контракті Bridge. Ретранслятори проіндексують цю транзакцію на L1 і надішлють її замовнику для включення в блоки L2. У договорі мосту L2 процес надсилання повідомлення від Scroll back до Ethereum схожий.
· Міжланцюгові повідомлення зберігаються в звичайних чергах повідомлень. Замовник отримує міжланцюгові повідомлення з цієї черги та додає їх до ланцюжка як звичайні транзакції.
**（7）**zksync Era
*Відмова від відповідальності: вміст у цьому розділі стосується лише zksync Era, яка може відрізнятися від міжланцюжкових повідомлень у ZK Stack, який є модульною структурою для побудови суверенного суперланцюга ZK. *
· Кожен пакет транзакцій має одне повідомлення L2->L1.
· Неможливо надіслати транзакції безпосередньо з L2 на L1. Однак ви можете надсилати повідомлення будь-якої довжини з zkSync Era в Ethereum, а потім обробляти отримані повідомлення в Ethereum за допомогою смарт-контракту L1. У zkSync Era є функція перевірки запиту, яка повертає логічний параметр, який вказує, чи було повідомлення успішно надіслано на L1. Отримайте доказ Merkle, що міститься в повідомленні, спостерігаючи за Ethereum або використовуючи метод zks_getL2ToL1LogProof API zksync-web3.
· Для L1→L2 смарт-контракт zkSync Era дозволяє відправнику запитувати транзакцію на Ethereum L1 і передавати дані в zkSync Era L2.
· Містовий договір:
4 Висновок
Міжланцюгова комунікація є невід’ємною частиною «обов’язкових» додатків для масового впровадження блокчейну (наприклад, міжланцюговий гаманець соціального відновлення, описаний у статті Vitalik). Більшість крос-ланцюгових рішень, які зараз використовуються, розроблені для L1 ←→ L2, щоб охопити функцію вилучення. Ці рішення можна розширити до більшої кількості блокчейнів. Але в той же час можна реалізувати більш просунуті міжланцюгові комунікаційні рішення, такі як «стан прямого читання» без підтвердження взагалі або «доказ зберігання» без довіри. Для більшості L2 все ще є місце для вдосконалення міжланцюгового зв’язку.
Переглянути оригінал
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
Дослідіть комунікацію між мережами з точки зору згортання
Автор: Lisa A., Taiko Labs; переклад: Jinse Finance xiaozou
У цій статті обговорюватимуться різні методи міжланцюгового обміну повідомленнями L2 з точки зору зведення, зосереджуючись на міжланцюжному зв’язку без довіри. Ми коротко розглянемо підхід прямого читання стану, підхід легкого клієнта та підтвердження зберігання. Ми також розглянемо механізм агрегування доказів, довірену передачу міжланцюжкових повідомлень третьої сторони та основні крос-ланцюгові рішення ZK. Нарешті, давайте подивимося, як різні L2 реалізують міжланцюговий обмін повідомленнями сьогодні.
1. Вступ до міжланцюжкового обміну повідомленнями
Для перехресного зв’язку всі сторони (L2, L3 тощо) повинні мати прямий доступ до останнього кореня стану Ethereum.
Усі депозитні рівні мають «вбудований» крос-чейн механізм, який можна використовувати для доступу до кореня стану L1, який буде передано L2 як повідомлення про депозит.
1**.1** Два типи доступу до кореня стану
Тип 1: Читати кореневий стан напряму - це можна зробити через код операції або попередньо скомпільований. Однак він досі не реалізований, тому докази не потрібні.
Брехт Девос описує можливий метод прямого зчитування стану в дослідницькій статті: "...ми можемо представити попередньо скомпільований контракт, який може безпосередньо викликати смарт-контракт у цільовому ланцюжку. Цей попередньо скомпільований безпосередньо в вихідному ланцюжку вставляє та виконує код смарт-контракту іншого ланцюга Це гарантує, що смарт-контракти завжди матимуть доступ до останнього доступного стану ефективним і легко доведеним способом».
· Також описано в RFP компанії Optimism «Доказ концепції віддаленого статичного виклику».
Тип 2: Генерація доказів - тобто підтвердження твердження про один блокчейн на іншому блокчейні.
«Крос-ланцюжок обміну повідомленнями з доказами» має два підходи:
· Ненадійний міжланцюговий зв’язок — тобто відсутність надійних третіх сторін (наприклад, використання легких клієнтів або підтвердження зберігання). Підхід без довіри може використовуватися як для сторонньої генерації доказів, так і для того, щоб учасники міжланцюгового зв’язку генерували докази самостійно.
Докази розподіляються між різними зведеннями для забезпечення міжланцюжкових операцій. Цей підхід, який мало обговорюється в цій статті, зараз знаходиться на стадії дослідження та не вважається потенційно широко застосовним рішенням.
1**.2** Метод «Міжланцюговий обмін повідомленнями з доказом»
1.2.1 Легкий міжланковий обмін повідомленнями
Доведіть дані про ланцюжок В
Отримайте дані перевірки Merkle від повного вузла ланцюга B (вузол архівування архіву, якщо потрібне підтвердження зберігання для певних історичних станів);
Надішліть заголовок блоку та перевірочні дані, що відповідають блоку ланцюжка B, що містить стан, який ми хочемо перевірити, до контракту перевірки на ланцюжку A як дані виклику;
Контракт перевірки обчислює хеш-значення блоку на основі даних заголовка блоку, запитує інтелектуальний контракт легкого клієнта в ланцюжку A (відстежує хеш-значення блоку в ланцюжку B) і перевіряє, чи дійсне хеш-значення;
Дані підтвердження перевіряються на корінь стану bytes32 у заголовку блоку.
1**.2.2** Доказ зберігання
Proof of Storage має два варіанти «робочого процесу»:
· Згенеруйте підтвердження зберігання → використовуйте в ланцюжку
· Створити доказ зберігання → створити доказ zk → використовувати в ланцюжку
Суб’єкт також може упакувати кілька колекцій доказів в єдиний доказ (як доказ зберігання, так і доказ zk). Це необов’язковий крок оптимізації, який ще не обговорюється.
Давайте розглянемо три основні етапи «робочого процесу» підтвердження зберігання: генерація підтвердження зберігання, генерація підтвердження zk і використання його в ланцюжку.
(1) Створення підтвердження зберігання
· Підтвердження зберігання дозволяє нам використовувати конфіденційне зобов’язання, щоб довести, що певна інформація існує в блокчейні та є правдивою;
Підтвердження зберігання є частиною криптопростору з моменту появи дерев Merkle у 1979 році. Однак ванільні стійки до зберігання зазвичай досить великі. Сучасна інновація полягає в поєднанні підтвердження зберігання з перевіреними обчисленнями для створення коротких доказів, які можна перевірити в мережі.
Щоб згенерувати підтвердження зберігання, необхідно надати певний блок даних і пов’язаний із ним шлях Merkle або Verkle у дереві Merkle. Шлях складається з однорідних хешів, необхідних для реконструкції кореневого хешу за допомогою того самого алгоритму хешування.
Щоб підтвердити підтвердження зберігання, одержувач може використати надані дані та шлях Merkle або Verkle для повторного обчислення кореневого хешу. Якщо перерахований кореневий хеш відповідає відомому кореневому хешу, одержувач може бути впевнений, що дані автентичні та є частиною наданого набору даних.
(2) Створення ZKP (доказ нульового знання)
Однак підтвердження зберігання типу Ethereum становить близько 4 Кб — це досить великий розмір для розміщення всього підтвердження зберігання в цільовому ланцюжку, оскільки перевірка підтвердження буде дуже дорогою. Тому для стиснення доцільно використовувати ЗКП (наприклад, ЗК-СНАРК), що може зробити доказ меншим і дешевшим у перевірці.
（3）A****roll ZKP
Після отримання ZKP користувачі в цільовому ланцюжку можуть розгортати свої зароблені докази (наприклад, отримати доступ до історичного стану через заголовки блоків або хеші блоків).
Розгорнути можна наступним чином:
Накопичення в ланцюжку: Весь процес реконструкції заголовків блоків із доказів виконується безпосередньо в ланцюжку блоків. Недоліки: висока комісія за газ, споживання обчислювальних ресурсів; переваги: відсутність додаткового часу на підтвердження, низька затримка, оскільки немає необхідності генерувати підтвердження поза блокчейном.
Стиснення в ланцюжку: видаліть зайву або непотрібну інформацію з даних або використовуйте структури даних, оптимізовані для економії простору. Стиснуті дані надсилаються в блокчейн і можуть бути розпаковані за потреби. Мінуси: стиснення та розпакування даних може означати додаткові обчислення, але ця затримка може бути незначною. Використаний алгоритм стиснення може мати негативний вплив на безпеку даних; перевага: зменшити витрати на дані.
Зберігання поза мережею: Зберігайте дані поза мережею та розміщуйте певні блоки даних у мережі за запитом. Це актуально для рішень, яким з якихось причин потрібно зберігати великі обсяги даних (наприклад, вузли архіву Ethereum з блоку genesis). Мінуси: те саме, що й стиснення в ланцюжку; Плюси: подальше зниження витрат на дані.
1**.2.3** Довірена третя сторона
Повне крос-чейн рішення також має включати рішення для перехресного обміну повідомленнями з довіреними третіми сторонами (такими як оракули, централізовані мости тощо).
1**.2.4** «Універсальна» система перевірки
У випадку спільного механізму платформи підтвердження агрегації обмін повідомленнями можна пришвидшити, отримуючи хеші блоків, які встановлюються на платформі агрегації, і тут також оброблятиметься обмін повідомленнями (але якщо є проблема з платформою агрегації, що робити?).
1**.2.5 Деякі невідомі проблеми ZK****міжланцюжкового обміну повідомленнями**
Чи можливий міжланцюговий обмін повідомленнями без довіреної третьої сторони (яка може бути однією організацією або кількома сутностями)? Що таке ефективний механізм передачі повідомлень між ланцюжками? Загалом, для Ethereum L2 (з прямим доступом до блокових хешів L1) і самого Ethereum, якщо один ланцюжок може запускати легкий клієнт тощо, чого достатньо для безнадійного обміну повідомленнями між ланцюжками.
Чи належним чином масштабовано схему ZK, яка використовується для генерації доказів крос-ланцюгів? У деяких випадках, особливо коли рівень консенсусу (який потрібно перевірити для міжланцюжкових операцій) дуже великий, схема, яка використовується для передачі повідомлень між ланцюжками ZK, може бути на порядки більшою, ніж зведення та зберігання в ланцюжку, і накладні витрати на обчислення також дуже великі. Ймовірно, цю проблему можна подолати за допомогою більш централізованого підходу.
2**、Приклад рішення міжланцюжкового обміну повідомленнями**
· Su****ccinct Labs використовує легкий клієнт для перевірки консенсусу від вихідного ланцюга до рівня консенсусу цільового ланцюга. Ідея полягає в тому, що існує легкий клієнтський протокол, який гарантує, що вузли можуть синхронізувати заголовки блоків остаточного стану блокчейну. ZKP використовується для створення консенсусних доказів.
· La****grange Labs створює неінтерактивне підтвердження стану крос-ланцюга. Лагранж доводить, що мережа відповідає за створення кореня стану. Кожен вузол Лагранжа містить частину закритого ключа фрагмента, який засвідчує стан певного ланцюжка. Кожен корінь стану — це пороговий корінь Verkle зі знаком, який можна використовувати для підтвердження стану певного ланцюга в певний час. Корінь стану є абсолютно загальним і може використовуватися в підтвердженні стану, щоб підтвердити поточний стан будь-якого одного контракту або гаманця в ланцюжку.
· He****rodotus використовує підтвердження зберігання ZKP, щоб надавати розумні контракти та синхронно отримувати доступ до даних у ланцюжку інших рівнів Ethereum. Для перевірки він використовує власні повідомлення L1<>L2 для синхронізації хешів блоків між зведеними пакетами Ethereum.
=нуль; Foundation (Mina, L1) дозволяє розумним контрактам на Ethereum перевіряти дійсність стану Mina. Створюйте спеціальні підтвердження стану, дешеві для перевірки на Ethereum (локальні підтвердження Mina на Ethereum дорогі). Гіпотетично (десь у майбутньому) додатки зможуть напряму використовувати інструмент створення доказів Mina для перевірки дійсності міжланцюжкових транзакцій. = нуль; Foundation також має Ринок доказів, де користувачі/проекти можуть переважно купувати/продавати докази SNARK, які забезпечують надійний доступ до даних.
Axiom: якщо Axiom наразі згенерувала ZKP для книги, їй не потрібно генерувати ZKP для певного блоку, вона може передати цю ZKP у ланцюжок (як ретранслятор) або навіть надає доступ до цього ЖКП.
3. Межланцюгова передача повідомлень L2
*Відмова від відповідальності: міжланцюговий обмін повідомленнями все ще розвивається для більшої частини L2. Весь наведений нижче аналіз базується на інформації з відкритих джерел. Тим не менш, рішення, згадані в статті, можуть перебувати на стадії дослідження та тестування, а зведений пакет може з часом застосувати інші методи. *
**（1）**Тайко
Taiko зберігає блочні хеші для кожного ланцюжка. Для кожної пари ланцюжків він розгортає два смарт-контракти, які зберігають хеші один одного. У прикладі L2←→L1, кожного разу, коли блок L2 створюється на Taiko, хеш-значення периферійних блоків на L1 зберігаються в контракті TaikoL2. Також у випадку L1←→L2 режим роботи такий самий.
Останній відомий корінь Merkle, що зберігається в цільовому ланцюжку, можна отримати, викликавши getCrossChainBlockHash(0) у контракті TaikoL1/TaikoL2 і отримавши значення/повідомлення для перевірки. Хеш-сестер останнього відомого кореня Merkle можна отримати, викликавши запит eth_getProof за допомогою стандартного RPC у «вихідному ланцюжку».
Потім просто надішліть їх на перевірку щодо останніх відомих хешів блоків, які зберігаються в списку в «цільовому ланцюжку». Валідатор візьме значення (листок на дереві Merkle) і однорідні хеші, щоб повторно обчислити корінь Merkle і перевірити, чи він відповідає кореню, збереженому в списку хешів блоків цільового ланцюга.
**（2）**Starknet
Starknet використовує Proof of Storage для надійного міжланкового обміну повідомленнями.
L2→L1 протокол обміну повідомленнями
· Під час виконання транзакції Starknet контракт на Starknet надсилає повідомлення L2→L1.
Параметри повідомлення (що містять договір одержувача та відповідні дані на L1) потім додаються до відповідного оновлення стану (основне дерево зберігання).
· Повідомлення L2 зберігаються на L1 смарт-контракту.
· Видавати подію на L1 (зберігати параметри повідомлення).
Адреси одержувачів на L1 можуть отримати доступ і використовувати повідомлення як частину транзакції L1 шляхом повторного надання параметрів повідомлення.
· Міжланцюгові повідомлення зберігаються в дереві стовбура.
L2 → L1
L1 → L2
**（3）**Оптимізм
Зв'язок між L1 і L2 реалізується за допомогою двох спеціальних смарт-контрактів, які називаються «месенджерами».
· Для транзакцій Optimism (L2) до Ethereum (L1) необхідно надати підтвердження Merkle повідомлення на L1 після запису кореня стану. Після того, як ця перевірна транзакція стане частиною ланцюга L1, починається період перевірки помилок. Після цього періоду очікування будь-який користувач може «завершити» транзакцію, запустивши другу транзакцію в Ethereum, надіславши повідомлення цільовому контракту L1.
· Міжланцюгові повідомлення зберігаються в дереві стовбура.
（4）Ar****бітрум
Квитки з можливістю повторної спроби — це канонічний метод, який Arbitrum використовує для створення повідомлень L1-L2, тобто транзакцій L1, які ініціалізують повідомлення для виконання на L2. Retryable можна надіслати на L1 за фіксовану плату (залежить лише від розміру даних виклику). Основне дерево станів використовується для перехресного обміну користувацькими форматами даних у смарт-контрактах. Надсилання повторного квитка на L1 є відокремленим/асинхронним від виконання на L2. Повторні спроби забезпечують атомарність між міжланцюжковими операціями. Якщо запит на транзакцію L1 подано успішно (тобто без відкоту), то повторне виконання на L2 має сильну гарантію того, що врешті-решт воно буде успішним.
Arbitrum має два стовбури: ланцюг Nitro підтримується у форматі дерева стану Ethereum, дереві Merkle. Дерево тверджень зберігає стан ланцюга Arbitrum, підтвердженого на Ethereum за допомогою «твердження». Правила, які просувають ланцюг Arbitrum, є детермінованими. Це означає, що враховуючи стан ланцюга та деякі нові вхідні значення, є лише один дійсний вихід. Таким чином, якщо дерево доказів містить кілька листів, щонайбільше один лист може представляти дійсний стан ланцюга.
Система вихідних повідомлень Arbitrum дозволяє будь-який договірний виклик від L2 до L1, тобто повідомлення ініціюється з L2 і остаточно виконується на L1. Повідомлення з рівня L2 на L1 (так звані «вихідні повідомлення») мають багато спільного з повідомленнями Arbitrum L1 на L2 (Retryable), хоча є деякі помітні відмінності. Частина стану L2 ланцюга Arbitrum, тобто частина, засвідчена в кожному RBlock, є коренем Merkle усіх повідомлень L2 до L1 в історії ланцюга. Після підтвердження перевіреного RBlock (зазвичай приблизно через тиждень після підтвердження), корінь Merkle включається в контракт Outbox і публікується в L1. Потім контракт «Вихідні» дозволяє користувачам виконувати свої повідомлення.
**（5）**Полігон zkEVM
· Bridge SC цього zkEVM використовує спеціальне дерево Merkle під назвою Exit Tree для кожної мережі, яка бере участь у комунікації або транзакції активів.
Він використовує коріння Merkle (в окремому дереві станів), діаграму архітектури мосту можна знайти на github.
Розгортання zkEVM Bridge SC внесло кілька змін на основі депозитного контракту Ethereum 2.0. Наприклад, він використовує спеціально розроблене дерево Merkle лише для додавання, але використовує ту ж логіку, що й депозитний контракт Ethereum 2.0. Інші відмінності стосуються базових хешів і листових вузлів.
Основною особливістю смарт-контракту Polygon zkEVM Bridge є використання дерева виходу та глобального дерева виходу, де корінь глобального дерева виходу є основним джерелом істинного стану. Тому L1 і L2 мають два різних глобальних кореневих менеджера виходу, а Bridge SC має окрему логіку.
（6）S****прокрутка
· Містові контракти, розгорнуті на Ethereum і Scroll, дозволяють користувачам передавати довільні повідомлення між L1 і L2. На додаток до цього протоколу обміну повідомленнями ми також створили безнадійний протокол з’єднання, щоб дозволити користувачам з’єднувати ресурси ERC-20 між L1 і L2. Щоб надіслати повідомлення або кошти з Ethereum на Scroll, користувач викликає транзакцію sendMessage у контракті Bridge. Ретранслятори проіндексують цю транзакцію на L1 і надішлють її замовнику для включення в блоки L2. У договорі мосту L2 процес надсилання повідомлення від Scroll back до Ethereum схожий.
· Міжланцюгові повідомлення зберігаються в звичайних чергах повідомлень. Замовник отримує міжланцюгові повідомлення з цієї черги та додає їх до ланцюжка як звичайні транзакції.
**（7）**zksync Era
*Відмова від відповідальності: вміст у цьому розділі стосується лише zksync Era, яка може відрізнятися від міжланцюжкових повідомлень у ZK Stack, який є модульною структурою для побудови суверенного суперланцюга ZK. *
· Кожен пакет транзакцій має одне повідомлення L2->L1.
· Неможливо надіслати транзакції безпосередньо з L2 на L1. Однак ви можете надсилати повідомлення будь-якої довжини з zkSync Era в Ethereum, а потім обробляти отримані повідомлення в Ethereum за допомогою смарт-контракту L1. У zkSync Era є функція перевірки запиту, яка повертає логічний параметр, який вказує, чи було повідомлення успішно надіслано на L1. Отримайте доказ Merkle, що міститься в повідомленні, спостерігаючи за Ethereum або використовуючи метод zks_getL2ToL1LogProof API zksync-web3.
· Для L1→L2 смарт-контракт zkSync Era дозволяє відправнику запитувати транзакцію на Ethereum L1 і передавати дані в zkSync Era L2.
· Містовий договір:
4 Висновок
Міжланцюгова комунікація є невід’ємною частиною «обов’язкових» додатків для масового впровадження блокчейну (наприклад, міжланцюговий гаманець соціального відновлення, описаний у статті Vitalik). Більшість крос-ланцюгових рішень, які зараз використовуються, розроблені для L1 ←→ L2, щоб охопити функцію вилучення. Ці рішення можна розширити до більшої кількості блокчейнів. Але в той же час можна реалізувати більш просунуті міжланцюгові комунікаційні рішення, такі як «стан прямого читання» без підтвердження взагалі або «доказ зберігання» без довіри. Для більшості L2 все ще є місце для вдосконалення міжланцюгового зв’язку.