Mėgstamiausias netechninio žmogaus klausimas apie bet kurią paskirstytą sistemą yra „Kiek tps yra jūsų blokų grandinėje? Tačiau atsakyme pateiktas skaičius paprastai turi mažai ką bendro su tuo, ką klausėjas norėtų išgirsti. Tiesą sakant, jis norėjo paklausti „ar jūsų blokų grandinė atitiks mano verslo reikalavimus“, ir šie reikalavimai yra ne vienas skaičius, o daug sąlygų – čia yra tinklo gedimų tolerancija, baigtinumo reikalavimai, dydžiai, operacijų pobūdis ir daugelis kitų parametrų. Taigi atsakymas į klausimą „kiek tps“ greičiausiai nebus paprastas ir beveik niekada neišsamus. Paskirstyta sistema su dešimtimis ar šimtais mazgų, atliekančių gana sudėtingus skaičiavimus, gali būti daugybės skirtingų būsenų, susijusių su tinklo būkle, blokų grandinės turiniu, techniniais gedimais, ekonominėmis problemomis, tinklo atakomis ir daugeliu kitų priežasčių. . Etapai, kuriuose galimos našumo problemos, skiriasi nuo tradicinių paslaugų, o „blockchain“ tinklo serveris yra tinklo paslauga, sujungianti duomenų bazės, žiniatinklio serverio ir „torrent“ kliento funkcijas, todėl ji itin sudėtinga visų posistemių apkrovos profilio atžvilgiu. : procesorius, atmintis, tinklas, saugykla

Taip atsitinka, kad decentralizuoti tinklai ir blokų grandinės yra gana specifinė ir neįprasta programinė įranga centralizuotos programinės įrangos kūrėjams. Todėl norėčiau pabrėžti svarbius decentralizuotų tinklų veiklos ir tvarumo aspektus, metodus, kaip juos išmatuoti ir rasti kliūtis. Apžvelgsime įvairias našumo problemas, kurios riboja paslaugų teikimo greitį blockchain naudotojams ir atkreipsime dėmesį į šio tipo programinei įrangai būdingas savybes.

Blockchain kliento paslaugos užklausos etapai

Norint nuoširdžiai kalbėti apie bet kokios daugiau ar mažiau sudėtingos paslaugos kokybę, reikia atsižvelgti ne tik į vidutines reikšmes, bet ir į maksimumą/minimalumą, medianas, procentilius. Teoriškai galime kalbėti apie 1000 tps tam tikroje blokų grandinėje, tačiau jei 900 operacijų buvo įvykdyta milžinišku greičiu, o 100 „užstrigo“ kelioms sekundėms, tai vidutinis laikas, surinktas per visas operacijas, nėra visiškai teisinga metrika klientui. kurio negalėjau užbaigti operacijos per kelias sekundes. Laikinos „skylės“, atsiradusios dėl praleistų konsensuso raundų arba tinklo padalijimo, gali labai sugadinti paslaugą, kuri parodė puikų našumą bandymų stenduose.

Norint nustatyti tokias kliūtis, būtina gerai suprasti etapus, kuriuose tikra blokų grandinė gali turėti sunkumų aptarnaujant vartotojus. Apibūdinkime operacijos pristatymo ir apdorojimo ciklą, taip pat naujos blokų grandinės būsenos gavimą, iš kurios klientas gali patikrinti, ar jo operacija buvo apdorota ir atsiskaityta.

sandoris formuojamas ant kliento
sandoris pasirašomas ant kliento
klientas pasirenka vieną iš mazgų ir siunčia į jį savo operaciją
klientas užsiprenumeruoja mazgo būsenos duomenų bazės atnaujinimus, laukdamas, kol pasirodys jo operacijos rezultatai
mazgas paskirsto operaciją per p2p tinklą
keli ar vienas BP (blokų gamintojas) apdoroja sukauptas operacijas, atnaujina būsenos duomenų bazę
Apdorojus reikiamą operacijų skaičių BP suformuoja naują bloką
BP platina naują bloką per p2p tinklą
naujas blokas pristatomas į mazgą, kurį pasiekia klientas
mazgas atnaujina būsenos duomenų bazę
mazgas mato kliento atnaujinimą ir siunčia jam pranešimą apie operaciją

