Disponibilidad de datos

"No confíe, verifique" es un principio común en Ethereum. La idea es que su nodo pueda verificar de manera independiente que la información que recibe es correcta ejecutando todas las transacciones en los bloques que recibe de sus pares para asegurarse de que los cambios propuestos coincidan exactamente con los calculados de manera independiente por el nodo. Esto significa que los nodos no tienen que confiar en que los remitentes del bloque sean honestos. Esto no es posible si falta información.

La disponibilidad de datos se refiere a la confianza que un usuario puede tener en que los datos necesarios para verificar un bloque estén realmente disponibles para todos los participantes de la red. Para los nodos completos en la capa 1 de Ethereum, esto es relativamente simple; el nodo completo descarga una copia de todos los datos en cada bloque: los datos deben estar disponibles para que la descarga sea posible. Un bloque con datos faltantes sería descartado en lugar de ser agregado a la cadena de bloques. Esto es la "disponibilidad de datos en cadena" y es una característica de las cadenas de bloques monolíticas. Los nodos completos no pueden ser engañados para aceptar transacciones inválidas porque descargan y ejecutan cada transacción por sí mismos. Sin embargo, en el caso de las cadenas de bloques modulares, los rollups de capa 2 y los clientes ligeros, el panorama de la disponibilidad de datos es más complejo, lo cual requiere de procedimientos de verificación más sofisticados.

Prerrequisitos

Debe tener una buena comprensión de los fundamentos de la cadena de bloques, especialmente de los mecanismos de consenso. Esta página también asume que el lector está familiarizado con bloques, transacciones, nodos, soluciones de escalabilidad y otros temas relevantes.

El problema de la disponibilidad de datos

El problema de la disponibilidad de datos es la necesidad de demostrar a toda la red que la forma resumida de algunos datos de transacción que se están agregando a la cadena de bloques realmente representa un conjunto de transacciones válidas, pero hacerlo sin requerir que todos los nodos descarguen todos los datos. Todos los datos de transacción son necesarios para verificar de manera independiente los bloques, pero requerir que todos los nodos descarguen todos los datos de transacción es un obstáculo para el escalamiento. Las soluciones al problema de disponibilidad de datos buscan proporcionar garantías suficientes de que todos los datos de transacción estuvieron disponibles para que los participantes de la red que no descargan y almacenan los datos los pudieran verificar.

Los nodos ligeros y los rollups de capa 2 son ejemplos importantes de participantes en la red que requieren garantías sólidas de disponibilidad de datos, pero que no pueden descargar y procesar los datos de transacción por sí mismos. Evitar la descarga de datos de transacción es lo que hace que los nodos ligeros sean ligeros y permite que las rollups sean soluciones efectivas de escalamiento.

La disponibilidad de datos también es una preocupación fundamental para futuros clientes "sin estado" (stateless) de Ethereum que no necesiten descargar ni almacenar datos de estado para verificar bloques. Los clientes sin estado aún necesitan estar seguros de que los datos estén disponibles en algún lugar y que han sido procesados correctamente.

Soluciones de disponibilidad de datos

Muestreo de disponibilidad de datos (DAS)

El muestreo de disponibilidad de datos (DAS) es una forma en la que la red verifica que los datos están disponibles sin ejercer demasiada presión sobre ningún nodo individual. Cada nodo (incluidos los nodos que no realizan staking) descarga un pequeño subconjunto seleccionado al azar de los datos totales. La descarga exitosa de las muestras confirma con alto grado de confianza que todos los datos están disponibles. Esto se basa en la codificación de borrado de datos, que expande un conjunto dado de datos con información redundante (la forma en que se hace esto es ajustando una función conocida como un polinomio sobre los datos y evaluando ese polinomio en puntos adicionales). Esto permite que los datos originales se recuperen a partir de los datos redundantes cuando sea necesario. Una consecuencia de esta creación de datos es que, si cualquiera de los datos originales no está disponible, la mitad de los datos expandidos terminará faltando. La cantidad de muestras de datos descargadas por cada nodo puede ajustarse de manera que sea extremadamente probable que al menos uno de los fragmentos de datos muestreados por cada cliente falte si menos de la mitad de los datos está realmente disponible.

