Obľúbená otázka o akomkoľvek distribuovanom systéme od netechnickej osoby je „Koľko tps je na vašom blockchaine?“ Číslo uvedené v odpovedi však zvyčajne nemá veľa spoločného s tým, čo by chcel pýtajúci počuť. V skutočnosti sa chcel opýtať „bude váš blockchain vyhovovať mojim obchodným požiadavkám“ a tieto požiadavky nie sú jedným číslom, ale mnohými podmienkami – tu sú odolnosť voči chybám siete, požiadavky na konečnosť, veľkosti, povaha transakcií a mnoho ďalších parametrov. Takže odpoveď na otázku „koľko tps“ pravdepodobne nebude jednoduchá a takmer nikdy úplná. Distribuovaný systém s desiatkami alebo stovkami uzlov vykonávajúcich pomerne zložité výpočty môže byť v obrovskom množstve rôznych stavov súvisiacich so stavom siete, obsahom blockchainu, technickými poruchami, ekonomickými problémami, útokmi na sieť a mnohými ďalšími dôvodmi. . Fázy, v ktorých sú možné problémy s výkonom, sa líšia od tradičných služieb a blockchainový sieťový server je sieťová služba, ktorá kombinuje funkčnosť databázy, webového servera a torrent klienta, čo ho robí mimoriadne zložitým z hľadiska profilu zaťaženia na všetkých podsystémoch. : procesor, pamäť, sieť, úložisko

Stáva sa, že decentralizované siete a blockchainy sú celkom špecifickým a nezvyčajným softvérom pre vývojárov centralizovaného softvéru. Preto by som rád zdôraznil dôležité aspekty výkonnosti a udržateľnosti decentralizovaných sietí, prístupy k ich meraniu a hľadaniu úzkych miest. Pozrieme sa na rôzne problémy s výkonom, ktoré obmedzujú rýchlosť poskytovania služieb používateľom blockchainu a všimneme si vlastnosti charakteristické pre tento typ softvéru.

Fázy žiadosti o službu klientom blockchainu

Aby ste mohli úprimne hovoriť o kvalite akejkoľvek viac či menej komplexnej služby, musíte brať do úvahy nielen priemerné hodnoty, ale aj maximum/minimum, mediány, percentily. Teoreticky môžeme hovoriť o 1000 tps v nejakom blockchaine, ale ak bolo 900 transakcií dokončených obrovskou rýchlosťou a 100 bolo „zaseknutých“ na niekoľko sekúnd, potom priemerný čas nazbieraný počas všetkých transakcií nie je pre klienta úplne férová metrika. ktorý som nemohol dokončiť transakciu za pár sekúnd. Dočasné „diery“ spôsobené zmeškanými kolami konsenzu alebo rozdelením siete môžu značne zničiť službu, ktorá na testovacích stoloch preukázala vynikajúci výkon.

Na identifikáciu takýchto prekážok je potrebné dobre porozumieť fázam, v ktorých môže mať skutočný blockchain problémy s obsluhou používateľov. Poďme si popísať cyklus doručenia a spracovania transakcie, ako aj získanie nového stavu blockchainu, z ktorého si klient môže overiť, že jeho transakcia bola spracovaná a zaúčtovaná.

transakcia sa tvorí na klientovi
transakcia je podpísaná na klientovi
klient si vyberie jeden z uzlov a odošle mu svoju transakciu
klient sa prihlási na odber aktualizácií stavovej databázy uzla a čaká, kým sa objavia výsledky jeho transakcie
uzol distribuuje transakciu cez p2p sieť
niekoľko alebo jeden BP (výrobca blokov) spracováva nahromadené transakcie a aktualizuje štátnu databázu
BP vytvorí nový blok po spracovaní požadovaného počtu transakcií
BP distribuuje nový blok cez sieť p2p
nový blok je doručený uzlu, ku ktorému klient pristupuje
uzol aktualizuje databázu stavu
uzol vidí aktualizáciu týkajúcu sa klienta a pošle mu oznámenie o transakcii

