*Переслати оригінальну назву: Вивчення канонічного мосту і системи доведення Eclipse в Ethereum

Огляд нашого канонічного мосту

Eclipse складається з трьох шарів:

1. Виконання: Форк клієнта Solana Labs(v1.17) для виконання SVM-транзакцій
2. Розрахунок: Наш канонічний міст, що визначає правило вибору форків Eclipse, існує і в Ethereum, де також будуть представлені докази шахрайства
3. Доступність даних: Eclipse публікує дані, необхідні для створення доказів шахрайства, у вигляді блоків даних на Celestia

На діаграмі нижче показано, як ці модулі взаємодіють між собою:

Решта статті буде присвячена мосту Ethereum в Eclipse, як показано на схемі. Blobstream буде передавати підтвердження, підписані валідатором Celestia, який засвідчує Ethereum, що дані про партію слотів Eclipse були опубліковані коректно. Це дозволяє мосту Eclipse звіряти дані, надані для перевірки на шахрайство, з підписаними кореневими даними від Celestia. У решті частини цього розділу ми опишемо процеси, за допомогою яких:

1. кошти вносяться через наш міст,
2. на Celestia публікуються блоки даних партій блоків Eclipse,
3. виведення коштів через міст обробляється, і
4. докази шахрайства генеруються в найгіршому випадку.

Поповнення рахунку через нативний Ethereum-міст Eclipse

Потік, коли користувач вносить кошти на Eclipse через власний міст Ethereum, виглядає наступним чином:

1. Користувач називає контракт депозитного мосту Eclipse на Ethereum
2. Зсередини SVM-виконавця Eclipse [1] ретранслятор [2] спостерігає за депозитом користувача та адресою призначення
3. Далі релеєр викликає програму-міст SVM, яка відповідає за переказ депозиту користувача на відповідну адресу призначення
4. Релеєр верифікує депозитну транзакцію за допомогою клієнта zk-light (буде реалізовано)
5. Нарешті, блок, що містить наступну транзакцію переказу після депозиту, завершується і публікується за допомогою плагінаSolana Geyser

На діаграмі нижче показано взаємодію між Ethereum, Celestia та Виконавцем SVM під час потоку депозитів, описаного вище:

Публікація слотів Eclipse в Celestia у вигляді блоків даних

Нижче показано процес публікації партій слотів Eclipse до Celestia у вигляді блоків даних:

1. Виконавець SVM публікує кожен слот Eclipse у чергу повідомлень через Geyser
2. SVM-виконавець надсилає партії слотів Eclipse до Celestia у вигляді блоків даних
3. Набір валідаторів Celestia генерує зобов'язання до наданих блоків даних, які можуть бути використані для доказу включення транзакції в ланцюжок Eclipse проти кореня даних
4. Корені даних, що містяться в кожному заголовку блоку Celestia, передаються до мостового контракту Eclipse на Ethereum через Blobstream

Наведена нижче діаграма з Celestia пояснює, як зобов'язання щодо даних у певному блоці Celestia зберігаються в заголовку блоку:

Виведення та надсилання доказів шахрайства на Ethereum-міст Eclipse

Подібно до інших L2, які використовують докази шахрайства (Arbitrum, Fuel і багато інших), виведення коштів з Eclipse вимагає періоду оскарження, протягом якого верифікатори можуть надати докази шахрайства в разі недійсного переходу в інший стан:

1. На регулярній каденції SVM-виконавець розміщує в Ethereum зобов'язання на епоху (заздалегідь визначену кількість партій) слотів Eclipse разом із заставою
2. У рамках мостового контракту Eclipse проводить деякі базові перевірки, щоб переконатися, що розміщені дані правильно сформовані (описано в розділі "Захист від шахрайства").
3. Якщо надіслана партія проходить ці базові перевірки, існує заздалегідь визначене вікно, протягом якого верифікатори можуть опублікувати докази шахрайства у випадку, якщо зобов'язання партії передбачає недійсний перехід до іншого стану
4. Якщо верифікатор публікує успішний доказ шахрайства, він виграє заставу виконавця, опублікована партія відхиляється, а канонічний стан Eclipse L2 відкочується до останнього дійсного зобов'язання щодо партії. У цьому випадку керівництво Eclipse матиме можливість обрати нового виконавця
5. Якщо період оскарження закінчується без успішного доведення шахрайства, виконавець повертає заставу разом із винагородою
6. Таким чином, бридж-контракт Eclipse завершить всі транзакції з виведення коштів, які були включені у фінальну партію

Дизайн із захистом від шахрайства

У цьому останньому розділі ми детально розглянемо дизайн системи захисту від шахрайства Eclipse, натхненний Анатолієм Яковенком та Джоном Адлером. Як правило, для будь-якого доказу шахрайства потрібен верифікатор:

