ProHoster > Blogg > Administrasjon > Hvor mange TPS har blockchain din?

Hvor mange TPS har blockchain din?

Det mest stilte spĂžrsmĂ„let fra ikke-tekniske spesialister om ethvert distribuert system er "Hvor mange tps har blokkjeden deres?". Men tallet som blir gitt som svar, har vanligvis lite Ă„ gjĂžre med det spĂžrsmĂ„let de Ăžnsket Ă„ stille. I realiteten Ăžnsket de Ă„ spĂžrre "passer blokkjeden deres til mine forretningsbehov?", og disse behovene er ikke ett tall, men en rekke betingelser – her er bĂ„de nettverksrobusthet, krav til endelighet, stĂžrrelser, karakteren av transaksjonene og mange andre parametere. SĂ„ svaret pĂ„ spĂžrsmĂ„let "hvor mange tps" vil sjelden vĂŠre enkelt, og nesten aldri vĂŠre komplett. Et distribuert system med titalls og hundretalls noder som utfĂžrer ganske komplekse beregninger, kan befinne seg i en enorm mengde forskjellige tilstander, knyttet til nettverkstilstanden, innholdet i blokkjeden, tekniske feil, Ăžkonomiske problemer, angrep pĂ„ nettverket og mange andre Ă„rsaker. Faser der ytelsesproblemer kan oppstĂ„ er forskjellige fra tradisjonelle tjenester, og serveren til blokkjedenettverket er en nettjeneste som kombinerer funksjonaliteten til en database, web-server og torrent-klient, noe som gjĂžr den ekstremt komplisert med hensyn til belastningsprofil pĂ„ alle undersystemer: prosessor, minne, nettverk, lagring.

Det har vist seg at desentraliserte nettverk og blokkjeder er ganske spesifikke og uvante programmer for utviklere av sentralisert programvare. Derfor Þnsker jeg Ä belyse viktige aspekter ved ytelse og robusthet i desentraliserte nettverk, tilnÊrminger til deres mÄling og identifisering av flaskehalser. Vi vil se pÄ ulike ytelsesproblemer som begrenser hastigheten pÄ tjenesteleveransen til brukerne av blokkjeder, og merke oss de sÊrtrekkene som er typiske for denne typen programvare.

Faser i forespĂžrselen om tjeneste fra blokkjeden av kunden.

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

To identify such bottlenecks, it's crucial to understand the stages where a real blockchain might face difficulties in servicing users. Let's describe the cycle of delivery and processing of a transaction, as well as how to obtain the new state of the blockchain from which the client can ensure that their transaction has been processed and accounted for.

  1. the transaction is formed on the client
  2. the transaction is signed on the client
  3. the client selects one of the nodes and sends their transaction to it
  4. the client subscribes to updates from the state database node, waiting for the results of their transaction execution
  5. the node propagates the transaction through the p2p network
  6. one or several BPs (block producers) process the accumulated transactions, updating the state database
  7. the BP forms a new block after processing the required number of transactions
  8. the BP propagates the new block through the p2p network
  9. the new block is delivered to the node that the client is addressing
  10. the node updates the state database
  11. the node sees the update concerning the client and sends them a notification about the transaction

La oss nĂ„ gĂ„ nĂŠrmere inn pĂ„ disse trinnene og beskrive potensielle ytelsesproblemer i hvert trinn. I motsetning til sentraliserte systemer vil vi ogsĂ„ se pĂ„ utfĂžrelsen av koden pĂ„ klientene i nettverket. Det er ganske vanlig at nĂ„r tps mĂ„les, samles behandlingstiden for transaksjoner fra noder, ikke fra klienten — dette er ikke helt rettferdig. Klienten bryr seg ikke om hvor raskt noden har prosessert transaksjonen sin; det viktigste for dem er Ăžyeblikket nĂ„r pĂ„litelig informasjon om denne transaksjonen, som er inkludert i blokkjeden, blir tilgjengelig for dem. Denne metrikken er i hovedsak tiden det tar Ă„ utfĂžre en transaksjon. Dette betyr at forskjellige klienter, selv om de sender den samme transaksjonen, kan fĂ„ helt forskjellige tider, avhengig av kanalen, belastning og avstand til noden, osv. Derfor er det helt nĂždvendig Ă„ mĂ„le denne tiden pĂ„ klientene, fordi det er denne parameteren som mĂ„ optimaliseres.

