Una cronología de todos los principales hitos, bifurcaciones y actualizaciones de la cadena de bloques de Ethereum.
Las bifurcaciones ocurren cuando se necesitan realizar actualizaciones o cambios técnicos importantes en la red; por lo general, provienen de las Propuestas de mejora de Ethereum (EIP) y cambian las "reglas" del protocolo.
Cuando se necesitan actualizaciones en el software tradicional controlado de forma centralizada, la empresa simplemente publica una nueva versión para el usuario final. Las cadenas de bloques funcionan de manera diferente porque no hay una propiedad central. Los clientes de Ethereum deben actualizar su software para implementar las nuevas reglas de la bifurcación. Además, los creadores de bloques (mineros en un entorno de prueba de trabajo (PoW), validadores en un entorno de prueba de participación (PoS)) y los nodos deben crear bloques y validarlos según las nuevas reglas. Más sobre los mecanismos de consenso
Estos cambios en las reglas pueden crear una división temporal en la red. Se podrían producir nuevos bloques de acuerdo con las nuevas reglas o las antiguas. Las bifurcaciones generalmente se acuerdan con anticipación para que los clientes adopten los cambios al unísono y la bifurcación con las actualizaciones se convierta en la cadena principal. Sin embargo, en casos raros, los desacuerdos sobre las bifurcaciones pueden hacer que la red se divida permanentemente, siendo el caso más notable la creación de Ethereum Classic con la bifurcación DAO.
El software subyacente de Ethereum está compuesto por dos mitades, conocidas como la y la .
Nomenclatura de las actualizaciones de ejecución
Desde 2021, las actualizaciones de la capa de ejecución se nombran según los nombres de las ciudades de las ubicaciones anteriores de Devcon y Devconnect (opens in a new tab) en orden cronológico:
| Nombre de la actualización | Año de Devcon(nect) | Número de Devcon | Fecha de actualización |
|---|---|---|---|
| Berlín | 2014 | 0 | 15 de abr. de 2021 |
| Londres | 2015 | I | 5 de ago. de 2021 |
| Shanghái | 2016 | II | 12 de abr. de 2023 |
| Cancún | 2017 | III | 13 de mar. de 2024 |
| Praga | 2018 | IV | 7 de may. de 2025 |
| Osaka | 2019 | V | 3 de dic. de 2025 |
| Ámsterdam | 2022 | Devconnect | Por determinar - Siguiente |
| Bogotá | 2022 | VI | Por determinar |
| Istanbul | 2023 | Devconnect | Por determinar |
| Bangkok | 2024 | VII | Por determinar |
| Buenos Aires | 2025 | Devconnect | Por determinar |
| Mumbai | 2026 | VIII | Por determinar |
Nomenclatura de las actualizaciones de consenso
Desde el lanzamiento de la , las actualizaciones de la capa de consenso llevan el nombre de estrellas celestes que comienzan con letras en orden alfabético:
| Nombre de la actualización | Fecha de actualización |
|---|---|
| Génesis de la cadena de balizas | 1 de dic. de 2020 |
| Altair (opens in a new tab) | 27 de oct. de 2021 |
| Bellatrix (opens in a new tab) | 6 de sep. de 2022 |
| Capella (opens in a new tab) | 12 de abr. de 2023 |
| Deneb (opens in a new tab) | 13 de mar. de 2024 |
| Electra (opens in a new tab) | 7 de may. de 2025 |
| Fulu (opens in a new tab) | 3 de dic. de 2025 |
| Gloas (opens in a new tab) | Por determinar - Siguiente |
| Heze (opens in a new tab) | Por determinar |
Nomenclatura combinada
Las actualizaciones de ejecución y consenso se implementaron inicialmente en diferentes momentos, pero después de La Fusión en 2022, estas se han implementado simultáneamente. Como tal, han surgido términos coloquiales para simplificar las referencias a estas actualizaciones utilizando un solo término conjunto. Esto comenzó con la actualización Shanghái-Capella, comúnmente conocida como "Shapella", y continúa con las actualizaciones posteriores.
| Actualización de ejecución | Actualización de consenso | Nombre corto |
|---|---|---|
| Shanghái | Capella | "Shapella" |
| Cancún | Deneb | "Dencun" |
| Praga | Electra | "Pectra" |
| Osaka | Fulu | "Fusaka" |
| Ámsterdam | Gloas | "Glamsterdam" |
| Bogotá | Heze | "Hegotá" |
Vaya directamente a la información sobre algunas de las actualizaciones pasadas particularmente importantes: La cadena de balizas; La Fusión; y EIP-1559
¿Busca futuras actualizaciones del protocolo? Obtenga más información sobre las próximas actualizaciones en la hoja de ruta de Ethereum.
2025
Fulu-Osaka ("Fusaka")
Prague-Electra ("Pectra")
La actualización Prague-Electra ("Pectra") incluyó varias mejoras en el protocolo de Ethereum destinadas a mejorar la experiencia de todos los usuarios, las redes de capa 2 (l2), los participantes de staking y los operadores de nodos.
El staking recibió una actualización con cuentas de validador de interés compuesto y un mejor control sobre los fondos en staking utilizando la dirección de retiro de ejecución. EIP-7251 aumentó el saldo efectivo máximo para un solo validador a 2048, mejorando la eficiencia del capital para los participantes de staking. EIP-7002 permitió que una cuenta de ejecución activara de forma segura acciones del validador, incluida la salida o el retiro de partes de los fondos, mejorando la experiencia para los participantes de staking de ETH, al tiempo que ayudaba a fortalecer la responsabilidad de los operadores de nodos.
Otras partes de la actualización se centraron en mejorar la experiencia de los usuarios habituales. EIP-7702 brindó la capacidad para que una cuenta normal que no es un contrato inteligente () ejecute código similar a un contrato inteligente. Esto desbloqueó nuevas funcionalidades ilimitadas para las cuentas tradicionales de Ethereum, como el procesamiento por lotes de transacciones, el patrocinio de gas, la autenticación alternativa, los controles de gasto programables, los mecanismos de recuperación de cuentas y más.
Mejor experiencia de usuario:
- EIP-7702 - Establecer código de cuenta EOA
- EIP-7691 - Aumento de la capacidad de procesamiento de blobs
- EIP-7623 - Aumentar el costo de los datos de llamada
- EIP-7840 - Agregar programación de blobs a los archivos de configuración de la capa de ejecución (EL)
Mejor experiencia de staking:
- EIP-7251 - Aumentar el
MAX_EFFECTIVE_BALANCE - EIP-7002 - Salidas activables por la capa de ejecución
- EIP-7685 - Solicitudes de capa de ejecución de propósito general
- EIP-6110 - Suministrar depósitos de validador en cadena
Mejoras en la eficiencia y seguridad del protocolo:
- Pectra.wtf (opens in a new tab)
- Cómo Pectra mejorará la experiencia de staking (opens in a new tab)
- Leer las especificaciones de la actualización Electra (opens in a new tab)
- Preguntas frecuentes sobre Prague-Electra ("Pectra")
2024
Cancún-Deneb ("Dencun")
Resumen de Cancún
La actualización Cancún contiene un conjunto de mejoras para la ejecución de Ethereum destinadas a mejorar la escalabilidad, en conjunto con las actualizaciones de consenso de Deneb.
En particular, esto incluye la EIP-4844, conocida como Proto-Danksharding, que disminuye significativamente el costo de almacenamiento de datos para los rollups de capa 2. Esto se logra mediante la introducción de "blobs" de datos que permiten a los rollups publicar datos en la Red principal durante un corto período de tiempo. Esto da como resultado tarifas de transacción significativamente más bajas para los usuarios de los rollups de capa 2.
- EIP-1153 - Códigos de operación de almacenamiento transitorio
- EIP-4788 - Raíz del bloque baliza en la EVM
- EIP-4844 - Transacciones de blobs de fragmentos (Proto-Danksharding)
- EIP-5656 -
MCOPY- Instrucción de copia de memoria - EIP-6780 -
SELFDESTRUCTsolo en la misma transacción - EIP-7516 - Código de operación
BLOBBASEFEE
- Rollups de capa 2
- Proto-Danksharding
- Danksharding
- Leer la especificación de la actualización Cancún (opens in a new tab)
Resumen de Deneb
La actualización Deneb contiene un conjunto de mejoras para el consenso de Ethereum destinadas a mejorar la escalabilidad. Esta actualización viene en conjunto con las actualizaciones de ejecución de Cancún para habilitar Proto-Danksharding (EIP-4844), junto con otras mejoras en la cadena de balizas.
Los "mensajes de salida voluntaria" firmados y generados previamente ya no caducan, lo que otorga más control a los usuarios que hacen staking de sus fondos con un operador de nodo externo. Con este mensaje de salida firmado, los participantes pueden delegar la operación del nodo mientras mantienen la capacidad de salir de forma segura y retirar sus fondos en cualquier momento, sin necesidad de pedir permiso a nadie.
La EIP-7514 trae un endurecimiento a la emisión de ETH al limitar la tasa de "rotación" con la que los validadores pueden unirse a la red a ocho (8) por época. Dado que la emisión de ETH es proporcional al total de ETH en staking, limitar el número de validadores que se unen limita la tasa de crecimiento de los ETH recién emitidos, al tiempo que reduce los requisitos de hardware para los operadores de nodos, lo que ayuda a la descentralización.
- Leer las especificaciones de la actualización Deneb (opens in a new tab)
- Preguntas frecuentes sobre Cancún-Deneb ("Dencun")
2023
Shanghái-Capella ("Shapella")
Resumen de Shanghái
La actualización Shanghái trajo los retiros de staking a la capa de ejecución. En conjunto con la actualización Capella, esto permitió que los bloques aceptaran operaciones de retiro, lo que permite a quienes hacen staking retirar su ETH de la cadena de balizas a la capa de ejecución.
Resumen de Capella
La actualización Capella fue la tercera gran actualización de la capa de consenso (cadena de balizas) y habilitó los retiros de staking. Capella ocurrió de forma sincrónica con la actualización de la capa de ejecución, Shanghái, y habilitó la funcionalidad de retiro de staking.
Esta actualización de la capa de consenso brindó la capacidad para que quienes hacen staking y no proporcionaron credenciales de retiro con su depósito inicial pudieran hacerlo, habilitando así los retiros.
La actualización también proporcionó una funcionalidad de barrido automático de cuentas, que procesa continuamente las cuentas de los validadores en busca de pagos de recompensas disponibles o retiros completos.
- Más sobre los retiros de staking.
- Leer las especificaciones de la actualización Capella (opens in a new tab)
2022
Paris (La Fusión)
Resumen
La actualización Paris se activó cuando la cadena de bloques de prueba de trabajo (PoW) superó una de 58750000000000000000000. Esto ocurrió en el bloque 15537393 el 15 de septiembre de 2022, lo que activó la actualización Paris en el siguiente bloque. Paris fue la transición de La Fusión: su característica principal fue desactivar el algoritmo de minería de prueba de trabajo (PoW) y la lógica de consenso asociada, y activar en su lugar la prueba de participación (PoS). Paris en sí fue una actualización de los clientes de ejecución (equivalente a Bellatrix en la capa de consenso) que les permitió recibir instrucciones de sus clientes de consenso conectados. Esto requirió la activación de un nuevo conjunto de métodos de API internos, conocidos colectivamente como la Engine API (opens in a new tab). ¡Esta fue posiblemente la actualización más significativa en la historia de Ethereum desde Homestead!
Bellatrix
Resumen
La actualización Bellatrix fue la segunda actualización programada para la cadena de balizas, preparando la cadena para La Fusión. Lleva las penalizaciones del validador a sus valores máximos por inactividad e infracciones de recorte. Bellatrix también incluye una actualización de las reglas de elección de bifurcación para preparar la cadena para La Fusión y la transición del último bloque de prueba de trabajo (PoW) al primer bloque de prueba de participación (PoS). Esto incluye hacer que los clientes de consenso sean conscientes de la de 58750000000000000000000.
Gray Glacier
Resumen
La actualización de la red Gray Glacier retrasó la tres meses. Este es el único cambio introducido en esta actualización, y es de naturaleza similar a las actualizaciones Arrow Glacier y Muir Glacier. Se han realizado cambios similares en las actualizaciones de la red Bizancio, Constantinopla y Londres.
- EIP-5133 – retrasa la bomba de dificultad hasta septiembre de 2022
2021
Arrow Glacier
Resumen
La actualización de la red Arrow Glacier retrasó la varios meses. Este es el único cambio introducido en esta actualización, y es de naturaleza similar a la actualización Muir Glacier. Se han realizado cambios similares en las actualizaciones de la red Bizancio, Constantinopla y Londres.
- Blog de la EF: Anuncio de la actualización Arrow Glacier (opens in a new tab)
- Ethereum Cat Herders: Actualización Arrow Glacier de Ethereum (opens in a new tab)
- EIP-4345 – retrasa la bomba de dificultad hasta junio de 2022
Altair
Resumen
La actualización Altair fue la primera actualización programada para la cadena de balizas. Añadió soporte para los "comités de sincronización" (lo que habilitó los clientes ligeros) y aumentó las penalizaciones por inactividad y recorte de los validadores a medida que el desarrollo avanzaba hacia La Fusión.
¡Dato curioso!
Altair fue la primera actualización importante de la red que tuvo una hora de lanzamiento exacta. Todas las actualizaciones anteriores se habían basado en un número de bloque declarado en la cadena de prueba de trabajo (PoW), donde los tiempos de bloque varían. La cadena de balizas no requiere resolver la prueba de trabajo y, en su lugar, funciona con un sistema de épocas basado en el tiempo que consta de 32 "slots" de doce segundos de duración en los que los validadores pueden proponer bloques. ¡Es por eso que sabíamos exactamente cuándo llegaríamos a la época 74.240 y Altair entraría en funcionamiento!
Londres
Resumen
La actualización Londres introdujo la EIP-1559 (opens in a new tab), que reformó el mercado de tarifas de transacción, junto con cambios en la forma en que se manejan los reembolsos de gas y el cronograma de la .
¿Qué fue la actualización Londres / EIP-1559?
Antes de la actualización Londres, Ethereum tenía bloques de tamaño fijo. En momentos de alta demanda de la red, estos bloques operaban a plena capacidad. Como resultado, los usuarios a menudo tenían que esperar a que la demanda se redujera para ser incluidos en un bloque, lo que generaba una mala experiencia de usuario. La actualización Londres introdujo bloques de tamaño variable en Ethereum.
La forma en que se calculaban las tarifas de transacción en la red Ethereum cambió con la actualización Londres de agosto de 2021. Antes de la actualización Londres, las tarifas se calculaban sin separar las tarifas base y priority, de la siguiente manera:
Supongamos que Alice tenía que pagarle a Bob 1 ETH. En la transacción, el límite de gas es de 21.000 unidades y el precio del gas es de 200 Gwei.
La tarifa total habría sido: Gas units (limit) * Gas price per unit, es decir, 21,000 * 200 = 4,200,000 gwei o 0,0042 ETH
La implementación de la EIP-1559 (opens in a new tab) en la actualización Londres hizo que el mecanismo de tarifas de transacción fuera más complejo, pero hizo que las tarifas de gas fueran más predecibles, lo que resultó en un mercado de tarifas de transacción más eficiente. Los usuarios pueden enviar transacciones con un maxFeePerGas correspondiente a cuánto están dispuestos a pagar para que se ejecute la transacción, sabiendo que no pagarán más que el precio de mercado del gas (baseFeePerGas), y se les reembolsará cualquier extra, menos su tarifa de prioridad.
Este video explica la EIP-1559 y los beneficios que aporta: Explicación de la EIP-1559 (opens in a new tab)
- ¿Eres desarrollador de una aplicación descentralizada (dapp)? Asegúrate de actualizar tus bibliotecas y herramientas. (opens in a new tab)
- Leer el anuncio de la Fundación Ethereum (opens in a new tab)
- Leer la explicación de Ethereum Cat Herders (opens in a new tab)
Berlín
Resumen
La actualización Berlín optimizó el costo de gas para ciertas acciones de la EVM y aumenta el soporte para múltiples tipos de transacciones.
- Leer el anuncio de la Fundación Ethereum (opens in a new tab)
- Leer la explicación de Ethereum Cat Herders (opens in a new tab)
2020
Génesis de la cadena de balizas
Resumen
La cadena de balizas necesitaba 16384 depósitos de 32 ETH en staking para lanzarse de forma segura. Esto ocurrió el 27 de noviembre, y la cadena de balizas comenzó a producir bloques el 1 de diciembre de 2020.
Leer el anuncio de la Fundación Ethereum (opens in a new tab)
La cadena de balizas
Despliegue del contrato de depósito de staking
Resumen
El contrato de depósito de staking introdujo el en el ecosistema de Ethereum. Aunque es un contrato de la , tuvo un impacto directo en el cronograma de lanzamiento de la cadena de balizas, una importante actualización de Ethereum.
Leer el anuncio de la Fundación Ethereum (opens in a new tab)
Staking
Muir Glacier
Resumen
La bifurcación Muir Glacier introdujo un retraso en la . Los aumentos en la dificultad del bloque del mecanismo de consenso de prueba de trabajo (PoW) amenazaban con degradar la usabilidad de Ethereum al aumentar los tiempos de espera para enviar transacciones y usar aplicaciones descentralizadas (dapps).
- Leer el anuncio de la Fundación Ethereum (opens in a new tab)
- Leer la explicación de Ethereum Cat Herders (opens in a new tab)
- EIP-2384 – retrasa la bomba de dificultad por otros 4.000.000 de bloques, o ~611 días.
2019
Istanbul
Resumen
La bifurcación Istanbul:
- Optimizó el costo de de ciertas acciones en la EVM.
- Mejoró la resistencia a los ataques de denegación de servicio.
- Hizo que las soluciones de escalabilidad de capa 2 basadas en SNARKs y STARKs fueran más eficientes.
- Permitió la interoperabilidad entre Ethereum y Zcash.
- Permitió a los contratos introducir funciones más creativas.
Leer el anuncio de la Fundación Ethereum (opens in a new tab)
- EIP-152: permite que Ethereum funcione con monedas que preservan la privacidad como Zcash.
- EIP-1108: criptografía más barata para mejorar los costos de .
- EIP-1344: protege a Ethereum contra ataques de repetición al agregar el código de operación
CHAINID. - EIP-1884: optimiza los precios del gas de los códigos de operación en función del consumo.
- EIP-2028: reduce el costo de los datos de llamada para permitir más datos en los bloques, lo cual es bueno para la escalabilidad de capa 2.
- EIP-2200: otras alteraciones en el precio del gas de los códigos de operación.
Constantinopla
Resumen
La bifurcación Constantinopla:
- Redujo las recompensas de minería de bloques de 3 a 2 ETH.
- Aseguró que la cadena de bloques no se congelara antes de que se implementara la prueba de participación (PoS).
- Optimizó el costo de de ciertas acciones en la EVM.
- Agregó la capacidad de interactuar con direcciones que aún no se han creado.
Leer el anuncio de la Fundación Ethereum (opens in a new tab)
- EIP-145: optimiza el costo de ciertas acciones en cadena.
- EIP-1014: permite interactuar con direcciones que aún no se han creado.
- EIP-1052: introduce la instrucción
EXTCODEHASHpara recuperar el hash del código de otro contrato. - EIP-1234: asegura que la cadena de bloques no se congele antes de la prueba de participación (PoS) y reduce la recompensa de bloque de 3 a 2 ETH.
2017
Bizancio
Resumen
La bifurcación Bizancio:
- Redujo las recompensas de minería de bloque de 5 a 3 ETH.
- Retrasó la un año.
- Añadió la capacidad de realizar llamadas que no cambian el estado a otros contratos.
- Añadió ciertos métodos de criptografía para permitir el escalado de capa 2.
Leer el anuncio de la Fundación Ethereum (opens in a new tab)
- EIP-140 – añade el código de operación
REVERT. - EIP-658 – se añade un campo de estado a los recibos de transacción para indicar éxito o fracaso.
- EIP-196 – añade la curva elíptica y la multiplicación escalar para permitir los ZK-Snarks.
- EIP-197 – añade la curva elíptica y la multiplicación escalar para permitir los ZK-Snarks.
- EIP-198 – habilita la verificación de firma RSA.
- EIP-211 – añade soporte para valores de retorno de longitud variable.
- EIP-214 – añade el código de operación
STATICCALL, permitiendo llamadas que no cambian el estado a otros contratos. - EIP-100 – cambia la fórmula de ajuste de dificultad.
- EIP-649 – retrasa la 1 año y reduce la recompensa de bloque de 5 a 3 ETH.
2016
Spurious Dragon
Resumen
La bifurcación Spurious Dragon fue la segunda respuesta a los ataques de denegación de servicio (DoS) en la red (septiembre/octubre de 2016), que incluyó:
- el ajuste de los precios de los códigos de operación para prevenir futuros ataques en la red.
- la habilitación del «aligeramiento» (debloat) del estado de la cadena de bloques.
- la adición de protección contra ataques de repetición.
Leer el anuncio de la Fundación Ethereum (opens in a new tab)
- EIP-155: evita que las transacciones de una cadena de Ethereum se vuelvan a transmitir en una cadena alternativa, por ejemplo, que una transacción de una red de prueba se repita en la cadena principal de Ethereum.
- EIP-160: ajusta los precios del código de operación
EXP, lo que dificulta la ralentización de la red mediante operaciones de contrato computacionalmente costosas. - EIP-161: permite la eliminación de cuentas vacías añadidas a través de los ataques DOS.
- EIP-170: cambia el tamaño máximo de código que puede tener un contrato en la cadena de bloques a 24576 bytes.
Tangerine whistle
Resumen
La bifurcación Tangerine Whistle fue la primera respuesta a los ataques de denegación de servicio (DoS) en la red (septiembre/octubre de 2016), que incluyó:
- la resolución de problemas urgentes de salud de la red relacionados con códigos de operación con precios demasiado bajos.
Leer el anuncio de la Fundación Ethereum (opens in a new tab)
Bifurcación DAO
Resumen
La bifurcación DAO fue una respuesta al ataque a The DAO de 2016 (opens in a new tab), en el que un contrato inseguro fue vaciado de más de 3,6 millones de ETH en un hackeo. La bifurcación movió los fondos del contrato defectuoso a un nuevo contrato (opens in a new tab) con una única función: retirar. Cualquiera que hubiera perdido fondos podía retirar 1 ETH por cada 100 tokens DAO en sus billeteras.
Este curso de acción fue votado por la comunidad de Ethereum. Cualquier titular de ETH pudo votar a través de una transacción en una plataforma de votación (opens in a new tab). La decisión de bifurcar alcanzó más del 85 % de los votos.
Algunos mineros se negaron a bifurcar porque el incidente de The DAO no era un defecto en el protocolo. Posteriormente, pasaron a formar Ethereum Classic (opens in a new tab).
Leer el anuncio de la Fundación Ethereum (opens in a new tab)
Homestead
Resumen
La bifurcación Homestead miraba hacia el futuro. Incluyó varios cambios en el protocolo y un cambio en la red que le dio a Ethereum la capacidad de realizar futuras actualizaciones de la red.
Leer el anuncio de la Fundación Ethereum (opens in a new tab)
2015
Deshielo de Frontera
Resumen
La bifurcación de deshielo de Frontera eliminó el límite de 5.000 de por y estableció el precio del gas predeterminado en 51 . Esto permitió realizar transacciones (las transacciones requieren 21.000 de gas). Se introdujo la para garantizar una futura bifurcación dura hacia la .
- Leer el anuncio de la Fundación Ethereum (opens in a new tab)
- Leer la actualización 1 del protocolo de Ethereum (opens in a new tab)
Frontera
Resumen
Frontera fue una implementación en vivo, pero básica, del proyecto Ethereum. Siguió a la exitosa fase de pruebas Olympic. Estaba destinada a usuarios técnicos, específicamente a desarrolladores. Los tenían un límite de de 5.000. Este período de «deshielo» permitió a los mineros iniciar sus operaciones y a los primeros usuarios instalar sus clientes sin tener que «apresurarse».
Leer el anuncio de la Fundación Ethereum (opens in a new tab)
2014
Venta de ether
El ether salió oficialmente a la venta durante 42 días. Se podía comprar con BTC.
Leer el anuncio de la Fundación Ethereum (opens in a new tab)
Lanzamiento del Libro Amarillo
El Libro Amarillo, escrito por el Dr. Gavin Wood, es una definición técnica del protocolo Ethereum.
Ver el Libro Amarillo (opens in a new tab)
2013
Publicación del documento técnico
El documento introductorio, publicado en 2013 por Vitalik Buterin, el fundador de Ethereum, antes del lanzamiento del proyecto en 2015.
Documento técnico