Інтерпретація всього процесу реалізації L2-транзакції: які показники безпеки кожного етапу?

Автор: Nic@ imToken Labs

Коли я можу бути впевнений, що транзакція L2 буде включена в блок? Коли я можу бути впевнений, що дохід від транзакції L2 не буде відкинутий через Re-org?

У цій статті ми розглянемо весь процес реалізації транзакції L2 та проаналізуємо показники безпеки кожного етапу транзакційного процесу.

Передумови:

• Весь процес транзакцій L1 (Layer 1)
• Причини і наслідки Re-org
• Зрозумійте поточну роль Ethereum в архітектурі PBS і те, як він працює
• Зрозумійте різницю між Optimistic Rollups і Validity (ZK) Rollups

Дізнайтеся про транзакції L1

ПРОЦЕС ТРАНЗАКЦІЇ

Діаграма потоку транзакцій L1

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

Імовірність і вартість Re-org будуть варіюватися в залежності від алгоритму консенсусу ланцюжка і ринкової капіталізації активу, і розрахунок вартості Re-org тут не буде представлений.

Дізнайтеся про транзакції L2

ПРОЦЕС ТРАНЗАКЦІЇ

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

Однак слід зазначити, що оскільки дані L2 Block завантажуються в транзакції L1 через L1, все ще можна зіткнутися з ситуацією, коли відбувається L1 Re-org, в результаті чого L2 Block не записується в історію Blockchain в кінцевому підсумку, тобто еквівалентно L2 Re-org, тому користувачеві все одно доведеться чекати, поки ймовірність L1 Re-org буде досить низькою, щоб бути впевненим, що його транзакція буде записана в історію Blockchain.

Діаграма потоку транзакцій L2

Користувач спочатку чекає, поки транзакція буде включена в блок L2, потім чекає, поки L2-блок буде завантажений на L1 через транзакцію L1, і, нарешті, чекає, поки транзакція L1 буде завершена.

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

Але якщо користувач готовий піти на деякі жертви, чи можна його обміняти на кращий досвід?

Попереднє підтвердження/Швидке підтвердження/М’яке підтвердження

Користувач повинен побачити, що L2-блок (що містить L2-транзакції) включений в L1-блок, і навіть почекати, поки ймовірність появи Re-org стане досить низькою, щоб повірити, що його транзакція L2 була зароблена.

Але що робити, якщо користувач готовий довіряти Секвенсеру? Можливо, Секвенсером керує команда розробників L2, якою керує авторитетна організація, і якщо Секвенсер запевняє користувача, що його транзакція буде оплачена негайно, на X-му Блоці, тоді цієї гарантії достатньо для користувача, який готовий довіряти Секвенсеру. Подібно до того, як якщо користувач довіряє Гаманцю, який він використовує, він не буде підозріло заходити в Etherscan, щоб перевірити ще раз після того, як Гаманець попередив його про те, що транзакція оплачена.

Гарантія доходу від транзакції, що надається цим секвенсером, називається попереднім підтвердженням, швидким підтвердженням або м’яким підтвердженням, що можна розуміти як «ранню» або «м’яку» гарантію доходу від транзакції. Йому не потрібно чекати, поки транзакції L2 будуть включені в блок L1, але це лише усна обіцянка, дана Секвенсером, і Секвенсер може забути початковий проміс через помилки або шкідливий Секвенсор безпосередньо порушить проміс, що може призвести до втрати часу користувача або бути “Double Spend Attack”.

Далі ми розглянемо деякі різні способи представлення статусу доходу транзакцій L2.

Статус доходу від транзакцій Arbitrum/Optimism

В даний час користувачі, які відправляють транзакцію на Arbitrum або Optimism, можуть практично відразу отримати Transaction Receipt, який буде результатом виконання транзакції. Це означає, що секвенсер вже секвенував і змоделював виконання транзакцій локально, і ця квитанція про транзакцію є попереднім підтвердженням для користувача.

Щоб дізнатися більше про Arbitrum, більш детальний опис життєвого циклу транзакції можна скопіювати за наступним посиланням на довідковий офіційний документ браузера:

Для більш детального ознайомлення з життєвим циклом транзакції Optimism, будь ласка, скопіюйте наступне посилання на офіційний документ браузера:

Перевірте статус доходу від транзакції на Arbitrum

Транзакції, які ви бачите в Arbitrum Explorer, будуть містити транзакції Pre-Confirmation, тобто транзакції, які ще не були завантажені в L1, як показано на наступному малюнку, ви можете побачити, що поруч з Block Number 145353000 є індикатор Confirmed by Sequencer:

На зображенні вище показані транзакції, які були підтверджені лише секвенсером, але ще не завантажені до L1

