Data Availability Sampling y KZG Commitments: cómo verificar sin descargar

La noche en que Ethereum casi se ahoga en sus propios datos

En diciembre de 2020, la cadena Beacon de Ethereum —la nueva columna vertebral de la red que debía sustituir al sistema de minería por uno de validación— arrancó con una promesa ambiciosa: procesar miles de transacciones por segundo sin sacrificar la descentralización. Pero a medida que la red crecía, un problema que los ingenieros habían anticipado en la pizarra se materializó con una brutalidad inesperada. Cada validador necesitaba descargar y verificar cada byte de cada bloque para estar seguro de que ningún dato había sido omitido o manipulado. Con bloques cada vez más grandes y una red que aspiraba a dar servicio a millones de usuarios, el coste de participar como validador se disparaba: más ancho de banda, más almacenamiento, más potencia de cálculo. Los nodos más modestos —ordenadores domésticos, servidores pequeños en países con conexiones lentas— empezaban a quedarse atrás. La red se enfrentaba a un dilema que los investigadores de blockchain llevan años llamando el trilema de la escalabilidad: puedes tener seguridad, descentralización o rendimiento, pero no los tres a la vez.

Al otro lado del Atlántico, en un despacho de la Universidad de Columbia, un joven investigador llamado Mustafa Al-Bassam llevaba meses trabajando en una idea que parecía casi demasiado elegante para ser verdad. ¿Y si un nodo no necesitara descargar todo el bloque para estar seguro de que los datos existen? ¿Y si bastara con pedir unas pocas muestras aleatorias —como un inspector de sanidad que no necesita probar cada plato de un restaurante, sino solo unos cuantos, elegidos al azar— para tener una confianza estadística abrumadora de que todo está en orden? La técnica se llamaría Data Availability Sampling, y junto con una herramienta matemática de los años setenta llamada codificación de borrado y un compromiso criptográfico publicado en 2010 por tres investigadores canadienses —Kate, Zaverucha y Goldberg—, cambiaría para siempre la forma en que pensamos sobre la verificación de datos en sistemas distribuidos.

En marzo de 2024, Ethereum activó la actualización conocida como Dencun, que incluía la propuesta EIP-4844, bautizada informalmente como «Proto-Danksharding» en honor a Dankrad Feist, el investigador de la Ethereum Foundation que diseñó la arquitectura completa. Por primera vez en la historia de una blockchain de esta magnitud, los datos se podían verificar sin descargarlos íntegramente, usando exactamente las técnicas que Al-Bassam había imaginado años atrás. El coste de publicar datos en Ethereum cayó hasta un 90%. Las soluciones de capa dos —Optimism, Arbitrum, Base, zkSync— que dependían de Ethereum para almacenar sus datos vieron cómo sus tarifas se desplomaban de decenas de dólares a fracciones de céntimo.

Esta es la historia de cómo un problema aparentemente imposible —verificar que datos existen sin mirarlos— se resolvió combinando matemáticas de los años cuarenta, criptografía de los años dos mil diez y una dosis considerable de ingeniería práctica. Para contarla, necesitamos empezar por el principio: ¿qué significa, exactamente, que unos datos estén «disponibles»?

El problema de la disponibilidad de datos: la pesadilla del sobre cerrado

¿Por qué no basta con confiar?

Imaginemos una situación cotidiana. Ana es notaria y le llega un sobre cerrado de un cliente que dice: «Dentro de este sobre está mi testamento, firmado y completo. Guárdalo para cuando sea necesario». Ana guarda el sobre en su archivo. Pasan los años. El cliente fallece. Los herederos acuden al despacho de Ana. Abren el sobre y descubren que está vacío. O peor: contiene solo la primera página del testamento, con las otras tres arrancadas. ¿Quién tiene la culpa? ¿El cliente mintió al entregar el sobre? ¿Alguien lo manipuló mientras estaba guardado? ¿Ana debería haber abierto el sobre para verificar su contenido en el momento de la entrega?

Este escenario captura la esencia del problema de la disponibilidad de datos en blockchain. Cuando un productor de bloques (el equivalente al cliente de Ana) propone un nuevo bloque a la red, está diciendo implícitamente: «Aquí están todas las transacciones de este bloque. Están completas, son válidas y cualquiera puede verificarlas». Pero ¿qué ocurre si el productor no publica todos los datos? ¿Qué ocurre si retiene parte de las transacciones, publicando solo el encabezado del bloque —que contiene un resumen criptográfico de los datos— pero ocultando los datos reales?

En una blockchain como Bitcoin o Ethereum clásico, cada nodo completo descarga íntegramente cada bloque. Si faltan datos, el nodo se da cuenta inmediatamente y rechaza el bloque. Es como si Ana abriera el sobre delante del cliente y contara las páginas. El problema es que este enfoque no escala. A medida que los bloques crecen —porque queremos procesar más transacciones por segundo—, el coste de descargar y verificar cada byte se vuelve prohibitivo para la mayoría de los participantes. Solo los nodos con conexiones de alta velocidad y hardware potente pueden seguir el ritmo. La red se centraliza en manos de los operadores más pudientes, que es precisamente lo que una blockchain intenta evitar.

El ataque de retención de datos

Para entender por qué este problema es realmente peligroso, consideremos un escenario concreto. Un productor de bloques malicioso crea un bloque que contiene una transacción oculta: una transferencia de un millón de euros desde una cuenta ajena hacia su propia cuenta. Publica el encabezado del bloque —que incluye la raíz de Merkle, la firma del productor y todos los metadatos habituales— pero retiene los datos de las transacciones. Los nodos ligeros, que solo verifican los encabezados, aceptan el bloque como válido porque la firma es correcta y la raíz de Merkle parece legítima. Los nodos completos, que intentan descargar las transacciones para verificarlas, no pueden obtenerlas. Saben que algo va mal, pero no pueden demostrar qué va mal. No pueden generar una prueba de fraude porque no tienen los datos sobre los que construirla.

Es como un juicio en el que el acusado destruye las pruebas. El fiscal sabe que las pruebas existían —hay testigos que las vieron— pero sin las pruebas físicas, no puede construir su caso. El acusado se esconde detrás de la ausencia de evidencia, convirtiendo su acto de destrucción en su propia coartada.

El problema de la disponibilidad de datos se reduce, en última instancia, a una pregunta desoladoramente simple: ¿cómo puedes estar seguro de que unos datos existen si no puedes descargarlos todos? Es una pregunta que parece no tener solución. Si no los has visto, ¿cómo sabes que están ahí? La respuesta, como veremos, viene de un lugar inesperado: la misma matemática que permite que los CDs de música suenen perfectos aunque estén rayados.

Códigos de borrado Reed-Solomon: la matemática que salva la música rayada

Un poco de historia: del ruido espacial a tu reproductor de CD

En 1960, dos matemáticos del MIT llamados Irving S. Reed y Gustave Solomon publicaron un artículo de apenas diez páginas titulado «Polynomial Codes over Certain Finite Fields». El problema que abordaban era eminentemente práctico: ¿cómo enviar un mensaje a través de un canal ruidoso —una transmisión de radio, un cable con interferencias, una señal espacial que recorre millones de kilómetros— de forma que el receptor pueda recuperar el mensaje original incluso si parte de la señal se pierde o se corrompe por el camino?

