En favoritfråga om alla distribuerade system från en icke-teknisk person är "Hur många tps finns på din blockchain?" Siffran som ges som svar har dock vanligtvis lite gemensamt med vad frågeställaren skulle vilja höra. Faktum är att han ville fråga "kommer din blockchain att passa mina affärskrav", och dessa krav är inte ett nummer, utan många villkor - här är nätverksfeltolerans, slutgiltighetskrav, storlekar, transaktioners karaktär och många andra parametrar. Så svaret på frågan "hur många tps" är osannolikt enkelt och nästan aldrig komplett. Ett distribuerat system med tiotals eller hundratals noder som utför ganska komplexa beräkningar kan vara i ett stort antal olika tillstånd relaterade till nätverkets tillstånd, innehållet i blockkedjan, tekniska fel, ekonomiska problem, attacker på nätverket och många andra orsaker . Stadierna där prestandaproblem är möjliga skiljer sig från traditionella tjänster, och en blockchain-nätverksserver är en nätverkstjänst som kombinerar funktionaliteten hos en databas, webbserver och torrentklient, vilket gör den extremt komplex när det gäller belastningsprofilen på alla delsystem : processor, minne, nätverk, lagring

Det råkar vara så att decentraliserade nätverk och blockkedjor är ganska specifika och ovanliga program för centraliserade mjukvaruutvecklare. Därför skulle jag vilja lyfta fram viktiga aspekter av decentraliserade nätverks prestanda och hållbarhet, metoder för att mäta dem och hitta flaskhalsar. Vi kommer att titta på olika prestandaproblem som begränsar hastigheten för att tillhandahålla tjänster till blockchain-användare och notera egenskaperna som är karakteristiska för denna typ av programvara.

Stadier av en tjänsteförfrågan från en blockchain-klient

För att tala ärligt om kvaliteten på någon mer eller mindre komplex tjänst måste du ta hänsyn till inte bara medelvärden, utan även max/minimum, medianer, percentiler. Teoretiskt kan vi prata om 1000 tps i någon blockchain, men om 900 transaktioner genomfördes med enorm hastighet och 100 "fastnade" i några sekunder, så är den genomsnittliga tiden som samlats in över alla transaktioner inte ett helt rättvist mått för en kund som jag inte kunde slutföra transaktionen på några sekunder. Tillfälliga "hål" orsakade av missade konsensusrundor eller nätverksdelningar kan i hög grad förstöra en tjänst som har visat utmärkt prestanda på testbänkar.

För att identifiera sådana flaskhalsar är det nödvändigt att ha en god förståelse för de stadier där en riktig blockkedja kan ha svårt att betjäna användarna. Låt oss beskriva cykeln för att leverera och bearbeta en transaktion, samt att få ett nytt tillstånd för blockkedjan, från vilket kunden kan verifiera att hans transaktion har behandlats och redovisats.

transaktionen bildas på klienten
transaktionen signeras på klienten
klienten väljer en av noderna och skickar sin transaktion till den
klienten prenumererar på uppdateringar av nodens tillståndsdatabasen och väntar på att resultatet av dess transaktion ska visas
noden distribuerar transaktionen över p2p-nätverket
flera eller en BP (block producent) bearbetar ackumulerade transaktioner och uppdaterar den statliga databasen
BP bildar ett nytt block efter att ha bearbetat det erforderliga antalet transaktioner
BP distribuerar ett nytt block över p2p-nätverket
det nya blocket levereras till noden som klienten har åtkomst till
noden uppdaterar tillståndsdatabasen
noden ser uppdateringen om klienten och skickar ett transaktionsmeddelande till honom

Låt oss nu titta närmare på dessa stadier och beskriva de potentiella prestationsproblemen i varje steg. Till skillnad från centraliserade system kommer vi också att överväga kodexekvering på nätverksklienter. Ganska ofta, när man mäter TPS, samlas transaktionsbehandlingstiden från noderna och inte från klienten - detta är inte helt rättvist. Kunden bryr sig inte om hur snabbt noden bearbetade sin transaktion; det viktigaste för honom är ögonblicket när tillförlitlig information om denna transaktion som ingår i blockkedjan blir tillgänglig för honom. Det är detta mått som i huvudsak är transaktionsexekveringstiden. Detta innebär att olika klienter, även som skickar samma transaktion, kan ta emot helt olika tider, vilket beror på kanalen, belastningen och närheten till noden, etc. Så det är absolut nödvändigt att mäta denna tid på klienter, eftersom det är denna parameter som behöver optimeras.

