Bitcoin Core : : Mise à l'échelle en chaîne


L’article suivant vise à mettre en évidence les étapes de développement qui ont permis de préserver une expérience fiable pour les utilisateurs du client logiciel Bitcoin au fil des ans. Enfin.

Mise en cache des signatures

Version : Bitcoin-Qt 0.7.0

La vérification des signatures ECSDA est l’une des opérations les plus lourdes en termes de calcul effectuées au niveau des pairs. Parce qu’ils doivent être vérifiés pour chaque transaction. C’était le cas pour les premières versions du logiciel qui vérifiaient à la fois les signatures avant qu’elles n’entrent dans un mempool de nœud et après qu’elles aient été reçues dans un bloc.

Bitcoin Core : : Mise à l'échelle en chaîne

Afin de gagner en efficacité, les développeurs ont créé un cache permettant aux nœuds de stocker les signatures précédemment validées et d’ignorer les tâches redondantes une fois que les transactions sont devenues un bloc accepté.

De plus, le cache de signature atténue également un vecteur DoS introduit par le potentiel de transactions spécialement conçues pour bloquer les clients Bitcoin.

Plus d’informations

Ultraprune + LevelDB

Version : Bitcoin-Qt 0.8.0

Ultraprune a été l’une des premières mises à jour majeures du logiciel Bitcoin visant à résoudre les frais généraux associés à la validation des données de transaction de la blockchain. Les versions précédentes du client de référence Bitcoin maintenaient un index de toutes les sorties de transaction, dépensées ou non dépensées. Ultraprune a considérablement réduit la taille de cet index avec l’idée que vous n’aviez besoin que de garder une trace des sorties non dépensées, et une sortie – une fois dépensée – peut être entièrement supprimée des index.

Pour y parvenir, une nouvelle disposition de la base de données a été mise en œuvre qui alloue les sorties de transaction non dépensées à un format personnalisé compact afin de réduire la taille des informations requises pour le travail de validation.

Pour optimiser davantage les performances du système, Ultraprune a été introduit en parallèle avec LevelDB, qui rendait obsolète l’ancienne technologie de base de données BDB. Dans l’ensemble, l’impact a été notable  : en fonction de leur matériel, les utilisateurs ont pu constater une amélioration d’au moins un ordre de grandeur lors de la validation des données de la blockchain. Cette nouvelle structure de base de données ouvrirait également la voie à de futurs travaux sur l’élagage et des implémentations plus légères des nœuds complets Bitcoin.

Plus d’informations

Vérification de script parallèle

Version : Bitcoin-Qt 0.8

Bien qu’il s’agisse d’un changement plus subtil, la transition de la vérification des scripts vers un processus plus parallélisé a supprimé une surcharge importante des temps de validation des blocs. Les premières versions du logiciel valideraient les données de script à partir des entrées entre chaque extraction UTXO, créant un problème de performances en raison du traitement linéaire de toutes les actions. Cela enfreint un principe de base pour la conception de processus informatiques efficaces, qui dicte que le calcul doit avoir lieu en même temps que les tâches d’E/S, lorsque cela est possible. Dans cet esprit, le mécanisme de validation de bloc a été repensé afin de pouvoir allouer des vérifications de script à des threads parallèles afin que leur vérification puisse avoir lieu avant même que le client n’ait fini de récupérer tous les UTXO du bloc. Pour ce faire, les actions de vérification de script sont stockées dans une file d’attente après le traitement des transactions et sont gérées séparément des autres tâches de validation d’entrée.

En conséquence. Lors des tests de l’implémentation, les développeurs ont noté une accélération de 35 % à 100 % lors de l’analyse comparative par rapport aux versions précédentes du logiciel.

Plus d’informations

Version : Bitcoin Core 0.10

S’efforçant d’améliorer encore le temps de téléchargement initial des blocs, le projet Core a introduit fin 2014 une importante réarchitecture du mécanisme utilisé par les nœuds pour se synchroniser avec la chaîne valide la plus active.

Initialement, le processus d’amorçage d’un nouveau client Bitcoin impliquerait qu’un utilisateur récupère les données de bloc d’un seul pair, avec pour conséquence que toute interruption ou diminution de la qualité de la connexion bloquerait considérablement le processus. Avec une taille de blockchain sans cesse croissante, cela entraînerait un temps d’attente parfois énorme pour que la synchronisation se termine, avec un grand pourcentage d’utilisateurs signalant des périodes allant jusqu’à plusieurs jours en fonction de leur matériel.

La synchronisation des en-têtes d’abord atténue complètement ce problème en utilisant une nouvelle méthode qui implique que les nœuds téléchargent et valident d’abord les en-têtes de bloc à partir d’un seul pair, puis récupèrent les données de bloc en parallèle à partir d’une multitude d’autres.

