Qué es exactamente una bifurcación de Ethereum
Para entender un fork hay que pensar en Ethereum como un conjunto de reglas compartidas.
Miles de ordenadores ejecutan software que comprueba, entre otras cosas, si una transacción tiene una firma válida, cómo debe ejecutarse un smart contract, cuánto gas consume una operación o qué bloque pertenece a la cadena correcta. Ese acuerdo sobre las reglas permite que una blockchain funcione sin una base de datos central.
Cuando Ethereum necesita modificar alguna de esas reglas, los clientes de la red incorporan el cambio en una actualización de software. La documentación oficial de Ethereum denomina forks precisamente a estos cambios en las reglas del protocolo, que normalmente proceden de Ethereum Improvement Proposals o EIP.
Aquí aparece la primera confusión: “fork” puede referirse a situaciones bastante distintas.
| Situación | Qué ocurre | ¿Termina en dos redes? |
|---|---|---|
| Actualización planificada del protocolo | Ethereum adopta nuevas reglas de forma coordinada | Normalmente no |
| Bifurcación temporal de bloques | Durante un breve periodo hay dos posibles cabezas de la cadena | No; el consenso elige una |
| División permanente de la comunidad | Dos grupos mantienen reglas incompatibles | Sí, si ambas ramas conservan participantes |
| Soft fork | Se endurecen las reglas manteniendo cierta compatibilidad con nodos antiguos | No necesariamente |
| Hard fork | Las nuevas reglas dejan de ser plenamente compatibles con las anteriores | Solo si alguien mantiene la rama antigua |
Por eso, decir simplemente que “una bifurcación divide Ethereum en dos” es una simplificación excesiva.
Hard fork y soft fork: la diferencia que realmente importa
Los dos conceptos que más vas a encontrar son hard fork y soft fork.
Hard fork
Un hard fork introduce cambios de consenso que no son plenamente compatibles con las reglas anteriores. Un nodo que quiera continuar siguiendo la red actualizada debe utilizar software que conozca esas nuevas reglas.
Ethereum utiliza principalmente hard forks para sus grandes actualizaciones de protocolo. London, Dencun, Pectra o Fusaka son ejemplos de actualizaciones coordinadas de la red, no de guerras internas que hayan creado una nueva criptomoneda.
Soft fork
Un soft fork introduce reglas más restrictivas manteniendo compatibilidad hacia atrás en un sentido concreto: los bloques válidos bajo las reglas nuevas pueden seguir pareciendo válidos para los nodos antiguos, aunque estos últimos no estén comprobando todas las restricciones nuevas.
La clasificación técnica de las EIP lo expresa de forma especialmente precisa: en un soft fork, algo que antes era válido puede dejar de serlo; en un hard fork, las nuevas reglas pueden hacer válidas estructuras que antes no lo eran.
| Hard fork | Soft fork | |
|---|---|---|
| Compatibilidad con reglas antiguas | No plenamente compatible | Compatible hacia atrás |
| ¿Los nodos deben actualizarse? | Sí, para seguir correctamente la nueva red | No siempre de forma inmediata |
| Uso habitual en Ethereum | Muy frecuente para actualizaciones del protocolo | Mucho menos habitual |
| ¿Crea otra moneda? | No por sí mismo | No |
| ¿Puede provocar una división permanente? | Sí | Mucho menos probable |
La distinción importante no es si el fork “suena grande”, sino si los dos conjuntos de reglas pueden seguir validando la misma cadena.
Cómo se hace una bifurcación de Ethereum paso a paso
Ethereum no tiene una empresa que pueda pulsar un botón y obligar a toda la red a instalar una versión nueva. Cambiar sus reglas exige coordinación entre investigadores, desarrolladores, equipos de clientes, operadores de nodos, validadores y otras partes del ecosistema.
El proceso simplificado es este.
1. Alguien propone un cambio
Muchas modificaciones importantes empiezan como una Core EIP, una propuesta técnica que describe qué debe cambiar en el protocolo y cómo debería funcionar.
Una EIP no es una votación ni significa que el cambio vaya a llegar a Ethereum.
2. La propuesta se debate
La EIP se analiza públicamente y puede pasar por discusiones entre investigadores, desarrolladores de clientes y otros participantes.
Ethereum no utiliza una votación simple en la que quien acumula más ETH decide automáticamente el protocolo. Su gobernanza se basa principalmente en procesos fuera de cadena y en conseguir un consenso suficientemente amplio alrededor de cambios técnicamente viables.
3. Los distintos clientes implementan las nuevas reglas
Ethereum tiene varias implementaciones de cliente. No existe un único programa oficial que todo el mundo ejecute.
Los equipos correspondientes tienen que escribir y probar código que produzca el mismo resultado siguiendo la especificación acordada.
Este detalle es importante: el consenso no consiste solo en estar de acuerdo políticamente con una EIP; diferentes programas tienen que interpretar las reglas exactamente de la misma forma.
4. Los cambios se prueban
Antes de llegar a mainnet se utilizan redes de desarrollo y testnets. El objetivo es detectar incompatibilidades entre clientes, problemas de consenso, errores de implementación o efectos inesperados.
Una EIP puede modificarse, retrasarse o quedarse fuera de una actualización durante este proceso.
5. Se fija un punto de activación
Una vez preparada la actualización, las reglas nuevas se programan para activarse en un punto concreto de la red.
Las EIP suelen agruparse porque coordinar a todo Ethereum cada vez que se quiere introducir una pequeña modificación sería extremadamente costoso. La propia documentación de gobernanza de Ethereum describe este proceso: propuesta, discusión, implementación, pruebas, inclusión en una actualización y, finalmente, activación en la red.
6. Los operadores actualizan sus nodos
Antes de la activación, quienes ejecutan infraestructura deben instalar versiones compatibles.
Cuando llega el momento programado, los nodos actualizados empiezan a aplicar las reglas nuevas. Un nodo que siga con software incompatible puede dejar de seguir la misma cadena que el resto de Ethereum.
Y ahí aparece la posibilidad teórica de una división: si una cantidad suficiente de participantes decide deliberadamente continuar utilizando las reglas antiguas, las dos ramas podrían sobrevivir.
Lo normal es justo lo contrario. En una actualización consensuada, prácticamente todo el ecosistema migra y la rama antigua deja de tener relevancia.
Por qué las actualizaciones actuales de Ethereum tienen nombres dobles
Desde la transición de Ethereum a proof of stake, el protocolo tiene dos grandes componentes que deben coordinarse:
- capa de ejecución, donde se ejecutan transacciones y smart contracts;
- capa de consenso, donde los validadores acuerdan qué bloques forman la cadena canónica.
Las actualizaciones de ejecución reciben nombres de ciudades relacionadas con Devcon y Devconnect, mientras que las de consenso utilizan nombres de estrellas.
Por eso aparecen parejas como:
- Shanghai + Capella = Shapella;
- Cancun + Deneb = Dencun;
- Prague + Electra = Pectra;
- Osaka + Fulu = Fusaka.
Desde The Merge, las grandes actualizaciones de ambas capas se coordinan de forma simultánea, y esos nombres combinados se han convertido en la forma habitual de referirse a ellas.
Qué pasa con tus ETH cuando hay un hard fork
En una actualización normal, mucho menos de lo que puede sugerir la palabra bifurcación.
Si simplemente tienes ETH en una wallet, no necesitas cambiar tus ETH por una supuesta versión nueva, generar otra dirección ni compartir tu seed phrase.
Tu saldo forma parte del estado de Ethereum y ese estado continúa después de la actualización.
En términos prácticos:
- tus direcciones siguen siendo las mismas;
- tus claves privadas siguen controlando esas direcciones;
- ETH sigue siendo ETH;
- el historial anterior no desaparece;
- los tokens y NFT registrados en Ethereum continúan formando parte del estado;
- los smart contracts existentes no tienen que desplegarse otra vez.
Esto último tiene un matiz. El código y el estado del contrato continúan ahí, pero un hard fork sí puede modificar características de la EVM, costes de gas, opcodes u otras reglas con las que se ejecuta. Por eso los desarrolladores deben comprobar si una actualización afecta a sus aplicaciones.
Los exchanges también pueden detener temporalmente depósitos o retiradas mientras comprueban que su infraestructura está sincronizada. Eso es una medida operativa, no significa que tus ETH tengan que convertirse en otro activo.
Y conviene recordar una regla sencilla: una actualización de Ethereum nunca exige revelar la seed phrase. Cualquier web que te la pida para “migrar”, “sincronizar” o “reclamar” ETH está intentando conseguir acceso a tu wallet.
Cuándo una bifurcación sí acaba creando dos Ethereum
El ejemplo histórico más importante es The DAO.
En 2016, un fallo en el smart contract de The DAO permitió extraer más de 3,6 millones de ETH. La comunidad tuvo que afrontar una decisión incómoda: mantener intacta la historia de la cadena o modificar el estado mediante un hard fork para permitir la recuperación de los fondos.
Si quieres entender el contexto, primero conviene saber qué es una DAO y cómo funciona realmente su gobernanza.
El hard fork se activó en el bloque 1.920.000. No se limitó a “borrar el hack”: trasladó los fondos afectados a un contrato desde el que los participantes podían recuperarlos.
Una parte de los participantes rechazó el cambio y continuó operando con las reglas anteriores. Esa rama sobrevivió como Ethereum Classic (ETC), mientras que la cadena que adoptó el fork continuó siendo Ethereum. La cronología oficial de Ethereum identifica precisamente este episodio como su ejemplo más destacado de una bifurcación que terminó provocando una división permanente.
Por eso Ethereum Classic no es simplemente “una versión antigua de ETH”. Es una blockchain independiente con su propia red, consenso, activo ETC y evolución posterior.
El episodio deja una lección bastante más interesante que la típica definición de hard fork: el código determina qué reglas puede seguir una cadena, pero son los participantes quienes determinan qué cadenas continúan teniendo actividad y valor económico.
¿Una bifurcación duplica tus criptomonedas?
Solo en un sentido técnico y únicamente cuando existe una división permanente.
Imagina una blockchain justo antes de separarse:
A → B → C → DDesde D, aparecen dos conjuntos incompatibles de reglas:
→ E1 → F1 → G1
A → B → C → D
→ E2 → F2 → G2Las dos ramas comparten toda la historia hasta D.
Eso implica que el estado existente en el momento de la división —cuentas, saldos y smart contracts— puede aparecer inicialmente en las dos cadenas.
Pero de ahí no se deduce que hayas duplicado tu patrimonio.
Si antes del fork tienes 1 unidad del activo nativo, después de una división persistente podrías controlar técnicamente activos en ambas cadenas. Desde ese instante son activos distintos, en redes distintas y con mercados distintos.
Uno podría valer mucho. El otro, poco o nada.
Con tokens el asunto es todavía más delicado. Una stablecoin emitida por una empresa, por ejemplo, puede aparecer en ambos registros después de la bifurcación, pero el emisor puede reconocer como canónica una sola cadena. Tener “1.000 unidades” duplicadas en otra rama no obliga al emisor a canjearlas por 1.000 euros o dólares.
Lo mismo ocurre con buena parte de DeFi: bridges, oráculos, activos respaldados fuera de cadena y protocolos dependientes de infraestructura externa no se duplican económicamente simplemente porque su estado on-chain lo haga.
El problema de los ataques de repetición
Una división también puede producir otro problema: que una transacción válida en una cadena pueda repetirse en la otra.
Ethereum ya tuvo que enfrentarse a este riesgo tras la separación de Ethereum y Ethereum Classic. EIP-155 introdujo protección mediante identificadores de cadena para evitar que una transacción firmada para una red pudiera reproducirse sin más en otra.
Es un buen ejemplo de por qué “tengo monedas en las dos ramas” no debería interpretarse como “voy a moverlas inmediatamente para aprovechar el fork”.
Las bifurcaciones que más han cambiado Ethereum
Ethereum ha utilizado los hard forks como parte normal de su desarrollo desde prácticamente sus inicios. Esta selección resume los hitos que mejor muestran para qué sirven; la cronología oficial recoge el historial completo de actualizaciones.
| Bifurcación o actualización | Fecha | Qué cambió |
|---|---|---|
| Homestead | Marzo de 2016 | Primera gran actualización planificada del protocolo y base para futuras mejoras |
| DAO Fork | Julio de 2016 | Modificó el estado tras el ataque a The DAO; la división persistente dio lugar a Ethereum Classic |
| Tangerine Whistle / Spurious Dragon | 2016 | Respuesta a ataques DoS, ajustes de costes y protección frente a replay |
| Byzantium | Octubre de 2017 | Mejoras de EVM, criptografía y preparación para soluciones de escalabilidad |
| Constantinople | Febrero de 2019 | Cambios de eficiencia y modificaciones económicas de la etapa proof of work |
| Istanbul | Diciembre de 2019 | Ajustes de gas, resistencia a DoS y mejoras criptográficas |
| Berlin | Abril de 2021 | Modificó costes de gas y amplió el soporte de tipos de transacciones |
| London | Agosto de 2021 | Introdujo EIP-1559 y el sistema de tarifa base que se quema |
| Paris / The Merge | Septiembre de 2022 | Desactivó proof of work en Ethereum y completó la transición a proof of stake |
| Shapella | Abril de 2023 | Habilitó las retiradas de ETH del sistema de staking |
| Dencun | Marzo de 2024 | Introdujo blobs mediante EIP-4844 para abaratar y escalar la disponibilidad de datos de las L2 |
| Pectra | Mayo de 2025 | Mejoras en cuentas, staking, capacidad de blobs y eficiencia del protocolo |
| Fusaka | Diciembre de 2025 | Introdujo PeerDAS y nuevas herramientas para aumentar la capacidad de datos destinada al escalado |
La tabla también deja claro por qué definir una bifurcación únicamente como “una división en dos criptomonedas” no funciona para Ethereum. London, Dencun o Pectra fueron hard forks aunque la intención fuera precisamente que toda la red continuase junta bajo las reglas nuevas.
Un matiz reciente: los BPO forks
Ethereum incluso ha empezado a especializar algunos tipos de actualización.
El mecanismo Blob-Parameter-Only (BPO) permite modificar determinados parámetros relacionados con la capacidad de blobs sin tener que empaquetar el cambio dentro de una gran actualización repleta de nuevas funcionalidades.
El objetivo es poder aumentar la capacidad de disponibilidad de datos de forma más gradual y con un proceso más ligero que el de un hard fork completo tradicional. EIP-7892 formaliza este mecanismo.
Es un detalle técnico, pero ayuda a entender hacia dónde ha evolucionado Ethereum: una “bifurcación” puede ir desde una transformación como The Merge hasta un cambio coordinado y muy concreto de parámetros.
Hay otro tipo de fork que ocurre sin actualizar Ethereum
Hasta aquí hemos hablado principalmente de cambios en las reglas del protocolo. Pero el propio mecanismo de consenso también utiliza el concepto de fork.
Imagina que, por latencia de red o por un comportamiento incorrecto, distintos validadores reciben dos bloques distintos que pretenden ocupar la misma posición.
Durante un instante existen dos posibles ramas:
→ bloque A
bloque anterior
→ bloque BEso no es un hard fork ni una nueva criptomoneda. Es una bifurcación temporal de la cadena.
Ethereum necesita decidir qué rama pasa a ser canónica.
En proof of stake utiliza LMD-GHOST, una regla de elección de bifurcación que favorece la rama con mayor peso de atestaciones de los validadores. La finalidad de Ethereum añade una segunda capa de seguridad: cuando determinados checkpoints reciben el apoyo necesario, revertirlos requeriría destruir una cantidad muy importante de ETH en staking.
Esta diferencia es fundamental:
un hard fork cambia las reglas con las que los nodos juzgan la cadena; el algoritmo de fork choice decide qué rama seguir cuando temporalmente hay varias candidatas bajo esas reglas.
No son el mismo fenómeno.
Tampoco es un fork todo lo que sea compatible con Ethereum
Otra confusión habitual consiste en llamar “fork de Ethereum” a cualquier blockchain que utilice la EVM o herramientas desarrolladas originalmente para Ethereum.
No es correcto.
Una red puede ser compatible con la Ethereum Virtual Machine y permitir ejecutar contratos Solidity sin compartir la historia de Ethereum.
Del mismo modo, soluciones de escalabilidad como Arbitrum u Optimism no son una bifurcación de Ethereum mainnet. Son redes que ejecutan actividad fuera de la capa 1 y utilizan Ethereum dentro de su arquitectura de liquidación y seguridad.
Conviene separar cuatro ideas:
- hard fork: cambio incompatible en las reglas del protocolo;
- chain split: dos ramas incompatibles que siguen funcionando;
- EVM compatible: otra red capaz de ejecutar software compatible con la EVM;
- Layer 2: sistema construido para escalar Ethereum apoyándose de alguna manera en la capa base.
Pueden relacionarse, pero no son sinónimos.
Qué debes hacer cuando Ethereum anuncia un nuevo fork
Depende mucho más de tu papel en la red de lo que parece.
Si solo tienes ETH o tokens
Normalmente, nada especial.
Comprueba que utilizas software legítimo y actualizado, y ten cuidado con falsas webs de migración. Si tu exchange o wallet anuncia mantenimiento, puede tener sentido evitar movimientos justo durante la actualización.
No necesitas entregar tus claves a nadie.
Si utilizas DeFi
Una actualización planificada tampoco exige normalmente mover todos tus activos.
Sí merece la pena revisar avisos de los protocolos que estés utilizando si dependen de alguna funcionalidad que cambia con el fork.
Si operas un nodo
Aquí sí hay trabajo.
Debes instalar las versiones de cliente compatibles antes de la activación. Un nodo que siga reglas obsoletas puede acabar fuera del consenso de la red actualizada.
Si eres validador
Además de mantener actualizados los clientes de ejecución y consenso, un operador tiene que seguir las instrucciones de las implementaciones que utiliza.
No actualizar infraestructura crítica no tiene nada que ver con el riesgo normal de un holder. Si haces staking directamente, merece la pena entender también qué riesgos existen al participar en staking.
Si desarrollas smart contracts
La pregunta no es solamente “¿seguirá existiendo mi contrato?”.
Hay que comprobar si las EIP incluidas cambian costes de gas, comportamiento de determinados opcodes, límites, formatos de transacción u otras dependencias de tu aplicación. Para eso existen precisamente las devnets y testnets previas a mainnet.
Lo que de verdad debes recordar sobre las bifurcaciones de Ethereum
Las bifurcaciones son uno de los mecanismos con los que Ethereum puede cambiar sin tener un administrador central que actualice la red por decreto.
La mayoría de los hard forks de Ethereum son actualizaciones coordinadas: los nodos adoptan nuevas reglas y la misma red continúa funcionando. Solo cuando dos grupos mantienen deliberadamente reglas incompatibles y ambas ramas conservan apoyo aparece una división persistente como la que dio lugar a Ethereum Classic.
Y hay una última distinción que evita buena parte de la confusión: Ethereum es la red; ETH es su activo nativo. Un cambio en las reglas de Ethereum puede afectar a cómo funciona la red sin significar que tus ETH se hayan convertido de repente en una criptomoneda diferente.
