Najljubše vprašanje netehnične osebe o katerem koli porazdeljenem sistemu je "Koliko tps je v vaši verigi blokov?" Vendar ima številka, navedena v odgovoru, običajno malo skupnega s tem, kar bi spraševalec želel slišati. Pravzaprav je želel vprašati, "ali bo vaša veriga blokov ustrezala mojim poslovnim zahtevam," in te zahteve niso ena številka, ampak številni pogoji - tukaj so toleranca napak v omrežju, zahteve glede končnosti, velikosti, narava transakcij in številni drugi parametri. Zato odgovor na vprašanje "koliko tps" verjetno ne bo preprost in skoraj nikoli popoln. Porazdeljeni sistem z več deset ali stotinami vozlišč, ki izvajajo precej zapletene izračune, je lahko v ogromnem številu različnih stanj, povezanih s stanjem omrežja, vsebino blockchaina, tehničnimi okvarami, ekonomskimi težavami, napadi na omrežje in številnimi drugimi razlogi. . Stopnje, na katerih so možne težave pri delovanju, se razlikujejo od klasičnih storitev, omrežni strežnik blockchain pa je omrežna storitev, ki združuje funkcionalnost podatkovne baze, spletnega strežnika in torrent odjemalca, zaradi česar je izjemno kompleksna glede obremenitvenega profila vseh podsistemov. : procesor, pomnilnik, omrežje, shranjevanje

Tako se zgodi, da so decentralizirana omrežja in verige blokov precej specifična in nenavadna programska oprema za centralizirane razvijalce programske opreme. Zato bi rad izpostavil pomembne vidike uspešnosti in trajnosti decentraliziranih omrežij, pristope k njihovemu merjenju in iskanju ozkih grl. Ogledali si bomo različne težave z zmogljivostjo, ki omejujejo hitrost zagotavljanja storitev uporabnikom blockchaina, in opazili značilnosti, značilne za to vrsto programske opreme.

Faze storitvene zahteve odjemalca blockchain

Če želite iskreno govoriti o kakovosti katere koli bolj ali manj zapletene storitve, morate upoštevati ne le povprečne vrednosti, temveč tudi maksimum/minimum, mediane, percentile. Teoretično lahko govorimo o 1000 tps v neki verigi blokov, vendar če je bilo 900 transakcij opravljenih z enormno hitrostjo, 100 pa je bilo "zataknjenih" za nekaj sekund, potem povprečni čas, zbran v vseh transakcijah, ni povsem poštena metrika za stranko. ki nisem mogel dokončati transakcije v nekaj sekundah. Začasne "luknje", ki jih povzročijo zgrešeni krogi soglasja ali razcepi omrežja, lahko močno pokvarijo storitev, ki je na preskusnih mizah pokazala odlično zmogljivost.

Za prepoznavanje takšnih ozkih grl je treba dobro razumeti stopnje, na katerih ima lahko prava veriga blokov težave pri zagotavljanju storitev uporabnikom. Opišimo cikel dostave in obdelave transakcije ter pridobitev novega stanja blockchaina, iz katerega lahko stranka preveri, ali je bila njegova transakcija obdelana in obračunana.

posel se oblikuje na stranko
transakcija je podpisana na stranki
odjemalec izbere eno od vozlišč in vanj pošlje svojo transakcijo
odjemalec se naroči na posodobitve podatkovne baze stanja vozlišča in čaka, da se prikažejo rezultati njegove transakcije
vozlišče distribuira transakcijo po omrežju p2p
več ali en BP (proizvajalec blokov) obdeluje nakopičene transakcije in posodablja državno bazo podatkov
BP po obdelavi zahtevanega števila transakcij oblikuje nov blok
BP distribuira nov blok po omrežju p2p
nov blok je dostavljen v vozlišče, do katerega odjemalec dostopa
vozlišče posodablja državno bazo podatkov
vozlišče vidi posodobitev glede odjemalca in mu pošlje obvestilo o transakciji

