4844

¿Qué es 4844?

4844 hace referencia a la propuesta EIP-4844 de Ethereum, conocida también como Proto-Danksharding. Se activó con la actualización Dencun en la red principal, incorporando un mecanismo de “publicación de datos” más eficiente en costes para las redes de Capa 2.

En el ecosistema de Ethereum, las soluciones de Capa 2 (L2) actúan como autopistas elevadas que desvían grandes volúmenes de tráfico. Los rollups son la L2 más extendida, ya que agrupan múltiples transacciones de usuarios y las publican en la red principal de Ethereum para garantizar la seguridad. EIP-4844 introduce un nuevo canal de datos “Blob”, que hace esta publicación de datos más económica y escalable.

¿Por qué 4844 reduce los costes en L2?

Antes, los rollups almacenaban sus datos de transacción en el “calldata” de Ethereum, compitiendo por los mismos recursos que la ejecución de contratos inteligentes y elevando los precios. EIP-4844 traslada estos datos “de corta duración” a un “mercado de tarifas de Blob” independiente, haciendo que los costes sean más previsibles y sencillos de gestionar.

Piense en el calldata como un “tablón de anuncios permanente”, mientras que los Blobs serían “tableros temporales que se vacían periódicamente”. Como los rollups solo necesitan garantizar la disponibilidad de los datos durante un tiempo limitado, los Blobs resultan suficientes y más baratos, aumentando la capacidad global de la red.

¿Qué es un Blob en 4844?

Un Blob es un gran bloque de datos asociado a un tipo especial de transacción, utilizado exclusivamente para publicar y acreditar información. Los Blobs no pueden ser leídos directamente por los contratos inteligentes de Ethereum (EVM); su integridad y disponibilidad se garantizan mediante mecanismos de compromiso y verificación.

Los datos Blob se almacenan temporalmente en la red y los nodos los eliminan pasado un tiempo, reduciendo la necesidad de almacenamiento permanente. Esto se ajusta a los rollups, que solo requieren acceso a datos históricos durante periodos de disputa o repetición.

¿Cómo funciona 4844 en Ethereum?

4844 introduce un nuevo tipo de transacción capaz de transportar datos Blob. Cada bloque tiene un límite de Blobs incluidos y el precio se determina en un mercado específico que se ajusta dinámicamente según oferta y demanda.

Cuando los usuarios o rollups envían transacciones con Blobs, los validadores verifican los compromisos asociados y cobran las tarifas correspondientes. Este diseño separa los “costes de disponibilidad de datos” de los “costes de ejecución de contratos”, evitando la competencia por recursos y estabilizando los gastos de publicación de datos en L2.

La EVM no puede acceder directamente al contenido de los Blobs; las aplicaciones confían en pruebas de compromiso para verificar que el Blob se ha publicado correctamente. Así se reduce la carga de almacenamiento a largo plazo, manteniendo una ventana de auditoría para recuperación y verificación de datos.

¿Cómo afecta 4844 a los rollups?

4844 abarata notablemente la publicación de datos para los rollups, permitiendo lotes mayores y empaquetados más flexibles, lo que mejora la experiencia del usuario con comisiones más bajas y confirmaciones más rápidas. Desde la actualización Dencun en marzo de 2024, las comisiones principales en L2 han caído drásticamente y se han mantenido bajas (véase: notas de actualización de Ethereum.org y paneles de comisiones comunitarios, desde marzo de 2024).

Para los operadores, unas comisiones más estables y mayor ancho de banda de datos permiten atender a más usuarios y aplicaciones avanzadas, como trading de alta frecuencia, acuñación de NFT o interacciones en juegos, con mayor resiliencia en picos de demanda.

¿Cómo puedes ahorrar en L2 con 4844?

Para aprovechar los menores costes de EIP-4844, el principio es interactuar on-chain en L2 de Ethereum compatibles con Blobs, prestando atención a los métodos de depósito/retiro y la gestión de riesgos.

Paso 1: Prepara tu wallet. Usa una wallet popular y actualizada para asegurar la compatibilidad con redes L2 y formatos de firma. Los principiantes pueden añadir el endpoint RPC y el chain ID de la L2 deseada en la configuración.

Paso 2: Deposita y retira desde Gate. Transfiere fondos desde Gate a tu dirección L2 seleccionando el canal de red adecuado en la página de retiro, normalmente con comisiones más bajas. Para depósitos, aplica el proceso inverso; verifica siempre red y dirección, y prueba primero con una pequeña cantidad para evitar pérdidas por errores.

Paso 3: Interactúa en L2. Realiza transferencias, operaciones en DEX o acuñación de NFT en la L2 elegida, normalmente con comisiones más bajas y confirmaciones más rápidas. En periodos de alta demanda, considera pagar comisiones superiores o transaccionar fuera de horas punta.

Paso 4: Supervisa paneles de comisiones. Consulta paneles oficiales o comunitarios de comisiones en L2, detectando posibles picos temporales en el precio de los Blobs por congestión y planifica tus transacciones para optimizar costes.

Paso 5: Ten en cuenta los tiempos de espera en bridges. Los bridges oficiales de distintas L2 pueden tener retrasos en los retiros; en casos urgentes, puedes usar bridges de terceros de confianza, pero evalúa siempre el riesgo de contraparte y las comisiones adicionales.

