O întrebare favorită despre orice sistem distribuit de la o persoană netehnică este „Câte tps sunt pe blockchain-ul tău?” Cu toate acestea, numărul dat ca răspuns, de obicei, are puține în comun cu ceea ce ar dori să audă cel care a întrebat. De fapt, a vrut să întrebe „se potrivește blockchain-ul tău cu cerințele mele de afaceri” și aceste cerințe nu sunt un număr, ci multe condiții - aici sunt toleranța la erori ale rețelei, cerințele de finalitate, dimensiunile, natura tranzacțiilor și mulți alți parametri. Deci, răspunsul la întrebarea „câte tps” este puțin probabil să fie simplu și aproape niciodată complet. Un sistem distribuit cu zeci sau sute de noduri care efectuează calcule destul de complexe se poate afla într-un număr mare de stări diferite legate de starea rețelei, conținutul blockchain-ului, defecțiuni tehnice, probleme economice, atacuri asupra rețelei și multe alte motive . Etapele în care sunt posibile probleme de performanță diferă de serviciile tradiționale, iar un server de rețea blockchain este un serviciu de rețea care combină funcționalitatea unei baze de date, server web și client torrent, ceea ce îl face extrem de complex în ceea ce privește profilul de încărcare pe toate subsistemele. : procesor, memorie, rețea, stocare

Se întâmplă că rețelele descentralizate și blockchain-urile sunt software destul de specific și neobișnuit pentru dezvoltatorii de software centralizat. Prin urmare, aș dori să evidențiez aspecte importante ale performanței și durabilității rețelelor descentralizate, abordări pentru măsurarea acestora și găsirea blocajelor. Vom analiza diverse probleme de performanță care limitează viteza de furnizare a serviciilor către utilizatorii blockchain și vom observa caracteristicile caracteristice acestui tip de software.

Etapele unei solicitări de servicii de către un client blockchain

Pentru a vorbi sincer despre calitatea oricărui serviciu mai mult sau mai puțin complex, trebuie să țineți cont nu doar de valori medii, ci și de maxim/minim, mediane, percentile. Teoretic, putem vorbi despre 1000 de tps în unele blockchain, dar dacă 900 de tranzacții au fost finalizate cu o viteză enormă, iar 100 au fost „blocate” pentru câteva secunde, atunci timpul mediu colectat pentru toate tranzacțiile nu este o măsură complet corectă pentru un client. pe care nu am putut finaliza tranzacția în câteva secunde. „Gaurile” temporare cauzate de rundele de consens ratate sau de divizarea rețelei pot ruina în mare măsură un serviciu care a demonstrat performanțe excelente pe bancurile de testare.

Pentru a identifica astfel de blocaje, este necesar să avem o bună înțelegere a etapelor în care un blockchain real poate avea dificultăți în deservirea utilizatorilor. Să descriem ciclul de livrare și procesare a unei tranzacții, precum și obținerea unei noi stări a blockchain-ului, din care clientul poate verifica dacă tranzacția sa a fost procesată și contabilizată.

tranzactia se formeaza pe client
tranzacția este semnată pe client
clientul selectează unul dintre noduri și îi trimite tranzacția sa
clientul se abonează la actualizări ale bazei de date de stat a nodului, așteptând să apară rezultatele tranzacției acestuia
nodul distribuie tranzacția prin rețeaua p2p
mai multe sau un BP (producător de bloc) procesează tranzacții acumulate, actualizând baza de date de stat
BP formează un nou bloc după procesarea numărului necesar de tranzacții
BP distribuie un nou bloc prin rețeaua p2p
noul bloc este livrat la nodul pe care clientul îl accesează
nodul actualizează baza de date de stare
nodul vede actualizarea cu privire la client și îi trimite o notificare de tranzacție

