¿Cuándo se puede estar seguro de que una transacción L2 (Capa 2) será incluida en un bloque? ¿Cuándo se puede estar seguro de que las ganancias de una transacción L2 no serán descartadas debido a un Re-org?

Este artículo presentará a los lectores 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:

1. Todo el proceso de transacciones de L1 (Capa 1)

2. Las causas y impactos de Re-orgs

3. Comprender los roles y métodos de funcionamiento en la arquitectura actual de PBS de Ethereum

4. Comprender las diferencias entre Optimistic Rollup y Validity (ZK) Rollup

Descripción de las transacciones L1

Proceso de transacción

Después de que un usuario emite y firma una transacción, se envía a la red peer-to-peer y espera a que un Minero bajo el mecanismo de consenso PoW o un Proponente bajo el mecanismo de consenso PoS lo incluya en un bloque. Cuando un usuario descubre que su transacción ha sido incluida en el último bloque, no puede estar 100% seguro de que la transacción será registrada permanentemente en la historia de esa blockchain. Esto se debe a la posibilidad de un evento de blockchain conocido como “Re-org”. Los usuarios deben esperar hasta que la probabilidad de que ocurra un Re-org en un bloque determinado sea lo suficientemente baja como para estar seguros de que su transacción será registrada en la historia de la blockchain.

Ilustración del Proceso de Transacción L1

Incluso después de que una transacción se incluya en un bloque, todavía podría ocurrir un Re-org. Uno debe esperar hasta que sea poco probable que ocurra un Re-org para estar seguro de que la transacción se ha finalizado.

La probabilidad y el costo de un Re-org varían dependiendo del algoritmo de consenso de una cadena y del valor de mercado de sus activos. El método para calcular el costo de un Re-org no se discutirá en detalle aquí.

Comprender las transacciones L2

Proceso de Transacción

Después de que un usuario de L2 genera y firma una transacción, esta suele enviarse directamente a un Secuenciador responsable de ordenar las transacciones. El Secuenciador luego incluye esta transacción en un bloque de L2. Posteriormente, cuando el Secuenciador escribe los datos del bloque de L2 de vuelta a L1 a través de una transacción de L1, los usuarios pueden ver que su transacción se incluye en el último bloque de L2. Sin embargo, es importante tener en cuenta que, dado que los datos del bloque de L2 se cargan en L1 a través de una transacción de L1, todavía existe la posibilidad de encontrarse con una Reorganización de L1. Este escenario podría llevar a que el bloque de L2 no se incluya en el historial de la cadena de bloques, lo que efectivamente resultaría en una Reorganización de L2. Por lo tanto, los usuarios deben esperar hasta que la probabilidad de una Reorganización de L1 sea lo suficientemente baja antes de poder estar seguros de que su transacción se registrará en el historial de la cadena de bloques.

Ilustración del Proceso de Transacción L2

Los usuarios primero esperan a que su transacción se incluya en un bloque L2, luego esperan a que el bloque L2 se cargue en L1 a través de una transacción L1, y finalmente esperan a que la transacción L1 se finalice. Aunque esperar a que una transacción L2 se incluya en un bloque L2 por un Secuenciador agrega un paso en comparación con las transacciones L1, este período de espera generalmente no es significativo si la capacidad del bloque L2 es grande y la velocidad de generación del bloque es rápida. La mayor parte del tiempo de espera se dedica realmente a confirmar la transacción L1. Por lo tanto, en general, la experiencia del usuario para las transacciones L1 y L2 es similar. ¿Pero pueden los usuarios hacer algunas concesiones por una mejor experiencia?

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

Lo ideal es que los usuarios sean testigos de que sus transacciones L2 (incluidas en los bloques L2) se incluyen en los bloques L1, e incluso esperar hasta que la probabilidad de una Reorganización sea lo suficientemente baja, antes de confiar en que sus transacciones L2 se han incluido. Pero, ¿qué pasa si los usuarios están dispuestos a confiar en el secuenciador? Supongamos que el secuenciador es operado por el equipo de desarrollo de L2 o una institución de renombre. Si el secuenciador asegura a los usuarios al recibir sus transacciones que serán incluidos inmediatamente o en el bloque X, esta garantía podría ser suficiente para aquellos que estén dispuestos a confiar en el secuenciador. Esto es similar a un usuario que confía en su aplicación de billetera que no verifica repetidamente Etherscan para obtener confirmación de transacción después de que la billetera le haya notificado de la inclusión.

