Corrija los comentarios vagos de Vitalik sobre cuestiones de DA y retiros resistentes a la censura

Vitalik se perdió el “desafío de disponibilidad de datos” de Arbitrum y Redstone, que se puede llamar el asesino de Celestia.

Escrito por: Fausto, geek web3

El 16 de enero de 2024, en un tweet iniciado por Daniel Wang, fundador del proyecto Ethereum Layer 2 Taiko, e interactuando con Zeng Jiajun, fundador de AA wallet Soul Wallet, Vitalik dijo: "La clave de Rollup es la seguridad incondicional: incluso “Si eres el objetivo de todos y aún puedes quitarte los activos. Esto no se puede hacer si DA depende de un sistema externo (fuera de Ethereum)”.

Escape Pod: “Retiros seguros sin condiciones” en palabras de Viatlik

Debido a que Vitalik habló sobre sus puntos de vista sobre Validium en la segunda mitad de este tweet (Validium se refiere a la segunda capa de ZK que no usa Ethereum para implementar la publicación de datos DA), atrajo mucha atención (anteriormente había rumores de que Ethereum El fondo pensará en Layer2 = Rollup).

(Debe enfatizarse: ** El concepto DA discutido en la comunidad Ethereum se refiere a si puede obtener datos recién generados de la Capa 2, no a si puede recuperar datos históricos hace mucho tiempo. ** Si no está publicado en Ethereum cadena de datos nuevos, es posible que los nodos Layer2 no puedan analizar con éxito el último bloque L2)

Sin embargo, innumerables personas han escuchado durante mucho tiempo el “Debate sobre la definición de la capa 2 de Ethereum” y la “Guerra de DA”. Este artículo no tiene la intención de discutir estos temas. El propósito es centrar más energía en la primera mitad de El discurso de Vitalik también son las palabras mencionadas al principio de este artículo.

Vitalik declaró aquí que Rollup puede lograr retiros sin confianza y resistentes a la censura. Incluso si todos los nodos de Layer2 no cooperan con usted, aún puede retirar sus activos de Layer2; y ** señaló que solo rollup puede lograr esto " “Incondicionalmente seguro retiro”, mientras que la Capa 2, que depende de otros métodos de publicación de datos DA, no puede hacer esto. **

Pero, de hecho, lo que dijo Vitalik no es riguroso. **

En primer lugar, solo los activos que están conectados de la Capa 1 a la Capa 2 se pueden cruzar de regreso a la cadena ETH. Los activos nativos puros de la Capa 2 no se pueden cruzar a la Capa 1 (a menos que los activos nativos de la Capa 2 implementen un contrato de activos puente en la Capa 1).

**Si, como dijo Vitalik, “todo el mundo está apuntando a ti”, **puedes retirar los activos puente L1-L2 como máximo, **pero no puedes retirar tu “Token nativo de Capa 2”, **en este momento no No importa si utilizas una retirada normal, una retirada forzada o una escotilla de escape.

En segundo lugar, “**Retiro seguro sin condiciones” no depende necesariamente del sistema DA. ** La primera solución Layer2 antes de Rollup, Plasma que implementa la liberación de datos DA bajo la cadena Ethereum, cuando el sistema DA falla (es decir, se produce la retención de datos, aparte del secuenciador/comité, nadie más puede recibir nuevos datos de transacción/Estado información de transición), también permite a los usuarios enviar certificados de activos a través de datos históricos y escapar de la Capa 2 de forma segura.

En otras palabras, **los retiros seguros de Plasma no dependen del sistema DA, y **los retiros anticensura no tienen que depender del sistema DA (pero los datos históricos deben estar disponibles); además, **esta declaración es de Ethereum Dankrad de la Fundación (el creador de Danksharding) lo dijo él mismo, ** también es universalmente aceptado.

Consulte los artículos anteriores de Geek Web3: “Retención de datos y prueba de fraude: razones por las que Plasma no admite contratos inteligentes”

En segundo lugar, dejando de lado a Celestia y Blobstream, el problema de retención de datos/fallo de DA se puede resolver incluso sin utilizar ETH como capa DA. Hablemos simplemente del “desafío de disponibilidad de datos” que el equipo de Arbitrum y el equipo de Redstone están implementando, permitiendo al secuenciador publicar solo un Compromiso DA (en realidad, un hash de datos) en la cadena, indicando que los datos han sido liberados de la cadena. Si alguien no puede obtener los datos recién generados fuera de la cadena, puede desafiar el Compromiso DA en la cadena y exigir que el secuenciador revele los datos a la cadena.

Este mecanismo tiene un diseño muy simple y no necesita depender de DA de terceros como Celestia, Avail o EigenDA. Solo requiere que la parte del proyecto Layer2 configure el nodo DAC fuera de la cadena. Se le puede llamar un asesino de Celestia. **

A continuación, el autor tiene la intención de interpretar el “retiro seguro sin condiciones” mencionado por Vitalik y el “desafío de disponibilidad de datos” que no mencionó, y tratar de decirles a todos: ** ¿Por qué proyectos DA de terceros como Celestia, Avail? y EigenDA no son una opción imprescindible para la capa 2 que es DA fuera de la cadena y busca la seguridad. **

Además, en nuestro artículo anterior que explica "Indicadores de evaluación de riesgos de la capa 2 de Bitcoin", hablamos de que los retiros resistentes a la censura son más básicos y críticos que el sistema DA. El artículo de hoy también discutirá este punto de vista. explicación. **

De hecho, no es difícil deducir lo que dijo Vitalik: se refería a la cabina de escape de ZK Rollup. Escape Hatch, también conocido como Escape Hatch, es un modo de retirada que se activa directamente en Layer1. Una vez que se activa este modo, el contrato acumulativo entrará en un estado congelado, rechazará los nuevos datos enviados por el secuenciador y permitirá que cualquiera muestre Merkle Proof para demostrar su saldo de activos en Layer2 y transferir sus propios activos desde Transferencia de la dirección de depósito puente oficial de Layer2. **

Además, el modo de trampilla de escape es un “mecanismo de retiro sin confianza” que las partes en la Capa 1 pueden activar manualmente después de que el secuenciador de la Capa 2 haya rechazado la transacción del usuario durante mucho tiempo. **

Sin embargo, antes de activar el modo de trampilla de escape, los usuarios que son rechazados por el secuenciador primero deben llamar a la función de retiro forzado en el contrato acumulativo en la Capa 1, iniciar una solicitud de retiro forzado y lanzar un evento para informar al nodo de Capa 2: alguien ha iniciado un retiro forzoso Solicitud de retiro.

Dado que todos los nodos Layer2 ejecutarán el cliente geth de Ethereum y recibirán bloques de Ethereum, pueden monitorear la activación del evento de retiro forzado

Si la solicitud de retiro forzado se ignora durante mucho tiempo, el usuario puede activar activamente el modo de trampilla de escape (el período de espera predeterminado del protocolo Loopring es de 15 días y el plan StarkEx es de 7 días). Luego, el proceso de operación es como se discutió al principio de este artículo: el usuario envía la Prueba Merkle correspondiente a sus propios activos para demostrar el estado de sus activos en la Capa 2, y luego retira los activos del contrato relacionado con Rollup.

**Pero para construir Merkle Proof, primero necesita conocer el estado completo de L2 y **necesita encontrar un nodo completo de L2 para solicitar datos. Si ocurre la situación extrema mencionada por Vitalik y no hay ningún nodo de Capa 2 que coopere con usted, ** puede iniciar un nodo completo de Capa 2 usted mismo y obtener los datos históricos publicados por el clasificador L2 en Ethereum a través de la red Ethereum, ** desde la Capa 2 Los bloques de génesis comienzan a sincronizarse uno por uno hasta que se calcula el estado final y se construye la Prueba Merkle, y luego los fondos se pueden retirar de forma segura a través de la trampilla de escape.

**Obviamente, la “resistencia a la censura” en este momento es equivalente al propio Ethereum/Layer1. ** Siempre que el nodo completo de Ethereum le proporcione datos históricos de hace mucho tiempo, está cerca de la falta de confianza.

**Sin embargo, después de EIP-4844, todos los nodos de Ethereum perderán automáticamente algunos datos históricos, por lo que los datos históricos de la Capa 2 durante más de 18 días ya no estarán respaldados por todo el nodo ETH. En ese momento, la resistencia a la censura de las retiradas de trampillas de escape ya no serán tan buenas como hoy están tan cerca de Trustless. **

Después de 4844, debemos confiar en que un número relativamente limitado de nodos de Ethereum que almacenan todos los datos históricos están dispuestos a proporcionarle datos (los nodos nativos de Capa 2 suelen ser muy pocos, por lo que no los consideraremos por el momento). Para entonces, la suposición de confianza de **Se pueden recuperar datos históricos de Capa1/retirada de la trampilla de escape de Capa2 cambiará del Trustless actual o 0 a 1/N, es decir, se supone que 1 de N nodos puede proporcionarle datos. **

El equipo de EthStorage parece estar comprometido a expandir esta N para alentar a más nodos a almacenar datos históricos de hace mucho tiempo. Si el denominador de 1/N es lo suficientemente grande, la puntuación aún está cerca de 0, lo que significa que no se introduce ningún supuesto de confianza. Esta puede ser una solución adecuada al problema de la recuperación de datos históricos después de 4844.

La relación entre las cápsulas de escape y DA: el ataque de ransomware de Validium

Aquí lo resumiremos nuevamente: **La trampilla de escape le permite demostrar el estado de sus activos de Capa 2 a través de Merkle Proof y realizar retiros confiables en la Capa 1. **

La razón por la que Vitalik mencionó que la seguridad de los activos involucrados en los retiros requiere DA como requisito previo es que la solución Validium puede evitar retiros debido a "ataques de retención de datos". (Solo se publica stateroot y no se publican los datos de transacción correspondientes).

El principio específico es: el secuenciador puede conservar los datos de la transacción y solo publicar una Merkle Root (Stateroot) en la cadena Ethereum, y luego, a través de la prueba de validez, intentar hacer que el nuevo Stateroot pase la verificación y se convierta en el Stateroot legal actual.

En este momento, no todos conocen el estado completo correspondiente al Stateroot legal y no pueden construir la Prueba Merkle correspondiente para iniciar la retirada de la trampilla de escape. **No puede retirar dinero a menos que el clasificador esté dispuesto a revelarle los datos. Un director técnico de Arbitrum lo llama vívidamente “problema de rescate” (yo personalmente prefiero llamarlo ataque de rescate). **

**Pero la razón por la que DA es propenso a “ataques de rescate” en Validium fuera de la cadena es porque el diseño de su propio mecanismo no es lo suficientemente perfecto. **Si se introduce un mecanismo de desafío relacionado con el comportamiento de retiro, o se introduce un desafío de disponibilidad de datos En teoría, puede resolver el problema de los ataques de ransomware.

Por cierto, como se mencionó anteriormente, Plasma, que permite a los usuarios retirar dinero a través de datos históricos de hace mucho tiempo, no tendrá “ataques de rescate” como Validium, y Plasma también es DA fuera de la cadena (verificación en cadena DA+ fuera de la cadena). a prueba de fraude).

*Referencia: *Retención de datos y prueba de fraude: por qué Plasma no admite contratos inteligentes

**Por lo tanto, los retiros/escotillas de escape resistentes a la censura no dependen necesariamente del DA, todo depende del diseño del mecanismo del proceso de retiro. **La razón por la que Vitalik cree que los retiros resistentes a la censura están vinculados a DA es porque partió de soluciones existentes como Validium y Smart Contract Rollup, y ya tenía una mentalidad fija en su mente.

