Bitcoin Core : : FAQ sur les blocs compacts


Le relais de bloc compact, BIP152, est une méthode de réduction de la quantité de bande passante utilisée pour propager de nouveaux blocs vers des nœuds complets.

Résumé

En utilisant des techniques simples, il est possible de réduire la quantité de bande passante nécessaire pour propager de nouveaux blocs vers des nœuds complets lorsqu’ils partagent déjà une grande partie du même contenu mempool. Les pairs envoient des « esquisses » de blocs compacts aux pairs récepteurs. Ces croquis comprennent les informations suivantes  :

  • L’en-tête de 80 octets du nouveau bloc
  • Identifiants de transaction raccourcis (txids), conçus pour empêcher les attaques par déni de service (DoS)
  • Certaines transactions complètes que le pair expéditeur prédit que le pair récepteur n’a pas encore

Le pair récepteur essaie alors de reconstruire le bloc entier en utilisant les informations reçues et les transactions déjà présentes dans son pool de mémoire. S’il manque toujours des transactions, il les demandera au pair émetteur.

Bitcoin Core : : FAQ sur les blocs compacts

L’avantage de cette approche est que les transactions ne doivent être envoyées qu’une seule fois dans le meilleur des cas, lorsqu’elles sont diffusées à l’origine, ce qui réduit considérablement la bande passante globale.

De plus, la proposition de relais de blocs compacts fournit également un deuxième mode de fonctionnement (appelé mode à bande passante élevée) où le nœud récepteur demande à quelques-uns de ses pairs d’envoyer directement de nouveaux blocs sans demander d’abord l’autorisation, ce qui peut augmenter la bande passante (car deux pairs peut essayer d’envoyer le même bloc en même temps) mais qui réduit encore le temps nécessaire à l’arrivée des blocs (latence) sur les connexions à large bande passante.

Le schéma ci-dessous montre la manière dont les nœuds envoient actuellement des blocs par rapport aux deux modes de fonctionnement du relais de bloc compact. La case grise sur la chronologie du nœud A représente la période pendant laquelle il effectue la validation.

  • Dans Relais hérité, un bloc est validé (la barre grise) par le nœud A, qui envoie alors un message inv au nœud B demandant l’autorisation d’envoyer le bloc. Le nœud B répond par une requête (getdata) pour le bloc et le nœud A l’envoie.

  • Dans Relais haut débit, Le nœud B utilise sendcmpt(1) (send compact) pour dire au nœud A qu’il veut recevoir des blocs dès que possible. Lorsqu’un nouveau bloc arrive, le nœud A effectue une validation de base (telle que la validation de l’en-tête du bloc), puis commence automatiquement à envoyer l’en-tête, les txid raccourcis et la transaction manquante prévue (comme décrit ci-dessus) au nœud B. Le nœud B tente de reconstruire le block et demande toutes les transactions qui lui manquent encore (getblocktxn), que le nœud A envoie (blocktxn). En arrière-plan, les deux nœuds terminent leur validation complète du bloc avant de l’ajouter à leurs copies locales de la blockchain, en maintenant la même sécurité de nœud complète qu’auparavant.

  • Dans Relais à faible bande passante, Le nœud B utilise sendcmpt(0) pour indiquer au nœud A qu’il souhaite minimiser autant que possible l’utilisation de la bande passante. Lorsqu’un nouveau bloc arrive, le nœud A le valide entièrement (il ne relaie donc aucun bloc invalide). Ensuite, il demande au nœud B s’il veut le bloc (inv) afin que si le nœud B a déjà reçu le bloc d’un autre pair. Si le nœud B veut le bloc, il le demande en mode compact (getdata(CMPCT)) et le nœud A envoie l’en-tête, les txid courts et les transactions manquantes prévues. Le nœud B tente de reconstruire le bloc, demande toutes les transactions manquantes et le nœud A envoie ces transactions. Le nœud B valide alors complètement le bloc normalement.

Quels sont les repères utiles pour cela ?

Une annonce de bloc complète moyenne de 1 Mo peut être reconstruite par le nœud récepteur avec une esquisse de bloc de 9 Ko, plus une surcharge pour chaque transaction dans le bloc qui n’est pas dans le mempool du nœud récepteur. Les plus grands croquis de bloc vus dépassent quelques octets au nord de 20 Ko.

