¿No cuenta como un Rollup si no usa Ethereum como capa DA? Entendiendo la Capa 2 desde la perspectiva del proponente de Danksharding

Autor: Fausto, friki web3

Introducción: Recientemente, Dankrad Feist, el creador de Danksharding e investigador de la Fundación Ethereum, hizo algunos comentarios controvertidos en Twitter. Señaló claramente que una cadena de bloques modular que no usa ETH como capa DA (capa de disponibilidad de datos) no es Rollup, ni es Ethereum Layer 2. Según Dankrad, Arbitrum Nova, Immutable X, ApeX y Metis pueden "eliminarse" de la lista de Capa 2, porque solo divulgan datos de transacciones fuera de ETH (construyeron su propia red DA fuera de la cadena llamada DAC).

Al mismo tiempo, Dankrad también dijo que las soluciones como Plasmas y canales estatales que no requieren disponibilidad de datos en cadena (Disponibilidad de datos) para garantizar la seguridad siguen siendo Capa 2, pero Validium (ZKRollup que no usa ETH como capa DA) no es la capa 2.

Tan pronto como surgieron los comentarios de Dankrad, muchos fundadores o investigadores en el campo de Rollup cuestionaron. Después de todo, hay muchos proyectos de "Capa 2" que no usan ETH como la capa DA (Disponibilidad de datos) para ahorrar costos. Si estos proyectos se eliminan de la lista L2, inevitablemente afectará bastante la expansión. redes; al mismo tiempo, si validium no se cuenta como L2, Plasma tampoco debería calificar como L2.

En este sentido, Dankrad dijo que cuando DA no está disponible (es decir, la red de capa DA debajo de la cadena se involucra en la retención de datos y no divulga datos de transacciones), los usuarios de Plasma aún pueden retirar sus activos de manera segura a L1; pero bajo las mismas circunstancias. , Validium (la mayoría de los proyectos que utilizan el esquema StarkEx son validium), pero puede evitar que los usuarios retiren fondos a L1 y congelar el dinero.

Obviamente, Dankrad tiene la intención de definir si un proyecto de expansión es Ethereum Layer 2 a partir de "si es seguro o no". Desde la perspectiva de la "seguridad", Validium puede congelar activos de usuario en L2 y no puede mencionar L1 en el caso extremo de falla del secuenciador + capa DA lanzando un ataque de retención de datos (ocultando nuevos datos); Diferente de Validium en diseño, aunque la mayoría de Por el momento, la seguridad no es tan buena como la de Validium, pero cuando la falla del secuenciador + la capa DA lanza un ataque de retención de datos (oculta nuevos datos), permite a los usuarios evacuar activos de forma segura a L1. Así que la retórica de Dankrad tiene sentido.

Este artículo tiene la intención de comenzar desde la perspectiva de Dankrad y analizar más a fondo los detalles de Layer2 para comprender por qué Validium no es estrictamente "Layer2".

¿Cómo definir Layer2?

Según la definición del sitio web ethereum.org y la mayoría de los miembros de la comunidad Ethereum, la Capa 2 es "una cadena de bloques independiente que amplía la capacidad de Ethereum + hereda la seguridad de Ethereum". En primer lugar, "ampliar la capacidad de Ethereum" se refiere a desviar el tráfico que Ethereum no puede transportar y compartir la presión de TPS. Y "heredar la seguridad de Ethereum" en realidad puede traducirse como "proteger su propia seguridad con la ayuda de Ethereum".

Por ejemplo, todas las transacciones Tx en la Capa 2 deben finalizarse en ETH, y no se liberarán Tx con datos incorrectos; si desea revertir el bloque de Capa 2, primero debe revertir el bloque Ethereum, siempre que Ethereum Los bloques L2 de la red principal no se revertirán sin una reversión de bloques similar a un ataque del 51 %.

Si exploramos más a fondo la seguridad de la Capa 2, en realidad hay muchos casos de esquina a considerar. Por ejemplo, si la parte del proyecto L2 se escapa, el secuenciador falla y la capa DA fuera de la cadena cuelga, ¿pueden los usuarios retirar sus fondos de forma segura en L2 a L1 cuando ocurren estos eventos extremos?

Mecanismo de "retirada forzada" de Layer2

Independientemente de factores como actualizaciones de contratos L2/peligros ocultos de firmas múltiples, de hecho, como Arbitrum o StarkEx, hay salidas para que los usuarios establezcan retiros obligatorios. Suponiendo que el secuenciador de L2 lanza un ataque de censura, rechaza deliberadamente la transacción/solicitud de retiro del usuario, o simplemente se apaga permanentemente, el usuario de Arbitrum puede llamar a la función de inclusión forzada del contrato de la bandeja de entrada del secuenciador en L1 para enviar directamente los datos de la transacción a L1 ; Dentro de las 24 horas, el secuenciador no ha procesado la transacción/retiro que debe ser "obligatoriamente incluido", y la transacción se incluirá directamente en la secuencia de transacciones del libro mayor Rollup, lo que crea un "retiro obligatorio" para los usuarios de L2. salida".

