Le réseau Waku : mise à l'échelle du P2P et des communications axées sur la confidentialité

En décembre dernier, nous avons annoncé le Waku Network .

Le réseau Waku est le premier réseau décentralisé et préservant la confidentialité qui fournit des protections contre le déni de service (DoS) pour la messagerie peer-to-peer. Il vise à améliorer la confidentialité et la sécurité des communications peer-to-peer en mettant en œuvre des protocoles et des technologies innovants.

Approfondissons le pourquoi et ce qu'est le réseau Waku.

Origine

Si vous avez suivi Waku ou Status , vous connaissez probablement l'origine de Waku. L'application mobile Status a été créée en tant que super application web3, un portail vers l'écosystème Ethereum qui exploite les trois piliers d'origine : Ethereum pour le consensus, Swarm pour le stockage et Whisper pour la communication.

L'équipe de développement de Status a tenté de créer Status avec Whisper, mais ce protocole présentait des limites fondamentales, en particulier pour les appareils à ressources limitées, tels que les téléphones mobiles. Waku est né en tant que successeur de Whisper, apprenant de ses défauts pour fournir un réseau de communication peer-to-peer évolutif adapté aux mobiles et aux navigateurs.

Défis/Propriétés souhaitées

Waku vise à surmonter les défis suivants :

• Messagerie généralisée : Waku vise à fournir des protocoles et un réseau permettant le transfert de charges utiles arbitraires. Alors que Waku a été créé à l'origine pour une application de chat, Status, l'objectif est d'être suffisamment généralisé pour construire toute application de communication ou de signalisation décentralisée sur Waku.

• Messagerie éphémère : Waku vise à résoudre le problème de la communication en temps réel, qui vise à fournir une latence équitable pour permettre à un ou plusieurs utilisateurs d'échanger de petites charges utiles de données. Cela contraste avec IPFS ou d'autres systèmes de stockage décentralisés, qui permettent de stocker de grandes quantités de données au détriment de la latence et de la réactivité.

• Résistance à la censure : Waku vise à fournir une solution résistante à la censure où les acteurs externes ne peuvent pas bloquer l'accès des utilisateurs à l'infrastructure de Waku. Mais aussi pour que les développeurs d'applications soient capables de construire avec un état d'esprit de ne pas faire le mal , où ils n'ont pas la clé du royaume et la capacité de déplateforme leurs utilisateurs.

• Soucieux de la confidentialité : permettre aux développeurs d'applications de fonctionner selon le principe de l'impossibilité de faire du mal en termes de collecte de données et de métadonnées de leurs utilisateurs. Cela signifie que même s’ils le voulaient ou subissaient des pressions, eux ou tout tiers ne pourraient pas collecter de métadonnées telles que des graphiques sociaux ou des modèles d’activité auprès de leurs utilisateurs.

• Anonymat : à l'instar de la confidentialité, il s'agit de la possibilité pour les utilisateurs de ne pas lier les informations personnelles identifiables (PII) à leur activité sur le réseau Waku ou à l'application utilisant le réseau. Les informations personnelles prises en compte ici concernent le réseau (adresse IP), la blockchain (par exemple, l'adresse Ethereum) et le routage (corrélation des messages).

• Appareils à ressources limitées : comme mentionné précédemment, lors de la conception de Waku, un effort est fait pour prendre en compte des environnements tels que les mobiles et les navigateurs afin de permettre aux développeurs de créer des DApp pour ces plates-formes et de fournir autant de propriétés répertoriées ci-dessus que possible.

• Évolutivité : Waku vise à prendre en charge des millions d'utilisateurs tout en conservant les principes ci-dessus ; cela doit être soigneusement conçu et testé.

  
  

Toutes les propriétés ci-dessus signifient que d’autres problèmes doivent être surmontés lors de la conception de Waku :

• Protection DOS : garantir que le réseau ne peut pas être inondé de messages, ce qui amènerait les utilisateurs disposant de moins de ressources à démarrer hors du réseau.

• Durabilité du réseau et incitations : comment garantir suffisamment de ressources dans le réseau pour permettre aux appareils tels que les navigateurs et les appareils mobiles d'accéder au réseau ?

• Décentralisation : Waku doit être décentralisé à plusieurs niveaux pour permettre ces propriétés. Comment maintenir un niveau équitable de décentralisation pour garantir que ces propriétés perdurent dans le temps ?