Dabar atidžiau pažvelkime į šiuos etapus ir apibūdinkime galimas veikimo problemas kiekviename etape. Skirtingai nuo centralizuotų sistemų, mes taip pat apsvarstysime kodo vykdymą tinklo klientams. Gana dažnai, matuojant TPS, operacijos apdorojimo laikas renkamas iš mazgų, o ne iš kliento – tai nėra visiškai teisinga. Klientui nerūpi, kaip greitai mazgas apdorojo jo operaciją, jam svarbiausia yra momentas, kai jam tampa prieinama patikima informacija apie šią į blockchain įtrauktą operaciją. Būtent ši metrika iš esmės yra operacijos vykdymo laikas. Tai reiškia, kad skirtingi klientai, net ir siųsdami tą pačią operaciją, gali gauti visiškai skirtingą laiką, kuris priklauso nuo kanalo, mazgo apkrovos ir artumo ir pan. Taigi šį laiką būtina išmatuoti ant klientų, nes tai yra parametras, kurį reikia optimizuoti.

Sandorio paruošimas kliento pusėje

Pradėkime nuo pirmųjų dviejų punktų: sandorį sudaro ir pasirašo klientas. Kaip bebūtų keista, tai taip pat gali būti blokų grandinės veikimo kliūtis kliento požiūriu. Tai neįprasta centralizuotoms tarnyboms, kurios perima visus skaičiavimus ir operacijas su duomenimis, o klientas tiesiog parengia trumpą užklausą, galinčią paprašyti didelio duomenų kiekio ar skaičiavimų, gaudamas jau paruoštą rezultatą. Blokų grandinėse kliento kodas tampa vis galingesnis, o blokų grandinės branduolys tampa vis lengvesnis, o didžiulės skaičiavimo užduotys dažniausiai perkeliamos į kliento programinę įrangą. Blokų grandinėse yra klientų, kurie gana ilgai gali ruošti vieną sandorį (kalbu apie įvairius įrodinėjimus, glaustus įrodymus, slenksčio parašus ir kitas sudėtingas operacijas kliento pusėje). Geras lengvo tikrinimo grandinėje ir kruopštaus kliento sandorio paruošimo pavyzdys yra narystės sąraše, paremtame Merkle-tree, įrodymas, čia straipsnis.

Taip pat nepamirškite, kad kliento kodas ne tiesiog siunčia operacijas į blokų grandinę, o pirmiausia užklausia blokų grandinės būseną – ir ši veikla gali turėti įtakos tinklo ir blockchain mazgų perkrovimui. Taigi, atliekant matavimus, būtų tikslinga kiek įmanoma labiau imituoti kliento kodo elgesį. Net jei jūsų blokų grandinėje yra paprastų lengvųjų klientų, kurie įprastą skaitmeninį parašą parašo ant paprasčiausios operacijos, kad perduotų tam tikrą turtą, kiekvienais metais vis tiek vyksta masiškesni kliento skaičiavimai, kriptovaliutų algoritmai stiprėja, o ši apdorojimo dalis gali ateityje taps reikšminga kliūtimi. Todėl būkite atidūs ir nepraleiskite situacijos, kai 3.5 s trunkančioje operacijoje 2.5 s išleidžiama sandorio paruošimui ir pasirašymui, o 1.0 s – siuntimui į tinklą ir laukiant atsakymo. Norėdami įvertinti šios kliūties riziką, turite rinkti metrikas iš klientų mašinų, o ne tik iš blokų grandinės mazgų.

Operacijos siuntimas ir jos būsenos stebėjimas

Kitas žingsnis – nusiųsti operaciją į pasirinktą blokų grandinės mazgą ir gauti jos priėmimo į transakcijų fondą būseną. Šis etapas panašus į įprastą prieigą prie duomenų bazės; mazgas turi įrašyti operaciją į telkinį ir pradėti platinti informaciją apie ją per p2p tinklą. Našumo vertinimo metodas čia panašus į tradicinių Web API mikropaslaugų našumo vertinimą, o pačios operacijos blokų grandinėse gali būti atnaujinamos ir aktyviai keičiasi jų būsena. Apskritai kai kurių blokų grandinių sandorių informacija gali būti atnaujinta kelis kartus, pavyzdžiui, perjungiant grandinės šakes arba kai BP praneša apie savo ketinimą įtraukti operaciją į bloką. Šio telkinio dydžio ir jame atliekamų operacijų skaičiaus apribojimai gali turėti įtakos blokų grandinės veikimui. Jei operacijų telkinys užpildytas iki didžiausio galimo dydžio arba netelpa į RAM, tinklo našumas gali smarkiai sumažėti. „Blockchain“ neturi centralizuotų priemonių, apsaugančių nuo nepageidaujamų pranešimų antplūdžio, o jei „blockchain“ palaiko didelės apimties operacijas ir mažus mokesčius, tai gali sukelti transakcijų fondo perpildymą – tai dar viena galima našumo kliūtis.

