SOFT / HARDCOMPARACIONES BASADAS EN FUENTES
Soft Fork vs. Hard Fork
Examine los cambios en las reglas de validez, la compatibilidad de nodos sin actualizar y los riesgos de activación o división de la red.
Soft Fork endurece las reglas para que los bloques válidos con ellas también cumplan las comprobaciones antiguas. Hard Fork permite además algunos bloques que las reglas antiguas rechazan. La distinción describe compatibilidad, no tamaño ni apoyo político del cambio.
02Diferencias importantes
Las reglas nuevas excluyen algunos bloques antes permitidos. Un bloque que las cumple sigue siendo compatible con las antiguas.
Las reglas nuevas admiten al menos algunos bloques antes inválidos. Un nodo antiguo los rechaza incluso con mucho trabajo acumulado.
Puede seguir una cadena compatible, pero no verifica las restricciones nuevas. En SegWit, por ejemplo, no valida los datos witness.
Sin cambiar reglas no puede validar y aceptar bloques recién permitidos que antes estaban prohibidos; puede quedarse en otra rama o dejar de avanzar.
Aplica las reglas adicionales al cumplirse las condiciones de activación. La señalización no sustituye la validación real.
Aplica el nuevo conjunto según su activación. Actualizar un nodo no cambia las reglas de los demás participantes.
Las discrepancias sobre activación o aplicación pueden producir ramas distintas. La compatibilidad hacia atrás no garantiza por sí sola una transición fluida.
Una división duradera ocurre si distintos grupos siguen manteniendo cadenas incompatibles. El nombre del cambio no garantiza dos redes viables.
Un BIP describe una propuesta, no una aprobación automática. BIP9, por ejemplo, distingue señalización, fijación de la activación y reglas activas.
Publicar un BIP tampoco activa nada aquí. Los operadores deben conocer las reglas específicas de transición y las consecuencias de la incompatibilidad.
Soft Fork no garantiza que no haya división de la cadena, y Hard Fork no crea automáticamente una moneda nueva. El resultado depende de la activación, aplicación y continuidad de historiales incompatibles por grupos distintos.
Comparamos cambios de consenso, no actualizaciones ordinarias de interfaz o políticas de mempool. BIP9, BIP16 y BIP141 son ejemplos concretos; sus condiciones de activación no son universales para toda propuesta.