Коли можна бути впевненим, що транзакцію L2 (рівень 2) буде включено в блок? Коли можна бути впевненим, що дохід від транзакції L2 не буде відкинуто через реорганізацію?

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

Попередні знання:

• Увесь процес L1 (Шар 1) транзакцій
• Причини та наслідки випадків Re-org
• Розуміння ролей та методів функціонування в поточній архітектурі Ethereum PBS
• Відмінності між Оптимістичним Rollup та Rollup з підтвердженням (ZK)

Розуміння транзакцій L1

Процес транзакції

Після того, як користувач видає та підписує транзакцію, вона надсилається в мережу p2p, очікуючи включення в блок майнером за механізмом консенсусу Proof of Work (PoW) або ініціатором за механізмом консенсусу Proof of Stake (PoS). Коли користувач помічає, що його транзакція була включена в останній блок, ще не факт, що транзакція буде назавжди зафіксована в історії блокчейну. Ця невизначеність пов'язана з можливістю «реорганізації» (реорганізації) в блокчейні. Користувачі повинні почекати, поки ймовірність того, що відбудеться Re-org, стане достатньо низькою, щоб бути впевненими, що їхня транзакція буде назавжди зафіксована в історії блокчейну.

Процес транзакції L1 ілюстровано

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

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

Розуміння транзакцій L2

Процес транзакції

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

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

Процес транзакції L2 проілюстровано

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

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

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

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

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

Такі гарантії, надані Секвенсором, називаються Попередньою Підтвердженням, Швидким Підтвердженням або М'яким Підтвердженням. Ці гарантії вважаються "попередніми" або "м'якими" завданнями включення транзакції, які не потребують включення транзакції L2 у блок L1. Однак це лише словесні зобов'язання Секвенсора, які можуть бути забуті через помилку або навмисно порушені зловмисним Секвенсором, в найгіршому випадку призводячи до атаки з подвійним використанням.

Подальшим чином ми представимо різні способи представлення статусів включення транзакцій L2.

Статус включення транзакції Arbitrum/Optimism

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

Дізнатися більше

Для отримання більш детальної інформації про життєвий цикл транзакцій на Arbitrum, звертайтеся до офіційної документації: https://docs.arbitrum.io/tx-lifecycle

Для отримання більш детальної інформації про життєвий цикл транзакцій Optimism звертайтеся до офіційної документації:https://community.optimism.io/docs/protocol/txn-flow/#posting-to-l1

Статус доходів від торгівлі для Arbitrum/Optimism

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

дізнайтесь більше

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

https://docs.arbitrum.io/tx-lifecycle

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

https://community.optimism.io/docs/protocol/txn-flow/#posting-to-l1

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

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

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

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

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

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

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

Просто повідомлення користувачу про кількість підтверджень блоку L1 обмежує користувача, оскільки користувач повинен розуміти та розраховувати рівень безпеки, що представлений такою кількістю підтверджень блоків. Оскільки Layer1 (тобто Ethereum) вже має механізм Finality, подібний Casper FFG, Explorer фактично може безпосередньо відображати, чи був фіналізований блок Layer1 в Layer1. На даний момент Explorer Optimism вже реалізував таку функцію.

Перевірка статусу квитанції транзакції на оптимізмі

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

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

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

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

Транзакції з давніх днів все ще перебувають у статусі "Підтверджено послідовником"

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

Крім того, як показано на знімку екрана нижче, транзакція, яка була опублікована на L1, містить ще два додаткові елементи інформації: "Індекс партії стану L1" та "Хеш транзакції подання кореня стану L1". Ці деталі представляють, в яку Партію Стану включена транзакція L2 та через яку транзакцію L1 ця Партія Стану була опублікована на L1:

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

△ State Batch 3480 включено в блок L1 18457449, і блок 18457449 був завершений.

Джерело: https://etherscan.io/block/18457449

Якщо партію було опубліковано, але ще не було підтверджено на рівні L1, вона буде відображатися як Непідтверджена:

Стан партії 3494, хоча опублікований в L1, включений в блок L1, який не був завершений:

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

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

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

Порада з читання: Якщо послідовник обробляє транзакції достатньо швидко, він може обійти статус «ОТРИМАНО» і перейти безпосередньо до стану оброблено. Для більш детального введення до процесу транзакції на StarkNet ви можете скопіювати нижченаведене посилання у свій браузер, щоб проконсультуватися з офіційними документами.

Офіційні документи:Цикл життя транзакції StarkNet

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

"Прийнято на L2" означає, що воно було включено в чергу Квінсеру в блок L2, але ще не було завантажено на L1.

Два статуси перед "Прийнято на рівні L2" - Отримано та Очікується, що представляють "транзакція була отримана та перевірена" та "транзакція обробляється Секвенсором" відповідно. Після завершення виконання обробки транзакцій він перейде до статусу "Прийнято на рівні L2":

Транзакція була отримана та перевірена.

Транзакція обробляється послідовником.

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

Дані про транзакції були завантажені до L1.

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

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

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

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

Подібно до StakrNet, zkSync також має стан ОЧІКУВАННЯ, що означає, що вузол отримав транзакцію і після перевірки транзакції проблем немає. Вона буде чекати на включення в блок L2 від Послідовника та виконання. Однак у стані ОЧІКУВАННЯ жодна транзакція не буде виконана. результат.

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

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

Для більш детального введення в процес транзакції zkSync ви можете скопіювати посилання нижче та переглянути його в браузері: https://era.zksync.io/docs/reference/concepts/finality.html#finality-on-ethereum

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

Ця транзакція була включена в блок L2 від Послідовника і зараз очікує на завантаження на L1 (Відправлення Ethereum)

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

Пакет 292700 був завантажений на L1 та увійшов у стадію Зобов'язань. Джерело: https://explorer.zksync.io/batch/292700

Поточний статус угод у пакеті 292700 змінився з надсилання Ethereum на перевірку Ethereum, що свідчить про те, що він очікує на перевірку нульовим доказом для підтвердження його достовірності.

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

Ця транзакція перейшла до етапу "Перевірка". Посилання на транзакцію для завантаження партії на рівень L1 на попередньому етапі (Відправлення) також можна побачити безпосередньо тут.

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

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

Транзакції всередині також увійдуть у стадію "Виконання" з "Перевірки", яка очікує виконання.

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

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

Статус транзакції в пакеті також оновлюється на «Виконано». На відміну від транзакцій StarkNet, які завершуються від рівня 2 (L2) до рівня 1 (L1) за один крок, zkSync розбиває процес транзакцій від L2 до L1 на три більш детальні етапи: Віддана → Доведена → Виконана. Незважаючи на те, що це подовжує весь процес транзакції приблизно до одного дня в якості захисного заходу, статус «Зобов'язаний» дозволяє користувачам швидко дізнатися, чи була включена їхня транзакція (як тільки транзакція переходить у стадію «Зобов'язання», це вже не просто попереднє підтвердження), не покладаючись постійно на довіру до секвенсера. Крім того, zkSync Explorer забезпечує вичерпне та повне відображення даних для різних етапів, дозволяючи будь-кому зрозуміти останній статус транзакцій і навіть особисто перевірити виконання транзакцій на кожному етапі переходу (наприклад, від Відданого до Доведеного, від Доведеного до Виконаного). Однак важливо зазначити, що в якості захисного заходу на стадії Альфа секвенсер zkSync може змінювати історичні записи. Це вказує на те, що, незважаючи на те, що транзакції можуть швидко вийти за межі попереднього підтвердження, щоб перейти в стадію «Зафіксовано», секвенсер все одно може видаляти транзакції користувача з історичних записів, доки вони не досягнуть стадії «Виконано». Тому користувачам все одно потрібно довіряти секвенсеру до доби.

Рівень 1 також може підтримувати Передпідтвердження