1. Виявити транзакцію, що містить неприпустимий перехід стану
2. Надайте вхідні дані для зазначеної транзакції з неприпустимим переходом у стан
3. Продемонструвати, що повторне виконання зазначеної транзакції із заданими вхідними даними призводить до результату, який не дорівнює тому, що було зафіксовано в ланцюжку

У випадку Eclipse, (1) Celestia мерклізує блоки партій блоків, які відправляє SVM-виконавець Eclipse, забезпечуючи докази включення транзакцій через свідків Меркла. Для (2), на відміну від L2 на основі EVM, які розміщують корінь Меркла у глобальному дереві станів, з міркувань продуктивності Eclipse не оновлює глобальне дерево станів для кожної транзакції, але ми пояснимо, як ми забезпечуємо коректність вхідних даних більш детально нижче. Нарешті, у випадку (3), верифікатор Eclipse генерує zk-доказ виводу (виводів) для даної транзакції, на відміну від інтерактивного ігрового підходу до верифікації, поширеного в L2 на основі EVM.

Всі транзакції Eclipse можна представити як отримання списку вхідних рахунків, виконання транзакції та створення списку результуючих вихідних рахунків:

Критично важливим спостереженням для нашого дизайну захисту від шахрайства є те, що для виконання транзакції будь-який S_InputAccount має бути S_OutputAccount'ом якоїсь попередньої транзакції. Це дозволяє нам посилатися на останню транзакцію в ланцюжку, яка створила даний вхідний обліковий запис, замість того, щоб надавати свідчення Меркла до глобального дерева станів. В результаті нашої розробки ми ввели додаткові типи звинувачень у шахрайстві, такі як посилання на те, що попередня транзакція не є дійсною, або що вхідний рахунок вже "витрачено" якоюсь пізнішою транзакцією. Нижче ми опишемо цей процес більш детально:

Вхідні дані транзакції відправлено до Celestia

1. Дані транзакції (розміщені секвенсором)
2. Дані транзакції (відправлені виконавцем SVM), які містять наступне:
   1. Кількість транзакцій [3]
   2. Розташування даних про транзакції в просторі імен Celestia
   3. Хеш облікового запису [4] для кожного входу, з кількістю транзакцій, отриманих в результаті для кожного
   4. Список використаних системних парамет рів та значення кожного з них, із зазначенням кількості транзакцій у кожному з них (якщо застосовно) [5].
   5. Висновок транзакції, якщо транзакція була успішною; в іншому випадку, індикатор того, що транзакція не відбулася (або через те, що вона не змогла розібратись, або через те, що вона не змогла виконатись)

Опубліковані пакетні зобов'язання на Ethereum Bridge

Крім того, пакети даних про транзакції, розміщені в Celestia, мають зобов'язання, що передаються в контракт Ethereum. Зобов'язання складаються з наступного:

1. Розташування в просторі імен Celestia даних останньої транзакції, включеної до пакета
2. Простір імен Celestia, в якому зберігаються дані про виконання [6] всіх включених транзакцій
3. Список депозитів, виведень і перевизначень, кожен з яких супроводжується лічильником транзакцій відповідної Eclipse-транзакції

Критерії недійсної партії

Як пояснювалося вище, є кілька способів, як можна виявити, що партія є некоректною:

1. Одне з посилань на простір імен Celestia має неправильну форму або не вказує на дані потрібного типу
2. Існує транзакція на Celestia без пов'язаних з нею даних про виконання, що може бути пов'язано з двома причинами:
   1. Транзакція, яка повинна була бути останньою в пакеті, не має пов'язаних з нею даних про виконання.
      1. В такому випадку верифікатор перевіряє, чи це так, а мостовий контракт Ethereum перевіряє, чи не відповідає останній запис у списку даних виконання правильним даним транзакції
   2. Відсутні дані виконання іншої транзакції
      1. Верифікатор розміщує в просторі імен Celestia дані про транзакцію, що порушила правила, а також попередні та наступні транзакції в порядку, в якому вони були успішно виконані. Після цього бридж-контракт перевіряє, що ця транзакція була пропущена
