Waarom Blockchain-prestaties moeilijk te meten zijn

Prestaties en schaalbaarheid zijn veelbesproken uitdagingen in de crypto-ruimte, relevant voor zowel Layer 1-projecten (onafhankelijke blockchains) als Layer 2-oplossingen (zoals rollups en off-chain-kanalen). Toch hebben we geen gestandaardiseerde statistieken of benchmarks. Cijfers worden vaak op inconsistente en onvolledige manieren gerapporteerd, waardoor het moeilijk is om projecten nauwkeurig te vergelijken en vaak verdoezelt wat in de praktijk het belangrijkst is. 

We hebben een meer genuanceerde en grondige benadering nodig voor het meten en vergelijken van prestaties - een die prestaties opsplitst in meerdere componenten en afwegingen over meerdere assen vergelijkt. In dit bericht definieer ik basisterminologie, schets ik uitdagingen en bied ik richtlijnen en belangrijke principes om in gedachten te houden bij het evalueren van blockchain-prestaties. 

Schaalbaarheid versus prestaties

Laten we eerst twee termen definiëren, schaalbaarheid en prestatie, die standaard informatica-betekenissen hebben die vaak worden misbruikt in blockchain-contexten. Performance meet wat een systeem is momenteel in staat om te bereiken. Zoals we hieronder zullen bespreken, kunnen prestatiestatistieken transacties per seconde of mediane transactiebevestigingstijd omvatten. Schaalbaarheid, aan de andere kant, meet de vermogen van een systeem om de prestaties te verbeteren door resources toe te voegen.

Dit onderscheid is belangrijk: veel benaderingen om de prestaties te verbeteren, verbeteren de schaalbaarheid helemaal niet, als ze goed zijn gedefinieerd. Een eenvoudig voorbeeld is het gebruik van een efficiënter digitaal handtekeningschema, zoals BLS-handtekeningen, die ongeveer half zo groot zijn als Schnorr- of ECDSA-handtekeningen. Als Bitcoin overschakelde van ECDSA naar BLS, zou het aantal transacties per blok met 20-30% kunnen stijgen, waardoor de prestaties van de ene op de andere dag zouden verbeteren. Maar we kunnen dit maar één keer doen - er is geen nog meer ruimtebesparend handtekeningschema om naar over te schakelen (BLS-handtekeningen kunnen ook worden samengevoegd om meer ruimte te besparen, maar dit is weer een eenmalige truc).

Een aantal andere eenmalige trucs (zoals SegWit) zijn mogelijk in blockchains, maar je hebt een schaalbare architectuur nodig om continue prestatieverbetering te bereiken, waarbij het toevoegen van meer bronnen de prestaties in de loop van de tijd verbetert. Dit is ook de conventionele wijsheid in veel andere computersystemen, zoals het bouwen van een webserver. Met een paar veelvoorkomende trucs kun je een zeer snelle server bouwen; maar uiteindelijk hebt u een architectuur met meerdere servers nodig die aan de steeds groeiende vraag kan voldoen door voortdurend extra servers toe te voegen.

Als u het onderscheid begrijpt, kunt u ook de veelvoorkomende categoriefout vermijden die wordt aangetroffen in uitspraken als: "Blockchain X is zeer schaalbaar, het kan Y-transacties per seconde aan!" De tweede claim is misschien indrukwekkend, maar het is een prestatie metriek, geen schaalbaarheidsmetriek. Het spreekt niet over de mogelijkheid om de prestaties te verbeteren door resources toe te voegen.

Schaalbaarheid vereist inherent het benutten van parallellisme. In de blockchain-ruimte lijkt Layer 1-schaling sharding te vereisen of iets dat op sharding lijkt. Het basisconcept van sharding - het opsplitsen van de status in stukjes zodat verschillende validators onafhankelijk kunnen worden verwerkt - sluit nauw aan bij de definitie van schaalbaarheid. Er zijn nog meer opties op Layer 2 die het mogelijk maken om parallelle verwerking toe te voegen, inclusief off-chain kanalen, rollup-servers en zijketens.

Latentie versus doorvoer

