Iga jaotatud süsteemi kohta esitatav levinud küsimus mitte-tehniliselt inimeselt on "Kui palju tps on teie plokiahelas?". Kuid vastuseks antud number ei pruugi tegelikult olla see, mida küsija kuulda tahab. Tegelikult tahtis ta küsida, "kas teie plokiahel sobib minu ärinõuetele", ja need nõuded ei ole lihtsalt üks number, vaid mitmed tingimused - sealhulgas võrgu taluvus, lõpparve nõuded, tehingute maht ja iseloom ning palju muid parameetreid. Seega on vastus küsimusele "Kui palju tps" tõenäoliselt mitte lihtne ja peaaegu kunagi mitte täielik. Jaotatud süsteem, kus on kümneid ja sadu sõlmi, mis teevad üsna keerulisi arvutusi, võib olla tohutu hulga erinevates olekutes, mis on seotud võrgu oleku, plokiahela sisu, tehniliste tõrgete, majandusprobleemide, rünnakute võrgu ja paljude muude põhjustega. Etapid, kus võib esineda jõudlusprobleeme, erinevad traditsioonilistest teenustest, ja server, mis tegutseb plokiahelas, on võrgu teenus, mis ühendab endas andmebaasi, veebiserveri ja torrent-klient jarollide, mis muudab selle äärmiselt keeruliseks koormuse profiilide osas kõikides alamsüsteemides: protsessor, mälu, võrk, salvestus.

On tulnud välja, et detsentraliseeritud võrgud ja plokiahelad on üsna spetsiifilised ja harjumatud tarkvaratooted kesksete tarkvaraarendajate jaoks. Seetõttu soovin tuua esile olulised aspektid detsentraliseeritud võrkude jõudluse ja vastupidavuse kohta, lähenemisviisid nende mõõtmiseks ja kitsaste kohtade leidmiseks. Uurime erinevaid jõudlusprobleeme, mis piiravad plokiahela teenuse pakkumise kiirusen, ja tähistame sellele tarkvarale iseloomulikke jooni.

Plokiahela kliendi teenuse päringu etapid

Kvaliteedi objektiivselt hindamiseks igasugustes keerukates teenustes tuleb arvesse võtta mitte ainult keskmisi väärtusi, vaid ka maksimaalseid/ minimaalseid väärtusi, mediaane ning persentiile. Teoreetiliselt on võimalik rääkida 1000 tps-st mingisuguses plokiahelas, kuid kui 900 tehingut toimusid erakordselt kiiresti, samas kui 100 — "seiskusid" mitme sekundi jooksul, siis kõigi tehingute kohta kogutud keskmine aeg ei pruugi olla aus näitaja kliendi jaoks, kes ei suutnud tehingut paar sekundi jooksul lõpule viia. Ajanikud, mis on põhjustatud konsensuse ringide vahelejäänud või võrgu jagunemise tõttu, võivad oluliselt halvendada teenust, mille teststandards näitas suurepärast jõudlust.

Selliste kitsaskohtade tuvastamiseks on vajalik hästi mõista etappe, mille jooksul reaalsed plokiahelad võivad kasutajate teenindamisel takistusi kogeda. Kirjeldame tehingute tarnimise, töötlemise ja uue plokiahela seisundi saamise tsüklit, mille järgi klient saab veenduda, et tema tehing on töödeldud ja arvesse võetud.

tehing vormistatakse kliendi poolt
tehing allkirjastatakse kliendi poolt
klient valib ühe sõlme ja saadab sinna oma tehingu
klient liitub state database sõlme uuendustega, oodates oma tehingu täitmise tulemusi
sõlm levitab tehingut p2p võrgus
mitmed või üks BP (block producer) töötlevad kogutud tehingud, uuendades state database
BP koostab uue ploki, töötledes vajaliku arvu tehinguid
BP levitab uut ploki p2p võrgus
uus plokk toimetatakse sõlme, millega klient ühendust võtab
sõlm uuendab state database
sõlm näeb kliendiga seotud uuendust ja saadab talle tehingu teate

