• Título original reenviado: Interpretación errónea de la disponibilidad de datos: DA = divulgación de datos ≠ recuperación de datos históricos

Introducción

¿Qué es exactamente la disponibilidad de datos? Para la mayoría de las personas, la primera impresión podría ser "acceder a datos históricos de un momento determinado", pero en realidad se trata de un gran malentendido del concepto de DA. Recientemente, los cofundadores de L2BEAT y los defensores de Danksharding, junto con el fundador de Celestia, han aclarado este concepto erróneo. Señalaron que la disponibilidad de datos (DA) en realidad debería referirse a la "publicación de datos", pero la mayoría de la gente ha interpretado la DA como "capacidad de recuperación de datos históricos", que en realidad implica problemas de almacenamiento de datos.

Por ejemplo, hace un tiempo, Dankrad mencionó el mecanismo obligatorio de retirada/escotilla de escape de la Capa 2, señalando que la retirada obligatoria de Validium requiere obtener el último estado L2 para construir una prueba de Merkle, mientras que Plasma sólo necesita los datos de 7 días anteriores (esto se relaciona con sus métodos para determinar una raíz de estado legítima).

Con esto, Dankrad señaló claramente que Validium requiere que DA garantice la seguridad de los fondos de los usuarios, pero Plasma no lo hace. Aquí, el caso de uso de Dankrad señala la diferencia entre DA y la recuperación de datos históricos, que es que DA a menudo solo involucra datos recién publicados.

En L2BEAT, se ha enfatizado aún más la distinción entre disponibilidad de datos (DA) y almacenamiento de datos (DS). Bartek, de L2BEAT, ha subrayado en repetidas ocasiones que el DA y el almacenamiento de datos/recuperabilidad de datos históricos son dos cosas diferentes, y que los usuarios pueden acceder a los datos de L2 que necesitan sólo porque los nodos que proporcionan datos son "lo suficientemente amables con usted". Además, L2BEAT planea usar "si hay nodos de almacenamiento de datos con permisos disponibles" como una nueva métrica para evaluar los Rollups, más allá de DA.

Las declaraciones de la comunidad Ethereum/miembros de la Fundación Ethereum muestran su intención de aclarar y refinar los conceptos relacionados con la Capa 2 en el futuro, así como de proporcionar una definición más detallada de la propia Capa 2. Esto se debe a que muchos términos relacionados con Rollup y L2 no se han explicado claramente, como la antigüedad en que los datos se consideran "históricos": algunos creen que, dado que los contratos inteligentes solo pueden llamar a datos de los últimos 256 bloques, los datos de antes de 256 bloques (50 minutos) se consideran "históricos".

Sin embargo, el "Rollup" mencionado por Celestia y la Fundación Ethereum se refiere estrictamente a dos cosas diferentes. Este artículo tiene como objetivo aclarar la diferencia entre el concepto de DA y el almacenamiento de datos, desde la fuente de DA, el muestreo de disponibilidad de datos, hasta los métodos de implementación de DA en Rollups, explicando lo que realmente significa la disponibilidad de datos: publicación de datos.

El origen del concepto de DA

El concepto de DA se origina a partir de la cuestión de la "disponibilidad de datos", que el fundador de Celestia, Mustafa, explica de la siguiente manera: DA se trata de cómo garantizar que todos los datos de un bloque se publiquen en la red cuando un productor de bloques propone un nuevo bloque. Si el productor del bloque no libera todos los datos del bloque, es imposible comprobar si el bloque contiene transacciones erróneas.

Mustafa también señala que los Ethereum Rollups simplemente publican datos de bloques L2 en la cadena Ethereum y confían en ETH para garantizar la disponibilidad de los datos. En el sitio web oficial de Ethereum, el problema de disponibilidad de datos se resume en la pregunta: "¿Cómo verificamos si los datos de un nuevo bloque están disponibles?" Para los clientes ligeros, el problema de la disponibilidad de datos se refiere a la verificación de la disponibilidad de un bloque sin necesidad de descargar todo el bloque.

El sitio web oficial de Ethereum también distingue claramente entre disponibilidad de datos y recuperabilidad de datos: la disponibilidad de datos se refiere a la capacidad de los nodos para descargar datos de bloques cuando se propone, en otras palabras, está relacionada con el tiempo antes de que un bloque alcance el consenso. La capacidad de recuperación de datos se refiere a la capacidad de los nodos para recuperar información histórica de la cadena de bloques. Aunque el archivado puede requerir datos históricos de blockchain, los nodos no necesitan usar datos históricos para verificar bloques y procesar transacciones.

