Nessun codice è stato rimosso e non è stata presa alcuna decisione finale, ma le metriche di adozione persistentemente basse hanno spinto i contributori di Bitcoin Core a riconsiderare i compromessi pratici di sicurezza e ingegneria legati al mantenimento delle reti overlay legacy all'interno del client Bitcoin principale — un dibattito ormai incentrato sul fatto che la rete di routing crittografata CJDNS giustifichi ancora il proprio posto nell'implementazione di riferimento.

Sette nodi «buoni» innescano un audit infrastrutturale più ampio

La discussione tecnica è iniziata in una issue aperta su GitHub, dove gli sviluppatori si sono chiesti se Bitcoin Core debba continuare a supportare un livello di routing crittografato che registra quasi nessun traffico reale documentato. L'obiettivo principale dell'aggiunta di livelli di trasporto di rete alternativi a Bitcoin è la ridondanza: prevenire qualsiasi singolo punto di guasto o di censura a livello di rete. Le rotte ridondanti funzionano, tuttavia, solo se una mesh attiva di peer partecipa alla rete sottostante.

Durante i test automatici di una configurazione di nodo solo-CJDNS, lo sviluppatore di Core Marco Falke ha riferito che la sua istanza non riusciva a stabilire connessioni con più di tre o quattro peer distinti in un dato momento. A seguito di quell'osservazione, un altro contributor ha interrogato un database seeder di rete consolidato — i servizi di bootstrap che forniscono ai nodi appena avviati i loro primi indirizzi peer — contenente 25 indirizzi CJDNS noti. Dei 25 indirizzi testati, 22 hanno risposto agli handshake di base, ma solo sette soddisfacevano i criteri tecnici richiesti per essere classificati come peer «buoni» affidabili per la propagazione attiva di blocchi e transazioni.

Una singola interrogazione del seeder non rappresenta un censimento assoluto di ogni nodo operativo nell'intero ecosistema CJDNS; nodi privati non annunciati e peer non indicizzati possono ancora esistere al di fuori degli elenchi pubblici dei seeder. Anche così, i numeri sottolineano una seria realtà pratica: una rete overlay con meno di una dozzina di destinazioni di routing accessibili non fornisce la ridondanza operativa richiesta a un nodo di produzione resiliente. Per dare una scala di riferimento, i crawl pubblici di lunga durata hanno conteggiato nodi Bitcoin raggiungibili annunciati tramite Tor nell'ordine delle poche migliaia, contro i 25 indirizzi presenti nel seeder CJDNS.

Capire CJDNS: routing IPv6 crittografato contro regole di consenso

CJDNS è una rete overlay mesh IPv6 crittografata che utilizza la crittografia a chiave pubblica per l'allocazione degli indirizzi e il routing distribuito. Al di fuori di Bitcoin, il protocollo è noto soprattutto come livello di routing di Hyperboria, una rete mesh comunitaria gestita da volontari. Bitcoin Core ha aggiunto il supporto nativo a CJDNS nella versione 23.0 nel 2022, consentendo agli operatori di nodi di instradare il traffico peer su CJDNS insieme a IPv4, IPv6, Tor e I2P.

Secondo la documentazione di Bitcoin Core, CJDNS crittografa il traffico end-to-end e può rendere più difficile l'analisi e il filtraggio del traffico. Non è, tuttavia, una rete di anonimato nello stesso senso di Tor: i router CJDNS intermedi possono comunque vedere gli indirizzi crittografici di origine e di destinazione dei pacchetti che inoltrano.

La proposta riguarda solo il modo in cui Bitcoin Core trova e si connette ai peer. La rimozione del supporto CJDNS non modificherebbe la validazione dei blocchi, il mining, le regole di script o i formati delle transazioni; i nodi continuerebbero a far rispettare le stesse regole di consenso di Bitcoin.

Le dinamiche di sicurezza di un attacco eclipse

Nella sicurezza dei nodi Bitcoin, il trasporto di rete e la selezione dei peer sono direttamente legati all'integrità dei dati. La crittografia nasconde il contenuto dei pacchetti a terzi, ma non protegge un nodo dal ricevere informazioni false o ritardate se la sua selezione di peer è troppo ristretta. Pool di peer esigui minano la sicurezza rendendo drasticamente più facile per attori malintenzionati isolare e manipolare i nodi solo-CJDNS.

La minaccia principale per i nodi isolati è un attacco eclipse. In un attacco eclipse, un avversario compromette o controlla tutte le connessioni peer stabilite da un nodo bersaglio. Circondando completamente il nodo bersaglio, l'attaccante lo isola di fatto dalla rete Bitcoin globale legittima. Da questa posizione di vantaggio, l'attaccante può manipolare la visione della blockchain della vittima ritardando gli annunci dei blocchi, censurando specifiche transazioni in arrivo o tentando attacchi di double-spend contro transazioni non confermate.

