---
title: "Réseau pair-à-pair"
description: "Un réseau pair-à-pair fournit à chaque nœud un ensemble limité et changeant de pairs directs pour la découverte, le gossip et les échanges requête-réponse ; il ne crée pas de vue globale et ne transforme pas l’acceptation d’un message en consensus."
image: "https://wiki.fcontext.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Réseau pair-à-pair

> À des fins éducatives uniquement ; ne constitue ni un conseil en investissement ni une recommandation d’investissement. Les investissements peuvent entraîner des pertes.

<a id="answer"></a>

## Réponse directe

Un réseau pair-à-pair permet à chaque nœud de découvrir et conserver un ensemble limité de pairs directs, d’échanger des messages de protocole authentifiés et de construire sa propre vue locale sans tout faire transiter par un serveur central. Ce n’est ni un graphe complet, ni un mempool global, ni une source de vérité autonome. La réception, la validation ou la retransmission d’un objet par un pair ne prouve ni que tous les nœuds l’ont vu, ni qu’un bloc l’a inclus, ni que le consensus l’a finalisé.

Après The Merge, Ethereum utilise deux réseaux P2P distincts. Les clients d’exécution emploient la découverte, RLPx et la capability versionnée `eth` pour la synchronisation et l’échange de transactions. Les clients de consensus emploient discv5 pour la découverte, ainsi que le gossip libp2p et des protocoles requête-réponse pour les beacon blocks, attestations et autres objets de consensus. Les deux clients se coordonnent localement par l’Engine API authentifiée ; une wallet soumet généralement par JSON-RPC sans devenir pour autant un nœud de gossip.

<a id="mechanism"></a>

## Fonctionnement

1. Fixer la blockchain, le réseau, la configuration de genesis et de fork, les versions des clients d’exécution et de consensus, les identités des nœuds et l’heure d’observation. Représenter séparément client d’exécution, client de consensus, validator facultatif, Engine API locale et RPC destiné aux utilisateurs.
2. Vérifier chaque voie de découverte : bootnodes intégrés, listes DNS, pairs statiques ou de confiance, identité ENR ou enode, endpoint et séquence annoncés, compatibilité réseau, NAT et accessibilité entrante. Un ENR signé lie un enregistrement à une clé ; il ne prouve ni l’honnêteté, ni la synchronisation, ni l’accessibilité actuelle.
3. Consigner séparément la connexion et la négociation de protocole. Les pairs d’exécution établissent des sessions RLPx et négocient des capabilities telles que `eth` ; les pairs de consensus négocient transport libp2p, sécurité et identifiants de protocole après la découverte discv5. Trouver un endpoint n’implique pas une compatibilité applicative.
4. Suivre chaque objet sur son parcours réel. Une transaction peut passer de la soumission RPC à la validation locale et au mempool d’exécution, puis aux annonces et requêtes `eth`. Les objets de consensus utilisent une validation gossip propre au topic, tandis que les blocs manquants peuvent être récupérés par requête-réponse.
5. Appliquer un décodage borné, la déduplication, des limites de débit et des contrôles de signature, syntaxe et état avant admission ou retransmission locale. Consigner les résultats invalides, ignorés, indisponibles ou limités par les ressources ; score et déconnexion des pairs sont des décisions locales d’implémentation, non une réputation de consensus.
6. Maintenir réception, validation, retransmission, inclusion de transaction, résultat d’exécution, fork choice, justification et finalité comme des états et horloges distincts. Comparer plusieurs pairs ou nœuds lorsque pool, head ou réponse d’historique locale est incomplet, contradictoire ou périmé.
7. Surveiller diversité des pairs entrants et sortants, opérateur, concentration des préfixes IP et ASN, rotation, latence, pertes, bande passante, files, trafic invalide, état de l’horloge et dépendances RPC. Répéter la perte des bootnodes, une panne NAT, une partition, une attaque eclipse, une surcharge et le rétablissement sans revendiquer une résistance absolue.

Découverte de pairs, sécurité du transport et validité applicative résolvent des problèmes différents. Les bootnodes présentent des candidats, mais ne relaient pas le trafic ordinaire et ne choisissent pas la chaîne canonique. Le chiffrement protège contenu et authentification de session, mais les pairs connaissent toujours endpoints et horaires ; un fournisseur RPC distant peut aussi observer requêtes, adresses et transactions soumises.

La propagation est concurrente et dépend de la topologie. Fanout, chemins dupliqués, sérialisation par bande passante, CPU de validation, files, pertes, retransmission, score et règles propres à l’objet déterminent la distribution et la traîne des temps d’arrivée. Une formule telle que `delay = hops * perHopTime` n’est qu’un modèle pédagogique sériel explicite, non une garantie du réseau.

<a id="example"></a>

## Exemples

