Una delle domande preferite da una persona non tecnica su qualsiasi sistema distribuito è "Quanti tps ci sono sulla tua blockchain?" Tuttavia, il numero fornito nella risposta di solito ha poco in comune con ciò che l'interrogante vorrebbe sentire. In effetti, voleva chiedere "la tua blockchain soddisferà i miei requisiti aziendali" e questi requisiti non sono un numero, ma molte condizioni: qui ci sono la tolleranza agli errori di rete, i requisiti di definitività, le dimensioni, la 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 o centinaia di nodi che eseguono calcoli piuttosto complessi può trovarsi in un numero enorme di stati diversi legati allo stato della rete, al contenuto della blockchain, a guasti tecnici, problemi economici, attacchi alla rete e molti altri motivi . Le fasi in cui sono possibili problemi di prestazioni differiscono dai servizi tradizionali e un server di rete blockchain è un servizio di rete che combina le funzionalità di un database, server web e client torrent, il che lo rende estremamente complesso in termini di profilo di carico su tutti i sottosistemi : processore, memoria, rete, storage

Accade così che le reti decentralizzate e le blockchain siano software piuttosto specifici e insoliti per gli sviluppatori di software centralizzati. Pertanto, vorrei evidenziare aspetti importanti delle prestazioni e della sostenibilità delle reti decentralizzate, gli approcci per misurarle e individuare i colli di bottiglia. Esamineremo vari problemi di prestazioni che limitano la velocità di fornitura dei servizi agli utenti blockchain e noteremo le caratteristiche caratteristiche di questo tipo di software.

Fasi di una richiesta di servizio da parte di un client blockchain

Per parlare onestamente della qualità di un servizio più o meno complesso è necessario tenere conto non solo dei valori medi, ma anche dei massimi/minimi, delle mediane, dei percentili. In teoria, possiamo parlare di 1000 tps in alcune blockchain, ma se 900 transazioni sono state completate con enorme velocità e 100 sono rimaste "bloccate" per alcuni secondi, il tempo medio raccolto su tutte le transazioni non è una metrica del tutto equa per un cliente che non sono riuscito a completare la transazione in pochi secondi. I “buchi” temporanei causati da mancati round di consenso o da divisioni della rete possono rovinare notevolmente un servizio che ha mostrato prestazioni eccellenti sui banchi di prova.

Per identificare tali colli di bottiglia, è necessario avere una buona comprensione delle fasi in cui una vera blockchain può avere difficoltà a servire gli utenti. Descriviamo il ciclo di consegna ed elaborazione di una transazione, nonché l'ottenimento di un nuovo stato della blockchain, dal quale il cliente può verificare che la sua transazione è stata elaborata e contabilizzata.

la transazione si forma sul client
la transazione viene firmata sul client
il cliente seleziona uno dei nodi e gli invia la sua transazione
il client si iscrive agli aggiornamenti del database di stato del nodo, in attesa che vengano visualizzati i risultati della sua transazione
il nodo distribuisce la transazione sulla rete p2p
diversi o un BP (block produttore) elaborano le transazioni accumulate, aggiornando il database dello stato
BP forma un nuovo blocco dopo aver elaborato il numero richiesto di transazioni
BP distribuisce un nuovo blocco sulla rete p2p
il nuovo blocco viene consegnato al nodo a cui accede il client
il nodo aggiorna il database dello stato
il nodo vede l'aggiornamento riguardante il cliente e gli invia una notifica di transazione

Ora diamo uno sguardo più da vicino a queste fasi e descriviamo i potenziali problemi di prestazioni in ciascuna fase. A differenza dei sistemi centralizzati, prenderemo in considerazione anche l'esecuzione del codice sui client di rete. Molto spesso, quando si misura il TPS, il tempo di elaborazione della transazione viene raccolto dai nodi e non dal client: questo non è del tutto giusto. Al cliente non interessa la velocità con cui il nodo ha elaborato la sua transazione, la cosa più importante per lui è il momento in cui saranno a sua disposizione informazioni affidabili su questa transazione incluse nella blockchain. È questa metrica che rappresenta essenzialmente il tempo di esecuzione della transazione. Ciò significa che client diversi, anche inviando la stessa transazione, possono ricevere orari completamente diversi, che dipendono dal canale, dal carico e dalla vicinanza del nodo, ecc. Quindi è assolutamente necessario misurare questo tempo sui clienti, poiché è questo il parametro da ottimizzare.

Preparazione di una transazione lato client

