Análisis del proceso completo de ejecución de transacciones de Capa 2: Evaluación de la seguridad en cada etapa

Capa 2(L2) tecnología ha proporcionado una mayor escalabilidad a Ethereum, pero también ha incrementado la complejidad de la confirmación de transacciones. Este artículo detallará el proceso completo de ejecución de transacciones L2 y analizará el rendimiento de seguridad en cada una de las etapas.

Revisión del proceso de transacciones L1

Después de que el usuario envía una transacción, debe esperar a que los mineros o validadores la incluyan en un bloque. Incluso si la transacción ha sido incluida, aún debe esperar una cierta cantidad de bloques de confirmación para reducir el riesgo de reorganización (Re-org). Solo cuando la probabilidad de reorganización es lo suficientemente baja, la transacción puede considerarse confirmada de forma definitiva.

Detalles del proceso de negociación de Capa 2

El proceso de transacción de Capa 2 en comparación con Capa 1, tiene un paso adicional:

1. El usuario envía la transacción al Sequencer
2. Sequencer empaqueta las transacciones en bloques de Capa 2
3. Sequencer enviará los datos del bloque L2 a L1
4. Esperar la confirmación de L1

Entre los pasos 2 y 3 son exclusivos de Capa 2. En esta etapa, la transacción aún no se ha registrado en la cadena, y los usuarios solo pueden confiar en la promesa del Secuenciador, lo que se conoce como "pre-confirmación" ( Pre-Confirmation ).

Mecanismo de confirmación de transacciones de las soluciones L2 principales

Arbitrum/Optimism

• Las transacciones casi pueden obtener un recibo de inmediato, esta es la pre-confirmación del Sequencer.
• El explorador mostrará el estado de la transacción, incluyendo "Confirmado por Sequencer" y el número de confirmaciones de L1
• Optimism también mostrará el estado de Finalidad de L1

StarkNet

• El estado de la transacción incluye Recibido, Pendiente, Aceptado en Capa 2, Aceptado en Capa 1
• El tiempo de confirmación de L2 a L1 es más largo, aproximadamente 4-5 horas
• Explorer no muestra información de Finalidad L1

zkSync

• El estado de la transacción incluye Pendiente, zkSync Era Procesado, Comprometido, Comprobado, Ejecutado
• Dividir el proceso de L2 a L1 en tres etapas
• Explorer proporciona información detallada sobre cada etapa

Mecanismo de preconfirmación de L1

Si se puede conocer de antemano al minero, L1 también puede soportar la preconfirmación. En la arquitectura PBS, el Builder puede proporcionar servicios de preconfirmación, pero su efectividad es limitada. En el futuro, si el Proposer puede participar en la creación de bloques, el mecanismo de preconfirmación podría ser más confiable.

Mejora del mecanismo de preconfirmación

Se puede permitir que el Builder o el Sequencer depositen un depósito a través de un contrato inteligente y firmen el contenido del compromiso. Si se viola el compromiso, el usuario puede presentar pruebas y castigar a la otra parte, aumentando así la credibilidad de la pre-confirmación.

Resumen

• Las transacciones de L2 tienen una fase adicional de espera para subir a L1.
• Antes de subir a L1, los usuarios solo pueden confiar en la preconfirmación del Secuenciador.
• La mayoría de los Exploradores L2 mostrarán el estado de pre-confirmación
• Esperar a que los datos de L2 se suban a L1 es la práctica más segura.
• Se puede mejorar la fiabilidad de la preconfirmación a través de mecanismos de incentivos económicos.

La siguiente tabla resume las garantías de confirmación y los riesgos de las transacciones L1 y Capa 2 en cada etapa:

| Fase | Transacciones L1 | Transacciones L2 | |------|--------|--------| | Enviar transacción | Sin garantía | Sin garantía | | Preconfirmación | Builder se compromete ( en el futuro posiblemente ) | Sequencer se compromete | | Empacar bloques | Garantía alta | Garantía media ( depende de Sequencer ) | | Subir L1 | - | Alta garantía | | Múltiples confirmaciones | Garantía extremadamente alta | Garantía extremadamente alta | | Confirmación final | Garantía máxima | Garantía máxima |