Teknikoa ez den pertsona baten edozein sistema banatuari buruzko galdera gogokoena "Zenbat tps daude zure bloke-katean?" Hala ere, erantzun moduan emandako zenbakiak normalean ez du zerikusi handirik galdetzaileak entzun nahiko lukeenarekin. Izan ere, "zure blockchain-a nire negozio-eskakizunetara egokitzen al da" galdetu nahi zuen, eta eskakizun hauek ez dira zenbaki bakarra, baldintza asko baizik: hona hemen sarearen akatsen tolerantzia, azken baldintzak, tamainak, transakzioen izaera eta beste hainbat parametro. Beraz, "zenbat tps" galderaren erantzuna nekez erraza izango da, eta ia inoiz ez osoa. Nahiko kalkulu konplexuak egiten dituzten hamarnaka edo ehunka nodo dituen sistema banatu bat sarearen egoerarekin, bloke-katearen edukiekin, akats teknikoekin, arazo ekonomikoekin, sarearen aurkako erasoekin eta beste hainbat arrazoirekin zerikusia duten hainbat egoeratan egon daiteke. . Errendimendu-arazoak gerta daitezkeen faseak zerbitzu tradizionaletatik desberdinak dira, eta blockchain sareko zerbitzaria datu-base baten, web zerbitzariaren eta torrent bezeroaren funtzionalitateak konbinatzen dituen sare-zerbitzua da, eta horrek oso konplexua bihurtzen du azpisistema guztietan karga-profilari dagokionez. : prozesadorea, memoria, sarea, biltegiratzea

Gertatzen da sare deszentralizatuak eta bloke-kateak software nahiko zehatz eta ezohikoak direla software zentralizatuko garatzaileentzat. Hori dela eta, sare deszentralizatuen errendimenduaren eta iraunkortasunaren alderdi garrantzitsuak, horiek neurtzeko planteamenduak eta botila-lepoak aurkitzeko alderdi garrantzitsuak nabarmendu nahi nituzke. Blockchain erabiltzaileei zerbitzuak eskaintzeko abiadura mugatzen duten hainbat errendimendu-arazo aztertuko ditugu eta software mota honen ezaugarriak kontuan hartuko ditugu.

Blockchain bezero batek zerbitzu eskaera baten faseak

Gutxiago ala konplexua den edozein zerbitzuren kalitateaz zintzotasunez hitz egiteko, batez besteko balioak ez ezik, gehienez/minimoak, medianak, pertzentilak ere kontuan hartu behar dituzu. Teorian, 1000 tps-i buruz hitz egin dezakegu bloke-kate batzuetan, baina 900 transakzio abiadura izugarriarekin burutu baziren eta 100 segundo batzuetan "itsatsita" egon baziren, orduan transakzio guztietan bildutako batez besteko denbora ez da guztiz bidezko metrika bat bezero batentzat. transakzioa segundo gutxitan burutu ezin nuena. Galdutako adostasun errondak edo sare zatiketak eragindako aldi baterako "zuloak" proba-bankuetan errendimendu bikaina erakutsi duen zerbitzua asko honda dezakete.

Botil-lepo horiek identifikatzeko, beharrezkoa da benetako bloke-kate batek erabiltzaileei zerbitzatzeko zailtasunak izan ditzakeen faseak ondo ulertzea. Deskriba dezagun transakzio bat entregatu eta prozesatzeko zikloa, baita blockchain-aren egoera berri bat lortzea ere, eta bertatik bezeroak egiazta dezake bere transakzioa prozesatu eta kontabilizatu dela.

transakzioa bezeroaren gainean eratzen da
transakzioa bezeroarekin sinatzen da
bezeroak nodoetako bat hautatzen du eta bertara bidaltzen du bere transakzioa
bezeroak nodoaren egoera datu-basearen eguneraketak harpidetzen ditu, bere transakzioaren emaitzak agertuko zain
nodoak transakzioa p2p sarean banatzen du
hainbat edo BP (bloke ekoizlea) metatutako transakzioak prozesatzen ditu, egoera datu-basea eguneratuz
BPk bloke berri bat osatzen du beharrezko transakzio kopurua prozesatu ondoren
BPk bloke berri bat banatzen du p2p sarean
bloke berria bezeroa sartzen ari den nodora entregatzen da
nodoen egoera datu-basea eguneratzen du
nodoak bezeroari buruzko eguneraketa ikusten du eta transakzio jakinarazpena bidaltzen dio

