¿Cuándo se puede estar seguro de que una transacción de L2 (Capa 2) se incluirá en un bloque? ¿Cuándo se puede estar seguro de que los ingresos de una transacción de L2 no se descartarán debido a una Re-org?

Este artículo presentará todo el proceso de implementación de transacciones L2 y analizará el rendimiento de seguridad en cada etapa del proceso de transacción.

Conocimientos Previos:

• Todo el proceso de transacciones L1 (Capa 1)
• Razones e impactos de las ocurrencias de Re-org
• Comprendiendo los roles y métodos de operación en la arquitectura actual de PBS de Ethereum
• Diferencias entre Optimistic Rollup y Validity (ZK) Rollup

Comprendiendo transacciones L1

Proceso de transacción

Después de que un usuario emite y firma una transacción, se envía a la red p2p, a la espera de ser incluida en un bloque por un minero bajo el mecanismo de consenso Proof of Work (PoW) o un proponente bajo el mecanismo de consenso Proof of Stake (PoS). Cuando un usuario se da cuenta de que su transacción se ha incluido en el último bloque, aún no es seguro que la transacción se registre permanentemente en el historial de la cadena de bloques. Esta incertidumbre se debe a la posibilidad de que se produzca una "Re-org" (reorganización) en la cadena de bloques. Los usuarios deben esperar hasta que la probabilidad de que ocurra una reorganización sea lo suficientemente baja como para estar seguros de que su transacción se registrará permanentemente en el historial de la cadena de bloques.

Proceso de transacción L1 ilustrado

Incluso después de que una transacción se incluya en un bloque, todavía puede ocurrir un Re-org, lo que significa que la confirmación solo puede asegurarse una vez que la probabilidad de un Re-org se vuelve poco probable.

La probabilidad y el costo de un Re-org varían con el algoritmo de consenso de cada blockchain y el valor de mercado de sus activos. Este documento no profundizará en los métodos de cálculo de los costos de Re-org.

Comprender Transacciones L2

Proceso de transacción

Los usuarios de L2 generan y firman transacciones, generalmente enviándolas directamente a un Secuenciador, quien luego incluye estas transacciones en un bloque de L2. Posteriormente, cuando el Secuenciador publica los datos del bloque de L2 de vuelta a L1 a través de una transacción de L1, los usuarios pueden ver sus transacciones incluidas en el último bloque de L2.

Sin embargo, es importante tener en cuenta que dado que los datos de bloque L2 se publican en L1 a través de una transacción L1, todavía es posible que ocurra un Re-org de L1, lo que podría resultar en que el bloque L2 no se registre permanentemente en la historia de la cadena de bloques. Este escenario es similar a un Re-org de L2, por lo que los usuarios deben esperar hasta que la probabilidad de un Re-org de L1 sea lo suficientemente baja como para estar seguros de que su transacción se registrará permanentemente en la historia de la cadena de bloques.

Proceso de Transacción L2 Ilustrado

Los usuarios primero deben esperar a que su transacción se incluya en un bloque L2, luego a que el bloque L2 se publique en L1 a través de una transacción L1, y finalmente a que la transacción L1 se finalice.

Aunque las transacciones L2 implican un tiempo de espera adicional para su inclusión en un bloque L2 por el Secuenciador en comparación con las transacciones L1, esta espera suele ser corta si la capacidad del bloque L2 es grande y la generación de bloques es rápida, ya que el principal período de espera es para que la transacción L1 sea confirmada. Por lo tanto, la experiencia general del usuario en las transacciones L1 y L2 es similar.

Pre-Confirmación/Confirmación Rápida/Confirmación Suave

Los usuarios deben verificar personalmente que sus transacciones L2, junto con el bloque L2, hayan sido incluidos en un bloque L1, e incluso esperar hasta que la probabilidad de un Re-org sea suficientemente baja para confiar en que su transacción L2 haya sido incluida.

