Varför Blockchain Performance är svårt att mäta

Prestanda och skalbarhet är mycket omdiskuterade utmaningar i kryptorymden, relevanta för både Layer 1-projekt (oberoende blockchains) och Layer 2-lösningar (som rollups och off-chain-kanaler). Ändå har vi inte standardiserade mätvärden eller riktmärken. Siffror rapporteras ofta på inkonsekventa och ofullständiga sätt, vilket gör det svårt att korrekt jämföra projekt och ofta döljer det som betyder mest i praktiken. 

Vi behöver ett mer nyanserat och grundligt tillvägagångssätt för att mäta och jämföra prestanda – en som bryter ner prestanda i flera komponenter och jämför avvägningar över flera axlar. I det här inlägget definierar jag grundläggande terminologi, skisserar utmaningar och erbjuder riktlinjer och nyckelprinciper att tänka på när du utvärderar blockchain-prestanda. 

Skalbarhet kontra prestanda

Låt oss först definiera två termer, skalbarhet och prestanda, som har vanliga datavetenskapliga betydelser som ofta missbrukas i blockkedjesammanhang. prestanda mäter vad ett system är för närvarande kan uppnå. Som vi kommer att diskutera nedan kan resultatstatistiken inkludera transaktioner per sekund eller mediantid för transaktionsbekräftelse. skalbarhet, å andra sidan, mäter ett systems förmåga att förbättra prestanda genom att lägga till resurser.

Denna distinktion är viktig: Många metoder för att förbättra prestanda förbättrar inte skalbarheten alls, när de är korrekt definierade. Ett enkelt exempel är att använda ett mer effektivt digitalt signatursystem, såsom BLS-signaturer, som är ungefär hälften så stora som Schnorr- eller ECDSA-signaturer. Om Bitcoin bytte från ECDSA till BLS, kan antalet transaktioner per block gå upp med 20-30%, vilket förbättrar prestandan över en natt. Men vi kan bara göra detta en gång — det finns inte ett ännu mer utrymmeseffektivt signaturschema att byta till (BLS-signaturer kan också aggregeras för att spara mer utrymme, men detta är ett annat engångsknep).

Ett antal andra engångsknep (som SegWit) är möjliga i blockkedjor, men du behöver en skalbar arkitektur för att uppnå ständiga prestandaförbättringar, där att lägga till fler resurser förbättrar prestandan över tid. Detta är den konventionella visdomen i många andra datorsystem också, som att bygga en webbserver. Med några vanliga knep kan du bygga en mycket snabb server; men i slutändan behöver du en multi-server arkitektur som kan möta den ständigt växande efterfrågan genom att kontinuerligt lägga till extra servrar.

Att förstå distinktionen hjälper också till att undvika det vanliga kategorifelet som finns i uttalanden som "Blockchain X är mycket skalbar, den kan hantera Y-transaktioner per sekund!" Det andra påståendet kan vara imponerande, men det är en prestanda mått, inte ett skalbarhetsmått. Det talar inte om förmågan att förbättra prestanda genom att lägga till resurser.

Skalbarhet kräver i sig att man utnyttjar parallellism. I blockchain-utrymmet verkar Layer 1-skalning kräva sharding eller något som ser ut som sharding. Det grundläggande konceptet med sharding - att dela upp tillstånd i bitar så att olika validatorer kan bearbeta oberoende - stämmer väl överens med definitionen av skalbarhet. Det finns ännu fler alternativ på Layer 2 som gör det möjligt att lägga till parallell bearbetning - inklusive off-chain-kanaler, rollup-servrar och sidokedjor.

Latens kontra genomströmning

Klassiskt sett utvärderas blockchain-systemets prestanda över två dimensioner, latens och genomströmning: Latens mäter hur snabbt en enskild transaktion kan bekräftas, medan genomströmningen mäter den aggregerade transaktionshastigheten över tid. Dessa axlar gäller både för lager 1- och lager 2-system, såväl som många andra typer av datorsystem (som databasfrågemotorer och webbservrar).

Tyvärr är både latens och genomströmning komplexa att mäta och jämföra. Dessutom bryr sig enskilda användare faktiskt inte om genomströmning (vilket är ett systemomfattande mått). Vad de verkligen bryr sig om är latens och transaktionsavgifter - mer specifikt att deras transaktioner bekräftas så snabbt och så billigt som möjligt. Även om många andra datorsystem också utvärderas på kostnads-/prestandabasis, är transaktionsavgifter en något ny prestandaaxel för blockkedjesystem som egentligen inte finns i traditionella datorsystem.

