Una quistione preferita nantu à qualsiasi sistema distribuitu da una persona non tecnica hè "Quanti tps sò in u vostru blockchain?" In ogni casu, u numeru datu in risposta di solitu hà pocu in cumunu cù ciò chì l'interrogatori piacerebbe sente. In fatti, hà vulsutu dumandà "a vostra blockchain si adatta à i mo bisogni di l'affari", è queste esigenze ùn sò micca un numeru, ma assai cundizioni - quì sò a toleranza di a reta di a reta, i requisiti di finalità, dimensioni, a natura di e transazzione è parechji altri parametri. Allora a risposta à a quistione "quantu tps" hè improbabile di esse simplice, è quasi mai cumpletu. Un sistema distribuitu cù decine o cintunari di nodi chì realizanu calculi abbastanza cumplessi pò esse in un gran numaru di stati diffirenti ligati à u statu di a reta, u cuntenutu di u blockchain, fallimenti tecnichi, prublemi ecunomichi, attacchi à a reta è parechje altre ragioni. . I tappe in quale i prublemi di rendiment sò pussibuli differenu da i servizii tradiziunali, è un servitore di rete di blockchain hè un serviziu di rete chì combina a funziunalità di una basa di dati, servitore web è cliente torrent, chì a rende estremamente cumplessa in quantu à u prufilu di carica in tutti i sottosistemi. : processore, memoria, reta, almacenamiento

Hè cusì chì e rete decentralizate è blockchains sò un software abbastanza specificu è inusual per i sviluppatori di software centralizzati. Per quessa, vogliu mette in risaltu aspetti impurtanti di u funziunamentu è a sustenibilità di e rete decentralizate, l'avvicinamenti à a misurazione è à truvà i colli di bottiglia. Fighjemu diversi prublemi di rendiment chì limitanu a velocità di furnisce servizii à l'utilizatori di blockchain è nutate e caratteristiche caratteristiche di stu tipu di software.

Fasi di una dumanda di serviziu da un cliente blockchain

Per parlà onestamente di a qualità di qualsiasi serviziu più o menu cumplessu, avete bisognu di piglià in contu micca solu i valori mediu, ma ancu u massimu / minimu, mediani, percentili. Teoricamente, pudemu parlà di 1000 tps in certi blockchain, ma se 900 transacciones sò stati cumpletati cù una velocità enormosa, è 100 sò stati "stuck" per uni pochi di sicondi, allura u tempu mediu recullatu nantu à tutte e transazzione ùn hè micca una metrica cumpletamente ghjustu per un cliente. chì ùn aghju micca pussutu compie a transazzione in pochi seconde. I "buchi" tempuranei causati da round di cunsensu mancati o splits di rete ponu arruvinà assai un serviziu chì hà dimustratu un rendimentu eccellente nantu à i banchi di prova.

Per identificà tali bottlenecks, hè necessariu avè una bona cunniscenza di e tappe in quale un veru bluccatu pò avè difficultà à serve l'utilizatori. Fighjemu u ciculu di a consegna è a trasfurmazioni di una transazzione, è ancu di ottene un novu statu di u blockchain, da quale u cliente pò verificà chì a so transazzione hè stata trattata è contabilizzata.

a transazzione hè furmatu nantu à u cliente
a transazzione hè firmata nantu à u cliente
u cliente sceglie unu di i nodi è manda a so transazzione à questu
u cliente sottumette à l'aghjurnamenti di a basa di dati statali di u node, aspittendu chì i risultati di a so transazzione appariscenu
u node distribuisce a transazzione nantu à a reta p2p
parechji o unu BP (produttore di blocchi) prucessa transazzione accumulate, aghjurnà a basa di dati statali
BP forma un novu bloccu dopu à trasfurmà u numeru necessariu di transacciones
BP distribuisce un novu blocu nantu à a reta p2p
u novu bloccu hè mandatu à u node chì u cliente accede
node aghjurnà a basa di dati statali
u node vede l'aghjurnamentu riguardanti u cliente è li manda una notificazione di transazzione

