La domanda preferita su qualsiasi sistema distribuito da un non tecnico è "Quanti tps ha la vostra blockchain?" Tuttavia, il numero menzionato in risposta ha solitamente poco a che fare con quello che il domandante vorrebbe sentire. In realtà, voleva chiedere "La vostra blockchain soddisfa le mie esigenze aziendali?", e questi requisiti non sono un numero unico, ma una serie di condizioni: resilienza della rete, requisiti di finalità, dimensioni, natura delle transazioni e molti altri parametri. Quindi, la risposta alla domanda "quanti tps" difficilmente sarà semplice e quasi mai completa. Un sistema distribuito con decine e centinaia di nodi che eseguono calcoli complessi può trovarsi in una grande varietà di stati diversi, legati allo stato della rete, al contenuto della blockchain, ai guasti tecnici, ai problemi economici, agli attacchi alla rete e molte altre cause. Le fasi in cui possono verificarsi problemi di prestazioni sono diverse rispetto ai servizi tradizionali, e il server della rete blockchain è un servizio di rete che combina le funzionalità di un database, un web server e un client torrent, rendendolo estremamente complesso in termini di carico su tutti i sottosistemi: CPU, memoria, rete, storage.

È successo che le reti decentralizzate e le blockchain siano un software piuttosto specifico e insolito per gli sviluppatori di software centralizzato. Pertanto, vorrei trattare gli aspetti importanti delle prestazioni e della resilienza delle reti decentralizzate, i metodi per misurarli e individuare i colli di bottiglia. Esamineremo diversi problemi di prestazioni che limitano la velocità di servizio agli utenti delle blockchain e evidenzieremo le caratteristiche specifiche di questo tipo di software.

Fasi di richiesta del servizio da parte del cliente della blockchain

Per parlare onestamente della qualità di qualsiasi servizio più o meno complesso, è necessario considerare non solo i valori medi, ma anche i massimi/minimi, le mediane e i percentili. Teoricamente, si potrebbe parlare di 1000 tps in qualche blockchain, ma se 900 transazioni vengono eseguite con grande rapidità mentre 100 'si bloccano' per diversi secondi, il tempo medio calcolato su tutte le transazioni non è una metrica del tutto onesta per il cliente che non è riuscito a completare la transazione in pochi secondi. Le 'buche' temporali causate da turni di consenso mancati o dalla divisione della rete possono rovinare gravemente un servizio che in ambiente di test mostrava un'ottima performance.

Per identificare tali colli di bottiglia è necessario comprendere bene le fasi in cui una blockchain reale può avere difficoltà nel servire gli utenti. Descriviamo il ciclo di consegna e il processo di elaborazione delle transazioni, così come l'ottenimento di un nuovo stato della blockchain, da cui il cliente può verificare che la sua transazione sia stata elaborata e registrata.

la transazione si forma sul cliente
la transazione viene firmata sul cliente
il cliente sceglie uno dei nodi e invia la propria transazione a esso
il cliente si iscrive agli aggiornamenti del database di stato del nodo, in attesa dell'arrivo dei risultati dell'esecuzione della propria transazione
il nodo diffonde la transazione nella rete p2p
più di un BP (block producer) elabora le transazioni accumulate, aggiornando il database di stato
il BP forma un nuovo blocco, elaborando il numero necessario di transazioni
il BP diffonde il nuovo blocco nella rete p2p
il nuovo blocco viene consegnato al nodo a cui si rivolge il cliente
il nodo aggiorna il database di stato
il nodo vede l'aggiornamento relativo al cliente e gli invia una notifica sulla transazione

Ora analizziamo in dettaglio queste fasi e descriviamo i potenziali problemi di prestazioni in ciascuna fase. A differenza dei sistemi centralizzati, esamineremo anche l'esecuzione del codice sui client della rete. Spesso, quando si misura il tps, il tempo di elaborazione delle transazioni viene raccolto dai nodi, e non dal client: questo non è del tutto corretto. Al cliente non importa quanto velocemente il nodo ha elaborato la sua transazione; ciò che conta per lui è il momento in cui le informazioni affidabili su questa transazione, incluse nella blockchain, diventeranno disponibili per lui. Questa metrica è fondamentalmente il tempo di esecuzione della transazione. Ciò significa che diversi client, anche inviando la stessa transazione, possono ottenere tempi completamente diversi, che dipendono dal canale, dal carico e dalla vicinanza del nodo, ecc. Quindi, è assolutamente necessario misurare questo tempo sui client, poiché è questo parametro che deve essere ottimizzato.

Preparazione della transazione sul lato client

