Installi Bitcoin Core su un portatile e lo avvii per la prima volta. La rubrica degli indirizzi è vuota. Non c’è un account da aprire e nessun server aziendale da chiamare. blockchain that runs exactly as written when it is called, holding and moving funds according to its code, without an intermediary able to change the outcome.">smart contract holding reserves of two or more tokens, supplied by users, that a decentralized exchange uses to execute trades automatically at a price set by a formula.">pool diverge, compared with simply holding the same tokens in a wallet. It becomes permanent when the provider withdraws.">Il programma contiene sette nomi di dominio scritti nel suo codice sorgente (in inglese), ciascuno curato da un collaboratore con nome e cognome, e a partire da quelli arriva a 10 connessioni in uscita con macchine scelte da lui: 8 che rilanciano tutto e 2 che rilanciano solo i blocchi. Nessuno gliele ha assegnate. Questa è una rete peer to peer blockchain al lavoro, e il resto della lezione segue le tre domande che si pone ogni nuovo nodo: come trovare degli sconosciuti, come una notizia attraversa migliaia di macchine che non si fidano l’una dell’altra, e che cosa può fare un attaccante su quella strada.
La lezione precedente spiegava che cos’è un nodo e che cosa conserva. Qui il nodo si dà per noto, e così la catena che custodisce (come funziona una blockchain e che cosa contiene un blocco hanno ciascuna la propria lezione). Questa resta sui fili che collegano un nodo all’altro.
Cos’è una rete peer to peer e che cosa sostituisce
In un sistema client-server, l’app della tua banca parla con la banca. Il server custodisce i dati, decide chi può entrare e può essere spento da chi lo gestisce. È la differenza tra rete peer to peer e client server che chiunque cerchi la definizione trova nei manuali: in una rete peer to peer ogni macchina fa domande e dà risposte. Non esiste un indirizzo privilegiato, quindi non c’è un posto solo a cui bussare e non c’è un unico gestore da mettere offline o a cui dare ordini.
Due sistemi più vecchi mostrano perché i dettagli contano. Napster faceva passare i file musicali direttamente tra gli utenti ma, come descrisse la Corte d’appello del Nono Circuito nel febbraio 2001 (sentenza in inglese), un software sui suoi server teneva l’indice di chi possedeva che cosa, e quei server fornivano l’indirizzo internet dell’ospite. Quel pezzo centrale lo rendeva facile da fermare: una sentenza successiva registra che Napster disattivò i trasferimenti di file e che il tribunale di primo grado ordinò di tenerli spenti finché non fosse soddisfatto. BitTorrent andò oltre. I suoi tracker erano ancora centrali, così il BEP 5, di Andrew Loewenstern e Arvid Norberg, trasformò ogni partecipante in un piccolo tracker grazie a una tabella hash distribuita di tipo Kademlia: identificatori a 160 bit, distanza XOR, bucket da 8 nodi e quattro tipi di richiesta.
Il whitepaper di Bitcoin si era dato un compito più duro di entrambi: una «purely peer-to-peer version of electronic cash», cioè una versione di denaro elettronico puramente peer to peer (citazione in inglese). Condividere una canzone tollera un peer disonesto, perché nel peggiore dei casi si scarica un brutto file. Mettersi d’accordo su chi possiede che cosa no. Per questo un nodo controlla tutto ciò che riceve, ed è anche il motivo per cui il progetto descritto nel whitepaper chiede così poco alla rete in sé. Nella sezione 5 si legge che le trasmissioni di nuove transazioni non devono necessariamente raggiungere tutti i nodi. I messaggi possono arrivare in ritardo, andare persi o essere inviati da bugiardi, e il sistema deve reggere lo stesso.
Un limite alla parola «aperta»: questa lezione parla di catene pubbliche, a cui chiunque può unirsi. Le blockchain private hanno un elenco di membri approvati e saltano la maggior parte dei problemi che seguono, reintroducendo un gestore.
Come si trovano i nodi: il primo peer quando nessuno ti dà un elenco
Bitcoin: sette nomi DNS, un elenco fisso e una rubrica locale
Un nuovo nodo Bitcoin Core parte dal DNS. Nel codice attuale conosce sette seed, come seed.bitcoin.sprovoost.nl e dnsseed.emzy.de. Ne interroga tre alla volta, dopo un’attesa di 11 secondi quando conosce meno di 1.000 indirizzi, e ogni risposta è semplicemente un elenco di indirizzi di nodi. Se il DNS non dà nulla, dopo circa un minuto il programma ripiega su un elenco di indirizzi fissi compilato dentro la versione.
L’avvio, quindi, non è del tutto privo di fiducia, e il progetto lo dice nelle proprie regole. Chi gestisce un seed deve seguire una politica scritta: i risultati devono essere composti esclusivamente da nodi Bitcoin scelti in modo equo e funzionanti. Un seed disonesto potrebbe comunque consegnare al nuovo arrivato un elenco avvelenato, ed è uno dei motivi per cui il nodo interroga più seed, gestiti da persone diverse. Dopo il primo avvio i seed contano poco. Il nodo tiene una rubrica propria, chiamata addrman, e scopre nuovi indirizzi dai peer con i messaggi addr, fino a 1.000 per messaggio, elaborati a un ritmo limitato di 0,1 indirizzi al secondo per peer.
La rubrica ha due tabelle. La tabella «new» contiene gli indirizzi sentiti dire da altri: 1.024 bucket da 64 voci, cioè 65.536 posti. La tabella «tried» contiene gli indirizzi che il nodo ha davvero raggiunto: 256 bucket da 64, cioè 16.384 posti. In media ogni 2 minuti circa, una connessione breve detta feeler mette alla prova un indirizzo non verificato e lo sposta nell’altra tabella se risponde. Un nodo in ascolto annuncia inoltre il proprio indirizzo circa ogni 24 ore, così continua a essere riscoperto.
Ethereum: bootnode, tabella distribuita e record firmati
I client Ethereum arrivano con alcuni bootnode scritti nel codice, usati solo per presentare il nuovo arrivato agli altri. La pagina di ethereum.org sul livello di rete (in inglese) descrive due livelli dopo il Merge, ciascuno con la propria rete. I client di esecuzione fanno la scoperta via UDP, oggi con Discv4, una tabella di tipo Kademlia, mentre è in corso il passaggio a Discv5, e comunicano con devp2p (RLPx) su TCP. I client di consenso usano Discv5 con libp2p. Discv5 è, nella sua specifica, «loosely inspired by the Kademlia DHT», cioè liberamente ispirato alla DHT Kademlia, e conserva gli Ethereum Node Record: piccole schede firmate con un’identità, un numero di sequenza che sale a ogni modifica e dati chiave-valore come la rete del client e le sottoreti che segue.
La differenza con Bitcoin è di metodo. La rubrica di Bitcoin è un cumulo di passaparola, filtrato a tentativi. La scoperta di Ethereum è una ricerca strutturata: un nodo chiede peer sempre più vicini a un identificatore di destinazione, poi filtra in base a ciò che dice il record.
Solana: entrypoint e un calendario pubblicato
Solana ha meno bisogno della scoperta degli altri, per un aspetto. Un validatore Agave si avvia con uno o più indirizzi di ingresso (entrypoint) e riempie da lì la propria tabella di gossip, e l’ordine dei produttori di blocchi si calcola in anticipo: i nodi aggiornano il calendario dei leader a ogni confine di epoca, all’incirca ogni due giorni, secondo un’analisi di Helius (in inglese). Una macchina che sa chi produrrà i prossimi blocchi sa dove spedire le cose, e questo plasma tutto ciò che segue nella sezione sul gossip.
| Rete | Primo contatto | Scoperta continua | Trasporto |
|---|---|---|---|
| Bitcoin | 7 seed DNS, poi indirizzi fissi | Gossip addr, tabelle locali | TCP, porta 8333; v2 cifrato (BIP 324); Tor, I2P, CJDNS |
| Ethereum, livello di esecuzione | Bootnode scritti nel codice | Discv4 su UDP, in transizione verso Discv5 | devp2p (RLPx) su TCP |
| Ethereum, livello di consenso | Bootnode | Discv5 su UDP | libp2p: prima QUIC, poi anche TCP |
| Solana | Indirizzi di ingresso dati all’avvio | Tabella di gossip, più un calendario dei leader pubblicato | QUIC verso i leader; shred tramite Turbine |
Quanti vicini tiene un nodo, e chi sono
I numeri dei peer sembrano ordinaria amministrazione. Sono una scelta di sicurezza. Le connessioni in uscita, quelle scelte dal tuo nodo, sono le più preziose, perché un attaccante non può semplicemente chiamare e prenderle. Bitcoin Core le tiene poche e stabili: 8 a relay completo e 2 solo per blocchi, più qualche feeler occasionale e un ulteriore peer solo-blocchi provato in media ogni 5 minuti. I posti in uscita si riempiono da gruppi di rete diversi, così un piccolo intervallo di IP non può prenderseli tutti.
Il numero in evidenza è cambiato pochi giorni fa. Il limite totale predefinito è stato 125 per anni, e molte guide vecchie lo riportano ancora. Bitcoin Core 32.1, uscito il 28 ottobre 2026, afferma nelle sue note di rilascio (in inglese) che il valore predefinito «has increased from 125 to 200». Il tag 32.0 non fu mai rilasciato per intero, quindi la 32.1 è la prima versione pubblica con la modifica. Lo spazio in più è capacità in entrata per peer solo-blocchi, i peer che rilanciano transazioni possono occupare al massimo il 50% dei posti in entrata, e le connessioni automatiche in uscita restano come prima. Nello snapshot di Bitnodes del 2 novembre 2026, ore 09:01 UTC, dal conteggio degli user agent fatto sul file, 3.071 dei 18.526 nodi raggiungibili riportavano la versione 32 e gli altri software più vecchi o altri client: i due limiti sono quindi in uso sulla rete.
| Client (al 2 novembre 2026) | Valore predefinito | Nota |
|---|---|---|
| Bitcoin Core 32.1 | 200 connessioni; in uscita 8 a relay completo e 2 solo-blocchi | 125 fino alla versione 31; i valori oltre 2.000 vengono ridotti |
| Geth 1.17.10 | MaxPeers 50 | Rapporto di chiamata (dial ratio) pari a 3: circa un terzo dei peer è in uscita |
| Lighthouse 8.3.2 (client di consenso) | Obiettivo di 200 peer | Un’impostazione del client, non una regola del protocollo |
Sono valori predefiniti nel software. Nessun protocollo li impone, e chi gestisce un nodo può cambiarli.
Il gossip: come un blocco attraversa la rete
Bitcoin: annunciare, chiedere, consegnare
Lo schema di base usa tre messaggi. Un nodo che ha qualcosa di nuovo manda inv, un inventario di hash. Un peer a cui ne manca uno risponde con getdata. Solo allora il primo nodo invia i dati. Annunciare l’hash prima dei byte evita che la rete trasporti la stessa transazione molte volte su ogni collegamento. Il prezzo è un andata e ritorno per ogni salto, e nel 2013 Decker e Wattenhofer (in inglese) trovarono che quell’andata e ritorno dominava il ritardo per le transazioni, il 96% delle quali era allora sotto 1 kB.
Gli annunci delle transazioni vengono anche trattenuti di proposito. Nel codice attuale un nodo li raggruppa con ritardi casuali di 2 secondi in media verso i peer in uscita e di 5 verso quelli in entrata. Il ritardo costa tempo e compra riservatezza: offusca quale peer abbia sentito per primo. La versione 32.1 mantiene il limite predefinito di 14 transazioni al secondo, con un aumento di 2,5 volte per i peer in uscita, e aggiunge un tetto di 12 MB ogni 10 minuti.
Per i blocchi il trattamento è diverso. Il BIP 152, i compact block, si appoggia su un fatto: un peer ha già visto quasi tutte le transazioni di un nuovo blocco, nella sua mempool (una lezione successiva spiega la mempool). Il mittente spedisce quindi uno schizzo di identificatori brevi, e il destinatario ricostruisce il blocco e chiede soltanto ciò che manca. Le domande frequenti di Bitcoin Core del giugno 2016 indicavano una media di 9 kB per ricostruire un blocco da 1 MB. In modalità ad alta banda, un nodo chiede a pochi peer (al massimo tre, nel codice attuale) di spingergli i nuovi blocchi senza aspettare una richiesta.
Erlay prova a fare per le transazioni quello che i compact block hanno fatto per i blocchi, sostituendo la maggior parte degli annunci individuali con un confronto periodico degli insiemi di due peer. Una voce del 2025 elencata sulla pagina tematica di Bitcoin Optech dice che potrebbe far risparmiare «100 MB a day of node bandwidth, 20% of total bandwidth for some nodes», cioè 100 MB di banda al giorno, il 20% del totale per alcuni nodi (citazione in inglese). Non è stato rilasciato. Il BIP 330 resta una bozza. Nella versione 32.1 il codice esiste ma è spento di default, dietro un’opzione riservata al debug. Una discussione aperta nel febbraio 2026 chiede se valga la pena proseguire, ed era ancora aperta all’ultimo aggiornamento del 20 agosto 2026.
Ethereum: hash per le transazioni, gossipsub per i blocchi
Dopo il Merge la propagazione dei blocchi spetta al livello di consenso. La rete di esecuzione scambia soprattutto transazioni, con un’idea vicina a quella di Bitcoin: NewPooledTransactionHashes annuncia gli hash e i peer recuperano i corpi che non hanno.
Il livello di consenso usa gossipsub su libp2p, e la specifica ne dà i numeri. Ogni nodo tiene una maglia di circa 8 peer per argomento (tra 6 e 12) e manda metadati più leggeri ad altri 6, con un battito di 0,7 secondi. Gli argomenti dividono il traffico per tipo: beacon_block per i blocchi, beacon_aggregate_and_proof per i voti aggregati, 64 sottoreti di attestazione per i voti singoli e, dalla fork Fulu, 128 sottoreti per le colonne di dati. Un nodo non deve sentire tutto. Così il livello regge un insieme di validatori troppo grande perché ciascuno ascolti ciascuno.
Solana: un albero al posto della folla
Solana rinuncia al gossip per i dati dei blocchi. Il suo leader taglia il blocco in shred e li manda in Turbine, un albero ricostruito per ogni shred con un rimescolamento pesato sullo stake, così i validatori con più stake tendono a stare più vicino alla cima. Nel sorgente di Agave ogni nodo inoltra al massimo a 200 altri, e uno shred compie al massimo 4 salti. La codifica a cancellazione copre le perdite: con 32 shred di dati e 32 di codifica, l’esempio svolto della documentazione, che ipotizza una perdita di pacchetti del 15%, porta la riuscita del blocco a circa 0,99.
Turbine è ancora il progetto in vigore. La pagina di Anza su Alpenglow, datata 29 ottobre 2026, dice che il nuovo consenso è attivo su mainnet-beta, con 10/21 come tappa, e mette tra ciò che viene dopo Rotor, che sostituirebbe l’albero con un solo salto di relay. Non indica una data per Rotor.
Le transazioni prendono un’altra strada. Solana non ha una mempool pubblica nel senso di Bitcoin: i nodi RPC mandano una transazione via QUIC direttamente al leader attuale e a quelli successivi, noti dal calendario. Il servizio di invio delle transazioni di Agave inoltra di default a 2 leader e riprova ogni 2 secondi. Il nome di questo approccio, dai post dei fondatori del 2019, è Gulf Stream, anche se Helius ne ha trovata nel codice una sola menzione trascurabile: va letto come l’etichetta di un comportamento.
Perché la latenza è un parametro di sicurezza
Che cosa è stato misurato
Le misure sulla propagazione esistono, ma non condividono una sola definizione. La tabella le mette una accanto all’altra e non va letta come un’unica serie: le righe di Bitcoin misurano quando i nodi ricevono un blocco, mentre la riga di ethPandaOps misura la diffusione dopo che il primo sentinella l’ha visto.
| Studio | Rete | Mediana | Coda | Tasso di fork o orfani |
|---|---|---|---|---|
| Decker e Wattenhofer, 2013 | Bitcoin | 6,5 s (media 12,6 s) | 5% dei nodi ancora in attesa dopo 40 s | 1,69% osservato, 1,78% da modello |
| Fechner e altri, pubblicato nel 2022 | Bitcoin | 0,454 s (media circa 4,1 s) | 5% dei nodi oltre i 15,8 s | Da 0,014% a 0,127% su quattro catene |
| ethPandaOps, 25 aprile – 2 maggio 2026 | Ethereum | Da 104 ms (9 kB) a 348 ms (circa 238 kB) | p99 da 427 ms a 1.248 ms | Non misurato |
| Chainbound, novembre 2025 | Ethereum | Non indicata | Validazione del blocco con p99 pari o superiore alla scadenza di 4 s, per numero di blob | 584 slot su 216.000, 0,27% |
Il miglioramento di Bitcoin è grande. Nel 2013 il nodo mediano aspettava 6,5 secondi per un blocco. Nel lavoro di Fechner, Chandrasekaran e Makkes (in inglese) si legge: «The majority of peers in all four blockchains learn of a newly mined block within one second», cioè la maggioranza dei peer di tutte e quattro le blockchain viene a sapere di un blocco appena minato entro un secondo. Le loro riserve: un solo osservatore ad Amsterdam, solo IPv4, circa il 27% dei nodi Bitcoin raggiungibili. Tra i due studi sono arrivati i compact block, insieme ad altre modifiche al software.
Dal ritardo al blocco orfano
Il ritardo conta per quello che fanno i miner mentre aspettano. Due miner trovano blocchi validi quasi nello stesso istante, ciascuno manda il proprio, e per un po’ la rete ha due viste. I nodi continuano a lavorare sul primo ricevuto. Quando il blocco successivo arriva su uno dei due lati, vince la catena con più proof of work e i nodi dell’altro lato si riorganizzano. Il blocco perdente è «stale», cioè orfano: valido, ma non più parte della catena, e con lui se ne va la ricompensa del miner. Sono le riorganizzazioni di cui si legge, ed è il motivo per cui una conferma è una probabilità che cresce (perché i vecchi blocchi diventano difficili da modificare approfondisce).
Decker e Wattenhofer si proposero di verificare se il ritardo di propagazione sia la causa principale dei fork. Il loro modello prevedeva l’1,78% e osservarono l’1,69% su 10.000 blocchi a partire dall’altezza 180.000. Poi fecero girare un client modificato come hub, collegato in media a 3.048 nodi, con alcune modifiche al relay. Tra le altezze 200.000 e 210.000 il tasso di fork scese allo 0,78%.
Ethereum mostra la stessa causa con regole diverse. I suoi attestatori in proof of stake devono vedere un blocco entro una scadenza di 4 secondi dall’inizio dello slot, quindi un blocco in ritardo può perdere i suoi voti. Chainbound ha contato 584 blocchi orfani in 216.000 slot a novembre 2025, e il suo post mostra la validazione in coda che raggiunge quella scadenza. ethPandaOps, in un rapporto del 6 maggio 2026 su 50.318 blocchi, concludeva: «The 4-second attestation deadline is not at risk for any size band currently on mainnet», cioè la scadenza di 4 secondi non è a rischio per nessuna fascia di dimensione oggi sulla mainnet. I due risultati non sono in conflitto, perché uno guarda la validazione con i blob e l’altro la dispersione dopo il primo avvistamento.
Gli attacchi alla rete, non alla catena
Gli attacchi al consenso finiscono sulle prime pagine, e si può hackerare una blockchain li tratta. Quelli che seguono colpiscono un’altra cosa: ciò che un nodo riesce a sentire. Nessuno di loro può far accettare a un full node un blocco non valido, perché il nodo controlla da solo ogni regola.
Sybil: un solo attore, molte facce
John Douceur lo battezzò in un articolo del gennaio 2002 (in inglese): se una sola entità difettosa può presentare più identità, può controllare una frazione sostanziale del sistema (parafrasi dell’abstract). Mostrò anche che, senza un’autorità centrale, questi attacchi restano possibili a meno di ipotesi irrealistiche. Le blockchain accettano il risultato e mettono il costo dove serve: il peso di voto richiede potenza di calcolo o stake. Il livello di rete non ha un prezzo del genere. L’identità di un peer costa un indirizzo IP, quindi contare i nodi dimostra poco, e una maggioranza di nodi non significa nulla per il consenso.
Eclipse: circondare un solo nodo
Un attacco eclipse punta tutte le connessioni di una vittima verso l’attaccante. Heilman, Kendler, Zohar e Goldberg mostrarono nel 2015 che un avversario con abbastanza indirizzi IP poteva «monopolize all connections to and from a victim bitcoin node», cioè monopolizzare tutte le connessioni da e verso un nodo bitcoin vittima (citazione in inglese). Le loro cifre, per il software di allora: una botnet di 4.600 bot poteva eclissare una vittima con probabilità di almeno l’85% qualunque fosse la dimensione della rete, 32 blocchi /24 distinti (8.192 indirizzi) potevano fare lo stesso, e 400 bot bastavano contro i loro nodi attivi. Il trucco era riempire la rubrica di indirizzi dell’attaccante, aspettare il riavvio del nodo e prendersi ogni posto.
Che cosa ci guadagna l’attaccante? La vittima può essere privata dei blocchi, o vedere una versione valida ma non aggiornata della catena. Un commerciante che accetta pagamenti non confermati può subire una doppia spesa, perché la sua transazione non arriva a nessun altro (una lezione successiva tratta la doppia spesa). Se tra i nodi eclissati ci sono dei miner, il lavoro descrive gare tra blocchi, potenza di mining divisa, selfish mining più facile e doppie spese anche dopo N conferme.
Gli autori avvisarono gli sviluppatori di Bitcoin Core nel febbraio 2015, e tre delle loro contromisure arrivarono in bitcoind 0.10.1, tra cui quattro volte più bucket. Il codice successivo ne ha aggiunte altre: peer solo-blocchi, che rivelano meno della topologia del nodo perché non rilanciano indirizzi né transazioni; due peer di ancoraggio salvati allo spegnimento e provati per primi al riavvio; i feeler; e il file opzionale -asmap, che classifica i peer per operatore di rete invece che per intervallo di IP. I numeri del 2015 non valgono più per il software attuale.
Dirottamento BGP e partizione della rete
L’instradamento di internet poggia sulla fiducia tra gli operatori di rete, attraverso il Border Gateway Protocol. Apostolaki, Zohar e Vanbever misurarono che cosa questo significasse per Bitcoin in un lavoro del 2017. Sui dati del progetto del 2015 e 2016, 13 fornitori di accesso ospitavano il 30% della rete, e il 60% di tutte le connessioni possibili passava per 3 fornitori. Calcolarono che dirottare meno di 100 prefissi BGP poteva isolare fino al 47% della potenza di mining, ossia una partizione: due parti che continuano a minare separate, finché la parte con meno lavoro perde i propri blocchi alla riconnessione. Un attacco di ritardo più sottile, condotto da un attaccante sul percorso del traffico, poteva trattenere un blocco a una vittima per fino a 20 minuti senza interrompere la connessione.
Il lavoro è prudente su ciò che è stato dimostrato. Gli autori dirottarono solo i propri nodi sulla rete reale, dove tutto il traffico passò sulla rotta dell’attaccante entro 1,5 minuti. Provarono una divisione 50-50 su un banco di prova da 1.050 client, non su Bitcoin stesso, e le due parti si ricollegarono in fretta. Per l’internet reale esaminarono dati BGP da ottobre 2015 a marzo 2016: ogni mese veniva deviato il traffico di almeno 100 nodi Bitcoin, e a novembre 2015 di 447 nodi (circa il 7,8% della rete). È esposizione, non prova di un attacco a Bitcoin. Una nota a piè di pagina avverte che ogni dirottamento «may have been aimed at other services in the same IP range», cioè potrebbe essere stato rivolto ad altri servizi nello stesso intervallo di IP.
Un caso vicino mostra la stessa debolezza attorno alla catena. Il 24 aprile 2018 eNET (AS10297) annunciò rotte più specifiche per gli indirizzi Route 53 di Amazon per quasi due ore, da circa le 11:05 UTC. Il traffico raggiunse un server DNS malevolo a Chicago, e Cloudflare riferì che gli utenti di MyEtherWallet venivano mandati su una copia falsa del sito, che mostrava un certificato TLS firmato da un’autorità sconosciuta. Le vittime dovevano ignorare quell’avviso prima che le loro credenziali fossero rubate. Era DNS più BGP contro un sito web, e nessun livello peer to peer fu toccato.
| Attacco | Fonte | Risorsa | Effetto | Difese |
|---|---|---|---|---|
| Sybil | Douceur, 2002 | Molte identità | Quota sproporzionata di una vista | Voti costosi (lavoro, stake); diversità dei peer |
| Eclipse | Heilman e altri, 2015 | 4.600 bot o 32 blocchi /24 (software 2015) | La vittima vede solo l’attaccante | Tabelle più grandi, ancore, feeler, peer solo-blocchi, asmap |
| Partizione o ritardo BGP | Apostolaki e altri, 2017 | Meno di 100 prefissi dirottati | Rete divisa o rallentata | Connessioni diverse, traffico cifrato, proposte di relay come SABRE |
| DNS e BGP contro un’app | Internet Society, 2018 | Una rete che annuncia rotte false | Utenti mandati su un sito falso | Filtraggio delle rotte; dare retta agli avvisi sui certificati |
Che cosa cambiano Tor, I2P e la cifratura per la privacy
Una rete peer to peer non è anonima di per sé. Un nodo in chiaro mostra il proprio indirizzo IP a ciascun peer, e un peer che osserva i tempi può intuire quale nodo abbia inviato per primo una transazione. Le risposte di Bitcoin arrivano a strati.
Il trasporto cifrato, il BIP 324, è attivo di default da Bitcoin Core 27.0, nell’aprile 2024. Nasconde il contenuto a chi ascolta passivamente e costringe l’attaccante a diventare attivo. La sua cifratura non è autenticata per scelta di progetto, quindi non dimostra chi sia dall’altra parte.
Tor e I2P nascondono l’indirizzo IP stesso. Lo snapshot di Bitnodes del 2 novembre 2026 alle 09:01 UTC elenca 7.841 indirizzi onion e 4.624 indirizzi I2P, contro 5.453 su IPv4 e 601 su IPv6. Un indirizzo non è una macchina: un solo operatore può stare dietro a molti. CJDNS ne aveva 7, e le note della 32.1 dicono che il progetto sta valutando di eliminarlo.
Dandelion, la proposta di far passare una transazione lungo un percorso privato prima di diffonderla, non è mai arrivata in Bitcoin Core. Il BIP 156 ha lo stato Closed. Quello che è arrivato al suo posto, nella versione 31.0, è una modalità facoltativa -privatebroadcast per sendrawtransaction: invia ogni transazione su Tor o I2P, con una connessione per transazione, così i destinatari non ne conoscono l’origine e due transazioni non si possono collegare. È spenta di default, e la versione 32.1 ha corretto una possibile fuga dell’indirizzo di chi la origina.
Come si presenta oggi la rete
Quello snapshot dà 18.526 nodi raggiungibili in totale, al blocco 974.233, e la cifra ha bisogno delle sue avvertenze. Conta le macchine che accettano connessioni in entrata. I nodi dietro un router di casa o un firewall sono invisibili, e un solo operatore può gestire più indirizzi. Bitnodes stesso dice di essere in fase di ricostruzione indipendente sotto un nuovo gestore, e il suo conteggio è instabile: gli otto snapshot fino alle 09:01 UTC andavano da 18.526 a 18.899. Quindi 18.526 non è né il numero dei nodi né il numero delle parti indipendenti. Chainbound citava circa 20.000 nodi sulla mainnet di Ethereum per la fine del 2025.
L’ospitalità è l’altra lettura. Nello studio di Fechner Amazon ospitava il 7,7% dei nodi Bitcoin osservati, Google il 3,78%, Digital Ocean il 3,3% e OVH il 2,24%, e il 5,17% stava in reti di operatori statali. Quelle quote sono vecchie e riguardano una parte della rete, e lo studio stesso non considera significativa la quota di nessun singolo fornitore per Bitcoin. Restano comunque sullo stesso internet il cui instradamento la sezione sul BGP ha descritto.
Se gestisci un nodo, puoi ispezionare il tuo angolo di rete. Due comandi mostrano le connessioni per tipo e per rete, e il trasporto usato da ciascun peer.
bitcoin-cli -netinfo 4
bitcoin-cli getpeerinfoCerca il numero di connessioni in uscita e i campi connection_type e transport_protocol_type. La lezione sul nodo ha le note su hardware e sincronizzazione. Tre cose da seguire da qui in poi: quanti nodi passeranno al limite predefinito di 200 connessioni, se la discussione su Erlay si chiuderà con una decisione, e quando Anza darà una data a Rotor. Le note della 32.1 avvertono anche che le vecchie configurazioni I2P perderanno il supporto a ElGamal legacy entro la versione 34.
