Warum die Blockchain-Leistung schwer zu messen ist

Leistung und Skalierbarkeit sind viel diskutierte Herausforderungen im Krypto-Bereich, die sowohl für Layer-1-Projekte (unabhängige Blockchains) als auch für Layer-2-Lösungen (wie Rollups und Off-Chain-Kanäle) relevant sind. Dennoch verfügen wir nicht über standardisierte Kennzahlen oder Benchmarks. Zahlen werden oft inkonsistent und unvollständig gemeldet, was einen genauen Vergleich von Projekten erschwert und oft den Blick auf das Wesentliche in der Praxis verschleiert. 

Wir brauchen einen differenzierteren und gründlicheren Ansatz zum Messen und Vergleichen der Leistung – einen, der die Leistung in mehrere Komponenten aufteilt und Kompromisse über mehrere Achsen hinweg vergleicht. In diesem Beitrag definiere ich grundlegende Terminologie, skizziere Herausforderungen und biete Richtlinien und Schlüsselprinzipien an, die bei der Bewertung der Blockchain-Leistung zu beachten sind. 

Skalierbarkeit vs. Leistung

Definieren wir zunächst zwei Begriffe, Skalierbarkeit und Leistung, die in der Informatik übliche Bedeutungen haben, die in Blockchain-Kontexten häufig missbraucht werden. Leistung misst, was ein System ist derzeit in der Lage, dies zu erreichen. Wie wir weiter unten besprechen werden, können Leistungsmetriken Transaktionen pro Sekunde oder die mittlere Transaktionsbestätigungszeit umfassen. Skalierbarkeit, misst hingegen die Fähigkeit eines Systems, die Leistung durch Hinzufügen von Ressourcen zu verbessern.

Diese Unterscheidung ist wichtig: Viele Ansätze zur Leistungsverbesserung verbessern die Skalierbarkeit überhaupt nicht, wenn sie richtig definiert sind. Ein einfaches Beispiel ist die Verwendung eines effizienteren digitalen Signaturschemas wie BLS-Signaturen, die etwa halb so groß sind wie Schnorr- oder ECDSA-Signaturen. Wenn Bitcoin von ECDSA auf BLS umsteigen würde, könnte die Anzahl der Transaktionen pro Block um 20–30 % steigen und die Leistung über Nacht verbessern. Aber das können wir nur einmal machen – es gibt kein noch platzsparenderes Signaturschema, zu dem wir wechseln könnten (BLS-Signaturen können auch aggregiert werden, um mehr Platz zu sparen, aber das ist ein weiterer einmaliger Trick).

Eine Reihe anderer einmaliger Tricks (wie SegWit) sind in Blockchains möglich, aber Sie benötigen eine skalierbare Architektur, um eine kontinuierliche Leistungsverbesserung zu erreichen, wobei das Hinzufügen weiterer Ressourcen die Leistung im Laufe der Zeit verbessert. Dies ist auch in vielen anderen Computersystemen die gängige Meinung, beispielsweise beim Aufbau eines Webservers. Mit ein paar gängigen Tricks können Sie einen sehr schnellen Server aufbauen; Letztendlich benötigen Sie jedoch eine Multi-Server-Architektur, die der ständig wachsenden Nachfrage durch kontinuierliche Hinzufügung zusätzlicher Server gerecht wird.

Das Verständnis der Unterscheidung hilft auch, den häufigen Kategoriefehler zu vermeiden, der in Aussagen wie „Blockchain X ist hoch skalierbar, sie kann Y Transaktionen pro Sekunde verarbeiten!“ auftritt. Die zweite Behauptung mag beeindruckend sein, aber sie ist eine Leistung Metrik, keine Skalierbarkeitsmetrik. Es spricht nicht für die Fähigkeit, die Leistung durch Hinzufügen von Ressourcen zu verbessern.

