peers : Pourquoi Bitcoin n'utilise-t-il pas UDP pour faire Blockpropagation ?


Le système Bitcoin n’a pas qu’un seul protocole réseau  : n’importe quel moyen d’obtenir les blocs est également valable – les blocs sur Freenet, sur la diffusion par satellite, sur le réseau P2P, tous fonctionnent aussi bien et sont utilisés dans la pratique. UDP est également utilisé avec le bitcoin, par le protocole Fiber.

En ce qui concerne le protocole commun Bitcoin P2P, UDP n’est pas particulièrement adapté à la plupart des opérations qu’il effectue. Bitcoin doit envoyer de manière fiable des messages bien plus volumineux qu’un paquet IP, comme des transactions et des blocs. Bien qu’Internet soit « fiable », des taux de perte de paquets de 1 à 3 % sont courants. Cela signifie que toute application ayant besoin de communiquer des messages volumineux avec UDP doit implémenter la mise en paquets, la retransmission, la réorganisation, etc. De nombreuses applications qui ont « implémenté leur propre TCP » dans l’espace utilisateur se sont retrouvées avec des bogues exploitables, ce n’est donc pas quelque chose qui devrait être fait sans motif valable.

UDP a également le problème de la traversée NAT  : obtenir une communication bidirectionnelle à travers un NAT avec UDP n’est pas une mince affaire. Traverser quelque chose de plus compliqué qu’un cône complet nécessite des quantités considérables de code spécial, mais sans cela, il y aura de nombreux hôtes qui ne pourront tout simplement pas parler à d’autres pairs avec UDP.

peers : Pourquoi Bitcoin n'utilise-t-il pas UDP pour faire Blockpropagation ?

Vous mentionnez l’absence de connexion vous permettant de vous relayer vers un hôte aléatoire dans le réseau, mais dans Bitcoin P2P. Les nœuds ont une idée de ce que leurs pairs savent déjà et peuvent éviter de leur envoyer des données redondantes. Les nœuds savent également quels pairs ont été les plus rapides à leur envoyer des blocs dans le passé et les gèrent spécialement. De même, même si le protocole est sans connexion, il y a des coûts pour traiter les messages des pairs en donnant la priorité au traitement des messages des pairs existants, Bitcoin réduit l’impact de certains types d’attaques DOS. La gestion de messages de plus d’un paquet, de retransmissions, etc. signifie également que même avec un transport sans connexion, il doit toujours y avoir une sorte d’état persistant.

Mais si une implémentation voulait se connecter au hasard pour envoyer un message, elle le pourrait, moyennant un coût supplémentaire, quelques allers-retours pour la poignée de main. Ou même pas ça : il n’y a qu’environ 10 000 nœuds accessibles dans le réseau P2P, il n’y aurait pas beaucoup de difficulté à maintenir ouverte une connexion TCP la plupart du temps inactive à chacun d’entre eux si tout l’état retenu n’était que le TCP Etat. Donc, pour ce point, l’utilisation d’UDP ne serait au mieux qu’une optimisation pour quelque chose qui pourrait déjà être fait mais qui n’est pas fait. Je pense qu’il serait plus intéressant de démontrer l’utilité d’avoir toutes ces connexions d’abord, avant de se soucier de l’optimiser.

Alors pourquoi le transport UDP pourrait-il être utile au protocole Bitcoin P2P ?

  • Pour obtenir le transfert de bloc avec la latence la plus faible possible, il ne doit y avoir aucun aller-retour, même en cas de perte de paquets, ce qui exclut TCP et c’est pourquoi la fibre utilise UDP. Mais pour ne pas avoir d’allers-retours, le protocole doit être capable de gérer la perte sans retransmission et pour obtenir une faible latence, un bloc doit être décodable avec un minimum de données reçues. Cela nécessite des techniques de correction d’erreurs très sophistiquées qui sont un domaine en évolution et qui ne sont pas encore suffisamment mûres pour envisager de les généraliser. Les avantages de la latence de la fibre existent également tant qu’un petit nombre d’hôtes l’utilisent, car elle fait le gros du travail en prenant des blocs partout dans le monde. Les allers-retours ne causent pas beaucoup de dommages sur les liaisons à faible latence. Et ce problème de latence ne s’applique qu’au relais de bloc.
  • Contrairement à TCP, UDP nécessite une certaine quantité de traitement de traversée NAT pour que la communication bidirectionnelle fonctionne simplement. Mais combiné avec la gestion complète de la traversée nat, UDP est souvent capable d’établir une communication entre des hôtes qui sont tous deux derrière des NAT différents. Cela pourrait être utile pour le réseau Bitcoin P2P puisque la plupart des hôtes sont inaccessibles derrière un nat. Ainsi, ironiquement, l’un des défis d’UDP est également l’une de ses utilisations. Cependant, pour connecter des hôtes qui sont tous les deux derrière un réseau, l’assistance d’un hôte tiers non natté est nécessaire avec encore plus de code de traversée NAT. Compte tenu de la complexité de la traversée, l’amélioration de la prise en charge de Bitcoin pour le mappage des ports TCP (par exemple, la mise en œuvre de NAT-PMP) serait probablement un meilleur retour sur investissement en ce moment.
  • L’utilisation d’UDP permettrait une gestion du trafic « pire que le meilleur effort ». Pour le « trafic de masse » de faible priorité comme la synchronisation de la blockchain, il serait bien que le trafic se forme soigneusement pour éviter d’interférer avec d’autres trafics sur le réseau. Des algorithmes de contrôle de congestion alternatifs comme LEDBAT permettent de transférer des données de faible priorité avec un impact minimal. Mais comme les piles TCP ne prennent pas encore en charge ces approches de contrôle de congestion, les applications qui les souhaitent doivent actuellement implémenter leurs propres transports. Pour Bitcoin. lorsque le pair demande des blocs historiques ou à l’avenir lorsque quelque chose comme Fiber est utilisé par le nœud pour relayer de nouveaux blocs ) mais ce n’est pas encore une option.