Një pyetje e preferuar për çdo sistem të shpërndarë nga një person jo teknik është "Sa tps ka në blockchain tuaj?" Megjithatë, numri i dhënë në përgjigje zakonisht ka pak të përbashkëta me atë që pyetësi do të dëshironte të dëgjonte. Në fakt, ai donte të pyeste "a do t'i përshtatet blockchain-i juaj kërkesat e biznesit tim," dhe këto kërkesa nuk janë një numër, por shumë kushte - këtu janë toleranca e gabimeve të rrjetit, kërkesat e finalitetit, madhësitë, natyra e transaksioneve dhe shumë parametra të tjerë. Pra, përgjigja e pyetjes "sa tps" nuk ka gjasa të jetë e thjeshtë dhe pothuajse asnjëherë e plotë. Një sistem i shpërndarë me dhjetëra ose qindra nyje që kryejnë llogaritje mjaft komplekse mund të jetë në një numër të madh gjendjesh të ndryshme që lidhen me gjendjen e rrjetit, përmbajtjen e blockchain, dështimet teknike, problemet ekonomike, sulmet në rrjet dhe shumë arsye të tjera. . Fazat në të cilat problemet e performancës janë të mundshme ndryshojnë nga shërbimet tradicionale, dhe një server rrjeti blockchain është një shërbim rrjeti që kombinon funksionalitetin e një baze të dhënash, një server në internet dhe një klient torrent, gjë që e bën atë jashtëzakonisht kompleks për sa i përket profilit të ngarkesës në të gjitha nënsistemet. : procesor, memorie, rrjet, memorie

Ndodh që rrjetet e decentralizuara dhe blockchains janë softuer mjaft specifik dhe i pazakontë për zhvilluesit e centralizuar të softuerëve. Prandaj, do të doja të nënvizoja aspekte të rëndësishme të performancës dhe qëndrueshmërisë së rrjeteve të decentralizuara, qasjet për matjen e tyre dhe gjetjen e pengesave. Ne do të shqyrtojmë çështje të ndryshme të performancës që kufizojnë shpejtësinë e ofrimit të shërbimeve për përdoruesit e blockchain dhe do të vërejmë veçoritë karakteristike të këtij lloji të softuerit.

Fazat e një kërkese shërbimi nga një klient blockchain

Për të folur me ndershmëri për cilësinë e çdo shërbimi pak a shumë kompleks, duhet të keni parasysh jo vetëm vlerat mesatare, por edhe maksimum/minimum, mediana, përqindje. Teorikisht, mund të flasim për 1000 tps në disa blockchain, por nëse 900 transaksione u kryen me shpejtësi të madhe dhe 100 ishin "ngecur" për disa sekonda, atëherë koha mesatare e mbledhur mbi të gjitha transaksionet nuk është një metrikë plotësisht e drejtë për një klient. të cilët nuk mund ta kryeja transaksionin në pak sekonda. "Vrimat" e përkohshme të shkaktuara nga raundet e humbura të konsensusit ose ndarjet e rrjetit mund të shkatërrojnë shumë një shërbim që ka treguar performancë të shkëlqyer në stolat e testimit.

Për të identifikuar pengesa të tilla, është e nevojshme të keni një kuptim të mirë të fazave në të cilat një blockchain i vërtetë mund të ketë vështirësi në shërbimin e përdoruesve. Le të përshkruajmë ciklin e dorëzimit dhe përpunimit të një transaksioni, si dhe marrjen e një gjendjeje të re të blockchain, nga e cila klienti mund të verifikojë që transaksioni i tij është përpunuar dhe kontabilizuar.

