Sprecher: Vitalik Buterin
Zusammengestellt von: Yuliya, PANews
Hallo zusammen! Willkommen bei ETHShanghai 2026. Heute möchte ich mit euch ein recht komplexes technisches Thema diskutieren, das für die Zukunft von Ethereum entscheidend ist – es kann Ethereum ermöglichen, eine extrem hohe Skalierbarkeit zu erreichen und gleichzeitig Privatsphäre und Dezentralisierung in Einklang zu bringen, und alle drei können gleichzeitig erreicht werden. Dieser Vorschlag wird sehr wahrscheinlich die Betriebsarchitektur vieler Komponenten in der Blockchain wirklich verändern. Er kann viele Dinge ändern, aber überraschenderweise ist es nicht allzu schwierig, ihn tatsächlich in das bestehende Ethereum zu integrieren. Das ist EIP-8288: Rekursive Signatur und Aggregation.
Kernproblem: Die Unvereinbarkeit von Sicherheit, Privatsphäre und Skalierbarkeit
Heute möchte ich mich auf einige wichtige Themen konzentrieren, die euch sehr am Herzen liegen: Quantensicherheit, Privatsphäre und Skalierbarkeit. Derzeit besteht ein großes Problem darin, dass sowohl Quantensicherheit als auch Privatsphäre derzeit stark mit der Skalierbarkeit kollidieren:
Eine normale Ethereum-Transaktion verbraucht derzeit etwa 21.000 Gas; die unabhängige Verifizierung einer ECDSA-Signatur (etwa 65 Bytes) dauert etwa 4.000 Gas.
Wenn man sie durch quantensichere Signaturen ersetzt (unabhängig davon, welcher Typ von Post-Quanten-Signaturschema), wird der Gasverbrauch grob zwischen 100.000 und 300.000 Gas liegen, abhängig von der gewählten Parametergröße (zum Beispiel, ob sie mit Blockchain-Wallet-Szenarien kompatibel sein muss). Aber egal, wie man wählt, die Kosten werden um ein Vielfaches höher sein als bei heutigen Transaktionen – quantensichere Signaturen sind groß und teuer.
Das zweite Problem: Beweise für Privatsphäre-Protokolle sind ebenfalls groß und teuer. Wenn jemand ein Privatsphäre-Protokoll verwendet hat, das auf Zero-Knowledge-Technologie (ZK) basiert, weiß er, dass solche Operationen auf Ethereum mindestens etwa 350.000 Gas kosten. Da viele solcher Protokolle nicht sehr effizient gestaltet sind, können die tatsächlichen Kosten manchmal sogar etwa 1 Million Gas erreichen – das ist sehr teuer. Heute kostet eine normale Transaktion vielleicht nur ein paar Cent, während solche Transaktionen 20 Cent oder sogar zwei Dollar kosten können.
Ein noch gravierenderes Problem ist: Wenn man sowohl Quantensicherheit als auch Privatsphäre möchte, muss man STARK-Beweise verwenden, um die vorherigen Schemata zu ersetzen. Allerdings verbraucht ein STARK-Beweis etwa 8 Millionen Gas, und sehr wahrscheinlich mehr. Das heißt, wenn wir jetzt alle dazu bringen würden, „quantensichere + Privatsphäre“-Transaktionen zu verwenden, würde die ursprüngliche Verarbeitungskapazität von Ethereum von etwa 25 TPS auf etwa 0,25 TPS abstürzen und fast die Nutzbarkeit verlieren.
Ein weiteres Problem ist: Man möchte möglicherweise auch benutzerdefinierte kryptografische Schemata unterstützen. Zum Beispiel der Wechsel von den heutigen elliptischen Kurven zur zukünftigen gitterbasierten Kryptografie. Das Problem ist, dass jedes Mal, wenn man solche neuen Schemata unterstützen möchte, die Größe des Protokolls selbst zunimmt und mehr Vorberechnungsdateien benötigt werden (groß in der Größe, hohe Kosten). Und wenn man diese Schemata nicht nativ in der EVM unterstützt oder keine entsprechenden Vorberechnungsdateien hat, dann wird die Verifizierung einer solchen Signatur on-chain eine sehr große Menge Gas verbrauchen.
Mit anderen Worten, alle unsere Ziele in Bezug auf Sicherheit und Privatsphäre behindern tatsächlich die Skalierbarkeit, zumindest unter der aktuellen Architektur.
Kernlösung: Aggregationsberechnung vorverlagern in den Mempool
Wie lösen wir also dieses Problem? Das ist der Kernmechanismus, der von EIP-8288 implementiert wird.
Die Kernidee ist: Anstatt all diese Signaturen und all diese STARK-Beweise (diese riesigen, strukturell komplexen Objekte) direkt on-chain zu legen, halten wir sie off-chain und schließen die Aggregation innerhalb des Mempools ab.
Konkret: Wenn ein Benutzer eine Transaktion sendet, gibt es eine Gruppe von Knoten im Mempool, und diese Knoten arbeiten bereits, bevor die Transaktion in einen Block verpackt wird. Was diese Knoten tun, wird „Aggregation“ genannt – sie ersetzen eine große Anzahl von Signaturen und Beweisen durch einen einzigen Beweis, der verifizieren kann, dass all diese Signaturen und Beweise wirklich existieren und gültig sind.
Aus der Perspektive des Nutzers also: Der Nutzer sendet eine Transaktion, und zusammen mit der Transaktion sendet er auch dieses riesige Objekt (Signatur/Beweis), aber dieses riesige Objekt selbst geht niemals tatsächlich on-chain. Was tatsächlich on-chain geht, ist nur ein einziger STARK-Beweis, der verwendet wird, um zu verifizieren, dass alle Signaturen und alle Beweise, die in allen Nutzertransaktionen enthalten sind, wirklich existieren und gültig sind.
Dieser Mechanismus baut auf EIP-8141 (native Account-Abstraktion) auf, die im nächsten Hard Fork eingeführt wird. EIP-8141 verdichtet fast ein Jahrzehnt Forschung der Ethereum-Community auf dem Gebiet der Account-Abstraktion. Sie ermöglicht es jeder Transaktion, ihre Bestandteile, Signaturspezifikationen und Verifikationsalgorithmen direkt und präzise explizit zu deklarieren, was Transaktionen eine stärkere Programmierbarkeit und typisierte Struktur verleiht.
In EIP-8288 haben wir einen neuen Frame-Typ hinzugefügt, der als „Abhängigkeit“ verstanden werden kann. Es gibt insgesamt zwei Arten von Abhängigkeiten: Eine entspricht Signaturen, und eine entspricht Beweisen (STARK). Anders als beim aktuellen Modell, bei dem Signaturen direkt in den Transaktionskörper eingebettet sind, enthält die Transaktion selbst unter dem neuen Mechanismus nur eine abstrakte Deklaration, die angibt, von welcher Art von Signatur und Beweis die Transaktion abhängt. Wenn die Transaktion gebroadcastet wird, wird zwar die vollständige Datenmenge mitgesendet, aber was letztendlich in den Block geschrieben wird, ist nur die Mikro-Frame-Struktur, die die Abhängigkeiten trägt. Die Daten, die jede Abhängigkeit belegt, betragen nur 96 Bytes, und die meisten sogar nur 65 Bytes. Der Rest der riesigen kryptografischen Entitäten wird im Mempool absorbiert und aggregiert und erscheint letztendlich im Blockchain-Ledger nur in Form eines einzigen Beweises.
Unter dieser Architektur hört jeder Knoten im Mempool kontinuierlich auf einen Datenträger, der „Envelope“ genannt wird. Ein einzelner Envelope kann mehrere Transaktionen und ihre begleitenden Beweise kapseln.
Knoten verwenden einen festen Zeitraum als Fenster, sammeln kontinuierlich alle während dieses Zeitraums beobachteten Envelope-Objekte, führen eine lokale Aggregationsberechnung durch und broadcasten sie dann. Während des Broadcasts wurden alle ursprünglich diskreten unabhängigen Beweise durch einen globalen aggregierten Beweis ersetzt, der mathematisch streng die Korrektheit aller zugrunde liegenden Signaturen in diesem Batch abdeckt.
Dies zeigt, dass das Ethereum-Netzwerk, bevor die Block-Packaging-Knoten formell Zustandsaktualisierungen ausführen, bereits die überwiegende Mehrheit der hochintensiven Verifikationsberechnung in der Mempool-Phase in der Nicht-Konsens-Schicht abgeschlossen hat.
Architektonisches Wesen: „Spezialisiertes Sharding“
Eine Möglichkeit, diesen Mechanismus zu verstehen, besteht darin, ihn als eine Art spezialisiertes Sharding zu betrachten. Seine Idee ist: Wir können die extrem teuren Teile der Berechnung, die extrem große Datenmengen betreffen, herausgreifen und das gesamte verteilte Netzwerk diesen Teil der Berechnung auf sehr lockere, unstrukturierte Weise parallel verarbeiten lassen.
Dieser Ansatz ist nicht fragil; im Gegenteil, er ist sehr robust – jeder Knoten kann jeden Teil dieser Arbeit übernehmen. Was wir tun, ist im Wesentlichen, jede Transaktion in zwei Teile aufzuteilen:
Ein Teil erklärt, „was diese Transaktion tut, wie sie mit dem Zustand interagiert und wie sie mit anderen Transaktionen interagiert“;
Der andere Teil ist der riesige, kostspielige Teil dieser Transaktion – das heißt, reine Verifikationsarbeit.
Indem die Verifikationslast gezielt geshardet und abgetrennt wird, wird die Datenlast, die die Konsensschicht der Hauptkette letztendlich von allen Netzwerkverifikationsknoten gemeinsam getragen werden muss, strikt auf einen extrem kleinen Bereich von 100 bis 300 KB pro Block komprimiert. Dieser Overhead beträgt nur etwa das Doppelte des aktuellen Ethereum-Blockdatenvolumens, und da der Gesamtdurchsatz des Netzwerks linear expandiert, wird der Anteil dieses konstanten Overheads an der gesamten Netzwerklast weiter verdünnt.
Im Wesentlichen tun wir Folgendes: Wir verlagern Arbeit weg von Validatoren und sogar weg von den Knoten, die Blöcke packen, und schieben diesen Teil der Arbeit zu jenen Off-Chain-Knoten, die sich zwischen „der Nutzer sendet eine Transaktion“ und „der Knoten, der den Block packt, nimmt die Transaktion tatsächlich in den Block auf“ befinden.
Was bedeutet das für Ethereum?
Aus technischer Sicht bedeutet dies, dass Ethereum eine bestimmte Klasse von Berechnungen hyperskaliert. Ich denke, dies ist auch ein Trend, den wir mit der weiteren Entwicklung von Ethereum immer häufiger sehen werden.
Ethereum, vor zehn Jahren geboren, konzentrierte sich auf vollständig allgemeine Berechnung, entbehrte aber auch vollständig der Skalierbarkeit. Was wir jetzt also tun, ist, Berechnung in verschiedene Typen aufzuteilen und dann gezielt jene Arten von Berechnung, die „von Natur aus besser für Skalierung geeignet“ sind, extrem skalierbar zu machen – wir bauen diese spezialisierteren „kleinen Werkzeuge“, um dies zu erreichen.
Gleichzeitig machen wir auch die Berechnungen, die auf weniger effiziente Weise behandelt werden müssen, kleiner und leichter handhabbar. EIP-8288 ist genau die Hyper-Skalierung zweier Arten von Objekten: „Signaturverifikation“ und „Zero-Knowledge-Proof-Verifikation“.
Ein weiterer interessanter Punkt ist folgender: Ich weiß, dass viele Menschen schon lange neugierig darauf sind, wann Ethereum auf RISC-V umsteigen wird – denn im Vergleich zum aktuellen Ansatz ist RISC-V oder ein anderes moderneres Befehlssatz-System weitaus effizienter und auch viel einfacher. Und EIP-8288 wird sehr wahrscheinlich das erste Szenario auf Ethereum werden, das wirklich RISC-V (oder einen ähnlichen Befehlssatz) einführt. Der Grund dafür ist, dass EIP-8288 es Nutzern ermöglicht, Proofs einzureichen, und wenn Nutzer Proofs einreichen, müssen sie eine Sprache verwenden, um die Aussagen auszudrücken, die sie verifizieren – RISC-V ist genau diese Sprache.
Das heißt, in RISC-V ausgedrückte Verifikationslogik muss lokal auf dem Client des Nutzers nur als eine einzige physische Berechnung ausgeführt werden: Der Nutzer erzeugt den entsprechenden Proof (in Datenschutzszenarien ist dies ein ZK-STARK) und schiebt ihn dann sofort in den Mempool; der erste Relay-Knoten, der folgt, wird ihn sofort rekursiv zusammen mit Hunderten oder Tausenden ähnlicher Proofs im gesamten Netzwerk zu einer einzigen Entität komprimieren.
Dies entspricht auch einer Aufteilung der gesamten Berechnung in zwei große Kategorien:
Eine Kategorie sind „Abhängigkeiten“ – das heißt die Teile, die garantiert korrekt sein müssen, damit die Transaktion gültig ist;
Die andere Kategorie ist „Geschäftslogik“ – das heißt, was die Transaktion selbst tatsächlich tut.
Geschäftslogik kann dadurch leichter und sauberer werden, was auch bedeutet, dass der Teil der Block-Building-Logik, der von der Transaktionsreihenfolge abhängt, ebenfalls einfacher wird. Und der Teil der „Abhängigkeiten“ kann in extrem großem Maßstab parallel verarbeitet werden, wobei praktisch keine größeren Änderungen an der Entwicklungserfahrung von Ethereum-Entwicklern erforderlich sind.
Der praktische Wert für Entwickler, Nutzer und Layer 2
Für jeden, der Anwendungen on-chain entwickelt, ist die zentrale Bedeutung all dessen: Die teuersten Operationen von heute werden viel billiger werden.
Der Ausführungsaufwand quantensicherer Transaktionen wird auf ein nahezu vernachlässigbares niedriges Niveau komprimiert;
Datenschutzbewahrende Anwendungen, die auf zk-SNARK/STARK aufbauen, werden den Einschränkungen hoher Gas-Gebühren entkommen, zu erschwinglichen Kosten weit verbreitet sein und von Natur aus Quantenresistenz besitzen.
Über Datenschutzszenarien hinaus wird die Anwendungseffizienz von zk-SNARK bei der Skalierung (insbesondere Layer 2) einen qualitativen Sprung machen. Derzeit sind viele ZK-Rollups, um die hohen Gas-Kosten für die Veröffentlichung von Zustands-Proofs im Mainnet zu amortisieren, oft gezwungen, den Einreichungszyklus zu verlängern und in Batches mit Frequenzen von zehn Minuten oder sogar einer Stunde abzurechnen. Dies schränkt die endgültige Bestätigungsgeschwindigkeit in Zeiten geringer Netzwerktransaktionsaktivität stark ein.
Derzeit sind viele ZK-Rollups, um die hohen Gas-Kosten für die Veröffentlichung von Zustands-Proofs im Mainnet zu amortisieren, oft gezwungen, den Einreichungszyklus zu verlängern und in Batches mit Frequenzen von zehn Minuten oder sogar einer Stunde abzurechnen. Dies schränkt die endgültige Bestätigungsgeschwindigkeit in Zeiten geringer Netzwerktransaktionsaktivität stark ein.
Die Endgame-Evolution: Berechnung vollständig an den Rand verlagern
Wenn es schließlich andere Berechnungen gibt, die Sie durchführen möchten, die aber zu teuer sind, um sie innerhalb der EVM auszuführen, hoffe ich, dass wir wirklich beginnen können, die Richtung zu ändern – nicht länger das Ethereum-Protokoll selbst all die Berechnungen direkt tragen zu lassen, die jeder durchführen möchte, sondern stattdessen Nutzer zu ermutigen, diesen Teil der Berechnung lokal auf ihren Clients abzuschließen und dann einen Proof zu veröffentlichen, sodass dieser Proof auf Ethereum verifiziert wird.
Im Wesentlichen ist dies die Skalierung von Ethereum, indem Berechnung aus dem „Zentrum“ der Chain heraus und an den „Rand“ verlagert wird. Das Ergebnis ist: Die Dinge, die auf Ethereum heute am teuersten sind (verschiedene Formen von Sicherheit, verschiedene Formen von Datenschutz und verschiedene Formen der Kompatibilität mit externen Anwendungen), werden heute von niemandem gemacht, weil sie zu teuer sind, und in Zukunft werden sie alle viel billiger und für jeden wirklich nutzbar werden.
Ich hoffe, dies ist nur der erste Schritt, um Ethereum von der Architektur, die es fast seit seiner Geburt verwendet hat, in eine völlig andere und noch leistungsfähigere neue Architektur zu verwandeln – eine neue Architektur, die wirklich zwei Dinge vereint: Zum einen die sehr einfache frühe Blockchain-Idee von Satoshi Nakamoto; zum anderen die extrem leistungsfähige und extrem moderne kryptografische Technologie, die wir seitdem kontinuierlich angesammelt haben.
Ökosystem-Beteiligung und Implementierungsfortschritt
Derzeit werden rund um diesen Ansatz intensiv frühe Erkundungen und Engineering-Validierungen durchgeführt, und die technische Community kann bereits über mehrere Einstiegspunkte am Aufbau teilnehmen:
Simulationsmodelle auf Netzwerkebene: Frühe Simulationstools für Mempool-Topologie und Aggregations-Propagationsmechanismen wurden geöffnet;
Testnetz-Betrieb: Das EIP-8141-Testnetz, das die Frame-Transaktionsform unterstützt, wurde in den Testbetrieb überführt;
Algorithmus-Optimierungswettbewerbe: Spezielle Algorithmuswettbewerbe für die Entwickler-Community werden vorangetrieben, mit Fokus auf effiziente Implementierung des zugrunde liegenden Beweissystems;
Code-Implementierung und -Verifikation: Die zugrunde liegende Prototyp-Codebasis hat Gestalt angenommen, damit Ökosystem-Entwickler unabhängige Client-Implementierungen und formale Verifikation durchführen können.
Eine große Anzahl zugrunde liegender technischer Bausteine wird schnell ergänzt. Entwickler sind eingeladen, sich tiefgehend an diesem technischen Prozess zu beteiligen und dazu beizutragen, dass diese revolutionäre Architektur so bald wie möglich zu einem Realitätsstandard im Ethereum-Mainnet wird.