Якщо заздалегідь відомо, хто відповідає за виробництво блоків, то L1 також може підтримувати Pre-Confirmation. Візьмемо для прикладу Ethereum, фактичним виробником блоків є Builder, який може запропонувати послуги попереднього підтвердження, надаючи користувачам гарантію включення транзакцій. Однак, оскільки Забудовник не обов'язково має право виробляти певний блок, але повинен брати участь у торгах за право виробляти кожен блок, ефективність Попереднього підтвердження може бути слабшою. Крім того, необхідно враховувати конкурентоспроможність забудовника; якщо забудовник недостатньо конкурентоспроможний, йому буде важко забезпечити собі право на виробництво блоків, що значно знизить надійність його послуг попереднього підтвердження. Щоб уникнути цих проблем, кращим підходом було б дозволити ініціаторам надавати послуги попереднього підтвердження, оскільки зазвичай заздалегідь визначено та визначено, хто з них запропонує який блок. Однак, в поточній архітектурі PBS, ініціатори пропонують тільки блоки, а фактичне виробництво блоків і прийняття рішень щодо контенту здійснюється будівельниками, тому ініціатори не можуть безпосередньо вставляти транзакцію в блок або вимагати від Builder зробити це. У майбутньому, якщо архітектура PBS зміниться, наприклад, шляхом додавання списку включень або дозволу ініціаторам брати участь у виробництві блоків, ініціатори можуть мати можливість пропонувати послуги попереднього підтвердження. Для отримання додаткової інформації про PBS, будь ласка, перейдіть за наданим посиланням.

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

Попереднє підтвердження – це просто усне зобов'язання Builders або L2 Sequencers, без зобов'язань щодо виконання обіцянки та без механізму покарання за невиконання. Однак можна зробити це зобов'язання більш надійним, використовуючи смарт-контракти для стандартизації конструкторів або секвенсорів. Вони можуть надавати послуги попереднього підтвердження, а також вносити заставу в смарт-контракт і підписувати контент під час обіцянки включення транзакції. Якщо користувачі виявлять, що будівельники або секвенсери не виконали свої обіцянки, вони можуть надіслати вміст обіцянки та підпис до смарт-контракту, який потім може перевірити, чи виконано обіцянку. Незважаючи на те, що сценарій застосування вищезгаданого контракту все ще знаходиться на стадії підтвердження концепції, за посиланням нижче показано презентаційне відео одного з таких прикладів застосування контракту.

Огляд:

Після того, як L1-транзакції включаються в L1-блоки, ймовірність реорганізації знижується, а впевненість користувачів у включенні транзакцій поступово зростає. L2-транзакції мають додатковий робочий процес у порівнянні з транзакціями L1: «L2-транзакції включені в блоки L2 і очікують завантаження на L1». Однак, оскільки дані не були завантажені в L1 на цьому етапі, все ще існує ймовірність відхилення, тому впевненість, яку користувачі можуть отримати щодо включення транзакції на цьому етапі, є усним зобов'язанням секвенсера, відомим як попереднє підтвердження або швидке підтвердження/м'яке підтвердження. Якщо секвенсер шкідливий або просто стикається з помилкою, його обіцянка може бути порушена, що призведе до відсутності підтвердження транзакції користувача L2. В даний час більшість L2 відображають статуси транзакцій у своїх провідниках, які включають статус попереднього підтвердження, наприклад, Arbitrum/Optimism's Confirmed by Sequencer або Accepted від StarkNet на L2. Побачивши таку інформацію, важливо звернути увагу на часову ефективність наданої гарантії включення транзакції. Якщо користувачі не хочуть покладатися на попереднє підтвердження секвенсера, їм потрібно буде почекати довше і перевірити інформацію L2 Explorer про те, що дані L2 завантажуються в L1. Попереднє підтвердження може включати механізм економічного стимулювання, наприклад, штрафування секвенсерів за допомогою смарт-контрактів, коли вони порушують свої обіцянки, надаючи користувачам більш чіткий захист. У таблиці нижче наведені гарантії включення угоди і відповідні сценарії ризику, передбачені транзакціями L1 і L2 на різних етапах процесу угоди.

Disclaimer:

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