Pyetja më e zakonshme për çdo sistem të distribuuar nga një specialist jo teknik është “Sa tps ka bllokada juaj?”. Megjithatë, numri i dhënë në përgjigje zakonisht ka pak të bëjë me atë që dëshiron të dëgjojë pyetësi. Në të vërtetë, ai dëshiron të pyesë “a përshtatet bllokada juaj me kërkesat e mia të biznesit”, dhe këto kërkesa nuk janë një numër e vetme, por një grup kushtesh — këtu përfshihet qëndrueshmëria e rrjetit, kërkesat për përfundim, madhësitë, natyra e transaksioneve dhe shumë parametra të tjerë. Kështu që përgjigjja në pyetjen “sa tps” nganjëherë do të jetë e komplikuar dhe pothuajse kurrë nuk do të jetë e plotë. Një sistem i distribuuar me dhjetëra dhe qindra nyjash që realizojnë llogaritje të ndërlikuara mund të jetë në një sërë gjendjesh të ndryshme, të lidhura me gjendjen e rrjetit, përmbajtjen e bllokadës, dështimet teknike, problemet ekonomike, sulmet në rrjet dhe shumë arsye të tjera. Faza në të cilat mund të ketë probleme me performancën dallohen nga shërbimet tradicionale, dhe serveri i rrjetit të bllokadave është një shërbim rrjeti që kombinon funksionalitetin e një baze të dhënash, serveri web dhe klient torrent, gjë që e bën jashtëzakonisht të ndërlikuar në aspektin e profilit të ngarkesës në të gjitha nën-sistemat: procesori, memoria, rrjeti, ruajtja.

Siç ndodhi, rrjetet e decentralizuara dhe bllokadat janë një software mjaft specifik dhe i pazakontë për zhvilluesit e software-ve të centralizuar. Prandaj, do të doja të theksoj aspektet e rëndësishme të performancës dhe qëndrueshmërisë së rrjeteve të decentralizuara, qasjet për matjen e tyre dhe identifikimin e pengesave. Ne do të shqyrtojmë probleme të ndryshme të performancës që kufizojnë shpejtësinë e shërbimit për përdoruesit e bllokadave dhe do të shënojmë karakteristikat që janë specifike për këtë lloj software-i.

Fazat e kërkesës për shërbim nga klienti i bllokadës

Për të folur me sinqeritet rreth cilësisë së çdo shërbimi disi kompleks, duhet të merret parasysh jo vetëm vlera mesatare, por edhe ato maksimale/minimale, medianat, percentilet. Teoretikisht, mund të flitet për 1000 tps në ndonjë blockchain, por nëse 900 transaksione u përfunduan me një shpejtësi të madhe, ndërsa 100 - "ngjiten" për disa sekonda, atëherë koha mesatare e mbledhur për të gjitha transaksionet nuk është një metrikë krejtësisht e sinqertë për klientin, i cili nuk mundi të përfundojë marrëveshjen për disa sekonda. "Gropat" temporale, të shkaktuara nga humbje rrethesh konsensusi ose ndarje të rrjetit, mund të dëmtojnë rëndë shërbimin, i cili në stendat testuese tregonte performancë të shkëlqyer.

Për të identifikuar këto bottlenecks është e nevojshme të kuptohet mirë fazat se kur një blockchain real mund të hasë vështirësi në shërbimin e përdoruesve. Le të përshkruajmë ciklin e dorëzimit dhe procesin e përpunimit të transaksioneve, si dhe marrjen e gjendjes së re të blockchain-it, nga e cila klienti mund të konfirmojë që transaksioni i tij është përpunuar dhe regjistruar.

transaksioni formohet në klient
transaksioni nënshkruhet në klient
klienti zgjedh një nga nodet dhe i dërgon transaksionin e tij
klienti regjistrohet për azhornimet e state database-it të nodit, duke pritur shfaqjen e rezultateve të përpunimit të transaksionit të tij
noda shpërndan transaksionin në rrjetin p2p
disa, ose një BP (prodhues bllokesh) procesojnë transaksionet e akumuluara, duke azhurnuar state database
BP formon një bllok të ri, duke përpunuar numrin e nevojshëm të transaksioneve
BP shpërndan bllokun e ri në rrjetin p2p
blloku i ri dërgohet në nodën që kliente i drejtohet
noda azhurnon state database
noda sheh azhurnimin që i përket klientit dhe i dërgon atij një njoftim për transaksionin

