Gli sviluppatori che curano 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 codice di consenso del nodo Cardano hanno unito al ramo principale, il 9 ottobre 2026, il nucleo di Ouroboros Leios, l’aggiornamento di throughput noto come Cardano Leios. La modifica è arrivata con la pull request n. 2386 del repository IntersectMBO/ouroboros-consensus, che introduce un protocollo chiamato Praos2, definito nel titolo «Praos più il livello sovrapposto di Leios». Il rapporto settimanale del team di consenso del 23 ottobre ha confermato l’unione e ha aggiunto che due componenti di rete l’hanno seguita nel ramo principale.
Il codice è un passo avanti concreto. Il numero che gli viene attaccato, invece, non è un risultato. CryptoSlate, che ha raccontato la novità il 26 ottobre, ha messo nel titolo una «svolta di scalabilità 15x», ma il 15x è il limite alto di un intervallo condizionato pubblicato da Input Output (IOG): Leios dovrebbe partire da tre-cinque volte la capacità attuale e arrivare a circa 10-15 volte solo dopo almeno due successivi aggiornamenti dei parametri, ciascuno deciso con un voto di governance. Nessuna di queste tappe ha una data, e un pezzo del software, la selezione degli endorser block, non è ancora stato scritto.
La mainnet di Cardano (ADA) funziona ancora con il semplice Praos. Tra il codice unito e una catena più veloce restano una testnet che non ha ancora adottato le nuove regole, un emendamento costituzionale in bozza, il voto sull’hard fork, la registrazione delle chiavi da parte di diverse centinaia di stake pool e almeno altri due voti sui parametri.
Codice di Cardano Leios: cosa è stato unito il 9 ottobre
La pull request n. 2386 è stata aperta dall’utente GitHub nfrisby e approvata dai revisori ch1bo e jasagredo, prima di essere unita come commit 35d0289. ch1bo aveva chiesto in un primo momento delle modifiche. La richiesta era stata scritta come alternativa a una precedente, la n. 2354, che nella discussione ch1bo dice di chiudere. In pratica Praos2 è il protocollo Ouroboros Praos, quello che oggi produce i blocchi di Cardano, con uno strato aggiuntivo che permette alla catena di trasportare molti più dati di transazione.
Nelle due settimane successive sono arrivate altre unioni, più piccole, sullo stesso repository:
- n. 2400, «Leios: integrate latest changes for 2026w41», unita l’11 ottobre.
- n. 2415, che impedisce a Praos2 di certificare a cavallo di due epoche, unita il 16 ottobre.
- n. 2278, che adegua la specifica formale a Linear Leios, il progetto attuale, unita il 20 ottobre.
Una quarta unione, la n. 2427 del 21 ottobre, aggiunge una vista del ledger per Peras, un progetto separato per una finalità più rapida. Su GitHub porta l’etichetta Peras, non Leios, e non va contata come avanzamento di Leios.
I componenti di rete nel ramo principale al 23 ottobre
Il rapporto settimanale di sviluppo del 23 ottobre, pubblicato su Essential Cardano, scrive che Praos2 «had merged into main» e che anche i client LeiosNotify e i server LeiosFetch sono passati nel ramo principale. Sono le due metà del meccanismo con cui i nodi si segnalano che esistono nuovi dati Leios e poi li scaricano. Il rapporto aggiunge che il prototipo applica ora controlli più severi su ciò che i peer annunciano e sui certificati che inviano, avvicinando il modo in cui gli endorser block si diffondono in rete al disegno pensato per la produzione.
Due dettagli del rapporto contano per chi segue una rete di prova. Il prototipo usa il formato di intestazione di Leios solo a partire dall’era Dijkstra, nome della prossima era e del prossimo hard fork di Cardano. E la testnet prototipo di Leios va riavviata dal blocco genesi, con gli operatori dei nodi che aggiornano il software. La mainnet, precisa il rapporto, non è toccata da questo riavvio. Nella stessa settimana il team ha rilasciato la versione 5.1.0.1 di ouroboros-consensus.
Manca la selezione degli endorser block
Il rapporto è altrettanto chiaro su ciò che non è finito. La voce successiva in elenco è la selezione e il recupero degli endorser block. È il cuore dello schema: in Leios i blocchi ordinari che gli stake pool producono circa ogni 20 secondi possono puntare a endorser block, che elencano transazioni aggiuntive (per riferimento, non le transazioni stesse, spiega IOG), una volta che i pool con almeno il 75% dello stake attivo hanno votato per certificarli. Un nodo che non sa ancora scegliere quale endorser block scaricare, né recuperarlo, non esegue Leios da un capo all’altro.
A fine ottobre, dunque, il guscio del protocollo è unito, i componenti di messaggistica sono dentro e la specifica formale si è allineata al disegno di Linear Leios. La logica che decide quali blocchi extra un nodo accetta davvero è il lavoro che resta, e il rapporto settimanale non indica una data obiettivo.
Da dove arriva il 15x
I numeri vengono da IOG stessa. In un articolo del 20 ottobre, «Leios is coming: How it reaches Cardano mainnet», Ivan Irakoze, Ecosystem Communications Lead di Input Output, indica il tetto attuale di Praos in circa 4,5 kilobyte di transazioni al secondo (TxkB/s). L’obiettivo iniziale di Leios è da tre a cinque volte tanto. Dopo almeno due successivi aggiornamenti dei parametri, scrive il post, il throughput potrebbe arrivare a circa 10-15 volte.
L’avvertenza di IOG è netta: «The hard fork is the beginning of the rollout, not the point when Cardano suddenly runs at full Leios capacity», cioè l’hard fork è l’inizio del rilascio, non il momento in cui Cardano funziona di colpo a piena capacità Leios.
Lo stesso articolo cita una stima di CIP-164, la proposta di miglioramento di Cardano che definisce Linear Leios: perché i ricavi da commissioni arrivino al pareggio servirebbe un traffico sostenuto di circa 50-70 TxkB/s, che IOG descrive come più di dieci volte ciò che Praos può trasportare oggi. CIP-164 afferma anche, in transazioni al secondo e non in kilobyte, che la redditività degli stake pool migliora nettamente quando il throughput sostenuto supera 30-50 TPS. Le due unità misurano cose diverse e non si convertono senza conoscere la dimensione media di una transazione, quindi le teniamo separate.
La tabella qui sotto traduce in kilobyte al secondo i multipli di IOG. L’aritmetica è nostra (4,5 moltiplicato per ogni multiplo, e 50-70 diviso 4,5 per l’ultima riga); i multipli, la base di 4,5 TxkB/s e la fascia di 50-70 TxkB/s sono di IOG.
| Fase (IOG, 20 ottobre 2026) | Multiplo di Praos | Throughput approssimativo (TxkB/s) |
|---|---|---|
| Praos oggi | 1x | 4,5 |
| Leios all’attivazione (obiettivo iniziale) | 3-5x | 13,5-22,5 (calcolo nostro) |
| Dopo almeno due aggiornamenti dei parametri | 10-15x | 45-67,5 (calcolo nostro) |
| Traffico che secondo CIP-164 serve ai ricavi da commissioni per il pareggio | circa 11-16x (calcolo nostro) | 50-70 |
Letta così, la tappa del 10x (45 TxkB/s) resta sotto la fascia di pareggio, e solo il vertice dell’intervallo di IOG, 67,5 TxkB/s, cade al suo interno. Va detto che l’intervallo descrive una capacità, non la domanda: una catena in grado di trasportare 15 volte più dati deve anche essere usata altrettanto perché il ragionamento sulle commissioni regga.
Un articolo precedente di IOG, del 17 aprile 2025, partiva da una base leggermente diversa, circa 4,4 kB/s, e sosteneva che le simulazioni indicavano la possibilità di superare i 1.000 TPS grazie all’elaborazione parallela nel nodo. Era il risultato di una simulazione, non una misura sulla mainnet, e non è la cifra che IOG propone oggi per il rilascio.
Cos’è Cardano Leios, in breve
Leios cambia quanto può trasportare la catena base di Cardano, non il luogo in cui vanno le transazioni. È una modifica al layer 1 stesso, a differenza di rollup e canali di pagamento che spostano l’attività fuori dalla catena principale (la nostra guida su la differenza tra layer 1 e layer 2 spiega entrambi gli approcci). Cardano mantiene i suoi produttori di blocchi in proof of stake e il ritmo di circa 20 secondi per i blocchi di ranking; Leios aggiunge gli endorser block, che rimandano alle transazioni extra, e i voti degli stake pool che li certificano.
CIP-164, «Ouroboros Linear Leios – Greater transaction throughput», è stata creata il 7 marzo 2025 e nel repository delle CIP ha ancora lo stato Proposed. Tra gli autori figurano William Wolff, Brian W Bush, Sebastian Nagel e Nicolas Frisby, e come implementatore è indicata Input Output Engineering. Il testo esplicativo di IOG del 2025 diceva che il disegno mantiene la resistenza fino al 50% di stake avversario.
Cardano Leios: roadmap in sei tappe dal codice unito alla mainnet
L’articolo di IOG del 20 ottobre e il weekly update 134 di Intersect del 24 ottobre descrivono insieme il percorso. Nessuna delle tappe che seguono ha una data di calendario.
1. Una testnet Dijkstra che non usa ancora le regole Dijkstra
Intersect ha riavviato la testnet pubblica Dijkstra il 21 ottobre. Gira ancora con la versione di protocollo 11, l’attuale era Conway, sul nodo 11.1.3. Una azione di avvio dell’hard fork verso la versione di protocollo 12, Dijkstra, sarà presentata quando sarà disponibile una pre-release del nodo 11.2. La testnet usa epoche di un giorno, ha l’explorer Kleioscan ed è già aperta agli operatori di stake pool. Le regole Dijkstra vere e proprie non sono ancora in prova.
2. Il resto del codice di Leios
Selezione e recupero degli endorser block, come detto sopra, sono incompleti secondo il rapporto del 23 ottobre.
3. CAP-12, l’emendamento costituzionale, alla quarta bozza
CAP-12 scriverebbe nella costituzione di Cardano gli intervalli ammessi per i parametri dell’era Dijkstra. Il 19 ottobre il presidente del Technical Steering Committee ha pubblicato sette commenti a nome del Parameter Committee. Secondo Intersect, ha sostenuto che l’interruttore di spegnimento di Leios venga descritto come una disattivazione ordinata e non di emergenza, ha chiesto una procedura rapida scritta per i veri incidenti di gravità 1 o 2, ha trasmesso il consiglio di spostare i parametri di Peras in un emendamento a parte e ha sostituito il precedente tetto a quanto il pledge leverage può muoversi in un passo con un limite alla frequenza con cui può cambiare.
L’autore ha pubblicato una quarta bozza due giorni dopo. Peras ne è uscita e ora elenca le cinque disposizioni costituzionali che modifica. Restano aperti, dice Intersect, l’intervallo del pledge leverage, i numeri segnaposto, una breve descrizione dell’interruttore e la questione se CIP-23 arrivi nella prima o nella seconda fase di Dijkstra. La revisione degli editor ha trovato anche un errore di copia: una nuova salvaguardia della procedura rapida agganciata al parametro sbagliato. Cambiare la costituzione richiede il 75% dello stake dei DRep e due terzi del Constitutional Committee; gli stake pool non votano, secondo la tabella di IOG.
4. Il voto sull’hard fork
L’hard fork Dijkstra richiede il 60% dello stake dei DRep, il 51% dello stake dei pool e due terzi del comitato, afferma IOG. Leios non viaggerebbe da solo: IOG elenca nello stesso pacchetto le transazioni annidate, i miglioramenti degli account, i guard script, Plutus V4, le ricompense di staking prelevabili liberamente e un parametro di pledge leverage. Né IOG né Intersect indicano una data per il fork.
5. Chiavi BLS dal 90-95% dello stake
Dopo il fork, ogni operatore di stake pool deve generare una chiave BLS e inviare un certificato di registrazione del pool aggiornato che la contenga; la chiave diventa attiva al successivo confine di epoca. Non c’è alcun voto, e IOG dice che i pool ruoteranno queste chiavi circa ogni trimestre, con lo stesso ritmo delle chiavi KES. Nelle parole di IOG: «Leios needs roughly 90 to 95% of the stake registered before it switches on», ovvero Leios ha bisogno che si sia registrato circa il 90-95% dello stake prima di accendersi. Intersect lo traduce in circa i primi 500-900 pool su circa 2.700. Un certificato Leios richiede poi i voti del 75% dello stake attivo. I pool senza chiave continuano a produrre blocchi Praos ordinari ma non possono votare sugli endorser block.
6. Test di carico, poi due voti sui parametri
IOG prevede esercitazioni di carico sulla mainnet prima di alzare il throughput: picchi di traffico programmati, abbastanza grandi da far traboccare i blocchi ordinari, in modo che endorser block, voti e certificati vengano prodotti e cronometrati sulla rete reale. Non serve alcun voto. Seguono almeno due aggiornamenti dei parametri, ciascuno con il 67% dello stake dei DRep, il 51% dello stake dei pool e due terzi del comitato. Finché i nuovi valori restano entro i limiti fissati dalla costituzione, non occorre un altro hard fork. È la fase in cui l’intervallo da 10 a 15 volte potrebbe essere raggiunto.
| Decisione | Stake dei DRep | Stake dei pool | Constitutional Committee |
|---|---|---|---|
| Aggiornamento della costituzione (CAP-12) | 75% | nessun voto | 2/3 |
| Hard fork Dijkstra | 60% | 51% | 2/3 |
| Ogni aggiornamento dei parametri di throughput | 67% | 51% | 2/3 |
Fonte: IOG, 20 ottobre 2026. La registrazione delle chiavi BLS non è un voto ma ha una soglia propria: circa il 90-95% dello stake delegato.
Cardano Leios: c’è una data di rilascio?
No. L’articolo di IOG, l’aggiornamento di Intersect e il rapporto sul consenso non ne indicano una per l’hard fork Dijkstra, per la registrazione delle chiavi BLS o per i test di carico. L’unica tempistica condizionata nelle fonti è quella di Intersect: l’azione di hard fork sulla testnet attende la pre-release del nodo 11.2, che a sua volta non ha una data pubblicata. Le indiscrezioni che circolano nelle rassegne di notizie su Cardano a proposito della versione del nodo che porterà Leios non sono state confermate da una fonte primaria, e qui non le riprendiamo.
L’ordine degli eventi, però, è fissato dalle regole. Prima codice e testnet, poi l’emendamento costituzionale, poi il voto sul fork, poi la registrazione delle chiavi da parte dei pool, infine i test di carico e i voti sui parametri. I DRep e il comitato che voteranno questi passaggi sono gli stessi organi che già approvano i prelievi dalla tesoreria di Cardano, come abbiamo raccontato nel pezzo su i 42,6 milioni di ADA rimasti nella tesoreria di Cardano sotto il tetto di spesa.
Cosa cambia per chi detiene ADA e per gli operatori di pool
Per gli operatori di stake pool il messaggio pratico è di entrare nella testnet Dijkstra, che secondo Intersect è già aperta, e di aspettarsi un aggiornamento di chiave BLS e certificato dopo il fork. Un pool che salta il passaggio produce comunque blocchi ma non ha voce nella certificazione degli endorser block, e Leios non può accendersi finché il 90-95% dello stake non si è registrato.
Per i DRep e il Constitutional Committee il lavoro è CAP-12, poi il voto sul fork, poi i voti sul throughput. Nostra lettura dell’articolo di IOG e dell’aggiornamento di Intersect: nessuna delle tappe elencate affida un compito a chi si limita a detenere ADA. Sviluppatori, operatori di pool, DRep e comitato fanno il lavoro, e chi detiene i token partecipa solo attraverso il pool e il DRep a cui delega.
Per il lettore italiano è un aggiornamento di protocollo, non un nuovo prodotto: nessuna delle fonti citate lo collega a obblighi di Consob o OAM e ai detentori di ADA non viene chiesto alcun passaggio.
ADA scambiava intorno a 0,2047 dollari alle 11:46 UTC del 26 ottobre, in rialzo dello 0,63% in 24 ore e in calo del 7,19% in sette giorni. Nulla in questi dati collega il movimento alla notizia su Leios.
Prossime date da tenere d’occhio
- 27 ottobre, 16:00 UTC: CIP Editors Meeting (Intersect).
- 29 ottobre, 15:00 UTC: revisione CAP della quarta bozza di CAP-12 (Intersect).
- Senza data: la pre-release del nodo 11.2, che fa partire l’azione di avvio dell’hard fork sulla testnet Dijkstra.
- Senza data: selezione e recupero degli endorser block nel codice di consenso, indicati come prossimo compito nel rapporto del 23 ottobre.
1 commento