Avà fighjemu un ochju più vicinu à queste tappe è descrivimu i prublemi di rendiment potenziale in ogni tappa. A cuntrariu di i sistemi centralizzati, cunsideremu ancu l'esekzione di codice nantu à i clienti di a rete. Piuttostu spessu, quandu si misurà TPS, u tempu di prucessu di transazzione hè recullatu da i nodi, è micca da u cliente - questu ùn hè micca ghjustu. U cliente ùn importa micca quantu rapidamente u node hà processatu a so transazzione; u più impurtante per ellu hè u mumentu chì l'infurmazioni affidabili nantu à sta transazzione inclusa in u blockchain diventanu dispunibili per ellu. Hè sta metrica chì hè essenzialmente u tempu d'esekzione di transazzione. Questu significa chì i clienti diffirenti, ancu mandendu a listessa transazzione, ponu riceve tempi completamente differenti, chì dependenu di u canali, a carica è a vicinanza di u node, etc. Dunque hè assolutamente necessariu di misurà stu tempu nantu à i clienti, postu chì questu hè u paràmetru chì deve esse ottimizatu.

Preparazione di una transazzione da u cliente

Cuminciamu cù i primi dui punti: a transazzione hè furmata è firmata da u cliente. Curiosamente, questu pò ancu esse un collu di buttiglia di u rendiment di blockchain da u puntu di vista di u cliente. Questu hè inusual per i servizii centralizati, chì ripiglià tutti i calculi è l'operazioni cù dati, è u cliente solu prepara una breve dumanda chì pò dumandà una grande quantità di dati o calculi, ottenendu un risultatu prontu. In i blockchains, u codice di u cliente diventa più è più putente, è u core blockchain diventa più è più ligeru, è i travaglii di computing massivi sò generalmente trasferiti à u software di u cliente. In i blockchains, ci sò i clienti chì ponu preparà una transazzione per un bellu pezzu (parlu di diverse prove di merkle, prove succinct, signatures di soglia è altre operazioni cumplesse da u cliente). Un bon esempiu di verificazione faciule in a catena è a preparazione pesante di una transazzione nantu à u cliente hè una prova di appartenenza à una lista basatu in Merkle-tree, quì un articulu.

Inoltre, ùn vi scurdate micca chì u codice di u cliente ùn hè micca solu mandà transazzione à u blockchain, ma prima dumanda u statu di u blockchain - è sta attività pò influenzà a congestione di a rete è i nodi di blockchain. Allora, quandu pigliate e misurazioni, saria ragiunate per emulà u cumpurtamentu di u codice di u cliente cum'è pussibule. Ancu s'è in u vostru blockchain ci sò clienti di luce ordinariu chì mettenu una firma digitale regulare nantu à a transazzione più simplice per trasfirià qualchì attivu, ogni annu ci sò ancu calculi più massivi nantu à u cliente, l'algoritmi di criptu sò diventati più forti, è sta parte di u prucessu pò esse. diventerà un collu di bottiglia significativu in u futuru. Dunque, attentu è ùn mancate micca a situazione quandu, in una transazzione chì dura 3.5s, 2.5s sò spesi per preparà è firmà a transazzione, è 1.0s per mandà à a reta è aspittendu una risposta. Per valutà i risichi di stu collu di bottiglia, avete bisognu di cullà metriche da e macchine di u cliente, è micca solu da i nodi di blockchain.

Mandà una transazzione è monitorizà u so statutu

