¿Qué es Danksharding y el muestreo de disponibilidad de datos?

Por qué Ethereum no puede simplemente "hacer los bloques más grandes"

La propuesta de danksharding solo tiene sentido si primero entiendes la restricción que resuelve. Cada nodo en una blockchain tiene que descargar, verificar y almacenar cada bloque. Si simplemente aumentas el tamaño del bloque de, por ejemplo, unos pocos cientos de kilobytes a varios megabytes, no obtienes más rendimiento. Obtienes un umbral de hardware más alto, porque el portátil de consumo más barato sigue teniendo que ir al ritmo de la cadena.

Ese es el conflicto detrás del famoso trilema de la blockchain: una red quiere ser descentralizada (muchos nodos independientes), segura (sin una forma fácil de falsificar el historial) y escalable (muchas transacciones baratas). Aumentar el tamaño del bloque mejora una propiedad a costa de las otras, porque suben los requisitos para los nodos y cae el número de operadores.

La hoja de ruta de Ethereum centrada en rollups es una respuesta parcial. En lugar de hacerlo todo en la capa 1, dejas que los rollups de capa 2 ejecuten miles de transacciones y luego publican un resumen comprimido de vuelta en Ethereum. Ethereum se convierte en una capa de liquidación y de datos, no en una computadora mundial. Eso funciona, pero tiene un cuello de botella: los rollups necesitan un lugar barato y verificable donde publicar sus datos, y ese lugar es actualmente el calldata de Ethereum, que es caro y compite con cualquier otro uso del espacio de bloque.

Danksharding es el plan para eliminar ese cuello de botella dándoles a los rollups un canal de datos dedicado y abundante, sin obligar a cada nodo a descargarlo todo.

EIP-4844: el primer paso que ya viste

Antes de que el danksharding pudiera existir, Ethereum lanzó proto-danksharding, formalizado como EIP-4844, en marzo de 2024. Esta es la parte que quizá ya conozcas con el nombre de blobs.

Un blob es un fragmento de datos adjunto a una transacción que vive en un mercado de comisiones separado (a menudo llamado mercado de blob gas) y se elimina automáticamente de la cadena después de unos 18 días. Los nodos no tienen que ejecutar el contenido de los blobs; solo tienen que almacenarlos temporalmente y demostrar que se publicaron. Rollups como Arbitrum, Optimism y Base pasaron de publicar datos comprimidos como calldata a publicarlos como blobs, lo que de inmediato hizo que las transacciones de rollup fueran varias veces más baratas.

EIP-4844 es el compromiso de ingeniería. No cambia cómo Ethereum verifica la disponibilidad de datos. Sigue exigiendo que cada nodo descargue cada blob completo para confirmar que el bloque es válido. Eso funciona con unos pocos blobs por bloque, pero no escala hasta los volúmenes que imagina el danksharding.

Así que piensa en proto-danksharding como la rampa de acceso. Introduce el formato de transacción con blobs, el mercado de comisiones separado y las reglas de consenso que el danksharding futuro reutilizará. El danksharding completo es lo que ocurre cuando Ethereum deja de obligar a cada nodo a descargar cada blob y empieza a muestrear en su lugar.

Qué significa realmente "data availability"

La frase "los datos están disponibles" suena obvia, pero en la investigación sobre consenso tiene un significado preciso. Un bloque es data-available si todos los nodos honestos pueden realmente obtener los datos subyacentes, no solo el encabezado o un compromiso sobre ellos. Sin esa garantía, un productor de bloques malicioso podría publicar un encabezado de bloque que parece válido pero retener los datos que hay detrás, y los nodos completos no tendrían forma de detectar el fraude ni de reconstruir la cadena.

Este es el problema de la disponibilidad de datos, y es uno de los problemas más difíciles al escalar blockchains. Por eso los light clients en Bitcoin no pueden verificar la cadena por completo: descargan los encabezados de bloque, pero confían en que otra persona está almacenando los cuerpos. Si un minero retuviera alguna vez las transacciones de un bloque, un light client no podría saberlo.

Ethereum quiere dar a los light clients una verificación real en lugar de confianza. Eso requiere un primitivo con el que un nodo pueda confirmar que se publicó un conjunto grande de datos sin descargarlo. El data availability sampling es ese primitivo, y danksharding es el diseño específico de Ethereum que lo despliega a nivel de consenso.

Codificación de borrado: la matemática que permite que las muestras impliquen el todo

DAS solo funciona gracias a la codificación de borrado, una técnica tomada de la teoría del almacenamiento y de las comunicaciones. El modelo mental más sencillo es imaginar que escribes un archivo de 1 MB en una hoja de cálculo y luego añades 1 MB de filas redundantes que son combinaciones lineales de las celdas originales. Ahora tienes 2 MB, pero puedes reconstruir el 1 MB original a partir de cualquier 1 MB de los 2 MB.