Skalierbarkeit erfordert grundsätzlich die Ausnutzung der Parallelität. Im Blockchain-Bereich scheint die Skalierung der Schicht 1 Sharding oder etwas, das wie Sharding aussieht, zu erfordern. Das Grundkonzept des Shardings – die Aufteilung des Zustands in Teile, damit verschiedene Validatoren unabhängig voneinander verarbeiten können – entspricht weitgehend der Definition von Skalierbarkeit. Auf Layer 2 gibt es noch mehr Optionen, die das Hinzufügen paralleler Verarbeitung ermöglichen – einschließlich Off-Chain-Kanälen, Rollup-Servern und Sidechains.

Latenz vs. Durchsatz

Klassischerweise wird die Leistung eines Blockchain-Systems in zwei Dimensionen bewertet: Latenz und Durchsatz: Die Latenz misst, wie schnell eine einzelne Transaktion bestätigt werden kann, während der Durchsatz die Gesamtrate der Transaktionen im Zeitverlauf misst. Diese Achsen gelten sowohl für Layer-1- und Layer-2-Systeme als auch für viele andere Arten von Computersystemen (z. B. Datenbankabfrage-Engines und Webserver).

Leider sind sowohl Latenz als auch Durchsatz komplex zu messen und zu vergleichen. Darüber hinaus ist den einzelnen Benutzern der Durchsatz (der ein systemweites Maß darstellt) eigentlich egal. Was ihnen wirklich am Herzen liegt, sind Latenz und Transaktionsgebühren – genauer gesagt, dass ihre Transaktionen so schnell und kostengünstig wie möglich bestätigt werden. Obwohl viele andere Computersysteme ebenfalls auf Kosten-Leistungs-Basis bewertet werden, sind Transaktionsgebühren eine etwas neue Leistungsachse für Blockchain-Systeme, die es in herkömmlichen Computersystemen nicht wirklich gibt.

Herausforderungen bei der Messung der Latenz

Die Latenz erscheint zunächst einfach: Wie lange dauert es, bis eine Transaktion bestätigt wird? Aber es gibt immer verschiedene Möglichkeiten, diese Frage zu beantworten.

Erstens können wir die Latenz zwischen verschiedenen Zeitpunkten messen und unterschiedliche Ergebnisse erhalten. Beginnen wir beispielsweise mit der Messung der Latenz, wenn der Benutzer lokal auf die Schaltfläche „Senden“ klickt oder wenn die Transaktion den Mempool erreicht? Und stoppen wir die Uhr, wenn sich die Transaktion in einem vorgeschlagenen Block befindet oder wenn ein Block mit einem oder sechs Folgeblöcken bestätigt wird?

Der gebräuchlichste Ansatz nimmt den Standpunkt von Validatoren ein und misst von dem Zeitpunkt an, an dem ein Kunde eine Transaktion zum ersten Mal sendet, bis zu dem Zeitpunkt, an dem eine Transaktion angemessen „bestätigt“ wird (in dem Sinne, dass echte Händler eine erhaltene Zahlung berücksichtigen und Waren freigeben würden). . Natürlich können verschiedene Händler unterschiedliche Akzeptanzkriterien anwenden, und sogar ein einzelner Händler kann je nach Transaktionsbetrag unterschiedliche Standards verwenden.

Der validatorzentrierte Ansatz lässt mehrere Dinge außer Acht, die in der Praxis wichtig sind. Erstens ignoriert es die Latenz im Peer-to-Peer-Netzwerk (wie lange dauert es von der Übertragung einer Transaktion durch den Client bis zu dem Zeitpunkt, an dem die meisten Knoten sie gehört haben?) und die Latenz auf der Clientseite (wie lange dauert die Vorbereitung einer Transaktion). auf dem lokalen Rechner des Clients?). Die clientseitige Latenz kann bei einfachen Transaktionen wie der Unterzeichnung einer Ethereum-Zahlung sehr gering und vorhersehbar sein, kann jedoch bei komplexeren Fällen wie dem Nachweis der Korrektheit einer geschützten Zcash-Transaktion erheblich sein.

