Et favoritspørgsmål om ethvert distribueret system fra en ikke-teknisk person er "Hvor mange tps er der på din blockchain?" Det tal, der gives som svar, har dog normalt ikke meget til fælles med det, spørgeren gerne vil høre. Faktisk ville han spørge "vil din blockchain passe til mine forretningskrav", og disse krav er ikke ét tal, men mange betingelser - her er netværksfejltolerance, endelighedskrav, størrelser, transaktionernes art og mange andre parametre. Så svaret på spørgsmålet "hvor mange tps" er usandsynligt simpelt og næsten aldrig fuldstændigt. Et distribueret system med snesevis eller hundredvis af noder, der udfører ret komplekse beregninger, kan være i et stort antal forskellige tilstande relateret til netværkets tilstand, indholdet af blockchain, tekniske fejl, økonomiske problemer, angreb på netværket og mange andre årsager . Stadierne, hvor ydelsesproblemer er mulige, adskiller sig fra traditionelle tjenester, og en blockchain-netværksserver er en netværkstjeneste, der kombinerer funktionaliteten af en database, webserver og torrentklient, hvilket gør den ekstremt kompleks med hensyn til belastningsprofilen på alle undersystemer : processor, hukommelse, netværk, lager

Det sker sådan, at decentraliserede netværk og blockchains er ret specifik og usædvanlig software for centraliserede softwareudviklere. Derfor vil jeg gerne fremhæve vigtige aspekter af decentraliserede netværks ydeevne og bæredygtighed, tilgange til at måle dem og finde flaskehalse. Vi vil se på forskellige præstationsproblemer, der begrænser hastigheden af at levere tjenester til blockchain-brugere, og bemærke de karakteristiske egenskaber for denne type software.

Stadier af en serviceanmodning fra en blockchain-klient

For at kunne tale ærligt om kvaliteten af enhver mere eller mindre kompleks service, skal du ikke kun tage højde for gennemsnitsværdier, men også maksimum/minimum, medianer, percentiler. Teoretisk kan vi tale om 1000 tps i nogle blockchain, men hvis 900 transaktioner blev gennemført med enorm hastighed, og 100 sad "fast" i et par sekunder, så er den gennemsnitlige tid indsamlet over alle transaktioner ikke en helt retfærdig metrik for en klient som jeg ikke kunne gennemføre transaktionen på få sekunder. Midlertidige "huller" forårsaget af manglende konsensusrunder eller netværksopdelinger kan i høj grad ødelægge en tjeneste, der har vist fremragende ydeevne på testbænke.

For at identificere sådanne flaskehalse er det nødvendigt at have en god forståelse for de stadier, hvor en rigtig blockchain kan have svært ved at betjene brugerne. Lad os beskrive cyklussen med levering og behandling af en transaktion, samt opnåelse af en ny tilstand af blockchain, hvorfra kunden kan verificere, at hans transaktion er blevet behandlet og redegjort for.

transaktionen er dannet på klienten
transaktionen er underskrevet på klienten
klienten vælger en af noderne og sender sin transaktion til den
klienten abonnerer på opdateringer til nodens tilstandsdatabase og venter på, at resultaterne af dens transaktion vises
noden distribuerer transaktionen over p2p-netværket
flere eller en BP (blokproducent) behandler akkumulerede transaktioner og opdaterer statsdatabasen
BP danner en ny blok efter at have behandlet det nødvendige antal transaktioner
BP distribuerer en ny blok over p2p-netværket
den nye blok leveres til den node, som klienten har adgang til
node opdaterer tilstandsdatabase
noden ser opdateringen vedrørende klienten og sender ham en transaktionsmeddelelse

Lad os nu se nærmere på disse stadier og beskrive de potentielle præstationsproblemer på hvert stadie. I modsætning til centraliserede systemer vil vi også overveje kodeudførelse på netværksklienter. Ganske ofte, når man måler TPS, indsamles transaktionsbehandlingstiden fra noderne og ikke fra klienten - det er ikke helt fair. Klienten er ligeglad med, hvor hurtigt noden behandlede sin transaktion; det vigtigste for ham er det øjeblik, hvor pålidelig information om denne transaktion inkluderet i blockchain bliver tilgængelig for ham. Det er denne metrik, der i det væsentlige er transaktionsudførelsestiden. Det betyder, at forskellige klienter, selv der sender den samme transaktion, kan modtage helt forskellige tidspunkter, som afhænger af kanalen, belastningen og nærheden af noden osv. Så det er absolut nødvendigt at måle denne tid på klienter, da det er den parameter, der skal optimeres.

