Forks suaves y forks duros

Curiosidad

1. ¿Por qué una red puede adoptar reglas más estrictas sin obligar a que cada nodo se actualice simultáneamente?
2. ¿Qué cambio estructural específico en agosto de 2017 causó que Bitcoin Cash se separara de Bitcoin?
3. ¿Cómo un error de software en marzo de 2013 creó dos cadenas competidoras que nadie había previsto?

Explorar

1. Un soft fork endurece las reglas de consenso. Los bloques y transacciones válidas bajo las nuevas reglas más estrictas siguen siendo válidas bajo las antiguas, más flexibles. Esta compatibilidad retroactiva significa que los nodos no actualizados continúan aceptando la cadena, mientras que los nodos actualizados aplican las nuevas restricciones. Mientras la mayor parte de la potencia de hash aplique las nuevas reglas, la red permanece en una sola cadena; si no es así, incluso un soft fork puede dividirla, como ocurrió en julio de 2015.
2. Un hard fork suaviza o modifica las reglas de tal manera que las estructuras anteriormente inválidas pasan a ser válidas. Por ejemplo, aumentar el límite del tamaño del bloque hace que los bloques más grandes sean aceptables. Si no todos los nodos se actualizan para aceptar estas nuevas estructuras, la red se divide en dos cadenas competidoras con historiales incompatibles. Esta división ocurrió el 1 de agosto de 2017, cuando Bitcoin Cash adoptó un tamaño de bloque mayor que Bitcoin.
3. Los soft forks requieren una activación cuidadosa, ya que los mineros que aplican las nuevas reglas deben constituir la mayoría de la potencia de hash. Si los mineros ignoran la señal o aplican reglas obsoletas, la cadena corre el riesgo de dividirse de todos modos. El estándar BIP9 (2015-2016) estandarizó la activación mediante una señal por parte de los mineros: un soft fork se establecía una vez que el 95% de los bloques en un período de 2,016 bloques indicaban estar listos; posteriormente, tras otro período adicional, los nodos actualizados lo aplicaban.
4. El fork accidental de marzo de 2013 surgió cuando un bloque grande fue aceptado por la versión 0.8 pero rechazado por la versión 0.7 debido a un límite de la base de datos. La red se dividió, y no se resolvió con la victoria de la cadena más larga, sino porque los mineros cambiaron deliberadamente a la versión 0.7, de modo que la rama compatible con 0.7 superó a la otra. Esto demostró que las diferencias no intencionadas entre versiones pueden dividir la red, y que en una emergencia la solución puede ser una decisión humana coordinada que anule cuál rama tenía más trabajo en ese momento.
5. Ejemplos históricos ilustran estas mecánicas. P2SH (Pay-to-Script-Hash) se activó en 2012 como un soft fork, permitiendo scripts complejos mientras mantenía la compatibilidad con nodos más antiguos. SegWit (Segregated Witness) se activó el 24 de agosto de 2017 en el bloque 481,824, trasladando los datos de firma fuera de la parte de la transacción utilizada para calcular su ID, corrigiendo la maleabilidad y aumentando la capacidad. Taproot llegó posteriormente en noviembre de 2021 en el bloque 709,632.
6. Verifique la división de Bitcoin Cash en dos exploradores de bloques. El bloque 478,558 es el último bloque que comparten las dos cadenas. Busque el bloque 478,559 en un explorador de Bitcoin y en uno de Bitcoin Cash: son bloques diferentes, y el de Bitcoin Cash tiene un tamaño mayor a 1 MB, lo cual estaba prohibido por las reglas antiguas de Bitcoin. A partir de ese punto, cada cadena considera los bloques de la otra como inválidos.

Datos clave

Ejercicio nueve, seis, tres, uno

Verificación de hechos

Fechas, cifras y afirmaciones verificadas con las fuentes publicadas que se enumeran a continuación.

• A. M. Antonopoulos & D. A. Harding, Mastering Bitcoin, 3rd ed. (2023), ch. 12
• BIP16: Pay to Script Hash (2012)
• BIP141: Segregated Witness (Consensus layer) (2015)
• BIP9: Version bits with timeout and delay (2015); BIP50: March 2013 Chain Fork Post-Mortem