Utmaningar med att mäta latens

Latensen verkar enkel till en början: hur lång tid tar det att bekräfta en transaktion? Men det finns alltid flera olika sätt att svara på denna fråga.

Först kan vi mäta latens mellan olika tidpunkter och få olika resultat. Börjar vi till exempel mäta latens när användaren trycker på en "skicka"-knapp lokalt, eller när transaktionen träffar mempoolen? Och stoppar vi klockan när transaktionen är i ett föreslaget block, eller när en blockering bekräftas med ett uppföljningsblock eller sex?

Det vanligaste tillvägagångssättet tar validerarnas synvinkel, och mäter från det att en kund först sänder en transaktion till det att en transaktion rimligen "bekräftas" (i den meningen att verkliga handlare skulle överväga en betalning som tagits emot och släpper varor) . Naturligtvis kan olika handlare tillämpa olika acceptanskriterier, och även en enskild handlare kan använda olika standarder beroende på transaktionsbeloppet.

Det validatorcentrerade tillvägagångssättet missar flera saker som betyder något i praktiken. För det första ignorerar den latens på peer-to-peer-nätverket (hur lång tid tar det från det att klienten sänder en transaktion tills de flesta noder har hört den?) och latens på klientsidan (hur lång tid tar det att förbereda en transaktion på klientens lokala dator?). Latens på klientsidan kan vara mycket liten och förutsägbar för enkla transaktioner som att signera en Ethereum-betalning, men kan vara betydande för mer komplexa fall som att bevisa att en skyddad Zcash-transaktion är korrekt.

Även om vi standardiserade tidsfönstret vi försöker mäta med latens, är svaret nästan alltid det beror. Inget kryptovalutasystem som någonsin byggts har erbjudit fast transaktionslatens. En grundläggande tumregel att komma ihåg är:

Latens är en fördelning, inte ett enda nummer.

Nätverksforskningssamhället har länge förstått detta (se t.ex. detta utmärkt föredrag av Gil Tene). En särskild tonvikt läggs på distributionens "långa svans", eftersom en mycket förhöjd latens i till och med 0.1 % av transaktionerna (eller webbserverfrågor) kommer att allvarligt inverkan slutanvändare.

Med blockkedjor kan bekräftelsefördröjningen variera av ett antal anledningar:

Batchning: de flesta system batcherar transaktioner på något sätt, till exempel i block på de flesta Layer 1-system. Detta leder till variabel latens, eftersom vissa transaktioner måste vänta tills batchen är full. Andra kan ha tur och gå med i partiet sist. Dessa transaktioner bekräftas omedelbart och upplever ingen ytterligare latens.

Variabel trafikstockning: de flesta system lider av överbelastning, vilket innebär att fler transaktioner bokförs (åtminstone en del av tiden) än vad systemet omedelbart kan hantera. Hur överbelastat kan variera när transaktioner sänds vid oförutsägbara tidpunkter (ofta abstrakt som en Poisson-process) eller när takten för nya transaktioner ändras under dagen eller veckan, eller som svar på externa händelser som en populär NFT-lansering.

Konsensus-lagervarians: Att bekräfta en transaktion på lager 1 kräver vanligtvis en distribuerad uppsättning noder för att nå konsensus om ett block, vilket kan lägga till variabla fördröjningar oavsett överbelastning. Bevis-of-work-system hittar block vid oförutsägbara tidpunkter (också abstrakt en Poisson-process). Bevis-of-stake-system kan också lägga till olika fördröjningar (till exempel om ett otillräckligt antal noder är online för att bilda en kommitté i en omgång, eller om en vyändring krävs som svar på att en ledare kraschar).

Av dessa skäl är en bra riktlinje:

Påståenden om latens bör presentera en fördelning (eller histogram) av bekräftelsetider, snarare än ett enda tal som medelvärde eller median.

Även om sammanfattande statistik som medelvärde, median eller percentiler ger en partiell bild, kräver en korrekt utvärdering av ett system att man beaktar hela fördelningen. I vissa applikationer kan medellatensen ge god insikt om latensfördelningen är relativt enkel (till exempel Gaussisk). Men i kryptovaluta är det nästan aldrig så här: Vanligtvis finns det en lång svans av långsamma bekräftelsetider.

Betalningskanalnätverk (t.ex. Lightning Network) är ett bra exempel. En klassisk L2-skalningslösning, dessa nätverk erbjuder mycket snabba betalningsbekräftelser för det mesta, men ibland kräver de en kanalåterställning som kan öka latensen i storleksordningar.