Iniziamo con i primi due punti: la transazione viene formata e firmata dal client. Stranamente, questo può anche essere un collo di bottiglia per le prestazioni della blockchain dal punto di vista del client. È insolito per i servizi centralizzati, che gestiscono tutti i calcoli e le operazioni sui dati, mentre il client si limita a preparare una richiesta breve, capace di richiedere grandi volumi di dati o calcoli, ricevendo un risultato pronto. Nelle blockchain, il codice client diventa sempre più potente, mentre il nucleo della blockchain diventa sempre più leggero, e i compiti di calcolo complessi vengono affidati al software client. Nelle blockchain esistono client che possono impiegare molto tempo a preparare una transazione (parlo di vari merkle proof, succinct proof, firme threshold e altre operazioni complesse sul lato client). Un buon esempio di verifica on-chain leggera e di preparazione pesante della transazione sul client è la prova di appartenenza a un elenco basata su Merkle-tree. su Habr..

Inoltre, non bisogna dimenticare che il codice client non si limita a inviare transazioni alla blockchain, ma prima richiede lo stato della blockchain, e questa attività può influenzare il carico della rete e dei nodi blockchain. Pertanto, durante le misurazioni, è sensato emulare il comportamento del codice client nel modo più completo possibile. Anche se nella vostra blockchain ci sono normali client leggeri che appongono una comune firma digitale su una semplice transazione di trasferimento di un asset, ogni anno il carico computazionale sul client continua a crescere, gli algoritmi crittografici diventano più robusti, e questa parte del processamento potrebbe trasformarsi in un considerevole collo di bottiglia in futuro. Pertanto, è importante prestare attenzione e non trascurare situazioni in cui, in una transazione che dura 3,5 secondi, 2,5 secondi vengono spesi per la preparazione e la firma della transazione, e 1,0 secondo per l'invio nella rete e l'attesa della risposta. Per valutare i rischi di comparsa di questo collo di bottiglia è necessario raccogliere metriche dalle macchine client, e non solo dai nodi blockchain.

Invio della transazione e monitoraggio del suo stato

La fase successiva consiste nell'invio della transazione al nodo blockchain selezionato e nella ricezione dello stato di accettazione nella pool delle transazioni. Questa fase è simile a una normale richiesta a un database, il nodo deve registrare la transazione nella pool e iniziare a diffondere le informazioni attraverso la rete p2p. L'approccio per valutare le prestazioni qui è simile alla valutazione del lavoro dei tradizionali microservizi Web API, poiché le stesse transazioni nelle blockchain possono essere aggiornate e cambiare stato attivamente. In generale, l'aggiornamento delle informazioni sulla transazione in alcune blockchain può avvenire più volte, ad esempio durante i passaggi tra fork della catena o quando i BP comunicano l'intenzione di includere la transazione in un blocco. Le limitazioni sulla dimensione di questa pool e sul numero di transazioni in essa possono influenzare le prestazioni della blockchain. Se la pool delle transazioni è saturata fino alla dimensione massima possibile, o non può essere contenuta nella memoria operativa, le prestazioni della rete potrebbero diminuire drasticamente. Le blockchain non dispongono di mezzi di protezione centralizzati contro il flusso di messaggi spazzatura, e se la blockchain supporta transazioni di grande volume e commissioni basse, ciò potrebbe portare a un sovraccarico della pool delle transazioni, rappresentando un ulteriore potenziale collo di bottiglia delle prestazioni.

Nei blockchain, il cliente invia una transazione a qualsiasi nodo del blockchain a lui gradito; l'hash della transazione è solitamente noto al cliente prima dell'invio, quindi tutto ciò di cui ha bisogno è stabilire una connessione e, dopo la trasmissione, attendere quando il blockchain cambia il suo stato, includendo la sua transazione. È interessante notare che misurando il "tps" si possono ottenere risultati completamente diversi a seconda dei metodi di connessione al nodo del blockchain. Questo può essere un normale RPC HTTP o un WebSocket, che consente di realizzare il modello "subscribe". Nel secondo caso, il cliente riceverà una notifica prima, e il nodo spenderà meno risorse (principalmente memoria e traffico) per le risposte sullo stato della transazione. Pertanto, quando si misura il "tps", è necessario considerare il modo di collegare i clienti ai nodi. Per questo motivo, per valutare i rischi di questo colli di bottiglia, il benchmark del blockchain deve essere in grado di emulare i clienti sia con richieste WebSocket che con richieste HTTP RPC, in proporzioni che corrispondono alle reti reali, e anche di variare il tipo e la dimensione delle transazioni.

Per valutare i rischi di questo colli di bottiglia è necessario raccogliere anche metriche dalle macchine client, e non solo dai nodi blockchain.

Trasmissione di transazioni e blocchi attraverso una rete p2p