El DAS se va a utilizar para garantizar que los operadores de rollups pongan a disposición sus datos de transacciones luego de que se haya implementado EIP-4844. Los nodos de Ethereum van a tomar muestras aleatorias de los datos de transacción proporcionados en blobs utilizando el esquema de redundancia explicado anteriormente para asegurarse de que existan todos los datos. La misma técnica también podría emplearse para estar seguros de que los productores de bloques estén poniendo a disposición todos sus datos, garantizando así la seguridad de los clientes ligeros. De manera similar, bajo la separación entre constructor/generador de bloques y proponente, solo el generador de bloques estaría obligado a procesar un bloque completo, mientras que otros validadores harían la verificación utilizando el muestreo de disponibilidad de datos.

Comités de disponibilidad de datos

Los Comités de Disponibilidad de Datos (DAC) son entidades de confianza que proporcionan o certifican la disponibilidad de datos. Los DAC pueden ser utilizados en lugar del Muestreo de Disponibilidad de Datos o en combinación con él(opens in a new tab) . Las garantías de seguridad que vienen con los comités dependen de la configuración específica. Ethereum utiliza subconjuntos de validadores seleccionados al azar para dar fe de la disponibilidad de datos para nodos ligeros, por ejemplo.

Algunos validiums también utilizan DAC. El DAC es un conjunto de nodos confiables que almacenan copias de datos sin conexión. El DAC está obligado a poner los datos a disposición en caso de disputa. Los miembros del DAC también publican atestaciones o certificaciones en la cadena para demostrar que los datos mencionados están efectivamente disponibles. Algunos validiums reemplazan los DAC con un sistema de validadores de prueba de participación (PoS). Aquí, cualquier persona puede convertirse en un validador y almacenar datos fuera de la cadena. Sin embargo, deben proporcionar una "garantía o fianza", que se deposita en un contrato inteligente. En caso de comportamiento malicioso, como que el validador retenga los datos, la garantía puede acuchillarse (cortarse). Los comités de disponibilidad de datos basados en la prueba de participación son considerablemente más seguros que los DAC regulares porque incentivan directamente el comportamiento honesto.

Disponibilidad de datos y nodos ligeros

Los nodos ligeros necesitan validar que los encabezados de los bloques que reciben son correctos sin descargar los datos de dichos bloques. El precio de ser tan ligeros es la incapacidad de verificar de forma independiente los encabezados de los bloques mediante la reejecución de transacciones de manera local, como lo hacen los nodos completos.

Los nodos ligeros de Ethereum confían en conjuntos aleatorios de 512 validadores que fueron asignados a un comité de sincronización. El comité de sincronización funciona como un DAC, el cual señala a los clientes ligeros que los datos en el encabezado son correctos mediante una firma criptográfica. El comité de sincronización se renueva diariamente. El encabezado de cada bloque informa a los nodos ligeros cuáles son los validadores que tienen que esperar que autoricen el próximo bloque, de tal manera que no sean engañados y terminen confiando en un grupo malicioso que se haga pasar por el auténtico comité de sincronización.

Sin embargo, ¿qué es lo que sucede si un atacante de alguna u otra manera logra hacer pasar el encabezado de un bloque malicioso a los clientes ligeros y los convence de que fue autorizado por un comité de sincronización honesto? En ese escenario, el atacante podría incluir transacciones no válidas y el cliente ligero las aceptaría ciegamente, ya que no verifican independientemente todos los cambios de estado resumidos en el encabezado del bloque. Para protegerse de esto, el cliente ligero puede utilizar pruebas de fraude.

La forma en que estas pruebas de fraude funcionan es que un nodo completo, al detectar que una transición de estado inválida se difunde por la red, podría generar rápidamente un pequeño conjunto de datos para demostrar que una transición de estado propuesta es imposible que surja de un conjunto dado de transacciones y transmitir esos datos a sus pares. Los nodos ligeros podrían recoger dichas pruebas de fraude y utilizarlas para descartar encabezados de bloques incorrectos, asegurándose de que permanezcan en la misma cadena honesta que los nodos completos.

Esto depende de nodos completos que tengan acceso a los datos completos de las transacciones. Un atacante que propague el encabezado incorrecto de un bloque y sumado a eso no ponga a disposición los datos de transacciones podría evitar que los nodos completos generen pruebas de fraude. Los nodos completos podrían emitir una advertencia sobre un bloque incorrecto, pero no podrían respaldar su advertencia con pruebas, ya que los datos no estaban disponibles para generarlas.

La solución a este problema de disponibilidad de datos es el muestreo de disponibilidad de datos (DAS). Los nodos ligeros descargan fragmentos muy pequeños y aleatorios de los datos de estado completo y utilizan estas muestras para verificar que el conjunto de datos completo esté disponible. La probabilidad real de asumir equivocadamente que los datos completos están disponibles luego de descargar N fragmentos aleatorios se puede calcular: por ejemplo, para 100 fragmentos, la probabilidad es de 10^-30(opens in a new tab), es decir que es extremadamente improbable.

