Interpretación de todo el proceso de implementación de transacciones L2: ¿cuál es el rendimiento de seguridad de cada etapa?

Autor: Nic@ imToken Labs

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

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

Requisitos previos:

• Todo el proceso de transacciones L1 (Capa 1)
• Causas y efectos de Re-org
• Comprender el papel actual de Ethereum en la arquitectura PBS y cómo funciona
• Comprender las diferencias entre los Optimistic Rollups y los Validity (ZK) Rollups

Más información sobre las transacciones L1

PROCESO DE TRANSACCIÓN

Diagrama del flujo de transacciones L1

La reorganización sigue siendo posible después del bloqueo de ingresos de la transacción, y es necesario esperar hasta que sea poco probable que se produzca la reorganización para estar seguro de que la transacción se ha finalizado.

La probabilidad y el coste de la reorganización variarán en función del algoritmo de consenso de una cadena y de la capitalización de mercado del activo, y el cálculo del coste de la reorganización no se introducirá aquí.

Más información sobre las transacciones L2

PROCESO DE TRANSACCIÓN

Después de que el usuario L2 genera y firma la transacción, generalmente se envía directamente al secuenciador responsable de ordenar la transacción, y el secuenciador recopila su transacción en el bloque L2. A continuación, cuando el secuenciador vuelve a escribir los datos del bloque L2 en L1 a través de una transacción L1, el usuario puede ver que su transacción está incluida en el último bloque L2.

Sin embargo, debe tenerse en cuenta que debido a que los datos del bloque L2 se cargan en L1 a través de transacciones L1, aún es posible encontrar una situación en la que se produzca una reorganización L1, lo que resulta en que el bloque L2 no se escriba en el historial de la cadena de bloques al final, es decir, equivalente a la reorganización L2, por lo que el usuario aún tiene que esperar a que la probabilidad de L1 Reorganización sea lo suficientemente baja como para estar seguro de que su transacción se escribirá en el historial de la cadena de bloques.

Diagrama del flujo de transacciones L2

El usuario primero espera a que la transacción se incluya en el bloque L2, luego espera a que el bloque L2 se cargue en L1 a través de una transacción L1 y, finalmente, espera a que finalice la transacción L1.

Aunque en comparación con las transacciones L1, las transacciones L2 tienen un período de tiempo adicional para esperar a que las transacciones L2 se incluyan en los bloques L2 por Sequencer, pero de hecho, cuando el tamaño del bloque L2 es lo suficientemente grande y la velocidad de producción del bloque es lo suficientemente rápida, este tiempo de espera no tomará mucho tiempo, porque el tiempo de espera dedicará principalmente las transacciones L1 al reconocimiento de ingresos, por lo que, en general, la experiencia de las transacciones L1 y las transacciones L2 es similar.

Pero si el usuario está dispuesto a hacer algunos sacrificios, ¿se puede cambiar por una mejor experiencia?

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

El usuario debe ver que el bloque L2 (que contiene transacciones L2) se incluye en el bloque L1, e incluso esperar hasta que la probabilidad de que ocurra la reorganización sea lo suficientemente baja como para creer que su transacción L2 se ha ganado.

Pero, ¿qué pasa si el usuario está dispuesto a confiar en Sequencer? Tal vez Sequencer está dirigido por el equipo de desarrollo de L2, dirigido por una organización de renombre, y si Sequencer asegura al usuario que su transacción será pagada inmediatamente, en el Xth Block, entonces esta garantía es suficiente para el usuario que está dispuesto a confiar en Sequencer. Al igual que si un usuario confía en la billetera que está utilizando, no acudirá sospechosamente a Etherscan para verificar dos veces después de que la billetera le haya alertado de que la transacción ha sido pagada.

La Garantía de Ingresos por Transacción proporcionada por este Secuenciador se denomina Pre-Confirmación, Confirmación Rápida o Confirmación Suave, que puede entenderse como una garantía de ingresos por transacción “temprana” o “suave”. No es necesario esperar a que las transacciones L2 se incluyan en el bloque L1, pero es solo una promesa verbal dada por Sequencer, y Sequencer puede olvidar la promesa original debido a errores o Sequencer malicioso violará directamente la promesa, lo que puede hacer perder tiempo al usuario o ser un “ataque de doble gasto”.

A continuación, veremos algunas de las diferentes formas en que se presenta el estado de ingresos de las transacciones L2.