Teraz sa pozrime bližšie na tieto fázy a popíšme potenciálne problémy s výkonom v každej fáze. Na rozdiel od centralizovaných systémov budeme brať do úvahy aj spúšťanie kódu na sieťových klientoch. Pomerne často sa pri meraní TPS čas spracovania transakcie zhromažďuje od uzlov a nie od klienta - to nie je úplne spravodlivé. Klienta nezaujíma, ako rýchlo uzol spracoval jeho transakciu, najdôležitejší je pre neho moment, kedy sa mu sprístupnia spoľahlivé 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, dokonca aj odosielajúci rovnakú transakciu, môžu prijímať úplne odlišné časy, ktoré závisia od kanála, zaťaženia a blízkosti uzla atď. Je teda absolútne nevyhnutné merať tento čas na klientoch, keďže toto je parameter, ktorý treba optimalizovať.

Príprava transakcie na strane klienta

Začnime prvými dvoma bodmi: transakciu tvorí a podpisuje klient. Napodiv to môže byť aj prekážka výkonu blockchainu z pohľadu klienta. To je nezvyčajné pri centralizovaných službách, ktoré prevezmú všetky výpočty a operácie s dátami a klient jednoducho pripraví krátku požiadavku, ktorá si môže vyžiadať veľké množstvo dát alebo výpočtov, čím získa hotový výsledok. V blockchainoch sa klientsky kód stáva čoraz výkonnejším a jadro blockchainu sa stáva čoraz ľahším a rozsiahle výpočtové úlohy sa zvyčajne prenášajú na klientsky softvér. V blockchainoch sú klienti, ktorí dokážu jednu transakciu pripravovať pomerne dlho (hovorím o rôznych merkle proofoch, stručných dôkazoch, prahových podpisoch a iných zložitých operáciách na strane klienta). Dobrým príkladom jednoduchého overenia na reťazci a náročnej prípravy transakcie na klientovi je doklad o členstve v zozname založenom na Merkle-tree, tu článok.

Nezabudnite tiež, že kód klienta jednoducho neposiela transakcie do blockchainu, ale najprv sa pýta na stav blockchainu – a táto aktivita môže ovplyvniť preťaženie siete a blockchainových uzlov. Takže pri meraní by bolo rozumné čo najúplnejšie napodobniť správanie klientskeho kódu. Aj keď sú vo vašom blockchaine obyčajní ľahkí klienti, ktorí na tú najjednoduchšiu transakciu prenesú nejaké aktívum bežným digitálnym podpisom, každý rok sú na klientovi stále masívnejšie výpočty, krypto-algoritmy sú čoraz silnejšie a táto časť spracovania môže sa v budúcnosti zmení na významnú prekážku. Buďte preto opatrní a nepremeškajte situáciu, keď pri transakcii trvajúcej 3.5s minie príprava a podpis transakcie 2.5s a odoslanie do siete a čakanie na odpoveď 1.0s. Ak chcete posúdiť riziká tohto úzkeho miesta, musíte zbierať metriky z klientskych strojov, a nie len z uzlov blockchainu.

Odoslanie transakcie a sledovanie jej stavu

Ďalším krokom je odoslanie transakcie do vybraného uzla blockchainu a získanie stavu jej prijatia do fondu transakcií. Táto fáza je podobná bežnému prístupu k databáze; uzol musí zaznamenať transakciu v skupine a začať o nej distribuovať informácie prostredníctvom siete p2p. Prístup k hodnoteniu výkonu je tu podobný ako pri hodnotení výkonu tradičných webových API mikroslužieb a samotné transakcie v blockchainoch je možné aktualizovať a aktívne meniť ich stav. Vo všeobecnosti môže k aktualizácii informácií o transakciách na niektorých blockchainoch dôjsť viackrát, napríklad pri prepínaní medzi reťazovými vidlicami alebo keď BP oznámia svoj zámer zahrnúť transakciu do bloku. Obmedzenia veľkosti tohto fondu a počtu transakcií v ňom môžu ovplyvniť výkon blockchainu. Ak je fond transakcií naplnený na maximálnu možnú veľkosť alebo sa nezmestí do pamäte RAM, výkon siete môže prudko klesnúť. Blockchainy nemajú žiadne centralizované prostriedky na ochranu pred záplavou nevyžiadaných správ a ak blockchain podporuje transakcie s vysokým objemom a nízkymi poplatkami, môže to spôsobiť pretečenie fondu transakcií – ďalšie potenciálne obmedzenie výkonu.

