En favoritfrĂ„ga om alla distribuerade system frĂ„n en icke-teknisk specialist Ă€r "Hur mĂ„nga tps har din blockchain?" Men det nummer som anges i svaret har vanligtvis lite att göra med vad frĂ„gestĂ€llaren egentligen vill veta. I sjĂ€lva verket ville han frĂ„ga "uppfyller din blockchain mina affĂ€rskrav?", och dessa krav handlar inte om ett enda nummer, utan om flera villkor â inklusive nĂ€tverksresiliens, finalitetskrav, storlekar, karaktĂ€r pĂ„ transaktioner och mĂ„nga andra parametrar. SĂ„ svaret pĂ„ frĂ„gan "hur mĂ„nga tps" Ă€r knappast enkelt, och kommer nĂ€stan aldrig att vara fullstĂ€ndigt. Ett distribuerat system med tiotals och hundratals noder som utför ganska komplexa berĂ€kningar kan befinna sig i en stor mĂ€ngd olika tillstĂ„nd, kopplade till nĂ€tverkets status, blockchainens innehĂ„ll, tekniska fel, ekonomiska problem, attacker pĂ„ nĂ€tverket och mĂ„nga andra orsaker. De steg dĂ€r prestandaproblem kan uppstĂ„ skiljer sig frĂ„n traditionella tjĂ€nster, och servern för blockchain-nĂ€tverket Ă€r en nĂ€tverkstjĂ€nst som kombinerar funktionerna av en databas, webbserver och torrentklient, vilket gör den extremt komplex nĂ€r det kommer till belastningsprofilen pĂ„ alla delsystem: processor, minne, nĂ€tverk, lagring.
Det har visat sig att decentraliserade nÀtverk och blockchains Àr ganska specifik och ovanlig programvara för utvecklare av centraliserad programvara. DÀrför skulle jag vilja belysa viktiga aspekter av prestanda och motstÄndskraft hos decentraliserade nÀtverk, metoder för att mÀta dem och identifiera flaskhalsar. Vi kommer att granska olika prestandaproblem som begrÀnsar hastigheten pÄ tjÀnster som tillhandahÄlls till blockchain-anvÀndare och notera de egenskaper som Àr typiska för denna typ av programvara.
Steg för begÀran av tjÀnst frÄn blockchain-kunden
För att Àrligt kunna tala om kvaliteten pÄ vilken som helst mer eller mindre komplex tjÀnst, mÄste man ta hÀnsyn till inte bara medelvÀrden, utan ocksÄ maximala/minimala vÀrden, medianer och percentiler. Teoretiskt kan man tala om 1000 tps i nÄgon blockchain, men om 900 transaktioner genomfördes med enorm hastighet, medan 100 "hÀngde" i nÄgra sekunder, sÄ Àr det genomsnittliga tiden, som samlats in för alla transaktioner, inte helt rÀttvisande för kunden, som inte kunde avsluta sin affÀr pÄ nÄgra sekunder. Tids "hÄl", orsakade av missade konsensusomgÄngar eller nÀtverksuppdelningar kan starkt försÀmra en tjÀnst som pÄ testbÀnkar visade utmÀrkt prestanda.
För att identifiera sÄdana flaskhalsar Àr det nödvÀndigt att förstÄ vÀl de steg dÀr en verklig blockchain kan uppleva svÄrigheter med att betjÀna anvÀndare. LÄt oss beskriva leveranscykeln och bearbetningsprocessen för transaktionen, samt hur man fÄr det nya tillstÄndet för blockkedjan, som kunden kan försÀkra sig om att hans transaktion har bearbetats och beaktats.
- transaktionen skapas pÄ klienten
- transaktionen signeras pÄ klienten
- klienten vÀljer en av noderna och skickar sin transaktion till den
- klienten prenumererar pÄ uppdateringar av nodens state database och vÀntar pÄ resultaten av sin transaktions genomförande
- noden sprider transaktionen i p2p-nÀtverket
- flera eller en blockproducent (BP) bearbetar de ackumulerade transaktionerna och uppdaterar state database
- BP skapar en ny block efter att ha bearbetat det nödvÀndiga antalet transaktioner
- BP sprider den nya blocken i p2p-nÀtverket
- den nya blocken levereras till noden som klienten kontaktar
- noden uppdaterar state database
- noden ser uppdateringen som berör klienten och skickar en avisering om transaktionen
LĂ„t oss nu gĂ„ igenom dessa steg mer detaljerat och beskriva potentiella prestationsproblem vid varje steg. Till skillnad frĂ„n centraliserade system kommer vi ocksĂ„ att titta pĂ„ kodkörning pĂ„ nĂ€tverksklienter. Ofta, nĂ€r tps mĂ€ts, samlas behandlingstiden för transaktioner in frĂ„n noder, inte frĂ„n klienten â det Ă€r inte helt rĂ€ttvist. Klienten bryr sig inte om hur snabbt noden har behandlat hans transaktion, det viktigaste för honom Ă€r ögonblicket nĂ€r korrekt information om den transaktionen, som inkluderats i blockkedjan, blir tillgĂ€nglig för honom. Den metrik Ă€r egentligen tiden för transaktionens genomförande. Det innebĂ€r att olika klienter, Ă€ven om de skickar samma transaktion, kan fĂ„ helt olika tider, beroende pĂ„ kanalen, belastningen och nodens nĂ€rhet, osv. SĂ„ det Ă€r absolut nödvĂ€ndigt att mĂ€ta denna tid pĂ„ klienterna, eftersom det Ă€r denna parameter som mĂ„ste optimeras.
Föreberedelse av transaktion pÄ klientsidan
Vi börjar med de första tvÄ punkterna: transaktionen skapas och signeras av klienten. Konstigt nog kan det hÀr ocksÄ vara en flaskhals för blockkedjans prestanda sett ur klientens perspektiv. Detta Àr ovanligt för centraliserade tjÀnster som tar hand om alla berÀkningar och databehandlingar, medan klienten bara förbereder en kort begÀran som kan begÀra en stor mÀngd data eller berÀkningar och sedan fÄ det fÀrdiga resultatet. I blockkedjor blir klientkoden allt mer kraftfull medan blockkedje-kÀrnan blir allt mer lÀttviktig, och massiva berÀkningsuppgifter tenderar att överlÀmnas till klientprogramvara. I blockkedjor finns det klienter som kan förbereda en transaktion under lÄng tid (jag talar om olika merkle-bevis, succinct proof, threshold-signaturer och andra komplexa operationer pÄ klientsidan). Ett bra exempel pÄ lÀtt on-chain verifiering och tung transaktionsberedning pÄ klienten Àr beviset för tillhörighet till en lista baserat pÄ Merkle-trÀd, hÀr. .
TĂ€nk ocksĂ„ pĂ„ att klientkoden inte bara skickar transaktioner till blockkedjan, utan först begĂ€r tillstĂ„ndet för blockkedjan â och denna aktivitet kan pĂ„verka nĂ€tverksbelastningen och blockkedjenoderna. DĂ€rför, nĂ€r du genomför mĂ€tningar, Ă€r det klokt att efterlikna klientkodens beteende sĂ„ fullstĂ€ndigt som möjligt. Ăven om din blockkedja har vanliga lĂ€tta klienter som sĂ€tter en vanlig digital signatur pĂ„ en enkel transaktion för överföring av nĂ„got tillgĂ„ng, ökar mĂ€ngden berĂ€kningar pĂ„ klienten med varje Ă„r, kryptovalutaalgoritmerna stĂ€rks, och denna del av processeringen kan bli en betydande flaskhals i framtiden. SĂ„ var försiktig sĂ„ att du inte missar en situation dĂ€r en transaktion, som varar i 3,5 sekunder, har 2,5 sekunder som gĂ„r Ă„t till förberedelse och signering av transaktionen, och 1,0 sekunder för att skicka till nĂ€tverket och vĂ€nta pĂ„ svar. För att bedöma riskerna för att denna flaskhals ska uppstĂ„, behöver du samla in mĂ€tvĂ€rden frĂ„n klientmaskiner, och inte bara frĂ„n blockkedjenoder.
Skicka transaktionen och övervaka dess status
NĂ€sta steg Ă€r att skicka transaktionen till den valda blockkedjenoden och fĂ„ status för dess acceptans i transaktionspoolen. Detta steg liknar ett vanligt databasanrop, noden mĂ„ste skriva transaktionen i poolen och börja sprida information om den genom p2p-nĂ€tverket. TillvĂ€gagĂ„ngssĂ€ttet för att bedöma prestanda hĂ€r liknar bedömningen av traditionella mikrotjĂ€nster i Web API, och sjĂ€lvaste transaktionerna i blockkedjor kan uppdateras och aktivt förĂ€ndra status. Generellt kan uppdateringen av transaktionsinformation i vissa blockkedjor ske flera gĂ„nger, till exempel vid vĂ€xling mellan forkar av kedjan eller nĂ€r BP meddelar sin avsikt att inkludera transaktionen i en block. BegrĂ€nsningar för volymen av denna pool och antalet transaktioner i den kan pĂ„verka blockkedjans prestanda. Om transaktionspoolen Ă€r full till maximalt möjligt storlek, eller inte fĂ„r plats i det interna minnet â kan nĂ€tverkets prestanda falla dramatiskt. Blockkedjor har inte centraliserade skydd mot flöden av skrĂ€ppost, och om blockkedjan stödjer transaktioner med stora volymer och lĂ„ga avgifter, kan detta leda till att transaktionspoolen överfylls â detta Ă€r ytterligare en potentiell flaskhals för prestanda.
I blockchain, skickar klienten en transaktion till vilken nod i blockchain som helst som de föredrar. Hashen av transaktionen Àr vanligtvis kÀnd för klienten redan innan den skickas, sÄ allt som krÀvs Àr att etablera en anslutning och sedan vÀnta pÄ att blockchain Àndrar sitt tillstÄnd genom att inkludera deras transaktion. Det Àr vÀrt att notera att nÀr man mÀter "tps" kan man fÄ helt olika resultat beroende pÄ vilken typ av anslutning till blockchain-noden som anvÀnds. Det kan vara en vanlig HTTP RPC eller WebSocket, vilket möjliggör implementationen av "subscribe"-mönster. I det andra fallet fÄr klienten en notifiering tidigare, och noden kommer att anvÀnda mindre resurser (frÀmst minne och trafik) för att svara pÄ statusen för transaktionen. SÄ nÀr man mÀter "tps" Àr det viktigt att ta hÀnsyn till hur klienterna kopplar upp sig till noderna. DÀrför, för att bedöma risken för att detta bottleneck kan uppstÄ, bör blockchain-benchmarket kunna emulera klienter bÄde med WebSocket och med HTTP RPC-förfrÄgningar i proportioner som motsvarar verkliga nÀtverk, samt variera arten av transaktionerna och deras storlek.
För att bedöma risken för detta bottleneck Àr det ocksÄ viktigt att samla in metrik frÄn klientmaskiner, och inte bara frÄn blockchain-noder.
Ăverföring av transaktioner och block över ett p2p-nĂ€tverk
I blockchain anvÀnds peer-to-peer (p2p) nÀtverk för att överföra transaktioner och block mellan deltagarna. Transaktioner sprids genom nÀtverket, som börjar frÄn en av noderna, tills de nÄr peer-block-producenter som packar in transaktionerna i block och sprider nya block genom hela nÀtverket med samma p2p. Grunden för de flesta moderna p2p-nÀtverk Àr olika modifieringar av Kademlia-protokollet. en bra kort översikt av detta protokoll, samt en artikel med olika mÀtningar inom BitTorrent-nÀtverket, dÀr man kan förstÄ att denna typ av nÀtverk Àr mer komplex och mindre förutsÀgbar Àn ett strikt konfigurerat nÀtverk av en centraliserad tjÀnst. Dessutom, en artikel om mÀtning av olika intressanta metrik för Ethereum-noder.
Sammanfattningsvis har varje peer i sÄdana nÀtverk sin egen dynamiska lista över andra peers, frÄn vilka den begÀr informationsblock som adresseras efter innehÄll. NÀr en begÀran tas emot ger peer antingen den nödvÀndiga informationen eller vidarebefordrar begÀran till en pseudo-slumptals-peer frÄn listan och, efter att ha fÄtt svar, vidarebefordrar den det till den begÀrande och cachar det under en tid, vilket gör att den kan leverera detta informationsblock tidigare nÀsta gÄng. PÄ sÄ sÀtt hamnar populÀr information i mÄnga cachar hos ett stort antal peers, medan mindre populÀr information gradvis trÀngs ut. Peers hÄller reda pÄ vem som har överfört hur mycket information, och nÀtverket försöker stimulera aktiva delare genom att öka deras ranking och ge dem en högre servicenivÄ, samtidigt som det automatiskt trÀnger ut inaktiva deltagare frÄn listorna över peers.
SÄ, nu mÄste transaktionen spridas i nÀtverket sÄ att blockproducenterna ser den och inkluderar den i ett block. Nodens uppgift Àr aktivt att "dela" den nya transaktionen med alla som vill ha den och lyssna pÄ nÀtverket, i avvaktan pÄ ett block dÀr den önskade transaktionen kommer att dyka upp, för att informera den vÀntande kunden. Tiden för nÀtverket att överföra information om nya transaktioner och block i p2p-nÀtverk beror pÄ ett mycket stort antal faktorer: antalet Àrliga noder som arbetar nÀra varandra (ur nÀtverkssynpunkt), hur vÀl cacharna hos dessa noder Àr uppvÀrmda, storleken pÄ block, transaktioner, karaktÀren av förÀndringar, nÀtverksgeografi, antalet noder och mÄnga andra faktorer. Komplexa mÀtningar av prestandametriker i sÄdana nÀtverk Àr komplicerat; det Àr nödvÀndigt att samtidigt bedöma behandlingen av begÀran bÄde pÄ klienterna och pÄ peers (blockchain-noder). Problem i nÄgot av p2p-mekanismerna, felaktig utstötning och cachning av data, ineffektiv hantering av listor över aktiva peers och mÄnga andra faktorer kan orsaka fördröjningar som pÄverkar effektiviteten hos hela nÀtverket och denna flaskhals Àr den svÄraste att analysera, testa och tolka resultaten av.
Bearbetning av blockkedjan och uppdatering av state-databasen
Den mest centrala delen av blockkedjans funktion Àr konsensusalgoritmen, dess tillÀmpning pÄ nya block som erhÄllits frÄn nÀtverket och bearbetningen av transaktioner med registrering av resultaten i state database. TillÀgget av ett nytt block till kedjan och valet av huvudkedjan dÀrefter ska fungera sÄ snabbt som möjligt. Men i verkliga livet betyder "ska" inte nödvÀndigtvis "fungerar", och man kan till exempel förestÀlla sig en situation dÀr tvÄ lÄnga konkurrerande kedjor stÀndigt vÀxlar mellan varandra, vilket Àndrar metadatan för tusentals transaktioner i poolen vid varje vÀxling och orsakar konstanta ÄterstÀllningar av state database. Detta steg Àr, nÀr det gÀller att definiera bottlenecks, enklare Àn det nÀtverksbaserade p2p-laget, eftersom genomförandet av transaktioner och konsensusalgoritmen Àr strikt deterministiska, och det Àr enklare att mÀta nÄgot hÀr.
Det viktigaste Àr att inte förvÀxla tillfÀllig nedgradering av prestanda vid detta steg med nÀtverksproblem - noder överlÀmnar block och information om huvudkedjan mer lÄngsamt och för en extern klient kan detta verka som ett lÄngsamt nÀtverk, Àven om problemet ligger pÄ helt annat stÀlle.
För att optimera prestanda vid detta steg Àr det bra att samla in och övervaka mÀtvÀrden frÄn noderna sjÀlva och inkludera de som rör uppdateringen av state database: antal block som behandlas pÄ noden, deras storlek, antal transaktioner, antal vÀxlingar mellan kedjeforkar, antal ogiltiga block, tiden för virtuella maskinen, tiden för datalagring osv. Detta gör det möjligt att inte förvÀxla nÀtverksproblem med fel i kedjeprocesseringens algoritmer.
Den processande maskinen för transaktioner kan vara en anvÀndbar informationskÀlla som kan optimera blockkedjans funktion. Antalet minnesallokeringar, antalet read/write-instruktioner och andra mÀtvÀrden som rör effektiviteten av kodens exekvering av kontrakt kan ge mycket anvÀndbar information till utvecklarna. Samtidigt Àr smarta kontrakt program, vilket innebÀr att de i teorin kan konsumera alla typer av resurser: cpu/memory/network/storage, sÄ transaktionsprocesseringen Àr en ganska osÀker fas, som dessutom förÀndras kraftigt vid övergÄngar mellan versioner och Àndringar av kontraktskoden. DÀrför behövs Àven mÀtvÀrden rörande transaktionsprocessering för effektiv optimering av blockkedjans prestanda.
Mottagande av kundnotification om aktivering av transaktion i blockkedjan
Detta Àr det avslutande steget i mottagandet av blockkedje-tjÀnsten av kunden. JÀmfört med de andra stegen finns det inte stora kostnader hÀr, men det Àr fortfarande viktigt att ta hÀnsyn till möjligheten att kunden fÄr ett omfattande svar frÄn noden (till exempel ett smart kontrakt som returnerar en datamÀngd). I vilket fall som helst Àr just detta ögonblick det mest avgörande för den som stÀller frÄgan "hur mÄnga tps har ni i er blockkedja?", eftersom det Àr hÀr tjÀnstetiden registreras.
I detta steg mÄste den fulla tiden som kunden har spenderat pÄ att vÀnta pÄ ett svar frÄn blockkedjan meddelas. Det Àr denna tid som anvÀndaren kommer att vÀnta pÄ bekrÀftelse i sin applikation, och dess optimering Àr huvuduppgiften för utvecklarna.
Slutsats
Som ett resultat kan man beskriva typerna av operationer som genomförs i blockkedjor och dela in dem i flera kategorier:
- kryptografiska transformationer, bevisuppbyggnad
- peer-to-peer-nÀtverk, replikering av transaktioner och block
- transaktionsbearbetning, utförande av smarta kontrakt
- tillÀmpning av förÀndringar i blockkedjan mot state-databasen, uppdatering av transaktions- och blockdata
- read-only-förfrÄgningar till state-databasen, API för blockkedjenoden, prenumerationstjÀnster
De tekniska kraven pĂ„ noderna i moderna blockkedjor Ă€r överlag mycket strĂ€nga â det behövs snabba CPU:er för kryptografi, stor mĂ€ngd RAM för att lagra och snabbt komma Ă„t state-databasen, nĂ€tverksinteraktion som anvĂ€nder ett stort antal öppna anslutningar samtidigt, och omfattande lagring. Dessa höga krav och mĂ€ngden olika typer av operationer leder oundvikligen till att resurserna hos noderna kan bli otillrĂ€ckliga, och dĂ„ kan vilket som helst av de ovanstĂ„ende stegen bli en flaskhals för nĂ€tverkets totala prestanda.
NÀr man utvecklar och utvÀrderar prestanda för blockkedjor mÄste man ta hÀnsyn till alla dessa aspekter. Detta krÀver att man samlar in och analyserar mÀtvÀrden frÄn bÄde klienter och noder i nÀtverket, letar efter korrelationer mellan dem, bedömer serviceleveranstid till kunderna och beaktar alla grundlÀggande resurser: cpu/minne/nÀtverk/lagring, samt förstÄr hur de anvÀnds och pÄverkar varandra. Allt detta gör det ytterst utmanande att jÀmföra hastigheten hos olika blockkedjor i termer av 'antal TPS', eftersom det finns en mÀngd olika konfigurationer och tillstÄnd. I stora centraliserade system, kluster med hundratals servrar, Àr dessa problem ocksÄ komplexa och krÀver ocksÄ insamling av ett stort antal olika mÀtvÀrden, men i blockkedjor, pÄ grund av p2p-nÀtverk, virtuella maskiner, kontraktsprogrammering, och intern ekonomi, Àr antalet frihetsgrader mycket större, vilket gör att tester Àven pÄ ett fÄtal servrar blir opÄlitliga och endast visar extremt approximativa vÀrden som nÀstan har inget att göra med verkligheten.
SÄ nÀr vi utvecklar i blockkedjans kÀrna, för att bedöma prestanda och svara pÄ frÄgan 'har det förbÀttrats jÀmfört med förra gÄngen' anvÀnder vi ganska avancerad mjukvara som orkestrerar starten av blockkedjan med dussintals noder samt automatiskt startar prestandatest och samlar in mÀtvÀrden. Utan denna information Àr det extremt svÄrt att felsöka protokoll som arbetar med mÄnga deltagare.
SÄ nÀr du fÄr frÄgan 'Hur mÄnga TPS har din blockkedja?', erbjud din samtalspartner te och frÄga om de Àr beredda att ta del av ett dussin grafer, samt höra alla tre lÄdor av problem kring blockkedjors prestanda och dina förslag till lösningar...
KĂ€lla: habr.com
