Mittetehnilise inimese lemmikküsimus mis tahes hajutatud süsteemi kohta on "Mitu tps-d on teie plokiahelas?" Vastuseks antud numbril on aga tavaliselt vähe ühist sellega, mida küsija kuulda tahaks. Tegelikult tahtis ta küsida, kas teie plokiahel vastab minu ärinõuetele, ja need nõuded ei ole üks number, vaid palju tingimusi – siin on võrgu tõrketaluvus, lõplikkuse nõuded, suurused, tehingute olemus ja paljud muud parameetrid. Nii et vastus küsimusele "mitu tps" pole tõenäoliselt lihtne ja peaaegu kunagi täielik. Kümnete või sadade sõlmedega hajutatud süsteem, mis teeb üsna keerulisi arvutusi, võib olla tohutul hulgal erinevates olekutes, mis on seotud võrgu oleku, plokiahela sisu, tehniliste rikete, majanduslike probleemide, võrgu rünnakute ja paljude muude põhjustega. . Võimalike jõudlusprobleemide etapid erinevad tavapärastest teenustest ja plokiahela võrguserver on võrguteenus, mis ühendab endas andmebaasi, veebiserveri ja torrent-kliendi funktsionaalsused, mis muudab selle kõigi alamsüsteemide koormusprofiili osas äärmiselt keeruliseks. : protsessor, mälu, võrk, salvestusruum

Juhtub nii, et detsentraliseeritud võrgud ja plokiahelad on tsentraliseeritud tarkvaraarendajate jaoks üsna spetsiifiline ja ebatavaline tarkvara. Seetõttu soovin välja tuua detsentraliseeritud võrgustike toimivuse ja jätkusuutlikkuse olulised aspektid, lähenemised nende mõõtmisele ja kitsaskohtade leidmisele. Vaatleme erinevaid jõudlusprobleeme, mis piiravad plokiahela kasutajatele teenuste osutamise kiirust, ja paneme tähele seda tüüpi tarkvarale iseloomulikke funktsioone.

Plokiahela kliendi teenusetaotluse etapid

Et rääkida ausalt iga enam-vähem keeruka teenuse kvaliteedist, tuleb arvestada mitte ainult keskmiste väärtustega, vaid ka maksimum/miinimum, mediaanid, protsentiilid. Teoreetiliselt võib mõnes plokiahelas rääkida 1000 tps-st, aga kui 900 tehingut tehti tohutu kiirusega ja 100 jäi mõneks sekundiks “kinni”, siis ei ole kõigi tehingute pealt kogutud keskmine aeg kliendi jaoks päris õiglane mõõdik. kellega ma ei saanud tehingut mõne sekundiga lõpule viia. Ajutised "augud", mis on põhjustatud konsensusvoorude vahelejäämisest või võrgu lõhenemisest, võivad oluliselt rikkuda teenuse, mis on katsestendil suurepäraseid tulemusi näidanud.

Selliste kitsaskohtade tuvastamiseks on vaja hästi mõista, millistel etappidel võib tõelisel plokiahelal olla raskusi kasutajate teenindamisega. Kirjeldame tehingu kohaletoimetamise ja töötlemise tsüklit ning plokiahela uue oleku saamist, millest klient saab veenduda, et tema tehing on töödeldud ja arveldatud.

tehing vormistatakse kliendi peal
tehing allkirjastatakse kliendil
klient valib ühe sõlmedest ja saadab oma tehingu sellele
klient tellib sõlme olekuandmebaasi värskendused, oodates oma tehingu tulemuste ilmumist
sõlm jaotab tehingu üle p2p võrgu
mitu või üks BP (plokitootja) töötleb akumuleeritud tehinguid, uuendab olekuandmebaasi
BP moodustab pärast vajaliku arvu tehingute töötlemist uue ploki
BP jagab uue ploki üle p2p võrgu
uus plokk toimetatakse sõlme, millele klient juurde pääseb
sõlme värskendab olekuandmebaasi
sõlm näeb kliendiga seotud uuendust ja saadab talle tehinguteate

