Omiljeno pitanje svakog netehničkog stručnjaka o bilo kojem distribuiranom sistemu je „Koliko tps u vašem blockchainu?“. Međutim, broj koji se navedu kao odgovor obično ima vrlo malo veze s onim što bi ispitivač želeo čuti. U stvari, želeo je pitati „Da li vaš blockchain odgovara mojim poslovnim zahtevima?“, a ti zahtevi nisu samo jedan broj, već mnoštvo uslova — od otpornosti mreže, zahteva za konačnošću, veličine, karaktera transakcija, pa do mnogih drugih parametara. Tako da odgovor na pitanje „koliko tps“ verovatno neće biti jednostavan, i gotovo nikada neće biti potpun. Distribuirani sistem sa desetinama i stotinama čvorova koji obavljaju prilično složene izračune može se nalaziti u ogromnom 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 problemi s performansama mogu se razlikovati od tradicionalnih usluga, dok je server blockchain mreže mrežna usluga koja kombinuje funkcionalnosti baze podataka, web servera i torrent klijenta, što ga čini izuzetno složenim u pogledu opterećenja na sve podsisteme: procesor, memorija, mreža, skladište.

Zanimljivo je da su decentralizovane mreže i blockchaini prilično specifičan i neobičan softver za programere centralizovanog softvera. Zato bih želeo da osvetlim važne aspekte performansi i otpornosti decentralizovanih mreža, pristupe njihovom merenju i identifikaciji uskih grla. Razmotrićemo različite probleme s performansama koji ograničavaju brzinu pružanja usluga korisnicima blockchaina i istakao posebnosti karakteristične za ovu vrstu softvera.

Faze zahteva usluge od strane klijenta blockchaina

Da biste iskreno govorili o kvaliteti bilo kojeg složenijeg servisa, potrebno je uzeti u obzir ne samo prosječne vrijednosti, već i maksimalne/minimalne, medijane i percentile. Teoretski, možete razgovarati o 1000 tps u nekoj blockchain mreži, ali ako je 900 transakcija izvršeno s ogromnom brzinom, a 100 – „zapelo“ na nekoliko sekundi, prosječno vrijeme prikupljeno za sve transakcije nije potpuno poštena metrika za klijenta koji nije mogao završiti transakciju u nekoliko sekundi. Vremenske „rupa“, uzrokovane propuštenim krugovima konsenzusa ili podjelom mreže, mogu značajno pokvariti servis koji je na testnim postavkama pokazivao odličnu izvedbu.

Da biste identificirali takve bottleneckove, potrebno je dobro razumjeti faze u kojima stvarni blockchain može imati poteškoća u opsluživanju korisnika. Opisujmo ciklus dostave i procesiranja transakcije, kao i dobivanje novog stanja blockchaina, iz kojeg klijent može biti siguran da je njegova transakcija obrađena i uzeta u obzir.

1. transakcija se formira na klijentu
2. transakcija se potpisuje na klijentu
3. klijent odabire jedan od nodova i šalje mu svoju transakciju
4. klijent se prijavljuje za ažuriranja state database nodova, čekajući na pojavu rezultata izvršenja svoje transakcije
5. nod distribuira transakciju putem p2p mreže
6. nekoliko, ili jedan BP (block producer) procesira akumulirane transakcije, ažurirajući state database
7. BP formira novi blok, obradivši potrebno broj transakcija
8. BP distribuira novi blok putem p2p mreže
9. novi blok dostavlja se nodu kojem se klijent obraća
10. nod ažurira state database
11. nod vidi ažuriranje koje se tiče klijenta i šalje mu obavijest o transakciji

Sada ćemo detaljnije razraditi te korake i opisati potencijalne probleme s performansama u svakom koraku. Za razliku od centraliziranih sustava, također ćemo razmotriti izvršavanje koda na klijentima mreže. Prilično često, prilikom mjerenja tps-a, vrijeme obrade transakcija prikuplja se s nodova, a ne s klijenata - to nije sasvim pošteno. Klijentu nije stalo koliko je brzo nod obradio njegovu transakciju, najvažnije za njega je trenutak kada postane dostupna vjerodostojna informacija o toj transakciji uključena u blockchain. Upravo ova metrike je suštinski 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 nodova, i slično. Stoga je potpuno nužno mjeriti to vrijeme na klijentima, s obzirom na to da je to parametar koji treba optimizirati.

Priprema transakcije na strani klijenta