Forberedelse av transaksjonen pÄ klientsiden

Vi begynner med de fÞrste to punktene: transaksjonen blir dannet og signert av klienten. Merkelig nok kan dette ogsÄ vÊre et flaskehalser for ytelsen til blokkjeden sett fra klientens perspektiv. Dette er uvanlig for sentraliserte tjenester, som tar seg av alle beregninger og databehandling, mens klienten bare lager en kort forespÞrsel som kan be om store datamengder eller beregninger, og fÄr et klart resultat. I blokkjeder blir klientkoden stadig mer og mer kraftig, mens blokkjernene blir lettere, og store beregningsoppgaver overfÞres ofte til klientprogramvaren. I blokkjeder finnes det klienter som kan bruke lang tid pÄ Ä forberede én transaksjon (jeg snakker om ulike merkle-prover, kortfattede prover, threshold-signaturer og andre komplekse operasjoner pÄ klientsiden). Et godt eksempel pÄ lett on-chain verifisering og tung forberedelse av transaksjonen pÄ klienten er bevis pÄ tilhÞrighet til en liste basert pÄ Merkle-tre, her. article.

Det er ogsĂ„ viktig Ă„ huske at klientkoden ikke bare sender transaksjoner til blokkjeden, men fĂžrst ber om tilstanden til blokkjeden — og denne aktiviteten kan pĂ„virke belastningen pĂ„ nettverket og blokkjedenoder. SĂ„ nĂ„r du tar mĂ„linger, vil det vĂŠre fornuftig Ă„ emulere klientkoden sĂ„ nĂžyaktig som mulig. Selv om det i blokkjeden din er vanlige lette klienter som setter en enkel digital signatur pĂ„ en enkel transaksjon for overfĂžring av et hvilket som helst aktivum, blir det motstridende beregninger pĂ„ klienten stadig mer omfattende hvert Ă„r, kryptografiske algoritmer blir mer robuste, og denne delen av prosesseringen kan bli en betydelig flaskehals i fremtiden. VĂŠr derfor forsiktig, og ikke oversett situasjonen der, i en transaksjon som varer i 3,5 sekunder, gĂ„r 2,5 sekunder til forberedelse og signering av transaksjonen, og 1,0 sekunder til sending til nettverket og venting pĂ„ svar. For Ă„ vurdere risikoen for at denne flaskehalsen kan oppstĂ„, bĂžr metrikkene samles inn fra klientmaskiner, ikke bare fra blokkjedenoder.

Sende transaksjon og overvÄke dens status

Neste steg er Ă„ sende transaksjonen til den valgte blokkjedenoden og motta status for aksept i transaksjonspoolen. Dette trinnet ligner pĂ„ en vanlig databaseforespĂžrsel; noden mĂ„ registrere transaksjonen i poolen og begynne Ă„ spre informasjon om den gjennom p2p-nettverket. TilnĂŠrmingen til ytelsesevaluering her ligner pĂ„ evalueringen av tradisjonelle mikrotjenester i Web API, ettersom selve transaksjonene i blokkjeder kan oppdateres og aktivt endre status. Generelt kan oppdateringen av informasjonen om transaksjonen i enkelte blokkjeder skje flere ganger, for eksempel ved skifting mellom forker av kjeden eller nĂ„r BP varsler om hensikten om Ă„ inkludere transaksjonen i en blokk. Begrensninger i volumet av denne poolen og antall transaksjoner i den kan pĂ„virke ytelsen til blokkjeden. Hvis transaksjonspoolen er fullstappet til maksimal stĂžrrelse, eller ikke fĂ„r plass i det tilgjengelige minnet — kan nettverksytelsen falle dramatisk. Blokkjeder har ikke sentraliserte beskyttelsesmetoder mot strĂžmmen av sĂžppelmeldinger, og hvis blokkjeden stĂžtter transaksjoner med stort volum og lave gebyrer, kan det fĂžre til overfylling av transaksjonspoolen — dette er enda en potensiell flaskehals for ytelse.