Förbereda en transaktion på kundsidan

Låt oss börja med de två första punkterna: transaktionen bildas och undertecknas av kunden. Konstigt nog kan detta också vara en flaskhals för blockchain-prestanda ur kundens synvinkel. Detta är ovanligt för centraliserade tjänster, som tar över alla beräkningar och operationer med data, och kunden förbereder helt enkelt en kort förfrågan som kan begära en stor mängd data eller beräkningar, vilket ger ett färdigt resultat. I blockkedjor blir klientkoden mer och mer kraftfull och blockkedjekärnan blir mer och mer lättviktig, och massiva datoruppgifter överförs vanligtvis till klientmjukvaran. I blockkedjor finns det kunder som kan förbereda en transaktion under ganska lång tid (jag pratar om olika merkle-bevis, kortfattade bevis, tröskelsignaturer och andra komplexa operationer på klientsidan). Ett bra exempel på enkel verifiering i kedjan och tung förberedelse av en transaktion på klienten är bevis på medlemskap i en lista baserad på Merkle-tree, här artikel.

Glöm inte heller att klientkoden inte bara skickar transaktioner till blockkedjan, utan först frågar blockkedjans tillstånd - och denna aktivitet kan påverka överbelastningen av nätverket och blockkedjenoderna. Så när man gör mätningar skulle det vara rimligt att emulera klientkodens beteende så fullständigt som möjligt. Även om det i din blockchain finns vanliga lätta klienter som sätter en vanlig digital signatur på den enklaste transaktionen för att överföra någon tillgång, varje år görs det fortfarande mer massiva beräkningar på klienten, kryptoalgoritmerna blir starkare, och denna del av bearbetningen kan bli en betydande flaskhals i framtiden. Var därför försiktig och missa inte situationen när, i en transaktion som varar i 3.5 s, 2.5 s spenderas på att förbereda och signera transaktionen och 1.0 s på att skicka den till nätverket och vänta på svar. För att bedöma riskerna med denna flaskhals måste du samla in mätvärden från klientmaskiner, och inte bara från blockkedjenoder.

Skickar en transaktion och övervakar dess status

Nästa steg är att skicka transaktionen till den valda blockkedjenoden och få status för att acceptera den i transaktionspoolen. Detta steg liknar en vanlig databasåtkomst; noden måste registrera transaktionen i poolen och börja distribuera information om den genom p2p-nätverket. Tillvägagångssättet för att bedöma prestanda här liknar att bedöma prestanda för traditionella webb-API-mikrotjänster, och själva transaktionerna i blockkedjor kan uppdateras och aktivt ändra deras status. I allmänhet kan uppdatering av transaktionsinformation på vissa blockkedjor ske flera gånger, till exempel när man byter mellan kedjegafflar eller när BP:er tillkännager sin avsikt att inkludera en transaktion i ett block. Begränsningar för storleken på denna pool och antalet transaktioner i den kan påverka blockkedjans prestanda. Om transaktionspoolen är fylld till största möjliga storlek, eller inte får plats i RAM, kan nätverksprestandan sjunka kraftigt. Blockkedjor har inga centraliserade sätt att skydda sig mot en flod av skräpmeddelanden, och om blockkedjan stöder transaktioner med stora volymer och låga avgifter kan detta få transaktionspoolen att svämma över – en annan potentiell flaskhals i prestanda.

I blockkedjor skickar klienten en transaktion till valfri blockkedjenod han gillar, hashen för transaktionen är vanligtvis känd för klienten innan han skickar, så allt han behöver göra är att uppnå anslutningen och, efter överföring, vänta på att blockkedjan ska ändras dess tillstånd, vilket möjliggör hans transaktion. Observera att genom att mäta "tps" kan du få helt olika resultat för olika metoder för att ansluta till en blockkedjenod. Detta kan vara en vanlig HTTP RPC eller en WebSocket som låter dig implementera "prenumerera" mönstret. I det andra fallet kommer klienten att få ett meddelande tidigare, och noden kommer att spendera mindre resurser (främst minne och trafik) på svar om transaktionsstatus. Så när man mäter "tps" är det nödvändigt att ta hänsyn till hur klienter ansluter till noder. Därför, för att bedöma riskerna med denna flaskhals, måste benchmark-blockkedjan kunna emulera klienter med både WebSocket och HTTP RPC-förfrågningar, i proportioner som motsvarar verkliga nätverk, samt ändra karaktären på transaktioner och deras storlek.