Acum să aruncăm o privire mai atentă asupra acestor etape și să descriem potențialele probleme de performanță în fiecare etapă. Spre deosebire de sistemele centralizate, vom lua în considerare și execuția codului pe clienții de rețea. Destul de des, atunci când se măsoară TPS, timpul de procesare a tranzacției este colectat de la noduri și nu de la client - acest lucru nu este în întregime corect. Clientului nu îi pasă cât de repede și-a procesat nodul tranzacția; cel mai important lucru pentru el este momentul în care informații fiabile despre această tranzacție incluse în blockchain îi devin disponibile. Această măsurătoare este în esență timpul de execuție a tranzacției. Aceasta înseamnă că diferiți clienți, chiar trimițând aceeași tranzacție, pot primi timpi complet diferite, care depind de canal, încărcare și proximitatea nodului etc. Deci este absolut necesar să măsurați acest timp pe clienți, deoarece acesta este parametrul care trebuie optimizat.

Pregătirea unei tranzacții pe partea clientului

Să începem cu primele două puncte: tranzacția este formată și semnată de client. Destul de ciudat, acest lucru poate fi, de asemenea, un blocaj al performanței blockchain din punctul de vedere al clientului. Acest lucru este neobișnuit pentru serviciile centralizate, care preiau toate calculele și operațiunile cu date, iar clientul pur și simplu pregătește o cerere scurtă care poate solicita o cantitate mare de date sau calcule, obținând un rezultat gata făcut. În blockchain-uri, codul clientului devine din ce în ce mai puternic, iar nucleul blockchain-ului devine din ce în ce mai ușor, iar sarcinile de calcul masive sunt de obicei transferate către software-ul client. În blockchains, există clienți care pot pregăti o tranzacție pentru o perioadă destul de lungă (vorbesc despre diverse dovezi merkle, dovezi succinte, semnături de prag și alte operațiuni complexe pe partea clientului). Un bun exemplu de verificare ușoară în lanț și pregătire grea a unei tranzacții asupra clientului este dovada apartenenței la o listă bazată pe Merkle-tree, aici articol.

De asemenea, nu uitați că codul clientului nu trimite pur și simplu tranzacții către blockchain, ci mai întâi interogează starea blockchainului - iar această activitate poate afecta aglomerația rețelei și a nodurilor blockchain. Deci, atunci când se efectuează măsurători, ar fi rezonabil să se emuleze cât mai complet comportamentul codului clientului. Chiar dacă în blockchain-ul tău există clienți ușoare obișnuiți care pun o semnătură digitală obișnuită pe cea mai simplă tranzacție pentru a transfera un activ, în fiecare an există încă calcule mai masive asupra clientului, algoritmii cripto devin mai puternici, iar această parte a procesării poate se transformă într-un blocaj semnificativ în viitor. Prin urmare, fiți atenți și nu ratați situația când, într-o tranzacție care durează 3.5 secunde, se cheltuiesc 2.5 secunde pentru pregătirea și semnarea tranzacției și 1.0 secunde pentru trimiterea acesteia în rețea și așteptarea unui răspuns. Pentru a evalua riscurile acestui blocaj, trebuie să colectați valori de la mașinile client, și nu doar de la nodurile blockchain.

Trimiterea unei tranzacții și monitorizarea stării acesteia

Următorul pas este să trimiteți tranzacția către nodul blockchain selectat și să primiți starea acceptării acesteia în pool-ul de tranzacții. Această etapă este similară cu un acces obișnuit la baza de date; nodul trebuie să înregistreze tranzacția în pool și să înceapă să distribuie informații despre aceasta prin rețeaua p2p. Abordarea evaluării performanței aici este similară cu evaluarea performanței microserviciilor web API tradiționale, iar tranzacțiile în sine în blockchain pot fi actualizate și își pot schimba în mod activ starea. În general, actualizarea informațiilor despre tranzacții pe unele blockchain-uri poate avea loc de mai multe ori, de exemplu atunci când comutați între fork-uri de lanț sau când BP-urile își anunță intenția de a include o tranzacție într-un bloc. Limitele privind dimensiunea acestui pool și numărul de tranzacții din acesta pot afecta performanța blockchain-ului. Dacă pool-ul de tranzacții este umplut la dimensiunea maximă posibilă sau nu se încadrează în RAM, performanța rețelei poate scădea brusc. Blockchain-urile nu au mijloace centralizate de a se proteja împotriva unui val de mesaje nedorite, iar dacă blockchain-ul acceptă tranzacții de mare volum și comisioane mici, acest lucru poate duce la depășirea pool-ului de tranzacții - un alt potențial blocaj de performanță.