Estado de los ingresos por transacciones de Arbitrum/Optimism

En la actualidad, los usuarios que envían una transacción en Arbitrum u Optimism pueden obtener casi de inmediato un recibo de transacción, que será el resultado de la ejecución de la transacción. Esto significa que Sequencer ya ha secuenciado y simulado la ejecución de las transacciones localmente, y este recibo de transacción es la confirmación previa para el usuario.

Para obtener más información sobre Arbitrum, se puede copiar una descripción más detallada del ciclo de vida de la transacción en el siguiente enlace al documento oficial de referencia del navegador:

Para obtener una introducción más detallada al ciclo de vida de las transacciones de Optimism, copie el siguiente enlace al documento oficial de referencia del navegador:

Verifique el estado de los ingresos de la transacción en Arbitrum

Las transacciones que ve en el Explorador de Arbitrum contendrán transacciones de Pre-Confirmación, es decir, transacciones que aún no se han cargado en L1, como se muestra en la siguiente figura, puede ver que hay un indicador Confirmado por Secuenciador junto al Número de Bloque 145353000:

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

Si la transacción se ha cargado en L1 como se muestra en la siguiente figura, su estado ha cambiado a 69 confirmaciones de bloque L1, lo que significa que se ha cargado en L1 y contiene el bloque de datos de la transacción y hay 69 bloques detrás:

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

O la transacción que se muestra en la captura de pantalla a continuación, el bloque L1 que contiene estos datos de transacción tiene 6174 bloques detrás, lo que ya es muy seguro.

Pero lo que se puede hacer mejor aquí es combinar la información de finalidad de L1.

El simple hecho de decirle al usuario cuántas confirmaciones de bloque L1 hay es una ayuda limitada para el usuario, ya que el usuario tiene que comprender y calcular el nivel de seguridad representado por tal número de confirmaciones de bloque. Y dado que la Capa 1 (es decir, Ethereum) ya tiene un mecanismo de finalidad como Casper FFG, el Explorador puede mostrar directamente si el Bloque de Capa 1 está actualmente finalizado en la Capa 1. Actualmente, el Explorador de Optimism ha implementado dicha función.

Verifique el estado de las ganancias de la transacción en Optimism

Las transacciones que vemos en el Explorador de Optimism también incluirán transacciones de Pre-Confirmación, es decir, transacciones que aún no se han cargado en L1, como se muestra en la siguiente figura, podemos ver que hay un símbolo de Confirmado por Secuenciador junto al Número de Bloque 111526300:

Transacciones que solo han sido confirmadas por Sequencer pero que aún no se han cargado en L1

Sin embargo, el Explorador no parece tener una especificación clara de lo que significa Confirmado por el Secuenciador, diciendo que “Las confirmaciones del Secuenciador son equivalentes a unas pocas confirmaciones de bloque en L1.”, lo que indica que Confirmado por el Secuenciador representa un número de Bloque que se han cargado en L1 y han sido seguidos por varios:

Pero, de hecho, la última transacción también se muestra como Confirmada por el secuenciador, e incluso hace docenas de días, el estado de la transacción que ha pasado el período de desafío sigue siendo Confirmado por el secuenciador:

Hace docenas de días, el estado de la transacción todavía estaba atascado en “Confirmado por secuenciador”

Consejo de lectura: La situación anterior también puede ser que el explorador marque diferentes estados en diferentes lugares: el Confirmado por el secuenciador después del número de bloque le dice al usuario que el bloque ha sido confirmado por el secuenciador, y el usuario tiene que confirmar el estado después de cargar en L1 a través de otra información, como la información de “Lote de estado L1” que se menciona a continuación.

Además, la transacción que se ha cargado en L1, como se muestra en la captura de pantalla siguiente, tiene dos información adicional: “L1 State Batch Index” y “L1 State Root Submission Tx Hash”. Estos dos datos representan el lote de estado en el que se incluyó la transacción L2 y la transacción L1 a través de la cual se cargó el lote de estado en L1:

Haga clic en el lote de estado “3480”, puede ver que su estado es Finalizado, que corresponde al estado Finalizado de L1 (es decir, la red principal de Ethereum), que es un estado muy seguro que ha acumulado con éxito los votos de dos validadores de Epoch.

△ Se ha adquirido el lote estatal 3480 en el bloque L1 18457449 y se ha finalizado el bloque 18457449.