En opinión del colaborador chino de Celestia y socio de W3Hitchhiker, Ren Hongyi, Layer 2 asume de antemano que Ethereum es lo suficientemente seguro y descentralizado. Los clasificadores pueden enviar con confianza datos de DA a Ethereum, y estos datos se propagarán sin obstrucciones a todos los nodos completos de Ethereum. Dado que los nodos completos de L2 ejecutan el cliente Geth, se consideran un subconjunto de los nodos completos de Ethereum y, por lo tanto, pueden recibir los datos DA de la capa 2.

A los ojos del Dr. Qi Zhou, fundador de EthStorage, la definición de disponibilidad de datos (DA) es que nadie puede retener los datos de las transacciones enviadas por los usuarios a la red. El modelo de confianza correspondiente es que solo necesitamos confiar en el protocolo de la Capa 1 (L1) en sí, sin necesidad de introducir otros supuestos de confianza.

Qi Zhou señala que la implementación actual de DA en Ethereum es esencialmente una transmisión P2P (utilizando el protocolo de chismes), donde cada nodo completo descarga, propaga nuevos bloques y almacena datos de Rollup. Sin embargo, los nodos completos de Ethereum no almacenarán bloques históricos para siempre. Después de la implementación de EIP-4844, es posible que eliminen automáticamente los datos de un tiempo determinado (aparentemente 18 días). No hay muchos nodos de archivo que almacenen todos los datos históricos en todo el mundo. EthStorage planea llenar este vacío en el ecosistema de Ethereum y ayudar a Layer 2 a establecer sus nodos dedicados de permanencia de datos.

Las primeras discusiones sobre la disponibilidad de datos por parte de la Fundación Ethereum se pueden ver en los tweets de Vitalik Buterin y en los documentos de GitHub en 2017. En ese momento, creía que para asegurar la escalabilidad y eficiencia de la cadena de bloques, era necesario aumentar la configuración de hardware de los nodos completos (los nodos completos son los que descargan el bloque completo y verifican su validez, y los Validadores, que participan en consenso, son un subconjunto de los nodos completos). Sin embargo, el aumento de los requisitos de hardware para los nodos completos también aumentaría los costos operativos, lo que llevaría a la centralización de la cadena de bloques.

En este sentido, Vitalik sugirió diseñar un esquema para abordar los riesgos de seguridad provocados por la tendencia a la centralización de los nodos completos de alto rendimiento. Planeaba introducir códigos de borrado y muestreo aleatorio de datos para diseñar un protocolo que permitiera a los nodos ligeros con menores capacidades de hardware verificar que un bloque está libre de problemas sin conocer el bloque completo.

Su idea inicial estaba relacionada con una idea mencionada en el documento técnico de Bitcoin, que establece que los nodos ligeros no necesitan recibir el bloque completo, sino que serán alertados por nodos completos honestos si hay un problema con el bloque. Este concepto podría extenderse a pruebas de fraude posteriores, pero no garantiza que los nodos completos honestos siempre puedan obtener datos suficientes, ni puede juzgar a posteriori si el proponente del bloque retuvo algunos datos para que no se publicaran.

Por ejemplo, un nodo A podría publicar una prueba de fraude afirmando que recibió un bloque incompleto del nodo B. Sin embargo, es imposible determinar si el bloque incompleto fue fabricado por A o enviado por B. Vitalik señaló que este problema podría resolverse mediante el muestreo de disponibilidad de datos (DAS), que obviamente involucra problemas de publicación de datos.

Vitalik discutió brevemente estos problemas y sus soluciones en su artículo "Una nota sobre la disponibilidad de datos y la codificación de borrado". Señaló que las pruebas de DA (disponibilidad de datos) son esencialmente un "complemento" de las pruebas de fraude.

Muestreo de disponibilidad de datos

Sin embargo, el concepto de DA no es tan fácil de explicar, como lo demuestra el documento de GitHub de Vitalik que ha sufrido 18 correcciones, la última de las cuales se presentó el 25 de septiembre de 2018. Justo el día anterior, el 24 de septiembre de 2018, el fundador de Celestia, Mustafa, y Vitalik fueron coautores del famoso artículo "Pruebas de fraude y disponibilidad de datos: maximización de la seguridad de los clientes ligeros y escalado de cadenas de bloques con mayorías deshonestas".

Curiosamente, Mustafa figura como el primer autor del artículo, no Vitalik (otro autor es ahora investigador en la cadena de bloques pública Sui). El documento menciona el concepto de Fraud Proofs y explica el principio de Data Availability Sampling (DAS), diseñando a grandes rasgos un protocolo mixto de DAS + codificación de borrado bidimensional + pruebas de fraude. El documento menciona específicamente que el sistema de prueba de DA es un complemento necesario a las pruebas de fraude.