Partiamo dai primi due punti: la transazione viene formata e firmata dal cliente. Stranamente, questo può anche rappresentare un collo di bottiglia per le prestazioni della blockchain dal punto di vista del cliente. Questo è insolito per i servizi centralizzati, che si assumono tutti i calcoli e le operazioni con i dati, e il cliente prepara semplicemente una breve richiesta che può richiedere una grande quantità di dati o calcoli, ottenendo un risultato già pronto. Nelle blockchain, il codice client diventa sempre più potente, il nucleo della blockchain diventa sempre più leggero e massicce attività di elaborazione vengono solitamente trasferite al software client. Nelle blockchain, ci sono clienti che possono preparare una transazione per un periodo piuttosto lungo (sto parlando di varie prove merkle, prove succinte, firme di soglia e altre operazioni complesse sul lato client). Un buon esempio di facile verifica on-chain e di pesante preparazione di una transazione sul cliente è la prova di appartenenza a un elenco basato su Merkle-tree, qui articolo.

Inoltre, non dimenticare che il codice client non invia semplicemente transazioni alla blockchain, ma interroga prima lo stato della blockchain e questa attività può influire sulla congestione della rete e dei nodi della blockchain. Pertanto, quando si effettuano le misurazioni, sarebbe ragionevole emulare il comportamento del codice client nel modo più completo possibile. Anche se nella tua blockchain ci sono normali clienti leggeri che inseriscono una firma digitale regolare sulla transazione più semplice per trasferire qualche risorsa, ogni anno ci sono ancora calcoli più massicci sul cliente, gli algoritmi crittografici stanno diventando più forti e questa parte dell'elaborazione può trasformarsi in un significativo collo di bottiglia in futuro. Pertanto, fai attenzione e non perdere la situazione in cui, in una transazione della durata di 3.5 s, si spendono 2.5 s per preparare e firmare la transazione e 1.0 s per inviarla alla rete e attendere una risposta. Per valutare i rischi di questo collo di bottiglia, è necessario raccogliere parametri dalle macchine client e non solo dai nodi blockchain.

Invio di una transazione e monitoraggio del suo stato

Il passaggio successivo è inviare la transazione al nodo blockchain selezionato e ricevere lo stato di accettazione nel pool di transazioni. Questa fase è simile ad un normale accesso al database; il nodo deve registrare la transazione nel pool e iniziare a distribuire le informazioni su di essa attraverso la rete p2p. L'approccio alla valutazione delle prestazioni in questo caso è simile alla valutazione delle prestazioni dei tradizionali microservizi API Web e le transazioni stesse nelle blockchain possono essere aggiornate e modificare attivamente il loro stato. In generale, l’aggiornamento delle informazioni sulle transazioni su alcune blockchain può verificarsi più volte, ad esempio quando si passa da una catena all’altra o quando i BP annunciano la loro intenzione di includere una transazione in un blocco. I limiti alla dimensione di questo pool e al numero di transazioni in esso contenute possono influire sulle prestazioni della blockchain. Se il pool di transazioni viene riempito alla massima dimensione possibile o non entra nella RAM, le prestazioni della rete possono diminuire drasticamente. Le blockchain non dispongono di mezzi centralizzati per proteggersi da un'ondata di messaggi spazzatura e, se la blockchain supporta transazioni ad alto volume e commissioni basse, ciò può causare un traboccamento del pool di transazioni, un altro potenziale collo di bottiglia nelle prestazioni.

Nelle blockchain, il cliente invia una transazione a qualsiasi nodo blockchain desideri, l'hash della transazione è solitamente noto al cliente prima dell'invio, quindi tutto ciò che deve fare è ottenere la connessione e, dopo la trasmissione, attendere che la blockchain cambi il suo stato, consentendo la sua transazione. Tieni presente che misurando “tps” puoi ottenere risultati completamente diversi per diversi metodi di connessione a un nodo blockchain. Può trattarsi di un normale RPC HTTP o di un WebSocket che consente di implementare il modello "sottoscrivi". Nel secondo caso, il client riceverà una notifica prima e il nodo spenderà meno risorse (principalmente memoria e traffico) nelle risposte sullo stato della transazione. Quindi quando si misura il “tps” è necessario tenere conto del modo in cui i client si connettono ai nodi. Pertanto, per valutare i rischi di questo collo di bottiglia, la blockchain di riferimento deve essere in grado di emulare client con richieste sia WebSocket che HTTP RPC, in proporzioni corrispondenti alle reti reali, oltre a modificare la natura delle transazioni e la loro dimensione.

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

Trasmissione di transazioni e blocchi tramite rete p2p

