Omiljeno pitanje o bilo kojem distribuiranom sistemu od strane netehničara je „Koliko tps-a ima na vašem blockchainu?“ Međutim, broj koji se daje u odgovoru obično nema mnogo zajedničkog sa onim što bi pitalac želio da čuje. Zapravo, želio je pitati “hoće li vaš blockchain odgovarati mojim poslovnim zahtjevima”, a ti zahtjevi nisu jedan broj, već mnogi uvjeti – ovdje su tolerancija na greške mreže, zahtjevi za konačnost, veličine, priroda transakcija i mnogi drugi parametri. Dakle, malo je vjerovatno da će odgovor na pitanje "koliko tps" biti jednostavan i gotovo nikad potpun. Distribuirani sistem sa desetinama ili stotinama čvorova koji obavljaju prilično složene proračune može biti u velikom broju različitih stanja povezanih sa stanjem mreže, sadržajem blockchaina, tehničkim kvarovima, ekonomskim problemima, napadima na mrežu i mnogim drugim razlozima. . Faze u kojima su mogući problemi u performansama razlikuju se od tradicionalnih usluga, a blockchain mrežni server je mrežni servis koji kombinuje funkcionalnost baze podataka, web servera i torrent klijenta, što ga čini izuzetno složenim u smislu profila opterećenja na svim podsistemima. : procesor, memorija, mreža, skladište
Desilo se da su decentralizirane mreže i blockchains prilično specifičan i neobičan softver za programere centraliziranog softvera. Stoga bih želio istaknuti važne aspekte performansi i održivosti decentraliziranih mreža, pristupe njihovom mjerenju i pronalaženju uskih grla. Razmotrit ćemo različite probleme performansi koji ograničavaju brzinu pružanja usluga korisnicima blockchaina i zabilježiti karakteristike karakteristične za ovu vrstu softvera.
Faze zahtjeva za uslugu od strane blockchain klijenta
Da biste iskreno govorili o kvaliteti bilo koje manje ili više složene usluge, potrebno je uzeti u obzir ne samo prosječne vrijednosti, već i maksimum/minimum, medijane, percentile. Teoretski, možemo govoriti o 1000 tps u nekom blockchainu, ali ako je 900 transakcija završeno ogromnom brzinom, a 100 je "zaglavljeno" na nekoliko sekundi, onda prosječno vrijeme prikupljeno za sve transakcije nije sasvim fer metrika za klijenta koji nisam mogao završiti transakciju za nekoliko sekundi. Privremene „rupe“ uzrokovane propuštenim krugovima konsenzusa ili podjelom mreže mogu uvelike upropastiti uslugu koja je pokazala odlične performanse na testnim stolovima.
Da bi se prepoznala takva uska grla, potrebno je dobro razumjeti faze u kojima pravi blockchain može imati poteškoća u opsluživanju korisnika. Opišimo ciklus isporuke i obrade transakcije, kao i dobijanje novog stanja blockchaina, iz kojeg klijent može provjeriti da li je njegova transakcija obrađena i obračunata.
- transakcija se formira na klijentu
- transakcija se potpisuje na klijentu
- klijent bira jedan od čvorova i šalje mu svoju transakciju
- klijent se pretplaćuje na ažuriranja baze podataka stanja čvora, čekajući da se prikažu rezultati njegove transakcije
- čvor distribuira transakciju preko p2p mreže
- nekoliko ili jedan BP (proizvođač blokova) obrađuje akumulirane transakcije, ažurirajući bazu podataka stanja
- BP formira novi blok nakon obrade potrebnog broja transakcija
- BP distribuira novi blok preko p2p mreže
- novi blok se isporučuje čvoru kojem klijent pristupa
- čvor ažurira bazu podataka stanja
- čvor vidi ažuriranje u vezi sa klijentom i šalje mu obavijest o transakciji
Sada pogledajmo bliže ove faze i opišemo potencijalne probleme performansi u svakoj fazi. Za razliku od centralizovanih sistema, takođe ćemo razmotriti izvršenje koda na mrežnim klijentima. Često se prilikom mjerenja TPS-a vrijeme obrade transakcije prikuplja od čvorova, a ne od klijenta - to nije sasvim pošteno. Klijenta nije briga koliko brzo je čvor obradio njegovu transakciju, njemu je najvažniji trenutak kada mu postanu dostupne pouzdane informacije o ovoj transakciji uključene u blockchain. Ova metrika je u suštini vrijeme izvršenja transakcije. To znači da različiti klijenti, čak i šaljući istu transakciju, mogu primiti potpuno različita vremena koja zavise od kanala, opterećenja i blizine čvora, itd. Stoga je apsolutno neophodno mjeriti ovo vrijeme na klijentima, jer je to parametar koji treba optimizirati.
Priprema transakcije na strani klijenta
Počnimo s prve dvije tačke: transakciju formira i potpisuje klijent. Čudno, ovo također može biti usko grlo performansi blockchaina sa stanovišta klijenta. Ovo je neuobičajeno za centralizovane servise koji preuzimaju sve kalkulacije i operacije sa podacima, a klijent jednostavno pripremi kratak zahtev koji može zahtevati veliku količinu podataka ili proračuna, dobijajući gotov rezultat. U blockchainima, klijentski kod postaje sve moćniji, a jezgra blockchaina postaje sve lakša, a masivni računski zadaci se obično prenose na klijentski softver. U blockchains-u postoje klijenti koji mogu pripremati jednu transakciju dosta dugo (govorim o raznim merkle dokazima, sažetim dokazima, threshold potpisima i drugim složenim operacijama na strani klijenta). Dobar primjer lake verifikacije na lancu i teške pripreme transakcije na klijentu je dokaz članstva u listi zasnovanoj na Merkle-tree, ovdje .
Također, nemojte zaboraviti da klijentski kod ne šalje jednostavno transakcije u blockchain, već prvo ispituje stanje blockchaina - a ova aktivnost može utjecati na zagušenje mreže i blockchain čvorova. Dakle, prilikom mjerenja, bilo bi razumno emulirati ponašanje klijentskog koda što je potpunije moguće. Čak i ako u vašem blockchainu postoje obični laki klijenti koji stavljaju običan digitalni potpis na najjednostavniju transakciju za prijenos neke imovine, svake godine su i dalje masovniji kalkulacije na klijentu, kripto algoritmi su sve jači, a ovaj dio obrade može pretvoriti u značajno usko grlo u budućnosti. Stoga, budite oprezni i ne propustite situaciju da se u transakciji koja traje 3.5s potroši 2.5s na pripremu i potpisivanje transakcije, a 1.0s na slanje u mrežu i čekanje odgovora. Da biste procijenili rizike ovog uskog grla, potrebno je prikupiti metriku sa klijentskih mašina, a ne samo od blockchain čvorova.
Slanje transakcije i praćenje njenog statusa
Sljedeći korak je slanje transakcije na odabrani blockchain čvor i primanje statusa prihvatanja u skup transakcija. Ova faza je slična redovnom pristupu bazi podataka; čvor mora snimiti transakciju u bazen i početi distribuirati informacije o njoj kroz p2p mrežu. Pristup procjeni performansi ovdje je sličan procjeni performansi tradicionalnih Web API mikroservisa, a same transakcije u blockchain-u mogu se ažurirati i aktivno mijenjati svoj status. Općenito, ažuriranje informacija o transakcijama na nekim blockchainima može se dogoditi više puta, na primjer pri prebacivanju između lančanih račva ili kada BP najave svoju namjeru da uključe transakciju u blok. Ograničenja veličine ovog bazena i broja transakcija u njemu mogu uticati na performanse blockchaina. Ako je skup transakcija popunjen do najveće moguće veličine ili ne stane u RAM, performanse mreže mogu naglo pasti. Blockchain nemaju centralizirana sredstva zaštite od poplave neželjenih poruka, a ako blockchain podržava velike količine transakcija i niske naknade, to može uzrokovati prelijevanje skupa transakcija – još jedno potencijalno usko grlo u performansama.
U blockchain-ovima, klijent šalje transakciju na bilo koji blockchain čvor koji želi, heš transakcije je obično poznat klijentu prije slanja, tako da sve što treba učiniti je uspostaviti vezu i, nakon prijenosa, pričekati da se blockchain promijeni njegovo stanje, omogućavajući njegovu transakciju. Imajte na umu da mjerenjem “tps” možete dobiti potpuno različite rezultate za različite metode povezivanja na blockchain čvor. Ovo može biti običan HTTP RPC ili WebSocket koji vam omogućava da implementirate obrazac "pretplate". U drugom slučaju, klijent će dobiti obavijest ranije, a čvor će potrošiti manje resursa (uglavnom memorije i prometa) na odgovore o statusu transakcije. Dakle, prilikom mjerenja “tps” potrebno je uzeti u obzir način na koji se klijenti povezuju na čvorove. Stoga, da bi se procijenili rizici ovog uskog grla, benčmark blockchain mora biti u stanju da emulira klijente i sa WebSocket i HTTP RPC zahtjevima, u proporcijama koje odgovaraju stvarnim mrežama, kao i da mijenja prirodu transakcija i njihovu veličinu.
Da biste procijenili rizike ovog uskog grla, također morate prikupiti metriku sa klijentskih strojeva, a ne samo iz blockchain čvorova.
Prijenos transakcija i blokova putem p2p mreže
U blockchain-u, peer-to-peer (p2p) umrežavanje se koristi za prijenos transakcija i blokova između sudionika. Transakcije se šire kroz mrežu, počevši od jednog od čvorova, sve dok ne dođu do peer blok proizvođača, koji pakuju transakcije u blokove i, koristeći isti p2p, distribuiraju nove blokove svim čvorovima mreže. Osnova najsavremenijih p2p mreža su različite modifikacije Kademlia protokola. dobar sažetak ovog protokola, i - članak s različitim mjerenjima u BitTorrent mreži, iz kojeg se može shvatiti da je ova vrsta mreže složenija i manje predvidljiva od rigidno konfigurirane mreže centraliziranog servisa. također, članak o mjerenju različitih zanimljivih metrika za Ethereum čvorove.
Ukratko, svaki peer u takvim mrežama održava svoju vlastitu dinamičku listu drugih ravnopravnih uređaja od kojih traži blokove informacija kojima se adresira sadržaj. Kada ravnopravni partner primi zahtjev, on ili daje potrebne informacije ili prosljeđuje zahtjev sljedećem pseudoslučajnom peeru sa liste, a nakon što je primio odgovor, prosljeđuje ga podnosiocu zahtjeva i neko vrijeme ga kešira, dajući ovo blok informacija ranije sljedeći put. Tako popularne informacije završavaju u velikom broju keš memorija velikog broja vršnjaka, a nepopularne informacije se postepeno zamjenjuju. Vršnjaci vode evidenciju o tome ko je kome prenio koliko informacija, a mreža pokušava stimulirati aktivne distributere povećavajući njihove ocjene i pružajući im viši nivo usluge, automatski istiskujući neaktivne učesnike sa lista kolega.
Dakle, transakciju sada treba distribuirati po cijeloj mreži kako bi je proizvođači blokova mogli vidjeti i uključiti u blok. Čvor aktivno „distribuira“ novu transakciju svima i osluškuje mrežu, čekajući blok u čijem indeksu će se pojaviti tražena transakcija kako bi obavijestio klijenta koji čeka. Vrijeme koje je potrebno mreži da jedna drugoj prenese informacije o novim transakcijama i blokovima u p2p mrežama ovisi o velikom broju faktora: broju poštenih čvorova koji rade u blizini (sa mrežne tačke gledišta), „toplo- gore” keša ovih čvorova, veličine blokova, transakcija, prirode promjena, geografije mreže, broja čvorova i mnogih drugih faktora. Kompleksna mjerenja metrike performansi u takvim mrežama su složena stvar, potrebno je istovremeno procijeniti vrijeme obrade zahtjeva i na klijentima i na kolegama (blockchain čvorovima). Problemi u bilo kojem od p2p mehanizama, netačno izbacivanje i keširanje podataka, neefikasno upravljanje listama aktivnih peer-a i mnogi drugi faktori mogu uzrokovati kašnjenja koja utiču na efikasnost cijele mreže u cjelini, a ovo usko grlo je najteže analizirati. , testiranje i interpretacija rezultata.
Blockchain obrada i ažuriranje baze podataka
Najvažniji dio blockchaina je algoritam konsenzusa, njegova primjena na nove blokove primljene iz mreže i obrada transakcija sa evidentiranjem rezultata u bazi podataka stanja. Dodavanje novog bloka u lanac, a zatim odabir glavnog lanca trebalo bi raditi što je brže moguće. Međutim, u stvarnom životu, "trebalo bi" ne znači "radi", a može se, na primjer, zamisliti situacija u kojoj se dva duga konkurentna lanca stalno mijenjaju između sebe, mijenjajući metapodatke hiljada transakcija u grupi na svakom prekidaču. , i stalno vraćanje baze podataka stanja. Ova faza, u smislu definisanja uskog grla, je jednostavnija od p2p mrežnog sloja, jer Izvršenje transakcije i konsenzus algoritam su strogo deterministički, i ovdje je lakše bilo šta izmjeriti.
Glavna stvar je ne brkati nasumične degradacije u performansama ove faze sa problemima mreže - čvorovi su sporiji u isporuci blokova i informacija o glavnom lancu, a za eksternog klijenta to može izgledati kao spora mreža, iako problem leži u potpuno drugačije mjesto.
Za optimizaciju performansi u ovoj fazi, korisno je prikupiti i pratiti metriku iz samih čvorova i uključiti u njih one koje se odnose na ažuriranje baze podataka stanja: broj blokova obrađenih na čvoru, njihovu veličinu, broj transakcija, broj prekidača između viljuški lanca, broj nevažećih blokova, radno vrijeme virtuelne mašine, vrijeme predaje podataka itd. Ovo će spriječiti da se problemi mreže pomiješaju s greškama u algoritmima lančane obrade.
Virtualna mašina koja obrađuje transakcije može biti koristan izvor informacija koji može optimizirati rad blockchaina. Broj alokacija memorije, broj instrukcija za čitanje/pisanje i druge metrike vezane za efikasnost izvršavanja koda ugovora mogu pružiti mnogo korisnih informacija programerima. U isto vrijeme, pametni ugovori su programi, što u teoriji znači da mogu konzumirati bilo koji od resursa: cpu/memory/mreža/storage, tako da je obrada transakcija prilično neizvjesna faza, koja se, osim toga, uvelike mijenja kada se kreće između verzija i prilikom promjene šifri ugovora. Stoga su metrike povezane s obradom transakcija također potrebne za učinkovitu optimizaciju performansi blockchaina.
Prijem od strane klijenta obavijesti o uključivanju transakcije u blockchain
Ovo je posljednja faza primanja usluge blockchain klijenta; u poređenju s drugim fazama, nema velikih režijskih troškova, ali je ipak vrijedno razmotriti mogućnost da klijent dobije opsežan odgovor od čvora (na primjer, pametni ugovor vraćanje niza podataka). U svakom slučaju, ova tačka je najvažnija za onoga ko je postavio pitanje „koliko tps je u vašem blockchainu?“, jer U ovom trenutku se evidentira vrijeme prijema usluge.
Na ovom mjestu uvijek postoji slanje punog vremena koje je klijent morao da provede čekajući odgovor od blockchaina; to je vrijeme kada će korisnik čekati potvrdu u svojoj aplikaciji, a njegova optimizacija je ono što glavni zadatak programera.
zaključak
Kao rezultat toga, možemo opisati vrste operacija koje se izvode na blockchainima i podijeliti ih u nekoliko kategorija:
- kriptografske transformacije, konstrukcija dokaza
- peer-to-peer umrežavanje, transakcija i replikacija blokova
- obrada transakcija, izvođenje pametnih ugovora
- primjena promjena u blockchainu na državnu bazu podataka, ažuriranje podataka o transakcijama i blokovima
- zahtjevi samo za čitanje za državnu bazu podataka, blockchain node API, usluge pretplate
Općenito, tehnički zahtjevi za moderne blockchain čvorove su izuzetno ozbiljni - brzi procesori za kriptografiju, velika količina RAM-a za pohranu i brzi pristup bazi podataka stanja, mrežna interakcija pomoću velikog broja istovremeno otvorenih veza i velika pohrana. Tako visoki zahtjevi i obilje različitih tipova operacija neminovno dovode do činjenice da čvorovi možda nemaju dovoljno resursa, a onda bilo koja od gore navedenih faza može postati još jedno usko grlo za ukupne performanse mreže.
Prilikom dizajniranja i evaluacije performansi blockchaina, morat ćete uzeti u obzir sve ove točke. Da biste to učinili, morate prikupljati i analizirati metriku istovremeno od klijenata i mrežnih čvorova, tražiti korelacije između njih, procijeniti vrijeme potrebno za pružanje usluga klijentima, uzeti u obzir sve glavne resurse: cpu/memory/mreža/skladištenje , razumiju kako se koriste i utiču jedni na druge. Sve to čini usporedbu brzina različitih blockchaina u obliku "koliko TPS" izuzetno nezahvalnim zadatkom, budući da postoji ogroman broj različitih konfiguracija i stanja. U velikim centralizovanim sistemima, klasterima od stotina servera, ovi problemi su takođe složeni i takođe zahtevaju prikupljanje velikog broja različitih metrika, ali u blockchain-u, zbog p2p mreža, virtuelnih mašina za obradu ugovora, interne ekonomije, broja stepeni slobode je mnogo veća, što čini test čak i na nekoliko servera, nije indikativan i pokazuje samo krajnje približne vrijednosti koje nemaju gotovo nikakve veze sa stvarnošću.
Stoga, kada razvijamo jezgru blockchaina, da bismo procijenili performanse i odgovorili na pitanje „je li se poboljšao u odnosu na prošli put?“ koristimo prilično složen softver koji orkestrira pokretanje blockchaina s desetinama čvorova i automatski pokreće benchmark i prikuplja metriku ; bez ovih informacija izuzetno je teško otkloniti greške u protokolima koji rade sa više učesnika.
Dakle, kada dobijete pitanje „koliko je TPS-a u vašem blockchainu?“, ponudite sagovorniku čajem i pitajte ga da li je spreman da pogleda desetak grafikona i posluša sve tri kutije problema s performansama blockchaina i vaše prijedloge za rešavanje njih...
izvor: www.habr.com