Zdaj pa si poglejmo podrobneje te stopnje in opišimo morebitne težave z zmogljivostjo na vsaki stopnji. Za razliko od centraliziranih sistemov bomo upoštevali tudi izvajanje kode na omrežnih odjemalcih. Precej pogosto se pri merjenju TPS čas obdelave transakcij zbira od vozlišč in ne od odjemalca - to ni povsem pošteno. Odjemalca ne zanima, kako hitro je vozlišče obdelalo njegovo transakcijo, zanj je najpomembnejši trenutek, ko so mu na voljo zanesljive informacije o tej transakciji, ki je vključena v blockchain. Ta metrika je v bistvu čas izvedbe transakcije. To pomeni, da lahko različne stranke, tudi če pošiljajo isto transakcijo, prejmejo popolnoma različne čase, ki so odvisni od kanala, obremenitve in bližine vozlišča itd. Zato je nujno potrebno meriti ta čas na strankah, saj je to parameter, ki ga je potrebno optimizirati.

Priprava transakcije na strani stranke

Začnimo s prvima dvema točkama: transakcijo oblikuje in podpiše stranka. Nenavadno je, da je to lahko tudi ozko grlo pri delovanju verige blokov z vidika stranke. To je neobičajno za centralizirane storitve, ki prevzamejo vse izračune in operacije s podatki, naročnik pa preprosto pripravi kratko zahtevo, ki lahko zahteva veliko količino podatkov ali izračunov, pri čemer dobi že pripravljen rezultat. V blokovnih verigah odjemalska koda postaja vse močnejša, jedro blokovne verige pa čedalje lažje, obsežne računalniške naloge pa se običajno prenesejo na odjemalsko programsko opremo. V blokovnih verigah so odjemalci, ki lahko eno transakcijo pripravljajo precej dolgo (govorim o raznih merkle dokazih, succinct proofih, threshold signature in drugih kompleksnih operacijah na strani odjemalca). Dober primer enostavnega preverjanja v verigi in težke priprave transakcije na stranki je dokazilo o članstvu v seznamu, ki temelji na Merkle-treeju, tukaj članek.

Prav tako ne pozabite, da koda odjemalca ne pošilja preprosto transakcij v verigo blokov, ampak najprej poizveduje o stanju verige blokov – in ta dejavnost lahko vpliva na prezasedenost omrežja in vozlišč verige blokov. Zato bi bilo pri meritvah smiselno čim bolj popolno posnemati vedenje kode odjemalca. Tudi če so v vaši verigi blokov običajni lahki odjemalci, ki najenostavnejšo transakcijo za prenos nekega sredstva podpišejo z navadnim digitalnim podpisom, so vsako leto še vedno bolj množični izračuni na odjemalcu, kripto algoritmi postajajo močnejši in ta del obdelave lahko v prihodnosti postala pomembno ozko grlo. Zato bodite previdni in ne zamudite situacije, ko se pri transakciji, ki traja 3.5 s, 2.5 s porabi za pripravo in podpis transakcije, 1.0 s pa za pošiljanje v omrežje in čakanje na odgovor. Če želite oceniti tveganja tega ozkega grla, morate zbrati meritve iz odjemalskih strojev in ne le iz vozlišč verige blokov.

Pošiljanje transakcije in spremljanje njenega statusa

