La dure vérité concernant le drame du hardfork de Luke : Je ne pense pas qu'il y ait quoi que ce soit de mal à construire un _client alternatif_ qui se synchronise avec le dernier chaintip le plus lourd par le biais de ZK, même si cela signifie ne pas télécharger tous les contenus des blocs... même s'il y a un consortium centralisé (multisig) qui contrôle quelles portions de la chaîne sont validées par ZK et quelles portions sont validées normalement. Même si cela signifie que le _client de référence_ (Core) serait bloqué en synchronisant la chaîne si les SEULS données disponibles dans l'ensemble du réseau étaient celles que mon client alternatif hébergeait. Ce serait un problème si le *client de référence* (ou le "client de la vaste majorité") adoptait cela... parce que si la vaste majorité du réseau l'exécutait, cela pourrait conduire à des situations de chaînes séparées. Cela pourrait également poser un problème si le client alternatif qui adopte cela se connecte à d'autres nœuds du réseau, prétendant avoir l'intégralité des données de la blockchain, alors qu'en réalité, il ne les a pas, et essayait de servir des preuves ZK non reconnaissables à la place des données de transaction réelles à des pairs non avertis pour une raison quelconque. Cela serait équivalent à une attaque d'éclipse, mais nous n'avons aucune raison de croire que quiconque a planifié ou planifierait quoi que ce soit de ce genre. En réalité, de tels nœuds (s'ils sont honnêtes) annonceraient probablement simplement un bit de service approprié qui communique aux nœuds en synchronisation (IBD) qu'ils n'ont pas toutes les données. Tout comme les nœuds Core élagués sur le réseau le font (bit de service : NODE_NETWORK_LIMITED == la façon dont votre nœud dit "Je n'ai pas toute l'historique des blocs... vous devez vous connecter à quelqu'un d'autre si vous voulez faire une synchronisation complète"). Je ne suis pas un expert sur les mécanismes de synchronisation de Core, mais je crois que les nœuds Core priorisent déjà les connexions qui diffusent qu'ils ont l'intégralité des données de la blockchain, et évinceront/feront tourner les pairs limités qui ne peuvent pas servir l'historique complet. En général, il est toujours de la responsabilité du client Core de faire tourner les pairs et de trouver des connexions honnêtes sur le réseau, pour avoir une résistance contre les situations d'attaques d'éclipse intentionnellement adversariales ainsi que contre celles qui le sont involontairement. 🔸🔸🔸🔸 Maintenant, là où les choses se compliquent, c'est si je ne me contentais pas de publier/construire/planifier de publier ce client alternatif, mais que je faisais également de la peur publique sur la façon dont le client de référence ***garantit la mort de Bitcoin*** et que j'explorais également des voies légales pour dissuader les nœuds ou les pools de minage de faire fonctionner Core. Je ne sais pas grand-chose sur cette dernière partie (légale), donc je ne vais pas en parler. Quoi qu'il en soit, c'est l'essentiel de pourquoi certaines personnes diront que ce que Luke planifiait n'était pas un hardfork de censure (et seulement un client de hardfork dans une définition technique stricte parce qu'il peut déclencher une séparation de chaînes dans des conditions peu probables), tandis que d'autres observent le contexte de peur/légal qui peint de manière globale un tableau plutôt néfaste. Fin.

et *quelles* portions sont validées normalement... faute de frappe dans le premier paragraphe

Dans le cas des Knots, ce qui précède pourrait très bien être destiné à être une fonctionnalité optionnelle, et non quelque chose que tous les nœuds feraient par défaut.