transaksioni formohet mbi klientin
transaksioni nënshkruhet tek klienti
klienti zgjedh një nga nyjet dhe i dërgon transaksionin e tij
klienti pajtohet në përditësimet e bazës së të dhënave shtetërore të nyjës, duke pritur që të shfaqen rezultatet e transaksionit të tij
nyja shpërndan transaksionin në rrjetin p2p
disa ose një BP (prodhues blloku) përpunon transaksionet e akumuluara, duke përditësuar bazën e të dhënave shtetërore
BP formon një bllok të ri pasi përpunon numrin e kërkuar të transaksioneve
BP shpërndan një bllok të ri mbi rrjetin p2p
blloku i ri dorëzohet në nyjen që klienti po i qaset
nyja përditëson bazën e të dhënave të gjendjes
nyja sheh përditësimin në lidhje me klientin dhe i dërgon atij një njoftim transaksioni

Tani le t'i hedhim një vështrim më të afërt këtyre fazave dhe të përshkruajmë problemet e mundshme të performancës në secilën fazë. Ndryshe nga sistemet e centralizuara, ne do të shqyrtojmë gjithashtu ekzekutimin e kodit në klientët e rrjetit. Shumë shpesh, kur matni TPS, koha e përpunimit të transaksionit mblidhet nga nyjet, dhe jo nga klienti - kjo nuk është plotësisht e drejtë. Klientit nuk i intereson se sa shpejt nyja e përpunoi transaksionin e tij; gjëja më e rëndësishme për të është momenti kur informacioni i besueshëm në lidhje me këtë transaksion të përfshirë në blockchain bëhet i disponueshëm për të. Është kjo metrikë që është në thelb koha e ekzekutimit të transaksionit. Kjo do të thotë që klientë të ndryshëm, edhe duke dërguar të njëjtin transaksion, mund të marrin kohë krejtësisht të ndryshme, të cilat varen nga kanali, ngarkesa dhe afërsia e nyjës, etj. Pra, është absolutisht e nevojshme të matet kjo kohë tek klientët, pasi ky është parametri që duhet optimizuar.

Përgatitja e një transaksioni nga ana e klientit

Le të fillojmë me dy pikat e para: transaksioni formohet dhe nënshkruhet nga klienti. Mjaft e çuditshme, kjo mund të jetë gjithashtu një pengesë e performancës së blockchain nga këndvështrimi i klientit. Kjo është e pazakontë për shërbimet e centralizuara, të cilat marrin përsipër të gjitha llogaritjet dhe operacionet me të dhëna, dhe klienti thjesht përgatit një kërkesë të shkurtër që mund të kërkojë një sasi të madhe të dhënash ose llogaritje, duke marrë një rezultat të gatshëm. Në blockchains, kodi i klientit bëhet gjithnjë e më i fuqishëm, dhe thelbi i blockchain bëhet gjithnjë e më i lehtë dhe detyrat masive kompjuterike zakonisht transferohen në softuerin e klientit. Në blockchains, ka klientë që mund të përgatisin një transaksion për një kohë mjaft të gjatë (po flas për prova të ndryshme merkle, prova të përmbledhura, nënshkrime të pragut dhe operacione të tjera komplekse nga ana e klientit). Një shembull i mirë i verifikimit të lehtë në zinxhir dhe përgatitjes së rëndë të një transaksioni për klientin është prova e anëtarësimit në një listë të bazuar në Merkle-tree, këtu artikull.

Gjithashtu, mos harroni se kodi i klientit nuk dërgon thjesht transaksione në blockchain, por së pari pyet gjendjen e blockchain - dhe ky aktivitet mund të ndikojë në bllokimin e rrjetit dhe nyjeve të blockchain. Pra, kur merrni matje, do të ishte e arsyeshme të imitoni sjelljen e kodit të klientit sa më plotësisht të jetë e mundur. Edhe nëse në blockchain-in tuaj ka klientë të zakonshëm të lehtë që vendosin një nënshkrim të rregullt dixhital në transaksionin më të thjeshtë për të transferuar një aktiv, çdo vit ka ende llogaritje masive për klientin, algoritmet e kriptove po bëhen më të forta dhe kjo pjesë e përpunimit mund të të kthehet në një pengesë të rëndësishme në të ardhmen. Prandaj, jini të kujdesshëm dhe mos e humbisni situatën kur, në një transaksion që zgjat 3.5 sekonda, shpenzohen 2.5 për përgatitjen dhe nënshkrimin e transaksionit, dhe 1.0 për dërgimin e tij në rrjet dhe pritjen e përgjigjes. Për të vlerësuar rreziqet e kësaj pengese, ju duhet të grumbulloni metrikë nga makinat e klientëve, dhe jo vetëm nga nyjet e bllokut.