Fuente:

Si el lote se ha cargado pero no se ha finalizado en L1, se mostrará como Sin finalizar:

Aunque el lote de estado 3494 se ha cargado en L1, el bloque L1 que se incluye en el lote aún no se ha finalizado.

En comparación con el Explorador de Arbitrum, el Explorador de Optimismo proporciona más información (Lote de Estado) para las transacciones, y encadenará directamente la información de Finalidad L1 al Explorador de L2, de modo que el usuario pueda saber directamente si el Bloque L1 ha sido finalizado, en lugar de juzgar el grado de seguridad correspondiente al número de Confirmaciones de Bloque.

Estado de las ganancias comerciales de StarkNet

En la actualidad, después de que el usuario envía una transacción en StarkNet, aunque el recibo de la transacción se puede consultar rápidamente, el estado de la transacción que se muestra en el recibo generalmente estará en el estado RECIBIDO, lo que significa que el Nodo ha recibido la transacción y no hay ningún problema después de que se verifique la transacción, y esperará a que la transacción sea recibida por el Bloque L2 del secuenciador y ejecutada, mientras que la transacción en el estado RECIBIDO no tendrá ningún resultado de ejecución de transacción. Los usuarios pueden verificar el progreso de sus transacciones a través del estado de la transacción que se muestra en StarkNet Explorer.

Consejo de lectura: Si el secuenciador procesa lo suficientemente rápido, es posible omitir el estado RECIBIDO e ir al estado en el que ya se ha procesado la transacción. Para obtener una introducción más detallada al proceso de negociación de StarkNet, puede copiar el siguiente enlace para ver los documentos oficiales en su navegador.

Documentos oficiales: _and_concepts/Network_Architecture/transaction-life-cycle/

Las transacciones vistas en Starkscan, el Explorador de StarkNet, también incluirán transacciones de Pre-Confirmación, como se muestra en la siguiente figura, puede ver que el Estado es actualmente Aceptado en L2, lo que significa que ha sido clasificado en el Bloque L2 por Secuenciador:

“Aceptado en L2” significa que ha sido colocado en un bloque L2 por el secuenciador, pero aún no se ha cargado en L1

Los dos primeros estados de Aceptado en L2 son Recibido y Pendiente, lo que significa que “la transacción ha sido recibida y verificada” y “la transacción está siendo procesada por el secuenciador”, y la transacción entrará en el estado de Aceptado en L2 después de que se ejecute la transacción:

La transacción se recibe y se verifica

La transacción está siendo procesada por Sequencer

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

Los datos transaccionales se han cargado en L1

Aunque las transacciones de StarkNet tienen un estado más rico que permite a los usuarios conocer el progreso de la transacción, la transacción puede tardar cuatro o cinco horas en cargarse en L1 (probablemente porque se tarda mucho tiempo en generar Zero-Knowledge Proof), por lo que los usuarios durante este tiempo confían en la confirmación previa de Sequencer.

Además, Explorer solo muestra Aceptado en L1 para transacciones cargadas en L1, y no tiene la información de Finalidad o Confirmación de Bloque con L1, lo que significa que los usuarios tienen que verificar si hay suficientes Bloque en L1 Bloque o si se han finalizado.

En general, debido al cuello de botella de rendimiento de StarkNet, los usuarios deben confiar en la confirmación previa durante mucho tiempo, y Explorer no admite la información de finalidad L1, lo que resulta en una mala experiencia de reconocimiento de ingresos por transacciones de StarkNet, que es donde StarkNet debe mejorarse en el futuro.

Estado de los ingresos por transacciones de zkSync

Al igual que StakrNet, zkSync también tiene un estado PENDING, lo que significa que Node ha recibido la transacción y la transacción ha sido verificada sin problemas, esperará a que la transacción sea bloqueada y ejecutada por Sequencer L2, mientras que la transacción en el estado PENDING no tendrá ningún resultado de ejecución de transacción.

Los usuarios pueden conocer el progreso de sus transacciones a través del estado de la transacción que se muestra en el Explorador zkSync.

Consejo de lectura: Si Sequencer procesa lo suficientemente rápido, es posible omitir el estado PENDING e ir al estado en el que ya se ha procesado la transacción.

Para una introducción más detallada al proceso de transacción de zkSync, puede copiar el siguiente enlace para verlo en su navegador:

Las transacciones que ve en el Explorador zkSync también incluirán las transacciones de preconfirmación, como la que se muestra en la captura de pantalla a continuación, puede ver que el estado es actualmente zkSync Era Procesado, lo que significa que ha sido clasificado en el bloque L2 por el secuenciador:

Esta transacción ha sido colocada en el bloque L2 por Sequencer y actualmente está a la espera de ser cargada en L1 (Ethereum Sending)

Después de que el secuenciador haya creado un bloque L2, el bloque y las transacciones en él pasarán por tres fases en secuencia: Confirmado, Probado y uted, indicando que “El bloque se ha cargado en L1”, “Se ha demostrado la validez del bloque” y “El estado de L2 se ha actualizado a L1 después de que se haya ejecutado la transacción del bloque”. A continuación se muestran el bloque y la transacción en diferentes etapas:

El lote 292700 se ha cargado en L1 y se encuentra en la fase de confirmación. Fuente:

El estado actual de la transacción en el lote 292700 ha cambiado de Ethereum Sending a Ethereum Validating, lo que indica que está a la espera de ser verificada por Zero-Knowledge Proof.

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

Esta transacción entra en la etapa “Validando”, y el enlace a la transacción que cargó Batch a L1 en la etapa anterior (Envío) también se puede ver aquí.

La eficacia del lote 292000 ha sido probada, así que entra en la fase probada:

Una vez probado el lote, entra en el estado probado con un vínculo a la transacción que ejecuta la acción Probar.

La transacción también pasará de “validar” a “usar”, es decir, a la espera de ser ejecutada.

Cuando se prueba el lote, entra en un período de espera (alrededor de 21 horas en documentos oficiales) antes de que se ejecute la transacción en el interior y se actualice el estado L2 registrado en L1. Esto se debe principalmente a una salvaguarda que se ha añadido en la fase alfa para garantizar que haya tiempo suficiente para reaccionar ante cualquier error que surja. Cuando se ejecuta el lote, entra en la fase final:

Una vez ejecutado el lote, entra en el estado uted final con un vínculo de transacción que ejecuta la acción ute.

El estado de la transacción en Batch también se ha actualizado a “uted”

A diferencia de StarkNet, donde las transacciones de L2 a L1 se completan en un solo paso, el proceso de zkSync de mover L2 a L1 se divide en tres etapas más detalladas: Comprometida → Probada → usada.

Si bien todo el proceso de transacción se extiende a aproximadamente un día como medida de seguridad, el estado Committed permite a los usuarios saber rápidamente si se ha ganado una transacción (y ya no es solo una confirmación previa una vez que la transacción ingresa a Committed) sin tener que depender de la confianza en Sequencer de forma continua.

Además, zkSync Explorer proporciona una visualización de datos rica y completa para diferentes etapas, de modo que cualquiera puede comprender el estado más reciente de las transacciones a través del explorador, e incluso poder verificar personalmente la ejecución de la transacción de cada transición de etapa (como de Committed a Proven o Proven a uted).

Sin embargo, hay que tener en cuenta que, como medida de protección para la fase alfa, el historial puede ser modificado por zkSync Sequencer en este momento.

Esto sugiere que, aunque una transacción puede salir rápidamente de la confirmación previa y pasar a la fase de confirmación, Sequencer puede eliminar una transacción de usuario del historial antes de que la transacción entre en la fase de utilización. Por lo tanto, los consumidores aún necesitan confiar en Sequencer hasta por un día.

L1 también puede admitir la confirmación previa

Si puede saber de antemano quién es responsable de producir bloques, entonces L1 también puede admitir la confirmación previa.

Tomando Ethereum como ejemplo, la persona que realmente produce bloques es el Constructor, y el Constructor puede proporcionar servicios de Pre-Confirmación para dar a los usuarios una garantía de ingresos por transacción. Pero debido a que el Constructor no necesariamente obtiene el derecho a una cierta salida y un cierto Bloque, sino que debe ofertar por el derecho a cada salida de Bloque, por lo que la efectividad de esta Pre-Confirmación será relativamente pobre, y se debe considerar la fuerza del Constructor, si el Constructor no es lo suficientemente competitivo, entonces es difícil para el Constructor obtener el derecho a producir Bloque, por lo que la Pre-Confirmación proporcionada por el Constructor El servicio se verá muy comprometido.

