Malentendido sobre la disponibilidad de datos: DA = publicación de datos ≠ recuperación de datos históricos

Introducción: ¿Qué es exactamente la disponibilidad de datos? ** Quizás la primera impresión de la mayoría de la gente es que "se pueden obtener datos históricos en un momento determinado", pero este es en realidad el mayor malentendido del concepto de DA. **Recientemente, L2BEAT Lianchuang, el proponente de Danksharding y el fundador de Celestia han aclarado este malentendido y señalaron que Disponibilidad de datos en realidad debería referirse a "liberación de datos", pero la mayoría de la gente entiende DA como "datos históricos". se puede recuperar", y este último en realidad implica problemas de almacenamiento de datos.

Por ejemplo, Dankrad mencionó hace un tiempo el mecanismo de retirada forzada/escotilla de escape de la Capa 2. Señaló que la retirada forzada de Validium necesita obtener el último estado L2 para construir Merkle Proof, pero Plasma solo necesita el último estado L2 de hace 7 días (esto es diferente de los dos. Está relacionado con el método para determinar el Stateroot legal del usuario).

Con esto, Dankrad señaló claramente que Validium requiere DA para garantizar la seguridad de los fondos de los usuarios, pero Plasma no. Aquí, el caso de uso de Dankrad señala la diferencia entre DA y la recuperación de datos históricos, es decir, que DA tiende a involucrar solo datos recientemente publicados. **

En L2BEAT, la diferencia entre disponibilidad de datos DA y almacenamiento de datos DS se fortalece aún más. Bartek de L2BEAT ha enfatizado repetidamente que DA y el almacenamiento de datos/datos históricos son dos cosas diferentes, y los usuarios pueden obtener los datos L2 que necesitan solo porque los nodos que proporcionan los datos son "lo suficientemente buenos para usted". Además, L2BEAT también planea utilizar "si hay nodos de almacenamiento de datos con permisos abiertos" como un nuevo indicador para evaluar Rollup además de DA.

Los comentarios anteriores de los miembros de la comunidad Ethereum/Fundación Ethereum indican que estandarizarán los conceptos relacionados con la Capa 2 en el futuro y proporcionarán una definición más detallada de la Capa 2 en sí. Debido a que muchos términos relacionados con Rollup y L2 en realidad no están bien explicados, como por ejemplo, cuánto tiempo hace que los datos se consideran "datos históricos", algunas personas piensan que debido a que los contratos inteligentes solo pueden llamar a datos de bloques anteriores dentro de 256 bloques, por lo tanto, los datos 256 bloques ( 50 minutos) se consideran "datos históricos".

Estrictamente hablando, el "Rollup" mencionado por Celestia y la Fundación Ethereum son 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 y la implementación de DA de Rollup, le explicaremos qué es la disponibilidad de datos: liberación de datos. **

Fuente del concepto DA

Con respecto a lo que se refiere al problema de la "disponibilidad de datos", **el fundador de Celestia, Mustafa, explicó esto: **DA es, cuando el generador de bloques propone un nuevo bloque, ¿cómo garantizar que todos los datos del bloque se liberen a la red? Si el generador de bloques no publica todos los datos del bloque, no puede detectar si el bloque contiene transacciones incorrectas.

Mustafa también señaló que Ethereum Rollup simplemente publica datos del bloque L2 en la cadena Ethereum y depende de ETH para garantizar la disponibilidad de los datos.

**En el sitio web oficial de Ethereum, hay el siguiente resumen sobre DA: **El problema de disponibilidad de datos se puede resumir en una pregunta: "¿Cómo verificamos si los datos de un nuevo bloque están disponibles?"... Para mayor claridad clientes En general, el problema de disponibilidad de datos se refiere a verificar la disponibilidad de un bloque sin descargar el bloque completo.

**El sitio web oficial de Ethereum también distingue claramente la diferencia entre disponibilidad y recuperación de datos: **La disponibilidad de datos se refiere a la capacidad del nodo para descargar datos de bloque cuando se propone un bloque. En otras palabras, la disponibilidad de datos es relevante cuando un bloque aún no ha alcanzado un consenso... La recuperación de datos se refiere a la capacidad de un nodo para recuperar información histórica de la cadena de bloques... aunque el archivado puede requerir una cadena de bloques Datos históricos, pero los nodos pueden validar bloques y procesar transacciones sin utilizar datos históricos.