I blokkjedene sender kunden en transaksjon til hvilken som helst node i blokkjedet han Þnsker. Hashen av transaksjonen er vanligvis kjent for kunden allerede fÞr sending, sÄ alt han trenger Ä gjÞre er Ä oppnÄ forbindelse og deretter vente pÄ at blokkjedet endrer sin tilstand ved Ä inkludere transaksjonen. Vi merker at mÄling av «tps» kan gi helt forskjellige resultater avhengig av mÄten man kobler til noden i blokkjedet. Dette kan vÊre vanlig HTTP RPC eller WebSocket, som gjÞr det mulig Ä implementere et «subscribe»-mÞnster. I det andre tilfellet vil kunden motta et varsel tidligere, og noden vil bruke fÊrre ressurser (hovedsakelig minne og trafikk) for Ä svare om tilstanden til transaksjonen. Ved mÄling av «tps» mÄ derfor mÄten kunder kobler til nodene, tas i betraktning. For Ä vurdere risikoen for at denne flaskehalsen oppstÄr, mÄ blokkjede-benchmarken kunne emulere kunder med bÄde WebSocket- og HTTP RPC-forespÞrsel, i proporsjoner som samsvarer med ekte nettverk, samt variere typen transaksjoner og deres stÞrrelse.

For Ä vurdere risikoen for at denne flaskehalsen oppstÄr, er det ogsÄ nÞdvendig Ä samle inn data fra kundemaskiner, ikke bare fra blokkjedene.

OverfĂžring av transaksjoner og blokker via p2p-nettverk

I blokkjedene brukes peer-to-peer (p2p) nettverking for Ă„ overfĂžre transaksjoner og blokker mellom deltakerne. Transaksjoner sprer seg i nettverket, begynner fra en av nodene, til de nĂ„r peerene-block producerne, som pakker transaksjonene inn i blokker og bruker den samme p2p-teknologien til Ă„ spre de nye blokkene til alle nodene i nettverket. Grunnlaget for de fleste moderne p2p-nettverk er ulike modifikasjoner av Kademlia-protokollen. Her er en god kort oversikt over denne protokollen, og her — en artikkel med ulike mĂ„linger i BitTorrent-nettverket, som kan hjelpe til med Ă„ forstĂ„ at denne typen nettverk er mer kompleks og mindre forutsigbar enn en stivt konfigurert nettverk av en sentralisert tjeneste. OgsĂ„, her en artikkel om mĂ„ling av ulike interessante metrikker for Ethereum-noder.

Kort sagt, hver peer i slike nettverk opprettholder sin egen dynamiske liste over andre peer-er, hvor den forespÞr informasjon om blokker adressert etter innhold. NÄr en forespÞrsel mottas, gir peer-en enten den nÞdvendige informasjonen, eller den videresender forespÞrselen til en tilfeldig valgt peer fra listen. NÄr den fÄr et svar, videresender den det til den som spurte og cacher informasjonen en stund, slik at denne blokken kan leveres raskere neste gang. Dermed ender populÊr informasjon opp i mange cacher hos et stort antall peer-er, mens upopulÊr informasjon gradvis blir presset ut. Peer-er holder oversikt over hvem som har sendt hva til hvem, og nettverket prÞver Ä stimulere aktive delere ved Ä heve rangeringen deres og gi dem et hÞyere servicenivÄ, mens det automatisk fjerner inaktive deltakere fra peer-listene.

