Saltar al contenido
Financial Context Wiki

Hard fork frente a soft fork: compatibilidad, activación y división de la cadena

Un hard fork y un soft fork describen relaciones distintas de compatibilidad entre reglas de consenso antiguas y nuevas. Analiza por separado los conjuntos de bloques válidos, la activación, la validación de nodos, los productores, la preparación operativa, el riesgo de repetición y cualquier división de la cadena.

Actualizado

Análisis educativo del protocolo; no constituye asesoramiento de inversión. Un fork propuesto o activado puede alterar la validación, depósitos, retiros, custodia, contratos, precios, liquidez, tratamiento fiscal y seguridad operativa, y no garantiza un segundo activo duradero.

Respuesta directa

Hard fork y soft fork clasifican un cambio de las reglas de consenso según cómo juzgan los bloques los nodos actualizados y los no actualizados. Sea V_old el conjunto de bloques aceptado por las reglas antiguas y V_new el aceptado por las nuevas. Un soft fork restringe la validez de modo que V_new subset V_old: todo bloque válido bajo las reglas nuevas también lo es bajo las antiguas, aunque un nodo antiguo no aplica la restricción añadida. Un hard fork permite al menos un bloque válido bajo las reglas nuevas que un nodo antiguo rechaza: exists b: b in V_new and b not in V_old. Los conjuntos de un hard fork pueden ser una ampliación o no ser comparables; «hard» no significa simplemente un bloque mayor o una función más radical.

La compatibilidad es asimétrica. En un soft fork exitoso, los nodos no actualizados pueden permanecer en la misma cadena porque aceptan los bloques de mineros o validadores actualizados, pero pueden considerar válido algo que estos rechazan y ofrecer menos garantías. En un hard fork, cuando un productor actualizado crea un bloque fuera del conjunto válido antiguo, los nodos antiguos no pueden seguirlo. Si participantes económicamente relevantes mantienen ambos conjuntos de reglas, pueden resultar dos redes duraderas; si un lado carece de apoyo efectivo, el cambio no tiene por qué crear dos activos persistentes.

Las etiquetas describen reglas, no legitimidad de gobierno, seguridad, respaldo económico ni método de activación. Una propuesta puede llamarse hard fork antes de activarse, un cambio activado puede no producir una división duradera y una incompatibilidad accidental de implementación puede dividir la cadena sin votación de gobierno. La señalización de mineros o validadores puede coordinar la preparación, pero no vuelve válido para un nodo completo un bloque que sus reglas rechazan.

No confundas un fork de consenso con una bifurcación temporal bajo las mismas reglas, una reorganización, un fork de un repositorio de software o una actualización de aplicación. La cuestión operativa es qué red, reglas, condición de activación e historial reconocerá cada nodo, monedero, plataforma, custodio, oráculo y contrato.

Cómo analizar un fork de protocolo

  1. Fija identidad y alcance. Registra chain, network, client version, propuesta de activación, génesis o punto de control finalizado, hash de bloque actual y capa afectada. El mismo nombre en testnet, mainnet, ejecución, consenso o una aplicación puede implicar reglas diferentes.
  2. Compara la validez de consenso. Enumera cada regla modificada de bloque, transacción, firma, transición de estado, gas, marca temporal, finalidad o elección de fork. Clasifica objetos representativos como valid, invalid o unknown bajo ambas versiones; no deduzcas la compatibilidad solo de las notas de versión.
  3. Demuestra la relación entre conjuntos. Comprueba si todo objeto válido nuevo sigue siendo válido bajo las reglas antiguas. Si es así, puede ser compatible como soft fork; si algún bloque válido nuevo es inválido para las reglas antiguas, esos nodos requieren una transición de hard fork. Prueba también qué objetos válidos antiguos pasan a ser inválidos.
  4. Reproduce la activación. Verifica altura, época, tiempo mediano, umbral de señalización, demora de bloqueo, condición de dificultad total o disparador de gobierno en la especificación y el código desplegados. Señalización, bloqueo, activación y aplicación son estados distintos.
  5. Mapea el comportamiento de los participantes. Mide el peso de producción actualizado e identifica nodos completos, relés, monederos, plataformas, custodios, puentes, emisores de stablecoins, oráculos y contratos de cada lado. La tasa de hash o la participación por sí solas no determinan la aceptación económica.
  6. Sigue la división y las transacciones. Rastrea hashes padre y validez bajo ambos conjuntos. Comprueba políticas de confirmación, divergencia del mempool, protección contra repetición, formatos de dirección, identificadores de cadena, dominios de firma, rutas de retiro y si una transacción puede ejecutarse en ambas ramas.
  7. Establece controles operativos. Pausa o prolonga la liquidación si la ascendencia es ambigua; actualiza y respalda de forma deliberada; concilia saldos y pasivos por rama; prueba firma y recuperación sin conexión; y reanuda solo al cumplir criterios explícitos de cadena, nodo, contraparte y finalidad.

Este método separa cuatro hechos que suelen condensarse en «fork»: una propuesta de reglas, su condición de activación, una divergencia observada y la supervivencia económica posterior de una o más ramas. Ninguno demuestra automáticamente el siguiente.

Ejemplos resueltos

1. Compatibilidad de conjuntos válidos

Supón que las reglas antiguas aceptan 100 formas candidatas de bloque y las nuevas solo 80. Si esas 80 están completamente dentro del conjunto antiguo, existe la relación de soft fork; las 20 formas antiguas restantes son rechazadas por nodos actualizados. Las cifras ilustran conjuntos, no probabilidades ni umbrales de votación.

