Omiljeno pitanje o bilo kojem distribuiranom sustavu od strane nestručne osobe je "Koliko tps-ova ima na vašem blockchainu?" Međutim, broj koji se daje u odgovoru obično nema mnogo zajedničkog s onim što bi ispitivač želio čuti. 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 mrežnih grešaka, zahtjevi za konačnošću, veličine, priroda transakcija i mnogi drugi parametri. Dakle, odgovor na pitanje "koliko tps" vjerojatno neće biti jednostavan i gotovo nikada potpun. Distribuirani sustav s desecima ili stotinama čvorova koji izvode prilično složene izračune može biti u velikom broju različitih stanja vezanih uz stanje mreže, sadržaj blockchaina, tehničke kvarove, ekonomske probleme, napade na mrežu i mnoge druge razloge. . Faze u kojima su mogući problemi u radu razlikuju se od tradicionalnih servisa, a blockchain mrežni poslužitelj mrežni je servis koji objedinjuje funkcionalnost baze podataka, web poslužitelja i torrent klijenta, što ga čini iznimno složenim u smislu profila opterećenja na svim podsustavima. : procesor, memorija, mreža, pohrana

Dogodilo se da su decentralizirane mreže i blockchaini prilično specifični i neobični softver za centralizirane programere softvera. Stoga bih želio istaknuti važne aspekte izvedbe i održivosti decentraliziranih mreža, pristupe njihovom mjerenju i pronalaženju uskih grla. Razmotrit ćemo različite probleme s performansama koji ograničavaju brzinu pružanja usluga korisnicima blockchaina i primijetiti značajke karakteristične za ovu vrstu softvera.

Faze zahtjeva usluge od strane blockchain klijenta

Da biste iskreno govorili o kvaliteti bilo koje više ili manje složene usluge, morate 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 dovršeno enormnom brzinom, a 100 je "zapelo" na nekoliko sekundi, tada prosječno vrijeme prikupljeno u svim transakcijama nije sasvim poštena metrika za klijenta koji nisam mogao dovršiti transakciju za nekoliko sekundi. Privremene "rupe" uzrokovane propuštenim rundama konsenzusa ili podjelama mreže mogu uvelike uništiti uslugu koja je pokazala izvrsne performanse na ispitnim stolovima.

Da bi se identificirala 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 dobivanje novog stanja blockchaina, iz kojeg klijent može provjeriti je li njegova transakcija obrađena i obračunata.

transakcija se formira na klijentu
transakcija se potpisuje na klijentu
klijent odabire jedan od čvorova i šalje mu svoju transakciju
klijent se pretplaćuje na ažuriranja državne baze podataka čvora, čekajući da se pojave rezultati njegove transakcije
čvor distribuira transakciju preko p2p mreže
nekoliko ili jedan BP (proizvođač blokova) obrađuje akumulirane transakcije, ažurirajući državnu bazu podataka
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 državnu bazu podataka
čvor vidi ažuriranje u vezi s klijentom i šalje mu obavijest o transakciji

Sada pobliže pogledajmo ove faze i opišimo moguće probleme s izvedbom u svakoj fazi. Za razliku od centraliziranih sustava, također ćemo razmotriti izvršavanje koda na mrežnim klijentima. Vrlo često, prilikom mjerenja TPS-a, vrijeme obrade transakcije prikuplja se od čvorova, a ne od klijenta - to nije sasvim pošteno. Klijenta nije briga koliko je brzo čvor obradio njegovu transakciju, njemu je najvažniji trenutak kada mu postanu dostupne pouzdane informacije o toj transakciji uključene u blockchain. To je metrika koja je u biti vrijeme izvršenja transakcije. To znači da različiti klijenti, čak i šaljući istu transakciju, mogu dobiti potpuno različita vremena, koja ovise o kanalu, opterećenju i blizini čvora itd. Stoga je apsolutno potrebno mjeriti ovo vrijeme na klijentima, jer je to parametar koji treba optimizirati.

Priprema transakcije na strani klijenta

