Obľúbenou otázkou každého netechnického odborníka o akejkoľvek distribuovanej sústave je „Koľko tps má váš blockchain?“. Odpoveď na túto otázku však obvykle má len málo spoločného s tým, čo by chcel počuť pýtajúci sa. V skutočnosti sa pýtal „Vyhovuje váš blockchain mojim obchodným požiadavkám?“, a tieto požiadavky nie sú len jedno číslo, ale množstvo podmienok — zahŕňajú tu aj odolnosť siete proti výpadkom, požiadavky na konečnosť, veľkosti, charakter transakcií a mnoho iných parametrov. Takže odpoveď na otázku „koľko tps“ pravdepodobne nebude jednoduchá a takmer nikdy nebude úplná. Distribuovaná sústava so desiatkami a stovkami uzlov vykonávajúcich dosť zložité výpočty môže mať obrovské množstvo rôznych stavov, ktoré sú spojené so stavom siete, obsahom blockchainu, technickými poruchami, ekonomickými problémami, útokmi na sieť a množstvom iných dôvodov. Fázy, v ktorých môžu nastať problémy s výkonnosťou, sa líšia od tradiciórnych služieb, pričom server blockchainovej siete predstavuje sieťovú službu, ktorá kombinuje funkčnosť databázy, webového servera a torrent klienta, čo ju robí mimoriadne zložitou z hľadiska profilu zaťaženia všetkých subsystémov: procesora, pamäte, siete, úložiska.

Stalo sa, že decentralizované siete a blockchainy sú pomerne špecifickým a nezvyčajným softvérom pre vývojárov centralizovaného softvéru. Preto by som rád osvetlil dôležité aspekty výkonu a stability decentralizovaných sietí, prístupy k ich meraniu a nachádzaniu bottleneckov. Preskúmame rôzne problémy výkonnosti, ktoré obmedzujú rýchlosť poskytovania služieb používateľom blockchainov a poznamenáme špecifiká, ktoré sú pre tento typ softvéru charakteristické.

Fázy požiadavky na službu klientom blockchainu

Aby sme mohli čestne hovoriť o kvalite akéhokoľvek zložitějšího servisu, musíme zohľadniť nie len priemerné hodnoty, ale aj maximálne/minimálne, mediány, percentily. Teoreticky môžeme hovoriť o 1000 tps v nejakom blockchaine, ale ak 900 transakcií prebehlo s obrovskou rýchlosťou, zatiaľ čo 100 „zamrzlo“ na niekoľko sekúnd, potom priemerný čas zozbieraný zo všetkých transakcií nie je úplne čestná metrika pre klienta, ktorý nedokázal dokončiť obchod za niekoľko sekúnd. Časové „jamy“, spôsobené vynechanými kolami konsenzu alebo delením siete môžu výrazne narušiť servis, ktorý v testovacích prostrediach predvádzal vynikajúcu výkonnosť.

Na identifikáciu takých bottleneckov je potrebné dobre rozumieť etapám, v ktorých môže reálny blockchain zažívať ťažkosti pri obsluhe používateľov. Poďme opísať cyklus dodávky a spracovania transakcií, ako aj získania nového stavu blockchainu, z ktorého si klient môže overiť, že jeho transakcia bola spracovaná a zohľadnená.

transakcia sa formuje na klientovi
transakcia sa podpisuje na klientovi
klient si vyberie jednu z nód a posiela do nej svoju transakciu
klient sa podpisuje na aktualizácie state database nód, čakajúc na výsledky spracovania svojej transakcie
nód šíri transakciu po p2p sieti
niekoľko alebo jeden BP (block producer) spracováva nahromadené transakcie, aktualizujúc state database
BP vytvára nový blok spracovaním požadovaného počtu transakcií
BP šíri nový blok po p2p sieti
nový blok je doručený do nód, na ktorú sa klient obracia
nód aktualizuje state database
nód vidí aktualizáciu týkajúcu sa klienta a posiela mu oznámenie o transakcii