Les plaintes concernant le temps de téléchargement initial du bloc sont fréquentes depuis les premiers jours de Bitcoin. Avec la première synchronisation des en-têtes, le logiciel a fait un grand pas en avant en termes de convivialité pour les nouveaux utilisateurs. Plutôt que de perdre de nombreuses heures sur une synchronisation peu fiable, les nœuds peuvent désormais tirer parti de l’ensemble de leur réseau de pairs et réduire considérablement le temps d’amorçage. Avec l’utilisation d’algorithmes plus intelligents, une autre amélioration asymptotique a été apportée à cet aspect crucial de la durabilité à long terme de Bitcoin.

Plus d’informations

Bloquer l’élagage des fichiers

Version : Bitcoin Core 0.11

L’élagage des anciennes données était un concept décrit pour la première fois par Satoshi Nakamoto dans son livre blanc comme une solution potentielle à la pénurie d’espace disque. Malheureusement, la conception originale était inadéquate et n’a pas pu être mise en œuvre comme l’avait imaginé son créateur. Sept ans plus tard, alors que la blockchain atteint plus d’une centaine de gigaoctets.

L’élagage des fichiers en bloc tire parti des travaux antérieurs avec ultraprune ; les utilisateurs qui ont initialement téléchargé et validé la blockchain peuvent désormais supprimer les données brutes de plus de 288 blocs. Étant donné que ces nœuds conservent toujours l’ensemble UTXO complet, ils restent capables de valider les données non dépensées, ce qui est suffisant pour valider complètement les nouveaux blocs et se protéger contre les doubles dépenses potentielles.

Bien sûr, l’élagage implique qu’il reste un nombre suffisant de nœuds d’archivage pour servir les données complètes de la blockchain. D’autre part, cette innovation élargit la gamme des validateurs en rendant plus rentable le fait de le rester. Dans l’ensemble.

Plus d’informations

libsecp256k1

Version : Bitcoin Core 0.12

Après des mesures, il a été déterminé que la prochaine étape après avoir résolu les inefficacités du téléchargement de la blockchain était de s’attaquer au goulot d’étranglement de la vérification des transactions et à sa lourde charge informatique. Le projet Core a entrepris de le faire en utilisant une nouvelle bibliothèque conçue pour optimiser les performances des opérations ECDSA. ECDSA (Elliptic Curve Digital Signature Algorithm) est l’épine dorsale de l’infrastructure à clé publique de Bitcoin et est utilisé chaque fois qu’un utilisateur déplace des pièces en signant un message avec ses clés privées. Ces signatures doivent être vérifiées par chaque pair du réseau afin de préserver l’intégrité du registre.

Les premiers développeurs avaient longtemps envisagé de s’éloigner de la bibliothèque OpenSSL d’origine et après 5 ans de considérations de conception, de tests et d’examen par les pairs, la bibliothèque libsecp256k1 de Pieter Wuille a été introduite en remplacement. Comme prévu, la mise en œuvre a entraîné une accélération majeure du processus de validation de signature derrière chaque transaction Bitcoin. Les benchmarks ont rapporté des améliorations de 5 à 7 fois par rapport à la mise en œuvre d’OpenSSL. Pour les utilisateurs, cela se traduirait par une économie de jusqu’à la moitié du temps d’amorçage généralement consacré aux opérations ECSDA, l’une des étapes les plus laborieuses de la synchronisation d’un nouveau nœud à partir de zéro.

Compte tenu de la croissance de l’activité de transaction Bitcoin, cette mise à niveau était essentielle pour préserver une expérience utilisateur raisonnable pour les pairs du réseau. Une fois de plus.

Plus d’informations

Limitation du pool de mémoire

Version : Bitcoin Core 0.12

Une vulnérabilité de longue date du logiciel Bitcoin était son incapacité à gérer correctement l’inondation du pool de mémoire d’un pair. En effet, un attaquant pourrait envoyer un grand nombre de transactions de faible valeur et à faible coût qui s’accumuleraient dans le pool de mémoire jusqu’à surcharger la mémoire disponible. La seule mesure efficace contre cela était d’augmenter les frais de relais minimum du logiciel, ce qui ne laissait toujours aucune limite supérieure à la taille potentielle du mempool.

Pour remédier à cela, les développeurs du projet Core ont implémenté une taille maximale de pool de mémoire stricte avec des politiques d’éviction spécifiques triant les transactions par frais et expulsant les moins payantes en premier. Afin d’empêcher les transactions avec les mêmes frais de réintégrer le pool de mémoire, le nœud augmentera son tarif de relais minimum effectif pour correspondre à celui de la dernière transaction évincée plus le tarif de relais minimum initial.

La configuration de la taille maximale est laissée aux utilisateurs, la taille par défaut étant de 300 mégaoctets. en général, rend l’ensemble du réseau plus fiable.

Plus d’informations

Dans la partie 2.