Hvorfor Blockchain Performance er svært at måle

Ydeevne og skalerbarhed er meget omtalte udfordringer i kryptorummet, der er relevante for både Layer 1-projekter (uafhængige blockchains) og Layer 2-løsninger (som rollups og off-chain-kanaler). Alligevel har vi ikke standardiserede målinger eller benchmarks. Tal rapporteres ofte på inkonsekvente og ufuldstændige måder, hvilket gør det vanskeligt at sammenligne projekter nøjagtigt og ofte slører det, der betyder mest i praksis. 

Vi har brug for en mere nuanceret og grundig tilgang til måling og sammenligning af ydeevne – en, der opdeler ydeevnen i flere komponenter og sammenligner afvejninger på tværs af flere akser. I dette indlæg definerer jeg grundlæggende terminologi, skitserer udfordringer og tilbyder retningslinjer og nøgleprincipper, du skal huske på, når du evaluerer blockchain-ydeevne. 

Skalerbarhed vs. ydeevne

Lad os først definere to udtryk, skalerbarhed og ydeevne, som har standard datalogiske betydninger, som ofte misbruges i blockchain-sammenhænge. Performance (Præstation) måler, hvad et system er i øjeblikket er i stand til at opnå. Som vi vil diskutere nedenfor, kan præstationsmålinger omfatte transaktioner pr. sekund eller median transaktionsbekræftelsestid. Skalerbarhedpå den anden side måler et systems evne til at forbedre ydeevnen ved at tilføje ressourcer.

Denne skelnen er vigtig: Mange tilgange til at forbedre ydeevnen forbedrer slet ikke skalerbarheden, når de er korrekt defineret. Et simpelt eksempel er at bruge en mere effektiv digital signaturordning, såsom BLS-signaturer, som er omtrent halvt så store som Schnorr- eller ECDSA-signaturer. Hvis Bitcoin skiftede fra ECDSA til BLS, kunne antallet af transaktioner pr. blok stige med 20-30%, hvilket forbedrer ydeevnen fra den ene dag til den anden. Men vi kan kun gøre dette én gang — der er ikke et endnu mere pladseffektivt signaturskema at skifte til (BLS-signaturer kan også aggregeres for at spare mere plads, men dette er endnu et enkeltstående trick).

En række andre enkeltstående tricks (såsom SegWit) er mulige i blockchains, men du har brug for en skalerbar arkitektur for at opnå en løbende forbedring af ydeevnen, hvor tilføjelse af flere ressourcer forbedrer ydeevnen over tid. Dette er den konventionelle visdom i mange andre computersystemer, såsom at bygge en webserver. Med et par almindelige tricks kan du bygge en meget hurtig server; men i sidste ende har du brug for en multi-server-arkitektur, der kan imødekomme stadigt voksende efterspørgsel ved løbende at tilføje ekstra servere.

At forstå sondringen hjælper også med at undgå den almindelige kategorifejl, der findes i udsagn som, "Blockchain X er meget skalerbar, den kan håndtere Y-transaktioner pr. sekund!" Den anden påstand kan være imponerende, men det er en ydeevne metrik, ikke en skalerbarhedsmetrik. Det taler ikke om evnen til at forbedre ydeevnen ved at tilføje ressourcer.

Skalerbarhed kræver i sagens natur udnyttelse af parallelitet. I blockchain-rummet ser det ud til, at lag 1-skalering kræver sharding eller noget, der ligner sharding. Det grundlæggende koncept med sharding - opdeling af tilstand i stykker, så forskellige validatorer kan behandle uafhængigt - stemmer nøje overens med definitionen af ​​skalerbarhed. Der er endnu flere muligheder på Layer 2, som tillader tilføjelse af parallel behandling - inklusive off-chain-kanaler, rollup-servere og sidechains.

Latency vs. gennemløb

Klassisk set evalueres blockchain-systemets ydeevne på tværs af to dimensioner, latens og gennemløb: Latency måler, hvor hurtigt en individuel transaktion kan bekræftes, hvorimod gennemstrømning måler den aggregerede hastighed af transaktioner over tid. Disse akser gælder både for Layer 1- og Layer 2-systemer, såvel som mange andre typer computersystemer (såsom databaseforespørgselsmotorer og webservere).

Desværre er både latenstid og gennemløb komplekse at måle og sammenligne. Desuden er individuelle brugere faktisk ligeglade med gennemstrømning (som er et mål for hele systemet). Det, de virkelig bekymrer sig om, er latenstid og transaktionsgebyrer - mere specifikt, at deres transaktioner bekræftes så hurtigt og så billigt som muligt. Selvom mange andre computersystemer også evalueres på omkostnings-/ydelsesbasis, er transaktionsgebyrer en noget ny ydeevneakse for blockchain-systemer, der ikke rigtig findes i traditionelle computersystemer.