Poďme sa podrobnejšie venovať týmto krokom a opísať potenciálne problémy s výkonom v každom z nich. Na rozdiel od centralizovaných systémov sa budeme zaoberať aj vykonávaním kódu na klientoch siete. Pomerne často pri meraní tps sa čas spracovania transakcií zbiera z uzlov, nie z klienta — to nie je úplne fér. Klientovi je jedno, ako rýchlo uzol spracoval jeho transakciu; najdôležitejší je pre neho okamih, kedy sa mu sprístupnia presné informácie o tejto transakcii, zahrnutej v blockchaine. Práve táto metrika je v podstate časom vykonania transakcie. To znamená, že rôzni klienti, aj keď posielajú tú istú transakciu, môžu mať úplne odlišné časy, ktoré závisia od kanála, zaťaženia a blízkosti uzla atď. Preto je nevyhnutné merať tento čas na klientoch, pretože tento parameter je potrebné optimalizovať.

Príprava transakcie na strane klienta

Začneme s prvými dvoma bodmi: transakcia je vytvorená a podpísaná klientom. Akoby to bolo prekvapujúce, aj to môže byť bottleneckom výkonu blockchainu z pohľadu klienta. To je nezvyčajné pre centralizované služby, ktoré si berú všetky výpočty a operácie s dátami, zatiaľ čo klient jednoducho pripravuje krátku požiadavku schopnú požiadať o veľké množstvo dát alebo výpočtov a obdrží hotový výsledok. V blockchanoch sa klientske kódy stávajú čoraz mocnejšími, zatiaľ čo blockchain jadro je čoraz ľahšie, a ťažké výpočtové úlohy sú zvyčajne odovzdávané klientskému softvéru. V blockchanoch existujú klienti, ktorí môžu pripravovať jednu transakciu pomerne dlho (hovorím o rôznych merkle proof-och, succinct proof-och, threshold podpisoch a iných zložitých operáciách na strane klienta). Dobré príklady ľahkej on-chain verifikácie a ťažkej prípravy transakcie na klientovi je dôkaz patrnosti k zoznamu založený na Merkle-strome. článok.

Takisto netreba zabúdať, že klientsky kód nielen posiela transakcie do blockchainu, ale najskôr žiada stav blockchainu — a táto činnosť môže ovplyvniť zaťaženie siete a nodov blockchainu. Preto, ak meráte, bude rozumné emulovať správanie klientského kódu čo najpresnejšie. Aj keď vo vašom blockchain sa používajú bežní ľahkí klienti, ktorí podpisujú jednoduché transakcie na prevod nejakého aktíva, s každým rokom množstvo výpočtov na strane klienta neustále narastá, kryptografické algoritmy sa posilňujú a táto časť spracovania sa môže stať vážnym bottleneckom v budúcnosti. Preto buďte opatrní a nenechajte si ujsť situáciu, keď v transakcii trvajúcej 3,5 sekundy 2,5 sekundy ide na prípravu a podpis transakcie a 1,0 sekundy na odoslanie do siete a čakanie na odpoveď. Na hodnotenie rizika vzniku tohto bottlenecku je potrebné zbierať metriky z klientských strojov, nie len z blockchainových nodov.

Odoslanie transakcie a sledovanie jej stavu