Naslednji korak je pošiljanje transakcije v izbrano vozlišče blockchain in prejem statusa sprejema v transakcijsko skupino. Ta stopnja je podobna običajnemu dostopu do baze podatkov; vozlišče mora zabeležiti transakcijo v bazenu in začeti distribuirati informacije o njej prek omrežja p2p. Pristop k ocenjevanju uspešnosti tukaj je podoben ocenjevanju uspešnosti tradicionalnih mikrostoritev Web API, same transakcije v verigah blokov pa je mogoče posodabljati in aktivno spreminjati njihov status. Na splošno se lahko posodabljanje informacij o transakcijah v nekaterih verigah blokov zgodi večkrat, na primer pri preklapljanju med vilicami verige ali ko BP objavijo svojo namero, da bodo transakcijo vključili v blok. Omejitve velikosti tega bazena in števila transakcij v njem lahko vplivajo na delovanje verige blokov. Če je transakcijsko področje napolnjeno do največje možne velikosti ali se ne prilega v RAM, lahko zmogljivost omrežja močno pade. Blockchains nimajo centraliziranih sredstev za zaščito pred poplavo neželenih sporočil, in če blockchain podpira velike količine transakcij in nizke provizije, lahko to povzroči prelivanje transakcijskega bazena – še eno potencialno ozko grlo pri delovanju.

V verigah blokov odjemalec pošlje transakcijo kateremu koli vozlišču verige blokov, ki mu je všeč, zgoščena vrednost transakcije je običajno znana odjemalcu pred pošiljanjem, zato mora le vzpostaviti povezavo in po prenosu počakati, da se veriga blokov spremeni njegovo stanje, ki omogoča njegovo transakcijo. Upoštevajte, da lahko z merjenjem "tps" dobite popolnoma različne rezultate za različne načine povezovanja z vozliščem blockchain. To je lahko običajni HTTP RPC ali WebSocket, ki omogoča implementacijo vzorca »naroči«. V drugem primeru bo odjemalec prej prejel obvestilo, vozlišče pa bo porabilo manj virov (predvsem pomnilnika in prometa) za odgovore o statusu transakcije. Pri merjenju “tps” je torej potrebno upoštevati način povezovanja strank z vozlišči. Zato mora biti za oceno tveganja tega ozkega grla primerjalna veriga blokov sposobna posnemati odjemalce z zahtevami WebSocket in HTTP RPC v razmerjih, ki ustrezajo resničnim omrežjem, ter spremeniti naravo transakcij in njihovo velikost.

Če želite oceniti tveganja tega ozkega grla, morate zbrati tudi meritve iz odjemalskih strojev in ne samo iz vozlišč verige blokov.

Prenos transakcij in blokov preko p2p omrežja

V verigah blokov se za prenos transakcij in blokov med udeleženci uporablja omrežje enakovrednih (p2p). Transakcije se širijo po omrežju, začenši od enega od vozlišč, dokler ne dosežejo enakovrednih proizvajalcev blokov, ki zapakirajo transakcije v bloke in z uporabo istega p2p distribuirajo nove bloke vsem omrežnim vozliščem. Osnova večine sodobnih omrežij p2p so različne modifikacije protokola Kademlia. Tu dober povzetek tega protokola in glej - članek z različnimi meritvami v omrežju BitTorrent, iz katerega je razbrati, da je tovrstno omrežje bolj kompleksno in manj predvidljivo kot togo konfigurirano omrežje centralizirane storitve. tudi glej članek o merjenju različnih zanimivih metrik za vozlišča Ethereum.

Skratka, vsak vrstnik v takšnih omrežjih vzdržuje svoj dinamični seznam drugih vrstnikov, od katerih zahteva bloke informacij, ki so naslovljene po vsebini. Ko vrstnik prejme zahtevo, poda potrebne informacije ali pa zahtevo posreduje naslednjemu psevdonaključnemu vrstniku s seznama, in ko prejme odgovor, ga posreduje zahtevniku in ga za nekaj časa shrani v predpomnilnik, tako da blok informacij naslednjič prej. Tako priljubljene informacije končajo v velikem številu predpomnilnikov velikega števila vrstnikov, nepriljubljene informacije pa se postopoma nadomestijo. Peerji vodijo evidenco o tem, kdo je komu prenesel koliko informacij, omrežje pa skuša aktivne distributerje stimulirati tako, da zvišuje njihove ocene in jim zagotavlja višjo raven storitev, s čimer samodejno izpodriva neaktivne udeležence s peer seznamov.