En danksharding, los productores de bloques hacen más o menos lo mismo con los datos de blob. Amplían los datos subyacentes de cada blob con fragmentos de paridad adicionales calculados mediante un código de estilo Reed-Solomon, duplicando el tamaño en cadena a cambio de una garantía poderosa. Si los datos están aunque sea parcialmente disponibles, un nodo honesto puede reconstruirlo todo.

¿Por qué importa esto para el muestreo? Supón que un productor de bloques intenta retener un cuarto de los datos ampliados para que nadie pueda reconstruirlos. Eso es estadísticamente imposible de ocultar, porque las muestras se eligen uniformemente al azar en todo el conjunto de datos ampliado. Un nodo ligero que descargue con éxito, por ejemplo, 30 fragmentos aleatorios y confirme que todos coinciden puede estar seguro matemáticamente, con una probabilidad ajustable, de que todo el conjunto de datos es reconstruible por alguien.

La idea clave es que la codificación de borrado convierte un problema de descargarlo todo en un problema de comprobación aleatoria por muestreo. Sin ella, el muestreo no serviría, porque un productor malicioso podría retener un solo byte concreto y ninguna comprobación aleatoria lo detectaría.

Cómo funciona realmente el data availability sampling en un nodo

En el diseño de danksharding, los datos de la cadena se organizan conceptualmente como una cuadrícula bidimensional. Cada fila corresponde a los datos de blob de un slot, y cada columna es una franja de fragmentos ampliados. Un productor de bloques se compromete con toda la cuadrícula mediante compromisos polinómicos, compromisos KZG en el plan actual, que actúan como una huella criptográfica lo bastante pequeña como para caber en un encabezado de bloque.

Luego, los nodos ligeros hacen lo siguiente para cada slot:

• Reciben el encabezado del bloque y los compromisos KZG de los datos ampliados.
• Descargan un puñado de celdas aleatorias de la cuadrícula, pidiendo a distintos pares posiciones diferentes.
• Verifican cada celda descargada frente a su compromiso. Una celda mala falla la comprobación al instante.
• Aumentan su confianza, con cada muestra exitosa, de que toda la cuadrícula está disponible.

Después de suficientes muestras exitosas, el nodo ligero trata los datos como disponibles. Si el productor de bloques intentó retener incluso una pequeña fracción de la cuadrícula, la probabilidad de que todas las muestras aleatorias caigan en la parte honesta se reduce exponencialmente. Con unas pocas decenas de muestras, la probabilidad de fallo se vuelve insignificante.

Esta es la parte que cambia la historia del hardware. Un nodo ligero ya no necesita ser un servidor potente con un SSD rápido. Necesita descargar del orden de unos pocos kilobytes por slot y luego propagar esas muestras por la red. Eso mantiene competitivos a los stakers individuales y a los validadores domésticos, lo que preserva la descentralización.

Los riesgos de los que nadie habla con honestidad

Danksharding es técnicamente elegante, pero también trae modos de fallo reales. Hablar con honestidad exige mencionarlos.

El primer riesgo es el ataque de retención de disponibilidad de datos. Un productor de bloques podría intentar publicar un encabezado y luego retener suficientes celdas para que los nodos ligeros honestos no puedan muestrear. Si la red no tiene suficientes nodos ligeros muestreando de forma redundante, un atacante puede jugar con la aleatoriedad hasta que bastantes light clients se pierdan los datos disponibles y rechacen el bloque, causando un fallo de liveness, la cadena se detiene. Entre las mitigaciones de investigación están tener varios productores de bloques por slot y obligar a los nodos ligeros a esperar hasta que la red haya tenido tiempo de propagar las muestras, pero ambas añaden latencia.

El segundo riesgo es el propio modo de fallo de la codificación de borrado. Si un error o una equivocación de implementación hace que la codificación sea inconsistente entre clientes, unos nodos ligeros honestos podrían rechazar bloques válidos o aceptar otros no disponibles. En parte por eso el diseño depende de los compromisos KZG, que pueden demostrar que celdas individuales son coherentes con el encabezado, y por eso se ejecutan testnets extensas, devnets como da-dedi, inspirado en Celestia, y el trabajo de EIP-7591, antes del despliegue en mainnet.

El tercer riesgo es la centralización en torno a la infraestructura. Aunque en papel los requisitos para un nodo ligero sean mínimos, los requisitos reales para un validador completo, los que de verdad proponen y atestiguan bloques, siguen aumentando. Si los stakers individuales se retiran porque las tareas de attestación requieren hardware sofisticado, la red se vuelve más centralizada, por muy baratos que sean los light clients.

Por último, existe el riesgo social de venderlo en exceso. La frase "escalabilidad ilimitada" se asocia a menudo con DAS, y eso es गलत incorrecto. La codificación de borrado duplica aproximadamente la huella de datos, así que hay un coste real. El muestreo solo verifica la disponibilidad, no permite mágicamente que la red procese más ejecución. Los rollups siguen pagando la ejecución en otro lugar, y los límites de rendimiento siguen ahí, solo que a un nivel mucho más alto que hoy.

