Oblíbená otázka o jakémkoli distribuovaném systému od netechnické osoby je „Kolik tps je na vašem blockchainu?“ Číslo uvedené v odpovědi má však obvykle jen málo společného s tím, co by tazatel chtěl slyšet. Ve skutečnosti se chtěl zeptat „bude váš blockchain vyhovovat mým obchodním požadavkům“ a tyto požadavky nejsou jedno číslo, ale mnoho podmínek – zde je odolnost proti chybám sítě, požadavky na finalitu, velikosti, povaha transakcí a mnoho dalších parametrů. Takže odpověď na otázku „kolik tps“ pravděpodobně nebude jednoduchá a téměř nikdy úplná. Distribuovaný systém s desítkami nebo stovkami uzlů provádějících poměrně složité výpočty se může nacházet v obrovském množství různých stavů souvisejících se stavem sítě, obsahem blockchainu, technickými poruchami, ekonomickými problémy, útoky na síť a mnoha dalšími důvody. . Fáze, ve kterých jsou možné problémy s výkonem, se liší od tradičních služeb a blockchainový síťový server je síťová služba, která kombinuje funkčnost databáze, webového serveru a torrent klienta, díky čemuž je extrémně složitá, pokud jde o profil zatížení na všech podsystémech. : procesor, paměť, síť, úložiště

Stává se, že decentralizované sítě a blockchainy jsou pro vývojáře centralizovaného softwaru zcela specifický a neobvyklý software. Proto bych rád zdůraznil důležité aspekty výkonu a udržitelnosti decentralizovaných sítí, přístupy k jejich měření a hledání úzkých míst. Podíváme se na různé problémy s výkonem, které omezují rychlost poskytování služeb uživatelům blockchainu, a všimneme si vlastností charakteristických pro tento typ softwaru.

Fáze požadavku na službu klientem blockchainu

Abyste mohli upřímně mluvit o kvalitě jakékoli více či méně komplexní služby, musíte brát v úvahu nejen průměrné hodnoty, ale také maximum/minimum, mediány, percentily. Teoreticky můžeme v nějakém blockchainu mluvit o 1000 tps, ale pokud bylo 900 transakcí dokončeno obrovskou rychlostí a 100 bylo „zaseknutých“ na pár sekund, pak průměrný čas nasbíraný za všechny transakce není pro klienta úplně férová metrika. který jsem nemohl dokončit transakci během několika sekund. Dočasné „díry“ způsobené zmeškanými konsensuálními koly nebo rozdělením sítě mohou značně zničit službu, která na zkušebních stolicích prokázala vynikající výkon.

K identifikaci takových úzkých míst je nutné dobře porozumět fázím, ve kterých může mít skutečný blockchain potíže s obsluhou uživatelů. Pojďme si popsat cyklus doručení a zpracování transakce a také získání nového stavu blockchainu, ze kterého si klient může ověřit, že jeho transakce byla zpracována a zaúčtována.

transakce se tvoří na klientovi
transakce je podepsána na klientovi
klient vybere jeden z uzlů a odešle mu svou transakci
klient se přihlásí k odběru aktualizací stavové databáze uzlu a čeká, až se objeví výsledky jeho transakce
uzel distribuuje transakci přes p2p síť
několik nebo jeden BP (výrobce bloků) zpracovává nahromaděné transakce a aktualizuje státní databázi
BP vytvoří nový blok po zpracování požadovaného počtu transakcí
BP distribuuje nový blok přes p2p síť
nový blok je doručen do uzlu, ke kterému klient přistupuje
uzel aktualizuje stavovou databázi
uzel vidí aktualizaci týkající se klienta a odešle mu oznámení o transakci

Nyní se podívejme blíže na tyto fáze a popišme potenciální problémy s výkonem v každé fázi. Na rozdíl od centralizovaných systémů budeme zvažovat i spouštění kódu na síťových klientech. Poměrně často se při měření TPS doba zpracování transakce sbírá od uzlů, nikoli od klienta – to není úplně fér. Klienta nezajímá, jak rychle uzel jeho transakci zpracoval, nejdůležitější je pro něj okamžik, kdy se mu zpřístupní spolehlivé informace o této transakci zahrnuté v blockchainu. Právě tato metrika je v podstatě dobou provedení transakce. To znamená, že různí klienti, i když odesílají stejnou transakci, mohou přijímat zcela odlišné časy, které závisí na kanálu, zatížení a blízkosti uzlu atd. Je tedy bezpodmínečně nutné měřit tento čas na klientech, jelikož je to parametr, který je potřeba optimalizovat.