Počnimo s prve dvije točke: transakciju formira i potpisuje klijent. Čudno, to također može biti usko grlo performansi blockchaina sa stajališta klijenta. To je neuobičajeno za centralizirane servise koji preuzimaju sve izračune i operacije s podacima, a klijent jednostavno pripremi kratki zahtjev koji može zatražiti veliku količinu podataka ili izračune, dobivajući gotov rezultat. U lancima blokova klijentski kod postaje sve moćniji, a jezgra lanca blokova postaje sve lakša, a masivni računalni zadaci obično se prenose na klijentski softver. U blockchainima postoje klijenti koji mogu dosta dugo pripremati jednu transakciju (govorim o raznim merkle dokazima, succinct proofima, threshold signature i drugim složenim operacijama na strani klijenta). Dobar primjer jednostavne on-chain verifikacije i teške pripreme transakcije na klijentu je dokaz o članstvu na popisu temeljenom na Merkle-tree-u, ovdje članak.

Također, nemojte zaboraviti da kod klijenta ne šalje samo transakcije u blockchain, već prvo ispituje stanje blockchaina - a ta 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 lagani klijenti koji stavljaju obični digitalni potpis na najjednostavniju transakciju za prijenos neke imovine, svake godine još uvijek postoje masovniji izračuni 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 nemojte propustiti situaciju da se u transakciji koja traje 3.5s, 2.5s potroši na pripremu i potpisivanje transakcije, a 1.0s na slanje u mrežu i čekanje odgovora. Da biste procijenili rizike ovog uskog grla, morate prikupiti metriku s klijentskih strojeva, a ne samo s čvorova blockchaina.

Slanje transakcije i praćenje njenog statusa

Sljedeći korak je slanje transakcije odabranom blockchain čvoru i primanje statusa prihvaćanja u skup transakcija. Ova faza je slična uobičajenom pristupu bazi podataka; čvor mora zabilježiti transakciju u bazenu i početi distribuirati informacije o njoj kroz p2p mrežu. Pristup ocjenjivanju performansi ovdje je sličan ocjenjivanju performansi tradicionalnih Web API mikroservisa, a same transakcije u lancima blokova mogu se ažurirati i aktivno mijenjati svoj status. Općenito, ažuriranje informacija o transakciji na nekim lancima blokova može se dogoditi više puta, na primjer prilikom prebacivanja između račvanja lanca ili kada BP-ovi objave svoju namjeru uključivanja transakcije u blok. Ograničenja veličine ovog skupa i broja transakcija u njemu mogu utjecati na performanse blockchaina. Ako je skup transakcija ispunjen do najveće moguće veličine ili ne stane u RAM, performanse mreže mogu naglo pasti. Blockchaini nemaju centralizirane načine zaštite od poplave bezvrijednih 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 izvedbi.

U blockchain-u, klijent šalje transakciju na bilo koji blockchain čvor koji želi, hash 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ćujući njegovu transakciju. Imajte na umu da mjerenjem "tps" možete dobiti potpuno različite rezultate za različite metode povezivanja na blockchain čvor. To može biti obični HTTP RPC ili WebSocket koji vam omogućuje implementaciju obrasca "pretplate". U drugom slučaju, klijent će primiti obavijest ranije, a čvor će potrošiti manje resursa (uglavnom memorije i prometa) na odgovore o statusu transakcije. Dakle, pri mjerenju “tps” potrebno je uzeti u obzir način na koji se klijenti spajaju na čvorove. Stoga, da bi se procijenili rizici ovog uskog grla, referentni blockchain mora moći oponašati klijente s WebSocket i HTTP RPC zahtjevima, u omjerima koji odgovaraju stvarnim mrežama, kao i promijeniti prirodu transakcija i njihovu veličinu.

Da biste procijenili rizike ovog uskog grla, također morate prikupiti metriku s klijentskih strojeva, a ne samo s čvorova blockchaina.

Prijenos transakcija i blokova putem p2p mreže

U lancima blokova, peer-to-peer (p2p) umrežavanje koristi se za prijenos transakcija i blokova između sudionika. Transakcije se šire mrežom, počevši od jednog od čvorova, sve dok ne dođu do proizvođača ravnopravnih blokova, koji pakiraju transakcije u blokove i koristeći isti p2p distribuiraju nove blokove svim mrežnim čvorovima. Osnova većine modernih p2p mreža su razne modifikacije Kademlia protokola. ovdje je dobar sažetak ovog protokola, i ovdje - članak s raznim mjerenjima u BitTorrent mreži, iz kojih se može shvatiti da je ova vrsta mreže složenija i manje predvidljiva od rigidno konfigurirane mreže centraliziranog servisa. Također, ovdje članak o mjerenju raznih zanimljivih metrika za Ethereum čvorove.

