Najpogostejše vprašanje o kateri koli porazdeljeni sistemu, ki ga postavi netehnična oseba, je: "Koliko tps ima vaš blokchain?" Vendar pa številka, ki je podana kot odgovor, ponavadi nima veliko skupnega s tem, kar bi želel slišati vpraša. V resnici je želel vprašati: "Ali vaš blokchain ustreza mojim poslovnim zahtevam?" Te zahteve niso ena številka, temveč množica pogojev – tukaj so odpornost omrežja, zahteve glede končne faze, velikosti, narava transakcij in še mnogi drugi parametri. Zato odgovor na vprašanje "kolikokrat tps" verjetno ne bo preprost, in skoraj nikoli ne bo popoln. Porazdeljen sistem z desetinami in stotnimi vozlišči, ki izvajajo precej zapletene izračune, lahko obstaja v ogromnem številu različnih stanj, povezanih s stanjem omrežja, vsebino blokchaina, tehničnimi napakami, ekonomskimi težavami, napadi na omrežje in mnogimi drugimi razlogi. Stopnje, pri katerih so možne težave s zmogljivostjo, se razlikujejo od tradicionalnih storitev, in strežnik blokchain omrežja je omrežna storitev, ki združuje funkcionalnost podatkovne baze, spletnega strežnika in torrent odjemalca, kar ga dela izjemno zapletenega glede obremenitve na vse pod sisteme: procesor, pomnilnik, omrežje, shranjevanje.

Tako se je zgodilo, da so decentralizirane mreže in blokchaini precej specifična in nenavadna programska oprema za razvijalce centralizirane programske opreme. Zato bi želel osvetliti pomembne vidike zmogljivosti in stabilnosti decentraliziranih mrež, pristope k njihovi merjenju ter iskanju ozkih grl. Pregledali bomo različne težave z zmogljivostjo, ki omejujejo hitrost zagotavljanja storitev uporabnikom blokchainov, in poudarili značilnosti, tipične za to vrsto programske opreme.

Stopnje, na katerih uporabnik blokchaina zahteva storitev

Da bi se racionalno govorilo o kvalitetu bilo kojeg složenijeg servisa, potrebno je uzeti u obzir ne samo srednje vrednosti, već i maksimalne/minimalne, medijane i percentile. Teoretski, može se govoriti o 1000 tps u nekoj blockchain mreži, ali ako je 900 transakcija obavljeno izuzetno brzo, dok je 100 'zaglavilo' na nekoliko sekundi, onda prosečno vreme prikupljeno po svim transakcijama nije baš poštena metrika za klijenta koji nije mogao da završi transakciju tokom tih nekoliko sekundi. Vremenski 'rupe', uzrokovane izostavljenim krugovima konsenzusa ili deljenjem mreže, mogu značajno oštetiti servis koji je na testnim platformama pokazivao odličnu performansu.

Da bismo identifikovali takve bottleneck-e, potrebno je dobro razumeti faze u kojima stvarni blockchain može imati poteškoća u opsluživanju korisnika. Opisujmo ciklus dostave i procesiranja transakcije, kao i dobijanje novog stanja blockchain-a, iz kojeg klijent može biti siguran da je njegova transakcija procesirana i uzeta u obzir.

transakcija se formira na klijentu
transakcija se potpisuje na klijentu
klijent bira jedan od nodova i šalje mu svoju transakciju
klijent se pretplaćuje na ažuriranja state database nodova, čekajući rezultate izvršenja svoje transakcije
noda širi transakciju putem p2p mreže
nekoliko, ili jedan BP (block producer) procesuiraju prikupljene transakcije, ažurirajući state database
BP formira novi blok, obradivši potreban broj transakcija
BP širi novi blok putem p2p mreže
novi blok se dostavlja nodi kojoj se klijent obraća
noda ažurira state database
noda uočava ažuriranje vezano za klijenta i šalje mu obaveštenje o transakciji

