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

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

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

1. Весь процес L1 (Шар 1) транзакцій

2. Причини та наслідки реорганізацій

3. Розуміння ролей і методів роботи в поточній архітектурі PBS Ethereum

4. Розуміння відмінностей між оптимістичним Rollup та Validity (ZK) Rollup

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

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

Після того, як користувач видає та підписує транзакцію, вона надсилається до мережі однорангових вузлів та очікує на майнера за механізмом підтвердження PoW або пропозера за механізмом підтвердження PoS, щоб включити її в блок. Коли користувач виявляє, що їхня транзакція була включена в останній блок, вони не можуть бути на 100% впевнені, що транзакція буде назавжди записана в історії цього блокчейну. Це пов'язано з можливістю події в блокчейні, відомої як "Переорганізація". Користувачам слід зачекати, поки ймовірність Переорганізації в певному блоку буде достатньо низькою, щоб бути впевненими, що їхня транзакція буде записана в історії блокчейну.

Ілюстрація процесу транзакції L1

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

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

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

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

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

Ілюстрація процесу транзакції L2

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

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

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

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

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

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

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

Для отримання більш детальної інформації про життєвий цикл транзакцій на 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]

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

[На зображенні показана транзакція на L1 з підтвердженням 69 блоків]

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

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

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

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

[Зображення показує транзакцію, підтверджену лише послідовником, але не завантажену на рівень L1]

Однак Експлорер не чітко визначає значення "Підтверджено послідовником". Він стверджує, що "Підтвердження послідовником еквівалентні декільком підтвердженням блоків на L1", що вказує на те, що транзакція, позначена як "Підтверджено послідовником", була завантажена на L1 та має кілька блоків за ним:

[Зображення показує останні транзакції, позначені як "Підтверджено послідовником"]

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

[Зображення показує транзакції, які були здійснені дні тому, і все ще позначені як "Підтверджено послідовником"]

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

Як показано на наступному знімку екрана, транзакція, яка вже завантажена на L1, включає додаткову інформацію: «Індекс блоку стану L1» та «Хеш транзакції відправлення кореня стану L1». Ці деталі показують, в якому блоку стану включена L2-транзакція та яка L1-транзакція завантажила цей блок стану на L1:

[Зображення транзакції із інформацією пакета стану L1]

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

[Зображення показує, що Державний партійний пакет 3480 завершено в блоку L1 18457449]

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

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

[Зображення показує державний пакунок, завантажений на L1, але ще не завершений]

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

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

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

Примітка: Якщо послідовник обробляє транзакції достатньо швидко, він може пропустити статус RECEIVED та перейти безпосередньо до обробленого стану. Докладнішу інформацію про процес транзакцій StarkNet дивіться у офіційному документі на https://docs.starknet.io/documentation/architecture_and_concepts/Network_Architecture/transaction-life-cycle/

На Starkscan, досліджувачі StarkNet, відображаються транзакції, включаючи предварительне підтвердження. Наприклад, транзакція, показана як «Прийнято на L2», вказує, що вона була впорядкована в блок L2:

«Прийнято на L2» означає, що транзакція була впорядкована в блок L2, але ще не була завантажена на L1.

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

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

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

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

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

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

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

Через обмеження продуктивності StarkNet, довгострокове використання Pre-Confirmation та відсутність підтримки інформації про L1 Finality в Explorer, користувацький досвід щодо підтвердження включення транзакції в StarkNet потребує поліпшень.

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

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

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

Підказка з читання: Якщо послідовник обробляє транзакції достатньо швидко, він може обійти статус ОЧІКУЄТЬСЯ і перейти безпосередньо до стану, коли транзакція вже була оброблена.

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

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

Транзакція була розміщена в блок L2 секвенсором і зараз очікує на завантаження до L1 (Відсилання Ethereum).

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

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

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

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

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

Партія 292000 була доведена своєю валідністю, тому вона переходить до етапу Перевірено:

Після того як партія підтверджена, вона потрапляє в стан Підтверджено, з посиланням на транзакцію, що виконує дію Підтвердження.

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

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

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

