Disponibilidad de datos

"No confíes, verifica" es una máxima común en Ethereum. La idea es que su nodo puede verificar de forma independiente que la información que recibe es correcta al ejecutar todas las transacciones en los bloques que recibe de sus pares para garantizar que los cambios propuestos coincidan exactamente con los calculados de forma 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 faltan datos.

La disponibilidad de datos se refiere a la confianza que un usuario puede tener de que los datos requeridos para verificar un bloque están realmente disponibles para todos los participantes de la red. Para los nodos completos en la capa 1 (l1) de Ethereum esto es relativamente simple; el nodo completo descarga una copia de todos los datos en cada bloque: los datos tienen que 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 "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, para las cadenas de bloques modulares, los rollups de capa 2 (l2) y los clientes ligeros, el panorama de la disponibilidad de datos es más complejo, lo que requiere algunos procedimientos de verificación más sofisticados.

Requisitos previos

Debería 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 los bloques, las transacciones, los nodos, las soluciones de escalado 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 transacciones que se están agregando a la cadena de bloques realmente representa un conjunto de transacciones válidas, pero haciéndolo sin requerir que todos los nodos descarguen todos los datos. Los datos completos de las transacciones son necesarios para verificar los bloques de forma independiente, pero requerir que todos los nodos descarguen todos los datos de las transacciones es una barrera para el escalado. Las soluciones al problema de la disponibilidad de datos tienen como objetivo proporcionar garantías suficientes de que los datos completos de las transacciones se pusieron a disposición para su verificación a los participantes de la red que no descargan ni almacenan los datos por sí mismos.

Los nodos ligeros y los rollups de capa 2 (l2) son ejemplos importantes de participantes de la red que requieren fuertes garantías de disponibilidad de datos pero no pueden descargar y procesar los datos de las transacciones por sí mismos. Evitar la descarga de datos de transacciones es lo que hace que los nodos ligeros sean ligeros y permite que los rollups sean soluciones de escalado efectivas.

La disponibilidad de datos también es una preocupación crítica para los futuros clientes de Ethereum "sin estado" que no necesitan descargar y almacenar datos de estado para verificar los bloques. Los clientes sin estado aún necesitan estar seguros de que los datos están disponibles en algún lugar y que se han procesado correctamente.

Soluciones de disponibilidad de datos

Muestreo de disponibilidad de datos (DAS)

El muestreo de disponibilidad de datos (DAS) es una forma en 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 hacen staking) descarga un pequeño subconjunto seleccionado al azar del total de los datos. La descarga exitosa de las muestras confirma con gran confianza que todos los datos están disponibles. Esto se basa en la codificación de borrado de datos, que expande un conjunto de datos dado con información redundante (la forma en que se hace esto es ajustar una función conocida como polinomio sobre los datos y evaluar ese polinomio en puntos adicionales). Esto permite que los datos originales se recuperen 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, ¡faltará la mitad de los datos expandidos! La cantidad de muestras de datos descargadas por cada nodo se puede ajustar para que sea extremadamente probable que falte al menos uno de los fragmentos de datos muestreados por cada cliente si menos de la mitad de los datos están realmente disponibles.

DAS se utilizará para garantizar que los operadores de rollups pongan a disposición sus datos de transacciones después de que se haya implementado el danksharding completo. Los nodos de Ethereum muestrearán aleatoriamente los datos de transacciones proporcionados en blobs utilizando el esquema de redundancia explicado anteriormente para garantizar que todos los datos existan. La misma técnica también podría emplearse para garantizar que los productores de bloques pongan a disposición todos sus datos para asegurar a los clientes ligeros. De manera similar, bajo la separación proponente-constructor (PBS), solo se requeriría que el constructor de bloques procese un bloque completo; otros validadores verificarían utilizando el muestreo de disponibilidad de datos.

Comités de disponibilidad de datos

Los comités de disponibilidad de datos (DAC) son partes de confianza que proporcionan o dan fe de la disponibilidad de datos. Los DAC se pueden usar en lugar de, o en combinación con (opens in a new tab) DAS. Las garantías de seguridad que vienen con los comités dependen de la configuración específica. Ethereum utiliza subconjuntos de validadores muestreados aleatoriamente para dar fe de la disponibilidad de datos para los nodos ligeros, por ejemplo.

Los DAC también son utilizados por algunos validiums. El DAC es un conjunto de nodos de confianza que almacena copias de datos fuera de línea. Se requiere que el DAC ponga los datos a disposición en caso de una disputa. Los miembros del DAC también publican atestaciones en cadena para demostrar que dichos datos están efectivamente disponibles. Algunos validiums reemplazan los DAC con un sistema de validadores de prueba de participación (PoS). Aquí, cualquiera puede convertirse en un validador y almacenar datos fuera de la cadena. Sin embargo, deben proporcionar una "fianza", que se deposita en un contrato inteligente. En caso de comportamiento malicioso, como que el validador retenga datos, la fianza puede sufrir un recorte. Los comités de disponibilidad de datos de 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 la corrección de los encabezados del bloque que reciben sin descargar los datos del bloque. El costo de esta ligereza es la incapacidad de verificar de forma independiente los encabezados del bloque al volver a ejecutar las transacciones localmente de la forma en que lo hacen los nodos completos.

Los nodos ligeros de Ethereum confían en conjuntos aleatorios de 512 validadores que han sido asignados a un comité de sincronización. El comité de sincronización actúa como un DAC que señala a los clientes ligeros que los datos en el encabezado son correctos utilizando una firma criptográfica. Todos los días, el comité de sincronización se actualiza. Cada encabezado del bloque alerta a los nodos ligeros sobre qué validadores esperar que firmen el siguiente bloque, por lo que no pueden ser engañados para confiar en un grupo malicioso que finge ser el verdadero comité de sincronización.