Si desea evitar los problemas anteriores, es mejor que el Proponente proporcione el servicio de Pre-Confirmación, porque el “qué Proponente propondrá el primer Bloque” suele ser una situación precalculada y determinista.

Sin embargo, debido a que en la arquitectura actual de PBS, el Proponente solo propone el rol de Bloque, y el rol de hacer realmente el Bloque y determinar el contenido del Bloque es el Constructor, por lo que el Proponente no puede meter directamente una transacción en un Bloque o pedirle al Constructor que rellene una transacción. Cuando la arquitectura de PBS cambie en el futuro, como agregar una lista de inclusión o permitir que los proponentes participen en la producción de bloques, el proponente tendrá la oportunidad de proporcionar servicios de preconfirmación.

Consejo de lectura: Para obtener más información sobre PBS, copie el siguiente enlace para leerlo en su navegador: _4j_-TweXHX_LMag656k_pAyJWIBXpEDrzpUfVsss.

Mejorar la preconfirmación

La preconfirmación es solo una promesa verbal del Constructor o del secuenciador L2, y la otra parte no tiene la obligación de cumplir la promesa, y no existe un mecanismo de penalización por incumplimiento.

¿Es posible hacer que esta promesa sea más segura? En realidad, sí, porque la persona responsable de producir el Bloque y el contenido de su promesa (por ejemplo, “en el Bloque 1.350.000 la transacción de ingresos”) se puede escribir como una comprobación de condición. Por lo tanto, podemos usar el contrato inteligente para regular al Constructor o Secuenciador, pedirles que brinden servicios de Pre-Confirmación al garantizar el depósito en el Contrato Inteligente, y firmar el contenido al dar la promesa de ingresos de la transacción, cuando el usuario encuentra que el Constructor o Secuenciador no ha cumplido con el compromiso, el contenido prometido y la firma de la otra parte se pueden enviar al Contrato Inteligente, y el Contrato Inteligente puede verificar si el compromiso se ha cumplido (como “en el primer 1.350.000 Ingresos en Bloque por esta transacción”).

Aunque el escenario de aplicación del contrato anterior aún se encuentra en la etapa de prueba de concepto, el video de presentación que se muestra en el enlace a continuación muestra un ejemplo de una de las solicitudes de contrato, copie el enlace a continuación para ver los detalles en su navegador:

Resumen

• Después de que las transacciones L1 se incluyan en los bloques L1, la probabilidad de Re-org disminuirá gradualmente y la confianza de los usuarios en los ingresos de las transacciones aumentará gradualmente.
• Un flujo de trabajo de transacción más para las transacciones L2 que para las transacciones L1 es la etapa en la que las transacciones L2 se incluyen en bloques L2 y esperan ser cargadas en L1.
• Sin embargo, en el flujo de trabajo de transacciones donde las transacciones L2 son más que las transacciones L1, debido a que los datos aún no se han cargado en L1 en esta etapa, todavía existe la posibilidad de variables, por lo que la garantía de ingresos por transacciones que los usuarios pueden obtener en esta etapa es la promesa verbal de Sequencer, que se denomina Pre-Confirmación o Confirmación Rápida, Soft Confirmation.
• Si Sequencer es malicioso, o si hay un error simple, entonces la promesa hecha por Sequencer puede ser violada, lo que resulta en que no se reconozcan ingresos para las transacciones L2 del usuario.
• Actualmente, la mayoría de los estados de transacción L2 en su Explorador incluyen un estado de Pre-Confirmación, como Confirmado por Secuenciador para Arbitrum/Optimism o Aceptado en L2 para StarkNet. Cuando vea dicha información, preste atención a la validez temporal de la garantía de ingresos por transacción proporcionada por esta información.
• Si no desea confiar en la preconfirmación proporcionada por Sequencer, deberá esperar un poco más y verificar con la información proporcionada por el Explorador de L2 que los datos de L2 se cargan en L1.
• La Pre-Confirmación se puede combinar con el diseño de incentivos económicos, como penalizaciones a través de Smart Contract cuando Sequencer viola los compromisos, para que los usuarios puedan obtener una protección más clara.

La siguiente tabla ilustra la garantía de ingresos por transacción y los escenarios de riesgo correspondientes proporcionados por las transacciones L1 y L2 en diferentes etapas del proceso de transacción: