---
title: "Rete peer-to-peer"
description: "Una rete peer-to-peer fornisce a ogni nodo un insieme limitato e variabile di peer diretti per discovery, gossip e scambi request-response; non crea una vista globale né trasforma l’accettazione di messaggi in consenso."
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.
# Rete peer-to-peer
> Solo a scopo educativo; non costituisce consulenza né raccomandazione d’investimento. Gli investimenti possono comportare perdite.
## Risposta diretta
Una rete peer-to-peer consente a ogni nodo di scoprire e mantenere un insieme limitato di peer diretti, scambiare messaggi di protocollo autenticati e costruire una propria vista locale senza instradare tutto attraverso un server centrale. Non è un grafo completo, un mempool globale o una fonte di verità autonoma. La ricezione, validazione o propagazione di un oggetto da parte di un peer non dimostra che tutti i nodi lo abbiano visto, che un blocco lo abbia incluso o che il consenso lo abbia finalizzato.
Dopo The Merge, Ethereum utilizza due reti P2P distinte. I client di esecuzione usano discovery, RLPx e la capability versionata `eth` per sincronizzazione e scambio delle transazioni. I client di consenso usano discv5 per la discovery e gossip libp2p più protocolli request-response per beacon block, attestations e altri oggetti di consenso. I due client si coordinano localmente tramite Engine API autenticata; una wallet invia comunemente tramite JSON-RPC e non diventa per questo un nodo gossip.
## Come funziona
1. Fissare chain, rete, configurazione di genesis e fork, versioni dei client di esecuzione e consenso, identità dei nodi e istante di osservazione. Rappresentare separatamente client di esecuzione, client di consenso, validator opzionale, Engine API locale e RPC rivolto all’utente.
2. Controllare ogni percorso di discovery: bootnode integrati, elenchi DNS, peer statici o fidati, identità ENR o enode, endpoint e sequenza annunciati, compatibilità di rete, NAT e raggiungibilità in ingresso. Un ENR firmato lega il record a una chiave; non prova onestà, sincronizzazione o raggiungibilità corrente.
3. Registrare separatamente connessione e negoziazione del protocollo. I peer di esecuzione stabiliscono sessioni RLPx e negoziano capability come `eth`; i peer di consenso negoziano trasporti libp2p, sicurezza e ID di protocollo dopo la discovery discv5. Trovare un endpoint non implica compatibilità applicativa.
4. Tracciare ogni oggetto lungo il percorso effettivo. Una transazione può passare dall’invio RPC alla validazione locale e al mempool di esecuzione, quindi agli annunci e alle richieste `eth`. Gli oggetti di consenso usano validazione gossip specifica per topic; i blocchi mancanti possono essere ottenuti tramite request-response.
5. Applicare decodifica limitata, deduplicazione, rate limit e controlli di firma, sintassi e stato prima dell’ammissione o propagazione locale. Registrare esiti non validi, ignorati, indisponibili e limitati dalle risorse; peer score e disconnessione sono decisioni locali dell’implementazione, non reputazione di consenso.
6. Mantenere ricezione, validazione, propagazione, inclusione della transazione, risultato dell’esecuzione, fork choice, giustificazione e finalità come stati e orologi separati. Confrontare diversi peer o nodi quando pool, head o risposta storica locale è incompleta, contraddittoria o obsoleta.
7. Monitorare diversità dei peer in entrata e uscita, operatore, concentrazione di prefissi IP e ASN, ricambio, latenza, perdita, banda, code, traffico non valido, salute dell’orologio e dipendenze RPC. Provare perdita dei bootnode, guasto NAT, partizione, eclipse, sovraccarico e ripristino senza dichiarare resistenza assoluta.
Peer discovery, sicurezza del trasporto e validità applicativa risolvono problemi diversi. I bootnode presentano candidati, ma non propagano il traffico ordinario né scelgono la chain canonica. La cifratura protegge contenuto e autenticazione della sessione, ma i peer conoscono endpoint e tempistiche; un provider RPC remoto può inoltre osservare richieste, indirizzi e transazioni inviate.
La propagazione è concorrente e dipende dalla topologia. Fanout, percorsi duplicati, serializzazione della banda, CPU di validazione, code, perdita, ritrasmissione, peer score e regole dell’oggetto determinano distribuzione e coda dei tempi di arrivo. Una formula come `delay = hops * perHopTime` è solo un modello didattico seriale dichiarato, non una garanzia della rete.
## Esempi
- **Percorso seriale rispetto a pipeline.** Su un percorso didattico di `4 hops`, ogni hop ha `80 ms` di rete e `20 ms` di validazione. L’elaborazione interamente seriale produce `4 * (80 + 20) = 400 ms`. Se la validazione si sovrappone alla trasmissione successiva, un limite inferiore semplificato è `4 * 80 + 20 = 340 ms`. Nessun valore è il tempo di propagazione dell’intera rete.
- **Annuncio e recupero delle transazioni.** Un nodo riceve `20` hash e ne possiede già `6`, quindi mancano `20 - 6 = 14` body. Se una richiesta didattica ne contiene al massimo `8`, servono `ceil(14 / 8) = 2 batches`. Con `120 ms` di andata e ritorno più `30 ms` di validazione per batch, il completamento seriale è `2 * (120 + 30) = 300 ms`; quello parallelo ideale `150 ms`. I limiti reali dipendono dalla versione `eth` negoziata e dal client.
- **Probabilità semplificata di eclipse.** Se ciascuno degli `8` peer in uscita fosse campionato indipendentemente e i candidati malevoli fossero `25%`, la probabilità che fossero tutti malevoli sarebbe `0.25^8 = 0.0000152587890625 = 0.00152587890625%`. Bias di discovery, identità Sybil, correlazione IP/ASN e mantenimento dei peer violano l’indipendenza; non è una garanzia di sicurezza.
- **Sovraccarico della validazione.** Il gossip in entrata è `900 messages/s`; `4` worker validano ciascuno `250 messages/s`, per capacità `1,000 messages/s`, margine `100 messages/s` e utilizzo `90%`. Un attacco a `1,400 messages/s` crea `400 messages/s` di accumulo e `6,000 messages` in `15 seconds`. Una coda da `5,000-message` si riempie in `5,000 / 400 = 12.5 seconds` prima di scarti o limitazione, ignorando la varianza del servizio.
## Rischi
- Chain, genesis o configurazione fork errati.
- Mancata corrispondenza tra client di esecuzione, consenso o Engine API.
- Discovery tramite bootnode o DNS concentrata o dirottata.
- Metadati dell’endpoint obsoleti, falsi o irraggiungibili.
- NAT, firewall o porte bloccano la raggiungibilità prevista.
- Attacco eclipse che filtra la vista locale del nodo.
- Identità Sybil e concentrazione di IP, ASN, operatore o cloud.
- Dipendenza eccessiva da peer statici o fidati.
- Censura delle transazioni o propagazione selettiva.
- Divergenza tra order flow pubblico e privato.
- Divergenza locale di ammissione, sostituzione ed espulsione dal mempool.
- Gossip non valido esaurisce la CPU di validazione.
- Richieste sovradimensionate, decompressione o esaurimento di banda, memoria o disco.
- Manipolazione del peer score o penalità false.
- Backpressure delle code scarta messaggi sensibili al tempo.
- Latenza, perdita o deriva dell’orologio causano divergenza temporanea dell’head.
- Incompatibilità di versione del protocollo o fork digest.
- Storico potato o risposta non disponibile per risorse interpretati come inesistenza.
- Perdita di privacy di IP, tempistiche, query e origine delle transazioni.
- RPC centralizzato o esposto consente tracciamento, viste obsolete, censura o compromissione.
## Idee errate comuni
- **Ogni nodo si collega direttamente a ogni altro nodo.** Ciascuno ha un insieme locale finito e variabile; nodi diversi possono vedere temporaneamente messaggi e head differenti.
- **Un bootnode è una fonte fidata di blocchi o un partecipante al consenso.** Il suo ruolo normale è presentare peer; validità della chain e fork choice sono verificate altrove.
- **Una transazione accettata da un peer è propagata globalmente e ha inclusione garantita.** Ammissione e propagazione sono locali; builder o proposer possono ometterla.
- **Validazione gossip significa consenso e finalità.** È un primo filtro locale; fork choice, giustificazione e finalità sono macchine a stati separate.
- **Più peer o trasporto cifrato offrono automaticamente anonimato e resistenza all’eclipse.** Diversità e selezione contano; peer e provider RPC possono ancora correlare endpoint, tempistiche e attività.
## Argomenti correlati
- [Full node](/it/crypto/full-node/)
- [Mempool](/it/crypto/mempool/)
- [Resistenza alla censura](/it/crypto/censorship-resistance/)
## Fonti
- [Networking layer](https://ethereum.org/developers/docs/networking-layer) - Ethereum.org (consultato il 2026-08-13)
- [Ethereum Wire Protocol (ETH)](https://github.com/ethereum/devp2p/blob/master/caps/eth.md) - Ethereum devp2p (consultato il 2026-08-13)
- [The RLPx Transport Protocol](https://github.com/ethereum/devp2p/blob/master/rlpx.md) - Ethereum devp2p (consultato il 2026-08-13)
- [Node Discovery Protocol v5 - Wire Protocol](https://github.com/ethereum/devp2p/blob/master/discv5/discv5-wire.md) - Ethereum devp2p (consultato il 2026-08-13)
- [Phase 0 -- Networking](https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/p2p-interface.md) - Ethereum Consensus Specs (consultato il 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 (consultato il 2026-08-13)
- [Connecting To The Network](https://geth.ethereum.org/docs/fundamentals/peer-to-peer) - go-ethereum (consultato il 2026-08-13)
- [Spin up your own Ethereum node](https://ethereum.org/developers/docs/nodes-and-clients/run-a-node/) - Ethereum.org (consultato il 2026-08-13)
Source: https://wiki.fcontext.com/it/crypto/peer-to-peer-network/index.mdx