Och även om vi har bra statistik över den exakta latensfördelningen, kommer de sannolikt att variera över tiden när systemet och efterfrågan på systemet förändras. Det är inte heller alltid klart hur man jämför latensfördelningar mellan konkurrerande system. Tänk till exempel på ett system som bekräftar transaktioner med jämnt fördelad latens mellan 1 och 2 minuter (med ett medelvärde och median på 90 sekunder). Om ett konkurrerande system bekräftar 95 % av transaktionerna på 1 minut exakt, och de andra 5 % på 11 minuter (med ett medelvärde på 90 sekunder och en median på 60 sekunder), vilket system är bättre? Svaret är förmodligen att vissa applikationer skulle föredra det förra och andra det senare.

Slutligen är det viktigt att notera att i de flesta system prioriteras inte alla transaktioner lika. Användare kan betala mer för att få en högre prioritet för inkludering, så utöver allt ovanstående varierar latensen som en funktion av betalda transaktionsavgifter. Sammanfattningsvis:

Latensen är komplex. Ju mer data som rapporteras, desto bättre. Helst bör fullständiga latensfördelningar mätas under varierande överbelastningsförhållanden. Uppdelningar av latens i olika komponenter (lokalt, nätverk, batchning, konsensusfördröjning) är också till hjälp.

Utmaningar med att mäta genomströmning

Genomströmningen verkar också enkel vid första anblicken: hur många transaktioner kan ett system bearbeta per sekund? Två primära svårigheter uppstår: vad exakt är en "transaktion" och mäter vi vad ett system gör idag eller vad det kan göra?

Medan "transaktioner per sekund" (eller tps) är en de facto standard för att mäta blockchain-prestanda, är transaktioner problematiska som måttenhet. För system som erbjuder generell programmerbarhet ("smarta kontrakt") eller till och med begränsade funktioner som Bitcoins multiplextransaktioner eller alternativ för multi-sig-verifiering, är den grundläggande frågan:

Alla transaktioner är inte lika.

Detta är uppenbarligen sant i Ethereum, där transaktioner kan inkludera godtycklig kod och godtyckligt modifiera tillstånd. Begreppet gas i Ethereum används för att kvantifiera (och ta ut avgifter för) den totala mängden arbete som en transaktion utför, men detta är mycket specifikt för EVM-exekveringsmiljön. Det finns inget enkelt sätt att jämföra den totala mängden arbete som utförs av en uppsättning EVM-transaktioner med till exempel en uppsättning Solana-transaktioner som använder BPF-miljön. Att jämföra båda med en uppsättning Bitcoin-transaktioner är lika svårt.

Blockkedjor som separerar transaktionslagret i ett konsensuslager och ett exekveringslager kan göra detta mer tydligt. Vid det (rena) konsensusskiktet kan genomströmningen mätas i byte som adderas till kedjan per tidsenhet. Utförandelagret kommer alltid att vara mer komplext.

Enklare exekveringslager, till exempel sammanslagningsservrar som endast stöder betalningstransaktioner, undviker svårigheten att kvantifiera beräkningar. Även i detta fall kan dock betalningar variera i antal ingångar och utgångar. Betalningskanal transaktioner kan variera i antalet "hopp" som krävs, vilket påverkar genomströmningen. Och sammanlagd servergenomströmning kan bero på i vilken utsträckning en grupp transaktioner kan "nettas" till en mindre uppsättning sammanfattningsändringar.

En annan utmaning med genomströmning är att gå längre än att empiriskt mäta dagens prestanda för att utvärdera teoretisk kapacitet. Detta introducerar alla möjliga modelleringsfrågor för att utvärdera potentiell kapacitet. Först måste vi besluta om en realistisk transaktionsbelastning för exekveringsskiktet. För det andra uppnår verkliga system nästan aldrig teoretisk kapacitet, särskilt blockkedjesystem. Av robusthetsskäl hoppas vi att nodimplementeringar är heterogena och mångsidiga i praktiken (snarare än att alla klienter kör en enda mjukvaruimplementering). Detta gör exakta simuleringar av blockchain-genomströmning ännu svårare att genomföra. 

Övergripande:

Påståenden om genomströmning kräver noggrann förklaring av transaktionens arbetsbelastning och populationen av validerare (deras kvantitet, implementering och nätverksanslutning). I avsaknad av någon tydlig standard räcker det med historiska arbetsbelastningar från ett populärt nätverk som Ethereum.

Avvägningar för latens-genomströmning

