Det mest stillede spørgsmål om ethvert distribueret system fra en ikke-teknisk person er: “Hvor mange tps har jeres blockchain?”. Det tal, der gives som svar, har dog sjældent noget at gøre med det, som spørgeren ønsker at høre. I virkeligheden ville spørgsmålet være: “Er jeres blockchain egnet til mine forretningskrav?”, og disse krav handler ikke om et enkelt tal, men om en række betingelser — herunder redundans i netværket, finalitetskrav, størrelser, karakteren af transaktioner og mange andre parametre. Så svaret på spørgsmålet “hvor mange tps” vil næppe være simpelt, og det vil næsten aldrig være fuldstændigt. Et distribueret system med titusinder og hundredevis af noder, der udfører ret komplekse beregninger, kan befinde sig i et enormt antal forskellige tilstande, afhængigt af netværkets tilstand, indholdet af blockchainen, tekniske fejl, økonomiske problemer, angreb på netværket og mange andre årsager. De faser, hvor der kan opstå præstationsproblemer, adskiller sig fra traditionelle tjenester, og serveren i blockchain-netværket er en netværkstjeneste, der kombinerer funktionaliteten af en database, webserver og torrent-klient, hvilket gør den ekstremt kompleks med hensyn til belastningsprofilen på alle undersystemer: CPU, hukommelse, netværk, lagring.

Det viser sig, at decentrale netværk og blockchains er ret specifik og uvant software for udviklere af centraliseret software. Derfor vil jeg gerne belyse de væsentlige aspekter af præstation og robusthed i decentrale netværk, tilgange til måling af dem og identificering af flaskehalse. Vi vil se på forskellige præstationsproblemer, der begrænser hastigheden af tjenesteydelser til blockchain-brugere og bemærke de særlige træk, der kendetegner denne type software.

Faserne for anmodning om service fra blockchain-klienten

For an honest discussion about the quality of any reasonably complex service, it's essential to consider not only the average values but also maximum/minimum, medians, and percentiles. Theoretically, one might talk about 1000 tps in some blockchain, but if 900 transactions were completed at high speed while 100 'stuck' for a few seconds, the average time calculated across all transactions is not quite a fair metric for a client who couldn’t complete a deal in just a few seconds. Time 'gaps' caused by missed consensus rounds or network splits can significantly spoil a service that demonstrated excellent performance on test benches.

To identify such bottlenecks, it's crucial to have a thorough understanding of the stages where a real blockchain may encounter difficulties in serving users. Let's describe the transaction delivery and processing cycle, as well as how to obtain a new state of the blockchain, from which the client can verify that their transaction has been processed and accounted for.

the transaction is formed on the client
the transaction is signed on the client
the client chooses one of the nodes and sends their transaction to it
the client subscribes to updates from the state's database of the node, waiting for the results of their transaction execution
the node disseminates the transaction across the p2p network
one or more BPs (block producers) process the accumulated transactions, updating the state database
the BP forms a new block after processing the required number of transactions
the BP spreads the new block across the p2p network
the new block is delivered to the node that the client queries
the node updates the state database
the node sees the update concerning the client and sends them a notification about the transaction

Lad os nu se nærmere på disse trin og beskrive potentielle ydelsesproblemer i hvert trin. I modsætning til centraliserede systemer vil vi også se på kodeudførelse på netværksklienter. Det er ganske ofte, at tps-målinger for behandlingstiden for transaktioner indsamles fra noder og ikke fra klienten — det er ikke helt retfærdigt. Klienten er ligeglad med, hvor hurtigt noden har behandlet hans transaktion; det vigtigste for ham er, hvornår den pålidelige information om denne transaktion, der er inkluderet i blockchainen, bliver tilgængelig for ham. Netop denne måling er i virkeligheden tiden for transaktionsudførelsen. Dette betyder, at forskellige klienter, selv når de sender den samme transaktion, kan få helt forskellige tider, som afhænger af kanalen, belastningen og nodens nærhed, osv. Så det er helt nødvendigt at måle denne tid på klienterne, da det netop er denne parameter, der skal optimeres.

Forberedelse af transaktionen på klientsiden