Incluso en este escenario, ataques que retengan solo unos pocos bytes podrían pasar desapercibidos fácilmente para aquellos clientes que realizan solicitudes de datos aleatorios. La solución se alcanza mediante la codificación de borrado, que reconstruye pequeñas partes de datos faltantes para luego utilizarlas para verificar las modificaciones de estado propuestas. Posteriormente se puede construir una prueba de fraude utilizando los datos reconstruidos, evitando que los nodos ligeros acepten encabezados incorrectos.

Nota: El DAS y las pruebas de fraude aún no se implementaron en los clientes ligeros de Ethereum en prueba de participación, pero están contemplados dentro del plan de desarrollo, probablemente en forma de pruebas basadas en ZK-SNARK. Actualmente los clientes ligeros usan una forma de DAC: verifican las identidades del comité de sincronización y luego confían en los encabezados de bloque firmados que reciben.

Disponibilidad de datos y rollups de capa 2

Las soluciones de escalabilidad de capa 2, como los

Sin embargo, solo es posible confiar en las transacciones de "resumen" publicadas en Ethereum si el cambio de estado propuesto puede ser verificado de manera independiente y confirmado como resultado de aplicar todas las transacciones individuales fuera de la cadena. Si los operadores de los rollup no ponen a disposición los datos de transacción para esta verificación, podrían estar enviando datos incorrectos a Ethereum.

Los rollups optimistas publican datos de transacciones de manera comprimida en Ethereum y esperan cierto tiempo (normalmente 7 días) para permitir que verificadores independientes comprueben los datos. Si alguno identifica un problema, puede generar una prueba de fraude y utilizarla para impugnar al rollup. La consecuencia sería una reversión en la cadena y la omisión del bloque inválido. Esto solo es posible si los datos están disponibles. Actualmente, los datos se ponen a disposición permanentemente como CALLDATA, que residen permanentemente en la cadena. Sin embargo, EIP-4844 pronto va a permitir que los rollups publiquen sus datos de transacción en un almacenamiento de tipo blob más económico. Esto no sería un almacenamiento permanente. Los verificadores independientes van a tener que consultar los blobs y presentar sus impugnaciones en el lapso de 1-3 meses antes de que los datos sean eliminados de la capa 1 de Ethereum. La disponibilidad de datos solamente va a estar garantizada por el protocolo de Ethereum durante ese corto período de tiempo. Luego de ese lapso, la responsabilidad va a recaer en otras entidades del ecosistema de Ethereum. Cualquier nodo puede verificar la disponibilidad de datos utilizando DAS, es decir, descargando pequeñas muestras aleatorias de los datos de los blobs.

Los rollups de conocimiento cero (ZK) no necesitan publicar los datos de la transacción, ya que las

Disponibilidad de datos frente a capacidad de recuperación de datos

La disponibilidad de datos es diferente de la capacidad de recuperación de datos. La disponibilidad de datos es la garantía de que los nodos completos han podido acceder y verificar el conjunto completo de transacciones asociadas con un bloque específico. No es necesario que los datos sean accesibles para siempre.

La recuperabilidad de datos es la capacidad de los nodos para recuperar información histórica de la cadena de bloques. Estos datos históricos no son necesarios para verificar nuevos bloques, solo son necesarios para sincronizar nodos completos del bloque inicial o para servir solicitudes históricas específicas.

El protocolo principal de Ethereum se ocupa principalmente de la disponibilidad de datos, no de su capacidad de recuperación. La capacidad de recuperación de datos puede ser proporcionada por una pequeña población de nodos de archivo ejecutados por terceros, o puede distribuirse a través de la red utilizando el almacenamiento de archivos descentralizado, como la Portal Network(opens in a new tab).

Más información

• ¿Qué es la disponibilidad de datos?(opens in a new tab)
• ¿Qué es la disponibilidad de datos?(opens in a new tab)
• El panorama de disponibilidad de datos fuera de la cadena de Ethereum(opens in a new tab)
• Manual básico sobre las comprobaciones de disponibilidad de datos(opens in a new tab)
• Explicación de la propuesta de fragmentación + DAS(opens in a new tab)
• Nota sobre la disponibilidad de datos y la codificación de borrado(opens in a new tab)
• Comités de disponibilidad de datos(opens in a new tab)
• Comités de disponibilidad de datos de prueba de participación(opens in a new tab)
• Soluciones al problema de la capacidad de recuperación de datos(opens in a new tab)