Latens och genomströmning är vanligtvis en avvägning. Som Lefteris Kokoris-Kogias skisserar, är denna avvägning ofta inte jämn, med en böjningspunkt där latensen ökar kraftigt när systembelastningen närmar sig sin maximala genomströmning.

System med nollkunskaper är ett naturligt exempel på avvägningen mellan genomströmning och latens. Stora omgångar av transaktioner ökar provningstiden vilket ökar latensen. Men kedjans fotavtryck, både när det gäller bevisstorlek och valideringskostnad, kommer att skrivas av över fler transaktioner med större batchstorlekar, vilket ökar genomströmningen.

transaktionsavgifter

Förståeligt nog bryr sig slutanvändare mer om avvägningen mellan latens och avgifter, inte latens och genomströmning. Användare har ingen direkt anledning att bry sig om genomströmning alls, bara att de kan bekräfta transaktioner snabbt för lägsta möjliga avgifter (med vissa användare bryr sig mer om avgifter och andra mer om latens). På en hög nivå påverkas avgifter av flera faktorer:

1. Hur stor efterfrågan på marknaden finns för att göra transaktioner?
2. Vilken total genomströmning uppnås av systemet?
3. Hur mycket totala intäkter ger systemet till validerare eller gruvarbetare?
4. Hur mycket av dessa intäkter är baserat på transaktionsavgifter kontra inflationsbelöningar?

De två första faktorerna är ungefär utbud/efterfrågan kurvor som leder till ett marknadsclearande pris (även om det har hävdats att gruvarbetare fungerar som en kartell för att höja avgifterna över denna punkt). Allt annat lika borde mer genomströmning tendera att leda till lägre avgifter, men det händer mycket mer.

I synnerhet punkterna 3 och 4 ovan är grundläggande frågor om blockchain-systemdesign, men vi saknar bra principer för någon av dem. Vi har viss förståelse för fördelarna och nackdelarna med att ge gruvarbetare intäkter från inflationsbelöningar kontra transaktionsavgifter. Men trots många ekonomiska analyser av blockchain-konsensusprotokoll har vi fortfarande ingen allmänt accepterad modell för hur mycket intäkter som behöver gå till validatorer. Idag bygger de flesta system in en välgrundad gissning om hur mycket intäkter som räcker för att hålla validerare uppträda ärligt utan att strypa den praktiska användningen av systemet. I förenklade modeller, det kan visas att kostnaden för att montera en 51 % attack skalar med belöningar till validerare.

Att höja kostnaderna för attacker är bra, men vi vet inte heller hur mycket säkerhet som är "tillräckligt". Föreställ dig att du funderar på att åka till två nöjesparker. En av dem säger sig spendera 50 % mindre på underhåll av åkarna än den andra. Är det en bra idé att gå till den här parken? Det kan vara så att de är mer effektiva och får motsvarande säkerhet för mindre pengar. Den andra kanske spenderar mer än vad som behövs för att hålla åkerna säkra till ingen nytta. Men det kan också vara så att den första parken är farlig. Blockchain-system är liknande. När du väl har räknat ut genomströmningen har blockkedjor med lägre avgifter lägre avgifter eftersom de belönar (och därför motiverar) sina validerare mindre. Vi har inga bra verktyg idag för att bedöma om detta är okej eller om det gör systemet sårbart för attacker. Övergripande:

Att jämföra avgifter mellan system kan vara vilseledande. Även om transaktionsavgifter är viktiga för användarna, påverkas de av många faktorer förutom själva systemdesignen. Genomströmning är ett bättre mått för att analysera ett system som helhet.

Slutsats

Att utvärdera prestandan rättvist och exakt är svårt. Detta är lika sant för att mäta en bils prestanda. Precis som med blockkedjor kommer olika människor att bry sig om olika saker. Med bilar kommer vissa användare att bry sig om toppfart eller acceleration, andra om bensinkörning och ytterligare andra om dragkapacitet. Alla dessa är icke-triviala att utvärdera. I USA upprätthåller exempelvis Environmental Protection Agency detaljerade riktlinjer bara för hur gassträcka utvärderas samt hur den måste presenteras för användare hos en återförsäljare.

Blockchain-utrymmet är långt från denna standardiseringsnivå. Inom vissa områden kan vi komma dit i framtiden med standardiserade arbetsbelastningar för att utvärdera genomströmningen av ett system eller standardiserade grafer för att presentera latensfördelningar. För närvarande är det bästa tillvägagångssättet för utvärderare och byggare att samla in och publicera så mycket data som möjligt, med en detaljerad beskrivning av utvärderingsmetodiken, så att den kan reproduceras och jämföras med andra system.