oc-discovery/docs/DECENTRALIZED_SYSTEMS_COMPARISON.txt

================================================================================
  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

================================================================================