Mise en réseau dans la sérénité (ETH2.0)

Un aperçu de la mise en réseau dans la sérénité

Un merci spécial à Hsaio-Wei Wang, à Kevin Mai-Hsuan Chia et à John Adler pour les modifications et leurs précieux commentaires.

La mise en réseau dans des blockchains fragmentés est un problème difficile. Comment pouvons-nous concevoir et mettre en place des réseaux peer-to-peer sécurisés et évolutifs pour des chaînes de blocs fragmentées? Au moment de la rédaction de ce document, il n’existait aucun système de blockchain fragmenté déployé en production. Nous n’avons donc aucun précédent sur la façon de concevoir de tels réseaux peer-to-peer. C'est un problème de conception auquel Ethereum 2.0 est actuellement confronté. Le but de cet article est de vous familiariser avec les recherches en cours sur la couche p2p d'ETH2.0 et peut-être de contribuer à cette partie de la recherche Ethereum 2.0. Tout au long de ce post, je suppose que vous connaissez les spécifications actuelles de l'ETH2.0.

Configuration réseau requise dans ETH2.0

Avant de plonger dans les idées et les protocoles en cours, nous devons d’abord comprendre quelles sont les conditions requises pour le réseau P2P de Serenity.

Premièrement, les nœuds du réseau doivent pouvoir s'abonner facilement à plusieurs fragments simultanément. Cela inclut les validateurs assignés aléatoirement aux fragments par la chaîne de balises et les nœuds non validants, c’est-à-dire les nœuds qui ne participent pas au protocole de consensus, qui se connectent à différents fragments pour leurs besoins particuliers.

Deuxièmement, les nœuds du réseau doivent pouvoir basculer entre des fragments à faible latence. Etant donné que les validateurs sont affectés de manière aléatoire à des fragments, il est important qu'ils puissent basculer entre les fragments le plus efficacement possible. Il s'ensuit que les nœuds doivent pouvoir trouver et se connecter aux autres nœuds aussi rapidement que possible.

Troisièmement, nous devons prendre en compte le fait que beaucoup de données sont transmises aux réseaux de fragments et au réseau de balises. Ces réseaux ont besoin d'une faible latence afin de s'assurer que les nœuds de ces réseaux reçoivent des blocs, des attestations, etc. afin de participer efficacement au protocole. Ces réseaux ont également besoin d'une bande passante suffisamment élevée pour ces données, même si la taille des blocs, des attestations, etc. est relativement constante. Les chiffres relatifs à la bande passante et au temps de latence sont difficiles à estimer à l’avance, mais Jannik, de BrainBot, a des estimations sur ce à quoi ces chiffres peuvent ressembler. Notez que ces estimations sont obsolètes car les spécifications de la phase 0 ont considérablement changé.

Conception actuelle

Tenant compte des exigences de conception pour le réseau p2p, ce sont les idées actuelles qui sont considérées pour le réseau. Ces idées sont basées sur une collaboration entre la fondation Ethereum et l'équipe Libp2p de Protocol Labs. Libp2p est un framework modulaire permettant de construire des réseaux peer-to-peer évolutifs. Bien qu’il soit actuellement très expérimental, de grands progrès ont été réalisés pour le rendre plus facile à utiliser pour les développeurs de réseaux peer-to-peer.

Un système PubSub efficace: GossipSub

Les nœuds du réseau communiquent à l'aide d'un modèle appelé Publish-Subscribe (PubSub). Dans ce cadre, les nœuds qui envoient des messages n'envoient pas de messages à des nœuds spécifiques. Au lieu de cela, ils catégorisent ces messages en rubriques et envoient des messages aux nœuds abonnés à ces rubriques. Les nœuds qui envoient ces messages sont appelés éditeurs et les nœuds abonnés à des rubriques sont appelés abonnés. Ainsi, les éditeurs n'ont pas besoin de savoir qui ils publient et les abonnés n'ont pas besoin de savoir qui sont les éditeurs des sujets. Ce cadre d’envoi et de réception de messages permet une plus grande évolutivité du réseau et une topologie de réseau plus dynamique.