Sedaj se podrobneje pogovorimo o teh korakih in opišimo morebitne težave pri zmogljivosti v vsakem koraku. Za razliko od centraliziranih sistemov bomo obravnavali tudi izvajanje kode na klientih mreže. Zelo pogosto, ko merimo tps, čas obdelave transakcij zbiramo z vozlišč, ne s klienta — to ni povsem pošteno. Klientu je vseeno, kako hitro je vozlišče obdelalo njegovo transakcijo, najpomembnejše zanj je, kdaj bo zaupanja vredna informacija o tej transakciji, vključeni v blockchain, na voljo. Ta metrika je v bistvu čas izvršitve transakcije. To pomeni, da lahko različni klienti, tudi če pošiljajo isto transakcijo, dobijo povsem različne čase, ki so odvisni od kanala, obremenitve in bližine vozlišča, itd. Zato je nujno meriti ta čas na klientih, saj je prav ta parameter tisti, ki ga je treba optimizirati.

Priprava transakcije na strani klienta

Začnimo z prvima dvema točkama: transakcija se oblikuje in podpisuje s strani klienta. Kakor nenavadno se morda zdi, je to lahko tudi ozko grlo zmogljivosti blockchaina z vidika klienta. To je nenavadno za centralizirane storitve, ki vse izračune in operacije z podatki prevzamejo nase, klient pa pripravi le kratek zahtevek, ki je sposoben zahtevati velik obseg podatkov ali izračunov, prejemajoč končni rezultat. V blockchainih postaja klientova koda vedno bolj zmogljiva, medtem ko je osrednji del blockchaina vedno lažji, masivna izračunavanja pa se običajno prenesejo na klientsko programsko opremo. V blockchainih obstajajo klienti, ki lahko pripravljajo eno transakcijo kar dolgo (govorim o različnih merkle proof-ih, succinct proof-ih, threshold podpisih in drugih zapletenih operacijah na strani klienta). Dober primer lahke on-chain verifikacije in težke priprave transakcije na klientu je dokaz o pripadnosti seznamu na podlagi Merkle-tree. članek.

Prav tako ne pozabite, da klientska koda ne pošilja le transakcij v blokchain, temveč najprej preverja stanje blokchaina — ta dejavnost lahko vpliva na obremenitev omrežja in nod blokchaina. Zato je smiselno emulirati vedenje klientske kode čim bolj natančno. Tudi če vaš blokchain običajno uporablja lahke kliente, ki postavljajo običajno digitalno podpis na najpreprostejšo transakcijo prenosa kakšne količine sredstev, se s vsakim letom obseg računalniških opravil na klientu povečuje, kriptoalgoritmi postajajo močnejši in ta del procesiranja se lahko v prihodnosti spremeni v resen ozko grlo. Zato bodite previdni in ne zamudite situacije, ko v transakciji, ki traja 3,5 sekunde, 2,5 sekunde preživi na pripravi in podpisovanju transakcije, in 1 sekundo na pošiljanju v omrežje in čakanju na odziv. Za oceno tveganja pojava tega ozkega grla je treba zbirati metrike z klientskih naprav, ne samo z nod blokchaina.

Pošiljanje transakcije in spremljanje njenega statusa