V blockchainoch klient odošle transakciu do akéhokoľvek blockchainového uzla, ktorý sa mu páči, hash transakcie je klientovi zvyčajne známy pred odoslaním, takže všetko, čo musí urobiť, je dosiahnuť spojenie a po prenose počkať, kým sa blockchain zmení. jeho stav, umožňujúci jeho transakciu. Všimnite si, že meraním „tps“ môžete získať úplne odlišné výsledky pre rôzne metódy pripojenia k uzlu blockchainu. Môže to byť bežný HTTP RPC alebo WebSocket, ktorý vám umožňuje implementovať vzor „subscribe“. V druhom prípade klient dostane upozornenie skôr a uzol minie menej zdrojov (hlavne pamäte a prevádzky) na odpovede o stave transakcie. Takže pri meraní „tps“ je potrebné vziať do úvahy spôsob, akým sa klienti pripájajú k uzlom. Preto, aby bolo možné posúdiť riziká tohto úzkeho miesta, benchmarkový blockchain musí byť schopný emulovať klientov s požiadavkami WebSocket aj HTTP RPC v pomeroch zodpovedajúcich skutočným sieťam, ako aj meniť povahu transakcií a ich veľkosť.

Ak chcete posúdiť riziká tohto úzkeho miesta, musíte tiež zbierať metriky z klientskych strojov, a nie len z uzlov blockchainu.

Prenos transakcií a blokov cez p2p sieť

V blockchainoch sa na prenos transakcií a blokov medzi účastníkmi používa sieť peer-to-peer (p2p). Transakcie sa šíria po celej sieti, začínajúc od jedného z uzlov, až kým sa nedostanú k producentom peer blokov, ktorí zabalia transakcie do blokov a pomocou rovnakého p2p distribuujú nové bloky do všetkých sieťových uzlov. Základom väčšiny moderných p2p sietí sú rôzne modifikácie protokolu Kademlia. Tu dobrý súhrn tohto protokolu a tu - článok s rôznymi meraniami v sieti BitTorrent, z ktorých sa dá pochopiť, že tento typ siete je zložitejší a menej predvídateľný ako pevne nakonfigurovaná sieť centralizovanej služby. tiež tu článok o meraní rôznych zaujímavých metrík pre uzly Ethereum.

Stručne povedané, každý partner v takýchto sieťach udržiava svoj vlastný dynamický zoznam ostatných partnerov, od ktorých požaduje bloky informácií, ktoré sú adresované obsahom. Keď partner dostane požiadavku, buď poskytne potrebné informácie, alebo odovzdá požiadavku ďalšiemu pseudonáhodnému partnerovi zo zoznamu, a keď dostane odpoveď, odovzdá ju žiadateľovi a na chvíľu ju uloží do vyrovnávacej pamäte. blok informácií nabudúce skôr. Obľúbené informácie tak končia vo veľkom počte cache veľkého počtu rovesníkov a nepopulárne informácie sa postupne nahrádzajú. Partneri vedú záznamy o tom, kto komu odovzdal koľko informácií, a sieť sa snaží stimulovať aktívnych distribútorov zvyšovaním ich hodnotenia a poskytovaním vyššej úrovne služieb, čím automaticky vytláča neaktívnych účastníkov zo zoznamov partnerov.