Klassiek worden de prestaties van het blockchain-systeem geëvalueerd over twee dimensies, latentie en doorvoer: latentie meet hoe snel een individuele transactie kan worden bevestigd, terwijl doorvoer de totale snelheid van transacties in de loop van de tijd meet. Deze assen zijn zowel van toepassing op Layer 1- als Layer 2-systemen, evenals op vele andere soorten computersystemen (zoals databasequery-engines en webservers).

Helaas zijn zowel latency als throughput complex om te meten en te vergelijken. Bovendien geven individuele gebruikers niet echt om doorvoer (wat een systeembrede maatregel is). Waar ze echt om geven, zijn latentie- en transactiekosten - meer specifiek, dat hun transacties zo snel en zo goedkoop mogelijk worden bevestigd. Hoewel veel andere computersystemen ook worden beoordeeld op basis van kosten/prestatie, zijn transactiekosten een enigszins nieuwe prestatie-as voor blockchain-systemen die niet echt bestaat in traditionele computersystemen.

Uitdagingen bij het meten van latentie

Latency lijkt in eerste instantie eenvoudig: hoe lang duurt het voordat een transactie wordt bevestigd? Maar er zijn altijd verschillende manieren om deze vraag te beantwoorden.

Ten eerste kunnen we de latentie tussen verschillende tijdstippen meten en verschillende resultaten krijgen. Beginnen we bijvoorbeeld de latentie te meten wanneer de gebruiker lokaal op de knop 'Verzenden' drukt, of wanneer de transactie de mempool bereikt? En stoppen we de klok wanneer de transactie zich in een voorgesteld blok bevindt, of wanneer een blok wordt bevestigd met één vervolgblok of zes?

De meest gebruikelijke benadering is het standpunt van validators, waarbij wordt gemeten vanaf het moment dat een klant een transactie voor het eerst uitzendt tot het moment dat een transactie redelijkerwijs wordt "bevestigd" (in de zin dat echte handelaren een ontvangen betaling zouden beschouwen en goederen vrijgeven) . Natuurlijk kunnen verschillende handelaren verschillende acceptatiecriteria toepassen, en zelfs een enkele handelaar kan verschillende standaarden gebruiken, afhankelijk van het transactiebedrag.

De validatorgerichte benadering mist een aantal zaken die er in de praktijk toe doen. Ten eerste negeert het latentie op het peer-to-peer netwerk (hoe lang duurt het vanaf het moment dat de client een transactie uitzendt tot wanneer de meeste nodes het hebben gehoord?) en latentie aan de clientzijde (hoe lang duurt het om een ​​transactie voor te bereiden) op de lokale computer van de klant?). De latentie aan de kant van de klant kan erg klein en voorspelbaar zijn voor eenvoudige transacties zoals het ondertekenen van een Ethereum-betaling, maar kan aanzienlijk zijn voor complexere gevallen, zoals bewijzen dat een afgeschermde Zcash-transactie correct is.

Zelfs als we het tijdvenster dat we proberen te meten hebben gestandaardiseerd met latentie, is het antwoord bijna altijd het hangt ervan. Geen enkel cryptocurrency-systeem dat ooit is gebouwd, heeft een vaste transactielatentie geboden. Een fundamentele vuistregel om te onthouden is:

Latency is een verdeling, geen enkel getal.

De netwerkonderzoeksgemeenschap heeft dit al lang begrepen (zie bijvoorbeeld dit uitstekende toespraak van Gil Tene). Er wordt bijzondere nadruk gelegd op de "lange staart" van de distributie, aangezien een sterk verhoogde latentie in zelfs 0.1% van de transacties (of zoekopdrachten op de webserver) ernstig invloed eindgebruikers.

Bij blockchains kan de bevestigingslatentie om een ​​aantal redenen variëren:

batchgewijs: de meeste systemen batchen transacties op de een of andere manier, bijvoorbeeld in blokken op de meeste Layer 1-systemen. Dit leidt tot variabele latentie, omdat sommige transacties moeten wachten tot de batch vol is. Anderen hebben misschien geluk en sluiten zich als laatste aan bij de groep. Deze transacties worden meteen bevestigd en ondervinden geen extra latentie.