La idea de añadir redundancia a un mensaje no era nueva. Los marineros han utilizado durante siglos la práctica de repetir las órdenes a gritos: «¡Babor! ¡Babor! ¡BABOR!». Si el viento se lleva una de las repeticiones, las otras dos llegan. Pero la repetición es tremendamente ineficiente: para protegerse contra la pérdida de un tercio del mensaje, necesitas triplicar la cantidad de datos transmitidos. Reed y Solomon encontraron algo mucho más elegante: una forma de añadir redundancia que permite recuperar el mensaje original incluso cuando se pierde una fracción significativa de los datos, pero sin necesidad de multiplicar el volumen de información enviada.

Lo que Reed y Solomon probablemente no imaginaron es la ubicuidad que alcanzaría su invención. Cuando en 1977 la NASA lanzó las sondas Voyager 1 y Voyager 2 hacia los confines del sistema solar, las señales que enviaban de vuelta a la Tierra eran tan débiles —después de recorrer miles de millones de kilómetros— que llegaban ahogadas en ruido cósmico. Los códigos Reed-Solomon permitieron reconstruir las imágenes de Júpiter y Saturno a partir de señales que, sin corrección de errores, habrían sido indistinguibles del ruido estático. Cuando Philips y Sony desarrollaron el disco compacto en 1982, eligieron los códigos Reed-Solomon como mecanismo de protección. Es por eso que un CD rayado sigue sonando perfectamente: el sistema puede reconstruir los datos perdidos a partir de la redundancia codificada en el disco. Y cuando abrimos un código QR con el teléfono móvil, la razón por la que funciona incluso si parte del código está tapada o dañada es, de nuevo, Reed-Solomon.

La idea intuitiva: el mapa del tesoro dividido en fragmentos

Para entender cómo funciona la codificación de borrado, imaginemos una situación concreta. Tienes un mapa del tesoro que necesitas enviar a un amigo en otra ciudad. El problema es que el servicio postal es poco fiable: de cada diez cartas que envías, tres se pierden por el camino, y no sabes cuáles. La solución ingenua —enviar diez copias idénticas del mapa— funciona, pero es absurdamente cara.

Lo que hace la codificación de borrado es algo mucho más inteligente. Imagina que tu mapa del tesoro se puede describir con cuatro números: la latitud del punto de inicio (40), la longitud del punto de inicio (3), la latitud del tesoro (41) y la longitud del tesoro (4). Estos cuatro números son tus datos originales. Ahora, en lugar de repetirlos, los usas para construir una curva matemática —un polinomio— que pasa por esos cuatro puntos. Una vez que tienes la curva, puedes calcular tantos puntos adicionales como quieras. Calculas, digamos, otros cuatro puntos de la misma curva. Ahora tienes ocho puntos en total: los cuatro originales y cuatro de redundancia.

Envías los ocho puntos en ocho cartas separadas. Si tres se pierden, no importa: con cualquier combinación de cinco puntos (o incluso solo cuatro, que es el mínimo teórico) puedes reconstruir la curva completa y, a partir de ella, recuperar los cuatro datos originales. No necesitas saber cuáles cartas se perdieron. Cualquier subconjunto suficiente de puntos contiene toda la información necesaria. Es la misma propiedad matemática que vimos con Shamir’s Secret Sharing: un polinomio de grado tres queda determinado de forma única por cuatro puntos, y cualquier cuatro puntos de la curva —no importa cuáles— sirven para reconstruirlo.

Las matemáticas, paso a paso

Los datos originales se interpretan como los coeficientes de un polinomio. Si tenemos cuatro datos —digamos, los valores 7, 3, 5, 1—, construimos el polinomio de grado tres cuya expresión es 7 + 3x + 5x² + x³. Este polinomio es una curva que queda completamente determinada por sus cuatro coeficientes.

Ahora evaluamos este polinomio en ocho puntos distintos —por ejemplo, en x = 1, 2, 3, 4, 5, 6, 7 y 8—. Cada evaluación produce un valor numérico. Estos ocho valores son los datos que transmitimos o almacenamos. Son el doble de los datos originales, lo que significa una tasa de redundancia del 100%: por cada dato original, enviamos un dato adicional.

Si se pierden hasta cuatro de los ocho valores, los cuatro restantes son suficientes para reconstruir el polinomio mediante interpolación —la misma técnica de Lagrange que se usa en la compartición de secretos—. Una vez reconstruido el polinomio, recuperamos los coeficientes originales y, con ellos, nuestros datos. La belleza del método es que la redundancia es eficiente: duplicamos los datos (tasa 2x), pero podemos tolerar la pérdida de hasta la mitad. Compare esto con la repetición simple: para tolerar la pérdida de la mitad, necesitaríamos repetir cada dato muchas más veces.

En la práctica, los cálculos no se hacen con números enteros normales sino con campos finitos —sistemas numéricos que «se enrollan» al llegar a un cierto valor, como las horas en un reloj—. Esto evita que los números crezcan sin control y garantiza que cada fragmento codificado tiene exactamente el mismo tamaño que un fragmento de los datos originales. Es un detalle técnico crucial para la implementación, pero no cambia la idea fundamental.

¿Cuánta redundancia necesitamos?

La tasa de redundancia se puede ajustar según las necesidades. Si tus datos originales tienen k fragmentos y codificas un total de n fragmentos, puedes tolerar la pérdida de hasta n − k fragmentos. La relación k/n se llama tasa de código. Una tasa de 1/2 (duplicar los datos) es la más común en sistemas blockchain. Una tasa de 1/4 (cuadruplicar) ofrece más resiliencia pero a mayor coste de almacenamiento. La siguiente tabla compara distintas configuraciones:

Datos originales (k)	Datos codificados (n)	Tasa de código	Pérdida tolerable	Redundancia
4	8	1/2	Hasta 4 fragmentos	100%
4	12	1/3	Hasta 8 fragmentos	200%
4	16	1/4	Hasta 12 fragmentos	300%
128	256	1/2	Hasta 128 fragmentos	100%

La última fila es representativa de lo que ocurre en blockchains reales: los datos de un bloque se dividen en 128 fragmentos originales, se codifican hasta 256, y el sistema puede tolerar la pérdida de la mitad sin que se pierda un solo byte de información. Es esta propiedad —la capacidad de reconstruir el todo a partir de una parte— la que hace posible el muestreo de disponibilidad de datos.

Extended Data Squares: redundancia en dos dimensiones

La analogía de la cuadrícula

Imaginemos que eres profesor de un colegio y necesitas comprobar que todos los alumnos han entregado sus deberes. Tienes una clase de 16 alumnos sentados en una cuadrícula de 4×4: cuatro filas y cuatro columnas. Cada alumno tiene sus deberes sobre el pupitre. La forma directa de comprobarlo es pasar por cada pupitre, uno por uno, y verificar los 16 trabajos. Pero eso lleva mucho tiempo.

Ahora imagina que aplicas una técnica de codificación de borrado a cada fila y a cada columna por separado. Primero, extiendes cada fila de 4 pupitres a 8 pupitres, añadiendo 4 pupitres «de redundancia» a la derecha, cuyos deberes son una función matemática de los cuatro originales de esa fila. Luego, extiendes cada columna de la misma forma, añadiendo 4 pupitres de redundancia debajo. El resultado es una cuadrícula de 8×8 = 64 pupitres, donde los 16 originales están en la esquina superior izquierda y el resto son redundancia calculada.