Esta garantía proporcionada por el Secuenciador se conoce como Preconfirmación, Confirmación rápida o Confirmación suave. Estos pueden entenderse como garantías de inclusión de transacciones "prematuras" o "suaves". No requieren esperar a que la transacción L2 se incluya en un bloque L1, sino que son simplemente compromisos verbales del Secuenciador. El Secuenciador podría olvidar su promesa debido a un error o un Secuenciador malicioso podría romper su promesa, lo que resultaría en tiempo perdido para el usuario o, en el peor de los casos, exposición a un "ataque de doble gasto".

A continuación, presentaremos varias formas diferentes de presentar el estado de la inclusión de transacciones L2.

Estado de inclusión de transacción en Arbitrum/Optimism

Actualmente, cuando los usuarios ejecutan transacciones en Arbitrum u Optimism, casi inmediatamente reciben un recibo de transacción, que incluye el resultado de la ejecución de la transacción. Esto indica que el Secuenciador ya ha ordenado y simulado la ejecución de la transacción localmente, y el recibo de transacción sirve como una Pre-Confirmación para el usuario.

Para obtener más información sobre el ciclo de vida detallado de la transacción en Arbitrum, puede consultar el documento oficial en: https://docs.arbitrum.io/tx-lifecycle

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

Verificando el Estado de Inclusión de la Transacción en Arbitrum

Las transacciones mostradas en el Explorador de Arbitrum incluyen aquellas con Pre-Confirmación, es decir, transacciones aún no cargadas en L1. Como se muestra en la siguiente imagen, una transacción con el Número de Bloque 145353000 está marcada como "Confirmado por el Secuenciador", lo que indica que ha sido confirmada por el Secuenciador pero aún no ha sido cargada en L1:

[La imagen muestra una transacción confirmada por el Secuenciador pero no cargada en L1]

En contraste, la próxima imagen muestra una transacción que ya ha sido cargada a L1, con un estado de "69 Confirmaciones de Bloque L1". Esto significa que el bloque L1 que contiene estos datos de transacción tiene 69 bloques siguientes, lo que indica un nivel más alto de seguridad:

[Imagen muestra una transacción en L1 con 69 confirmaciones de bloque]

Otro ejemplo es una transacción con 6174 confirmaciones de bloque L1, como se muestra a continuación, que se considera muy segura.

Sin embargo, sería mejor si la información de Finalidad L1 se integrara en esta pantalla. Simplemente decir a los usuarios el número de Confirmaciones de Bloque L1 es de ayuda limitada, ya que tienen que entender y calcular qué nivel de seguridad representa este número. Dado que la Capa 1 (Ethereum) tiene un mecanismo de Finalidad como Casper FFG, el Explorador podría mostrar directamente si el bloque de la Capa 1 ha sido Finalizado. Actualmente, el Explorador de Optimism ha implementado esta función.

Verificando el estado de inclusión de la transacción en Optimism

Las transacciones mostradas en el Explorador de Optimism también incluyen aquellas con Pre-Confirmación, es decir, transacciones aún no cargadas en L1. Como se muestra en la siguiente imagen, una transacción con el Número de Bloque 111526300 está marcada como "Confirmada por el Secuenciador":

[La imagen muestra una transacción solo confirmada por Sequencer pero no cargada en L1]

Sin embargo, el Explorer no define claramente el significado de "Confirmado por el Secuenciador." Indica que "las confirmaciones del secuenciador son equivalentes a unas pocas confirmaciones de bloque en L1," lo que sugiere que una transacción marcada como "Confirmado por el Secuenciador" ha sido cargada en L1 y tiene varios bloques que la siguen:

[La imagen muestra transacciones recientes marcadas como "Confirmadas por el Secuenciador"]

Las transacciones de hace varios días, incluso las que han pasado el período de desafío, todavía muestran el estado "Confirmado por el Secuenciador":

[La imagen muestra las transacciones de hace días que todavía están marcadas como "Confirmadas por el secuenciador"]

