Dencun: la actualización de Ethereum de marzo de 2024
Dencun en Ethereum: qué cambió en marzo de 2024, las nueve EIP incluidas y por qué los blobs afectan al coste de las Layer 2.

Dencun fue una actualización de Ethereum activada el 13 de marzo de 2024. Introdujo una vía específica para publicar los datos que utilizan los rollups y varios cambios en ejecución y consenso. Su aportación principal fue separar parte del coste de disponibilidad de datos del mercado de ejecución habitual.
Para entender su efecto conviene distinguir tres cosas: ejecutar una transacción, publicar los datos necesarios para verificarla y conservar esos datos a largo plazo. Dencun modificó especialmente la segunda. No convirtió las operaciones en gratuitas ni garantizó una tarifa fija para todas las Layer 2. Reducir ese coste puede mejorar la economía de operación de los rollups; el efecto para el usuario depende también del resto de costes de cada red.
Qué significa Dencun y cuándo se activó
El nombre combina Cancun, correspondiente a la capa de ejecución, y Deneb, correspondiente a la de consenso. La activación se programó para la época 269568, el 13 de marzo de 2024 a las 13:55 UTC. Los operadores de nodos debían utilizar clientes compatibles en ambas capas.
Los titulares de ETH no tenían que canjear monedas por un nuevo activo. La actualización cambió reglas del protocolo. Es distinta de The Merge, que completó el paso a prueba de participación en septiembre de 2022, y de Shapella, que habilitó retiradas de validadores en abril de 2023.
EIP-4844: datos para los rollups
Un rollup ejecuta operaciones fuera de la capa base y necesita publicar datos que permitan comprobar o reconstruir su actividad según su diseño. Antes de Dencun, una vía utilizada era calldata en transacciones de Ethereum. EIP-4844 añadió transacciones que transportan referencias a blobs, con un mercado de comisiones específico para esos datos.
Los blobs no son contratos ni nuevas cadenas que ejecutan operaciones en paralelo. Su contenido se distribuye por la capa de consenso y no es directamente accesible como datos ordinarios desde la EVM. La ejecución dispone de referencias criptográficas y mecanismos de comprobación definidos por la propuesta.
La disponibilidad requerida por el protocolo es temporal. Una aplicación que necesite recuperar históricos más adelante debe organizar su conservación. Un compromiso criptográfico permite comprobar datos disponibles; no reconstruye por sí solo un archivo que nadie conserva.
La guía de EIP-4844 profundiza en la relación entre blobs, costes y disponibilidad. Aquí importa situarlo dentro del conjunto de cambios de Dencun.
Las nueve propuestas incluidas
EIP-4844 incorporó las transacciones con blobs y su contabilidad de gas. EIP-7516 añadió BLOBBASEFEE, una instrucción que permite consultar desde la EVM la comisión base de blobs del bloque. No debe confundirse con la comisión base del gas de ejecución.
EIP-1153 introdujo almacenamiento transitorio mediante TSTORE y TLOAD. Su estado pertenece a la transacción y se descarta al terminar; no sustituye al almacenamiento persistente. Puede servir para coordinar llamadas dentro de una operación, siempre que el contrato se diseñe con esas reglas.
EIP-5656 añadió MCOPY para copiar memoria. Es una instrucción de la EVM; aprovecharla depende del código y de las herramientas de compilación. La actualización no reescribe automáticamente todos los contratos desplegados para usarla.
EIP-4788 expuso raíces de bloques de la beacon chain mediante un contrato accesible desde ejecución. Esto permite construir verificaciones sobre datos de consenso, con las pruebas y controles correspondientes. No convierte cualquier dato externo en información verificada por Ethereum.
EIP-6780 cambió SELFDESTRUCT. Fuera de la transacción en la que se creó el contrato, la instrucción deja de eliminar su código y almacenamiento, aunque conserva la transferencia del saldo de ether al destinatario. La excepción de creación y destrucción en la misma transacción mantiene el comportamiento previo definido en la propuesta.
EIP-7044 hizo que las salidas voluntarias firmadas bajo las condiciones de Deneb siguieran siendo válidas tras futuras actualizaciones. EIP-7045 amplió la ventana de inclusión de attestations hasta el final de la época siguiente a aquella en la que se emitieron.
EIP-7514 introdujo un límite máximo de ocho activaciones de validadores por época en aquel diseño. Es un parámetro histórico de Dencun, no una descripción completa del mecanismo de entrada vigente tras todas las actualizaciones posteriores.
Por qué puede reducir costes en una Layer 2
El precio final de una operación L2 puede incluir ejecución local, publicación de datos, infraestructura y la política de comisiones del operador. Abaratar un componente puede reducir el total, pero la proporción depende del tipo de operación y del uso de la red.
En un ejemplo ficticio, una transacción cuesta 0,10 €: 0,06 € corresponden a publicación de datos y 0,04 € al resto. Si el primer componente baja a 0,01 € y todo lo demás permanece igual, el total pasa a 0,05 €. Es una reducción del 50 %, no del 83 % que experimentó únicamente el componente de datos. El ejemplo explica la comparación; no representa una tarifa observada.
El mercado de blobs también responde a demanda y capacidad. Por eso no es riguroso atribuir a Dencun un porcentaje universal y permanente de ahorro. Para medirlo, compara operaciones equivalentes, fechas, moneda y componentes de comisión.
Qué no cambió automáticamente
Dencun no eliminó secuenciadores, permisos de actualización ni riesgos de puentes de las Layer 2. Publicar datos en Ethereum es una propiedad concreta del diseño; las garantías de una aplicación también dependen de validación, disponibilidad, pruebas y mecanismos de salida.
Tampoco prometió comisiones bajas para cualquier operación en la capa base. Una transferencia o llamada ordinaria sigue compitiendo por recursos de ejecución. La capacidad de datos para rollups y la capacidad de ejecutar contratos son dimensiones distintas.
Qué debe revisar un equipo técnico
Comprueba que compilador, entorno de pruebas y red objetivo admiten las instrucciones utilizadas. Un bytecode compilado para un hard fork más reciente puede fallar en una red que aún no lo soporte, aunque ambas se describan como compatibles con EVM.
Para integraciones L2, identifica cómo se publican y recuperan los datos, qué coste se repercute al usuario y qué ocurre si falla el secuenciador o el archivo histórico. La mejora de infraestructura resulta útil cuando el producto entiende esas condiciones y las refleja correctamente en su operación.
¿Tienes un proyecto blockchain en mente?
De la idea al producto, estrategia y tecnología deben avanzar juntas.