Transakciu je teda teraz potrebné distribuovať po sieti, aby ju producenti blokov mohli vidieť a zahrnúť do bloku. Uzol aktívne „distribuuje“ novú transakciu všetkým a počúva sieť, pričom čaká na blok, v indexe ktorého sa požadovaná transakcia objaví, aby upozornil čakajúceho klienta. Čas, ktorý potrebuje sieť na prenos informácií o nových transakciách a blokoch medzi sebou v sieťach p2p, závisí od veľmi veľkého množstva faktorov: počet poctivých uzlov pracujúcich v blízkosti (z hľadiska siete), „teplý- up“ vyrovnávacích pamätí týchto uzlov, veľkosť blokov, transakcie, charakter zmien, geografia siete, počet uzlov a mnoho ďalších faktorov. Komplexné merania výkonových metrík v takýchto sieťach sú komplexnou záležitosťou, je potrebné súčasne vyhodnocovať čas spracovania požiadaviek na klientoch aj peeroch (blockchain uzloch). Problémy v ktoromkoľvek z mechanizmov p2p, nesprávne vymazanie údajov a ukladanie do vyrovnávacej pamäte, neefektívna správa zoznamov aktívnych partnerov a mnohé ďalšie faktory môžu spôsobiť oneskorenia, ktoré ovplyvňujú efektivitu celej siete ako celku a toto úzke miesto je najťažšie analyzovať. , testovanie a interpretácia výsledkov.

Spracovanie blockchainu a aktualizácia stavovej databázy

Najdôležitejšou súčasťou blockchainu je konsenzuálny algoritmus, jeho aplikácia na nové bloky prijaté zo siete a spracovanie transakcií so záznamom výsledkov do štátnej databázy. Pridanie nového bloku do reťaze a následný výber hlavnej reťaze by malo fungovať čo najrýchlejšie. V reálnom živote však „mal by“ neznamená „funguje“ a možno si napríklad predstaviť situáciu, keď sa dva dlhé konkurenčné reťazce medzi sebou neustále prepínajú a menia metadáta tisícok transakcií v skupine pri každom prepnutí. a neustále vracať späť štátnu databázu. Táto fáza z hľadiska definovania úzkeho miesta je jednoduchšia ako sieťová vrstva p2p, pretože vykonanie transakcie a konsenzuálny algoritmus sú prísne deterministické a je jednoduchšie tu čokoľvek merať.
Hlavnou vecou nie je zamieňať si náhodnú degradáciu výkonu tejto fázy so sieťovými problémami – uzly sú pomalšie pri doručovaní blokov a informácií o hlavnom reťazci a pre externého klienta to môže vyzerať ako pomalá sieť, hoci problém spočíva v úplne iné miesto.

Na optimalizáciu výkonu v tejto fáze je užitočné zbierať a monitorovať metriky zo samotných uzlov a zahrnúť do nich tie, ktoré súvisia s aktualizáciou databázy stavu: počet blokov spracovaných na uzle, ich veľkosť, počet transakcií, počet prepínačov medzi reťazovými vidlicami, počet neplatných blokov, prevádzkový čas virtuálneho stroja, čas odovzdania údajov atď. Tým sa zabráni zámene problémov so sieťou s chybami v algoritmoch spracovania reťazca.

Virtuálny stroj spracovávajúci transakcie môže byť užitočným zdrojom informácií, ktoré môžu optimalizovať fungovanie blockchainu. Počet alokácií pamäte, počet inštrukcií na čítanie/zápis a ďalšie metriky súvisiace s efektívnosťou vykonávania kódu zmluvy môžu vývojárom poskytnúť veľa užitočných informácií. Inteligentné kontrakty sú zároveň programy, čo znamená, že teoreticky môžu spotrebovať ktorýkoľvek zo zdrojov: procesor/pamäť/sieť/úložisko, takže spracovanie transakcií je dosť neistá fáza, ktorá sa navyše výrazne mení pri prechode medzi verziami. a pri zmene zmluvných kódov. Preto sú na efektívnu optimalizáciu výkonu blockchainu potrebné aj metriky súvisiace so spracovaním transakcií.

Prijatie oznámenia o zaradení transakcie do blockchainu klientom