Ďalším krokom je odoslanie transakcie do vybraného nodu blockchainu a získanie stavu jej prijatia do transakčného poolu. Tento krok je podobný bežnému prístupu k databáze, nod musí zapísať transakciu do poolu a začať šíriť informácie o nej cez p2p sieť. Prístup k hodnoteniu výkonnosti je tu podobný hodnoteniu práce tradičných mikroslužieb Web API, pričom samé transakcie v blockchaine sa môžu aktualizovať a aktívne meniť stav. Všeobecne sa aktualizácia informácií o transakcii v niektorých blockchainoch môže stať viackrát, napríklad pri prechode medzi forkmi reťazca alebo keď BP oznamujú úmysel zaradiť transakciu do bloku. Obmedzenia na objem tohto poolu a počet transakcií v ňom môžu ovplyvniť výkonnosť blockchainu. Ak je pool transakcií naplnený na maximálnu možnú veľkosť, alebo sa nezmestí do operačnej pamäte — výkonnosť siete môže prudko klesnúť. Blockchainy nemajú centralizované prostriedky na ochranu pred tokom spamových správ, a ak blockchain podporuje transakcie veľkého objemu a nízke poplatky, môže to viesť k preplneniu transakčného poolu — toto je ďalší potenciálny bottleneck výkonnosti.

V blockchains klient odošle transakciu do ľubovoľného uzla blockchainu, hash transakcie je obvykle klientovi známy už pred odoslaním, takže všetko, čo potrebuje, je dosiahnuť spojenie a po prenose čakať, kedy sa blockchain zmení, pričom zahrnie jeho transakciu. Poznám, že meraním „tps“ je možné získať úplne odlišné výsledky pre rôzne spôsoby pripojenia k uzlu blockchainu. Môže to byť bežný HTTP RPC alebo WebSocket, ktorý umožňuje realizovať vzor „subscribe“. V druhom prípade klient dostane upozornenie skôr a uzol minie menej zdrojov (predovšetkým pamäte a dát) na odpovede o stave transakcie. Pri meraní „tps“ je teda potrebné zohľadniť spôsob pripojenia klientov k uzlom. Preto, na posúdenie rizík vzniku tohto bottlenecku, benchmark blockchainu by mal byť schopný emulovať klientov s WebSocketom a s HTTP RPC požiadavkami v podieloch, ktoré zodpovedajú reálnym sieťam, a taktiež meniť charakter transakcií a ich veľkosť.

Na posúdenie rizík vzniku tohto bottlenecku je tiež potrebné zbierať metriky z klientskych strojov, a nie len z blockchainových uzlov.

Prenos transakcií a blokov cez p2p sieť

V blockchains sa na prenos transakcií a blokov medzi účastníkmi používa peer-to-peer (p2p) networking. Transakcie sa šíria sieťou, počnúc jedným z uzlov, kým nedosiahnu peer-ov-block producer-ov, ktorí balia transakcie do blokov a pomocou rovnakého p2p šíria nové bloky po všetkých uzloch siete. Základom väčšiny moderných p2p sietí sú rôzne modifikácie protokolu Kademlia. Tu sú dobrý stručný prehľad tohto protokolu, a tu — článok s rôznymi meraniami v sieti BitTorrent, podľa ktorého je možné pochopiť — že tento typ sietí je zložitejší a menej predvídateľný než pevne nakonfigurovaná sieť centralizovanej služby. Taktiež, tu článok o meraní rôznych zaujímavých metrík pre uzly Ethereum.

V skratke, každý peer v takýchto sieťach udržiava svoj vlastný dynamický zoznam iných peerov, od ktorých si žiada bloky informácií, ktoré sú adresované podľa obsahu. Pri prijatí žiadosti peer buď odovzdá potrebné informácie, alebo prenesie požiadavku nasledujúcemu pseudonáhodnému peerovi zo zoznamu; po obdržaní odpovede ju odovzdá žiadajúcemu a na určitý čas ju kešuje, čím tento blok informácií skôr odovzdáva pri ďalšej žiadosti. Takto sa populárne informácie nachádzajú v mnohých kešoch u množstva peerov, zatiaľ čo nepoužívané informácie sa postupne vytláčajú. Peerovia sledujú, kto komu koľko informácií odovzdal, a sieť sa snaží stimulovať aktívnych odovzdávateľov, zvyšovaním ich hodnotenia a poskytovaním vyššej úrovne služby, automaticky vytláčajúc neaktívnych účastníkov zo zoznamov peerov.