¿Por qué hacer esto en dos dimensiones en lugar de una? Porque la bidimensionalidad permite un tipo de verificación que la codificación unidimensional no ofrece. Si un alumno de la cuadrícula original no ha entregado sus deberes (o ha entregado deberes falsos), la inconsistencia se puede detectar comprobando o bien su fila o bien su columna. No necesitas verificar toda la cuadrícula: basta con comprobar una fila o una columna completa para detectar la anomalía. Y si la anomalía está en los datos de redundancia, se puede detectar comprobando la fila o columna correspondiente.

Extended Data Squares en blockchain

En el contexto de una blockchain, los datos de un bloque se organizan en lo que se conoce como un Extended Data Square (EDS) o cuadrado de datos extendido. El proceso funciona así: se toman las transacciones del bloque y se distribuyen en una matriz cuadrada de dimensión k×k. Después, se aplica la codificación de borrado Reed-Solomon a cada fila, extendiéndola al doble de su longitud. Luego se aplica la misma codificación a cada columna. El resultado es una matriz de 2k×2k, cuatro veces más grande que la original, pero con una propiedad extraordinaria: cualquier cuadrante de la matriz —cualquier combinación de k filas y k columnas— contiene información suficiente para reconstruir los datos originales completos.

Pensemos en lo que esto significa. Si un bloque tiene, digamos, 256 kilobytes de transacciones, el EDS tiene un megabyte (4×256 KB). Pero un nodo que solo descargue la mitad de las celdas del EDS —medio megabyte, elegidas de forma adecuada— puede reconstruir el bloque entero. Y lo que es aún más poderoso: un nodo que descargue apenas unas decenas de celdas aleatorias puede, con altísima probabilidad, determinar si los datos completos están disponibles en la red.

La bidimensionalidad tiene otra ventaja crucial: simplifica las pruebas de fraude. Si un productor de bloques codifica mal los datos —es decir, si la redundancia no es consistente con los datos originales—, basta con presentar una sola fila o columna inconsistente como prueba. Una prueba de fraude unidimensional requeriría presentar todos los datos de una dimensión; una prueba bidimensional solo necesita los datos de una fila o columna, lo que reduce drásticamente el tamaño de la prueba.

De la cuadrícula al cubo y más allá

¿Por qué detenerse en dos dimensiones? En teoría, se podría extender la codificación a tres dimensiones (un cubo de datos) o incluso más. La razón de quedarse en dos dimensiones es práctica: el equilibrio entre la eficiencia de la codificación, el tamaño de las pruebas de fraude y la complejidad computacional es óptimo en 2D para los tamaños de bloque que manejan las blockchains actuales. Pasar a tres dimensiones reduciría el tamaño de las pruebas, pero aumentaría la complejidad de la codificación y la decodificación. El cuadrado extendido es, como ocurre tantas veces en ingeniería, el punto de equilibrio entre lo teóricamente perfecto y lo prácticamente implementable.

KZG Commitments: la huella dactilar de un polinomio

El artículo que tardó una década en hacerse imprescindible

En 2010, tres investigadores de la Universidad de Waterloo en Canadá —Aniket Kate, Gregory Zaverucha e Ian Goldberg— publicaron un artículo titulado «Constant-Size Commitments to Polynomials and Their Applications». El paper describía un esquema que permitía «comprometerse» con un polinomio —es decir, publicar una especie de huella dactilar del polinomio— de tal forma que luego se pudiera demostrar que el polinomio evaluado en un punto concreto produce un valor concreto, sin revelar el polinomio entero. Y lo más notable: la prueba tenía un tamaño constante de apenas 48 bytes, independientemente del grado del polinomio. Un polinomio de grado 10 y uno de grado un millón producían pruebas del mismo tamaño.

Durante años, el artículo fue una curiosidad académica, citado en círculos especializados pero sin una aplicación clara a gran escala. Fue la revolución de la escalabilidad blockchain —la necesidad desesperada de verificar grandes volúmenes de datos de forma compacta— la que convirtió los compromisos KZG en una pieza central de la infraestructura criptográfica moderna. Hoy, KZG es el mecanismo que usa Ethereum para verificar los «blobs» de datos de la EIP-4844, y es fundamental en los diseños de Celestia, Danksharding completo y docenas de protocolos de capa dos.

La analogía del sello de cera

Para entender los compromisos KZG sin entrar todavía en las matemáticas, imaginemos a un notario medieval. Un noble redacta un documento extenso —digamos, las leyes de su feudo, que ocupan veinte páginas—. El noble cierra el documento con un sello de cera que tiene dos propiedades: primero, el sello es único para ese documento específico (si se cambia una sola palabra, el sello ya no coincide); segundo, el sello permite verificar fragmentos individuales del documento sin necesidad de abrirlo entero. Si alguien quiere comprobar que la ley número 7 dice efectivamente «los impuestos no superarán el diez por ciento de la cosecha», el noble puede proporcionar esa ley concreta junto con un «certificado de autenticidad» que cualquiera puede verificar contra el sello, sin necesidad de leer las otras diecinueve páginas.

Un compromiso KZG funciona exactamente así. El polinomio es el documento. El compromiso (un punto en una curva elíptica, de 48 bytes) es el sello de cera. Y las pruebas de evaluación (también de 48 bytes cada una) son los certificados de autenticidad para puntos concretos del polinomio. Lo extraordinario es que tanto el sello como los certificados tienen un tamaño fijo —48 bytes— sin importar la longitud del documento original.

Curvas elípticas y emparejamientos bilineales: el andamiaje matemático

Los compromisos KZG se construyen sobre dos pilares matemáticos que merecen ser explicados, al menos intuitivamente.

El primero son las curvas elípticas. Una curva elíptica es una curva matemática definida por una ecuación de la forma y² = x³ + ax + b. Los puntos de esta curva, junto con una operación de «suma» geométricamente definida, forman un grupo algebraico con una propiedad clave para la criptografía: es fácil calcular el resultado de «multiplicar» un punto por un número (sumar el punto consigo mismo muchas veces), pero dado el resultado, es prácticamente imposible averiguar por qué número se multiplicó. Esta asimetría —fácil en una dirección, imposible en la otra— es lo que los criptógrafos llaman una función de trampilla, y es la base de la seguridad de todo el sistema.

El segundo pilar son los emparejamientos bilineales (o pairings). Imaginemos dos salas de un museo, cada una con su propia colección. La Sala A tiene esculturas de bronce y la Sala B tiene esculturas de mármol. Existe una máquina especial que toma una escultura de cada sala y produce un mosaico en una tercera Sala C. La propiedad crucial de esta máquina es que si «amplías» la escultura de bronce al doble antes de introducirla, el mosaico resultante es el mismo que si hubieras «ampliado» la escultura de mármol al doble en lugar de la de bronce. Puedes «mover» la transformación de un lado a otro sin que cambie el resultado.

En términos formales, un emparejamiento bilineal es una función e que toma un elemento del grupo G&sub1; y un elemento del grupo G&sub2; y produce un elemento de un tercer grupo G_T, cumpliendo la propiedad e(a·P, Q) = e(P, a·Q) = e(P, Q)^a. Esta capacidad de «mover factores entre los argumentos» es lo que permite verificar compromisos KZG: el verificador puede comprobar que una prueba es correcta sin conocer el polinomio original, usando solo el compromiso público y la propiedad del emparejamiento.