Ukratko, svaki peer u takvim mrežama održava svoju vlastitu dinamičku listu drugih peera od kojih zahtijeva blokove informacija koji su adresirani sadržajem. Kada peer primi zahtjev, on ili daje potrebne informacije ili prosljeđuje zahtjev sljedećem pseudo-nasumičnom peeru s liste, a nakon što primi odgovor, prosljeđuje ga podnositelju zahtjeva i sprema ga neko vrijeme, dajući ovo blok informacija ranije sljedeći put. Tako popularne informacije završavaju u velikom broju predmemorija velikog broja peerova, a nepopularne se informacije postupno zamjenjuju. Peeri vode evidenciju tko je kome koliko informacija prenio, a mreža nastoji stimulirati aktivne distributere tako što im povećava rejting i pruža im višu razinu usluge, automatski istiskujući neaktivne sudionike s peer lista.

Dakle, transakcija se sada mora distribuirati kroz mrežu 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 će se indeksu pojaviti tražena transakcija kako bi obavijestio klijenta koji čeka. Vrijeme koje je mreži potrebno da međusobno prenese informacije o novim transakcijama i blokovima u p2p mrežama ovisi o vrlo velikom broju čimbenika: broju poštenih čvorova koji rade u blizini (s mrežnog gledišta), „toplom up” predmemorija ovih čvorova, veličina blokova, transakcija, priroda promjena, mrežna geografija, broj čvorova i mnogi drugi čimbenici. Složena mjerenja metrike performansi u takvim mrežama su složena stvar; potrebno je istovremeno procijeniti vrijeme obrade zahtjeva i na klijentima i na peerovima (blockchain čvorovi). Problemi u bilo kojem od p2p mehanizama, netočno izbacivanje i predmemoriranje podataka, neučinkovito upravljanje listama aktivnih peerova i mnogi drugi čimbenici mogu uzrokovati kašnjenja koja utječu na učinkovitost cijele mreže u cjelini, a ovo usko grlo je najteže analizirati , ispitivanje i interpretacija rezultata.

Obrada blockchaina i ažuriranje državne baze podataka

Najvažniji dio blockchaina je algoritam konsenzusa, njegova primjena na nove blokove primljene s mreže te obrada transakcija uz bilježenje rezultata u državnu bazu podataka. Dodavanje novog bloka u lanac i zatim odabir glavnog lanca trebalo bi raditi što je brže moguće. Međutim, u stvarnom životu, "trebalo bi" ne znači "radi", i može se, na primjer, zamisliti situacija u kojoj se dva dugačka konkurentska lanca neprestano prebacuju između sebe, mijenjajući metapodatke tisuća transakcija u skupu pri svakom preklopu , i stalno vraćanje državne baze podataka. Ova je faza, u smislu definiranja uskog grla, jednostavnija od p2p mrežnog sloja, jer izvršenje transakcije i algoritam konsenzusa su strogo deterministički, i ovdje je lakše bilo što izmjeriti.
Glavna stvar je ne brkati nasumične degradacije u izvedbi ove faze s mrežnim problemima - čvorovi su sporiji u isporuci blokova i informacija o glavnom lancu, a za vanjskog 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 metrike iz samih čvorova i u njih uključiti one koji se odnose na ažuriranje baze podataka o stanju: broj blokova obrađenih na čvoru, njihovu veličinu, broj transakcija, broj prebacivanja između vilica lanca, broj nevažećih blokova, vrijeme rada virtualnog stroja, vrijeme predaje podataka itd. To će spriječiti brkanje problema s mrežom s pogreškama u algoritmima za obradu lanca.

Virtualni stroj koji obrađuje transakcije može biti koristan izvor informacija koji može optimizirati rad blockchaina. Broj dodjela memorije, broj instrukcija za čitanje/pisanje i druge metrike povezane s učinkovitošću izvršenja 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/memorija/mreža/pohrana, tako da je obrada transakcija prilično neizvjesna faza, koja se, osim toga, uvelike mijenja prilikom prelaska s jedne verzije na drugu a kod promjene kodova ugovora. Stoga su metrike povezane s obradom transakcija također potrebne za učinkovito optimiziranje performansi blockchaina.

