Una delle domande più comuni che un non tecnico fa su qualsiasi sistema distribuito è "Qual è il tuo tps nel blockchain?" Tuttavia, il numero menzionato in risposta di solito ha poco a che fare con ciò che il richiedente desidera sentire. In realtà, volevano chiedere "il tuo blockchain soddisfa i miei requisiti aziendali?", e questi requisiti non sono un singolo numero, ma una serie di condizioni: dal livello di tolleranza ai guasti della rete, alle necessità di finalità, alle dimensioni, alla natura delle transazioni e a molti altri parametri. Quindi la risposta alla domanda "quanti tps?" difficilmente sarà semplice e quasi mai sarà completa. Un sistema distribuito con dozzine o centinaia di nodi che eseguono calcoli piuttosto complessi può trovarsi in un numero enorme di stati diversi, legati allo stato della rete, ai contenuti del blockchain, ai guasti tecnici, ai problemi economici, agli attacchi alla rete e a molte altre ragioni. Le fasi in cui possono sorgere problemi di performance sono diverse rispetto ai servizi tradizionali, e un server di una rete blockchain è un servizio di rete che combina le funzionalità di un database, di un web server e di un client torrent, rendendolo estremamente complesso in termini di profilo di carico su tutti i sottosistemi: processore, memoria, rete, storage.

È emerso che le reti decentralizzate e le blockchain sono un tipo di software piuttosto specifico e poco familiare per gli sviluppatori di software centralizzato. Pertanto, desidero evidenziare aspetti importanti delle prestazioni e della resilienza delle reti decentralizzate, i metodi per misurarle e per identificare i colli di bottiglia. Esamineremo varie problematiche di prestazione che limitano la velocità di fornitura dei servizi agli utenti delle blockchain, evidenziando le peculiarità caratteristiche di questo tipo di software.

Fasi della richiesta di servizio da parte del cliente della blockchain

Для того, чтобы честно говорить о качестве любого более-менее сложного сервиса, нужно учесть не только средние значения, но и максимальные/минимальные, медианы, персентили. Теоретически, можно говорить о 1000 tps в каком-нибудь блокчейне, но если 900 транзакций выполнились с огромной скоростью, а 100 — «зависли» на несколько секунд, то среднее время, собранное по всем транзакциям — это не совсем честная метрика для клиента, который за несколько секунд не смог завершить сделку. Временные «ямы», вызванные пропущенными раундами консенсуса или разделением сети могут сильно испортить сервис, который на тестовых стендах показывал прекрасную производительность.

Чтобы идентифицировать такие bottleneck-и необходимо хорошо понимать этапы, на которых реальный блокчейн может испытывать затруднения при обслуживании пользователей. Давайте опишем цикл доставки и процессинга транзакции, а также получения нового состояния блокчейна, из которого клиент может убедиться, что его транзакция была обработана и учтена.

транзакция формируется на клиенте
транзакция подписывается на клиенте
il cliente seleziona uno dei nodi e invia la propria transazione
il cliente si iscrive per ricevere aggiornamenti sul database di stato del nodo, aspettando i risultati dell'esecuzione della propria transazione
il nodo diffonde la transazione nella rete p2p
uno o più BP (block producer) elaborano 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 recapitato al nodo a cui si rivolge il cliente
il nodo aggiorna il database di stato
il nodo rileva l'aggiornamento relativo al cliente e gli invia una notifica sulla transazione

Esaminiamo più in dettaglio queste fasi e descriviamo i potenziali problemi di performance in ogni fase. A differenza dei sistemi centralizzati, considereremo anche l'esecuzione del codice sui client della rete. Spesso, nel misurare il tps, il tempo di elaborazione delle transazioni viene raccolto dai nodi, e non dai client — questo non è del tutto giusto. Al cliente non importa quanto velocemente un nodo ha elaborato la sua transazione; ciò che conta di più per lui è il momento in cui le informazioni verificate su quella transazione, una volta incluse nella blockchain, gli saranno accessibili. Questa metrica è, in effetti, il tempo di esecuzione della transazione. Ciò significa che diversi client, anche inviando la stessa transazione, possono ottenere tempi completamente diversi, a seconda del canale, del carico e della vicinanza del nodo, e così via. È quindi assolutamente necessario misurare questo tempo sui client, poiché è proprio questo parametro che deve essere ottimizzato.

