Est-ce ainsi que fonctionnent une réorganisation et un fork dans Bitcoin ?

J'essaie de comprendre comment fonctionnent les réorganisations et les forks qui y sont liés dans Bitcoin. J'ai passé en revue toutes les questions (environ 80/90 d'entre elles) liées à la balise de réorganisation en chaîne, et je pense avoir acquis une certaine idée de la façon dont tout fonctionne, mais j'ai encore quelques incertitudes, que je vais décrire ci-dessous. Tout d’abord, je commencerai par comment je comprends la réorganisation et les forks, puis je poserai les questions.

Les réponses qui m'ont le plus aidé à comprendre comment tout fonctionne (Un grand merci à ces gens formidables ! ) :

Murch :

Pieter Wuille :

Ava Chow :

Merci à tous d'avance pour votre compréhension et votre aide et nous nous excusons sincèrement pour le texte excessif. Toute aide serait appréciée

J'envisage une situation dans laquelle nous sommes synchronisés, n'avons pas été hors ligne, puis nous nous reconnectons.

Les fourches se produisent lorsque deux mineurs créent le bloc suivant (bloc A et bloc B) à peu près en même temps. Dans cette situation, le bloc A est accepté par une partie du réseau, tandis que le bloc B est accepté par une autre partie du réseau. En fonction du bloc qu'un nœud reçoit en premier (via un en-tête ou un message cmpct), le nœud validera d'abord ce bloc (disons A), et si tout va bien, déclarera sa branche comme branche principale/canonique, en la laissant en place. Le bloc A est ensuite propagé à tous ses pairs. Quant au deuxième bloc (bloc B), qu'il ait reçu uniquement l'en-tête ou la totalité du bloc en raison de cmpct, il effectuera uniquement une validation pour vérifier s'il a un PoW valide et un parent connu (tous les autres détails ne sont pas pertinents ; si les transactions sont correctes ou non). De plus, nous transmettrons uniquement le bloc A à tous nos pairs puisqu'il fait partie de notre chaîne principale, tandis que nous gardons B uniquement localement comme l'un des conseils de chaîne. À ce stade, nous avons deux chaînes (principale et « secondaire »), attendant de voir laquelle de ces deux sera ensuite étendue (bloc C). Si la chaîne avec le bloc A est étendue, tout va bien ; nous effectuons une validation régulière, et c'est tout. Cependant, si la chaîne avec le bloc B est étendue, une réorganisation est nécessaire. Dans ce cas, toutes les transactions du bloc A sont renvoyées au pool de mémoire et tous les UTXO dépensés sont renvoyés à l'ensemble UTXO. Après cela, une validation complète est effectuée sur les autres champs de l'en-tête et les transactions du bloc B (si on n'avait que l'en-tête, il faut également envoyer une requête getdata pour l'ensemble du bloc ou une requête getblocktxn pour les transactions manquantes restantes ). Si tout va bien, le bloc C est validé. Si C convient également, il est transmis à tous les pairs et cette branche devient la nouvelle branche canonique/principale.

Mes questions sont :

Est-ce que tout ce qui est écrit ci-dessus est correct ?

Je sais qu'un nœud n'accepte que les blocs dont il connaît le parent (s'il ne le sait pas, ce sont des blocs orphelins). Cependant, ce parent doit-il être exclusivement l'une des extrémités de branche, ou doit-il simplement être l'un des blocs de l'une des branches (soit principale, soit l'une des branches) ? Par exemple, si la chaîne principale comporte 100 000 blocs et qu'il y a deux fourches sur le côté : la première se divise en 20 000 blocs avec la chaîne principale et comporte 5 blocs supplémentaires, et la seconde se divise en 60 000 blocs avec 30 blocs supplémentaires. Un bloc sera-t-il accepté uniquement si un bloc arrive dont le parent est le 100 000ème bloc de la chaîne principale, le 20 005ème bloc du premier fork ou le 60 030ème bloc du deuxième fork ? Ou les blocs dont les parents ne sont pas des pointes de branche seront-ils également acceptés (par exemple, le 86 004ème bloc de la chaîne principale, le 20 002ème bloc du premier fork, etc.) ? Quand je dis accepté, je veux dire validation du PoW et vérifier s'il aurait pu devenir la nouvelle chaîne principale. Si elle devient la chaîne principale, d’autres contrôles de validation suivront

Qu'arrive-t-il aux blocs qui restent dans ce fork obsolète pendant la réorganisation ? Restent-ils tels quels ou les transactions sont-elles rejetées, ne laissant que l'en-tête ?

Si la chaîne avec le bloc B est étendue avec le bloc C, pour moi, cela devient la chaîne principale, donc dans ce cas, je transmets le bloc C à tous mes pairs. Cependant, comme il s'agissait auparavant de la chaîne avec le bloc A, je n'ai pas propagé le bloc B à mes pairs, donc le bloc C sera rejeté en tant que bloc orphelin. Que se passe-t-il si ces pairs n’ont jamais entendu parler du bloc B ? Ils n'accepteront jamais cette branche.

Est-ce que tout ce que j'ai écrit correspond exactement à la façon dont Bitcoin Core met en œuvre la gestion de la blockchain, et rien ici ne fait partie du consensus, à l'exception du suivi de la chaîne avec le plus de travail, ou cela ne fait même pas partie du consensus ? Est-il seulement important de suivre la chaîne qui demande le plus de travail, et la manière dont nous la mettons en œuvre n'a pas d'importance ?