Torej je treba transakcijo zdaj porazdeliti po celotnem omrežju, tako da jo lahko proizvajalci blokov vidijo in vključijo v blok. Vozlišče aktivno »distribuira« novo transakcijo vsem in posluša omrežje ter čaka na blok, v indeksu katerega se pojavi zahtevana transakcija, da obvesti čakajočega odjemalca. Čas, potreben, da omrežje med seboj prenese informacije o novih transakcijah in blokih v omrežjih p2p, je odvisen od zelo velikega števila dejavnikov: števila poštenih vozlišč, ki delujejo v bližini (z omrežnega vidika), »toplega« navzgor« predpomnilnikov teh vozlišč, velikost blokov, transakcije, narava sprememb, geografija omrežja, število vozlišč in številni drugi dejavniki. Kompleksne meritve metrike zmogljivosti v takšnih omrežjih so kompleksna zadeva, potrebno je sočasno ovrednotiti čas obdelave zahtev tako na odjemalcih kot na enakovrednih (blockchain vozliščih). Težave v katerem koli od mehanizmov p2p, nepravilno izločanje in predpomnjenje podatkov, neučinkovito upravljanje seznamov aktivnih vrstnikov in številni drugi dejavniki lahko povzročijo zamude, ki vplivajo na učinkovitost celotnega omrežja kot celote, in to ozko grlo je najtežje analizirati , test in interpretacija rezultatov.

Obdelava blokovnih blokov in posodabljanje državne baze podatkov

Najpomembnejši del verige blokov je konsenzni algoritem, njegova uporaba na nove bloke, prejete iz omrežja, in obdelava transakcij z zapisom rezultatov v državno bazo podatkov. Dodajanje novega bloka v verigo in nato izbira glavne verige mora delovati čim hitreje. Vendar pa v resničnem življenju "mora" ne pomeni "deluje" in lahko si na primer predstavljamo situacijo, v kateri dve dolgi konkurenčni verigi nenehno preklapljata med seboj in ob vsakem preklopu spreminjata metapodatke tisočih transakcij v skupini in nenehno vračanje državne baze podatkov. Ta stopnja je v smislu definiranja ozkega grla enostavnejša od omrežne plasti p2p, ker izvedba transakcije in algoritem soglasja sta strogo deterministična in tukaj je lažje kar koli izmeriti.
Glavna stvar je, da ne zamenjujete naključnega poslabšanja delovanja te stopnje z omrežnimi težavami - vozlišča počasneje dostavljajo bloke in informacije o glavni verigi, za zunanjega odjemalca pa je to lahko videti kot počasno omrežje, čeprav je težava v popolnoma drug kraj.

Za optimizacijo delovanja na tej stopnji je koristno zbirati in spremljati metrike iz samih vozlišč in vanje vključiti tiste, ki so povezane s posodabljanjem podatkovne baze stanja: število blokov, obdelanih na vozlišču, njihova velikost, število transakcij, število preklopov med vilicami verige, število neveljavnih blokov, čas delovanja virtualnega stroja, čas predaje podatkov itd. To bo preprečilo, da bi težave z omrežjem zamenjali z napakami v algoritmih za obdelavo verige.

Virtualni stroj, ki obdeluje transakcije, je lahko koristen vir informacij, ki lahko optimizirajo delovanje verige blokov. Število dodelitev pomnilnika, število navodil za branje/pisanje in druge metrike, povezane z učinkovitostjo izvajanja pogodbene kode, lahko razvijalcem zagotovijo veliko koristnih informacij. Hkrati so pametne pogodbe programi, kar v teoriji pomeni, da lahko porabijo kateri koli vir: cpu/pomnilnik/omrežje/shramba, zato je obdelava transakcij precej negotova faza, ki se poleg tega močno spreminja pri prehodu med različicami. in pri spreminjanju kod pogodbe. Zato so za učinkovito optimizacijo delovanja verige blokov potrebne tudi meritve, povezane z obdelavo transakcij.

Stranka prejme obvestilo o vključitvi transakcije v verigo blokov