**En opinión de Ren Hongyi, colaborador de Celestia China y socio de W3Hitchhiker, **Layer2 asume de antemano que Ethereum es lo suficientemente seguro y descentralizado, y que el secuenciador puede enviar datos DA de forma segura y audaz a Ethereum, y estos datos se difundirán sin obstáculos. A todos los nodos completos de Ethereum. El nodo completo L2 debe ejecutar el cliente Geth, que es un subconjunto del nodo completo Ethereum, para que pueda recibir datos DA de Capa 2.

**A los ojos del Dr. Qi Zhou, fundador de EthStorage, la definición de 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 L1 en sí y no necesitamos introducir otros supuestos de confianza.

** Qi Zhou señaló que el método de implementación DA actual de Ethereum es en realidad transmisión P2P ** (protocolo de chismes): cada nodo completo descargará y propagará nuevos bloques y almacenará datos acumulativos. Por supuesto, los nodos completos de Ethereum no almacenarán permanentemente bloques históricos y pueden eliminar automáticamente datos de un período de tiempo (parece ser 18 días) después de que 4844 se conecte. **No hay muchos nodos de archivo en el mundo que almacenen todos los datos históricos. **EthStorage tiene la intención de llenar este vacío en el sistema Ethereum y ayudar a la Capa 2 a configurar su propio nodo exclusivo de persistencia de datos.

Las primeras discusiones de la Fundación Ethereum sobre la disponibilidad de datos se pueden encontrar en los tweets y documentos de github de Vitalik en 2017. En ese momento, creía que si queremos garantizar la escalabilidad/alta eficiencia de la cadena de bloques, necesitamos mejorar la configuración de hardware del nodo completo (un nodo completo es un nodo que descarga un bloque completo y verifica su validez, y el Validador que genera consenso es un subconjunto del nodo completo). Sin embargo, si se mejora la configuración de hardware del nodo completo, el costo operativo aumentará, lo que hará que la cadena de bloques se centralice.

Respecto a este punto,** Vitalik dijo que se puede diseñar una solución para resolver los riesgos de seguridad causados por la centralización de nodos completos de alto rendimiento. ** Planea introducir codificación de borrado y muestreo aleatorio de datos para diseñar un protocolo para que los nodos ligeros con hardware de gama baja puedan saber que no hay ningún problema con el bloque incluso si no conocen el bloque completo.

Su pensamiento inicial en realidad estaba relacionado con la idea mencionada en el documento técnico de Bitcoin. Esta idea dice que los nodos ligeros no necesitan recibir el bloque completo, y cuando hay un problema con el bloque, el nodo completo honesto emitirá una "alarma" para notificar al nodo ligero. Esta idea se puede extender a pruebas de fraude posteriores, pero no hay garantía de que los nodos completos honestos siempre puedan obtener suficientes datos, ni se puede juzgar posteriormente si el proponente del bloque ha retenido ciertos datos y no los ha revelado.

Por ejemplo, un determinado nodo A puede emitir un certificado de fraude afirmando haber recibido un bloque incompleto del nodo B. Pero en este momento, es imposible juzgar si este bloque incompleto fue falsificado por el propio A o enviado por B. Vitalik señaló que este problema se puede resolver con el muestreo de disponibilidad de datos DAS (obviamente, la disponibilidad de datos implica esencialmente problemas de publicación de datos).

Vitalik ofrece una discusión superficial de estos problemas y sus soluciones en "Una nota sobre la disponibilidad de datos y la codificación de borrado". **Señaló que el certificado DA es esencialmente una "completación" del certificado de fraude. **

Muestreo de disponibilidad de datos

Pero, obviamente, el concepto de DA no es tan fácil de explicar, porque el documento github de Vitalik se ha corregido 18 veces. Los registros muestran que la última corrección se presentó el 25 de septiembre de 2018. Justo el día anterior, el 24 de septiembre de 2018, Los fundadores de Celestia, Mustafa y Vitalik, publicaron conjuntamente un artículo que se haría famoso en el futuro——Pruebas de fraude y disponibilidad de datos: Maximizar la seguridad del cliente ligero y escalar las cadenas de bloques con mayorías deshonestas

Curiosamente, el primer autor de este artículo es Mustafa en lugar de Vitalik (el otro autor es ahora investigador de Sui Public Chain). El artículo menciona el concepto de prueba de fraude, explica el principio de muestreo de disponibilidad de datos DAS y diseña a grandes rasgos un protocolo combinado de DAS + codificación de borrado bidimensional + prueba de fraude. **El documento menciona claramente que el sistema de prueba DA es esencialmente un complemento necesario a la prueba de fraude. **