Nei blockchain, per il trasferimento di transazioni e blocchi tra i partecipanti si utilizza il networking peer-to-peer (p2p). Le transazioni si diffondono attraverso la rete, a partire da uno dei nodi, fino a raggiungere i peer - produttori di blocchi, che impacchettano le transazioni in blocchi e, utilizzando lo stesso p2p, distribuiscono i nuovi blocchi a tutti i nodi della rete. La base della maggior parte delle moderne reti p2p è costituita da varie modifiche del protocollo Kademlia. Ecco una buona panoramica di questo protocollo, e ecco un articolo con varie misurazioni nella rete BitTorrent, dal quale si può capire che questo tipo di rete è più complesso e meno prevedibile rispetto a una rete centralizzata rigidamente configurata. Inoltre, ecco un articolo sulla misurazione di diverse metriche interessanti per i nodi Ethereum.

In breve, ogni peer in tali reti mantiene la propria lista dinamica di altri peer, da cui richiede blocchi di informazioni, che sono indirizzati in base al contenuto. Quando riceve una richiesta, un peer restituisce le informazioni necessarie oppure trasferisce la richiesta al successivo peer pseudocasuale della lista, e una volta ricevuta la risposta, la trasmette a chi ha richiesto e la memorizza in cache per un certo periodo, restituendo questo blocco di informazioni per primo la prossima volta. In questo modo, le informazioni popolari si trovano in un gran numero di cache di molti peer, mentre quelle non popolari vengono gradualmente espulse. I peer registrano quanto e a chi hanno trasferito informazioni, e la rete cerca di incentivare i distributori attivi, aumentando il loro punteggio e garantendo loro un livello di servizio maggiore, espellendo automaticamente i partecipanti inattivi dalle liste dei peer.

Quindi, la transazione deve ora essere diffusa nella rete affinché i block-producer la vedano e la includano in un blocco. Il nodo 'distribuisce' attivamente la nuova transazione a tutti gli interessati e ascolta la rete, aspettando un blocco nel cui indice apparirà la transazione necessaria, per notificare il cliente in attesa. Il tempo in cui la rete scambia informazioni su nuove transazioni e blocchi nelle reti p2p dipende da un numero molto elevato di fattori: il numero di nodi onesti che funzionano nelle vicinanze (dal punto di vista della rete), la 'prontezza' delle cache di questi nodi, la dimensione dei blocchi, delle transazioni, la natura delle modifiche, la geografia della rete, il numero di nodi e molti altri fattori. Misurazioni complesse delle metriche di performance in tali reti sono un compito difficile, è necessario valutare contemporaneamente i tempi di elaborazione delle richieste sia sui client che sui peer (nodi blockchain). I problemi in uno qualsiasi dei meccanismi p2p, l'espulsione e la memorizzazione in cache errate dei dati, la gestione inefficace delle liste dei peer attivi e molti altri fattori possono provocare ritardi che influenzano l'efficienza dell'intera rete, e questo collo di bottiglia è il più difficile da analizzare, testare e interpretare i risultati.

Processamento della catena di blocchi e aggiornamento del database di stato

La parte più importante del funzionamento della blockchain è l'algoritmo di consenso, la sua applicazione a nuovi blocchi ottenuti dalla rete e il processing delle transazioni con registrazione dei risultati nel state database. L'aggiunta di un nuovo blocco nella catena e la successiva selezione della catena principale devono avvenire il più rapidamente possibile. Tuttavia, nella vita reale, «deve» non significa necessariamente «funziona», e si può per esempio immaginare una situazione in cui due lunghe catene concorrenti si alternano costantemente, cambiando i metadati di migliaia di transazioni nel pool a ogni passaggio, e producendo continui rollback dello stato del state database. Questa fase, in termini di definizione del bottleneck, è più semplice rispetto allo strato p2p di rete, poiché l'esecuzione delle transazioni e l'algoritmo di consenso sono strettamente deterministici, e misurare qualcosa qui è più facile.
L'importante è non confondere una degradazione casuale delle prestazioni di questa fase con i problemi di rete: i nodi forniscono blocchi e informazioni sulla catena principale più lentamente e per un cliente esterno questo può apparire come una rete lenta, anche se il problema risiede altrove.

Per ottimizzare le prestazioni in questa fase è utile raccogliere e monitorare metriche dai nodi stessi, includendo quelle relative all'aggiornamento del state database: numero di blocchi elaborati sul nodo, la loro dimensione, numero di transazioni, numero di passaggi tra fork delle catene, numero di blocchi non validi, tempo di esecuzione della macchina virtuale, tempo di finalizzazione dei dati, ecc. Questo eviterà di confondere problemi di rete con errori negli algoritmi di processing delle catene.