Selbst wenn wir das Zeitfenster, das wir mit der Latenz messen möchten, standardisieren, lautet die Antwort fast immer es hängt davon ab, ob. Kein jemals gebautes Kryptowährungssystem bietet eine feste Transaktionslatenz. Eine grundlegende Faustregel, die Sie sich merken sollten, lautet:

Latenz ist eine Verteilung, keine einzelne Zahl.

Die Netzwerkforschungsgemeinschaft hat dies schon lange verstanden (siehe zum Beispiel hier). ausgezeichneter Vortrag von Gil Tene). Besonderes Augenmerk wird auf den „Long Tail“ der Verteilung gelegt, da eine stark erhöhte Latenz bei sogar 0.1 % der Transaktionen (oder Webserver-Anfragen) schwerwiegende Folgen haben kann Einfluss auf Endnutzer.

Bei Blockchains kann die Bestätigungslatenz aus mehreren Gründen variieren:

Chargenbildung: Die meisten Systeme stapeln Transaktionen auf irgendeine Weise, zum Beispiel in Blöcken auf den meisten Layer-1-Systemen. Dies führt zu variabler Latenz, da einige Transaktionen warten müssen, bis der Stapel voll ist. Andere haben vielleicht Glück und schließen sich der Gruppe als Letzter an. Diese Transaktionen werden sofort bestätigt und unterliegen keiner zusätzlichen Latenz.

Variabler Stau: Die meisten Systeme leiden unter Überlastung, was bedeutet, dass (zumindest zeitweise) mehr Transaktionen gebucht werden, als das System sofort verarbeiten kann. Die Überlastung kann unterschiedlich sein, wenn Transaktionen zu unvorhersehbaren Zeiten übertragen werden (oft abstrahiert als: Poisson-Prozess) oder wenn sich die Rate neuer Transaktionen im Laufe des Tages oder der Woche ändert oder als Reaktion auf externe Ereignisse wie eine beliebte NFT-Einführung.

Konsensschichtvarianz: Die Bestätigung einer Transaktion auf Schicht 1 erfordert normalerweise eine verteilte Gruppe von Knoten, um einen Konsens über einen Block zu erzielen, was unabhängig von der Überlastung zu variablen Verzögerungen führen kann. Proof-of-Work-Systeme finden Blöcke zu unvorhersehbaren Zeiten (abstrakt auch ein Poisson-Prozess). Proof-of-Stake-Systeme können auch verschiedene Verzögerungen verursachen (z. B. wenn nicht genügend Knoten online sind, um in einer Runde ein Komitee zu bilden, oder wenn als Reaktion auf den Absturz eines Leiters ein Meinungswechsel erforderlich ist).

Aus diesen Gründen ist eine gute Richtlinie:

Angaben zur Latenz sollten eine Verteilung (oder ein Histogramm) der Bestätigungszeiten darstellen und nicht eine einzelne Zahl wie den Mittelwert oder Median.

Während zusammenfassende Statistiken wie Mittelwert, Median oder Perzentile ein Teilbild liefern, erfordert die genaue Bewertung eines Systems die Berücksichtigung der gesamten Verteilung. In einigen Anwendungen kann die mittlere Latenz gute Erkenntnisse liefern, wenn die Latenzverteilung relativ einfach ist (z. B. Gauß). Bei Kryptowährungen ist dies jedoch fast nie der Fall: Typischerweise gibt es eine lange Reihe langsamer Bestätigungszeiten.

Ein gutes Beispiel sind Zahlungskanalnetzwerke (z. B. Lightning Network). Als klassische L2-Skalierungslösung bieten diese Netzwerke meist sehr schnelle Zahlungsbestätigungen, erfordern jedoch gelegentlich einen Kanal-Reset, der die Latenz um Größenordnungen erhöhen kann.