Forberedelse af en transaktion på kundesiden

Lad os starte med de to første punkter: transaktionen er dannet og underskrevet af kunden. Mærkeligt nok kan dette også være en flaskehals for blockchain-ydelse fra kundens synspunkt. Dette er usædvanligt for centraliserede tjenester, som overtager alle beregninger og operationer med data, og klienten udarbejder blot en kort anmodning, der kan anmode om en stor mængde data eller beregninger, hvilket giver et færdigt resultat. I blockchains bliver klientkoden mere og mere kraftfuld, og blockchain-kernen bliver mere og mere letvægts, og massive computeropgaver overføres normalt til klientsoftwaren. I blockchains er der kunder, der kan forberede en transaktion i ret lang tid (jeg taler om forskellige merkle-beviser, kortfattede beviser, tærskelsignaturer og andre komplekse operationer på klientsiden). Et godt eksempel på nem on-chain verifikation og tung forberedelse af en transaktion på klienten er bevis på medlemskab i en liste baseret på Merkle-tree, her artiklen.

Glem heller ikke, at klientkoden ikke blot sender transaktioner til blockchain, men først forespørger på tilstanden af blockchain - og denne aktivitet kan påvirke overbelastningen af netværket og blockchain-noder. Så når der foretages målinger, ville det være rimeligt at efterligne klientkodens adfærd så fuldstændigt som muligt. Selvom der i din blockchain er almindelige light-klienter, der sætter en almindelig digital signatur på den enkleste transaktion for at overføre et aktiv, er der hvert år stadig mere massive beregninger på klienten, kryptoalgoritmerne bliver stærkere, og denne del af behandlingen kan blive en betydelig flaskehals i fremtiden. Vær derfor forsigtig og gå ikke glip af situationen, når der i en transaktion, der varer 3.5 s, bruges 2.5 s på at forberede og underskrive transaktionen og 1.0 s på at sende den til netværket og vente på svar. For at vurdere risiciene ved denne flaskehals skal du indsamle metrics fra klientmaskiner og ikke kun fra blockchain-noder.

Sender en transaktion og overvåger dens status

Det næste trin er at sende transaktionen til den valgte blockchain-knude og modtage status for at acceptere den i transaktionspuljen. Dette trin ligner en almindelig databaseadgang; noden skal registrere transaktionen i puljen og begynde at distribuere information om den gennem p2p-netværket. Tilgangen til at vurdere ydeevnen her svarer til at vurdere ydeevnen af traditionelle Web API-mikrotjenester, og selve transaktionerne i blockchains kan opdateres og aktivt ændre deres status. Generelt kan opdatering af transaktionsoplysninger på nogle blockchains forekomme flere gange, for eksempel når der skiftes mellem kædegafler, eller når BP'er meddeler, at de har til hensigt at inkludere en transaktion i en blok. Begrænsninger for størrelsen af denne pulje og antallet af transaktioner i den kan påvirke blockchainens ydeevne. Hvis transaktionspuljen er fyldt til den maksimalt mulige størrelse eller ikke passer i RAM, kan netværkets ydeevne falde kraftigt. Blockchains har ingen centraliserede midler til at beskytte mod en strøm af uønskede meddelelser, og hvis blockchain understøtter transaktioner i store mængder og lave gebyrer, kan dette få transaktionspuljen til at løbe over – endnu en potentiel flaskehals i ydeevnen.

I blockchains sender klienten en transaktion til enhver blockchain node, han kan lide, hashen af transaktionen er normalt kendt af klienten før afsendelse, så alt han skal gøre er at opnå forbindelsen og, efter transmission, vente på, at blockchain ændres dets tilstand, hvilket muliggør hans transaktion. Bemærk, at du ved at måle "tps" kan få helt forskellige resultater for forskellige metoder til at forbinde til en blockchain-node. Dette kan være en almindelig HTTP RPC eller en WebSocket, der giver dig mulighed for at implementere "subscribe"-mønsteret. I det andet tilfælde vil klienten modtage en meddelelse tidligere, og noden vil bruge færre ressourcer (hovedsageligt hukommelse og trafik) på svar om transaktionsstatus. Så når man måler "tps" er det nødvendigt at tage højde for den måde, klienter forbinder til noder. Derfor, for at vurdere risiciene ved denne flaskehals, skal benchmark blockchain være i stand til at efterligne klienter med både WebSocket og HTTP RPC anmodninger, i proportioner svarende til rigtige netværk, samt ændre arten af transaktioner og deres størrelse.

For at vurdere risiciene ved denne flaskehals skal du også indsamle metrics fra klientmaskiner og ikke kun fra blockchain-noder.