Pero ¿qué pasa si los usuarios están dispuestos a confiar en el Secuenciador? El Secuenciador podría ser operado por el equipo de desarrollo de L2 o una institución de reputación. Si el Secuenciador asegura a los usuarios inmediatamente al recibir sus transacciones que serán incluidas en un bloque específico, esta garantía puede ser suficiente para aquellos dispuestos a confiar en el Secuenciador. Es similar a un usuario que confía en la aplicación de su billetera y no verifica obsesivamente Etherscan para confirmación después de ser notificado de la inclusión de una transacción.

Tales garantías proporcionadas por el Secuenciador se conocen como Preconfirmación, Confirmación Rápida o Confirmación Suave. Estas se consideran como garantías "preliminares" o "suaves" de inclusión de transacciones, no requiriendo que la transacción L2 se incluya en un bloque L1. Sin embargo, estas son simplemente compromisos verbales por parte del Secuenciador, que podrían ser olvidados debido a un error o ser quebrantados deliberadamente por un Secuenciador malintencionado, resultando en el peor de los casos en un ataque de doble gasto.

Posteriormente, presentaremos las diversas formas en que se presentan los estados de inclusión de transacciones L2.

Estado de inclusión de transacciones de Arbitrum/Optimism

Actualmente, los usuarios en Arbitrum u Optimism casi pueden recibir inmediatamente un recibo de transacción después de enviar una transacción, lo que indica el resultado de la ejecución de la transacción. Esto significa que el Secuenciador ya ha secuenciado y simulado localmente la transacción, proporcionando a los usuarios una Preconfirmación.

Más información

Para obtener información más detallada sobre el ciclo de vida de la transacción de Arbitrum, consulte la documentación oficial:https://docs.arbitrum.io/tx-lifecycle

Para obtener información más detallada sobre el ciclo de vida de la transacción de Optimism, consulte la documentación oficial:https://community.optimism.io/docs/protocol/txn-flow/#posting-to-l1

Estado de ingresos comerciales para Arbitrum/Optimism

Actualmente, después de que los usuarios envíen una transacción en Arbitrum u Optimism, casi inmediatamente pueden obtener un recibo de transacción (Receipt de Transacción), que contendrá los resultados de la ejecución de la transacción. Esto significa que el Secuenciador ha secuenciado la transacción localmente y la ha simulado una vez. Este recibo de transacción es la Preconfirmación proporcionada al usuario.

aprender más

Para obtener una introducción más detallada al ciclo de vida de transacción de Arbitrum, puede copiar el enlace a continuación en el navegador para consultar el documento oficial:

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

Para obtener una introducción más detallada al ciclo de vida de la transacción de Optimism, puede copiar el enlace a continuación en el navegador y consultar el documento oficial:

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

Verificar el estado de ingresos de transacciones en Arbitrum

Las transacciones vistas en Arbitrum Explorer incluirán transacciones de preconfirmación, es decir, transacciones que no se han subido a L1. Para esta transacción, como se muestra en la figura a continuación, puedes ver una marca de Confirmado por el Secuenciador junto al Número de Bloque 145353000:

La imagen de arriba muestra transacciones que solo han sido confirmadas por Sequencer pero aún no han sido cargadas en L1.

Si se trata de una transacción que se ha subido a L1 como se muestra en la figura a continuación, su estado ha cambiado a 69 confirmaciones de bloque L1, lo que significa que se ha subido a L1 y el bloque de Layer1 que contiene los datos de la transacción tiene 69 bloques siguientes:

El bloque L1 que contiene estos datos de transacción ya tiene 69 bloques que lo siguen. Cuantos más bloques lo sigan, más seguro será.

O para esta transacción, como se muestra en la captura de pantalla a continuación, el bloque L1 que contiene los datos de esta transacción ya tiene 6174 bloques siguientes, lo que ya es muy seguro.

Pero de hecho, lo que se puede hacer mejor aquí es presentarlo en combinación con la información de Finality de L1.