Blokų grandinėse klientas siunčia operaciją į bet kurį jam patinkantį blokų grandinės mazgą, operacijos maišą klientas paprastai žino prieš išsiųsdamas, todėl jam tereikia užmegzti ryšį ir po perdavimo laukti, kol blokų grandinė pasikeis. jos būsena, leidžianti atlikti sandorį. Atkreipkite dėmesį, kad matuodami „tps“, galite gauti visiškai skirtingus rezultatus skirtingiems prisijungimo prie „blockchain“ mazgo metodams. Tai gali būti įprastas HTTP RPC arba „WebSocket“, leidžiantis įgyvendinti „prenumeratos“ modelį. Antruoju atveju klientas gaus pranešimą anksčiau, o mazgas išleis mažiau išteklių (daugiausia atminties ir srauto) atsakydamas apie operacijos būseną. Taigi matuojant „tps“ būtina atsižvelgti į tai, kaip klientai prisijungia prie mazgų. Todėl, norint įvertinti šios kliūties riziką, etaloninė blokų grandinė turi sugebėti imituoti klientus tiek WebSocket, tiek HTTP RPC užklausomis, proporcijomis, atitinkančiomis tikrus tinklus, taip pat keisti operacijų pobūdį ir jų dydį.

Norėdami įvertinti šios kliūties riziką, taip pat turite rinkti metrikas iš klientų mašinų, o ne tik iš blokų grandinės mazgų.

Sandorių ir blokų perdavimas per p2p tinklą

„Blockchain“ grandinėse naudojamas lygiavertis (p2p) tinklas transakcijoms ir blokams perduoti tarp dalyvių. Sandoriai plinta visame tinkle, pradedant nuo vieno iš mazgų, kol pasiekia lygiaverčių blokų gamintojus, kurie supakuoja operacijas į blokus ir, naudodami tą patį p2p, paskirsto naujus blokus visiems tinklo mazgams. Daugumos šiuolaikinių p2p tinklų pagrindas yra įvairios Kademlia protokolo modifikacijos. Čia gera šio protokolo santrauka ir čia - straipsnis su įvairiais BitTorrent tinklo matavimais, iš kurių galima suprasti, kad tokio tipo tinklas yra sudėtingesnis ir mažiau nuspėjamas nei griežtai sukonfigūruotas centralizuotos paslaugos tinklas. Taip pat čia Straipsnis apie įvairių įdomių Ethereum mazgų metrikų matavimą.

Trumpai tariant, kiekvienas lygiavertis tokiuose tinkluose turi savo dinaminį kitų lygiaverčių sąrašą, iš kurio jis prašo informacijos blokų, kuriems skirtas turinys. Gavęs užklausą bendraamžis arba suteikia reikiamą informaciją, arba perduoda užklausą kitam pseudoatsitiktiniam bendraamžiui iš sąrašo, o gavęs atsakymą perduoda jį užklausančiajam ir kurį laiką saugo talpykloje, pateikdamas tai. informacijos blokas kitą kartą anksčiau. Taigi populiari informacija patenka į daugybę daugelio bendraamžių talpyklų, o nepopuliari informacija palaipsniui keičiama. Bendraamžiai registruoja, kas kiek kam perdavė informacijos, o tinklas bando paskatinti aktyvius platintojus didindamas jų reitingus ir teikdamas jiems aukštesnio lygio paslaugas, automatiškai išstumdamas neaktyvius dalyvius iš kolegų sąrašų.

