4 844

4844 es una pieza clave de la actualización Dencun de Ethereum (conocida anteriormente como EIP-4844), desplegada el 13 de marzo de 2024. Supone un avance fundamental en la hoja de ruta de escalabilidad de Ethereum al incorporar mecanismos de almacenamiento temporal de datos llamados blobs (binary large objects), que permiten reducir notablemente los costes de las soluciones de capa 2 como Optimistic Rollups y ZK-Rollups. Esta actualización, también denominada Proto-Danksharding, representa una fase intermedia hacia el Danksharding completo (tecnología de sharding integral), aportando mayor disponibilidad de datos y comisiones de transacción más bajas en la red de Ethereum gracias a nuevos tipos de transacciones y métodos de gestión de datos.

Antecedentes: El origen de 4844

4844 nace de la Propuesta de Mejora de Ethereum EIP-4844, presentada en 2021 por desarrolladores principales de Ethereum como Vitalik Buterin y Dankrad Feist. Esta propuesta fue diseñada para abordar las altas comisiones de transacción de Ethereum, especialmente mediante la introducción de un mecanismo de publicación de datos más eficiente en costes para soluciones de escalado de capa 2.

En la hoja de ruta de escalabilidad de Ethereum, el sharding es una solución a largo plazo, pero su despliegue completo aún llevará varios años. Proto-Danksharding actúa como fase transitoria, permitiendo a los desarrolladores aprovechar mejoras parciales de escalabilidad sin esperar a la implantación total del sharding.

La comunidad de Ethereum sometió 4844 a exhaustivas pruebas y revisiones desde su propuesta hasta la implementación, con múltiples despliegues y validaciones en redes de prueba antes de su llegada definitiva a la red principal con la actualización Dencun. Este proceso refleja el enfoque meticuloso de la comunidad de Ethereum para evolucionar técnicamente, asegurando la seguridad de la red al tiempo que se avanza en escalabilidad.

Mecanismo de funcionamiento: así opera 4844

La principal innovación de 4844 consiste en la introducción de un nuevo tipo de transacción—las transacciones que transportan blobs—y en los mecanismos específicos para su procesamiento:

1. Estructura de datos blob: Los blobs son paquetes de datos de gran tamaño que se almacenan en la blockchain sin conservarse de forma permanente, pensados para soluciones de capa 2 y capaces de contener hasta 125 KB de datos.

2. Disponibilidad y periodo de validez de los datos: Los datos de los blobs están accesibles para validadores y participantes de la red durante aproximadamente 1-2 semanas; transcurrido ese tiempo, la red los elimina automáticamente. Esta temporalidad equilibra la disponibilidad de datos y la presión sobre el almacenamiento.

3. Mecanismo de tarificación: 4844 introduce un sistema de precios independiente de las comisiones de gas de la red principal de Ethereum, ajustando automáticamente los costes en función de un volumen objetivo de datos, lo que posibilita que las soluciones de capa 2 publiquen datos de forma más predecible y barata.

4. Verificación criptográfica: Cada blob se verifica mediante compromisos KZG (Kate-Zaverucha-Goldberg), un método criptográfico que garantiza la integridad de los datos sin obligar a todos los nodos a descargar el blob completo.

5. Separación del entorno de ejecución: Los datos de los blobs se mantienen fuera de la capa de ejecución de Ethereum (EVM), sin intervenir directamente en la ejecución de smart contracts, pero actuando como capa de disponibilidad de datos para las soluciones de capa 2.

Este diseño permite a las soluciones de capa 2 publicar sus pruebas y datos de transacción en la red principal de Ethereum reduciendo considerablemente los costes, lo que se traduce en experiencias de transacción más económicas para el usuario final.

¿Qué riesgos y desafíos plantea 4844?

Aunque 4844 aporta grandes ventajas al ecosistema de Ethereum, también enfrenta ciertos riesgos y retos:

1. Complejidad técnica: La incorporación de nuevos tipos de transacciones y estructuras de datos añade complejidad al sistema, lo que puede dar lugar a vulnerabilidades o riesgos de seguridad aún no detectados.

2. Presión sobre los recursos de red: Si bien los datos de blobs son temporales, un alto volumen de transacciones de blobs puede generar presión a corto plazo sobre el almacenamiento y el ancho de banda de los nodos, en especial para validadores con recursos limitados.

3. Adaptación del ecosistema: Los proyectos de capa 2, los proveedores de monederos y los servicios de infraestructura necesitan realizar ajustes técnicos para sacar el máximo partido a las transacciones de blobs, un proceso que podría no ser completamente fluido.

4. Incertidumbre en el mecanismo de precios: El nuevo sistema de tarifas para blobs puede enfrentar desafíos inesperados en la práctica, como volatilidad en los precios o problemas de adaptación al mercado.

5. Transición al Danksharding completo: Proto-Danksharding es solo una etapa intermedia, y el futuro paso al sharding completo podría suponer nuevos retos técnicos y costes de coordinación adicionales.

Además, como actualización mayor de la red Ethereum, cualquier problema en la implementación puede tener un impacto considerable en todo el ecosistema. Es imprescindible una supervisión y mejora continuas por parte de la comunidad.

4844, como hito esencial en la hoja de ruta de escalabilidad de Ethereum, representa un avance decisivo en la superación del “triángulo imposible” de la blockchain. Al introducir transacciones de blobs y almacenamiento temporal de datos, 4844 reduce de manera efectiva los costes de las soluciones de capa 2, permitiendo que la red Ethereum abarque escenarios de uso más amplios y una base de usuarios mayor. Para los usuarios habituales, esto supone comisiones de transacción más bajas y experiencias más ágiles; para los desarrolladores, brinda la infraestructura necesaria para crear aplicaciones escalables de manera eficiente. Conforme más proyectos de capa 2 adopten y aprovechen plenamente esta tecnología, la capacidad total de procesamiento del ecosistema Ethereum crecerá significativamente, sentando las bases para la adopción masiva de aplicaciones Web3.