Nelle blockchain, la rete peer-to-peer (p2p) viene utilizzata per trasferire transazioni e blocchi tra i partecipanti. Le transazioni si diffondono in tutta la rete, a partire da uno dei nodi, fino a raggiungere i produttori di blocchi peer, che impacchettano le transazioni in blocchi e, utilizzando lo stesso p2p, distribuiscono nuovi blocchi a tutti i nodi della rete. La base delle reti p2p più moderne sono varie modifiche del protocollo Kademlia. Qui un buon riassunto di questo protocollo e qui - un articolo con varie misurazioni nella rete BitTorrent, da cui si capisce che questo tipo di rete è più complessa e meno prevedibile di una rete rigidamente configurata di un servizio centralizzato. Anche, qui articolo sulla misurazione di vari parametri interessanti per i nodi Ethereum.

In breve, ogni peer in tali reti mantiene il proprio elenco dinamico di altri peer a cui richiede blocchi di informazioni indirizzate dal contenuto. Quando un peer riceve una richiesta, fornisce le informazioni necessarie o passa la richiesta al successivo peer pseudo-casuale dall'elenco e, dopo aver ricevuto una risposta, la trasmette al richiedente e la memorizza nella cache per un po', fornendo questa blocco di informazioni prima la volta successiva. Pertanto, le informazioni popolari finiscono in un gran numero di cache di un gran numero di peer e le informazioni impopolari vengono gradualmente sostituite. I peer tengono traccia di chi ha trasferito quante informazioni a chi, e la rete cerca di stimolare i distributori attivi aumentando le loro valutazioni e fornendo loro un livello di servizio più elevato, sostituendo automaticamente i partecipanti inattivi dalle liste dei peer.

Pertanto, la transazione ora deve essere distribuita in tutta la rete in modo che i produttori di blocchi possano vederla e includerla nel blocco. Il nodo “distribuisce” attivamente una nuova transazione a tutti e ascolta la rete, in attesa di un blocco nell'indice in cui apparirà la transazione richiesta per avvisare il client in attesa. Il tempo impiegato dalla rete per trasferire reciprocamente informazioni su nuove transazioni e blocchi nelle reti p2p dipende da un numero molto elevato di fattori: il numero di nodi onesti che lavorano nelle vicinanze (dal punto di vista della rete), il "caldo- up” delle cache di questi nodi, la dimensione dei blocchi, le transazioni, la natura delle modifiche, la geografia della rete, il numero di nodi e molti altri fattori. Le misurazioni complesse delle metriche delle prestazioni in tali reti sono una questione complessa; è necessario valutare simultaneamente il tempo di elaborazione della richiesta sia sui client che sui peer (nodi blockchain). Problemi in uno qualsiasi dei meccanismi p2p, eliminazione errata dei dati e memorizzazione nella cache, gestione inefficace degli elenchi di peer attivi e molti altri fattori possono causare ritardi che influiscono sull'efficienza dell'intera rete nel suo insieme e questo collo di bottiglia è il più difficile da analizzare , test e interpretazione dei risultati.

Elaborazione blockchain e aggiornamento del database statale

La parte più importante della blockchain è l’algoritmo di consenso, la sua applicazione ai nuovi blocchi ricevuti dalla rete e l’elaborazione delle transazioni con registrazione dei risultati nel database statale. L'aggiunta di un nuovo blocco alla catena e la selezione della catena principale dovrebbero funzionare il più rapidamente possibile. Tuttavia, nella vita reale, "dovrebbe" non significa "funziona", e si può, ad esempio, immaginare una situazione in cui due lunghe catene concorrenti si scambiano costantemente tra loro, modificando i metadati di migliaia di transazioni nel pool ad ogni passaggio. e ripristinando costantemente il database dello stato. Questa fase, in termini di definizione del collo di bottiglia, è più semplice del livello di rete p2p, perché l'esecuzione delle transazioni e l'algoritmo di consenso sono strettamente deterministici ed è più facile misurare qualsiasi cosa qui.
La cosa principale è non confondere il degrado casuale nelle prestazioni di questa fase con problemi di rete: i nodi sono più lenti nel fornire blocchi e informazioni sulla catena principale e per un client esterno questa può sembrare una rete lenta, sebbene il problema risieda in un posto completamente diverso.

Per ottimizzare le prestazioni in questa fase, è utile raccogliere e monitorare le metriche provenienti dai nodi stessi, e includere in essi quelle relative all'aggiornamento del database-stato: il numero di blocchi elaborati sul nodo, la loro dimensione, il numero di transazioni, il numero di passaggi tra le ramificazioni della catena, il numero di blocchi non validi, il tempo di funzionamento della macchina virtuale, il tempo di commit dei dati, ecc. Ciò impedirà che i problemi di rete vengano confusi con errori negli algoritmi di elaborazione della catena.