Sin embargo, ¿qué sucede si un atacante de alguna manera logra pasar un encabezado del bloque malicioso a los clientes ligeros y convencerlos de que fue firmado por un comité de sincronización honesto? En ese caso, el atacante podría incluir transacciones inválidas y el cliente ligero las aceptaría a ciegas, ya que no verifican de forma independiente todos los cambios de estado resumidos en el encabezado del bloque. Para protegerse contra esto, el cliente ligero podría usar pruebas de fraude.

La forma en que funcionan estas pruebas de fraude es que un nodo completo, al ver una transición de estado inválida que se difunde por la red, podría generar rápidamente un pequeño fragmento de datos que demuestre que una transición de estado propuesta no podría surgir de un conjunto dado de transacciones y transmitir esos datos a sus pares. Los nodos ligeros podrían recoger esas pruebas de fraude y usarlas para descartar encabezados de bloque incorrectos, asegurando que permanezcan en la misma cadena honesta que los nodos completos.

Esto depende de que los nodos completos tengan acceso a los datos completos de las transacciones. Un atacante que transmite un encabezado de bloque incorrecto y que además no pone a disposición los datos de las transacciones podría evitar que los nodos completos generen pruebas de fraude. Los nodos completos podrían señalar una advertencia sobre un bloque incorrecto, pero no podrían respaldar su advertencia con pruebas, ¡porque los datos no se pusieron a disposición para generar la prueba!

La solución a este problema de disponibilidad de datos es DAS. Los nodos ligeros descargan fragmentos aleatorios muy pequeños de los datos de estado completos y usan las muestras para verificar que el conjunto de datos completo esté disponible. La probabilidad real de asumir incorrectamente la disponibilidad completa de datos después de descargar N fragmentos aleatorios se puede calcular (para 100 fragmentos la probabilidad es de 10^-30 (opens in a new tab), es decir, increíblemente improbable).

Incluso en este escenario, los ataques que retienen solo unos pocos bytes podrían pasar desapercibidos para los clientes que realizan solicitudes de datos aleatorias. La codificación de borrado soluciona esto al reconstruir pequeñas piezas de datos faltantes que se pueden usar para verificar los cambios de estado propuestos. Luego se podría construir una prueba de fraude utilizando los datos reconstruidos, evitando que los nodos ligeros acepten encabezados incorrectos.

Nota: DAS y las pruebas de fraude aún no se han implementado para los clientes ligeros de Ethereum de prueba de participación (PoS), pero están en la hoja de ruta, muy probablemente tomando la forma de pruebas basadas en ZK-SNARK. Los clientes ligeros de hoy en día dependen de una forma de DAC: verifican las identidades del comité de sincronización y luego confían en los encabezados del bloque firmados que reciben.

Disponibilidad de datos y rollups de capa 2

Las soluciones de escalado de capa 2 (l2), como los , reducen los costos de transacción y aumentan la capacidad de procesamiento de Ethereum al procesar transacciones fuera de la cadena. Las transacciones de los rollups se comprimen y se publican en Ethereum en lotes. Los lotes representan miles de transacciones individuales fuera de la cadena en una sola transacción en Ethereum. Esto reduce la congestión en la capa base y reduce las tarifas para los usuarios.

Sin embargo, solo es posible confiar en las transacciones de "resumen" publicadas en Ethereum si el cambio de estado propuesto se puede verificar de forma independiente y confirmar que es el resultado de aplicar todas las transacciones individuales fuera de la cadena. Si los operadores de rollups no ponen a disposición los datos de las transacciones para esta verificación, entonces podrían enviar datos incorrectos a Ethereum.

Los rollups optimistas publican datos de transacciones comprimidos en Ethereum y esperan una cierta cantidad de tiempo (generalmente 7 días) para permitir que los verificadores independientes revisen los datos. Si alguien identifica un problema, puede generar una prueba de fraude y usarla para desafiar al rollup. Esto haría que la cadena retrocediera y omitiera el bloque inválido. Esto solo es posible si los datos están disponibles. Actualmente, hay dos formas en que los rollups optimistas publican datos de transacciones en la capa 1 (l1). Algunos rollups hacen que los datos estén disponibles permanentemente como CALLDATA que vive permanentemente en cadena. Con la implementación de EIP-4844, algunos rollups publican sus datos de transacciones en un almacenamiento de blobs más económico en su lugar. Este no es un almacenamiento permanente. Los verificadores independientes tienen que consultar los blobs y presentar sus desafíos dentro de ~18 días antes de que los datos se eliminen de la capa 1 (l1) de Ethereum. La disponibilidad de datos solo está garantizada por el protocolo de Ethereum durante esa breve ventana fija. Después de eso, se convierte en responsabilidad de otras entidades en el ecosistema de Ethereum. Cualquier nodo puede verificar la disponibilidad de datos utilizando DAS, es decir, descargando muestras pequeñas y aleatorias de los datos del blob.

Los rollups de conocimiento cero (ZK) no necesitan publicar datos de transacciones ya que las garantizan la corrección de las transiciones de estado. Sin embargo, la disponibilidad de datos sigue siendo un problema porque no podemos garantizar la funcionalidad del rollup ZK (o interactuar con él) sin acceso a sus datos de estado. Por ejemplo, los usuarios no pueden conocer sus saldos si un operador retiene detalles sobre el estado del rollup. Además, no pueden realizar actualizaciones de estado utilizando la información contenida en un bloque recién agregado.

Disponibilidad de datos frente a recuperabilidad de datos

La disponibilidad de datos es diferente de la recuperabilidad 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 se deduce necesariamente 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 se requieren para la sincronización de nodos completos desde el bloque génesis o para atender solicitudes históricas específicas.

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