Taigi dabar sandoris turi būti paskirstytas visame tinkle, kad blokų gamintojai galėtų jį matyti ir įtraukti į bloką. Mazgas aktyviai „paskirsto“ naują operaciją visiems ir klausosi tinklo, laukdamas bloko, kurio indekse atsiras reikalinga operacija, kad apie tai būtų pranešta laukiančiam klientui. Laikas, per kurį tinklas perduoda informaciją apie naujas operacijas ir blokus vieni kitiems p2p tinkluose, priklauso nuo labai daug veiksnių: šalia dirbančių sąžiningų mazgų skaičiaus (tinklo požiūriu), „šiltos iki“ šių mazgų talpyklų, blokų dydžio, operacijų, pakeitimų pobūdžio, tinklo geografijos, mazgų skaičiaus ir daugelio kitų veiksnių. Sudėtingi našumo metrikos matavimai tokiuose tinkluose yra sudėtingas dalykas; būtina vienu metu įvertinti užklausų apdorojimo laiką tiek klientams, tiek bendradarbiams (blokų grandinės mazgams). Problemos bet kuriame iš p2p mechanizmų, neteisingas duomenų iškeldinimas ir kaupimas talpykloje, neefektyvus aktyvių partnerių sąrašų valdymas ir daugelis kitų veiksnių gali sukelti vėlavimus, turinčius įtakos viso tinklo efektyvumui, o šią kliūtį sunkiausia išanalizuoti. , testavimas ir rezultatų interpretavimas.

Blockchain apdorojimas ir būsenos duomenų bazės atnaujinimas

Svarbiausia blokų grandinės dalis – konsensuso algoritmas, jo taikymas naujiems blokams, gaunamiems iš tinklo, bei operacijų apdorojimas su rezultatų įrašymu į būsenos duomenų bazę. Naujo bloko pridėjimas prie grandinės ir pagrindinės grandinės pasirinkimas turėtų veikti kuo greičiau. Tačiau realiame gyvenime „turėtų“ nereiškia „veikia“, o, pavyzdžiui, galima įsivaizduoti situaciją, kai dvi ilgos konkuruojančios grandinės nuolat keičiasi tarpusavyje, keisdamos tūkstančių banke esančių transakcijų metaduomenis kiekvieno keitimo metu. , ir nuolat grąžina valstybės duomenų bazę. Šis etapas, kalbant apie kliūties apibrėžimą, yra paprastesnis nei p2p tinklo sluoksnis, nes operacijų vykdymas ir konsensuso algoritmas yra griežtai deterministiniai, todėl čia lengviau viską išmatuoti.
Svarbiausia nepainioti atsitiktinio šio etapo veikimo pablogėjimo su tinklo problemomis - mazgai lėčiau perduoda blokus ir informaciją apie pagrindinę grandinę, o išoriniam klientui tai gali atrodyti kaip lėtas tinklas, nors problema slypi visai kita vieta.

Siekiant optimizuoti našumą šiame etape, naudinga rinkti ir stebėti metriką iš pačių mazgų ir įtraukti į juos tuos, kurie susiję su būsenos duomenų bazės atnaujinimu: mazge apdorojamų blokų skaičius, jų dydis, operacijų skaičius, perjungimų tarp grandinės šakių skaičius, netinkamų blokų skaičius, virtualios mašinos veikimo laikas, duomenų perdavimo laikas ir kt. Taip tinklo problemos nebus supainiotos su grandinės apdorojimo algoritmų klaidomis.

Virtuali mašina, apdorojanti operacijas, gali būti naudingas informacijos šaltinis, galintis optimizuoti blokų grandinės veikimą. Atminties paskirstymų skaičius, skaitymo/rašymo instrukcijų skaičius ir kita metrika, susijusi su sutarties kodo vykdymo efektyvumu, gali suteikti daug naudingos informacijos kūrėjams. Tuo pačiu metu išmaniosios sutartys yra programos, o tai reiškia, kad teoriškai jos gali sunaudoti bet kokius išteklius: procesorių/atmintį/tinklą/saugyklą, todėl operacijų apdorojimas yra gana neapibrėžtas etapas, kuris, be to, labai keičiasi pereinant tarp versijų. ir keičiant sutarčių kodus. Todėl norint efektyviai optimizuoti „blockchain“ veikimą, reikia ir su operacijų apdorojimu susijusių metrikų.

Kliento pranešimo apie sandorio įtraukimą į blokų grandinę gavimas

