¿Cómo mejorará PeerDAS la disponibilidad de datos en Ethereum?

Para garantizar una gestión eficiente de los datos y una validación segura, Ethereum evolucionó de DA a DAS, e introdujo finalmente PeerDAS.

Escrito por: 0XNATALIE

En la reciente reunión de desarrolladores de Ethereum, se discutió la propuesta de dividir el hard fork Pectra de Ethereum en dos partes. Esta propuesta había sido rechazada anteriormente porque se temía que retrasaría la actualización de los árboles Verkle. Sin embargo, en esta reunión, los desarrolladores volvieron a plantear la idea porque desean incluir más propuestas de mejora (EIP) en el fork de Pectra. La propuesta consiste en dividir el hard fork en dos partes: la primera incluiría todos los EIP actualmente en Pectra Devnet 3, y la segunda incluiría EOF (EVM Object Format) y PeerDAS, entre otros. Para comprender mejor PeerDAS, primero debemos partir del concepto básico de disponibilidad de datos.

DA: Garantizar que los nodos accedan a los datos en la cadena

La disponibilidad de datos (Data Availability, DA) se refiere a garantizar que los bloques propuestos por los validadores, así como todos los datos de transacciones incluidos en esos bloques, sean accesibles y recuperables eficazmente por otros participantes de la red. La disponibilidad de datos es un factor clave para la seguridad de la blockchain, ya que si los datos no están disponibles, incluso si el bloque es válido, otros nodos no pueden verificar su contenido, lo que podría causar problemas de consenso y ataques a la red. Por ejemplo, un atacante podría publicar solo una parte de los datos del bloque, impidiendo que otros nodos puedan verificarlo.

Cuando se transmite un nuevo bloque, todos los nodos participantes descargan y verifican los datos del bloque. Este modelo es viable cuando la red es pequeña, pero a medida que la blockchain crece, la cantidad de datos se vuelve enorme y el almacenamiento requerido por cada nodo aumenta, elevando también los requisitos de hardware. Para permitir que nodos ligeros (como dispositivos móviles o computadoras personales) participen en la validación de bloques, la blockchain introdujo la tecnología de sharding.

El sharding consiste en dividir toda la red blockchain en varias "shards" o fragmentos más pequeños. Cada shard solo procesa su propia parte de los datos y no necesita manejar toda la información de la blockchain. Así, un nodo individual solo necesita procesar los datos de su shard. Pero como cada shard solo maneja una parte de los datos, los nodos de otros shards no pueden acceder directamente a la información completa. ¿Cómo se garantiza entonces que los datos dentro de un shard están disponibles y que otros nodos pueden verificar su validez? Por ejemplo, un nodo de un shard podría publicar un bloque recién generado, pero tal vez solo publique una parte de los datos. Si otros nodos no pueden obtener todos los datos del bloque, no podrán verificar si ese bloque es realmente legítimo.

DAS: Verificar la disponibilidad de datos globales mediante muestreo parcial

Para abordar el problema de la disponibilidad de datos en los shards, se propuso la técnica de Data Availability Sampling (DAS), cuyo concepto central es verificar la disponibilidad de los datos de un bloque mediante muestreo, sin requerir que cada nodo almacene o descargue todos los datos completos del bloque.

El muestreo de disponibilidad de datos permite que los nodos solo necesiten obtener aleatoriamente una parte de los datos del bloque para verificar su disponibilidad. Si el nodo puede obtener y verificar con éxito estos fragmentos aleatorios, se puede inferir que los datos completos del bloque están disponibles.

Para soportar este tipo de verificación por muestreo, los datos del bloque suelen codificarse con RS encoding. Esta codificación permite recuperar los datos completos incluso si se pierde parte de la información. Por lo tanto, aunque un nodo solo descargue una parte de los datos del bloque, puede inferir y confirmar la validez de todo el bloque. DAS reduce la cantidad de datos que cada nodo debe procesar, permitiendo que los nodos ligeros también participen en la validación de bloques.

La capa DA, como la de Celestia, utiliza estas tecnologías. Principalmente involucra RS encoding + validity proof + DAS.

• RS encoding (Reed-Solomon Encoding): Este método de codificación permite que los nodos que solo reciben una parte de los fragmentos de datos puedan reconstruir el bloque completo. Es similar a un código de corrección de errores, con cierta tolerancia a fallos; incluso si se pierde parte de los datos, el resto es suficiente para reconstruir la información completa.
• Validity Proof (Prueba de validez): Utiliza pruebas de conocimiento cero para garantizar que no haya errores durante la codificación y transmisión de los datos. Si la verificación es exitosa, se puede decodificar correctamente todo el bloque de datos.
• DAS (Data Availability Sampling): Los nodos ligeros muestrean aleatoriamente una parte de los fragmentos codificados con RS en el bloque, verifican la disponibilidad de estos fragmentos y, de este modo, infieren que todo el bloque de datos está disponible.

PeerDAS: Verificación colaborativa de datos entre nodos

PeerDAS es una implementación concreta de DAS que utiliza una red peer-to-peer para el muestreo de disponibilidad de datos. Una red peer-to-peer está compuesta por múltiples nodos que se comunican directamente entre sí. Bajo DAS, cada nodo realiza de forma independiente el muestreo y la verificación de los datos, mientras que PeerDAS optimiza este proceso permitiendo que los nodos colaboren para compartir y verificar los datos de los bloques, mejorando aún más la eficiencia de la verificación. Los nodos no están aislados, pueden compartir tareas y resultados de verificación de datos, y pueden confiar en los datos ya verificados por otros nodos. Así, los nodos no tienen que asumir toda la carga de verificación por sí solos, sino que distribuyen las tareas de verificación mediante la cooperación, reduciendo aún más la carga de cada nodo. Además, la verificación colaborativa dificulta la manipulación de datos, ya que un atacante necesitaría comprometer simultáneamente a varios nodos de verificación para alterar los datos con éxito.

Actualmente, según la última reunión de Ethereum sobre PeerDAS, el equipo de Lighthouse, cliente de Ethereum, ya ha fusionado la rama DAS en la rama principal y está realizando pruebas para garantizar la compatibilidad con PeerDAS. Las ramas suelen utilizarse para desarrollar y probar nuevas funciones o mejoras en versiones independientes del código; fusionarlas en la rama principal significa que la función o mejora ya está desarrollada y se considera lo suficientemente estable como para integrarse en el código central.