Lors de l’exécution d’expériences en direct en mode « haute bande passante » et avec des nœuds pré-remplis jusqu’à 6 transactions. Même sans pré-remplir aucune transaction à l’exception de la coinbase. le reste nécessitant un aller-retour complet sur le réseau.

Étant donné que la différence entre les mempools et les blocs pour les nœuds réchauffés est rarement supérieure à 6 transactions, cela signifie que le relais de bloc compact permet une réduction spectaculaire de la bande passante de pointe requise.

Pour réduire le nombre de choses qui doivent être examinées lors de la mise en œuvre initiale, seule la transaction coinbase sera envoyée de manière préventive.

Cependant, dans les expériences décrites, le nœud expéditeur a utilisé une formule simple pour choisir les transactions à envoyer  : lorsque le nœud A a reçu un bloc, il a vérifié quelles transactions étaient dans le bloc mais pas dans son mempool ; ce sont les transactions qu’il prévoyait que son homologue n’avait pas. Le raisonnement est que (sans informations supplémentaires) les transactions dont vous n’aviez pas connaissance sont probablement aussi les transactions dont vos pairs ne sont pas au courant. Avec cette heuristique de base, une grande amélioration a été constatée, illustrant que les solutions les plus simples sont souvent les meilleures.

Comment le réseau de relais rapide prend-il en compte cela ?

Le réseau de relais rapide (FRN) se compose de deux éléments  :

L’ensemble des nœuds organisés dans le FRN a été soigneusement choisi avec un minimum de relais sur le globe comme priorité numéro un. La défaillance de ces nœuds entraînerait une augmentation significative de la puissance de hachage gaspillée et une éventuelle centralisation supplémentaire de l’exploitation minière. Une grande majorité de la puissance de hachage minière se connecte aujourd’hui à ce réseau.

Le FBRP d’origine est la façon dont les nœuds participants communiquent les informations de bloc les uns aux autres. Les nœuds gardent une trace des transactions qu’ils s’envoient les uns aux autres et relaient les différentiels de blocs en fonction de ces connaissances. Ce protocole est presque optimal pour une communication serveur-client un à un de nouveaux blocs. Plus récemment, un protocole basé sur UDP et Forward Error Correction (FEC), nommé RN-NextGeneration, a été déployé pour être testé et utilisé par les mineurs. Ces protocoles nécessitent cependant une topologie de relais mal connectée et sont plus fragiles qu’un réseau p2p plus général. Les améliorations au niveau du protocole à l’aide de blocs compacts réduiront l’écart de performances entre le réseau organisé de nœuds et le réseau p2p en général. La robustesse accrue du réseau p2p et la vitesse de propagation des blocs dans son ensemble joueront un rôle dans la façon dont le réseau se développera à l’avenir.

Est-ce que cela met à l’échelle Bitcoin?

Cette fonctionnalité est destinée à économiser la bande passante maximale des blocs pour les nœuds, en réduisant les pics de bande passante qui peuvent dégrader l’expérience Internet de l’utilisateur final. Cependant, les pressions de centralisation de l’exploitation minière existent en grande partie en raison de la latence de la propagation des blocs, comme décrit dans la vidéo suivante. La version 1 des blocs compacts n’est pas principalement conçue pour résoudre ce problème.

//www./embed/Y6kibPzbrIc

On s’attend à ce que les mineurs continuent à utiliser le réseau Fast Relay jusqu’à ce qu’une solution à latence plus faible ou plus robuste soit développée. Cependant, les améliorations apportées au protocole p2p de base augmenteront la robustesse en cas de défaillance du FRN et réduiront peut-être l’avantage des réseaux de relais privés, ce qui les rendra inutiles.

De plus.

