Traduzione italiana di “Increasing the transaction throughput of Cardano - IOHK Blog”
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
Aumentare il throughput delle transazioni Cardano
Il pipelining a diffusione - programmato per quest’estate - aumenterà il margine per la propagazione dei blocchi e i tempi di convalida, consentendo blocchi più grandi e un maggiore throughput delle transazioni. Ecco una prospettiva di ricerca tecnica. (Insieme a un’introduzione ad AV, il suo parente ancora più performante…)
La recente introduzione dei contratti intelligenti su Cardano ha portato ad un aumento significativo dell’attività degli utenti. Contemporaneamente, le dimensioni medie delle transazioni sono cresciute a causa delle transazioni di script che trasportano codice. Con le prime applicazioni di finanza decentralizzata (DeFi) ora distribuite sull’ecosistema Cardano, e altre in arrivo, ci aspettiamo che questa tendenza continui. Per tenere il passo con questa elevata domanda, l’attuale flusso di transazioni del sistema deve essere aumentato.
Un approccio ovvio per aumentare il throughput delle transazioni è quello di aumentare il limite della dimensione del blocco per inserire più transazioni per blocco. La dimensione del blocco è già stata aumentata del 25% quest’anno, da 64kB agli attuali 80kB, e prevediamo ulteriori aumenti. Tuttavia, c’è un limite su quanto grande un blocco possa essere mantenuto in modo sicuro da un protocollo di consenso del ledger se il tasso di produzione dei blocchi deve essere mantenuto al livello attuale. Per raggiungere un alto throughput senza compromettere la sicurezza del sistema, sono necessarie misure aggiuntive. Per capire perché, dobbiamo dare un’occhiata più da vicino a come funziona il consenso ledger in generale:
I protocolli di consenso del ledger sono caratterizzati da due parametri temporali:
- Δp, il ritardo massimo della rete per un nuovo blocco per raggiungere (ad esempio) il 95% della rete, e
- Δb, il tempo (previsto) tra la generazione di due nuovi blocchi
Nei protocolli tipici, per sostenere la coerenza del consenso, la propagazione di un blocco precedente deve finire prima che il blocco successivo sia generato - almeno la maggior parte delle volte. Quindi, Δb è scelto per essere un po’ più grande di Δp. In Cardano, abbiamo Δp=5s (secondi) e Δb=20s.
Ora, quanti dati possono essere trasportati da un blocco in queste condizioni? Per vedere questo, abbiamo bisogno di esaminare più in dettaglio cosa esattamente deve essere raggiunto entro Δp.
Figura 1. Diffusione dei blocchi in rete e convalida all’interno del budget Δp=5s
Si consideri la precedente Figura 1 che rappresenta in modo semplificato come funziona la propagazione dei blocchi nella rete. Il produttore del blocco invia la sua nuova intestazione al Peer 1 (h-box bianca), occupando i collegamenti di rete di entrambi i nodi durante l’intervallo di tempo indicato dall’h-box bianca. Il Peer 1 quindi convalida l’intestazione (coinvolgendo il calcolo locale durante l’intervallo di tempo indicato dall’hv-box grigio). Se l’intestazione è valida, cioè l’intestazione dimostra la leadership del blocco, ecc., il corpo del blocco viene scaricato dal Peer 1 (white b-box), occupando di nuovo i collegamenti di rete di entrambi i nodi. Infine, il Peer 1 convalida il corpo del blocco (bv-box grigio), e, solo se anche il corpo del blocco è valido, il Peer 1 è pronto a propagare il blocco ad altri peer secondo le linee di quanto appena descritto.
Uno sfortunato effetto collaterale di questo modo di operare è che la CPU di un singolo nodo e il collegamento di rete sono utilizzati solo durante una piccola frazione di Δp=5s mentre rimangono (per lo più) inattivi durante il resto del (previsto) Δb=20s.
Concretamente, la quantità di dati che possiamo inserire in un blocco è determinata dal ritardo di rete peer-to-peer del blocco e dal tempo di validazione richiesto. Entrambi crescono all’incirca linearmente nella dimensione del blocco, moltiplicato per il numero massimo di hop (salti) necessari per raggiungere il 95% di tutti i nodi. Le misurazioni mostrano che, per garantire la propagazione della rete entro Δp=5s, la dimensione del blocco non dovrebbe superare i 2 MB. Tenendo conto degli script computazionalmente intensi, il tempo di convalida può anche imporre un limite molto più basso.
La buona notizia è che, entro questi vincoli, il throughput delle transazioni può essere superato applicando modifiche alla rete peer-to-peer e/o ai livelli di consenso. Spieghiamo queste tecniche di seguito.
Pipelining a diffusione
Riconsiderando la figura 1, vediamo che tutte le azioni dei nodi sono eseguite in stretta sequenza, e quindi Δp deve adattarsi al tempo richiesto da un singolo nodo moltiplicato per il numero di hop nel percorso peer-to-peer. Osserviamo che, mentre questo è necessario per la propagazione in rete, non lo è per la validazione dei blocchi.
Si consideri la figura 2. Permettendo ai blocchi di essere propagati prima che la validazione completa abbia avuto luogo, possiamo escludere la validazione (ripetuta) del corpo dal percorso di propagazione. Non appena il Peer 1 ha ricevuto il corpo del blocco (b-box), può già iniziare a propagare il blocco contemporaneamente alla validazione del corpo del blocco, ecc.
In contrasto con lo schema in Figura 1, il budget Δp ora deve tenere conto della convalida del corpo solo una volta. Questo si traduce in un budget di tempo più alto per la trasmissione di rete peer-to-peer e/o per la validazione del corpo, permettendo così un più alto throughput di transazione (per un facile confronto con la Figura 1, questo guadagno è illustrato da un budget di validazione del corpo (‘bv’) più grande).
Per ragioni spiegate di seguito, è fondamentale che i seguenti due controlli di validazione rimangano completamente replicati nel percorso di propagazione:
- Correttezza dell’intestazione, cioè il blocco fa correttamente riferimento al suo predecessore, e la corretta leadership del blocco (verifiable-random-function (VRF) e validazione della firma del blocco).
- Completezza del blocco, cioè il corpo ricevuto (ma non ancora convalidato) è effettivamente referenziato dall’hash del corpo dell’intestazione.
Come potrebbe il pipeline diffuso (come descritto sopra) influenzare la sicurezza dei livelli di consenso e di rete?
In primo luogo, si noti che il livello di consenso rimane inalterato da questo cambiamento:
- I blocchi onesti sono sempre validi, poiché il leader del blocco convalida completamente la catena da aggiungere al nuovo blocco così come il nuovo blocco stesso, e,
- I blocchi incompleti non vengono propagati (a causa del punto 2 sopra), e,
- I blocchi non validi (completi), anche se eventualmente propagati attraverso la rete, sono sempre scartati da un nodo onesto dopo la convalida del corpo
In secondo luogo, per quanto riguarda gli attacchi Denial-of-Service (DoS) al livello di rete, si noti che l’avversario può cercare di congestionare il sistema diffondendo blocchi non validi. Tuttavia, la corretta leadership del blocco è ancora verificata (a causa del punto 1), il che implica che tale blocco sarà propagato solo se l’avversario è programmato per farlo, cioè, non viene generato più carico che se questo leader del blocco fosse onesto (tranne che per il blocco che non contribuisce al throughput del sistema). Inoltre, gli stake-pool operator (SPO) che generano blocchi non validi possono essere facilmente identificati e puniti, infatti un sistema di gestione delle infrazioni è attualmente in sviluppo per svolgere esattamente questa funzione.
Per concludere, il pipelining a diffusione aumenta il budget per la propagazione dei blocchi e i tempi di convalida entro il limite Δp, consentendo blocchi più grandi e quindi di aumentare il throughput delle transazioni, pur lasciando invariate le regole di consenso. Promette di aumentare sostanzialmente il throughput pur essendo realizzabile con modifiche minimamente invasive al sistema, ed è quindi un ottimo candidato per l’implementazione a breve termine. Tuttavia, l’impatto del pipelining (da solo) è limitato, e le nostre ambizioni non si fermano qui.
Diamo ora un riassunto di una tecnica più potente che può raggiungere un throughput di transazioni ancora più alto, ma richiede anche alcuni cambiamenti di protocollo più significativi.
Convalida asincrona
L’idea alla base del pipelining a diffusione - la validazione ritardata del corpo - può essere portata all’estremo: un nuovo blocco deve ancora arrivare entro Δp, ma non chiediamo che la sua validazione del corpo sia completata entro Δp. Ci riferiamo a questa validazione asincrona (AV).
Si consideri la figura 3. La convalida del corpo può essenzialmente consumare il restante budget (previsto) di Δb (oltre alla trasmissione dei blocchi e alla convalida dell’intestazione), mettendo così virtualmente le CPU dei nodi a carico permanente. Tuttavia, si noti che il collegamento di rete e la CPU sono anche assegnati ad altri compiti (come la sincronizzazione della mempool), il che significa che non vogliamo utilizzare l’intero residuo di Δb per la validazione del corpo, ma lasciare un paio di secondi assegnati a tali altri compiti.
Questo ha un notevole effetto collaterale. In contrasto con il pipeline a diffusione, la convalida del libro mastro è generalmente in ritardo rispetto alla testa della catena. In particolare, anche i leader di blocco onesti ora possono creare blocchi che sono (parzialmente) non validi, poiché potrebbero non aver finito di convalidare la storia delle transazioni che porta al nuovo blocco.
Per far fronte a questo effetto collaterale, le regole del ledger devono essere adattate: per garantire che i blocchi onesti contribuiscano sempre alla sicurezza del consenso, i blocchi che portano transazioni non valide devono ancora essere considerati come estensioni valide della catena. Le transazioni non valide possono quindi essere semplicemente scartate durante la convalida del libro mastro.
Anche se sostanzialmente migliorato rispetto al pipelining a diffusione, AV può essere ulteriormente migliorato. La ragione è che, generalmente, non si possono diffondere abbastanza dati durante Δp per produrre abbastanza lavoro di convalida per massimizzare le CPU durante tutto il resto del periodo Δb. Per sfruttare appieno i benefici di AV, lo combineremo con il meccanismo degli endorser di input, che descriveremo in un prossimo post sul blog.
Impatto
Quale impatto sul throughput possiamo aspettarci da pipelining e AV? Trovare la risposta precisa a questa domanda è ancora un lavoro in corso da parte dei nostri team di rete e di ricerca, poiché dare un’analisi rigorosa nel caso di un avversario malintenzionato (che tenta di interrompere al massimo il protocollo) è piuttosto complicato. Tuttavia, per fornire una prima stima, diamo qui di seguito un’analisi del throughput per il caso ottimistico in cui tutti gli SPO si comportino onestamente - nell’aspettativa che i risultati per il caso malevolo non si discostino sostanzialmente (data anche la futura presenza del sistema di gestione delle infrazioni). Tuttavia, si noti che il throughput reale del sistema probabilmente varierà dalle stime date.
Nella Tabella 1, presentiamo queste stime di throughput (in transazioni al secondo, TPS). Ricordiamo che il throughput dipende sia dalle dimensioni delle transazioni che dai tempi di validazione. Per una selezione di coppie dimensione/tempo di validazione, assumiamo che tutte le transazioni abbiano le stesse caratteristiche, e diamo i rispettivi numeri di throughput. Confrontiamo quattro diversi protocolli:
- Praos: Il protocollo attualmente utilizzato da Cardano (dimensione del blocco 80 kB)
- Praos Max: Praos con la massima dimensione possibile del blocco che può essere mantenuta in sicurezza (sotto le ipotesi di cui sopra)
- Pipeline a diffusione
- AV (con il 20% del budget Δb scontato, e riservato a diversi compiti)
Consideriamo quattro diversi tipi di transazione con dimensioni e tempi di convalida diversi. Una semplice transazione di pagamento è da qualche parte vicino alla categoria 0.5 kB / 0.5 ms, mentre le transazioni di script possono rientrare in uno degli altri tipi, che richiedono sia una dimensione maggiore che più sforzo per la convalida. Notate anche l’ultima colonna (2 kB / 32 ms) dove il tempo di convalida diventa sostanziale in confronto al ritardo della rete: Aumentare la dimensione del blocco (da Praos a Praos Max) non aiuta a migliorare il throughput poiché la validazione già massimizza il budget di tempo. Di conseguenza, pipelining e AV forniscono forti guadagni relativi proprio in questi casi, poiché aumentano il budget di tempo di validazione.
Prospettive per Cardano
Aumentare il throughput di una blockchain permissionless è critico per la sicurezza, poiché ammettere più carico al sistema può introdurre opportunità di attacchi DoS. È quindi consigliabile eseguire tali modifiche in una sequenza di piccoli passi osservando attentamente gli effetti sul sistema.
I primi passi di questo tipo sono stati fatti lo scorso dicembre e questo febbraio aumentando il limite della dimensione dei blocchi (e delle unità di memoria degli script Plutus) da 64kB a 80kB (vedi anche questo recente blog di John Woods).
Nei mesi a venire, continueremo a monitorare da vicino e a regolare questi parametri, in base alla domanda della rete e ai vincoli di capacità. Ulteriori miglioramenti arriveranno con l’implementazione del pipelining a diffusione. Altre ottimizzazioni del consenso, compresi gli endorser di ingresso, sono ancora in fase di sviluppo, e maggiori dettagli su come saranno eseguiti saranno annunciati a tempo debito.
Si noti che lo sforzo di ottimizzazione dell’era Cardano Basho si estende oltre la rete e i livelli di consenso, e comprende i miglioramenti dello script Plutus così come l’elaborazione fuori dalla catena - si veda questo recente blog di Tim Harrison. In particolare, Hydra, una suite di protocolli layer-2 in fase di sviluppo, offre un altro percorso per un drammatico miglioramento del throughput totale delle transazioni, permettendo di eseguire le transazioni fuori dalla catena.
Riconoscimenti. Vorrei ringraziare Duncan Coutts, Sandro Coretti-Drayton, Neil Davies, Alexander Esgen, Nicolas Frisby, Peter Gaži, Philipp Kant, Aggelos Kiayias, Karl Knutsson, Tim Harrison, Giorgos Panagiotakos, Alexander Russell, Fernando Sanchez, Marcin Szamotulski, Peter Thompson, Spyros Voulgaris e John Woods.