Tani le ta njëherë në detaje këto etapa dhe të përshkruajmë problemet potenciale me performancën në çdo hap. Ndryshe nga sistemet e centralizuara, ne do të shqyrtojmë gjithashtu ekzekutimin e kodit në klientët e rrjetit. Mjaft shpesh, kur matet tps, koha e procesimit të transaksioneve mblidhet nga nodet dhe jo nga klienti — kjo nuk është krejtësisht e sinqertë. Klienti nuk e ka problem sa shpejt node proceson transaksionin e tij, ajo që është më e rëndësishme për të është momenti kur informacioni i saktë mbi këtë transaksion, i përfshirë në blockchain, do të jetë në dispozicion për të. Kjo metrikë është esencialisht koha e ekzekutimit të transaksionit. Kjo do të thotë se klientët e ndryshëm, edhe pse dërgojnë një transaksion të njëjtë, mund të kenë kohë tërësisht të ndryshme, të cilat varen nga kanali, ngarkesa dhe afërsia e nodit, etj. Pra, është thelbësore të matet kjo kohë në klientë, pasi ky është parametri që duhet optimizuar.

Përgatitja e transaksionit nga ana e klientit

Le të fillojmë me dy pikët e para: transaksioni formohet dhe nënshkruhet nga klienti. Siç duket, kjo gjithashtu mund të jetë një ngushticë e performancës së blockchain nga perspektiva e klientit. Kjo është e pazakontë për shërbimet e centralizuara, të cilat i marrin për vete të gjitha llogaritë dhe operacionet me të dhëna, ndërsa klienti përgatit një kërkesë të shkurtër, e cila mund të kërkojë një volum të madh të dhënash ose llogaritjesh, duke marrë rezultatin e gatshëm. Në blockchain, kodi i klientit po bëhet gjithnjë e më i fuqishëm, ndërsa bërthama e blockchain-it po bëhet gjithnjë e më e lehtë, dhe detyrat masive të llogaritjes zakonisht u jepen softuerëve të klientit. Në blockchain ekzistojnë klientë që mund të përgatisin një transaksion për një kohë të gjatë (po flas për dëshmitë e ndryshme merkle, dëshmitë e shkurtëra, nënshkrimet threshold dhe operacione të tjera komplekse nga ana e klientit). Një shembull i mirë i verifikimit të lehtë on-chain dhe përgatitjes së rëndë të transaksionit nga ana e klientit është dëshmia e përkatësisë në një listë të bazuar në Merkle-tree, ja artikulli.

Po gjithashtu, nuk duhet harruar se kodi i klientit nuk dërgon thjesht transaksione në blockchain, por fillimisht kërkon gjendjen e blockchain-it — dhe kjo aktivitet mund të ndikojë në ngarkesën e rrjetit dhe node-ve të blockchain-it. Prandaj, gjatë marrjes së matjeve, do të ishte e arsyeshme të emuloni sa më saktë të jetë e mundur sjelljen e kodit të klientit. Edhe nëse në blockchain-in tuaj ka klientë normalë të lehtë, që vendosin një nënshkrim dixhital të zakonshëm në një transaksion të thjeshtë për transferimin e ndonjë asset-i, sasia e llogaritjeve në anën e klientit vazhdon të rritet çdo vit, algoritmet kriptografike po bëhen më të forta, dhe kjo pjesë e procesimit mund të shndërrohet në një bllokim të konsiderueshëm në të ardhmen. Prandaj, jini të kujdesshëm dhe mos e humbisni situatën kur në një transaksion që zgjat 3.5 sekonda, 2.5 sekonda shpenzohen për përgatitjen dhe nënshkrimin e transaksionit, dhe 1.0 sekondë për dërgimin në rrjet dhe pritjen e përgjigjes. Për të vlerësuar rreziqet e ndodhjes së këtij bllokimi, duhet të mblidhni metrika nga makinat e klientëve dhe jo vetëm nga node-t e blockchain-it.

Dërgimi i transaksionit dhe monitorimi i statusit të tij

Hapi i ardhshëm është dërgimi i transaksionit në node-n e zgjedhur të blockchain-it dhe marrja e statusit për pranimin e tij në grupin e transaksioneve. Ky hap i ngjan një kërkese të zakonshme në një databazë; node-ja duhet të regjistrojë transaksionin në grupin dhe të fillojë të shpërndajë informacionin për të në rrjetin p2p. Qasja për vlerësimin e performancës këtu është e ngjashme me vlerësimin e punës së mikroshërbimeve tradicionale Web API, ndërsa vetë transaksionet në blockchain mund të përditësohen, duke ndryshuar statusin aktivisht. Në përgjithësi, përditësimi i informacionit për një transaksion në disa blockchain-e mund të ndodhë disa herë, për shembull, gjatë kalimeve mes bifurkime të zinxhirit ose kur BP njoftojnë se kanë për qëllim të përfshijnë transaksionin në bllok. Kufizimet mbi volumet e këtij grupi dhe numrin e transaksioneve në të mund të ndikojnë në performancën e blockchain-it. Nëse grupi i transaksioneve është mbushur deri në madhësinë maksimale të mundshme, ose nuk i përshtatet në memorjen e përkohshme - performanca e rrjetit mund të bjerë ndjeshëm. Blockchain-et nuk kanë mjete të centralizuara mbrojtjeje nga fluksi i mesazheve të plehrave, dhe nëse blockchain-i mbështet transaksione të volumit të madh me tarifa të ulëta, kjo mund të çojë në mbushjen e grupit të transaksioneve - ky është një tjetër bllokim potencial i performancës.