Und selbst wenn wir über gute Statistiken zur genauen Latenzverteilung verfügen, werden diese wahrscheinlich im Laufe der Zeit variieren, wenn sich das System und die Anforderungen an das System ändern. Es ist auch nicht immer klar, wie die Latenzverteilungen zwischen konkurrierenden Systemen verglichen werden können. Stellen Sie sich beispielsweise ein System vor, das Transaktionen mit einer gleichmäßig verteilten Latenzzeit zwischen 1 und 2 Minuten (mit einem Mittelwert und einem Median von 90 Sekunden) bestätigt. Wenn ein konkurrierendes System 95 % der Transaktionen genau in 1 Minute bestätigt und die anderen 5 % in 11 Minuten (mit einem Mittelwert von 90 Sekunden und einem Median von 60 Sekunden), welches System ist dann besser? Die Antwort ist wahrscheinlich, dass einige Anwendungen Ersteres und andere Letzteres bevorzugen würden.

Abschließend ist zu beachten, dass in den meisten Systemen nicht alle Transaktionen gleich priorisiert werden. Benutzer können mehr bezahlen, um eine höhere Einbindungspriorität zu erhalten. Zusätzlich zu all dem oben genannten variiert die Latenz in Abhängigkeit von den gezahlten Transaktionsgebühren. In Summe:

Latenz ist komplex. Je mehr Daten gemeldet werden, desto besser. Idealerweise sollten vollständige Latenzverteilungen unter unterschiedlichen Überlastungsbedingungen gemessen werden. Hilfreich sind auch Aufschlüsselungen der Latenz in verschiedene Komponenten (lokal, Netzwerk, Batchverarbeitung, Konsensverzögerung).

Herausforderungen bei der Durchsatzmessung

Auch der Durchsatz erscheint auf den ersten Blick einfach: Wie viele Transaktionen kann ein System pro Sekunde verarbeiten? Dabei treten vor allem zwei Schwierigkeiten auf: Was genau ist eine „Transaktion“ und messen wir, was ein System heute tut oder wozu es in der Lage sein könnte?

Während „Transaktionen pro Sekunde“ (oder tps) ein De-facto-Standard zur Messung der Blockchain-Leistung ist, sind Transaktionen als Maßeinheit problematisch. Bei Systemen, die allgemeine Programmierbarkeit („Smart Contracts“) oder sogar eingeschränkte Funktionen wie die Multiplex-Transaktionen von Bitcoin oder Optionen für die Multi-Sig-Verifizierung bieten, ist das grundlegende Problem:

Nicht alle Transaktionen sind gleich.

Dies gilt offensichtlich für Ethereum, wo Transaktionen beliebigen Code enthalten und den Status willkürlich ändern können. Der Begriff „Gas“ wird in Ethereum verwendet, um die Gesamtmenge an Arbeit, die eine Transaktion leistet, zu quantifizieren (und dafür Gebühren zu erheben). Dies ist jedoch sehr spezifisch für die EVM-Ausführungsumgebung. Es gibt keine einfache Möglichkeit, den Gesamtarbeitsaufwand einer Reihe von EVM-Transaktionen beispielsweise mit einer Reihe von Solana-Transaktionen in der BPF-Umgebung zu vergleichen. Der Vergleich mit einer Reihe von Bitcoin-Transaktionen ist ähnlich problematisch.

Blockchains, die die Transaktionsschicht in eine Konsensschicht und eine Ausführungsschicht unterteilen, können dies deutlicher machen. Auf der (reinen) Konsensschicht kann der Durchsatz in Bytes gemessen werden, die der Kette pro Zeiteinheit hinzugefügt werden. Die Ausführungsebene wird immer komplexer sein.