Dërgimi i një transaksioni dhe monitorimi i statusit të tij

Hapi tjetër është dërgimi i transaksionit në nyjen e zgjedhur të blockchain dhe marrja e statusit të pranimit të tij në grupin e transaksioneve. Kjo fazë është e ngjashme me një akses të rregullt në bazën e të dhënave; nyja duhet të regjistrojë transaksionin në grup dhe të fillojë shpërndarjen e informacionit rreth tij përmes rrjetit p2p. Qasja për vlerësimin e performancës këtu është e ngjashme me vlerësimin e performancës së mikroshërbimeve tradicionale të Web API, dhe vetë transaksionet në blockchains mund të përditësohen dhe të ndryshojnë në mënyrë aktive statusin e tyre. Në përgjithësi, përditësimi i informacionit të transaksionit në disa zinxhirë bllokues mund të ndodhë shumë herë, për shembull kur kaloni midis pirunëve të zinxhirit ose kur BP-të shpallin synimin e tyre për të përfshirë një transaksion në një bllok. Kufizimet në madhësinë e këtij grupi dhe numrin e transaksioneve në të mund të ndikojnë në performancën e blockchain. Nëse grupi i transaksioneve është i mbushur në madhësinë maksimale të mundshme, ose nuk përshtatet në RAM, performanca e rrjetit mund të bjerë ndjeshëm. Blockchain-et nuk kanë mjete të centralizuara për t'u mbrojtur kundër një vërshimi të mesazheve të padëshiruara, dhe nëse blockchain mbështet transaksione me vëllim të lartë dhe tarifa të ulëta, kjo mund të shkaktojë tejmbushjen e grupit të transaksioneve - një tjetër pengesë e mundshme e performancës.

Në blockchain, klienti dërgon një transaksion në çdo nyje blockchain që i pëlqen, hash-i i transaksionit zakonisht njihet për klientin përpara se të dërgohet, kështu që gjithçka që duhet të bëjë është të arrijë lidhjen dhe, pas transmetimit, të presë që blockchain të ndryshojë. gjendjen e tij, duke mundësuar transaksionin e tij. Vini re se duke matur "tps" mund të merrni rezultate krejtësisht të ndryshme për metoda të ndryshme të lidhjes me një nyje blockchain. Ky mund të jetë një HTTP RPC i rregullt ose një WebSocket që ju lejon të zbatoni modelin "subscribe". Në rastin e dytë, klienti do të marrë një njoftim më herët dhe nyja do të shpenzojë më pak burime (kryesisht memorie dhe trafik) në përgjigjet rreth statusit të transaksionit. Pra, kur matni "tps" është e nevojshme të merret parasysh mënyra se si klientët lidhen me nyjet. Prandaj, për të vlerësuar rreziqet e kësaj pengese, blockchain-i i standardeve duhet të jetë në gjendje të imitojë klientët me kërkesat WebSocket dhe HTTP RPC, në përmasa që korrespondojnë me rrjetet reale, si dhe të ndryshojë natyrën e transaksioneve dhe madhësinë e tyre.

Për të vlerësuar rreziqet e kësaj pengese, ju gjithashtu duhet të grumbulloni metrikë nga makinat e klientëve, dhe jo vetëm nga nyjet e zinxhirit të bllokimit.

Transmetimi i transaksioneve dhe blloqeve nëpërmjet rrjetit p2p