Započnimo s prva dva mjesta: transakcija se formira i potpisuje od strane klijenta. Čudno je, ali to također može biti bottleneck u performansama blockchaina s gledišta klijenta. To nije uobičajeno za centralizirane usluge koje preuzimaju sve proračune i operacije s podacima, dok klijent jednostavno priprema kratak zahtjev, sposoban zatražiti veliki volumen podataka ili proračuna, dobivajući gotov rezultat. U blockchainima klijentski kod postaje sve moćniji, dok je jezgra blockchaina sve lakša, a masivne proračunske zadatke obično prepuštaju klijentskom softveru. U blockchainima postoje klijenti koji mogu pripremiti jednu transakciju prilično dugo (govorim o raznim merkle proof-ima, succinct proof-ima, threshold potpisima i drugim složenim operacijama na strani klijenta). Dobar primjer lagane on-chain verifikacije i teške pripreme transakcije na klijentu je dokaz pripadnosti listi temeljen na Merkle-drvetu. članak.

Također, ne smijemo zaboraviti da klijentski kod ne šalje samo transakcije u blokchain, već prvo zahtijeva stanje blokchaina — a ta aktivnost može utjecati na opterećenje mreže i čvorova blokchaina. Stoga, prilikom mjerenja, bit će razumno emulirati ponašanje klijentskog koda na što potpuniji način. Čak i ako u vašem blokchainu postoje obični lagani klijenti koji stavljaju običan digitalni potpis na najjednostavniju transakciju prijenosa nečega, s godinama se računski zahtjevi na klijentskoj strani ipak povećavaju, kriptoalgoritmi postaju jači, i ovaj dio procesiranja može postati značajna točka uskog grla u budućnosti. Zato budite oprezni i ne propustite situaciju u kojoj u transakciji koja traje 3.5 sekundi, 2.5 sekundi odlazi na pripremu i potpisivanje transakcije, i 1.0 sekundu na slanje u mrežu i čekanje odgovora. Za procjenu rizika od pojave ovog uskog grla potrebno je prikupljati metrike s klijentskih računala, a ne samo s čvorova blokchaina.

Slanje transakcije i praćenje njezinog statusa

Sljedeća faza je slanje transakcije odabranom čvoru blokchaina i dobivanje statusa prihvaćanja u bazu transakcija. Ova faza je slična uobičajenom pristupu bazi podataka, čvor mora zapisati transakciju u bazu i početi širiti informacije o njoj putem p2p mreže. Pristup procjeni performansi ovdje je sličan procjeni rada tradicionalnih mikroservisa Web API, pri čemu se same transakcije u blokchainima mogu ažurirati i aktivno mijenjati status. Uopće, ažuriranje informacija o transakciji u nekim blokchainima može se dogoditi nekoliko puta, na primjer kada se prelazi između forkova lanaca ili kada BP izvještava o namjeri uključivanja transakcije u blok. Ograničenja u volumenu ove baze i broj transakcija u njoj mogu utjecati na performanse blokchaina. Ako je baza transakcija ispunjena do maksimalne mogućnosti, ili ne stane u radnu memoriju — performanse mreže mogu naglo pasti. Blokchaini nemaju centralizirane zaštite od toka nevažnih poruka, i ako blokchain podržava transakcije velikog volumena i niske naknade, to može dovesti do preopterećenja baze transakcija — što je još jedna potencijalna točka uskog grla u performansama.

U blockchainima, klijent šalje transakciju bilo kojoj čvoru blockchaina koji mu se sviđa, hash transakcije obično je poznat klijentu čak i prije slanja, tako da je sve što mu treba – ostvariti vezu i nakon slanja čekati kada će blockchain promijeniti svoje stanje, uključivši njegovu transakciju. Primijetimo da mjerenje „tps“ može dati potpuno različite rezultate za različite načine povezivanja s čvorom blockchaina. To može biti obični HTTP RPC ili WebSocket, koji omogućava implementaciju obrasca „subscribe“. U drugom slučaju, klijent će dobiti obavijest ranije, a čvor će potrošiti manje resursa (uglavnom memorije i prometa) na odgovore o stanju transakcije. Stoga, prilikom mjerenja „tps“, treba uzeti u obzir način povezivanja klijenata s čvorovima. Zato, za procjenu rizika pojave ovog bottleneck-a, benchmark blockchaina treba moći emulirati klijente s WebSocket i HTTP RPC zahtjevima, u omjerima koji odgovaraju stvarnim mrežama, kao i mijenjati karakter i veličinu transakcija.

Za procjenu rizika pojave ovog bottleneck-a potrebno je također prikupljati metrike s klijentovih strojeva, a ne samo s blockchain čvorova.

Prenos transakcija i blokova putem p2p mreže

