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

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

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

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

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

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

После того, как пользователь выпускает и подписывает транзакцию, она отправляется в сеть p2p, ожидая включения в блок либо майнером в рамках механизма консенсуса Proof of Work (PoW), либо Proposer в соответствии с механизмом консенсуса Proof of Stake (PoS). Когда пользователь замечает, что его транзакция была включена в последний блок, он еще не уверен, что транзакция будет навсегда записана в историю блокчейна. Эта неопределенность связана с возможностью «реорганизации» (реорганизации), происходящей в блокчейне. Пользователи должны подождать, пока вероятность реорганизации не станет достаточно низкой, чтобы быть уверенными в том, что их транзакция будет навсегда записана в историю блокчейна.

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

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

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

Понимание транзакций 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 почти мгновенно могут получить квитанцию о транзакции после отправки транзакции, указывающую на результат выполнения транзакции. Это означает, что Seque[ncer] уже локально упорядочил и симулировал транзакцию, предоставляя пользователям Предварительное Подтверждение.

Узнать больше

Для получения более подробной информации о жизненном цикле транзакции 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), которая будет содержать результаты выполнения транзакции. Это означает, что Секвенсер локально отсортировал транзакцию и один раз её симулировал. Эта квитанция о транзакции является Предварительным подтверждением, предоставленным пользователю.

узнать больше

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

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

Для более подробного знакомства с жизненным циклом транзакции в Optimism вы можете скопировать ссылку ниже в браузер и обратиться к официальному документу:

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

Проверьте статус поступления транзакции на Arbitrum

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

На рисунке выше показаны транзакции, которые были подтверждены только Sequencer, но еще не были загружены на L1.

Если это транзакция, которая была загружена на уровень L1, как показано на рисунке ниже, ее статус изменился на 69 подтверждений блока L1, что означает, что она была загружена на уровень L1, и в блоке Layer1, содержащем данные транзакции, за ним следует 69 блоков:

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

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

Но, на самом деле, что можно сделать лучше здесь, это представить его в сочетании с информацией о финальности L1.

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

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

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

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

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

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

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

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

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

Нажав на "State Batch 3480", его статус отображается как Завершено, соответствующее Завершенному статусу на уровне L1 (т.е. основной сети Ethereum), который является высоко защищенным статусом, достигнутым после накопления голосов от валидаторов за два периода.

△ Состояние пакета 3480 включено в блок L1 18457449, и блок 18457449 был завершен.

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

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

Пакет состояния 3494, хотя и размещен в L1, включен в блок L1, который не был завершен:

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

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

В настоящее время, когда пользователи отправляют транзакции на StarkNet, они могут быстро запросить квитанцию о транзакции. Однако квитанция часто показывает статус транзакции как ПОЛУЧЕНО. Этот статус указывает на то, что узел получил транзакцию и после проверки не обнаружил проблем. Транзакция ожидает включения в блок L2 Секвенсором и выполнения. Транзакции со статусом ПОЛУЧЕНО пока не имеют результатов выполнения. Пользователи могут отслеживать прогресс своих транзакций, просматривая статус транзакции, отображаемый в StarkNet Explorer.

Совет по чтению: Если последователь обрабатывает транзакции достаточно быстро, он может обойти статус ПОЛУЧЕНО и сразу перейти в обработанный состояние. Для более подробного введения в процесс транзакции на StarkNet вы можете скопировать ссылку ниже в свой браузер, чтобы проконсультироваться с официальными документами.

Официальные документы:Жизненный цикл транзакции StarkNet

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

Принято на L2 означает, что это было поставлено в очередь Секвенсором в блок L2, но еще не загружено на L1.

Два статуса перед "Принято на уровне L2" - Получено и В ожидании, представляют собой "транзакция получена и проверена" и "транзакция обрабатывается Sequencer'ом" соответственно. После завершения выполнения обработки транзакции она перейдет в статус "Принято на уровне L2":

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

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

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

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

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

Кроме того, исследователь отображает только «Принято на уровне L1» для транзакций, загруженных на уровень L1, без сопутствующей информации о L1 Финальности или Подтверждении блока. Это означает, что пользователям приходится самостоятельно проверять, достаточно ли уровень L1 имеет последующих блоков или был завершен.

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

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

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

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

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

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

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

Эта транзакция была поставлена в очередь в блок L2 Sequencer и в настоящее время ожидает загрузки на L1 (Отправка Ethereum)

После завершения последовательности L2 блока блок и транзакции в нем пройдут через три этапа: Зафиксированный, Доказанный и Выполненный, что соответственно означает "блок был загружен на L1" и "доказана действительность блока". И "статус L2 обновляется до L1 после выполнения транзакции в блоке". Ниже показаны три блока и транзакции на разных этапах:

Пакет 292700 был загружен в L1 и перешел в стадию Committed. Источник: https://explorer.zksync.io/batch/292700

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

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

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

Эффективность Batch 292000 доказана, поэтому он переходит на этап Proven:

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

Транзакции внутри также перейдут в стадию «Выполнение» из стадии «Проверка», ожидая выполнения.

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

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

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

Уровень 1 также может поддерживать Предварительное подтверждение

Если заранее известно, кто отвечает за производство блоков, то L1 также может поддерживать Pre-Confirmation. Если взять в качестве примера Ethereum, то фактическим производителем блока является Builder, который может предложить услуги предварительного подтверждения, давая пользователям гарантию включения транзакции. Однако, поскольку Застройщик не обязательно имеет право производить определенный блок, но должен участвовать в торгах за право производства каждого блока, эффективность Предварительного подтверждения может быть слабее. Кроме того, необходимо учитывать конкурентоспособность Застройщика; Если Застройщик недостаточно конкурентоспособен, ему будет сложно получить право на производство блоков, что значительно снизит надежность его услуг по предварительному подтверждению. Чтобы избежать этих проблем, лучшим подходом было бы разрешить Инициаторам предоставлять услуги по предварительному подтверждению, поскольку обычно это заранее определено и определено, кто из Инициаторов предложит какой блок. Тем не менее, в текущей архитектуре PBS инициаторы предлагают только блоки, а фактическое производство блоков и принятие решений по контенту выполняются создателями, поэтому инициаторы предложения не могут напрямую вставлять транзакцию в блок или требовать от создателя этого. В будущем, если архитектура PBS изменится, например, путем добавления списка включения или разрешения Авторам предложений участвовать в производстве блоков, у Инициаторов может появиться возможность предлагать услуги по предварительному подтверждению. Для получения дополнительной информации о PBS, пожалуйста, перейдите по предоставленной ссылке.

Улучшение предварительного подтверждения:

Предварительное подтверждение — это всего лишь устное обязательство Строителей или Секвенсоров L2, без каких-либо обязательств по выполнению обещания и без механизма наказания за невыполнение. Тем не менее, можно сделать это обязательство более надежным, используя смарт-контракты для стандартизации Builders или Sequencers. Они могут предоставлять услуги предварительного подтверждения, а также вносить залог в смарт-контракт и подписывать контент при обещании включения транзакции. Если пользователи обнаружат, что конструкторы или секвенсоры не выполнили свои обещания, они могут отправить содержимое промисов и подпись смарт-контракту, который затем может проверить, было ли выполнено обещание. Несмотря на то, что сценарий применения вышеупомянутого контракта все еще находится на стадии проверки концепции, по ссылке ниже приведено презентационное видео одного из примеров применения такого контракта.

Обзор:

После включения L1-транзакций в L1-блоки вероятность реорганизации снижается, а доверие пользователей к включению транзакций постепенно повышается. Транзакции L2 имеют дополнительный рабочий процесс по сравнению с транзакциями L1: «Транзакции L2 включаются в блоки L2 и ожидают загрузки в L1». Однако, поскольку данные не были загружены в L1 на этом этапе, все еще существует вероятность отклонения, поэтому гарантией, которую пользователи могут получить о включении транзакции на этом этапе, является устное обязательство от секвенсора, известное как предварительное подтверждение или быстрое подтверждение/мягкое подтверждение. Если секвенсор является вредоносным или просто сталкивается с ошибкой, его обещание может быть нарушено, что приведет к отсутствию подтверждения транзакции L2 пользователя. В настоящее время большинство L2 отображают статусы транзакций в своих эксплорерах, которые включают статус Pre-Firmation, такие как Approved by Sequencer от Arbitrum/Optimism или StarkNet от StarkNet на L2. При просмотре такой информации важно обращать внимание на временную эффективность предоставленной гарантии включения транзакций. Если пользователи не хотят полагаться на предварительное подтверждение секвенсора, им придется подождать дольше и проверить информацию L2 Explorer о данных L2, загружаемых в L1. Предварительное подтверждение может включать в себя механизм экономического стимулирования, такой как наказание секвенсоров с помощью смарт-контрактов, когда они нарушают свои обещания, обеспечивая пользователям более четкую защиту. В таблице ниже приведены гарантии включения транзакций и соответствующие сценарии рисков, предоставляемые сделками L1 и L2 на разных этапах транзакционного процесса.

Disclaimer：

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