Vitalik über mögliche Zukünfte von Ethereum (Sechs): The Splurge

Im Design des Ethereum-Protokolls bezieht sich etwa die Hälfte der Inhalte auf verschiedene Arten von EVM-Verbesserungen, während der Rest aus einer Vielzahl von Nischenthemen besteht – das ist es, was „Splurge“ bedeutet.

Originaltitel: 《Possible futures of the Ethereum protocol, part 6: The Splurge》

Autor: Vitalik Buterin

Übersetzung: zhouzhou, BlockBeats

Nachfolgend der Originalinhalt (zur besseren Lesbarkeit und Verständlichkeit wurde der Inhalt bearbeitet):

Manche Dinge lassen sich nur schwer einer einzigen Kategorie zuordnen. Im Design des Ethereum-Protokolls gibt es viele „Details“, die für den Erfolg von Ethereum sehr wichtig sind. Tatsächlich bezieht sich etwa die Hälfte der Inhalte auf verschiedene Arten von EVM-Verbesserungen, während der Rest aus einer Vielzahl von Nischenthemen besteht – das ist es, was „Splurge“ bedeutet.

Roadmap 2023: Splurge

Splurge: Zentrale Ziele

• Die EVM zu einem leistungsstarken und stabilen „Endzustand“ machen
• Account Abstraction ins Protokoll einführen, damit alle Nutzer von sichereren und bequemeren Accounts profitieren
• Optimierung der Transaktionsgebührenökonomie, um die Skalierbarkeit zu erhöhen und gleichzeitig Risiken zu senken
• Erforschung fortschrittlicher Kryptographie, um Ethereum langfristig signifikant zu verbessern

EVM-Verbesserungen

Welches Problem wird gelöst?

Die aktuelle EVM ist schwer statisch zu analysieren, was die Erstellung effizienter Implementierungen, die formale Verifikation von Code und weitere Erweiterungen erschwert. Außerdem ist die Effizienz der EVM gering, und viele Formen fortgeschrittener Kryptographie lassen sich nur schwer umsetzen, es sei denn, sie werden explizit durch Precompiles unterstützt.

Was ist das und wie funktioniert es?

Der erste Schritt auf der aktuellen Roadmap zur Verbesserung der EVM ist das EVM Object Format (EOF), das im nächsten Hard Fork aufgenommen werden soll. EOF ist eine Reihe von EIPs, die eine neue Version des EVM-Codes spezifizieren, mit vielen einzigartigen Eigenschaften, am auffälligsten sind:

• Trennung von Code (ausführbar, aber nicht aus der EVM lesbar) und Daten (lesbar, aber nicht ausführbar)
• Verbot von dynamischen Sprüngen, nur statische Sprünge sind erlaubt
• EVM-Code kann keine Informationen mehr beobachten, die mit Gas zu tun haben
• Eine neue explizite Subroutinen-Mechanik wurde hinzugefügt

Struktur von EOF-Code

Splurge: EVM-Verbesserungen (Fortsetzung)

Legacy Contracts werden weiterhin existieren und können erstellt werden, obwohl sie letztlich möglicherweise schrittweise abgeschafft werden (oder sogar gezwungen werden, in EOF-Code umgewandelt zu werden). Neue Contracts profitieren von den Effizienzsteigerungen durch EOF – zunächst durch leicht verkleinerte Bytecodes dank Subroutinen, später durch neue, EOF-spezifische Funktionen oder geringere Gas-Kosten.

Nach der Einführung von EOF werden weitere Upgrades einfacher. Am weitesten fortgeschritten ist derzeit die EVM Modular Arithmetic Extension (EVM-MAX). EVM-MAX erstellt eine Reihe neuer Operationen speziell für Modulo-Berechnungen und platziert sie in einem neuen Speicherbereich, der von anderen Opcodes nicht zugänglich ist. Das ermöglicht Optimierungen wie Montgomery-Multiplikation.

Eine neuere Idee ist die Kombination von EVM-MAX mit Single Instruction Multiple Data (SIMD). SIMD ist ein Konzept, das es in Ethereum schon lange gibt, erstmals vorgeschlagen von Greg Colvin in EIP-616. SIMD kann zur Beschleunigung vieler kryptographischer Verfahren genutzt werden, darunter Hashfunktionen, 32-Bit-STARKs und gitterbasierte Kryptographie. Die Kombination von EVM-MAX und SIMD macht diese beiden leistungsorientierten Erweiterungen zu einer natürlichen Paarung.

Das grobe Design einer kombinierten EIP würde bei EIP-6690 beginnen und dann:

• Erlauben (i) jede ungerade Zahl oder (ii) jede Zweierpotenz bis maximal 2768 als Modulus
• Für jeden EVM-MAX-Opcode (Addition, Subtraktion, Multiplikation) eine Version hinzufügen, die nicht mehr 3 Immediate-Werte x, y, z verwendet, sondern 7 Immediate-Werte: x_start, x_skip, y_start, y_skip, z_start, z_skip, count. Im Python-Code funktioniert das wie folgt:

for i in range(count):

mem[z_start + z_skip * count] = op(

mem[x_start + x_skip * count],

mem[y_start + y_skip * count]

)

In der tatsächlichen Implementierung wird dies parallel verarbeitet.