Udfordringer med at måle latens

Latency virker i første omgang simpel: Hvor lang tid tager en transaktion at blive bekræftet? Men der er altid flere forskellige måder at besvare dette spørgsmål på.

For det første kan vi måle latens mellem forskellige tidspunkter og få forskellige resultater. Begynder vi for eksempel at måle latens, når brugeren trykker på en "send"-knap lokalt, eller når transaktionen rammer mempoolen? Og stopper vi uret, når transaktionen er i en foreslået blok, eller når en blokering bekræftes med en opfølgningsblok eller seks?

Den mest almindelige tilgang tager udgangspunkt i validatorer, der måler fra det tidspunkt, hvor en klient først udsender en transaktion, til det tidspunkt, hvor en transaktion er rimeligt "bekræftet" (i den forstand, at købmænd i den virkelige verden ville overveje en betaling modtaget og frigive merchandise) . Selvfølgelig kan forskellige forhandlere anvende forskellige acceptkriterier, og selv en enkelt forhandler kan bruge forskellige standarder afhængigt af transaktionsbeløbet.

Den validator-centrerede tilgang går glip af flere ting, der betyder noget i praksis. For det første ignorerer den latens på peer-to-peer-netværket (hvor lang tid tager det fra klienten udsender en transaktion, til de fleste noder har hørt den?) og latens på klientsiden (hvor lang tid tager det at forberede en transaktion på klientens lokale maskine?). Latens på klientsiden kan være meget lille og forudsigelig for simple transaktioner som at underskrive en Ethereum-betaling, men kan være væsentlig for mere komplekse sager som at bevise, at en afskærmet Zcash-transaktion er korrekt.

Selv hvis vi standardiserede det tidsvindue, vi forsøger at måle med latens, er svaret næsten altid det afhænger. Intet cryptocurrency-system, der nogensinde er bygget, har tilbudt fast transaktionsforsinkelse. En grundlæggende tommelfingerregel at huske er:

Latency er en fordeling, ikke et enkelt tal.

Netværksforskningsmiljøet har længe forstået dette (se f.eks. dette fremragende tale af Gil Tene). Der lægges særlig vægt på den "lange hale" af distributionen, da en stærkt forhøjet latenstid i selv 0.1 % af transaktionerne (eller webserverforespørgsler) vil alvorligt indvirkning slutbrugere.

Med blockchains kan bekræftelsesforsinkelsen variere af en række årsager:

Batching: de fleste systemer batcherer transaktioner på en eller anden måde, for eksempel i blokke på de fleste Layer 1-systemer. Dette fører til variabel latenstid, fordi nogle transaktioner skal vente, indtil batchen er fyldt op. Andre kan være heldige og slutte sig til partiet sidst. Disse transaktioner bekræftes med det samme og oplever ingen yderligere forsinkelse.

Variabel overbelastning: de fleste systemer lider af overbelastning, hvilket betyder, at flere transaktioner bogføres (i hvert fald noget af tiden), end systemet umiddelbart kan håndtere. Hvor overbelastet kan variere, når transaktioner udsendes på uforudsigelige tidspunkter (ofte abstraheret som en Poisson proces) eller når hastigheden af ​​nye transaktioner ændres i løbet af dagen eller ugen, eller som reaktion på eksterne begivenheder som en populær NFT-lancering.

Konsensus-lag-varians: Bekræftelse af en transaktion på lag 1 kræver normalt et distribueret sæt af noder for at nå konsensus om en blok, hvilket kan tilføje variable forsinkelser uanset overbelastning. Proof-of-work-systemer finder blokke på uforudsigelige tidspunkter (også abstrakt en Poisson-proces). Proof-of-stake-systemer kan også tilføje forskellige forsinkelser (f.eks. hvis et utilstrækkeligt antal noder er online til at danne en komité i en runde, eller hvis en visningsændring er påkrævet som svar på en leder, der går ned).

Af disse grunde er en god retningslinje:

Påstande om latenstid bør præsentere en fordeling (eller histogram) af bekræftelsestidspunkter i stedet for et enkelt tal som middelværdien eller medianen.

Mens opsummerende statistikker som middelværdi, median eller percentiler giver et delvist billede, kræver en nøjagtig evaluering af et system at overveje hele fordelingen. I nogle applikationer kan den gennemsnitlige latens give god indsigt, hvis latensfordelingen er relativt enkel (f.eks. Gaussisk). Men i kryptovaluta er det næsten aldrig sådan: Typisk er der en lang hale af langsomme bekræftelsestider.

Betalingskanalnetværk (f.eks. Lightning Network) er et godt eksempel. En klassisk L2-skaleringsløsning, disse netværk tilbyder meget hurtige betalingsbekræftelser det meste af tiden, men lejlighedsvis kræver de en kanalnulstilling, som kan øge latensen i størrelsesordener.