Cómo funciona un compromiso KZG, paso a paso

El proceso tiene tres fases: generación de parámetros (que se hace una sola vez), compromiso (que hace el que publica los datos) y verificación (que hace cualquiera que quiera comprobar un dato).

Fase 1: La ceremonia de confianza. Antes de que nadie pueda usar KZG, es necesario generar unos parámetros públicos. Estos parámetros son, intuitivamente, como las pesas calibradas de una balanza de precisión: todo el mundo necesita usar las mismas pesas para que las mediciones sean comparables, y las pesas deben haber sido calibradas correctamente. En KZG, los parámetros son un conjunto de puntos de la curva elíptica calculados a partir de un número secreto —llamémoslo s— que debe ser destruido después de la generación. Si alguien conserva s, puede fabricar pruebas falsas. Esto plantea una pregunta obvia: ¿cómo puedes confiar en que el número secreto fue destruido?

La respuesta es la ceremonia de configuración de confianza (trusted setup ceremony). En lugar de que una sola persona genere s, participan miles de personas en un proceso secuencial. Cada participante aporta su propia aleatoriedad, que se mezcla con la de todos los anteriores. El resultado final es que s se compone de las contribuciones de todos los participantes, y basta con que uno solo de ellos haya sido honesto —es decir, haya destruido su contribución individual— para que el sistema sea seguro. No necesitas confiar en todos; necesitas confiar en que, entre miles de participantes, al menos uno no fue comprometido.

La ceremonia de KZG para Ethereum, celebrada entre 2022 y 2023, contó con más de 141.000 participantes de todo el mundo. Fue, por volumen de participación, la mayor ceremonia criptográfica de la historia. Los participantes incluían investigadores, ingenieros, activistas, artistas y ciudadanos ordinarios que ejecutaron el software de la ceremonia en sus portátiles, contribuyendo su grano de arena a la seguridad del sistema. Para que la ceremonia hubiera fallado —para que alguien pudiera fabricar pruebas KZG falsas en Ethereum—, los 141.000 participantes tendrían que haber sido comprometidos o haber conspirado. La probabilidad de que esto ocurriera es tan remota que los criptógrafos la consideran despreciable.

Fase 2: El compromiso. Quien publica los datos toma su polinomio —que codifica los datos del bloque o del blob— y calcula un solo punto de la curva elíptica que es la «huella dactilar» del polinomio. Este cálculo usa los parámetros públicos generados en la ceremonia. El resultado es un punto de 48 bytes que se incluye en el encabezado del bloque. A partir de este punto, cualquiera puede verificar evaluaciones individuales del polinomio.

Fase 3: La verificación. Supongamos que alguien quiere verificar que el polinomio evaluado en el punto z produce el valor y. El publicador proporciona una prueba de 48 bytes. El verificador realiza dos operaciones de emparejamiento bilineal —esencialmente, dos «pasadas por la máquina del museo»— y comprueba si los resultados son iguales. Si lo son, la evaluación es correcta. Si no, alguien ha mentido. Todo el proceso —compromiso, generación de prueba y verificación— es computacionalmente ligero comparado con descargar y verificar los datos en bruto.

¿Por qué es mejor que un hash de Merkle para este propósito?

La pregunta natural es: ¿por qué no usar simplemente un árbol de Merkle, que es más sencillo y no requiere una ceremonia de confianza? La respuesta tiene que ver con la eficiencia de las pruebas.

Propiedad	Árbol de Merkle	Compromiso KZG
Tamaño del compromiso	32 bytes (hash raíz)	48 bytes (punto de curva)
Tamaño de la prueba por elemento	Crece logarítmicamente con el número de elementos	Constante: 48 bytes siempre
Prueba para 1.000 elementos	∼320 bytes	48 bytes
Prueba para 1.000.000 elementos	∼640 bytes	48 bytes
Verificación de consistencia con codificación de borrado	Requiere reconstrucción parcial	Directa mediante propiedades algebraicas
Ceremonia de confianza	No necesaria	Necesaria (una sola vez)

En un árbol de Merkle con un millón de hojas, demostrar que una hoja tiene un determinado valor requiere proporcionar unos 20 hashes intermedios (la «rama» desde la hoja hasta la raíz). Con KZG, la prueba siempre es de 48 bytes, sin importar cuántos datos haya. Cuando necesitas verificar miles de puntos —como ocurre en el muestreo de disponibilidad—, la diferencia en ancho de banda es enorme. Además, los compromisos KZG tienen una propiedad algebraica que los hace especialmente compatibles con la codificación de borrado: verificar que una extensión Reed-Solomon es correcta se puede hacer directamente sobre los compromisos, sin necesidad de descodificar los datos.

Data Availability Sampling: verificar sin descargar

La inspección sanitaria que funciona con muestras

Imaginemos que eres inspector de sanidad y tu trabajo consiste en garantizar que los 10.000 restaurantes de tu ciudad cumplen las normas de higiene. Inspeccionar los 10.000 cada mes es imposible: no tienes suficientes inspectores, ni suficiente tiempo, ni suficiente presupuesto. La solución, que cualquier epidemiólogo aprobaría, es el muestreo aleatorio: seleccionas 200 restaurantes al azar cada mes y los inspeccionas a fondo. Si un restaurante sirve comida en mal estado, la probabilidad de que pase desapercibido durante varios meses consecutivos de muestreo aleatorio es insignificante. No has inspeccionado todos los restaurantes, pero tienes una confianza estadística altísima de que los problemas graves serán detectados.

El Data Availability Sampling (DAS) aplica exactamente esta lógica a la verificación de datos en blockchain. En lugar de que cada nodo descargue el bloque entero para comprobar que los datos están disponibles, cada nodo ligero solicita unas pocas celdas aleatorias del Extended Data Square. Si todas las celdas solicitadas están disponibles y son consistentes con el compromiso KZG publicado en el encabezado del bloque, el nodo puede concluir, con una probabilidad abrumadora, que los datos completos del bloque están disponibles en la red.

La matemática de la confianza: por qué funciona

La intuición matemática detrás del DAS se puede explicar con un razonamiento sorprendentemente simple. Supongamos que un productor de bloques malicioso quiere ocultar datos. Para que el ataque tenga éxito, necesita retener una fracción significativa del Extended Data Square —recordemos que, gracias a la codificación de borrado, basta con que el 50% de las celdas estén disponibles para reconstruir todos los datos originales—. Si el atacante retiene menos del 50%, los datos pueden reconstruirse y su ataque fracasa. Así que el atacante necesita retener al menos el 50% de las celdas.

Ahora, un nodo ligero solicita una celda aleatoria. La probabilidad de que esa celda caiga en la parte retenida por el atacante es de al menos el 50%. Si eso ocurre, el nodo no recibe respuesta (o recibe una respuesta inconsistente con el compromiso KZG) y sabe que algo va mal. Pero si por casualidad la celda cae en la parte disponible, el nodo no detecta nada. ¿Cuál es la solución? Solicitar más de una celda.

Si el nodo solicita n celdas aleatorias independientes, la probabilidad de que todas caigan en la parte disponible —es decir, de que el ataque pase desapercibido— es como máximo (1 − 0,5)ⁿ = 0,5ⁿ. Veamos qué significa esto en la práctica:

Muestras (n)	Probabilidad de no detectar el ataque	Confianza
1	50%	50%
5	3,1%	96,9%
10	0,098%	99,9%
20	0,000095%	99,99990%
30	9,3 × 10−10	99,9999999%
75	2,6 × 10−23	Prácticamente 100%

Con solo 30 muestras, la probabilidad de que un ataque de retención de datos pase desapercibido es inferior a una entre mil millones. Con 75 muestras —que a una tasa de, digamos, 512 bytes por celda equivalen a descargar apenas 38 kilobytes—, la probabilidad es tan baja que se necesitaría repetir el experimento más veces de las que hay átomos en el universo observable para esperar un solo fallo. Y esto es para un solo nodo ligero. Si la red tiene miles de nodos ligeros, cada uno muestreando independientemente, la probabilidad acumulada de que el ataque tenga éxito es astronómicamente pequeña.

El protocolo completo, paso a paso

Reunamos todas las piezas que hemos construido. El protocolo de Data Availability Sampling funciona así:

Paso 1: El productor del bloque toma las transacciones del bloque, las organiza en una matriz cuadrada de k×k, aplica la codificación de borrado Reed-Solomon en filas y columnas para obtener un Extended Data Square de 2k×2k, y calcula un compromiso KZG para cada fila y cada columna del EDS. Estos compromisos —un punto de curva elíptica de 48 bytes por fila y por columna— se incluyen en el encabezado del bloque.

Paso 2: El productor distribuye las celdas del EDS por la red, de forma que cada nodo almacene una parte del cuadrado. Ningún nodo individual necesita almacenar el cuadrado completo; basta con que, colectivamente, la red almacene todas las celdas.

Paso 3: Cada nodo ligero selecciona aleatoriamente entre 30 y 75 celdas del EDS y las solicita a la red. Para cada celda recibida, verifica que su valor es consistente con el compromiso KZG de la fila o columna correspondiente. Si todas las verificaciones pasan, el nodo acepta el bloque como disponible.

Paso 4: Si una celda no está disponible o es inconsistente con el compromiso, el nodo rechaza el bloque y lo reporta a la red. Si suficientes nodos reportan problemas, el bloque se considera inválido.

Paso 5: Si un nodo completo detecta que la codificación de borrado es incorrecta —que las filas o columnas del EDS no son extensiones Reed-Solomon válidas de los datos originales—, genera una prueba de fraude: una fila o columna completa que demuestra la inconsistencia. Esta prueba se propaga por la red y permite a todos los nodos rechazar el bloque sin necesidad de descargar los datos completos.

Lo que el nodo ligero descarga frente al nodo completo

Para poner números concretos, consideremos un bloque de 1 megabyte de datos originales. Después de la codificación de borrado, el Extended Data Square tiene 4 megabytes. Un nodo completo necesita descargar los 4 megabytes completos para verificar íntegramente el bloque. Un nodo ligero que realiza 75 muestras de 512 bytes cada una descarga aproximadamente 38 kilobytes, más unos pocos kilobytes de compromisos KZG y pruebas. Es decir, el nodo ligero descarga menos del 1% de lo que descarga el nodo completo, y aun así obtiene una confianza superior al 99,9999999% de que los datos están disponibles.

Esto es lo que permite la escalabilidad. Si mañana los bloques crecen a 10 megabytes, el nodo completo necesita diez veces más ancho de banda, pero el nodo ligero sigue descargando los mismos 38 kilobytes. El coste de verificación para los nodos ligeros es constante, independientemente del tamaño del bloque. Es la diferencia entre un inspector que necesita revisar cada plato de un restaurante (y que, por tanto, no puede inspeccionar más restaurantes sin contratar más inspectores) y uno que solo prueba tres platos elegidos al azar (y que puede inspeccionar restaurantes cada vez más grandes sin cambiar su método).

Pruebas de fraude: el mecanismo de denuncia

¿Qué ocurre cuando alguien miente?

El Data Availability Sampling garantiza que los datos están disponibles, pero no garantiza que estén correctamente codificados. Un productor de bloques malicioso podría publicar un EDS donde las celdas de redundancia no corresponden a una extensión Reed-Solomon válida de los datos originales. Si nadie detecta esta inconsistencia, un nodo que intentara reconstruir los datos a partir de las celdas de redundancia obtendría basura en lugar de las transacciones originales.

Imaginemos una analogía. Un testigo en un juicio presta declaración bajo juramento. El juez no puede verificar la veracidad de cada frase del testigo en tiempo real, pero si otro testigo —o una prueba documental— contradice la declaración, el abogado defensor puede presentar una objeción con evidencia. El juez examina la evidencia, comprueba la contradicción y desestima el testimonio falso. No fue necesario verificar cada palabra del testigo: bastó con encontrar una contradicción demostrable.

Las pruebas de fraude en el DAS funcionan de manera análoga. Un nodo completo que descarga todos los datos y verifica la codificación de borrado puede detectar filas o columnas donde la redundancia no es consistente con los datos originales. Cuando encuentra una, construye una prueba de fraude: la fila o columna completa junto con el compromiso KZG que la contradice. Esta prueba es compacta —una fila de 2k celdas, no el bloque entero— y es verificable por cualquier nodo, incluidos los nodos ligeros, realizando unas pocas operaciones de emparejamiento bilineal.

La existencia de pruebas de fraude crea un equilibrio de incentivos. Un productor de bloques sabe que, si codifica incorrectamente los datos, cualquier nodo completo puede generar una prueba de fraude que se propagará por toda la red en segundos, causando el rechazo del bloque y, en muchas blockchains, la pérdida de un depósito económico significativo. El coste de hacer trampa es alto y la probabilidad de ser detectado es cercana a uno. Como resultado, los productores de bloques racionales no intentan hacer trampa, lo que a su vez significa que las pruebas de fraude rara vez necesitan ser generadas en la práctica. Es un arma disuasoria cuya efectividad se mide precisamente por la infrecuencia de su uso.

EIP-4844 y Proto-Danksharding: la primera aplicación a escala mundial

El problema que Ethereum necesitaba resolver

Para entender por qué Ethereum adoptó KZG y los conceptos de disponibilidad de datos, necesitamos entender el ecosistema de las soluciones de capa dos. A partir de 2021, la mayor parte de la actividad en Ethereum empezó a migrar hacia redes de capa dos como Optimism, Arbitrum, Base y zkSync. Estas redes procesan las transacciones fuera de la cadena principal de Ethereum —en sus propios servidores, con sus propias reglas de ejecución— pero necesitan publicar los datos de las transacciones en Ethereum para heredar su seguridad. Es como una empresa que tiene sus propias oficinas pero deposita todos sus documentos legales en un notario público: el procesamiento es privado, pero el registro es público e inmutable.

El problema era que publicar datos en Ethereum era carísimo. Las redes de capa dos empaquetaban sus datos de transacciones como «calldata» —un campo de las transacciones de Ethereum diseñado originalmente para pasar parámetros a contratos inteligentes, no para almacenar grandes volúmenes de datos—. El coste de calldata estaba sujeto al mecanismo de tarifas general de Ethereum, y en momentos de alta demanda, publicar un megabyte de datos podía costar cientos o miles de dólares. Este coste se repercutía directamente a los usuarios de las redes de capa dos en forma de tarifas de transacción.

