développement de base de bitcoin : Quels sont les cas d'utilisation où de très anciens fichiers rev*.dat sont nécessaires  ?


  • et ils sont 1 ::1 avec des fichiers de bloc (c’est-à-dire que pour un NNNNN donné, les fichiers blkNNNNN.dat et revNNNNN.dat contiennent des informations pour le même

    blocs),

  • et ils sont écrits et fragmentés dans l’ordre dans lequel les blocs sont reçus par le nœud (du réseau)
  • Cette hypothèse est incorrecte. Les fichiers rev*.dat sont en fait écrits par ordre de hauteur. C’est parce qu’ils sont écrits à un autre moment. Les données d’annulation d’un bloc ne sont écrites qu’après avoir été connectées à la pointe de la chaîne, de sorte que les données d’annulation finissent par être dans l’ordre dans lequel les blocs sont connectés. Ainsi, pour les blocs téléchargés mais jamais connectés, les données d’annulation n’existent pas pour eux (bien que ce cas soit peu probable car les blocs ne sont pas téléchargés à moins qu’ils ne soient censés être connectés).

    Puis: De très vieux fichiers rev*.dat sont-ils déjà utilisés ? Dites, ceux qui appartiennent à des blocs enfouis à plus de 100 blocs de profondeur du haut de la chaîne ? S’ils sont déjà utilisés, quel est le cas d’utilisation ?

    En ce qui concerne le fonctionnement du nœud, non, les anciennes données d’annulation ne sont pas réellement utilisées. Cependant, il a certaines utilisations en dehors du fonctionnement des nœuds, en particulier dans l’examen de la blockchain via RPC et la création du filtre de bloc et des indices de statistiques de pièces.

    développement de base de bitcoin : Quels sont les cas d'utilisation où de très anciens fichiers rev*.dat sont nécessaires  ?

    Le RPC utilise des données d’annulation à certains endroits car il contient les UTXO qui ont été dépensés par ce bloc. Cela permet à getblock de calculer les frais de transaction payés pour chaque transaction dans le bloc. Cependant, ce n’est pas une exigence stricte, et si les données d’annulation ne sont pas trouvées, alors il ne calcule tout simplement pas les frais.

    Un autre RPC qui utilise les données d’annulation est getblockstats qui utilise les données d’annulation pour calculer également les frais pour le bloc ainsi que le changement de taille de l’ensemble UTXO causé par le bloc. Si l’annulation n’existe pas, ce RPC échouera.

    Pour les indices de filtre de bloc et de statistiques de pièces, les données d’annulation sont utilisées pour les créer car elles fournissent un instantané des modifications apportées à l’ensemble UTXO. Cela permet à l’index d’être rempli sans avoir à suivre l’ensemble UTXO pendant sa construction, ce qui réduit l’utilisation de la mémoire et augmente les performances.

    Pour le fonctionnement du nœud, les données d’annulation ne sont nécessaires que si le bloc devait être déconnecté de la pointe. Cela ne se produit que lorsque les réorganisations se produisent. Cependant, Bitcoin est construit avec la possibilité qu’il puisse y avoir une réorganisation de travail extrêmement importante qui pourrait réorganiser des choses qui sont considérées comme de l’histoire ancienne.

    Cependant, les anciennes données d’annulation ne sont en effet pas utilisées dans le fonctionnement du nœud, et il pourrait y avoir un mode ajouté qui les supprime. Sur mon nœud, cela totalise 48 Go de données, donc les économies d’espace ne sont pas aussi importantes que l’élagage normal.

    (et, par rapport à la réponse ici à la première question de la liste suivante, quelle est la corruption de la base de données qui se produit – vraisemblablement à l’état UTXO – si les fichiers rev sont tous supprimés et pourquoi est-il nécessaire de les régénérer ?)

    Ils doivent être régénérés en raison du fonctionnement de l’index de bloc. Puisqu’il contient également l’emplacement des données d’annulation, si ces données étaient manquantes, l’index de bloc trouvera qu’il s’agit d’une erreur et nécessitera donc une réindexation. Si une option était ajoutée pour permettre la suppression des fichiers rev*.dat, cela devrait évidemment être modifié.

    (question bonus  : étant donné un txindex  : y a-t-il quelque chose dans le fichier rev*.dat qui ne peut pas être régénéré simplement en regardant les blocs dans le fichier blk*.dat correspondant et en utilisant le txindex pour trouver les transactions précédentes ?

    Oui, mais ce serait assez lent.