Hard forks: Rompiendo la compatibilidad hacia atrás
Un hard fork cambia las reglas del protocolo de una manera que no es compatible hacia atrás. Los nodos que ejecutan software antiguo rechazarán los bloques creados bajo las nuevas reglas, y los nodos que ejecutan software nuevo rechazarán los bloques creados bajo las reglas antiguas. A menos que cada participante se actualice, la red se divide en dos cadenas separadas — cada una con su propio historial de transacciones en adelante.
Los hard forks son la opción nuclear de la gobernanza blockchain. Pueden cambiar prácticamente cualquier cosa: el tamaño de bloque, el algoritmo de minería, la política monetaria o el mecanismo de consenso en sí. Debido a que requieren adopción universal para evitar una división de cadena, los hard forks son inherentemente contenciosos. Si alguna porción significativa de la red se niega a actualizar, el resultado son dos versiones competidoras de la criptomoneda — como sucedió con Bitcoin Cash en 2017.
Algunas blockchains usan hard forks rutinariamente para actualizaciones (Ethereum ha ejecutado muchos hard forks planificados). Bitcoin, por el contrario, trata los hard forks como último recurso. La fuerte preferencia de la comunidad de Bitcoin por la compatibilidad hacia atrás significa que los hard forks en Bitcoin solo han ocurrido cuando una facción de la comunidad deliberadamente eligió crear una nueva cadena.
Soft forks: Endureciendo las reglas
Un soft fork cambia las reglas del protocolo de una manera que es compatible hacia atrás. Los nodos antiguos seguirán aceptando bloques creados bajo las nuevas reglas porque los soft forks solo endurecen las reglas — hacen que algunas transacciones o bloques previamente válidos sean inválidos, pero nunca hacen que los previamente inválidos sean válidos.
Esta distinción es sutil pero crítica. Considera una analogía: si una ciudad reduce el límite de velocidad de 100 km/h a 80 km/h (soft fork), cualquiera que conduzca a 70 km/h sigue siendo legal bajo ambas reglas, la antigua y la nueva. Pero si la ciudad aumenta el límite de velocidad de 100 km/h a 120 km/h (hard fork), alguien que conduzca a 110 km/h es legal bajo las nuevas reglas pero ilegal bajo las antiguas — las reglas antiguas no pueden acomodar el cambio.
En Bitcoin, SegWit es el ejemplo canónico de soft fork. Reestructuró cómo se almacenan las firmas de transacciones, pero los nodos antiguos aún ven las transacciones SegWit como válidas (aparecen como transacciones "anyone-can-spend" para los nodos antiguos, lo cual es seguro porque los mineros aplican las nuevas reglas). Esta compatibilidad hacia atrás significó que SegWit pudo activarse sin forzar a cada nodo a actualizarse, evitando una división de cadena.
El proceso BIP y el consenso
El proceso de actualización de Bitcoin se centra en las Propuestas de Mejora de Bitcoin (BIP). Introducidas por primera vez en 2011 (como BIP-0001 por Amir Taaki), el proceso BIP proporciona una forma estandarizada de proponer, discutir e implementar cambios en el protocolo de Bitcoin.
El ciclo de vida de un BIP típicamente sigue estas etapas: un autor redacta una propuesta y la envía a la lista de correo bitcoin-dev para discusión. La propuesta es revisada, debatida y a menudo revisada múltiples veces. Si obtiene suficiente apoyo de los desarrolladores, se implementa en Bitcoin Core (la implementación de referencia). Para cambios a nivel de consenso (soft forks), los mineros deben señalar preparación incluyendo datos específicos en los bloques que minan.
Los mecanismos de activación han evolucionado con el tiempo. BIP 34 introdujo la activación basada en versión. BIP 9 formalizó la señalización de los mineros con un umbral del 95%. BIP 8 añadió una opción de "soft fork activado por usuarios" como respaldo si los mineros se niegan a señalar. La activación de Taproot en 2021 usó Speedy Trial — un mecanismo de compromiso que dio a los mineros un umbral de señalización del 90% dentro de un plazo fijo, después del cual la actualización sería reconsiderada. Esta evolución refleja el refinamiento continuo de la comunidad sobre cómo equilibrar velocidad, seguridad y descentralización en el proceso de actualización.
SegWit, Taproot y el futuro
Segregated Witness (SegWit), activado en agosto de 2017, fue el soft fork más impactante en la historia de Bitcoin. Al separar los datos de firma de los datos de transacción, SegWit efectivamente aumentó la capacidad de los bloques a aproximadamente 1.8 MB sin cambiar el límite base de tamaño de bloque de 1 MB. Más importante aún, corrigió la maleabilidad de transacciones, un error de larga data que impedía la construcción de canales de pago confiables — habilitando la Lightning Network para pagos rápidos y baratos fuera de cadena.
Taproot, activado en noviembre de 2021, fue el segundo gran soft fork. Introdujo firmas Schnorr (más eficientes y respetuosas de la privacidad que las firmas ECDSA que Bitcoin usaba originalmente), MAST (Merkelized Alternative Script Trees, que ocultan condiciones de gasto no utilizadas) y Tapscript (un lenguaje de scripting actualizado). Juntos, estos cambios hicieron que las transacciones complejas de Bitcoin — billeteras multi-firma, contratos con bloqueo temporal y canales Lightning — se vieran idénticas a las transacciones simples en la blockchain, mejorando la privacidad para todos los usuarios.
Las futuras propuestas de soft fork incluyen OP_CTV (BIP 119, que habilitaría covenants — restricciones sobre cómo se puede gastar Bitcoin después de recibirlo) y varias propuestas de OP_CAT para scripting mejorado. El ritmo deliberado de las actualizaciones de Bitcoin — típicamente años desde la propuesta hasta la activación — refleja la convicción de la comunidad de que la estabilidad y la seguridad son más importantes que las características. Bitcoin se actualiza lentamente porque puede permitírselo. El sistema funciona, y cada cambio conlleva el riesgo de romper algo que gestiona cientos de miles de millones de dólares en valor.