• Möglicherweise werden XOR, AND, OR, NOT und SHIFT (einschließlich zyklisch und nicht-zyklisch) hinzugefügt, zumindest für Zweierpotenzen als Modulus. ISZERO wird ebenfalls hinzugefügt (das Ergebnis wird auf den Haupt-Stack der EVM gepusht). Das ist ausreichend leistungsfähig, um elliptische Kurven-Kryptographie, Small-Field-Kryptographie (wie Poseidon, Circle STARKs), traditionelle Hashfunktionen (wie SHA256, KECCAK, BLAKE) und gitterbasierte Kryptographie zu implementieren. Andere EVM-Upgrades sind ebenfalls möglich, haben aber bisher weniger Aufmerksamkeit erhalten.

Links zu bestehender Forschung

• EOF: 
• EVM-MAX: 
• SIMD: 

Verbleibende Arbeit und Abwägungen

Derzeit ist geplant, EOF im nächsten Hard Fork aufzunehmen. Es besteht zwar immer die Möglichkeit, es in letzter Minute zu entfernen – in früheren Hard Forks wurden Funktionen vorübergehend entfernt –, aber das wäre eine große Herausforderung. Die Entfernung von EOF würde bedeuten, dass zukünftige Upgrades der EVM ohne EOF durchgeführt werden müssten. Das ist zwar möglich, aber wahrscheinlich schwieriger.

Der Hauptkompromiss der EVM liegt in der Komplexität von L1 gegenüber der Infrastrukturkomplexität. EOF ist eine große Menge an Code, die zur EVM-Implementierung hinzugefügt werden muss, und die statische Codeprüfung ist relativ komplex. Im Gegenzug können wir jedoch High-Level-Sprachen vereinfachen, die EVM-Implementierung vereinfachen und weitere Vorteile erzielen. Man kann sagen, dass eine Roadmap, die kontinuierliche Verbesserungen von Ethereum L1 priorisiert, EOF einschließen und darauf aufbauen sollte.

Eine wichtige Aufgabe ist die Implementierung von Funktionen wie EVM-MAX plus SIMD und das Benchmarking des Gasverbrauchs für verschiedene kryptographische Operationen.

Wie interagiert das mit anderen Teilen der Roadmap?

Wenn L1 seine EVM anpasst, wird es für L2 ebenfalls einfacher, entsprechende Anpassungen vorzunehmen. Wenn dies nicht synchron geschieht, kann es zu Inkompatibilitäten und negativen Auswirkungen kommen. Außerdem können EVM-MAX und SIMD die Gas-Kosten vieler Beweissysteme senken und so L2 effizienter machen. Es wird auch einfacher, mehr Precompiles durch EVM-Code zu ersetzen, der die gleiche Aufgabe erfüllt, ohne die Effizienz wesentlich zu beeinträchtigen.

Account Abstraction

Welches Problem wird gelöst?

Derzeit können Transaktionen nur auf eine Weise verifiziert werden: durch ECDSA-Signaturen. Ursprünglich zielte Account Abstraction darauf ab, darüber hinauszugehen und zu erlauben, dass die Verifizierungslogik eines Accounts beliebiger EVM-Code sein kann. Das ermöglicht eine Reihe von Anwendungen:

• Umstieg auf quantensichere Kryptographie
• Rotation alter Schlüssel (allgemein empfohlene Sicherheitsmaßnahme)
• Multisig-Wallets und Social Recovery Wallets
• Verwendung eines Schlüssels für Transaktionen mit geringem Wert und eines anderen (oder einer Gruppe von Schlüsseln) für Transaktionen mit hohem Wert

Erlaubt es Privacy-Protokollen, ohne Relayer zu funktionieren, was deren Komplexität deutlich reduziert und einen zentralen Abhängigkeitsfaktor eliminiert

Seit der Einführung von Account Abstraction im Jahr 2015 wurden die Ziele auch um zahlreiche „Convenience-Ziele“ erweitert, z. B. dass ein Account ohne ETH, aber mit einigen ERC20, die Gasgebühren mit ERC20 bezahlen kann. Nachfolgend eine Übersichtsgrafik dieser Ziele:

MPC (Multi-Party Computation) ist eine seit 40 Jahren bestehende Technik, um Schlüssel in mehrere Teile zu teilen und auf verschiedenen Geräten zu speichern, wobei kryptographische Methoden verwendet werden, um Signaturen zu erzeugen, ohne die Schlüsselteile direkt zu kombinieren.

EIP-7702 ist ein Vorschlag, der im nächsten Hard Fork eingeführt werden soll. EIP-7702 ist das Ergebnis der wachsenden Erkenntnis, dass die Vorteile von Account Abstraction allen Nutzern (einschließlich EOA-Nutzern) zugutekommen sollten. Ziel ist es, kurzfristig das Nutzererlebnis für alle zu verbessern und eine Spaltung in zwei Ökosysteme zu vermeiden.

Die Arbeit begann mit EIP-3074 und mündete schließlich in EIP-7702. EIP-7702 bringt die „Convenience-Funktionen“ der Account Abstraction allen Nutzern, einschließlich heutiger EOAs (Externally Owned Accounts, also Accounts, die durch ECDSA-Signaturen kontrolliert werden).