Preparazione della transazione lato client

Iniziamo dai primi due punti: la transazione è formata e firmata dal cliente. Stranamente, questo può essere un collo di bottiglia nelle prestazioni della blockchain dal punto di vista del cliente. Questo è insolito per i servizi centralizzati, dove tutti i calcoli e le operazioni sui dati sono gestiti da loro, mentre il cliente si limita a inviare una breve richiesta, capace di richiedere un grande volume 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, con compiti computazionali complessi delegati al software del client. Esistono clienti nelle blockchain che possono preparare una sola transazione per un lungo periodo (sto parlando di vari merkle proof, succinct proof, soglie di firma e altre operazioni complesse lato client). Un buon esempio di verifica on-chain leggera e di pesante preparazione della transazione lato client è la prova di appartenenza a un elenco basata su Merkle-tree, ecco. articolo.

Non dimenticate che il codice client non invia semplicemente 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, è saggio emulare il comportamento del codice client nel modo più completo possibile. Anche se nella vostra blockchain ci sono normalmente client leggeri che appongono una normale firma digitale sulla più semplice delle transazioni relative a un asset, con ogni anno, il carico computazionale sul client sta aumentando, gli algoritmi crittografici diventano sempre più robusti e questa parte del processamento potrebbe diventare un significativo collo di bottiglia in futuro. Quindi, fate attenzione e non trascurate la situazione in cui in una transazione della durata di 3,5 secondi, 2,5 secondi vengono spesi per la preparazione e la firma della transazione, e 1 secondo per l'invio alla rete e l'attesa della risposta. Per valutare i rischi di apparizione 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 della sua accettazione nel pool delle transazioni. Questa fase è simile a una normale richiesta a un database, il nodo deve registrare la transazione nel pool e iniziare a diffondere l'informazione tramite la rete p2p. L'approccio alla valutazione delle prestazioni qui è simile a quello dei tradizionali microservizi Web API, con transazioni nelle blockchain che possono essere aggiornate e cambiare stato attivamente. In generale, l'aggiornamento delle informazioni sulla transazione in alcune blockchain può verificarsi più volte, ad esempio, a seguito di cambiamenti tra fork della catena o quando i BP segnalano l'intenzione di includere la transazione in un blocco. Le limitazioni sulla dimensione di questo pool e sul numero di transazioni in esso possono influenzare le prestazioni della blockchain. Se il pool delle transazioni è saturo fino alla massima capacità possibile, o se non entra in memoria operativa, le prestazioni della rete possono diminuire drasticamente. Le blockchain non dispongono di strumenti centralizzati per proteggersi da flussi di messaggi spazzatura e, se la blockchain supporta transazioni di grande volume e basse commissioni, questo può portare a un sovraccarico del pool delle transazioni — un ulteriore potenziale collo di bottiglia nelle prestazioni.

Nei blockchain, il cliente invia una transazione a qualsiasi nodo del blockchain che preferisce; l'hash della transazione è generalmente noto al cliente prima dell'invio, quindi tutto ciò che deve fare è stabilire una connessione e, dopo la trasmissione, attendere che il blockchain cambi il proprio stato includendo la sua transazione. È importante notare che misurando il 'tps' si possono ottenere risultati completamente diversi a seconda dei vari metodi di connessione al nodo del blockchain. Questo può essere un normale HTTP RPC o WebSocket, che consente di implementare il pattern 'subscribe'. Nel secondo caso, il cliente riceve notifiche prima, e il nodo spende meno risorse (principalmente memoria e traffico) per rispondere allo stato della transazione. Pertanto, nella misurazione del 'tps' è necessario considerare il metodo di connessione dei clienti ai nodi. Di conseguenza, per valutare i rischi di questo bottleneck, il benchmarking del blockchain deve essere in grado di emulare clienti sia con richieste WebSocket che HTTP RPC, in proporzioni che corrispondono a reti reali, oltre a variare la natura delle transazioni e la loro dimensione.

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