Vaatame nüüd neid etappe lähemalt ja kirjeldame iga etapi võimalikke toimivusprobleeme. Erinevalt tsentraliseeritud süsteemidest kaalume ka koodi täitmist võrguklientidel. Üsna sageli kogutakse TPS-i mõõtmisel tehingute töötlemise aeg sõlmedelt, mitte kliendilt - see pole päris õiglane. Klienti ei huvita, kui kiiresti sõlm tema tehingut töötles, tema jaoks on kõige olulisem hetk, mil selle plokiahelas sisalduva tehingu kohta saab kättesaadavaks usaldusväärne teave. See mõõdik on sisuliselt tehingu täitmise aeg. See tähendab, et erinevad kliendid, isegi sama tehingut saates, saavad kätte täiesti erinevad kellaajad, mis sõltuvad kanalist, sõlme koormusest ja lähedusest jne. Seega on absoluutselt vajalik seda aega klientide pealt mõõta, kuna see on parameeter, mida tuleb optimeerida.

Tehingu ettevalmistamine kliendi poolel

Alustame kahest esimesest punktist: tehing vormistab ja allkirjastab klient. Kummalisel kombel võib see olla ka kliendi seisukohast plokiahela toimimise kitsaskoht. See on ebatavaline tsentraliseeritud teenuste puhul, mis võtavad üle kõik arvutused ja toimingud andmetega ning klient koostab lihtsalt lühikese päringu, mis võib nõuda suurt hulka andmeid või arvutusi, saades valmis tulemuse. Plokiahelates muutub kliendikood üha võimsamaks ja plokiahela tuum muutub üha kergemaks ning massiivsed arvutusülesanded kanduvad tavaliselt üle klienttarkvarasse. Plokiahelates on kliente, kes suudavad ühte tehingut ette valmistada päris kaua (räägin siin erinevatest märgitõestustest, lakoonilistest tõestustest, läve allkirjadest ja muudest keerukatest kliendipoolsetest toimingutest). Hea näide lihtsast ahelasisesest kontrollimisest ja tehingu raskest ettevalmistamisest kliendil on Merkle-puul põhinevasse nimekirja kuulumise tõend, siin artikkel.

Samuti ärge unustage, et kliendikood ei saada lihtsalt tehinguid plokiahelasse, vaid küsib esmalt plokiahela olekut – ja see tegevus võib mõjutada võrgu ja plokiahela sõlmede ülekoormust. Seega oleks mõistlik mõõtmiste tegemisel võimalikult täielikult imiteerida kliendikoodi käitumist. Isegi kui teie plokiahelas on tavalisi kergeid kliente, kes annavad tavalise digiallkirja kõige lihtsamale tehingule mõne vara ülekandmiseks, tehakse iga aastaga kliendi kohta siiski massilisemaid arvutusi, krüptoalgoritmid muutuvad tugevamaks ja see osa töötlemisest võib muutuda tulevikus oluliseks kitsaskohaks. Seetõttu olge ettevaatlik ja ärge laske mööda olukorda, kui 3.5 s kestva tehingu puhul kulub tehingu ettevalmistamisele ja allkirjastamisele 2.5 s ning võrku saatmisele ja vastuse ootamisele 1.0 s. Selle kitsaskoha riskide hindamiseks peate koguma mõõdikuid kliendi masinatest, mitte ainult plokiahela sõlmedest.

Tehingu saatmine ja selle oleku jälgimine