Il existe différentes variantes du framework publish-subscribe spécifié dans libp2p. Celui qui est actuellement pris en compte pour Serenity s'appelle GossipSub, qui utilise des potins pour acheminer efficacement les messages aux abonnés. GossipSub utilise les idées de RandomSub et de MeshSub ainsi que le bavardage afin de router efficacement les messages dans le réseau en superposition. La principale différence entre GossipSub et les autres variantes de PubSub réside dans la manière dont il publie les messages. Les messages sont publiés à l'aide de MeshSub, mais les métadonnées sont envoyées à des pairs non maillés à l'aide de RandomSub de manière bavarde. En d'autres termes, les pairs qui ne font pas partie du maillage créé par MeshSub pourront obtenir des métadonnées sur les messages du sujet maillé, un maillage dont les pairs se sont abonnés au même sujet sans s'abonner directement à ce sujet. Si nécessaire, ces homologues peuvent ensuite interroger les messages réels. Notez que cela réduit la quantité de messages que chaque homologue doit envoyer, ainsi que le degré de chaque homologue dans le réseau maillé superposé créé par GossipSub.

Dans ETH2.0, il y aura provisoirement deux types de sujets: les sujets globaux et les sujets locaux. Les rubriques globales concernent les messages que tous les nœuds du réseau doivent connaître, tels que les messages de chaîne de balises et les ID de partage. Les sujets locaux concernent les messages relatifs à un fragment particulier, tels que les en-têtes et les transactions de fragment.

Routage par les pairs à l'aide de Kademlia DHT

Les algorithmes de routage entre homologues indiquent comment les homologues d'un réseau décident quels homologues acheminer des messages. En d’autres termes, comment les identifiants des pairs sont mappés sur l’adresse IP et le numéro de port d’un homologue. Kademlia DHT est actuellement à l’étude dans ETH2.0 en raison de sa robustesse et de sa simplicité d’utilisation, car elle est implémentée dans Libp2p et actuellement utilisée dans ETH1.0. Pour connaître les spécifications de l’implémentation de Kademlia par libp2p, vous pouvez lire la spécification Kademlia de libp2p.

Découverte de pairs à l'aide de Bootstrapping et Kademlia DHT

Pour communiquer efficacement dans un réseau d'égal à égal, les pairs doivent être capables de se retrouver. Dans ETH2.0, une combinaison de bootstrapping et de Kademlia DHT sera utilisée pour aider les pairs à se retrouver.

L’amorçage est un mécanisme de découverte entre homologues utilisé dans le réseau ETH1.0 actuel dans lequel un nouvel homologue souhaitant se connecter au réseau se connecte à un ensemble d’homologues prédéterminés du réseau. Ces pairs sont généralement codés en dur dans le client et sélectionnés par les développeurs du client. Ce processus facilite l'intégration de nouveaux nœuds au réseau. Kademlia fournit ce mécanisme d'amorçage dans le cadre de ses spécifications.

Une fois que l’homologue a rejoint le réseau à l’aide du mécanisme d’amorçage de Kademlia, il peut découvrir de nouveaux homologues en interrogeant des nœuds dans ses propres k-buckets les plus proches de la clé souhaitée. Ensuite, ces nœuds interrogés lancent le même processus et renvoient la liste résultante des nœuds les plus proches de la clé souhaitée. Ce processus est répété jusqu'à ce qu'aucun nœud interrogé ne renvoie la liste des nœuds les plus proches de la clé souhaitée.

Libp2p vs Devp2p

Vous avez peut-être remarqué que Devp2p n'était pas mentionné dans la section précédente sur la pile réseau actuelle. La raison principale en est qu’étant donné la documentation limitée et l’absence de changements depuis sa proposition en 2014, il a été décidé que Ethereum passerait de Devp2p à Libp2p. De plus, la conception modulaire de Libp2p nous permet de créer facilement des fonctionnalités réseau personnalisées nécessaires au partage. Nous ne pouvons pas facilement faire cela avec Devp2p. Pour un bref aperçu des avantages de l’utilisation de Libp2p, vous pouvez lire l’article de Parity Technologies sur les raisons pour lesquelles ils utilisent Libp2p dans leurs projets.

Problèmes ouverts

