Особлива подяка Джону Шарбоно та Конору Макменаміну за перегляд цієї статті.

На цьому етапі ми всі повинні знати, що правила підтвердження мають безпеку, а не самі зведення. Коли ми говоримо, що зведення успадковують «безпеку Ethereum» або що вони «з мінімізованою довірою», ми насправді маємо на увазі, що для зведень можна використовувати правила підтвердження, які мають приблизно такий самий рівень безпеки, як і правила підтвердження Ethereum. Проте дослідники блоків здебільшого піклуються про відображення зеленого значка, не вдаючись до подробиць, яке правило підтвердження вони мають на увазі чи які властивості безпеки вони надають.

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

Правила підтвердження: узгодженість проти доступності

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

Різні правила підтвердження дають користувачам різні гарантії безпеки. Безпека правила підтвердження включає послідовність і доступність і значною мірою залежить від базових алгоритмів консенсусу:

• Узгодженість (безпека): перегляд будь-яких двох вузлів є узгодженим у мережевих розділах.
• Доступність (жвавість): транзакції продовжують включатися в реєстр протягом деякого часу навіть після того, як значна частина вузлів припиняє участь у протоколі.

Теорема CAP говорить нам, що неможливо розробити алгоритм консенсусу, який залишається послідовним у розділах мережі та доступним за динамічної участі: якщо відбувається серйозне розділення мережі, вузли можуть або вирішити продовжувати створювати блоки та втратити узгодженість, або зупинитися та втратити доступність. Немає способу для вузлів розрізнити інші, які просто офлайн (динамічна участь) або активні, але недоступні (розділи мережі), і тому неможливо діяти інакше.

Єва не може знати, чи Боб просто офлайн чи в іншому розділі мережі.

Блокчейни, такі як біткойн, які використовують консенсус, подібний до Накамото, сприяють живучості, тобто під час розбиття мережі обидві сторони продовжуватимуть виробляти блоки та зрештою переорганізовуватимуться, якщо розділ буде вирішено, тоді як інші, такі як ланцюги Cosmos, використовують PBFT-подібний консенсус, зупинка під розділами мережі для збереження узгодженості.

Правила підтвердження на Ethereum

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

За сприятливих умов мережі Ethereum також прагне забезпечити гарантії узгодженості через остаточність, використовуючи протокол Casper FFG . Завершеність є найсильнішим можливим правилом підтвердження, з вузлами, які мають жорстко запрограмоване правило ніколи не переорганізовувати завершені блоки.

Завершена книга (зелена) завжди є префіксом поточної книги (синя).

Гарантії остаточності порушуються, якщо два конфліктуючі блоки завершуються, подія, яка може статися, якщо більше 1/3 валідаторів діють зловмисно. Однак на Ethereum такі дії супроводжуються значним штрафом у вигляді втрати частки.

Користувачі можуть вибрати, чи використовувати Casper FFG як найбезпечніше правило підтвердження, чи бути активнішими, покладаючись на LMD GHOST. Правила підтвердження для LMD GHOST, подібно до правила k-підтвердження в біткойнах, можуть бути складнішими, ніж просто перевірка того, чи включена транзакція в книгу, як зазначено в правилі підтвердження безпечного блокування.

Правила підтвердження для зведень

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

Зведення даних про транзакції

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

Під час зведення, оскільки дії публікації даних і коренів роз’єднані, транзакції не потрібно відкидати залежно від дійсності відповідних коренів стану. Враховуючи це розділення, достатньо перевірити, чи завершуються транзакції, не чекаючи завершення кореневого стану, в обхід додаткових затримок, таких як 7-денний період виклику в оптимістичних зведених версіях.

Зведення відмінностей стану

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

Методи агрегування доказів пропонують вирішення цього компромісу між часом підтвердження та амортизацією вартості: навіть якщо зведення зазнає мінімальної активності, воно все одно може отримати вигоду від амортизації, включивши транзакції з більш активних зведень у той самий доказ. Прикладом такого підходу є SHARP від Starkware, який наразі збирає докази зі зведених пакетів Starknet, Paradex і StarkEx, таких як dYdX і навіть Validiums.