Einfachere Ausführungsebenen wie Rollup-Server, die nur Zahlungstransaktionen unterstützen, vermeiden die Schwierigkeit, Berechnungen zu quantifizieren. Allerdings können auch in diesem Fall die Zahlungen in der Anzahl der Ein- und Ausgänge variieren. Zahlungskanal Transaktionen können in der Anzahl der erforderlichen „Hops“ variieren, was sich auf den Durchsatz auswirkt. Und der Durchsatz des Rollup-Servers kann davon abhängen, inwieweit ein Transaktionsstapel auf einen kleineren Satz zusammenfassender Änderungen „verrechnet“ werden kann.

Eine weitere Herausforderung beim Durchsatz besteht darin, über die empirische Messung der heutigen Leistung hinauszugehen und die theoretische Kapazität zu bewerten. Dies führt zu allen möglichen Modellierungsfragen zur Bewertung der potenziellen Kapazität. Zunächst müssen wir uns für eine realistische Transaktionsarbeitslast für die Ausführungsschicht entscheiden. Zweitens erreichen reale Systeme fast nie die theoretische Kapazität, insbesondere Blockchain-Systeme. Aus Gründen der Robustheit hoffen wir, dass Knotenimplementierungen in der Praxis heterogen und vielfältig sind (und nicht, dass alle Clients eine einzige Softwareimplementierung ausführen). Dies macht die Durchführung genauer Simulationen des Blockchain-Durchsatzes noch schwieriger. 

Gesamt:

Angaben zum Durchsatz erfordern eine sorgfältige Erläuterung der Transaktionsarbeitslast und der Anzahl der Validatoren (Anzahl, Implementierung und Netzwerkkonnektivität). In Ermangelung eines klaren Standards genügen historische Workloads eines beliebten Netzwerks wie Ethereum.

Kompromisse zwischen Latenz und Durchsatz

Latenz und Durchsatz sind normalerweise ein Kompromiss. Als Lefteris Kokoris-Kogias UmrisseDieser Kompromiss verläuft jedoch häufig nicht reibungslos und weist einen Wendepunkt auf, an dem die Latenz stark ansteigt, wenn sich die Systemlast ihrem maximalen Durchsatz nähert.

Zero-Knowledge-Rollup-Systeme sind ein natürliches Beispiel für den Kompromiss zwischen Durchsatz und Latenz. Große Transaktionsmengen verlängern die Prüfzeit, was die Latenz erhöht. Aber der Fußabdruck in der Kette, sowohl in Bezug auf die Beweisgröße als auch auf die Validierungskosten, wird sich über mehr Transaktionen mit größeren Batch-Größen amortisieren, was den Durchsatz erhöht.

Transaktions Gebühren

Verständlicherweise legen Endbenutzer mehr Wert auf den Kompromiss zwischen Latenz und Gebühren, nicht Latenz und Durchsatz. Benutzer haben keinen direkten Grund, sich überhaupt um den Durchsatz zu kümmern, sondern nur, dass sie Transaktionen schnell und zu den geringstmöglichen Gebühren bestätigen können (wobei einige Benutzer sich mehr um Gebühren und andere mehr um die Latenz kümmern). Auf hohem Niveau werden die Gebühren von mehreren Faktoren beeinflusst:

1. Wie groß ist die Marktnachfrage nach Transaktionen?
2. Welchen Gesamtdurchsatz erreicht das System?
3. Wie viel Gesamtumsatz bietet das System den Validatoren oder Minern?
4. Wie viel dieser Einnahmen basiert auf Transaktionsgebühren im Vergleich zu inflationären Belohnungen?

Bei den ersten beiden Faktoren handelt es sich grob um Angebots-/Nachfragekurven, die zu einem markträumenden Preis führen (obwohl dies behauptet wurde). Bergleute agieren als Kartell, um die Gebühren über diesen Punkt hinaus zu erhöhen). Wenn alles andere gleich bleibt, sollte ein höherer Durchsatz tendenziell zu niedrigeren Gebühren führen, aber es passiert noch viel mehr.

