La latence, le talon d'Achille du réseau
Lorsque nous parlons de latence, dans le cas du Cloud, nous parlons du délai qui s’écoule pour qu’un paquet réseau, un morceau d’un message, ne soit livré à son destinataire. Sur le Cloud, il est admis de considérer que ce délai dépend pour l’essentiel du temps de traitement par les nœuds du réseau, car la circulation sur la fibre optique se fait quasiment à la vitesse de la lumière. Traverser l’océan ne prend alors que quelques dizaines de millisecondes.
Dans le cas de Bitcoin, nous pouvons appliquer le même raisonnement pour comprendre le temps nécessaire au traitement d’une transaction. La première étape concerne l’enregistrement de la transaction dans un bloc : le délai avant que ce bloc ne soit « miné » (la réalisation du traitement nécessaire à son ajout à la chaîne) dépend des frais avancés par l’auteur de la transaction et de la congestion du réseau. C’est d’ailleurs la raison pour laquelle, lorsque beaucoup de monde soumet des transactions, les frais montent : l’ensemble fonctionne un peu comme une enchère, où le premier servi sera celui qui paie les frais les plus élevés. Les autres devront attendre jusqu’à ce que suffisamment de transactions soient écoulées, et que le réseau se décongestionne.
Mais une fois miné arrive la deuxième étape : le bloc doit être propagé sur le réseau… Mais alors, combien de temps prend cette partie du processus, et comment s’explique ce délai ? Avant de répondre à cette question, nous allons prendre le temps de reposer le fonctionnement d’un réseau classique, avant de nous pencher sur le cas spécifique de Bitcoin.
La grande aventure du paquet réseau
Un paquet réseau contient un fragment d’une requête envoyée sur le réseau. Lorsque ce paquet traverse un nœud (routeur, switch, etc.) dans un réseau classique, il subit plusieurs étapes de traitement dont voici les principales.
L’interface d’entrée
Le paquet est reçu par une interface physique, qui recalculera un code de contrôle pour ensuite le comparer avec la valeur qui a été calculée à l’émission du paquet. Cette opération permet de vérifier son intégrité : que le paquet n’ait pas été modifié en cours de route.
L’interface va ensuite vérifier l’adresse de destination. S’il s’agit de sa propre adresse, il va transmettre le paquet à l’application qui le traitera, sinon il le transmet au prochain nœud du réseau. Sur certains protocoles, l’interface va également contrôler un « Time To Live », et le décrémenter (le réduire d’une unité). Si la valeur de ce TTL tombe à zéro, le paquet est rejeté avec un message « Time Exceeded » (en fait de « time », il s’agit plutôt d’un nombre de rebonds sur un nœud maximum atteint).
Filtrage et politiques de sécurité
L’interface pourra également appliquer des politiques de sécurité et de traduction. Par exemple, une adresse de réseau privé peut être traduite en adresse de réseau public pour que le paquet puisse transiter de l’un vers l’autre. Les politiques peuvent également aboutir au blocage du paquet, car l’émetteur n’a pas les accès requis pour envoyer son paquet vers la destination qu’il lui a affectée.
Routage et commutation du paquet
Arrive ensuite le routage à proprement parler, qui nécessite la consultation d’une table dédiée. Celle-ci est régulièrement mise à jour avec la liste des destinataires possibles depuis notre interface actuelle. C’est un peu comme la station de triage des entrepôts Amazon : quand un colis arrive, l’agent va récupérer l’adresse et consulter l’annuaire (enfin, son Google Maps) pour voir où et comment livrer le colis.
Sur un réseau informatique, le paquet peut également être encapsulé dans plusieurs couches suivant le chemin qu’il doit suivre pour arriver à destination. Ces différentes couches peuvent contenir les informations et protections nécessaires pour qu’il puisse être lu et compris par le destinataire (et uniquement lui). Nous avions évoqué cette notion au dernier chapitre de notre petite formation Linux, au passage portant sur le modèle OSI.
Après l’entrée, la sortie
En plus de l’interface d’entrée, notre nœud possède une interface de sortie, par laquelle le paquet va passer pour poursuivre son chemin.
Avec certains protocoles, le nœud peut être capable de transmettre un message d’erreur s’il a rencontré des problèmes lors du traitement du paquet, comme le cas du « Time To Live » vu plus tôt. Ces messages d’erreurs constitueront un nouveau paquet à faire voyager jusqu’à son destinataire.
Le routage Bitcoin
La propagation d’un bloc sur le réseau Bitcoin repose sur un mécanisme de diffusion de pair à pair entre les nœuds. Dès qu’un mineur trouve un bloc valide, il le diffuse immédiatement à ses pairs, les nœuds voisins du réseau. Chacun d’entre eux vérifie la validité du bloc avant de le relayer à son tour. Ce processus continue jusqu’à ce que l’ensemble du réseau soit informé.
Mais le réseau Bitcoin est avant tout… un réseau !
Les nœuds Bitcoin possèdent des interfaces réseau tout ce qu’il y a de plus classique : les transactions sont reçues comme n’importe quel paquet circulant sur internet. Nous retrouvons donc les principales étapes du trajet classique d’un paquet tel que nous venons de les voir :
- la réception du paquet contenant la transaction à intégrer au bloc, ou bien le bloc lui-même ;
- la vérification de l’intégrité du paquet, mais aussi du bloc ou de la transaction contenus dans le paquet via un mécanisme de cryptographie ;
- le contrôle de l’en-tête dans le cas d’un bloc, notamment pour contrôler la preuve de travail, l’heure (un « timestamp », compté en secondes depuis le 1er janvier 1970), etc. ;
- des règles de filtrage correspondant aux règles de consensus (nous en reparlons plus loin) ;
- et la transmission du paquet pour en valider le contenu auprès des pairs du réseau.
Maintenant, nous voyons quelques particularités pointer le bout de leur nez.
Le temps de propagation et les confirmations
La propagation d’un bloc à travers le réseau Bitcoin est généralement très rapide. En conditions normales, il ne faut que quelques secondes à quelques dizaines de secondes pour atteindre plus de 50 % des nœuds.
Ce délai de diffusion n’est toutefois qu’une partie du temps total nécessaire au traitement d’une transaction. Une transaction est considérée comme valide – en général – après six confirmations, ce qui amène au final à un délai d’environ une heure : chaque confirmation correspond en effet au minage d’un bloc, ce qui prend environ 10 minutes sur le réseau Bitcoin.
C’est donc le délai minimum à prévoir avant de retrouver son solde actualisé sur son portefeuille : l’application consulte le registre, qui n’est officiellement mis à jour qu’après ces six confirmations.
Les facteurs qui influencent la diffusion
D’autres éléments font varier le temps de propagation.
Le premier est la taille du bloc : plus un bloc est volumineux, plus chaque nœud met de temps à le télécharger et à vérifier l’ensemble des transactions qu’il contient. Avec les technologies récentes utilisées sur Bitcoin, cette taille peut tout de même atteindre 4 Mo.
La congestion du réseau intervient ensuite. Lorsque le volume de requêtes dépasse la capacité d’absorption des nœuds, certaines d’entre elles restent en attente ou sont abandonnées.
Enfin, la latence réseau, liée à la topologie et à la distance géographique entre les nœuds, joue un rôle important. Le réseau Bitcoin étant planétaire, ces distances ont un impact significatif.
Les améliorations du réseau
Le réseau bénéficie régulièrement d’évolutions destinées à réduire ces délais.
Des protocoles comme FIBRE (Fast Internet Bitcoin Relay Engine) ou BIP 152 (qui introduit le Compact Block Relay) ont été mis en place pour accélérer la diffusion des blocs en diminuant la quantité de données transmises entre les nœuds.
FIBRE consiste en un réseau de relais conçu pour optimiser la propagation des blocs entre les nœuds du réseau, via des connexions optimisées, tandis que le Compact Block Relay permet aux nœuds de s’échanger un bloc en ne transmettant que les informations manquantes, plutôt que le bloc entier.
Ces solutions jouent ainsi à la fois sur les interconnexions et sur la taille des blocs pour réduire le délai de leur traitement.
Les conséquences du délai
La propagation d’une information n’est jamais instantanée. Même à la vitesse de la lumière, les distances à l’échelle planétaire restent suffisamment importantes pour que le trajet ne soit pas négligeable.
Dans le cas de Bitcoin, un délai de propagation maîtrisé a deux implications majeures.
D’une part, il limite les risques de forks accidentels. Un fork survient lorsque deux mineurs trouvent un bloc quasiment au même moment, créant temporairement deux variantes de la chaîne. Chaque nœud conserve le premier bloc reçu tout en gardant le second sous surveillance, puis continue de miner. C’est finalement la chaîne la plus longue – celle qui a accumulé le plus de preuve de travail – qui l’emporte ; les transactions des blocs abandonnés sont réinjectées dans le mempool (parmi les autres transactions en attente).
D’autre part, un délai court réduit le risque que des mineurs travaillent en vain sur une chaîne destinée à être abandonnée : celle dont les blocs contiennent les transactions qui retournent dans le mempool.
Conclusion
Si nous disons parfois que le réseau Bitcoin est relativement lent, c’est avant tout parce qu’il privilégie la sécurité – avec le mécanisme de confirmations – et ensuite parce que nous le comparons à des réseaux non soumis aux mêmes contraintes : un simple transfert de paquet peut se traiter en quelques secondes, l’équivalent de la réception de notre transaction par un seul nœud du réseau.
Qu’il s’agisse d’un réseau classique ou d’un réseau pair à pair comme Bitcoin, la latence reste un sérieux talon d’Achille pour toute communication. Pour le premier cas, elle se mesure en millisecondes ; le second ajoute le coût des confirmations. Pour un système monétaire, cette exigence de sécurité en vaut la peine.
Ressources
- Bitcoin n’est pas trop lent, sur le blog de Bitstack
- Optimisation de la Propagation des Blocs : Techniques et Solutions, sur w3r.one.
- Notre petite formation Linux, sur Nostr.
Write a comment