Wie aus der Grafik ersichtlich ist, können einige Herausforderungen (insbesondere „Convenience“-Herausforderungen) durch schrittweise Technologien wie MPC oder EIP-7702 gelöst werden. Die wichtigsten Sicherheitsziele, die ursprünglich mit Account Abstraction verfolgt wurden, lassen sich jedoch nur erreichen, wenn man das ursprüngliche Problem angeht: die Kontrolle der Transaktionsverifizierung durch Smart Contract Code zu ermöglichen. Der Grund, warum dies bisher nicht umgesetzt wurde, liegt in der sicheren Implementierung, die eine Herausforderung darstellt.

Was ist das und wie funktioniert es?

Der Kern von Account Abstraction ist einfach: Smart Contracts dürfen Transaktionen initiieren, nicht nur EOAs. Die Komplexität entsteht dadurch, dies so zu implementieren, dass die Dezentralisierung des Netzwerks erhalten bleibt und Denial-of-Service-Angriffe verhindert werden.

Eine typische Schlüsselherausforderung ist das Problem des „Multi-Failure“:

Wenn die Verifizierungsfunktion von 1000 Accounts von einem einzigen Wert S abhängt und der aktuelle Wert S alle Mempool-Transaktionen gültig macht, kann eine einzelne Transaktion, die S ändert, alle anderen Transaktionen im Mempool ungültig machen. Das ermöglicht es Angreifern, mit minimalem Aufwand Spam-Transaktionen in den Mempool zu senden und so die Ressourcen der Netzwerkknoten zu blockieren.

Nach jahrelanger Arbeit, um die Funktionalität zu erweitern und gleichzeitig das DoS-Risiko zu begrenzen, wurde schließlich eine Lösung für „ideale Account Abstraction“ gefunden: ERC-4337.

ERC-4337 funktioniert, indem die Verarbeitung von User Operations in zwei Phasen unterteilt wird: Verifizierung und Ausführung. Zuerst werden alle Verifizierungen durchgeführt, dann alle Ausführungen. Im Mempool werden nur User Operations akzeptiert, deren Verifizierungsphase nur den eigenen Account betrifft und keine Umgebungsvariablen liest. Das verhindert Multi-Failure-Angriffe. Außerdem gibt es strenge Gas-Limits für den Verifizierungsschritt.

ERC-4337 wurde als zusätzlicher Protokollstandard (ERC) entworfen, weil sich die Ethereum-Client-Entwickler damals auf den Merge konzentrierten und keine Kapazitäten für weitere Features hatten. Deshalb verwendet ERC-4337 sogenannte User Operations statt regulärer Transaktionen. Inzwischen wurde erkannt, dass zumindest Teile davon ins Protokoll geschrieben werden müssen.

Zwei Hauptgründe dafür:

1. Die inhärente Ineffizienz von EntryPoint als Contract: Jeder Bundle verursacht einen Fixkosten-Overhead von etwa 100.000 Gas sowie mehrere Tausend Gas pro User Operation.
2. Die Notwendigkeit, Ethereum-Eigenschaften zu gewährleisten: Zum Beispiel müssen die von Inclusion Lists geschaffenen Garantien auch für Account-Abstraction-Nutzer gelten.

Darüber hinaus erweitert ERC-4337 zwei Funktionen:

• Paymasters: Erlauben es einem Account, die Gebühren für einen anderen Account zu bezahlen. Das widerspricht der Regel, dass die Verifizierungsphase nur auf den Sender-Account zugreifen darf, daher gibt es spezielle Sicherheitsmechanismen für Paymasters.
• Aggregators: Unterstützen die Aggregation von Signaturen, z. B. BLS-Aggregation oder SNARK-basierte Aggregation. Das ist für maximale Dateneffizienz auf Rollups notwendig.

Links zu bestehender Forschung

• Vortrag zur Geschichte von Account Abstraction:
• ERC-4337:
• EIP-7702:
• BLSWallet-Code (mit Aggregationsfunktion):
• EIP-7562 (Account Abstraction im Protokoll):
• EIP-7701 (Account Abstraction im Protokoll auf Basis von EOF):

Verbleibende Arbeit und Abwägungen

Derzeit muss vor allem geklärt werden, wie Account Abstraction vollständig ins Protokoll integriert werden kann. Die zuletzt populäre Protokoll-Account-Abstraction-EIP ist EIP-7701, die Account Abstraction auf EOF aufbaut. Ein Account kann einen separaten Code-Abschnitt zur Verifizierung besitzen. Wenn dieser gesetzt ist, wird der Code während des Verifizierungsschritts für Transaktionen dieses Accounts ausgeführt.

Der Reiz dieser Methode liegt darin, dass sie zwei gleichwertige Perspektiven auf native Account Abstraction klar macht:

1. Die Integration von EIP-4337 als Teil des Protokolls
2. Ein neuer EOA-Typ, bei dem der Signaturalgorithmus die Ausführung von EVM-Code ist

Wenn wir damit beginnen, die Komplexität des ausführbaren Codes während der Verifizierung streng zu begrenzen – kein Zugriff auf externen Status, und anfangs so niedrige Gas-Limits, dass quantensichere oder privacy-orientierte Anwendungen nicht möglich sind –, ist die Sicherheit dieser Methode sehr klar: Es wird einfach die ECDSA-Verifizierung durch eine EVM-Code-Ausführung mit ähnlicher Laufzeit ersetzt.

Mit der Zeit müssen wir diese Grenzen jedoch lockern, denn Privacy-Anwendungen ohne Relayer und Quantensicherheit sind sehr wichtig. Dafür müssen wir flexiblere Methoden finden, um DoS-Risiken zu begegnen, ohne dass der Verifizierungsschritt extrem minimalistisch sein muss.

