Oblíbenou otázkou, kterou se netechnický odborník ptá na jakýkoli distribuovaný systém, je „Kolik tps má váš blockchain?“. Číslo zmíněné v odpovědi však obvykle má málo společného s tím, co by chtěl slyšet dotazující se. Ve skutečnosti se chtěl zeptat „Hodí se váš blockchain pro mé obchodní požadavky?“, a tyto požadavky nejsou jedno číslo, ale celá řada podmínek — zahrnují jak odolnost sítě, tak požadavky na konečnost, velikosti, charakter transakcí a řadu dalších parametrů. Odpověď na otázku „kolik tps“ tedy pravděpodobně nebude jednoduchá a téměř nikdy nebude úplná. Distribuovaný systém se desítkami a stovkami uzlů provádějících poměrně složitá výpočty může být ve velkém množství různých stavů v závislosti na stavu sítě, obsahu blockchainu, technických poruchách, ekonomických problémech, útocích na síť a z mnoha dalších důvodů. Etapy, ve kterých mohou problémy s výkonem nastat, se liší od tradičních služeb, a server blockchainové sítě je síťová služba, která kombinuje funkce databáze, webového serveru a torrent klienta, což z něj činí extrémně složité z pohledu zatížení všech subsystémů: procesoru, paměti, sítě, úložiště.

Tak se stalo, že decentralizované sítě a blockchainy jsou pro vývojáře centralizovaného softwaru poměrně specifickým a nezvyklým softwarem. Proto bych rád osvětlil důležité aspekty výkonu a spolehlivosti decentralizovaných sítí, přístupy k jejich měření a hledání úzkých míst. Prozkoumáme různé problémy s výkonem, které omezují rychlost poskytování služeb uživatelům blockchainů, a upozorníme na charakteristiky, které jsou pro tento typ softwaru typické.

Etapy požadavku na službu klientem blockchainu

Aby bylo možné čestně hodnotit kvalitu jakékoli složitější služby, je třeba vzít v úvahu nejen průměrné hodnoty, ale také maximální/minimální hodnoty, mediány a percentily. Teoreticky lze hovořit o 1000 TPS v nějakém blockchainu, ale pokud 900 transakcí proběhlo velmi rychle a 100 „uvízlo“ na několik sekund, pak průměrný čas shromážděný ze všech transakcí není pro klienta, který nemohl transakci dokončit během několika sekund, zcela férovou metrikou. Časové „jamky“ způsobené zmeškanými koly konsenzu nebo dělením sítě mohou výrazně zhoršit službu, která na testovacích stanicích vykazovala skvělou výkonnost.

Abychom identifikovali takové bottlenecky, musíme dobře porozumět etapám, ve kterých může skutečný blockchain zažívat potíže při obsluze uživatelů. Pojďme popsat cyklus dodávky a zpracování transakce, stejně jako získání nového stavu blockchainu, ze kterého se klient může ujistit, že jeho transakce byla zpracována a započítána.

transakce je vytvářena na klientovi
transakce je podepisována na klientovi
klient si vybírá jednu z uzlů a posílá do ní svou transakci
klient se přihlašuje k aktualizacím databáze stavu uzlu a čeká na výsledky zpracování své transakce
uzel šíří transakci po p2p síti
několik, nebo jeden BP (block producer) zpracovává nahromaděné transakce a aktualizuje databázi stavu
BP vytváří nový blok zpracováním potřebného počtu transakcí
BP šíří nový blok po p2p síti
nový blok je doručen uzlu, na který se klient obrací
uzel aktualizuje databázi stavu
uzel vidí aktualizaci týkající se klienta a posílá mu upozornění o transakci

Nyní se podívejme podrobněji na tyto etapy a popišme potenciální problémy s výkonem v každé fázi. Na rozdíl od centralizovaných systémů se také zaměříme na vykonávání kódu na klientech sítě. Poměrně často, při měření TPS, se čas zpracování transakcí shromažďuje z uzlů, nikoli z klienta — to není zcela fér. Klientovi je jedno, jak rychle uzel zpracoval jeho transakci, pro něj je nejdůležitější okamžik, kdy se spolehlivé informace o této transakci, začleněné do blockchainu, stanou dostupné. Tato metrika je v podstatě časem vykonání transakce. To znamená, že různí klienti, i když posílají tutéž transakci, mohou získat zcela odlišné časy, které závisí na kanálu, zatížení a blízkosti uzlu atd. Je tedy naprosto nezbytné měřit tento čas na klientech, protože právě tento parameter je třeba optimalizovat.

