Lo sviluppatore Anthony Towns ha presentato il 20 settembre sulla mailing list Bitcoin-Dev una bozza che propone un alias a un byte per i messaggi P2P del trasporto cifrato BIP324. Secondo la proposta, ogni nodo potrebbe scegliere da sé gli identificatori brevi dei messaggi che invia, risparmiando 12 byte a ogni invio di un messaggio con alias. BitcoinLive24 ricostruisce cosa cambia, e soprattutto quanto poco cambia oggi, sulla base della bozza, della discussione e della newsletter Bitcoin Optech di questa settimana.
BIP324 e alias a un byte: cosa propone Anthony Towns
Per il tipo di messaggio, la specifica del BIP324 (protocollo di trasporto cifrato di seconda generazione tra nodi, detto v2) prevede 1 byte oppure 13 byte: un identificatore da 1 a 255, oppure uno zero seguito da un nome ASCII di 12 byte.
La proposta aggiunge un nuovo messaggio, chiamato set324alias, con cui un nodo comunica al peer una serie di coppie «numero:nome del messaggio». Towns porta l’esempio di set324alias [98:messagea, 99:messageb]: dopo averlo inviato, il nodo può usare 98 o 99 al posto del nome completo, risparmiando 12 byte a ogni messaggio, come scrive nella mailing list.
Gli identificatori a un byte stanno in una tabella fissa: per aggiungere un nuovo messaggio serve un accordo globale, con il rischio di conflitti. La bozza di Towns, secondo il suo testo, vuole evitare questo coordinamento e rendere più semplici gli esperimenti a livello P2P.
Come funziona set324alias: regole della bozza
La bozza stabilisce che ogni alias sia un numero da 1 a 255 associato a un nome di messaggio lungo da 1 a 12 byte. Il supporto viene dichiarato con il messaggio feature del BIP434 (il BIP sulla negoziazione delle funzionalità tra peer, di cui Towns è autore), e solo ai peer che lo hanno annunciato si può inviare set324alias.
Le regole principali, secondo il testo della bozza, sono queste:
- il messaggio non può partire prima del
verack(la conferma dell’handshake) e dovrebbe essere inviato una sola volta per connessione, appena possibile; - ogni nodo definisce gli alias solo per i messaggi che invia, quindi due peer possono usare numeri diversi per lo stesso messaggio;
- gli alias vanno applicati subito e in ordine: se lo stesso numero compare due volte, vale l’ultima definizione;
- chi riceve deve continuare ad accettare anche il nome completo di 12 byte;
- i nodi che non implementano la funzione non ricevono mai il messaggio, quindi non sono toccati.
La bozza raccomanda inoltre di definire alias solo per i messaggi inviati più volte nella stessa connessione, e non per quelli che partono al massimo una volta.
Quanta banda si risparmia davvero: i numeri di Towns
Il risparmio dipende dai messaggi che passano sulla connessione. Peter Todd ha chiesto nella discussione che la bozza includa una stima della quota di banda risparmiata, e Towns ha risposto il 24 settembre nella mailing list con tre scenari, che Bitcoin Optech riassume con il dato dal 66% al 5%.
| Tipo di connessione | Risparmio di banda stimato |
|---|---|
| Connessione con soli messaggi molto piccoli (ping/pong) | fino al 66% |
| Connessione tipica, dominata da INV, GETDATA e TX | circa 5% |
| Nodo in modalità blocksonly, traffico di blocchi da circa 2 MB | circa 0,0006% |
| Messaggi che hanno già un identificatore a un byte | 0% |
Towns precisa nella mailing list che il risparmio è di 12 byte per messaggio e che, finché non si usano messaggi nuovi privi di un identificatore a un byte, il guadagno è nullo. Il valore dello 0,0006% quadra con il calcolo di 12 byte su un blocco da 2 MB (nostra verifica aritmetica). Bitcoin Optech ricorda anche che il vantaggio è zero fino a quando non vengono distribuiti nuovi messaggi senza un identificatore breve già assegnato.
Perché la proposta interessa chi sviluppa su Bitcoin
Il beneficio principale, secondo il testo della bozza, non è la banda ma la flessibilità: i nuovi messaggi P2P potrebbero essere sperimentati e distribuiti senza attendere una nuova voce nella tabella condivisa del BIP324. È un tema di infrastruttura più che di mercato, simile a quelli che BitcoinLive24 ha seguito sui nodi, come nel caso di Bitcoin Core 31.1 e la patch di sicurezza per i nodi o delle falle DoS sui nodi Lightning Eclair.
Il progetto è ancora allo stato di bozza. Il testo riporta «BIP: TBD» e un identificativo della funzione ancora da assegnare, mentre la sezione sull’implementazione di riferimento è segnata come da completare, con rinvio a un ramo di sviluppo personale di Towns su GitHub. Nelle fonti consultate non risultano né un numero BIP assegnato né l’integrazione in Bitcoin Core.
Cosa guardare nelle prossime settimane
Oggi mancano ancora il numero BIP e l’implementazione di riferimento completa, quindi il testo può cambiare. Chi usa un nodo non deve fare nulla: la funzione riguarda gli sviluppatori e, secondo la bozza, verrebbe usata solo tra peer che hanno dichiarato di supportarla.
Vuoi seguire in tempo reale le novità tecniche e di mercato su Bitcoin? Scarica l’app BitcoinLive24 e attiva le notifiche.
Domande frequenti su BIP324 e gli alias dei messaggi
Che cosa propone Anthony Towns per il BIP324?
Propone un nuovo messaggio, set324alias, con cui ogni nodo sceglie gli identificatori a un byte per i messaggi che invia, secondo la bozza pubblicata nella mailing list. Così si evita di aggiornare ogni volta la tabella condivisa.
Quanti byte si risparmiano per ogni messaggio?
Dodici byte per ogni messaggio con alias: la specifica del BIP324 prevede 13 byte per il nome completo contro 1 per l’identificatore breve. L’effetto sulla banda totale va da circa 0,0006% fino al 66%, a seconda del traffico, e resta 0% per i messaggi che hanno già un identificatore a un byte.
La funzione è già attiva sui nodi Bitcoin?
No. Nelle fonti consultate la proposta è una bozza senza numero BIP assegnato, e l’implementazione di riferimento risulta ancora da completare.
I nodi che non la supportano smettono di funzionare?
No. Secondo la bozza, il messaggio viene inviato solo ai peer che hanno dichiarato il supporto tramite il BIP434, e il nome completo di 12 byte resta sempre valido.
Dove si trova un riassunto della discussione?
Nella newsletter Bitcoin Optech del 9 ottobre, che inserisce la proposta tra le novità della settimana.