To je zadnja faza prejema storitve odjemalca blockchain, v primerjavi z drugimi stopnjami ni velikih režijskih stroškov, vseeno pa je vredno razmisliti o možnosti, da odjemalec prejme obsežen odgovor od vozlišča (npr. pametna pogodba). vračanje niza podatkov). V vsakem primeru je ta točka najpomembnejša za tistega, ki je postavil vprašanje "koliko tps je v vaši verigi blokov?", ker V tem trenutku se zabeleži čas prejema storitve.

Na tem mestu je vedno pošiljanje celotnega časa, ki ga je moral odjemalec porabiti za čakanje na odgovor iz blockchaina, ta čas bo uporabnik čakal na potrditev v svoji aplikaciji, prav njegova optimizacija pa je glavna naloga razvijalcev.

Zaključek

Posledično lahko opišemo vrste operacij, ki se izvajajo na verigah blokov, in jih razdelimo v več kategorij:

kriptografske transformacije, konstrukcija dokazov
mreženje enakovrednih, podvajanje transakcij in blokov
obdelava transakcij, izvajanje pametnih pogodb
apliciranje sprememb v blockchainu v državno bazo, posodabljanje podatkov o transakcijah in blokih
zahteve samo za branje v državno bazo podatkov, API vozlišča blockchain, naročniške storitve

Na splošno so tehnične zahteve za sodobna vozlišča blockchain izjemno resne - hitri procesorji za kriptografijo, velika količina RAM-a za shranjevanje in hiter dostop do državne baze podatkov, omrežna interakcija z uporabo velikega števila hkrati odprtih povezav in velik prostor za shranjevanje. Tako visoke zahteve in obilica različnih vrst operacij neizogibno vodijo do dejstva, da vozlišča morda nimajo dovolj virov, nato pa lahko katera koli od zgoraj obravnavanih stopenj postane še eno ozko grlo za celotno delovanje omrežja.

Pri načrtovanju in ocenjevanju učinkovitosti verig blokov boste morali upoštevati vse te točke. Če želite to narediti, morate zbirati in analizirati metrike hkrati od odjemalcev in omrežnih vozlišč, iskati korelacije med njimi, oceniti čas, potreben za zagotavljanje storitev odjemalcem, upoštevati vse glavne vire: cpu/pomnilnik/omrežje/pomnilnik , razumeti, kako se uporabljajo in vplivajo drug na drugega. Zaradi vsega tega je primerjanje hitrosti različnih blockchainov v obliki “koliko TPS” izjemno nehvaležno opravilo, saj je različnih konfiguracij in stanj ogromno. V velikih centraliziranih sistemih, grozdih več sto strežnikov, so te težave prav tako zapletene in prav tako zahtevajo zbiranje velikega števila različnih metrik, v blokovnih verigah pa zaradi p2p omrežij, pogodb za obdelavo virtualnih strojev, notranjih ekonomij, števila diplom svobode je veliko večja, zaradi česar je test tudi na več strežnikih, je neindikativen in prikazuje le zelo približne vrednosti, ki nimajo skoraj nobene povezave z realnostjo.

Zato pri razvoju v jedru verige blokov za oceno uspešnosti in odgovor na vprašanje "ali se je izboljšala v primerjavi s prejšnjim časom?" uporabljamo precej zapleteno programsko opremo, ki orkestrira zagon verige blokov z več desetimi vozlišči in samodejno zažene merilo uspešnosti ter zbira meritve. ; brez teh informacij je izjemno težko odpraviti napake v protokolih, ki delujejo z več udeleženci.

Torej, ko prejmete vprašanje "koliko TPS je v vaši verigi blokov?", ponudite sogovorniku čaj in ga vprašajte, ali je pripravljen pogledati ducat grafov ter prisluhniti vsem trem poljem težav z zmogljivostjo verige blokov in vašim predlogom za reševanje njih...

Vir: www.habr.com

Koliko TPS je v vaši verigi blokov?