Og selvom vi har gode statistikker over den nøjagtige latensfordeling, vil de sandsynligvis variere over tid, efterhånden som systemet og efterspørgslen på systemet ændrer sig. Det er heller ikke altid klart, hvordan man sammenligner latensfordelinger mellem konkurrerende systemer. Overvej f.eks. et system, der bekræfter transaktioner med ensartet fordelt latenstid mellem 1 og 2 minutter (med et gennemsnit og median på 90 sekunder). Hvis et konkurrerende system bekræfter 95 % af transaktionerne præcist på 1 minut, og de øvrige 5 % på 11 minutter (med et gennemsnit på 90 sekunder og en median på 60 sekunder), hvilket system er bedst? Svaret er sandsynligvis, at nogle applikationer foretrækker førstnævnte og andre sidstnævnte.

Endelig er det vigtigt at bemærke, at i de fleste systemer er ikke alle transaktioner prioriteret lige meget. Brugere kan betale mere for at få en højere prioritet af inklusion, så ud over alt det ovenstående varierer latens som funktion af betalte transaktionsgebyrer. Sammenfattende:

Latency er kompleks. Jo flere data der rapporteres, jo bedre. Ideelt set bør fuldstændige latensfordelinger måles under varierende overbelastningsforhold. Opdelinger af latens i forskellige komponenter (lokalt, netværk, batching, konsensusforsinkelse) er også nyttige.

Udfordringer med at måle gennemløb

Gennemløbet virker også simpelt ved første øjekast: Hvor mange transaktioner kan et system behandle i sekundet? Der opstår to primære vanskeligheder: hvad er en "transaktion" præcist, og måler vi, hvad et system gør i dag, eller hvad det kan være i stand til?

Mens "transaktioner per sekund" (eller tps) er en de facto standard til måling af blockchain-ydelse, er transaktioner problematiske som måleenhed. For systemer, der tilbyder programmerbarhed til generelle formål ("smarte kontrakter") eller endda begrænsede funktioner som Bitcoins multiplex-transaktioner eller muligheder for multi-sig-verifikation, er det grundlæggende problem:

Ikke alle transaktioner er lige.

Dette er naturligvis sandt i Ethereum, hvor transaktioner kan inkludere vilkårlig kode og vilkårligt ændre tilstand. Begrebet gas i Ethereum bruges til at kvantificere (og opkræve gebyrer for) den samlede mængde arbejde, en transaktion udfører, men dette er meget specifikt for EVM-udførelsesmiljøet. Der er ingen enkel måde at sammenligne den samlede mængde arbejde udført af et sæt EVM-transaktioner med f.eks. et sæt Solana-transaktioner, der bruger BPF-miljøet. Sammenligning af begge med et sæt Bitcoin-transaktioner er på samme måde fyldt.

Blockchains, der adskiller transaktionslaget i et konsensuslag og et eksekveringslag, kan gøre dette mere klart. Ved det (rene) konsensuslag kan gennemløbet måles i bytes tilføjet til kæden pr. tidsenhed. Udførelseslaget vil altid være mere komplekst.

Enklere eksekveringslag, såsom rollup-servere, der kun understøtter betalingstransaktioner, undgår vanskeligheden med at kvantificere beregninger. Selv i dette tilfælde kan betalinger dog variere i antallet af input og output. Betalingskanal transaktioner kan variere i antallet af krævede "hop", hvilket påvirker gennemløbet. Og rollup-servergennemløbet kan afhænge af, i hvilket omfang en batch af transaktioner kan "nettes" ned til et mindre sæt af oversigtsændringer.

En anden udfordring med gennemstrømning er at gå ud over empirisk måling af dagens ydeevne for at evaluere teoretisk kapacitet. Dette introducerer alle mulige modelleringsspørgsmål for at evaluere potentiel kapacitet. Først skal vi beslutte os for en realistisk transaktionsarbejdsbyrde for eksekveringslaget. For det andet opnår rigtige systemer næsten aldrig teoretisk kapacitet, især blockchain-systemer. Af robusthedsmæssige årsager håber vi, at nodeimplementeringer er heterogene og forskellige i praksis (i stedet for at alle klienter kører en enkelt softwareimplementering). Dette gør nøjagtige simuleringer af blockchain-gennemstrømning endnu sværere at udføre. 

Samlet:

Påstande om gennemløb kræver en omhyggelig forklaring af transaktionens arbejdsbyrde og populationen af ​​validatorer (deres mængde, implementering og netværksforbindelse). I mangel af nogen klar standard er historiske arbejdsbelastninger fra et populært netværk som Ethereum tilstrækkeligt.

Afvejninger mellem latens og gennemløb