U prossimu passu hè di mandà a transazzione à u node bluccatu sceltu è riceve u statutu di accettà in u pool di transazzione. Questa tappa hè simile à un accessu regulare à a basa di dati; u node deve registrà a transazzione in a piscina è cumincià à distribuisce infurmazioni nantu à questu attraversu a reta p2p. L'approcciu di evaluà u rendiment quì hè simile à a valutazione di u rendiment di i microservizi tradiziunali di l'API Web, è e transazzioni stessi in blockchains ponu esse aghjurnati è cambianu attivamente u so status. In generale, l'aghjurnà l'infurmazioni di transazzione nantu à certi blockchains pò accade parechje volte, per esempiu quandu si cambia trà e forche di a catena o quandu i BP annunzianu a so intenzione di include una transazzione in un bloccu. Limiti nantu à a dimensione di sta piscina è u numeru di transazzione in questu pò influenzà u rendiment di u blockchain. Se u pool di transazzione hè pienu à a dimensione massima pussibule, o ùn si mette in RAM, u rendiment di a rete pò calà bruscamente. Blockchains ùn anu micca un mezzu centralizatu di prutezzione contru una inundazione di messagi junk, è se u blockchain supporta transacciones à voluminu elevatu è tariffi bassi, questu pò causà a piscina di transazzione per overflow - un altru putenziale scontru di u rendiment.

In blockchain, u cliente manda una transazzione à qualsiasi node blockchain chì li piace, l'hash di a transazzione hè di solitu cunnisciutu da u cliente prima di mandà, cusì tuttu ciò chì deve fà hè di ottene a cunnessione è, dopu a trasmissione, aspittà chì u blockchain cambie. u so statu, chì permette a so transazzione. Innota chì misurà "tps" pudete ottene risultati completamente differenti per diversi metudi di cunnessione à un node blockchain. Questu pò esse un RPC HTTP regulare o un WebSocket chì permette di implementà u mudellu "subscribe". In u sicondu casu, u cliente riceverà una notificazione prima, è u node spende menu risorse (principalmente memoria è trafficu) in risposti nantu à u statu di transazzione. Allora quandu si misurà "tps" hè necessariu di piglià in contu a manera chì i clienti cunnetta à i nodi. Per quessa, per valutà i risichi di stu bottleneck, u blockchain benchmark deve esse capace di emulà i clienti cù dumande WebSocket è HTTP RPC, in proporzioni chì currispondenu à e rete reale, è ancu cambià a natura di e transazzione è a so dimensione.

Per valutà i risichi di stu collu di bottiglia, avete ancu bisognu di cullà metriche da e macchine di u cliente, è micca solu da i nodi di blockchain.

Trasmissione di transazzione è blocchi via rete p2p

In i blockchains, a rete di peer-to-peer (p2p) hè utilizata per trasfiriri transacciones è blocchi trà i participanti. E transazzione sparghje in tutta a reta, partendu da unu di i nodi, finu à chì ghjunghjenu à i pruduttori di peer block, chì imballanu transacciones in blocchi è, cù u listessu p2p, distribuiscenu novi blocchi à tutti i nodi di rete. A basa di a maiò parte di e rete p2p muderni sò diverse mudificazioni di u protocolu Kademlia. quì un bon riassuntu di stu protokollu, è eccu - un articulu cù diverse misurazioni in a reta BitTorrent, da quale si pò capisce chì stu tipu di rete hè più cumplessu è menu prevedibile chì una reta cunfigurata rigidamente di un serviziu centralizatu. Inoltre, eccu articulu nantu à a misurazione di diverse metriche interessanti per i nodi Ethereu.

In corta, ogni peer in such networks mantene a so propria lista dinamica di altri pari da quale dumanda blocchi di informazioni chì sò indirizzati da u cuntenutu. Quandu un peer riceve una dumanda, o dà l'infurmazioni necessarii o passa a dumanda à u prossimu peer pseudo-aleatoriu da a lista, è avè ricevutu una risposta, a trasmette à u richiedente è a cache per un tempu, dendu questu. bloccu di informazioni prima a prossima volta. Cusì, l'infurmazioni populari finiscinu in un gran numaru di cache di un gran numaru di pari, è l'infurmazione impopulare hè gradualmente rimpiazzata. Peers mantenenu registri di quale hà trasferitu quantu infurmazione à quale, è a reta prova di stimulà i distributori attivi aumentendu e so valutazioni è furnisce un livellu più altu di serviziu, automaticamente i participanti inattivi da i listi di pari.