Якщо транзакція була завантажена в L1, як показано на малюнку нижче, її статус змінився на 69 L1 Block Confirmations, що означає, що вона була завантажена в L1 і містить блок даних транзакції, а за ним знаходиться 69 Блок:

Блок L1, що містить дані про цю транзакцію, вже має за собою 69 блоків, і чим більше блоків слідує за ним, тим він безпечніший.

Або транзакція, показана на скріншоті нижче, блок L1, що містить ці дані про транзакцію, має за собою 6174 блоки, що вже дуже безпечно.

Але що тут можна зробити краще, так це об’єднати інформацію про остаточність L1.

Просте повідомлення користувачеві, скільки існує підтверджень блоків L1, є обмеженою допомогою для користувача, оскільки користувач повинен зрозуміти та обчислити рівень безпеки, представлений такою кількістю підтверджень блоків. І оскільки рівень 1 (тобто Ethereum) вже має механізм остаточності, такий як Casper FFG, Провідник може фактично безпосередньо показати, чи завершено блок рівня 1 в даний час на рівні 1. В даний час Optimism’s Explorer реалізував таку функцію.

Перевірте статус прибутку від транзакцій на Optimism

Транзакції, які ми бачимо на Optimism Explorer, також включатимуть транзакції попереднього підтвердження, тобто транзакції, які ще не були завантажені на L1, як показано на наступному малюнку, ми можемо побачити, що поруч із номером блоку 111526300 є символ Підтверджено секвенсором:

Транзакції, які були підтверджені лише секвенсером, але ще не завантажені до L1

Однак, Провідник, схоже, не має чіткої специфікації того, що означає «Підтверджено секвенсором», кажучи «Підтвердження секвенсера еквівалентні декільком підтвердженням блоку на L1.», вказуючи на те, що «Підтверджено секвенсером» представляє ряд блоків, які були завантажені в L1 і за якими слідували кілька:

Але насправді остання транзакція також відображається як Підтверджено секвенсором, і навіть десятки днів тому статус транзакції, яка пройшла період оскарження, все ще підтверджується секвенсором:

Десятки днів тому статус транзакції все ще залишався на рівні «Підтверджено секвенсором»

Порада щодо читання: Наведена вище ситуація також може полягати в тому, що провідник позначає різні стани в різних місцях: Підтверджено секвенсером після номера блоку повідомляє користувачеві, що блок був підтверджений секвенсором, і користувач повинен підтвердити стан після завантаження в L1 за допомогою іншої інформації, такої як інформація “L1 State Batch”, згадана нижче.

Крім того, транзакція, яка була завантажена в L1, як показано на скріншоті нижче, має дві додаткові відомості: “L1 State Batch Index” і “L1 State Root Submit Tx Hash”. Ці дві частини інформації представляють Державну партію, в яку була включена транзакція L2, і транзакцію L1, за допомогою якої Державний пакет був завантажений в L1:

Натисніть на «3480» State Batch, ви можете побачити, що його стан Finalized, що відповідає Finalized стану L1 (тобто основної мережі Ethereum), який є дуже безпечним станом, який успішно акумулював голоси двох валідаторів Epoch.

△ Державна партія 3480 була придбана в блоці L1 18457449, а блок 18457449 був доопрацьований.

Джерело:

Якщо пакет був завантажений, але не завершений у L1, він буде відображений як Unfinalized:

Незважаючи на те, що State Batch 3494 був завантажений в L1, блок L1, який входить до пакету, ще не доопрацьований.

У порівнянні з Arbitrum Explorer, Optimism Explorer надає більше інформації (State Batch) для транзакцій, і він безпосередньо передає інформацію про остаточність L1 в провідник L2, щоб користувач міг безпосередньо знати, чи був блок L1 завершений, а не оцінювати ступінь безпеки, що відповідає кількості підтверджень блоку.

Статус прибутку від торгівлі StarkNet

Наразі, після того, як користувач надсилає транзакцію в StarkNet, хоча отримання транзакції можна швидко запитати, статус транзакції, що відображається в квитанції, зазвичай буде в стані ОТРИМАНО, що означає, що вузол отримав транзакцію і немає проблем після перевірки транзакції, і чекатиме, поки транзакція буде отримана блоком L2 секвенсера та виконана, тоді як транзакція в стані ОТРИМАНО не матиме жодного результату виконання транзакції. Користувачі можуть перевірити хід своїх транзакцій за допомогою статусу транзакції, що відображається в StarkNet Explorer.

Порада щодо читання: Якщо секвенсер обробляється досить швидко, можна пропустити стан RECEIVED і перейти до стану, коли транзакція вже була оброблена. Для більш детального ознайомлення з торговим процесом StarkNet ви можете скопіювати посилання нижче, щоб переглянути офіційні документи у своєму браузері.