Naslednji korak je pošiljanje transakcije izbrani nodi blokchaina in pridobitev statusa sprejema v transakcijski sklad. Ta korak je podoben običajnemu dostopu do baze podatkov, nod mora zapisati transakcijo v sklad in začeti širiti informacije o njej preko P2P omrežja. Pristop k oceni zmogljivosti je tukaj podoben oceni delovanja tradicionalnih mikroservisov Web API, pri čemer se same transakcije v blokchainih lahko posodobijo in aktivno spreminjajo status. Na splošno lahko posodobitev informacij o transakciji v nekaterih blokchainih poteka večkrat, na primer ob preklopih med vilicami verige ali ko BP sporočajo namen vključitve transakcije v blok. Omejitve glede obsega tega sklada in števila transakcij v njem lahko vplivajo na zmogljivost blokchaina. Če je sklad transakcij poln do največjega možnega obsega, ali ne more biti shranjen v pomnilniku — se lahko zmogljivost omrežja drastično zmanjša. Blokchaini nimajo centraliziranih sredstev zaščite pred tokom odpadnih sporočil, in če blokchain podpira transakcije z velikim obsegom in nizkimi provizijami, lahko to privede do preobremenitve sklada transakcij — to je še eno potencialno ozko grlo zmogljivosti.

V blockchainih stranke pošljejo transakcijo kateri koli vozlišču blockchaina, hash transakcije je običajno znan stranki še pred pošiljanjem, tako da je edina naloga doseči povezavo in nato čakati, da se stanje blockchaina spremeni in vključi njihovo transakcijo. Ugotovimo, da lahko pri merjenju "tps" dobimo popolnoma različne rezultate za različne načine povezovanja z vozliščem blockchaina. To je lahko običajni HTTP RPC ali WebSocket, ki omogoča izvedbo vzorca "subscribe". V drugem primeru bo stranka prejela obvestilo, vozlišče pa bo porabilo manj virov (predvsem pomnilnika in prometa) za odgovore o stanju transakcije. Zato je pri merjenju "tps" potrebno upoštevati način povezovanja strank z vozlišči. Zato mora benchmark blockchaina za oceno tveganj nastanka tega ozkega grla znati emulirati stranke tako s WebSocket kot tudi s HTTP RPC zahtevami, v deležih, ki ustrezajo realnim omrežjem, ter spreminjati naravo transakcij in njihovo velikost.

Za oceno tveganj nastanka tega ozkega grla je prav tako potrebno zbirati metrike z odjemalskih naprav, ne le z blockchain vozlišč.

Prenos transakcij in blokov po p2p omrežju

V blockchainih se za prenos transakcij in blokov med udeleženci uporablja peer-to-peer (p2p) omrežje. Transakcije se širijo po omrežju, začenši z enim od vozlišč, dokler ne dosežejo peer-ov - proizvajalcev blokov, ki pakirajo transakcije v bloke in s pomočjo istega p2p širijo nove bloke po vseh vozliščih omrežja. Osnova večine sodobnih p2p omrežij so različne različice protokola Kademlia. Evo dober kratek pregled tega protokola, ki tukaj je — članek z različnimi meritvami v omrežju BitTorrent, ki lahko pokaže, da so te vrste omrežij bolj zapletene in manj predvidljive kot strogo konfigurirano omrežje centralizirane storitve. Prav tako, tukaj je članek o merjenju različnih zanimivih metrik za vozlišča Ethereum.

Na kratko, vsak peer v takih omrežjih vzdržuje svoj lasten dinamični seznam drugih peerov, od katerih zahteva bloke informacij, ki so naslovljeni glede na vsebino. Ko prejme zahtevo, peer bodisi vrne želeno informacijo, bodisi prenese zahtevo naslednjemu psevdoraspršenemu peeru na seznamu, in ko prejme odgovor, ga posreduje zahtevajočemu ter ga za določen čas shrani v predpomnilniku, kar omogoča, da se ta blok informacij znova odloži prej naslednjič. Tako se priljubljene informacije znajdejo v številnih predpomnilnikih pri mnogih peerih, medtem ko se nepomembne postopoma zatiskajo. Peeri vodijo evidenco o tem, koliko informacij je kdo prenesel, omrežje pa si prizadeva spodbujati aktivne delitelje, s čimer jim povečuje oceno in zagotavlja višjo raven storitve ter samodejno izključuje neaktivne udeležence s seznamov peerov.

