Perché le prestazioni della Blockchain sono difficili da misurare

Prestazioni e scalabilità sono sfide molto discusse nello spazio crittografico, rilevanti sia per i progetti Layer 1 (blockchain indipendenti) che per le soluzioni Layer 2 (come rollup e canali off-chain). Eppure non disponiamo di parametri o benchmark standardizzati. I numeri sono spesso riportati in modo incoerente e incompleto, rendendo difficile il confronto accurato dei progetti e spesso oscurando ciò che conta di più nella pratica. 

Abbiamo bisogno di un approccio più sfumato e approfondito per misurare e confrontare le prestazioni, un approccio che suddivida le prestazioni in più componenti e confronti i compromessi su più assi. In questo post definisco la terminologia di base, delineamo le sfide e offro linee guida e principi chiave da tenere a mente quando si valutano le prestazioni della blockchain. 

Scalabilità e prestazioni

Innanzitutto, definiamo due termini, scalabilità e prestazioni, che hanno significati informatici standard che vengono spesso abusati nei contesti blockchain. Prestazione misura cos'è un sistema attualmente in grado di realizzare. Come discuteremo di seguito, le metriche sulle prestazioni potrebbero includere transazioni al secondo o tempo medio di conferma della transazione. Scalabilità, d'altra parte, misura il capacità di un sistema di migliorare le prestazioni aggiungendo risorse.

Questa distinzione è importante: molti approcci al miglioramento delle prestazioni non migliorano affatto la scalabilità, se definiti correttamente. Un semplice esempio è l’utilizzo di uno schema di firma digitale più efficiente, come le firme BLS, che sono circa la metà delle firme Schnorr o ECDSA. Se Bitcoin passasse da ECDSA a BLS, il numero di transazioni per blocco potrebbe aumentare del 20-30%, migliorando le prestazioni da un giorno all’altro. Ma possiamo farlo solo una volta: non esiste uno schema di firma ancora più efficiente in termini di spazio a cui passare (le firme BLS possono anche essere aggregate per risparmiare più spazio, ma questo è un altro trucco una tantum).

Nelle blockchain sono possibili una serie di altri trucchi una tantum (come SegWit), ma è necessaria un'architettura scalabile per ottenere un miglioramento continuo delle prestazioni, in cui l'aggiunta di più risorse migliora le prestazioni nel tempo. Questa è la saggezza convenzionale anche in molti altri sistemi informatici, come la creazione di un server web. Con alcuni trucchi comuni, puoi costruire un server molto veloce; ma, in ultima analisi, è necessaria un'architettura multi-server in grado di soddisfare la domanda in continua crescita aggiungendo continuamente server aggiuntivi.

Comprendere la distinzione aiuta anche a evitare l'errore di categoria comune che si trova in affermazioni come "Blockchain X è altamente scalabile, può gestire Y transazioni al secondo!" La seconda affermazione può essere impressionante, ma è a performance metrica, non una metrica di scalabilità. Non parla della capacità di migliorare le prestazioni aggiungendo risorse.

La scalabilità richiede intrinsecamente lo sfruttamento del parallelismo. Nello spazio blockchain, il ridimensionamento del livello 1 sembra richiedere lo sharding o qualcosa che assomigli allo sharding. Il concetto di base dello sharding, ovvero la suddivisione dello stato in parti in modo che diversi validatori possano elaborarlo in modo indipendente, corrisponde strettamente alla definizione di scalabilità. Ci sono ancora più opzioni sul Layer 2 che consentono di aggiungere l'elaborazione parallela, inclusi canali off-chain, server rollup e sidechain.

Latenza e velocità effettiva

Classicamente, le prestazioni del sistema blockchain vengono valutate attraverso due dimensioni, latenza e throughput: la latenza misura la rapidità con cui una singola transazione può essere confermata, mentre il throughput misura il tasso aggregato delle transazioni nel tempo. Questi assi si applicano sia ai sistemi Layer 1 che Layer 2, così come a molti altri tipi di sistemi informatici (come motori di interrogazione di database e server web).

Sfortunatamente, sia la latenza che il throughput sono complessi da misurare e confrontare. Inoltre, i singoli utenti in realtà non si preoccupano del throughput (che è una misura a livello di sistema). Ciò a cui tengono veramente sono la latenza e le commissioni di transazione, più specificamente, che le loro transazioni vengano confermate nel modo più rapido ed economico possibile. Sebbene anche molti altri sistemi informatici siano valutati in base al rapporto costi/prestazioni, le commissioni di transazione sono un asse di prestazione in qualche modo nuovo per i sistemi blockchain che in realtà non esiste nei sistemi informatici tradizionali.

Sfide nella misurazione della latenza