Në blockchains, rrjeti peer-to-peer (p2p) përdoret për të transferuar transaksione dhe blloqe midis pjesëmarrësve. Transaksionet përhapen në të gjithë rrjetin, duke filluar nga një prej nyjeve, derisa arrijnë tek prodhuesit e blloqeve homologe, të cilët paketojnë transaksionet në blloqe dhe, duke përdorur të njëjtin p2p, shpërndajnë blloqe të reja në të gjitha nyjet e rrjetit. Baza e shumicës së rrjeteve moderne p2p janë modifikimet e ndryshme të protokollit Kademlia. Këtu një përmbledhje e mirë e këtij protokolli, dhe këtu - një artikull me matje të ndryshme në rrjetin BitTorrent, nga i cili mund të kuptohet se ky lloj rrjeti është më kompleks dhe më pak i parashikueshëm se një rrjet i konfiguruar në mënyrë të ngurtë i një shërbimi të centralizuar. Gjithashtu, këtu artikull në lidhje me matjen e metrikave të ndryshme interesante për nyjet Ethereum.

Shkurtimisht, çdo koleg në rrjete të tilla mban listën e vet dinamike të kolegëve të tjerë nga të cilët kërkon blloqe informacioni që adresohen sipas përmbajtjes. Kur një koleg merr një kërkesë, ai ose jep informacionin e nevojshëm ose ia kalon kërkesën kolegut tjetër pseudo rastësor nga lista, dhe pasi të ketë marrë një përgjigje, ia kalon atë kërkuesit dhe e ruan atë për një kohë, duke i dhënë këtë një bllok informacioni më herët herën tjetër. Kështu, informacioni popullor përfundon në një numër të madh të cache-ve të një numri të madh kolegësh dhe informacioni jopopullor zëvendësohet gradualisht. Kolegët mbajnë shënime se kush ka transferuar sa informacion kujt, dhe rrjeti përpiqet të stimulojë shpërndarësit aktivë duke rritur vlerësimet e tyre dhe duke u ofruar atyre një nivel më të lartë shërbimi, duke zhvendosur automatikisht pjesëmarrësit joaktivë nga listat e kolegëve.

Pra, transaksioni tani duhet të shpërndahet në të gjithë rrjetin në mënyrë që prodhuesit e bllokut ta shohin atë dhe ta përfshijnë atë në bllok. Nyja "shpërndan" në mënyrë aktive një transaksion të ri për të gjithë dhe dëgjon rrjetin, duke pritur për një bllok në indeksin e të cilit do të shfaqet transaksioni i kërkuar për të njoftuar klientin në pritje. Koha që i duhet rrjetit për të transferuar informacione rreth transaksioneve dhe blloqeve të reja tek njëri-tjetri në rrjetet p2p varet nga një numër shumë i madh faktorësh: numri i nyjeve të sinqerta që punojnë afër (nga pikëpamja e rrjetit), "i ngrohtë- lart” e cache-ve të këtyre nyjeve, madhësia e blloqeve, transaksionet, natyra e ndryshimeve, gjeografia e rrjetit, numri i nyjeve dhe shumë faktorë të tjerë. Matjet komplekse të matjeve të performancës në rrjete të tilla janë një çështje komplekse; është e nevojshme që njëkohësisht të vlerësohet koha e përpunimit të kërkesës si për klientët ashtu edhe për kolegët (nyjet e bllokut). Problemet në cilindo nga mekanizmat p2p, nxjerrja dhe ruajtja e gabuar e të dhënave, menaxhimi joefektiv i listave të kolegëve aktivë dhe shumë faktorë të tjerë mund të shkaktojnë vonesa që ndikojnë në efikasitetin e të gjithë rrjetit në tërësi, dhe kjo pengesë është më e vështira për t'u analizuar. , testimi dhe interpretimi i rezultateve.

Përpunimi i Blockchain dhe përditësimi i bazës së të dhënave shtetërore