Nota: El Explorador puede mostrar diferentes estados en diferentes lugares: “Confirmado por el Secuenciador” al lado del Número de Bloque indica que el bloque ha sido confirmado por el Secuenciador. Para verificar el estado después de ser cargado en L1, los usuarios necesitan buscar otra información, como el “Lote de Estado L1” mencionado a continuación.

Como se muestra en la siguiente captura de pantalla, una transacción ya cargada en L1 incluye información adicional: “Índice de Lote de Estado L1” y “Hash de Transacción de Envío de Raíz de Estado L1.” Estos detalles indican en qué Lote de Estado se incluye la transacción L2 y qué transacción L1 cargó este Lote de Estado en L1:

[La imagen muestra una transacción con información de lote de estado L1]

Al hacer clic en el lote de estado '3480', se revela que su estado es Finalizado. Este estado finalizado corresponde a la mainnet de Ethereum e indica un estado muy seguro, habiendo acumulado con éxito dos épocas de votos de validadores.

[Se muestra el lote de estado 3480 finalizado en el bloque L1 18457449]

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

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

[La imagen muestra un lote de estado cargado en L1 pero aún no finalizado]

En comparación con el Arbitrum Explorer, el Optimism Explorer proporciona más información (Lote de Estado) e integra directamente la información de Finalidad L1 en el Explorador L2, lo que permite a los usuarios saber si el bloque L1 ha sido finalizado sin tener que interpretar el número de confirmaciones de bloque para la seguridad.

Estado de ingresos por transacciones de StarkNet

Actualmente, cuando los usuarios envían transacciones en StarkNet, pueden acceder rápidamente al recibo de la transacción. Sin embargo, el estado que a menudo se muestra en el recibo es RECIBIDO, lo que indica que el nodo ha recibido y validado la transacción como libre de errores. Luego esperará la inclusión y ejecución en un bloque L2 por parte del Secuenciador. Las transacciones en estado RECIBIDO aún no tienen resultados de ejecución. Los usuarios pueden monitorear el progreso de sus transacciones a través del estado mostrado en el Explorador de StarkNet.

Nota: Si el Secuenciador procesa las transacciones lo suficientemente rápido, podría omitir el estado RECIBIDO y pasar directamente a un estado procesado. Para obtener una introducción más detallada al proceso de transacción de StarkNet, consulte el documento oficial en https://docs.starknet.io/documentation/architecture_and_concepts/Network_Architecture/transaction-life-cycle/

En Starkscan, un explorador de StarkNet, se muestran transacciones que incluyen la preconfirmación. Por ejemplo, una transacción mostrada como "Aceptada en L2" indica que ha sido secuenciada en un bloque L2:

"Aceptado en L2" significa que la transacción ha sido secuenciada en un bloque L2 pero aún no ha sido cargada en L1.

Los dos estados anteriores, Recibido y Pendiente, representan 'transacción recibida y validada' y 'transacción siendo procesada por el Secuenciador'. Después del procesamiento, el estado cambia a Aceptado en L2.

Transacción recibida y verificada

La transacción está siendo procesada por Secuenciador

Después de que los datos de la transacción se carguen en L1, el estado cambiará a Aceptado en L1, como se muestra en la figura a continuación para esta 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, lo que permite a los usuarios conocer el progreso de sus transacciones, la carga en L1 puede tardar varias horas, principalmente debido al tiempo necesario para generar pruebas de conocimiento cero. Por lo tanto, los usuarios confían en la Preconfirmación del Secuenciador durante este período.

El explorador de StarkNet solo muestra Aceptado en el estado L1 sin información adicional sobre la Finalidad L1 o la Confirmación del Bloque. Los usuarios necesitan verificar si se han agregado suficientes bloques después de su transacción en L1 o si ha sido Finalizado.

Debido a las limitaciones de rendimiento de StarkNet, la larga dependencia de la Pre-Confirmación y la falta de soporte para la información de Finalidad L1 en Explorer, la experiencia del usuario para la confirmación de inclusión de transacciones en StarkNet necesita mejoras.

Estado de inclusión de transacciones zkSync

Similar to StarkNet, zkSync also has a PENDING status, which indicates that the node has received and verified the transaction without any issues. The transaction will then wait to be included and executed in an L2 block by the Sequencer. Transactions in PENDING status do not yet have any execution results.

Los usuarios pueden seguir el progreso de sus transacciones a través del estado mostrado en el Explorador zkSync.

