Bitcoin Core 32.0 entra nella fase finale prima del rilascio previsto per il 10 ottobre

Bitcoin Core 32.0 è alla fine di un ciclo di sviluppo in cui le modifiche più visibili non sono necessariamente le più interessanti. La versione candidata è ora disponibile e gli sviluppatori puntano al 10 ottobre per la versione finale. Tra le novità: validazione meglio organizzata, server HTTP rivisitato e diversi correttivi di sicurezza. Un audit assistito da IA ha anche avviato una sequenza di test piuttosto istruttiva: la prima diagnosi non aveva ancora raccontato tutta la storia.

In breve

• Bitcoin Core 32.0 si avvicina al rilascio dopo diversi mesi di sviluppo, con una versione candidata ora sottoposta agli ultimi test dei collaboratori.
• La validazione dei blocchi evolve sotto il cofano grazie al caricamento parallelo di alcuni dati, particolarmente utile per gli operatori che gestiscono i propri nodi.
• Kimi K3 ha aiutato a individuare una vulnerabilità del server HTTP, prima che uno sviluppatore scoprisse che lo scenario poteva colpire un numero maggiore di connessioni.
• Il correttivo ha richiesto diversi aggiustamenti, poiché la sua prima versione proteggeva la memoria introducendo però una latenza fastidiosa su alcune connessioni persistenti.
• Per l'utente comune, il cambiamento rimarrà per lo più invisibile, mentre sviluppatori e operatori beneficeranno soprattutto di un'infrastruttura meglio protetta e più efficacemente organizzata.

Bitcoin Core 32.0 accelera soprattutto il lavoro sotto il cofano

Bitcoin Core consente a un computer di verificare autonomamente le transazioni e i blocchi della rete, senza dover delegare questo compito a un servizio esterno. La versione 32.0 riguarda quindi principalmente gli operatori di nodi, gli sviluppatori e i servizi costruiti attorno a questa infrastruttura.

Il cambiamento di prestazioni più significativo riguarda la validazione dei blocchi. Per verificare una transazione, il software deve in particolare trovare le uscite precedenti che essa spende, i famosi prevouts. Quando si trovano su disco, la loro lettura può rallentare il lavoro. La nuova versione consente di pre-caricare questi dati in parallelo dalla base chainstate.

Otto thread lavorano per impostazione predefinita, con un massimo fissato a sedici. Una macchina più modesta può ridurre questo numero a zero e disattivare il meccanismo.

Il guadagno non renderà la blockchain più veloce e non ridurrà l'intervallo tra due blocchi. Riguarda il lavoro svolto localmente dal nodo. Una sfumatura tecnica, certo discreta sullo schermo, ma piuttosto concreta per coloro che mantengono l'infrastruttura giorno dopo giorno.

Kimi K3 individua una falla, gli sviluppatori approfondiscono ulteriormente

La storia inizia con Matthew Zipkin, un collaboratore noto con lo pseudonimo pinheadmz. Auditando il nuovo server HTTP con Kimi K3, un modello di intelligenza artificiale utilizzato anche dal Bitcoin Red Team, si imbatte in uno scenario di esaurimento della memoria.

Il server poteva continuare a leggere i dati inviati da un cliente mentre stava già elaborando una richiesta. Un cliente malevolo aveva quindi la possibilità di mantenere questa richiesta occupata e inviare sempre più dati. Questi si accumulavano in memoria.

Zipkin pensava inizialmente che l'attacco richiedesse un'autenticazione. Poi la revisione del codice ha cambiato le carte in tavola. Lo sviluppatore jeanpablojp testa l'interfaccia REST e scopre che 16 connessioni senza credenziali possono far passare il consumo del nodo da circa 46 MB a quasi 3 GB in un minuto.

L'IA aveva quindi effettivamente individuato un problema. Non aveva chiuso l'indagine. Un umano ha spinto il test oltre e ha scoperto un vettore più ampio. Ecco una collaborazione uomo-macchina decisamente più interessante di una semplice competizione per vedere chi trova più bug.

Il primo correttivo rallentava troppo il server

