Hard fork

¿Qué es un hard fork?

Un hard fork es un cambio en las reglas de consenso de una blockchain que no es compatible con versiones anteriores de los nodos que siguen aplicando las reglas previas.

Una vez activadas las nuevas reglas, los nodos actualizados pueden aceptar bloques o transacciones que los nodos no actualizados consideran inválidos.

Los nodos que quieran seguir la red actualizada deben instalar software compatible antes del momento de activación o poco después.

El glosario para desarrolladores de Bitcoin describe un hard fork como un cambio en las reglas de consenso que compromete la seguridad de los nodos que no se actualizan.

El glosario de Ethereum explica de forma similar que un cambio que implica un hard fork puede crear una divergencia permanente cuando los nodos antiguos no pueden validar los bloques producidos conforme a las nuevas reglas.

Un hard fork puede modificar los límites de los bloques, los formatos de las transacciones, el comportamiento de la máquina virtual, las operaciones criptográficas, las reglas de comisiones, los requisitos para validadores, las reglas de minería u otros elementos fundamentales de un protocolo de criptomoneda.

El término describe la compatibilidad del cambio de reglas, no el grado de desacuerdo político que lo rodea.

Una actualización de red planificada y respaldada ampliamente puede ser un hard fork aunque casi todos los participantes sigan la misma cadena actualizada.

En cambio, un hard fork controvertido puede dar lugar a dos blockchains persistentes si distintos grupos siguen aplicando reglas diferentes.

¿Por qué se llama fork?

Se produce un fork cuando los participantes de una blockchain no siguen todos la misma secuencia de bloques válidos.

El término procede de la imagen de un camino que se bifurca en dos ramas.

Antes de que se active un hard fork, los nodos actualizados y los no actualizados pueden coincidir en el mismo historial de la blockchain.

Después de la activación, pueden discrepar sobre qué nuevos bloques cumplen las reglas del protocolo.

Los nodos actualizados empiezan a aplicar las nuevas reglas de consenso en el momento de activación especificado.

Los nodos antiguos siguen aplicando las reglas anteriores porque su software no comprende ni acepta el cambio.

Si ambos grupos siguen produciendo y reconociendo bloques, el historial compartido de la blockchain puede dividirse en dos historiales independientes.

Si casi todos los participantes económicamente relevantes se actualizan, la rama antigua puede recibir poco o ningún apoyo continuado.

El cambio de reglas sigue siendo un hard fork aunque no llegue a desarrollarse una segunda criptomoneda duradera.

Cómo funciona un hard fork

Un hard fork suele comenzar con una propuesta para modificar una o varias reglas de consenso de una blockchain.

Los desarrolladores crean especificaciones técnicas que describen el nuevo comportamiento.

Los equipos de clientes implementan las reglas en software de nodos compatible.

El código propuesto se revisa, se prueba y normalmente se activa en redes de desarrollo o testnets públicas antes de llegar a la mainnet.

A continuación, los participantes reciben instrucciones sobre las versiones de software necesarias y las condiciones de activación.

La activación puede producirse en una altura de bloque, marca de tiempo, época, slot, valor de dificultad total u otro desencadenante definido por el protocolo.

Antes del momento de activación, el software actualizado suele seguir las reglas existentes.

En el momento de la activación, los nodos actualizados cambian a la nueva lógica de validación.

Los bloques creados conforme a las nuevas reglas pueden incluir características o comportamientos que los nodos antiguos rechacen.

Los mineros o validadores también deben utilizar software compatible si quieren que la red actualizada acepte sus bloques.

¿Qué son las reglas de consenso?

Las reglas de consenso son las que utilizan los nodos operados de forma independiente para determinar si los bloques, las transacciones y los estados de la blockchain son válidos.

Pueden definir la oferta permitida de monedas, las firmas de las transacciones, la estructura de los bloques, el cálculo del gas, el objetivo de Proof of Work, el comportamiento de los validadores y la ejecución de los contratos inteligentes.

Un nodo no acepta un bloque simplemente porque otro participante diga que es válido.

El nodo comprueba el bloque según las reglas implementadas en su software.

Los nodos que aplican reglas incompatibles pueden llegar a conclusiones distintas sobre un mismo bloque.

Un hard fork cambia esas conclusiones al permitir o exigir un comportamiento que el software anterior no acepta.

Por eso, un hard fork requiere coordinación entre operadores de nodos, mineros o validadores, desarrolladores de aplicaciones, proveedores de infraestructura, wallets y otros participantes de la red.

Hard fork frente a soft fork

Un hard fork introduce un cambio de reglas que los nodos antiguos no reconocen como válido.

Un soft fork introduce reglas más restrictivas que pueden seguir siendo compatibles con las comprobaciones de validez realizadas por los nodos antiguos.

En un soft fork, los nodos actualizados aplican una restricción adicional, mientras que los nodos antiguos pueden seguir reconociendo como válidos los bloques que la respetan.

En un hard fork, los nodos actualizados pueden aceptar algo que los antiguos rechazan.

Por ejemplo, la guía de la blockchain de Bitcoin explica que aumentar el tamaño de bloque permitido por encima del límite reconocido por los nodos antiguos requiere un hard fork.

La diferencia se refiere a la compatibilidad técnica, no a si una actualización es buena, mala, popular o controvertida.

Cualquiera de los dos tipos de fork puede requerir pruebas exhaustivas y coordinación de la comunidad.

Hard fork frente a bifurcación temporal de la cadena

Puede producirse una bifurcación temporal de la cadena sin que cambien las reglas de consenso.

Dos mineros o validadores pueden producir bloques válidos distintos aproximadamente al mismo tiempo.

Algunos nodos pueden recibir inicialmente un bloque, mientras que otros reciben el bloque en competencia.

El mecanismo de consenso acaba haciendo que una rama se convierta en la cadena reconocida y que la otra se abandone.

Este evento de corta duración se denomina a veces fork accidental, rama obsoleta o reorganización temporal.

Un hard fork es distinto porque cambia las reglas utilizadas para determinar la validez de los bloques.

La competencia temporal entre bloques puede producirse entre nodos que aplican reglas idénticas, mientras que un hard fork implica conjuntos de reglas incompatibles.

Hard fork frente a fork de software

Un fork de software se produce cuando los desarrolladores copian el código fuente de un proyecto y crean una versión independiente.

Este significado es habitual en el desarrollo de código abierto.

Copiar el código de un cliente de blockchain no crea automáticamente una nueva red de criptomoneda.

Un desarrollador puede bifurcar un repositorio de código para proponer mejoras, probar funciones o mantener una implementación de cliente independiente.

Un hard fork de blockchain cambia específicamente el comportamiento del consenso en una red activa y puede afectar a los bloques que aceptan los nodos.

Ambas ideas pueden coincidir cuando un proyecto de software copiado lanza una blockchain independiente, pero no son lo mismo.

Hard fork planificado

Un hard fork planificado es una actualización del protocolo programada y respaldada por las principales comunidades de desarrollo e infraestructura de la red.

Los detalles de su activación suelen publicarse con antelación.

Se indica a los operadores de nodos que instalen software compatible antes del momento de activación.

Los desarrolladores de wallets y contratos inteligentes, validadores, mineros, proveedores de datos y otros servicios pueden probar sus sistemas con las próximas reglas.

Cuando la adopción es amplia, la red puede pasar a las nuevas reglas sin mantener una cadena antigua relevante.

Muchas de las principales actualizaciones de la red Ethereum se implementan mediante hard forks coordinados.

La cronología oficial de forks de Ethereum recoge actualizaciones que modificaron el comportamiento de las capas de ejecución y consenso a lo largo de la historia de la red.

Hard fork controvertido

Un hard fork controvertido se produce cuando grupos importantes discrepan sobre qué reglas de consenso deben regir la criptomoneda.

Un grupo puede adoptar las nuevas reglas, mientras que otro continúa deliberadamente con las anteriores o implementa un cambio distinto.

Si ambos bandos cuentan con suficientes usuarios, desarrolladores, operadores de nodos, actividad económica y productores de bloques, pueden surgir dos redes persistentes.

A partir del punto de bifurcación, cada red desarrolla su propio historial de blockchain.

Con el tiempo, las redes pueden utilizar nombres, símbolos, hojas de ruta de desarrollo, modelos de seguridad y valores de mercado distintos.

Un fork controvertido es en parte técnico y en parte social, porque el software no puede obligar a los participantes independientes a reconocer una rama como legítima.

¿Todos los hard forks crean una moneda nueva?

No. La mayoría de los hard forks coordinados no crean una segunda criptomoneda duradera.

Una moneda nueva solo adquiere relevancia cuando una rama alternativa sigue funcionando y recibe suficiente apoyo técnico y económico.

Si casi todos los mineros o validadores, nodos, usuarios, wallets y aplicaciones adoptan las reglas actualizadas, la rama antigua puede dejar de producir bloques o volverse económicamente irrelevante.

La red actualizada puede conservar el nombre existente, los saldos de los activos, el historial y la identidad de la comunidad.

Cuando una actualización rutinaria se completa correctamente, los usuarios suelen seguir teniendo el mismo activo nativo sin necesidad de convertirlo.

Puede surgir un activo independiente si otro grupo mantiene deliberadamente una cadena distinta tras la bifurcación.

¿Qué ocurre con las monedas durante una división de la cadena?

Cuando se produce una división persistente de la cadena, ambas cadenas comparten el mismo historial de transacciones hasta el punto de bifurcación.

Por ello, una dirección que tuviera activos antes de la división puede aparecer con saldos equivalentes en ambas cadenas resultantes.

La clave privada que controlaba la dirección antes del fork puede autorizar inicialmente transacciones en ambas cadenas.

Esto no significa que los dos activos vayan a tener el mismo valor de mercado, seguridad, liquidez o apoyo a largo plazo.

Cada cadena desarrolla su propio estado después de la división.

Una transacción confirmada en una rama no actualiza automáticamente el saldo de la otra, salvo que el comportamiento de repetición haga que esa misma transacción firmada también se acepte allí.

Los usuarios deben comprender las reglas de seguridad y de protección contra la repetición antes de intentar acceder a los activos de ambas cadenas.

¿Qué es un ataque de repetición tras un hard fork?

Puede producirse un ataque de repetición cuando una transacción firmada para una blockchain también es válida en otra que comparte el mismo historial y las mismas reglas de firma.

Un observador puede copiar la transacción firmada de una rama y difundirla en la otra.

El usuario puede querer transferir activos solo en la primera cadena, pero transferir involuntariamente los activos correspondientes en ambas.

La protección contra la repetición permite distinguir las transacciones entre redes.

EIP-155 añadió un identificador de cadena a la firma de las transacciones de Ethereum para ayudar a impedir que una transacción destinada a una cadena sea válida en otra que utilice un identificador distinto.

Los usuarios no deben dar por hecho que todos los forks incluyen automáticamente una protección eficaz contra la repetición.

Antes de mover activos generados por una división de cadena, conviene revisar las instrucciones específicas del fork.

¿Qué es un chain ID?

Un chain ID es un identificador numérico que permite distinguir una red blockchain de otra en los procesos de firma de transacciones y en los flujos de trabajo de las aplicaciones.

Incluir el chain ID en la transacción firmada ayuda a vincular la autorización a la red prevista.

Las wallets también utilizan los chain ID para seleccionar la configuración de red, las direcciones de contratos, los tokens y la información sobre comisiones.

Dos cadenas persistentes no deberían utilizar deliberadamente el mismo chain ID si eso puede generar riesgos de repetición o de interfaz para el usuario.

Un chain ID no demuestra que una red sea fiable ni que un token sea legítimo.

Los usuarios deben verificar igualmente el nombre de la red, el activo nativo, el explorador de blockchain, la configuración de la wallet y los detalles de la transacción.

Identificación de forks entre nodos

Los nodos necesitan una forma de determinar si sus pares son compatibles con las mismas reglas de la cadena.

EIP-2124 define un identificador de fork que los nodos compatibles con Ethereum pueden utilizar para comprobar la compatibilidad de los pares.

El identificador representa las activaciones de forks anteriores y un punto de activación futuro previsto.

Los nodos compatibles pueden seguir conectados, mientras que los pares claramente incompatibles pueden desconectarse.

Esto ayuda a evitar que se desperdicien recursos intercambiando datos repetidamente entre nodos que acabarán rechazando las cadenas de los demás.

Los identificadores de fork contribuyen a la seguridad de la red, pero no sustituyen la validación completa de bloques y transacciones.

Métodos de activación de un hard fork

Una activación por altura de bloque comienza cuando la blockchain alcanza un número de bloque predeterminado.

Una activación por marca de tiempo comienza cuando el tiempo del bloque alcanza o supera un valor especificado.

Las activaciones por época son habituales en redes Proof of Stake que organizan el tiempo de consenso en épocas y slots.

Una activación por dificultad total puede desencadenarse cuando la Proof of Work acumulada alcanza un umbral definido.

Cada método tiene ventajas y consideraciones operativas.

Los tiempos de bloque varían, por lo que no siempre se puede predecir con exactitud al segundo una activación por altura de bloque.

Los calendarios de Proof of Stake basados en el tiempo pueden ofrecer una hora de activación prevista más precisa.

Los clientes deben implementar la lógica de activación de manera coherente o podrían discrepar en el punto de transición.

Hard forks en redes Proof of Work

En una red Proof of Work, los mineros crean bloques candidatos y los nodos completos los validan conforme a las reglas de consenso.

Un hard fork puede cambiar el algoritmo de minería, la estructura de los bloques, la recompensa, el cálculo de la dificultad, las reglas de las transacciones o los recursos permitidos por bloque.

Los mineros que no se actualicen pueden producir bloques que los nodos actualizados rechacen.

Los equipos de minería actualizados también pueden volverse incompatibles con la rama antigua si cambia el algoritmo de Proof of Work.

La tasa de hash puede repartirse entre cadenas en competencia si ambas ramas siguen funcionando.

La seguridad de cada rama dependerá en parte de cuánta potencia de minería compatible conserve y de la facilidad con que pueda redirigirse potencia de hash externa.

Los nodos completos siguen rechazando los bloques que infringen sus propias reglas, independientemente del trabajo dedicado a producirlos.

Hard forks en redes Proof of Stake

En una red Proof of Stake, los validadores deben utilizar software que implemente las reglas correctas de consenso y ejecución.

Un hard fork puede cambiar las funciones de los validadores, los formatos de los bloques, las penalizaciones, las transiciones de estado, las operaciones criptográficas o el comportamiento de la máquina virtual.

Los validadores que utilicen software obsoleto pueden incumplir sus funciones, seguir una rama incompatible o recibir penalizaciones, según el protocolo.

Las distintas implementaciones de cliente deben coincidir en las nuevas reglas para evitar fallos de consenso.

Los operadores de nodos deben actualizar tanto los clientes de ejecución como los de consenso cuando la red utilice capas de cliente separadas.

La guía de Ethereum para operar nodos recomienda instalar las versiones correctas de los clientes antes de los hard forks importantes.

Hard forks de Ethereum

Ethereum utiliza actualizaciones de red coordinadas para introducir cambios en su capa de ejecución, su capa de consenso o ambas.

Las actualizaciones de las capas de ejecución y consenso pueden tener nombres de desarrollo distintos que se combinan en un único nombre público de actualización.

Por ejemplo, los cambios Prague y Electra formaron la actualización Pectra.

La documentación oficial de Pectra indica que la actualización se activó en Ethereum Mainnet el 7 de mayo de 2025.

La siguiente actualización importante de Ethereum, Fulu-Osaka o Fusaka, se activó el 3 de diciembre de 2025.

A julio de 2026, la cronología oficial identifica Glamsterdam como la siguiente actualización importante, aunque su fecha de activación aún está por determinar.

Estas actualizaciones demuestran que un hard fork puede ser un método habitual de desarrollo del protocolo, no un intento de crear una moneda en competencia.

El hard fork de la DAO de Ethereum

El hard fork de la DAO de Ethereum es un ejemplo histórico de una respuesta controvertida a un incidente importante relacionado con un contrato inteligente.

La comunidad de la red debatió si debían cambiarse las reglas del protocolo para abordar los activos afectados por el incidente.

Algunos participantes adoptaron el historial modificado, mientras que otros siguieron reconociendo el historial original.

El resultado demostró que la gobernanza de una blockchain incluye decisiones sociales sobre qué software y estado eligen reconocer los participantes.

La documentación de gobernanza de Ethereum analiza el evento como un ejemplo importante de la interacción entre los grandes cambios del protocolo y la coordinación de la comunidad.

Este ejemplo no significa que los desarrolladores puedan reescribir a la ligera una blockchain cada vez que falla un contrato inteligente.

Estas intervenciones pueden generar desacuerdos duraderos sobre la inmutabilidad, la legitimidad y la autoridad de gobernanza.

Consideraciones sobre los hard forks de Bitcoin

Los cambios de consenso de Bitcoin requieren una coordinación cuidadosa, ya que los nodos operados de forma independiente aplican las reglas que eligen utilizar.

Una propuesta que amplíe el conjunto de bloques válidos más allá de lo que aceptan los nodos antiguos implica un cambio que requiere un hard fork.

Aumentar un límite de bloque por encima del máximo que acepta un nodo antiguo es un ejemplo técnico habitual.

Los nodos antiguos rechazarían el bloque más grande aunque los nodos actualizados lo aceptaran.

Mantener dos conjuntos de reglas incompatibles puede dar lugar a cadenas separadas si ambos bandos siguen recibiendo apoyo de mineros, nodos, usuarios y participantes económicos.

La historia de Bitcoin ha influido en debates más amplios sobre las actualizaciones conservadoras, la compatibilidad con versiones anteriores, la soberanía de los nodos y el consenso de la comunidad.

Por qué las blockchains utilizan hard forks

Una blockchain puede necesitar un hard fork para introducir funciones que no se puedan expresar con las reglas de consenso existentes.

Un hard fork puede añadir nuevos tipos de transacción, precompilaciones criptográficas, opcodes, funciones de cuenta o capacidades para los validadores.

Puede modificar los límites de recursos para facilitar la escalabilidad o reducir los riesgos de denegación de servicio.

Puede corregir una vulnerabilidad grave del protocolo o eliminar comportamientos obsoletos.

También puede alterar la emisión, el cálculo de comisiones, la distribución de recompensas o los mecanismos de consenso.

Asimismo, puede simplificar reglas antiguas que generan una complejidad innecesaria en la implementación.

Normalmente, solo debería recurrirse a un hard fork tras considerar la compatibilidad, la seguridad, las pruebas, el despliegue y el impacto en el ecosistema.

Gobernanza de los hard forks

Las blockchains públicas rara vez tienen una sola persona con autoridad ilimitada para obligar a todos los participantes a actualizarse.

Los desarrolladores pueden proponer e implementar software, pero los operadores de nodos deciden qué versiones utilizan.

Los mineros o validadores deciden qué bloques compatibles producen y validan.

Los desarrolladores de aplicaciones deciden qué cadena admiten sus programas.

Las wallets y los proveedores de infraestructura deciden cómo etiquetan y conectan con la red resultante.

Los usuarios y titulares de activos deciden qué red reconocen y utilizan.

La coordinación económica entre estos grupos suele determinar si una actualización se convierte en la continuación dominante de la cadena.

Por tanto, la gobernanza se lleva a cabo mediante especificaciones técnicas, debates públicos, versiones de clientes, pruebas, señalización y adopción efectiva del software.

¿Quién decide si un hard fork tiene éxito?

Ningún indicador por sí solo determina el éxito de todos los hard forks.

El apoyo de los desarrolladores es importante porque los clientes deben implementar y mantener las reglas.

La adopción por parte de los nodos es importante porque estos aplican las reglas de validez.

La adopción por parte de mineros o validadores es importante porque los bloques deben producirse conforme a las nuevas reglas.

El apoyo de las aplicaciones y las wallets es importante porque los usuarios necesitan acceder a la red.

La liquidez y el apoyo del mercado son importantes cuando surgen activos separados.

El reconocimiento de la comunidad es importante porque el valor de las criptomonedas depende en parte de las expectativas compartidas y del acuerdo social.

Una rama que funciona técnicamente puede seguir siendo débil desde el punto de vista económico si pocos usuarios o aplicaciones la reconocen.

Pruebas de un hard fork

Un hard fork debería probarse con varias implementaciones de cliente y en distintas condiciones de red.

Los desarrolladores necesitan vectores de prueba que confirmen que todos los clientes calculan el mismo estado después del fork.

Las testnets públicas pueden revelar problemas de sincronización de nodos, participación de validadores, procesamiento de transacciones y compatibilidad de aplicaciones.

También pueden crearse redes de desarrollo temporales específicamente para probar una actualización planificada.

Los equipos de seguridad pueden realizar fuzzing, pruebas diferenciales, análisis formal y simulaciones de ataques de denegación de servicio.

Ni siquiera unas pruebas exhaustivas pueden garantizar que la activación en mainnet esté libre de problemas.

Durante la transición, los operadores deben seguir los canales oficiales de comunicación y mantener procedimientos de respuesta ante incidentes.

Diversidad de clientes y seguridad de los hard forks

Muchas blockchains tienen más de una implementación independiente de cliente de nodo.

La diversidad de clientes puede reducir la dependencia de una única base de código, pero todos los clientes deben interpretar las reglas de consenso de manera idéntica.

Un error en un cliente puede hacer que sus nodos acepten o rechacen bloques distintos.

Si ese cliente controla una gran parte de la red, el error puede provocar una división grave de la cadena o una pérdida de finalidad.

Las pruebas de los hard forks deberían comparar los resultados de implementaciones independientes.

Los operadores de nodos también pueden reducir la dependencia del ecosistema respecto a una única implementación promoviendo una diversidad de clientes saludable.

Qué deben hacer los operadores de nodos

Los operadores de nodos deben confirmar si una actualización requiere software nuevo.

Deben obtener las versiones de fuentes de proyectos autenticadas.

Conviene revisar las notas de la versión para comprobar los sistemas operativos compatibles, las migraciones de bases de datos, los cambios de configuración y las combinaciones de clientes necesarias.

Antes de realizar tareas importantes de mantenimiento, los operadores deberían hacer copias de seguridad de las claves y los datos de configuración necesarios.

Después de la actualización, se debe sincronizar y supervisar el nodo.

Los operadores deben comprobar que el chain ID, la versión del fork, la altura de bloque, las conexiones con pares y el estado del cliente coinciden con la red prevista.

Ignorar una actualización obligatoria puede dejar al nodo siguiendo una cadena incompatible o inactiva.

Qué deben hacer los validadores

Los validadores deben instalar software que comprenda las nuevas reglas de consenso antes de la activación.

Deben confirmar que los componentes de ejecución, consenso, validación y firma son compatibles entre sí.

También puede ser necesario actualizar los firmantes remotos y las herramientas de supervisión.

Los validadores no deberían ejecutar configuraciones incompatibles que puedan provocar una doble firma o certificaciones incompatibles.

Los sistemas de respaldo deben actualizarse con cuidado para que una conmutación por error de emergencia no reinicie software obsoleto.

Si no se realizan las actualizaciones, pueden perderse recompensas, aplicarse penalizaciones por inactividad o producirse consecuencias más graves, según la red y el comportamiento.

Qué deben hacer los mineros

Los mineros deben confirmar que su nodo, el software para crear plantillas de bloques, los sistemas del pool y el firmware de minería son compatibles con las nuevas reglas.

Un hard fork que cambie el algoritmo de Proof of Work puede requerir hardware o firmware distintos.

Minar bloques con reglas obsoletas puede desperdiciar electricidad porque los nodos actualizados podrían rechazarlos.

Los participantes de los pools deben saber a qué cadena contribuye su tasa de hash.

No deberían basarse únicamente en el nombre o el panel del pool, ya que la configuración y las políticas de pago pueden cambiar ante un fork controvertido.

Qué deben hacer los usuarios de wallets

Los usuarios de wallets normales a menudo no necesitan hacer nada especial durante un hard fork coordinado.

Los saldos y las claves privadas suelen seguir siendo válidos en la cadena actualizada.

No obstante, los usuarios deben mantener actualizado el software de su wallet y seguir los anuncios de fuentes de la red autorizadas.

Nunca se debe revelar una frase de recuperación para reclamar una actualización, convertir monedas, sincronizar una wallet o recibir supuestos activos derivados de un fork.

Las actualizaciones legítimas del protocolo no exigen que los usuarios faciliten frases de recuperación a sitios web o representantes de soporte.

Cuando una división persistente crea activos separados, los usuarios deben esperar a recibir instrucciones de seguridad claras antes de intentar mover cualquiera de los saldos.

¿Hay que convertir las monedas después de un hard fork?

Una actualización rutinaria de la red normalmente no obliga a cambiar una moneda antigua por una nueva.

El mismo registro contable y los mismos saldos continúan bajo las reglas actualizadas.

Por ejemplo, las instrucciones oficiales de actualización de Ethereum indican que los usuarios no necesitan convertir sus activos nativos tras las actualizaciones coordinadas del protocolo.

Un mensaje que exija una conversión urgente puede ser un intento de phishing.

Puede ser necesaria una migración independiente si un proyecto lanza deliberadamente una nueva red o un nuevo contrato de token, pero esto no es una característica automática de todos los hard forks.

Los usuarios deben verificar las afirmaciones sobre migraciones en la documentación oficial del protocolo y desconfiar de mensajes no solicitados.

Hard forks y compatibilidad de los contratos inteligentes

Un hard fork puede cambiar la forma en que se ejecutan los contratos inteligentes aunque su código fuente no cambie.

Los costes de gas pueden aumentar o disminuir.

Pueden habilitarse nuevos opcodes.

Se pueden restringir o eliminar comportamientos antiguos.

La información de los bloques, las transacciones o las cuentas a la que acceden los contratos puede cambiar.

Las aplicaciones que dependan de supuestos precisos sobre el gas, el comportamiento de los opcodes o los campos de los bloques deberían probarse con las nuevas reglas.

Los desarrolladores también deben confirmar que las herramientas de desarrollo, los indexadores, los oráculos, los relayers y los servicios de infraestructura son compatibles con la actualización.

Hard forks y redes Layer 2

Las redes Layer 2 pueden depender de los formatos de transacción, la disponibilidad de datos, la finalidad, los costes de gas y el comportamiento de los contratos inteligentes de la capa base.

Por ello, un hard fork de la capa base puede afectar a los rollups, los bridges, los secuenciadores, los provers y los sistemas de retirada.

Los desarrolladores de Layer 2 podrían tener que actualizar el software de los nodos, los circuitos de prueba, los despliegues de contratos o los cálculos de comisiones.

Una actualización de la capa base destinada a mejorar la escalabilidad puede aumentar la capacidad de datos o introducir nuevas operaciones criptográficas.

El cambio debería probarse en ambas capas, ya que una actualización válida de la capa base puede revelar igualmente supuestos problemáticos en los sistemas dependientes.

Hard forks y bridges

Los bridges cross-chain deben decidir qué rama reconocer cuando se divide una blockchain conectada.

Un bridge que acepte mensajes de ambas ramas sin separarlas claramente puede enfrentarse a reclamaciones de activos duplicadas o no respaldadas.

Los operadores de bridges pueden pausar las transferencias durante un fork controvertido hasta que se aclare la identidad y la finalidad de la cadena.

Es posible que los contratos inteligentes necesiten identificadores de cadena, conjuntos de validadores o raíces de bloques aceptadas actualizados.

Los usuarios deberían evitar transferir activos puenteados durante una división incierta, salvo que el bridge haya publicado una política de soporte clara.

Hard forks y oráculos

Los oráculos proporcionan datos externos utilizados por sistemas de préstamos, activos vinculados a valores estables, derivados y otros contratos inteligentes.

Una división de la cadena puede crear dos versiones del mismo contrato de oráculo y feed de precios.

Los operadores de oráculos deben decidir si informan sobre una rama, ambas o ninguna temporalmente.

Las aplicaciones pueden funcionar mal si presuponen que los datos de los oráculos seguirán actualizándose normalmente con cualquier fork.

Los equipos de protocolo deberían definir procedimientos de emergencia para precios obsoletos, reorganizaciones de cadena y ramas no compatibles.

Hard forks y activos vinculados a valores estables

Una división de blockchain puede duplicar la representación on-chain de un activo vinculado a un valor estable sin duplicar las reservas off-chain del emisor.

La organización responsable del reembolso puede reconocer una sola rama.

El token de la rama no respaldada puede perder su valor de reembolso aunque el saldo del contrato inteligente no cambie.

Los usuarios no deben dar por sentado que cada token duplicado representa una reclamación duplicada sobre el mundo real.

Los emisores de activos, custodios, bridges y sistemas de gobernanza pueden influir en qué rama conserva el respaldo práctico.

Hard forks y posiciones DeFi

Un fork persistente puede duplicar estados de contratos inteligentes, como depósitos de colateral, préstamos, posiciones de liquidez y saldos de gobernanza.

La copia del estado no garantiza que ambas versiones sigan funcionando desde el punto de vista económico.

Los feeds de precios, los activos estables, los bridges, los administradores, los liquidadores, las aplicaciones de interfaz y los servicios externos pueden admitir una sola rama.

Una posición de préstamo puede volverse insegura si el oráculo deja de actualizarse.

Un pool de liquidez puede desequilibrarse gravemente si uno de los activos duplicados pierde su valor externo.

Los usuarios no deberían considerar las posiciones DeFi duplicadas como un aumento de riqueza adicional sin riesgo.

Hard forks y tokens no fungibles

Un hard fork puede crear registros on-chain idénticos de tokens no fungibles en ambas ramas en el momento de la división.

El reconocimiento de los mercados, el apoyo de los creadores, los servicios de metadatos, los derechos de propiedad intelectual y el acuerdo de la comunidad pueden favorecer solo una versión.

Las imágenes o los metadatos off-chain no se convierten automáticamente en activos separados porque se haya copiado el estado del contrato.

El valor económico de cada versión depende de que siga recibiendo reconocimiento y apoyo de la infraestructura.

Hard forks y tokens de gobernanza

Los saldos de tokens de gobernanza pueden duplicarse cuando se divide una cadena.

Cada rama puede celebrar entonces votaciones separadas o reconocer decisiones de gobernanza distintas.

Las delegaciones y el estado de las propuestas también pueden copiarse en el punto del fork.

Las organizaciones off-chain, entidades jurídicas, sitios web, repositorios y firmantes del tesoro pueden apoyar solo una rama.

El poder de voto de los tokens por sí solo puede no determinar qué rama controla los recursos externos.

Riesgos de seguridad de los hard forks

Un hard fork puede dejar al descubierto errores de software que no se detectaron durante las pruebas.

Distintos clientes pueden calcular resultados diferentes a partir de una misma transacción.

Los nodos obsoletos pueden seguir una cadena incompatible.

Los validadores pueden incumplir sus funciones o firmar mensajes contradictorios.

Los mineros pueden desperdiciar potencia de hash en bloques rechazados.

Las aplicaciones pueden utilizar chain ID o direcciones de contratos incorrectos.

Los ataques de repetición pueden mover activos de forma inesperada entre ramas.

Una menor participación en minería o staking puede debilitar temporalmente la seguridad de la cadena.

Los estafadores pueden aprovechar la confusión con instrucciones falsas de actualización, activos falsificados o herramientas de wallet fraudulentas.

Riesgos de mercado de los hard forks

Un hard fork controvertido puede provocar una volatilidad de precios considerable.

Los participantes del mercado pueden discrepar sobre qué rama recibirá apoyo a largo plazo.

La liquidez puede fragmentarse entre activos relacionados.

Los proveedores de infraestructura pueden pausar los depósitos y las retiradas durante periodos de incertidumbre.

Es posible que se exijan más confirmaciones de las transacciones porque aumente la probabilidad de reorganizaciones de la cadena.

Un activo de fork recién creado puede tener inicialmente poca liquidez y movimientos de precio extremos.

No se garantiza que el valor combinado de dos activos posteriores al fork iguale o supere el valor del activo original.

Estafas relacionadas con hard forks

Los estafadores suelen afirmar que los usuarios deben conectar una wallet para recibir monedas creadas por un próximo hard fork.

Un sitio fraudulento puede solicitar una frase de recuperación, una clave privada, la aprobación de un token o la firma de un mensaje.

Otra estafa puede vender un token de fork falso antes de que exista una red legítima.

Los atacantes también pueden crear software de wallet falsificado que afirme admitir ambas ramas mientras roba las claves.

Ninguna reclamación legítima de un fork exige que el usuario revele una frase de recuperación.

Antes de interactuar, los usuarios deberían confirmar la documentación oficial de la cadena, el código fuente, las versiones de clientes, el chain ID, la protección contra la repetición y el explorador de bloques.

Cómo prepararse para un hard fork

Confirma la fecha, el bloque, la época u otro desencadenante exacto de activación mediante fuentes autorizadas de la red.

Determina si la actualización está coordinada o si es probable que produzca una división persistente.

Actualiza el software de nodos, validadores, wallets y aplicaciones desde canales autenticados.

Haz copias de seguridad de las claves y los datos de configuración necesarios sin exponer secretos de recuperación.

Verifica los chain ID, las versiones de clientes, los identificadores de fork y las direcciones de contratos.

Pausa las operaciones automatizadas de alto riesgo si la actualización puede afectar al comportamiento de las transacciones o a la finalidad.

Espera a que la producción de bloques se estabilice antes de mover cantidades elevadas tras una división controvertida.

Revisa la protección contra la repetición antes de intentar acceder a activos duplicados.

Cómo evaluar un hard fork propuesto

Empieza por identificar las reglas de consenso exactas que se van a cambiar.

Revisa la especificación técnica y el motivo del cambio.

Comprueba si varios equipos de clientes independientes han implementado y probado la propuesta.

Revisa los resultados de las testnets, las auditorías, los riesgos conocidos y los desacuerdos pendientes.

Determina cómo se activará la actualización y qué ocurrirá con los nodos obsoletos.

Comprueba si las transacciones incluirán protección contra la repetición e identificadores de cadena distintos.

Considera cómo afecta la actualización a las wallets, los contratos inteligentes, los validadores, los mineros, los bridges, los oráculos y las redes Layer 2.

Distingue el apoyo técnico de las afirmaciones promocionales sobre el precio futuro de los activos.

Ventajas de un hard fork

Un hard fork puede introducir funciones importantes que las reglas antiguas no admiten.

Puede corregir debilidades graves del protocolo.

Puede mejorar la escalabilidad, el procesamiento de transacciones, el soporte criptográfico o la experiencia de los desarrolladores.

Puede modificar parámetros económicos que ya no contribuyan a los objetivos de la red.

Puede eliminar comportamientos obsoletos y simplificar la implementación de los clientes.

También puede permitir que una comunidad con prioridades fundamentalmente distintas mantenga un conjunto de reglas independiente.

Limitaciones de un hard fork

Un hard fork requiere una amplia coordinación entre muchos participantes independientes.

Los nodos obsoletos pueden volverse incompatibles o inseguros.

Una activación fallida puede interrumpir la producción de bloques o el funcionamiento de las aplicaciones.

Un fork controvertido puede dividir a usuarios, desarrolladores, recursos de seguridad, liquidez y efectos de red.

Los activos copiados pueden generar problemas de repetición, bridges, oráculos y reembolso.

La actualización también puede introducir nuevos errores mientras intenta resolver problemas anteriores.

Por tanto, un hard fork debe tratarse como un evento importante del protocolo, no como una actualización rutinaria de una aplicación.

Malentendidos habituales sobre los hard forks

Un malentendido habitual es creer que todos los hard forks crean criptomonedas gratis.

La mayoría de las actualizaciones planificadas continúan como una sola red, sin un segundo activo valioso.

Otro malentendido es creer que un hard fork siempre se debe a una disputa comunitaria.

Muchos hard forks son actualizaciones técnicas respaldadas ampliamente.

Un tercer malentendido es pensar que los desarrolladores pueden obligar por sí solos a todo el mundo a adoptar las nuevas reglas.

Los participantes independientes eligen qué software y qué cadena reconocen.

Un cuarto malentendido es que la duplicación de saldos on-chain garantiza que también se duplique su valor en el mundo real.

Las reservas off-chain, las aplicaciones, la liquidez y el apoyo de la comunidad pueden reconocer solo una rama.

Un quinto malentendido es que los usuarios deben introducir una frase de recuperación para actualizar sus monedas.

Las actualizaciones de una blockchain nunca requieren revelar los secretos de una wallet a otra persona o sitio web.

Preguntas frecuentes

¿Qué es un hard fork explicado de forma sencilla?

Un hard fork es un cambio en las reglas de una blockchain que el software antiguo de los nodos no puede aceptar o validar por completo.

¿Un hard fork es una blockchain nueva?

Un hard fork cambia las reglas de una blockchain y puede crear una rama nueva, pero solo existe una blockchain independiente y duradera si los participantes siguen apoyando ambos conjuntos de reglas.

¿Todos los hard forks crean una criptomoneda nueva?

No. Las actualizaciones coordinadas suelen continuar como una sola red sin crear un segundo activo relevante.

¿Qué diferencia hay entre un hard fork y un soft fork?

Un hard fork introduce reglas que los nodos antiguos rechazan, mientras que un soft fork suele introducir reglas más estrictas que siguen siendo válidas según las comprobaciones más amplias de los nodos antiguos.

¿Puede producirse un hard fork por accidente?

Un error de software puede provocar accidentalmente una validación incompatible, pero los hard forks planificados son cambios de protocolo especificados y activados deliberadamente.

¿Tengo que vender criptomonedas antes de un hard fork?

No hay una regla general que exija vender, aunque los usuarios deberían comprender los posibles riesgos de volatilidad, división de la cadena, repetición y liquidez.

¿Tengo que convertir mis monedas después de un hard fork?

Una actualización coordinada normalmente no requiere conversión, porque los saldos existentes continúan bajo las reglas actualizadas.

¿Cambiará la dirección de mi wallet después de un hard fork?

A menudo sigue siendo válida, aunque las nuevas reglas, los formatos de dirección o el diseño de migración de una red concreta pueden exigir un procedimiento distinto.

¿Puede aparecer mi saldo en ambas cadenas?

Sí. Si dos cadenas comparten el historial anterior al fork, el mismo saldo previo puede aparecer inicialmente en ambas ramas.

¿Las monedas duplicadas de un fork son dinero gratis?

No. Los saldos duplicados pueden implicar ataques de repetición, poca liquidez, activos no respaldados, wallets inseguras, impuestos, estafas y un valor de mercado incierto.

¿Qué es la protección contra la repetición?

La protección contra la repetición impide o reduce la posibilidad de que una transacción firmada para una cadena se copie y se acepte en otra.

¿Qué es un chain ID?

Un chain ID identifica una red blockchain y puede vincular una transacción firmada a esa red concreta.

¿Puede un hard fork revertir transacciones?

En teoría, un hard fork puede cambiar el estado reconocido, pero las actualizaciones rutinarias suelen conservar el historial de transacciones y los saldos existentes.

¿Quién controla un hard fork?

Los desarrolladores proponen e implementan las reglas, mientras que los nodos, mineros, validadores, aplicaciones, usuarios y participantes económicos deciden qué software y cadena respaldan.

¿Pueden los mineros forzar un hard fork?

Los mineros pueden respaldar una rama con su potencia de hash, pero los nodos completos pueden seguir rechazando los bloques que infrinjan las reglas que aplican.

¿Pueden los validadores seguir usando software antiguo?

Técnicamente pueden seguir utilizándolo, pero podrían seguir una cadena incompatible, incumplir sus funciones o recibir penalizaciones del protocolo.

¿Un hard fork afecta a los contratos inteligentes?

Sí. Los cambios en los costes de gas, los opcodes, los tipos de transacción, los campos de los bloques o las reglas de transición de estado pueden afectar al comportamiento de los contratos inteligentes.

¿Puede un hard fork afectar a las posiciones DeFi?

Sí. La duplicación del estado, los oráculos no compatibles, los fallos de los bridges, la fragmentación de la liquidez y los cambios en el valor de los activos pueden volver inseguras las posiciones posteriores al fork.

¿Puede un hard fork afectar a los tokens no fungibles?

Sí. Puede haber registros en ambas ramas, pero el reconocimiento de los mercados, los metadatos, los creadores y la comunidad puede diferir.

¿Cómo puedo reclamar de forma segura monedas de un fork?

Antes, los usuarios deberían verificar que existe una segunda cadena legítima, confirmar la protección contra la repetición, utilizar software revisado y no revelar nunca una frase de recuperación.

¿Por qué programan hard forks las redes?

Los programan para añadir funciones importantes, cambiar el comportamiento del consenso, corregir vulnerabilidades, mejorar la escalabilidad o actualizar las reglas económicas.

¿Puede fracasar un hard fork?

Sí. Una adopción reducida, errores de los clientes, implementaciones incoherentes, una coordinación deficiente o pruebas insuficientes pueden interrumpir la activación.

¿Es permanente un hard fork?

Las nuevas reglas de consenso permanecen vigentes en la cadena actualizada hasta que otro cambio del protocolo las modifique.

¿Un hard fork siempre perjudica a una criptomoneda?

No. Un hard fork bien probado y respaldado ampliamente puede mejorar una red, mientras que uno mal coordinado puede crear riesgos importantes.

¿Cómo puedo verificar un anuncio de hard fork?

Consulta la documentación oficial del protocolo, las notas de las versiones de los clientes, las especificaciones técnicas, los detalles de activación y varios equipos de desarrollo independientes.

¿Un hard fork me pedirá la frase semilla?

No. Una actualización legítima de blockchain nunca exige que los usuarios revelen una frase semilla o una clave privada.

Conclusión

Un hard fork es un cambio incompatible con versiones anteriores en las reglas de consenso que aplican los nodos de una criptomoneda.

Los nodos actualizados empiezan a aceptar o exigir comportamientos que los nodos antiguos no reconocen como válidos.

El cambio puede ser una actualización de red planificada o formar parte de un desacuerdo grave sobre el futuro de la blockchain.

Un hard fork no crea automáticamente una segunda cadena permanente ni una nueva criptomoneda valiosa.

Para que la división perdure, ambas ramas deben seguir recibiendo apoyo técnico, de seguridad, comunitario y económico.

Cuando se produce una división, los saldos anteriores al fork pueden aparecer en ambas cadenas, pero los activos resultantes pueden diferir en seguridad, liquidez, gobernanza y valor de mercado.

La protección contra la repetición y los chain ID distintos son importantes porque las mismas claves privadas y los mismos formatos de transacción pueden existir inicialmente en ambas ramas.

Los operadores de nodos, mineros, validadores, wallets, desarrolladores de contratos inteligentes, bridges, oráculos y sistemas Layer 2 deben prepararse para los cambios que afecten a su software.

Durante una actualización coordinada, los usuarios normales a menudo solo tienen que mantener actualizado el software de una wallet de confianza.

Nunca deben introducir una frase de recuperación en un sitio web para convertir, actualizar, validar o reclamar activos relacionados con un fork.

Los hard forks son herramientas importantes para añadir funciones, corregir debilidades del protocolo, cambiar reglas económicas y apoyar el desarrollo de blockchain a largo plazo.

También generan riesgos relacionados con clientes incompatibles, divisiones de la cadena, activos duplicados, aplicaciones inestables e incertidumbre de mercado.

La forma más prudente de abordar un hard fork es verificar la especificación técnica, las condiciones de activación, las versiones oficiales de los clientes, la identidad de la cadena y el diseño de protección contra la repetición antes de actuar.

En el ámbito de las criptomonedas, un hard fork demuestra, en última instancia, que las reglas de una blockchain se aplican mediante software, pero se adoptan gracias a la coordinación entre las personas y organizaciones que deciden ejecutarlo.