Si partimos de la perspectiva de Vitalik, el papel de este protocolo se puede resumir de la siguiente manera:

Supongamos que una cadena pública tiene N validadores de nodos de consenso con hardware de alta gama, su rendimiento de datos es grande y su eficiencia es muy alta. Aunque una cadena de bloques de este tipo tiene un TPS alto, el número de nodos de consenso N es relativamente pequeño, está relativamente centralizado y la probabilidad de colusión de nodos es alta.

Sin embargo, al menos uno de los N nodos de consenso será honesto. **Siempre que al menos 1/N Validadores sean honestos, **verifiquen que el bloqueo no sea válido y estén dispuestos a transmitir pruebas de fraude cuando sea necesario, los nodos ligeros o los Validadores honestos pueden saber que hay un problema de seguridad en la red. , y puede usar Slash nodos maliciosos y consenso social para usar Forks y otros métodos para restaurar la red a la normalidad.

Sin embargo, como Vitalik mencionó antes, si un nodo completo honesto recibe un bloque y descubre que le faltan ciertas partes y publica un certificado de fraude, es difícil determinar si el proponente del bloque no publicó esta parte de los datos o fue bloqueado. A mitad de camino, otros nodos lo retuvieron o el nodo que emitió el certificado de fraude actuó por iniciativa propia.

Además, si la mayoría de los nodos se confabulan, 1/N validadores honestos quedarán aislados y es posible que no puedan obtener nuevos bloques, lo que se considera un escenario de ataque de retención de datos. Cabe señalar que en este momento, el nodo honesto no sabe si la condición de la red es mala o si otras personas han conspirado para retener datos, ni si otros nodos también están aislados, y es difícil juzgar si el nodo honesto también está aislado. La mayoría de las personas han conspirado para ocultar datos.

En resumen, debe haber una manera de garantizar que el Validador honesto pueda obtener los datos necesarios para verificar el bloque con una probabilidad muy alta; al mismo tiempo, debe ser posible determinar quién está participando en ataques de retención de datos** - es el proponente del bloque el que no ha publicado. Si hay suficientes datos, todavía se dice que otros nodos los retienen o que la mayoría de los nodos están en connivencia. Obviamente, este modelo de seguridad tiene muchas más garantías que la "suposición mayoritaria honesta" de las cadenas POS ordinarias, y el muestreo de disponibilidad de datos DAS es el método de implementación específico.

Ahora asumimos que hay muchos nodos de luz en la red, tal vez 10 N, y cada nodo de luz está conectado a múltiples Validadores** (para facilitar el análisis, se supone que cada nodo de luz está conectado a todos los N Validadores). Estos nodos ligeros lanzarán muestreos de datos al Validador varias veces, solicitando aleatoriamente una pequeña parte de los datos cada vez (suponiendo que solo represente el 1% de un bloque). Posteriormente, propagarán los fragmentos extraídos a los Validadores que no tengan estos datos. Siempre que haya suficientes nodos ligeros y el número de muestreos de datos sea lo suficientemente frecuente, incluso si algunas solicitudes pueden ser rechazadas, siempre que se responda a la mayoría de ellas, se puede garantizar que todos los Validadores eventualmente lo harán. obtener suficientes datos necesarios para verificar el bloque. Esto puede compensar el impacto de que los datos sean retenidos por nodos distintos del proponente del bloque. **

(Fuente de la imagen: W3 Hitchhiker)

Y si la mayoría de los Validadores se confabulan y se niegan a responder a las solicitudes de la mayoría de los nodos ligeros, la gente se dará cuenta fácilmente de que hay un problema con la cadena (porque incluso si la velocidad de la red de algunas personas no es buena, no será tan mala como las solicitudes). de la mayoría de los nodos ligeros) fueron rechazados). Por lo tanto, el esquema antes mencionado puede detectar la mayoría de los comportamientos colusorios con una probabilidad muy alta, aunque por supuesto esta situación en sí rara vez ocurre.

En este punto, podemos resolver las incertidumbres provenientes de fuera del proponente del bloque. **Si el proponente del bloque retiene datos, *por ejemplo, no publica suficientes datos necesarios para verificar el bloque en el bloque (después de la introducción de la codificación de borrado bidimensional, un bloque contiene 2k*2k fragmentos, y Recuperar los datos originales del bloque requiere al menos aproximadamente k*k fragmentos, lo que representa 1/4. El proponente quiere que otros no puedan restaurar los datos originales, y al menos k+1*k+1 fragmentos ser retenido), *Eventualmente será detectado por un validador honesto, quien transmitirá pruebas de fraude para advertir a otros *****ers. **