În blockchain, clientul trimite o tranzacție către orice nod blockchain care îi place, hash-ul tranzacției este de obicei cunoscut clientului înainte de trimitere, așa că tot ce trebuie să facă este să realizeze conexiunea și, după transmitere, să aștepte ca blockchain-ul să se schimbe starea acestuia, permițându-i tranzacția. Rețineți că, măsurând „tps”, puteți obține rezultate complet diferite pentru diferite metode de conectare la un nod blockchain. Acesta poate fi un RPC HTTP obișnuit sau un WebSocket care vă permite să implementați modelul de „abonare”. În al doilea caz, clientul va primi o notificare mai devreme, iar nodul va cheltui mai puține resurse (în principal memorie și trafic) pentru răspunsuri despre starea tranzacției. Deci, atunci când se măsoară „tps”, este necesar să se țină cont de modul în care clienții se conectează la noduri. Prin urmare, pentru a evalua riscurile acestui blocaj, blockchain-ul de referință trebuie să fie capabil să emuleze clienții atât cu solicitări WebSocket, cât și cu HTTP RPC, în proporții corespunzătoare rețelelor reale, precum și să modifice natura tranzacțiilor și dimensiunea acestora.

Pentru a evalua riscurile acestui blocaj, trebuie să colectați, de asemenea, valori de la mașinile client, și nu doar de la nodurile blockchain.

Transmiterea tranzacțiilor și a blocurilor prin rețeaua p2p

În blockchain-urile, rețelele peer-to-peer (p2p) sunt folosite pentru a transfera tranzacții și blocuri între participanți. Tranzacțiile se răspândesc în întreaga rețea, pornind de la unul dintre noduri, până ajung la producătorii de blocuri egali, care împachetează tranzacțiile în blocuri și, folosind același p2p, distribuie blocuri noi către toate nodurile rețelei. Baza celor mai moderne rețele p2p este diferitele modificări ale protocolului Kademlia. Aici un rezumat bun al acestui protocol și aici - un articol cu diverse măsurători în rețeaua BitTorrent, din care se poate înțelege că acest tip de rețea este mai complex și mai puțin previzibil decât o rețea configurată rigid a unui serviciu centralizat. De asemenea, aici articol despre măsurarea diferitelor valori interesante pentru nodurile Ethereum.

Pe scurt, fiecare peer din astfel de rețele își menține propria listă dinamică de alți colegi de la care solicită blocuri de informații care sunt adresate de conținut. Când un peer primește o solicitare, fie oferă informațiile necesare, fie transmite solicitarea următorului peer pseudo-aleatoriu din listă și, după ce a primit un răspuns, îl transmite solicitantului și îl memorează în cache pentru un timp, dând acest lucru bloc de informații mai devreme data viitoare. Astfel, informațiile populare ajung într-un număr mare de cache-uri ale unui număr mare de colegi, iar informațiile nepopulare sunt înlocuite treptat. Peers țin evidența cine a transferat câte informații cui, iar rețeaua încearcă să stimuleze distribuitorii activi prin creșterea evaluărilor lor și oferindu-le un nivel mai ridicat de servicii, înlocuind automat participanții inactivi din listele de colegi.