Lad os starte med de to første punkter: transaktionen dannes og signeres af klienten. Underligt nok kan dette også være et flaskehalsproblem for blockchainens ydeevne set fra klientens perspektiv. Dette er uvant for centraliserede tjenester, som håndterer alle beregninger og dataoperationer selv, mens klienten blot forbereder en kort forespørgsel, der har potentiale til at anmode om store mængder data eller beregninger og modtage det færdige resultat. I blockchain-teknologier bliver klientkoden mere og mere kraftfuld, mens blockchain-kernen bliver mere og mere letvægts, og omfattende beregningsopgaver er blevet standard at give til klientsoftwaren. I blockchain findes der klienter, som kan forberede én transaktion i ret lang tid (jeg taler om forskellige merkle-beviser, succinct proofs, threshold-signaturer og andre komplekse operationer på klientsiden). Et godt eksempel på let on-chain verifikation og tung transaktionsforberedelse på klienten er beviset for medlemskab i en liste baseret på Merkle-træet, her er... artikel.

Husk også, at klientsystemet ikke blot sender transaktioner til blokchainen, men først anmoder om blokchainens tilstand — og denne aktivitet kan påvirke netværksbelastningen og blokchain-noderne. Når du foretager målinger, kan det derfor være fornuftigt at efterligne klientkodens adfærd så fuldstændigt som muligt. Selvom dit blokchain har almindelige letvægtsklienter, der blot sætter en almindelig digital underskrift på en simpel transaktion for overførsel af et aktiv, bliver den mængde beregninger, der skal udføres på klienten, med hvert år større, krypteringsalgoritmerne styrkes, og denne del af behandlingen kan blive til en betydelig flaskehals i fremtiden. Vær derfor opmærksom og lad være med at overse en situation, hvor en transaktion, der varer 3,5 sekunder, bruger 2,5 sekunder på forberedelse og underskrift af transaktionen, og 1,0 sekunder på at sende til netværket og vente på svar. For at vurdere risikoen for denne flaskehals skal du indsamle målinger fra klientmaskiner og ikke kun fra blokchain-noder.

Afsendelse af transaktion og overvågning af dens status

Næste skridt er at sende transaktionen til den valgte blokchain-node og få status for dens accept i transaction poolen. Dette skridt ligner en almindelig databaseforespørgsel; noden skal registrere transaktionen i puljen og begynde at sprede information om den via p2p-netværket. Tilgangen til at vurdere ydeevnen her ligner vurderingen af traditionelle mikrotjenester i Web API, idet selve transaktionerne i blokchains kan opdateres og aktivt ændre status. Generelt kan opdateringen af informationen om en transaktion i nogle blokchains ske flere gange, for eksempel når der er skift mellem forkerne i kæden, eller når BP informerer om deres hensigt om at inkludere transaktionen i en blok. Begrænsninger på størrelsen af denne pulje og antallet af transaktioner i den kan påvirke blokchainens ydeevne. Hvis transaktionspuljen er fyldt til den maksimalt mulige størrelse eller ikke kan rummes i hukommelsen, kan netværkets ydeevne falde dramatisk. Blokchains har ikke centraliserede midler til at beskytte mod strømme af støjende beskeder, og hvis blokchainen understøtter store transaktioner med lave gebyrer, kan det føre til overbelastning af transaktionspuljen — dette er endnu en potentiel flaskehals for ydeevnen.

I blockchain-netværk sender klienten en transaktion til en vilkårlig node, de ønsker, og hash-værdien af transaktionen er som regel kendt for klienten inden afsendelse. Alt, hvad kunden skal gøre, er at opnå forbindelse og derefter vente på, at blockchainet ændrer sin tilstand ved at inkludere deres transaktion. Bemærk, at måling af «tps» kan give vidt forskellige resultater afhængig af måden, man tilslutter sig en node i blockchainet - dette kan være almindelig HTTP RPC eller WebSocket, der gør det muligt at implementere mønsteret «subscribe». I det andet tilfælde får klienten en tidligere meddelelse, og noden bruger færre ressourcer (primært hukommelse og trafik) til at svare om transaktionens tilstand. Så når man måler «tps», er det vigtigt at tage hensyn til, hvordan klienter tilslutter sig noderne. Derfor bør benchmarket for blockchain kunne emulere klienter med både WebSocket og HTTP RPC anmodninger, i forhold, der svarer til reelle netværk, og samtidig ændre karakteren og størrelsen af transaktionerne.

For at vurdere risici for denne flaskehals er det også nødvendigt at indsamle metrics fra klientmaskiner, ikke kun fra blockchain-noder.

Transmission af transaktioner og blokke over p2p-netværk