Variabele congestie: de meeste systemen hebben last van congestie, wat betekent dat er meer transacties worden geboekt (ten minste een deel van de tijd) dan het systeem onmiddellijk aankan. Hoe overbelast kan zijn wanneer transacties op onvoorspelbare tijden worden uitgezonden (vaak geabstraheerd als a Poisson-proces) of wanneer het aantal nieuwe transacties gedurende de dag of week verandert, of als reactie op externe gebeurtenissen zoals een populaire NFT-lancering.

Consensus-laag variantie: Het bevestigen van een transactie op Laag 1 vereist meestal een gedistribueerde set knooppunten om consensus over een blok te bereiken, wat variabele vertragingen kan toevoegen, ongeacht de congestie. Proof-of-work-systemen vinden blokken op onvoorspelbare tijden (ook abstract een Poisson-proces). Proof-of-stake-systemen kunnen ook verschillende vertragingen toevoegen (bijvoorbeeld als er onvoldoende knooppunten online zijn om een ​​commissie in een ronde te vormen, of als een weergavewijziging nodig is als reactie op een crash van een leider).

Om deze redenen is een goede richtlijn:

Claims over latentie moeten een verdeling (of histogram) van bevestigingstijden weergeven in plaats van een enkel getal zoals het gemiddelde of de mediaan.

Hoewel samenvattende statistieken zoals het gemiddelde, de mediaan of de percentielen een gedeeltelijk beeld geven, vereist een nauwkeurige evaluatie van een systeem dat de volledige distributie in aanmerking wordt genomen. In sommige toepassingen kan de gemiddelde latentie goed inzicht geven als de latentieverdeling relatief eenvoudig is (bijvoorbeeld Gaussiaans). Maar in cryptocurrency is het bijna nooit zo: meestal is er een lange staart van langzame bevestigingstijden.

Betaalkanaalnetwerken (bijvoorbeeld Lightning Network) zijn een goed voorbeeld. Deze netwerken, een klassieke L2-schaaloplossing, bieden meestal zeer snelle betalingsbevestigingen, maar af en toe vereisen ze een kanaalreset die de latentie met orden van grootte kan verhogen.

En zelfs als we goede statistieken hebben over de exacte latentieverdeling, zullen deze waarschijnlijk in de loop van de tijd variëren naarmate het systeem en de vraag naar het systeem veranderen. Het is ook niet altijd duidelijk hoe latentieverdelingen tussen concurrerende systemen moeten worden vergeleken. Neem bijvoorbeeld een systeem dat transacties bevestigt met een uniform verdeelde latentie tussen 1 en 2 minuten (met een gemiddelde en mediaan van 90 seconden). Als een concurrerend systeem 95% van de transacties in precies 1 minuut bevestigt, en de andere 5% in 11 minuten (met een gemiddelde van 90 seconden en een mediaan van 60 seconden), welk systeem is dan beter? Het antwoord is waarschijnlijk dat sommige toepassingen de voorkeur geven aan de eerste en sommige aan de laatste.

Ten slotte is het belangrijk op te merken dat in de meeste systemen niet alle transacties dezelfde prioriteit krijgen. Gebruikers kunnen meer betalen om een ​​hogere prioriteit van opname te krijgen, dus naast al het bovenstaande varieert de latentie als een functie van de betaalde transactiekosten. Samengevat:

Latentie is complex. Hoe meer gegevens worden gerapporteerd, hoe beter. Idealiter moeten volledige latentieverdelingen worden gemeten onder variërende congestieomstandigheden. Uitsplitsingen van latentie in verschillende componenten (lokaal, netwerk, batching, consensusvertraging) zijn ook nuttig.

Uitdagingen bij het meten van de doorvoer

Doorvoer lijkt op het eerste gezicht ook eenvoudig: hoeveel transacties kan een systeem per seconde verwerken? Er doen zich twee primaire problemen voor: wat is precies een 'transactie' en meten we wat een systeem vandaag doet of wat het zou kunnen doen?

