bitcoin core : Comment les en-têtes d'abord empêchent-ils les attaques par remplissage de disque ?

[pxn_tldr]

Pour ajouter à l'autre réponse, depuis Bitcoin Core 24.0, une protection supplémentaire a été mise en œuvre contre le spam d'en-tête de faible difficulté  : pré-synchronisation de l'en-tête.

avons déjà plus à nous soucier du blocage du spam à faible difficulté. Les blocs ne sont tout simplement pas téléchargés à moins qu'ils ne fassent partie d'une chaîne qui s'est avérée suffisamment bonne.

en-têtes qui ne valent jamais rien de précieux. Étant donné que les en-têtes sont envoyés dans l’ordre direct, il n’y a aucun moyen de savoir au début quelle sera la qualité du résultat. L'ancienne solution (points de contrôle) n'est pas satisfaisante  : elle repose sur un logiciel mis à jour avec des remplacements codés en dur sur la chaîne acceptable. Depuis Bitcoin Core 26.0, les points de contrôle demeurent, mais n'ont pas été mis à jour depuis 2014. À présent, le minage est devenu tellement moins cher par hachage qu'un attaquant pourrait de manière réaliste lancer une attaque après le dernier point de contrôle.

bitcoin core : Comment les en-têtes d'abord empêchent-ils les attaques par remplissage de disque ?

Depuis Bitcoin Core 24.0, une nouvelle solution a été implémentée : la pré-synchronisation des en-têtes.

L'idée est que la synchronisation des en-têtes (qui précède la synchronisation des blocs) se décompose en deux phases  :

  • Dans une première phase, la présynchronisation des en-têtes, les en-têtes d'un homologue sont téléchargés et vérifiés, mais non stocké, parce qu'on ne sait pas encore s'ils seront assez bons. Au lieu de cela, seul un hachage très compact (salé) de ces en-têtes est conservé (dans la mémoire par homologue, supprimé lors de la déconnexion)
  • Dans une deuxième phase, le retéléchargement des en-têtes, les mêmes en-têtes sont à nouveau téléchargés depuis le même homologue et comparés au hachage stocké

S'il y a une correspondance, ils sont transmis à la validation complète de l'en-tête, qui les stocke et déclenchera le téléchargement du bloc.

Cette approche a un coût  : la synchronisation des en-têtes est effectivement effectuée deux fois, ce qui double le coût de la bande passante (qui est encore faible par rapport au téléchargement de blocs complets), mais supprime la dernière dépendance aux points de contrôle dans la base de code. Ils seront probablement supprimés dans une future version.

pas seulement la fin. La structure réelle consiste en un seul hachage salé de 1 bit tous les environ 600 blocs. Pour compenser le (extrêmement) petit hachage, lors du retéléchargement, il existe un tampon d'environ 14 000 en-têtes qui sont téléchargés avant validation. Ce n'est que si tous les ~23 hachages de 1 bit de ces 14 000 en-têtes correspondent que le début du tampon est transmis à la validation. Cela signifie que chaque en-tête fait l'objet d'une vérification de 23 bits avant la validation, ce qui coûterait à un attaquant des millions de tentatives pour réussir.