Una macchina virtuale che elabora transazioni può essere un’utile fonte di informazioni in grado di ottimizzare il funzionamento della blockchain. Il numero di allocazioni di memoria, il numero di istruzioni di lettura/scrittura e altri parametri relativi all'efficienza dell'esecuzione del codice del contratto possono fornire molte informazioni utili agli sviluppatori. Allo stesso tempo, i contratti intelligenti sono programmi, il che significa che in teoria possono consumare qualsiasi risorsa: CPU/memoria/rete/storage, quindi l'elaborazione delle transazioni è una fase piuttosto incerta, che, inoltre, cambia notevolmente quando si passa da una versione all'altra e quando si modificano i codici contratto. Pertanto, sono necessari anche parametri relativi all’elaborazione delle transazioni per ottimizzare in modo efficace le prestazioni della blockchain.

Ricezione da parte del cliente di una notifica relativa all'inclusione di una transazione nella blockchain

Questa è la fase finale in cui il client blockchain riceve il servizio; rispetto alle altre fasi non ci sono grossi costi generali, ma è comunque opportuno considerare la possibilità che il client riceva una risposta voluminosa dal nodo (ad esempio uno smart contract restituendo un array di dati). In ogni caso, questo punto è il più importante per chi ha posto la domanda “quanti tps ci sono nella tua blockchain?”, perché In questo momento viene registrata l'ora di ricezione del servizio.

In questo luogo, c'è sempre l'invio dell'intero tempo che il cliente ha dovuto trascorrere in attesa di una risposta dalla blockchain; è questo tempo che l'utente attenderà la conferma nella sua applicazione, ed è la sua ottimizzazione che è il punto compito principale degli sviluppatori.

conclusione

Di conseguenza, possiamo descrivere i tipi di operazioni eseguite sulle blockchain e dividerle in diverse categorie:

trasformazioni crittografiche, costruzione di prove
networking peer-to-peer, transazione e replica a blocchi
elaborazione delle transazioni, esecuzione di contratti intelligenti
applicare modifiche nella blockchain al database statale, aggiornare i dati su transazioni e blocchi
richieste di sola lettura al database statale, API del nodo blockchain, servizi di abbonamento

In generale, i requisiti tecnici per i moderni nodi blockchain sono estremamente seri: CPU veloci per la crittografia, una grande quantità di RAM per archiviare e accedere rapidamente al database statale, interazione di rete utilizzando un gran numero di connessioni aperte contemporaneamente e ampio spazio di archiviazione. Requisiti così elevati e l'abbondanza di diversi tipi di operazioni portano inevitabilmente al fatto che i nodi potrebbero non avere risorse sufficienti, e quindi qualsiasi fase sopra discussa può diventare un altro collo di bottiglia per le prestazioni complessive della rete.

Quando progetti e valuti le prestazioni delle blockchain, dovrai tenere conto di tutti questi punti. Per fare ciò è necessario raccogliere e analizzare simultaneamente le metriche dei client e dei nodi della rete, cercare correlazioni tra loro, stimare il tempo necessario per fornire servizi ai client, prendere in considerazione tutte le risorse principali: cpu/memoria/rete/storage , capire come vengono utilizzati e influenzarsi a vicenda. Tutto ciò rende il confronto delle velocità di diverse blockchain sotto forma di “quanti TPS” un compito estremamente ingrato, poiché esiste un numero enorme di configurazioni e stati diversi. Nei grandi sistemi centralizzati, cluster di centinaia di server, questi problemi sono anche complessi e richiedono anche la raccolta di un gran numero di parametri diversi, ma nelle blockchain, a causa delle reti p2p, delle macchine virtuali che elaborano i contratti, delle economie interne, del numero di gradi di libertà è molto maggiore, il che rende il test anche su più server, non è indicativo e mostra solo valori estremamente approssimativi che non hanno quasi alcun collegamento con la realtà.

Pertanto, quando sviluppiamo nel core blockchain, per valutare le prestazioni e rispondere alla domanda “è migliorato rispetto all’ultima volta?” utilizziamo un software piuttosto complesso che orchestra il lancio di una blockchain con decine di nodi e lancia automaticamente un benchmark e raccoglie parametri ; senza queste informazioni è estremamente difficile eseguire il debug di protocolli che funzionano con più partecipanti.

Quindi, quando ricevi la domanda “quanti TPS ci sono nella tua blockchain?”, offri del tè al tuo interlocutore e chiedigli se è pronto a guardare una dozzina di grafici e anche ad ascoltare tutte e tre le caselle di problemi di performance della blockchain e i tuoi suggerimenti per risolvendoli...

Fonte: habr.com

Quanti TPS ci sono sulla tua blockchain?