- **Parcours sériel et pipeline.** Sur un parcours pédagogique de `4 hops`, chaque saut comporte `80 ms` de réseau et `20 ms` de validation. Un traitement entièrement sériel donne `4 * (80 + 20) = 400 ms`. Si la validation chevauche la transmission suivante, une borne inférieure simplifiée est `4 * 80 + 20 = 340 ms`. Aucun résultat n’est le temps de propagation du réseau entier.
- **Annonce et récupération de transactions.** Un nœud reçoit `20` hashes et en possède déjà `6` ; il manque donc `20 - 6 = 14` corps. Si une requête pédagogique en contient au plus `8`, il faut `ceil(14 / 8) = 2 batches`. Avec `120 ms` d’aller-retour et `30 ms` de validation par lot, le traitement sériel dure `2 * (120 + 30) = 300 ms` ; le parallèle idéal, `150 ms`. Les limites réelles dépendent de la version `eth` négociée et du client.
- **Probabilité simplifiée d’eclipse.** Si chacun des `8` pairs sortants était tiré indépendamment et si `25%` des candidats étaient malveillants, la probabilité qu’ils le soient tous serait `0.25^8 = 0.0000152587890625 = 0.00152587890625%`. Biais de découverte, identités Sybil, corrélation IP/ASN et conservation des pairs violent l’indépendance ; ce n’est pas une garantie de sécurité.
- **Surcharge de validation.** Le gossip entrant est de `900 messages/s` ; `4` workers valident chacun `250 messages/s`, soit une capacité de `1,000 messages/s`, une marge de `100 messages/s` et une utilisation de `90%`. Une attaque à `1,400 messages/s` crée `400 messages/s` d’arriéré et `6,000 messages` en `15 seconds`. Une file de `5,000-message` se remplit en `5,000 / 400 = 12.5 seconds` avant rejets ou limitation, sans tenir compte de la variance du service.

<a id="risks"></a>

## Risques

- Mauvaise configuration de blockchain, genesis ou fork.
- Incompatibilité entre client d’exécution, client de consensus ou Engine API.
- Découverte par bootnode ou DNS concentrée ou détournée.
- Métadonnées d’endpoint périmées, falsifiées ou inaccessibles.
- NAT, firewall ou ports bloquant l’accessibilité attendue.
- Attaque eclipse filtrant la vue locale du nœud.
- Identités Sybil et concentration par IP, ASN, opérateur ou cloud.
- Dépendance excessive envers des pairs statiques ou de confiance.
- Censure de transactions ou relais sélectif.
- Divergence entre flux d’ordres public et privé.
- Divergence locale d’admission, remplacement et éviction du mempool.
- Gossip invalide épuisant le CPU de validation.
- Requêtes surdimensionnées, décompression ou épuisement de bande passante, mémoire ou disque.
- Manipulation du score des pairs ou fausses pénalités.
- Contre-pression des files supprimant des messages sensibles au temps.
- Latence, pertes ou dérive d’horloge provoquant une divergence temporaire du head.
- Incompatibilité de version de protocole ou de fork digest.
- Historique élagué ou réponse indisponible faute de ressources interprété comme une inexistence.
- Fuite de confidentialité sur IP, horaires, requêtes et origine des transactions.
- RPC centralisé ou exposé permettant suivi, vues périmées, censure ou compromission.

<a id="misconceptions"></a>

## Idées reçues

- **Chaque nœud se connecte directement à tous les autres.** Chacun possède un ensemble local fini et changeant ; différents nœuds peuvent voir temporairement des messages et heads distincts.
- **Un bootnode est une source de blocs de confiance ou un participant au consensus.** Son rôle normal est de présenter des pairs ; validité de la chaîne et fork choice sont vérifiés ailleurs.
- **Une transaction acceptée par un pair est diffusée mondialement et son inclusion est garantie.** Admission et relais sont locaux ; builders ou proposers peuvent l’omettre.
- **La validation gossip signifie consensus et finalité.** C’est une première barrière réseau locale ; fork choice, justification et finalité sont des machines à états distinctes.
- **Davantage de pairs ou un transport chiffré procurent automatiquement anonymat et résistance aux attaques eclipse.** Diversité et sélection comptent ; pairs et fournisseurs RPC peuvent encore corréler endpoints, horaires et activité.

<a id="related"></a>

## Sujets connexes

- [Nœud complet](/fr/crypto/full-node/)
- [Mempool](/fr/crypto/mempool/)
- [Résistance à la censure](/fr/crypto/censorship-resistance/)

<a id="sources"></a>

## Sources

- [Networking layer](https://ethereum.org/developers/docs/networking-layer) - Ethereum.org (consulté le 2026-08-13)
- [Ethereum Wire Protocol (ETH)](https://github.com/ethereum/devp2p/blob/master/caps/eth.md) - Ethereum devp2p (consulté le 2026-08-13)
- [The RLPx Transport Protocol](https://github.com/ethereum/devp2p/blob/master/rlpx.md) - Ethereum devp2p (consulté le 2026-08-13)
- [Node Discovery Protocol v5 - Wire Protocol](https://github.com/ethereum/devp2p/blob/master/discv5/discv5-wire.md) - Ethereum devp2p (consulté le 2026-08-13)
- [Phase 0 -- Networking](https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/p2p-interface.md) - Ethereum Consensus Specs (consulté le 2026-08-13)
- [gossipsub v1.1: Security extensions to improve on attack resilience and bootstrapping](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.1.md) - libp2p (consulté le 2026-08-13)
- [Connecting To The Network](https://geth.ethereum.org/docs/fundamentals/peer-to-peer) - go-ethereum (consulté le 2026-08-13)
- [Spin up your own Ethereum node](https://ethereum.org/developers/docs/nodes-and-clients/run-a-node/) - Ethereum.org (consulté le 2026-08-13)

Source: https://wiki.fcontext.com/fr/crypto/peer-to-peer-network/index.mdx