Consejo de lectura: Si el Secuenciador procesa las transacciones lo suficientemente rápido, podría pasar por alto el estado PENDIENTE y pasar directamente a un estado donde la transacción ya ha sido procesada.

Para obtener una introducción más detallada al proceso de transacción de zkSync, sigue este enlace: https://era.zksync.io/docs/reference/concepts/finality.html#finality-on-ethereum

Las transacciones vistas en el Explorador zkSync también incluyen transacciones de preconfirmación, como la que se muestra en la captura de pantalla a continuación. El estado es actualmente "Procesado en la era zkSync," lo que indica que ha sido organizado en un bloque L2 por el Secuenciador:

La transacción ha sido organizada en un bloque L2 por el Secuenciador y actualmente está esperando ser cargada en L1 (Envío a Ethereum).

Después de que el Secuenciador completa un bloque L2, el bloque y sus transacciones pasan por tres etapas: Comprometido, Probado y Ejecutado. Estos indican respectivamente que "el bloque se carga en L1", "la validez del bloque está probada" y "el estado L2 después de la ejecución de transacciones dentro del bloque se actualiza a L1". A continuación se muestran ejemplos de bloques y transacciones en estas diferentes etapas:

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

El estado de las transacciones en el Lote 292700 cambia de Ethereum Sending a Ethereum Validating, lo que indica que están esperando la validación de prueba de conocimiento cero de 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 se adjuntará:

Esta transacción ha entrado en la etapa de "Validación". El enlace de la transacción para cargar el Lote en L1 en la etapa anterior (Envío) también se puede ver directamente aquí.

El lote 292000 ha demostrado su validez, por lo que entra en la etapa Probada:

Después de que un lote sea probado, entra en el estado Probado, con un enlace a la transacción que ejecuta la acción Probar.

Las transacciones luego pasan de "Validando" a "Ejecutando," lo que significa que están esperando ser ejecutadas.

Después de que se demuestre un Lote, hay un período de espera (aproximadamente 21 horas según la documentación oficial) antes de ejecutar las transacciones dentro del mismo y actualizar el estado L2 registrado en L1. Esta es una medida de protección en la fase Alfa para garantizar un tiempo de reacción suficiente en caso de errores. Una vez que se ejecuta el Lote, entra en la etapa final de Ejecución:

Después de la ejecución, el Lote entra en el estado final Ejecutado, con un enlace a la transacción que ejecuta la acción Ejecutar.

El estado de las transacciones dentro del Lote también se actualiza a "Ejecutado".