La prima risposta di Zipkin seguiva una logica abbastanza sobria: quando una richiesta è già in fase di elaborazione, non è necessario continuare a raccogliere i dati successivi nella memoria dell'applicazione. Possono attendere sul lato del sistema fino a quando la pressione TCP frena naturalmente il mittente.

La soluzione di questa patch consiste nel non leggere nemmeno il socket quando siamo occupati a elaborare una richiesta.

Matthew Zipkin, GitHub PR #36123

Tuttavia, il primo patch aveva un difetto. Su una connessione persistente, jeanpablojp misura una latenza mediana che passa da circa 0,14 ms a 53 ms. La correzione proteggeva la memoria, ma faceva attendere inutilmente alcune richieste.

Nuova copia, nuovi test. Dopo revisione, 16 connessioni REST non autenticate aggiungono ora solo circa 3 MB in 90 secondi, contro 3,2 GB in precedenza. La penalità di circa 50 ms scompare anche.
Le tue prime criptovalute con Binance Questo link utilizza un programma di affiliazione

Non è tutto gratuito, però. Su un nodo inattivo sottoposto a un pipelining continuo, un revisore misura un throughput che passa da 383 a 18,9 richieste al secondo. Un caso molto specifico, che dice di non ritrovare in nessun cliente reale. La sicurezza guadagna quindi nettamente, con un compromesso misurato piuttosto che nascosto.

In ottobre, gli operatori troveranno soprattutto pulizie utili

La versione 32.0 non si riassume a questa storia di memoria. Diversi cambiamenti meno spettacolari arriveranno con essa se il calendario tiene. Quattro comandi legati alle transazioni parzialmente firmate utilizzeranno PSBT v2 per impostazione predefinita. Le applicazioni che ne hanno bisogno potranno ancora richiedere la versione precedente.

Il server HTTP, invece, è stato riscritto per sostituire libevent. Applica regole più severe e limita per impostazione predefinita a sedici il numero di clienti HTTP connessi contemporaneamente. Un'altra economia apprezzabile: dopo la ricostruzione, l'indice delle transazioni txindex occuperà meno della metà del suo precedente spazio su disco.

Dal lato del portafoglio, exportwatchonlywallet permetterà di esportare le informazioni necessarie per un portafoglio di osservazione senza portare con sé le chiavi private.

Un correttivo chiude anche la falla walletnotify. Su sistemi diversi da Windows, un utente RPC autenticato con i diritti richiesti poteva creare alcuni nomi di portafogli per provocare l'esecuzione di comandi. Questi nomi sono ora trattati letteralmente.

Per l'utente di un'applicazione leggera, nulla di tutto ciò sconvolge la giornata. Per coloro che gestiscono i nodi della blockchain, i dettagli contano di più.

Da ricordare prima del 10 ottobre

• L'uscita di Bitcoin Core 32.0 è prevista per il 10 ottobre 2026, una scadenza che rimane suscettibile di modifiche durante gli ultimi test della versione candidata.
• La validazione potrà pre-caricare alcuni dati con otto thread per impostazione predefinita e sedici al massimo, senza modificare la cadenza di produzione dei blocchi.
• Dopo la correzione, 16 connessioni REST non autenticate aggiungevano circa 3 MB di memoria in 90 secondi, contro 3,2 GB prima della revisione.
• Quattro comandi del portafoglio adotteranno PSBT v2 per impostazione predefinita, mentre le applicazioni manterranno la possibilità di richiedere la versione precedente.
• Un txindex completamente ricostruito occuperà meno della metà dello spazio su disco, mentre il nuovo server HTTP riceve diversi ulteriori salvaguardie.

Il calendario offre inoltre un bel incrocio. Mentre Bitcoin Core punta a ottobre, Ethereum sta preparando Glamsterdam, la prossima evoluzione importante della sua blockchain. Sepolia dovrebbe ospitare un test il 6 ottobre, se i bug ancora presenti sui devnets vengono corretti. Il mainnet è atteso nel quarto trimestre, con dicembre ancora possibile. Due cantieri diversi, un unico metodo: testare, rompere a volte, correggere molto, e poi solo consegnare.