Orain ikus ditzagun fase hauek hurbilagotik eta deskriba ditzagun etapa bakoitzean errendimendu-arazo potentzialak. Sistema zentralizatuak ez bezala, sareko bezeroen kodearen exekuzioa ere kontuan hartuko dugu. Askotan, TPS neurtzean, transakzioen prozesatzeko denbora nodoetatik jasotzen da, eta ez bezeroarengandik - hau ez da guztiz bidezkoa. Bezeroak ez dio axola nodoak zein azkar prozesatu duen bere transakzioa; berarentzat garrantzitsuena bloke-katean sartutako transakzio honi buruzko informazio fidagarria eskura jartzen duen momentua da. Neurri hau da, funtsean, transakzioaren exekuzio-denbora. Horrek esan nahi du bezero ezberdinek, transakzio bera bidaliz ere, denbora guztiz desberdinak jaso ditzaketela, kanalaren, kargaren eta nodoaren hurbiltasunaren araberakoak, etab. Beraz, guztiz beharrezkoa da denbora hori bezeroei neurtzea, hori baita optimizatu beharreko parametroa.

Bezeroaren aldetik transakzio bat prestatzea

Has gaitezen lehenengo bi puntuetatik: transakzioa bezeroak eratu eta sinatzen du. Bitxia bada ere, hau blockchain-en errendimenduaren botila-lepo bat ere izan daiteke bezeroaren ikuspuntutik. Ezohikoa da zerbitzu zentralizatuetan, datuekin kalkulu eta eragiketa guztiak hartzen baitituzte, eta bezeroak eskaera labur bat besterik ez du prestatzen, datu edo kalkulu kopuru handia eska dezakeena, prest egindako emaitza lortuz. Bloke-kateetan, bezero-kodea gero eta indartsuagoa da, eta bloke-katearen nukleoa gero eta arinagoa da, eta informatika-zeregin masiboak bezeroaren softwarera transferitzen dira normalean. Blokeoetan, denbora luzez transakzio bat presta dezaketen bezeroak daude (merkle-froga, froga laburrak, atalasearen sinadurak eta bezeroaren aldetik dauden beste eragiketa konplexu batzuei buruz ari naiz). Bezeroaren kateko egiaztapen errazaren eta transakzio baten prestaketa astunaren adibide ona Merkle-zuhaitzan oinarritutako zerrenda bateko kide izatearen froga da, hemen artikuluan.

Gainera, ez ahaztu bezero-kodeak ez dituela transakzioak blokeo-katera bidaltzen, lehenik eta behin bloke-katearen egoera galdetzen duela, eta jarduera honek sarearen eta bloke-katearen nodoen pilaketari eragin diezaioke. Beraz, neurketak egiterakoan, zentzuzkoa izango litzateke bezeroaren kodearen portaera ahalik eta gehien imitatzea. Zure blokeo-katean aktiboren bat transferitzeko transakzio errazenean sinadura digital erregularra jartzen duten bezero arin arruntak badaude ere, urtero oraindik bezeroari kalkulu masiboagoak daude, kripto-algoritmoak sendotzen ari dira eta prozesamenduaren zati hau. etorkizunean botilako lepo garrantzitsu bat bihurtu. Beraz, kontuz ibili eta ez galdu egoera, 3.5s irauten duen transakzio batean, 2.5s transakzioa prestatzen eta sinatzen pasatzen direnean, eta 1.0s sarera bidaltzen eta erantzunaren zain. Botila-lepo honen arriskuak ebaluatzeko, neurketak bildu behar dituzu bezero-makinetatik, eta ez soilik blockchain-en nodoetatik.

Transakzio bat bidaltzea eta haren egoera kontrolatzea