Järgmine samm on saata tehing valitud plokiahela sõlme ja saada selle tehingukogumisse vastuvõtmise olek. See etapp sarnaneb tavalise juurdepääsuga andmebaasile; sõlm peab tehingu kogumis salvestama ja alustama selle kohta teabe levitamist p2p-võrgu kaudu. Toimivuse hindamise lähenemisviis on siin sarnane traditsiooniliste Web API mikroteenuste toimivuse hindamisega ning tehinguid endid plokiahelates saab värskendada ja nende olekut aktiivselt muuta. Üldiselt võib mõne plokiahela tehinguteabe värskendamine toimuda mitu korda, näiteks ahelate vahel vahetamisel või kui BP-d teatavad oma kavatsusest lisada tehing plokki. Selle kogumi suuruse ja selles tehtavate tehingute arvu piirangud võivad mõjutada plokiahela jõudlust. Kui tehingukogum on täidetud maksimaalse võimaliku suurusega või ei mahu RAM-i, võib võrgu jõudlus järsult langeda. Plokiahelatel pole tsentraliseeritud vahendeid rämpssõnumite tulva eest kaitsmiseks ja kui plokiahel toetab suuremahulisi tehinguid ja madalaid tasusid, võib see põhjustada tehingute kogumi ületäitumise – veel üks potentsiaalne jõudluse kitsaskoht.

Plokiahelates saadab klient tehingu suvalisse plokiahela sõlme, mis talle meeldib, tehingu räsi on kliendile tavaliselt enne saatmist teada, seega pole tal vaja teha muud, kui luua ühendus ja pärast edastamist oodata, kuni plokiahel muutub selle olek, mis võimaldab tema tehingut. Pange tähele, et tps-i mõõtmisega saate plokiahela sõlmega ühendamise erinevate meetodite jaoks täiesti erinevaid tulemusi. See võib olla tavaline HTTP RPC või WebSocket, mis võimaldab teil rakendada "tellimise" mustrit. Teisel juhul saab klient teate varem ja sõlm kulutab tehingu oleku kohta vastamiseks vähem ressursse (peamiselt mälu ja liiklust). Seega tuleb “tps” mõõtmisel arvestada sellega, kuidas kliendid sõlmedega ühenduse loovad. Seetõttu peab võrdlusplokiahel selle kitsaskoha riskide hindamiseks suutma emuleerida kliente nii WebSocketi kui ka HTTP RPC päringutega, proportsioonides, mis vastavad reaalsetele võrkudele, samuti muutma tehingute olemust ja nende suurust.

Selle kitsaskoha riskide hindamiseks peate koguma mõõdikuid ka kliendi masinatest, mitte ainult plokiahela sõlmedest.

Tehingute ja plokkide edastamine p2p võrgu kaudu

Plokiahelates kasutatakse tehingute ja plokkide edastamiseks osalejate vahel peer-to-peer (p2p) võrku. Tehingud levivad üle kogu võrgu, alustades ühest sõlmedest, kuni jõudmiseni partnerplokkide tootjateni, kes pakivad tehingud plokkidesse ja jaotavad sama p2p abil uued plokid kõikidesse võrgusõlmedesse. Enamike kaasaegsete p2p-võrkude aluseks on Kademlia protokolli mitmesugused modifikatsioonid. siin on selle protokolli hea kokkuvõte ja siin - artikkel erinevate mõõtmistega BitTorrent võrgus, millest saab aru, et seda tüüpi võrk on keerulisem ja vähem etteaimatav kui tsentraliseeritud teenuse jäigalt konfigureeritud võrk. Samuti siin artikkel erinevate huvitavate mõõdikute mõõtmise kohta Ethereumi sõlmede jaoks.

Lühidalt öeldes peab iga sellistes võrkudes oma dünaamilist loendit teistest partneritest, millelt ta taotleb sisuga adresseeritud teabeplokke. Kui partner saab päringu, annab ta vajaliku teabe või edastab päringu loendist järgmisele pseudojuhuslikule kaaslasele ning vastuse saamisel edastab ta selle päringu esitajale ja salvestab selle mõneks ajaks vahemällu, andes selle järgmisel korral varem. Seega satub populaarne teave suure hulga kaaslaste vahemällu ja ebapopulaarne teave asendatakse järk-järgult. Partnerid peavad arvestust selle üle, kes kui palju teavet kellele edastas, ning võrk püüab stimuleerida aktiivseid levitajaid, tõstes nende reitinguid ja pakkudes neile kõrgemat teenindustaset, tõrjudes mitteaktiivsed osalejad automaatselt välja partnerite loenditest.