Die Hauptabwägung scheint zu sein: „Schnell eine Lösung implementieren, die weniger Leute zufriedenstellt“ versus „länger warten, um vielleicht eine ideale Lösung zu bekommen“. Der ideale Weg könnte ein Hybrid sein: Einige Anwendungsfälle schneller implementieren und mehr Zeit für andere lassen. Oder ambitioniertere Account-Abstraction-Versionen zuerst auf L2 deployen. Die Herausforderung dabei ist, dass L2-Teams Vertrauen in die vorgeschlagenen Lösungen haben müssen, um sie zu implementieren, insbesondere um sicherzustellen, dass L1 und/oder andere L2 in Zukunft kompatible Lösungen übernehmen können.

Ein weiterer zu berücksichtigender Anwendungsfall sind Key-Storage-Accounts, die den Account-bezogenen Status auf L1 oder einem dedizierten L2 speichern, aber auf L1 und jedem kompatiblen L2 verwendet werden können. Um das effektiv zu ermöglichen, müssten L2s Opcodes wie L1SLOAD oder REMOTESTATICCALL unterstützen, was wiederum voraussetzt, dass die Account-Abstraction-Implementierung auf L2 diese Operationen unterstützt.

Wie interagiert das mit anderen Teilen der Roadmap?

Inclusion Lists müssen Account-Abstraction-Transaktionen unterstützen. In der Praxis sind die Anforderungen von Inclusion Lists und dezentralen Mempools sehr ähnlich, auch wenn Inclusion Lists etwas flexibler sind. Außerdem sollte die Account-Abstraction-Implementierung möglichst zwischen L1 und L2 koordiniert werden. Wenn wir erwarten, dass die meisten Nutzer künftig Key-Storage-Rollups verwenden, sollte das Design der Account Abstraction darauf aufbauen.

EIP-1559-Verbesserungen

Welches Problem wird gelöst?

EIP-1559 wurde 2021 auf Ethereum aktiviert und hat die durchschnittliche Block-Inclusion-Zeit deutlich verbessert.

Wartezeit

Die aktuelle Implementierung von EIP-1559 ist jedoch in mehreren Punkten nicht perfekt:

1. Die Formel ist leicht fehlerhaft: Sie zielt nicht auf 50 % volle Blöcke ab, sondern auf etwa 50–53 %, abhängig von der Varianz (das hängt mit der „arithmetisch-geometrischen Mittelwert-Ungleichung“ zusammen).
2. In Extremsituationen erfolgt die Anpassung nicht schnell genug.

Die spätere Formel für Blobs (EIP-4844) wurde speziell entwickelt, um das erste Problem zu lösen, und ist insgesamt auch einfacher. Allerdings versuchen weder EIP-1559 noch EIP-4844, das zweite Problem zu lösen. Das Ergebnis ist ein verwirrender Zwischenzustand mit zwei verschiedenen Mechanismen, und es gibt die Ansicht, dass beide im Laufe der Zeit verbessert werden müssen.

Darüber hinaus gibt es weitere Schwächen bei der Ressourcenbepreisung in Ethereum, die nicht direkt mit EIP-1559 zusammenhängen, aber durch Anpassungen an EIP-1559 gelöst werden können. Ein zentrales Problem ist der Unterschied zwischen Durchschnitts- und Worst-Case: Die Ressourcenpreise in Ethereum müssen so festgelegt werden, dass sie den Worst-Case (ein Block, der das gesamte Gas für eine Ressource verbraucht) abdecken, während die durchschnittliche Nutzung weit darunter liegt – das ist ineffizient.

Was ist Multi-Dimensional Gas und wie funktioniert es?

Die Lösung für diese Ineffizienzen ist Multi-Dimensional Gas: unterschiedliche Preise und Limits für verschiedene Ressourcen. Dieses Konzept ist technisch unabhängig von EIP-1559, aber EIP-1559 erleichtert die Umsetzung. Ohne EIP-1559 wäre das optimale Packen eines Blocks mit mehreren Ressourcenbeschränkungen ein komplexes Multi-Dimensional-Knapsack-Problem. Mit EIP-1559 erreichen die meisten Blöcke bei keiner Ressource das Limit, sodass ein einfaches „Akzeptiere jede Transaktion, die genug zahlt“-Verfahren ausreicht.

Derzeit gibt es Multi-Dimensional Gas für Execution und Data Blobs; prinzipiell könnte man das auf weitere Dimensionen ausweiten: etwa calldata (Transaktionsdaten), Status-Reads/Writes und Statuswachstum.

EIP-7706 führt eine neue Gas-Dimension speziell für calldata ein. Gleichzeitig vereinfacht es das Multi-Dimensional-Gas-System, indem es drei Gas-Typen in einen (EIP-4844-Stil) Rahmen zusammenführt und so auch den mathematischen Fehler von EIP-1559 behebt. EIP-7623 ist eine präzisere Lösung für das Ressourcenproblem zwischen Durchschnitts- und Worst-Case und begrenzt calldata strenger, ohne eine neue Dimension einzuführen.

Ein weiteres Forschungsfeld ist die Lösung des Update-Rate-Problems: eine schnellere Basisgebührenberechnung zu finden, die dennoch die von EIP-4844 eingeführten Invarianten (d. h. langfristig liegt die durchschnittliche Nutzung genau beim Zielwert) beibehält.

Links zu bestehender Forschung

• EIP-1559 FAQ: 
• Empirische Analyse zu EIP-1559: 
• Verbesserungsvorschläge für schnellere Anpassungen: 
• Abschnitt zur Basisgebührenmechanik in der EIP-4844 FAQ: 
• EIP-7706: 
• EIP-7623: 
• Multi-Dimensional Gas: 

Was bleibt zu tun und welche Abwägungen gibt es?

Die Hauptabwägungen bei Multi-Dimensional Gas sind zwei:

1. Erhöhte Protokollkomplexität: Die Einführung von Multi-Dimensional Gas macht das Protokoll komplexer.
2. Erhöhte Komplexität der optimalen Algorithmen zum Füllen von Blöcken: Die Algorithmen, um Blöcke optimal zu füllen, werden ebenfalls komplexer.

Die Protokollkomplexität ist für calldata relativ gering, aber für Gas-Dimensionen innerhalb der EVM (wie Speicher-Reads und -Writes) steigt sie. Das Problem ist, dass nicht nur Nutzer Gas-Limits setzen, sondern auch Contracts beim Aufruf anderer Contracts. Derzeit können sie das nur eindimensional tun.

Eine einfache Lösung ist, Multi-Dimensional Gas nur innerhalb von EOF verfügbar zu machen, da EOF es Contracts nicht erlaubt, beim Aufruf anderer Contracts Gas-Limits zu setzen. Nicht-EOF-Contracts müssen bei Speicheroperationen alle Gas-Typen bezahlen (z. B. wenn SLOAD 0,03 % des Block-Speicherzugriffs-Gas-Limits verbraucht, zahlt ein Nicht-EOF-Nutzer ebenfalls 0,03 % des Execution-Gas-Limits).

Weitere Forschung zu Multi-Dimensional Gas wird helfen, diese Abwägungen besser zu verstehen und einen idealen Kompromiss zu finden.

Wie interagiert das mit anderen Teilen der Roadmap?

Eine erfolgreiche Implementierung von Multi-Dimensional Gas kann die Nutzung bestimmter Ressourcen im Worst-Case deutlich senken und so den Druck auf Performance-Optimierungen verringern, etwa für STARKed-Hash-basierte Binärbäume. Ein klares Ziel für das Wachstum der Statusgröße erleichtert es Client-Entwicklern, für die Zukunft zu planen und Anforderungen abzuschätzen.

Wie bereits erwähnt, macht die Existenz von EOF die Implementierung extremerer Versionen von Multi-Dimensional Gas einfacher, da Gas nicht beobachtbar ist.

Verifiable Delay Functions (VDFs)

Welches Problem wird gelöst?

Derzeit nutzt Ethereum RANDAO-basierte Zufälligkeit zur Auswahl von Proposern. Die RANDAO-Zufälligkeit funktioniert, indem jeder Proposer ein zuvor zugesagtes Geheimnis offenlegt, das dann in die Zufälligkeit gemischt wird.

Jeder Proposer hat dadurch „1 Bit Manipulationsmacht“: Er kann durch Nichterscheinen die Zufälligkeit ändern (zu einem Preis). Das ist für die Auswahl von Proposern akzeptabel, weil es selten vorkommt, dass man durch Verzicht auf eine Chance zwei neue erhält. Für On-Chain-Anwendungen, die Zufälligkeit benötigen, ist das jedoch nicht ideal. Idealerweise sollte es eine robustere Zufälligkeitsquelle geben.

Was ist eine VDF und wie funktioniert sie?

Eine Verifiable Delay Function ist eine Funktion, die nur sequentiell berechnet werden kann und nicht durch Parallelisierung beschleunigt werden kann. Ein einfaches Beispiel ist wiederholtes Hashen: for i in range(10**9): x = hash(x). Das Ergebnis wird ausgegeben und mit einem SNARK bewiesen, dass es korrekt ist, und kann als Zufallswert verwendet werden.

Die Idee ist, dass der Input auf Informationen basiert, die zu Zeitpunkt T verfügbar sind, das Output aber zu T noch nicht bekannt ist: Das Output wird erst nach vollständiger Berechnung nach T verfügbar. Da jeder die Berechnung durchführen kann, kann niemand das Ergebnis verheimlichen oder manipulieren.

Das Hauptrisiko bei VDFs ist unerwartete Optimierung: Jemand findet einen Weg, die Funktion schneller als erwartet zu berechnen und kann so die zu T offenbarten Informationen manipulieren.

Unerwartete Optimierung kann auf zwei Arten auftreten:

1. Hardware-Beschleunigung: Jemand baut einen ASIC, der die Berechnungsschleife schneller als vorhandene Hardware ausführt.
2. Unerwartete Parallelisierung: Jemand findet einen Weg, die Funktion durch Parallelisierung schneller auszuführen, auch wenn das 100-fache Ressourcen erfordert.

Die Aufgabe bei der Entwicklung erfolgreicher VDFs ist es, beide Probleme zu vermeiden und gleichzeitig die Effizienz praktikabel zu halten (z. B. ist das SNARK-Proving für Hashes in Echtzeit hardwareintensiv). Hardware-Beschleunigung wird meist gelöst, indem ein gemeinnütziger Akteur einen nahezu optimalen VDF-ASIC entwickelt und verteilt.

Links zu bestehender Forschung

• VDF-Forschungswebsite: 
• Überlegungen zu Angriffen auf VDFs in Ethereum, 2018: 
• Angriffe auf die vorgeschlagene VDF MinRoot: 

Was bleibt zu tun und welche Abwägungen gibt es?

Derzeit gibt es keine VDF-Konstruktion, die alle Anforderungen der Ethereum-Forscher erfüllt. Es ist noch mehr Arbeit nötig, um eine solche Funktion zu finden. Falls gefunden, besteht die Hauptabwägung darin, ob sie aufgenommen werden soll: Funktionalität versus Protokollkomplexität und Sicherheitsrisiken.

Wenn wir glauben, dass eine VDF sicher ist, sie sich aber als unsicher herausstellt, fällt die Sicherheit auf die RANDAO-Annahme zurück (1 Bit Manipulationsmacht pro Angreifer) oder etwas schlechter. Das Protokoll bleibt also intakt, aber Anwendungen oder neue Protokollfunktionen, die stark darauf angewiesen sind, könnten beeinträchtigt werden.

Wie interagiert das mit anderen Teilen der Roadmap?

VDF ist ein relativ eigenständiger Bestandteil des Ethereum-Protokolls. Neben der Erhöhung der Sicherheit bei der Proposer-Auswahl findet es auch Anwendung in (i) On-Chain-Anwendungen, die Zufälligkeit benötigen, und (ii) kryptographischen Mempools, wobei Letzteres noch weitere kryptographische Durchbrüche erfordert.

Ein wichtiger Punkt ist, dass es aufgrund von Hardwareunsicherheiten eine gewisse „Lücke“ zwischen der Erzeugung und dem Bedarf von VDF-Outputs geben wird. Das bedeutet, dass Informationen einige Blöcke im Voraus verfügbar sein werden. Das kann ein akzeptabler Preis sein, sollte aber bei Designs wie Single-Slot-Finality oder Committee Selection berücksichtigt werden.

Obfuskation und One-Shot-Signaturen: Die ferne Zukunft der Kryptographie

Welches Problem wird gelöst?

Nick Szabos bekanntester Artikel ist sein 1997 verfasster Aufsatz über das „God Protocol“. Darin stellt er fest, dass viele Multi-Party-Anwendungen auf einen „vertrauenswürdigen Dritten“ angewiesen sind, der die Interaktion verwaltet. Aus seiner Sicht besteht die Aufgabe der Kryptographie darin, einen simulierten vertrauenswürdigen Dritten zu schaffen, der dieselbe Arbeit erledigt, ohne dass man jemandem vertrauen muss.

Bisher konnten wir dieses Ideal nur teilweise umsetzen. Wenn wir lediglich eine transparente virtuelle Maschine benötigen, deren Daten und Berechnungen nicht abgeschaltet, zensiert oder manipuliert werden können und Privatsphäre kein Ziel ist, kann die Blockchain dies leisten, wenn auch mit begrenzter Skalierbarkeit.

Wenn Privatsphäre ein Ziel ist, konnten wir bis vor Kurzem nur für bestimmte Anwendungen spezifische Protokolle entwickeln: Digitale Signaturen für grundlegende Authentifizierung, Ring-Signaturen und Linkable Ring Signatures für rohe Anonymität, Identity-Based Encryption für bequemere Verschlüsselung unter bestimmten Annahmen über vertrauenswürdige Aussteller und Blind Signatures für Chaum’sches E-Cash usw. Diese Methode erfordert für jede neue Anwendung viel Arbeit.

In den 2010er Jahren bekamen wir erstmals einen Einblick in eine andere, viel mächtigere Methode: programmierbare Kryptographie. Anstatt für jede neue Anwendung ein neues Protokoll zu entwickeln, können wir mit mächtigen neuen Protokollen – konkret ZK-SNARKs – kryptographische Garantien für beliebige Programme hinzufügen.

ZK-SNARKs erlauben es Nutzern, beliebige Aussagen über ihre Daten zu beweisen, wobei der Beweis (i) leicht zu verifizieren ist und (ii) keine weiteren Informationen außer der Aussage selbst preisgibt. Das ist ein enormer Fortschritt für Privatsphäre und Skalierbarkeit – vergleichbar mit dem Einfluss von Transformern in der KI. Tausende Jahre an anwendungsspezifischer Arbeit werden plötzlich durch diese universelle Lösung ersetzt, die eine unerwartet breite Palette von Problemen abdeckt.

Doch ZK-SNARKs sind nur das erste von drei extrem mächtigen universellen Primitiven. Diese Protokolle sind so mächtig, dass sie mich an eine Gruppe extrem starker Karten aus „Yu-Gi-Oh!“ erinnern – ein Kartenspiel und eine TV-Serie, die ich als Kind gespielt habe: die ägyptischen Götterkarten.

Die ägyptischen Götterkarten sind drei extrem mächtige Karten, deren Herstellung angeblich tödlich sein kann und deren Stärke dazu führte, dass sie im Duell verboten wurden. Ähnlich gibt es in der Kryptographie diese drei „ägyptischen Götterprotokolle“:

Was sind ZK-SNARKs und wie funktionieren sie?