Hoewel "transacties per seconde" (of tps) een de facto standaard is voor het meten van blockchain-prestaties, zijn transacties problematisch als meeteenheid. Voor systemen die programmeerbaarheid voor algemene doeleinden ("slimme contracten") of zelfs beperkte functies zoals Bitcoin's multiplextransacties of opties voor multi-sig-verificatie bieden, is het fundamentele probleem:

Niet alle transacties zijn gelijk.

Dit is duidelijk waar in Ethereum, waar transacties willekeurige code kunnen bevatten en de status willekeurig kunnen wijzigen. Het begrip gas in Ethereum wordt gebruikt om de totale hoeveelheid werk die een transactie doet te kwantificeren (en kosten in rekening te brengen), maar dit is zeer specifiek voor de EVM-uitvoeringsomgeving. Er is geen eenvoudige manier om de totale hoeveelheid werk van een set EVM-transacties te vergelijken met bijvoorbeeld een set Solana-transacties met behulp van de BPF-omgeving. Het vergelijken van een van beide met een reeks Bitcoin-transacties is eveneens beladen.

Blockchains die de transactielaag scheiden in een consensuslaag en een uitvoeringslaag kunnen dit duidelijker maken. Op de (pure) consensuslaag kan de doorvoer worden gemeten in bytes die per tijdseenheid aan de keten worden toegevoegd. De uitvoeringslaag zal altijd complexer zijn.

Eenvoudigere uitvoeringslagen, zoals rollup-servers die alleen betalingstransacties ondersteunen, vermijden de moeilijkheid om berekeningen te kwantificeren. Zelfs in dit geval kunnen betalingen echter variëren in het aantal inputs en outputs. Betaalkanaal transacties kunnen variëren in het aantal benodigde "hops", wat van invloed is op de doorvoer. En de verwerkingscapaciteit van de rollup-server kan afhangen van de mate waarin een batch transacties kan worden "verrekend" tot een kleinere reeks samenvattingswijzigingen.

Een andere uitdaging met de doorvoer is om verder te gaan dan het empirisch meten van de huidige prestaties om de theoretische capaciteit te evalueren. Dit introduceert allerlei modelleringsvragen om potentiële capaciteit te evalueren. Eerst moeten we beslissen over een realistische transactiebelasting voor de uitvoeringslaag. Ten tweede bereiken echte systemen bijna nooit theoretische capaciteit, vooral blockchain-systemen. Om robuustheidsredenen hopen we dat knooppuntimplementaties in de praktijk heterogeen en divers zijn (in plaats van dat alle clients een enkele software-implementatie uitvoeren). Dit maakt nauwkeurige simulaties van blockchain-doorvoer nog moeilijker uit te voeren. 

Algemeen:

Claims van doorvoer vereisen een zorgvuldige uitleg van de transactiebelasting en de populatie validators (hun hoeveelheid, implementatie en netwerkconnectiviteit). Bij gebrek aan een duidelijke standaard volstaan ​​historische workloads van een populair netwerk als Ethereum.

Latentie-doorvoer compromissen

Latency en doorvoer zijn meestal een afweging. Net zo Lefteris Kokoris-Kogias schetst, is deze afweging vaak niet soepel, met een buigpunt waar de latentie sterk toeneemt naarmate de systeembelasting de maximale doorvoer nadert.

Zero-knowledge rollup-systemen zijn een natuurlijk voorbeeld van de afweging tussen doorvoer en latentie. Grote hoeveelheden transacties verhogen de bewijstijd, waardoor de latentie toeneemt. Maar de on-chain footprint, zowel in termen van bewijsgrootte als validatiekosten, zal worden afgeschreven over meer transacties met grotere batchgroottes, waardoor de doorvoer toeneemt.

Transactiekosten

Het is begrijpelijk dat eindgebruikers meer geven om de afweging tussen latentie en fees, niet latentie en doorvoer. Gebruikers hebben helemaal geen reden om zich druk te maken over de doorvoer, alleen dat ze transacties snel kunnen bevestigen tegen de laagst mogelijke kosten (sommige gebruikers geven meer om vergoedingen en anderen meer over latentie). Op een hoog niveau worden vergoedingen beïnvloed door meerdere factoren:

1. Hoeveel marktvraag is er om transacties te doen?
2. Welke totale doorvoer wordt door het systeem bereikt?
3. Hoeveel totale inkomsten levert het systeem aan validators of miners?
4. Hoeveel van deze inkomsten is gebaseerd op transactiekosten versus inflatiebeloningen?

De eerste twee factoren zijn ruwweg vraag/aanbodcurves die leiden tot een marktclearingprijs (hoewel beweerd wordt dat mijnwerkers fungeren als een kartel om de vergoedingen boven dit punt te verhogen). Als al het andere gelijk is, zou meer doorvoer moeten leiden tot lagere tarieven, maar er is veel meer aan de hand.

Met name de punten 3 en 4 hierboven zijn fundamentele vragen over het ontwerp van blockchainsystemen, maar voor geen van beide ontbreekt het ons aan goede principes. We hebben enig begrip van de voor- en nadelen van het geven van inkomsten aan mijnwerkers uit inflatoire beloningen versus transactiekosten. Ondanks vele economische analyses van blockchain-consensusprotocollen, hebben we echter nog steeds geen algemeen geaccepteerd model voor hoeveel inkomsten naar validators moeten gaan. Tegenwoordig zijn de meeste systemen gebaseerd op een weloverwogen schatting van hoeveel inkomsten voldoende zijn om validators zich eerlijk te laten gedragen zonder het praktische gebruik van het systeem in de weg te staan. In vereenvoudigde modellen, het kan worden aangetoond dat de kosten van het opzetten van een 51%-aanval worden geschaald met beloningen voor validators.

Het verhogen van de kosten van aanvallen is een goede zaak, maar we weten ook niet hoeveel beveiliging 'voldoende' is. Stel je voor dat je overweegt naar twee pretparken te gaan. De een beweert 50% minder uit te geven aan het onderhoud van de rit dan de ander. Is het een goed idee om naar dit park te gaan? Het kan zijn dat ze efficiënter zijn en gelijkwaardige veiligheid krijgen voor minder geld. Misschien geeft de ander meer uit dan nodig is om de ritten veilig te houden, zonder enig voordeel. Maar het kan ook zijn dat het eerste park gevaarlijk is. Blockchain-systemen zijn vergelijkbaar. Zodra u de doorvoer buiten beschouwing laat, hebben blockchains met lagere kosten lagere kosten omdat ze hun validators minder belonen (en daarom stimuleren). We hebben tegenwoordig geen goede tools om te beoordelen of dit in orde is of dat het systeem kwetsbaar is voor aanvallen. Algemeen:

Het vergelijken van vergoedingen tussen systemen kan misleidend zijn. Hoewel transactiekosten belangrijk zijn voor gebruikers, worden ze beïnvloed door vele factoren naast het systeemontwerp zelf. Doorvoer is een betere maatstaf voor het analyseren van een systeem als geheel.

Conclusie

Prestaties eerlijk en nauwkeurig evalueren is moeilijk. Dit geldt evenzeer voor het meten van de prestaties van een auto. Net als bij blockchains, zullen verschillende mensen om verschillende dingen geven. Bij auto's zullen sommige gebruikers zich zorgen maken over topsnelheid of acceleratie, anderen over benzineverbruik en weer anderen over het trekvermogen. Al deze zijn niet triviaal om te evalueren. In de VS heeft de Environmental Protection Agency bijvoorbeeld gedetailleerde richtlijnen voor de manier waarop het benzineverbruik wordt beoordeeld en hoe deze moet worden gepresenteerd aan gebruikers bij een dealer.

De blockchain-ruimte is ver verwijderd van dit niveau van standaardisatie. In bepaalde gebieden kunnen we daar in de toekomst komen met gestandaardiseerde workloads om de doorvoer van een systeem te evalueren of gestandaardiseerde grafieken voor het presenteren van latentieverdelingen. Vooralsnog is de beste aanpak voor evaluatoren en bouwers om zoveel mogelijk gegevens te verzamelen en te publiceren, met een gedetailleerde beschrijving van de evaluatiemethodologie, zodat deze kan worden gereproduceerd en vergeleken met andere systemen.