All'inizio la latenza sembra semplice: quanto tempo impiega una transazione per essere confermata? Ma ci sono sempre diversi modi per rispondere a questa domanda.

Innanzitutto, possiamo misurare la latenza tra diversi punti nel tempo e ottenere risultati diversi. Ad esempio, iniziamo a misurare la latenza quando l'utente preme localmente un pulsante "invia" o quando la transazione raggiunge il mempool? E fermiamo l'orologio quando la transazione si trova in un blocco proposto o quando un blocco viene confermato con uno o sei blocchi successivi?

L’approccio più comune adotta il punto di vista dei validatori, misurando dal momento in cui un cliente trasmette per la prima volta una transazione al momento in cui una transazione viene ragionevolmente “confermata” (nel senso che i commercianti del mondo reale considererebbero un pagamento ricevuto e rilascerebbero la merce) . Naturalmente, diversi commercianti possono applicare criteri di accettazione diversi e anche un singolo commerciante può utilizzare standard diversi a seconda dell’importo della transazione.

L’approccio incentrato sul validatore trascura diversi aspetti che contano nella pratica. Innanzitutto, ignora la latenza sulla rete peer-to-peer (quanto tempo impiega da quando il client trasmette una transazione a quando la maggior parte dei nodi l'ha ascoltata?) e la latenza lato client (quanto tempo occorre per preparare una transazione sul computer locale del cliente?). La latenza lato client può essere molto piccola e prevedibile per transazioni semplici come la firma di un pagamento Ethereum, ma può essere significativa per casi più complessi come dimostrare che una transazione Zcash protetta è corretta.

Anche se standardizzassimo la finestra temporale che cerchiamo di misurare con la latenza, la risposta è quasi sempre dipende. Nessun sistema di criptovaluta mai costruito ha offerto una latenza di transazione fissa. Una regola pratica fondamentale da ricordare è:

La latenza è una distribuzione, non un singolo numero.

La comunità di ricerca sul networking lo ha capito da tempo (vedi, ad esempio, this ottimo intervento di Gil Tene). Un'enfasi particolare è posta sulla "coda lunga" della distribuzione, poiché una latenza molto elevata anche nello 0.1% delle transazioni (o delle query sul server web) danneggerebbe gravemente influenza utenti finali.

Con le blockchain, la latenza di conferma può variare per una serie di motivi:

Dosaggio: la maggior parte dei sistemi effettua transazioni in batch in qualche modo, ad esempio in blocchi sulla maggior parte dei sistemi di livello 1. Ciò porta a una latenza variabile, poiché alcune transazioni dovranno attendere fino al riempimento del batch. Altri potrebbero essere fortunati e unirsi al gruppo per ultimi. Queste transazioni vengono confermate immediatamente e non subiscono alcuna latenza aggiuntiva.

Congestione variabile: la maggior parte dei sistemi soffre di congestione, il che significa che vengono registrate più transazioni (almeno in alcune occasioni) di quelle che il sistema può gestire immediatamente. Il livello di congestione può variare quando le transazioni vengono trasmesse in orari imprevedibili (spesso astratti come a Processo di Poisson) o quando il tasso delle nuove transazioni cambia nel corso del giorno o della settimana, o in risposta a eventi esterni come un popolare lancio di NFT.

Varianza dello strato di consenso: La conferma di una transazione sul Livello 1 richiede solitamente che un insieme distribuito di nodi raggiunga il consenso su un blocco, il che può aggiungere ritardi variabili indipendentemente dalla congestione. I sistemi di prova del lavoro trovano blocchi in momenti imprevedibili (anche astrattamente un processo di Poisson). I sistemi di prova della posta in gioco possono anche aggiungere vari ritardi (ad esempio, se un numero insufficiente di nodi è online per formare un comitato in un round o se è necessario un cambio di visione in risposta al crash di un leader).

Per questi motivi, una buona linea guida è:

Le affermazioni sulla latenza dovrebbero presentare una distribuzione (o un istogramma) dei tempi di conferma, piuttosto che un singolo numero come la media o la mediana.

Mentre le statistiche riassuntive come la media, la mediana o i percentili forniscono un quadro parziale, per valutare accuratamente un sistema è necessario considerare l’intera distribuzione. In alcune applicazioni, la latenza media può fornire informazioni utili se la distribuzione della latenza è relativamente semplice (ad esempio, gaussiana). Ma nelle criptovalute non è quasi mai così: in genere c’è una lunga coda di tempi di conferma lenti.

Un buon esempio sono le reti di canali di pagamento (ad esempio Lightning Network). Una classica soluzione di scalabilità L2, queste reti offrono conferme di pagamento molto veloci per la maggior parte del tempo, ma occasionalmente richiedono un ripristino del canale che può aumentare la latenza di ordini di grandezza.

E anche se disponiamo di buone statistiche sull’esatta distribuzione della latenza, probabilmente varieranno nel tempo man mano che il sistema e la domanda sul sistema cambiano. Inoltre, non è sempre chiaro come confrontare le distribuzioni della latenza tra i sistemi concorrenti. Ad esempio, consideriamo un sistema che conferma le transazioni con una latenza uniformemente distribuita tra 1 e 2 minuti (con una media e una mediana di 90 secondi). Se un sistema concorrente conferma esattamente il 95% delle transazioni in 1 minuto e il restante 5% in 11 minuti (con una media di 90 secondi e una mediana di 60 secondi), quale sistema è migliore? La risposta è probabilmente che alcune applicazioni preferirebbero la prima e altre la seconda.

Infine, è importante notare che nella maggior parte dei sistemi non tutte le transazioni hanno la stessa priorità. Gli utenti possono pagare di più per ottenere una priorità di inclusione più elevata, quindi oltre a tutto quanto sopra, la latenza varia in funzione delle commissioni di transazione pagate. In sintesi:

La latenza è complessa. Più dati vengono riportati, meglio è. Idealmente, le distribuzioni complete della latenza dovrebbero essere misurate in condizioni di congestione variabili. Sono utili anche le suddivisioni della latenza in diversi componenti (locale, rete, batch, ritardo del consenso).

Sfide nella misurazione del throughput

Anche il throughput sembra semplice a prima vista: quante transazioni può elaborare un sistema al secondo? Sorgono due difficoltà principali: cos’è esattamente una “transazione” e stiamo misurando ciò che un sistema fa oggi o cosa potrebbe essere in grado di fare?

Sebbene le “transazioni al secondo” (o tps) siano uno standard de facto per misurare le prestazioni della blockchain, le transazioni sono problematiche come unità di misura. Per i sistemi che offrono programmabilità generica ("contratti intelligenti") o anche funzionalità limitate come le transazioni multiplex di Bitcoin o le opzioni per la verifica multi-sig, la questione fondamentale è:

Non tutte le transazioni sono uguali.

Questo è ovviamente vero in Ethereum, dove le transazioni possono includere codice arbitrario e modificare arbitrariamente lo stato. Il concetto di gas in Ethereum viene utilizzato per quantificare (e addebitare commissioni per) la quantità complessiva di lavoro svolto da una transazione, ma questo è altamente specifico per l'ambiente di esecuzione EVM. Non esiste un modo semplice per confrontare la quantità totale di lavoro svolto da un insieme di transazioni EVM con, ad esempio, un insieme di transazioni Solana utilizzando l'ambiente BPF. Il confronto con una serie di transazioni Bitcoin è altrettanto complicato.

Le blockchain che separano il livello di transazione in un livello di consenso e in un livello di esecuzione possono renderlo più chiaro. Al livello di consenso (puro), il throughput può essere misurato in byte aggiunti alla catena per unità di tempo. Il livello di esecuzione sarà sempre più complesso.

Livelli di esecuzione più semplici, come i server rollup che supportano solo transazioni di pagamento, evitano la difficoltà di quantificare il calcolo. Anche in questo caso, però, i pagamenti possono variare nel numero di input e output. Canale di pagamento le transazioni possono variare nel numero di “hop” richiesti, il che influisce sulla velocità effettiva. Inoltre, la velocità effettiva del server di rollup può dipendere dalla misura in cui un batch di transazioni può essere “nettato” in un insieme più piccolo di modifiche di riepilogo.

Un'altra sfida relativa al throughput è andare oltre la misurazione empirica delle prestazioni odierne per valutare la capacità teorica. Ciò introduce tutti i tipi di domande di modellazione per valutare la capacità potenziale. Innanzitutto, dobbiamo decidere un carico di lavoro realistico per le transazioni per il livello di esecuzione. In secondo luogo, i sistemi reali non raggiungono quasi mai la capacità teorica, soprattutto i sistemi blockchain. Per ragioni di robustezza, speriamo che le implementazioni dei nodi siano eterogenee e diverse nella pratica (piuttosto che tutti i client eseguano una singola implementazione software). Ciò rende ancora più difficile condurre simulazioni accurate del throughput della blockchain. 

Nel complesso:

Le dichiarazioni di throughput richiedono un'attenta spiegazione del carico di lavoro della transazione e della popolazione di validatori (la loro quantità, implementazione e connettività di rete). In assenza di uno standard chiaro, sono sufficienti i carichi di lavoro storici di una rete popolare come Ethereum.

Compromessi tra latenza e throughput

La latenza e il throughput sono solitamente un compromesso. COME Lefteris Kokoris-Kogias delinea, questo compromesso spesso non è uniforme, con un punto di flesso in cui la latenza aumenta bruscamente quando il carico del sistema si avvicina al throughput massimo.

I sistemi di rollup a conoscenza zero rappresentano un esempio naturale del compromesso throughput/latenza. Grandi lotti di transazioni aumentano il tempo di prova, che aumenta la latenza. Ma l’impatto sulla catena, sia in termini di dimensioni della prova che di costo di convalida, sarà ammortizzato su più transazioni con batch di dimensioni maggiori, aumentando la produttività.

Le spese di transazione

Comprensibilmente, gli utenti finali si preoccupano maggiormente del compromesso tra latenza e tasse, non latenza e throughput. Gli utenti non hanno alcun motivo diretto per preoccuparsi del throughput, ma solo che possono confermare rapidamente le transazioni alle tariffe più basse possibili (con alcuni utenti che si preoccupano maggiormente delle tariffe e altri della latenza). Ad alto livello, le tariffe sono influenzate da molteplici fattori:

1. Quanta domanda di mercato c’è per effettuare transazioni?
2. Quale rendimento complessivo viene raggiunto dal sistema?
3. Quante entrate complessive fornisce il sistema ai validatori o ai minatori?
4. Quanta parte di queste entrate si basa sulle commissioni di transazione rispetto ai premi inflazionistici?

I primi due fattori sono approssimativamente curve di domanda/offerta che portano a un prezzo di equilibrio del mercato (sebbene sia stato affermato che i minatori agiscono come un cartello per aumentare le tariffe oltre questo punto). A parità di condizioni, una maggiore produttività dovrebbe tendere a portare a tariffe più basse, ma c’è molto di più da fare.

In particolare, i punti 3 e 4 sopra sono questioni fondamentali per la progettazione di un sistema blockchain, ma per nessuno dei due mancano buoni principi. Comprendiamo in parte i vantaggi e gli svantaggi di fornire ai minatori entrate derivanti da premi inflazionistici rispetto alle commissioni di transazione. Tuttavia, nonostante molte analisi economiche sui protocolli di consenso blockchain, non disponiamo ancora di un modello ampiamente accettato per quanto riguarda le entrate che devono andare ai validatori. Oggi la maggior parte dei sistemi si basa su un’ipotesi plausibile su quante entrate siano sufficienti per far sì che i validatori si comportino onestamente senza strangolare l’uso pratico del sistema. Nei modelli semplificati, si può dimostrare che il costo di organizzare un attacco del 51% aumenta con le ricompense per i validatori.

Aumentare il costo degli attacchi è positivo, ma non sappiamo nemmeno quanta sicurezza sia “sufficiente”. Immagina di voler visitare due parchi di divertimento. Uno di loro afferma di spendere il 50% in meno per la manutenzione delle giostre rispetto all'altro. È una buona idea andare in questo parco? Potrebbe essere che siano più efficienti e ottengano una sicurezza equivalente con meno soldi. Forse l'altro sta spendendo più di quanto necessario per mantenere le giostre sicure senza alcun beneficio. Ma potrebbe anche darsi che il primo parco sia pericoloso. I sistemi blockchain sono simili. Una volta considerato il throughput, le blockchain con commissioni più basse hanno commissioni più basse perché premiano (e quindi incentivano) meno i loro validatori. Oggi non disponiamo di validi strumenti per valutare se questo va bene o se lascia il sistema vulnerabile agli attacchi. Complessivamente:

Il confronto delle tariffe tra i sistemi può essere fuorviante. Anche se le commissioni di transazione sono importanti per gli utenti, sono influenzate da molti fattori oltre alla progettazione del sistema stesso. Il throughput è una metrica migliore per analizzare un sistema nel suo insieme.

Conclusione

Valutare le prestazioni in modo equo e accurato è difficile. Ciò vale anche per misurare le prestazioni di un’auto. Proprio come con le blockchain, persone diverse si preoccuperanno di cose diverse. Con le automobili, alcuni utenti si preoccuperanno della velocità massima o dell’accelerazione, altri del consumo di carburante e altri ancora della capacità di traino. Tutti questi non sono banali da valutare. Negli Stati Uniti, ad esempio, l'Environmental Protection Agency mantiene linee guida dettagliate solo su come viene valutato il consumo di carburante e su come deve essere presentato agli utenti presso una concessionaria.

Lo spazio blockchain è molto lontano da questo livello di standardizzazione. In alcune aree, potremmo arrivarci in futuro con carichi di lavoro standardizzati per valutare il throughput di un sistema o grafici standardizzati per presentare le distribuzioni di latenza. Per il momento, l’approccio migliore per valutatori e costruttori è quello di raccogliere e pubblicare quanti più dati possibile, con una descrizione dettagliata della metodologia di valutazione, in modo che possa essere riprodotta e confrontata con altri sistemi.