¿Por qué no es rigurosa la declaración de Vitalik Buterin sobre "los problemas de la Fiscalía y las retiradas resistentes a la censura"?

Título original: “Corrección de los comentarios laxos de Vitalik Buterin sobre cuestiones de DA y retiros resistentes a la censura”

Autor original: Fausto

Fuente original: Geek Web3

El 16 de enero de 2024, en un tuit iniciado por DanielWang, fundador del proyecto de capa 2 de Ethereum Taiko, e interactuando con Zeng Jiajun, fundador de AA Wallet Soul Wallet, Vitalik dijo: "La clave de Rollup es la seguridad incondicional: incluso si todo el mundo te ataca, puedes retirar tus activos. Esto no se puede hacer si DA se basa en sistemas externos (fuera de Ethereum). 」**

Cápsula de escape: “Retirada segura sin condiciones” de Viatlik

Desde que Vitalik habló sobre sus puntos de vista sobre Validium en la segunda mitad de este tweet (Validium se refiere a ZK Layer 2 que no usa Ethereum para implementar la publicación de datos de DA), ha recibido mucha atención (anteriormente se rumoreaba que la Fundación Ethereum cree que Layer 2 = Rollup).

(Cabe destacar que el concepto de DA del que habla la comunidad de Ethereum se refiere a si se puede acceder a los datos recién generados de la Capa 2, no a si se pueden recuperar datos históricos de hace mucho tiempo). **Si no se publican nuevos datos en la cadena Ethereum, es posible que el nodo de capa 2 no pueda resolver el último bloque L2 sin problemas)

Sin embargo, la “Controversia de la definición de la capa 2 de Ethereum” y la “Guerra DA” han sido escuchadas durante mucho tiempo por innumerables personas, y este artículo no va a entrar en ninguna discusión de tales temas, sino a centrar más energía en la primera mitad del discurso de Vitalik, que es la que se trata al principio de este artículo.

Vitalik muestra aquí que los rollups pueden permitir retiros resistentes a la censura sin confianza, lo que le permite retirar sus activos incluso si todos los nodos de capa 2 no cooperan con su capa 2 y, señala, solo los rollups pueden lograr tales “retiros incondicionales y seguros”, que no pueden hacer los de capa 2 que dependen de otros métodos de publicación de datos de DA. **

Pero en realidad, las palabras de Vitalik no son rigurosas. **

En primer lugar, solo los activos que se puentean a la capa 2 pueden volver a cruzar a la cadena ETH, y los activos nativos puros de capa 2 no pueden cruzar a la capa 1 (a menos que el activo nativo de capa 2 implemente un contrato de activo puente en la capa 1).

Si, como dijo Vitalik, “todo el mundo te está apuntando”, puedes retirar los activos del puente L1-L2 como máximo, pero no puedes retirar tu propio “token nativo de capa 2”, en este momento, ya sea que tomes un retiro ordinario, un retiro forzado o Escape Hatch, es inútil.

En segundo lugar, los “retiros seguros sin condiciones” no tienen que depender del sistema DA. ** Soluciones tempranas de Capa 2 antes de Rollup, Plasma que implementa la publicación de datos DA bajo la cadena Ethereum y fallas del sistema DA (es decir, se produce la retención de datos y nadie más que el secuenciador/comité puede recibir nuevos datos de transacciones/información de transición de estado), también permite a los usuarios enviar pruebas de activos a través de datos históricos y escapar de forma segura de la Capa 2.

En otras palabras, los retiros seguros de Plasma no dependen del sistema DA, y los retiros resistentes a la censura no tienen que depender del sistema DA (sino garantizar que los datos históricos estén disponibles); además, esta declaración fue hecha por Dankrad (el proponente de Danksharding) de la Fundación Ethereum, y también es axiomática en todas partes.

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

En segundo lugar, dejando a un lado Celestia y Blobstream, el problema de retención de datos/falla de DA se puede resolver incluso si ETH no se utiliza como capa de DA. Hablemos del “desafío de disponibilidad de datos” en el que están trabajando el equipo de Arbitrum y el equipo de Redstone, lo que permite que el secuenciador publique solo un compromiso de DA (en realidad datahash) en la cadena, indicando que los datos se han publicado fuera de la cadena. Si alguien no puede obtener los datos recién generados fuera de la cadena, puede impugnar el compromiso de DA en la cadena y pedirle al secuenciador que divulgue los datos en la cadena.

El diseño de este mecanismo es muy simple, y no necesita depender de DA de terceros como Celestia, Avail o EigenDA, sino que solo necesita que la parte del proyecto de Capa 2 configure su propio nodo DAC fuera de la cadena, que puede llamarse el asesino de Celestia. **

A continuación, el autor tiene la intención de interpretar los “retiros seguros incondicionales” de Vitalik y los “desafíos de disponibilidad de datos” que no mencionó, tratando de decirte: ¿Por qué los proyectos de DA de terceros como Celestia y Avail y EigenDA no son necesarios para la cadena de DA fuera de la cadena y la capa 2 que busca seguridad?