För att bedöma riskerna med denna flaskhals måste du också samla in mätvärden från klientmaskiner, och inte bara från blockkedjenoder.

Överföring av transaktioner och block via p2p-nätverk

I blockkedjor används peer-to-peer (p2p) nätverk för att överföra transaktioner och block mellan deltagare. Transaktioner sprids över hela nätverket, från en av noderna, tills de når peer-blockproducenter, som packar transaktioner i block och med samma p2p distribuerar nya block till alla nätverksnoder. Grunden för de flesta moderna p2p-nätverk är olika modifieringar av Kademlia-protokollet. Här en bra sammanfattning av detta protokoll, och här - en artikel med olika mätningar i BitTorrent-nätverket, av vilken man kan förstå att denna typ av nätverk är mer komplext och mindre förutsägbart än ett stelt konfigurerat nätverk av en centraliserad tjänst. Också, här artikel om att mäta olika intressanta mätvärden för Ethereum-noder.

Kort sagt, varje peer i sådana nätverk upprätthåller sin egen dynamiska lista över andra peers från vilka den begär informationsblock som adresseras av innehåll. När en peer tar emot en förfrågan ger den antingen den nödvändiga informationen eller skickar förfrågan till nästa pseudo-slumpmässiga peer från listan, och efter att ha fått ett svar skickar den vidare den till förfrågaren och cachar den ett tag, vilket ger detta informationsblock tidigare nästa gång. Därmed hamnar populär information i ett stort antal cacher hos ett stort antal kamrater, och impopulär information ersätts successivt. Peers registrerar vem som har överfört hur mycket information till vem, och nätverket försöker stimulera aktiva distributörer genom att öka deras betyg och ge dem en högre servicenivå, vilket automatiskt förskjuter inaktiva deltagare från peer-listor.

Så transaktionen måste nu distribueras över hela nätverket så att blockproducenter kan se den och inkludera den i blocket. Noden "distribuerar" aktivt en ny transaktion till alla och lyssnar på nätverket och väntar på ett block i indexet för vilket den nödvändiga transaktionen kommer att visas för att meddela den väntande klienten. Den tid det tar för nätverket att överföra information om nya transaktioner och block till varandra i p2p-nätverk beror på ett mycket stort antal faktorer: antalet ärliga noder som arbetar i närheten (ur nätverkssynpunkt), den "varma- upp” av cacharna för dessa noder, storleken på blocken, transaktioner, förändringarnas karaktär, nätverksgeografi, antal noder och många andra faktorer. Komplexa mätningar av prestandamått i sådana nätverk är en komplex fråga; det är nödvändigt att samtidigt utvärdera förfrågningsbehandlingstiden på både klienter och peers (blockkedjenoder). Problem i någon av p2p-mekanismerna, felaktig datavräkning och cachning, ineffektiv hantering av listor över aktiva peers och många andra faktorer kan orsaka förseningar som påverkar effektiviteten i hela nätverket som helhet, och denna flaskhals är den svåraste att analysera , test och tolkning av resultat.

Blockchain-bearbetning och uppdatering av statens databas

Den viktigaste delen av blockkedjan är konsensusalgoritmen, dess tillämpning på nya block som tas emot från nätverket och bearbetningen av transaktioner med registrering av resultaten i statensdatabasen. Att lägga till ett nytt block i kedjan och sedan välja huvudkedjan ska fungera så snabbt som möjligt. Men i verkligheten betyder "bör" inte "fungerar", och man kan till exempel föreställa sig en situation där två långa konkurrerande kedjor ständigt växlar mellan sig och ändrar metadata för tusentals transaktioner i poolen vid varje byte , och ständigt rulla tillbaka tillståndsdatabasen. Detta steg, när det gäller att definiera flaskhalsen, är enklare än p2p-nätverkslagret, eftersom transaktionsutförande och konsensusalgoritm är strikt deterministiska, och det är lättare att mäta vad som helst här.
Huvudsaken är att inte blanda ihop slumpmässig försämring av detta stegs prestanda med nätverksproblem - noder är långsammare när det gäller att leverera block och information om huvudkedjan, och för en extern klient kan detta se ut som ett långsamt nätverk, även om problemet ligger i en helt annan plats.

För att optimera prestandan i detta skede är det användbart att samla in och övervaka mätvärden från själva noderna och inkludera i dem de som är relaterade till uppdatering av tillståndsdatabasen: antalet block som bearbetas på noden, deras storlek, antalet transaktioner, antalet växlar mellan kedjegafflar, antalet ogiltiga block , drifttid för virtuell maskin, databekräftelsetid, etc. Detta kommer att förhindra att nätverksproblem förväxlas med fel i kedjebearbetningsalgoritmer.