Příprava transakce na straně klienta

Začněme s prvními dvěma body: transakce je formována a podepisována klientem. Jak to může být překvapivé, také to může být výkonovým úzkým místem blockchainu z pohledu klienta. To je nezvyklé pro centralizované služby, které veškeré výpočty a operace s daty berou na sebe, zatímco klient prostě připravuje krátký dotaz, schopný požadovat velké objemy dat nebo výpočtů a získává hotový výsledek. V blockchainech se klientský kód stává čím dál tím mocnějším, zatímco jádro blockchainu je čím dál tím lehčí, a masivní výpočetní úkoly jsou běžně svěřovány klientskému softwaru. V blockchainech existují klienti, kteří mohou připravovat jednu transakci docela dlouho (mluvím o různých merkle proofech, succinct proofech, threshold podpisech a dalších složitých operacích na straně klienta). Příkladem snadné on-chain verifikace a těžké přípravy transakce na klientovi je důkaz příslušnosti k seznamu založený na Merkle-trees. neaktuální statistika.

Také je důležité si uvědomit, že klientský kód ne pouze odesílá transakce do blockchainu, ale nejprve žádá o stav blockchainu - a tato činnost může ovlivnit zatížení sítě a uzlů blockchainu. Při měření je tedy rozumné co nejvíce emulovat chování klientského kódu. I když ve vašem blockchainu běží obyčejní lehcí klienti, kteří podepisují obyčejnou digitální transakci na převod nějakého aktiva, s každým rokem se množství výpočtů na klientovi zvyšuje, kryptografické algoritmy se posilují a tato část zpracování se může v budoucnu stát významným úzkým místem. Proto buďte opatrní a nepřehlédněte situaci, kdy u transakce trvající 3,5 sekundy trvá 2,5 sekundy na přípravu a podpis transakce, a 1,0 sekundy na odeslání do sítě a čekání na odpověď. Pro hodnocení rizika vzniku tohoto úzkého místa je nutné shromažďovat metriky z klientských strojů, a ne pouze z uzlů blockchainu.

Odeslání transakce a sledování jejího stavu

Dalším krokem je odeslání transakce do vybraného uzlu blockchainu a získání stavu jejího přijetí do transakčního poolu. Tento krok je podobný běžnému dotazu na databázi, uzel musí zaznamenat transakci do poolu a začít šířit informace o ní prostřednictvím p2p sítě. Přístup k hodnocení výkonu zde je podobný hodnocení práce tradičních mikroslužeb Web API, přičemž samotné transakce v blockchainech mohou být aktualizovány a aktivně měnit svůj status. Obecně může aktualizace informací o transakci v některých blockchainech probíhat několikrát, například při přepínání mezi forky řetězce nebo když BP oznamují úmysl zahrnout transakci do bloku. Omezení na objem tohoto poolu a počet transakcí v něm mohou mít vliv na výkon blockchainu. Pokud je transakční pool zaplněn na maximální možnou velikost, nebo se nevejde do operační paměti - výkon sítě může výrazně klesnout. Blockchainy nemají centralizované prostředky na ochranu před tokem spamových zpráv, a pokud blockchain podporuje transakce velkého objemu a nízké poplatky, může to vést k přeplnění transakčního poolu - to je další potenciální úzké místo výkonu.

V blockchainu klient posílá transakci do libovolného uzlu blockchainu, hash transakce je obvykle klientovi znám i před odesláním, takže jediným, co potřebuje, je navázat spojení a po odeslání čekat, až se blockchain změní a zahrne jeho transakci. Je třeba poznamenat, že při měření 'tps' mohou být výsledky různorodé v závislosti na způsobu připojení k uzlu blockchainu. To může být běžný HTTP RPC nebo WebSocket, který umožňuje realizaci vzoru 'subscribe'. V druhém případě klient dostane upozornění dřív a uzel vynaloží méně prostředků (převážně paměti a dat) na odpovědi o stavu transakce. Při měření 'tps' je tedy nutné brát v úvahu způsob připojení klientů k uzlům. Proto by při hodnocení rizik vzniku tohoto bottlenecku měl benchmark blockchainu umět emulovat klienty s WebSocketem i HTTP RPC požadavky v podílech odpovídajících reálným sítím, a také měnit charakter transakcí a jejich velikost.