Pjesa më e rëndësishme e blockchain është algoritmi i konsensusit, aplikimi i tij në blloqe të reja të marra nga rrjeti dhe përpunimi i transaksioneve me regjistrimin e rezultateve në bazën e të dhënave shtetërore. Shtimi i një blloku të ri në zinxhir dhe më pas zgjedhja e zinxhirit kryesor duhet të funksionojë sa më shpejt që të jetë e mundur. Sidoqoftë, në jetën reale, "duhet" nuk do të thotë "punon" dhe mund të imagjinohet, për shembull, një situatë ku dy zinxhirë të gjatë konkurrues po kalojnë vazhdimisht midis tyre, duke ndryshuar metadatat e mijëra transaksioneve në grup në çdo ndërprerës. , dhe duke e kthyer vazhdimisht bazën e të dhënave shtetërore. Kjo fazë, për sa i përket përcaktimit të bottleneck, është më e thjeshtë se shtresa e rrjetit p2p, sepse ekzekutimi i transaksionit dhe algoritmi i konsensusit janë rreptësisht përcaktues dhe është më e lehtë të matet çdo gjë këtu.
Gjëja kryesore është të mos ngatërroni degradimin e rastësishëm në performancën e kësaj faze me problemet e rrjetit - nyjet janë më të ngadalta në dhënien e blloqeve dhe informacionit rreth zinxhirit kryesor, dhe për një klient të jashtëm kjo mund të duket si një rrjet i ngadaltë, megjithëse problemi qëndron në një vend krejtësisht tjetër.

Për të optimizuar performancën në këtë fazë, është e dobishme të mblidhen dhe monitorohen metrikat nga vetë nyjet dhe të përfshihen në to ato që lidhen me përditësimin e bazës së të dhënave të gjendjes: numrin e blloqeve të përpunuara në nyje, madhësinë e tyre, numrin e transaksioneve, numri i ndërruesve midis pirunëve të zinxhirit, numri i blloqeve të pavlefshme, koha e funksionimit të makinës virtuale, koha e kryerjes së të dhënave, etj. Kjo do të parandalojë që problemet e rrjetit të ngatërrohen me gabimet në algoritmet e përpunimit të zinxhirit.

Transaksionet e përpunimit të një makine virtuale mund të jenë një burim i dobishëm informacioni që mund të optimizojë funksionimin e blockchain. Numri i alokimeve të memories, numri i udhëzimeve të leximit/shkrimit dhe metrika të tjera që lidhen me efikasitetin e ekzekutimit të kodit të kontratës mund të ofrojnë shumë informacione të dobishme për zhvilluesit. Në të njëjtën kohë, kontratat inteligjente janë programe, që do të thotë se në teori ato mund të konsumojnë cilindo nga burimet: cpu/memorie/rrjet/ruajtje, kështu që përpunimi i transaksioneve është një fazë mjaft e pasigurt, e cila, për më tepër, ndryshon shumë kur lëvizni midis versioneve. dhe gjatë ndryshimit të kodeve të kontratës. Prandaj, metrikat që lidhen me përpunimin e transaksioneve janë gjithashtu të nevojshme për të optimizuar në mënyrë efektive performancën e blockchain.

Marrja nga klienti i një njoftimi për përfshirjen e një transaksioni në blockchain

Kjo është faza përfundimtare e klientit blockchain që merr shërbimin; në krahasim me fazat e tjera, nuk ka kosto të mëdha të përgjithshme, por ia vlen të merret parasysh mundësia që klienti të marrë një përgjigje voluminoze nga nyja (për shembull, një kontratë inteligjente duke kthyer një grup të dhënash). Në çdo rast, kjo pikë është më e rëndësishmja për atë që bëri pyetjen "sa tps janë në blockchain tuaj?", sepse Në këtë moment regjistrohet koha e marrjes së shërbimit.

Në këtë vend, ka gjithmonë një dërgim të kohës së plotë që klienti duhej të kalonte duke pritur për një përgjigje nga blockchain; është këtë herë që përdoruesi do të presë konfirmimin në aplikacionin e tij dhe është optimizimi i tij që është Detyra kryesore e zhvilluesve.