Insbesondere die Punkte 3 und 4 oben sind grundlegende Fragen des Blockchain-Systemdesigns, für beide fehlen uns jedoch gute Prinzipien. Wir haben ein gewisses Verständnis für die Vor- und Nachteile, die es mit sich bringt, Bergleuten Einnahmen aus inflationären Belohnungen im Vergleich zu Transaktionsgebühren zu verschaffen. Trotz zahlreicher wirtschaftlicher Analysen von Blockchain-Konsensprotokollen verfügen wir jedoch immer noch über kein allgemein akzeptiertes Modell dafür, wie viel Umsatz an Validatoren gehen muss. Heutzutage basieren die meisten Systeme auf einer fundierten Schätzung darüber, wie viel Umsatz ausreicht, um ein ehrliches Verhalten der Prüfer sicherzustellen, ohne die praktische Nutzung des Systems zu beeinträchtigen. In vereinfachten Modellen Es kann gezeigt werden, dass die Kosten für die Durchführung eines 51-Prozent-Angriffs mit den Belohnungen für Validatoren skalieren.

Die Kosten für Angriffe zu erhöhen ist eine gute Sache, aber wir wissen auch nicht, wie viel Sicherheit „ausreichend“ ist. Stellen Sie sich vor, Sie überlegen, in zwei Vergnügungsparks zu gehen. Einer von ihnen gibt an, 50 % weniger für die Wartung seiner Fahrgeschäfte auszugeben als der andere. Ist es eine gute Idee, in diesen Park zu gehen? Möglicherweise sind sie effizienter und bieten die gleiche Sicherheit für weniger Geld. Vielleicht gibt man zum anderen mehr aus, als nötig ist, um die Fahrgeschäfte sicher zu halten, ohne dass es einen Nutzen bringt. Es könnte aber auch sein, dass der erste Park gefährlich ist. Blockchain-Systeme sind ähnlich. Wenn man den Durchsatz herausrechnet, haben Blockchains mit niedrigeren Gebühren niedrigere Gebühren, weil sie ihre Validatoren weniger belohnen (und daher weniger Anreize bieten). Wir verfügen heute nicht über gute Tools, um zu beurteilen, ob dies in Ordnung ist oder das System dadurch anfällig für Angriffe macht. Gesamt:

Der Vergleich der Gebühren zwischen Systemen kann irreführend sein. Obwohl Transaktionsgebühren für Benutzer wichtig sind, werden sie neben dem Systemdesign selbst von vielen Faktoren beeinflusst. Der Durchsatz ist eine bessere Messgröße für die Analyse eines Systems als Ganzes.

Zusammenfassung

Es ist schwierig, die Leistung fair und genau zu bewerten. Dies gilt auch für die Messung der Leistung eines Autos. Genau wie bei Blockchains kümmern sich verschiedene Menschen um unterschiedliche Dinge. Bei Autos legen einige Benutzer Wert auf Höchstgeschwindigkeit oder Beschleunigung, andere auf den Benzinverbrauch und wieder andere auf die Anhängelast. All dies ist nicht trivial zu bewerten. In den USA beispielsweise verfügt die Environmental Protection Agency über detaillierte Richtlinien dazu, wie der Kraftstoffverbrauch bewertet wird und wie er den Benutzern bei einem Händler präsentiert werden muss.

Von diesem Standardisierungsgrad ist der Blockchain-Bereich weit entfernt. In bestimmten Bereichen könnten wir in Zukunft mit standardisierten Workloads zur Bewertung des Durchsatzes eines Systems oder standardisierten Diagrammen zur Darstellung von Latenzverteilungen dorthin gelangen. Derzeit besteht der beste Ansatz für Gutachter und Bauherren darin, so viele Daten wie möglich zu sammeln und zu veröffentlichen, zusammen mit einer detaillierten Beschreibung der Bewertungsmethodik, damit diese reproduziert und mit anderen Systemen verglichen werden kann.