Traduzione italiana di “Optimizing Cardano” scritto nel blog IOG
Traduzione italiana a cura di Lordwotton di RIOT Stake Pools. Se apprezzi queste traduzioni, per favore valuta di supportare il mio lavoro delegando i tuoi ada a RIOT 
entra nel nostro gruppo Telegram
Ottimizzare Cardano
Il percorso verso l’ottimizzazione della rete consiste in aggiustamenti graduali passo dopo passo
Come blockchain proof-of-stake, Cardano è costruito per essere altamente sicuro e resiliente ai fallimenti della rete. Guidato dall’algoritmo di consenso Ouroboros, integrato da Haskell che utilizza metodi formali, e dalla ricerca accademica peer-reviewed, Cardano è progettato per fornire un ambiente solido come una roccia per elaborare milioni di transazioni a livello globale, in modo decentralizzato e altamente scalabile.
Nel nostro precedente post sul blog, abbiamo discusso le prestazioni della rete - come funziona il sistema nel suo complesso quando elabora, verifica e firma le transazioni. Ottenere questo risultato nella primissima fase di progettazione è cruciale se si vuole un sistema che sia costruito per il lungo termine. Tuttavia, la capacità di rete è una risorsa preziosa, quindi per le metriche di performance più efficienti, è essenziale che le risorse di calcolo, memoria, stoccaggio e rete siano consumate in modo efficace.
Cardano è costruito per essere flessibile. È progettato per massimizzare il throughput consentendo allo stesso tempo di rispondere all’aumento della domanda. Man mano che la rete cresce, stiamo sintonizzando i parametri del protocollo per adattarsi alle fluttuazioni dei prezzi, estendere la scalabilità e le proprietà di throughput. Quindi diamo un’occhiata più da vicino a come ottimizzeremo le prestazioni della rete nel tempo.
Definire la congestione
I sistemi efficienti - dalle reti alle strade - sono costruiti per minimizzare la congestione, mentre permettono una gestione efficace quando accade. In termini di blockchain, la congestione implica che la rete è sovrasatura e sperimenta difficoltà nell’elaborazione di grandi volumi di transazioni e nella firma dei blocchi associati. In media, i blocchi di Cardano sono utilizzati per circa il 25% in una data epoca, il che dimostra che generalmente la rete non è congestionata e c’è una significativa capacità di riserva per elaborare un numero ancora maggiore di transazioni.
Cardano è progettato per essere equo e altamente resiliente anche in condizioni di forte saturazione. Ricordiamo le attuali impostazioni dei parametri e guardiamo alle future ottimizzazioni che sono previste. Le attuali metriche di performance dipendono dalle seguenti misure:
- Throughput - il volume di dati trasferiti. L’attuale dimensione del blocco è impostata a 64 KB. Una singola transazione di script Plutus è attualmente limitata a 16 KB, e le transazioni semplici possono comunemente prendere fino a circa 300 byte. Queste misure sono state bilanciate per assicurare un buon utilizzo della rete minimizzando le latenze delle transazioni. Se aumentate significativamente e in una sola volta, gli utenti dovranno affrontare un aumento del ritardo nel tempo di adozione dei blocchi. Questo perché il throughput e la tempestività sono in tensione l’uno con l’altro - massimizzare il throughput implica migliori prestazioni di rete, ma questo può venire al costo di un aumento del ritardo quando il sistema è pesantemente saturo.
- Tempestività - cioè il tempo di adozione del blocco. Il “budget” totale per l’adozione del blocco è impostato a 5 secondi per la propagazione di un blocco attraverso la rete (95% della posta in gioco) con un budget di circa 50 millisecondi disponibile per gli script di Plutus. Questo è stato progettato per consentire al blocco di includere sia gli script che le transazioni semplici senza monopolizzare.
Recentemente, gli utenti hanno registrato un aumento del tempo di attesa per l’elaborazione delle transazioni che è stato causato da grandi rilasci di NFT (non-fungible token). La ragione di questa sovrasaturazione risiede nel fatto che un’elevata quantità di NFT è stata rilasciata in una sola volta, il che ha causato quanto segue:
- un gran numero di transazioni NFT simultanee
- diversi utenti che cercano di acquistare lo stesso NFT e quindi tentano di elaborare le transazioni allo stesso tempo
- transazioni simultanee di rimborso agli utenti che non erano in grado di acquistare il NFT
Questo scenario ha creato una scarsità di rete per la vendita di NFT e quindi un’enorme domanda sul servizio - 43.000% dell’offerta. Vale anche la pena notare che il periodo di “congestione” è durato meno di un’ora.
Questo è un mercato in crescita e i creatori di NFT stanno già iniziando a iterare i loro processi per minimizzare l’impatto di tali cali sull’esperienza dell’utente. È ancora presto e stiamo tutti imparando velocemente. Va notato che il processo di conio degli NFT è perfettamente parallelizzabile, il che significa che non ci sono limiti a questo processo. Una volta coniati, gli NFT che memorizzano il codice di swap programmabile e gli asset necessari alla transazione sono pronti a interagire con il mercato.
Ma nel breve e medio termine almeno, si tratta di costruire sistemi di traffico più efficienti piuttosto che allargare le strade. Alcuni sviluppatori stanno già producendo tali sistemi specificamente per le emissioni di NFT, il che dovrebbe ridurre i costi così come i carichi di rete a breve termine.
Exchange decentralizzati (DEX)
Molte delle prime DApps costruite su Cardano sono DEXs o Decentralized Exchanges. E in alcune applicazioni gli utenti tendono a sperimentare la competizione mentre piazzano i loro ordini. Poiché il design delle DApp presuppone che l’intero stato sia mantenuto all’interno di una UTXO (piuttosto che distribuito su più UTXO), si verifica una dipendenza di una transazione futura da un output di una transazione precedente. Questo è stato ampiamente indicato come il “problema” della concurrency. Tuttavia, tirando fuori di nuovo l’analogia con l’automobile, non è un “problema” più di quanto lo sia guidare a sinistra nel Regno Unito o in Giappone. Richiede una curva di apprendimento, ma alla fine è solo un modo diverso di fare le cose. E se uno sviluppatore non lo fa, sì, incontrerà dei problemi! Né è intrinsecamente più complesso - richiede solo un approccio diverso.
Il modello EUTXO di Cardano è diverso dal modello basato su account. Le DApps costruite su Cardano dovrebbero allontanarsi dallo stile della macchina a stati a thread singolo e scendere direttamente al livello di astrazione dell’EUTXO, costruendo una soluzione che coinvolge i bordi concorrenti nel diagramma EUTXO. È importante usare diversi set di UTXO per imporre il parallelismo che migliorerà il throughput del sistema pur mantenendo le prestazioni delle singole operazioni. Certo, questo richiede un cambiamento di mentalità a qualsiasi sviluppatore abituato all’approccio di Ethereum. Tuttavia, il modello basato su UTXO è più sicuro del modello basato sull’account, perché mantenere tutto lo stato in un singolo account è più vulnerabile agli attacchi. Se si utilizzano correttamente le tecniche di parallelismo, gli utenti potranno godere di risultati migliori in termini di throughput e scalabilità, mentre le soluzioni off-chain sono meglio applicabili ai ledger UTXO. Per maggiori dettagli leggete il post del blog sulla concurrency e su come costruire una DApp Plutus scalabile. Pubblicheremo ulteriori contenuti su questo a tempo debito per fornire ulteriori indicazioni su come sfruttare al meglio il modello.
La tabella di marcia dell’ottimizzazione
Il nostro obiettivo al lancio è sempre stato quello di fornire capacità di base e correttezza, prima di ottimizzare. Questo è sempre stato il nostro obiettivo dichiarato. Stiamo continuando a monitorare le prestazioni e le regolazioni di benchmark. Man mano che la rete cresce e Cardano funziona ad una capacità maggiore, regoleremo la parametrizzazione per tenere il passo con la domanda della rete. Si tratta di aggiornamenti graduali che saranno implementati passo dopo passo nei prossimi mesi per garantire che i cambiamenti soddisfino i requisiti della rete e non compromettano le diverse proprietà.
Abbiamo condotto un’analisi approfondita e iniziato a implementare metriche di nodo che misurano accuratamente il tempo di diffusione dei dati. La diffusione dei dati è il processo di distribuzione delle transazioni e dei blocchi tra i nodi che verificano la blockchain. È essenziale fornire ai nodi le informazioni necessarie affinché l’algoritmo di consenso possa prendere le sue decisioni.
Probabilmente implementeremo un tempo medio di attesa dall’invio della transazione all’adozione della stessa. Insieme a questo, stiamo studiando e analizzando scenari che aumenteranno le prestazioni della rete in modo iterativo nel breve e lungo termine, tra cui:
- Aumento della dimensione del blocco - l’aumento della dimensione del blocco significa più transazioni in un blocco. Il vantaggio è che ci sarà meno tempo di attesa per le transazioni per essere adottate da un blocco durante i periodi di saturazione della rete. Tuttavia, c’è un compromesso. I blocchi più grandi richiedono più tempo per propagarsi attraverso la rete. Questo significa anche che i nodi avranno bisogno di più tempo per verificare le transazioni. Anche se l’aumento della dimensione del blocco è un’opzione per aumentare le prestazioni della rete, tali cambiamenti dovrebbero essere eseguiti con cautela. Per garantire che l’aumento non comprometta il tempo di adozione dei blocchi, cambieremo gradualmente i parametri e valuteremo i risultati durante i periodi di alta saturazione. Questo non è un aggiornamento in un solo passo, ma piuttosto un approccio iterativo che ci fornirà risultati chiari e aiuterà a garantire le regolazioni più efficienti.
- Dimensione della mempool - attualmente, la dimensione della mempool è impostata a 128 KB, che è il doppio della dimensione del blocco corrente. Il mempool funziona come buffer di rete e può causare un breve ritardo quando si includono le transazioni in un blocco. Tuttavia, l’aumento della dimensione del mempool non migliorerà il throughput della rete - le code delle transazioni rimarranno le stesse. Il mempool permette un’adozione equa delle nuove transazioni che vi entrano in modo casuale in base al nodo produttore che viene scelto dall’algoritmo della lotteria.
- Compressione degli script - dato che la dimensione attuale delle transazioni è impostata a 16 KB, stiamo continuando a lavorare sulla compressione, che permette al protocollo di ‘zippare’ il codice in modo trasparente. Questo significa più transazioni di script in un blocco a causa della loro dimensione ridotta - gli sviluppatori saranno in grado di presentare codice più sofisticato comprimendolo a 16 KB o meno, e ci sarà più spazio lasciato per altre transazioni.
Progettare per EUTXO
Come descritto nel nostro precedente post sul blog sulla concurrency, il modello EUTXO di Cardano elimina intere classi di problemi quando si progettano applicazioni DeFi. Oltre alla capacità nativa di EUTXO di elaborare transazioni in parallelo, la natura deterministica del modello assicura che gli sviluppatori e gli utenti possano evitare lo spreco di “gas”.
Detto questo, il modello EUTXO non è lo stesso del modello basato su account. Sollevare e spostare l’architettura delle applicazioni destinate a sistemi basati su account in un sistema basato su EUTXO risulterà in un design di applicazione subottimale. Le applicazioni progettate specificamente per il modello EUTXO di Cardano forniranno la migliore esperienza utente.
A breve pubblicheremo un’immersione tecnica più approfondita su come gli sviluppatori possono ottimizzare l’invio e l’elaborazione degli ordini, per esempio, al modello EUTXO.
Iterazione e miglioramento
Quindi c’è un sacco di lavoro in corso dietro le quinte mentre continuiamo ad evolvere e iterare. Questi sono ancora i primi giorni, e valuteremo continuamente le prestazioni della rete e regoleremo i parametri di conseguenza. A breve termine, saremo in grado di alleggerire la congestione dei drop di NFT distribuendo più uniformemente il calcolo della distribuzione dello stake e delle ricompense. Questo ci permetterà a sua volta di aumentare la dimensione del blocco, eliminare le pause e la congestione ai confini dell’epoca, e rimuovere i picchi di calcolo (che possono causare una propagazione del blocco più lenta). L’aumento graduale della dimensione del blocco ci permetterà anche di valutare i migliori scenari per le prestazioni della rete e questi risultati saranno presto visibili sulla rete.
Abbiamo anche in programma di spostare lo stato del ledger su disco per alleggerire il carico sulla catena, insieme alla compressione degli script e all’implementazione delle funzioni di condivisione sulla catena. Quando saranno finalizzati, completeranno notevolmente gli aggiustamenti della rete.
A medio termine, Hydra porterà ulteriori capacità. A più lungo termine, il nostro Chief Scientist e il nostro team continuano a ricercare altri metodi e meccanismi intorno alle strutture dei prezzi e al miglioramento del protocollo Ouroboros per aumentare il throughput delle transazioni. Ulteriori informazioni su questo nei prossimi post del blog!
Sono passati due mesi
Sono passati solo due mesi dall’inizio dell’era dei contratti intelligenti su Cardano. Qualunque sia il peso dell’aspettativa e dell’anticipazione intorno al “lancio”, questo non sarebbe mai stato un aggiornamento di un solo colpo. Proprio come c’è sempre stato bisogno di tempo per l’ecosistema per costruire lo slancio, c’è sempre stato un periodo di assestamento e poi di adattamento, come le richieste sulla rete crescono. Siamo in un viaggio e la comprensione del feedback della comunità rimane la chiave. Parlando con molti dei nuovi entusiasmanti progetti #BuildingOnCardano, stiamo costruendo una migliore comprensione dei loro piani e obiettivi - insieme a qualsiasi problema che stanno affrontando - in modo da poter sostenere e servire come necessario. Stiamo anche seguendo da vicino il dibattito della comunità.
Sono i primi giorni e stiamo ancora imparando. Tuttavia, per progetto, Cardano è impostato per flettere e crescere insieme al suo nascente - ma già vibrante - ecosistema. Continuiamo tutti a costruire!
Se sei uno sviluppatore e vuoi una guida, supporto, o semplicemente vuoi passare per una chiacchierata ad una delle nostre sessioni aperte - assicurati di unirti alla nostra crescente comunità tecnica su Discord.
I miei ringraziamenti a John Woods, Vitor Silva, Kevin Hammond, Duncan Coutts, Romain Pellerin, Michael Peyton Jones, Jean-Frederic Etienne & Olga Hryniuk per il loro supporto e feedback nella preparazione di questo post.