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

  • Une réorganisation et un fork se produisent lorsque deux mineurs créent le bloc suivant en même temps, ce qui divise le réseau en acceptant différents blocs.
  • Un nœud n'accepte que les blocs dont il connaît le parent, que ce soit l'une des extrémités d'une branche ou l'un des blocs de l'une des branches.
  • Pendant une réorganisation, les transactions du bloc obsolète sont renvoyées au pool de mémoire et les UTXO dépensés sont renvoyés à l'ensemble UTXO.

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  :

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

Pieter Wuille :

Ava Chow  :

Toute aide serait appréciée

n'

il fait partie de notre chaîne principaleun des conseils de chaîne attendant de voir laquelle de ces deux sera ensuite étendue (bloc C) 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.
  • a pas d'importance ?