Dankrad Feist, investigador de la Ethereum Foundation, propuso una solución elegante: crear un nuevo tipo de espacio de datos en Ethereum, específicamente diseñado para las necesidades de las redes de capa dos. Este nuevo espacio utilizaría compromisos KZG en lugar de la estructura de transacciones existente, tendría su propio mercado de tarifas separado del gas de ejecución, y los datos almacenados en él serían temporales —disponibles durante unas semanas, no para siempre—. La propuesta se formalizó como EIP-4844 y se bautizó informalmente como «Proto-Danksharding»: «proto» porque es el primer paso hacia el Danksharding completo, y «Danksharding» en honor a Dankrad.

¿Qué cambió con EIP-4844?

La EIP-4844 introdujo un nuevo concepto en Ethereum: los blobs (no confundir con los blobs de Git, que vimos en artículos anteriores; aquí «blob» se usa en su sentido genérico de «gran objeto binario»). Cada blob contiene aproximadamente 128 kilobytes de datos y va acompañado de un compromiso KZG que actúa como su huella dactilar criptográfica. Los bloques de Ethereum pueden incluir hasta 6 blobs (con un objetivo de 3 por bloque), lo que añade entre 384 y 768 kilobytes de espacio de datos por bloque.

Los datos de los blobs no se almacenan permanentemente en la cadena de Ethereum. Se mantienen disponibles durante un período de aproximadamente 18 días —tiempo suficiente para que cualquier disputa o verificación pueda resolverse— y luego se descartan. Esto es radicalmente diferente del modelo anterior, donde los datos publicados como calldata permanecían para siempre en la cadena, consumiendo almacenamiento indefinidamente. Es la diferencia entre un periódico (que se lee, se guarda unas semanas por si acaso, y luego se recicla) y un libro de actas (que se conserva indefinidamente). Los datos de los blobs son el periódico: informativos y verificables mientras son relevantes, pero no diseñados para la eternidad.

El impacto económico fue inmediato y dramático. Antes de EIP-4844, una transacción en Optimism costaba entre 0,05 y 2 dólares, dependiendo de la congestión de Ethereum. Después de la activación, los costes cayeron a fracciones de céntimo. Base, la red de capa dos de Coinbase, reportó reducciones de costes superiores al 99%. Para los millones de usuarios de estas redes, la diferencia fue perceptible de un día para otro.

Proto-Danksharding frente a Danksharding completo

Es importante entender que EIP-4844 es un primer paso, no la solución final. En Proto-Danksharding, cada nodo de Ethereum todavía descarga todos los blobs de cada bloque. No se hace muestreo de disponibilidad de datos todavía. La mejora viene de usar un mercado de tarifas separado y datos temporales, no de reducir lo que cada nodo descarga.

El Danksharding completo, que se espera implementar en fases futuras de Ethereum, sí incorporará Data Availability Sampling en toda su potencia. Con Danksharding completo, el número de blobs por bloque podría crecer de 6 a 64 o incluso más, proporcionando megabytes de espacio de datos por bloque. Pero ningún nodo individual necesitará descargar todos esos blobs: cada nodo muestreará aleatoriamente una fracción del Extended Data Square, exactamente como hemos descrito en las secciones anteriores. El resultado será que Ethereum podrá ofrecer órdenes de magnitud más espacio de datos sin aumentar los requisitos de hardware para los validadores individuales.

Característica	Ethereum antes de EIP-4844	Proto-Danksharding (EIP-4844)	Danksharding completo (futuro)
Espacio de datos por bloque	∼85 KB (calldata)	∼384-768 KB (3-6 blobs)	Varios MB (64+ blobs)
Verificación criptográfica	Merkle Patricia Trie	Compromisos KZG	Compromisos KZG + DAS
Persistencia de datos	Permanente	Temporal (∼18 días)	Temporal
Cada nodo descarga todo	Sí	Sí (aún)	No (muestreo)
Mercado de tarifas	Unificado con ejecución	Separado para blobs	Separado para blobs
Coste para capa dos	Alto	Bajo	Muy bajo

Celestia: la blockchain que nació del DAS

Mientras Ethereum adaptaba su infraestructura existente para incorporar disponibilidad de datos, un proyecto construido desde cero alrededor de esta idea tomaba forma. Celestia, cofundado por el propio Mustafa Al-Bassam (coautor del artículo académico fundacional sobre DAS), se lanzó en octubre de 2023 como la primera blockchain diseñada específicamente como capa de disponibilidad de datos. A diferencia de Ethereum, que es una blockchain «de propósito general» que añade disponibilidad de datos como una función más, Celestia solo hace disponibilidad de datos. No ejecuta contratos inteligentes, no procesa transacciones, no mantiene un estado global. Su única función es recibir datos, codificarlos con borrado Reed-Solomon en un Extended Data Square, publicar compromisos KZG y permitir que los nodos ligeros verifiquen la disponibilidad mediante muestreo.

Esta especialización le permite a Celestia optimizar cada aspecto de su diseño para el DAS. Los bloques de Celestia están organizados en Namespaced Merkle Trees, donde cada aplicación que publica datos tiene su propio espacio de nombres. Los nodos ligeros de Celestia realizan DAS nativo: al arrancar, empiezan a muestrear celdas aleatorias del EDS y, si todas las muestras son consistentes, aceptan el bloque. Esto permite que un teléfono móvil con una conexión mediocre verifique la disponibilidad de datos de un bloque de varios megabytes descargando apenas unas decenas de kilobytes.

Historias del mundo real: cinco escenarios donde DAS y KZG cambian las reglas

Marcos y la plataforma de préstamos en crisis

Marcos es director técnico de una plataforma de préstamos descentralizada que opera como rollup sobre Ethereum. La plataforma gestiona colateral por valor de 800 millones de euros y procesa miles de liquidaciones diarias cuando los precios del mercado caen. Cada liquidación es una transacción que debe publicarse en Ethereum para que cualquiera pueda verificar que fue justa: que el precio de referencia era correcto, que los márgenes se calcularon adecuadamente, que el prestatario recibió lo que le correspondía después de la liquidación.

Antes de EIP-4844, cada liquidación costaba entre 5 y 15 dólares en tarifas de publicación de datos. En un día de volatilidad extrema —como el que ocurrió en mayo de 2022, cuando el ecosistema Terra colapsó—, la plataforma de Marcos procesó 47.000 liquidaciones en 24 horas. El coste de publicar los datos de esas liquidaciones en Ethereum superó los 400.000 dólares. La plataforma tuvo que elegir entre absorber ese coste (erosionando sus reservas), repercutirlo a los usuarios (haciendo las liquidaciones prohibitivamente caras) o dejar de publicar datos temporalmente (comprometiendo la verificabilidad y, por tanto, la confianza).

Después de la activación de EIP-4844, los datos de liquidación se publican como blobs. El coste de publicar las mismas 47.000 liquidaciones habría sido inferior a 2.000 dólares. No es solo una cuestión económica: es una cuestión de viabilidad. A los costes anteriores, la plataforma de Marcos solo podía operar de forma sostenible si los volúmenes se mantenían por debajo de cierto umbral. Por encima de ese umbral, el coste de la transparencia era mayor que el valor de la transparencia. Los compromisos KZG y la disponibilidad de datos barata eliminaron esa barrera, haciendo que la verificabilidad completa sea económicamente sostenible incluso en los peores escenarios de mercado.

