¿Qué es un hard fork?

Los cambios en las reglas de una blockchain pueden afectar a usuarios, desarrolladores, operadores e inversores. Un concepto importante es el hard fork: un cambio de las reglas de consenso que no es compatible con el software antiguo.

No todas las actualizaciones requieren un hard fork. También existen soft forks y mejoras del software que no cambian el consenso. Entender la diferencia ayuda a saber qué software verifica las nuevas reglas y cuándo puede dividirse una red.

¿Qué es un hard fork?

Un hard fork cambia las reglas con las que los nodos determinan si los bloques y las transacciones son válidos.

Los bloques válidos según las reglas nuevas pueden ser rechazados por nodos que siguen las anteriores. El cambio puede introducir funciones o modificar límites del protocolo. Lo decisivo es la compatibilidad de las reglas de consenso, no solo la cantidad de código modificada.

Los operadores que quieran validar la cadena con las nuevas reglas deben utilizar software compatible. No todos están técnicamente obligados a hacerlo: algunos pueden mantener las reglas antiguas. La continuidad de la cadena anterior depende del apoyo de los participantes y del mecanismo de consenso.

Los desarrolladores o miembros de la comunidad pueden proponer un hard fork para añadir funciones, corregir problemas o elegir otra dirección. La propuesta no cambia la red por sí sola: los participantes deben adoptar el software y coordinar su activación.

¿Qué ocurre durante un hard fork?

Las reglas nuevas suelen activarse en una altura de bloque o un momento determinados. Los nodos sin actualizar pueden rechazar bloques aceptados por los nuevos. Sin embargo, un hard fork no crea necesariamente dos redes o monedas duraderas: si los participantes cambian juntos, la cadena antigua puede detenerse.

Si grupos diferentes siguen produciendo bloques bajo reglas incompatibles, puede surgir una separación duradera. Eso difiere de una bifurcación temporal en la que aparecen dos bloques válidos casi a la vez y la red vuelve después a un historial común.

Dos cadenas que continúan comparten la historia hasta la bifurcación y luego evolucionan por separado. La antigua no pierde automáticamente su relevancia. Ambas dependen de usuarios, desarrolladores, operadores de nodos y mineros o validadores.

¿Qué cadena se considera original?

Los hard forks no se limitan a Bitcoin o Ethereum. El nombre y la identidad tras una división dependen del uso y del reconocimiento de la comunidad y del mercado. No existe una regla universal que otorgue el nombre original a la cadena con el código más reciente.

Actualizar reglas y cambiar la identidad de un proyecto son asuntos distintos. Una red puede conservar su nombre después de una actualización coordinada. Los participantes que discrepan pueden continuar otra cadena con un nombre diferente. Esto no significa que cada actualización de Bitcoin sea un hard fork.

Bitcoin Cash y Bitcoin Gold son ejemplos de proyectos surgidos de bifurcaciones relacionadas con Bitcoin. Bitcoin SV apareció después de una bifurcación de Bitcoin Cash. Son redes distintas, no simples nombres de versiones del mismo software Bitcoin.

¿Por qué se propone un hard fork?

Las razones pueden ser nuevas funciones, cambios en parámetros de consenso o correcciones de vulnerabilidades. El apoyo de la mayoría puede facilitar la coordinación, pero no constituye una decisión central que obligue a todos los nodos a aceptar cambios. Los participantes eligen las reglas que ejecutan.

Una cadena grande o con muchos nodos no es automáticamente inmune a ataques. Las vulnerabilidades de contratos inteligentes, software y consenso son problemas distintos. En circunstancias concretas, una comunidad puede apoyar un cambio en el estado de la red, pero eso no equivale a borrar libremente su historial de transacciones.

También conviene distinguir un cambio de reglas de una migración de plataforma, tratada en el artículo relacionado sobre Polymath y Ethereum. Un ejemplo de cambio de estado mediante hard fork fue la respuesta de Ethereum al ataque al DAO en 2016.

El fork del DAO se activó el 20 de julio de 2016 en el bloque 1.920.000. El informe de la Ethereum Foundation describe el traslado de fondos desde los contratos DAO afectados a un contrato de recuperación. Un apoyo amplio no significaba unanimidad de toda la comunidad: algunos rechazaron el cambio y continuaron la cadena sin fork como Ethereum Classic.

El fork no borró del historial las transacciones del ataque. El cambio de estado trasladó fondos a un contrato nuevo que permitía retiradas según los derechos de los titulares de tokens DAO. La recuperación se hacía mediante ese contrato, no con un pago automático simultáneo a todos.

Diferencias entre hard fork y soft fork

Ambos pueden cambiar las reglas de consenso, pero difieren en su compatibilidad. Un soft fork las hace más restrictivas: los bloques que cumplen las reglas nuevas también son aceptados por los nodos antiguos, aunque estos no verifican todas las restricciones añadidas.

En un hard fork, los nodos antiguos pueden rechazar bloques permitidos por las reglas nuevas. Si ambos grupos mantienen sus reglas, pueden sobrevivir dos cadenas. El soft fork busca conservar una cadena compatible, pero los errores de coordinación o implementación también pueden causar problemas y divisiones.

Los operadores que quieran verificar todas las reglas nuevas deben actualizar el software. Con un soft fork, un nodo antiguo puede seguir bloques nuevos sin comprender todas las restricciones adicionales. Con un hard fork puede rechazarlos. Por tanto, ambos métodos no generan necesariamente la misma división.

Un hard fork no es intrínsecamente más seguro que un soft fork. La seguridad depende del diseño, la implementación, las pruebas, la activación coordinada y el apoyo de la red. Los soft forks tampoco son obsoletos: Taproot de Bitcoin fue un soft fork activado en 2021. Un hard fork no requiere automáticamente mucha más capacidad de cálculo; las necesidades dependen del cambio concreto del protocolo.

Conclusión

Los hard forks permiten cambios de consenso incompatibles con los nodos antiguos. Pueden formar parte de un plan de desarrollo o responder a problemas urgentes, pero no todas las funciones nuevas los requieren.

El resultado depende del contenido del cambio y del apoyo de los participantes. Una actualización coordinada puede preservar una sola red, mientras que el desacuerdo puede crear cadenas separadas. Para los usuarios es importante comprender las reglas, el software y la red que eligen.