**Pero esto no significa que toda la Capa 2 de DA offchain en el mundo enfrente los mismos problemas que Validium. **No significa que el tipo de contrato inteligente Rollup sea el final de todo. La innovación puede ocurrir en cualquier momento (como los desafíos de disponibilidad de datos que se mencionan más adelante).

Por otro lado, si su solución de Capa 2 no considera diseños como trampillas de escape y retiradas anticensura desde el principio, su solución de Capa 2 definitivamente no será lo suficientemente confiable/segura. **En otras palabras, un buen DA y un buen sistema de prueba son condiciones suficientes para lograr retiradas resistentes a la censura, pero no son una condición necesaria.

Por lo tanto, en nuestro artículo anterior, mencionamos que en el efecto barril de Capa 2, la retirada resistente a la censura es una deficiencia más básica que la DA y los sistemas de prueba, y hay una razón.

*Material de referencia: *“Uso de la teoría del barril para desmantelar el modelo de seguridad y los indicadores de riesgo de capa 2 de Bitcoin/Ethereum”

Celestia Killer: Desafíos de disponibilidad de datos para Arbitrum y Redstone

Después de hablar sobre la relación entre la trampilla de escape y DA, echemos un vistazo al DA en sí: la Capa 2 no necesita publicar datos de DA en Ethereum para evitar la “retención de datos” por parte del secuenciador.

Redstone, Arbitrum, Metis, etc. están desarrollando un mecanismo de “desafío de disponibilidad de datos”, que permite al secuenciador publicar solo el compromiso DA (datahash) + Stateroot en la cadena, indicando que los parámetros de transición de estado (datos de transacción) se han publicado. fuera de la cadena. **Si alguien no puede obtener los datos recién generados fuera de la cadena, puede desafiar el Compromiso DA en la cadena y exigir que el secuenciador revele los datos a la cadena. **

Si el secuenciador no publica datos en la cadena ETH a tiempo después de ser cuestionado, el datahash/compromiso que publicó anteriormente se considerará inválido y el stateroot asociado también será inválido. ** Obviamente, esto resuelve directamente el problema de retención de datos (solo se publica stateroot y no se publican los datos de transacción correspondientes). **

Obviamente, esto presenta un “desafío de disponibilidad de datos” adicional en comparación con la Capa 2 de las cadenas de DA como Validium y Optimium. **Pero un diseño tan simple es suficiente para crear una fuerte competencia contra Celestia, Avail, EigenDA, etc. **Configure un DAC usted mismo e introduzca desafíos de disponibilidad de datos, para que ya no necesite depender de Celestia.

Pero, por el contrario, los desafíos de disponibilidad de datos también tienen problemas económicos que deben resolverse. **El fundador de ZkSync señaló durante una batalla con el director técnico de Arbitrum que **los desafíos de disponibilidad de datos son teóricamente susceptibles a ataques DoS. **Por ejemplo, el secuenciador libera rápidamente miles de compromisos de DA en la cadena y luego retiene los datos completos correspondientes sin publicarlos. Puede drenar todos los fondos del retador de esta manera y luego emitir un bloqueo no válido, robando los activos del usuario.

Por supuesto, esta suposición es demasiado extrema. Es esencialmente un problema de teoría de juegos entre el atacante y el defensor. De hecho, es más probable que el secuenciador sea atacado por retadores maliciosos y degenere en un Rollup después de ser desafiado continuamente. La situación del juego entre los lados ofensivo y defensivo en torno al desafío de la disponibilidad de datos es realmente muy interesante, y el diseño del mecanismo correspondiente también pondrá a prueba por completo la sabiduría de Arbitrum, Redstone y el equipo del proyecto Metis (este tema se puede escribir por separado).

Pero en cualquier caso, el desafío de la disponibilidad de datos traerá más innovación al diseño de la solución DA de la Capa 2, que también hará una contribución significativa al ecosistema de la Capa 2 de Bitcoin.