WEB-SCALE SOCIAL PEER-TO-PEER PROTOCOL.
TLDR :
Social est conçu pour offrir aux utilisateurs une expérience la plus proche possible des plateformes de médias sociaux Web 2, tout en tirant parti des technologies Web3.
Les frais d'utilisation sont un obstacle auquel toute plate-forme basée sur la blockchain est confrontée. Afin d'éliminer les frais d'utilisation pour les opérations non liées aux jetons tout en maintenant la confidentialité et le consensus, Solcial construit une couche peer-to-peer (P2P) ancrée dans Solana et construite sur libp2p qui fournit du contenu (flux, likes, etc.) via l'auto-hébergement et la réplication par les pairs.
Nous avons également développé un type de nœud spécial doté du même protocole externe qu'une application de bureau ou mobile typique, avec des optimisations supplémentaires conçues pour gérer des dizaines de milliers de pairs concurrents, appelées Nœuds de Balise. Les balises sont essentiellement un ensemble de services d'épinglage qui préserveront le contenu des utilisateurs lorsque les créateurs se déconnecteront et le rendront disponible pour d'autres utilisateurs; tout le contenu des utilisateurs est stocké sur IPFS et accessible via une couche P2P sans compter sur des serveurs ou des passerelles censurables.
Introduction
Il s'agit du premier article d'une série de notes décrivant comment le fonctionnement interne du protocole social lui confère des propriétés de résistance à la censure uniques tout en maintenant des performances d'échange de données raisonnables.
Topologie du Réseau
Les nœuds communiquent sur l'Internet public, formant un réseau de superposition spécifique aux Social en utilisant une version modifiée du protocole HyparView1.
Chaque nœud conserve une liste de pairs actifs d'une taille de log2(N)+1 où N est la taille estimée de l'ensemble du réseau. La valeur de N est extraite de la blockchain en trouvant le nombre de comptes d'utilisateurs enregistrés à jour, et est mise à jour périodiquement à mesure que le nombre d'utilisateurs augmente. Les connexions aux pairs actifs sont stables, bidirectionnelles et persistantes et ce sont les nœuds avec lesquels ils communiquent directement pendant les potins ou toute autre activité p2p.
La traversée NAT est réalisée à l'aide de trois méthodes utilisées en fonction des circonstances du réseau du pair. La première méthode consiste à utiliser IPv6 au lieu d'IPv4 quand c’est possible, car dans ce cas, il n'y a pas besoin de NATs, mais selon les statistiques, seulement moins de 40% d'Internet est sur ipv6⁴.
Le mécanisme de secours consiste à utiliser Automatisé en utilisant le protocole d'identité de libp2p qui interroge les autres nœuds du réseau sur l'adresse visible de notre machine. Cette adresse, initiée par le pair derrière un NAT, est déjà enregistrée avec son routeur sur la machine cible, mais il existe des circonstances où cela ne fonctionne pas, alors nous revenons à la troisième option la plus fiable mais la plus coûteuse.
La troisième option consiste à utiliser le protocole de relais de circuit libp2p qui imite le fonctionnement d'un protocole TURN 6 en ayant un nœud intermédiaire qui relaie les paquets entre deux pairs derrière les NAT. Ce rôle peut être assumé par les nœuds de balise et certains pairs avec des adresses IP publiques qui choisissent d'être des relais avec des limites configurées. Plus d'informations sur les nœuds de balise plus loin dans cet article.
Identité des Pairs
Les pairs sont identifiés à l'aide de leur clé publique sous la forme d'un multihash7 qui est égal à la clé publique de leur adresse de portefeuille sur Solana qui est enregistrée avec le contrat Solcial sur la chaîne. La seule façon de supposer un id pair public donné est de posséder la clé secrète d'une paire de clés ED25519.
Cette paire de clés est également utilisée pour établir des canaux cryptés pour tous les messages passant entre pairs, ainsi qu'un moyen de vérifier l'authenticité des messages qui sont vraisemblablement produits par le propriétaire du portefeuille.
Adhésion superposée
Les pairs dont les clés publiques ne sont pas enregistrées sur la chaîne ne seront pas autorisés à rejoindre la superposition de réseau HyparView et seront automatiquement exclus du réseau peer-to-peer Solcial.
Tous les pairs souhaitant rejoindre le p2p Solcial enverront un message de « JOINTURE » à l'un des nœuds d'amorçage (certains de ces nœuds d'amorçage sont également des nœuds de balise) sur le sujet « /solcial/public ». L'introduction de sujets à Hyperview est l'une de nos modifications à l'article original.
Tout nœud recevant une demande de « JOINTURE » d'un pair vérifiera d'abord que le multihash existe sur la chaîne et est associé à un compte Solcial, puis il enverra un message de « JOINTURE » à l'un de ses pairs actifs avec une marche aléatoire active définie sur 3, ils propageront à leur tour ce message à tous leurs pairs actifs, augmentant le nombre de sauts actuel d'un jusqu'à ce qu'il atteigne 3 sauts. Il s'agit d'une atténuation des attaques DDoS contre les nœuds bootstrap, ainsi que d'une technique de décentralisation efficace pour diffuser et randomiser autant que possible la connectivité entre les nœuds.
Tout nœud qui se trouve à moins de 3 sauts du récepteur de « JOINTURE » initial enverra un message « VOISIN » à la demande de « JOINTURE » initiale ou établira une connexion persistante active entre eux.
Périodiquement, toutes les 15 secondes, les nœuds diffuseront un message ALÉATOIRE à un homologue actif aléatoire avec un échantillon aléatoire de ses homologues actifs et passifs et définiront la longueur de marche aléatoire de ce message à 4. Cela garantit que tous les pairs du réseau ont toujours de nouvelles informations sur d'autres pairs qu'ils peuvent stocker dans leur vue passive à des fins de réparation du réseau, chaque fois que l'un de leurs pairs actifs ne répond plus ou se déconnecte explicitement.
Bavardage Efficace
Seuls les pairs actifs participent à la diffusion du message entre pairs. Les pairs actifs forment un réseau de superposition sur l'Internet public et il existe des cycles dans le graphique de connectivité entre les nœuds. Pour permettre un commérage efficace des messages entre paires sur le réseau, nous devons d'abord minimiser la propagation des messages en double entre pairs et ensuite trouver l'itinéraire le plus optimal pour les messages.
Ceci est réalisé en utilisant l'algorithme Epidemic Broadcast Trees qui forme un arbre couvrant minimum entre pairs, en divisant les pairs dans un groupe de nœuds de poussée impatiente(eager-push) et de nœuds de poussée paresseux(lazy push). Les nœuds de poussée paresseux reçoivent toujours des messages transmis dès qu'ils sont reçus par n'importe quel nœud.
Les noeuds "lazy push" reçoivent périodiquement, toutes les 500 ms, un lot d'identifiants de messages vus par le noeud actuel. Chaque fois qu'un nœud observe qu'il y a un identifiant de message dans le lot de lazy-push qui n'a pas été reçu de son nœud parent en amont, il reconstruit (« GRAFT ») la connexion et rétablit son statut de push actif. Cela constitue le mécanisme de réparation de l'arbre de portée minimale en cas de panne de l'un des nœuds et de formation de graphes disjoints. Les messages “GRAFT” rétablissent la connectivité complète du réseau.
Chaque fois qu'un message reçu s'avère être une duplication d'un message précédemment reçu d'un nœud actif, la connexion à ce nœud est considérée comme un cycle dans le graphique et transformée en poussée lente en envoyant un message de « PRUNEAU ».
Un autre cas pour élaguer une connexion active et la remplacer par une de la liste paresseuse est lorsque nous observons que le nombre de sauts parcourus par un message pour nous atteindre via un nœud paresseux est inférieur à 4 sauts d'un message du pair actif impatient. Cela constitue l'algorithme d'optimisation de l'arbre de diffusion.
Diffusion de contenu
Les messages diffusés par le protocole p2p décrit dans les sections précédentes sont des messages IPFS Bitswap⁹ avec les CID des contenus produits par les utilisateurs de Solcial. Pour mieux comprendre comment Bitswap et IPFS sont utilisés dans Solcial, décrivons d'abord la structure d'un profil d'utilisateur.
Chaque compte utilisateur sur le réseau possède ce qu'on appelle un index de profil. Cet index pointe vers les CID des dernières versions de leur contenu. L'index est une séquence éventuellement cohérente CRDT qui forme un journal immuable des opérations effectuées par le compte.
L'index du profil peut être considéré comme une liste liée où chaque élément pointe vers le CID de l'élément précédent et n'est accepté par les pairs comme l'élément suivant dans la séquence que s'il est signé par la clé privée du propriétaire du compte. Un exemple logique de haut niveau d'un flux de profil affiché codé dans ce format ressemble à ceci :
{
"auteur" : "12D3KooWSoeYKbpkb5UoL2T5eiomWRHdxR9cPC4tk11gKU89fFwT",
"prev" : "QmYtUc4iTCbbfVSDNKvtQqrfyezPPnFvE33wFmutw9PBBk",
"action" : "append-feed-post",
"timestamp" : "2022-01-11T15:58Z",
"params" : {
"content" : "QmV8cfu6n4NT5xRr2AHdKxFMTZEJrA44qgrBCr739BN9Wb"
"enckey" : "z2DhMLJmV8kNQm6zeWUrXQKtmzoh6YkKHSRxVSibscDQ7nq"
},
"signature" : "2Lpnvt23H6qHswCNPmwCCUSas7YNP[...]jV1dC9qdNPR4zDqsCuBX"
}
Une entrée comme celle-ci a son propre CID et est diffusée en tant qu'objet IPFS PB-DAG¹⁰ vers le sujet de recouvrement « /solcial/content » HyparView . Cette entrée est liée à son entrée précédente et à tout contenu supplémentaire ; en interrogeant de manière récursive les CID liés, les utilisateurs peuvent obtenir l'ensemble de l'historique et du contenu du compte.
Cet objet est d'abord validé par tout pair récepteur si la signature du contenu correspond à la clé publique de l'auteur. En cas d'échec de la vérification de la signature, le pair expéditeur est définitivement banni du nœud actuel pour violation du protocole. Une validation de signature réussie propage le contenu à tous les autres pairs intéressés par le contenu écrit par ce compte.
Lorsqu'un tel CID est reçu par un pair, il est ajouté au journal des opérations de l'auteur. La somme de toutes les opérations effectuées par l'auteur constitue l'état actuel du profil.
Par défaut, chaque nœud épingle et sème le contenu de son propre compte et celui de ses amis. Il existe des pairs spéciaux que nous construisons dans le cadre de notre infrastructure et que nous appelons des nœuds phares. Ils sont comme les pairs utilisateurs ordinaires, sauf qu'ils sont intéressés par le contenu de tout le monde et servent en quelque sorte de service d'épinglage IPFS spécifique de la « Social » pour tout le contenu au cas où tous les ensemenceurs actuels seraient hors ligne. Considérez-les comme des nœuds qui sont les amis de tous. Le réseau peut fonctionner sans eux, mais ils apportent une couche supplémentaire de disponibilité du contenu.
Accès en lecture
Tout le monde sur la superposition p2p Solcial peut interroger, télécharger et fournir tout contenu utilisateur en diffusant des messages Bitswap IWANT( je veux) et IHAVE(j’ai) au sujet « /solcial/content » avec le CID de l'index racine de premier niveau du compte, puis en demandant récursivement tous les CID liés.
La synchronisation initiale d'un compte, ou l'obtention des entrées les plus récentes d'un compte, est réalisée par la diffusion d'un message « HEAD » (message principal) au sujet « /solcial/sync », où d'autres pairs qui sont des semeurs (y compris les nœuds beacon) répondent avec le CID du dernier contenu dont ils ont connaissance. La traduction entre les identifiants et les clés publiques des utilisateurs est effectuée en interrogeant la blockchain Solana.
Le champ de l'entrée précédente peut être utilisé pour résoudre les conflits de HEAD et choisir l'entrée la plus récente.
Accès en écriture
Pour pouvoir écrire dans le journal d'un compte, l'utilisateur doit posséder la clé privée de la paire de clés ED25519 qui correspond à son ID de compte. En ayant cette clé, l'utilisateur est capable de générer une signature valide d'une entrée qu'il ajoute au journal et qui ne sera pas rejetée par les autres pairs sur le réseau.
Accès privilégié au contenu
Certains contenus publiés par les utilisateurs ne sont destinés qu'à un groupe restreint de destinataires, comme les flux d'abonnement de niveau 1 ou 2. Ces messages sont d'abord chiffrés à l'aide d'une clé de chiffrement symétrique AES-256. Le hachage de cette clé est joint aux métadonnées du contenu dans le message original.
La clé est diffusée à un sous-ensemble aléatoire de pairs éligibles via le canal crypté « NOISE » (la bruit) établi pendant l'établissement de la connexion libp2p. L'auteur du message peut choisir d'autoriser les nœuds de balises à participer également à ce schéma d'échange de clés afin de rendre le processus quasi instantané pour tous les utilisateurs, mais il n'est pas obligé de le faire s'il estime que son contenu est très sensible. Lorsqu'un utilisateur éligible souhaite déchiffrer le contenu, il envoie un message « GETKEY »(obtenir la clé) au sujet superposé « /solcial/keyexchange »( échange de clés) avec le hachage de la clé de chiffrement.
Tous les pairs en possession de cette clé et qui sont en ligne vérifient l'éligibilité du pair pour obtenir cette clé en interrogeant la blockchain et en vérifiant si l'utilisateur détient les jetons requis pour accéder au contenu. Après une vérification réussie, la clé est transmise au pair demandeur en utilisant une connexion quic/noise(quic /bruit) directe qui contourne le protocole de commérage.
Support de la plateforme
Ce protocole peer to peer pour le contenu résistant à la censure est disponible uniquement pour les clients de bureau et mobiles et n'est pas disponible sur l'interface web. Cela est dû aux limitations des navigateurs. Les navigateurs sont par nature conçus comme des consommateurs de contenu hébergé sur des serveurs et leur modèle de sécurité interdit d'accepter des connexions aléatoires provenant d'autres machines.
La version web sera presque toujours centralisée en raison de la façon dont les navigateurs fonctionnent et du fait que la durée de vie d'un onglet de navigateur est courte, et tout contenu produit par l'interface web sera reflété sur p2p par les nœuds de balises. Tout contenu consommé par le client web sera une copie du p2p. Le p2p est la source de vérité.
La pile technique sous-jacente est mise en œuvre en utilisant Rust, libp2p avec des liaisons à React Native et Tauri¹¹.
[1] Leitao, Joao, José Pereira, et Luis Rodrigues. «HyParView : Un protocole d'adhésion pour la diffusion fiable basée sur le commérage.»
[2] https://en.wikipedia.org/wiki/QUIC
[3] https://libp2p.io/
[4] https://www.google.com/intl/en/ipv6/statistics.html
[5] https://docs.libp2p.io/concepts/circuit-relay/
[6] https://datatracker.ietf.org/doc/html/rfc5766
[7] https://docs.libp2p.io/reference/glossary/#multihash
[8] Leitao, Joao, Jose Pereira, et Luis Rodrigues. "Arbres de diffusion épidémique". 26e symposium international de l'IEEE sur les systèmes distribués fiables (SRDS 2007). IEEE, 2007.
[9] https://docs.ipfs.io/concepts/bitswap/
[10] https://github.com/ipld/ipld/blob/master/specs/codecs/dag-pb/spec.md
[11] https://tauri.studio/
À propos de Social
Solcial est un réseau social décentralisé qui donne aux utilisateurs le pouvoir du web3 en permettant aux gens d'interagir les uns avec les autres sans craindre la censure, et en permettant aux créateurs de contenu d'être récompensés équitablement à la valeur marchande.