Статус операцій в межах партії також оновлюється на "Виконано".

У порівнянні з StarkNet, де транзакції переходять з L2 на L1 за один крок, zkSync розбиває процес від L2 до L1 на три більш детальні етапи: Зафіксовано → Доведено → Виконано. Хоча як захисний захід, весь процес транзакції займає близько дня, статус Зафіксовано дозволяє користувачам швидко дізнатися, чи була їхня транзакція включена (після Зафіксовано, це не лише Перед-Підтвердження) без виключної залежності від довіри до Послідовника. Крім того, zkSync Explorer надає всебічні дані для кожного етапу, дозволяючи будь-кому відстежувати останній статус транзакцій навіть перевіряти переходи між етапами (наприклад, від Зафіксовано до Доведено, від Доведено до Виконано).

Однак важливо зазначити, що як захисний захід у фазі Альфа секвенсер zkSync наразі може змінювати історичні записи. Це означає, що навіть якщо транзакції можуть швидко перейти з попереднього підтвердження в стадію «Зафіксовано», секвенсер все одно може видаляти транзакції користувача з історичного запису, доки вони не досягнуть стадії «Виконано». Тому користувачам все одно потрібно довіряти секвенсеру до доби.

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

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

Кращим рішенням для уникнення цих проблем було б пропонувати Пропоненту послуги попереднього підтвердження, оскільки зазвичай заздалегідь відомо, який Пропонент запропонує який блок. Однак у поточній архітектурі PBS (розділення Пропонента-Будівника) Пропонент відповідає лише за пропозицію блоків, тоді як Будівник вирішує зміст блоку. Тому Пропонент не може безпосередньо вставити транзакцію в блок або попросити Будівника це зробити. Ця ситуація може змінитися з майбутніми модифікаціями архітектури PBS, такими як додавання списку включення або надання можливості Пропонентам брати участь у виробництві блоків, що дозволить Пропонентам пропонувати послуги попереднього підтвердження.

Порада щодо читання: Для отримання додаткової інформації про PBS скопіюйте посилання нижче у свій браузер для читання: https://mirror.xyz/0x347c9872A2a1dE370D798f9FE96341A9A0E05af8/oG_4j_-TweXHX_LMag656k_pAyJWIBXpEDrzpUfVsss.

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

Підтвердження перед підтвердженням - це лише усний обіцянка від Будівельника або L2 Послідовника, без обов'язку виконувати її та механізму покарання за невиконання. Чи можна зробити це обіцянкою надійніше? Так, оскільки зміст зобов'язання (наприклад, "включити цю операцію в блок 1350000"), що робиться відповідальною особою за виробництво блоків, може бути записаний як умовна перевірка. Таким чином, ми можемо використовувати смарт-контракти для регулювання Будівельників або Послідовників, просячи їх внести заставу в смарт-контракт при наданні послуг передпідтвердження та підписати зміст зобов’язання. Якщо користувачі виявлять, що Будівельники або Послідовники не виконали свої обіцянки, вони можуть подати зобов'язання та підпис на перевірку в смарт-контракт.

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

https://www.youtube.com/watch?v=Uw5HxSYXwYo

Короткий опис

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

Транзакції L2 мають додатковий робочий процес порівняно з транзакціями L1: фаза «включення транзакції L2 в блок L2 та очікування на завантаження в L1». Під час цієї фази, оскільки дані ще не були завантажені в L1, існує ймовірність змін, тому єдине підтвердження, яке користувачі мають щодо включення своєї транзакції, - це вербальне зобов'язання від Послідовника, відоме як Передпідтвердження, Швидке Підтвердження або М'яке Підтвердження.

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

На даний момент більшість L2 відображають статус транзакції у своїх дослідниках, включаючи статус попереднього підтвердження, такий як "Підтверджено послідовником" у Arbitrum/Optimism або "Прийнято на L2" у StarkNet. Користувачі повинні бути уважні щодо часової дійсності гарантії включення транзакції, наданої цими статусами.

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

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

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

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

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