Де все ускладнюється

Специфікація похідного зведення

Якщо зведення не базується, порядок виведення пакетів може бути визначений секвенсором зведення, який може публікувати їх в іншому порядку на L1.

Для прикладу ланцюжки OP Stack публікують пакети на L1, які пов’язані за допомогою хешів попереднього пакета. Ці пакети не потрібно публікувати в хронологічному порядку, що призводить до 12-годинного вікна послідовності , протягом якого вузли очікують потенційно відсутні транзакції. Транзакції не слід вважати включеними лише тому, що вони опубліковані на L1: якщо пакет ще не підключено до канонічного ланцюжка пакетів, існує ризик, що буде створено альтернативний форк з іншим порядком або набором транзакцій.

У ланцюжках OP Stack час блокування становить 2 секунди, що означає 6 блоків у кожному блоці Ethereum. Це групування з 6 блоків між блоками Ethereum називається «епохою». Повідомлення L1-L2, надіслані через L1, включаються в першу частину першого блоку відповідної епохи для даного блоку L1. Хоча ці транзакції можна вважати підтвердженими, не чекаючи, поки пройде вікно послідовності, оскільки відоме їхнє впорядкування в реєстрі L2 після деривації, важливо зазначити, що вузли не почнуть обчислювати блоки, що містять ці повідомлення, якщо попередній пакет відсутній. Це пояснюється тим, що стан неможливо обчислити без повної послідовності, а отже, корені стану також не будуть опубліковані на L1.

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

Дозволені функції

Scroll — це зведена версія ZK, яка публікує дані транзакцій, тобто, в принципі, не потрібно чекати підтвердження ZK, щоб вважати свою транзакцію остаточною. Це було б правдою, якби вони не реалізували функцію видалення партій, які ще не перевірені.

https://etherscan.io/address/0x2e07f0fba71709bb5e1f045b02152e45b451d75f#code#F1#L260

Те саме стосується зведених розбіжностей у стані: zkSync Era та zkSync Lite мають триетапний процес для публікації розбіжностей у стані: спочатку вони фіксують дані без будь-яких підтверджень, потім надають підтвердження для них, а потім, після 24-годинної затримки , root стає доступним для виконання для обробки зняття коштів. Теоретично, коли надається доказ, порядок транзакцій фіксується, тому не потрібно чекати, поки мине затримка виконання. Крім того, zkSync може повернути ці блоки:

https://etherscan.io/address/0x7Ed066718Dfb1b2B04D94780Eca92b67ECF3330b#code#F10#L425

Хоча для zkSync Era блоки ніколи не поверталися, на zkSync Lite це сталося 8 разів.

Остаточна спостережуваність

Оскільки відмінності стану публікації зведених даних не публікують дані транзакції, як ми можемо відстежити, що транзакція справді була включена? Так, ми могли б відстежувати ефекти, як-от одноразові облікові записи, але загальний випадок стає складним. Місяць тому я поставив таке запитання:

Давайте подивимося на деякі з відповідей:

Це рішення, яке працює, якщо секвенсор готовий відповісти вам і якщо ви йому довіряєте. А якщо ні? Або що, якщо це так, але ви йому не довіряєте? Як перевірити правильність заяви?

Моя улюблена відповідь.

Тут було запропоновано рішення, яке насправді працює:

Хоча це працює, це означає, що технічне рішення про використання відмінностей стану просочується в логіку програми, тобто навіть якщо зведення є еквівалентом EVM, проекти повинні адаптувати свій контракт до цього міркування.

Частковим рішенням є публікація кореня транзакцій і перевірка їх дійсності в ZK-доказі. Навіть у цьому випадку потрібно покладатися на секвенсор, щоб отримати необхідний шлях Merkle, що може бути розумним для авторитетних централізованих секвенсорів, але стає складнішим у налаштуваннях без дозволу.