Por qué Celestia, EigenDA y Avail se parecen

Ethereum no es el único equipo que apuesta por el muestreo de disponibilidad de datos. Celestia se lanzó a finales de 2023 como una blockchain independiente cuyo único cometido es ser una capa de disponibilidad de datos. Usa la misma receta de DAS y codificación de borrado: los datos se codifican en una cuadrícula 2D, los nodos ligeros muestrean celdas aleatorias y un compromiso de estilo KZG ancla toda la cuadrícula.

La propuesta es que los rollups y las app-chains no tienen por qué vivir en Ethereum en absoluto. Pueden publicar sus datos en Celestia, pagar comisiones de Celestia y usar Ethereum, o cualquier otra capa de liquidación, solo para pruebas de fraude o de validez. Celestia se posiciona como una pieza modular de blockchain, más que como una plataforma de smart contracts.

EigenDA tiene una forma distinta. Es un servicio de disponibilidad de datos construido sobre EigenLayer, que permite a los stakers de ETH optar por proteger servicios adicionales haciendo restaking de su colateral. La afirmación de EigenDA es que hereda la seguridad económica de Ethereum, porque los operadores que ejecutan su red de almacenamiento también son validadores de Ethereum con una exposición real a slashing.

Avail, que originalmente se escindió de Polygon, toma un tercer camino: se posiciona como una capa de disponibilidad de datos que puede servir a muchas cadenas, incluidas las que no son de Ethereum, y usa un esquema distinto de compromisos polinómicos, en el que los compromisos Kate pueden sustituirse o complementarse con otros diseños, para mantener la flexibilidad. Polygon ha lanzado su propia cadena Polygon POS, que históricamente usaba un enfoque diferente, mientras que los rollups más nuevos de "Polygon CDK" son libres de elegir cualquier capa de DA.

¿Por qué se molesta Ethereum en construir la suya propia? Por dos razones. Primero, la comunidad de Ethereum quiere una seguridad de DA respaldada por stakers de ETH en lugar de por un token separado, lo que mantiene los supuestos de confianza de un rollup de Ethereum dentro del ecosistema Ethereum. Segundo, la competencia es saludable. Saber que Celestia existe obliga a los investigadores de Ethereum a entregar resultados, y viceversa.

Qué significa esto para ti como usuario o constructor

Si solo estás haciendo transacciones en Ethereum o en un rollup, el danksharding se refleja principalmente en comisiones más baratas. Una vez que los blobs sean abundantes y baratos, los rollups podrán publicar lotes más grandes y reducir aún más el gas. Las cifras exactas dependen de la dinámica del mercado de comisiones de blobs y de las mejoras de compresión de los rollups, pero el impacto direccional es real: las transacciones de rollups que ya cuestan unos pocos céntimos pueden caer a fracciones de céntimo con recuentos altos de blobs.

Si eres desarrollador y estás eligiendo una pila de rollup, la nueva decisión es qué capa de DA usar. Las opciones ahora incluyen Ethereum nativo, después del danksharding completo, Celestia, EigenDA y Avail, cada una con diferentes supuestos de coste, seguridad y puentes. Un rollup en Celestia no está tan profundamente ligado a los stakers de ETH, pero puede ser más barato y flexible. Un rollup en EigenDA hereda la seguridad de ETH en restaking, pero solo está tan descentralizado como el conjunto de operadores de EigenLayer. No hay almuerzos gratis.

Si eres staker o validador doméstico, el mensaje práctico es más tranquilizador que alarmante. Los requisitos de los clientes ligeros siguen siendo bajos, por lo que el umbral de hardware del día a día no sube como lo haría con aumentos ingenuos del tamaño de bloque. Los requisitos de attestations aún pueden aumentar, pero a un ritmo más controlado, y mejoras como la separación proposer-builder consagrada buscan reducir la carga operativa.

Lo que no deberías hacer es asumir que el danksharding está "terminado". A principios de 2026 sigue en testnets, con EIP-7591, PeerDAS, un paso intermedio, como despliegue a corto plazo y el danksharding completo más adelante. Tratar cualquier calendario como garantizado es una receta para la decepción.

Mantente al día de la hoja de ruta de escalado de Ethereum

El danksharding, DAS, las comisiones de blobs y las capas competidoras de disponibilidad de datos avanzan rápido, y la cobertura fiable está dispersa entre foros de investigación, borradores de EIP y llamadas de desarrolladores principales. Zippfeed agrega titulares sobre el escalado de Ethereum con puntuación de sentimiento (bullish, neutral, or bearish) y una valoración de importancia, para que puedas distinguir qué hitos de protocolo realmente marcan la diferencia y cuáles son solo republicaciones.