ZK-SNARKs sind das am weitesten entwickelte der drei Protokolle. In den letzten fünf Jahren haben massive Verbesserungen bei der Geschwindigkeit der Prover und der Entwicklerfreundlichkeit ZK-SNARKs zum Grundpfeiler der Skalierbarkeits- und Privatsphäre-Strategie von Ethereum gemacht. Aber ZK-SNARKs haben eine wichtige Einschränkung: Man muss die Daten kennen, um sie zu beweisen. Jeder Status in einer ZK-SNARK-Anwendung muss einen eindeutigen „Besitzer“ haben, der anwesend sein muss, um Lese- oder Schreibzugriffe zu genehmigen.

Das zweite Protokoll, das diese Einschränkung nicht hat, ist Fully Homomorphic Encryption (FHE). FHE erlaubt es, beliebige Berechnungen auf verschlüsselten Daten durchzuführen, ohne sie zu entschlüsseln. Das ermöglicht es, im Interesse des Nutzers auf dessen Daten zu rechnen und dabei sowohl Daten als auch Algorithmus privat zu halten.

Damit kann man auch Systeme wie MACI auf fast perfekte Sicherheits- und Privatsphäre-Garantien ausweiten. Lange Zeit galt FHE als zu ineffizient für den praktischen Einsatz, aber mittlerweile ist es effizient genug für erste Anwendungen.

Cursive ist eine Anwendung, die Private Matchmaking durch Secure Multi-Party Computation und Fully Homomorphic Encryption (FHE) ermöglicht.

FHE hat jedoch auch seine Grenzen: Jede FHE-basierte Technik benötigt jemanden, der den Entschlüsselungsschlüssel hält. Das kann ein verteiltes M-of-N-Setup sein, oder man kann Trusted Execution Environments (TEEs) als zweite Schutzschicht nutzen, aber es bleibt eine Einschränkung.

Das dritte Protokoll ist noch mächtiger als die beiden anderen zusammen: Indistinguishability Obfuscation. Diese Technik ist noch weit von der Reife entfernt, aber seit 2020 gibt es theoretisch sichere Protokolle auf Basis von Standardannahmen, und erste Implementierungen werden entwickelt.

Indistinguishability Obfuscation erlaubt es, ein „verschlüsseltes Programm“ zu erstellen, das beliebige Berechnungen ausführt und dabei alle internen Details verbirgt. Ein einfaches Beispiel: Man kann einen privaten Schlüssel in ein obfuskiertes Programm einbauen, das nur erlaubt, mit ihm Primzahlen zu signieren, und dieses Programm verteilen. Andere können damit beliebige Primzahlen signieren, aber den Schlüssel nicht extrahieren. In Kombination mit Hashes kann man damit praktisch jedes andere kryptographische Primitive und mehr umsetzen.

Das einzige, was ein obfuskiertes Programm nicht verhindern kann, ist, dass es kopiert wird. Dafür gibt es aber noch mächtigere Techniken, die allerdings voraussetzen, dass jeder einen Quantencomputer besitzt: Quantum One-Shot Signatures.

Durch die Kombination von Obfuskation und One-Shot-Signaturen können wir nahezu perfekte vertrauenslose Dritte bauen. Das einzige Ziel, das rein kryptographisch nicht erreichbar ist, bleibt die Zensurresistenz, für die weiterhin eine Blockchain nötig ist. Diese Technologien können nicht nur Ethereum selbst sicherer machen, sondern auch mächtigere Anwendungen darauf ermöglichen.

Um besser zu verstehen, wie diese Primitiven zusätzliche Fähigkeiten bringen, nehmen wir Voting als zentrales Beispiel. Voting ist ein interessantes Problem, weil es viele komplexe Sicherheitsanforderungen hat, darunter sehr starke Verifizierbarkeit und Privatsphäre. Es gibt seit Jahrzehnten Voting-Protokolle mit starken Sicherheitsgarantien, aber wir können die Herausforderung erhöhen und verlangen, dass beliebige Voting-Protokolle unterstützt werden: Quadratic Voting, Pairwise Capped Quadratic Funding, Clustered Matching Quadratic Funding usw. Mit anderen Worten: Der „Counting“-Schritt soll ein beliebiges Programm sein.

Zunächst nehmen wir an, dass die Wahlergebnisse öffentlich auf der Blockchain stehen. Das bringt öffentliche Verifizierbarkeit (jeder kann das Endergebnis und die Regeln überprüfen) und Zensurresistenz (niemand kann das Voting verhindern), aber keine Privatsphäre.

Dann fügen wir ZK-SNARKs hinzu: Jetzt haben wir Privatsphäre – jede Stimme ist anonym, und es wird sichergestellt, dass nur autorisierte Wähler abstimmen und jeder nur einmal.

Als Nächstes kommt MACI: Die Stimmen werden für den zentralen Server verschlüsselt, der den Counting-Prozess (einschließlich der Entfernung von Doppelstimmen) durchführt und einen ZK-SNARK-Beweis für das Ergebnis veröffentlicht. Das erhält die bisherigen Garantien (selbst bei Server-Betrug!), aber wenn der Server ehrlich ist, gibt es eine zusätzliche Coercion-Resistance: Nutzer können nicht beweisen, wie sie abgestimmt haben, selbst wenn sie es wollen. Sie können zwar ihre Stimme beweisen, aber nicht, dass sie keine Gegenstimme abgegeben haben. Das verhindert Bestechung und andere Angriffe.

