Un agradecimiento especial a Jon Charbonneau y Conor McMenamin por revisar este artículo.

En este punto, todos deberíamos saber que las reglas de confirmación tienen seguridad, no resúmenes en sí. Cuando decimos que los rollups heredan la "seguridad de Ethereum" o que están "minimizados", lo que en realidad queremos decir es que en los rollups es posible utilizar reglas de confirmación que tienen aproximadamente la misma seguridad que las reglas de confirmación de Ethereum. Sin embargo, los exploradores de bloques se preocupan principalmente por mostrar una insignia verde sin entrar en detalles sobre a qué regla de confirmación se refieren o qué propiedades de seguridad proporcionan.

En L2BEAT queremos abordar este problema y hacerlo accesible para todos. En particular, queremos centrarnos en la finalidad, la regla de confirmación más sólida contra los ataques de doble gasto.

Reglas de confirmación: coherencia versus disponibilidad

Las reglas de confirmación son algoritmos que, bajo supuestos específicos, indican cuándo un bloque está confirmado y es poco probable que se reorganice. Una vez que se confirma un bloque, se pueden tomar acciones relacionadas con sus transacciones. Por ejemplo, esto podría implicar entregar un café a un cliente o entregar un automóvil a su comprador.

Las diferentes reglas de confirmación brindan a los usuarios diferentes garantías de seguridad. La seguridad de una regla de confirmación comprende coherencia y disponibilidad, y depende en gran medida de los algoritmos de consenso subyacentes:

• Coherencia (seguridad): la vista de dos nodos cualesquiera es coherente en las particiones de red.
• Disponibilidad (vivacidad): las transacciones continúan incluyéndose en el libro mayor dentro de un plazo determinado, incluso después de que una fracción sustancial de los nodos dejan de participar en el protocolo.

El teorema CAP nos dice que no es posible diseñar un algoritmo de consenso que permanezca consistente bajo particiones de red y disponible bajo participación dinámica: si ocurre una partición de red grave, los nodos pueden decidir continuar produciendo bloques y perder consistencia, o detenerse y perder disponibilidad. No hay forma de que los nodos distingan entre otros que simplemente están fuera de línea (participación dinámica) o que están activos pero inalcanzables (particiones de red) y, por lo tanto, no es posible actuar de manera diferente.

Eve no puede saber si Bob simplemente está desconectado o en una partición de red diferente.

Las cadenas de bloques como Bitcoin, que utilizan un consenso similar al de Nakamoto, favorecen la vida, lo que significa que durante una división de la red, ambos lados continuarán produciendo bloques y eventualmente se reorganizarán si se resuelve la partición, mientras que otras, como las cadenas Cosmos, que utilizan un consenso tipo PBFT. consenso, detenerse bajo las particiones de la red para preservar la coherencia.

Reglas de confirmación en Ethereum

Ethereum prioriza la disponibilidad bajo particiones de red utilizando el algoritmo LMD GHOST . Este enfoque significa que los nodos honestos pueden tener diferentes vistas en la punta de la cadena y podrían confirmar diferentes bloques para la misma altura, lo que podría conducir a reorganizaciones.

En condiciones favorables de la red, Ethereum también pretende proporcionar garantías de coherencia mediante la finalidad, utilizando el protocolo Casper FFG . La finalidad es la regla de confirmación más sólida posible, y los nodos tienen una regla codificada para nunca reorganizar los bloques finalizados.

El libro mayor finalizado (verde) es siempre un prefijo del libro mayor activo (azul).

Las garantías de finalidad se ven comprometidas si se finalizan dos bloques en conflicto, un evento que puede ocurrir si más de 1/3 de los validadores actúan de manera maliciosa. Sin embargo, en Ethereum, tales acciones conllevan la importante penalización de perder su participación.

Los usuarios pueden elegir si usar Casper FFG como la regla de confirmación más segura o estar más activos confiando en LMD GHOST. Las reglas de confirmación para LMD GHOST, de manera similar a la regla de confirmación k en Bitcoin, pueden ser más sofisticadas que simplemente mirar si la transacción está incluida en el libro mayor, como se especifica en la regla de confirmación Safe Block.

Reglas de confirmación en resúmenes

Los rollups pueden, en principio, utilizar las mismas reglas de confirmación disponibles en Ethereum. Si envía una transacción en un resumen y luego ve la misma transacción publicada en L1 en un bloque finalizado, es posible que también desee considerar la transacción L2 como final. Resulta que la historia es mucho más compleja que esto.

Resúmenes de datos de transacciones

En Ethereum, los bloques incluyen tanto la lista de transacciones como la raíz del estado propuesta en el encabezado del bloque. Si la ejecución de las transacciones no conduce al estado que representa la raíz, se descarta todo el bloque, incluidas las transacciones que luego se pueden agregar a otros bloques en un orden diferente.

En los paquetes acumulativos, dado que las acciones de publicación de datos y raíces están desacopladas, no es necesario descartar las transacciones dependiendo de la validez de las raíces estatales correspondientes. Dada esta separación, es suficiente verificar si las transacciones se finalizan sin esperar la finalización de la raíz estatal, evitando demoras adicionales, como el período de desafío de 7 días en los resúmenes optimistas.