Příprava transakce na straně klienta

Začněme prvními dvěma body: transakci tvoří a podepisuje klient. Kupodivu to může být také úzkým hrdlem výkonu blockchainu z pohledu klienta. To je neobvyklé u centralizovaných služeb, které převezmou veškeré výpočty a operace s daty a klient jednoduše připraví krátký požadavek, který si může vyžádat velké množství dat nebo výpočtů, čímž získá hotový výsledek. V blockchainech se klientský kód stává stále výkonnějším a jádro blockchainu se stává stále lehčím a masivní výpočetní úlohy jsou obvykle přenášeny do klientského softwaru. V blockchainech jsou klienti, kteří dokážou jednu transakci připravovat poměrně dlouho (mám na mysli různé merkle proofy, stručné důkazy, prahové podpisy a další složité operace na straně klienta). Dobrým příkladem snadného on-chain ověření a náročné přípravy transakce na klientovi je doklad o členství v seznamu založeném na Merkle-tree, zde článek.

Nezapomeňte také, že klientský kód jednoduše neposílá transakce do blockchainu, ale nejprve se dotazuje na stav blockchainu – a tato aktivita může ovlivnit zahlcení sítě a blockchainových uzlů. Při měření by tedy bylo rozumné co nejúplněji emulovat chování klientského kódu. I když jsou ve vašem blockchainu obyčejní lehcí klienti, kteří dávají běžný digitální podpis na nejjednodušší transakci, aby převedli nějaké aktivum, každým rokem jsou na klientovi stále masivnější výpočty, kryptoalgoritmy jsou stále silnější a tato část zpracování může se v budoucnu promění ve významné úzké hrdlo. Buďte proto opatrní a nenechte si ujít situaci, kdy při transakci trvající 3.5s stráví příprava a podpis transakce 2.5s a odeslání do sítě a čekání na odpověď 1.0s. Abyste mohli posoudit rizika tohoto úzkého hrdla, musíte shromažďovat metriky z klientských strojů, nejen z uzlů blockchainu.

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

Dalším krokem je odeslání transakce do vybraného blockchainového uzlu a obdržení stavu jejího přijetí do transakčního fondu. Tato fáze je podobná běžnému přístupu k databázi, uzel musí transakci zaznamenat do fondu a začít o ní distribuovat informace prostřednictvím sítě p2p. Přístup k hodnocení výkonu je zde podobný jako při hodnocení výkonu tradičních webových API mikroslužeb a samotné transakce v blockchainech lze aktualizovat a aktivně měnit jejich stav. Obecně může k aktualizaci informací o transakcích na některých blockchainech dojít vícekrát, například při přepínání mezi řetězovými rozvětvemi nebo když BP oznámí svůj záměr zahrnout transakci do bloku. Omezení velikosti tohoto fondu a počtu transakcí v něm mohou ovlivnit výkon blockchainu. Pokud je fond transakcí naplněn na maximální možnou velikost nebo se nevejde do paměti RAM, výkon sítě může prudce klesnout. Blockchainy nemají žádné centralizované prostředky k ochraně před záplavou nevyžádaných zpráv, a pokud blockchain podporuje velkoobjemové transakce a nízké poplatky, může to způsobit přetečení fondu transakcí – další potenciální problémové místo výkonu.

V blockchainech klient odešle transakci do libovolného blockchainového uzlu, který se mu líbí, hash transakce je klientovi obvykle znám před odesláním, takže stačí dosáhnout spojení a po přenosu počkat, až se blockchain změní. jeho stavu, umožňující jeho transakci. Všimněte si, že měřením „tps“ můžete získat zcela odlišné výsledky pro různé metody připojení k uzlu blockchainu. Může to být běžný HTTP RPC nebo WebSocket, který vám umožní implementovat vzor „subscribe“. Ve druhém případě klient obdrží upozornění dříve a uzel utratí méně prostředků (hlavně paměti a provozu) na odpovědi o stavu transakce. Při měření „tps“ je tedy nutné vzít v úvahu způsob, jakým se klienti připojují k uzlům. Aby bylo možné vyhodnotit rizika tohoto úzkého hrdla, musí být benchmarkový blockchain schopen emulovat klienty s požadavky WebSocket i HTTP RPC v proporcích odpovídajících skutečným sítím a také měnit povahu transakcí a jejich velikost.