Takže teraz je potrebné rozšíriť transakciu po sieti, aby ju videli block-produceri a zahrnuli ju do bloku. Node aktívne „odovzdáva“ novú transakciu všetkým záujemcom a počúva sieť, čakajúc na blok, v ktorom sa objaví požadovaná transakcia, aby mohla upozorniť čakajúceho klienta. Čas, počas ktorého sieť prenáša informácie o nových transakciách a blokoch v p2p sieťach, závisí od veľmi veľkého množstva faktorov: počtu čestných, funkčných nód vedľa seba (z pohľadu siete), „pripravenosti“ kešov týchto nód, veľkosti blokov, transakcií, charakteru zmien, geografickej polohy siete, počtu nód a množstva ďalších faktorov. Komplexné merania metriky výkonu v takýchto sieťach sú zložitou záležitosťou; je potrebné súčasne hodnotiť čas spracovania požiadaviek na klientoch aj na peerach (blockchain nódach). Problémy v akomkoľvek z p2p mechanizmov, nesprávne vytláčanie a kešovanie údajov, neefektívne spravovanie zoznamov aktívnych peerov a množstvo ďalších faktorov môžu spôsobiť oneskorenia, ovplyvňujúce efektivitu celej siete, a tento bottleneck je najťažší na analýzu, testovanie a interpretáciu výsledkov.

Spracovanie reťazca blokov a aktualizácia state database

Najdôležitejšou časťou práce blockchainu je konsenzuálny algoritmus, jeho aplikácia na nové bloky získané zo siete a spracovanie transakcií s uložením výsledkov v štátnej databáze. Pridanie nového bloku do reťazca a následujúci výber hlavného reťazca by mal prebiehať čo najrýchlejšie. Avšak v reálnom živote "by mal" neznamená "funguje", a môžeme si napríklad predstaviť situáciu, keď sa dve dlhé súťažné reťazce neustále prepínajú medzi sebou, meniac metaúdaje tisícov transakcií v poole pri každom prepnutí, a produkujúc neustále návraty stavu štátnej databázy. Tento krok je vo vzťahu k určeniu bottlenecku jednoduchší ako sieťová p2p vrstva, pretože vykonávanie transakcií a konsenzuálny algoritmus sú prísne deterministické, a meranie čohokoľvek tu je jednoduchšie.
Hlavné je nezamieňať náhodnú degradáciu výkonu tohto kroku s problémami v sieti — uzly pomalšie poskytujú bloky a informácie o hlavnom reťazci a pre vonkajšieho klienta to môže vyzerať ako pomalá sieť, hoci problém sa nachádza úplne inde.

Na optimalizáciu výkonu v tomto kroku je užitočné zbierať a monitorovať metriky priamo z uzlov a zahrnúť do nich aj tie, ktoré sa týkajú aktualizácie štátnej databázy: počet blokov spracovávaných na uzle, ich veľkosť, počet transakcií, počet prepnutí medzi forkami reťazca, počet neplatných blokov, čas prevádzky virtuálnych strojov, čas potvrdenia údajov a pod. To umožní nezamieňať sieťové problémy s chybami v algoritmoch spracovania reťazcov.

Virtuálna mašínka spracúvajúca transakcie môže byť užitočným zdrojom informácií, schopným optimalizovať fungovanie blockchainu. Množstvo alokácií pamäte, počet read/write inštrukcií a iné metriky týkajúce sa efektivity vykonávania kódu zmlúv môžu poskytnúť mnoho užitočných informácií pre vývojárov. Zároveň sú smart kontrakty programy, a preto teoreticky môžu spotrebovať akékoľvek prostriedky: cpu/memory/network/storage, takže spracovanie transakcií je pomerne neurčitý krok, ktorý navyše značne mení prechodom medzi verziami a zmenou kódu zmlúv. Preto sú metriky týkajúce sa spracovania transakcií tiež potrebné pre efektívnu optimalizáciu výkonu blockchainu.

