Интерпретация всего процесса реализации L2-транзакции: каковы показатели безопасности каждого этапа?

Автор: Nic@ imToken Labs

Когда я могу быть уверен, что L2-транзакция будет включена в блок? Когда я могу быть уверен, что доход от L2-транзакции не будет сброшен из-за реорганизации?

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

Необходимые условия:

• Весь процесс транзакций L1 (Layer 1)
• Причины и следствия реорганизации
• Понять текущую роль Ethereum в архитектуре PBS и то, как она работает
• Понимать различия между оптимистичными накопительными пакетами и накопительными пакетами валидности (ZK)

Подробнее о транзакциях L1

ПРОЦЕСС ТРАНЗАКЦИИ

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

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

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

Подробнее о транзакциях L2

ПРОЦЕСС ТРАНЗАКЦИИ

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

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

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

Сначала пользователь ожидает, пока транзакция будет включена в блок L2, затем ожидает, пока блок L2 будет загружен в блок L1 через транзакцию L1, и, наконец, ожидает завершения транзакции L1.

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

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

Предварительное подтверждение/Быстрое подтверждение/Мягкое подтверждение

Пользователь должен видеть, что блок L2 (содержащий транзакции L2) включается в блок L1, и даже ждать, пока вероятность возникновения реорганизации не станет достаточно низкой, чтобы поверить, что его транзакция L2 была заработана.

Но что делать, если пользователь готов доверять Sequencer? Возможно, Sequencer управляется командой разработчиков L2, управляемой авторитетной организацией, и если Sequencer заверяет пользователя, что его транзакция будет оплачена немедленно, на X-м блоке, то этой гарантии достаточно для пользователя, который готов доверять Sequencer. Точно так же, как если пользователь доверяет кошельку, который он использует, он не будет подозрительно заходить в Etherscan, чтобы перепроверить после того, как кошелек предупредил его о том, что транзакция была оплачена.

Гарантия дохода от транзакции, предоставляемая этим секвенсором, называется предварительным подтверждением, быстрым подтверждением или мягким подтверждением, что можно понимать как «раннюю» или «мягкую» гарантию дохода от транзакции. Ему не нужно ждать, пока транзакции L2 будут включены в блок L1, но это только устное обещание, данное Sequencer, и Sequencer может забыть исходное обещание из-за ошибок или вредоносный Sequencer напрямую нарушит обещание, что может привести к потере времени пользователя или к «Double Spend Attack».

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

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

В настоящее время пользователи, отправляющие транзакцию на Arbitrum или Optimism, могут практически сразу получить Transaction Receipt, которая и будет являться результатом исполнения транзакции. Это означает, что Sequencer уже секвенировал и смоделировал выполнение транзакций локально, и это получение транзакции является предварительным подтверждением для пользователя.

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

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

Проверить статус дохода от транзакций на Arbitrum

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

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

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

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

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

Но что можно сделать лучше, так это объединить информацию о завершении L1.

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

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

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

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

Тем не менее, Explorer, похоже, не имеет четкого определения, что означает Confirmed by Sequencer, говоря: «Подтверждения Sequencer эквивалентны нескольким подтверждениям блоков на L1.», указывая на то, что Confirmed by Sequencer представляет собой количество Block, которые были загружены в L1 и за которыми следовали несколько:

Но на самом деле последняя транзакция также отображается как Confirmed by Sequencer, и даже десятки дней назад статус транзакции, прошедшей период запроса, по-прежнему Confirmed by Sequencer:

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

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

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

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

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

Источник:

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

Несмотря на то, что State Batch 3494 был загружен в L1, блок L1, включенный в пакет, еще не завершен.

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

Статус торгового заработка StarkNet

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

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

Официальные документы: _and_concepts/network_Architecture/transaction-life-cycle/

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

“Accepted on L2” означает, что он был помещен в блок L2 Sequencer, но еще не был загружен в L1

Первые два состояния Accepted на L2 — Received и Pending, что означает, что «транзакция получена и проверена» и «транзакция обрабатывается Sequencer», и транзакция перейдет в состояние Accepted на L2 после выполнения транзакции:

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

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

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

Данные о транзакциях загружены в L1

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

Кроме того, Explorer отображает Accepted on L1 только для транзакций, загруженных в L1, и не имеет информации о завершении или подтверждении блока с L1, что означает, что пользователи должны проверить, достаточно ли блоков в блоке L1 или они были завершены.

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

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

Как и StakrNet, zkSync также имеет состояние PENDING (Ожидание), что означает, что Node получил транзакцию и транзакция была проверена без проблем, он будет ждать, пока транзакция будет заблокирована и выполнена Sequencer L2, в то время как транзакция в состоянии PENDING не будет иметь никакого результата выполнения транзакции.

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