Trasmissione di transazioni e blocchi tramite rete p2p

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

In breve, ogni peer in queste reti mantiene la propria lista dinamica di altri peer da cui richiede blocchi di informazioni, indirizzati per contenuto. Al ricevimento di una richiesta, il peer restituisce le informazioni richieste oppure passa la richiesta al prossimo peer pseudo-casuale della lista; una volta ottenuta la risposta, la rimanda a chi ha richiesto e la immagazzina in cache per un certo periodo, fornendo quel blocco informativo più rapidamente la prossima volta. In questo modo, le informazioni popolari si trovano in molte cache di un gran numero di peer, mentre quelle impopolari vengono gradualmente eliminate. I peer tengono traccia di quante informazioni sono state trasferite tra di loro e la rete cerca di incentivare i distributori attivi, aumentando il loro punteggio e fornendo loro un livello di servizio più elevato, escludendo automaticamente i partecipanti inattivi dalle liste dei peer.

Quindi, la transazione deve ora essere propagata nella rete affinché venga vista dai block producer e inclusa nel blocco. Il nodo «distribuisce» attivamente la nuova transazione a chiunque lo desideri e ascolta la rete, in attesa di un blocco in cui apparirà la transazione necessaria, per notificare il cliente in attesa. Il tempo che la rete impiega a scambiarsi informazioni su nuove transazioni e blocchi nelle reti p2p dipende da un gran numero di fattori: il numero di nodi onesti e funzionanti nelle vicinanze (dal punto di vista della rete), il livello di «riscaldamento» 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. Misurare complessivamente le metriche di performance in tali reti è un compito complesso, in quanto è necessario valutare contemporaneamente il tempo di elaborazione delle richieste sia sui client che sui peer (nodi blockchain). Problemi in uno qualsiasi dei meccanismi p2p, l'inserimento errato e la memorizzazione dei dati, la gestione inefficace delle liste di 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.

El processamento della catena di blocchi e l'aggiornamento del database di stato

La parte più importante del funzionamento 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 di stato. L'aggiunta di un nuovo blocco alla catena e la selezione successiva della catena principale devono avvenire il più velocemente possibile. Tuttavia, nella vita reale, 'deve' non significa 'funziona', e si può ad esempio immaginare una situazione in cui due lunghe catene concorrenti si alternano continuamente, cambiando i metadati di migliaia di transazioni nel pool ad ogni alternanza e producendo costanti rollback dello stato del database. Questo passaggio, dal punto di vista dell'identificazione dei colli di bottiglia, è più semplice rispetto al livello p2p di rete, poiché l'esecuzione delle transazioni e l'algoritmo di consenso sono rigorosamente deterministici, e misurare qualsiasi cosa qui è più semplice.
La cosa principale è non confondere la degradazione casuale delle prestazioni di questa fase con i problemi di rete: i nodi restituiscono i blocchi e le informazioni sulla catena principale più lentamente e per il cliente esterno questo può apparire come una rete lenta, mentre il problema si trova in un altro luogo.

Per ottimizzare le prestazioni, è utile raccogliere e monitorare le metriche direttamente dalle nodi, includendo quelle relative all'aggiornamento del database di stato: il numero di blocchi elaborati dal nodo, la loro dimensione, il numero di transazioni, il numero di switch tra fork delle catene, il numero di blocchi non validi, il tempo di funzionamento della macchina virtuale, il tempo di finalizzazione dei dati, ecc. Questo aiuterà a non confondere i problemi di rete con gli errori negli algoritmi di elaborazione delle catene.