La macchina virtuale che processa le transazioni può essere una fonte utile di informazioni in grado di ottimizzare il funzionamento della blockchain. La quantità di allocazioni di memoria, il numero di istruzioni read/write e altre metriche relative all'efficienza dell'esecuzione del codice dei contratti possono fornire molte informazioni preziose agli sviluppatori. Allo stesso tempo, i smart contract sono programmi, il che significa che possono in teoria consumare qualsiasi risorsa: cpu/memory/network/storage, quindi il processing delle transazioni è una fase piuttosto indeterminata, che inoltre cambia notevolmente passando tra versioni e modificando il codice dei contratti. Pertanto, le metriche relative al processing delle transazioni sono anch'esse necessarie per un'ottimizzazione efficace delle prestazioni della blockchain.

Ricezione della notifica da parte del cliente sull'inclusione della transazione nella blockchain

Questo è l'ultimo passaggio per ottenere il servizio della blockchain da parte del cliente; rispetto ad altre fasi non ci sono grandi costi aggiuntivi, ma è comunque importante considerare la possibilità di ricevere dal nodo una risposta volumetrica (ad esempio, un contratto intelligente che restituisce un array di dati). In ogni caso, questo momento è il più importante per chi ha posto la domanda «quanti tps ci sono nella vostra blockchain?», poiché è in questo momento che viene registrato il tempo di ricezione del servizio.

In questo punto deve essere sempre presente l'invio del tempo totale che il cliente ha dovuto attendere per ricevere una risposta dalla blockchain; proprio questo tempo il utente aspetterà una conferma nella propria applicazione, e proprio l'ottimizzazione di questo è l'obiettivo principale degli sviluppatori.

Conclusione

Di conseguenza, è possibile descrivere i tipi di operazioni che vengono eseguite nelle blockchain e dividerle in diverse categorie:

trasformazioni crittografiche, costruzione di prove
rete peer-to-peer, replicazione di transazioni e blocchi
elaborazione delle transazioni, esecuzione di contratti intelligenti
applicazione delle modifiche nella blockchain al database di stato, aggiornamento dei dati su transazioni e blocchi
richieste di sola lettura al database di stato, API del nodo blockchain, servizi in abbonamento

In generale, i requisiti tecnici per i nodi delle moderne blockchain sono estremamente severi: richiedono CPU veloci per la crittografia, grande quantità di memoria RAM per memorizzare e accedere rapidamente al database di stato, interazione di rete che utilizza un numero elevato di connessioni aperte simultaneamente, e spazio di archiviazione consistente. Tali requisiti elevati e la varietà di operazioni inevitabilmente portano al fatto che le risorse nei nodi potrebbero non essere sufficienti, e quindi ciascuna delle fasi sopra menzionate potrebbe diventare un collo di bottiglia per le prestazioni complessive della rete.

Nel progettare e valutare le prestazioni delle blockchain, è necessario tenere conto di tutti questi aspetti. Per farlo, è necessario raccogliere e analizzare le metriche sia dai client che dai nodi della rete, cercando correlazioni tra di esse, valutando il tempo di fornitura del servizio ai clienti, considerando tutte le risorse principali: cpu/memoria/rete/archiviazione, comprendendo come vengono utilizzate e come influenzano l'una sull'altra. Tutto ciò rende il confronto delle velocità delle varie blockchain, in termini di 'quante TPS', un compito estremamente difficile, poiché ci sono un'enorme varietà di configurazioni e stati. In grandi sistemi centralizzati, cluster di centinaia di server, questi problemi sono altrettanto complessi e richiedono anche la raccolta di un gran numero di metriche diverse, ma nelle blockchain, a causa delle reti p2p, delle macchine virtuali, dei contratti intelligenti, dell'economia interna, il numero di gradi di libertà è molto maggiore, rendendo anche il test su pochi server indicativo solo di valori estremamente approssimativi, quasi privi di legame con la realtà.

Pertanto, nello sviluppo del nucleo della blockchain, per valutare le prestazioni e rispondere alla domanda 'è migliorato rispetto all'ultima volta', utilizziamo software piuttosto complesso che orchestri l'avvio della blockchain con decine di nodi e l'esecuzione automatica del benchmark e della raccolta delle metriche; senza queste informazioni è estremamente difficile debugare i protocolli che operano con numerosi partecipanti.

Quindi, ricevuto il quesito 'quante TPS ci sono nella vostra blockchain?', offri un tè al tuo interlocutore e chiedi se è pronto a prendere visione di una decina di grafici e a ascoltare tutti e tre i cassetti dei problemi legati alle prestazioni delle blockchain e le tue proposte per la loro soluzione…

Fonte: habr.com