U blockchainima za prenos transakcija i blokova između sudionika koristi se peer-to-peer (p2p) umrežavanje. Transakcije se šire mrežom, počinjući od jednog od čvorova, sve dok ne dođu do peer-a - blok producenata, koji pakiraju transakcije u blokove i putem iste p2p mreže šire nove blokove svim čvorovima u mreži. Osnova većine modernih p2p mreža su različite modifikacije Kademlijevog protokola. Evo dobar kratak pregled ovog protokola, a evo — članak s različitim mjerenjima u mreži BitTorrent, prema kojem se može shvatiti – da su ove vrste mreža složenije i manje predvidive od strogo konfiguriranih mreža centralizirane usluge. Također, evo članak o mjerenju različitih zanimljivih metrika za Ethereum čvorove.

Ukratko, svaki peer u takvim mrežama održava svoj vlastiti dinamički popis drugih peer-a, od kojih traži blokove informacija koji se adresiraju prema sadržaju. Kada primi zahtjev, peer ili proslijedi potrebne informacije, ili prenosi zahtjev sljedećem pseudo-namjenskom peer-u sa popisa, a nakon što dobije odgovor, proslijedi ga tražitelju i na neko vrijeme ga kešira, dajući taj blok informacija ranije sljedeći put. Na taj način popularne informacije završavaju u velikom broju keševa kod velikog broja peer-a, dok manje popularne postupno budu istisnute. Peer-ovi vode evidenciju o tome tko koliko informacija prenosi, a mreža nastoji poticati aktivne davatelje, povećavajući njihovu ocjenu i osiguravajući im viši nivo usluge, automatski istiskujući neaktivne sudionike iz popisa peer-a.

Dakle, transakciju sada treba distribuirati mrežom kako bi je block-producer-i vidjeli i uključili je u blok. Čvor aktivno "dijeli" novu transakciju svima koji žele i sluša mrežu, čekajući blok u čijem će se indeksu pojaviti potrebna transakcija, kako bi obavijestio čekajućeg klijenta. Vrijeme dok mreža međusobno prenosi informacije o novim transakcijama i blokovima u p2p mrežama ovisi o vrlo velikom broju faktora: broju poštenih, radnih čvorova (s mrežnog stajališta) u blizini, "zagrijanosti" keševa tih čvorova, veličini blokova, transakcijama, prirodi promjena, geografiji mreže, broju čvorova i još mnogo drugih faktora. Kompleksno mjerenje metrika performansi u takvim mrežama je složen posao, potrebno je simultano procijeniti vrijeme obrade zahtjeva i na klijentima i na peer-ima (blockchain čvorovima). Problemi u bilo kojem od p2p mehanizama, netočno istiskivanje i keširanje podataka, neučinkovito upravljanje popisima aktivnih peer-a, i mnoštvo drugih faktora mogu uzrokovati kašnjenja koja utječu na učinkovitost cijele mreže, a ovaj bottleneck je najteži za analizu, testiranje i interpretaciju rezultata.

Obrada lanca blokova i ažuriranje state database

Najvažniji dio rada blockchaina je algoritam konsenzusa, njegova primjena na nove, dobivene iz mreže blokove i procesuiranje transakcija s bilježenjem rezultata u state database. Dodavanje novog bloka u lanac i izbor glavnog lanca nakon toga trebali bi raditi što brže. Međutim, u stvarnom životu "trebalo bi" ne znači "radi", i možemo, na primjer, zamisliti situaciju kada se dva dugačka konkurentska lanca neprekidno mijenjaju jedan s drugim, mijenjajući metapodatke tisuća transakcija u bazenu pri svakoj promjeni, i stvarajući stalne povratne točke stanja state database. Ova faza, u smislu određivanja bottlenecka, jednostavnija je od mrežnog p2p sloja, jer je izvršenje transakcija i algoritam konsenzusa strogo determinirani, i ovdje je lakše mjeriti nešto.
Glavno je ne pobrkati slučajno pogoršanje performansi ove faze s problemima mreže — nodovi sporije isporučuju blokove i informacije o glavnom lancu i za vanjskog klijenta to može izgledati kao spora mreža, iako se problem krije potpuno na drugom mjestu.

Za optimizaciju performansi u ovoj fazi korisno je prikupljati i nadzirati metrike s samih nodova, uključujući one koje se odnose na ažuriranje state-database: broj blokova obrađenih na nodu, njihova veličina, broj transakcija, broj prebacivanja između forkova lanaca, broj nevaljanih blokova, vrijeme rada virtualne mašine, vrijeme pohrane podataka itd. To će omogućiti da ne pobrkamo mrežne probleme s greškama u algoritmima procesiranja lanaca.

