Küsimus, mis sageli tekib mis tahes hajutatud süsteemi kohta mitte-tehnilise spetsialisti poolt, on "Kui palju tps on teie plokiahelas?" Ent vastuseks antud number ei haaku tavaliselt sellega, mida küsija tegelikult kuulda tahaks. Tegelikult soovis ta küsida: "Kas teie plokiahel vastab minu ettevõtte nõuetele?" Need nõudmised ei piirdu ühe numbriga, vaid koosnevad mitmest tingimusest – sealhulgas võrgu talitlushäiretest, lõplikkuse nõuetest, tehingute suurusest, iseloomust ja paljusid teisi parameetreid. Seetõttu on vastus küsimusele "kui palju tps" harva lihtne ning peaaegu kunagi mitte ammendav. Hajutatud süsteem, kus on kümneid ja sadu sõlmi, mis teevad üsna keerulisi arvutusi, võib olla tohutul hulgal erinevates seisundites, mis on seotud võrgu olukorra, plokiahela sisuga, tehniliste riketega, majanduslike probleemidega, rünnakutega võrgu vastu ja paljude muude põhjustega. Etapid, mille jooksul võivad tekkida jõudlusprobleemid, erinevad traditsioonilistest teenustest, ning plokiahela võrgu server on võrgu teenus, mis ühendab endas andmebaasi, veebi serveri ja torrent-klientide funktsioone, mistõttu on sellel äärmiselt keeruline koormuse profiil kõigis alamsüsteemides: protsessor, mälu, võrk, salvestus.

Nii juhtus, et detsentraliseeritud võrgud ja plokiahelad on arendajatele, kes töötavad tsentraliseeritud tarkvaraga, tõeliselt spetsiifiline ja ebatavaline tarkvara. Seetõttu sooviksin käsitleda detsentraliseeritud võrkude jõudluse ja vastupidavuse olulisi aspekte, lähenemisviise nende mõõtmiseks ja kitsaskohtade leidmiseks. Vaatame erinevaid jõudluse probleeme, mis piiravad plokiahelate teenuse pakkumise kiirus, ning märkime ära selle tarkvaratüübi omadused.

Plokiahela kliendi teenuse taotlemise etapid

Ette ausutlese kvaliteedi kohta mistahes keerukama teenuse osas, on oluline arvestada mitte ainult keskmisi, vaid ka maksimaalseid/minimaalseid, mediaane ja persentiile. Teoreetiliselt võib rääkida 1000 tps-st mõnes blockchainis, kuid kui 900 tehingut toimusid vägagi kiiresti, samas kui 100 „hanges“ mõneks sekundiks, siis kõikide tehingute keskmine aeg ei ole klientide jaoks aus mõõdik, kes ei saanud paarikümne sekundi jooksul tehingut lõpetada. Ajalisest „aukkesest“, mis on põhjustatud konsensuse ringide vahelejätmisest või võrgu jagunemisest, võivad tõsiselt rikkuda teenuse, mis katsetest näitas suurt jõudlust.

Selliste pudelikaelte tuvastamiseks on vajalik hästi mõista etappe, mille jooksul võib tõeline blockchain kasutajate teenindamisel raskusi kogeda. Kirjeldame tehingu tarnimise ja töötlemise tsüklit, samuti uue blockchaini oleku saamist, mille põhjal klient saab veenduda, et tema tehing on töödeldud ja arvesse võetud.

tehingu vormistamine kliendis
tehingu allkirjastamine kliendis
klient valib ühe sõlme ja saadab sinna oma tehingu
klient tellib sõlme oleku andmebaasi uuendusi, oodates oma tehingu täitmise tulemusi
sõlm levitab tehingu p2p võrgus
mitmed või üks BP (block producer) töötlevad kogunenud tehingud, uuendades oleku andmebaasi
BP vormib uue bloki, töötledes vajaliku arvu tehinguid
BP levitab uue bloki p2p võrgus
uus blokk toimetatakse sõlmeni, mille poole klient pöördub
sõlm uuendab oleku andmebaasi
sõlm näeb kliendiga seotud uuendusi ja saadab talle tehingu teate