Según vitalik y mustafa, en realidad combinaron ideas que se habían propuesto antes e hicieron ciertas innovaciones sobre ellas. Desde la perspectiva del punto de partida y la implementación de todo el concepto, es obvio que la llamada "disponibilidad de datos" se refiere a si los datos necesarios para verificar el último bloque han sido publicados por el proponente del bloque y pueden ser verificados por el verificador Recibimos. **Se trata de "si los datos se publican en su totalidad" en lugar de "si se pueden recuperar los datos históricos".

Cómo implementar el DA de Ethereum Rollup

Con la conclusión anterior, veamos la implementación DA de Ethereum Rollup. En realidad, es relativamente claro: **El proponente de bloques en Rollup es el secuenciador, que emitirá verificaciones en Ethereum de vez en cuando. Datos necesarios para la transición de estado de Capa 2 . ** Para ser precisos, se trata de iniciar una transacción para el contrato especificado, insertar los datos involucrados en DA en los parámetros de entrada personalizados y finalmente registrarse en el bloque Ethereum. Dado que Ethereum está lo suficientemente descentralizado, puede estar seguro de que el "validador" recibirá con éxito los datos enviados por el secuenciador. Pero lo que desempeña el papel de "verificador" en diferentes redes Rollup es diferente.

*(El secuenciador Arbitrum publica lotes de transacciones en un contrato en Ethereum. El contrato en sí no verifica estos datos, solo genera un evento para que lo escuche el nodo completo L2, haciéndole saber a este último que el secuenciador ha liberado el lote de transacciones ) *

Específicamente, ZK Rollup utiliza el contrato Verifier en Ethereum para actuar como "verificador". ** ZKR solo necesita publicar al menos la diferencia de estado + prueba de validez, ** es decir, cambios de estado + prueba de validez. El contrato del Verificador detectará la prueba de validez para determinar si puede coincidir con la diferencia de estado. Después de pasar la verificación, el Bloque/Lote L2 emitido por el secuenciador se considera válido.

(Fuente: Informe técnico del antiguo Polygon Hermez)

El Rollup más optimista publicará más datos sobre Ethereum, porque solo puede confiar en los nodos completos L2 para descargar datos y verificar la validez del bloque. **En este caso, se debe revelar al menos la firma digital de cada transacción L2 (ahora generalmente se usan firmas agregadas), y si se llama a un contrato, se deben revelar los parámetros de entrada. Además, la dirección de transferencia de la transacción y el Se debe revelar el valor de Nonce para evitar ataques de repetición. Espere. Pero en comparación con los datos completos de transacciones, todavía hay algo de poda.

**En comparación con ZK Rollup, el costo de DA del Rollup optimista es mayor, **porque ZK Rollup solo necesita revelar los cambios de estado finales después de que se ejecuta un lote de transacciones y viene con un certificado de validez, aprovechando la simplicidad de ZK SNARK/STARK; Optimistic Rollup solo puede utilizar el método más engorroso, permitiendo que todas las transacciones se vuelvan a ejecutar en otros nodos completos L2.

W3hitchhiker ha estimado anteriormente aproximadamente que sin considerar 4844 y blobs futuros, el efecto de expansión de ZKR puede alcanzar varias veces el de OPR, y si considera 4337 billeteras inteligentes relacionadas (reemplazando firmas de claves privadas con datos de huellas dactilares e iris), ZKR Las ventajas serán más obvias, porque no necesita publicar los datos binarios de huellas dactilares e iris en Ethereum, mientras que Optimistic Rollup sí lo hace).

En cuanto a Validium y Plasma/Optimium, en realidad utilizan la capa DA bajo la cadena Ethereum para implementar DA. Por ejemplo, ImmutableX, que utiliza un sistema de prueba de validez, ha creado un conjunto de nodos DAC (Comité de Disponibilidad de Datos) para publicar datos relacionados con DA; Metis publica datos de DA en Memlabs, y Rooch y Manta usan Celestia. En la actualidad, parece que debido a la existencia de DAS y un sistema a prueba de fraude, **Celestia es uno de los proyectos de capa DA más creíbles fuera de Ethereum. **

referencias

5