En contraste, el esquema StarkEx con el mecanismo Escape Hetch de la cápsula de escape es aún peor. Si el usuario de L2 no recibe una respuesta del secuenciador cuando finaliza la solicitud de retiro forzado enviada por L1 dentro del período de 7 días, el usuario puede llamar a la función de solicitud de congelación para permitir que L2 ingrese al período de congelación. En este momento, el secuenciador L2 no podrá actualizar el estado L2 en el L1, y tardará 1 año después de que el estado L2 se congele para descongelarse.

Después de que se congela el estado L2, el usuario puede construir una prueba de Merkle relacionada con el estado actual para demostrar que tiene XX cantidad de fondos en L2 y retirar fondos a través del contrato relacionado con Escape Hetch en L1. Este es el servicio de "retiro completo" proporcionado por el programa StarkEx. Incluso si la parte del proyecto L2 se ha ido y el secuenciador falla permanentemente, los usuarios todavía tienen una forma de retirar fondos de L2.

Pero aquí hay un problema: la mayoría de L2 que usa el esquema StarkEx es Validium (como Immutable X y ApeX), y no publicará los datos requeridos por DA a ETH, y la información para construir el árbol de estado L2 actual se almacena fuera de la cadena Si el usuario no puede obtener los datos para construir Merkle Proof fuera de la cadena (por ejemplo, la capa DA fuera de la cadena lanza un ataque de retención de datos), es imposible retirar fondos a través de la cápsula de escape.

Hasta ahora, la razón por la que Dankrad mencionó al comienzo del artículo que cree que Validium no es seguro es muy clara: debido a que Validium no envía datos DA a la cadena como Rollup, es posible que los usuarios no puedan construir el Merkle requerido para "forzar retirada". Prueba.

La diferencia entre Validium y Plasma en caso de un ataque de retención de datos

De hecho, el secuenciador de Validium solo publica el Stateroot más reciente (la raíz del árbol de estado) de L2 en la cadena L1 y luego envía una Prueba de validez (Prueba ZK) para probar la transición de estado (cambio de fondos de usuario) involucrada en el nuevo Stateroot proceso de generación. , son todos correctos.

Sin embargo, stateroot por sí solo no puede restaurar el trie de estado mundial del árbol de estado actual, y no puede conocer el estado específico de cada cuenta L2 (incluido el saldo de fondos), y los usuarios de L2 no pueden construir una prueba de Merkle correspondiente al Stateroot legal actual. Aquí es donde Validium está en desventaja.

Aquí hay que recalcar lo del DAC. Los datos involucrados en el DA de Validium, como el último lote de transacciones procesadas por el secuenciador, se sincronizarán con la red DA exclusiva de L2 denominada Comité de Disponibilidad de Datos (DAC). Y los miembros de la comunidad u otras unidades son responsables de la operación y supervisión (pero esto es solo en la superficie, de hecho, es difícil para el mundo exterior verificar quiénes son los miembros del DAC).

Lo interesante es que los miembros del DAC de Validium necesitan enviar con frecuencia en L1 Multi-signature, lo que demuestra que el nuevo Stateroot y Validity Proof presentado por el secuenciador L2 en L1 se pueden comparar con los datos DA sincronizados por el DAC. Después de la presentación de múltiples firmas de DAC, el nuevo Stateroot y Validity Proof se considerarán legales.

En la actualidad, el DAC de Immutable X adopta la firma múltiple 5 / 7. Aunque dYdX es ZKRollup, también tiene DAC, que usa la firma múltiple 1/2. (dYdX solo publica diferencias de estado en L1, es decir, cambios de estado, en lugar de datos completos de transacciones. Sin embargo, después de obtener las diferencias de estado en los registros históricos, se puede restaurar el saldo de activos de todas las direcciones L2. En este momento, Merkle Proof puede construirse para retirarse en su totalidad).

Dankrad tiene razón. Si los miembros de DAC de Validium conspiran para lanzar un ataque de retención de datos, evitar que otros nodos L2 sincronicen los datos más recientes en este momento y actualizar el Stateroot legal de L2 en este momento, el usuario no puede construir la Prueba Merkle correspondiente a la legal. root en el momento de retirar dinero (porque los datos DA actuales ya no están disponibles, los datos DA anteriores están disponibles).

Pero Dankrad solo considera casos extremos teóricos. En realidad, la mayoría de los secuenciadores de Validium transmitirán los datos de transacciones recién procesados a otros nodos L2 en tiempo real, incluidos muchos nodos honestos. Siempre que haya un nodo honesto que pueda obtener datos de DA a tiempo, los usuarios pueden escapar de L2.

Pero el problema que teóricamente existe en Validium, ¿por qué no existe en Plasma? Esto se debe a que la forma en que Plasma determina el Stateroot legal es diferente de Validium, porque hay un período de prueba de fraude. Plasma es la solución de expansión de L2 anterior a OPRollup. Al igual que OPR, se basa en pruebas de fraude para garantizar la seguridad de L2.

Plasma, como OPR, tiene una configuración de período de ventana. El nuevo stateroot lanzado por el secuenciador no se considerará legal de inmediato. Tiene que esperar hasta que se cierre el período de ventana y no haya un certificado de fraude emitido por el nodo L2. Por lo tanto, los Stateroots legales actuales de Plasma y OPR se enviaron hace unos días (esto es como la luz de las estrellas que vemos, que en realidad se emitió hace mucho tiempo), y los usuarios a menudo pueden obtener datos de DA en momentos pasados.

Al mismo tiempo, el requisito previo para que el mecanismo a prueba de fraude surta efecto en este momento es que el L2 DA esté disponible en este momento, es decir, el nodo Verificador de Plasma pueda obtener los datos involucrados en el DA en este momento, por lo que que se pueda generar la prueba de fraude en el momento (en caso de ser necesario).

Entonces todo es muy simple: la premisa de que Plasma funcione normalmente es que los datos DA de L2 estén disponibles en este momento. Si a partir de ahora, el DA de L2 no está disponible, ¿pueden los usuarios retirar fondos de forma segura?

Este problema no es difícil de analizar, suponiendo que el período de ventana de Plasma es de 7 días, si a partir de un cierto punto de tiempo T0, los nuevos datos de DA no estarán disponibles (DAC lanza un ataque de retención de datos para evitar que los nodos L2 honestos obtengan datos después de T0). Debido a que el Stateroot legal en T0 y durante un período de tiempo posterior se envió antes de T0, y se pueden rastrear los datos históricos antes de T0, los usuarios pueden construir Merkle Proof para forzar el retiro.

Aunque muchas personas no pueden detectar la anomalía de inmediato, porque hay un período de ventana (OP es de 7 días), siempre que el Stateroot enviado en T0 no haya sido legalizado, y los datos DA antes de T0 se puedan rastrear, los usuarios pueden retirarse con seguridad dinero de L2.

Resumir

Hasta ahora podemos entender aproximadamente la diferencia entre Validium y Plasma en términos de seguridad:

Después de que el secuenciador de Validium publique Stateroot, siempre que publique inmediatamente Validity Proof y DAC multi-firma, puede hacerlo legal y convertirse en el último Stateroot legal; si los usuarios y los nodos L2 honestos encuentran ataques de retención de datos, no pueden construir el Merkle correspondiente a el Stateroot legal actual. Prueba, no puede retirar dinero a L1.

Sin embargo, después de que Plasma envía un nuevo Stateroot, no puede ser legal hasta el final del período de ventana En este momento, el Stateroot legal se envió en el pasado. Debido a que hay un período de ventana (ARB es de 3 días, OP es de 7 días), incluso si los datos de Stateroot DA recién enviados no están disponibles, el usuario todavía tiene los datos de Stateroot DA legales actuales (la raíz legal se envió en el pasado) , y hay tiempo suficiente para forzar Retiro a L1.

Entonces, lo que dijo Dankrad tiene sentido. Cuando ocurre un ataque de retención de datos, Validium puede atrapar los activos del usuario en L2, pero Plasma no tiene este problema.

Por lo tanto, los ataques de retención de datos en la capa DA fuera de la cadena causarán muchos riesgos de seguridad, pero es este problema el que Celestia está tratando de resolver. Además, debido a que la mayoría de los proyectos de Capa 2 proporcionarán puertos de servicio para mantener los nodos L2 y los secuenciadores sincronizados fuera de la cadena, las preocupaciones de Dankrad suelen ser más teóricas que reales.

Si usamos una actitud quisquillosa y presentamos una hipótesis más extrema: todos los nodos fuera de la cadena de Plasma no están disponibles, entonces los usuarios comunes que no han pasado por los nodos L2 no podrán forzar retiros a L1. Pero la probabilidad de que tal cosa suceda es equivalente a la probabilidad de que todos los nodos de una cadena pública se desactiven colectivamente de forma permanente, y es posible que nunca suceda.

Entonces, muchas veces, la gente solo habla de cosas que nunca sucedieron. Al igual que la frase de oro que el vicepresidente de Rick Gerb le dijo al protagonista del drama estadounidense "Chernobyl": "¿Por qué preocuparse por cosas que nunca sucederán?"