Когда можно быть уверенным, что транзакция L2 (уровень 2) будет включена в блок? Когда можно быть уверенным, что доходы от транзакции L2 не будут отклонены из-за Re-org?

В этой статье мы познакомим читателей со всем процессом реализации L2-транзакции и проанализируем показатели безопасности на каждом этапе транзакционного процесса.

Предварительные знания:

1. Весь процесс транзакций L1 (Уровень 1)

2. Причины и последствия Re-orgs

3. Понимание ролей и методов функционирования в текущей архитектуре PBS в Ethereum

4. Понимание различий между оптимистичным Rollup и Rollup с проверкой (ZK)

Понимание транзакций L1

Процесс транзакции

После того как пользователь создает и подписывает транзакцию, она отправляется в сеть равноправных узлов и ожидает, когда Майнер в рамках механизма консенсуса PoW или Предлагающий в рамках механизма консенсуса PoS включат ее в блок. Когда пользователь обнаруживает, что его транзакция была включена в последний блок, он не может быть на 100% уверен, что транзакция будет постоянно записана в истории этой блокчейн. Это связано с возможностью события в блокчейн, известного как «Re-org». Пользователям нужно дождаться, пока вероятность Re-org в определенном блоке не станет достаточно низкой, чтобы быть уверенными, что их транзакция будет записана в истории блокчейн.

Иллюстрация процесса транзакции L1

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

Вероятность и стоимость Re-org варьируют в зависимости от алгоритма консенсуса цепочки и рыночной стоимости ее активов. Методика расчета стоимости Re-org не будет рассматриваться подробно здесь.

Понимание транзакций L2

Процесс транзакции

После того, как пользователь L2 создает и подписывает транзакцию, она обычно отправляется непосредственно в секвенсор, ответственный за упорядочивание транзакций. Затем секвенсор включает эту транзакцию в блок L2. Впоследствии, когда секвенсор записывает данные блока L2 обратно в блок L1 через транзакцию L1, пользователи могут видеть, что их транзакция включена в последний блок L2. Тем не менее, важно отметить, что, поскольку данные блока L2 загружаются в L1 через транзакцию L1, все еще существует вероятность столкнуться с реорганизацией L1. Этот сценарий может привести к тому, что блок L2 не будет включен в историю блокчейна, что фактически приведет к реорганизации L2. Поэтому пользователи должны подождать, пока вероятность реорганизации L1 не станет достаточно низкой, прежде чем они смогут быть уверены, что их транзакция будет записана в историю блокчейна.

Иллюстрация процесса транзакции L2

Пользователи сначала ждут, чтобы их транзакция была включена в блок L2, затем ждут, пока блок L2 будет загружен на L1 с помощью транзакции L1, и, наконец, ждут завершения транзакции L1. Хотя ожидание включения транзакции L2 в блок L2 с помощью Sequencer добавляет шаг по сравнению с транзакциями L1, этот период ожидания обычно не значителен, если ёмкость блока L2 большая и скорость генерации блока быстрая. Большинство времени ожидания фактически тратится на подтверждение транзакции L1. Таким образом, в целом, пользовательский опыт для транзакций L1 и L2 похож. Но могут ли пользователи пожертвовать чем-то ради лучшего опыта?

Pre-Confirmation/Fast Confirmation/Soft Confirmation

В идеале пользователи должны быть свидетелями того, как их транзакции L2 (включенные в блоки L2) включаются в блоки L1, и даже подождать, пока вероятность реорганизации не станет достаточно низкой, прежде чем доверять тому, что их транзакции L2 были включены. Но что делать, если пользователи готовы доверять секвенсору? Предположим, что секвенсор управляется командой разработчиков L2 или авторитетным учреждением. Если Секвенсор заверяет пользователей при получении их транзакций, что они будут включены немедленно или в X-й блок, этой гарантии может быть достаточно для тех, кто готов доверять Секвенсору. Это похоже на то, как если бы пользователь, который доверял своему приложению-кошельку, не проверял Etherscan на предмет подтверждения транзакции после того, как кошелек уведомил его о включении.

Это обеспечение, предоставленное Секвенсером, называется Предварительным подтверждением, Быстрым подтверждением или Мягким подтверждением. Их можно понимать как «преждевременные» или «мягкие» заверения включения транзакции. Не требуется ожидание включения транзакции L2 в блок L1, но это просто устные обязательства от Секвенсера. Секвенсер может забыть свое обещание из-за ошибки или злонамеренный Секвенсер может нарушить свое обещание, что приведет к потере времени для пользователя или, в худшем случае, к угрозе «атаки на двойные расходы».

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

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