Lucía y el sistema de votación municipal

Lucía es responsable de innovación digital en un ayuntamiento español que quiere implementar un sistema de votación electrónica para presupuestos participativos. Los ciudadanos deben poder votar desde sus teléfonos móviles, y el proceso debe ser completamente verificable: cualquier ciudadano debe poder comprobar que su voto fue contado y que el resultado total es correcto, sin necesidad de confiar en el ayuntamiento.

El sistema que diseña el equipo de Lucía registra los votos como transacciones en un rollup de capa dos. Los datos de cada ronda de votación —los votos cifrados, los recuentos parciales, las pruebas de elegibilidad— se publican en blobs de Ethereum. Cada ciudadano tiene una aplicación móvil que funciona como nodo ligero: cuando se publica el resultado de una votación, la aplicación realiza DAS sobre los blobs correspondientes para verificar que todos los datos están disponibles. Si algún dato faltara —si el ayuntamiento hubiera omitido votos, por ejemplo—, el DAS lo detectaría.

Pero lo verdaderamente transformador para Lucía es que la verificación la puede hacer cualquier ciudadano con un teléfono modesto y una conexión 4G. No necesita ejecutar un nodo completo, no necesita descargar megabytes de datos, no necesita conocimientos técnicos. La aplicación muestrea 75 celdas, las verifica contra los compromisos KZG y muestra un indicador verde si todo está en orden. Es la diferencia entre decirle a un ciudadano «confía en nosotros, el recuento es correcto» y darle una herramienta para que lo verifique personalmente en diez segundos.

Roberto y la cadena de suministro farmacéutica

Roberto dirige la logística de una distribuidora farmacéutica que mueve 200.000 paquetes al mes por toda la Península Ibérica. La normativa europea exige trazabilidad completa de cada medicamento desde la fábrica hasta la farmacia: cada transferencia de custodia, cada cambio de temperatura en la cadena de frío, cada verificación del número de serie contra la base de datos antifalsificación. Son millones de registros al mes, y todos deben ser auditables por las autoridades sanitarias.

El sistema de Roberto utiliza una red blockchain de capa dos específica para el sector farmacéutico. Cada paquete genera decenas de registros a lo largo de su recorrido, y todos estos registros se agrupan en lotes que se publican como blobs en Ethereum. Cuando un inspector de la Agencia Española de Medicamentos quiere auditar el recorrido de un lote sospechoso, no necesita descargar meses de datos de toda la cadena de suministro. Solicita los registros del lote en cuestión y verifica su consistencia contra los compromisos KZG publicados. En minutos, tiene una garantía criptográfica de que los datos que está revisando son auténticos y completos.

Antes de la disponibilidad de datos barata, Roberto se enfrentaba a un dilema: o publicaba los datos en Ethereum (caro pero verificable) o los almacenaba en una base de datos centralizada (barato pero no verificable). EIP-4844 eliminó ese dilema. Los datos se publican como blobs a un coste marginal por paquete inferior a 0,001 euros, y cualquier inspector puede verificar su autenticidad sin confiar en la distribuidora.

Carmen y la red de videojuegos descentralizada

Carmen es arquitecta de software en un estudio de videojuegos que desarrolla un juego multijugador donde los objetos del juego tienen valor económico real: los jugadores pueden comprar, vender e intercambiar objetos digitales, y las transacciones se liquidan en una red blockchain. El juego procesa 50.000 transacciones por hora en momentos de máxima actividad —durante torneos, eventos especiales o lanzamientos de nuevas temporadas— y cada transacción debe ser verificable para que los jugadores confíen en que el mercado es justo.

El volumen de datos que genera el juego es sustancial: cada transacción incluye no solo la transferencia de propiedad del objeto, sino también metadatos como el estado del objeto (nivel de desgaste, mejoras aplicadas, historial de propietarios) y el contexto de la transacción (precio, moneda, marcas temporales). Comprimir estos datos y publicarlos como blobs en Ethereum permite a Carmen ofrecer algo que antes era económicamente inviable: un mercado de objetos virtuales donde cada transacción es públicamente verificable, pero cuyo coste de verificabilidad se reparte entre millones de transacciones gracias a la eficiencia de los compromisos KZG.

Los jugadores de Carmen no saben qué es un compromiso KZG ni qué significa «muestreo de disponibilidad de datos». Lo que saben es que cuando intercambian un objeto raro, pueden pulsar un botón en la interfaz que dice «verificar transacción» y recibir, en dos segundos, una confirmación de que la transacción fue registrada correctamente y que los datos subyacentes son íntegros. Esa verificación, invisible para el usuario, ejecuta un muestreo DAS y una comprobación KZG bajo la superficie.

Pilar y la auditoría financiera automatizada

Pilar es socia de una firma de auditoría que trabaja con empresas cotizadas en bolsa. La normativa exige que las cuentas anuales de estas empresas sean verificadas por un auditor externo, un proceso que tradicionalmente implica meses de trabajo, decenas de auditores revisando miles de documentos y un coste que puede superar el millón de euros para las empresas más grandes.

Pilar está explorando un modelo donde las empresas publican sus registros financieros —facturas, pagos, nóminas, amortizaciones— en una capa de disponibilidad de datos a medida que se generan, no al final del ejercicio. Cada registro se agrupa en lotes periódicos (diarios o semanales) que se publican como blobs con compromisos KZG. Al llegar el momento de la auditoría, Pilar no necesita solicitar documentos a la empresa: los datos ya están publicados y su integridad está garantizada criptográficamente. Su trabajo se transforma: en lugar de verificar la autenticidad de los documentos (que ahora es automática), se centra en analizar su contenido —¿los ingresos son razonables? ¿los gastos están justificados? ¿las provisiones son adecuadas?—.

El DAS es crucial en este escenario porque permite a los reguladores verificar que los datos publicados están completos sin descargar los registros financieros de todas las empresas cotizadas. Un regulador puede ejecutar nodos ligeros que muestrean continuamente la capa de disponibilidad de datos, alertando automáticamente si alguna empresa deja de publicar datos o si los datos publicados son inconsistentes. Es supervisión continua en tiempo real, no auditoría retrospectiva anual.

Implicaciones para la escalabilidad: los números que importan

El cuello de botella que DAS elimina

En una blockchain tradicional, la capacidad de procesamiento está limitada por el nodo más lento de la red. Si queremos que cualquier persona con un ordenador doméstico pueda operar un nodo completo —lo cual es necesario para la descentralización—, los bloques no pueden ser más grandes de lo que un ordenador doméstico con una conexión de internet estándar puede descargar y procesar en el intervalo entre bloques. Para Ethereum, con bloques cada 12 segundos y una conexión doméstica típica de 25 megabits por segundo, esto pone un límite práctico de unos pocos megabytes por bloque.

Con DAS, este límite se desacopla. Lo que importa ya no es cuánto puede descargar cada nodo, sino cuánto pueden descargar todos los nodos en conjunto. Si la red tiene 10.000 nodos ligeros y cada uno muestrea 75 celdas, entre todos cubren cientos de miles de celdas del Extended Data Square. Los bloques pueden crecer —a 16, 32 o incluso 128 megabytes— sin que ningún nodo individual necesite descargar más que unas decenas de kilobytes. La capacidad de datos de la red escala con el número de nodos, no con el ancho de banda de cada nodo.