Allora, a transazzione avà deve esse distribuita in tutta a reta per chì i pruduttori di blocchi ponu vede è includenu in u bloccu. U node attivamente "distribuisce" una nova transazzione à tutti è sente à a reta, aspittendu un bloccu in l'indici di quale a transazzione necessaria apparirà per avvisà u cliente chì aspetta. U tempu chì ci vole à a reta per trasfiriri l'infurmazioni nantu à e novi transazzioni è blocchi à l'altri in e rete p2p dipende da un gran numaru di fatturi: u numeru di nodi onesti chì travaglianu vicinu (da u puntu di vista di a rete), u "caldo- up" di i cache di sti nodi, a dimensione di blocchi, transazzione, a natura di i cambiamenti, a geografia di a rete, u numeru di nodi è parechji altri fattori. E misurazioni cumplesse di metriche di prestazione in tali reti sò una materia cumplessa; hè necessariu valutà simultaneamente u tempu di trasfurmazione di e richieste sia nantu à i clienti sia i pari (nodi blockchain). I prublemi in qualsiasi di i meccanismi p2p, eviction di dati incorrecte è caching, gestione inefficace di listi di pari attivi, è parechji altri fattori ponu causà ritardi chì affettanu l'efficienza di a reta sana in tuttu, è questu collu di bottiglia hè u più difficiuli di analizà. , prova è interpretazione di i risultati.

Trattamentu di Blockchain è aghjurnamentu di basa di dati statali

A parte più impurtante di u blockchain hè l'algoritmu di cunsensu, a so applicazione à i novi blocchi ricivuti da a reta è u trattamentu di e transazzione cù a registrazione di i risultati in a basa di dati statali. Aghjunghjendu un novu blocu à a catena è dopu selezziunate a catena principale deve travaglià u più prestu pussibule. Tuttavia, in a vita reale, "duverebbe" ùn significheghja micca "opere", è unu pò, per esempiu, imagine una situazione induve duie catene longu in competizione si cambianu constantemente trà elli, cambiendu i metadati di millaie di transazzioni in a piscina à ogni switch. , è rinfriscà constantemente a basa di dati statali. Questa tappa, in quantu à definisce u collu di buttiglia, hè più simplice di a capa di rete p2p, perchè L'esekzione di transazzione è l'algoritmu di cunsensu sò strettamente deterministichi, è hè più faciule per misurà qualcosa quì.
A cosa principal ùn hè micca cunfundà a degradazione aleatoria in u funziunamentu di sta tappa cù i prublemi di rete - i nodi sò più lenti in a consegna di blocchi è infurmazioni nantu à a catena principale, è per un cliente esternu questu pò esse cum'è una reta lenta, ancu s'ellu u prublema si trova in un locu completamente diversu.

Per ottimisà u rendiment in questa fase, hè utile per cullà è monitorà e metriche da i nodi stessi, è includenu in elli quelli chì sò ligati à l'aghjurnamentu di a basa di dati statali: u numeru di blocchi processati nantu à u node, a so dimensione, u numeru di transazzione, u numeru di scambii trà e forche di a catena, u numeru di blocchi invalidi, u tempu di funziunamentu di a macchina virtuale, u tempu di cummissione di dati, etc. Questu impedisce chì i prublemi di a rete ùn sò cunfunditi cù l'errori in l'algoritmi di trasfurmazioni di a catena.

Una transazzione di trasfurmazioni di macchina virtuale pò esse una fonte utile d'infurmazioni chì ponu ottimisà l'operazione di u blockchain. U numeru di assignazioni di memoria, u numeru di struzzioni di lettura / scrittura, è altre metriche ligati à l'efficienza di l'esekzione di u codice di u cuntrattu ponu furnisce assai infurmazioni utili à i sviluppatori. À u listessu tempu, i cuntratti intelligenti sò prugrammi, chì significa chì in teoria ponu cunsumà qualsiasi risorse: cpu/memoria/rete/almacenamiento, cusì u prucessu di transazzione hè un stadiu piuttostu incertu, chì, in più, cambia assai quandu si move trà e versioni. è quandu cambiate i codici di u cuntrattu. Dunque, e metriche relative à u processu di transazzione sò ancu necessarii per ottimisà in modu efficace u rendiment di blockchain.