Hurrengo urratsa transakzioa hautatutako blockchain nodora bidaltzea da eta transakzio multzoan onartzeko egoera jasotzea da. Etapa hau datu-baseko sarbide arrunt baten antzekoa da; nodoak transakzioa igerilekuan erregistratu behar du eta horri buruzko informazioa p2p sarearen bidez banatzen hasi behar du. Hemen errendimendua ebaluatzeko ikuspegia Web API mikrozerbitzu tradizionalen errendimendua ebaluatzearen antzekoa da, eta blockchains-en transakzioak beraiek eguneratu eta egoera aktiboki alda daitezke. Orokorrean, bloke-kate batzuetako transakzio-informazioa eguneratzea hainbat aldiz gerta daiteke, adibidez, kate-sardexka batetik bestera aldatzean edo BPek transakzio bat bloke batean sartzeko asmoa iragartzen dutenean. Igerileku honen tamainaren eta transakzio kopuruaren mugak blokeo-katearen errendimenduan eragina izan dezakete. Transakzio multzoa ahalik eta tamaina handienarekin betetzen bada, edo RAMan sartzen ez bada, sarearen errendimendua nabarmen jaitsi daiteke. Blockchains-ek ez dute mezu zabor-uholdearen aurka babesteko baliabide zentralizaturik, eta blockchain-ak bolumen handiko transakzioak eta kuota baxuak onartzen baditu, horrek transakzio-biltegia gainezka eragin dezake, beste errendimendu potentzial bat.

Blockchain-en, bezeroak transakzio bat bidaltzen du nahi duen edozein blockchain-nodora, transakzioaren hash-a normalean bezeroak ezagutzen du bidali aurretik, beraz, egin behar duen guztia konexioa lortu eta, transmisioaren ondoren, blockchain-a aldatu arte itxaron. bere egoera, bere transakzioa ahalbidetuz. Kontuan izan "tps" neurtuz emaitza guztiz desberdinak lor ditzakezula blockchain nodo batera konektatzeko metodo desberdinetarako. Hau HTTP RPC arrunta edo "harpidetza" eredua ezartzeko aukera ematen duen WebSocket bat izan daiteke. Bigarren kasuan, bezeroak jakinarazpen bat lehenago jasoko du, eta nodoak baliabide gutxiago gastatuko ditu (memoria eta trafikoa batez ere) transakzio egoerari buruzko erantzunetan. Beraz, "tps" neurtzerakoan bezeroak nodoetara konektatzeko modua kontuan hartu behar da. Hori dela eta, botila-lepo horren arriskuak ebaluatzeko, erreferentziazko bloke-kateak WebSocket zein HTTP RPC eskaerak dituzten bezeroak emulatzeko gai izan behar du, sare errealei dagozkien proportzioetan, baita transakzioen izaera eta haien tamaina aldatzeko ere.

Botila-lepo honen arriskuak ebaluatzeko, bezeroen makinen metrikak ere bildu behar dituzu, eta ez soilik blockchain nodoetatik.

Transakzio eta blokeen transmisioa p2p sarearen bidez

Blockchains-en, peer-to-peer (p2p) sareak parte-hartzaileen arteko transakzioak eta blokeak transferitzeko erabiltzen da. Transakzioak sarean zehar hedatzen dira, nodoetako batetik hasita, pareko blokeen ekoizleengana iritsi arte, transakzioak blokeetan paketatzen dituztenak eta, p2p bera erabiliz, bloke berriak sareko nodo guztietan banatzen dituztenak. P2p sare modernoen oinarria Kademlia protokoloaren hainbat aldaketa dira. Hemen protokolo honen laburpen ona, eta Hemen - BitTorrent sarean hainbat neurketa dituen artikulu bat, eta hortik uler daiteke sare mota hau zerbitzu zentralizatu baten sare zurrun konfiguratutako sare bat baino konplexuagoa eta gutxiago aurreikusten dela. Gainera, Hemen Ethereum nodoentzako hainbat metrika interesgarri neurtzeari buruzko artikulua.

Laburbilduz, halako sareetako parekide bakoitzak bere kideen zerrenda dinamikoa mantentzen du, non edukien arabera zuzentzen diren informazio blokeak eskatzeko. Parekide batek eskaera bat jasotzen duenean, beharrezkoa den informazioa ematen du edo zerrendako hurrengo sasi-ausazko parekideari pasatzen dio eskaera, eta erantzuna jaso ondoren, eskatzaileari pasatzen dio eta denbora batez katxeatzen du, hau emanez. informazio blokea lehenago hurrengoan. Horrela, informazio ezaguna parekide askoren cache kopuru handi batean amaitzen da, eta ezaguna ez den informazioa pixkanaka ordezkatzen da. Parekoek erregistroak gordetzen dituzte nork transferitu dion informazio zenbat nori, eta sarea banatzaile aktiboak suspertzen saiatzen da haien balorazioak handituz eta zerbitzu-maila handiagoa eskainiz, parte-hartzaile inaktiboak automatikoki lekualdatuz parekideen zerrendetatik.

