Soft fork vs Hard fork
Dos formas de cambiar las reglas del protocolo. Una mantiene la red unida, la otra la divide.
Cambios de consenso
Las reglas de consenso son las que determinan qué bloques y transacciones son válidos. Cambiarlas es el tipo de modificación más delicada en Bitcoin.
Hay dos formas de hacer cambios de consenso: soft forks y hard forks.
Soft fork: endurecer las reglas
Un soft fork hace las reglas más restrictivas. Cosas que antes eran válidas dejan de serlo, pero todo lo que era inválido sigue siendo inválido.
Propiedad clave: Los nodos que no actualicen siguen aceptando los bloques nuevos (porque son un subconjunto de lo que antes era válido).
Ejemplo: SegWit
Antes de SegWit, cualquier output con formato OP_0 <datos> era gastable por cualquiera (era un "anyone-can-spend" técnicamente).
SegWit redefinió estos outputs: ahora solo son gastables si se cumplen las reglas de witness.
Un nodo viejo ve una transacción SegWit y piensa "este output extraño ha sido gastado, ok". No sabe que hay reglas adicionales que un nodo nuevo sí verifica.
El bloque es válido para nodos viejos y nuevos, pero por razones diferentes.
Hard fork: relajar o cambiar las reglas
Un hard fork hace algo que antes era inválido ahora válido, o cambia las reglas de forma incompatible.
Propiedad clave: Los nodos que no actualicen rechazarán los bloques nuevos. La cadena se divide.
Ejemplo: Bitcoin Cash (2017)
Bitcoin tenía un límite de bloque de 1 MB. Bitcoin Cash aumentó ese límite a 8 MB.
Un bloque de 2 MB es inválido según las reglas de Bitcoin, pero válido según Bitcoin Cash. Los nodos de Bitcoin rechazan los bloques de Bitcoin Cash y viceversa.
Resultado: dos cadenas separadas, dos monedas diferentes, dos redes.
Por qué Bitcoin evita hard forks
Un hard fork divide la red:
- Los usuarios tienen que elegir qué cadena seguir
- Si no hay consenso claro, hay dos monedas compitiendo
- El valor se fragmenta
- Hay confusión y riesgo para usuarios
Los soft forks son preferidos porque:
- Son retrocompatibles: nodos viejos siguen funcionando
- No dividen la red involuntariamente
- Los usuarios que no actualizan pueden seguir participando (con funcionalidad reducida)
Mecanismos de activación de soft forks
BIP 9: Señalización de mineros
Los mineros señalan en sus bloques si apoyan la actualización. Si un umbral (típicamente 95%) se alcanza durante un período, la actualización se activa.
Problema: Da poder de veto a los mineros. En 2016-2017, algunos mineros bloquearon SegWit por razones políticas.
BIP 8: Activación con opción de forzado
Similar a BIP 9, pero con una fecha límite. Si los mineros no activan antes de la fecha, los nodos pueden activar de todos modos.
Esto remueve el poder de veto de los mineros.
UASF (User Activated Soft Fork)
Los usuarios declaran que a partir de cierta fecha, rechazarán bloques que no sigan las nuevas reglas. Si suficientes usuarios (nodos, exchanges, empresas) lo hacen, los mineros se ven forzados a cumplir o minar bloques que nadie acepta.
UASF fue la amenaza que finalmente activó SegWit en 2017.
Speedy Trial
Para Taproot se usó "Speedy Trial": un período corto de señalización de mineros. Si se alcanzaba el umbral, se activaba. Si no, se podía intentar otra cosa.
El umbral se alcanzó fácilmente y Taproot se activó sin drama en noviembre 2021.
La resistencia al cambio como feature
Que sea difícil cambiar Bitcoin es intencional.
Si fuera fácil cambiar las reglas, un grupo con poder podría modificar la política monetaria, censurar transacciones, o cambiar propiedades fundamentales.
La dificultad de los cambios de consenso protege a los usuarios de cambios que no quieren.
La resistencia de Bitcoin a hard forks es una de sus propiedades más valiosas. Cambiar las reglas del juego es extremadamente difícil. Esto protege a los usuarios de cambios arbitrarios y mantiene las promesas del protocolo.
Las excepciones necesarias
Ocasionalmente, cambios son necesarios:
- Corregir bugs de seguridad
- Mejorar la escalabilidad
- Añadir funcionalidades importantes
El proceso de BIPs y soft forks permite hacer estos cambios de forma que minimiza la disrupción y maximiza el consenso.
Bitcoin ha evolucionado significativamente desde 2009 sin necesidad de hard forks. SegWit, Taproot, y docenas de mejoras menores se han implementado manteniendo la red unida.