Vitalik Buterins Argument, einen großen Teil der Kryptografie außerhalb der Ethereum-Blockchain zu erledigen, beruht auf einer einfachen Unterscheidung: Rechenarbeit ist nicht dasselbe wie Datenübertragung. Ein sogenannter Precompile kann eine kryptografische Prüfung günstiger machen. Die Daten, die geprüft werden sollen, muss Ethereum aber trotzdem empfangen. EIP-8288 schlägt deshalb vor, umfangreiche kryptografische Daten möglichst aus den Blöcken herauszuhalten und die Prüfungen in rekursiven STARK-Beweisen zu bündeln. Der Vorschlag hat weiterhin den Status „Draft“ – also Entwurf.
4
16
Warum nicht einfach weitere Precompiles einführen?
Precompiles sind fest eingebaute Funktionen, die bestimmte Berechnungen günstiger machen. Sie lösen jedoch nicht automatisch das Problem, dass Ethereum die dafür nötigen Signaturen, Beweise oder sonstigen Eingaben übertragen muss. Buterin zufolge begrenzt die verfügbare Datenbandbreite, wie viel kryptografisches Material Ethereum verarbeiten kann – nicht nur die für die Prüfung anfallenden Gas-Kosten. Selbst mit PeerDAS und Blöcken, die Blob-Daten enthalten, veranschlagte er die praktisch nutzbare Datenrate auf etwa 8 MB pro Sekunde. Das ist seine Einschätzung und keine formale Grenze für Calldata.
4
12
Hinzu kommt ein Zielkonflikt bei der Flexibilität: Für jedes kryptografische Verfahren einen eigenen Precompile bereitzustellen, kann das Protokoll komplexer machen und erfordert Implementierungen durch die verschiedenen Clients. EIP-8288 soll stattdessen einen gemeinsamen Weg zur Prüfung unterschiedlicher kryptografischer Verfahren schaffen.
7
16
Die Beispiele im Entwurf veranschaulichen, worum es geht: Hash-basierte Signaturen könnten etwa 2 bis 3 kB groß sein; ihre direkte Prüfung wird im Vorschlag mit 150.000 bis 200.000 Gas angesetzt. Das sind Schätzwerte für ein Beispiel – keine allgemeingültigen Kosten für jede Signatur oder Implementierung.
10
So soll EIP-8288 funktionieren
Laut dem offiziellen EIP sind Vitalik Buterin und Thomas Coratger die Autoren des Vorschlags. Er erweitert Frame-Transaktionen aus EIP-8141 und setzt im Wesentlichen auf drei Bausteine:
16
- Transaktionen verweisen auf kompakte Abhängigkeiten. Eine Abhängigkeit nennt das Verfahren, einen Hash der Daten und einen Hash des Verifizierungsschlüssels. Zusammen werden diese Angaben laut Entwurf in 96 Byte codiert.
16
13
- Die vollständigen kryptografischen Daten werden bei der Verbreitung mitgeliefert. Umfangreiche Signaturen und Beweise reisen mit den Transaktionen durchs Netzwerk, statt vollständig im Block abgelegt zu werden. Teilnehmer im Mempool – dem Bereich, in dem ausstehende Transaktionen auf ihre Aufnahme warten – können Prüfungen zusammenführen.
15
16
- Die Prüfungen werden gebündelt. Rekursive STARK-Beweise sollen mehrere Prüfungen kombinieren. Statt jeder ursprünglichen kryptografischen Nutzlast soll dann ein aggregierter Beweis im Block stehen. Damit soll der Bedarf an Blockdaten sinken; die zugrunde liegende Bandbreitengrenze des Netzwerks wird dadurch nicht erhöht.
6
15
16
Nutzer könnten auf ihren eigenen Geräten auch aufwendige kryptografische Berechnungen ausführen und dafür STARK-Beweise erstellen. Das Ziel: Ethereum soll ein breiteres Spektrum kryptografischer Verfahren unterstützen können, ohne für jedes einzelne einen eigenen nativen Precompile einzuführen.
3
6
Was sich ändern könnte – und was nicht
Wenn das Konzept wie vorgesehen funktioniert, könnten kompakte Abhängigkeiten und gebündelte Prüfungen verringern, wie viele ursprüngliche Signatur- und Beweisdaten in Blöcken mitgeführt werden müssen. Es geht also nicht einfach um „schnellere Kryptografie“: Ein Teil der Arbeit würde auf Nutzer und Mempool-Teilnehmer verlagert, während Ethereum weniger Daten direkt in die Blockchain aufnehmen müsste.
1
13
16
Die Kosten kryptografischer Verfahren verschwinden dadurch aber nicht. Nutzer und Netzwerkteilnehmer müssten die nötigen Daten und Beweise weiterhin erstellen, verbreiten und prüfen. Die verfügbaren Quellen belegen weder eine bestimmte Einsparung bei den Gas-Kosten noch, dass EIP-8288 die umfassenderen Skalierungsprobleme von Ethereum lösen würde.
Welche Fragen noch offen sind
Sicherheit der Beweise und Hashes: Der Entwurf nennt die Korrektheit seiner Verifizierungsschaltungen und der Funktionen für Abhängigkeits-Hashes als Sicherheitsannahmen. Eine spätere Überarbeitung bindet außerdem den Abhängigkeits-Hash des Blocks an die Aggregationsschaltung. Das sind Schutzmaßnahmen, die geprüft werden müssen – kein Nachweis, dass das System bereits vollständig verifiziert oder im Einsatz als sicher bewiesen ist.
32
Überlastungsangriffe auf den Mempool: Die Bündelung erfordert zusätzliche Arbeit und Datenverarbeitung im Mempool. Die Gefahr von Denial-of-Service-Angriffen wird als Risikobereich genannt. Aus den hier verfügbaren Informationen geht jedoch nicht hervor, ob alle Schutzmaßnahmen abgeschlossen oder ausreichend sind.
25
Entwurfsparameter sind keine Regeln für das Mainnet: Eine offizielle Fassung des Entwurfs sieht höchstens 16 Signatur-Abhängigkeiten und eine STARK-Abhängigkeit pro Transaktion vor. Das sind Vorgaben im Entwurf, keine bereits geltenden Ethereum-Regeln.
32
Sicherheit gitterbasierter Signaturen: Berichten zufolge ließ Buterin die Möglichkeit offen, gitterbasierte Precompiles etwa für Konten und Wallets einzuführen, falls deren Sicherheit nachgewiesen wird. Bedenken über mögliche KI-gestützte Angriffe sind ein zu prüfendes Risiko – kein Beleg dafür, dass gitterbasierte Signaturen gebrochen wurden.
17
24
Das offizielle EIP ist weiterhin als Draft gekennzeichnet. Berichte sprechen von Simulationen und Arbeiten an Testnetzen, nicht von einer genehmigten Einführung im Mainnet. Eine endgültige Entscheidung zur Übernahme oder ein Termin für die Einführung sind durch die verfügbaren Quellen nicht belegt.
15
16