Advertencia de riesgo: Todas las transferencias y firmas on-chain implican riesgos irreversibles. Verifica siempre redes, contratos y direcciones; empieza con pequeñas cantidades para minimizar posibles pérdidas.

¿En qué se diferencia 4844 de sharding y calldata?

Frente al calldata, los Blobs en 4844 cuentan con su propio mercado de tarifas, se almacenan temporalmente y no pueden ser leídos directamente por la EVM, lo que los hace óptimos para datos de rollup que solo requieren disponibilidad a corto plazo y generalmente a un coste inferior.

A diferencia del sharding completo, 4844 es una solución intermedia (Proto-Danksharding). No divide Ethereum en shards de ejecución paralela, sino que amplía el ancho de banda de datos en la estructura existente y añade precios independientes, sentando las bases para el futuro Danksharding y el muestreo de disponibilidad de datos.

¿Cuáles son los riesgos y limitaciones de 4844?

EIP-4844 no reduce directamente los costes de ejecución de contratos inteligentes en Ethereum Layer 1; los contratos complejos siguen siendo costosos en L1. Si la demanda de Blobs sube bruscamente, los precios pueden aumentar temporalmente, provocando cierta volatilidad en las comisiones de L2.

Los datos Blob solo se almacenan en la red durante un tiempo limitado antes de ser eliminados, por lo que los rollups y operadores de nodos deben archivar los datos necesarios en otros lugares. Wallets, navegadores o herramientas pueden diferir en la rapidez de actualización para ser compatibles; los primeros usuarios pueden experimentar discrepancias en la visualización o en los avisos de firma.

Además, 4844 no modifica el modelo de seguridad fundamental de los rollups ni los tiempos de retiro en bridges. Los usuarios deben vigilar los riesgos en bridges cross-chain, actualizaciones de contratos y gestión de permisos.

¿Qué viene después para 4844?

EIP-4844 es un paso esencial hacia el Danksharding completo. Los siguientes pasos incluyen aumentar el límite de Blobs por bloque, optimizar los mecanismos de ajuste de tarifas y avanzar en tecnologías como Data Availability Sampling (DAS) para ampliar aún más el ancho de banda y la participación de nodos.

En el ámbito de las aplicaciones, más L2 optimizarán sus estrategias de agrupamiento en torno a una disponibilidad de datos (DA) más barata, facilitando aplicaciones on-chain de alta frecuencia y en tiempo real. Las capas alternativas de disponibilidad de datos se seguirán desarrollando en paralelo a la hoja de ruta de Ethereum, creando un ecosistema multinivel.

Conclusiones clave de 4844

EIP-4844 proporciona un canal de almacenamiento temporal y más económico para la publicación de datos de rollups, al separar los “costes de disponibilidad de datos” de los “costes de ejecución de contratos”. Esto mejora de forma significativa las comisiones y la capacidad de Layer 2, y allana el camino hacia el Danksharding completo. Para los usuarios: mover las interacciones a L2 compatibles con Blobs, elegir los canales de depósito/retiro adecuados a través de Gate y seguir buenas prácticas de gestión de riesgos ayuda a garantizar menores costes y una mejor experiencia.

Preguntas frecuentes

¿Se almacenarán los datos Blob permanentemente on-chain?

No. Los datos Blob permanecen on-chain durante unos 18 días antes de eliminarse automáticamente. Este almacenamiento temporal cumple los requisitos de disponibilidad de datos en L2 y ahorra espacio en los nodos completos. Los proyectos L2 pueden archivar los datos históricos necesarios antes de que caduquen los Blobs para garantizar la trazabilidad.

¿Por qué los Blobs son mucho más baratos que el calldata?

Los Blobs tienen un mecanismo de precios de gas propio, con precios iniciales bajos y sin competir con la ejecución de contratos por el espacio de gas. El calldata debe ser almacenado y ejecutado permanentemente por todos los nodos, lo que lo encarece, mientras que los Blobs solo se almacenan durante 18 días con un mercado de gas separado. Este diseño permite reducir los costes de transacción en L2 en más de un 90 %.

Si opero en una L2, ¿notaré comisiones más bajas gracias a 4844?

Sí. Siempre que la L2 elegida implemente la publicación de datos mediante Blobs, se beneficiará directamente de comisiones de transacción mucho más bajas. L2 líderes como Arbitrum y Optimism ya admiten Blobs; los nuevos usuarios pueden transferir activos desde plataformas como Gate a estas L2 para operar a bajo coste.

¿Por qué cada Blob tiene un tamaño fijo de 128 KB?

Este tamaño responde al equilibrio de Ethereum entre capacidad y requisitos de recursos para los nodos. Un Blob de 128 KB reduce de manera significativa los costes en L2 sin sobrecargar la verificación o el almacenamiento de los nodos. El tamaño podría ajustarse en función de la evolución de la red, pero actualmente ha demostrado ser eficaz.

¿4844 afecta a las transacciones en la red principal de Ethereum?

Muy poco. EIP-4844 optimiza principalmente las transacciones en Layer 2; las transacciones en la red principal no utilizan Blobs. Sin embargo, al reducir drásticamente los costes en L2, incentiva la migración de usuarios de la red principal hacia L2, ayudando a descongestionar la red principal como parte de la estrategia de escalabilidad de Ethereum.