Desde la perspectiva de Vitalik, el protocolo funciona de la siguiente manera:

Supongamos que una cadena de bloques pública tiene N nodos de consenso (validadores) con hardware de alta capacidad, lo que permite un alto rendimiento y eficiencia de datos. Aunque una cadena de bloques de este tipo puede tener un alto TPS (transacciones por segundo), el número de nodos de consenso, N, es relativamente pequeño, lo que la hace más centralizada con una mayor probabilidad de colusión entre los nodos.

Sin embargo, se supone que al menos uno de los N nodos de consenso es honesto. Siempre que al menos 1/N de los validadores sean honestos, capaces de detectar y transmitir pruebas de fraude cuando un bloque no es válido, los clientes ligeros o los validadores honestos pueden darse cuenta de los problemas de seguridad en la red y pueden utilizar mecanismos como la reducción de nodos maliciosos y bifurcaciones de consenso social para recuperar la red a la normalidad.

Como Vitalik mencionó antes, si un nodo completo honesto recibe un bloque y encuentra que le faltan algunas partes, y publica una prueba de fraude, es difícil determinar si el proponente del bloque no publicó esa parte, fue retenida por otros nodos durante la transmisión, o si es una bandera falsa del nodo que publica la prueba de fraude. Además, si la mayoría de los nodos conspiran, el validador honesto 1/N podría quedar aislado, incapaz de recibir nuevos bloques, lo cual es un escenario de ataque de retención de datos. En tales casos, el nodo honesto no puede determinar si se debe a las malas condiciones de la red o a una conspiración deliberada de retención por parte de otros, ni puede saber si otros nodos también están aislados, lo que dificulta juzgar si una mayoría ha conspirado en la retención de datos.

Por lo tanto, debe haber una forma de garantizar, con una probabilidad muy alta, que los validadores honestos puedan obtener los datos necesarios para validar los bloques; e identificar quién está detrás de un ataque de retención de datos, ya sea el proponente del bloque que no publicó suficientes datos, que fue retenido por otros nodos o si se trata de una conspiración mayoritaria. Claramente, este modelo de seguridad ofrece mucha más protección que la "suposición de la mayoría honesta" común en las cadenas PoS típicas, y el muestreo de disponibilidad de datos (DAS) es el método de implementación específico.

Suponiendo que hay muchos nodos de luz en la red, posiblemente 10 veces N, cada uno conectado a múltiples validadores (para simplificar, suponga que cada nodo de luz está conectado a todos los N validadores). Estos nodos ligeros realizarían múltiples muestreos de datos de los validadores, cada vez solicitando aleatoriamente una pequeña porción de datos (supongamos que es solo el 1% de un bloque). Luego, esparcirían los fragmentos adquiridos a los validadores que carecían de estos datos. Siempre que haya suficientes nodos ligeros y la frecuencia de muestreo de datos sea lo suficientemente alta, incluso si se deniegan algunas solicitudes, siempre que se responda a la mayoría, se puede garantizar que todos los validadores puedan eventualmente adquirir la cantidad necesaria de datos para validar un bloque. Esto puede anular el impacto de la retención de datos por parte de nodos distintos del proponente de bloques.

(Fuente de la imagen: W3 Hitchhiker)

Si la mayoría de los validadores conspiran y se niegan a responder a la mayoría de las solicitudes de los nodos ligeros, sería fácil que la gente se diera cuenta de que hay un problema con la cadena (porque incluso si algunas personas tienen una mala conexión a Internet, no daría lugar a que la mayoría de las solicitudes de los nodos ligeros fueran denegadas). Por lo tanto, es muy probable que el esquema mencionado anteriormente pueda determinar el comportamiento de la conspiración mayoritaria, aunque tales situaciones son raras en sí mismas. Con este enfoque, se pueden resolver las incertidumbres de fuentes distintas al proponente del bloque. Si el proponente de bloque retiene datos, por ejemplo, no publica suficientes datos en el bloque para validarlo (después de introducir la codificación de borrado bidimensional, un bloque contiene fragmentos de 2k2k, y la restauración de los datos originales del bloque requiere al menos unos fragmentos de kk, o 1/4. Para evitar que otros restauren los datos originales, el proponente tendría que retener al menos k + 1 * k + 1 fragmentos), eventualmente serán detectados por Validadores honestos, que luego transmitirán pruebas de fraude para advertir a otros.