Torej, transakcijo je zdaj treba razširiti po omrežju, da jo vidijo block-producerji in jo vključijo v blok. Vozlišče aktivno 'razdaja' novo transakcijo vsem zainteresiranim in posluša omrežje, pričakujoč blok, v indeksu katerega se bo pojavila želena transakcija, da obvesti čakajočega odjemalca. Čas, medtem ko omrežje prenaša informacije o novih transakcijah in blokih v p2p omrežjih, je odvisen od velikega števila dejavnikov: števila poštenih, aktivnih vozlišč, 'ogrevanja' predpomnilnikov teh vozlišč, velikosti blokov, transakcij, narave sprememb, geografije omrežja, števila vozlišč ter še mnogih drugih dejavnikov. Kompleksne meritve hitrosti v takih omrežjih so zapletena naloga, saj je treba hkrati oceniti čas obdelave zahtevkov tako na odjemalcih kot na peerih (blokchain vozliščih). Težave v kateremkoli od p2p mehanizmov, napačna izključitev in predpomnjenje podatkov, neučinkovito upravljanje seznamov aktivnih peerov in številni drugi dejavniki lahko povzročijo zamude, ki vplivajo na učinkovitost celotnega omrežja, ta tesnoba pa je najbolj zapletena za analizo, testiranje in interpretacijo rezultatov.

Obdelava verige blokov in posodabljanje state database

Najpomembnejši del dela verige blokov je algoritem soglasja, njegova uporaba pri novih, pridobljenih iz omrežja blokih in obdelava transakcij z zapisom rezultatov v stanje podatkovne baze. Dodajanje novega bloka v verigo in naslednje izbiro glavne verige mora delovati kar se da hitro. Vendar pa v resničnem življenju 'mora' ne pomeni 'deluje', in si lahko, na primer, predstavljamo situacijo, ko se dve dolgi konkurenčni verigi nenehno preklapljata med seboj, spreminjajoč metapodatke tisočih transakcij v bazenu ob vsakem preklopu, ter nenehno izvajata vračanje stanja podatkovne baze. Ta faza, v smislu določanja ozkih grl, je enostavnejša kot mrežni p2p sloj, saj sta izvajanje transakcij in algoritem soglasja strogo deterministična, kar poenostavi merjenje česarkoli tukaj.
Pomembno je ne zamenjati naključne degradacije zmogljivosti te faze s težavami v omrežju — vozlišča počasi pošiljajo bloke in informacije o glavni verigi, kar se lahko zunanjemu odjemalcu zdi kot počasno omrežje, medtem ko je težava povsem drugje.

Za optimizacijo zmogljivosti v tej fazi je koristno zbirati in spremljati metrike s samih vozlišč ter vključiti tiste, ki se nanašajo na posodabljanje podatkovne baze: število blokov, obdelanih na vozlišču, njihova velikost, število transakcij, število preklapljanj med ločnimi verigami, število neveljavnih blokov, čas delovanja virtualnega stroja, čas potrjevanja podatkov itd. To bo omogočilo, da ne zamenjamo omrežnih težav z napakami v algoritmih obdelave verig.

Procesirajoča transakcije virtualna naprava je lahko koristna informacija, ki optimizira delovanje verige blokov. Količina alokacij pomnilnika, število branja/pisanja navodil in druge metrike, ki se nanašajo na učinkovitost izvajanja kode pogodb, lahko razvijalcem nudijo mnoge koristne informacije. Hkrati so pametne pogodbe — programi, kar pomeni, da teoretično lahko porabijo katere koli od virov: cpu/pomnilnik/omrežje/shramba, zato je obdelava transakcij dokaj negotov korak, ki se poleg tega močno spreminja pri prehodih med različicami in ob spremembi kode pogodb. Zato so metrike, ki se nanašajo na obdelavo transakcij, prav tako potrebne za učinkovito optimizacijo zmogljivosti verige blokov.

Prejem obvestila o vključenju transakcije v blockchain