Совет по прочтению: Если Sequencer обрабатывается достаточно быстро, можно пропустить состояние PENDING и перейти к состоянию, в котором транзакция уже была обработана.

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

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

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

После того, как Sequencer создаст блок L2, блок и транзакции в нем пройдут три фазы последовательно: Committed, Proven и uted, указывая на то, что «Блок был загружен в L1», «Валидность блока была доказана» и «Статус L2 был обновлен до L1 после выполнения транзакции блока». Блок и транзакция на разных этапах показаны ниже:

Пакет 292700 был загружен в L1 и находится на этапе фиксации. Источник:

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

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

Эта транзакция переходит в стадию «Валидация», и ссылку на транзакцию, которая загрузила Batch в L1 на предыдущем этапе (Отправка), также можно увидеть здесь.

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

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

Транзакция также перейдет из состояния «validating» в состояние «uting», то есть в состояние ожидания выполнения.

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

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

Статус транзакции в пакетной службе также был изменен на “uted”

В отличие от StarkNet, где транзакции L2 на L1 выполняются в один шаг, процесс zkSync по перемещению L2 на L1 разбит на три более детальных этапа: Committed → Proven → uted.

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

Кроме того, zkSync Explorer обеспечивает богатое и полное отображение данных для различных этапов, так что любой может получить последний статус транзакций через проводник и даже иметь возможность лично проверить выполнение транзакций при переходе каждого этапа (например, от Committed к Proven, от Proven к uted).

Однако следует отметить, что в качестве меры защиты для альфа-фазы история может быть изменена zkSync Sequencer в это время.

Это говорит о том, что, несмотря на то, что транзакция может быстро перейти из фазы предварительного подтверждения в фазу фиксации, Sequencer может удалить транзакцию пользователя из истории до того, как транзакция перейдет в фазу фиксации. Таким образом, потребители по-прежнему должны доверять Sequencer на срок до одного дня.

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

Если вы можете заранее знать, кто отвечает за производство блоков, то L1 также может поддерживать предварительное подтверждение.

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

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

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

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

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

Предварительное подтверждение — это всего лишь устное обещание Builder или L2 Sequencer, и другая сторона не обязана выполнять обещание, и нет механизма штрафов за невыполнение.

Можно ли сделать это обещание более надежным? На самом деле, да, потому что лицо, ответственное за создание блока, и содержание его обещания (например, «в блоке 1 350 000 транзакция дохода») может быть записано как проверка состояния. Таким образом, мы можем использовать смарт-контракт для регулирования Builder или Sequencer, попросить их предоставить услуги Pre-Confirmation при обеспечении депозита в смарт-контракте и подписать контент при обещании дохода от транзакции, когда пользователь обнаружит, что Builder или Sequencer не выполнил обязательство, обещанный контент и подпись другой стороны могут быть отправлены в смарт-контракт, и смарт-контракт может проверить, было ли выполнено обязательство (например, «в первом 1 350 000 Block Revenue за эту транзакцию»).

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

Резюме

• После того, как L1-транзакции будут включены в L1-блоки, вероятность Re-org будет постепенно падать, а уверенность пользователей в транзакционном доходе будет постепенно расти.
• На один рабочий процесс транзакций L2 больше, чем для транзакций L1, — это этап, на котором транзакции L2 включаются в блоки L2 и ожидают загрузки в L1.
• Однако в транзакционном рабочем процессе, где транзакций L2 больше, чем транзакций L1, поскольку данные еще не загружены в L1 на этом этапе, все еще существует возможность переменных, поэтому гарантией дохода от транзакций, которую пользователи могут получить на этом этапе, является устное обещание Sequencer, которое называется Pre-Confirmation или Fast Confirmation, Soft Confirmation.
• Если Sequencer является вредоносным или если есть простая ошибка, то обещание, сделанное Sequencer, может быть нарушено, что приведет к непризнанию дохода за транзакции L2 пользователя.
• В настоящее время большинство статусов транзакций L2 в их Проводнике включают статус Pre-Confirmed, например, Confirmed by Sequencer для Arbitrum/Optimism или Accepted on L2 for StarkNet. Когда вы видите такую информацию, пожалуйста, обратите внимание на срок действия гарантии дохода от транзакции, предоставляемой этой информацией.
• Если вы не хотите доверять предварительному подтверждению, предоставляемому Sequencer, вам нужно будет подождать еще немного и свериться с информацией, предоставленной обозревателем L2, о данных, загружаемых на L1.
• Предварительное подтверждение может сочетаться с разработкой экономических стимулов, таких как штрафы через смарт-контракт, когда Sequencer нарушает обязательства, чтобы пользователи могли получить более четкую защиту.

В таблице ниже показана гарантия дохода от транзакции и соответствующие сценарии риска, предоставляемые транзакциями L1 и L2 на разных этапах транзакционного процесса: