Across V4 представляє нову та вдосконалену кросчейн-архітектуру. Система поєднує наміри та докази з нульовим розголошенням (ZKP) для швидшого розширення на більшу кількість ланцюжків. Ось технічна розбивка. 🧵
Раніше Across використовувала «канонічні мости» або адаптери для конкретного ланцюга для перевірки повідомлень із HubPool Ethereum. Це чудово спрацювало для L2, таких як Arbitrum і Optimism, які виставляють доопрацьований стан Ethereum. Але цей дизайн був обмежуючим...
Для ланцюгів без EVM, таких як BSC, ця модель ламається. Не існує канонічного способу перевірити стан Ethereum. Це означало або створення користувацьких адаптерів, або відсутність підтримки цих ланцюгів взагалі. Ні те, ні інше не є оптимальним рішенням. Ось ми і придумали кращий спосіб використання ЗКП.
Ось процес дій: Коли ретранслятори виконують кросчейн-ордери, транзакції групуються в пакети погашення релайзерів, які потім перевіряються @UMAProtocol Optimistic Oracle. Це завжди відбувається в основній мережі Ethereum.
Як тільки пакет підтверджено, Across HubPool запускає процес врегулювання. Потім він записує хеші повідомлення про погашення до контракту HubPoolStore у конкретні слоти для зберігання. Ця подія зберігання також відбувається в основній мережі Ethereum.
Кожен хеш повідомлення в контракті HubPoolStore відповідає наміру погасити ретранслятор у ланцюжку призначення. Зверніть увагу, що повідомлення L1 → L2 можуть означати кілька погашень (включаючи повільне заповнення). Це пов'язано з тим, що вони є кореневими пучками.
Коли контракт HubPoolStore записує збережений хеш повідомлення, він видає подію StoredCallData. Ця подія містить хеш повідомлення та слот для зберігання. Подія + збережені дані формують якір для верифікації ZK далі за потоком.
Сервіс під назвою фіналізатор прислухається до цих подій. Як тільки він виявляє новий, він ініціює процес, щоб довести, що хеш повідомлення дійсно був написаний на Ethereum. Кожне повідомлення, для якого зберігається хеш, має ціль, яка може бути специфічною для його ланцюжка.
Цей доказ дозволяє безпечно виконати повідомлення в ланцюжку призначення. Але остаточність Ethereum не є миттєвою. Після того, як фіналізатор надішле дані до ZK API, API чекає на вікно остаточності Ethereum, перш ніж створити доказ.
Щоб згенерувати дійсний доказ ZK, комітет синхронізації Ethereum повинен підписатися під конкретним доопрацьованим блоком. Якщо повідомлення було включено в цей блок або до нього, стають доступними необхідні підписи для початку генерації доказу ZK.
Фіналізатор запитує ZK API, щоб згенерувати доказ того, що певний хеш повідомлення був записаний у відомий слот зберігання HubPoolStore у доопрацьованому блоці Ethereum. Це дає змогу беззаперечно перевіряти платежі ретрансляторів у будь-якому ланцюжку призначення.
ZK API готує доказові вхідні дані, включаючи (але не обмежуючись ними): - Доопрацьовані маячкові заголовки - Підписи комітетів синхронізації - Докази зберігання Merkle на рівні виконання Ethereum Вони складають основу для створення доказів.
Across розгортає загальний стек у ланцюгах призначення: - Контракт Verifier (підтверджує доказ ZK) - SP1Helios від @Succinct (зберігає доопрацьований стан Ethereum) - Контракт UniversalSpokepool (перевіряє автентичність повідомлень під час виконання)
Після того, як доказ ZK буде перевірено та стан підтверджено, executeMsg() може безпечно запустити корисне навантаження в цільовому ланцюжку. Не викликає довіри. Безпечний. Універсальний.
Це означає, що Across більше не потрібні спеціальні адаптери для кожного ланцюга. Лише один пайплайн, який працює скрізь: storeMsg() на Ethereum → доказ ZK → виконати Msg() у будь-якому ланцюжку призначення, який може перевірити доказ SP1Helios.
Жодних припущень щодо довіри. Без накладних витрат на інтеграцію. Просто наміри + ЗК.
Чому це важливо? Це значно розширює охоплення Across, розблоковуючи підтримку ланцюгів з довгим хвостом, які не можуть самостійно перевіряти стан Ethereum і не мають канонічних мостів. Це робить онбординг швидшим, безпечнішим і масштабованішим.
Поперек не потрібен канонічний міст для цих ланцюжків. Йому просто потрібна можливість верифікувати ZK-доказ стану Ethereum. Це зменшує накладні витрати на інтеграцію, дозволяє уникнути ризику централізованого мосту та посилює роль Ethereum як кореня правди про кросчейн.
Показати оригінал
7,71 тис.
42
Вміст на цій сторінці надається третіми сторонами. Якщо не вказано інше, OKX не є автором цитованих статей і не претендує на авторські права на матеріали. Вміст надається виключно з інформаційною метою і не відображає поглядів OKX. Він не є схваленням жодних дій і не має розглядатися як інвестиційна порада або заохочення купувати чи продавати цифрові активи. Короткий виклад вмісту чи інша інформація, створена генеративним ШІ, можуть бути неточними або суперечливими. Прочитайте статтю за посиланням, щоб дізнатися більше. OKX не несе відповідальності за вміст, розміщений на сторонніх сайтах. Утримування цифрових активів, зокрема стейблкоїнів і NFT, пов’язане з високим ризиком, а вартість таких активів може сильно коливатися. Перш ніж торгувати цифровими активами або утримувати їх, ретельно оцініть свій фінансовий стан.