En comparación con StarkNet, donde las transacciones se mueven de L2 a L1 en un solo paso, zkSync descompone el proceso de L2 a L1 en tres etapas más detalladas: Comprometido → Probado → Ejecutado. Aunque como medida de protección, todo el proceso de transacción lleva aproximadamente un día, el estado Comprometido permite a los usuarios saber rápidamente si su transacción ha sido incluida (después de Comprometido, no es solo Pre-Confirmación), sin depender únicamente de la confianza en el Secuenciador. Además, zkSync Explorer proporciona datos completos para cada etapa, lo que permite a cualquier persona hacer un seguimiento del estado más reciente de las transacciones e incluso verificar las transiciones entre etapas (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 fase Alfa, el secuenciador zkSync puede modificar actualmente los registros históricos. Esto significa que, aunque las transacciones pueden pasar rápidamente de la confirmación previa a la etapa de confirmación, el secuenciador aún puede eliminar las transacciones de usuario del registro histórico hasta que alcancen la etapa de ejecución. Por lo tanto, los usuarios aún deben confiar en el secuenciador hasta por un día.

L1 También Puede Soportar la Preconfirmación

Si es posible saber de antemano quién es responsable de producir bloques, entonces L1 también puede admitir la Pre-Confirmación. Tomando Ethereum como ejemplo, el productor de bloques real es el Constructor, quien puede ofrecer servicios de Pre-Confirmación, brindando a los usuarios una garantía de inclusión de transacciones. Sin embargo, dado que el Constructor no tiene el derecho garantizado de producir un bloque en particular, sino que debe pujar por el derecho de producir cada bloque, la efectividad de esta Pre-Confirmación es relativamente débil. Además, se debe considerar la fortaleza del Constructor; si un Constructor carece de fuerza competitiva, le resultará difícil ganar el derecho de producir bloques, disminuyendo el valor de su servicio de Pre-Confirmación.

Una mejor solución para evitar estos problemas sería que el Proponente ofreciera servicios de Preconfirmación, ya que generalmente está predeterminado y seguro qué Proponente propondrá qué bloque. Sin embargo, en la arquitectura actual de PBS (Separación de Proponente-Constructor), el Proponente solo es responsable de proponer bloques, mientras que el Constructor decide el contenido del bloque. Por lo tanto, el Proponente no puede insertar directamente una transacción en un bloque o pedirle al Constructor que lo haga. Esta situación podría cambiar con modificaciones futuras en la arquitectura de PBS, como agregar una Lista de Inclusión o permitir que los Proponentes participen en la producción de bloques, lo que les permitiría ofrecer servicios de Preconfirmación.

Consejo de lectura: Para obtener más información sobre PBS, copie el enlace a continuación en su navegador para leer: https://mirror.xyz/0x347c9872A2a1dE370D798f9FE96341A9A0E05af8/oG_4j_-TweXHX_LMag656k_pAyJWIBXpEDrzpUfVsss.

Mejorando la Preconfirmación

La Pre-Confirmación es solo una promesa verbal de un Constructor o Secuenciador de L2, sin obligación de cumplirla y sin mecanismo de castigo por incumplimiento. ¿Se puede hacer esta promesa más confiable? Sí, porque el contenido del compromiso (por ejemplo, "incluir esta transacción en el bloque 1350000") hecho por la persona responsable de producir bloques puede ser escrito como una verificación condicional. Por lo tanto, podemos usar contratos inteligentes para regular a los Constructores o Secuenciadores, pidiéndoles que depositen garantías en el contrato inteligente al ofrecer servicios de Pre-Confirmación y firmen el contenido del compromiso. Si los usuarios descubren que los Constructores o Secuenciadores no han cumplido sus promesas, pueden enviar el compromiso y la firma al contrato inteligente para su verificación.

Aunque la aplicación de dichos contratos todavía está en la etapa de prueba de concepto, el siguiente enlace a un video de presentación muestra un ejemplo de aplicación de contrato:

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

Resumen

Después de que una transacción L1 se incluye en un bloque L1, la probabilidad de un Re-org disminuye gradualmente, y la confianza de los usuarios en que su transacción se incluya aumenta.

Las transacciones L2 tienen un flujo de trabajo adicional en comparación con las transacciones L1: la fase de “transacción L2 que se incluye en un bloque L2 y espera ser cargada en L1.” Durante esta fase, dado que los datos aún no se han cargado en L1, todavía existe la posibilidad de cambios, y por lo tanto, la única garantía que los usuarios tienen sobre la inclusión de su transacción es el compromiso verbal del Secuenciador, conocido como Preconfirmación, Confirmación Rápida o Confirmación Suave.

Si el Sequencer es malicioso o encuentra un error, sus compromisos podrían romperse, lo que potencialmente podría resultar en una falta de confirmación para la transacción L2 del usuario.

Actualmente, la mayoría de las L2 muestran el estado de la transacción en sus Exploradores, incluido el estado de Pre-Confirmación, como el "Confirmado por el Secuenciador" de Arbitrum/Optimism o el "Aceptado en L2" de StarkNet. Los usuarios deben ser conscientes de la validez temporal de la garantía de inclusión de la transacción proporcionada por estos estados.

Si los usuarios no desean confiar en la Preconfirmación del Secuenciador, deberán esperar más tiempo y validar a través de la información proporcionada por el Explorador L2 sobre los datos L2 que se cargan en L1.

La preconfirmación puede incluir un mecanismo de incentivos económicos, como sanciones a través de contratos inteligentes para los Secuenciadores que incumplan sus promesas, ofreciendo una protección más clara a los usuarios.

La tabla a continuación muestra las garantías de inclusión de transacciones y los escenarios de riesgo correspondientes para las diferentes etapas de transacciones L1 y L2: [Tenga en cuenta que la tabla no se proporciona en la traducción].

Descargo de responsabilidad：

1. Este artículo es reimpreso de [GateimToken Labs]. Todos los derechos de autor pertenecen al autor original [Nic]. If there are objections to this reprint, please contact the Gate Learnequipo, y 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.