Deci, tranzacția trebuie acum distribuită în întreaga rețea, astfel încât producătorii de blocuri să o poată vedea și să o includă în bloc. Nodul „distribuie” în mod activ o nouă tranzacție tuturor și ascultă rețeaua, așteptând un bloc în indexul căruia va apărea tranzacția necesară pentru a anunța clientul în așteptare. Timpul necesar rețelei pentru a transfera informații despre noile tranzacții și blocuri între ele în rețelele p2p depinde de un număr foarte mare de factori: numărul de noduri cinstite care lucrează în apropiere (din punct de vedere al rețelei), „cald- sus” a cache-urilor acestor noduri, dimensiunea blocurilor, tranzacțiile, natura modificărilor, geografia rețelei, numărul de noduri și mulți alți factori. Măsurătorile complexe ale metricilor de performanță în astfel de rețele sunt o chestiune complexă; este necesar să se evalueze simultan timpul de procesare a cererilor atât pe clienți, cât și pe peer (noduri blockchain). Probleme în oricare dintre mecanismele p2p, evacuarea și stocarea în cache incorectă a datelor, gestionarea ineficientă a listelor de colegi activi și mulți alți factori pot provoca întârzieri care afectează eficiența întregii rețele în ansamblu, iar acest blocaj este cel mai greu de analizat. , testarea și interpretarea rezultatelor.

Procesarea blockchain și actualizarea bazei de date de stat

Cea mai importantă parte a blockchain-ului este algoritmul de consens, aplicarea acestuia la noile blocuri primite din rețea și procesarea tranzacțiilor cu înregistrarea rezultatelor în baza de date de stat. Adăugarea unui nou bloc în lanț și apoi selectarea lanțului principal ar trebui să funcționeze cât mai repede posibil. Cu toate acestea, în viața reală, „ar trebui” nu înseamnă „funcționează”, și ne putem imagina, de exemplu, o situație în care două lanțuri lungi concurente se schimbă constant între ele, schimbând metadatele a mii de tranzacții din pool la fiecare comutare. și derularea constantă a bazei de date de stat. Această etapă, în ceea ce privește definirea blocajului, este mai simplă decât stratul de rețea p2p, deoarece execuția tranzacției și algoritmul de consens sunt strict deterministe și este mai ușor să măsurați orice aici.
Principalul lucru este să nu confundați degradarea aleatorie a performanței acestei etape cu problemele de rețea - nodurile sunt mai lente în furnizarea de blocuri și informații despre lanțul principal, iar pentru un client extern aceasta poate arăta ca o rețea lentă, deși problema constă în un loc complet diferit.

Pentru a optimiza performanța în această etapă, este util să colectăm și să monitorizăm metrici de la nodurile în sine și să le includem pe cele legate de actualizarea bazei de date de stat: numărul de blocuri procesate pe nod, dimensiunea acestora, numărul de tranzacții, numărul de comutări între forkurile de lanț, numărul de blocuri invalide, timpul de funcționare al mașinii virtuale, timpul de comitere a datelor etc. Acest lucru va preveni confundarea problemelor de rețea cu erorile din algoritmii de procesare în lanț.

O mașină virtuală care procesează tranzacțiile poate fi o sursă utilă de informații care poate optimiza funcționarea blockchain-ului. Numărul de alocări de memorie, numărul de instrucțiuni de citire/scriere și alte valori legate de eficiența executării codului contractual pot oferi dezvoltatorilor o mulțime de informații utile. În același timp, contractele inteligente sunt programe, ceea ce înseamnă că teoretic pot consuma oricare dintre resurse: cpu/memorie/rețea/stocare, deci procesarea tranzacțiilor este o etapă destul de incertă, care, în plus, se schimbă foarte mult la trecerea între versiuni. și la schimbarea codurilor contractuale. Prin urmare, sunt necesare și metrici legate de procesarea tranzacțiilor pentru a optimiza eficient performanța blockchain.

Primirea de către client a unei notificări despre includerea unei tranzacții în blockchain