Simplemente decirle al usuario cuántas confirmaciones de bloque L1 hay es de ayuda limitada para el usuario, porque el usuario tiene que comprender y calcular el nivel de seguridad representado por dicho número de confirmaciones de bloque. Y dado que Layer1 (es decir, Ethereum) ya tiene un mecanismo de Finalidad como Casper FFG, Explorer realmente puede mostrar directamente si el bloque de Layer1 ha sido Finalizado en Layer1. Actualmente, el Explorer de Optimism ha implementado dicha función.

Verificar el estado del recibo de transacción en Optimism

Las transacciones vistas en el Explorador de Optimism pueden incluir aquellas marcadas como Pre-Confirmación, lo que indica que aún no se han publicado en la Capa 1 (L1). Como se ilustra a continuación, la transacción con el Número de Bloque 111526300 está etiquetada como "Confirmado por el Secuenciador":

Las transacciones solo son confirmadas por el Secuenciador pero aún no son publicadas en L1

Actualmente, el Explorador parece carecer de una definición clara para "Confirmado por el Secuenciador", lo que sugiere que "las confirmaciones del Secuenciador son equivalentes a algunas confirmaciones de bloques en L1." Esto implica que ser "Confirmado por el Secuenciador" significa que la transacción ha sido publicada en L1 y tiene varios bloques que la siguen:

Sin embargo, las transacciones recién aparecidas también se muestran como "Confirmadas por el Secuenciador," e incluso las transacciones de hace muchos días, que han pasado el período de desafío, permanecen en el estado de "Confirmadas por el Secuenciador":

Las transacciones de hace días todavía se encuentran en el estado de "Confirmado por el Secuenciador"

Nota de lectura: Esta situación también podría deberse a que el Explorador presenta diferentes indicadores de estado en varios lugares: "Confirmado por el Secuenciador" junto al Número de Bloque informa a los usuarios que el bloque ha sido confirmado por el Secuenciador. Para verificar el estado posterior a L1, los usuarios deben hacer referencia a otra información, como los detalles del "Lote de Estado L1" discutidos a continuación.

Además, como se muestra en la captura de pantalla a continuación, una transacción que se ha publicado en L1 incluye dos piezas de información adicionales: “Índice de Lote de Estado L1” y “Hash de Transacción de Envío de Raíz de Estado L1”. Estos detalles representan en qué Lote de Estado se incluye la transacción L2 y a través de qué transacción L1 se publicó este Lote de Estado en L1:

Al hacer clic en "Lote de Estado 3480," su estado se muestra como Finalizado, correspondiente al estado Finalizado en L1 (es decir, la mainnet de Ethereum), que es un estado altamente seguro logrado después de acumular votos de validadores durante dos épocas.

△ El lote de estado 3480 está incluido en el Bloque L1 18457449, y el Bloque 18457449 ha sido finalizado.

Origen:https://etherscan.io/block/18457449

Si un lote ha sido publicado pero aún no se ha finalizado en L1, se mostrará como No finalizado:

El lote de estado 3494, aunque publicado en L1, está incluido en un bloque L1 que no ha sido finalizado：

En comparación con el Explorador de Arbitrum, el Explorador de Optimism proporciona información más detallada (lote de estado) y enlaza directamente la información de Finalidad L1 con el Explorador L2, lo que permite a los usuarios saber si un bloque L1 ha sido finalizado, en lugar de basarse en el número de confirmaciones de bloque para el nivel de seguridad y tomar su propia decisión.

Estado de ingresos por transacción de StarkNet

Actualmente, cuando los usuarios envían transacciones en StarkNet, pueden consultar rápidamente el recibo de la transacción. Sin embargo, el recibo a menudo muestra el estado de la transacción como RECIBIDO. Este estado indica que el nodo ha recibido la transacción y, después de la verificación, no ha encontrado problemas. La transacción está esperando ser incluida en un bloque L2 por el Secuenciador y ejecutada. Las transacciones en estado RECIBIDO aún no tendrán ningún resultado de ejecución. Los usuarios pueden verificar el progreso de sus transacciones viendo el estado de la transacción mostrado en el Explorador de StarkNet.