I blockchain-netværk bruges peer-to-peer (p2p) netværk til at transmitterer transaktioner og blokke mellem deltagerne. Transaktioner spredes i netværket, startet fra en af noderne, indtil de når til peer-block producers, som pakker transaktionerne i blokke og ved hjælp af det samme p2p-netværk spreder de nye blokke til alle noder i netværket. Grundlaget for de fleste moderne p2p-netværk er forskellige modifikationer af Kademlia-protokollen. Her er en god kort oversigt over denne protokol, og her — en artikel med forskellige målinger i BitTorrent-netværket, som gør det muligt at forstå, at denne type netværk er mere kompleks og mindre forudsigelig end et stift konfigureret netværk af en centraliseret tjeneste. Derudover, her en artikel om måling af forskellige interessante metrics for Ethereum-noder.

Kort sagt, hver peer i sådanne netværk understøtter sin egen dynamiske liste over andre peers, som den anmoder om blokke af information adresseret efter indhold. Ved modtagelse af en anmodning leverer peer'en enten den ønskede information eller videresender anmodningen til den næste pseudotilfældige peer fra listen. Når den modtager et svar, sender den det tilbage til den anmodende og gemmer det i et cache i et stykke tid, så den kan levere denne informationsblock hurtigere ved næste anmodning. På denne måde ender populær information i mange caches hos mange peers, mens upopulær information gradvist bliver overskrevet. Peers holder styr på, hvor meget information de har sendt til hinanden, og netværket forsøger at stimulere aktive udbydere ved at hæve deres rating og give dem en højere servicegrad, mens inaktive deltagere automatisk fjernes fra peer- listerne.

Så nu skal transaktionen spredes i netværket, så block-producerne kan se den og inkludere den i en blok. Noden deler aktivt den nye transaktion med interesserede og lytter til netværket, i ventetiden på en blok, hvor den ønskede transaktion vil blive inkluderet, for at kunne underrette den ventende klient. Tiden, mens netværket overfører information om nye transaktioner og blokke i p2p-netværk, afhænger af et meget stort antal faktorer: antallet af ærlige noder, der arbejder tæt på (set fra netværksperspektiv), cachede data fra disse noder, størrelsen på blokke, transaktioner, arten af ændringer, netværkets geografi, antallet af noder og en lang række andre faktorer. Kompleks måling af ydeevne i sådanne netværk er en svær opgave; det er nødvendigt samtidig at vurdere behandlingstiden for anmodninger både for klienterne og for peers (blockchain noderne). Problemer i nogen af p2p-mekanismerne, forkert udstødning og caching af data, ineffektiv håndtering af lister over aktive peers, samt mange andre faktorer kan skabe forsinkelser, der påvirker effektiviteten af hele netværket som helhed, og denne flaskehals er den sværeste at analysere, teste og fortolke resultaterne af.

Behandling af blockchain kæden og opdatering af state database

Den vigtigste del af blockchainens funktion er konsensusalgoritmen, dens anvendelse på nye blokke opnået fra netværket, og behandlingen af transaktioner med registrering af resultater i state-databasen. Tilsætningen af en ny blok til kæden og den efterfølgende valg af hovedkæden skal fungere så hurtigt som muligt. Men i virkeligheden betyder "skal" ikke altid "funker"; man kan for eksempel forestille sig en situation, hvor to lange konkurrerende kæder konstant skifter imellem hinanden, ændrer metadata for tusindvis af transaktioner i puljen ved hvert skift, og forårsager konstant tilbageslag i state-databasen. Denne fase er, når det kommer til at identificere flaskehalse, lettere end det netværksmæssige p2p-lag, da udførelsen af transaktioner og konsensusalgoritmen er strengt deterministiske, og det er lettere at måle noget her.
Det er vigtigt ikke at forveksle tilfældig degradering af ydeevnen i denne fase med netværksproblemer — noderne afleverer langsommere blokke og information om hovedkæden, og for en ekstern klient kan det se ud som et langsomt netværk, selvom problemet ligger et helt andet sted.

For at optimere ydeevnen på dette trin er det nyttigt at indsamle og overvåge metrikker fra selve noderne og inkludere dem, der vedrører opdateringen af state-databasen: antallet af blokke, der behandles på noden, deres størrelse, antallet af transaktioner, antal skift mellem kædeforkene, antallet af ugyldige blokke, tiden for den virtuelle maskine, tidsrammen for datalagring osv. Dette vil hjælpe med ikke at forveksle netværksproblemer med fejl i algoritmerne til behandling af kæder.