Pro hodnocení rizik vzniku tohoto bottlenecku je také nutné sbírat metriky z klientských strojů, ne jen z blockchainových uzlů.

Přenos transakcí a bloků přes p2p síť

V blockchainu se pro přenos mezi účastníky transakcí a bloků používá peer-to-peer (p2p) networking. Transakce se šíří sítí, počínaje jedním uzlem, dokud nedosáhnou peerů - producentů bloků, kteří balí transakce do bloků a s pomocí téže p2p sítě šíří nové bloky po všech uzlech sítě. Základ většiny moderních p2p sítí tvoří různé modifikace protokolu Kademlia. Tady dobrý stručný přehled tohoto protokolu, a tady je — článek s různými měřeními v síti BitTorrent, podle kterého lze pochopit, že tento typ sítí je složitější a méně předvídatelný než pevně konfigurovaná síť centralizované služby. Také, tady je článek o měření různých zajímavých metrik pro uzly Ethereum.

Stručně řečeno, každý peer v takových sítích udržuje svůj vlastní dynamický seznam dalších peerů, od kterých požaduje bloky informací podle obsahu. Při obdržení požadavku peer buď poskytne požadované informace, nebo předá požadavek dalšímu pseudo-náhodnému peerovi ze seznamu, a poté, co obdrží odpověď, předá ji požadujícímu a na určitou dobu ji ukládá do cache, čímž tento blok informací dodá dříve při příštím požadavku. Tak se populární informace ocitá v mnoha cache různých peerů, zatímco nepříliš populární se postupně vytlačuje. Peery evidují, kdo komu kolik informací předal, a síť se snaží stimulovat aktivní distributory tím, že zvyšuje jejich hodnocení a zajišťuje jim vyšší úroveň služby, automatem vytlačujíc neaktivní účastníky ze seznamů peerů.

Takže nyní je třeba transakci rozšířit po síti, aby ji viděli block-producery a zahrnuli ji do bloku. Node aktivně "distribuuje" novou transakci všem zájemcům a naslouchá síti, očekávajíc blok, ve kterém se objeví požadovaná transakce, aby mohl informovat čekajícího klienta. Doba, po kterou síť předává informace o nových transakcích a blocích v p2p sítích, závisí na velmi velkém množství faktorů: počtu čestných, pracovních nodů v blízkosti (z hlediska sítě), „ohřátosti“ cache těchto nodů, velikosti bloků, transakcí, povaze změn, geografii sítě, počtu nodů a nespočtu dalších faktorů. Složitá měření výkonnostních metrik v takových sítích jsou obtížný úkol, je třeba současně hodnotit dobu zpracování požadavků na klientech a na peerech (blockchain nodách). Problémy v některém z p2p mechanismů, nesprávné vytlačování a cachování dat, neefektivní správa seznamů aktivních peerů a mnoho dalších faktorů mohou vést k prodlevám, které ovlivňují efektivitu celé sítě, a tento bottleneck je nejtěžší pro analýzu, testování a interpretaci výsledků.

Zpracování řetězce bloků a aktualizace state database

Nejdůležitější částí práce blockchainu je algoritmus konsensu, jeho aplikace na nové bloky získané ze sítě a zpracování transakcí se zapisováním výsledků do state database. Přidání nového bloku do řetězce a následující výběr hlavního řetězce by mělo fungovat co nejrychleji. Nicméně, v reálném životě „by mělo“ neznamená „funguje“, a můžeme si představit situaci, kdy se dvě dlouhé konkurenční řetězce neustále přepínají mezi sebou, měnící metadata tisíců transakcí v poolu při každém přepnutí a neustále provádějící návraty stavu state database. Tato fáze, pokud jde o určení bottlenecku, je jednodušší než síťová p2p vrstva, protože provádění transakcí a algoritmus konsensu jsou přísně deterministické a měření čehokoli zde je jednodušší.
Hlavní je neplést náhodnou degradaci výkonu této fáze s problémy sítě — uzly pomaleji dávají bloky a informace o hlavním řetězci a pro externího klienta to může vypadat jako pomalá síť, i když problém spočívá úplně někde jinde.

Pro optimalizaci výkonu v této fázi je užitečné shromažďovat a monitorovat metriky z samotných uzlů a zahrnout do nich i ty, které se týkají aktualizace state-database: počet bloků zpracovávaných na uzlu, jejich velikost, počet transakcí, počet přepnutí mezi forky řetězců, počet neplatných bloků, čas práce virtuálního stroje, doba zafixování dat atd. To umožní neplést síťové problémy s chybami v algoritmech zpracování řetězců.