Aceasta este etapa finală în care clientul blockchain primește serviciul; în comparație cu alte etape, nu există costuri generale mari, dar merită totuși luată în considerare posibilitatea ca clientul să primească un răspuns voluminos de la nod (de exemplu, un contract inteligent returnând o serie de date). În orice caz, acest punct este cel mai important pentru cel care a pus întrebarea „câte tps sunt în blockchain-ul tău?”, deoarece În acest moment se înregistrează ora primirii serviciului.

În acest loc, există întotdeauna o trimitere a timpului complet pe care clientul a trebuit să-l petreacă așteptând un răspuns de la blockchain; de această dată utilizatorul va aștepta confirmarea în aplicația sa și optimizarea acesteia este cea care este sarcina principală a dezvoltatorilor.

Concluzie

Drept urmare, putem descrie tipurile de operațiuni efectuate pe blockchain și le putem împărți în mai multe categorii:

transformări criptografice, construcție de dovezi
rețele peer-to-peer, tranzacții și replicare în bloc
procesarea tranzacțiilor, executarea de contracte inteligente
aplicarea modificărilor din blockchain la baza de date de stat, actualizarea datelor privind tranzacțiile și blocurile
solicitări numai în citire către baza de date de stat, API-ul nodului blockchain, servicii de abonament

În general, cerințele tehnice pentru nodurile blockchain moderne sunt extrem de serioase - procesoare rapide pentru criptare, o cantitate mare de RAM pentru stocarea și accesarea rapidă a bazei de date de stat, interacțiunea cu rețea folosind un număr mare de conexiuni deschise simultan și stocare mare. Asemenea cerințe ridicate și abundența diferitelor tipuri de operațiuni duc inevitabil la faptul că nodurile pot să nu aibă suficiente resurse, iar apoi oricare dintre etapele discutate mai sus poate deveni un alt blocaj pentru performanța generală a rețelei.

Atunci când proiectați și evaluați performanța blockchain-urilor, va trebui să luați în considerare toate aceste puncte. Pentru a face acest lucru, trebuie să colectați și să analizați metrici simultan de la clienți și nodurile de rețea, să căutați corelații între ele, să estimați timpul necesar pentru a furniza servicii clienților, să luați în considerare toate resursele principale: cpu/memorie/rețea/stocare , înțelegeți cum sunt folosite și se influențează reciproc. Toate acestea fac ca compararea vitezelor diferitelor blockchain-uri sub forma „câte TPS” este o sarcină extrem de ingrată, deoarece există un număr mare de configurații și stări diferite. În sistemele mari centralizate, clustere de sute de servere, aceste probleme sunt și ele complexe și necesită, de asemenea, colectarea unui număr mare de metrici diferite, dar în blockchain, datorită rețelelor p2p, a contractelor de procesare a mașinilor virtuale, a economiilor interne, a numărului de grade. al libertății este mult mai mare, ceea ce face ca testul chiar și pe mai multe servere să fie neindicativ și arată doar valori extrem de aproximative care nu au aproape nicio legătură cu realitatea.

Prin urmare, atunci când dezvoltăm în nucleul blockchain, pentru a evalua performanța și a răspunde la întrebarea „s-a îmbunătățit față de data trecută?”, folosim un software destul de complex care orchestrează lansarea unui blockchain cu zeci de noduri și lansează automat un benchmark și colectează valori. ; fără aceste informații este extrem de dificil să depanați protocoalele care funcționează cu mai mulți participanți.

Așadar, când primiți întrebarea „câte TPS sunt în blockchain-ul dvs.?”, oferiți interlocutorului un ceai și întrebați-l dacă este gata să se uite la o duzină de grafice și, de asemenea, ascultați toate cele trei casete cu probleme de performanță blockchain și sugestiile dvs. pentru rezolvandu-le...

Sursa: www.habr.com

Câte TPS sunt pe blockchain-ul tău?