Notifikácia klienta o aktivácii transakcie v blockchaine

Toto je posledná etapa prijímania služby blockchainom klientom, v porovnaní s inými fázami tu nie sú vysoké náklady, avšak je potrebné zohľadniť možnosť, že klient získa rozsiahlu odpoveď od nody (napríklad smart kontrakt, ktorý vracia pole dát). V každom prípade je tento moment najdôležitejší pre toho, kto sa pýta: „koľko tps má váš blockchain?“, pretože v tomto momente sa zaznamenáva čas prijímania služby.

V tomto bode sa nevyhnutne posiela celkový čas, ktorý klient strávil čakaním na odpoveď od blockhainu, práve tento čas bude používateľ očakávať ako potvrdenie v svojej aplikácii, a jeho optimalizácia je hlavnou úlohou vývojárov.

Záver

Výsledkom toho môžeme opísať typy operácií, ktoré sa v blockhainoch vykonávajú, a rozdeliť ich do niekoľkých kategórií:

kryptografické transformácie, vytváranie dôkazov
peer-to-peer networking, replikácia transakcií a blokov
spracovanie transakcií, vykonávanie smart kontraktov
aplikácia zmien v blockchaine na stavovú databázu, aktualizácia údajov o transakciách a blokoch
read-only požiadavky na stavovú databázu, API nodu blockhainu, subscription služby

Technické požiadavky na nody moderných blockchainov sú veľmi prísne — ide o rýchle CPU pre kryptografiu, veľký objem RAM na uchovávanie a rýchly prístup k stavovej databáze, sieťovú interakciu, ktorá využíva veľký počet súčasne otvorených spojení, objemný storage. Takéto vysoké požiadavky a množstvo rôznych typov operácií nevyhnutne vedie k tomu, že nodom môže nedostačovať prostriedkov, a vtedy sa akákoľvek z vyššie uvedených etáp môže stať ďalším bottleneckom pre celkový výkon siete.

Pri navrhovaní a hodnotení výkonu blockchainov musíte zvážiť všetky tieto aspekty. Na to je potrebné zbierať a analyzovať metriky súčasne od klientov a uzlov siete, hľadať korelácie medzi nimi, hodnotiť čas poskytovania služby zákazníkom, brať do úvahy všetky hlavné zdroje: cpu/memory/network/storage, a rozumieť, ako sa používajú a vzájomne ovplyvňujú. To všetko robí porovnávanie rýchlostí rôznych blockchainov vo forme „koľko TPS“ mimoriadne vďačným úsilím, pretože existuje obrovské množstvo rôznych konfigurácií a stavov. V veľkých centralizovaných systémoch, klastroch zo stoviek serverov, sú tieto problémy tiež zložité a vyžadujú zber veľkého množstva rôznych metrik, ale v blockchainoch, kvôli p2p sieťam, virtuálnym strojom, procesná zmluva, vnútornej ekonomike, je počet stupňov voľnosti oveľa väčší, čo robí test aj na niekoľkých serveroch nevhodným a ukazuje len veľmi približné hodnoty, takmer bez akéhokoľvek spojenia s realitou.

Preto pri vývoji v jadre blockchainu na hodnotenie výkonu a odpoveď na otázku „zlepšilo sa to v porovnaní s posledným razom“ používame celkom zložitý softvér, ktorý orchestruje spustenie blockchainu s desiatkami uzlov a automatickým spustením benchmarku a zberom metrik, bez týchto informácií je veľmi ťažké ladť protokoly, ktoré pracujú s množstvom účastníkov.

Takže, keď dostanete otázku „koľko TPS vo vašom blockchainu?“, ponúknite svojmu interlocutorovi čaj a zistite, či je pripravený oboznámiť sa s desiatkami grafov a tiež vypočuť všetky tri boxy problémov s výkonom blockchainov a vaše návrhy na ich riešenie…

Zdroj: habr.com