Cronología de todos los forks de Ethereum (2014 hasta la actualidad)
Una cronología que incluye todos los principales hitos, bifurcaciones y actualizaciones de la cadena de bloques de Ethereum.
Las bifurcaciones se producen cuando es necesario realizar actualizaciones o cambios técnicos importantes en la red; suelen provenir de las propuestas de mejora de Ethereum (EIP) y cambian las «reglas» del protocolo.
Cuando se precisan actualizaciones en un software tradicional y controlado centralmente, la empresa publica una nueva versión para el usuario final. Las cadenas de bloque funcionan de manera diferente porque no hay propiedad central. Los clientes de Ethereum deben actualizar su software para implementar las nuevas reglas de la bifurcación. Además de creadores de bloques (los mineros en el mundo de las pruebas de trabajo y los validadores en el universo de las pruebas de participación) y los nodos, deben crearse bloques y validarlos con respecto a las reglas nuevas. Más sobre los mecanismos de consenso
Estos cambios en las reglas pueden crear una división temporal en la red. Los bloques nuevos podrían producirse de acuerdo con las reglas nuevas o con las antiguas. Normalmente las bifurcaciones se acuerdan con antelación para que los clientes adopten los cambios a la vez. Además, de este modo las bifurcaciones actualizadas se convertirán en la cadena principal. Sin embargo, en casos excepcionales, los desacuerdos con respecto a las bifurcaciones pueden provocar que la red permanezca dividida. La más notable es la creación de Ethereum Classic con la [bifurcación DAO] (#dao-fork).
El software que sustenta a Ethereum se compone de dos mitades, conocidas como la y la .
Nombres de actualizaciones de la ejecución
Desde 2021, las actualizaciones de la capa de ejecución se nombran según las ciudades de anteriores ubicaciones de Devcon (opens in a new tab) en orden cronológico:
| Nombre de Actualización | Año de Devcon | Número de Devcon | Fecha de Actualización |
|---|---|---|---|
| Berlin | 2014 | 0 | 15 de abril de 2021 |
| London | 2015 | I | 5 de agosto de 2021 |
| Shanghai | 2016 | II | 12 de abril de 2023 |
| Cancún | 2017 | III | 13 de marzo de 2024 |
| Praga | 2018 | IV | Por definir - Próxima |
| Osaka | 2019 | V | Por definir |
| Bogotá | 2022 | VI | Por definir |
| Bangkok | 2024 | VII | Por definir |
Nombres de las actualizaciones de consenso
Desde el lanzamiento de la , las actualizaciones de la capa de consenso se nombran por estrellas celestes comenzando con letras que avanzan en orden alfabético:
| Nombre de Actualización | Fecha de Actualización |
|---|---|
| El origen de la cadena de baliza | 1 de diciembre de 2020 |
| Altair (opens in a new tab) | 27 de octubre de 2021 |
| Bellatrix (opens in a new tab) | 6 de septiembre de 2022 |
| Capella (opens in a new tab) | 12 de abril de 2023 |
| Deneb (opens in a new tab) | 13 de marzo de 2024 |
| Electra (opens in a new tab) | Por definir - Próxima |
| Fulu (opens in a new tab) | Por definir |
Nombres combinados
Las actualizaciones de ejecución y consenso se implementaron inicialmente en distintos momentos, pero tras La Fusión en 2022 estas se despliegan simultáneamente. Como tal, han surgido términos coloquiales para simplificar las referencias a estas actualizaciones utilizando un único término conjunto. Esto comenzó con la actualización Shanghai-Capella, comúnmente llamada "Shapella", y continúa con las actualizaciones Cancun-Deneb (Dencun) y Prague-Electra (Pectra).
| Actualización de Ejecución | Actualización de Consenso | Nombre Corto |
|---|---|---|
| Shanghai | Capella | "Shapella" |
| Cancún | Deneb | "Dencun" |
| Praga | Electra | "Pectra" |
| Osaka | Fulu | "Fusaka" |
Vaya directamente a la información sobre algunas de las actualizaciones pasadas especialmente importantes: La Beacon Chain; La Fusión; y EIP-1559
¿Busca futuras actualizaciones del protocolo? Conozca las próximas actualizaciones en la hoja de ruta de Ethereum.
2025
Fulu-Osaka ("Fusaka")
Praga-Electra ("Pectra")
La actualización Prague-Electra ("Pectra") incluyó varias mejoras en el protocolo de Ethereum destinadas a mejorar la experiencia para todos los usuarios, redes de capa 2, participantes y operadores de nodos.
La participación recibió una mejora con cuentas de validadores compuestas y un mejor control sobre los fondos en participaciones mediante la dirección de retirada de ejecución. El EIP-7251 aumentó el saldo máximo efectivo para un solo validador a 2048, mejorando la eficiencia de capital para los participantes. El EIP-7002 permitió que una cuenta de ejecución activara de forma segura acciones del validador, incluyida la salida o la retirada de partes de los fondos, mejorando la experiencia para los participantes en ETH y ayudando a fortalecer la responsabilidad de los operadores de nodos.
Otras partes de la actualización se centraron en mejorar la experiencia para los usuarios comunes. EIP-7702 añadió la capacidad de que una cuenta regular que no es smart contract () ejecute código similar a un smart contract. Esto desbloqueó una nueva funcionalidad ilimitada para las cuentas tradicionales de Ethereum, como el agrupamiento de transacciones, el patrocinio de gas, la autenticación alternativa, controles programables de gasto y mecanismos de recuperación de cuenta, entre otros.
Mejor experiencia de usuario:
- EIP-7702: Establecer código de cuenta EOA
- EIP-7691: Aumento del rendimiento de blobs
- EIP-7623 - Aumento del coste de calldata
- EIP-7840: Agregar programación de blobs a los archivos de configuración EL
Mejor experiencia de participación:
- EIP-7251: Aumentar el
MAX_EFFECTIVE_BALANCE - EIP-7002 - Salidas activables desde la capa de ejecución
- EIP-7685: Solicitudes de propósito general para la capa de ejecución
- EIP-6110: Registrar depósitos de validadores en la 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)
- Lea las especificaciones de la actualización Electra (opens in a new tab)
- Preguntas frecuentes sobre Praga-Electra ("Pectra")
2024
Cancún-Deneb ("Dencun")
Resumen de Cancún
La actualización Cancún contiene un conjunto de mejoras en la ejecución de Ethereum orientadas a mejorar la escalabilidad, junto con las actualizaciones de consenso de Deneb.
Esto incluye especialmente EIP-4844, conocido como Proto-Danksharding, que reduce significativamente el coste de almacenamiento de datos para los rollups de capa 2. Esto se logra a través de la introducción de "blobs" de datos que permiten que los rollups publiquen datos en la red principal por 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 la capa 2.
- EIP-1153 - Códigos de operación de almacenamiento transitorio
- EIP-4788 - Raíz de bloque de Baliza en la EVM
- EIP-4844 - Transacciones de blob fragmentado (Proto-Danksharding)
- EIP-5656 -
MCOPY- Instrucción de copia de memoria - EIP-6780 -
AUTODESTRUCTORsolo en la misma transacción - EIP-7516 -
BLOBBASEFEEcódigo de operación
- Rollups de capa 2
- Proto-Danksharding
- Danksharding
- Lea 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 en el consenso de Ethereum orientadas a mejorar la escalabilidad. Esta actualización viene junto con las actualizaciones de ejecución de Cancun para habilitar Proto-Danksharding (EIP-4844), junto con otras mejoras en la cadena de Baliza.
Los "mensajes de salida voluntaria" pregenerados y firmados ya no caducan, lo que da más control a los usuarios que realizan staking con un operador de nodo externo. Con este mensaje de salida firmado, los participantes pueden delegar el funcionamiento del nodo mientras mantienen la capacidad de salida y retirada de sus fondos de forma segura en cualquier momento, sin necesidad de pedir permiso a nadie.
EIP-7514 reduce la emisión de ETH limitando la tasa de "churn" a 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 pone un tope al ritmo de crecimiento de ETH emitido, y también reduce los requisitos de hardware para los operadores de nodos, ayudando a la descentralización.
- Lea 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 actualizacion de Shangai trae los retiros de staking a la capa de ejecución. Junto con la actualización Capella, habilitó los bloques para aceptar las operaciones de retirada, que permitieran a los interesados retirar sus ETH provenientes de la cadena de baliza para ejecutarlos posteriormente.
Resumen de Capella
La actualizacion Capella es la tercera actualización importante a la capa de consenso (cadena de baliza), que le permite retirar su participación. Capella se produjo de forma sincrónica a la actualización de la capa de ejecución, Shanghai, y activó la funcionalidad de retirada de participaciones.
Esta actualización de la capa de consenso aporta a los participantes que no proporcionaron credenciales de retirada en su depósito inicial la posibilidad de hacerlo ahora.
La actualizacion también proporciona la funcionalidad de barrido automático de la cuenta, la cual procesa constantemente cuentas validadoras para cualquier pago de recompensa disponible o retiradas completas.
- Más información sobre las retiradas de participaciones.
- Lea las especificaciones de la actualización Capella (opens in a new tab)
2022
París (La Fusión)
Resumen
La actualización París se activó cuando la blockchain proof-of-work superó una de 58750000000000000000000. Esto ocurrió en el bloque 15537393 el 15 de septiembre de 2022, y dio comienzo a la actualización Paris en el siguiente bloque. París fue la transición de La Fusión — su característica principal fue apagar el algoritmo de minería proof-of-work y la lógica de consenso asociada, y activar proof-of-stake en su lugar. París en sí fue una actualización para los clientes de ejecución (equivalente a Bellatrix en la capa de consenso), que les permitió recibir instrucciones de sus conectados clientes de consenso. Esto requirió un nuevo conjunto de métodos de API internos, conocidos colectivamente como la Engine API (opens in a new tab), que debía ser activada. ¡Esta fue, sin duda, 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 Beacon Chain, preparando la cadena para La Fusión. Incorpora penalizaciones del validador a sus valores completos por inactividad y recortes por malas conductas. Bellatrix también incluye una actualización de las reglas de elección de la bifurcación para preparar la cadena de cara a La Fusión y la transición del último bloque de prueba de trabajo al primer bloque de prueba de participación. Esto incluye hacer que los clientes de consenso conozcan la de 58750000000000000000000.
Gray Glacier
Resumen
La actualización de red Gray Glacier pospuso la por 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. Cambios similares se realizaron en las actualizaciones de red Bizancio, Constantinopla y Londres.
- EIP-5133: retrasa la bomba de dificultad hasta septiembre de 2022
2021
Arrow Glacier
Resumen
La actualización de red Arrow Glacier pospuso la por varios meses. Este es el único cambio introducido en esta actualización, y es de naturaleza similar a la actualización Muir Glacier. Cambios similares se realizaron en las actualizaciones de red Bizancio, Constantinopla y Londres.
- EF Blog - Anuncio de 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 Beacon Chain. Añadió soporte para los «comités de sincronización», permitiendo clientes ligeros y un aumento de la inactividad del validador y de las penalizaciones de recorte a medida que avanzaba el desarrollo hacia La Fusión.
¡Dato curioso!
Altair fue la primera gran actualización de red que ha tenido un periodo de implementación preciso. Cada una de las actualizaciones anteriores se habían basado en un número de bloques declarados en la cadena de prueba de trabajo, donde los tiempos de bloque varían. La cadena de baliza no requiere resolución para la prueba de trabajo y, en lugar de ello, funciona en un sistema épocas basado en el tiempo, que consiste en «ranuras» de tiempo de doce segundos durante los cuales los validadores pueden proponer bloques. Por esta razón sabíamos exactamente cuándo alcanzaríamos la época 74.240 y Altair vería la luz.
Londres
Resumen
La actualización Londres introdujo EIP-1559 (opens in a new tab), que reformó el mercado de tarifas de transacción, junto con cambios en el manejo de devoluciones de gas y el calendario de la .
¿Qué fue la actualización London/EIP-1559?
Antes de la actualización London, Ethereum tenía bloques de tamaño fijo. En momentos de alta demanda de la red, estos bloques operaban a capacidad total. Como resultado, los usuarios a menudo tenían que esperar que la alta demanda disminuyera para ser incluidos en un bloque, lo cual provocaba una mala experiencia de usuario. La actualización London introdujo los bloques de tamaño variable en Ethereum.
La forma en la 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 base y priority fees, de la siguiente manera:
Supongamos que Alice tiene que pagar 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: Unidades de gas (límite) * Precio del gas por unidad, es decir, 21,000 * 200 = 4,200,000 gwei o 0.0042 ETH
La implementación de EIP-1559 (opens in a new tab) en la Actualización Londres hizo que el mecanismo de tarifas fuera más complejo, pero permitió que las tarifas de gas sean más previsibles, resultando en un mercado de tarifas de transacción más eficiente. Los usuarios pueden enviar transacciones con un maxFeePerGas que corresponda a lo máximo que están dispuestos a pagar para que la transacción sea ejecutada, sabiendo que no pagarán más que el precio de mercado para el gas (baseFeePerGas), y recibirán cualquier exceso, menos su propina, de vuelta.
Este video explica EIP-1559 y los beneficios que trae: EIP-1559 Explicado (opens in a new tab)
- ¿Es usted desarrollador de dapps? Asegúrese de actualizar sus librerías y herramientas. (opens in a new tab)
- Lea el anuncio de la Fundación Ethereum (opens in a new tab)
- Lea la explicación de Ethereum Cat Herder (opens in a new tab)
Berlín
Resumen
La actualización Berlin optimizó el coste del gas para ciertas acciones de EVM, y aumentó la compatibilidad con múltiples tipos de transacciones.
- Lea el anuncio de la Fundación Ethereum (opens in a new tab)
- Lea la explicación de Ethereum Cat Herder (opens in a new tab)
2020
Génesis de Beacon Chain
Resumen
La Beacon Chain necesitó 16,384 depósitos de 32 ETH en staking para lanzarse de forma segura. Esto sucedió el 27 de noviembre, y la Cadena de Baliza comenzó a producir bloques el 1 de diciembre de 2020.
Lea el anuncio de la Fundación Ethereum (opens in a new tab)
Contrato de depósito para staking implementado
Resumen
El contrato de depósito para staking introdujo el en el ecosistema Ethereum. Aunque fue un contrato de , tuvo un impacto directo en el cronograma para lanzar la Beacon Chain, una importante actualización de Ethereum.
Lea el anuncio de la Fundación Ethereum (opens in a new tab)
Muir Glacier
Resumen
El fork Muir Glacier introdujo un retraso en la . El aumento de dificultad por bloque del mecanismo de consenso proof-of-work amenazaba con degradar la usabilidad de Ethereum aumentando los tiempos de espera para enviar transacciones y usar dapps.
- Lea el anuncio de la Fundación Ethereum (opens in a new tab)
- Lea la explicación de Ethereum Cat Herder (opens in a new tab)
- EIP-2384: retrasa la bomba de dificultad otros 4.000.000 bloques o ~611 días.
2019
Estambul
Resumen
La bifurcación de Istanbul:
- Se optimizó el coste de de ciertas acciones dentro de la EVM.
- Mejoró la resistencia al ataque de denegación de servicio.
- Se mejoró el rendimiento de las soluciones de escalabilidad de capa 2 basadas en SNARKs y STARKs.
- Habilitó Ethereum y Zcash para que interoperasen.
- Permitió que los contratos introdujeran funciones más creativas.
Lea el anuncio de la Fundación Ethereum (opens in a new tab)
- EIP-152: permite a Ethereum funcionar con una moneda que mantiene la privacidad como Zcash.
- EIP-1108: criptografía más económica para mejorar los costes de .
- EIP-1344: protege a Ethereum contra ataques de repetición al agregar el
CHAINIDopcode. - EIP-1884: optimiza los precios del gas para el código de operación en función del consumo.
- EIP-2028: reduce el coste de CallData para permitir más datos en los bloques – beneficioso para la escalabilidad de capa 2.
- EIP-2200: otras modificaciones del precio del gas del código de operación
Constantinopla
Resumen
La bifurcación Constantinople:
- Se redujeron las recompensas de minería por bloque de 3 a 2 ETH.
- Se garantizó que la blockchain no se congelara antes de que se implementase proof-of-stake.
- Se optimizó el coste de de ciertas acciones dentro de la EVM.
- Añadió la capacidad de interactuar con direcciones que aún no se han creado.
Lea el anuncio de la Fundación Ethereum (opens in a new tab)
- EIP-145: optimiza el coste de ciertas acciones en la cadena.
- EIP-1014: le permite interactuar con direcciones que aún no se han creado.
- EIP-1052: introduce la instrucción
EXTCODEHASHpara obtener el hash del código de otro contrato. - EIP-1234: se asegura de que la cadena de bloques no' se congele antes de la prueba de participación y reduce la recompensa del bloque de 3 ETH a 2.
2017
Bizancio
Resumen
La bifurcación de Bizantium:
- Se redujeron las recompensas de minería por bloque de 5 a 3 ETH.
- Se retrasó la un año.
- Se ha añadido la habilidad para realizar llamadas «sin cambiar de estado» a otros contratos.
- Se añadieron ciertos métodos criptográficos para permitir la escalabilidad de capa 2.
Lea 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: campo de estado añadido a los recibos de la transacción para indicar el éxito o el fracaso.
- EIP-196 – agrega curva elíptica y multiplicación escalar para habilitar el uso de ZK-Snarks.
- EIP-197: agrega curva elíptica y multiplicación escalar para habilitar el uso de ZK-Snarks.
- EIP-198: permite la verificación de firmas RSA.
- EIP-211: añade soporte para valores de retorno de longitud variable.
- EIP-214 – agrega el código
STATICALL, permitiendo llamadas no cambiantes de 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 por 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) a la red (septiembre/octubre de 2016) e incluye:
- Ajuste de los precios del código de operación para evitar futuros ataques a la red.
- Activación de la «deflación» del estado de la cadena de bloques.
- Adición de la protección contra ataques de repetición.
Lea el anuncio de la Fundación Ethereum (opens in a new tab)
- EIP-155: evita que las transacciones de una cadena Ethereum se redifundan en una cadena alternativa, por ejemplo, una transacción de red de prueba que se reproduce en la cadena principal de Ethereum.
- EIP-160: ajusta los precios del código operativo
EXP: hace más difícil ralentizar la red a través de operaciones de contrato de elevado coste computacional. - EIP-161: permite eliminar cuentas vacías añadidas a través de los ataques DOS.
- EIP-170: cambia el tamaño máximo del código que un contrato en la cadena de bloques puede tener a 24.576 bytes.
Tangerine Whistle
Resumen
La bifurcación Tangerine Whistle fue la primera respuesta a los ataques de denegación de servicio (DoS) a la red (septiembre/octubre de 2016) e incluyó:
- la gestión de problemas urgentes del buen estado de la red relacionados con códigos de operación depreciados.
Lea el anuncio de la Fundación Ethereum (opens in a new tab)
Fork de la DAO
Resumen
El fork de la DAO fue en respuesta al ataque de la DAO en 2016 (opens in a new tab), donde un contrato inseguro fue vaciado en un hackeo de más de 3.6 millones de ETH. El fork movió los fondos del contrato defectuoso a un nuevo contrato (opens in a new tab) con una sola función: retirar. Cualquiera que haya perdido fondos podría retirar 1 ETH por cada 100 tókenes DAO en sus carteras.
Esta acción fue votada por la comunidad Ethereum. Cualquier tenedor de ETH pudo votar mediante una transacción en una plataforma de votación (opens in a new tab). La decisión de realizar un fork obtuvo más del 85 % de los votos.
Algunos mineros se negaron a bifurcar porque el incidente de la DAO no era un defecto en el protocolo. Fueron quienes formaron Ethereum Classic (opens in a new tab).
Lea el anuncio de la Fundación Ethereum (opens in a new tab)
Homestead
Resumen
Homestead: la bifurcación con perspectivas de futuro. Incluyó varios cambios de protocolo y un cambio de red que concedió a Ethereum la capacidad de hacer más actualizaciones de red.
Lea el anuncio de la Fundación Ethereum (opens in a new tab)
2015
Frontier Thawing
Resumen
El fork Frontier Thawing eliminó el límite de 5,000 por y estableció el precio por defecto del gas en 51 . Esto permitió que se realizaran transacciones que requiriesen 21.000 unidades de gas. Se introdujo la para asegurar un hard fork futuro hacia .
- Lea el anuncio de Frontier Thawing de la Fundación Ethereum (opens in a new tab)
- Lea la Actualización de Protocolo de Ethereum 1 (opens in a new tab)
Frontier
Resumen
Frontier 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. 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 adoptantes instalar sus clientes sin tener que «precipitarse».
Lea 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. Podía comprarse con BTC.
Lea el anuncio de la Fundación Ethereum (opens in a new tab)
Yellowpaper publicado
El protocolo, escrito por el Dr. Gavin Wood, es una definición técnica del protocolo de Ethereum.
Ver el Yellow Paper (opens in a new tab)
2013
Whitepaper publicado
Documento introductorio, publicado en el 2013 por Vitalik Buterin, fundador de Ethereum, antes del lanzamiento del proyecto en 2015.
Última actualización de la página: 22 de abril de 2026