Abyste mohli posoudit rizika tohoto úzkého hrdla, musíte také sbírat metriky z klientských strojů, a to nejen z uzlů blockchainu.

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

V blockchainech se k přenosu transakcí a bloků mezi účastníky používá síť peer-to-peer (p2p). Transakce se šíří po síti, počínaje jedním z uzlů, dokud nedosáhnou producentů peer bloků, kteří zabalí transakce do bloků a pomocí stejného p2p distribuují nové bloky do všech síťových uzlů. Základem většiny moderních p2p sítí jsou různé modifikace protokolu Kademlia. zde je dobré shrnutí tohoto protokolu a zde - článek s různými měřeními v síti BitTorrent, ze kterého lze pochopit, že tento typ sítě je složitější a méně předvídatelný než rigidně nakonfigurovaná síť centralizované služby. Taky, zde č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 ostatních peerů, od kterých požaduje bloky informací, které jsou adresovány obsahem. Když peer obdrží požadavek, buď poskytne potřebné informace, nebo předá požadavek dalšímu pseudonáhodnému peerovi ze seznamu a poté, co obdrží odpověď, předá jej žadateli a na chvíli jej uloží do mezipaměti, čímž poskytne toto blok informací příště dříve. Oblíbené informace tak končí ve velkém množství keší velkého počtu peerů a nepopulární informace jsou postupně nahrazovány. Peers vedou záznamy o tom, kdo komu předal kolik informací, a síť se snaží stimulovat aktivní distributory tím, že zvyšuje jejich hodnocení a poskytuje jim vyšší úroveň služeb, čímž automaticky vytlačuje neaktivní účastníky ze seznamů kolegů.

Transakce tedy nyní musí být distribuována po síti, aby ji producenti bloků viděli a zahrnuli ji do bloku. Uzel aktivně „distribuuje“ novou transakci všem a naslouchá síti a čeká na blok, v jehož indexu se požadovaná transakce objeví, aby upozornil čekajícího klienta. Doba, kterou si síť mezi sebou přenese informace o nových transakcích a blocích v sítích p2p, závisí na velmi velkém počtu faktorů: na počtu poctivých uzlů pracujících v blízkosti (z hlediska sítě), na „teplo- nahoru“ cache těchto uzlů, velikost bloků, transakce, povaha změn, geografie sítě, počet uzlů a mnoho dalších faktorů. Komplexní měření výkonnostních metrik v takových sítích je komplexní záležitostí, je nutné současně vyhodnocovat dobu zpracování požadavku na klientech i peerech (blockchain nodech). Problémy v kterémkoli z mechanismů p2p, nesprávné vyřazení dat a ukládání do mezipaměti, neefektivní správa seznamů aktivních peerů a mnoho dalších faktorů mohou způsobit zpoždění, která ovlivňují efektivitu celé sítě jako celku, a toto úzké hrdlo je nejobtížněji analyzovatelné. , test a interpretace výsledků.

Zpracování blockchainu a aktualizace stavové databáze

Nejdůležitější součástí blockchainu je konsenzuální algoritmus, jeho aplikace na nové bloky přijaté ze sítě a zpracování transakcí se záznamem výsledků do státní databáze. Přidání nového bloku do řetězu a poté výběr hlavního řetězce by mělo fungovat co nejrychleji. V reálném životě však „měl by“ neznamená „funguje“ a lze si například představit situaci, kdy se dva dlouhé konkurenční řetězce mezi sebou neustále přepínají a mění metadata tisíců transakcí v poolu při každém přepínači. a neustále vrací stav databáze zpět. Tato fáze, pokud jde o definování úzkého místa, je jednodušší než síťová vrstva p2p, protože provádění transakce a konsensus algoritmus jsou přísně deterministické a je snazší zde cokoliv měřit.
Hlavní věcí je nezaměňovat náhodnou degradaci výkonu této fáze se síťovými problémy - uzly jsou pomalejší v doručování bloků a informací o hlavním řetězci a pro externího klienta to může vypadat jako pomalá síť, i když problém spočívá v úplně jiné místo.

Pro optimalizaci výkonu v této fázi je užitečné shromažďovat a monitorovat metriky ze samotných uzlů a zahrnout do nich ty, které se týkají aktualizace stavové databáze: počet zpracovaných bloků na uzlu, jejich velikost, počet transakcí, počet přepínačů mezi řetězovými vidlicemi, počet neplatných bloků, provozní doba virtuálního stroje, doba odevzdání dat atd. To zabrání tomu, aby byly problémy se sítí zaměňovány s chybami v algoritmech řetězového zpracování.