Le réseau Waku

Comment le réseau Waku aide-t-il à fournir les propriétés ci-dessus ?

Passons en revue les différents protocoles Waku combinés dans le réseau et comment ils nous permettent de réaliser cet exploit.

Découverte par les pairs

Pour que tout système peer-to-peer soit fiable et décentralisé, il doit exister un mécanisme permettant de trouver de nouveaux pairs ou nœuds dans ledit système, généralement appelé découverte de pairs .

Waku utilise discv5, similaire à Ethereum. Des améliorations mineures à ENR ont été apportées pour permettre au nœud Waku de faire de la publicité :

• les fragments dans lesquels ils opèrent (voir routage des messages - sharding )

  • le protocole qu'ils ont activé

  • multiaddr alternatif qu'ils peuvent avoir, par exemple, pour que le navigateur se connecte audit nœud via WebSocket.

    
    

Discv5 est décentralisé, ce qui peut empêcher d'éventuelles attaques Sybil dans lesquelles un attaquant tente d'encercler le nœud de la victime pour donner une vue manipulée du réseau.

Cela contribue à permettre l’anonymat, la confidentialité et la résistance à la censure.

Grâce au protocole annoncé, il permet aux téléphones mobiles et au navigateur de trouver des nœuds capables de les desservir.

Routage des messages - Gossipsub

Semblable à Ethereum, Waku utilise libp2p-gossipsub. Cela apporte plusieurs avantages :

• performances de bande passante améliorées par rapport à Whisper : dans gossipsub, les nœuds forment un groupe de voisins (mesh) auxquels ils envoient des messages. Un nœud donné tentera uniquement de maintenir des connexions et d'échanger activement des messages avec d'autres nœuds. Réduire le nombre de fois que chaque message est téléchargé ou téléchargé.

• Fiabilité : gossipsub a une redondance intégrée, ce qui offre une fiabilité raisonnable lorsqu'il fonctionne dans un réseau peer-to-peer décentralisé, où aucun nœud ne peut être fiable ou se comporte bien.

• Anonymat : comme les nœuds transmettent les messages d'autres nœuds dans leur maillage et qu'aucune métadonnée n'est présente sur les messages individuels (par exemple, pas de signature en texte brut), cela fournit un anonymat équitable car il n'est pas possible pour un observateur de savoir si son voisin est à l'origine ou a transmis. un message. Cela fonctionne lorsqu'il est combiné avec un mécanisme de découverte d'homologues décentralisé tel que discv5.

  
  

Nous avons nommé l'utilisation par Waku de gossipsub, du protocole et du réseau. Relais Waku.

Routage des messages – Partage

L'un des inconvénients de Gossipsub est que chaque nœud du réseau reçoit et envoie tous les messages du réseau, avec une certaine amplification. On peut voir à quel point cela limite l’évolutivité : on ne peut pas s’attendre à ce que l’intégralité du trafic du réseau soit acheminée à partir d’une connexion Internet domestique.

Pour résoudre ce problème, le partitionnement est utilisé au lieu d'avoir un seul réseau gossipsub. Le réseau Waku est subdivisé en plusieurs sous-réseaux ou fragments distincts de routage de messages. Actuellement, le réseau Waku est divisé en huit fragments. Cela signifie que tout utilisateur d'une application Waku ne relayerait que le trafic d'un fragment ou d'un huitième (environ) de l'ensemble du réseau.

Au départ, huit était un petit nombre arbitraire. Notre analyse théorique montre qu'un fragment peut prendre en charge environ 10 000 utilisateurs actifs tout en maintenant un besoin moyen de bande passante d'environ 4 Mbps, soit 80 000 pour l'ensemble du réseau.

Nous travaillons à effectuer d'autres simulations pour confirmer nos hypothèses. Nous intégrons également des développeurs et des utilisateurs sur le réseau pour tester la théorie. L’objectif est d’augmenter le nombre de fragments dans le réseau au fil du temps.

Grâce aux améliorations apportées à discv5, les nœuds peuvent savoir quels fragments d'autres pairs desservent avant de s'y connecter.

Routage des messages – Partage automatique

L’un des problèmes du partitionnement est que les utilisateurs et les applications doivent savoir quelle partition utiliser.