Показники живості

Як перший крок до відстеження часу до завершення зведених транзакцій на L2BEAT ми почали відстежувати показники активності, зокрема інтервали між пакетами транзакцій (якщо застосовно) і корені стану. Обґрунтування полягає в тому, що якщо зведення, наприклад, взаємодіє з L1 лише раз на місяць, користувачі не можуть очікувати, що час до завершення буде порядку хвилин. Показники активності можна розглядати як індикатор нижньої межі для часу до завершення: якщо зведення даних транзакцій публікує пакети кожні дві хвилини, і припускаючи, що розподіл транзакцій L2 є рівномірним, очікуваний час до завершення не менше однієї хвилини. .

Ось кілька прикладів даних, які ми відстежуємо для zkSync Era (оновлення стану) і OP Mainnet (пакети передачі):

Показники активності zkSync Era за вересень місяць.

Показники активності OP Mainnet за вересень місяць.

Як і передбачалося, оскільки для створення доказів ZK потрібен час і є стимул включати більше транзакцій в одне підтвердження, zkSync Era має гірші показники живучості, ніж OP Mainnet. Важливо мати на увазі, що, як ми обговорювали в попередніх розділах, показники живучості не перетворюються безпосередньо на міркування остаточності: у гіршому випадку OP Mainnet насправді має вищий час до завершення через вікно послідовності.

Тепер ви можете досліджувати показники активності для більшості зведених на L2BEAT:

Обмеження живучості відстеження

Хоча живість можна розглядати як нижню межу показника остаточності, іноді вона може бути дуже поганою. Уявіть собі зведення з часом блокування 4 секунди, тобто для кожного блоку Ethereum є 3 блоки зведення. Якщо оператор зведення публікує лише два блоки L2 на блок L1, навіть якщо з точки зору Ethereum зведення є дуже активним, воно все більше відставатиме від м’яких підтверджень L2, і час до завершення буде дедалі гіршим. Хоча це екстремальний сценарій, це те, що зведені пакети повинні враховувати.

Практичним прикладом є Starknet: хоча ми спостерігаємо в середньому 32 секунди між оновленнями стану, час до завершення фактично наближається до 6 годин:

Джерело: starkscan.co

Це тому, що Starknet публікує кореневі оновлення стану для кожного блоку L2 на L1. Однак для цього вони повинні посилатися на доказ SHARP, який зазвичай публікується приблизно кожні 30 хвилин. Крім того, ці докази відстають приблизно на 6 годин від кінчика м’якого підтвердженого ланцюга L2.

М'які підтвердження

М’які підтвердження — це правила підтвердження, які використовуються для досягнення коротшого часу підтвердження на L2 за рахунок гарантій безпеки. Наразі в усіх випадках м’які підтвердження передбачають довіру централізованому оператору не публікувати різні повідомлення на L1. Неправильні м’які підтвердження є причиною помилок, тому можуть бути реалізовані механізми для відстеження репутації секвенсорів поза ланцюгом або в ланцюжку. У співпраці з Nethermind ми плануємо оцінити ці властивості безпеки та відстежити суму цінності під загрозою в будь-який момент часу.

Ліворуч: економічні гарантії на Starknet, якщо вони мали м’які підтвердження, захищені механізмом скорочення. Праворуч: загальна вартість ризикує бути переорганізована з часом.

Йти вперед

Відстеження часу до завершення є складним завданням. Наш перший крок полягає в моніторингу інтервалів подання доказів для зведення ZK, які встановлюють вищу нижню межу часу до завершення порівняно з інтервалами між поданням кореня стану. Після цього ми плануємо запровадити діаграми, які відображатимуть історичні дані для кожного проекту. Згодом наше дослідження буде зосереджено на всіх додаткових механізмах, які необхідно розглянути, щоб остаточно досягти метрик у реальному часі для часу до завершення. Залишайтеся на зв'язку!

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

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