Seega tuleb tehing nüüd üle võrgu levitada, et plokitootjad saaksid seda näha ja plokki kaasata. Sõlm “jagab” aktiivselt kõigile uut tehingut ja kuulab võrku, oodates plokki, mille indeksisse ilmub vajalik tehing, et teavitada ootavat klienti. Aeg, mis kulub võrgul p2p-võrkudes uute tehingute ja plokkide üksteisele teabe edastamiseks, sõltub väga paljudest teguritest: läheduses töötavate ausate sõlmede arvust (võrgu seisukohalt), üles” nende sõlmede vahemäludest, plokkide suurusest, tehingutest, muudatuste olemusest, võrgu geograafiast, sõlmede arvust ja paljudest muudest teguritest. Toimivusmõõdikute keerukad mõõtmised sellistes võrkudes on keerukad; vaja on samaaegselt hinnata päringu töötlemise aega nii klientidel kui ka partneritel (plokiahela sõlmed). Probleemid mis tahes p2p mehhanismides, vale andmete väljatõstmine ja vahemällu salvestamine, aktiivsete partnerite loendite ebatõhus haldamine ja paljud muud tegurid võivad põhjustada viivitusi, mis mõjutavad kogu võrgu kui terviku tõhusust ning seda kitsaskohta on kõige raskem analüüsida. , testimine ja tulemuste tõlgendamine.

Plokiahela töötlemine ja olekuandmebaasi uuendamine

Plokiahela kõige olulisem osa on konsensusalgoritm, selle rakendamine võrgust saadud uutele plokkidele ja tehingute töötlemine koos tulemuste salvestamisega olekuandmebaasi. Uue ploki lisamine ketti ja seejärel põhiketi valimine peaks toimima võimalikult kiiresti. Reaalses elus ei tähenda "peaks" aga "töötab" ja võib näiteks ette kujutada olukorda, kus kaks pikka konkureerivat ketti lülituvad pidevalt omavahel, muutes igal lülitusel basseinis tuhandete tehingute metaandmeid. , ja riigi andmebaasi pidevalt tagasi kerida. See etapp on kitsaskoha määratlemise mõttes lihtsam kui p2p võrgukiht, sest tehingu täitmine ja konsensusalgoritm on rangelt deterministlikud ning siin on lihtsam kõike mõõta.
Peaasi, et mitte segi ajada juhuslikku halvenemist selle etapi toimimises võrguprobleemidega - sõlmed edastavad plokke ja teavet põhiahela kohta aeglasemalt ning välise kliendi jaoks võib see tunduda aeglase võrguna, kuigi probleem seisneb täiesti erinev koht.

Selles etapis jõudluse optimeerimiseks on kasulik koguda ja jälgida mõõdikuid sõlmedelt endilt ning lisada neisse need, mis on seotud olekuandmebaasi värskendamisega: sõlmes töödeldavate plokkide arv, nende suurus, tehingute arv, keti kahvlite vaheliste lülituste arv, kehtetute plokkide arv, virtuaalmasina tööaeg, andmete edastamise aeg jne. See hoiab ära võrguprobleemide segi ajamise ketitöötlusalgoritmide vigadega.

Tehinguid töötlev virtuaalmasin võib olla kasulik teabeallikas, mis võib optimeerida plokiahela tööd. Mälueraldiste arv, lugemis-/kirjutuskäskude arv ja muud lepingukoodi täitmise tõhususega seotud mõõdikud võivad anda arendajatele palju kasulikku teavet. Samas on nutikad lepingud programmid, mis tähendab, et teoreetiliselt võivad nad tarbida mis tahes ressursse: protsessor/mälu/võrk/salvestusruum, seega on tehingute töötlemine üsna ebakindel etapp, mis lisaks muutub versioonide vahel liikumisel suuresti. ja lepingukoodide muutmisel. Seetõttu on plokiahela jõudluse tõhusaks optimeerimiseks vaja ka tehingute töötlemisega seotud mõõdikuid.

Kliendi kättesaamine teate tehingu lisamise kohta plokiahelasse