Vaatame nüüd neid etappe lähemalt ja kirjeldame võimalikke jõudlusprobleeme igal etapil. Erinevalt tsentraliseeritud süsteemidest käsitleme ka koodi täitmist võrgu klientide juures. Üsna tihti, kui mõõdetakse tps-i, kogutakse tehingute töötlemise aega sõlmedelt, mitte kliendilt — see pole just aus. Klient ei huvita, kui kiiresti sõlm töötleb tema tehingut; tema jaoks on kõige olulisem hetk, mil usaldusväärne teave selle tehingu kohta, mis on lisatud plokiahelasse, talle kätte saadakse. Just see mõõdik on sisuliselt 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, koormusest ja sõlme lähedusega seotud teguritest. Seega on täiesti hädavajalik mõõta seda aega klientide juures, kuna just seda parameetrit tuleb optimeerida.

Tehingu ettevalmistamine kliendi poolel

Alustame kahest esimesest punktist: tehingu loob ja allkirjastab klient. Üllatuslikult võib see olla ka blockchain'i jõudluse kitsaskohaks kliendi vaatenurgast. See on ebatavaline tsentraliseeritud teenuste puhul, kus kõik arvutused ja andmeoperatsioonid võetakse enda kanda, jättes kliendile vaid lühikese päringu vormimise, mis suudab küsida suurt hulka andmeid või arvutusi, saades valmis tulemuse. Blockchain'ides muutub kliendikood üha võimsamaks, samas kui blockchain'i tuum on üha kergem, ning massiivsed arvutusülesanded on tavaks anda kliendi tarkvarale. Blockchain'ides on olemas kliendid, kes võivad ühe tehingu ette valmistamiseks aega kulutada (rääkides erinevatest Merkle'i tõenditest, lühikestest tõenditest, threshold_allkirjadest ja muudest keerukatest operatsioonidest kliendi poolel). Hea näide kerge on-chain valideerimise ja raskete tehingu ettevalmistuste kohta kliendi poolel on tõend kuuluvusest loendisse, mis põhineb Merkle-puul. artikkel.

Samuti ei tohi unustada, et kliendi kood mitte ainult ei saada tehinguid plokiahelasse, vaid esmalt küsib plokiahela olekut — ja see tegevus võib mõjutada võrgu koormust ja plokiahela sõlmi. Seega, mõõtmisi tehes, on mõistlik simuleerida võimalikult täielikult kliendi koodi käitumist. Isegi kui teie plokiahelas on tavalised kerged kliendid, kes panevad lihtsa digitaalse allkirja kõige lihtsamale varade edastamise tehingule, siis iga aastaga kasvab jõudluse nõudmine kliendil, krüptoalgoritmid tugevnevad ja see protsessi osa võib muutuda tulevikus tõsiseks pudelikaelakaiks. Seetõttu olge ettevaatlikud ja ärge laske mööda olukorda, kus 3,5 sekundi vältel kulub 2,5 sekundit tehingu ettevalmistamiseks ja allkirjastamiseks ning 1,0 sekundit saatmiseks võrku ja vastuse ootamiseks. Selle pudelikaela tekkimise riskide hindamiseks tuleb koguda metrikaid kliendi masinatelt, mitte ainult plokiahela sõlmedelt.

Tehingu saatmine ja selle staatuse jälgimine

Järgmiseks sammuks on tehingu saatmine valitud plokiahelasõlmesse ja selle staatuse saamine tehingute basseinile vastuvõtmise osas. See etapp on sarnane tavaliste andmebaaside päringutega, sõlm peab tehingu kirja panema basseinile ja alustama teabe edastamist p2p võrgu kaudu. Lähenemine, millega hinnatakse jõudlust, on siin sarnane traditsiooniliste Web API mikroteenuste töö hindamisega, samas kui plokiahelate tehingud saavad uuendusi ja võivad aktiivselt oma staatust muuta. Üldiselt võib tehingute kohta teabe uuendamine mõnedes plokiahelates toimuda mitu korda, näiteks ketaste harude vahel vahetamisel või kui BP teatavad oma kavatsusest lisada tehing plokki. Seda basseini suurusele ja tehingute arvule kehtestatud piirangud võivad mõjutada plokiahela jõudlust. Kui tehingute bassein on täidetud maksimaalse võimaliku suurusega või ei mahutu operatiivmälu, võib võrgu jõudlus märgatavalt langeda. Plokiahelad ei oma tsentraliseeritud vahendeid rämpssõnumite voogu kaitsta, ning kui plokiahel toetab suuri tehingute mahtusid ja madalaid tasusid, võib see viia tehingute basseini ülevooluni — see on veel üks potentsiaalne jõudluse kitsaskoht.

Plokiahelites saadab klient tehingu mis tahes soovitud plokiahelasõlme, tehingu hash on tavaliselt kliendile teada juba enne saatmist, seega tuleb tal vaid saavutada ühendus ja pärast edastamist oodata, kuni plokiahel muudab oma seisundit, lisades tema tehingu. Tähisena, et mõõtes 'tps' võib saada täiesti erinevaid tulemusi erinevate viisil ühendamiseks plokiahelasõlmega. See võib olla tavaline HTTP RPC või WebSocket, mis võimaldab rakendada 'subscribe' mustrit. Teisel juhul saab klient teavituse varem ning sõlm säästab vähem ressursse (peamiselt mälu ja liiklust) tehingu oleku vastamiseks. Seetõttu tuleb 'tps' mõõtmisel arvesse võtta viisi, kuidas kliendid on ühendatud sõlmedega. Seega, et hinnata selle bottleneck'i riske, peab plokiahela benchmark suutma emuleerida kliente nii WebSocketi kui ka HTTP RPC päringutega, proportsioonides, mis vastavad tõelistele võrkudele, ning samuti vahetama tehingute iseloomu ja nende suurust.

Selle bottleneck'i riski hindamiseks tuleb samuti koguda mõõtmisi klientide masinast, mitte ainult plokiahela sõlmedelt.

Tehingute ja plokkide edastamine p2p-võrgus

Plokiahelites kasutatakse peer-to-peer (p2p) võrguühendust tehingute ja plokkide edastamiseks osalejate vahel. Tehingud levivad võrgus, alustades ühest sõlmest, kuni nad jõuavad peer'ide-block producer'ite juurde, kes pakivad tehingud plokkidesse ja levitavad uusi plokke kõikidele sõlmedele võrgu kaudu sama p2p tehnoloogia abil. Enamiku kaasaegsete p2p võrkude aluseks on erinevad Kademlia protokolli modifikatsioonid. Siin on hea lühike ülevaade sellest protokollist, siin on — artikkel erinevate mõõtmiste kohta BitTorrent võrgus, mille põhjal saab aru, et see tüüpi võrgud on keerulisemad ja vähem ettearvatavad kui rangelt konfigureeritud tsentraliseeritud teenuse võrk. Samuti, siin on artikkel erinevate huvitavate mõõtmete mõõtmisest Ethereum'i sõlmede jaoks.

Lühidalt öeldes toetab iga peer sellistes võrkudes oma ainulaadset dünaamilist nimekirja teistest peer'idest, kellelt küsitakse teavet plokkide kohta, mis on aadressitud nende sisule. Kui peer saab päringu, siis kas ta edastab vajaliku teabe või edastab päringu järgmisele pseudo-juhuslikule peer'ile nimekirjast, ning pärast vastuse saamist edastab selle pärijale ja salvestab selle mõneks ajaks vahemällu, andes selle teabe ploki järgmine kord kiiremini. Nii satub populaarne teave paljude peer'ide vahemälludesse, samas kui vähem populaarne tõrjutakse järk-järgult kõrvale. Peer'id jälgivad, kes kellele kui palju teavet edastanud on, ning võrk püüab aktiveerida aktiivseid jagajaid, tõstes nende reitingut ja pakkudes neile kõrgemat teenustaset, automaatselt kõrvaldades mitteaktiivsed osalised peer'ide nimekirjadest.

Nii et, nüüd tuleb tehing levitada võrgus, et block-producerid näeksid seda ja saaksid selle blokki lisada. Nodo jagab aktiivselt uut tehingut kõigile soovijatele ja kuulab võrku, oodates blokki, kuhu vajalikke tehingud ilmuvad, et teavitada ootavat klienti. Aeg, mille jooksul võrk edastab üksteisele teavet uute tehingute ja blokkide kohta p2p-võrkudes, sõltub väga paljusid faktoreid: ausate ja aktiivsete (võrgupoolest) nodode arv, nende nodode vahemälu „soojendamine”, blokkide ja tehingute suurus, muudatuste iseloom, võrgu geograafia, nodode arv ja veel paljusid tegureid. Komplekssete mõõtmiste tegemine selliste võrkude töö tõhususe kohta on keeruline, kuna tuleb samaaegselt hinnata päringute töötlemise aega nii klientidelt kui ka peer-idelt (blockchain nodod). Probleemid mistahes p2p mehhanismis, vale andmete eemaldamine ja vahemälude haldamine, ebaefektiivne aktiivsete peer-ide haldamine ja paljusid muid tegureid võivad põhjustada viivitusi, mis mõjutavad kogu võrgu tõhusust, ja see kitsaskoht on kõige keerulisem analüüsimiseks, testimiseks ja tulemuste tõlgendamiseks.

Plokiahelate ja staatuse andmebaasi värskendamine

Blokeeringu töö kõige olulisem osa on konsensuse algoritm, mille rakendamine uutele, võrgu kaudu saadud plokkidele ja tehingute töötlemine, mille tulemused salvestatakse staatuse andmebaasi. Uue ploki lisamine ahelasse ja sellele järgnev peamise ahela valimine peaks toimuma võimalikult kiiresti. Siiski, reaalses elus 'peaks' ei tähenda 'töötab', ja võib näiteks kujutleda olukorda, kus kaks pikka konkurentsivõimelist ahelat vahetavad pidevalt üksteist, muutes tuhandete tehingute metaandmeid igal vahetusel ja viies pidevatesse olekute tagasipöördumisse staatuse andmebaasis. See etapp on pudelikaela määramisel lihtsalt mõistetavam kui võrgup-tp kiht, kuna tehingute täitmine ja konsensuse algoritm on rangelt määratletud, ja siin on midagi mõõta lihtsam.
Peamine on mitte segi ajada selle etapi juhuslikku jõudluse halvenemist võrgu probleemidega — sõlmed edastavad aeglasemalt plokke ja teavet peamise ahela kohta ning väline klient võib seda tõlgendada kui aeglast võrku, kuigi probleem peitub hoopis teises kohas.

Selle etapi tõhususe optimeerimiseks on kasulik koguda ja jälgida meetrikaid otse sõlmedest, sealhulgas neid, mis puudutavad state-databasi uuendamist: blokimeetrite arv, nende suurus, tehingute arv, vahetuste arvu vahel forki ahelates, kehtetute blokkide arv, virtuaalmasina tööaeg, andmete fikseerimise aeg jne. See aitab eristada võrguprobleeme ahelate töötlemise algoritmide vigadest.

Virtuaalne masin, mis tegeleb tehingute töötlemisega, võib olla kasulik teabeallikas, mis suudab optimeerida plokiahela toimimist. Mälu eraldamise hulk, read/write käskude arv ja muud mõõdikud, mis puudutavad lepingu koodi täitmise efektiivsust, võivad anda palju kasulikku teavet arendajatele. Samuti on nutilepingud programmid, mis tähendab, et nad võivad teoreetiliselt tarbida ükskõik milliseid ressursse: cpu/mälu/võrk/salvestus, nii et tehingute töötlemine on üsna määramatu etapp, mis lisaks muutub oluliselt, kui liigelda versioonide vahel ja muuta lepingute koodi. Seetõttu on tehingute töötlemisega seotud mõõdikud samuti vajalikud plokiahela jõudluse tõhusaks optimeerimiseks.

Kliendi teavitamine tehingu blokiahelasse lisamisest

See on viimane etapp kliendi teenuse saamisel plokiahelas; võrreldes teiste etappidega ei ole siin suuri kulutusi, kuid siiski tuleks arvesse võtta kliendile antava mahuka vastuse võimalust nodilt (näiteks nutileping, mis tagastab andmehulga). Igatahes on just see hetk kõige olulisem küsimusele "kui palju tps on teie plokiahelas?" kuna täpselt sellel hetkel fikseeritakse teenuse saamise aeg.

Siin peab alati olema saatmine kogu ajast, mis kulus kliendil plokiahelast vastuse ootamisele; just seda aega hakkab kasutaja ootama oma rakenduses kinnitust, ja selle optimeerimine on arendajate peamine ülesanne.

Kokkuvõte

Seetõttu saab kirjeldada plokiahelates toimuvaid operatsioonide tüüpe ning jagada need mitmesse kategooriasse:

krüptograafilised teisendused, tõendite koostamine
peer-to-peer võrgu loomine, tehingute ja plokkide replikatsioon
tehingute töötlemine, nutilepingute täitmine
muudatuste rakendamine plokiahelas olekubaasis, tehingute ja plokkide andmete uuendamine
ainult lugemise päringud state andmebaasi, blockchain node API-d, tellimusteenused

Tegelikult on tänapäevaste blockchainide nodidele esitatud tehnilised nõuded äärmiselt ranged — need vajavad kiireid CPU-sid krüptograafiaks, suurt RAM-i mahtu state andmebaasi salvestamiseks ja kiireks juurdepääsuks, võrguühendust, mis toetab suurt arvu samaaegselt avatud ühendusi, ning mahukat salvestust. Nende kõrgete nõudmiste ja erinevat tüüpi toimingute rohkuse tõttu võib nodidel ressursid lõpuks otsa saada, ja siis võib ükski eespool käsitletud etapp saada järgmise kitsaskohaks kogu võrgu jõudluses.

Plokke häälestamine ja tõhususe hindamine nõuab kõigi nende aspektide arvestamist. Selleks tuleb koguda ja analüüsida mõõdikuid nii klientidelt kui ka võrgu sõlmedelt, otsida nende vahelisi seoseid, hinnata teenuse tarnimise aega klientidele ning arvestada kõiki põhivara: cpu/mälu/võrk/säilitamine, mõista, kuidas neid kasutatakse ja kuidas nad üksteisega mõjutavad. Kõik see teeb erinevate plokiahelate kiirusvõrdluse, näiteks "kui palju TPS-i", äärmiselt tänamatuks tegevuseks, kuna olemas on tohutult erinevaid konfiguratsioone ja olekuid. Suurtes tsentraliseeritud süsteemides, sadade serverite klastrites, on need probleemid samuti keerulised ja nõuavad erinevate mõõdikute kogumist, kuid plokiahelates, p2p võrkude, virtuaalmasinate, lepingu protsesside ja sisemise majanduse tõttu on vabaduse astmete arv palju suurem, mistõttu isegi testimine mõnel serveril ei anna informatiivseid tulemusi ja näitab vaid äärmiselt umbmääraseid väärtusi, mis on peaaegu reaalsusega seotud.

Seetõttu, kui töötame välja plokiahela tuuma, kasutame jõudluse hindamiseks ja küsimuse "kas see on parem kui eelmisel korral?" vastamiseks üsna keerulist tarkvara, mis orkestreerib plokiahela käivitamist kümnete sõlmede ja automaatse benchmark'i käivitamisega ning mõõdikute kogumisega. Ilma nende andmeteta on protokollide parandamine, mis opereerivad mitme osalisega, erakordselt keeruline.

Nii et kui saad küsimuse "kui palju TPS on teie plokiahelas?", pakkuge vestluspartnerile teed ja täpsustage, kas ta on valmis tutvuma kümne graafikuga ning kuulama kõiki kolme plokiahelate jõudlusprobleemide kasti ning teie ettepanekuid nende lahendamiseks...

Allikas: habr.com