SÄ nÄ mÄ transaksjonen spres over nettverket slik at block-produsenter kan se den og inkludere den i en blokk. Nodene «deler» den nye transaksjonen aktivt med alle interesserte og lytter til nettverket, venter pÄ en blokk der den nÞdvendige transaksjonen vil dukke opp, for Ä varsle den ventende klienten. Tiden det tar for nettverket Ä utveksle informasjon om nye transaksjoner og blokker i p2p-nettverk avhenger av et stort antall faktorer: antallet Êrlige, fungerende noder i nÊrheten (sett fra et nettverksperspektiv), hvor «varme» cachene pÄ disse nodene er, stÞrrelsen pÄ blokkene, transaksjonene, karakteren av endringene, nettverkets geografi, antall noder, og mange flere faktorer. Kompleks mÄling av ytelsesmÄlinger i slike nettverk er en kompleks oppgave, det er nÞdvendig Ä vurdere behandlingstiden for forespÞrslene bÄde pÄ klientene og pÄ peer-ene (blockchain-nodene) samtidig. Problemer i noen av p2p-mekanismene, feilaktig utvisning og caching av data, ineffektiv hÄndtering av aktiverte peer-lister, og mange andre faktorer kan forÄrsake forsinkelser som pÄvirker effektiviteten til hele nettverket, og denne flaskehalsen er den vanskeligste Ä analysere, teste og tolke resultatene av.

Prosesseringen av blokkekjeden og oppdatering av state-databasen.

Den viktigste delen av blockchain-arbeidet er konsensus-algoritmen, dets anvendelse pÄ nye blokker mottatt fra nettverket og prosesseringen av transaksjoner med registrering av resultater i statusdatabasen. Legg til en ny blokk i kjeden, og den pÄfÞlgende valg av hovedkjeden mÄ skje sÄ raskt som mulig. Imidlertid betyr ikke "mÄ" i det virkelige liv "fungerer", og man kan for eksempel forestille seg en situasjon hvor to lange konkurrerende kjeder konstant veksler mellom hverandre, og endrer metadataene til tusenvis av transaksjoner i puljen ved hver veksling, og gjÞr konstante tilbakestillinger av statusdatabasen. Dette stadiet, nÄr det gjelder Ä definere flaskehalser, er enklere enn det nettverksmessige p2p-laget, ettersom utfÞrelsen av transaksjoner og konsensus-algoritmen er strengt deterministiske, og Ä mÄle noe her er enklere.
Det viktigste er Ă„ ikke forveksle tilfeldig nedgang i ytelsen pĂ„ dette stadiet med nettverksproblemer — nodene gir tregere blokker og informasjon om hovedkjeden, og for en ekstern klient kan dette fremstĂ„ som et sakte nett, selv om problemet ligger helt andre steder.

For Ä optimalisere ytelsen pÄ dette stadiet er det nyttig Ä samle og overvÄke metrikk fra selve nodene, og inkludere de som gjelder oppdateringen av statusdatabasen: antall blokker behandlet pÄ noden, deres stÞrrelse, antall transaksjoner, antall vekslinger mellom forgreiningene av kjeden, antall ugyldige blokker, tid brukt av den virtuelle maskinen, tid for datalagring osv. Dette vil hjelpe med Ä ikke forveksle nettverksproblemer med feil i algoritmene for kjedeprosessering.

Den prosesserende transaksjonsmaskinen kan vÊre en nyttig informasjonskilde for Ä optimere arbeidet med blockchain. Antall minnetildelinger, antall read/write-instruksjoner og andre metrikker knyttet til effektiviteten av gjennomfÞringen av kontraktkode kan gi mye nyttig informasjon for utviklere. Samtidig er smarte kontrakter programmer, og dermed kan de teoretisk bruke enhver type ressurser: cpu/memory/network/storage, sÄ transaksjonsprosesseringen er et ganske ubestemt stadium, som forÞvrig endres mye nÄr man gÄr mellom versjoner og ved endringer i kontraktkoden. Derfor er metrikker relatert til transaksjonsprosessering ogsÄ nÞdvendige for effektiv optimalisering av ytelsen til blockchain.

Mottak av varsel fra kunden om aktivering av transaksjon i blokkjeden