Une application peut décider arbitrairement quelle partition elle souhaite utiliser, mais cela peut demander beaucoup de travail, en particulier lors de l'ajout de nouvelles partitions. C'est également une décision de plus que le développeur doit prendre ; nous préférons rendre l'expérience du développeur aussi simple que possible. Il permet également aux développeurs de créer des applications réparties sur plusieurs partitions sans déléguer le choix des partitions à l'utilisateur.

Le partage automatique est un protocole simple qui distribue des messages sur une partition en fonction de l'application.

Routage des messages - Relais RLN

Waku est généralisé et préserve la confidentialité, ce qui signifie que tout type de charge utile peut être transporté. Il n’existe donc pas de définition stricte du « spam ». Que le message contienne un mème ou une note zk pour DeFi privé , Waku ne devrait même pas connaître le contenu ; les métadonnées et les données doivent rester privées.

Il existe donc un risque que quelqu’un transmette des gigabits de données au réseau. Cela peut poser problème à différents niveaux :

• Utilisation de la bande passante : cela peut conduire à une monopolisation de la bande passante d'un utilisateur et à une incidence sur d'autres services (streaming, jalonnement) ou à une facture surprise.

• Connectivité : si un nœud ne dispose pas de suffisamment de bande passante pour envoyer/recevoir tous les messages sur la couche gossipsub, alors son comportement peut être considéré comme incorrect par d'autres nœuds qui pourraient s'en déconnecter.

• Fiabilité : si le trafic est supérieur à la bande passante disponible, un nœud peut ne pas être en mesure d'envoyer et de recevoir des messages de manière fiable.

• Autres ressources : l'utilisation de la mémoire est corrélée au trafic, tout comme l'espace disque pour un service de magasin.

  
  

Ainsi, plutôt que de définir à quoi ressemble un message « spam », nous avons introduit une limite de débit sur le réseau pour permettre une utilisation équitable de Waku, avec un plafonnement de l'utilisation de la bande passante par fragment. Cela se fait avec RLN, ou Rate Limiting Nullifier, qui limite le débit de messages envoyés par un éditeur donné. Il est actuellement réglé sur 1 msg/s.

Couplé à une taille maximale de message (150 Ko) et à un nombre maximum d'éditeurs (80 Ko, à déterminer), nous pouvons supposer une utilisation maximale de la bande passante par fragment (environ 10 Mbps).

Il est difficile de limiter les tarifs des éditeurs de manière privée et résistante à la censure ; c'est pourquoi nous utilisons une technologie sans connaissance :

1. Les utilisateurs transmettent leurs informations d'identification RLN à un contrat intelligent (actuellement sur le testnet Ethereum Sepolia).

   
   

2. Les nœuds gardent une trace de toutes les adhésions enregistrées sur le contrat.

   
   

3. Lors de l'envoi d'un message, l'utilisateur joint une preuve RLN au message avec l'époque actuelle (horodatage en secondes).

   
   

4. Les nœuds peuvent vérifier la preuve sans pouvoir corréler l'adresse Ethereum de l'utilisateur (utilisée sur le contrat intelligent) avec le message envoyé, préservant ainsi l'anonymat.

   
   

5. Si un utilisateur tente d'envoyer plus de 1 msg/s, les nœuds peuvent le détecter et supprimer le surplus de messages ou le spam, protégeant ainsi le réseau.

Entretien des appareils principalement hors ligne et aux ressources limitées