Según Vitalik y Mustafa, lo que hicieron fue esencialmente combinar ideas que ya habían sido propuestas por otros y agregar sus propias innovaciones. Al observar el concepto y el método de implementación en su conjunto, está claro que la "disponibilidad de datos" se refiere a si los datos necesarios para verificar el último bloque han sido publicados por el proponente de bloques y si pueden ser recibidos por los verificadores. Se trata de si los datos están "completamente publicados" en lugar de si "se pueden recuperar datos históricos".

Cómo se implementa la disponibilidad de datos (DA) de Ethereum Rollup

Con la afirmación anterior, veamos cómo se implementa la disponibilidad de datos (DA) en los Rollups de Ethereum, lo que queda bastante claro: El proponente de bloques en un Rollup se conoce como Secuenciador, que publica los datos necesarios para verificar las transiciones de estado de la Capa 2 en Ethereum a intervalos. Específicamente, inicia una transacción a un contrato designado, rellenando los datos relacionados con DA en los parámetros de entrada personalizados, que luego se registran en un bloque de Ethereum. Dado el alto grado de descentralización de Ethereum, se puede estar seguro de que los datos enviados por el secuenciador serán recibidos sin problemas por los "verificadores". Sin embargo, las entidades que desempeñan el papel de "verificadores" difieren entre las distintas redes Rollup.

Por ejemplo, en el caso de Arbitrum, el secuenciador publica lotes de transacciones en un determinado contrato en Ethereum. El contrato en sí no verifica estos datos, pero emite un evento para que los nodos completos de L2 lo escuchen, haciéndoles saber que el secuenciador ha publicado un lote de transacciones. En concreto, los ZK Rollups utilizan un contrato de verificador en Ethereum como "verificador". Un ZK Rollup solo necesita publicar una Diferencia de Estado + Prueba de validez, es decir, información sobre los cambios de estado más una prueba de validez. El contrato del verificador comprueba la prueba de validez para ver si coincide con la diferencia de estado. Si se supera la validación, el bloque/lote L2 publicado por el secuenciador se considera válido.

(Fuente: Antiguo libro blanco de Polygon Hermez)

Los Optimistic Rollups requieren la publicación de más datos en Ethereum porque se basan únicamente en nodos completos L2 para descargar datos y verificar la validez de los bloques. Esto significa que, como mínimo, se deben divulgar las firmas digitales de cada transacción L2 (que ahora se utilizan comúnmente firmas agregadas). Si se realizan llamadas de contrato, también se deben divulgar los parámetros de entrada, además de las direcciones de transferencia de transacciones, los valores nonce para evitar ataques de reproducción, etc. Sin embargo, en comparación con los datos completos de transacciones, todavía hay algunos recortes.

En comparación con los ZK Rollups, el costo de DA (disponibilidad de datos) de los Optimistic Rollups es mayor porque los ZK Rollups solo necesitan revelar los cambios de estado final después de que se ejecute un lote de transacciones, acompañado de una prueba de validez, aprovechando la concisión de ZK SNARK/STARK; mientras que los Optimistic Rollups solo pueden usar el método más engorroso, lo que requiere que todas las transacciones sean reejecutadas por otros nodos completos de L2.

Anteriormente, W3hitchhiker estimó aproximadamente que, sin tener en cuenta los desarrollos futuros de EIP-4844 y blobs, el efecto de escalado de ZKR (Zero-Knowledge Rollups) podría alcanzar varias veces el de OPR (Optimistic Rollups). Si se consideran las billeteras inteligentes relacionadas con EIP-4337 (que usan huellas dactilares, datos de iris en lugar de firmas de clave privada), la ventaja de ZKR sería aún más evidente, porque no necesita publicar los datos binarios de huellas dactilares, iris en Ethereum, mientras que Optimistic Rollups sí lo hace.

En cuanto a Validium y Plasma/Optimium, en realidad utilizan la capa DA fuera de la cadena de Ethereum para lograr DA. Por ejemplo, ImmutableX, que adoptó un sistema de prueba de validez, ha establecido un conjunto de nodos DAC (Comité de Disponibilidad de Datos) específicamente para publicar datos relacionados con DA; Metis publica datos de DA en Memlabs, y Rooch y Manta usan Celestia. Actualmente, debido a la existencia de DAS (Soluciones de Disponibilidad de Datos) y sistemas a prueba de fraude, Celestia es uno de los proyectos de capa DA más confiables fuera de Ethereum.

Renuncia:

1. Este artículo es una reimpresión de [Geek Web3]. Reenviar el título original:Malentendidos sobre la disponibilidad de datos: DA = Publicación de datos ≠ recuperación de datos históricos, Todos los derechos de autor pertenecen al autor original [ Fausto, Geek web3]. 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 son realizadas por el equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.