Transmission af transaktioner og blokeringer via p2p-netværk

I blockchains bruges peer-to-peer (p2p) netværk til at overføre transaktioner og blokeringer mellem deltagere. Transaktioner spredt over hele netværket, startende fra en af noderne, indtil de når peer-blokproducenter, som pakker transaktioner i blokke og ved hjælp af den samme p2p distribuerer nye blokke til alle netværksknuder. Grundlaget for de fleste moderne p2p-netværk er forskellige modifikationer af Kademlia-protokollen. her et godt resumé af denne protokol, og her - en artikel med forskellige målinger i BitTorrent-netværket, hvorfra man kan forstå, at denne type netværk er mere kompleks og mindre forudsigelig end et stift konfigureret netværk af en centraliseret tjeneste. Også, her artikel om måling af forskellige interessante målinger for Ethereum-noder.

Kort sagt vedligeholder hver peer i sådanne netværk sin egen dynamiske liste over andre peers, hvorfra den anmoder om blokke af information, der adresseres af indhold. Når en peer modtager en forespørgsel, giver den enten den nødvendige information eller videregiver anmodningen til den næste pseudo-tilfældige peer fra listen, og efter at have modtaget et svar, sender den den videre til rekvirenten og cacher den i et stykke tid, hvilket giver dette blok af information tidligere næste gang. Populær information ender således i et stort antal caches hos et stort antal peers, og upopulær information bliver gradvist erstattet. Peers registrerer, hvem der har overført hvor meget information til hvem, og netværket forsøger at stimulere aktive distributører ved at øge deres ratings og give dem et højere serviceniveau, hvilket automatisk fortrænger inaktive deltagere fra peer-lister.

Så transaktionen skal nu distribueres over hele netværket, så blokproducenter kan se den og inkludere den i blokken. Noden "distribuerer" aktivt en ny transaktion til alle og lytter til netværket og venter på en blok i indekset, som den påkrævede transaktion vil blive vist for for at underrette den ventende klient. Den tid det tager for netværket at overføre information om nye transaktioner og blokeringer til hinanden i p2p-netværk afhænger af et meget stort antal faktorer: antallet af ærlige noder, der arbejder i nærheden (set fra et netværkssynspunkt), den "varme- op” af cachen på disse noder, størrelsen af blokke, transaktioner, arten af ændringer, netværksgeografi, antal noder og mange andre faktorer. Komplekse målinger af præstationsmålinger i sådanne netværk er en kompleks sag; det er nødvendigt samtidigt at evaluere anmodningsbehandlingstiden på både klienter og peers (blockchain noder). Problemer i enhver af p2p-mekanismerne, forkert dataudsmidning og caching, ineffektiv styring af lister over aktive peers og mange andre faktorer kan forårsage forsinkelser, der påvirker effektiviteten af hele netværket som helhed, og denne flaskehals er den sværeste at analysere , test og fortolkning af resultater.

Blockchain-behandling og opdatering af statens database

Den vigtigste del af blockchain er konsensusalgoritmen, dens anvendelse på nye blokke modtaget fra netværket og behandlingen af transaktioner med registrering af resultaterne i statsdatabasen. Tilføjelse af en ny blok til kæden og derefter valg af hovedkæden skal fungere så hurtigt som muligt. Men i det virkelige liv betyder "bør" ikke "virker", og man kan for eksempel forestille sig en situation, hvor to lange konkurrerende kæder konstant skifter mellem sig og ændrer metadataene for tusindvis af transaktioner i puljen ved hvert skifte , og konstant ruller tilstandsdatabasen tilbage. Denne fase, med hensyn til at definere flaskehalsen, er enklere end p2p-netværkslaget, fordi transaktionsudførelse og konsensusalgoritme er strengt deterministiske, og det er nemmere at måle noget her.
Det vigtigste er ikke at forveksle tilfældig forringelse af ydeevnen på dette trin med netværksproblemer - noder er langsommere til at levere blokke og information om hovedkæden, og for en ekstern klient kan dette ligne et langsomt netværk, selvom problemet ligger i et helt andet sted.

For at optimere ydeevnen på dette stadium er det nyttigt at indsamle og overvåge metrikker fra selve noderne og inkludere dem, der er relateret til opdatering af tilstandsdatabasen: antallet af blokke, der behandles på noden, deres størrelse, antallet af transaktioner, antallet af skift mellem kædegafler, antallet af ugyldige blokke, virtuel maskine driftstid, data commit tid osv. Dette vil forhindre netværksproblemer i at blive forvekslet med fejl i kædebehandlingsalgoritmer.