En virtuell maskin som bearbetar transaktioner kan vara en användbar informationskälla som kan optimera driften av blockkedjan. Antalet minnesallokeringar, antalet läs/skrivinstruktioner och andra mätvärden relaterade till effektiviteten i exekvering av kontraktskod kan ge mycket användbar information till utvecklare. Samtidigt är smarta kontrakt program, vilket betyder att de i teorin kan konsumera vilken som helst av resurserna: cpu/minne/nätverk/lagring, så transaktionsbearbetning är ett ganska osäkert stadium, som dessutom förändras mycket när man flyttar mellan versioner och vid ändring av avtalskoder. Därför behövs mätvärden relaterade till transaktionsbearbetning också för att effektivt optimera blockchain-prestanda.

Mottagande av kunden av ett meddelande om införandet av en transaktion i blockkedjan

Detta är det sista steget av blockchain-klienten som tar emot tjänsten; jämfört med andra stadier finns det inga stora omkostnader, men det är fortfarande värt att överväga möjligheten att klienten får ett omfattande svar från noden (till exempel ett smart kontrakt returnera en mängd data). I alla fall är denna punkt den viktigaste för den som ställde frågan "hur många tps finns i din blockchain?", eftersom I detta ögonblick registreras tidpunkten för mottagande av tjänsten.

På den här platsen skickas det alltid hela tiden som klienten fick vänta på svar från blockkedjan; det är den här gången som användaren kommer att vänta på bekräftelse i sin ansökan, och det är dess optimering som är utvecklarnas huvuduppgift.

Slutsats

Som ett resultat kan vi beskriva de typer av operationer som utförs på blockkedjor och dela in dem i flera kategorier:

kryptografiska transformationer, beviskonstruktion
peer-to-peer-nätverk, transaktions- och blockreplikering
transaktionsbearbetning, utförande av smarta kontrakt
tillämpa ändringar i blockkedjan på statensdatabasen, uppdatera data om transaktioner och block
skrivskyddade förfrågningar till statens databas, blockchain nod API, prenumerationstjänster

Generellt sett är de tekniska kraven för moderna blockkedjenoder extremt allvarliga - snabba processorer för kryptografi, en stor mängd RAM för att lagra och snabbt komma åt tillståndsdatabasen, nätverksinteraktion med ett stort antal samtidigt öppna anslutningar och stor lagring. Så höga krav och överflöd av olika typer av operationer leder oundvikligen till det faktum att noder kanske inte har tillräckligt med resurser, och då kan vilket som helst av stegen som diskuterats ovan bli ytterligare en flaskhals för den övergripande nätverksprestandan.

När du designar och utvärderar prestandan hos blockkedjor måste du ta hänsyn till alla dessa punkter. För att göra detta måste du samla in och analysera mätvärden samtidigt från klienter och nätverksnoder, leta efter korrelationer mellan dem, uppskatta tiden det tar att tillhandahålla tjänster till klienter, ta hänsyn till alla huvudresurser: cpu/minne/nätverk/lagring , förstå hur de används och påverka varandra. Allt detta gör att jämföra hastigheterna för olika blockkedjor i form av "hur många TPS" till en extremt otacksam uppgift, eftersom det finns ett stort antal olika konfigurationer och tillstånd. I stora centraliserade system, kluster av 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 som bearbetar kontrakt, interna ekonomier, antalet grader friheten är mycket större, vilket gör testet även på flera servrar, det är icke-indikativt och visar endast extremt ungefärliga värden som nästan inte har något samband med verkligheten.

Därför, när vi utvecklar i blockchain-kärnan, för att utvärdera prestanda och svara på frågan "har det förbättrats jämfört med förra gången?", använder vi ganska komplex programvara som orkestrerar lanseringen av en blockchain med dussintals noder och automatiskt lanserar ett benchmark och samlar in mätvärden Utan denna information är det extremt svårt att felsöka protokoll som fungerar med flera deltagare.

Så när du får frågan "hur många TPS finns i din blockchain?", bjud din samtalspartner lite te och fråga om han är redo att titta på ett dussin grafer och även lyssna på alla tre boxarna med blockchain-prestandaproblem och dina förslag på lösa dem...

Källa: will.com

Hur många TPS finns på din blockchain?