Vai al contenuto
Financial Context Wiki

Rete peer-to-peer

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.

Aggiornato

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

Fonti

Navigazione

Cerca nella wiki...