Proces zpracování transakcí ve virtuálním stroji může být užitečným zdrojem informací, které mohou optimalizovat práci blockchainu. Počet alokací paměti, počet read/write instrukcí a další metriky týkající se účinnosti provádění kódu kontraktů mohou poskytnout mnoho užitečných informací vývojářům. Zároveň jsou chytré kontrakty programy, a tedy teoreticky mohou spotřebovávat jakékoli zdroje: cpu/memory/network/storage, takže zpracování transakcí je poměrně neurčitá fáze, která se navíc výrazně mění při přechodu mezi verzemi a při změně kódu kontraktů. Proto jsou metriky týkající se zpracování transakcí také potřebné pro efektivní optimalizaci výkonu blockchainu.

Oznámení zákazníkovi o zapnutí transakce v blockchainu

To je poslední fáze získávání služby zákazníkem blockchainu, ve srovnání s ostatními fázemi zde nejsou velké náklady, ale stále je třeba zohlednit možnost obdržení objemné odpovědi od uzlu (například chytrý kontrakt vracející pole dat). V každém případě je tento okamžik nejdůležitější pro toho, kdo se ptá "kolik tps má váš blockchain?", protože v tomto okamžiku se zaznamenává čas získání služby.

V tomto místě musí být odesláno celkové množství času, které zákazník strávil čekáním na odpověď od blockchainu, právě tento čas bude uživatel očekávat jako potvrzení ve své aplikaci, a jeho optimalizace je hlavním úkolem vývojářů.

Závěr

Na základě výsledků lze popsat typy operací prováděných v blockchainech a rozdělit je do několika kategorií:

kryptografické transformace, tvorba důkazů
peer-to-peer networking, replikace transakcí a bloků
zpracování transakcí, provádění chytrých kontraktů
aplikace změn v blockchainu na state database, aktualizace dat o transakcích a blocích
read-only dotazy na state database, API blockchainového uzlu, subscribe služby

Obecně platí, že technické požadavky na uzly moderních blockchainů jsou velmi přísné — to jsou rychlé CPU pro kryptografii, velké množství operační paměti pro ukládání a rychlý přístup ke state database, síťová interakce využívající velké množství současně otevřených připojení, rozsáhlé úložiště. Tyto vysoké požadavky a různé typy operací nevyhnutelně vedou k tomu, že uzlům může chybět zdroj, a pak se jakákoli z výše uvedených fází může stát dalším úzkým hrdlem pro celkový výkon sítě.

Při vývoji a hodnocení výkonu blockchainů je třeba zohlednit všechny tyto aspekty. K tomu je nutné sbírat a analyzovat metriky současně z klientů a uzlů sítě, hledat mezi nimi korelace, hodnotit čas poskytování služeb klientům, brát v úvahu všechny základní zdroje: cpu/memory/network/storage, a chápat, jak jsou tyto zdroje využívány a jak na sebe vzájemně působí. To vše činí srovnávání rychlosti různých blockchainů ve smyslu „kolik TPS“ nesmírně vděčným úkolem, protože existuje obrovské množství různých konfigurací a stavů. V velkých centralizovaných systémech, klastrech stovek serverů, jsou tyto problémy také složité a vyžadují shromažďování velkého počtu různých metrik, ale u blockchainů, díky p2p sítím, virtuálním strojům, procesům smart kontraktů a interní ekonomice, je počet stupňů volnosti mnohem vyšší, což činí test i na několika serverech nepředstavitelným a ukazuje pouze velmi aproximované hodnoty, které mají téměř žádnou spojitost s realitou.

Proto při vývoji v jádru blockchainu, pro hodnocení výkonu a odpověď na otázku „zlepšilo se to ve srovnání s minulým pokusem?“ používáme poměrně složitý software, který orchestruje spuštění blockchainu s desítkami uzlů a automatickým spuštěním benchmarku a sběrem metrik, bez těchto informací je velmi obtížné ladit protokoly, které pracují s mnoha účastníky.

Takže, pokud obdržíte otázku „kolik TPS ve vašem blockchainu?“, nabídněte svému protějšku čaj a zeptejte se, zda je ochoten se seznámit s desítkami grafů a také vyslechnout všechny tři krabice problémů s výkonem blockchainů a vaše návrhy na jejich řešení...

Zdroj: habr.com