Stellar Protocol 30, il 3 novembre il voto sulla testnet: smart account, firme post-quantum e nuovi indirizzi
Il 3 novembre 2026, alle 17:00 UTC, le 18:00 in Italia, i validatori della rete Stellar sono chiamati a votare l’attivazione sulla testnet di Bell, l’aggiornamento identificato come Protocol 30. La proposta introduce tre modifiche all’infrastruttura blockchain: indirizzi di contratto capaci di distinguere più clienti, strumenti per verificare firme crittografiche resistenti ai futuri computer quantistici e una gestione più precisa dei tempi di chiusura dei ledger.
Il calendario pubblicato dalla Stellar Development Foundation prevede una seconda votazione, questa volta sulla mainnet, il 23 novembre 2026 alle 17:00 UTC. Entrambe le date sono soggette a possibili modifiche e l’attivazione dipende dall’approvazione dei validatori. Al 2 novembre, quindi, Bell rimane un aggiornamento proposto, con il software già disponibile per gli operatori che devono preparare i propri sistemi.
L’aggiornamento Stellar Protocol 30 interessa soprattutto gli intermediari che gestiscono pagamenti e attività digitali per numerosi clienti. Exchange, piattaforme di custodia, operatori che consentono conversioni tra valute tradizionali e criptovalute e sviluppatori di smart contract sono i destinatari delle principali novità tecniche.
La preparazione è già iniziata. Stellar Core 30.0.0 è stato rilasciato in versione stabile il 16 ottobre, mentre ulteriori aggiornamenti per l’infrastruttura e gli SDK sono stati resi disponibili nella settimana successiva. La documentazione operativa, aggiornata il 23 ottobre, specifica quali componenti dovranno essere adeguati prima delle votazioni.
Un contratto per gestire più clienti: la novità degli indirizzi multiplexed
La modifica con le implicazioni più immediate per i servizi finanziari è descritta nella proposta tecnica CAP-84. Introduce gli indirizzi di contratto multiplexed, progettati per consentire a un unico smart contract di ricevere trasferimenti destinati a clienti differenti.
Stellar utilizza già un meccanismo simile per gli account tradizionali. Gli indirizzi multiplexed permettono di associare un identificativo a un conto principale, distinguendo i depositi dei singoli utenti senza dover creare necessariamente un account blockchain separato per ciascuno.
Questo sistema è particolarmente utile per gli exchange che ricevono fondi da migliaia di clienti e devono attribuire correttamente ogni pagamento.
Finora, però, gli smart account non disponevano di una funzionalità equivalente.
Uno smart account è un account governato dalla logica di uno smart contract, anziché esclusivamente da una coppia di chiavi crittografiche. Può applicare regole di autorizzazione personalizzate, richiedere più firme, utilizzare passkey o imporre specifiche condizioni di spesa.
La maggiore flessibilità comportava una difficoltà operativa: identificare i destinatari dei trasferimenti quando diversi clienti utilizzavano un medesimo contratto. Per ottenere una separazione attraverso gli indirizzi era necessario ricorrere a contratti distinti o adottare ulteriori meccanismi applicativi.
Con CAP-84, un indirizzo di contratto può incorporare un identificativo multiplexed a 64 bit. Il nuovo formato è riconoscibile dal prefisso W, distinto dagli indirizzi M già utilizzati per gli account multiplexed tradizionali.
Quando un token viene trasferito a uno di questi indirizzi, il contratto riceve il valore e l’identificativo del destinatario viene registrato nell’evento di trasferimento. Il sistema applicativo può quindi utilizzare quell’informazione per attribuire il pagamento al cliente corretto.
L’aggiornamento Stellar Protocol 30 punta così a rendere praticabile anche per gli smart account un modello di gestione centralizzata dei fondi già conosciuto dagli intermediari finanziari.
Un operatore di custodia potrebbe utilizzare un contratto condiviso per amministrare depositi riferiti a numerosi utenti, mantenendo la distinzione contabile attraverso gli identificativi associati ai trasferimenti.
Resta comunque necessario un sistema affidabile di riconciliazione tra registrazioni blockchain e posizioni dei clienti. Il nuovo indirizzo non sostituisce i controlli contabili, le procedure di sicurezza o gli obblighi normativi degli intermediari.
L’effettiva convenienza rispetto all’utilizzo di contratti separati dipenderà dall’architettura dei singoli servizi, dai costi operativi e dalle modalità con cui verranno implementate le nuove funzionalità.
Firme post-quantum, cosa cambia davvero per la sicurezza
La seconda modifica, CAP-87, riguarda la possibilità di verificare firme digitali basate sull’algoritmo ML-DSA all’interno degli smart contract Stellar.
L’algoritmo appartiene alla famiglia delle tecniche crittografiche post-quantum, sviluppate per resistere ad attacchi che potrebbero diventare praticabili con computer quantistici sufficientemente potenti.
Il National Institute of Standards and Technology statunitense ha standardizzato ML-DSA nell’agosto 2024 attraverso il documento FIPS 204. Lo standard definisce procedure per generare e verificare firme digitali utilizzando problemi matematici differenti da quelli su cui si fondano molte tecniche crittografiche attualmente diffuse.
L’interesse deriva dal possibile impatto dei futuri computer quantistici sulla crittografia a chiave pubblica. Algoritmi come Ed25519 si basano su problemi matematici considerati difficili per i computer convenzionali, ma potenzialmente vulnerabili a macchine quantistiche di grandi dimensioni.
Non esistono attualmente evidenze pubbliche di computer quantistici capaci di compromettere su larga scala queste firme. La migrazione crittografica, tuttavia, richiede preparazione, aggiornamenti software e verifiche di interoperabilità.
Con l’aggiornamento Stellar Protocol 30, gli sviluppatori potranno progettare smart account che richiedono una firma ML-DSA per autorizzare determinate operazioni.
La verifica viene eseguita attraverso funzionalità integrate in Stellar Core, evitando che ogni sviluppatore debba implementare autonomamente l’intero procedimento crittografico nel proprio contratto.
Questa scelta è rilevante anche dal punto di vista delle risorse computazionali. La verifica delle firme ML-DSA richiede infatti più lavoro rispetto a quella di una firma Ed25519. Un’implementazione nativa permette di gestire l’operazione attraverso una funzione condivisa, anziché riprodurre la logica crittografica nel codice dei diversi smart contract.
Per le piattaforme di custodia, la funzionalità potrebbe diventare un elemento di sistemi di autorizzazione costruiti per ridurre l’esposizione ai rischi quantistici futuri.
Bell non rende però l’intera rete Stellar resistente agli attacchi quantistici.
La distinzione è essenziale. CAP-87 introduce la verifica ML-DSA per le autorizzazioni gestite dagli smart contract, mentre le firme delle transazioni a livello di rete continuano a utilizzare Ed25519.
Un account tradizionale non acquisisce automaticamente protezione post-quantum per effetto dell’aggiornamento. L’eventuale introduzione di firmatari post-quantum nativi richiederà ulteriori modifiche del protocollo.
Anche l’adozione delle nuove funzioni da parte di wallet e custodi richiederà un lavoro specifico: gestione delle chiavi, procedure di recupero, controlli sulle autorizzazioni e compatibilità con i dispositivi utilizzati dagli utenti.
La disponibilità della verifica crittografica è quindi un prerequisito tecnico, non la dimostrazione che i servizi operativi siano già migrati verso sistemi di sicurezza post-quantum.
Ledger con precisione al millisecondo, ma senza accelerazione immediata
La terza proposta, CAP-88, modifica il modo in cui Stellar rappresenta il tempo di chiusura dei ledger.
Un ledger contiene lo stato della rete risultante dall’elaborazione e dalla conferma delle operazioni. Il suo tempo di chiusura costituisce un riferimento fondamentale per stabilire quando determinati aggiornamenti sono stati registrati.
Con Protocol 28, denominato Adapter e introdotto sulla mainnet nel settembre 2026, Stellar aveva già ridotto il tempo di chiusura da circa 5,7 a 5 secondi.
L’attuale rappresentazione temporale, tuttavia, utilizza una precisione espressa in secondi interi. Questa struttura limita le possibilità di adottare in futuro intervalli di chiusura più brevi e una misurazione temporale più granulare.
CAP-88 introduce una rappresentazione con precisione al millisecondo, modificando alcuni elementi dei dati utilizzati dal protocollo.
L’aggiornamento Stellar Protocol 30 non determina automaticamente una riduzione dei tempi di chiusura sotto gli attuali cinque secondi. Rimuove invece un vincolo tecnico che avrebbe ostacolato successivi interventi sulle prestazioni della rete.
La differenza tra predisporre l’infrastruttura e ottenere un risultato misurabile è significativa.
Ridurre ulteriormente gli intervalli di chiusura richiede valutazioni sulla propagazione delle informazioni tra nodi, sulla capacità di elaborazione delle transazioni e sulla stabilità del consenso.
I benefici potenziali interessano soprattutto le applicazioni che richiedono conferme rapide e frequenti, come determinati servizi di pagamento o sistemi di regolamento automatizzato.
Per il momento, però, non sarebbe corretto attribuire a Bell un aumento già conseguito della velocità delle transazioni.
La modifica introduce inoltre conseguenze operative immediate: cambiano alcuni tipi di dati presenti negli header dei ledger, rendendo necessario aggiornare i software che li interpretano.
Il campo tradizionale closeTime continuerà a esprimere il tempo in secondi interi, ma la nuova struttura del protocollo potrà rappresentare informazioni temporali con precisione superiore. I programmi che assumono differenze di almeno un secondo tra ledger consecutivi dovranno verificare le proprie logiche.
SDK, validatori e indicizzazione: gli aggiornamenti necessari prima del voto
L’adeguamento dei software costituisce uno dei passaggi più delicati dell’intera procedura.
La guida della Stellar Development Foundation indica che gli operatori che utilizzano gli SDK ufficiali devono installare versioni compatibili con Protocol 30 prima delle rispettive votazioni: il 3 novembre per gli ambienti testnet e il 23 novembre per quelli mainnet.
Non si tratta di un aggiornamento puramente facoltativo.
Le modifiche al formato dei dati possono impedire alle versioni precedenti degli SDK di interpretare correttamente i ledger prodotti dopo l’attivazione del nuovo protocollo.
La compatibilità coinvolge due ambiti distinti.
Il primo riguarda gli indirizzi W introdotti da CAP-84. Wallet, exchange e piattaforme di pagamento devono verificare che i propri sistemi siano in grado di riconoscerli, validarli, mostrarli e conservarli correttamente.
La disponibilità di un SDK aggiornato non risolve automaticamente eventuali limitazioni presenti nel codice applicativo. Un programma che accetta soltanto le tipologie di indirizzo precedenti potrebbe continuare a rifiutare i nuovi indirizzi multiplexed.
Il secondo ambito riguarda la decodifica dei dati blockchain.
Stellar utilizza il formato XDR per rappresentare e serializzare diverse strutture del protocollo. Con CAP-88 vengono introdotti nuovi tipi di valore negli header dei ledger, che i decoder costruiti sulle definizioni precedenti potrebbero non riconoscere.
I sistemi di indicizzazione, gli explorer e le piattaforme di analisi che leggono direttamente i dati devono quindi aggiornare le proprie definizioni XDR.
La prescrizione coinvolge anche le infrastrutture che utilizzano strumenti come Galexie e i servizi che alimentano database esterni attraverso flussi di dati blockchain.
Il rischio concreto, in assenza di adeguamento, è l’interruzione della decodifica dei ledger successivi all’aggiornamento. Per un exchange o un servizio di custodia, questo può compromettere la corretta elaborazione dei movimenti nei sistemi interni.
Gli operatori dei validatori devono invece installare Stellar Core 30.0.0. La procedura di predisposizione al voto sulla mainnet verrà comunicata attraverso i canali riservati ai validatori.
Anche i componenti infrastrutturali, tra cui Horizon e RPC, richiedono l’utilizzo delle versioni predisposte per il nuovo protocollo.
Gli smart contract già esistenti non devono necessariamente essere riscritti. Le nuove funzionalità di CAP-84 e CAP-87 sono adottabili dai progetti che intendono utilizzarle, mentre i contratti esistenti possono continuare a funzionare.
Gli sviluppatori che ricompilano i contratti per accedere alle nuove API dovranno però utilizzare versioni compatibili di Soroban SDK e Stellar CLI.
Particolare attenzione richiedono i contratti che accettano indirizzi come parametri: il tipo tradizionale Address non accetta automaticamente i nuovi indirizzi W. Il supporto deve essere previsto utilizzando le strutture appropriate.
Per gli intermediari finanziari la sfida è integrare le nuove funzioni
Le possibilità offerte da Bell devono essere valutate rispetto ai processi effettivamente utilizzati dagli operatori.
Un exchange che gestisce depositi su account multiplexed tradizionali non è obbligato a trasferire immediatamente la propria infrastruttura su smart account. Può continuare a utilizzare il modello esistente e considerare le nuove funzionalità in un successivo sviluppo.
Un servizio di custodia che impiega già smart contract per controllare le autorizzazioni potrebbe invece essere interessato alla combinazione tra indirizzi multiplexed e verifica delle firme ML-DSA.
Questa combinazione apre la possibilità di gestire numerosi rapporti attraverso contratti condivisi, introducendo al tempo stesso politiche crittografiche personalizzate per le operazioni autorizzate.
Le due funzioni rimangono comunque indipendenti e richiedono decisioni progettuali specifiche. Il supporto agli indirizzi multiplexed non comporta l’utilizzo automatico delle firme post-quantum.
Lo stesso vale per la precisione temporale dei ledger, che rappresenta un cambiamento infrastrutturale separato dagli strumenti di gestione degli account.
L’aggiornamento Stellar Protocol 30 si distingue quindi dalle modifiche orientate principalmente all’esecuzione degli smart contract o alla capacità elaborativa delle blockchain.
La proposta Bell interviene contemporaneamente sulla gestione degli indirizzi, sulle primitive crittografiche disponibili e sul formato temporale dei dati della rete. È una traiettoria tecnica differente rispetto a quella dell’aggiornamento Glamsterdam previsto nell’ecosistema Ethereum, legato a interventi specifici sull’infrastruttura e sull’esecuzione del protocollo Ethereum.
Non esiste una corrispondenza diretta tra i due aggiornamenti e non sarebbe corretto confrontarli utilizzando un unico indicatore di prestazioni.
Nel caso Stellar, la misura concreta dei risultati sarà soprattutto l’adozione delle nuove capacità da parte degli intermediari e la compatibilità dei sistemi dopo la transizione.
Il calendario di novembre e le condizioni per l’attivazione
Il primo appuntamento operativo è il 3 novembre 2026 alle 17:00 UTC, quando è programmata la votazione sulla testnet.
La rete di prova permette agli sviluppatori e agli operatori di verificare il comportamento delle applicazioni in presenza delle modifiche previste dal protocollo, prima della possibile introduzione sulla rete principale.
Il successivo voto sulla mainnet è fissato al 23 novembre 2026, sempre alle 17:00 UTC, corrispondenti alle 18:00 italiane.
L’approvazione dei validatori costituisce la condizione necessaria per l’attivazione nei rispettivi ambienti. Il calendario rimane suscettibile di variazioni e l’esito della procedura non può essere anticipato.
La disponibilità delle versioni software non equivale pertanto all’entrata in vigore di Bell.
La Stellar Development Foundation ha organizzato il coordinamento tecnico attraverso la documentazione dedicata e i canali della comunità degli sviluppatori, dove vengono condivise le informazioni sugli aggiornamenti e sulle procedure operative.
Per gli exchange, i fornitori di wallet e i gestori dei sistemi di indicizzazione, il passaggio più urgente rimane la verifica della compatibilità prima dell’attivazione della mainnet.
Il 23 novembre rappresenta così una scadenza tecnica precisa: gli operatori dovranno essere pronti a interpretare i nuovi dati dei ledger e a gestire gli indirizzi W qualora i validatori approvino il protocollo.
Le applicazioni più avanzate degli smart account e delle firme post-quantum potranno invece essere sviluppate progressivamente, senza che l’attivazione del protocollo comporti la loro adozione automatica da parte dei servizi già operativi.