Virtuální stroj zpracovávající transakce může být užitečným zdrojem informací, které mohou optimalizovat fungování blockchainu. Počet alokací paměti, počet instrukcí pro čtení/zápis a další metriky související s efektivitou provádění kódu smlouvy mohou vývojářům poskytnout mnoho užitečných informací. Chytré kontrakty jsou zároveň programy, což teoreticky znamená, že mohou spotřebovat jakýkoli ze zdrojů: cpu/paměť/síť/úložiště, takže zpracování transakcí je dosti nejistá fáze, která se navíc při přechodu mezi verzemi značně mění. a při změně smluvních kódů. Proto jsou také potřebné metriky související se zpracováním transakcí pro efektivní optimalizaci výkonu blockchainu.

Přijetí upozornění klienta o zařazení transakce do blockchainu

Toto je poslední fáze, kdy blockchainový klient obdrží službu; ve srovnání s jinými fázemi nevznikají žádné velké režijní náklady, ale stále stojí za zvážení možnosti, že klient obdrží od uzlu objemnou odpověď (například inteligentní smlouva vrací pole dat). V každém případě je tento bod nejdůležitější pro toho, kdo položil otázku „kolik tps je ve vašem blockchainu?“, protože V tomto okamžiku je zaznamenán čas přijetí služby.

Na tomto místě se vždy odešle plný čas, který musel klient strávit čekáním na odpověď z blockchainu, právě tento čas bude uživatel čekat na potvrzení ve své aplikaci a právě jeho optimalizace je hlavní. hlavním úkolem vývojářů.

Závěr

Díky tomu můžeme popsat typy operací prováděných na blockchainech a rozdělit je do několika kategorií:

kryptografické transformace, konstrukce důkazů
peer-to-peer networking, transakční a bloková replikace
zpracování transakcí, realizace smart kontraktů
aplikace změn v blockchainu do státní databáze, aktualizace dat o transakcích a blocích
požadavky pouze pro čtení na stavovou databázi, blockchain node API, předplatné služby

Obecně platí, že technické požadavky na moderní uzly blockchainu jsou extrémně vážné – rychlé CPU pro kryptografii, velké množství paměti RAM pro uložení a rychlý přístup ke stavové databázi, síťová interakce využívající velké množství současně otevřených připojení a velké úložiště. Takto vysoké požadavky a množství různých typů operací nevyhnutelně vedou k tomu, že uzly nemusí mít dostatek zdrojů, a pak se která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 navrhování a hodnocení výkonu blockchainů budete muset vzít v úvahu všechny tyto body. Chcete-li to provést, musíte současně shromažďovat a analyzovat metriky od klientů a síťových uzlů, hledat mezi nimi korelace, odhadovat čas potřebný k poskytování služeb klientům, brát v úvahu všechny hlavní zdroje: procesor/paměť/síť/úložiště pochopit, jak se používají a vzájemně se ovlivňují. To vše dělá z porovnávání rychlostí různých blockchainů ve formě „kolik TPS“ extrémně nevděčný úkol, protože existuje obrovské množství různých konfigurací a stavů. Ve velkých centralizovaných systémech, shlucích stovek serverů, jsou tyto problémy také složité a vyžadují také sběr velkého množství různých metrik, ale v blockchainech kvůli p2p sítím, smlouvám o zpracování virtuálních strojů, interním ekonomikám, počtu stupňů svobody je mnohem větší, díky čemuž je test i na několika serverech, je neindikativní a ukazuje pouze extrémně přibližné hodnoty, které nemají téměř žádnou souvislost s realitou.

Proto při vývoji v jádru blockchainu, abychom vyhodnotili výkon a odpověděli na otázku „zlepšilo se to oproti minule?“, používáme poměrně složitý software, který řídí spuštění blockchainu s desítkami uzlů a automaticky spouští benchmark a shromažďuje metriky. Bez těchto informací je extrémně obtížné ladit protokoly, které pracují s více účastníky.

Takže když dostanete otázku „kolik TPS je ve vašem blockchainu?“, nabídněte svému partnerovi čaj a zeptejte se, zda je připraven podívat se na tucet grafů a také si poslechnout všechny tři krabice problémů s výkonem blockchainu a vaše návrhy na řešit je...

Zdroj: www.habr.com

Kolik TPS je na vašem blockchainu?