Latency og gennemløb er normalt en afvejning. Som Lefteris Kokoris-Kogias skitserer, er denne afvejning ofte ikke jævn, med et bøjningspunkt, hvor latency stiger kraftigt, når systembelastningen nærmer sig sin maksimale gennemstrømning.

Nul-viden rollup-systemer præsenterer et naturligt eksempel på gennemstrømning/latency-afvejningen. Store partier af transaktioner øger bevistiden, hvilket øger latensen. Men fodaftrykket på kæden, både med hensyn til bevisstørrelse og valideringsomkostninger, vil blive amortiseret over flere transaktioner med større batchstørrelser, hvilket øger gennemløbet.

Transaktionsgebyrer

Forståeligt nok bekymrer slutbrugerne sig mere om afvejningen mellem latenstid og gebyrer, ikke latens og gennemløb. Brugere har ingen direkte grund til overhovedet at bekymre sig om gennemløb, kun at de kan bekræfte transaktioner hurtigt for de lavest mulige gebyrer (hvor nogle brugere bekymrer sig mere om gebyrer og andre mere om latens). På et højt niveau påvirkes gebyrer af flere faktorer:

1. Hvor stor markedsefterspørgsel er der for at foretage transaktioner?
2. Hvilken overordnet gennemstrømning opnås af systemet?
3. Hvor stor samlet indtægt giver systemet til validatorer eller minearbejdere?
4. Hvor meget af denne indtægt er baseret på transaktionsgebyrer i forhold til inflationære belønninger?

De to første faktorer er groft sagt udbuds-/efterspørgselskurver, som fører til en markedsclearende pris (selvom det er blevet hævdet, at minearbejdere fungerer som et kartel for at hæve gebyrerne over dette punkt). Alt andet lige burde mere gennemløb have tendens til at føre til lavere gebyrer, men der sker meget mere.

Især punkt 3 og 4 ovenfor er grundlæggende spørgsmål om design af blockchain-systemer, men alligevel mangler vi gode principper for nogen af ​​dem. Vi har en vis forståelse af fordele og ulemper ved at give minearbejdere indtægter fra inflationsbelønninger kontra transaktionsgebyrer. På trods af mange økonomiske analyser af blockchain-konsensusprotokoller har vi stadig ingen bredt accepteret model for, hvor meget omsætning der skal gå til validatorer. I dag bygger de fleste systemer på et kvalificeret gæt om, hvor meget indtjening der er nok til at holde validatorer opføre sig ærligt uden at kvæle den praktiske brug af systemet. I forenklede modeller, det kan påvises, at omkostningerne ved at montere et angreb på 51 % skalerer med belønninger til validatorer.

Det er en god ting at hæve omkostningerne ved angreb, men vi ved heller ikke, hvor meget sikkerhed der er "nok". Forestil dig, at du overvejer at tage til to forlystelsesparker. En af dem hævder at bruge 50 % mindre på vedligeholdelse af køreture end den anden. Er det en god idé at tage til denne park? Det kan være, at de er mere effektive og får tilsvarende sikkerhed for færre penge. Måske bruger den anden mere, end hvad der er nødvendigt for at holde forlystelserne sikre til ingen fordel. Men det kan også være sådan, at den første park er farlig. Blockchain-systemer ligner hinanden. Når du først har udregnet gennemstrømningen, har blockchains med lavere gebyrer lavere gebyrer, fordi de belønner (og derfor incitamenter) deres validatorer mindre. Vi har ikke gode værktøjer i dag til at vurdere, om dette er i orden, eller om det gør systemet sårbart over for angreb. Samlet set:

Sammenligning af gebyrer mellem systemer kan være vildledende. Selvom transaktionsgebyrer er vigtige for brugerne, påvirkes de af mange faktorer udover selve systemdesignet. Gennemløb er en bedre målestok til at analysere et system som helhed.

Konklusion

Det er svært at evaluere ydeevnen retfærdigt og præcist. Dette gælder også for måling af en bils ydeevne. Ligesom med blockchains vil forskellige mennesker bekymre sig om forskellige ting. Med biler vil nogle brugere bekymre sig om tophastighed eller acceleration, andre om benzin-kilometertal og atter andre om bugseringskapacitet. Alle disse er ikke-trivielle at evaluere. I USA vedligeholder Environmental Protection Agency f.eks. detaljerede retningslinjer for, hvordan gaskilometertal vurderes, samt hvordan det skal præsenteres for brugere hos en forhandler.

Blockchain-området er langt fra dette standardiseringsniveau. På visse områder kan vi komme dertil i fremtiden med standardiserede arbejdsbelastninger for at evaluere et systems gennemløb eller standardiserede grafer til præsentation af latensfordelinger. Indtil videre er den bedste tilgang for evaluatorer og bygherrer at indsamle og offentliggøre så meget data som muligt med en detaljeret beskrivelse af evalueringsmetodikken, så den kan gengives og sammenlignes med andre systemer.