Dette er den avsluttende fasen av Ä motta blokkjede-tjenesten fra kunden. Sammenlignet med andre faser er det her ikke store overhead-kostnader, men man bÞr uansett ta hÞyde for muligheten av Ä motta et stort svar fra noden (for eksempel et smartkontrakt som returnerer en datamatrise). Uansett er dette Þyeblikket det mest kritiske for den som stiller spÞrsmÄlet «hvor mange tps har blokkjeden deres?», siden det er dette tidspunktet hvor tid for mottak av tjenesten registreres.

PÄ dette stadiet er det viktig at den totale tiden kunden har brukt pÄ Ä vente pÄ svaret fra blokkjeden blir sendt. Det er denne tiden brukeren vil forvente Ä fÄ bekreftet i applikasjonen sin, og det Ä optimalisere denne tiden er hovedoppgaven for utviklerne.

Konklusjon

Som et resultat kan man beskrive typene operasjoner som utfĂžres i blokkjeder og dele dem inn i flere kategorier:

  1. kryptografiske transformasjoner, oppbygging av bevis
  2. peer-to-peer-nettverk, replikering av transaksjoner og blokker
  3. behandling av transaksjoner, utfĂžrelse av smartkontrakter
  4. anvendelse av endringer i blokkjeden til state database, oppdatering av data om transaksjoner og blokker
  5. read-only forespĂžrsel til state database, API fra blokkjede-noden, abonnementstjenester

Generelt er de tekniske kravene til nodene i moderne blokkjeder ekstremt strenge — det kreves raske CPU-er for kryptografi, stor mengde RAM slik at man kan lagre og raskt fĂ„ tilgang til state database, nettverksinteraksjon som benytter mange samtidig Ă„pne forbindelser, og betydelig lagring. Disse hĂžye kravene og en overflod av forskjellige typer operasjoner fĂžrer uunngĂ„elig til at nodene kan mangle ressurser, og da kan enhver av de vurderte trinnene bli en flaskehals for den samlede ytelsen i nettverket.

NÄr du utvikler og vurderer ytelsen til blokkjeder, mÄ du ta hensyn til alle disse faktorene. For dette mÄ du samle og analysere mÄlinger fra bÄde kunder og nodene i nettverket, se etter korrelasjoner mellom dem, vurdere tiden det tar Ä levere tjenester til kundene, samt ta hensyn til alle de viktigste ressursene: cpu/minne/nettverk/lagring, og forstÄ hvordan de brukes og pÄvirker hverandre. Alt dette gjÞr sammenligningen av hastigheter mellom ulike blokkjeder, med spÞrsmÄlet om «hvor mange TPS», ekstremt vanskelig, da det finnes en rekke forskjellige konfigurasjoner og tilstander. I store sentraliserte systemer, klynger av hundrevis av servere, er disse problemene ogsÄ komplekse og krever ogsÄ innsamling av mange ulike mÄlinger, men i blokkjeder, pÄ grunn av p2p-nettverk, virtuelle maskiner, kontrakter i prosess, og intern Þkonomi, er antallet frihetsgrader mye stÞrre, noe som gjÞr tester selv pÄ flere servere lite representative, og gir bare meget estimative verdier, nesten uten forbindelse til virkeligheten.

Derfor, ved utvikling i kjerne av blokkjeden, for Ä vurdere ytelsen og svare pÄ spÞrsmÄlet «har det forbedret seg sammenlignet med forrige gang», bruker vi ganske kompleks programvare som orkestrerer oppstart av blokkjeden med titalls noder og automatisk starter benchmark og samler mÄlinger. Uten denne informasjonen er det ekstremt vanskelig Ä feilsÞke protokollene som fungerer med mange deltakere.

SÄ nÄr du fÄr spÞrsmÄlet «hvor mange TPS er det i blokkjeden din?», tilby samtalepartneren te og spÞr om han er klar til Ä se pÄ titalls grafer, samt hÞre om de tre kasser med ytelsesproblemer i blokkjeder og dine forslag til hvordan de kan lÞses...

Kilde: habr.com

KjĂžp pĂ„litelig hosting for nettsteder med DDoS-beskyttelse, VPS VDS-servere đŸ”„ KjĂžp pĂ„litelig hosting for nettsteder med DDoS-beskyttelse, VPS VDS-servere | ProHoster