Además, en nuestro artículo anterior sobre los “Indicadores de evaluación de riesgos de la capa 2 de Bitcoin”, hablamos sobre el hecho de que los retiros resistentes a la censura son más básicos y críticos que los sistemas DA, y el artículo de hoy explicará con más detalle este punto. **

En realidad, las palabras de Vitalik no son difíciles de deducir, ** está hablando de la cápsula de escape del ZK Rollup. ** La cápsula de escape, también conocida como Escape Hatch, es un modo de retirada que se activa directamente en la capa 1. Una vez que se activa este modo, el contrato Rollup entrará en un estado congelado, rechazará los nuevos datos enviados por Sequencer y permitirá que cualquier persona muestre Merkle Proof para demostrar su saldo de activos en la Capa 2 y transferir sus activos desde la dirección oficial de depósito puente de la Capa 2. **

Además, el modo de cápsula de escape ** es un “mecanismo de retiro sin confianza” que puede ser activado manualmente por las partes en la Capa 1 después de que la transacción del usuario haya sido rechazada por el secuenciador de la Capa 2 durante mucho tiempo. **

Sin embargo, antes de activar el modo de cápsula de escape, los usuarios que son rechazados por el secuenciador deben llamar a la función de retiro forzado en el contrato Rollup en la Capa 1 para iniciar una solicitud de retiro forzado y lanzar un evento para que el Nodo de Capa 2 sepa que alguien ha iniciado una solicitud de retiro forzado.

Dado que el nodo de capa 2 ejecutará el cliente geth de Ethereum y recibirá EthereumBlock, podrá escuchar la activación de eventos de retiro forzado

Si la solicitud de retiro forzado se ignora durante mucho tiempo, el usuario puede activar activamente el modo de cápsula de escape (el período de espera predeterminado es de 15 días para el protocolo Loopring y de 7 días para la solución StarkEx). A continuación, como se ha comentado al principio de este artículo, los usuarios envían la prueba de Merkle correspondiente a sus activos, demuestran el estado de sus activos en la capa 2 y, a continuación, retiran los activos del contrato relacionado con el Rollup.

Pero para construir la prueba de Merkle, primero debe conocer el estado completo de L2 y debe encontrar un nodo completo de L2 para solicitar datos. Si ocurre el tipo de situación extrema de la que habla Vitalik y no hay un nodo de capa 2 que coopere con usted, puede iniciar un nodo completo de capa 2 usted mismo, obtener los datos históricos publicados por el secuenciador L2 en Ethereum a través de la red Ethereum y sincronizar uno por uno desde el bloque Genesis de capa 2 hasta que se calcule el estado final, y se construya la prueba de Merkle, y pueda retirar dinero de manera segura a través de la cápsula de escape.

**Obviamente, la “resistencia a la censura” en este momento es equivalente a la propia Ethereum/Capa 1. **Siempre que exista un nodo EthereumFull que le proporcione datos históricos de hace mucho tiempo, está cerca de Trustless.

**Sin embargo, después de EIP-4844, el Nodo EthereumFull perderá automáticamente parte de los datos históricos, de modo que los datos históricos de la Capa 2 de más de 18 días ya no estarán respaldados por la red del Nodo ETH, y la resistencia a la censura de los retiros de la cabina de escape ya no estará tan cerca de Trustless como lo es hoy. **

Después de 4844, necesitamos confiar en un número relativamente limitado de EthereumNode que almacenan todos los datos históricos, dispuestos a proporcionarle datos (los nodos nativos de capa 2 suelen ser muy pequeños, así que no los considere por el momento). En ese momento, la suposición de confianza de que los datos históricos de la capa 1 son recuperables / retiros de pods de escape de capa 2 cambiará de sin confianza o 0 hoy a 1/N, es decir, suponiendo que 1 de los N nodos puede proporcionarle datos. **

El equipo de EthStorage parece estar comprometido a escalar esta N, incentivando a más nodos a almacenar datos históricos de hace mucho tiempo. Si el denominador de 1/N es lo suficientemente grande, la fracción sigue estando cerca de 0, lo que está cerca de no introducir la hipótesis de confianza. Esta puede ser una solución apropiada al problema de la recuperación de datos históricos posteriores a 4844.

Relación de la cápsula de escape con DA: el ataque de rescate de Validium

Aquí resumimos de nuevo: **La cápsula de escape es un retiro que le permite demostrar su estado de activo de Capa 2 a través de retiros Merkle Proof y Trustless en Capa 1. **

La razón por la que Vitalik mencionó que la seguridad de los activos involucrados en los retiros debe tener DA como premisa, principalmente significa que el esquema de validium no puede ser retirado debido a "ataques de retención de datos. (Solo se publica stateroot, no los datos de transacción correspondientes).