В настоящее время, после того как пользователи отправляют транзакцию на Arbitrum или Optimism, они практически сразу же получают квитанцию о транзакции, которая включает в себя результат выполнения транзакции. Это указывает на то, что 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:

[Изображение показывает транзакцию, подтвержденную Sequencer, но не загруженную на L1]

В отличие от этого, на следующем изображении показана транзакция, которая уже была загружена на L1, со статусом "69 подтверждений блока L1". Это означает, что блок L1, содержащий эти данные транзакции, имеет 69 последующих блоков, что указывает на более высокий уровень безопасности:

[Изображение показывает транзакцию на L1 с 69 подтверждениями блоков]

Еще один пример - транзакция с подтверждениями блока 6174 L1, как показано ниже, которая считается очень безопасной.

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

Проверка статуса включения транзакций на Optimism

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

[Изображение показывает транзакцию, подтвержденную только Секвенсором, но не загруженную на L1]

Тем не менее, Explorer не дает четкого определения значения термина «Подтверждено секвенсором». В нем говорится: «Подтверждения секвенсора эквивалентны нескольким подтверждениям блоков на L1», предполагая, что транзакция, помеченная как «Подтверждено секвенсором», была загружена в L1 и имеет несколько следующих блоков:

[Изображение показывает недавние транзакции, отмеченные как «Подтверждено секвенсором»]

Транзакции за несколько дней назад, даже те, которые прошли период тестирования, по-прежнему отображаются со статусом «Подтверждено секвенсором»:

[Изображение показывает транзакции, сделанные дни назад, все еще помеченные как «Подтверждено Секвенсером»]

Примечание: В Explorer могут отображаться разные статусы в разных местах: «Подтверждено секвенсором» рядом с номером блока указывает на то, что блок был подтвержден секвенсором. Чтобы проверить статус после загрузки на L1, пользователям необходимо искать другую информацию, такую как упомянутый ниже «Пакет состояний L1».

Как показано на следующем скриншоте, транзакция, уже загруженная на L1, содержит дополнительную информацию: «L1 State Batch Index» и «L1 State Root Submission Tx Hash». Эти детали указывают, в каком State Batch включена L2 транзакция и какая L1 транзакция загрузила этот State Batch на L1:

[Изображение показывает транзакцию с информацией L1 State Batch]

Нажатие на партию "3480" показывает ее статус как завершенный. Этот завершенный статус соответствует основной сети Ethereum и указывает на очень безопасное состояние, успешно накопившее два эпохи голосов валидаторов.

[Image shows State Batch 3480 finalized in L1 Block 18457449]

Источник: https://etherscan.io/block/18457449

Если партия была загружена, но еще не была завершена на уровне L1, она будет отображаться как незавершенная:

[Изображение показывает группу штатов, загруженную на L1, но еще не завершенную]

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

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

В настоящее время, когда пользователи отправляют транзакции в StarkNet, они могут быстро получить доступ к квитанции о транзакции. Однако в квитанции часто отображается статус RECEIVED, указывающий на то, что узел получил и проверил транзакцию как безошибочную. Затем он будет ожидать включения и выполнения в блоке L2 секвенсором. Транзакции в статусе RECEIVED еще не имеют результатов выполнения. Пользователи могут следить за ходом своих транзакций с помощью статуса, отображаемого в StarkNet Explorer.

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

На Starkscan, исследователе StarkNet, отображаются транзакции, включая предварительное подтверждение. Например, транзакция, отображаемая как "Принято на уровне L2", указывает, что она была упорядочена в блок L2:

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

Два предшествующих статуса, Получено и Ожидание, представляют собой «транзакция получена и проверена» и «транзакция обрабатывается Секвенсором». После обработки статус меняется на Принято на L2.

Транзакция получена и проверена

Транзакция обрабатывается Sequencer

После загрузки данных транзакции на L1 статус изменится на Принято на L1, как показано на рисунке ниже для этой транзакции:

Данные транзакции были загружены на L1

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

StarkNet Explorer только показывает принятое состояние на L1 без сопровождающей информации о L1 Finality или подтверждении блока. Пользователи должны проверить, достаточно ли блоков было добавлено после их транзакции на L1, или она была завершена.