Primitak obavijesti od strane klijenta o uključivanju transakcije u blockchain

Ovo je posljednja faza u kojoj blockchain klijent prima uslugu; u usporedbi s drugim fazama, nema velikih režijskih troškova, ali ipak vrijedi razmotriti mogućnost da klijent dobije opsežan odgovor od čvora (na primjer, pametni ugovor vraćanje niza podataka). U svakom slučaju, ova točka je najvažnija za onoga tko je postavio pitanje "koliko tps ima u vašem blockchainu?", jer U ovom trenutku se bilježi vrijeme prijema usluge.

Na ovom mjestu se uvijek šalje puno vrijeme koje je klijent morao provesti čekajući odgovor od blockchaina, to vrijeme će korisnik čekati potvrdu u svojoj aplikaciji, a upravo je njegova optimizacija. glavni zadatak programera.

Zaključak

Kao rezultat toga, možemo opisati vrste operacija koje se izvode na lancima blokova i podijeliti ih u nekoliko kategorija:

kriptografske transformacije, konstrukcija dokaza
peer-to-peer umrežavanje, transakcija i replikacija blokova
obrada transakcija, izvršenje pametnih ugovora
primjena promjena u blockchainu u državnu bazu podataka, ažuriranje podataka o transakcijama i blokovima
zahtjevi samo za čitanje prema državnoj bazi podataka, API za blockchain čvor, usluge pretplate

Općenito, tehnički zahtjevi za moderne blockchain čvorove iznimno su ozbiljni - brzi procesori za kriptografiju, velika količina RAM-a za pohranu i brzi pristup državnoj bazi podataka, mrežna interakcija korištenjem velikog broja istovremeno otvorenih veza i velika pohrana. Tako visoki zahtjevi i obilje različitih vrsta operacija neizbježno dovode do činjenice da čvorovi možda nemaju dovoljno resursa, a tada bilo koja od gore spomenutih faza može postati još jedno usko grlo za cjelokupnu izvedbu mreže.

Kada dizajnirate i procjenjujete performanse blockchaina, morat ćete uzeti u obzir sve ove točke. Da biste to učinili, trebate prikupiti i analizirati metriku istovremeno od klijenata i mrežnih čvorova, tražiti korelacije među njima, procijeniti vrijeme potrebno za pružanje usluga klijentima, uzeti u obzir sve glavne resurse: procesor/memorija/mreža/pohrana , razumjeti kako se koriste i utječu jedni na druge. Sve to čini usporedbu brzina različitih blockchaina u obliku “koliko TPS” krajnje nezahvalnim poslom, budući da postoji ogroman broj različitih konfiguracija i stanja. U velikim centraliziranim sustavima, klasterima od stotina poslužitelja, ti su problemi također složeni i također zahtijevaju prikupljanje velikog broja različitih metrika, no u blockchainovima, zbog p2p mreža, virtualnih strojeva koji obrađuju ugovore, interne ekonomije, broja stupnjeva slobode je puno veća, što test čini čak i na nekoliko poslužitelja, neindikativno je i pokazuje samo krajnje približne vrijednosti koje nemaju gotovo nikakve veze sa stvarnošću.

Stoga, kada razvijamo u jezgri blockchaina, da bismo procijenili izvedbu i odgovorili na pitanje "je li se poboljšala u odnosu na prošli put?" koristimo prilično složen softver koji upravlja pokretanjem blockchaina s desecima čvorova i automatski pokreće referentnu vrijednost i prikuplja metrike ; bez ovih informacija izuzetno je teško otkloniti pogreške protokola koji rade s više sudionika.

Dakle, kada dobijete pitanje "koliko TPS-ova ima u vašem blockchainu?", ponudite sugovorniku čaj i pitajte je li spreman pogledati desetak grafova te poslušati sve tri kutije problema s performansama blockchaina i vaše prijedloge za rješavati ih...

Izvor: www.habr.com

Koliko TPS-ova ima na vašem blockchainu?