El principio específico es que el secuenciador puede retener los datos de la transacción, solo liberar una raíz de Merkle (Stateroot) a la cadena Ethereum y luego lograr que el nuevo Stateroot pase la verificación y se convierta en el Stateroot legítimo actual a través de la prueba de validez.

En este momento, no conoce el estado completo correspondiente a la raíz del estado legítima y no puede construir la prueba de Merkle correspondiente para iniciar la retirada del pod de escape. No puede retirarse hasta que el secuenciador esté dispuesto a entregarle los datos, que es a lo que uno de los líderes técnicos de Arbitrum se refiere como un “problema de rescate” (personalmente prefiero llamarlo un ataque de rescate). **

Sin embargo, la razón por la que la validez fuera de la cadena de DA es propensa a los “ataques de ransomware” es que el diseño de su propio mecanismo no es perfecto, y si se introduce un mecanismo de desafío relacionado con el comportamiento de retiro, o se introduce un desafío de disponibilidad de datos, el problema del ataque de ransomware teóricamente se puede resolver.

Por cierto, como se mencionó anteriormente, Plasma, que permite a los usuarios retirar a través de datos históricos de hace mucho tiempo, no tendrá un “ataque de ransomware” como validiums, y Plasma también es DA off-chain (fuera de la cadena DA+ verificación on-chain 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/cápsulas de escape resistentes a la censura no tienen que depender de 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 tiene una mentalidad preconcebida en su mente basada en soluciones existentes como Validium y Smart Contract Rollup.

Pero esto no significa que todos los DA offchain Layer 2 del mundo se enfrenten a los mismos problemas que los validiums, y no significa que los Smart Contract Rollups sean el final de todo, y que la innovación pueda ocurrir en cualquier momento (como los desafíos de disponibilidad de datos que se mencionan más adelante).

** Por el contrario, si su solución de Capa 2 no tiene en cuenta el diseño de las cápsulas de escape y los retiros resistentes a la censura desde el principio, su Capa 2 definitivamente no será lo suficientemente confiable / segura. En otras palabras, un buen sistema de DA y certificación es una condición suficiente para una retirada resistente a la censura, pero no necesaria.

Así que en nuestro artículo anterior, mencionamos que en el efecto barril de la capa 2, los retiros resistentes a la censura son una deficiencia más básica que los sistemas de DA y prueba, y hay una razón.

Referencia: “Desmantelamiento de los modelos de seguridad e indicadores de riesgo de capa 2 de Bitcoin / Ethereum con la teoría de barriles”

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

Después de hablar de la relación entre la cápsula de escape y el DA, volvamos al propio DA: la capa 2 no tiene que publicar datos de DA en Ethereum para evitar que el secuenciador se dedique a la “retención de datos”.

Redstone, Arbitrum, Metis y otros están trabajando en un mecanismo de “desafío de disponibilidad de datos” que permite a los secuenciadores publicar solo DA Commitment (datahash) + Stateroot en la cadena, declarando 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 impugnar el Compromiso de DA en la cadena y pedirle al secuenciador que divulgue los datos en la cadena. **

Si el secuenciador se cuestiona y no publica datos en la cadena de ETH de manera oportuna, su datahash/compromiso publicado anteriormente se considerará no válido y la raíz de estado asociada también será inválida. Obviamente, esto resuelve directamente el problema de retención de datos (solo se publica stateroot, no los datos de transacción correspondientes). **

Obviamente, este es un “desafío de disponibilidad de datos” más que 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 con Celestia y Avail, EigenDA, etc. Configure su propio DAC para presentar desafíos de disponibilidad de datos y ya no confíe en Celestia.

Sin embargo, a la inversa, los desafíos de disponibilidad de datos también tienen problemas económicos que deben abordarse. En una batalla con el líder técnico de Arbitrum, el fundador de ZkSync señaló que los desafíos de disponibilidad de datos son teóricamente susceptibles a los ataques de Dos. Por ejemplo, el secuenciador publica rápidamente miles de compromisos de DA en la cadena y, a continuación, retiene los datos completos correspondientes y no los publica. De esta manera, puede drenar los fondos de todos los retadores y luego publicar un bloqueo no válido para robar los activos de los usuarios.

Por supuesto, esta suposición es demasiado extrema, es esencialmente un problema de teoría de juegos tanto para el lado ofensivo como para el defensivo y, de hecho, es más probable que el secuenciador sea atacado por retadores maliciosos, y retrocede a un rollup después de ser desafiado continuamente. El juego entre el atacante y el defensor en torno al desafío de disponibilidad de datos es realmente muy interesante, y el diseño mecánico correspondiente pondrá a prueba por completo la sabiduría de Arbitrum y Redstone, así como el equipo del proyecto Metis (este tema se puede escribir por separado).

De cualquier manera, el desafío de la disponibilidad de datos traerá más innovación al diseño DA de la capa 2, lo que también marcará una gran diferencia en el ecosistema de la capa 2 de Bitcoin.

Enlace al artículo original