Resumen de diferencias estatales

Las diferencias de estado son resultados de una función de transición de estado y, para validar que realmente son válidas, es necesario esperar una prueba ZK. La generación de pruebas ZK lleva tiempo y, además, existe un incentivo para retrasar aún más la inclusión de más transacciones en una sola prueba para amortizar mejor los costos de generación y verificación de pruebas.

Las técnicas de agregación de pruebas ofrecen una solución a este compromiso entre los tiempos de confirmación y la amortización de costos: incluso si un resumen experimenta una actividad mínima, aún puede beneficiarse de la amortización al incluir transacciones de resúmenes más activos en la misma prueba. Un ejemplo de este enfoque es SHARP de Starkware, que actualmente agrega pruebas de paquetes acumulativos de Starknet, Paradex y StarkEx como dYdX e incluso Validiums.

donde las cosas se complican

Especificación de derivación acumulada

Si un resumen no está basado en, el secuenciador de resumen puede definir el orden de derivación de los lotes, que podría publicarlos en un orden diferente en L1.

Para dar un ejemplo, las cadenas OP Stack publican lotes en L1 que están vinculados mediante los hashes del lote anterior. No es necesario publicar estos lotes en orden cronológico, lo que genera una ventana de secuenciación de 12 horas durante la cual los nodos esperan transacciones potencialmente faltantes. Las transacciones no deben considerarse incluidas simplemente porque se publican en L1: si un lote aún no está conectado a la cadena canónica de lotes, existe el riesgo de que se cree una bifurcación alternativa con un orden o conjunto de transacciones diferente.

En las cadenas OP Stack, el tiempo de bloque es de 2 segundos, lo que da como resultado 6 bloques dentro de cada bloque de Ethereum. Esta agrupación de 6 bloques entre bloques de Ethereum se denomina "época". Los mensajes L1 a L2 enviados a través de L1 se incluyen en la primera parte del primer bloque de la época correspondiente para el bloque L1 dado. Si bien estas transacciones pueden considerarse confirmadas sin esperar a que pase la ventana de secuenciación, ya que se conoce su orden dentro del libro mayor L2 al momento de la derivación, es importante tener en cuenta que los nodos no comenzarán a calcular bloques que contengan estos mensajes si falta un lote anterior. Esto se debe a que el estado no se puede calcular sin la secuencia completa y, por lo tanto, las raíces del estado tampoco se publicarán en L1.

La consecuencia de esto es que el simple examen de los datos en cadena es insuficiente para rastrear los tiempos de confirmación L1. También es necesario comprender cómo se derivan los bloques L2 de los datos L1 examinando el propio software del nodo acumulativo.

Funciones permitidas

Scroll es un resumen de ZK que publica datos de transacciones, lo que significa que, en principio, no es necesario esperar una prueba de ZK para considerar que su transacción es definitiva. Esto hubiera sido cierto si no hubieran implementado una función para eliminar lotes que aún no han sido probados.

https://etherscan.io/address/0x2e07f0fba71709bb5e1f045b02152e45b451d75f#code#F1#L260

Lo mismo puede aplicarse a los rollups que publican diferencias de estado: zkSync Era y zkSync Lite tienen un proceso de tres pasos para publicar diferencias de estado: primero, confirman los datos sin ninguna prueba, luego proporcionan una prueba y luego, después de un retraso de 24 horas. , la raíz queda disponible para ejecutarse y procesar retiros. En teoría, cuando se proporciona una prueba, el orden de las transacciones es fijo, por lo que no es necesario esperar a que pase el retraso en la ejecución. Excepto que zkSync puede revertir esos bloques:

https://etherscan.io/address/0x7Ed066718Dfb1b2B04D94780Eca92b67ECF3330b#code#F10#L425

Mientras que en zkSync Era nunca se han revertido bloques, en zkSync Lite sucedió 8 veces.

Observabilidad de la finalidad

Dado que las diferencias de estado de publicación acumulada no publican datos de transacciones, ¿cómo podemos rastrear si una transacción realmente se ha incluido? Sí, podríamos rastrear los efectos, como los nonces de cuenta, pero el caso general se vuelve complicado. Hace un mes hice la siguiente pregunta:

Echemos un vistazo a algunas de las respuestas:

Esta es una solución que funciona si el secuenciador está dispuesto a responderte y si confías en él. ¿Qué pasa si no es así? ¿O qué pasa si lo hace pero no confías en él? ¿Cómo se verifica que el reclamo es correcto?

Mi respuesta favorita.

Aquí se sugirió una solución que realmente funciona:

Si bien esto funciona, significa que la decisión técnica de utilizar diferencias de estado se filtra en la lógica de la aplicación, lo que significa que incluso si un paquete acumulativo es equivalente a EVM, los proyectos deben adaptar su contrato a esta consideración.