Ahora supón que las nuevas reglas aceptan una forma de bloque que todo nodo antiguo rechaza. Aunque la mayoría de los demás bloques sean válidos bajo ambas reglas, ese contraejemplo rompe la aceptación retroactiva y hace la transición incompatible como hard fork. Que las redes permanezcan divididas depende de productores, usuarios e infraestructura económica después de que aparezca ese bloque.

2. La activación de BIP 34 no es la definición

BIP 34 exigió incluir la altura en la transacción coinbase y usó un mecanismo móvil de preparación. Con 750 of 1,000 bloques anteriores en versión 2 o superior, los nodos rechazaban bloques de versión 2 inválidos; tras 950 of 1,000, rechazaban bloques de versión 1. El BIP registra el bloque 227,835 como el último de versión 1.

Esos umbrales coordinaron el despliegue; no hicieron que el cambio fuera un soft fork. La compatibilidad procedía de restringir lo que aceptaban los nodos actualizados mientras los clientes antiguos seguían aceptando bloques conformes. Más tarde, BIP 9 definió estados de despliegue y bits de versión separados, mostrando de nuevo que la relación entre reglas y el mecanismo de activación son cuestiones distintas.

3. Segregated Witness como diseño de soft fork

BIP 141 introdujo datos witness y comprometió su árbol mediante la transacción coinbase dentro de la estructura de compromiso existente. El diseño permitió que nodos antiguos aceptaran bloques conformes sin comprender ni validar las nuevas reglas de witness, mientras los actualizados las aplicaban.

Eso es aceptación retroactiva, no verificación equivalente. Un nodo antiguo puede ver como menos restringidas las salidas regidas por las nuevas reglas, por lo que quien dependa de sus nuevas propiedades de seguridad necesita validación actualizada. «El software antiguo sigue funcionando» no completa el análisis de riesgo.

4. El DAO Fork de Ethereum

EIP-779 documenta el DAO Fork en el bloque 1,920,000 de mainnet. Describe un cambio irregular de estado que trasladó saldos de una lista de cuentas L al contrato WithdrawDAO, sin cambiar opcodes de EVM, formato de transacción ni estructura de bloque.

Los nodos que aplicaron la transición y los que la rechazaron calcularon estados distintos después del límite. El ejemplo muestra que un hard fork no necesita ampliar bloques ni añadir opcodes: una regla puntual de transición de estado puede crear incompatibilidad, y el apoyo continuado a ambos historiales puede conservar redes separadas.

Riesgos y errores de revisión

Errores de clasificación y especificación

  • Llamar hard fork a toda punta competidora temporal aunque todos los nodos usen las mismas reglas y la elección normal la resuelva.
  • Definir toda relajación como hard fork y toda restricción como soft fork sin probar los conjuntos válidos reales.
  • Equiparar aceptación retroactiva con seguridad retroactiva completa; los nodos antiguos no aplican las nuevas restricciones.
  • Inferir el consenso de una marca, hoja de ruta, nota de versión o rama de repositorio en vez del código y parámetros desplegados.
  • Mezclar actualizaciones de mainnet, testnet, ejecución, consenso, puentes, rollups y aplicaciones.
  • Suponer que propuesta, versión del cliente, umbral de señal, bloqueo y activación son el mismo evento.
  • Tratar la señal de productores como voto vinculante de usuarios, plataformas, custodios o nodos completos.

Riesgos de división y transacción

  • Suponer que la activación garantiza una división o que una división garantiza dos activos líquidos y duraderos.
  • Usar solo la altura cuando las ramas pueden tener bloques diferentes a igual altura; verifica hashes y ascendencia.
  • Enviar durante una división sin revisar protección contra repetición, identificadores, dominios de firma y construcción por rama.
  • Acreditar depósitos de una rama mientras se liquidan pasivos o retiros en otra.
  • Depender de un solo explorador, RPC o rótulo de custodia cuando los proveedores pueden seguir reglas distintas o retrasarse.
  • Ignorar reorganizaciones, finalidad detenida, pares aislados, minería minoritaria, doble voto o falta de datos.
  • Suponer que símbolo, contrato, saldo de stablecoin, precio de oráculo o derecho de puente tiene igual respaldo en ambas ramas.

Riesgos de gobierno y operación

  • Presentar compatibilidad como prueba de legitimidad, descentralización, seguridad o respaldo económico.
  • Actualizar nodos de producción sin binarios reproducibles, copias, límites de reversión, pruebas de migración y hashes independientes.
  • Suponer que bajar de versión siempre es seguro tras introducir nuevos datos, formatos de monedero o condiciones de penalización.
  • Mover claves o «reclamar monedas del fork» con software no verificado que puede revelar secretos o repetir firmas.
  • Tratar saldos de una instantánea como gastables sin revisar vencimientos, bloqueos, estado contractual y política de custodia.
  • Concluir sobre impuestos, contabilidad o valoración antes de establecer propiedad, control, liquidez y reglas locales.

Errores frecuentes

  • Un hard fork siempre crea una moneda nueva. Un segundo activo requiere producción continua, usuarios, infraestructura y mercado; muchas actualizaciones convergen en un solo historial aceptado.
  • Un soft fork no tiene riesgo porque los nodos antiguos funcionan. Pueden seguir la cadena, pero no aplican la regla añadida y ofrecen validación más débil.
  • La mayoría del hash o stake puede cambiar cualquier regla por sí sola. Los nodos completos rechazan bloques inválidos según sus reglas; el peso solo actúa entre bloques aceptados.
  • Hard significa polémico y soft, unanimidad. Los términos clasifican compatibilidad, no consenso social, calidad del gobierno ni controversia.
  • Todo fork visible en un explorador es una actualización. Los bloques competidores con las mismas reglas y las reorganizaciones ocurren sin cambiar el consenso.

Temas relacionados

Fuentes

Navegación

Buscar en la wiki...