Ricevuta da u cliente di una notificazione nantu à l'inclusione di una transazzione in u blockchain

Questa hè a tappa finale di u cliente di blockchain chì riceve u serviziu; cumparatu cù l'altri tappe, ùn ci sò micca grandi costi di sopra, ma vale a pena cunsiderà a pussibilità di u cliente riceve una risposta voluminosa da u node (per esempiu, un cuntrattu intelligente). riturnà una matrice di dati). In ogni casu, questu puntu hè u più impurtante per quellu chì hà dumandatu a quistione "quantu tps sò in u vostru blockchain?", perchè À questu mumentu, u tempu di riceve u serviziu hè registratu.

In questu locu, ci hè sempre un inviu di u tempu pienu chì u cliente hà da passà aspittendu una risposta da u blockchain; hè questu tempu chì l'utilizatore aspetta per a cunferma in a so applicazione, è hè a so ottimisazione chì hè u compitu principale di i sviluppatori.

cunchiusioni

In u risultatu, pudemu discrive i tipi d'operazioni realizati nantu à blockchains è dividite in parechje categurie:

trasfurmazioni criptografiche, custruzzione di prova
rete peer-to-peer, transazzione è replicazione di blocchi
Trattamentu di transazzione, esecuzione di cuntratti intelligenti
applicà cambiamenti in u blockchain à a basa di dati statali, aghjurnà e dati nantu à e transazzione è i blocchi
richieste di sola lettura à a basa di dati statali, API di nodi di blockchain, servizii di abbonamentu

Вообще технические требования к нодам современных блокчейнов крайне серьезные — это быстрые CPU для криптографии, большой объем оперативной памяти для того, чтобы хранить и быстро обращаться к state database, сетевое взаимодействие, использующее большое число одновременно открытых соединений, объемный storage. Такие высокие требования и обилие различных типов операций неизбежно приводят к тому, что ресурсов у нод может не хватать, и, тогда любой из рассмотренных выше этапов может стать очередным bottleneck-ом для общей производительности сети.

Quandu u disignu è a valutazione di u rendiment di i blockchains, avete da piglià in contu tutti questi punti. Per fà questu, avete bisognu di cullà è analizà e metriche simultaneamente da i clienti è i nodi di rete, cercate correlazioni trà elli, stimate u tempu chì ci vole à furnisce servizii à i clienti, piglià in contu tutte e risorse principali: cpu / memoria / rete / almacenamiento. , capisce cumu si sò usati è influenzanu l'altri. Tuttu chistu face paragunà e velocità di diverse blockchains in a forma di "quantu TPS" un compitu estremamente ingrate, postu chì ci sò un gran numaru di cunfigurazioni è stati diffirenti. In grandi sistemi centralizati, clusters di centinaie di servitori, sti prublemi sò ancu cumplessi è ancu esse bisognu di a cullizzioni di un gran numaru di metriche diffirenti, ma in blockchains, per via di rete p2p, cuntratti di trasfurmazioni di macchine virtuali, ecunumia interna, u numeru di gradi. di libertà hè assai più grande, chì face a prova ancu in parechji servitori, ùn hè micca indicativu è mostra solu valori estremamente apprussimativi chì ùn anu quasi nisuna cunnessione cù a realità.

Dunque, quandu si sviluppa in u core blockchain, per valutà u rendiment è risponde à a quistione "hà migliuratu in paragunà à l'ultima volta?" Utilizemu un software abbastanza cumplessu chì orchestra u lanciamentu di una blockchain cù decine di nodi è lancia automaticamente un benchmark è raccoglie metriche. ; senza questa informazione hè estremamente difficiule di debug protokolli chì travaglianu cù parechji participanti.

Allora, quandu avete ricevutu a quistione "quantu TPS sò in u vostru blockchain?", offre à u vostru interlocutore un tè è dumandate s'ellu hè prontu à guardà una decina di grafici è ancu à sente à tutti i trè scatuli di prublemi di rendiment di blockchain è i vostri suggerimenti per risolvili...

Source: www.habr.com

Quanti TPS sò nantu à a vostra blockchain?