Una solución parcial es publicar una raíz de transacciones y verificar su validez dentro de la prueba ZK. Sin embargo, incluso en este caso, uno debe confiar en el secuenciador para obtener la ruta Merkle necesaria, lo que podría ser razonable con secuenciadores centralizados acreditados, pero se vuelve más complicado en un entorno sin permiso.

Métricas de vida

Como primer paso hacia el seguimiento de los tiempos hasta la finalización de las transacciones acumuladas, en L2BEAT comenzamos a realizar un seguimiento de las métricas de vida, en particular los intervalos entre lotes de transacciones (si corresponde) y las raíces estatales. La razón es que si un resumen interactúa, por ejemplo, con L1 solo una vez al mes, los usuarios no pueden esperar que el tiempo hasta la finalización sea del orden de minutos. Las métricas de vida pueden considerarse como un indicador de límite inferior del tiempo hasta la finalización: si un resumen de datos de transacciones publica lotes una vez cada dos minutos y suponiendo que la distribución de las transacciones L2 es uniforme, el tiempo esperado hasta la finalización no es inferior a un minuto. .

Aquí hay algunos ejemplos de datos que estamos rastreando para zkSync Era (actualizaciones de estado) y OP Mainnet (lotes de transmisión):

Métricas de vida de zkSync Era para el mes de septiembre.

Métricas de vida de OP Mainnet para el mes de septiembre.

Como se predijo, dado que las pruebas ZK tardan en generarse y existe el incentivo de incluir más transacciones en una sola prueba, zkSync Era tiene peores métricas de vida que OP Mainnet. Es importante tener en cuenta que, como comentamos en secciones anteriores, las métricas de vida no se traducen directamente en consideraciones de finalidad: en el peor de los casos, OP Mainnet tiene en realidad un mayor tiempo hasta la finalidad debido a su ventana de secuenciación.

Ahora puedes explorar métricas de vida para la mayoría de los rollups en L2BEAT:

Limitaciones del seguimiento de la vida

Si bien la vivacidad puede verse como un indicador límite inferior de finalidad, a veces puede ser muy malo. Imagine un paquete acumulativo con un tiempo de bloque de 4 segundos, lo que significa que por cada bloque de Ethereum hay 3 bloques acumulativos. Si el operador de rollup publica solo dos bloques L2 por bloque L1, incluso si desde la perspectiva de Ethereum el rollup está muy activo, se quedará cada vez más atrás de las confirmaciones suaves de L2 y el tiempo hasta la finalidad sería cada vez peor. Si bien este es un escenario extremo, es algo que los resúmenes deben tener en cuenta.

Un ejemplo práctico es Starknet: aunque observamos un promedio de 32 segundos entre actualizaciones de estado, el tiempo hasta la finalización es en realidad cercano a las 6 horas:

Fuente: starkscan.co

Esto se debe a que Starknet publica una actualización del estado de la raíz para cada bloque L2 en L1. Sin embargo, para hacer esto, deben hacer referencia a una prueba SHARP, que normalmente se publica aproximadamente una vez cada 30 minutos. Además, estas pruebas están aproximadamente 6 horas detrás de la punta de la cadena de confirmación suave L2.

Confirmaciones suaves

Las confirmaciones suaves son reglas de confirmación que se utilizan para lograr tiempos de confirmación más cortos en L2 a expensas de las garantías de seguridad. Actualmente, en todos los casos, las confirmaciones suaves implican confiar en que el operador centralizado no publicará txs diferentes en L1. Las confirmaciones suaves incorrectas son fallas atribuibles, por lo tanto, se pueden implementar mecanismos para rastrear la reputación de los secuenciadores fuera de la cadena o en la cadena. En colaboración con Nethermind, planeamos estimar esas propiedades de seguridad y rastrear la cantidad de valor en riesgo en un momento dado.

Izquierda: garantías económicas para Starknet si tuvieran confirmaciones suaves aseguradas por un mecanismo de recorte. Derecha: valor total en riesgo de reordenarse con el tiempo.

Avanzando

Hacer un seguimiento del tiempo hasta la finalización es una tarea compleja. Nuestro primer paso es monitorear los intervalos de envío de pruebas para los paquetes acumulativos de ZK, que imponen un límite inferior más alto en el tiempo hasta la finalización en comparación con los intervalos entre los envíos de estado raíz. Después de esto, planeamos introducir gráficos que muestren datos históricos para cada proyecto. Posteriormente, nuestra investigación se centrará en todos los mecanismos adicionales que deben considerarse para, en última instancia, lograr métricas en tiempo real hasta su finalización. ¡Manténganse al tanto!

Descargo de responsabilidad:

1. Este artículo se reimprime de [medio]. Todos los derechos de autor pertenecen al autor original [Luca Donno]. Si hay objeciones a esta reimpresión, comuníquese con el equipo de Gate Learn y ellos lo manejarán de inmediato.
2. Descargo de responsabilidad: los puntos de vista y opiniones expresados en este artículo son únicamente los del autor y no constituyen ningún consejo de inversión.
3. Las traducciones del artículo a otros idiomas están a cargo del equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.