Un Hard Fork cambia las reglas de validez de bloques o transacciones sin mantener la compatibilidad con los nodos antiguos. Para seguir la nueva cadena incompatible, un nodo debe adoptar las nuevas reglas. Ni anunciarlas ni aportar más potencia minera puede obligarlo a hacerlo.
Anna y Pavel ejecutan cada uno un Full Node, un ordenador que comprueba las reglas de Bitcoin de forma independiente. Anna instala un programa que permite bloques mayores; Pavel conserva el límite original. Llega un bloque que cumple las condiciones nuevas, pero supera el límite antiguo. Anna lo acepta y Pavel lo rechaza. No es un fallo de conexión: sus programas discrepan sobre qué puede formar parte del historial compartido. Ese es el significado práctico de Hard Fork. Llamarlo «actualización» no hace que el ordenador de Pavel ignore su regla. Pueden continuar dos ramas si alguien produce bloques para cada una y la gente las utiliza. Si los participantes pasan a un solo conjunto de reglas, no tienen por qué quedar dos redes activas. [1]
El nodo antiguo rechaza el bloque incompatible y la rama construida sobre él. Eso no significa que se quede detenido para siempre. Si los mineros continúan otra rama según las reglas originales, puede seguir aceptando sus bloques. Sin esa continuación, permanece en el último bloque que considera válido. Importan las reglas de su software, no cuántas personas apoyan el cambio. Para seguir la rama incompatible, su operador debe cambiar esas reglas de forma deliberada. [1]
Bitcoin Cash se separó de Bitcoin a la altura de bloque 478559 el 1 de agosto de 2017. Adoptó reglas que permitían bloques mayores que los aceptados entonces por los nodos Bitcoin y creó su propia cadena continua. Los nodos Bitcoin rechazaron los bloques válidos únicamente para BCH; los nodos BCH siguieron su propia historia válida. Este Hard Fork creó una red independiente, en vez de sustituir Bitcoin mediante una actualización dentro de la misma red. [3] [4]
Piensa en el registro de una cantidad recibida que aún no has gastado: Bitcoin llama UTXO a esa salida de transacción sin gastar. Las ramas con un pasado común heredan ese registro y después lo administran por separado. Si controlas las claves necesarias y ambas redes siguen reconociendo esa salida, normalmente puedes gastar las monedas correspondientes en las dos. Eso no duplica su valor: son activos distintos con su propia demanda. Si los fondos están en una plataforma de intercambio, recibir las monedas de la otra red depende también de su política de abonos. [4] [6]
Si tienes monedas en ambas ramas, quizá quieras pagar solo en una. Sin protección, alguien podría copiar esa transacción firmada y transmitirla también en la otra, donde podría ser válida. Es el riesgo de replay. Conviene comprobar la protección de la red concreta y la compatibilidad de la billetera. Por ejemplo, cambiar sighash, las reglas sobre los datos que abarca una firma, puede vincular la transacción a una cadena determinada. Un aspecto distinto de las direcciones ayuda a distinguir redes, pero por sí solo no proporciona protección criptográfica contra replay. [3]
La activación es el punto establecido para empezar a aplicar las reglas nuevas. La altura indica la posición del bloque en la cadena. Una fecha fija, una altura de bloque o una señal minera pueden coordinar a quienes adoptaron la actualización, pero no cambian el software de quien no la adoptó. Si cada conjunto de reglas conserva participantes económicamente importantes, ambas cadenas pueden continuar. Por ello, activar un Hard Fork exige un plan de migración con riesgo de división. [1]
Gobernanza significa aquí cómo deciden los participantes sobre los cambios. Un ticker es el símbolo de negociación de un activo, como BTC o BCH. Los desarrolladores pueden publicar código, los mineros dirigir hashrate, las empresas elegir símbolos de negociación y políticas de depósitos, y los usuarios elegir software. Nada de ello cambia por sí solo las reglas con las que otros nodos verifican los bloques. Una división puede persistir si suficientes participantes independientes mantienen y valoran voluntariamente ambos conjuntos de reglas; no todo cambio incompatible tiene que crear dos redes permanentemente activas. Llamar «actualización» a una rama es una convención social, no una regla de consenso. [1]
Una red puede dividirse sin que nadie pretenda crear una moneda nueva. En marzo de 2013, algunos nodos antiguos no pudieron procesar un bloque con un número inusualmente alto de entradas de transacciones. Alcanzaron un límite de bloqueos de la base de datos, que impiden que operaciones simultáneas modifiquen los mismos datos. La versión más reciente, la 0.8, usaba otra base de datos y aceptó el bloque. Los pools de minería BTC Guild y Slush volvieron a la versión 0.7 y minaron en la rama que también aceptaban los nodos antiguos. Cuando esa rama acumuló más trabajo, los nodos nuevos también pasaron a seguirla. Así se corrigió una discrepancia involuntaria del software; no se buscaba mantener una red separada como Bitcoin Cash. [2]
Un Soft Fork hace más estrictas las reglas existentes. Por eso, un bloque que cumple las nuevas restricciones también cumple las reglas antiguas. Un nodo antiguo puede aceptarlo sin comprobar por sí mismo las restricciones añadidas. Un Hard Fork no ofrece esa compatibilidad: un bloque aceptado por el software nuevo puede infringir las reglas antiguas. Para aceptarlo, quien opera un nodo antiguo debe cambiar las reglas de su software. Tampoco un Soft Fork garantiza que la red permanezca unida: si los mineros producen un bloque que incumple una restricción nueva, los nodos antiguos y nuevos pueden evaluarlo de forma distinta. [1]
Sea V(old) el conjunto de bloques aceptados por las reglas originales. El cambio es un Hard Fork si el software nuevo acepta al menos un bloque fuera de ese conjunto. A menudo se amplía el conjunto válido, pero lo decisivo es la compatibilidad: si un bloque válido para el nodo nuevo puede ser inválido para el antiguo, este último no puede seguir la nueva cadena conservando sus reglas. [1]
Chainwork mide el trabajo acumulado demostrado por la minería de los bloques de toda una rama. Hashrate, en cambio, es la velocidad de los cálculos mineros. Un nodo elige la rama con más trabajo acumulado solo entre las cadenas que cumplen sus reglas. Si un bloque las infringe, acumular más trabajo no lo vuelve aceptable. Por eso, Pavel, en el ejemplo inicial, no aceptará un bloque demasiado grande solo porque la mayoría de los mineros estén construyendo sobre él. Proof of Work puede decidir entre ramas válidas, pero no elegir las reglas en nombre de quien opera el nodo. [1]
Empieza por comprobar la red, la billetera compatible y la protección contra replay. Un nombre conocido o una dirección parecida no bastan. No introduzcas tu Seed Phrase, las palabras de recuperación de la billetera, en un servicio desconocido que prometa reclamar monedas del fork. Si ejecutas un nodo, también puedes comprobar su versión, los nodos conectados, el último bloque aceptado y la huella del bloque donde ocurrió la división. Esa huella se llama hash. Contrasta los datos con la documentación de la red; un explorador web no sustituye tu propia verificación de las reglas. [5] [6]
Para obtener la imagen más completa, lee esta entrada junto con Soft Fork, Reglas de consenso, Full Node, Reorg, Guerra del tamaño de bloque, UTXO. También enlazan con esta entrada Soft Fork, BIP (Bitcoin Improvement Proposal), Reorg, Guerra del tamaño de bloque.