La macchina virtuale che elabora 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 di lettura/scrittura e altre metriche relative all'efficienza di esecuzione del codice dei contratti possono fornire molte informazioni preziose agli sviluppatori. Allo stesso tempo, i contratti smart sono programmi e, pertanto, in teoria, possono consumare qualsiasi risorsa: cpu/memoria/rete/memorizzazione, quindi il processo di elaborazione delle transazioni è una fase piuttosto indeterminata che cambia notevolmente con il passaggio tra versioni e con la modifica del codice dei contratti. Pertanto, anche le metriche relative all'elaborazione delle transazioni sono necessarie per un'ottimizzazione efficace delle prestazioni della blockchain.

Ricezione da parte del cliente della notifica di inclusione di una transazione nella blockchain

Questo è l'ultimo stadio per l'ottenimento del servizio blockchain da parte del cliente; rispetto ad altre fasi, qui non ci sono grandi spese generali, ma è comunque importante considerare la possibilità di ricevere una risposta volumetrica dal nodo (ad esempio, un contratto intelligente che restituisce un array di dati). In ogni caso, questo momento è cruciale per chi si chiede «quanti tps ci sono nella vostra blockchain?», poiché è in questo istante che si registra il tempo di ricezione del servizio.

In questo punto è fondamentale inviare il tempo totale che il cliente ha dovuto attendere per ricevere una risposta dalla blockchain; proprio questo tempo è quello che l'utente si aspetterà di vedere confermato nella propria applicazione, e la sua ottimizzazione è la principale responsabilità degli sviluppatori.

Conclusione

Di conseguenza, si possono descrivere i tipi di operazioni che si svolgono nelle blockchain e dividerle in diverse categorie:

trasformazioni crittografiche, costruzione di prove
networking 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 delle informazioni su transazioni e blocchi
richieste in sola lettura al database di stato, nodi API blockchain, servizi di abbonamento

In generale, i requisiti tecnici per i nodi dei moderni blockchain sono estremamente severi: ci vogliono CPU veloci per la crittografia, una grande quantità di memoria RAM per memorizzare e accedere rapidamente al database di stato, un'interazione di rete che utilizzi un gran numero di connessioni aperte contemporaneamente, e uno storage ampio. Queste elevate richieste e la varietà di operazioni comportano inevitabilmente che le risorse dei nodi possano non essere sufficienti, e in tal caso, qualsiasi fase esaminata potrebbe diventare un ulteriore collo di bottiglia per le prestazioni complessive della rete.

Sviluppando e valutando la performance delle blockchain, è necessario tenere in considerazione diversi aspetti. È fondamentale raccogliere e analizzare metriche provenienti sia dai client che dai nodi della rete, cercando correlazioni tra di esse, valutando il tempo di risposta ai clienti, tenendo conto delle risorse principali: CPU, memoria, rete e archiviazione, e comprendendo come queste vengano utilizzate e influenzino reciprocamente. Tutto ciò rende il confronto delle velocità delle diverse blockchain, misurato in "TPS", estremamente complicato, poiché esistono un enorme numero di configurazioni e stati differenti. In grandi sistemi centralizzati, come cluster di centinaia di server, questi problemi sono complessi e richiedono la raccolta di un gran numero di metriche diverse; tuttavia, nelle blockchain, a causa delle reti P2P, delle macchine virtuali, dei contratti intelligenti e dell'economia interna, il numero di gradi di libertà è molto maggiore, rendendo un test anche su pochi server poco rappresentativo e mostrando valori estremamente approssimativi, quasi senza correlazione con la realtà.

Perciò, nello sviluppo del nucleo della blockchain, per valutare le prestazioni e rispondere alla domanda "è migliorato rispetto a prima?" utilizziamo un software piuttosto complesso che orchestra il lancio della blockchain con decine di nodi e avvio automatico dei benchmark e raccolta delle metriche. Senza queste informazioni, è estremamente difficile diagnosticare i protocolli che operano con molti partecipanti.

Quindi, quando ricevete la domanda "quanti TPS ci sono nella vostra blockchain?", offrite un tè al vostro interlocutore e chiedete se è pronto a esaminare una decina di grafici e ad ascoltare tutti e tre i principali problemi di prestazioni delle blockchain e le vostre proposte per risolverli...

Fonte: habr.com