À qui profitent les blocs compacts ?

  • Utilisateurs de nœud complet qui souhaitent relayer des transactions mais qui disposent d’une bande passante Internet limitée. Si vous souhaitez simplement économiser le plus de bande passante possible tout en relayant les blocs aux pairs, il existe un mode blocs uniquement déjà disponible à partir de Bitcoin Core v0.12. Le mode blocs uniquement ne reçoit les transactions que lorsqu’elles sont incluses dans un bloc, il n’y a donc pas de surcharge de transaction supplémentaire.

  • Le réseau dans son ensemble. La diminution des temps de propagation des blocs sur le réseau p2p crée un réseau plus sain avec une meilleure marge de sécurité de relais de base.

Quel est le calendrier de codage, de test, de révision et de déploiement de la propagation de blocs compacts ?

La première version des blocs compacts a reçu le BIP152, a une implémentation fonctionnelle et est activement testée par la communauté des développeurs.

Comment cela peut-il être adapté pour un relais p2p encore plus rapide ?

Des améliorations supplémentaires au schéma de bloc compact peuvent être apportées. Celles-ci sont liées au RN-NG et sont doubles  :

  • Tout d’abord, remplacez la transmission TCP des informations de bloc par la transmission UDP.

  • Deuxièmement.

La transmission UDP permet aux données d’être envoyées par le serveur et digérées par le client aussi rapidement que le chemin le permet, sans se soucier des pertes de paquets intermittentes. Un client préférerait recevoir des paquets dans le désordre pour construire le bloc aussi vite que possible, mais TCP ne le permet pas.

Afin de traiter les paquets abandonnés et de recevoir des données de bloc non redondantes de plusieurs serveurs, des codes FEC seront utilisés. Un code FEC est une méthode de transformation des données d’origine en un code redondant, permettant une transmission sans perte tant qu’un certain pourcentage de paquets arrivent à destination, où les données requises ne sont que légèrement plus grandes que la taille d’origine des données.

Cela permettrait à un nœud de commencer à envoyer un bloc dès qu’il le reçoit, et permettrait aux destinataires de reconstruire les blocs diffusés simultanément par plusieurs pairs. Tous ces travaux continuent de s’appuyer sur les travaux de blocs compacts déjà achevés. Il s’agit d’une extension à moyen terme, et le développement est en cours.

Cette idée est-elle nouvelle ?

L’idée d’utiliser des filtres bloom (tels que ceux utilisés dans les blocs filtrés BIP37) pour transmettre plus efficacement les blocs a été proposée il y a plusieurs années. Il a également été mis en œuvre par Pieter Wuille (sipa) en 2013, mais il a constaté que les frais généraux ralentissaient le transfert.

09 :12 < sipa> TD  : je travaille sur la propagation de blocs basée sur bip37

10 :27 < BlueMatt> sipa  : bip37 n’a pas vraiment de sens pour le téléchargement en bloc, non ? pourquoi voulez-vous l’arbre de merkle filtré au lieu de la simple liste de hachage (puisque vous savez que vous voulez tous les txn de toute façon)

15 :14 < sipa> BlueMatt  : la surcharge de bip37 pour une correspondance complète est d’environ 1 bit par transaction, plus peut-être 20 octets par bloc environ 15 :14 < sipa> par rapport à l’envoi de la liste txid

00 :11 < sipa> BlueMatt  : j’ai une branche de téléchargement de blocs ~ bip37 fonctionnelle, mais elle est boguée et semble manquer des blocs et est très lente 00 :15 < sipa> BlueMatt  : n’a pas enquêté,:15 < sipa> alors qu’ils ont déjà expiré de notre pool de relais

00 :17 < sipa>il y a un aller-retour supplémentaire, ce qui le rend probablement plus lent que le téléchargement du bloc complet pour de nombreuses connexions 00 :18 < BlueMatt> vous ne pouvez pas non plus demander les txn manquants car ils ne le sont plus à mempool

00.

00 :23 < sipa> gmaxwell  : je ne vois pas comment faire sans aller-retour supplémentaire 00 :23 < BlueMatt> envoie une liste de txn dans ton mempool (ou filtre les fleurs ou quoi que ce soit)  !

Comme indiqué dans l’extrait, la simple extension du protocole pour prendre en charge l’envoi de hachages de transaction individuels pour les transactions de demande ainsi que les transactions individuelles dans des blocs a fini par permettre au schéma de blocs compacts d’être beaucoup plus simple, résistant au DoS et plus efficace.