Vous devriez probablement avoir un bon aperçu de ce à quoi pourrait ressembler le réseau dans ETH2.0 et peut-être que vous souhaitez commencer à contribuer. Voici une liste de problèmes en suspens à partir desquels vous pouvez commencer à réfléchir à la façon de contribuer. Cette liste n’est pas exhaustive, mais c’est un début.

Validateur Confidentialité

Les validateurs constituent une partie importante du réseau Ethereum. Ils assurent le fonctionnement du protocole et garantissent la sécurité du réseau. Les attaquants peuvent vouloir identifier des validateurs afin d'attaquer le réseau Ethereum d'une manière ou d'une autre. Les attaquants qui veulent DDoS avec un validateur particulier sont évidemment difficiles à empêcher, mais l'objectif est de rendre difficile l'identification des validateurs. Idéalement, nous avons mis en place des mécanismes pour qu'un attaquant ne puisse attaquer qu'un sous-ensemble aléatoire de tous les nœuds disponibles. Jannik a un problème de brainstorming sur différents aspects de la confidentialité des validateurs.

Plusieurs suggestions ont été faites sur la manière d'améliorer la confidentialité des validateurs. Cependant, toutes ces suggestions sont en phase de brainstorming et il n’ya rien de concret. Il a été suggéré d'utiliser des solutions d'anonymat de niveau P2P telles que Tor et / ou I2P. Ces approches ont été analysées par Nicolas Liochon, ingénieur chez PegaSys. Vous pouvez lire son analyse ici. L'essentiel est qu'il serait raisonnable d'intégrer le réseau ETH2.0 dans les réseaux Tor ou I2P. Je tiens à souligner qu’il existe un précédent en ce qui concerne la tentative d’intégration de ces technologies dans d’autres crypto-monnaies, le plus célèbre exemple étant Monero. Vous pouvez en savoir plus sur la tentative de Monero de construire Kovri, une implémentation C ++ du réseau I2P, ici.

Une autre approche qui a été discutée est basée sur Dandelion ++. L'idée de base est de créer un graphe d'anonymat en tant que sous-graphe de la topologie de réseau sous-jacente, de faire en sorte que les messages voyagent sur des chemins générés de manière pseudo-aléatoire sur le graphe d'anonymat, puis de diffuser des messages aux pairs environnants. Dandelion ++ est actuellement à l’étude par les réseaux Bitcoin Core et Grin. La proposition consiste à utiliser les 2 premières étapes du protocole Dandelion ++, puis à la 3ème étape, au lieu de simplement diffuser des messages à des pairs proches, ces derniers publient des messages comme dans GossipSub habituel. Vous pouvez lire les détails de la proposition ici.

Agrégation de signature

L'agrégation de signatures est une partie importante d'ETH2.0. Son utilisation principale est d'agréger les signatures des attestateurs en une seule signature à stocker dans les attestations. Cela supprime la nécessité de stocker toutes les signatures des attestateurs. Le schéma de signature utilisé est le schéma de signature BLS. Le principal avantage de l'utilisation du schéma de signature BLS est que, tant que les signatures ont été générées, nous n'avons plus besoin des signataires pour regrouper les signatures. Vous pouvez en savoir plus sur les détails du schéma de signature BLS ici. Maintenant, comment allons-nous agréger ces signatures dans le réseau P2P? Eh bien, nous ne le savons pas encore. L’équipe de PegaSys a présenté une proposition appelée Handel. Le document n’a pas encore été publié, mais le référentiel GitHub est public et un exposé a été donné à la conférence de Stanford Blockchain. Cependant, rien n'a encore été décidé. Si vous avez une idée sur la façon de procéder, contactez-nous.

Découverte par les pairs

La conception de découverte par les pairs actuelle convient pour la phase de testnet de la phase 0 mais n'est pas optimale pour un réseau P2P décentralisé et de production. Le principal candidat à la découverte par les pairs est discv5. Une version de discv5 est déployée dans Geth 1.5 et versions ultérieures, mais les autres clients Ethereum n’utilisent pas discv5. La spécification pour discv5 est en cours et n'est pas officielle. Felix Lange a un projet que vous pouvez lire ici.

Protocole de fil