Офіційні документи: _and_concepts/Мережа_Architecture/життєвий цикл транзакції/

Транзакції, які можна побачити на Starkscan, StarkNet Explorer, також включатимуть транзакції попереднього підтвердження, як показано на наступному малюнку, ви можете побачити, що статус наразі прийнято на L2, що означає, що він був ранжований у блок L2 за секвенсором:

“Прийнято на L2” означає, що він був поміщений в блок L2 секвенсором, але ще не завантажений в L1

Першими двома станами Accepted на L2 є Received та Pending, що означає, що “транзакція була отримана та перевірена” та “транзакція обробляється секвенсором”, і транзакція перейде у стан Accepted на L2 після виконання транзакції:

Транзакція отримана та верифікована

Транзакція обробляється секвенсером

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

Дані про транзакції завантажено до L1

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

Крім того, Провідник відображає Прийнято на L1 тільки для транзакцій, завантажених на L1, і не має інформації про Finality або Block Confirmation with L1, що означає, що користувачі повинні перевірити, чи достатньо Block в блоці L1 або вони були завершені.

Загалом, через вузьке місце продуктивності самого StarkNet, користувачам доводиться тривалий час покладатися на попереднє підтвердження, а Explorer не підтримує інформацію про остаточність L1, що призводить до поганого досвіду розпізнавання доходів від транзакцій StarkNet, і саме тут StarkNet потрібно вдосконалювати в майбутньому.

Статус доходу від транзакцій zkSync

Подібно до StakrNet, zkSync також має стан PENDING , що означає, що вузол отримав транзакцію і транзакція була перевірена без проблем, він чекатиме, поки транзакція буде заблокована та виконана секвенсером L2, тоді як транзакція в стані PENDING не матиме жодного результату виконання транзакції.

Користувачі можуть дізнатися про хід своїх транзакцій за допомогою статусу транзакції, що відображається в zkSync Explorer.

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

Для більш детального ознайомлення з процесом транзакції zkSync ви можете скопіювати наступне посилання, щоб переглянути його у своєму браузері:

Транзакції, які ви бачите в zkSync Explorer, також включатимуть транзакції попереднього підтвердження, наприклад, на скріншоті нижче, ви можете побачити, що статус наразі zkSync Era Processed, що означає, що він був ранжований у блок L2 за секвенсором:

Ця транзакція була розміщена в блоці L2 Sequencer і наразі очікує на завантаження на L1 (Ethereum Sending)

Після того, як секвенсер створить блок L2, Блок і транзакції в ньому будуть послідовно проходити три фази: Committed, Proproven і uted, що вказує на те, що “Блок був завантажений в L1”, “Валідність блоку була доведена” і “Статус L2 був оновлений до L1 після виконання транзакції Блоку”. Блок і транзакція на різних стадіях показані нижче:

Партія 292700 була завантажена в L1 і знаходиться на стадії Зобов’язання. Джерело:

Поточний стан транзакції в пакеті 292700 змінився з надсилання Ethereum на перевірку Ethereum, що вказує на те, що вона чекає на перевірку за допомогою Zero-Knowledge Proof.

Переміщення стрілки над піктограмою перевірки Ethereum також покаже різні етапи, а також буде прикріплено посилання на транзакцію з попереднього етапу (надсилання):

Ця транзакція переходить у стадію «Валідація», і посилання на транзакцію, яка завантажила Batch на L1 на попередньому етапі (Sending), також можна побачити тут.

Ефективність партії 292000 доведена, тому переходьте до фази перевірених:

Після того, як пакет доведено, він переходить у стан «Доведено» з посиланням на транзакцію, яка виконує дію «Доказ».

Транзакція також перейде від “validating” до “uting”, тобто очікування виконання.

Коли партія доведена, вона переходить у період очікування (близько 21 години в офіційних документах), перш ніж транзакція всередині буде виконана та оновлений стан L2, записаний на L1. В основному це пов’язано з запобіжником, який був доданий в альфа-фазі, щоб гарантувати, що є достатньо часу для реагування на будь-які помилки, що виникають. Коли партія виконана, вона переходить у завершальну фазу:

Після того, як пакет виконано, він переходить у кінцевий стан uted з посиланням транзакції, яке виконує дію ute.

Статус транзакції в Batch також було оновлено до “uted”

На відміну від StarkNet, де транзакції від L2 до L1 завершуються за один крок, процес переміщення L2 на L1 у zkSync розбивається на три більш детальні етапи: Відданий → Доведений → уточнений.

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