Nüüd vaatame lähemalt neid etappe ja kirjeldame iga etapi võimalikke jõudlusprobleeme. Erinevalt tsentraliseeritud süsteemidest käsitleme ka koodi täitmist võrgu klientide poolel. Suhteliselt tihti, kui mõõdetakse tps-i, kogutakse tehingute töötlemise aega node'itelt, mitte kliendilt — see ei ole täiesti aus. Kliendile ei puutu see kuigi palju, kui kiiresti node töötles tema tehingut; kõige olulisem on, millal usaldusväärne teave kõnealuse tehingu kohta, mis on lisatud plokiahelasse, temani jõuab. Just see mõõdik on tegelikult tehingu täitmise aeg. See tähendab, et erinevad kliendid, isegi saates sama tehingu, võivad saada täiesti erinevaid aegu, mis sõltuvad kanalist, koormatusest ja node'i lähedusest jne. Seetõttu on täiesti hädavajalik mõõta seda aega klientide peal, kuna just seda parameetrit tuleb optimeerida.

Tehingu ettevalmistamine kliendi poolel

Alustame kahest esimesest punktist: tehingu koostamine ja allkirjastamine kliendi poolt. Kuigi see võib tunduda ootamatuna, võib see samuti olla plokiahela jõudluse kitsaskohaks kliendi vaatepunktist. See on harjumatu tsentraliseeritud teenuste jaoks, kus kõik arvutused ja andmete töötlemine jäävad neile, ning klient valmistab lihtsalt lühikese päringu, mis suudab küsida suurt hulka andmeid või arvutusi, saades valmis tulemuse. Plokiahelates muutub kliendi kood üha võimsamaks, samas kui plokiahela tuum muutub üha kergemaks, ning massiivsed arvutusülesanded antakse tavaliselt kliendi tarkvara kätte. Plokiahelates on kliente, kes võivad ühe tehingu ettevalmistamisega aega kulutada (räägin erinevatest merkle'i tõenditest, kokkuvõtlikest tõenditest, künnise allkirjadest ja muudest keerukatest toimingutest kliendi poolel). Hea näide kerge on-chain verifitseerimise ja raskete tehingute ettevalmistamise kohta kliendi poolel on tõend kuuluvusest loendisse, mis põhineb Merkle-puus. artikkel.

Ärge unustage, et kliendi kood ei saada lihtsalt tehinguid plokiahelasse, vaid kõigepealt küsib plokiahela olekut — see tegevus võib mõjutada võrgu koormust ja plokiahela node'e. Seetõttu on mõistlik emuleerida kliendi koodi käitumist nii täielikult kui võimalik, kui teete mõõtmisi. Isegi kui teie plokiahelas on tavalised kerged kliendid, kes teevad tavalisi digitaalallkirju lihtsate tehingute jaoks, näiteks varade ülekandmiseks, suureneb iga aastaga arvutuste hulk kliendi poolel, krüptograafilised algoritmid muutuvad tugevamaks ja see töötlemise osa võib muutuda tulevikus märkimisväärseks kitsaskohaks. Seetõttu olge ettevaatlik, et mitte mööda lasta olukorrast, kus 3,5-sekundilise tehingu jooksul kulub 2,5 sekundit tehingu ettevalmistamiseks ja allkirjastamiseks ning 1,0 sekundit saatmiseks võrku ja vastuse ootamiseks. Selle kitsaskoha riski hindamiseks tuleb koguda mõõdikud kliendimasinatelt, mitte ainult plokiahela node'delt.

Tehingu saatmine ja selle staatuse jälgimine

Järgmine etapp on tehingu saatmine valitud plokiahela node'isse ja selle staatuse saamine tehingute üleslaadimise kohal. See etapp sarnaneb tavalise andmebaasi pärimisega, node peab tehingu üles kirjutama ja hakkama seda teavet levitama p2p-võrgus. Lähenemine siin oleva jõudluse hindamisel on sarnane traditsiooniliste mikroteenuste Web API hindamisele, kusjuures plokiahelates võivad iseeneslikud tehingud uuenduda ja aktiivselt oma staatust muuta. Üldiselt võib tehingu teabe uuendamine mõnes plokiahelas toimuda mitu korda, näiteks kettaahjude vahetamise korral või kui BP teavitavad plokiahela soovist tehingut plokki lisada. Selle tehingute hulga ja arvu piirangud võivad mõjutada plokiahela jõudlust. Kui tehingute hulk on täidetud maksimaalse lubatud suurusega või ei mahu operatiivmälu sisse, võib võrgu jõudlus järsult langeda. Plokiahelad ei oma tsentraliseeritud kaitsemehhanisme prügisõnumite voo vastu ning kui plokiahel toetab suure mahuga tehinguid ja madalaid tasusid, võib see põhjustada tehingute hulga ülekoormuse — see on veel üks potentsiaalne jõudluse kitsaskoht.

Ahelis, klient edastab tehingu igasse talle meelepärasesse plokk-ahelasse, tehingu räsi on tavaliselt kliendile teada juba enne saatmist, seega on kõik, mida tal on vaja teha — saavutada ühendus ja pärast edastamist oodata, kuni plokk-ahel muudab oma olekut, lisades tema tehingu. Tuleb märkida, et 'tps' mõõtmisel on erinevate ühendusmeetodite jaoks võimalik saada täiesti erinevaid tulemusi. See võib olla tavaline HTTP RPC või WebSocket, mis võimaldab rakendada 'subscribe' malli. Teises juhul saab klient teavituse varem ja sõlm kulutab vähem ressursse (peamiselt mälu ja liiklust) tehingu oleku vastuste jaoks. Seega tuleb 'tps' mõõtmisel arvesse võtta, kuidas kliendid on ühendatud plokk-ahelate sõlmedega. Seetõttu peaks plokk-ahela jõudluse hindamiseks olema võimalik simuleerida kliente nii WebSocketi kui ka HTTP RPC päringutega, osakaaludega, mis vastavad reaalsetele võrgustikele, samuti muutma tehingute laad ja nende suuruse.

Selle bottleneck'i tekke riskide hindamiseks tuleb koguda mõõdikud ka kliendi masinatelt, mitte ainult plokk-ahela sõlmedelt.

Tehingute ja plokkide edastamine p2p-võrgus

Plokk-ahelates kasutatakse osalejate vahel tehingute ja plokkide edastamiseks peer-to-peer (p2p) võrkude. Tehingud levivad võrgus, alustades ühest sõlmest, kuni need jõuavad peer'ide-blokki tootjate juurde, kes pakivad tehingud plokkidesse ja levitavad uusi plokke kõigile võrgus olevatele sõlmedele sama p2p kaudu. Enamikule tänapäeva p2p võrkudele tuginevad erinevad Kademlia protokolli modifikatsioonid. Siin hea lühike ülevaade sellest protokollist, ja siin on — artikkel erinevate mõõtmiste kohta BitTorreni võrgus, millest võib aru saada — et see tüüp võrke on keerulisem ja vähem ettearvatav kui rangelt seadistatud keskse teenuse võrk. Samuti, siin on artikkel erinevate huvitavate mõõdikute mõõtmisest Ethereum'i sõlmedes.

Kokkuvõttes toetab iga peer sellistes võrkudes oma dünaamilist nimekirja teistest peer-idest, kellelt ta pärib teabeplokke, mis on adresseeritud sisu järgi. Kui peer saab päringu, annab ta kas vajaliku teabe edasi või edastab päringu järgmisele pseudojuhuslikule peer-ile nimekirjast ja, kui vastus on saadud, edastab selle pärijale ning salvestab selle mõneks ajaks vahemällu, edastades selle teabeploki järgmine kord varem. Nii satub populaarne teave mitmesse vahemällu paljude peer-ide juurde, samas kui ebasoodsat teavet tõrjutakse järk-järgult. Peer-id jälgivad, kes kellele kui palju teavet edastas, ning võrk püüab aktiveerida aktiivseid levitajaid, tõstes nende reitingut ja pakkudes neile kõrgemat teenindustaset, eemaldades automaatselt mitteaktiivseid osalejaid peer-ide nimekirjadest.

Nüüd tuleb tehing levitada võrku, et block-producer-id näeksid seda ja saaksid selle blokki lisada. Node levitab aktiivselt uut tehingut kõigile soovijatele ja kuulab võrku, oodates blokki, kuhu vajaliku tehingu jäädvustatakse, et teavitada ootavat klienti. Aeg, mille võrgu inglid omavahel teabe edastamiseks uute tehingute ja plokkide kohta p2p võrkudes, sõltub väga paljusid teguritest: ausate töötavate node-ide arv, nende node-ide vahemälu „kuumutamine“, plokkide suurus, tehingud, muudatuste iseloom, võrgu geograafia, node-ide arv ja veel paljusid teisi tegureid. Komplekssete jõudluse mõõtmiste tegemine sellistes võrkudes on keeruline ülesanne, kuna tuleb samal ajal hinnata päringute töötlemise aega nii klientidel kui ka peer-idel (blockchain node-id). Probleemid mis tahes p2p mehhanismides, vale andmete tõrje ja vahemällu salvestamine, ebaefektiivne aktiivsete peer-ide loendite haldamine ning paljusid teisi tegureid võivad põhjustada viivitusi, mis mõjutavad kogu võrgustiku efektiivsust ning see kitsaskohad on kõige keerulisem analüüsida, testida ja tulemusi tõlgendada.

Ploki ahela töötlemine ja oleku andmebaasi värskendamine

Blokeina kõige olulisem osa on konsensuse algoritm, selle rakendamine uutest, võrgust saadud plokkidest ja tehingute töötlemine, tulemuste salvestamine state database. Uue ploki lisamine ahelasse ja sellele järgnev peamise ahela valimine peaks toimuma nii kiiresti kui võimalik. Kuid reaalses elus ei tähenda "peaks" "toimib" ja näiteks võib ette kujutada olukorda, kus kaks pikka konkureerivat ahelat vahelduvad pidevalt, muutes tuhandete tehingute metainfot igal vaheldusel ja tekitades pidevaid tagasihoidke state database. See etapp on bottleneck'i määratlemise osas lihtsam kui võrgu p2p kiht, kuna tehingute täitmine ja konsensuse algoritm on rangelt määratletud ning midagi on siinkohal lihtsam mõõta.
Peamine on mitte segi ajada selle etapi juhuslikku jõudluse halvenemist võrguprobleemidega — sõlmed jagavad bloke ja peamise ahela teavet aeglasemalt ning väliskliendi jaoks võib see tunduda kui aeglane võrguühendus, kuigi probleem on hoopis mujal.

Perfektsuse optimeerimiseks on selle etapi puhul kasulik koguda ja jälgida metrikat otse sõlmedest, ning hõlmata ka neid, mis puudutavad state-database'i uuendamist: plokkide arv, mida sõlm töötleb, nende suurus, tehingute arv, vahetuste arv ahela forkide vahel, valeplokkide arv, virtuaalse masina tööaeg, andmete fikseerimise aeg jne. See aitab eristada võrguprobleeme protsessimise algoritmide vigadest.

Tehingute töötlev virtuaalne masin võib olla kasulik teabeallikas, mis suudab optimeerida blokeina tööd. Mälu eraldamise arv, read/write juhiste arv ja muud metrikad, mis puudutavad lepingute koodi täitmise efektiivsust, võivad anda arendajatele palju kasulikku teavet. Samas, nutilepingud on programmid, mis tähendavad, et nad võivad teoorias kasutama kõiki ressursse: cpu/mälu/võrk/salvestus, seega on tehingute töötlemine üsna määramatu etapp, mis muutub oluliselt versioonide vahel ning lepingute koodi muutmisel. Seetõttu on metrikad, mis käsitlevad tehingute töötlemist, samuti vajalikud blokeina jõudluse efektiivseks optimeerimiseks.

Kliendi teavitamine tehingu aktiveerimisest plokiahelas

See on plokiahela teenuse saamise lõppfaasi etapp, erinevalt teistest etappidest ei ole siin suuri kõrvalkulusid, kuid siiski tuleks arvestada võimalusega, et klient saab nodilt mahuka vastuse (näiteks nutileping, mis tagastab andmevahemiku). Igal juhul on just see hetk kõige olulisem küsimusele 'kui palju tps on teie plokiahelas?' vastamisel, kuna sellel hetkel fikseeritakse teenuse saamise aeg.

Siin on hädavajalik edastada kogu aeg, mida klient pidi ootama plokiahelt vastust, just seda aega ootab kasutaja oma rakenduses kinnitust ning selle optimeerimine on arendajate peamine ülesanne.

Kokkuvõte

Tulemuseks on võimalik kirjeldada plokiahelates toimuvaid tehingute tüüpe ja jagada need mitmesse kategooriasse:

krüptograafilised muundamisprotsessid, tõendite koostamine
peer-to-peer võrgustik, tehingute ja plokkide replikatsioon
tehingute töötlemine, nutilepingute täitmine
muudatuste rakendamine plokiahelas state database-le, tehingute ja plokkide andmete uuendamine
ainult lugemise päringud state database-le, plokiahela nodi API, tellimiste teenused

Tegelikult on kaasaegsete plokiahela nodide tehnilised nõuded äärmiselt ranged — vajalikud on kiired CPU-d krüptograafia jaoks, suur hulk operatiivmälu andmete salvestamiseks ja kiireks ligipääsuks state database-le, võrguühendus, mis kasutab suurt hulka samaaegselt avatud ühendusi, mahukas salvestusruum. Need kõrged nõuded ja erinevate tehingutüüpide rohkus toovad paratamatult kaasa, et nodi ressursid võivad osutuda ebapiisavaks ning sel juhul võib mis tahes eespool arutletud etapp muutuda koguvõrgu üldise jõudluse kitsaskohaks.

Plokku, kui arendate ja hindate plokiahelate tõhusust, peate arvesse võtma kõiki neid aspekte. Selleks on vaja koguda ja analüüsida mõõdikuid samaaegselt klientidelt ja võrgu sõlmedelt, otsida nende vahel korrelatsioone, hinnata teenuse pakkumise aega klientidele, võtta arvesse kõiki põhivahendeid: cpu/mälu/võrk/salvestamine, mõista, kuidas neid kasutatakse ja kuidas nad üksteist mõjutavad. Kõik see muudab erinevate plokiahelate kiirusenäitamise nagu

Seetõttu kasutame plokiahela tuumas arendamisel jõudluse hindamiseks ja küsimusele "kas on võrreldes eelmise korraga paranenud" vastamiseks üsna keerulist tarkvara, mis korraldab plokiahela käivitamise kümmekonna sõlmega ja automaatse benchmarku käivitamise ning mõõdikute kogumise; ilma selle teabeta on äärmiselt keeruline tõrkeotsingut teostada protokollides, mis töötavad paljude osalejatega.

Nii et kui keegi küsib: "kui palju TPS teie plokiahelas?", siis pakkuge tal vajalikku teed ja küsige, kas ta on valmis tutvuma tosinaga diagrammidega ning kuulama ära kõik plokiahelate jõudluse probleemide kolm kasti ja teie ettepanekud nende lahendamiseks…

Allikas: habr.com