Toto je posledná fáza, kedy blockchain klient dostane službu; v porovnaní s inými fázami neexistujú žiadne veľké režijné náklady, ale stále stojí za zváženie možnosť, že klient dostane od uzla rozsiahlu odpoveď (napríklad smart kontrakt vrátenie poľa údajov). V každom prípade je tento bod najdôležitejší pre toho, kto položil otázku „koľko tps je vo vašom blockchaine?“, pretože V tomto momente je zaznamenaný čas prijatia služby.

Na tomto mieste sa vždy odošle celý čas, ktorý musel klient stráviť čakaním na odpoveď z blockchainu, práve tento čas bude používateľ čakať na potvrdenie vo svojej aplikácii a práve jeho optimalizácia je hlavnou úlohou vývojárov.

Záver

V dôsledku toho môžeme opísať typy operácií vykonávaných na blockchainoch a rozdeliť ich do niekoľkých kategórií:

kryptografické transformácie, dôkazová konštrukcia
sieť peer-to-peer, transakčná a bloková replikácia
spracovanie transakcií, realizácia smart kontraktov
aplikácia zmien v blockchaine do štátnej databázy, aktualizácia údajov o transakciách a blokoch
požiadavky iba na čítanie na stavovú databázu, API uzla blockchainu, služby predplatného

Vo všeobecnosti sú technické požiadavky na moderné uzly blockchainu mimoriadne vážne – rýchle CPU pre kryptografiu, veľké množstvo pamäte RAM na ukladanie a rýchly prístup k stavovej databáze, sieťová interakcia využívajúca veľké množstvo súčasne otvorených pripojení a veľké úložisko. Takéto vysoké požiadavky a množstvo rôznych typov operácií nevyhnutne vedie k tomu, že uzly nemusia mať dostatok zdrojov a potom sa ktorákoľvek z vyššie uvedených fáz môže stať ďalšou prekážkou pre celkový výkon siete.

Pri navrhovaní a hodnotení výkonu blockchainov budete musieť brať do úvahy všetky tieto body. Aby ste to dosiahli, musíte súčasne zbierať a analyzovať metriky od klientov a sieťových uzlov, hľadať medzi nimi korelácie, odhadovať čas potrebný na poskytovanie služieb klientom, brať do úvahy všetky hlavné zdroje: procesor/pamäť/sieť/úložisko pochopiť, ako sa používajú a navzájom sa ovplyvňujú. To všetko robí z porovnávania rýchlostí rôznych blockchainov vo forme „koľko TPS“ mimoriadne nevďačnú úlohu, keďže existuje veľké množstvo rôznych konfigurácií a stavov. Vo veľkých centralizovaných systémoch, klastroch stoviek serverov, sú tieto problémy tiež zložité a vyžadujú si aj zber veľkého množstva rôznych metrík, ale v blockchainoch, kvôli p2p sieťam, virtuálnym strojom na spracovanie zmlúv, interným ekonomikám, počtu stupňov slobody je oveľa väčšia, vďaka čomu je test aj na viacerých serveroch, je neindikatívny a ukazuje len extrémne približné hodnoty, ktoré nemajú takmer žiadnu súvislosť s realitou.

Preto pri vývoji v jadre blockchainu, aby sme zhodnotili výkon a odpovedali na otázku „zlepšilo sa to v porovnaní s minulou dobou?“, používame pomerne zložitý softvér, ktorý organizuje spustenie blockchainu s desiatkami uzlov a automaticky spúšťa benchmark a zbiera metriky. Bez týchto informácií je mimoriadne ťažké ladiť protokoly, ktoré pracujú s viacerými účastníkmi.

Takže, keď dostanete otázku „koľko TPS je vo vašom blockchaine?“, ponúknite svojmu partnerovi čaj a opýtajte sa, či je pripravený pozrieť sa na tucet grafov a tiež si vypočuť všetky tri krabice problémov s výkonom blockchainu a vaše návrhy riešiť ich...

Zdroj: hab.com

Koľko TPS je na vašom blockchaine?