================================================================================ OC-DISCOVERY : CORRÉLATION AVEC LES SYSTÈMES DÉCENTRALISÉS EXISTANTS Patterns, similitudes, divergences et comparaison ================================================================================ Rédigé à partir de l'analyse de l'architecture oc-discovery. Références académiques et systèmes industriels cités en §9. ================================================================================ 1. INTRODUCTION ET PÉRIMÈTRE ================================================================================ oc-discovery est un service de découverte P2P hiérarchique à trois niveaux (node → indexer → native indexer) construit sur libp2p, une DHT Kademlia à espace de noms privé, GossipSub, et un mécanisme de scoring de confiance multidimensionnel. Le réseau est isolé par une clé pré-partagée (PSK). Ce document met en regard la conception de oc-discovery avec : (A) Les systèmes de découverte P2P historiques et académiques (B) Les systèmes décentralisés industriels contemporains (C) Les patterns architecturaux identifiables dans la littérature (D) Une analyse comparative synthétique ================================================================================ 2. SYSTÈMES COMPARÉS ================================================================================ 2.1 Kademlia DHT [Maymounkov & Mazières, 2002] ----------------------------------------------- Description : Table de hachage distribuée à espace à k-buckets. Chaque nœud maintient un routage O(log n). Toute requête GET/PUT se résout en O(log n) sauts. La distance est la métrique XOR sur les PeerIDs (160 bits). Utilisation dans oc-discovery : oc-discovery embarque une instance Kademlia (go-libp2p-kad-dht) avec le préfixe "oc" — namespace privé qui isole la DHT du réseau IPFS public. Quatre espaces de noms (/node, /indexer, /name, /pid) y sont écrits avec des validateurs cryptographiques customisés. Similitudes : - Résolution en O(log n) sans serveur central. - Réplication Kademlia standard (k-buckets) pour la tolérance aux pannes. - Chaque entrée est auto-signée (Ed25519). Divergences : - Kademlia pur est flat : tout nœud est pair. oc-discovery superpose une hiérarchie fonctionnelle (native > indexer > node) sur la DHT. - Kademlia n'a pas de TTL applicatif par nature : oc-discovery impose des TTL stricts (90 s pour /indexer, 2 min pour /node) avec retry borné. - Kademlia pur n'a pas de mécanisme d'admission : tout nœud peut écrire. oc-discovery ajoute une validation cryptographique (Sign+Verify) avant tout PutValue dans l'espace /indexer. - La DHT de oc-discovery est un stockage secondaire (cache mémoire des natifs en primaire), non le plan de découverte principal — rôle tenu par le mesh natif + heartbeat long-lived. Source : Maymounkov, P. & Mazières, D. (2002). "Kademlia: A Peer-to-Peer Information System Based on the XOR Metric." IPTPS 2002, Springer LNCS 2429. ---- 2.2 Chord [Stoica et al., 2001] -------------------------------- Description : DHT en anneau. Chaque nœud a un successeur et une finger table de O(log n) entrées. Résolution en O(log n). Gestion des jonctions/départs via le protocole de stabilisation. Similitudes : - Résolution décentralisée sans serveur central. - Tolérance aux pannes par réplication de successeurs. Divergences : - Chord suppose un réseau ouvert et homogène. oc-discovery est fermé (PSK) et hétérogène (3 rôles différents). - Chord n'a pas de couche de scoring ni de consensus applicatif. - La stabilisation Chord (jointures fréquentes) génère du trafic O(log² n). oc-discovery évite cela par un pool statique d'indexeurs (StaticIndexers) avec replenish seulement en cas de panne. - Chord est mathématiquement élégant mais pratiquement fragile face aux partitions (l'anneau peut se "casser"). oc-discovery tolère les partitions via fallback + pool pré-validé. Source : Stoica, I., Morris, R., Karger, D., Kaashoek, M. F., & Balakrishnan, H. (2001). "Chord: A Scalable Peer-to-Peer Lookup Service for Internet Applications." ACM SIGCOMM 2001. ---- 2.3 Gnutella 2 / FastTrack — Supernœuds [Ritter, 2001] -------------------------------------------------------- Description : FastTrack (réseau de Kazaa, iMesh) introduit les "supernœuds" : des pairs capables de gérer des listes d'indexation pour les pairs ordinaires. Les supernœuds forment un mesh entre eux, les pairs ordinaires se connectent à un ou plusieurs supernœuds. Gnutella 2 adopte une architecture similaire avec "hubs" et "leaves". Similitudes — c'est le point de corrélation le plus fort : - La tripartition native/indexer/node de oc-discovery est structurellement identique à la partition supernode/ultrapeers/leaves de FastTrack/Gnutella2. - Les natifs forment un mesh entre eux (heartbeat bidirectionnel + gossip), exactement comme les hubs Gnutella2 s'interconnectent. - Les indexeurs s'enregistrent auprès des natifs exactement comme les leaves se connectent à un hub Gnutella2. - L'auto-sélection des supernœuds (selon la bande passante, uptime) préfigure le scoring multidimensionnel de oc-discovery. Divergences : - FastTrack/Gnutella2 sont ouverts : tout pair peut devenir supernœud si les critères ressources sont satisfaits. oc-discovery est fermé : le rôle de natif est configuré statiquement (NativeIndexerAddresses). Ce choix délibéré améliore la sécurité (admission explicite) mais réduit l'élasticité. - FastTrack n'a aucun mécanisme cryptographique de validation des entrées. oc-discovery signe chaque IndexerRegistration et valide en DHT. - FastTrack n'a pas de consensus : les supernœuds sont des autorités locales non coordonnées. oc-discovery introduit clientSideConsensus (Phase 1) et indexerLivenessVote (Phase 2) — inexistants dans Gnutella2. - Le scoring de oc-discovery (5 composants, gap-aware uptime) est bien plus sophistiqué que la simple métrique de bande passante de FastTrack. Source : Ritter, J. (2001). "Why Gnutella Can't Scale. No, Really." Clip2 Distributed Search Solutions Technical Report. CNN (2003). "KaZaA's Secret : Supernodes." ---- 2.4 IPFS / libp2p [Benet, 2014 ; libp2p, 2019] ------------------------------------------------ Description : IPFS (InterPlanetary File System) est un protocole de stockage P2P adressé par contenu. Il utilise libp2p comme couche réseau, Kademlia DHT (go-libp2p-kad-dht), GossipSub pour le pub/sub, et yamux pour le multiplexage. Similitudes — très fortes (stack identique) : - oc-discovery utilise exactement la même pile : libp2p + yamux + Kademlia + GossipSub. Les protocoles de transport, de mux, et de DHT sont les mêmes. - La notion de PeerID Ed25519 auto-certifié est commune. - Le mécanisme de PSK (private network) est une fonctionnalité libp2p standard utilisée dans les déploiements IPFS privés. - GossipSub avec TopicValidator (validation des messages avant acceptation) est utilisé dans les deux systèmes. Divergences : - IPFS est orienté adressage par contenu (CID, Merkle DAG). oc-discovery est orienté découverte de pairs (PeerRecord, présence). - IPFS utilise la DHT Kademlia comme plan de découverte principal (findProviders, findPeers). oc-discovery relègue la DHT à un rôle de persistance secondaire : le plan principal est le mesh natif + heartbeat long-lived (latence < 1 ms vs 50–200 ms DHT). - IPFS n'a pas de scoring d'admission. Tout pair libp2p peut publier du contenu. - IPFS n'a pas de concept d'indexeur ou de natif. La hiérarchie fonctionnelle de oc-discovery est absente — IPFS est architecturalement flat. - IPFS ne maintient pas de présence continue (heartbeat). La présence est inférée par la disponibilité DHT (providers). oc-discovery maintient une présence explicite avec TTL court (2 min) et GC. - L'espace de noms DHT de oc-discovery est privé (préfixe "oc") : il ne se mélange pas au réseau DHT IPFS public. Source : Benet, J. (2014). "IPFS - Content Addressed, Versioned, P2P File System." arXiv:1407.3561. libp2p (2019). libp2p specifications. https://github.com/libp2p/specs ---- 2.5 Ethereum devp2p / DiscV5 [Ethereum Foundation, 2014–2021] -------------------------------------------------------------- Description : Le protocole de découverte Ethereum (devp2p) utilise une DHT Kademlia modifiée (initialement discv4, puis discv5). Les nœuds s'annoncent via des ENR (Ethereum Node Records) signés. discv5 introduit des topics (TOPICQUERY) pour la découverte par type de service. Similitudes : - ENR (Ethereum Node Records) signés sont analogues aux IndexerRegistration signés de oc-discovery : preuve cryptographique que l'annonceur contrôle l'adresse déclarée (Sign(PeerID|Addr|Nonce)). - La notion de "bootstrap nodes" fixes (Ethereum Foundation opère des nodes DNS/statiques) est analogue aux NativeIndexerAddresses configurés statiquement. - discv5 TOPICQUERY permet de filtrer les pairs par capability, analogue au GetIndexersRequest{Count: n} de oc-discovery. Divergences : - Ethereum vise un réseau ouvert et mondial (des milliers de nœuds). oc-discovery est un réseau privé fermé (PSK), pensé pour des déploiements organisationnels. - discv5 est purement flat : aucune hiérarchie native/indexer/node. - Ethereum n'a pas de scoring de confiance d'admission. La sélection est purement Kademlia (proximité XOR des PeerIDs). - Ethereum n'a pas de mécanisme de liveness vote comparable à Phase 2 de oc-discovery. La vivacité est inférée par les échecs de connexion, non par un vote explicite. - Le consensus applicatif Ethereum (PoW/PoS) est au niveau de la chaîne, pas au niveau de la découverte. oc-discovery intègre un consensus directement dans la couche de découverte (clientSideConsensus). Source : Ethereum Foundation (2021). "Node Discovery Protocol v5." https://github.com/ethereum/devp2p/blob/master/discv5/discv5.md ---- 2.6 Bitcoin P2P / DNS Seeds [Nakamoto, 2008 ; Bitcoin Core] ------------------------------------------------------------ Description : Bitcoin utilise un réseau P2P flat avec un protocole de gossip ad hoc (ADDR messages). Au démarrage, un nœud se connecte à des "DNS seeds" (noms DNS opérés par des développeurs réputés) qui retournent une liste de pairs actifs. Le pair se connecte ensuite à N pairs au hasard. Similitudes : - Les DNS seeds de Bitcoin sont fonctionnellement analogues aux IndexerAddresses (seeds) de oc-discovery : liste de points d'entrée configurés statiquement pour bootstrapper la découverte. - Le mode seed de oc-discovery (IndexerAddresses sans natif, AdmittedAt=0) est structurellement analogue au mode bootstrap-DNS de Bitcoin : confiance explicite hors-bande, pas de validation cryptographique. Divergences : - Bitcoin est entièrement flat. Aucune hiérarchie, aucun rôle privilégié. - Bitcoin n'a pas de scoring ni de consensus de découverte. Le choix des pairs est pseudo-aléatoire (évitement du clustering). - Les DNS seeds Bitcoin sont des points de centralisation opérationnelle (opérés par quelques individus connus). Le mode natif de oc-discovery distribue cette autorité entre plusieurs natifs avec consensus. - Bitcoin tolère les Sybil attacks par PoW. oc-discovery tolère les Sybil par PSK + signature cryptographique + quorum natif. - oc-discovery détecte explicitement la panne d'un pair via heartbeat (20 s). Bitcoin détecte via timeout de connexion (2 h par défaut). Source : Nakamoto, S. (2008). "Bitcoin: A Peer-to-Peer Electronic Cash System." Lopp, J. (2016). "Bitcoin Node Network." Statoshi.info. ---- 2.7 Consul (HashiCorp) — Service Discovery [HashiCorp, 2014] ------------------------------------------------------------- Description : Consul est un service de découverte et de configuration distribué. Il utilise le consensus Raft au sein d'un cluster de serveurs (3 ou 5 nœuds), et le protocole Serf (gossip SWIM) pour la détection de défaillances entre agents. Les services s'enregistrent auprès des agents locaux qui répliquent vers les serveurs Raft. Similitudes : - La couche de health checking de Consul (SWIM : heartbeats périodiques + indirect probing) est fonctionnellement analogue au heartbeat long-lived de oc-discovery pour détecter les défaillances. - L'enregistrement de service avec TTL (service registration + TTL check) est analogue à IndexerRegistration + IndexerTTL (90 s). - Le concept de "critical service" qui expire si l'agent ne renouvelle pas le check TTL est analogue à la logique de GC de oc-discovery (now.After(Expiry)). Divergences : - Consul repose sur Raft pour la cohérence forte (CP dans le théorème CAP). oc-discovery fait un choix AP : disponibilité et cohérence à terme, tolérant les lectures potentiellement stales (cache mémoire natif vs DHT désynchronisée). - Consul requiert un quorum Raft de serveurs (minimum 3) pour fonctionner. oc-discovery fonctionne avec un seul natif (mode dégradé accepté). - Consul est un service centralisé (cluster de serveurs). oc-discovery est vraiment décentralisé : les natifs sont des pairs égaux sans leader élu. - Consul s'intègre typiquement dans un data center (LAN). oc-discovery est conçu pour un réseau WAN avec NAT traversal, PSK, et des RTT élevés. - Consul n'a pas de scoring de confiance des services : tout service enregistré par un agent authentifié est valide. oc-discovery ajoute 5 composantes de score. Source : HashiCorp (2014). "Consul: Service Mesh Solution." https://developer.hashicorp.com/consul/docs/architecture Maciej Dobrzański (2015). "Consul: HashiCorp's Service Discovery Tool." InfoQ. ---- 2.8 ZooKeeper [Hunt et al., 2010] ---------------------------------- Description : ZooKeeper est un service de coordination distribué utilisant un consensus ZAB (ZooKeeper Atomic Broadcast, dérivé de Paxos). Il maintient un espace de noms hiérarchique (znodes) avec watches. Utilisé pour la découverte de services (enregistrement d'éphémères), leader election, configuration. Similitudes : - Les znodes éphémères de ZooKeeper (supprimés quand le client se déconnecte) sont fonctionnellement analogues aux entrées liveIndexers avec TTL : dans les deux cas, la présence est inférée par la connexion active. - La notion de watch (notification de changement) est analogue au nudge channel de oc-discovery (indexerHeartbeatNudge, nativeHeartbeatNudge). Divergences : - ZooKeeper est fondamentalement centralisé : il requiert un ensemble de serveurs (ensemble) avec élection de leader via ZAB. C'est un service CP fort. oc-discovery n'a pas de leader, pas d'élection, pas de log répliqué. - ZooKeeper offre des garanties de linéarisabilité pour les écritures. oc-discovery n'offre qu'une cohérence à terme (liveIndexers vs DHT peuvent diverger jusqu'à ~30 s). - ZooKeeper est conçu pour des réseaux fiables (LAN intra-datacenter). oc-discovery tolère des partitions WAN longues via fallback pool + retryLostNative. - ZooKeeper n'a aucun mécanisme de scoring ou de confiance : toute session authentifiée peut écrire des znodes dans son espace. Source : Hunt, P., Konar, M., Junqueira, F. P., & Reed, B. (2010). "ZooKeeper: Wait-free Coordination for Internet-scale Systems." USENIX ATC 2010. ---- 2.9 Gossip / SWIM (Scalable Weakly-consistent Infection-style Membership) [Das et al., 2002] --------------------------------------------------------------------------- Description : SWIM est un protocole d'appartenance (membership) à base de gossip utilisé dans Consul/Serf, Cassandra, etcd (memberlist). Chaque nœud envoie des pings directs et des pings indirects (via tiers) pour détecter les défaillances. L'information se propage par infection (gossip) en O(log n) rounds. Utilisation dans oc-discovery : Le gossip GossipSub (oc-indexer-registry) de oc-discovery disséminate les IndexerRegistration signées entre natifs lorsqu'un indexeur s'enregistre. Ce sous-protocole joue un rôle SWIM partiel. Similitudes : - Dissémination par gossip (GossipSub avec random fanout) est formellement équivalente à l'infection-style de SWIM : chaque message atteint tous les nœuds en O(log n) rounds avec haute probabilité. - La détection de défaillance par timeout de heartbeat (2 min dans oc-discovery) est analogue au timeout de SWIM avant de déclarer un membre "suspect". - Le TopicValidator de oc-discovery (validation de l'émetteur + signature) est analogue au message authentication dans les implémentations sécurisées de SWIM. Divergences : - SWIM implémente un "indirect probing" (demander à un tiers de pinger le suspect avant de le déclarer mort) pour réduire les faux positifs. oc-discovery n'a pas d'indirect probing : la défaillance est déclarée dès que le heartbeat échoue directement (false positives possibles sous partition partielle). - SWIM gère l'appartenance de manière symétrique (tout nœud peut diagnostiquer tout autre). oc-discovery est asymétrique : seuls les natifs valident les indexeurs ; les nœuds ne se valident pas mutuellement. - Le gossip oc-discovery ne porte que les enregistrements d'indexeurs (plan de contrôle). SWIM gossipe l'état de tout le membership. Source : Das, A., Gupta, I., & Motivala, A. (2002). "SWIM: Scalable Weakly- consistent Infection-style Process Group Membership Protocol." DSN 2002. ---- 2.10 Tor — Onion Routing [Dingledine et al., 2004] ---------------------------------------------------- Description : Tor est un réseau d'anonymisation par routage en oignon. Un répertoire d'autorités (directory authorities) — 9 nœuds fixes connus de tous — publie un "consensus" signé des relais disponibles (adresse, bande passante, flags). Les clients téléchargent ce consensus et choisissent un circuit de 3 relais. Similitudes : - Les directory authorities de Tor sont structurellement analogues aux native indexers de oc-discovery : nœuds privilégiés, fixes, formant un mesh autoritaire qui publie un état de santé du réseau. - Le consensus signé de Tor (vote majority parmi les authorities) est le mécanisme le plus proche de clientSideConsensus de oc-discovery : les authorities votent sur quels relais sont valides, oc-discovery vote sur quels indexeurs sont valides. - Les flags Tor (Guard, Exit, HSDir, Stable, Fast) jouent un rôle analogue au scoring de confiance de oc-discovery : ils qualifient les nœuds selon leurs performances (bande passante, uptime, stabilité). - La bande passante comme critère de sélection des relais Tor est analogue au composant B (bpms) du score de oc-discovery. - L'uptime comme critère de stabilité Tor ("Stable" flag : médiane des temps de session) est analogue au composant U (UptimeRatio gap-aware) de oc-discovery. Divergences : - Les directory authorities Tor sont en nombre fixe (9) et leurs clés sont hardcodées dans le client Tor. oc-discovery permet un nombre variable de natifs, configuré par l'opérateur — plus flexible mais moins résistant à une reconfiguration malveillante. - Tor vise l'anonymat : il évite que les relais connaissent la source ET la destination. oc-discovery n'a aucun objectif d'anonymat : les indexeurs connaissent l'identité de tous les nœuds qui les heartbeatent. - Le consensus Tor est calculé toutes les heures (document voté entre authorities). oc-discovery recalcule la confiance à chaque heartbeat (20 s) — beaucoup plus réactif. - Tor est open : tout pair peut devenir un relais (il suffit de déclarer son adresse). oc-discovery est fermé (PSK + rôle de natif configuré statiquement). Source : Dingledine, R., Mathewson, N., & Syverson, P. (2004). "Tor: The Second- Generation Onion Router." USENIX Security 2004. ---- 2.11 Hyperledger Fabric — Gossip Service [Androulaki et al., 2018] ------------------------------------------------------------------ Description : Hyperledger Fabric est un blockchain permissionné. Son protocole gossip propage les blocs et les données d'appartenance entre pairs d'une organisation. Des "anchor peers" jouent le rôle d'intermédiaires entre organisations. Similitudes : - Les anchor peers de Fabric sont analogues aux native indexers de oc-discovery : points de contact fixes et stables qui relaient les informations entre participants d'organisations différentes. - Le gossip permissionné (membership service provider + certificats) est analogue au PSK + signatures de oc-discovery : seuls les pairs authentifiés participent. - La notion de "private data collection" (données partagées qu'avec un sous-ensemble) est analogue au scope privé de oc-discovery (PSK isole le réseau). Divergences : - Fabric est orienté transaction et consensus d'ordre (orderer service, Raft). oc-discovery est orienté présence et découverte sans log ordonné. - Fabric utilise TLS avec certificats X.509 (PKI gérée). oc-discovery utilise des clés Ed25519 auto-certifiées (pas de PKI, pas d'autorité de certification tierce). - Fabric distingue "endorse → order → commit" avec finalité forte. oc-discovery accepte la cohérence à terme pour favoriser la disponibilité. Source : Androulaki, E., et al. (2018). "Hyperledger Fabric: A Distributed Operating System for Permissioned Blockchains." EuroSys 2018. ---- 2.12 Cassandra / Dynamo — Gossip + Ring [DeCandia et al., 2007] ---------------------------------------------------------------- Description : Amazon Dynamo et Apache Cassandra utilisent un anneau de hachage cohérent (consistent hashing) pour distribuer les données, avec gossip pour l'appartenance au cluster (chaque nœud connaît l'état de santé de tous les autres). Cassandra utilise SWIM-like pour la détection de défaillances. Similitudes : - Le hachage cohérent de Cassandra (distribution des données sans point central) est analogue à la DHT Kademlia de oc-discovery pour la distribution des enregistrements /node. - Le gossip d'appartenance de Cassandra (Endpoint State → état de santé de chaque nœud diffusé à tous) est analogue au GossipSub de oc-discovery pour la diffusion des IndexerRegistration signées. - La réplication configurable de Cassandra (replication factor) est analogue à la réplication Kademlia (k-buckets) pour la tolérance aux pannes. Divergences : - Cassandra vise la disponibilité et la tolérance aux pannes pour des données persistantes (AP dans le théorème CAP). Ses écritures sont durables. oc-discovery ne persiste que des données de présence éphémères (TTL court). - Cassandra n'a aucun mécanisme d'admission ou de scoring des pairs. Tout nœud connaissant le token ring peut rejoindre le cluster. - La hiérarchie de oc-discovery (3 niveaux) est absente dans Cassandra (flat). Source : DeCandia, G., et al. (2007). "Dynamo: Amazon's Highly Available Key-value Store." ACM SIGOPS SOSP 2007. ---- 2.13 Pastry / Tapestry / Bamboo [Rowstron & Druschel, 2001] ------------------------------------------------------------ Description : Famille de DHT de 2e génération avec routage par préfixe. Pastry ajoute le concept de "leaf set" (voisins proches dans l'espace de noms) et de "neighborhood set" (voisins géographiques). Tapestry (Yale) ajoute un routage multi-hop avec racines locales pour la localité. Similitudes : - Le "leaf set" de Pastry (nœuds proches maintenus de façon persistante) est analogue au pool StaticIndexers de oc-discovery : un ensemble stable de pairs "proches" fonctionnellement. - La notion de "neighborhood set" (localité géographique) est analogue au composant D (diversité /24 de oc-discovery) qui mesure la diversité topologique. Divergences : - Pastry/Tapestry sont conçus pour des réseaux à grande échelle (millions de nœuds). oc-discovery est conçu pour des déploiements organisationnels (centaines à quelques milliers de nœuds). - Pastry n'a aucun mécanisme de scoring ni de consensus de confiance. - La hiérarchie de oc-discovery est fonctionnelle (les rôles sont configurés), non émergente comme dans Pastry (le "leaf set" est purement géométrique). Source : Rowstron, A. & Druschel, P. (2001). "Pastry: Scalable, decentralized object location and routing for large-scale peer-to-peer systems." Middleware 2001, Springer LNCS 2218. ---- 2.14 Wireguard / Tailscale — PSK + PKI [Donenfeld, 2017] --------------------------------------------------------- Description : Wireguard est un protocole VPN léger basé sur des clés statiques Curve25519 et un handshake Noise. Tailscale construit un overlay P2P sur Wireguard avec un plan de contrôle centralisé (coordination server) pour l'échange de clés et la découverte de pairs. Similitudes : - L'isolation par PSK de oc-discovery est conceptuellement analogue à l'isolation par clé partagée de Wireguard : seuls les pairs possédant la clé peuvent établir une connexion. - La clé Ed25519 auto-certifiée de libp2p est analogue à la clé statique Curve25519 de Wireguard : identité = clé, aucune PKI tierce nécessaire. Divergences : - Wireguard est un tunnel L3 (plan de données). oc-discovery est un protocole applicatif (plan de contrôle / découverte). Ils opèrent à des couches différentes. - Tailscale centralise la découverte (coordination server). oc-discovery distribue cette fonction sur le mesh natif. - oc-discovery n'implémente pas de confidentialité des flux applicatifs (les messages JSON circulent en clair sur le transport libp2p TCP, protégé uniquement par la PSK réseau, pas par un chiffrement de bout en bout des payloads). Source : Donenfeld, J. A. (2017). "WireGuard: Next Generation Kernel Network Tunnel." NDSS 2017. ---- 2.15 Polkadot — Parachain Discovery [Wood, 2016] ------------------------------------------------- Description : Polkadot utilise libp2p pour son transport, avec une couche de découverte basée sur Kademlia pour trouver les pairs de chaque parachain. La chaîne relais (Relay Chain) joue un rôle de coordination autoritaire entre les parachains (validation, finalité). Similitudes très fortes (stack identique) : - Polkadot utilise exactement la même pile : libp2p, yamux, Kademlia, GossipSub. - La Relay Chain de Polkadot est structurellement analogue aux native indexers de oc-discovery : autorité de coordination entre participants. - Les validateurs Polkadot (nœuds stables et bien capitalisés) sont analogues aux native indexers (nœuds stables et bien connectés). - Le protocole GRANDPA (finalité par vote de validateurs) partage avec clientSideConsensus le principe de vote majoritaire sur un état proposé. Divergences : - Polkadot est un protocole de blockchain : son consensus (BABE + GRANDPA) vise la finalité économique (transactions). oc-discovery vise la découverte de pairs — aucune finalité économique, aucune donnée persistante à long terme. - Polkadot intègre un mécanisme de staking économique (preuve d'enjeu) pour punir les validateurs malveillants. oc-discovery utilise uniquement des mécanismes cryptographiques (signature + quorum). Source : Wood, G. (2016). "Polkadot: Vision for a Heterogeneous Multi-chain Framework." Whitepaper v1. ================================================================================ 3. PATTERNS ARCHITECTURAUX RECONNUS ================================================================================ 3.1 Supernode / Tiered P2P (FastTrack, Gnutella2, Skype) --------------------------------------------------------- Pattern : Séparation des participants en tiers selon leurs capacités. Les supers-nœuds forment un mesh stable et gèrent les listes d'appartenance des nœuds ordinaires. oc-discovery : ✅ Correspond exactement. Native = supernode, Indexer = intermédiaire, Node = feuille. La hiérarchie est fonctionnelle (non pyramidale) : un natif peut devenir indexeur, un indexeur peut agir comme nœud. Divergence clé : dans les systèmes classiques (FastTrack, Skype), les supernœuds émergent de la topologie (auto-sélection selon la bande passante). Dans oc-discovery, les natifs sont configurés statiquement — choix délibéré pour la sécurité et la prévisibilité, au détriment de l'élasticité. ---- 3.2 Gossip Membership (SWIM, Cassandra, Consul/Serf) ----------------------------------------------------- Pattern : Dissémination par infection épidémique. Chaque nœud sélectionne aléatoirement k voisins à chaque round et leur envoie son état local. L'information atteint tous les nœuds en O(log n) rounds avec haute probabilité. oc-discovery : ✅ Partiellement. GossipSub (oc-indexer-registry) implémente ce pattern entre natifs pour disséminer les IndexerRegistration. GossipSub est une implémentation optimisée avec un graphe de gossip stable (mesh overlay) + graft/prune. Divergence : le gossip de oc-discovery ne porte que les événements d'enregistrement d'indexeurs (plan de contrôle). Il ne porte pas l'état de santé global du réseau (membership complet) comme SWIM. La vivacité des indexeurs est déterminée par le heartbeat direct, pas par gossip. ---- 3.3 DHT Kademlia avec namespacing (IPFS, Ethereum, Polkadot) ------------------------------------------------------------- Pattern : Table de hachage distribuée à résolution en O(log n), avec espaces de noms séparés pour différents types de données. Validateurs customisés par namespace. oc-discovery : ✅ Implémenté. 4 espaces : /node, /indexer, /name, /pid. Chaque espace a son propre validateur (PeerRecordValidator, IndexerRecordValidator, DefaultValidator). La DHT est en mode Server (tous les indexeurs/natifs participent au routage). Divergence notable : la DHT est secondaire dans oc-discovery (lecture lente de secours), contrairement à IPFS où elle est le plan principal. Ce choix favorise la latence de découverte (cache mémoire natif < 1 ms vs DHT 50–200 ms) mais introduit une désynchronisation potentielle (split-brain DHT/cache jusqu'à 30 s). ---- 3.4 Consensus par vote majoritaire (Tor, Raft, PBFT, Tendermint) ----------------------------------------------------------------- Pattern : Un ensemble de participants vote sur un état proposé. Un état est accepté si plus de q × |voters| participants l'approuvent (q > 0.5 pour tolérance byzantine, q > 0.5 pour crash-fault). oc-discovery : ✅ Implémenté en deux phases : Phase 1 (clientSideConsensus) : vote des natifs sur les candidats-indexeurs. Phase 2 (indexerLivenessVote) : vote des indexeurs stables sur la vivacité. Divergence majeure vs Raft/PBFT : le consensus de oc-discovery est stateless et one-shot — chaque appel à ConnectToNatives/replenishIndexersFromNative lance un round de vote indépendant. Il n'y a pas de log répliqué, pas de leader élu, pas de finalité forte. C'est un consensus light (discovery-grade) adapté à la découverte de pairs, pas à l'accord sur des transactions. ---- 3.5 Self-healing / Auto-recovery (Erlang OTP, Kubernetes, etcd) ---------------------------------------------------------------- Pattern : Le système détecte ses propres défaillances et se répare sans intervention externe. Acteurs superviseurs (Erlang), liveliness/readiness probes (k8s), leader re-election (etcd). oc-discovery : ✅ Implémenté. Quatre mécanismes de self-healing : (a) replenishIndexersFromNative : panne indexeur → remplacement automatique. (b) replenishNativesFromPeers : panne natif → recherche de remplaçant. (c) retryLostNative : ticker 30 s pour réessayer un natif inaccessible. (d) IsSelfFallback : natif sans indexeur → s'auto-désigne + runOffloadLoop. Divergence : Erlang/k8s ont un superviseur externe au composant défaillant (out-of-process). oc-discovery est self-supervising : chaque goroutine gère ses propres défaillances (doTick → err → delete + replenish). Cela simplifie l'architecture mais rend les défaillances en cascade plus difficiles à isoler. ---- 3.6 Trust Scoring / Reputation (BitTorrent, Web of Trust PGP, EigenTrust) -------------------------------------------------------------------------- Pattern : Attribution d'un score de réputation aux pairs selon des métriques observables (comportement passé, connectivité, uptime). Les pairs à faible score sont exclus ou dé-priorisés. oc-discovery : ✅ Implémenté. Score 5 composants avec seuil dynamique : S = (0.20×U + 0.20×B + 0.20×D + 0.15×L + 0.25×F) × 100 minScore(age) = 20 + 60×min(age/24h, 1) Similitude avec EigenTrust [Kamvar et al., 2003] : les deux systèmes normalisent les scores entre 0 et 1, utilisent l'uptime comme signal de fiabilité, et intègrent un historique temporel. Divergence majeure : EigenTrust est itératif (convergence en plusieurs rounds de gossip). oc-discovery calcule le score localement à chaque heartbeat sans propagation globale. C'est un score observable local (l'indexeur mesure ses propres pairs), non un score global agrégé par le réseau. Divergence vs BitTorrent : BitTorrent utilise un score d'échange ("tit-for-tat") basé sur les octets reçus. oc-discovery mesure la qualité de connexion (latence, bande passante, uptime, diversité topologique) — des métriques de qualité de service, pas de réciprocité de comportement. Source : Kamvar, S. D., Schlosser, M. T., & Garcia-Molina, H. (2003). "The EigenTrust Algorithm for Reputation Management in P2P Networks." WWW 2003. ---- 3.7 Long-lived Bidirectional Streams (gRPC server-side streaming, WebSocket) ----------------------------------------------------------------------------- Pattern : Réutilisation d'une connexion persistante pour des échanges multiples, évitant le coût de connexion (TCP SYN+ACK + TLS 1-RTT) à chaque message. oc-discovery : ✅ Implémenté. /opencloud/heartbeat/1.0 maintient un stream yamux persistant pour la durée de vie du pair. Économie estimée : 3 RTT par tick vs une connexion fresh. Convergence avec gRPC server-side streaming : même concept — un client ouvre un stream et le serveur pushed des messages periódicamente. La différence : gRPC est orienté RPC (request-response unique dans la direction inverse). oc-discovery est purement unidirectionnel (node → indexer, pas de réponse applicative sur le stream heartbeat). ================================================================================ 4. TABLEAU COMPARATIF SYNTHÉTIQUE ================================================================================ Légende : ✅ présent / similaire ⚠️ partiel / approximatif ❌ absent ┌─────────────────────────────────┬────────┬──────────┬────────┬───────┬────────┬────────┬────────┬──────────┐ │ Critère │oc-disc │Kademlia │FastTrk │Consul │ IPFS │Tor │Ethereum│ZooKeeper │ ├─────────────────────────────────┼────────┼──────────┼────────┼───────┼────────┼────────┼────────┼──────────┤ │ Réseau privé / fermé (PSK) │ ✅ │ ❌ │ ❌ │ ⚠️ │ ⚠️ │ ❌ │ ❌ │ ⚠️ │ │ Hiérarchie fonctionnelle 3 niv. │ ✅ │ ❌ │ ✅ │ ⚠️ │ ❌ │ ✅ │ ❌ │ ❌ │ │ DHT Kademlia │ ✅ │ ✅ │ ❌ │ ❌ │ ✅ │ ❌ │ ✅ │ ❌ │ │ Gossip dissémination │ ✅ │ ❌ │ ✅ │ ✅ │ ✅ │ ⚠️ │ ✅ │ ❌ │ │ Heartbeat long-lived (stream) │ ✅ │ ❌ │ ❌ │ ⚠️ │ ❌ │ ❌ │ ❌ │ ✅ │ │ Scoring de confiance multi-dim. │ ✅ │ ❌ │ ⚠️ │ ❌ │ ❌ │ ⚠️ │ ❌ │ ❌ │ │ Consensus de découverte (vote) │ ✅ │ ❌ │ ❌ │ ✅ │ ❌ │ ✅ │ ❌ │ ✅ │ │ Liveness vote 2 phases │ ✅ │ ❌ │ ❌ │ ❌ │ ❌ │ ❌ │ ❌ │ ❌ │ │ Signature cryptographique entrée│ ✅ │ ❌ │ ❌ │ ⚠️ │ ✅ │ ✅ │ ✅ │ ❌ │ │ TTL + GC des entrées │ ✅ │ ⚠️ │ ❌ │ ✅ │ ⚠️ │ ✅ │ ❌ │ ✅ │ │ Self-healing automatique │ ✅ │ ❌ │ ❌ │ ✅ │ ⚠️ │ ❌ │ ⚠️ │ ✅ │ │ Self-fallback (native→indexer) │ ✅ │ ❌ │ ❌ │ ❌ │ ❌ │ ❌ │ ❌ │ ❌ │ │ Consensus fort (Raft/PBFT) │ ❌ │ ❌ │ ❌ │ ✅ │ ❌ │ ⚠️ │ ✅ │ ✅ │ │ Seuil d'admission dynamique │ ✅ │ ❌ │ ❌ │ ❌ │ ❌ │ ❌ │ ❌ │ ❌ │ │ UptimeTracker gap-aware │ ✅ │ ❌ │ ❌ │ ❌ │ ❌ │ ⚠️ │ ❌ │ ❌ │ │ Fill rate routing (bell curve) │ ✅ │ ❌ │ ❌ │ ⚠️ │ ❌ │ ❌ │ ❌ │ ❌ │ │ Pas de PKI tierce │ ✅ │ ✅ │ ✅ │ ❌ │ ✅ │ ❌ │ ✅ │ ❌ │ │ Découverte bootstrapable > 0 │ ✅ │ ⚠️ │ ✅ │ ⚠️ │ ✅ │ ✅ │ ✅ │ ⚠️ │ │ Résistance à la partition WAN │ ✅ │ ⚠️ │ ⚠️ │ ❌ │ ✅ │ ✅ │ ⚠️ │ ❌ │ │ Scalabilité > 10K nœuds │ ⚠️ │ ✅ │ ✅ │ ⚠️ │ ✅ │ ✅ │ ✅ │ ⚠️ │ │ Anonymat / confidentialité pairs│ ❌ │ ❌ │ ❌ │ ❌ │ ⚠️ │ ✅ │ ❌ │ ❌ │ └─────────────────────────────────┴────────┴──────────┴────────┴───────┴────────┴────────┴────────┴──────────┘ ================================================================================ 5. ANALYSE DES DIVERGENCES STRUCTURELLES FONDAMENTALES ================================================================================ 5.1 La hiérarchie sans autorité centrale — originalité principale ------------------------------------------------------------------ oc-discovery réussit un équilibre que peu de systèmes atteignent : une hiérarchie fonctionnelle à 3 niveaux sans point de centralisation du contrôle. Tor s'en approche le plus avec ses 9 directory authorities — mais leurs clés sont hardcodées (décision centralisée). FastTrack et Gnutella2 ont une hiérarchie émergente mais sans mécanisme de consensus. La combinaison (hiérarchie statiquement configurée) + (consensus dynamique entre pairs de même niveau) + (fallback autonome sans coordinateur) est, à notre connaissance, sans équivalent direct dans les systèmes existants pour la couche de découverte de services. 5.2 Le score de confiance comme filtre d'admission — contraste avec DHT pures ------------------------------------------------------------------------------ Les DHT pures (Kademlia, Chord, Pastry) n'ont aucun mécanisme d'admission : tout pair qui connaît le bootstrap peut joindre le réseau. BitTorrent ajoute le "tit-for-tat" mais c'est un mécanisme de réciprocité, pas de qualité. EigenTrust est global (agrégation par gossip), non local. oc-discovery est rare dans sa catégorie : il applique un score de qualité multi-composant (5 métriques) calculé localement par l'indexeur receveur, avec un seuil dynamique qui s'adapte à la maturité du pair. Cela ressemble davantage à une logique de SLA d'entreprise qu'à un protocole P2P académique. 5.3 Le consensus en deux phases — séparation admission/vivacité --------------------------------------------------------------- Aucun système de découverte P2P parmi ceux étudiés ne sépare explicitement l'admission (validation d'identité par un tier de confiance) et la vivacité (validation de présence par les pairs actuels). Cette séparation (principe D19) est une contribution architecturale originale. Tor s'en approche le plus : les directory authorities valident l'identité des relais (admission), et le consensus horaire inclut des métriques de disponibilité récente (vivacité), mais les deux étapes sont fondues dans un seul vote horaire des mêmes acteurs, sans séparation structurelle des responsabilités. 5.4 La contrainte PSK — réseau organisationnel, non universel ------------------------------------------------------------- Le PSK rend oc-discovery fondamentalement différent de tous les systèmes P2P "ouverts" (IPFS, Ethereum, Bitcoin). C'est un réseau de confiance délimitée, plus proche des VPN d'entreprise ou des blockchains permissionnées (Hyperledger) que des réseaux P2P académiques. Cette contrainte simplifie considérablement la gestion des Sybil attacks (impossibles sans PSK) mais impose une gestion hors-bande de la distribution de la clé. 5.5 Limites par rapport aux systèmes comparés ---------------------------------------------- (a) Scalabilité : oc-discovery n'a pas été évalué au-delà de quelques centaines de nœuds. Kademlia, IPFS, et Ethereum sont validés à des millions de nœuds. Le mesh natif (topologie complète O(n²) entre natifs) ne passera pas à l'échelle de centaines de natifs. (b) Indirect probing absent : contrairement à SWIM/Consul, la détection de défaillance de oc-discovery est directe (heartbeat failure = dead). Un intermédiaire réseau défaillant peut créer de faux positifs. (c) Cohérence à terme seulement : contrairement à Consul (Raft CP) ou ZooKeeper (ZAB CP), oc-discovery offre uniquement une cohérence à terme. Pour des applications nécessitant une garantie forte de cohérence (config critique, PKI), un système CP est préférable. (d) Anonymat absent : Tor garantit l'anonymat des clients. oc-discovery expose l'identité de tous les pairs à tous les indexeurs (intentionnel : registre d'identités, pas d'anonymisation). ================================================================================ 6. POSITIONNEMENT DANS L'ESPACE DES DESIGNS ================================================================================ Axe 1 : Ouvert ←——————————————————→ Fermé (PSK) Kademlia, IPFS, Ethereum oc-discovery, Hyperledger Fabric Axe 2 : Flat ←————————————————————→ Hiérarchique Kademlia, Bitcoin, Cassandra oc-discovery, Tor, FastTrack Axe 3 : AP (disponibilité) ←———————→ CP (cohérence forte) oc-discovery, IPFS, Dynamo Consul, ZooKeeper, etcd Axe 4 : Score de confiance absent ←→ Présent Kademlia, Bitcoin, Chord oc-discovery, Tor (flags), EigenTrust Axe 5 : Court TTL / éphémère ←—————→ Long TTL / persistant oc-discovery (2min–90s) Cassandra, DHT IPFS (jusqu'à 24h) oc-discovery occupe une position distinctive : - Fermé (PSK) comme Hyperledger, mais sans PKI centralisée. - Hiérarchique comme Tor et FastTrack, mais avec consensus entre les hubs. - AP comme IPFS et Dynamo, mais avec des TTL très courts pour les données de présence (2 min vs heures/jours). - Scoring comme Tor et EigenTrust, mais calculé localement (non global). - Self-healing complet comme Consul et k8s, mais sans orchestrateur externe. ================================================================================ 7. RÉSUMÉ ================================================================================ oc-discovery est un système hybride qui emprunte à plusieurs familles de systèmes décentralisés sans s'identifier pleinement à aucun : - À FastTrack/Gnutella2 : la hiérarchie supernode/leaf. - À IPFS/Ethereum : la pile libp2p + Kademlia + GossipSub. - À Tor : le consensus entre autorités pour valider les participants, et l'utilisation de l'uptime/bande passante comme critères de qualité. - À Consul/SWIM : les heartbeats de détection de défaillance et le GC par TTL. - À EigenTrust : le scoring multi-composant de confiance des pairs. - À ZooKeeper/Raft : l'idée d'un quorum de vote pour valider un état proposé. Les principales contributions originales de oc-discovery par rapport à l'état de l'art sont : 1. La séparation structurelle admission (native) / vivacité (indexer) — D19. 2. Le score dynamique gap-aware avec seuil adaptatif à la maturité du pair. 3. Le routage fill rate par courbe en cloche (w(F) = F×(1-F)). 4. Le mode IsSelfFallback + runOffloadLoop pour la continuité sans indexeur. 5. La combinaison PSK + signatures auto-certifiées sans PKI tierce. ================================================================================ 8. NOTE MÉTHODOLOGIQUE ================================================================================ Cette analyse est basée sur une lecture directe des spécifications et publications académiques référencées. Les comparaisons portent sur les propriétés architecturales et les mécanismes de protocole, non sur les performances mesurées (oc-discovery n'ayant pas fait l'objet d'un benchmark à large échelle à la date de rédaction). Les appréciations ✅/⚠️/❌ dans le tableau comparatif reflètent une analyse qualitative et peuvent nécessiter une révision en fonction des évolutions respectives des systèmes comparés. ================================================================================ 9. TRAJECTOIRE D'ÉVOLUTION : VERS UN ANNUAIRE NATIF DYNAMIQUE ================================================================================ 9.1 Limite actuelle : le pool de natives est statique ------------------------------------------------------ Dans la version actuelle d'oc-discovery, les native indexers sont connus au démarrage via configuration (StaticNatives). Ce pool évolue partiellement au runtime (replenishNativesFromPeers) mais reste ancré à une liste d'entrée fixe. Cette contrainte implique que : - Chaque native connaît potentiellement tous les indexers → état O(N indexers) - Le consensus inter-natives est O(natives²) en communication - Les natives sont des hubs structurellement privilegiés → SPOFs relatifs - L'ajout d'une nouvelle native requiert une reconfiguration manuelle À mesure que le réseau grossit, les natives deviennent un goulot d'étranglement analogue aux super-nodes Gnutella 2 ou aux directory servers de BitTorrent. 9.2 L'analogie avec les indexeurs : un modèle déjà résolu ---------------------------------------------------------- Le problème a déjà été résolu pour les indexers : un nœud démarre avec un pool de bootstrap (StaticIndexers), puis l'enrichit dynamiquement via les natives (GetIndexersResponse, scoring, fill rate). Le pool d'indexers est vivant. La même logique devrait s'appliquer aux natives : ÉTAT ACTUEL : StaticNatives (boot) → léger enrichissement runtime CIBLE : StaticNatives (boot seulement) → pool natif vivant et ouvert Les natives ne seraient plus une liste exhaustive connue de tous, mais un annuaire distribué auto-organisé, rejoint par bootstrap puis par propagation. Un nœud démarre avec 1-3 natives connues, et en découvre d'autres par gossip ou par requête, exactement comme un indexer découvre ses pairs. 9.3 Séparation des rôles : toile vs annuaire -------------------------------------------- Cette évolution amène à clarifier deux fonctions que l'architecture actuelle fait porter simultanément aux natives : INDEXERS — La Toile de Routage ┌─────────────────────────────────────────────────────────────────────────┐ │ Rôle : Acheminer le trafic, servir les requêtes GET/Publish des nodes │ │ Modèle : Pool sélectif, scoring qualité, fill rate, rotation dynamique │ │ Taille : Quelques dizaines par node (pool optimisé, pas exhaustif) │ │ Analogie : CDN edge nodes, Tor relays │ └─────────────────────────────────────────────────────────────────────────┘ NATIVES — L'Annuaire Distribué ┌─────────────────────────────────────────────────────────────────────────┐ │ Rôle : Connaître et diffuser l'existence des indexers disponibles │ │ Modèle : Plus exhaustif que moins, propagation par gossip ou routage │ │ Taille : Peut croître sans limite si le routage est O(log N) │ │ Analogie : DNS racine distribué, Kademlia bootstrap nodes │ └─────────────────────────────────────────────────────────────────────────┘ En séparant ces deux préoccupations, le trafic opérationnel (node ↔ indexer) est découplé du trafic d'annuaire (indexer ↔ native). Les natives n'absorbent plus les heartbeats fonctionnels, elles ne font que maintenir un annuaire. 9.4 Inspiration Tapestry : routage O(log N) pour le plan d'annuaire -------------------------------------------------------------------- Tapestry [Zhao et al., 2004] démontre que des réseaux de millions de nœuds sont atteignables avec un routage Plaxton digit-by-digit : log₁₆(1 000 000) ≈ 5 sauts Table de routage ≈ 5 × 16 = ~80 entrées par nœud État par nœud = O(log N) — constant en pratique Appliqué aux natives d'oc-discovery, cela donnerait : - Les natives forment entre elles un overlay DHT (Kademlia ou Plaxton) - Chaque native ne connaît que O(log N) autres natives, pas toutes - Une requête "trouver des indexers de type X" traverse O(log N) natives - L'ajout d'une nouvelle native = jointure DHT, aucune reconfig centralisée Les indexers actuels deviendraient des feuilles de cet overlay, enregistrées auprès de leur native de référence (la plus proche dans l'espace de nommage). 9.5 Résumé de la trajectoire ----------------------------- Phase 1 (actuel) : Natives statiques, pool d'indexers dynamique Phase 2 (proche) : Pool de natives dynamique par bootstrap + gossip, même mécanique que le pool d'indexers (déjà résolu) Phase 3 (long terme): Natives organisées en overlay DHT O(log N), annuaire décentralisé sans hub autoritaire fixe, trafic opérationnel (indexers) découplé du plan d'annuaire (natives) Ce chemin n'est pas une rupture architecturale : les primitives libp2p (Kademlia DHT, GossipSub) sont déjà présentes dans oc-discovery. L'évolution consiste à étendre leur usage au niveau du plan de contrôle des natives, plutôt qu'au seul plan de données des records. ================================================================================ 10. RÉFÉRENCES ================================================================================ [1] Maymounkov, P. & Mazières, D. (2002). "Kademlia: A Peer-to-Peer Information System Based on the XOR Metric." IPTPS 2002. Springer LNCS 2429, pp. 53-65. [2] Stoica, I., Morris, R., Karger, D., Kaashoek, M. F., & Balakrishnan, H. (2001). "Chord: A Scalable Peer-to-Peer Lookup Service for Internet Applications." ACM SIGCOMM 2001. doi:10.1145/383059.383071. [3] Rowstron, A. & Druschel, P. (2001). "Pastry: Scalable, Decentralized Object Location and Routing for Large-Scale Peer-to-Peer Systems." Middleware 2001. Springer LNCS 2218. [4] Benet, J. (2014). "IPFS - Content Addressed, Versioned, P2P File System." arXiv:1407.3561. https://arxiv.org/abs/1407.3561 [5] libp2p (2019). libp2p Specifications. Protocol Labs. https://github.com/libp2p/specs [6] Dingledine, R., Mathewson, N., & Syverson, P. (2004). "Tor: The Second- Generation Onion Router." USENIX Security Symposium 2004, pp. 303-320. [7] Das, A., Gupta, I., & Motivala, A. (2002). "SWIM: Scalable Weakly-consistent Infection-style Process Group Membership Protocol." DSN 2002, pp. 303-312. [8] DeCandia, G., et al. (2007). "Dynamo: Amazon's Highly Available Key-value Store." ACM SOSP 2007. doi:10.1145/1294261.1294281. [9] Hunt, P., Konar, M., Junqueira, F. P., & Reed, B. (2010). "ZooKeeper: Wait-free Coordination for Internet-scale Systems." USENIX ATC 2010. [10] Kamvar, S. D., Schlosser, M. T., & Garcia-Molina, H. (2003). "The EigenTrust Algorithm for Reputation Management in P2P Networks." WWW 2003. doi:10.1145/775152.775242. [11] Androulaki, E., et al. (2018). "Hyperledger Fabric: A Distributed Operating System for Permissioned Blockchains." EuroSys 2018. doi:10.1145/3190508.3190538. [12] Nakamoto, S. (2008). "Bitcoin: A Peer-to-Peer Electronic Cash System." https://bitcoin.org/bitcoin.pdf [13] Ethereum Foundation (2021). "Node Discovery Protocol v5." https://github.com/ethereum/devp2p/blob/master/discv5/discv5.md [14] Wood, G. (2016). "Polkadot: Vision for a Heterogeneous Multi-chain Framework." https://polkadot.network/PolkaDotPaper.pdf [15] Donenfeld, J. A. (2017). "WireGuard: Next Generation Kernel Network Tunnel." NDSS 2017. doi:10.14722/ndss.2017.23160. [16] Demers, A., et al. (1987). "Epidemic Algorithms for Replicated Database Maintenance." ACM PODC 1987. doi:10.1145/41840.41841. [17] Kermarrec, A.-M. & van Steen, M. (2007). "Gossiping in Distributed Systems." ACM SIGOPS Operating Systems Review 41(5), pp. 2-7. [18] Mazieres, D., Kaminsky, M., Kaashoek, M. F., & Witchel, E. (2000). "Separating Key Management from File System Security." ACM SOSP 1999. (référencé dans l'introduction du ARCHITECTURE_PAPER.txt d'oc-discovery) [19] HashiCorp (2014). Consul Architecture Documentation. https://developer.hashicorp.com/consul/docs/architecture [20] Ritter, J. (2001). "Why Gnutella Can't Scale. No, Really." Clip2 Distributed Search Solutions. http://clip2.com/GnutellaProtocol04.pdf ================================================================================