Enfin, en quoi Waku est-il utile aux appareils à ressources limitées comme les téléphones mobiles et les navigateurs Web ? Waku définit un certain nombre de [protocoles de requête-réponse ( https://rfc.vac.dev/spec/10/#requestreply-domain ) pour permettre à ces appareils d'accéder au réseau Waku sans avoir à être toujours en ligne ou à consommer de grandes quantités de données. bande passante, c'est-à-dire sans participer au réseau Waku Relay.

Le protocole light push (liens vers la documentation) permet à un client léger d'envoyer un message à transmettre au réseau Waku Relay, avec accusé de réception du nœud distant. Le protocole de filtrage permet à un client léger de s'abonner à un homologue distant et de demander uniquement un sous-ensemble de messages au lieu de tous les messages transmis sur un fragment.

Enfin, le protocole de stockage permet aux clients légers et aux nœuds relais de récupérer l'historique des messages qui auraient pu être manqués.

La proposition de valeur du réseau Waku

Bien que nous ayons défini les propriétés souhaitées et la technologie, il est important de comprendre les cas d'utilisation potentiels du réseau Waku. Ce numéro décrit actuellement plusieurs USP (Unique Value Propositions), et nous documenterons le sujet plus en détail. Certains cas d'utilisation remarquables sont, au-delà de la création d'une application de communication de machine à machine ou d'humain à humain :

• No-Infra DApps : combinant diverses technologies décentralisées (Waku, Ethereum, IPFS) pour déployer une DApp sans payer un hébergeur centralisé.

• Accès résistant à la censure à un réseau décentralisé pour les clients légers : utilisation des protocoles de requête-réponse pour permettre aux clients légers d'accéder à votre réseau peer-to-peer sans recourir à une passerelle Web centralisée et censurable.

• Réseau de signaux : utilisez le réseau Waku pour trouver d'autres pairs et négocier des paramètres spécifiques pour former votre propre réseau peer-to-peer, Waku ou non, avec des règles différentes (limite de débit plus élevée, etc.).

Sommes-nous encore vierges ?

Nous avons décrit les propriétés souhaitées par Waku et comment le réseau Waku y répond. Cela signifie-t-il que Waku est résistant à la censure, privé, durable et évolutif ? Pas assez.

Le bootstrapping est un composant de tous les réseaux peer-to-peer que nous n'avons pas abordés : comment un nouveau nœud trouve-t-il d'autres nœuds dans le réseau ? Nous utilisons la technologie Ethereum pour le bootstrap (ENR + DNS Discovery). Toutefois, cette technologie pourrait être plus décentralisée. Nous comptons améliorer ce potentiel vers la fin 2024 ou 2025.

En général, le réseau doit être décentralisé pour obtenir les propriétés souhaitées. Même si une partie de la technologie permet une telle décentralisation (et nous travaillons à améliorer la partie qui ne le permet pas), ce problème a une composante sociale. Si l’équipe Waku est la seule à gérer des nœuds, alors, par nature, le réseau ne peut pas être considéré comme décentralisé, donc résistant à la censure, etc.

Pour résoudre ce problème, nous devons faire pression en faveur de l'adoption du réseau Waku afin de pouvoir constituer une bonne base d'opérateurs de nœuds et de développeurs qui exécutent des nœuds sans dépendre de l'équipe Waku pour le faire.

Nous avons accru cet effort l’année dernière et nous continuerons cette année. Un autre aspect consiste à fournir des incitations monétaires aux opérateurs de nœuds pour qu'ils gèrent des nœuds afin que le réseau puisse devenir autonome. Nous n’avons pas un tel protocole ; nous construisons le premier PoC.

Le réseau Waku joue ici un rôle important. Une fois qu'un tel protocole est disponible, un lieu (de marché) commun est nécessaire pour que les développeurs/utilisateurs et les opérateurs puissent se trouver ; le réseau Waku serait un tel endroit.

Conclusion

Waku vise à permettre des communications souveraines avec des propriétés spécifiques. Le réseau Waku constitue une étape cruciale vers la réalisation d’un tel objectif et la création d’un réseau commun décentralisé sur lequel les développeurs peuvent s’appuyer, et nous pouvons ajouter davantage de protocoles. Bien que nous ne puissions pas dire que Waku est tout ce qu’il vise à être aujourd’hui, il est déjà sans autorisation et décentralisé sur plusieurs niveaux.

Nous travaillons maintenant non seulement à ajouter les éléments manquants aux protocoles, mais également à faire pression pour l'adoption de Waku afin de le rendre de facto décentralisé, permettant à chacun de résister à la censure et au secteur privé.

Si vous souhaitez rejoindre une communauté partageant les mêmes idées et visant à offrir des communications peer-to-peer à des millions d'utilisateurs, rejoignez le Waku Discord ou suivez-nous sur X .

Inscrivez-vous à notre newsletter mensuelle pour recevoir nos actualités directement dans votre boîte mail.

Si la technologie vous parle, consultez nos offres d'emploi ou remportez certaines de nos primes .

Vous pouvez également contribuer à garantir que nous restons décentralisés en exécutant votre propre nœud Waku !