See on plokiahela kliendi teenuse saamise viimane etapp, teiste etappidega võrreldes suuri üldkulusid ei ole, kuid siiski tasub arvestada võimalusega, et klient saab sõlmelt mahuka vastuse (näiteks nutika lepingu andmemassiivi tagastamine). Igal juhul on see punkt kõige olulisem selle jaoks, kes esitas küsimuse "Mitu tps-d on teie plokiahelas?", sest Sel hetkel salvestatakse teenuse kättesaamise aeg.

Selles kohas saadetakse alati kogu aeg, mille klient pidi kulutama plokiahela vastuse ootamiseks; just sel ajal ootab kasutaja oma rakenduses kinnitust ja selle optimeerimine on arendajate peamine ülesanne.

Järeldus

Selle tulemusena saame kirjeldada plokiahelatega tehtavate toimingute tüüpe ja jagada need mitmesse kategooriasse:

krüptograafilised teisendused, tõestuskonstruktsioon
peer-to-peer võrgud, tehingud ja plokkide replikatsioon
tehingute töötlemine, nutikate lepingute täitmine
plokiahela muudatuste rakendamine olekuandmebaasi, tehingute ja plokkide andmete uuendamine
kirjutuskaitstud päringud olekuandmebaasile, plokiahela sõlme API-le, tellimusteenustele

Üldiselt on tänapäevaste plokiahela sõlmede tehnilised nõuded äärmiselt tõsised - krüptograafia jaoks mõeldud kiired CPU-d, suur hulk RAM-i olekuandmebaasi salvestamiseks ja kiireks juurdepääsuks, võrgu interaktsioon suure hulga samaaegselt avatud ühenduste abil ja suur salvestusruum. Nii kõrged nõuded ja erinevat tüüpi toimingute rohkus toovad paratamatult kaasa selle, et sõlmedel ei pruugi olla piisavalt ressursse ning siis võib mõni ülaltoodud etappidest saada järjekordseks kitsaskohaks kogu võrgu jõudluses.

Plokiahelate kavandamisel ja toimivuse hindamisel peate kõiki neid punkte arvesse võtma. Selleks tuleb klientidelt ja võrgusõlmedelt üheaegselt koguda ja analüüsida mõõdikuid, otsida nendevahelisi seoseid, hinnata klientidele teenuste osutamiseks kuluvat aega, võtta arvesse kõiki peamisi ressursse: protsessor/mälu/võrk/salvestusruum. , mõista, kuidas neid kasutatakse ja üksteist mõjutada. Kõik see muudab erinevate plokiahelate kiiruste võrdlemise “kui palju TPS-i” kujul äärmiselt tänamatuks ülesandeks, kuna erinevaid konfiguratsioone ja olekuid on tohutult palju. Suurtes tsentraliseeritud süsteemides, sadadest serveritest koosnevates klastrites on need probleemid samuti keerulised ja nõuavad ka suure hulga erinevate mõõdikute kogumist, kuid plokiahelates on tingitud p2p-võrkudest, lepinguid töötlevatest virtuaalmasinatest, sisemajandusest, kraadide arvust. vabadus on palju suurem, mis muudab testi isegi mitmes serveris, see ei ole indikatiivne ja näitab ainult äärmiselt ligikaudseid väärtusi, millel pole tegelikkusega peaaegu mingit seost.

Seetõttu kasutame plokiahela tuumas arendamisel jõudluse hindamiseks ja küsimusele “kas see on võrreldes eelmise korraga paranenud?” vastamiseks üsna keerulist tarkvara, mis korraldab kümnete sõlmedega plokiahela käivitamise ning käivitab automaatselt võrdlusaluse ja kogub mõõdikuid. ; ilma selle teabeta on mitme osalejaga töötavate protokollide silumine äärmiselt keeruline.

Seega, kui saate küsimuse "Mitu TPS-i on teie plokiahelas?", pakkuge oma vestluskaaslasele teed ja küsige, kas ta on valmis vaatama tosinat graafikut ning kuulama ka kõiki kolme kasti plokiahela toimivusprobleeme ja teie soovitusi. neid lahendades...

Allikas: www.habr.com

Mitu TPS-i on teie plokiahelas?