Tai paskutinis etapas, kai „blockchain“ klientas gauna paslaugą; lyginant su kitais etapais, didelių pridėtinių išlaidų nėra, tačiau vis tiek verta pagalvoti apie galimybę klientui gauti gausų atsakymą iš mazgo (pavyzdžiui, išmaniąją sutartį). grąžinant duomenų masyvą). Bet kokiu atveju šis punktas yra svarbiausias tam, kuris uždavė klausimą „kiek tps yra jūsų blokų grandinėje?“, nes Šiuo metu fiksuojamas paslaugos gavimo laikas.

Šioje vietoje visada siunčiamas visas laikas, kurį klientas turėjo praleisti laukdamas atsakymo iš blokų grandinės; būtent šį kartą vartotojas lauks patvirtinimo savo programoje, o būtent jos optimizavimas yra pagrindinė kūrėjų užduotis.

išvada

Dėl to galime apibūdinti blokų grandinėse atliekamų operacijų tipus ir suskirstyti jas į kelias kategorijas:

kriptografinės transformacijos, įrodymo konstravimas
lygiavertis tinklas, operacijų ir blokų replikacija
operacijų apdorojimas, išmaniųjų sutarčių vykdymas
blokų grandinės pakeitimų taikymas valstybės duomenų bazei, operacijų ir blokų duomenų atnaujinimas
tik skaitymo užklausos būsenos duomenų bazei, blokų grandinės mazgo API, prenumeratos paslaugoms

Apskritai techniniai reikalavimai šiuolaikiniams blokų grandinės mazgams yra itin rimti – greiti CPU kriptografijai, didelis RAM kiekis, leidžiantis saugoti ir greitai pasiekti būsenos duomenų bazę, tinklo sąveika naudojant daugybę vienu metu atvirų jungčių ir didelė saugykla. Tokie aukšti reikalavimai ir įvairių tipų operacijų gausa neišvengiamai veda prie to, kad mazgams gali neužtekti resursų, o tada bet kuris iš aukščiau aptartų etapų gali tapti dar viena kliūtimi bendram tinklo veikimui.

Kurdami ir vertindami blokų grandinių veikimą, turėsite atsižvelgti į visus šiuos dalykus. Norėdami tai padaryti, turite vienu metu rinkti ir analizuoti metriką iš klientų ir tinklo mazgų, ieškoti sąsajų tarp jų, įvertinti laiką, kurio reikia paslaugų teikimui klientams, atsižvelgti į visus pagrindinius išteklius: cpu / atmintis / tinklas / saugykla. , suprasti, kaip jie naudojami ir daryti įtaką vieni kitiems. Dėl viso to skirtingų blokų grandinių greičių palyginimas „kiek TPS“ forma yra nepaprastai nedėkingas uždavinys, nes yra daugybė skirtingų konfigūracijų ir būsenų. Didelėse centralizuotose sistemose, šimtų serverių klasteriuose šios problemos taip pat yra sudėtingos ir reikalauja surinkti daugybę skirtingų metrikų, tačiau blokų grandinėse dėl p2p tinklų, virtualių mašinų apdorojimo sutarčių, vidaus ekonomijos, laipsnių skaičiaus. laisvė yra daug didesnė, todėl testas atliekamas net keliuose serveriuose, jis nėra orientacinis ir rodo tik itin apytiksles reikšmes, kurios beveik neturi ryšio su realybe.

Todėl kurdami „blockchain“ branduolyje, norėdami įvertinti našumą ir atsakyti į klausimą „ar pagerėjo, palyginti su praėjusiu metu“, naudojame gana sudėtingą programinę įrangą, kuri organizuoja blokų grandinės paleidimą su daugybe mazgų ir automatiškai paleidžia etaloną bei renka metrikas. ; be šios informacijos labai sunku derinti protokolus, veikiančius su keliais dalyviais.

Taigi, gavę klausimą „kiek TPS yra jūsų blokų grandinėje?“, pasiūlykite savo pašnekovui arbatos ir paklauskite, ar jis yra pasirengęs pažvelgti į keliolika grafikų, taip pat išklausyti visas tris blokų grandinės veikimo problemų dėžutes ir jūsų pasiūlymus. sprendžiant juos...

Šaltinis: www.habr.com

Kiek TPS yra jūsų blokų grandinėje?