Den virtuelle maskine, der behandler transaktioner, kan være en nyttig informationskilde, der kan optimere blockchainens funktion. Antallet af hukommelsesallokeringer, antallet af read/write-instruktioner og andre metrikker vedrørende effektiviteten af koden for kontrakter kan give meget nyttig information til udviklere. Samtidig er smarte kontrakter programmer, og derfor kan de i teorien forbruge enhver form for ressourcer: cpu/memory/network/storage, så behandlingen af transaktioner er et ret usikkert trin, der desuden ændrer sig betydeligt ved overgangen mellem versioner og ved ændringer af kontraktkoden. Derfor er metrikker, der vedrører behandling af transaktioner, også nødvendige for effektiv optimering af blockchainens ydeevne.

Modtagelse af meddelelse til kunden om aktivering af transaktionen i blockchainen

Dette er den afsluttende fase af at modtage blockchain-service som kunde; sammenlignet med andre faser er der ikke store omkostninger her, men det er stadig vigtigt at tage højde for muligheden for, at kunden modtager et omfattende svar fra noden (for eksempel et smart kontrakt, der returnerer et array af data). Under alle omstændigheder er dette øjeblik det vigtigste for dem, der stiller spørgsmålet "hvor mange tps har jeres blockchain?", da det er her, tiden for modtagelse af service registreres.

Her skal der nødvendigvis sendes den samlede tid, som kunden har brugt på at vente på svar fra blockchainen; det er denne tid, brugeren vil forvente at få bekræftet i sin applikation, og optimeringen af denne tid er hovedopgaven for udviklerne.

Konklusion

Som et resultat kan man beskrive typerne af operationer, der udføres i blockchainer, og opdele dem i flere kategorier:

kryptografiske transformationer, opbygning af beviser
peer-to-peer netværk, replikation af transaktioner og blokke
behandling af transaktioner, udførelse af smart kontrakter
anvendelse af ændringer i blockchainen på state database, opdatering af data om transaktioner og blokke
read-only forespørgsler til state database, API for blockchain noden, abonnementsservicer

Generelt er de tekniske krav til noderne i moderne blockchains meget strenge—hurtige CPU'er til kryptografi, store mængder RAM for at gemme og hurtigt tilgå state database, netværksinteraktion der bruger et stort antal åbne forbindelser samtidig, og plads til stor lagring. Disse høje krav og den mangfoldighed af forskellige operationstyper fører uundgåeligt til, at ressourcerne hos noderne kan være utilstrækkelige, og så kan ethvert af de ovenfor nævnte trin blive en flaskehals for den samlede ydeevne i netværket.

Når du udvikler og vurderer ydeevnen af blockchains, skal du tage alle disse aspekter i betragtning. For at gøre dette skal du indsamle og analysere metrikker fra både klienterne og netværkets noder, lede efter korrelationer mellem dem, vurdere tiden til service og tage højde for alle de væsentlige ressourcer: cpu/memory/network/storage, samt forstå, hvordan de bruges og påvirker hinanden. Alt dette gør det ekstremt udfordrende at sammenligne hastighederne af forskellige blockchains i form af "hvor mange TPS", da der findes et væld af forskellige konfigurationer og tilstande. I store centraliserede systemer, klynger af hundreder af servere, er disse problemer også komplekse og kræver indsamling af et stort antal forskellige metrikker, men i blockchains, på grund af p2p-netværk, virtuelle maskiner, der behandler kontrakter, og intern økonomi, er antallet af frihedsgrader meget større, hvilket gør test på selv blot få servere uvist og kun giver meget omtrentlige værdier, som næsten ikke har forbindelse til virkeligheden.

Derfor, når vi udvikler i blockchain-kernen, bruger vi ret kompleks software til at vurdere ydeevnen og svare på spørgsmålet "er det forbedret i forhold til sidst?". Denne software orkestrerer opstarten af blockchain med dusinvis af noder og automatisk opstart af benchmarks og indsamling af metrikker. Uden disse oplysninger er det ekstremt svært at debugge protokoller, der arbejder med mange deltagere.

Så når du får spørgsmålet "hvor mange TPS er der i din blockchain?", så tilbyd din samtalepartner en kop te og undersøg, om de er villige til at kigge på et dusin grafer samt høre om alle de problemer, der findes ved blockchain-ydeevne og dine forslag til løsninger...

Kilde: habr.com