Wir führen Counting in FHE aus und machen eine N/2-of-N-Threshold-Decryption. Das erhöht die Coercion-Resistance auf N/2-of-N statt 1-of-1.

Wir obfuskieren das Counting-Programm und gestalten es so, dass es das Ergebnis nur bei Autorisierung ausgibt – etwa durch einen Blockchain-Konsensbeweis, Proof-of-Work oder beides. Das macht die Coercion-Resistance nahezu perfekt: Beim Blockchain-Konsens müssten 51 % der Validatoren kolludieren; bei Proof-of-Work wäre das Neuauszählen mit anderen Wähler-Sets extrem teuer. Das Programm kann sogar das Endergebnis leicht randomisieren, um die Extraktion einzelner Stimmen weiter zu erschweren.

Wir fügen One-Shot-Signaturen hinzu, ein auf Quantencomputern basierendes Primitive, das Signaturen nur für eine bestimmte Art von Information zulässt. Das macht die Coercion-Resistance wirklich perfekt.

Indistinguishability Obfuscation ermöglicht noch weitere mächtige Anwendungen. Zum Beispiel:

1. DAOs, On-Chain-Auktionen und andere Anwendungen mit beliebigem internem Geheimstatus.
2. Wirklich universelle Trusted Setups: Jemand erstellt ein obfuskiertes Programm mit einem Schlüssel, das beliebige Programme ausführt und den Output liefert, wobei hash(key, program) als Input verwendet wird. Jeder kann daraus ein weiteres Programm bauen und so ein 1-of-N Trusted Setup für jedes Protokoll erzeugen.
3. ZK-SNARK-Verifikation mit nur einer Signatur: Einfach ein Trusted Environment einrichten, das ein obfuskiertes Programm erstellt, das nur bei gültigem ZK-SNARK mit dem Schlüssel signiert.
4. Verschlüsselte Mempools: Verschlüsselte Transaktionen, die erst nach einem bestimmten On-Chain-Ereignis entschlüsselt werden können – etwa nach erfolgreicher Ausführung einer VDF.

Mit One-Shot-Signaturen kann man Blockchains gegen 51%-Angriffe auf die Finalität schützen, auch wenn Zensurangriffe weiterhin möglich sind. Ähnliche Primitiven ermöglichen Quantum Money und lösen das Double-Spending-Problem ohne Blockchain, auch wenn viele komplexere Anwendungen weiterhin eine Chain benötigen.

Wenn diese Primitiven effizient genug werden, können die meisten Anwendungen der Welt dezentralisiert werden. Die Hauptbremse wird die Verifikation der Implementierung sein.

Hier einige Links zu bestehender Forschung:

• Indistinguishability Obfuscation Protocol (2021): 
• Wie Obfuskation Ethereum helfen kann: 
• Erste bekannte One-Shot-Signatur-Konstruktion: 
• Versuch einer Obfuskationsimplementierung (1): 
• Versuch einer Obfuskationsimplementierung (2): 

Was bleibt zu tun und welche Abwägungen gibt es?

Es bleibt noch viel zu tun. Indistinguishability Obfuscation ist noch sehr unreif, und die Kandidatenkonstruktionen sind so langsam, dass sie praktisch nicht einsetzbar sind. Obfuskation ist zwar „theoretisch“ in Polynomialzeit möglich, aber in der Praxis kann die Laufzeit länger als das Universum sein. Neuere Protokolle sind schneller, aber immer noch zu langsam für den Alltag: Ein Implementierer schätzt die Laufzeit auf ein Jahr.

Quantencomputer existieren noch nicht: Alles, was man im Internet sieht, sind Prototypen, die nicht mehr als 4 Bit verarbeiten können, oder gar keine echten Quantencomputer. Es gibt zwar Fortschritte, aber bis jeder einen Quantencomputer auf dem Laptop oder Handy hat, wird es noch Jahrzehnte dauern, selbst wenn große Institutionen bald Elliptic-Curve-Kryptographie brechen können.

Bei Obfuskation ist ein wichtiger Kompromiss die Sicherheitshypothese: Es gibt aggressivere Designs mit speziellen Annahmen, die oft schneller sind, aber manchmal gebrochen werden. Mit der Zeit werden wir Gitter besser verstehen und robustere Annahmen machen können. Der konservativere Weg ist, nur Protokolle mit Reduktion auf „Standard“-Annahmen zu verwenden, was aber bedeutet, dass wir länger auf schnelle Protokolle warten müssen.

Wie interagiert das mit anderen Teilen der Roadmap?

Extrem mächtige Kryptographie könnte das Spiel komplett verändern, zum Beispiel:

1. Wenn ZK-SNARK-Verifikation so einfach wie Signaturen wird, brauchen wir keine Aggregationsprotokolle mehr – wir können direkt on-chain verifizieren.
2. One-Shot-Signaturen könnten sicherere Proof-of-Stake-Protokolle ermöglichen.
3. Viele komplexe Privacy-Protokolle könnten durch eine privacy-fähige Ethereum Virtual Machine (EVM) ersetzt werden.
4. Verschlüsselte Mempools werden leichter umsetzbar.

Anfangs werden die Vorteile auf der Anwendungsebene sichtbar sein, da Ethereum L1 bei Sicherheitshypothesen konservativ bleiben muss. Aber schon die Nutzung auf Anwendungsebene könnte disruptiv sein – wie bei der Einführung von ZK-SNARKs.