Un protocole filaire est nécessaire si nous voulons que différents clients parlent entre eux et soient interopérables. Danny Ryan a publié une API de connexion minimale pour la phase 0 pouvant être mise en œuvre une fois qu'un protocole de connexion spécifique a été spécifié. Une API filaire pour les phases suivantes nécessiterait des exigences différentes pour prendre en compte les fragments. Lors de la session du groupe de travail à Prague avant Devcon4, une liste d'exigences de ce dont un protocole filaire aurait besoin pour ETH2.0 a été élaborée. Vous pouvez lire les détails ici. Peut-être que jeter un coup d'œil au protocole filaire actuel d'ETH1.0 pourrait aider à concevoir un protocole filaire pour ETH2.0.

Protocole de transport

Le réseau Ethereum actuel utilise une combinaison d'UDP pour la découverte de nœud et de TCP pour toutes les autres communications p2p. Spécifiquement, pour la découverte de nœud, il utilise un système de type Kademlia sur UDP et un protocole de transport personnalisé, RLPx, construit sur TCP. UDP est un choix courant pour la découverte de nœuds dans les systèmes poste à poste. L'utilisation de TCP sert à envoyer des messages plus volumineux à d'autres pairs du réseau. Cette approche est couramment utilisée dans de nombreuses applications Internet telles que les jeux. Cependant, TCP peut parfois être lent, car TCP doit s'assurer que les paquets sont correctement classés et doit attendre les réponses des homologues. TCP a une récupération d’erreur intégrée afin d’envoyer des paquets de manière fiable aux homologues du réseau.

Il semble que des améliorations soient apportées aux protocoles de transport utilisés dans Ethereum. Peut-être pourrions-nous trouver un protocole de transport aussi rapide qu’UDP et aussi fiable que TCP. Le principal prétendant à un tel protocole est le transport expérimental appelé QUIC, proposé par Google en 2012. QUIC est un protocole de transport basé sur UDP qui vise à améliorer les performances d'envoi de paquets sur Internet. En outre, le chiffrement intégré à QUIC est intégré. Cela signifie qu'il serait plus difficile de bloquer la communication entre homologues. Les principaux avantages de l'utilisation de QUIC sur TCP sont doubles. Premièrement, QUIC nécessite un seul paquet afin d’établir une connexion à la place de la négociation à trois voies de TCP. Deuxièmement, il utilise le multiplexage de sorte que plusieurs flux de données puissent atteindre leurs points d'extrémité indépendamment, contrairement au TCP, où les connexions peuvent être bloquées si une erreur est détectée dans un flux de données. Les avantages de l'utilisation de QUIC sur TCP dans ETH2.0 ont été discutés dans ce numéro. L’équipe PegaSys prévoit d’effectuer davantage de recherches afin de déterminer sa viabilité dans ETH2.0. Il serait peut-être intéressant de faire une analyse pour voir quels types d’améliorations doivent être apportées afin d’avoir un protocole de transport fiable et rapide pour ETH2.0.

Alternatives à Kademlia DHT

Lors de la session du groupe de travail qui a suivi la conférence de Stanford Blockchain, l'utilisation de Kademlia DHT pour la découverte et le routage entre pairs est un thème récurrent. Kademlia DHT et ses variantes ont été utilisés dans le réseau Ethereum actuel en raison de sa renommée. Mais, cette utilisation intensive a rendu le réseau Ethereum vulnérable à une gamme d'attaques telles que les attaques par éclipse. De plus, le réseau Ethereum n’utilise pas pleinement les capacités de Kademlia. En fait, Ethereum n’a pas besoin des fonctionnalités de découverte de contenu de Kademlia. Ces faits suggèrent que nous devrions explorer des alternatives non-Kademlia pour le routage et la découverte par les pairs.

Rejoindre la conversation

Vous devriez maintenant avoir une meilleure idée de ce à quoi le réseau pourrait ressembler dans Serenity. Espérons que vous souhaiterez contribuer à la recherche et à la mise en œuvre d'un réseau p2p robuste et évolutif pour ETH2.0. Si vous souhaitez contribuer aux discussions en cours et au brainstorming, consultez le référentiel Ethresearch p2p sur GitHub et partagez des idées sur le canal sharding gitter et le canal p2p gitter récemment créé, le traqueur de spécifications techniques ETH2.0 et le forum de recherche Ethereum.