Из-за ограничений производительности StarkNet, длительной зависимости от предварительного подтверждения и отсутствия поддержки информации о L1 Finality в Explorer, пользовательский опыт подтверждения включения транзакции на StarkNet требует улучшения.

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

Подобно StarkNet, у zkSync также есть статус ОЖИДАНИЕ, который указывает на то, что узел получил и проверил транзакцию без проблем. Затем транзакция будет ждать включения и выполнения в блоке L2 с помощью Sequencer. Транзакции со статусом ОЖИДАНИЕ еще не имеют результатов выполнения.

Пользователи могут отслеживать прогресс своих транзакций через статус, отображаемый в zkSync Explorer.

Подсказка: Если последователь обрабатывает транзакции достаточно быстро, он может обойти статус ОЖИДАНИЯ и перейти прямо к состоянию, когда транзакция уже была обработана.

Для более подробного введения в процесс транзакции 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 и перешел в стадию Committed. Source: https://explorer.zksync.io/batch/292700

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

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

Эта транзакция перешла в стадию "Проверки". Ссылка на транзакцию для загрузки пакета на L1 на предыдущей стадии (Отправка) также может быть видна прямо здесь.

Партия 292000 была доказана своей действительностью, поэтому она переходит в стадию Подтверждено:

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

Транзакции затем переходят из состояния "Проверка" в состояние "Выполнение", что означает, что они ожидают выполнения.

После того как пакет подтвержден, есть период ожидания (приблизительно 21 час согласно официальной документации) перед выполнением транзакций внутри него и обновлением состояния L2, записанного на L1. Это защитная мера на начальном этапе Alpha, чтобы обеспечить достаточное время реакции в случае ошибок. Как только пакет выполнен, он переходит в окончательную стадию выполнения:

После выполнения пакета он входит в конечное состояние "Выполнено", с ссылкой на транзакцию, выполняющую действие Выполнить.

Статус транзакций в рамках пакета также обновляется на «Выполнено».

По сравнению со StarkNet, где транзакции перемещаются из L2 в L1 за один шаг, zkSync разбивает процесс от L2 до L1 на три более детальных этапа: Зафиксировано → Проверено → Выполнено. Несмотря на то, что в качестве защитной меры весь процесс транзакции занимает около суток, статус Committed позволяет пользователям быстро узнать, была ли их транзакция включена (после Committed, это не только Pre-Confirmation), не полагаясь исключительно на доверие к Sequencer. Кроме того, zkSync Explorer предоставляет исчерпывающие данные для каждого этапа, позволяя любому отслеживать последний статус транзакций и даже проверять переходы между этапами (например, от Committed к Proved, от Proven к Executed).

Однако важно отметить, что в качестве защитной меры в фазе Alpha сейчас zkSync Sequencer может изменять исторические записи. Это означает, что даже если транзакции могут быстро переходить из стадии Предварительного подтверждения в стадию Подтверждения, Sequencer все еще может удалить транзакции пользователей из исторической записи до тех пор, пока они не достигнут стадии Выполнено. Поэтому пользователи все еще должны доверять Sequencer'у до одного дня.

L1 также может поддерживать предварительное подтверждение

Если возможно заранее знать, кто несет ответственность за создание блоков, то L1 также может поддерживать предварительное подтверждение. Возьмем Ethereum в качестве примера: фактическим производителем блока является Builder, который может предоставлять услуги предварительного подтверждения, обеспечивая пользователям гарантию включения транзакции. Однако, поскольку у Builder нет гарантированного права на производство конкретного блока, а должен каждый раз торговаться за право на производство каждого блока, эффективность этого предварительного подтверждения относительно слабая. Кроме того, необходимо учитывать силу Builder: если у 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 о данных L2, загруженных на L1.

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

Ниже приведена таблица гарантий включения транзакций и соответствующих сценариев риска для различных этапов транзакций L1 и L2: [Обратите внимание, что таблица не предоставляется в переводе.]

Disclaimer：

1. Эта статья перепечатана из [imToken Labs]. Все авторские права принадлежат оригинальному автору [Ник]. Если есть возражения против этого перепечатывания, пожалуйста, свяжитесь с Gate Learnкоманда, и они незамедлительно разберутся с этим.
2. Ответственность за отказ: Взгляды и мнения, выраженные в этой статье, являются исключительно точкой зрения автора и не являются инвестиционными советами.
3. Переводы статьи на другие языки выполняются командой Gate Learn. Если не указано иное, копирование, распространение или плагиат переведенных статей запрещены.