Në blockchain-e, klienti dërgon një transaksion në çdo nodë të blockchain-it që i pëlqen, hash-i i transaksionit zakonisht është e njohur për klientin edhe para dërgimit, kështu që gjithçka që i nevojitet — është të arrijë një lidhje dhe pas dërgimit të presë kur blockchain-i të ndryshojë gjendjen e tij, duke përfshirë transaksionin e tij. Vërejmë se duke matur "tps" mund të merrni rezultate krejt të ndryshme për mënyra të ndryshme lidhjeje me nodën e blockchain-it. Kjo mund të jetë një HTTP RPC i zakonshëm ose WebSocket, i cili lejon realizimin e modelit "subscribe". Në rastin e dytë, klienti do të marrë njoftimin më herët, ndërsa nodja do të harxhojë më pak burime (për kryesisht kujtesë dhe trafik) në përgjigjet mbi gjendjen e transaksionit. Pra, kur matni "tps", duhet të merrni parasysh mënyrën e lidhjes së klientëve me nodat. Prandaj, për vlerësimin e rreziqeve të shfaqjes së këtij bottleneck-u, benchmark-u i blockchain-it duhet të jetë në gjendje të emulojë klientë me WebSocket dhe me kërkesa HTTP RPC, në proporcione që përputhen me rrjetet reale, si dhe të ndryshojë natyrën e transaksioneve dhe madhësinë e tyre.

Për vlerësimin e rreziqeve të shfaqjes së këtij bottleneck-u është gjithashtu e nevojshme të mblidhni metrika nga makinat e klientëve, dhe jo vetëm nga nodat e blockchain-it.

Transferimi i transaksioneve dhe blloqeve përmes rrjetit p2p

Në blockchain-e, për transferimin mes pjesëmarrësve të transaksioneve dhe blloqeve përdoret rrjetëzim peer-to-peer (p2p). Transaksionet shpërndahen në rrjet, duke filluar nga një nga nodet, derisa të arrijnë peer-at-produes të blloqeve, të cilët paketojnë transaksionet në blloqe dhe, duke përdorur të njëjtin p2p, shpërndajnë blloqet e reja në të gjitha nodat e rrjetit. Baza e shumicës së rrjeteve moderne p2p është ndryshime të ndryshme të protokollit Kademlia. Ja një përmbledhje e shkurtër e këtij protokolli, dhe ja — një artikull me matje të ndryshme në rrjetin BitTorrent, nga i cili mund të kuptoni — se ky lloj rrjeti është më i komplikuar, dhe më pak i parashikueshëm se sa një rrjet i konfiguruar fort me një shërbim të centralizuar. Gjithashtu, ja një artikull mbi matjen e metrikave të ndryshme interesante për nodat Ethereum.

Në thelb, çdo peer në këto rrjete mban listën e vet dinamike të peers të tjerë, nga të cilët kërkon blloqet e informacionit që i adresohen sipas përmbajtjes. Kur merr një kërkesë, peer ose jep informacionin e nevojshëm, ose e transmeton kërkesën te një peer tjetër pseudopasur nga lista, dhe pasi merr përgjigjen, ia kalon atë kërkuesit dhe për një periudhë të caktuar e ruan në cache, duke e ofruar këtë bllok informacioni më herët herën tjetër. Kështu, informacioni popullor gjendet në një numër të madh cache-esh te një numër të madh peers, ndërsa ai jo-popullor gradualisht zëvendësohet. Peers mbajnë një llogari se kush i kalon sa informacion, dhe rrjeti përpiqet të stimulojë ata që shpërndajnë aktivisht, duke rritur renditjen e tyre dhe duke u siguruar një nivel më të lartë shërbimi, duke përjashtuar automatikisht pjesëmarrësit inaktivë nga listat e peers.