Beraz, transakzioa sarean zehar banatu behar da, bloke-ekoizleek ikusi eta blokean sartzeko. Nodoak aktiboki "banatzen" du transakzio berri bat guztion artean eta sarea entzuten du, beharrezkoa den transakzioa agertuko den indizean bloke baten zain zain dagoen bezeroari jakinarazteko. Sareak p2p sareetan transakzio eta bloke berriei buruzko informazioa elkarri transferitzeko behar duen denbora faktore askoren araberakoa da: inguruan lan egiten duten nodo zintzoen kopurua (sarearen ikuspuntutik), "bero- gora” nodo horien cacheen, blokeen tamaina, transakzioak, aldaketen izaera, sarearen geografia, nodo kopurua eta beste hainbat faktore. Horrelako sareetan errendimendu-neurrien neurketa konplexuak kontu konplexua da; beharrezkoa da eskaera prozesatzeko denbora aldi berean ebaluatzea bezeroen zein kideen (blockchain nodoak). P2p mekanismoetako edozein arazok, datuen desalojo eta cache okerrak, parekide aktiboen zerrenden kudeaketa ez eraginkorrak eta beste hainbat faktorek sare osoaren eraginkortasunari eragiten dioten atzerapenak eragin ditzakete, eta botila-lepo hori da aztertzen zailena. , proba eta emaitzen interpretazioa.

Blockchain prozesatzea eta egoera datu-baseen eguneratzea

Blockchain-aren zatirik garrantzitsuena adostasun algoritmoa da, saretik jasotako bloke berriei aplikatzea eta transakzioen prozesamendua egoera datu-basean emaitzak erregistratuz. Kateari bloke berri bat gehitzeak eta gero kate nagusia hautatzeak ahalik eta azkarren funtzionatu beharko luke. Hala ere, bizitza errealean, "behar" ez du esan nahi "funtzionatzen duena", eta imajina daiteke, adibidez, lehian dauden bi kate luze etengabe aldatzen ari diren egoera bat, etengailu bakoitzean igerilekuan dauden milaka transakzioren metadatuak aldatuz. , eta egoera datu-basea etengabe atzera botatzen. Etapa hau, botila-lepoa definitzeari dagokionez, p2p sare-geruza baino sinpleagoa da, zeren transakzioen exekuzioa eta adostasun algoritmoa zorrozki deterministak dira, eta errazagoa da hemen ezer neurtzea.
Gauza nagusia etapa honen errendimenduan ausazko degradazioa sareko arazoekin ez nahastea da - nodoak motelagoak dira kate nagusiaren inguruko blokeak eta informazioa emateko, eta kanpoko bezero batentzat sare motel bat izan daiteke, arazoa arazoa bada ere. leku guztiz ezberdina.

Etapa honetan errendimendua optimizatzeko, komeni da nodoetatik bertatik neurketak biltzea eta kontrolatzea, eta horietan txertatzea egoera-datu-basea eguneratzearekin lotutakoak: nodoan prozesatutako blokeen kopurua, haien tamaina, transakzio kopurua, kateen arteko etengailuen kopurua, bloke baliogabeen kopurua, makina birtualaren funtzionamendu-denbora, datuen konpromezu-denbora, etab. Horrek sare-arazoak kate-prozesatzeko algoritmoen akatsekin nahastea saihestuko du.

Makina birtual batek prozesatzen dituen transakzioak informazio iturri erabilgarria izan daiteke, bloke-katearen funtzionamendua optimizatu dezakeena. Memoria-esleipen-kopuruak, irakurtzeko/idazteko jarraibide-kopuruak eta kontratu-kodeen exekuzioaren eraginkortasunarekin lotutako beste neurri batzuek informazio baliagarri asko eman diezaiekete garatzaileei. Aldi berean, smart contracts programak dira, hau da, teorian baliabideren bat kontsumitu dezaketela esan nahi du: CPU/memoria/sarea/biltegiratzea, beraz, transakzioen prozesamendua fase nahiko zalantzagarria da, eta, gainera, asko aldatzen da bertsioen artean mugitzean. eta kontratu kodeak aldatzean. Hori dela eta, transakzioen prozesamenduarekin lotutako neurketak ere beharrezkoak dira blockchain-en errendimendua eraginkortasunez optimizatzeko.

Bezeroak blockchain-en transakzio bat sartzeari buruzko jakinarazpen bat jasotzea

Blockchain-eko bezeroak zerbitzua jasotzen duen azken fasea da; beste fase batzuekin alderatuta, ez dago gastu orokor handirik, baina kontuan hartu behar da bezeroak nodotik erantzun handia jasotzeko aukera (adibidez, kontratu adimenduna). datu-matrize bat itzuliz). Nolanahi ere, puntu hau da garrantzitsuena "zenbat tps daude zure blockchain-ean?" galdera egin duenarentzat, izan ere. Momentu honetan, zerbitzua jasotzeko ordua erregistratzen da.

Leku honetan, bezeroak blockchain-en erantzunaren zain egon behar zuen denbora osoa bidaltzen da beti; oraingo honetan erabiltzaileak bere aplikazioan berrespena itxarongo du, eta bere optimizazioa da. garatzaileen zeregin nagusia.

Ondorioa

Ondorioz, bloke-kateetan egiten diren eragiketa motak deskriba ditzakegu eta hainbat kategoriatan banatu:

eraldaketa kriptografikoak, froga eraikuntza
peer-to-peer sareak, transakzioak eta blokeen erreplikazioa
transakzioen prozesamendua, kontratu adimendunen exekuzioa
blockchain-en aldaketak estatuko datu-basean aplikatuz, transakzio eta blokeei buruzko datuak eguneratuz
irakurtzeko soilik eskaerak estatu datu-baserako, blockchain nodoko APIrako, harpidetza zerbitzuetarako

Oro har, blockchain nodo modernoen eskakizun teknikoak oso larriak dira: kriptografiarako CPU azkarrak, RAM kopuru handia gordetzeko eta egoera datu-basera azkar sartzeko, sareko interakzioa aldi berean irekitako konexio ugari erabiliz eta biltegiratze handia. Baldintza handi horiek eta eragiketa mota desberdinen ugaritasunak ezinbestean nodoek behar adina baliabide ez izatea eragiten dute, eta, ondoren, goian aipaturiko faseetako edozein sarearen errendimendu orokorraren beste botila bat bihur daiteke.

Blockchainen errendimendua diseinatzean eta ebaluatzean, puntu horiek guztiak kontuan hartu beharko dituzu. Horretarako, bezeroen eta sareko nodoen neurketak aldi berean bildu eta aztertu behar dituzu, haien arteko korrelazioak bilatu, bezeroei zerbitzuak emateko behar den denbora kalkulatu, baliabide nagusi guztiak kontuan hartu: CPU/memoria/sarea/biltegiratzea. , nola erabiltzen diren ulertu eta elkarri eragiten diote. Horrek guztiak bloke-kate ezberdinen abiadurak konparatzea "zenbat TPS" moduan oso esker oneko zeregina bihurtzen du, konfigurazio eta egoera ezberdin ugari baitaude. Sistema zentralizatu handietan, ehunka zerbitzariz osatutako multzoetan, arazo hauek ere konplexuak dira eta metrika ezberdin ugari biltzea ere eskatzen dute, baina bloke-kateetan, p2p sareak, makina birtualak prozesatzeko kontratuak, barne ekonomiak, gradu kopuruak direla eta. askatasuna askoz handiagoa da, eta horrek proba egiten du hainbat zerbitzaritan ere, ez da adierazgarria eta errealitatearekin ia loturarik ez duten balio oso gutxi gorabeherakoak baino ez ditu erakusten.

Hori dela eta, blockchain-en nukleoan garatzerakoan, errendimendua ebaluatzeko eta "hobetu al da azken aldiarekin alderatuta?" galderari erantzuteko software nahiko konplexua erabiltzen dugu, hamaika nodo dituen bloke-katea abiaraztea eta automatikoki erreferentzia bat abiarazten duena eta neurketak biltzen dituena. ; informazio hori gabe oso zaila da parte-hartzaile anitzekin funtzionatzen duten protokoloak araztea.

Beraz, "zenbat TPS daude zure bloke-katean?" galdera jasotzen duzunean, eskaini tea pixka bat zure solaskideari eta galdetu dozena bat grafiko ikusteko prest dagoen eta, gainera, entzun blockchain-en errendimendu-arazoen hiru koadroak eta zure iradokizunak. horiek konpontzen...

Iturria: www.habr.com

Zenbat TPS daude zure blokean?