Përfundim

Si rezultat, ne mund të përshkruajmë llojet e operacioneve të kryera në blockchains dhe t'i ndajmë ato në disa kategori:

transformime kriptografike, ndërtim provash
rrjetëzimi peer-to-peer, transaksioni dhe përsëritja e bllokut
процессинг транзакций, исполнение смарт-контрактов
duke aplikuar ndryshime në blockchain në bazën e të dhënave shtetërore, duke përditësuar të dhënat për transaksionet dhe blloqet
kërkesat vetëm për lexim për bazën e të dhënave shtetërore, API-në e nyjeve të bllokut, shërbimet e abonimit

Në përgjithësi, kërkesat teknike për nyjet moderne të blockchain janë jashtëzakonisht serioze - CPU të shpejtë për kriptografi, një sasi e madhe RAM për të ruajtur dhe aksesuar shpejt në bazën e të dhënave shtetërore, ndërveprim në rrjet duke përdorur një numër të madh lidhjesh të hapura njëkohësisht dhe ruajtje të madhe. Kërkesa të tilla të larta dhe bollëku i llojeve të ndryshme të operacioneve çojnë në mënyrë të pashmangshme në faktin se nyjet mund të mos kenë burime të mjaftueshme, dhe më pas ndonjë nga fazat e diskutuara më sipër mund të bëhet një pengesë tjetër për performancën e përgjithshme të rrjetit.

Kur hartoni dhe vlerësoni performancën e blockchains, do të duhet të merrni parasysh të gjitha këto pika. Për ta bërë këtë, ju duhet të mbledhni dhe analizoni metrikat njëkohësisht nga klientët dhe nyjet e rrjetit, të kërkoni korrelacione midis tyre, të vlerësoni kohën që duhet për të ofruar shërbime për klientët, të merrni parasysh të gjitha burimet kryesore: cpu/memorie/rrjet/ruajtje , kuptojnë se si përdoren dhe ndikojnë njëri-tjetrin. E gjithë kjo e bën krahasimin e shpejtësive të zinxhirëve të ndryshëm në formën e "sa TPS" një detyrë jashtëzakonisht të pafalshme, pasi ka një numër të madh konfigurimesh dhe gjendjesh të ndryshme. Në sistemet e mëdha të centralizuara, grupe me qindra serverë, këto probleme janë gjithashtu komplekse dhe gjithashtu kërkojnë mbledhjen e një numri të madh metrikash të ndryshme, por në zinxhirët e bllokimit, për shkak të rrjeteve p2p, makinave virtuale që përpunojnë kontratat, ekonomive të brendshme, numrit të shkallëve e lirisë është shumë më e madhe, gjë që e bën testin edhe në disa serverë, është jo tregues dhe tregon vetëm vlera jashtëzakonisht të përafërta që nuk kanë pothuajse asnjë lidhje me realitetin.

Prandaj, kur zhvillojmë në bërthamën e blockchain, për të vlerësuar performancën dhe për t'iu përgjigjur pyetjes "a është përmirësuar në krahasim me herën e kaluar?", ne përdorim softuer mjaft kompleks që orkestron nisjen e një blockchain me dhjetëra nyje dhe automatikisht lëshon një pikë referimi dhe mbledh metrikë ; pa këtë informacion është jashtëzakonisht e vështirë të korrigjohen protokollet që funksionojnë me shumë pjesëmarrës.

Pra, kur merrni pyetjen "sa TPS ka në blockchain tuaj?", ofrojini bashkëbiseduesit tuaj pak çaj dhe pyesni nëse ai është gati të shikojë një duzinë grafikësh dhe gjithashtu të dëgjojë të tre kutitë e problemeve të performancës së blockchain dhe sugjerimet tuaja për duke i zgjidhur ato...

Burimi: www.habr.com

Sa TPS janë në blockchain tuaj?