Virtualna mašina koja procesira transakcije može biti koristan izvor informacija koje mogu optimizirati rad blockchaina. Količina alokacija memorije, broj read/write instrukcija i druge metrike vezane za učinkovitost izvršenja koda ugovora mogu dati mnogo korisnih informacija programerima. U isto vrijeme, pametni ugovori su programi, što znači da teoretski mogu trošiti sve resurse: cpu/memory/network/storage, pa je procesiranje transakcija prilično neodređena faza koja se također znatno mijenja pri prijelazu između verzija i kodiranju ugovora. Stoga su metrike koje se odnose na procesiranje transakcija također potrebne za učinkovitu optimizaciju performansi blockchaina.

Obavještavanje klijenta o aktivaciji transakcije u blockchainu

Ovo je završna faza dobivanja usluge od blockchaina, u usporedbi s drugim fazama ovdje nema velikih troškova, no još uvijek treba uzeti u obzir mogućnost dobivanja obimnog odgovora od čvora (na primjer, pametan ugovor koji vraća niz podataka). U svakom slučaju, ovaj trenutak je najvažniji za onoga tko postavlja pitanje "kolika je tps u vašem blockchainu?", jer se u tom trenutku bilježi vrijeme dobivanja usluge.

Na ovom mjestu mora biti zabilježeno ukupno vrijeme koje je klijent proveo čekajući odgovor od blockchaina, to je vrijeme koje će korisnik očekivati kao potvrdu u svojoj aplikaciji, a optimizacija tog vremena je glavni zadatak programera.

Zaključak

Kao rezultat, moguće je opisati tipove operacija koje se izvode u blockchainima i podijeliti ih u nekoliko kategorija:

1. kriptografske transformacije, izrada dokaza
2. peer-to-peer umrežavanje, replikacija transakcija i blokova
3. procesiranje transakcija, izvršavanje pametnih ugovora
4. primjena promjena u blockchainu na state database, ažuriranje podataka o transakcijama i blokovima
5. read-only upiti na state database, API blockchain čvorova, subscription servisi

Uopće, tehnički zahtjevi za čvorove modernih blockchaina su izuzetno zahtjevni - brzi CPU za kriptografiju, velika količina RAM-a za pohranu i brzo pristupanje state databaseu, mrežna interakcija koja koristi veliki broj istovremeno otvorenih veza, obiman storage. Ovi visoki zahtjevi i mnoštvo različitih tipova operacija neizbježno dovode do situacije da resursi čvorova mogu biti nedovoljni, a tada bilo koja od razmatranih faza može postati usko grlo za ukupnu učinkovitost mreže.

Kada razvijate i ocjenjujete performanse blockchaina, morate uzeti u obzir sve te aspekte. Za to je potrebno prikupljati i analizirati metrike simultano s klijentima i čvorovima mreže, tražeći korelacije među njima, ocjenjujući vrijeme pružanja usluge klijentima, uzimajući u obzir sve ključne resurse: cpu/memory/network/storage, razumjeti kako se koriste i utječu jedni na druge. Sve to čini usporedbu brzina različitih blockchaina u smislu 'koliko TPS' izuzetno nezahvalnim zadatkom, pošto postoji ogromna količina raznih konfiguracija i stanja. U velikim centraliziranim sustavima, klasterima od stotina servera, ovi problemi su također složeni i također zahtijevaju prikupljanje velikog broja različitih metrika, ali u blockchainima, zbog p2p mreža, virtualnih mašina, pametnih ugovora, unutarnje ekonomije, broj stepeni slobode je mnogo veći, što testiranje čak i na nekoliko servera čini neodređenim i gotovo ne daje stvarne vrijednosti.

Stoga, prilikom razvoja u jezgru blockchaina, za procjenu performansi i odgovor na pitanje 'jesmo li se poboljšali u odnosu na prošli put', koristimo prilično složen softver koji orkestrira pokretanje blockchaina s desecima čvorova i automatskim pokretanjem benchmarka i prikupljanjem metrika. Bez tih informacija, vrlo je teško otkloniti greške u protokolima koji rade s velikim brojem sudionika.

Dakle, kada dobijete pitanje 'koliko TPS ima vaš blockchain?', ponudite sugovorniku čaj i pitajte ga je li spreman upoznati se s desecima grafova, kao i saslušati sve tri kutije problema s performansama blockchaina i vaše prijedloge za njihovo rješavanje...

Izvor: habr.com