To je končna faza pridobivanja storitve s strani stranke v blockchainu. V primerjavi z drugimi fazami tukaj ni velikih stroškov, a kljub temu je treba upoštevati možnost prejetja obsežnega odgovora od vozlišča (na primer pametna pogodba, ki vrača niz podatkov). V vsakem primeru je ta trenutek najpomembnejši za tiste, ki sprašujejo: 'kolikšna je tps v vašem blockchainu?', saj se v tem trenutku zabeleži čas pridobivanja storitve.

Na tem mestu je nujno vključiti celotno časovno obdobje, ki ga je stranka potrebovala za čakanje na odgovor iz blockchaina. Ta čas bo uporabnik pričakoval, da bo prejel potrditev v svoji aplikaciji, in optimizacija tega časa je glavna naloga razvijalcev.

Zaključek

Rezultat je, da lahko opišemo vrste operacij, ki se izvajajo v blockchainih, in jih razdelimo v več kategorij:

kriptografske transformacije, gradnja dokazov
peer-to-peer omrežno povezovanje, replikacija transakcij in blokov
procesiranje transakcij, izvrševanje pametnih pogodb
uporaba sprememb v blockchainu v stanjskem podatkovnem sistemu, posodobitev podatkov o transakcijah in blokih
read-only poizvedbe v stanjskem podatkovnem sistemu, API blockchain vozlišča, naročniške storitve

Splošne tehnične zahteve za vozlišča sodobnih blockchainov so izredno visoke — hitro procesorji za kriptografijo, velika količina pomnilnika za shranjevanje in hitro dostopanje do stanjskega podatkovnega sistema, omrežno povezovanje, ki uporablja veliko število hkrati odprtih povezav, obsežen shranjevalni prostor. Takšne visoke zahteve in obilje različnih vrst operacij neizogibno pripeljejo do pomanjkanja virov pri vozliščih, kar lahko katere koli od prej omenjenih faz spremeni v ozko grlo za skupno zmogljivost omrežja.

Pri razvoju in ocenjevanju zmogljivosti verig blokov morate upoštevati vse te vidike. Za to je treba zbirati in analizirati metriko hkrati iz strank in vozlišč omrežja, iskati povezave med njimi, ocenjevati čas zagotavljanja storitev strankam, upoštevati vse glavne vire: CPU/memory/network/storage, razumeti, kako se ti uporabljajo in vplivajo drug na drugega. Vse to naredi primerjave hitrosti različnih verig blokov v smislu 'koliko TPS' izjemno nehvaležno nalogo, saj obstaja ogromno različnih konfiguracij in stanj. V velikih centraliziranih sistemih, grozdih iz stotin strežnikov, so ti problemi prav tako zapleteni in zahtevajo zbiranje velikega števila različnih metrik, vendar v verigah blokov, zaradi p2p omrežij, virtualnih strojev, ki procesirajo pogodbe, notranje ekonomije, je število prostih stopenj bistveno večje, kar naredi testiranje na celo več strežnikih neizrazito in prikazuje le izjemno približne vrednosti, ki skoraj nimajo zveze z realnostjo.

Zato pri razvoju v jedru verige blokov, za oceno zmogljivosti in odgovor na vprašanje 'se je izboljšalo v primerjavi s prejšnjim časom', uporabljamo precej zapleteno programsko opremo, ki orkestrira zagon verige blokov z desetinami vozlišč in samodejnim zagon ključe in zbiranjem metrike; brez teh informacij je izjemno težko odpraviti napake protokolov, ki delujejo z mnogimi udeleženci.

Torej, ko prejmete vprašanje 'koliko TPS je v vaši verigi blokov?', ponudite sogovorniku čaj in povprašajte, ali je pripravljen seznaniti s številnimi grafi in poslušati vse tri škatle težavnosti zmogljivosti verig blokov ter vaše predloge za njihovo rešitev...

Izvor: habr.com