En virtuel maskine, der behandler transaktioner, kan være en nyttig kilde til information, der kan optimere driften af blockchain. Antallet af hukommelsestildelinger, antallet af læse/skrive-instruktioner og andre målinger relateret til effektiviteten af kontraktkodeudførelse kan give en masse nyttig information til udviklere. Samtidig er smarte kontrakter programmer, hvilket betyder, at de i teorien kan forbruge alle ressourcerne: cpu/hukommelse/netværk/lager, så transaktionsbehandling er et ret usikkert stadie, som derudover ændrer sig meget, når man flytter mellem versioner og ved ændring af kontraktkoder. Derfor er målinger relateret til transaktionsbehandling også nødvendige for effektivt at optimere blockchain-ydelsen.

Kundens modtagelse af en meddelelse om inddragelse af en transaktion i blockchain

Dette er den sidste fase af blockchain-klienten, der modtager tjenesten; sammenlignet med andre faser er der ingen store overheadomkostninger, men det er stadig værd at overveje muligheden for, at klienten modtager et omfangsrigt svar fra noden (for eksempel en smart kontrakt returnere en række data). Under alle omstændigheder er dette punkt det vigtigste for den, der stillede spørgsmålet "hvor mange tps er der i din blockchain?", fordi På dette tidspunkt registreres tidspunktet for modtagelse af tjenesten.

På dette sted er der altid en afsendelse af den fuld tid, som klienten skulle bruge på at vente på et svar fra blockchainen; det er denne gang, at brugeren vil vente på bekræftelse i sin ansøgning, og det er dens optimering, der er udviklernes hovedopgave.

Konklusion

Som et resultat kan vi beskrive de typer operationer, der udføres på blockchains og opdele dem i flere kategorier:

kryptografiske transformationer, beviskonstruktion
peer-to-peer-netværk, transaktions- og blokreplikering
transaktionsbehandling, udførelse af smarte kontrakter
anvende ændringer i blockchain til statsdatabasen, opdatering af data om transaktioner og blokke
skrivebeskyttede anmodninger til statens database, blockchain node API, abonnementstjenester

Generelt er de tekniske krav til moderne blockchain-knudepunkter ekstremt alvorlige - hurtige CPU'er til kryptografi, en stor mængde RAM til at gemme og hurtigt få adgang til statsdatabasen, netværksinteraktion ved hjælp af et stort antal samtidigt åbne forbindelser og stort lager. Sådanne høje krav og overfloden af forskellige typer operationer fører uundgåeligt til det faktum, at noder måske ikke har nok ressourcer, og så kan enhver af de ovenfor diskuterede stadier blive endnu en flaskehals for den overordnede netværksydelse.

Når du designer og evaluerer blockchains ydeevne, skal du tage alle disse punkter i betragtning. For at gøre dette skal du indsamle og analysere metrikker samtidigt fra klienter og netværksknuder, se efter korrelationer mellem dem, estimere den tid, det tager at levere tjenester til klienter, tage højde for alle de vigtigste ressourcer: cpu/hukommelse/netværk/lagring , forstå, hvordan de bruges og påvirke hinanden. Alt dette gør sammenligning af hastighederne af forskellige blockchains i form af "hvor mange TPS" til en yderst utaknemmelig opgave, da der er et stort antal forskellige konfigurationer og tilstande. I store centraliserede systemer, klynger af hundredvis af servere, er disse problemer også komplekse og kræver også indsamling af et stort antal forskellige metrikker, men i blockchains, på grund af p2p-netværk, virtuelle maskiner, der behandler kontrakter, interne økonomier, antallet af grader af frihed er meget større, hvilket gør testen selv på flere servere, den er ikke-vejledende og viser kun ekstremt omtrentlige værdier, der næsten ikke har nogen forbindelse med virkeligheden.

Derfor bruger vi, når vi udvikler i blockchain-kernen, for at evaluere ydeevne og besvare spørgsmålet "er det forbedret i forhold til sidste gang?" ret kompleks software, der orkestrerer lanceringen af en blockchain med snesevis af noder og automatisk lancerer et benchmark og indsamler metrics Uden disse oplysninger er det ekstremt svært at fejlsøge protokoller, der fungerer med flere deltagere.

Så når du modtager spørgsmålet "hvor mange TPS er der i din blockchain?", så giv din samtalepartner noget te og spørg, om han er klar til at se på et dusin grafer og også lytte til alle tre kasser med blockchain-ydeevneproblemer og dine forslag til løse dem...

Kilde: www.habr.com

Hvor mange TPS er der på din blockchain?