Consejo de lectura: Si el Sequencer procesa las transacciones lo suficientemente rápido, puede omitir el estado RECIBIDO y pasar directamente a un estado procesado. Para obtener una introducción más detallada al proceso de transacción en StarkNet, puedes copiar el enlace a continuación en tu navegador para consultar los documentos oficiales.

Documentos Oficiales:Ciclo de vida de la transacción de StarkNet

Las transacciones vistas en Starkscan, un Explorador de StarkNet, también incluyen transacciones de Pre-Confirmación. Como se muestra en la siguiente transacción, el Estado actual es “Aceptado en L2,” lo que indica que ha sido encolado por el Secuenciador en un bloque L2:

"Aceptado en L2” significa que ha sido encolado por el Secuenciador en un bloque de L2, pero aún no se ha subido a L1.

Los dos estados anteriores a "Aceptado en L2" son Recibido y Pendiente, que representan "la transacción ha sido recibida y verificada" y "la transacción está siendo procesada por el Secuenciador", respectivamente. Después de que la ejecución del procesamiento de la transacción esté completa, se moverá al estado de "Aceptado en L2".

La transacción ha sido recibida y verificada.

La transacción está siendo procesada por el Secuenciador.

Una vez que los datos de la transacción se carguen en L1, el estado cambiará a "Aceptado en L1", como se muestra en la siguiente transacción:

Los datos de la transacción se han subido a L1.

Aunque las transacciones de StarkNet tienen un conjunto más amplio de estados para informar a los usuarios sobre el progreso del procesamiento, subir transacciones a L1 aún podría requerir una espera de varias horas (posiblemente porque la generación de pruebas de conocimiento nulo lleva más tiempo). Durante este tiempo, los usuarios dependen de la Preconfirmación del Secuenciador.

Además, el Explorer solo muestra "Aceptado en L1" para las transacciones cargadas en L1, sin información acompañante sobre la Finalidad de L1 o la Confirmación de Bloque. Esto significa que los usuarios tienen que verificar por sí mismos si el bloque de L1 tiene suficientes bloques posteriores o ha sido Finalizado.

En general, debido a los cuellos de botella de rendimiento de StarkNet, los usuarios necesitan depender de la Pre-Confirmación durante un período prolongado, y el Explorador no admite información de Finalidad L1, lo que conduce a una experiencia de usuario menos satisfactoria para la confirmación de ingresos por transacciones. Esta es un área en la que StarkNet necesita mejorar en el futuro.

Estado de ingresos por transacciones zkSync

Similar to StakrNet, zkSync also has a PENDING state, which means that the node has received the transaction and there are no problems after the transaction is verified. It will wait to be included in the L2 block by the Sequencer and executed. However, no transaction will be executed in the PENDING state. the result of.

Los usuarios pueden conocer el progreso del procesamiento de sus transacciones a través del estado de la transacción mostrado en zkSync Explorer.

Consejos de lectura: Si el Secuenciador se procesa lo suficientemente rápido, puede ser posible saltar directamente el estado PENDIENTE y entrar en el estado donde la transacción ha sido procesada.

Para obtener una introducción más detallada al proceso de transacción de zkSync, puedes copiar el enlace a continuación y verlo en tu navegador: https://era.zksync.io/docs/reference/concepts/finality.html#finality-on-ethereum

Las transacciones vistas en el Explorador de zkSync también incluirán transacciones de Pre-Confirmación, como la transacción en la captura de pantalla a continuación. Puede ver que el Estado es actualmente Procesado en la Era zkSync, lo que indica que ha sido encolado en el bloque L2 por el Secuenciador:

Esta transacción ha sido encolada en el bloque L2 por el Secuenciador y actualmente está esperando ser subida a L1 (Envío de Ethereum)

Después de que el Secuenciador complete el bloque L2, el bloque y las transacciones en él pasarán por las tres etapas de Comprometido, Probado y Ejecutado, lo que significa respectivamente “el bloque ha sido cargado en L1” y “la validez del bloque ha sido probada”. Y “el estado L2 se actualiza a L1 después de que la transacción en el bloque se ejecuta.” Lo siguiente muestra tres bloques y transacciones en diferentes etapas:

El lote 292700 ha sido cargado en L1 y ha entrado en la etapa de Compromiso. Fuente: https://explorer.zksync.io/batch/292700

El estado actual de las transacciones en el Lote 292700 ha cambiado de Ethereum Sending a Ethereum Validating, lo que indica que está esperando ser verificado por una prueba de conocimiento cero para verificar su validez.

Al mover la flecha sobre el icono de Validación de Ethereum, también se mostrarán las diferentes etapas, y el enlace de la transacción para la etapa anterior (Envío) también estará adjunto:

Esta transacción ha entrado en la etapa de “Validación”. El enlace de la transacción para subir el lote a L1 en la etapa anterior (Envío) también se puede ver directamente aquí.

La efectividad del Lote 292000 ha sido probada, por lo que entra en la etapa Probada:

Después de que el lote se haya demostrado, entra en el estado Demostrado, y se adjunta un enlace de transacción para ejecutar la acción Probar.

Las transacciones internas también entrarán en la etapa de "Ejecución" desde "Validación", que está esperando ser ejecutada.

Cuando el Batch esté probado, luego entrará en un período de espera (los documentos oficiales dicen que es de aproximadamente 21 horas) antes de ejecutar las transacciones en su interior y de actualizar el estado L2 registrado en L1. Esto se debe principalmente a una medida de protección que todavía está en la etapa Alfa para asegurar que haya suficiente tiempo para reaccionar cuando ocurran errores. Cuando se ejecute el Batch, entrará en la fase final de Ejecución:

Después de que se ejecute el lote, entra en el estado final Ejecutado, y se adjunta un enlace de transacción para ejecutar la acción Ejecutar.

El estado de la transacción en el lote también se actualiza a "Ejecutado". A diferencia de las transacciones de StarkNet, que se completan de la Capa 2 (L2) a la Capa 1 (L1) en un solo paso, zkSync descompone el proceso de transacciones de L2 a L1 en tres etapas más detalladas: Comprometido → Probado → Ejecutado. Aunque esto prolonga el proceso de transacción completo a aproximadamente un día como medida de protección, el estado Comprometido permite a los usuarios saber rápidamente si su transacción ha sido incluida (una vez que una transacción entra en la etapa Comprometido, ya no es simplemente Pre-Confirmación), sin depender continuamente de la confianza en el Secuenciador. Además, el explorador de zkSync proporciona pantallas de datos completas y detalladas para diferentes etapas, lo que permite a cualquiera conocer el estado más reciente de las transacciones e incluso verificar personalmente la ejecución de las transacciones en cada transición de etapa (por ejemplo, de Comprometido a Probado, de Probado a Ejecutado). Sin embargo, es importante tener en cuenta que, como medida de protección en la etapa Alpha, el Secuenciador de zkSync puede modificar registros históricos. Esto indica que aunque las transacciones pueden moverse rápidamente más allá de la Pre-Confirmación para ingresar a la etapa Comprometido, el Secuenciador aún puede eliminar transacciones de usuarios de los registros históricos hasta que alcancen la etapa Ejecutado. Por lo tanto, los usuarios aún deben confiar en el Secuenciador durante aproximadamente un día.

La capa 1 también puede admitir la preconfirmación

Si se sabe de antemano quién es el responsable de producir bloques, entonces L1 también puede admitir la confirmación previa. Tomando Ethereum como ejemplo, el verdadero productor de bloques es el Constructor, que puede ofrecer servicios de Pre-Confirmación, dando a los usuarios una garantía de inclusión en la transacción. Sin embargo, dado que el Constructor no tiene necesariamente el derecho de producir un determinado bloque, sino que debe pujar por el derecho a producir cada bloque, la eficacia de la Pre-Confirmación puede ser más débil. Además, se debe considerar la competitividad del Constructor; si un Constructor no es lo suficientemente competitivo, será difícil para ellos asegurar el derecho a producir bloques, reduciendo así significativamente la confiabilidad de sus servicios de Pre-Confirmación. Para evitar estos problemas, un mejor enfoque sería permitir que los proponentes proporcionen servicios de preconfirmación, ya que generalmente está predeterminado y seguro qué proponente propondrá qué bloque. Sin embargo, en la arquitectura actual de PBS, los proponentes solo proponen bloques, y la producción real de bloques y la toma de decisiones de contenido son realizadas por los constructores, por lo que los proponentes no pueden insertar directamente una transacción en un bloque o exigir a un constructor que lo haga. En el futuro, si la arquitectura de PBS cambia, por ejemplo, agregando una lista de inclusión o permitiendo que los proponentes participen en la producción de bloques, los proponentes podrían tener la oportunidad de ofrecer servicios de preconfirmación. Para obtener más información sobre PBS, visite el enlace proporcionado.