Крім того, zkSync Explorer забезпечує розширене та повне відображення даних для різних етапів, щоб будь-хто міг зрозуміти останній статус транзакцій через провідник і навіть мати можливість особисто перевірити виконання транзакцій під час переходу кожного етапу (наприклад, від Відданого до перевіреного, від Доведеного до перевіреного).

Однак слід зазначити, що в якості заходу захисту для альфа-фази, історія може бути змінена секвенсором zkSync в цей час.

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

L1 також може підтримувати попереднє підтвердження

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

Візьмемо для прикладу Ethereum, людина, яка фактично створює блоки, є Builder, і Builder може надавати послуги попереднього підтвердження, щоб надати користувачам гарантію доходу від транзакцій. Але оскільки Забудовник не обов’язково отримує право на певний вихід і певний Блок, але повинен претендувати на право на кожен вихід Блоку, тому ефективність цього Попереднього Підтвердження буде відносно низькою, і необхідно враховувати силу Будівельника, якщо Будівельник недостатньо конкурентоспроможний, то Будівельнику важко отримати право на виготовлення Блоку, тому Попереднє Підтвердження, надане Будівельником Сервіс буде сильно скомпрометований.

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

Однак, оскільки в поточній архітектурі PBS, Proposer пропонує лише роль Block, а роль фактичного створення Block та визначення вмісту Block є Builder, тому Proposer не може безпосередньо запхати транзакцію в Block або попросити Builder наповнити транзакцію. Коли в майбутньому архітектура PBS зміниться, наприклад, буде додано список включень або дозволено ініціаторам брати участь у виробництві блоків, Ініціатор матиме можливість надавати послуги попереднього підтвердження.

Порада щодо читання: Для отримання додаткової інформації про PBS, будь ласка, скопіюйте посилання нижче, щоб прочитати у вашому браузері: _4j_-TweXHX_LMag656k_pAyJWIBXpEDrzpUfVsss.

Покращено попереднє підтвердження

Попереднє підтвердження – це просто усна обіцянка Builder або L2 Sequencer, і інша сторона не зобов’язана виконувати обіцянку, і немає механізму покарання за невиконання.

Чи можна зробити цю обіцянку більш впевненою? Власне, так, тому що особа, відповідальна за створення Блоку, і зміст його обіцянки (наприклад, «у блоці 1 350 000 транзакція доходу») може бути записана як перевірка умов. Таким чином, ми можемо використовувати смарт-контракт для регулювання Builder або Sequencer, попросити їх надати послуги попереднього підтвердження під час забезпечення депозиту в смарт-контракті та підписати контент під час надання обіцянки доходу від транзакції, коли користувач виявить, що Builder або Sequencer не виконав зобов’язання, обіцяний контент та підпис іншої сторони можуть бути надіслані смарт-контракту, а смарт-контракт може перевірити, чи було виконано зобов’язання (наприклад, «у першому 1 350 000 Блоковий дохід за цією транзакцією»).

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

Підсумки

• Після того, як L1-транзакції будуть включені в L1-блоки, ймовірність Re-org буде поступово падати, а впевненість користувачів в доході від транзакцій поступово зростатиме.
• На один робочий процес транзакцій для транзакцій L2 більше, ніж для транзакцій L1, це стадія, на якій транзакції L2 включаються в блоки L2 і очікують завантаження на L1.
• Однак в транзакційному робочому процесі, де транзакцій L2 більше, ніж транзакцій L1, оскільки дані ще не завантажені в L1 на даному етапі, все ще існує можливість змінних, тому гарантією доходу від транзакції, яку користувачі можуть отримати на цьому етапі, є усна обіцянка Sequencer, яка називається Pre-Confirmation або Fast Confirmation, Soft Confirmation.
• Якщо Секвенсер шкідливий, або якщо є проста помилка, то обіцянка, дана Секвенсером, може бути порушена, що призведе до невизнання доходу від транзакцій користувача L2.
• В даний час більшість статусів транзакцій L2 в їх Explorer включають статус попереднього підтвердження, наприклад, Підтверджено секвенсером для Arbitrum/Optimism або Прийнято на L2 для StarkNet. Коли ви бачите таку інформацію, будь ласка, зверніть увагу на термін дії гарантії доходу від транзакції, передбачену цією інформацією.
• Якщо ви не хочете довіряти попередньому підтвердженню, наданому секвенсером, вам потрібно буде трохи почекати і звірити з інформацією, наданою L2 Explorer, про те, що дані L2 завантажуються в L1.
• Попереднє підтвердження може поєднуватися з розробкою економічних стимулів, таких як штрафи через смарт-контракт, коли секвенсер порушує зобов’язання, щоб користувачі могли отримати більш чіткий захист.

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