Esto invierte una relación que parecía inmutable. En el modelo antiguo, más nodos significaba más replicación del mismo dato, sin ganancia de capacidad. En el modelo DAS, más nodos significa más muestras distribuidas, lo que permite bloques más grandes con la misma confianza. Es como la diferencia entre un sistema donde cada cartero lleva una copia completa de todo el correo (más carteros no ayudan a llevar más correo) y uno donde cada cartero lleva solo unas cartas, pero entre todos cubren toda la ciudad (más carteros permiten repartir más correo).

Los desafíos pendientes

El DAS no es una solución perfecta, y es importante entender sus limitaciones actuales. La red de distribución de datos (cómo las celdas del EDS llegan desde el productor hasta los nodos que las solicitan) es un problema de ingeniería de redes aún en desarrollo. Se necesita una capa de red eficiente —probablemente basada en DHT (Distributed Hash Tables) o en protocolos de gossip especializados— para que las celdas estén disponibles rápidamente en toda la red.

El problema del arranque es otro desafío: el DAS funciona bien cuando hay muchos nodos ligeros muestreando, pero ¿qué ocurre al principio, cuando hay pocos? Si la red tiene solo 10 nodos ligeros, cada uno muestreando 75 celdas, la cobertura colectiva puede ser insuficiente para garantizar que todas las celdas están disponibles. Los diseños actuales contemplan una fase de transición donde los nodos completos siguen descargando todo mientras la red de nodos ligeros crece.

Finalmente, la latencia es una consideración importante. El muestreo de disponibilidad añade un paso al proceso de verificación de bloques: antes de aceptar un bloque, un nodo ligero necesita solicitar celdas, esperar las respuestas y verificar las pruebas KZG. Este proceso debe completarse en el intervalo entre bloques (12 segundos en Ethereum). Si las respuestas tardan demasiado —porque la red es lenta o porque los nodos que almacenan las celdas están lejos—, el nodo ligero podría no completar la verificación a tiempo. Los diseñadores de protocolos trabajan activamente en optimizar esta latencia.

Para saber más: referencias y lecturas recomendadas

Los conceptos presentados en este artículo se apoyan en décadas de investigación en teoría de la información, criptografía y sistemas distribuidos. Las siguientes referencias permiten profundizar en cada aspecto, desde las matemáticas fundamentales hasta las implementaciones prácticas más recientes.

• Reed, I. S. y Solomon, G. (1960). «Polynomial Codes over Certain Finite Fields». Journal of the Society for Industrial and Applied Mathematics, 8(2), 300-304. El artículo fundacional que introdujo los códigos de corrección de errores que hoy permiten que funcionen desde los CDs hasta las sondas espaciales. Con apenas cuatro páginas de extensión, es uno de los artículos más influyentes de la teoría de la información.
• Kate, A., Zaverucha, G. y Goldberg, I. (2010). «Constant-Size Commitments to Polynomials and Their Applications». ASIACRYPT 2010. El artículo que introdujo los compromisos polinomiales KZG. Describe cómo construir un compromiso de tamaño constante sobre un polinomio de grado arbitrario usando emparejamientos bilineales, permitiendo pruebas de evaluación de 48 bytes independientemente del tamaño de los datos.
• Al-Bassam, M., Sonnino, A. y Buterin, V. (2018). «Fraud and Data Availability Proofs: Maximising Light Client Security and Scaling Blockchains». Preprint arXiv:1809.09044. El artículo académico que formalizó el concepto de Data Availability Sampling y demostró matemáticamente cómo los nodos ligeros pueden verificar la disponibilidad de datos con solo unas decenas de muestras aleatorias. Es la base teórica de los diseños de Celestia y Danksharding.
• Feist, D. (2020). «KZG polynomial commitments». Blog personal de Dankrad Feist. Una explicación detallada y accesible de los compromisos polinomiales KZG, incluyendo su construcción matemática y sus aplicaciones a la verificación de datos en Ethereum.
• EIP-4844: Shard Blob Transactions. Ethereum Improvement Proposal, autores: Vitalik Buterin, Dankrad Feist, Diederik Loerakker, George Kadianakis, Matt Garnett, Mofi Taiwo, Ansgar Dietrichs. La especificación técnica completa de Proto-Danksharding, incluyendo el formato de las transacciones blob, el mecanismo de tarifas separado y la integración de compromisos KZG en el protocolo de Ethereum.
• Buterin, V. (2021). «An Incomplete Guide to Rollups». Blog de Vitalik Buterin. Una visión panorámica de cómo las soluciones de capa dos se benefician de la disponibilidad de datos barata, incluyendo la distinción entre rollups optimistas (que usan pruebas de fraude) y rollups de validez (que usan pruebas de conocimiento cero). Contextualiza el DAS dentro del ecosistema más amplio de escalabilidad de Ethereum.
• Celestia Documentation: Data Availability Layer. docs.celestia.org. La documentación técnica de la primera blockchain diseñada específicamente como capa de disponibilidad de datos. Explica en detalle los Namespaced Merkle Trees, el Extended Data Square y el protocolo de muestreo de los nodos ligeros de Celestia.
• Boneh, D., Drake, J., Fisch, B. y Gabizon, A. (2020). «Efficient polynomial commitment schemes for multiple points and polynomials». Preprint del IACR. Extensiones del esquema KZG original que permiten comprometer y evaluar múltiples polinomios simultáneamente, reduciendo el número de operaciones de emparejamiento necesarias. Estas optimizaciones son fundamentales para la eficiencia de DAS a escala.
• Ethereum KZG Ceremony. ceremony.ethereum.org. El sitio de la ceremonia de configuración de confianza de Ethereum, que reunió más de 141.000 contribuciones para generar los parámetros KZG de la EIP-4844. Incluye una descripción accesible de por qué las ceremonias de confianza funcionan y por qué basta con que un solo participante sea honesto.
• Merkle, R. (1979). «Secrecy, Authentication, and Public Key Systems». Tesis doctoral, Universidad de Stanford. El trabajo que introdujo los árboles de Merkle, la estructura de datos que subyace a la verificación eficiente de datos en todas las blockchains. Aunque el DAS usa compromisos KZG en lugar de árboles de Merkle para las pruebas de evaluación, la organización del Extended Data Square sigue dependiendo de principios merkelianos para la distribución de datos en la red.

El problema de la disponibilidad de datos es, en el fondo, una versión moderna de una pregunta filosófica antigua: ¿cómo puedes confiar en lo que no puedes ver? Durante siglos, la respuesta fue la fe en las instituciones —en el notario, en el banco, en el gobierno—. Los códigos de borrado, los compromisos KZG y el muestreo de disponibilidad ofrecen una respuesta radicalmente diferente: no necesitas verlo todo para estar seguro de que existe, siempre que las matemáticas te proporcionen las herramientas adecuadas para muestrear la realidad. Y resulta que muestrear 75 fragmentos de un universo de millones es suficiente para obtener una certeza que ninguna institución humana puede igualar. La confianza ya no reside en las personas ni en las organizaciones. Reside en la probabilidad, en los polinomios y en las curvas elípticas —y esa es una confianza que no se puede sobornar, engañar ni intimidar—.