3. Існує транзакція, дані виконання якої є некоректними, що може бути викликано наступними причинами:
   1. Лічильник транзакцій, пов'язаний з хешем облікового запису або sysvar, не дає очікуваного результату.
      1. У цьому випадку верифікатор розміщує в просторі імен Celestia дані про виконання даної транзакції з відповідним лічильником, а бридж-контракт перевіряє, що вказане значення є некоректним.
   2. Лічильник транзакцій, пов'язаний з хешем або sysvar облікового запису, застарілий
      1. Верифікатор розміщує в просторі імен Celestia дані про виконання новішої транзакції, змінюючи відповідне значення, а мостовий контракт перевіряє, що вони дійсно новіші.
   3. Вихід транзакції невірний, або транзакція використовує вхідні дані, яких немає у списку:
      1. У цьому випадку потрібне zk-доказ правильності виконання транзакції або zk-доказ того, що транзакція використовує вхідні дані, яких немає у списку. Це можна отримати двома способами:
         1. Верифікатор публікує доказ, або
         2. Верифікатор публікує індекс транзакції, яка вважається шахрайською, і мостовий контракт Eclipse використовує його для отримання zk-доказу від RISC Zero's Bonsai
   4. Був зроблений депозит з Ethereum більш ніж N партій назад, але в списку транзакцій (включених в пакетне зобов'язання, розміщене в бридж-контракті) немає відповідного депозиту для N минулих партій. Або ж у списку транзакцій є депозит, але немає пов'язаної з ним депозитної транзакції Ethereum, або ж транзакція існує, але вже була включена в іншу партію Eclipse
      1. Брідж-контракт у всіх цих випадках може визначити, що це сталося, і вважати таку партію недійсною
   5. Виконано поповнення або зняття коштів без відповідного запису у списку транзакцій
      1. У такому випадку верифікатор публікує в просторі імен Celestia місцезнаходження даних про виконання, а бридж-контракт перевіряє цей факт, щоб визнати транзакцію недійсною
   6. У списку транзакцій є депозит або зняття коштів, пов'язана з яким транзакція Eclipse не виконує очікуваної дії або кількість транзакцій якої не відповідає очікуваному діапазону кількості транзакцій. У такому випадку станеться одна з наступних подій:
      1. Міст автоматично визначить, що це саме той випадок, і відхилить відповідну партію
      2. Верифікатор помічає недійсний перехід стану і публікує доказ порушення транзакції, який потім перевіряється мостовим контрактом

Якщо будь-яка партія зобов'язань буде визнана неправильною, бридж-контракт Eclipse відкотиться до останньої достовірно правильної партії зобов'язань. Зауважте, що транзакції ніколи не видаляються з ланцюжка, навіть у випадку шахрайства, тому переобчислювати потрібно лише зобов'язання.

Прощальні думки

Ця стаття має на меті надати високорівневе керівництво по мінімізованому мосту довіри Eclipse на Ethereum і пояснити деякі деталі нашого дизайну, що захищає від шахрайства. Враховуючи модульну природу нашого L2 і зародження нашого технологічного стеку, ми продовжимо випускати статті та документацію про різні аспекти Eclipse в найближчі тижні.

Щоб долучитися до Eclipse Testnet, будь ласка, дотримуйтесь наших інструкцій тут. Ви можете зв'язатися з нами через Twitter або Discord з конкретними запитами про нашу Testnet, міст або технічними питаннями.

Виноски

[1]: Вузол, який обчислює результати SVM-транзакцій і застосовує кінцевий результат до нового стану Eclipse

[2]: Оператор, який передає події в ланцюжку між Ethereum та Eclipse

[3]: Зверніть увагу, що це робить виконавець, а не секвенсор. Якби він був включений до даних, що надсилаються секвенсором, це б ускладнило роботу, оскільки секвенсор міг би пропустити якийсь такт, що унеможливило б правильне виконання роботи виконавцем. Це можна було б компенсувати захистом від шахрайства, але це додало б додаткової складності. Друга перевага того, що тільки виконавець публікує підрахунок, полягає в тому, що це дозволяє легко дозволити перевизначення транзакцій, якщо потрібно, публікувати їх у Celestia.

[4]: Облікові записи SVM можуть бути представлені унікальним хешем. Єдиний спосіб змінити цей хеш - через транзакцію.

[5]: Щоб зробити це без надмірного хешування, ми будемо запускати трасування кожної виконуваної програми, щоб побачити, до яких частин кожного використовуваного sysvar насправді відбувається доступ. Це можливо, але потребуватиме модифікації інтерпретатора BPF Solana.

[6]: Сюди входять дані про спроби транзакцій, які не були виконані.

Відмова від відповідальності:.

1. Ця стаття передрукована з [[дзеркало]], всі авторські права належать оригінальному автору[Eclipse]. Якщо у вас є заперечення щодо цього передруку, будь ласка, зв'яжіться з командою Gate Learn, і вони оперативно його опрацюють.
2. Відмова від відповідальності: Погляди та думки, висловлені в цій статті, належать виключно автору і не є інвестиційною порадою.
3. Переклади статті іншими мовами виконані командою Gate Learn. Якщо не зазначено інше, копіювання, розповсюдження або плагіат перекладених статей заборонені.