Der Ethereum-Mitbegründer Vitalik Buterin hat EIP-8288 als vorgeschlagenen Weg unterstützt, komplexe Kryptographie zu unterstützen, ohne wiederholt neue Verifizierungsfunktionen zu Ethereum hinzuzufügen, und argumentiert, dass die meiste schwere kryptographische Arbeit außerhalb des Hauptausführungsprozesses des Netzwerks stattfinden sollte.
Zusammenfassung
- Vitalik Buterin möchte, dass Ethereum komplexe Kryptographie durch aggregierte Beweise verifiziert, anstatt durch wiederholte Protokoll-Upgrades.
- EIP-8288 schlägt vor, kryptographische Signaturen und STARK-Beweise zu kombinieren, bevor Ethereum-Validatoren deren kollektive Gültigkeit effizient verifizieren.
- Der Vorschlag könnte quantenresistente Wallet-Signaturen unterstützen, ohne dass für jeden Signaturtyp separate Ethereum-Precompiles erforderlich sind.
- Ethereum-Entwickler haben EIP-8288 nicht genehmigt; es bleibt ein Entwurf, der weitere Implementierung und Netzwerkkonsens erfordert.
- Das vorgeschlagene System würde große Beweise außerhalb der Blockdaten halten und gleichzeitig Transaktionsverpflichtungen zur Verifizierung beibehalten.
In einer Reihe von Beiträgen vom 19. Oktober auf X argumentierte Buterin, dass die bestehende virtuelle Maschine von Ethereum und die spezialisierten kryptographischen Funktionen nicht geeignet seien, jedes neue Signatur- oder Beweissystem zu unterstützen. Stattdessen befürwortete er ein Design, das es Nutzern ermöglichen würde, Beweise lokal zu erzeugen und sie über einen Aggregationsmechanismus einzureichen.
Der Vorschlag EIP-8288 würde es Ethereum ermöglichen zu verifizieren, dass kryptographische Operationen korrekt ausgeführt wurden, ohne jede ursprüngliche Signatur oder jeden Beweis in einen Block aufzunehmen.
Vitalik Buterin beschrieb diesen Ansatz als Teil seiner Vision von Ethereum als einem kryptographischen Weltcomputer, bei dem umfangreiche Berechnungen außerhalb der Blockchain stattfinden können, während ihre Ergebnisse verifizierbar bleiben.
Die Spezifikation bleibt ein Entwurf und wurde nicht für den Einsatz im Ethereum-Mainnet genehmigt.
Vitalik Buterin möchte weniger kryptographische Arbeit innerhalb von Ethereum
Die neuesten Kommentare von Vitalik Buterin konzentrieren sich darauf, wie Ethereum mit kryptographischen Operationen umgeht, die große Mengen an Berechnung oder Daten erfordern.
Derzeit können Entwickler die Ethereum Virtual Machine, kurz EVM, nutzen, um Smart Contracts auszuführen, die bestimmte kryptographische Aussagen verifizieren.
Ethereum bietet Precompiles, bei denen es sich um integrierte Funktionen handelt, die bestimmte Berechnungen effizienter als gewöhnlicher Smart-Contract-Code ausführen.
Diese Funktionen können Entwicklern helfen, Signaturen, Hashes und Zero-Knowledge-Beweise zu verifizieren.
Die direkte Unterstützung zusätzlicher kryptographischer Methoden über Precompiles kann jedoch Änderungen am Ethereum-Protokoll erfordern.
Vitalik Buterin argumentierte, dass keiner der beiden Ansätze zur Standardlösung für jedes neue kryptographische System werden sollte.
Seine Besorgnis konzentriert sich auf die Datenmenge, die in Ethereum-Blöcken enthalten sein muss, wenn Anwendungen große Signaturen oder kryptographische Beweise zur Verifizierung einreichen.
In der Diskussion vom 19. Oktober schätzte er, dass das Netzwerk selbst mit Verbesserungen wie PeerDAS und Blocks-in-Blobs praktische Grenzen von etwa 8 Megabyte pro Sekunde erreichen würde, bevor zusätzliche Daten schwierig zu handhaben würden.
Die Schätzung stellt Buterins Einschätzung zukünftiger technischer Einschränkungen dar, nicht den derzeit gemessenen Transaktionsdurchsatz von Ethereum.
Er beschrieb Ethereum als einen kryptographischen Weltcomputer, bei dem die Blockchain nur Informationen verarbeiten sollte, die eine gemeinsame Ausführung und Verifizierung erfordern.
Die Idee steht im Einklang mit seiner früheren Arbeit zur Reduzierung der Berechnungsmenge, die jeder Ethereum-Validator unabhängig ausführen muss.
Im September berichtete crypto.news über seine Vision eines kryptografischen Computers, die Ethereums vorgeschlagenen Übergang zu proof-basierter Verifikation, Privatsphäre und effizienterer Datenverarbeitung beschrieb.
Seine Oktober-Kommentare konzentrierten sich auf einen konkreten Vorschlag, um diesen Ansatz über verschiedene kryptografische Systeme hinweg funktionsfähig zu machen.
EIP-8288 würde Proofs kombinieren, bevor sie Ethereum erreichen
Der vorgeschlagene Mechanismus wird in EIP-8288 mit dem Titel In-mempool signature and proof aggregation beschrieben.
Buterin und der Ethereum-Forscher Thomas Coratger erstellten den Vorschlag am 3. Juni 2026.
Laut der offiziellen Spezifikation würde das System es Transaktionen ermöglichen, zu deklarieren, welche kryptografischen Aussagen verifiziert werden müssen, ohne dass das gesamte ursprüngliche Proof-Material in den finalen Block aufgenommen wird.
Diese Deklarationen würden das Verifikationsschema, einen Hash, der die relevanten Daten repräsentiert, und einen Hash, der dem Verifikationsschlüssel zugeordnet ist, identifizieren.
Das Netzwerk würde diese Referenzen nutzen, um Transaktionen mit Nachweisen zu verbinden, dass die erforderlichen Operationen korrekt ausgeführt wurden.
Nutzer würden Signaturen oder kryptografische Proofs außerhalb der Haupausführungsumgebung von Ethereum erzeugen.
Der Vorschlag erlaubt es, diese Proofs rekursiv zu kombinieren, was bedeutet, dass ein Proof die Gültigkeit mehrerer kleinerer Proofs belegen kann.
Anstatt jede einzelne ursprüngliche Signatur und jeden STARK individuell zu verifizieren, würde Ethereum einen aggregierten Proof verifizieren, der die relevanten Transaktionsabhängigkeiten abdeckt.
Ein STARK ist ein kryptografischer Proof, der es ermöglicht, zu demonstrieren, dass eine Berechnung korrekt ausgeführt wurde, ohne dass jeder Verifizierer die gesamte Berechnung wiederholen muss.
Das vorgeschlagene Aggregationssystem würde Lean Ethereum Tooling verwenden, um diese Proofs zu erzeugen und zu verifizieren.
EIP-8288 beschreibt einen neuen Transaktionsrahmenmodus, der kryptografische Abhängigkeiten deklarieren würde. Der Vorschlag baut auf EIP-8141 auf, das einen Rahmen für Transaktionen mit mehreren Ausführungs- und Verifikationsschritten einführt.
Auf Blockebene würde ein rekursiver STARK demonstrieren, dass die deklarierten Abhängigkeiten erfüllt wurden.
Das System würde weiterhin die notwendigen Transaktionsinformationen und kryptografischen Commitments auf Ethereum aufzeichnen.
Sein beabsichtigtes Design würde jedoch vermeiden, die ursprünglichen großen Signaturen und Proofs als gewöhnliche Transaktions-Calldata zu veröffentlichen.
Der Vorschlag ist kein Plan, alle Transaktionsdaten von der Blockchain zu entfernen oder Anwendungen zu erlauben, ohne verifizierbare Aufzeichnungen zu operieren.
Quantenresistente Signaturen sind ein wesentlicher Bestandteil des Vorschlags
EIP-8288 enthält Unterstützung für kryptografische Signaturen, die darauf ausgelegt sind, Angriffen zukünftiger Quantencomputer zu widerstehen.
Ethereum stützt sich derzeit auf etablierte digitale Signatursysteme für die Kontenauthentifizierung und den Blockchain-Konsens.
Entwickler erforschen Alternativen, die sicher bleiben würden, falls ausreichend leistungsfähige Quantencomputer verfügbar werden.
Einige vorgeschlagene quantenresistente Signaturen sind viel größer als die Signaturen, die in herkömmlichen Ethereum-Transaktionen verwendet werden.
Laut EIP-8288 können hash-basierte Signaturen, die in Betracht gezogen werden, etwa 2–3 Kilobyte und geschätzte 150.000–200.000 Gas erfordern, um direkt verifiziert zu werden.
Gitterbasierte Signaturen stellen in der Kostendiskussion des Vorschlags vergleichbare Herausforderungen dar.
STARK-Proofs können mehr als 128 Kilobyte erfordern, wobei einige Konfigurationen etwa 512 Kilobyte erreichen, wenn sie für eine schnelle Proof-Erzeugung optimiert sind.
Große Mengen dieses Materials direkt in Transaktionen aufzunehmen, könnte erhebliche Daten- und Ausführungskosten verursachen.
Vitalik Buterin argumentierte, dass Nutzer in der Lage sein sollten, ihre bevorzugten Signaturen lokal zu erzeugen und deren Gültigkeit durch STARK-Aggregation zu beweisen.
Er erörterte die Möglichkeit, gitterbasierte Kryptografie für Ethereum-Konten und -Wallets zu verwenden, falls die relevanten Sicherheitsannahmen etabliert würden.
Seine Erklärung vom 19. Oktober bezog sich ausdrücklich auf Kryptographie, die möglicherweise als sicher gegen KI-bezogene Angriffe nachgewiesen werden könnte. Diese Bedingung ist getrennt von der Standarddefinition der Widerstandsfähigkeit gegen Angriffe durch Quantencomputer.
Eine frühere Berichterstattung über Ethereums Roadmap beschrieb, wie Quantenresistenz und Privatsphäre zu Prioritäten für die zukünftige Entwicklung des Netzwerks geworden sind.
Die Roadmap umfasst Änderungen an der Signaturverifikation und den kryptographischen Systemen, die Ethereums Konsens und Datenverfügbarkeit unterstützen.
EIP-8288 adressiert einen Teil dieser Arbeit, indem es eine gemeinsame Methode zur Verifizierung mehrerer kryptographischer Schemata vorschlägt.
Rekursive Aggregation würde vor der Blockproduktion beginnen
Der vorgeschlagene Prozess hängt nicht ausschließlich von einem Blockproduzenten ab, der jede Signatur sammelt und einen finalen Beweis erzeugt.
EIP-8288 beschreibt eine rekursive Aggregation, die im Mempool von Ethereum beginnt, wo Transaktionen warten, bevor sie in Blöcke aufgenommen werden.
Nach diesem Design würden Benutzer Transaktionen zusammen mit den kryptographischen Nachweisen einreichen, die zu ihrer Autorisierung erforderlich sind.
Mempool-Teilnehmer könnten die eingereichten Nachweise validieren, mehrere Beweise zu einem zusammenfassen und das resultierende Paket an andere Teilnehmer weitergeben.
Die Spezifikation beschreibt ein Aggregationsintervall von 1.000 Millisekunden für diesen Prozess.
Block-Builder würden dann die relevanten Transaktionen und aggregierten Beweise sammeln, bevor sie einen Ethereum-Block konstruieren.
Ein finaler rekursiver STARK würde die Abhängigkeiten abdecken, die mit den zur Aufnahme ausgewählten Transaktionen verbunden sind.
Der Entwurf schlägt technische Grenzen vor, die verhindern sollen, dass böswillige Benutzer das Aggregationssystem mit übermäßigen Beweisanforderungen überlasten.
Beispielsweise erlauben seine aktuellen Parameter bis zu 16 spezifizierte Signaturabhängigkeiten und eine STARK-Abhängigkeit pro Transaktion.
Die Spezifikation behandelt auch die Kompatibilität mit FOCIL, einem vorgeschlagenen Transaktionsaufnahmemechanismus, der Zensur erschweren soll.
Eine im September veröffentlichte Ethereum-Analyse der beweisbasierten Verifizierung untersuchte die Unterscheidung zwischen der Verifizierung des Ergebnisses einer Berechnung und der Sicherstellung, dass die zugrunde liegenden Daten zugänglich bleiben.
EIP-8288 adressiert die kryptographische Verifizierung, während die Transaktionsinformationen erhalten bleiben, die zur Identifizierung und Validierung von Abhängigkeiten erforderlich sind.
Sein Design führt zusätzliche Arbeit für Mempool-Teilnehmer und Block-Builder ein, die Beweise generieren, aktualisieren und kombinieren müssten. Der Sicherheitsabschnitt des Vorschlags identifiziert die Korrektheit der Beweisschaltkreise, Hashfunktionen und der rekursiven Verifizierung als Annahmen, die einer sorgfältigen Bewertung bedürfen.
EIP-8288 bleibt ein Entwurf, der die Genehmigung des Netzwerks erfordert
Das offizielle Repository für Ethereum Improvement Proposals klassifiziert EIP-8288 als einen Entwurf eines Standards-Track-Vorschlags in der Kategorie Core.
Seine Implementierung würde Ethereums Konsensregeln ändern, da Blöcke, die das vorgeschlagene rekursive Beweisformat enthalten, von Knoten, die Software ohne das Update betreiben, nicht verstanden würden.
Die Spezifikation identifiziert EIP-2718 und EIP-8141 als Abhängigkeiten. Mehrere Implementierungsdetails bleiben unvollständig, darunter Parameter im Zusammenhang mit dem aggregierten Verifizierungsschlüssel und dem Dependency-Hashing.
Die Referenzimplementierung des Vorschlags ist als ausstehend aufgeführt. Ethereum-Entwickler müssten die technische Arbeit abschließen, die Sicherheitsannahmen überprüfen und sich auf die Netzwerkaktivierung einigen, bevor das Design bereitgestellt werden könnte. Das Repository listet derzeit kein genehmigtes Mainnet-Aktivierungsdatum für EIP-8288 auf.
Die bestehenden Testfälle des Vorschlags decken die individuelle Signaturverifizierung, mehrere Beweisabhängigkeiten, ungültige rekursive Beweise, Mempool-Aggregation und die Kompatibilität mit Transaktionsaufnahmelisten ab.
Sein Abschnitt zur Abwärtskompatibilität stellt fest, dass gewöhnliche Transaktionen ohne die neuen kryptographischen Verifizierungsrahmen ihr bestehendes Verhalten beibehalten würden.
Knoten, die die neuen Regeln nicht implementieren, würden Transaktionen, die den vorgeschlagenen Rahmenmodus verwenden, und Blöcke, die den rekursiven Beweisheader tragen, ablehnen.
Der Vorschlag erfordert daher ein koordiniertes Netzwerk-Upgrade, bevor sein kryptografisches Aggregationssystem Teil der Mainnet-Regeln von Ethereum werden kann.