Pra, tani duhet të përhapet transaksioni në rrjet që të shihet nga block-producer-ët dhe të përfshihet në bllok. Noda aktivisht "shpërndan" transaksionin e ri të gjithëve që dëshirojnë dhe dëgjon rrjetin, duke pritur bllokun, në indeksin e të cilit do të shfaqet transaksioni i nevojshëm për të njoftuar klientin që po pret. Koha ndërsa rrjeti kalon informacionin për transaksionet dhe blloqet e reja në rrjetet p2p varet nga një numër shumë të madh faktorësh: numri i nodave të ndershme që punojnë afër (në aspektin e rrjetit), "ngrohja" e cache-ve të këtyre nodave, përmasat e blloqeve, transaksioneve, natyra e ndryshimeve, gjeografia e rrjetit, numri i nodave dhe shumë faktorë të tjerë. Matjet komplekse të metrikes së performancës në këto rrjete janë një punë e komplikuar, është e nevojshme të vlerësohet njëkohësisht koha e përpunimit të kërkesave si për klientët ashtu edhe për peers (nodat e blockchain). Problemet në ndonjë nga mekanizmat p2p, ndërrimi i gabuar dhe ruajtja e të dhënave, menaxhimi joefikas i listave të peers aktivë, dhe shumë faktorë të tjerë mund të jenë shkak për vonesa që ndikojnë në efikasitetin e gjithë rrjetit si një e tërë, dhe ky bottleneck është më të vështirë për t'u analizuar, testuar dhe interpretuar rezultatet.

Procesimi i zinxhirit të blloqeve dhe përditësimi i databazës së gjendjes

Pjesa më e rëndësishme e funksionit të blockchain-it është algoritmi i konsensusit, aplikimi i tij në blloqet e reja, të marra nga rrjeti dhe procesi i transaksioneve me regjistrimin e rezultateve në bazën e të dhënave të shtetit. Shtimi i një blloku të ri në zinxhir dhe zgjedhja e zinxhirit kryesor që vjen pas duhet të ndodhin sa më shpejt të jetë e mundur. Sidoqoftë, në jetën reale, "duhet" nuk do të thotë "funksionon", dhe mund të imagjinoni një situatë kur dy zinxhirë konkurrues të gjatë kërcejnë vazhdimisht midis tyre, duke ndryshuar metadatën e mijëra transaksioneve në pool në çdo kalim dhe duke prodhuar rikthime të vazhdueshme të gjendjes së bazës së të dhënave. Ky fazë, në aspektin e identifikimit të ngushticës, është më e thjeshtë se shtresa p2p rrjetor, pasi ekzekutimi i transaksioneve dhe algoritmi i konsensusit janë tërësisht të determinuar, dhe është më e lehtë të matësh gjithçka këtu.
E rëndësishme është të mos ngatërrohet degradimi rastësor i performancës në këtë fazë me problemet në rrjet — nodet japin më ngadalë blloqe dhe informacion rreth zinxhirit kryesor dhe për klientin e jashtëm, këtë mund ta duket si një rrjet i ngadalshëm, ndonëse problemi ndodhet krejtësisht në një vend tjetër.

Për optimizimin e performancës në këtë fazë, është e dobishme të mblidhen dhe monitorohen metrikat nga vetë nodet dhe të përfshihen ato që lidhen me përditësimin e bazës së të dhënave të shtetit: numri i blloqeve të procesuar në nod, madhësia e tyre, numri i transaksioneve, numri i alternimeve midis bifurkave të zinxhirit, numri i blloqeve të pavlefshme, koha e funksionimit të makinerisë virtuale, koha e regjistrimit të të dhënave dhe të tjera. Kjo do të ndihmojë për të mos ngatërruar problemet rrjetore me gabimet në algoritmet e procesimit të zinxhirëve.

Makina virtuale që proceson transaksionet mund të jetë një burim i dobishëm informacioni që mund të optimizojë funksionimin e blockchain-it. Sasia e alokimeve të memories, numri i instrukcioneve read/write dhe metrika të tjera që lidhen me efikasitetin e ekzekutimit të kodit të kontratave mund të japin shumë informacion të dobishëm për zhvilluesit. Në të njëjtën kohë, kontratat inteligjente janë programe dhe prandaj në teori ato mund të konsumojnë çdo burim: cpu/memory/network/storage, kështu që procesimi i transaksioneve është një fazë mjaft e pasigurt, e cila gjithashtu ndryshon ndjeshëm gjatë kalimit midis versioneve dhe gjatë ndryshimit të kodit të kontratave. Prandaj, metrikat që lidhen me procesimin e transaksioneve janë gjithashtu të nevojshme për optimizimin e efektivitetit të performancës së blockchain-it.

Marrja e njoftimit nga klienti për aktivizimin e transaksionit në blockchain

Ky është faza përfundimtare e marrjes së shërbimit nga klienti i blockchain-it, krahasuar me fazat e tjera, këtu nuk ka shpenzime të mëdha, por gjithsesi duhet marrë parasysh mundësia e marrjes së një përgjigjeje voluminoze nga nodi (p.sh. kontratë inteligjente që kthen një array të dhënash). Në çdo rast, ky moment është më i rëndësishëm për ata që kanë bërë pyetjen "sa tps ka blockchain-i juaj?", sepse këtu e regjistrohet koha e marrjes së shërbimit.

Në këtë pikë është e nevojshme të dërgohet koha totale që i është dashur klientit për të pritur përgjigjen nga blockchain-i, kjo është koha që përdoruesi do të presë për të marrë konfirmimin në aplikacionin e tij, dhe optimizimi i saj është detyra kryesore e zhvilluesve.

Përfundim

Si rezultat, mund të përshkruhen llojet e operacioneve që kryhen në blockchain dhe t'i ndahen në disa kategori:

transformime kriptografike, ndërtimi i provave
networking peer-to-peer, replikimi i transaksioneve dhe blloqeve
procesimi i transaksioneve, ekzekutimi i kontratave inteligjente
aplikimi i ndryshimeve në blockchain në bazën e të dhënave të gjendjes, përditësimi i të dhënave rreth transaksioneve dhe blloqeve
kërkesa read-only në bazën e të dhënave të gjendjes, API e nodit blockchain, shërbimet e abonimit

Në përgjithësi, kërkesat teknike për nodet e blockchain-eve moderne janë jashtëzakonisht serioze - kërkohen CPU të shpejtë për kriptografinë, një sasi të madhe kujtesë të shpejtë për të ruajtur dhe aksesuar shpejt bazën e të dhënave të gjendjes, ndërveprimi në rrjet që përdor një numër të madh lidhjesh të hapura njëkohësisht, dhe hapësirë të madhe ruajtjeje. Këto kërkesa të larta dhe varieteti i llojeve të operacioneve do të sjellin domosdoshmërish që resurset e nodve të mos mjaftojnë, dhe në atë rast, çdo një nga fazat e shqikuara më sipër mund të bëhet një ngushticë tjetër për performancën e përgjithshme të rrjetit.

Kur zhvilloni dhe vlerësoni performancën e bllokadave, do t'ju duhet të merrni parasysh të gjitha këto aspekte. Për këtë, duhet të mblidhni dhe analizoni metrika njëkohësisht nga klientët dhe nodet e rrjetit, të kërkoni korrelacione midis tyre, të vlerësoni kohën e shërbimit për klientët, të merrni parasysh të gjithë burimet kryesore: cpu/memorie/rrjet/shërbim, të kuptoni si përdoren dhe ndikojnë njëri mbi tjetrin. Të gjitha këto e bëjnë krahasimin e shpejtësive të bllokadave të ndryshme në formën e "sa TPS" një detyrë jashtëzakonisht të pafalshme, pasi ekziston një sasi e madhe konfiguracionesh dhe gjendjesh të ndryshme. Në sisteme të mëdha të centralizuara, klastera me qindra serverë, këto probleme janë gjithashtu të komplikuara dhe kërkojnë mbledhjen e një numri të madh metricash të ndryshme, por në bllokada, për shkak të rrjeteve p2p, makina virtuale, kontraktesh procesi, ekonomi të brendshme, numri i gradave të lirisë është shumë më i lartë, që e bën testimin, edhe në disa serverë, krejtësisht joindicues dhe të tregojë vetëm vlera tepër të përafërta, që kanë pak lidhje me realitetin.

Prandaj, gjatë zhvillimit në thelbin e bllokadës, për të vlerësuar performancën dhe për të përgjigjur pyetjes "a është përmirësuar krahasuar me herën e kaluar", ne përdorim një softuer mjaft të komplikuar, që orkestron nisjen e bllokadës me dhjetëra nyje dhe fillimin automatik të benchmark-ut dhe mbledhjen e metricave; pa këtë informacion është jashtëzakonisht e vështirë të depurosh protokollet që punojnë me shumë pjesëmarrës.

Kështu që, kur të merrni pyetjen "sa TPS ka bllokada juaj?", ofroni një filxhan çaji dhe sqaroni nëse ai është i gatshëm të njihet me një dhjetë grafika dhe gjithashtu të dëgjojë të gjitha tre kutitë e problemeve të performancës së bllokadave dhe propozimet tuaja për zgjidhjen e tyre...

Burimi: habr.com