Con il routing standard IPv4, IPv6 o Tor, Bitcoin Core mitiga gli attacchi eclipse stabilendo molteplici connessioni indipendenti tra netgroup e intervalli di rete diversificati; per impostazione predefinita il software mantiene aperte contemporaneamente otto connessioni full-relay in uscita. Quando un nodo opera esclusivamente su una rete con soli sette peer affidabili — meno di quelle slot in uscita predefinite — il pool totale di connessioni disponibili è decisamente troppo piccolo: un attaccante ha bisogno di pochissime risorse per monopolizzare tutte le connessioni in entrata e in uscita di un nodo solo-CJDNS, trasformando un meccanismo di ripiego di sicurezza previsto in un significativo punto unico di guasto.

Complessità del codice e ragioni a favore della deprecazione

Oltre alle basse cifre di adozione e alle preoccupazioni di sicurezza, gli sviluppatori favorevoli alla rimozione evidenziano l'onere di manutenzione continuo che il codice CJDNS impone sull'intero repository software di Bitcoin Core.

A differenza dei gestori di protocollo standard, l'integrazione CJDNS non è completamente isolata dalla logica di connessione IPv6 standard. Poiché CJDNS utilizza indirizzi IPv6 con formattazione speciale, la base di codice richiede logica di gestione personalizzata, argomenti di avvio dedicati come -cjdnsreachable e soluzioni specifiche per i casi limite. Nel tempo, gli sviluppatori hanno notato che questi percorsi di logica personalizzata introducono rischi di bug e complicano il refactoring routinario dello stack di rete. Anche il livello di trasporto è in fase di sviluppo attivo, con il trasporto crittografato v2 del BIP 324 reso disponibile come opzione nella versione 26.0 e abilitato per impostazione predefinita nella versione 27.0 — nuovo codice di connessione che arriva mentre i percorsi legacy come CJDNS vengono rivalutati.

Diversi contributori di Core hanno espresso un «Concept ACK» a favore della deprecazione del protocollo. Nella terminologia dello sviluppo open-source di Bitcoin Core, un «Concept ACK» indica che un contributor concorda con l'obiettivo generale di una proposta; non costituisce un voto finale, un merge di codice né un impegno immediato a rimuovere la funzionalità.

Le ragioni per una riserva di emergenza a lungo termine

Sull'altro lato della questione, gli sviluppatori che invitano alla prudenza sostengono che l'utilità di un nodo non debba essere giudicata esclusivamente in base alle metriche di traffico attuali. Il contributor Jon Atack ha fatto notare che la scoperta automatica dei peer CJDNS è stata integrata in Core solo all'inizio del 2025. Prima di quell'aggiornamento, gli operatori di nodi dovevano configurare manualmente gli indirizzi dei peer — un processo che creava una barriera all'ingresso significativa rispetto alle configurazioni con un clic disponibili per Tor o I2P.

I sostenitori sostengono che i numeri bassi di utilizzo di CJDNS derivino da una scarsa consapevolezza degli utenti e da un'integrazione limitata nelle diffuse distribuzioni software di nodi chiavi in mano, piuttosto che da una mancanza di valore sottostante. Se grandi reti pubbliche di anonimizzazione come Tor o I2P dovessero subire blocchi centralizzati, interruzioni dell'infrastruttura o filtraggi a livello di stato-nazione, protocolli mesh alternativi come CJDNS potrebbero fornire un canale di ripiego di emergenza vitale per mantenere le connessioni peer.

Atack si è anche offerto volontario per mantenere personalmente il codice di integrazione CJDNS, rispondendo alle preoccupazioni riguardo all'onere per gli sviluppatori. I contributori di Core devono ora decidere se preservare una rotta di trasporto alternativa per le emergenze nei casi limite o snellire la base di codice rimuovendo la logica di rete a basso utilizzo.

Cosa significherebbe un'eventuale rimozione per gli operatori di nodi

Se Bitcoin Core dovesse infine rimuovere l'integrazione nativa CJDNS in una versione futura, il software smetterà semplicemente di gestire internamente, a livello di applicazione, le connessioni peer CJDNS. La modifica non impedirebbe agli operatori di eseguire CJDNS esternamente a livello di sistema operativo, né altererebbe il modo in cui la più ampia rete Bitcoin elabora le transazioni.

Le rimozioni in Bitcoin Core seguono tipicamente un percorso lento e documentato — la deprecazione viene segnalata nelle note di rilascio e il codice viene eliminato solo in una versione principale successiva, secondo il ciclo di rilascio di circa sei mesi del progetto — quindi gli indicatori da osservare sono la discussione su GitHub, un'eventuale pull request formale di deprecazione e se la scoperta automatica dei peer aggiunta nel 2025 modifichi i numeri di adozione prima che i maintainer decidano.

Per la grande maggioranza degli operatori di nodi che si affidano a connessioni standard IPv4, IPv6, Tor o I2P, la rimozione di CJDNS passerebbe completamente inosservata. La discussione in corso riflette la rigorosa filosofia ingegneristica di Bitcoin Core: ogni riga di codice deve giustificare la propria esistenza attraverso una sicurezza comprovata e un'utilità attiva.

Questo articolo è fornito solo a scopo informativo e non costituisce un consiglio di investimento.

Fonte: Coindoo