Artículo: imToken
A finales de 2025, la comunidad de Ethereum acogió con relativa calma la conclusión de la actualización Fusaka.
Mirando hacia atrás en el último año, aunque las discusiones sobre las actualizaciones tecnológicas subyacentes han ido perdiendo protagonismo en el mercado, muchos usuarios en la cadena ya han sentido un cambio notable: cada vez más barato es el uso de L2 en Ethereum.
Actualmente, las interacciones en la cadena, ya sea para transferencias o operaciones complejas de DeFi, suelen costar solo unos pocos centavos de dólar o incluso ser insignificantes. Detrás de esto, la actualización Dencun y el mecanismo Blob han sido fundamentales, pero al mismo tiempo, con la activación oficial de la característica central PeerDAS (Peer Data Availability Sampling, muestreo de disponibilidad de datos punto a punto) en la actualización Fusaka, Ethereum está diciendo adiós a la era de la validación de datos mediante “descarga completa”.
Se puede decir que, lo que realmente determina si Ethereum puede soportar aplicaciones a gran escala de forma sostenible a largo plazo, no es solo Blob en sí, sino el siguiente paso que representa PeerDAS.
1. ¿Qué es PeerDAS?
Para entender el significado revolucionario de PeerDAS, no basta con hablar de conceptos vacíos; primero hay que retroceder a un nodo clave en la expansión de Ethereum, la actualización Dencun de marzo de 2024.
En ese momento, EIP-4844 introdujo un modelo de transacciones que llevan Blob (incorporando grandes cantidades de datos de transacción en blobs), permitiendo que las L2 ya no dependieran del costoso mecanismo de almacenamiento calldata, sino que usaran almacenamiento temporal en blobs.
Este cambio redujo los costos de Rollup a una décima parte de los anteriores, garantizando que las plataformas L2 puedan ofrecer transacciones más baratas y rápidas sin comprometer la seguridad y descentralización de Ethereum, y también permitió a los usuarios disfrutar de la “era de tarifas de gas bajas”.
Sin embargo, aunque los blobs son muy útiles, el número de blobs que puede soportar cada bloque en la red principal de Ethereum tiene un límite rígido (normalmente entre 3 y 6). La razón es muy práctica: el ancho de banda físico y los discos duros son limitados.
En el modo de validación tradicional, cada validador en la red, ya sea un servidor operado por una institución profesional o una computadora doméstica común, debe descargar y propagar todos los datos de blobs completos para verificar su validez.
Esto genera un dilema:
- Si aumentamos la cantidad de blobs (para escalar): el volumen de datos se dispara, el ancho de banda de los nodos domésticos se saturará, los discos se llenarán, y se verán obligados a desconectarse, lo que acelerará la centralización de la red, convirtiéndola en una cadena dominada por grandes centros de datos;
- Si limitamos la cantidad de blobs (para mantener la descentralización): la capacidad de procesamiento de las L2 se quedará estancada, incapaz de responder a un crecimiento explosivo futuro.
En definitiva, los blobs solo dieron el primer paso, resolviendo el problema de “dónde guardar los datos”. Cuando la cantidad de datos es pequeña, todo funciona bien, pero si en el futuro la cantidad de Rollups continúa creciendo y cada uno envía datos a alta frecuencia, y la capacidad de blobs aumenta, la presión sobre el ancho de banda y el almacenamiento de los nodos se convertirá en un nuevo riesgo de centralización.
Si seguimos usando el modo tradicional de descarga completa, no podremos resolver la presión del ancho de banda, y el camino de expansión de Ethereum se topará con un muro físico. PeerDAS es precisamente la llave para romper ese callejón sin salida.
En una frase, PeerDAS es una arquitectura de validación de datos completamente nueva que rompe la regla de que la validación debe ser mediante descarga completa, permitiendo que la expansión de blobs supere el nivel actual de capacidad física (por ejemplo, de 6 blobs por bloque a 48 o más).
2. Blob resuelve “dónde guardar”, PeerDAS resuelve “cómo almacenar”
Como se mencionó anteriormente, los blobs dieron el primer paso en la expansión, resolviendo el problema de “dónde guardar los datos” (pasando del costoso calldata al espacio temporal de blobs), y ahora PeerDAS debe resolver “cómo almacenar de manera más eficiente”.
Su núcleo es cómo, ante la explosión exponencial de datos, no sobrecargar el ancho de banda físico de los nodos. La idea es sencilla: basada en probabilidades y colaboración distribuida, “no es necesario que todos almacenen toda la información, sino que con una alta probabilidad se puede confirmar que los datos existen realmente”.
Este concepto se refleja en el nombre completo de PeerDAS: “muestreo de disponibilidad de datos punto a punto”.
Puede parecer abstracto, pero podemos entender esta transferencia de paradigma con una metáfora sencilla: en la validación completa anterior, era como si en una biblioteca se añadiera una enciclopedia de miles de páginas (los datos de blobs). Para evitar pérdidas, cada administrador (nodo) debía copiar una copia completa del libro como respaldo.
Eso significaba que solo quienes tenían recursos (ancho de banda / discos duros grandes) podían ser administradores, y dado que la enciclopedia seguía creciendo, la descentralización se veía amenazada, eliminando a los usuarios comunes.
Ahora, con la muestreo basada en PeerDAS, y usando técnicas como codificación de borrado (Erasure Coding), es como si esa enciclopedia se dividiera en innumerables fragmentos, codificados matemáticamente. Cada administrador ya no necesita tener el libro completo, sino que puede tener solo unos pocos fragmentos aleatorios.
Incluso para verificar, no es necesario que alguien muestre el libro completo; en teoría, si la red obtiene cualquier 50% de los fragmentos (independientemente de quién tenga qué), mediante algoritmos matemáticos se puede reconstruir toda la enciclopedia con certeza del 100%.
Este es el poder de PeerDAS: reducir la carga de descarga de datos en un solo nodo, dispersándola en una red de miles de nodos colaborativos.
Fuente: @Maaztwts
Desde una perspectiva de datos, antes de la actualización Fusaka, el número de blobs estaba restringido a unos pocos (3-6). Con la implementación de PeerDAS, esa limitación se rompe, permitiendo que el número de blobs pase de 6 a 48 o más.
Cuando un usuario realiza una transacción en Arbitrum o Optimism y los datos se envían de vuelta a la cadena principal, ya no es necesario difundir en toda la red un paquete completo de datos, lo que hace que la expansión de Ethereum no dependa linealmente del aumento de nodos.
En conjunto, Blob + PeerDAS constituyen la solución completa de disponibilidad de datos (DA). Desde la hoja de ruta, esto también marca la transición clave de Ethereum desde Proto-Danksharding hacia Danksharding completo.
3. La nueva normalidad en la cadena tras Fusaka
Como es sabido, en los últimos años, capas de DA modulares de terceros como Celestia han ganado mucho mercado debido a los altos costos de almacenamiento en la cadena principal de Ethereum. Su narrativa se basa en que el almacenamiento nativo de datos en Ethereum es muy caro.
Pero con Blob y la más reciente PeerDAS, Ethereum se ha vuelto no solo más barato, sino también extremadamente seguro: el costo de publicar datos de L2 en L1 se ha reducido a la mitad, y Ethereum cuenta con la mayor red de validadores del mundo, superando ampliamente a cadenas de terceros en seguridad.
Desde un punto de vista objetivo, esto representa un golpe de gracia para soluciones como Celestia, marcando que Ethereum está recuperando la soberanía sobre la disponibilidad de datos y reduciendo significativamente su espacio de supervivencia.
Quizá te preguntes, ¿todo esto suena muy técnico y qué relación tiene con usar la wallet, transferencias o DeFi?
La relación es muy directa. Si PeerDAS se implementa con éxito, los costos de datos de las L2 podrán mantenerse bajos a largo plazo, y las Rollups no tendrán que subir tarifas por costos de DA, permitiendo que las aplicaciones en cadena diseñen interacciones de alta frecuencia sin tener que comprometer entre funcionalidad y costo…
En otras palabras, que podamos usar L2 baratos hoy se debe a Blob, y si en el futuro podemos seguir usándolos, será gracias a la contribución silenciosa de PeerDAS.
Por eso, en la hoja de ruta de expansión de Ethereum, aunque PeerDAS pasa desapercibido, siempre se considera un paso imprescindible. En esencia, es la mejor forma técnica a ojos del autor: “Beneficio sin sentirlo, pérdida y será difícil mantenerlo”, haciendo que su presencia pase desapercibida.
En definitiva, PeerDAS demuestra que la cadena de bloques puede, mediante diseños matemáticos ingeniosos (como muestreos de datos), soportar cantidades masivas de datos a nivel Web2 sin sacrificar demasiado la visión de descentralización.
Con esto, la autopista de datos de Ethereum está completamente pavimentada. Lo que venga en esta vía, en la capa de aplicaciones, será la próxima pregunta a responder.
Mantengámonos atentos.