Mejorando la Preconfirmación:

La Pre-Confirmación es simplemente un compromiso verbal por parte de los Constructores o Secuenciadores de nivel 2, sin obligación de cumplir la promesa y sin mecanismo de penalización por incumplimiento. Sin embargo, es posible hacer que este compromiso sea más confiable mediante el uso de contratos inteligentes para estandarizar a los Constructores o Secuenciadores. Podrían ofrecer servicios de Pre-Confirmación mientras depositan una fianza en el contrato inteligente y firman el contenido al hacer una promesa de inclusión de transacción. Si los usuarios descubren que los Constructores o Secuenciadores no han cumplido sus promesas, pueden presentar el contenido de la promesa y la firma al contrato inteligente, que luego puede verificar si se ha cumplido la promesa. Aunque el escenario de aplicación del contrato mencionado anteriormente todavía está en la etapa de prueba de concepto, el siguiente enlace muestra un video de presentación de un ejemplo de aplicación de dicho contrato.

Resumen:

Después de que las transacciones L1 se incluyen en los bloques L1, la probabilidad de reorganización disminuye y la confianza de los usuarios en la inclusión de transacciones aumenta gradualmente. Las transacciones L2 tienen un flujo de trabajo adicional en comparación con las transacciones L1: “Las transacciones L2 se incluyen en los bloques L2 y esperan ser cargadas en L1.” Sin embargo, dado que los datos aún no se han cargado en L1 en esta etapa, todavía existe la posibilidad de variación, por lo que la seguridad que los usuarios pueden obtener sobre la inclusión de la transacción en esta etapa es el compromiso verbal del Secuenciador, conocido como Preconfirmación o Confirmación Rápida/Confirmación Suave. Si el Secuenciador es malicioso o simplemente encuentra un error, su promesa puede romperse, lo que conduce a la falta de confirmación para la transacción L2 del usuario. Actualmente, la mayoría de los L2 muestran los estados de las transacciones en sus Exploradores que incluyen el estado de Preconfirmación, como Confirmado por el Secuenciador de Arbitrum/Optimism o Aceptado en L2 de StarkNet. Al ver esta información, es importante prestar atención a la efectividad temporal de la seguridad de la inclusión de la transacción proporcionada. Si los usuarios no desean depender de la Preconfirmación del Secuenciador, tendrán que esperar más tiempo y verificar a través de la información del Explorador L2 sobre los datos de L2 que se cargan en L1. La Preconfirmación puede incorporar un mecanismo de incentivos económicos, como penalizar a los Secuenciadores a través de contratos inteligentes cuando incumplen sus promesas, proporcionando a los usuarios una protección más clara. La tabla a continuación muestra las garantías de inclusión de transacciones y los escenarios de riesgo correspondientes proporcionados por las transacciones L1 y L2 en diferentes etapas del proceso de transacción.

Renuncia:

1. Este artículo es reimpreso de [Gateaicoin]. Todos los derechos de autor pertenecen al autor original [Foresight News]. Si hay objeciones a esta reimpresión, por favor contacte al Gate Learnequipo, y ellos lo resolverán rápidamente.
2. Descargo de responsabilidad: Las opiniones expresadas en este artículo son únicamente las del autor y no constituyen ningún consejo de inversión.
3. Las traducciones del artículo a otros idiomas son realizadas por el equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.