Der Schlüssel zur Transformation von Ethereum: Die Zukunft der STARK-Rekursiven Beweise in den nächsten zehn Jahren

In den nächsten zehn Jahren muss Ethereum drei Anforderungen erfüllen: post-quantensichere Sicherheit, Datenschutz und Skalierbarkeit.

Verfasst von: _deanstef

Ethereum steht an einem Wendepunkt.

Das erste Jahrzehnt hat eine Hypothese bestätigt: Öffentliche Blockchains können bedeutende Anwendungen in großem Maßstab unterstützen. Smart Contracts, DeFi, Stablecoins, Appchains und Tokenisierung haben Ethereum von einer experimentellen dezentralen Rechenplattform in die Abrechnungsstufe einer wachsenden digitalen Wirtschaft verwandelt.

Das zweite Jahrzehnt bringt andere Herausforderungen mit sich. Ethereum muss die wirtschaftlichen Aktivitäten unterstützen, auf die die Gesellschaft tatsächlich angewiesen ist. Stablecoins werden zur Zahlungsinfrastruktur, tokenisierte Vermögenswerte verlassen die Pilotphase, und Institutionen bauen direkt auf öffentlichen Blockchains auf.

Da Ethereum zur kritischen Infrastruktur wird, muss es für die kommenden Jahre verstärkt werden, um ein robustes, sicheres und effizientes Rechensystem zu sein, das in (dezentraler) Skalierung funktioniert. Konkret muss Ethereum:

• Bedrohungen widerstehen, die noch nicht existieren, insbesondere kryptographisch relevante Quantencomputer (CRQCs).
• Über ausreichende Privatsphäre verfügen, um den Anforderungen der realen wirtschaftlichen Aktivitäten an Vertraulichkeit gerecht zu werden.
• Skalierbarkeit erreichen, ohne die Neutralität, Offenheit und Zensurresistenz aufzugeben, die es ursprünglich ermöglicht haben.

Die Mission der Ethereum-Stiftung hat kürzlich durch CROPS diese Vision klargestellt.

Ethereum muss „vor allem zensurresistent, Open Source, privat und sicher bleiben“.

Mit dem Wachstum der Akzeptanz werden diese Bedingungen nicht weniger wichtig; sie werden vielmehr zur Grundlage, auf der die Akzeptanz beruht. Zwei davon – Privatsphäre und Sicherheit – stehen genau an der Spitze der aktuellen Forschung, was kein Zufall ist.

Die Ethereum-Strawmap skizziert einen schrittweisen, mehrjährigen Evolutionspfad hin zu Lean Ethereum – einer Form, die auf schlanken kryptographischen Beweisen basiert, das Netzwerk auf 10K TPS skaliert und auf post-quantenfähige Primitiven aufrüstet, ohne die Dezentralisierung des Protokolls aufzugeben. Der Technologiestack ist weitgehend um STARKs (Scalable Transparent Argument of Knowledge) aufgebaut. STARK ist ein hash-basiertes, transparentes Beweissystem, das keine vertrauenswürdige Einrichtung benötigt; bemerkenswert ist, dass es aggregiert werden kann, um viele verschiedene Berechnungen in einem einzigen Beweis zu bündeln.

Auf diesem Pfad sehe ich drei große Forschungssäulen:

• Post-quantensichere Sicherheit, überall: Bereiten Sie jede schutzbedürftige Schicht im Protokoll auf den Druck der Migration vor, bevor er eintritt.
• Programmierbare Privatsphäre: Bieten Sie Vertraulichkeit, die mit Verifizierbarkeit und Compliance koexistiert, und integrieren Sie sie in die Infrastruktur selbst.
• Skalierung: Halten Sie Konsens, Endgültigkeit und Verifizierung ausreichend effizient, damit die ersten beiden ohne Leistungseinbußen des Netzwerks implementiert werden können.

Die kryptographischen Kosten der ersten beiden sind höher, und ihr Erfolg hängt von der Fähigkeit des Systems ab, diese Komplexität zu bewältigen. Der dritte Pfad ist der Kleber. Post-quantensichere Primitiven und Privatsphäre-Primitiven existieren bereits, aber die Forschungsfrage ist, wie man sie für den großflächigen Einsatz zugänglich macht. Tatsächlich werden selbst die optimiertesten post-quantensicheren Primitiven und Privatsphäre-Primitiven schwerer sein als die traditionelle Kryptographie, die sie ersetzen, was ihre Einführung in so komplexe Systeme wie Ethereum erschwert. Um sie erschwinglich zu machen, gibt es letztlich nur einen Hebel: die Verwendung von STARK-Beweisen für rekursive Beweise. Der Rest dieses Artikels wird entlang dieser Kette entfaltet.

Post-quantensicherheit

Der Übergang zu einem post-quantensicheren (PQ) Ethereum muss jedes angreifbare Element im bestehenden Protokoll abdecken. Wie Vitaliks Roadmap und ein kürzlich erschienener Artikel von Nethermind über Quantenrisiken zusammenfassen, decken diese Komponenten ECDSA-Signaturen, BLS-Konsensbeweise, KZG-Verpflichtungen für Blobs und rollups ab, die auf L1 abgerechnet werden, basierend auf Paarungen. Ihr gemeinsames Merkmal ist die Schwierigkeit des elliptischen Kurven-Diskreten-Logarithmus-Problems, das der Shor-Algorithmus in polynomieller Zeit auf einem CRQC lösen kann.

Alternative Kandidaten verteilen sich über ein Spektrum:

• Gitterbasierte Signaturschemata (z. B. ML-DSA, Falcon) halten die Signaturen relativ klein, aber die Kosten für die On-Chain-Verifizierung sind hoch, über eine Million Gas, und ihre Aggregationstheorie ist noch nicht ausgereift.
• Hash-basierte Signaturschemata verlassen sich nur auf die Sicherheit der zugrunde liegenden Hash-Funktion, aber auf Kosten des Volumens: Die Signaturgröße kann mehrere KB erreichen, und die Verifizierungskosten können heute mehrere Hunderttausend Gas betragen. Sie unterteilen sich in zustandsbehaftete Varianten wie XMSS, die kleiner sind, aber erfordern, dass der Unterzeichner den Schlüsselstatus verfolgt; und zustandslose Varianten wie SPHINCS+, die größer sind, teurer in der Verifizierung, aber keinen Status verwalten müssen.
• STARK-Beweissysteme basieren auf Hash-Funktionen im Modell der zufälligen Orakel. Sie sind transparent, von Natur aus post-quantensicher und benötigen keine vertrauenswürdige Einrichtung. Ihr Preis ist das Volumen und die Verifizierungskosten. Ein STARK trägt Tausende von Merkle-Pfad-Hashes, sodass die Größe jedes Beweises mehrere Dutzend bis mehrere Hundert KB erreichen kann; bei den heutigen Beweisführern können die On-Chain-Verifizierungskosten mehrere Millionen Gas-Einheiten betragen, was um eine Größenordnung höher ist als die Gas-Kosten von paarungsbasierten SNARKs.

Insgesamt ist die Hauptschwierigkeit bei der Einführung von PQ-Primitiven auf den verschiedenen Schichten des Ethereum-Protokolls die größeren Signaturen und Beweise, die teurere Verifizierung und kompliziertere Protokolle mit sich bringen:

Konsens

Die Größe der Validatorengruppe von Ethereum ist dynamisch, wobei etwa 1/32 der Validatoren in jedem Slot Beweise erbringen (attest). BLS-Aggregation komprimiert ihre Stimmen On-Chain auf so wenig wie 8 Signaturen von 96 Bytes, und genau diese Aggregation macht eine so große Validatorengruppe praktikabel. Doch angesichts von CRQC kann der private Schlüssel eines Validators aus seinem öffentlichen Schlüssel abgeleitet werden, sodass ein Angreifer, der den öffentlichen Schlüssel des Validators kennt, seine Beweise fälschen und letztendlich eine ungültige Kette finalisieren kann. Eine natürliche post-quantensichere Alternative sind zustandsbehaftete Hash-Schemata wie XMSS, da Validatoren beim Unterzeichnen des Konsenses ihren Schlüsselstatus sicher verwalten können. Doch XMSS kann nicht aggregiert werden wie BLS; bei etwa 1 Million Validatoren müsste jeder Slot etwa 31.000 PQ-Signaturen einzeln tragen. Bei etwa 3 kB pro Signatur würde das Datenvolumen pro Slot etwa 90 MB betragen, was mehrere Größenordnungen über dem liegt, was heute durch Aggregation erreicht werden kann. In Szenarien mit endgültiger Slot-Größe wird es noch schlimmer. Um die Finalisierung jedes Blocks in ihren jeweiligen Slots zu erreichen, müsste die gesamte Validatorengruppe in jedem Slot Beweise erbringen, was zu einem Signaturdatenvolumen von mehreren GB führen würde.

Konten

Benutzerkonten verwenden ECDSA zur Authentifizierung. Sobald ein Konto eine Transaktion initiiert, wird sein öffentlicher Schlüssel offengelegt, sodass CRQC den privaten Schlüssel wiederherstellen und im Namen des Eigentümers Transaktionen unterzeichnen kann, wodurch Gelder nach Belieben erschöpft werden können. Es ist unvermeidlich, dies zu ersetzen, aber externe Konten (EOA) können den Signaturstatus nicht wie Validatoren verwalten, sodass sie zustandslose Schemata benötigen, was die Verifizierungskosten auf die Ausführungsebene verschiebt. Derzeit gibt es keinen klaren Gewinner. Die Arbeit der EF konzentriert sich auf das zustandslose Hash-Schema SPHINCS+, obwohl gitterbasierte Schemata weiterhin in Betracht gezogen werden, was weitgehend von den Verifizierungskosten abhängt. SPHINCS+ hat hohe Verifizierungskosten auf der EVM, was der Grund ist, warum einige Arbeiten darauf abzielen, das zustandslose Schema selbst günstiger zu machen: SPHINCS-minus ist ein keccak-natives Verifier; während andere Arbeiten es umgehen, indem sie Konten abstrahieren, um einmalige Schlüssel zu rotieren, sodass jede Signatur ein viel günstigeres einmaliges Schema verwenden kann.

Rollups

Rollups setzen durch die Veröffentlichung von Gültigkeitsbeweisen auf L1 ab. Die derzeit günstigste Verifizierungsmethode basiert auf paarungsbasierten SNARKs: Die Beweise sind nur wenige Hundert Bytes groß, die Verifizierungskosten betragen etwa 200–500k Gas. CRQC würde die Paarungsannahmen, auf denen sie basieren, untergraben, sodass Angreifer Gültigkeitsbeweise für nie erfolgte Statusübergänge fälschen könnten, die L1 akzeptieren und betrügerische Rollup-Status und deren Abhebungen finalisieren würden. Es macht auch viele Tricks, die Rollups zur Aufrechterhaltung niedriger Kosten verwenden, unbrauchbar, wie das Verpacken großer STARKs in einen kleinen endgültigen SNARK zur Abrechnung, da diese äußere Verpackung ebenfalls paarungsbasiert ist. Ohne sie müssten Rollups STARKs direkt auf L1 verifizieren, was Kosten in Millionen Gas-Einheiten verursacht, was um mehr als eine Größenordnung höher ist als SNARKs. Die Erschwinglichkeit der STARK-Verifizierung bleibt derzeit ein offenes Forschungsproblem.

Datenverfügbarkeit

Ethereum-Blobs verwenden KZG-Verpflichtungen, ein Polynomverpflichtungsschema, das für jedes 128 kB Blob eine 48-Byte-Verpflichtung erzeugt. KZG erleichtert die Datenverfügbarkeitsproben, da es (i) konstant große Öffnungen bietet, sodass die Verifizierungskosten für jede Probe niedrig sind, (ii) linear ist und 2D-Proben unterstützt, sowie (iii) reparierbar ist, sodass beschädigte Codierungen auf der Grundlage derselben Verpflichtung repariert werden können. Leider ist KZG auch paarungsbasiert, sodass CRQC Öffnungen fälschen kann und nicht verfügbare Daten als verfügbare Daten ausgeben kann. Post-quantensichere Alternativen müssen von hash-basierten Verpflichtungen stammen, wobei die Frage bleibt, wie viel von KZGs Garantien erhalten bleiben kann. Bestehende post-quantensichere Kandidaten stehen vor unterschiedlichen Kompromissen in Bezug auf Rechen- und Netzwerk-Effizienz, mit größeren Verpflichtungsgrößen und steigenden Beweis- und Verifizierungskosten. FRIDA ist ein transparentes DAS-Schema, das auf FRI basiert und auf 1D Reed-Solomon-Codes aufbaut, dessen Probennehmer die Nähe zu den Codewörtern testet. Es hat den Nachteil von Bandbreite: KZG-Proben müssen nur eine konstant große Öffnung tragen, während jede FRIDA-Probe einen vollständigen Nachweis der Nähe mit sich bringt, sodass jede Probe viel größer ist. ZODA ist eine weitere Alternative für 2D-Codierungen, die jede gesampelte Zeile und Spalte selbstzertifiziert und eine präzise Bindung an die verpflichteten Daten ermöglicht, aber diese Garantie ist pro Probe und lokal (sie deckt nur die Positionen ab, die die Knoten abgefragt haben), und das Sampling erfordert das Herunterladen der gesamten Zeile und Spalte der Codierung. Der dritte Ansatz verpackt die Codierung in STARK. Die Idee ist, in zkVM zu beweisen, dass die verpflichteten Daten ein gültiges Reed-Solomon-Codewort sind. Dann kann ein Beweis die gesamte Codierung präzise zertifizieren – nicht die Nähe, sondern pro Probe – und benötigt keine vertrauenswürdige Einrichtung. Der Preis ist der Durchsatz der Beweise. Die EF-Designs und Benchmark-Studien zu leanDA haben diese Methode gemessen: Auf einem heutigen High-End-CPU beträgt der Durchsatz etwa 0,9 MiB/s und erreicht gelegentlich etwa 1 MiB/s. Die aktuelle Forschung konzentriert sich darauf, sie schnell genug zu machen.

Forschungsrichtungen

Die Überbrückung der Lücke bei der Einführung von PQ-Primitiven wird in den kommenden Jahren ein Schwerpunkt der Forschungsarbeit sein. Wir können die relevanten Forschungsarbeiten in drei interdisziplinäre Richtungen zusammenfassen:

Protokolleffizienz, in zwei Aspekten:

• PQ-Signaturaggregation. Ziel ist es, viele große PQ-Signaturen in einen einzigen Nachweis zu falten, um die Kosten im kritischen Pfad des Protokolls (insbesondere im Konsens) niedrig zu halten. EF's leanVM konnte XMSS bereits mit einer Geschwindigkeit von etwa 1.480 Signaturen pro Sekunde zu einem Nachweis von weniger als 200 KiB aggregieren, und diese Nachweise können rekursiv neu kombiniert werden, sodass Signaturen parallel aggregiert und dann zusammengeführt werden können. Eine offene Frage ist: Kann ein Protokoll entworfen werden, das auf dem Weg zur endgültigen Bestätigung in einem einzelnen Slot (d.h. dass die gesamte Validatorengruppe in jedem Slot einen Nachweis erbringt) und innerhalb möglichst kurzer Slot-Zeiten weiterhin praktikabel ist? Darüber hinaus stellt sich die Frage, wer diese Nachweise generiert und welche Anreize dafür bestehen.
• Transaktionsauthentifizierung. Frames (EIP-8141) ermöglichen es Konten, ihren eigenen Code zur Autorisierung von Transaktionen zu tragen, wodurch die Signaturüberprüfung aus der Protokollebene herausgenommen und in die benutzerdefinierte Logik des Kontos integriert wird. Die Authentifizierung ist nicht mehr an eine feste ECDSA-Signatur gebunden; jedes Konto kann sein eigenes Schema wählen. Ein zu erkundender Bereich ist, wie diese Überprüfung funktioniert: Erfolgt sie durch auf der Kette festgelegte Precompiles für jedes Schema oder durch post-quantenfähige, aggregierbare Nachweise? Letzteres wird durch EIP-8288 untersucht, das die Signaturnachweise vieler Transaktionen in einen einzigen zusammenfaltet, sodass die Größe des Nachweises pro Block und die Bandbreite des Mempools stabil bleiben, selbst wenn die Anzahl der PQ-Transaktionen zunimmt.

Kryptographische Effizienz. Reduzierung der Größe und der Verifizierungskosten von PQ-Signaturen selbst; beispielsweise beträgt die Verifizierungskosten von SPHINCS-minus auf der EVM etwa 94k Gas. Idealerweise sollte die Forschungsgemeinschaft zk-freundliche Signaturen entwerfen, die effizient im zkVM nachgewiesen werden können (EF arbeitet in Richtung leanSPHINCS).

Nachweis-Infrastruktur. Die Nachweis-Kosten von PQ-Primitiven werden hauptsächlich durch die zugrunde liegenden Hash-Operationen bestimmt. Standard-Hashfunktionen für Nachweise (z.B. Keccak, SHA) sind nicht-nativen Operationen, die arithmetisiert werden müssen, was zu Rechenaufwand führt. Es werden zwei Wege erkundet: SNARK-freundliche Hashes wie Poseidon (schnell, aber weniger in der Praxis getestet) und Nachweissysteme, die direkt mit nicht-nativen Operationen umgehen, sodass Standard-Kryptographie ohne teure Feldsimulationen nachgewiesen werden kann. Für Letzteres gibt es schnelle Fortschritte in der Forschung, wie jüngste Arbeiten zu Zinc+ und modulare Verpflichtungen auf Ganzzahlen.

Post-Quanten-Primitiven existieren bereits, aber sie haben größere Datenmengen und höhere Verifizierungskosten. Das Forschungsziel ist es, sie auf der aktuellen Protokollebene praktikabel zu machen. Beispielsweise würde die öffentliche Speicherung sehr großer Signaturen im Mempool die Menge an Daten, die jeder Client speichern und verifizieren muss, explosionsartig erhöhen, während die Verifizierung dieser Signaturen mehr Gas kosten würde, was sowohl für Benutzer als auch für Validatoren eine Belastung darstellt. Schlüsseltechnologien konzentrieren sich auf STARK-Nachweise, die effizient aggregiert werden können, um den Datenaufwand und die Verifizierungskomplexität von O(n) auf O(1) zu verschieben. Clients müssen nicht mehr n verschiedene PQ-Signaturen verarbeiten und verifizieren, sondern nur einen aggregierten Nachweis. Und genau diese Eigenschaften ermöglichen die Skalierung, die wir als Nächstes diskutieren werden.

Programmable Privacy

Ethereum basiert auf vollständiger Transparenz, aber mit der globalen Finanzwelt, die auf die Blockchain umschlägt, wird Privatsphäre unverzichtbar, was derzeit noch nicht erreicht ist. Bestehende Lösungen weisen in zwei Bereichen Mängel auf. Einige fehlen die Programmierbarkeit, die für institutionelle Anwendungsfälle erforderlich ist, in denen starke Vertraulichkeit mit nachweisbarer Compliance koexistieren muss, da beide für Institutionen komplementär und nicht gegensätzlich sind. Andere sind zu kompliziert und schwer zu übernehmen: schlechte Benutzererfahrung, höhere Kosten und manchmal zusätzliche Vertrauensannahmen.

Verbraucherorientierte Shield Pools wie RAILGUN und Privacy Pools bieten Privatsphäre für normale Wallets; während unternehmensorientierte Plattformen wie Paladin programmierbare, compliance-fähige Privatsphäre für Institutionen bieten. Aber derzeit gibt es keine Lösung, die sowohl institutionelle als auch benutzerfreundliche Wallet-Funktionen gleichzeitig bietet; und die Nutzung eines dieser Systeme bedeutet immer noch, dass man mit Off-Chain-Zuständen (wie Merkle-Bäumen, Invalidierern und kryptographischen Schlüsseln) umgehen und für jede Operation Zero-Knowledge-Nachweise generieren muss. Vitaliks maximal einfache L1-Privatsphäre-Roadmap und pcaversaccios Privatsphäre-Roadmap fassen die bestehenden Forschungsrichtungen zur Privatsphäre auf Ethereum gut zusammen. Diese Richtungen können in vier höhere Dimensionen unterteilt werden:

Verfügbarkeit

Hier gibt es zwei Probleme. Erstens sollte der Aufbau einer privaten Transaktion sich anfühlen wie das Senden einer normalen Transaktion, aber heute erfordert es speziell konstruierte Transaktionen, die Nachverfolgung von Off-Chain-Zuständen und die Generierung von Zero-Knowledge-Nachweisen. Zweitens sollte es kostengünstig sein, aber eine private Überweisung bündelt einen SNARK, was bedeutet, dass sie mehr Daten und höhere Verifizierungskosten als öffentliche Überweisungen mit sich bringt, und sobald post-quanten Signaturen und Nachweise hinzukommen, wird dieser Unterschied nur noch größer. Standardisierte Frameworks wie Kohaku und Paladin, die diese Komplexität verbergen können, beginnen, das erste Problem zu lösen, obwohl beide noch in einem frühen Entwicklungsstadium sind. Der Schlüssel zum zweiten Problem liegt in der Nachweisaggregation (vorgeschlagen durch EIP-8288), einer wirtschaftlich effizienten Methode, um viele Nachweise von Transaktionen in einen einzigen zu kombinieren und die Verifizierungskosten zu teilen.

Vertrauenslosigkeit und Zensurresistenz

Heute verlassen sich viele Shield-Protokolle auf Relayer, die im Namen der Benutzer Transaktionen einreichen, was einen vertrauenswürdigen Dritten darstellt, der zensieren, verzögern oder anonymisieren kann. Das Ziel ist es, diese Abhängigkeit zu beseitigen. Frame-Transaktionen (EIP-8141) sind ein erster Schritt: Sie entkoppeln „wer die Transaktion autorisiert“ von „wer Gas bezahlt und wie sie ausgeführt wird“, sodass der Zahler von der signierenden Partei unterschiedlich sein kann und das Shielding von Ausgaben nicht mehr ein kapitalstarkes, identitätsgebundenes Konto erfordert, um auf die Blockchain zu gelangen. Zwei komplementäre Teile füllen diese Lücke. Der EIP-8250 mit Schlüsseln bietet einen unabhängigen Zufallszahlbereich, sodass die Shield-Operationen desselben Absenders sich nicht gegenseitig behindern; der jüngste Root (EIP-8272) erlaubt es Transaktionen, die Merkle-Root zu deklarieren, auf der ihre Nachweise basieren, sodass die Nachweise weiterhin gültig bleiben, während der Baum voranschreitet. Zusammen bieten sie einen stabilen, protokollinternen Verweis zur Validierung von Shield-Transaktionen, sodass ihre Gültigkeit nicht von sich schnell ändernden Zuständen abhängt und jeder die Überprüfung asynchron durchführen kann. Was die Forced Inclusion Lists (FOCIL, EIP-7805) betrifft, so können die Includer die Gültigkeit der Transaktion unabhängig überprüfen und deren Einbeziehung anfordern, was eine Zensurresistenz bietet, die mit einem Relayer-Ansatz nicht erreicht werden kann.

Datenabruf

Das Lesen ist ebenso schwierig wie das Schreiben. Private Zustände (technisch gesprochen, die kryptographischen Notizen, die von den Datenschutzprotokollen verwendet werden) geben den Empfänger nicht im Klartext an, sodass der Client eine große Menge an Daten scannen und speichern muss, nur um die Zahlungen zu finden, die er erhalten hat; und jedes Mal, wenn eine RPC-Anfrage gestellt wird, wird offengelegt, welche Daten er interessiert, was wiederum offenbart, wem diese Daten gehören. Das gleiche Prinzip der Abwesenheit von Mittelsmännern gilt auch hier. Private Information Retrieval (PIR) würde es Clients ermöglichen, von RPC zu lesen, ohne die Abfrage offenzulegen, während nicht-intrusive Nachrichtenerkennungslösungen es ihnen ermöglichen würden, ihre Notizen zu finden, ohne alles scannen zu müssen. Allerdings machen die Kompromisse in der Effizienz und die begrenzte Reife dieser Lösungen ihre Übernahme weiterhin zu einem aktiven Forschungsbereich.

Protokollinterne Privatsphäre

Die ehrgeizigste Richtung besteht darin, private Überweisungen direkt in das Protokoll selbst einzubauen und PQ-Designbeschränkungen von Anfang an zu integrieren, sodass Shield-Bilanzen nicht dem Risiko des „Zuerst sammeln, dann entschlüsseln“ ausgesetzt sind. Die Herausforderungen sind erheblich – von der Rekonstruktion des gesamten kryptographischen Stacks (Verpflichtungen, Invalidierer, Schlüsselverpackungen, Signaturen) auf PQ-Basis bis hin zur Generierung von Nachweisen auf Hardware-Wallets – diese Herausforderungen wurden gut in der Vision von nativen post-quanten privaten ETH umrissen.

Wie bei post-quanten Sicherheit hängen alle vier Richtungen von kostengünstigen Nachweisen und Aggregation ab, und sobald PQ-Beschränkungen angewendet werden, wird jede schwieriger. Privatsphäre wird zu einer Fähigkeit der Infrastruktur selbst, anstatt nachträglich auf die oberste Anwendungsebene aufgesetzt zu werden.

Herausforderungen und die dritte Säule

Diese beiden Säulen haben eine gemeinsame knifflige Eigenschaft: Sie sind kryptographisch kostspielig.

1. PQ-Signaturen sind größer und teurer als die elliptischen Kurven-Schemata, die sie ersetzen.
2. Datenschutzprotokolle hängen end-to-end von schweren Nachweisen ab, was die Komplexität und die Kosten für die Benutzer erhöht.

Wenn sie in großem Maßstab im Protokoll bereitgestellt werden, erhöhen beide die Verifizierungskosten für jeden Knoten im Netzwerk.

Die gleiche Antwort taucht immer wieder auf. Post-Quanten-Signaturen werden in rekursive STARKs gefaltet, quantensichere Datenverfügbarkeit wird in einen STARK kodiert, und private Überweisungen bündeln ihre Nachweise in einen anderen STARK, während Rollups bereits auf diese Weise abgerechnet werden. Die wiederkehrende Frage ist: Wie können wir stärkere Kryptographie finanzieren? Diese Frage reduziert sich jedes Mal auf eine fokussiertere Frage:

Wie kostengünstig und effizient können wir STARKs aggregieren und verifizieren?

Erweiterung der Basis-Schicht

Die rollup-zentrierte Roadmap hat die Ausführung von L1 entfernt, sodass Ethereum sich auf Konsens, Abrechnung und Datenverfügbarkeit konzentrieren kann. Aber die Skalierung kann nicht bei Layer 2 enden. Jeder Rollup erbt alles, was die Basis-Schicht bietet: ihren Konsens, ihre Endgültigkeit, ihre Verifizierung und ihre Datenverfügbarkeit, daher bedeutet die Verbesserung der Basis-Schicht, die Verbesserung von allem, was darauf aufgebaut ist.

Wir konzentrieren uns auf die Skalierung entlang zweier Achsen: Ausführung und Konsens *, und bei beiden ist der entscheidende Hebel derselbe. Rekursive Nachweise und Aggregation können eine große Anzahl von Nachweisen oder eine große Anzahl teurer kryptographischer Überprüfungen als einen einzigen kompakten Nachweis darstellen. Da STARKs andere STARKs verifizieren können, können diese Aggregationen unbegrenzt kombiniert werden; und da rekursive Prozesse jede Ebene in eine feste Größe von Überprüfungen falten, steigen die Verifizierungskosten des endgültigen Nachweises kaum mit der Anzahl der gefalteten Nachweise, sodass jeder Knoten nur einen Nachweis überprüfen muss, anstatt Tausende.

Ausführung

Ausführung bedeutet, mehr Transaktionen in weniger Zeit zu verarbeiten. Nachweisaggregation ermöglicht es Ausführungs-Clients, die Verifizierung einer großen Anzahl von Transaktionen in einem einzigen STARK zu komprimieren, wobei diese Transaktionen nicht vom gleichen Typ sein müssen. Die Verifizierung von post-quanten Signaturen, privaten Überweisungen und Rollup-Abrechnungen kann in dasselbe Aggregat gefaltet werden. Das ist der Grund, warum Frame-Transaktionen – die es Konten ermöglichen, ihre eigene Transaktionsverifizierungslogik zu definieren, anstatt fest codierte Signaturen zu verwenden – in Kombination mit Nachweisaggregation entscheidend für die Ausführungsschicht sind. Jede Transaktion erklärt durch Frame die erforderlichen Überprüfungen als Verpflichtung, und der Ersteller verarbeitet die gesamte Charge in einem rekursiven STARK, anstatt dass jeder Knoten jede Überprüfung inline verifizieren muss. Der vorgeschlagene Frame-Typ für PQ-Signaturen und STARK-Aggregation (EIP-8288) konkretisiert dies, wobei die Kosten „nur von den Erstellern und dem Mempool getragen werden, nicht von allen Validierungs-Knoten“; dieselbe Idee hält auch die Mempool-Bandbreite konstant, wenn die Anzahl der Nachweise zunimmt.

Konsens

Der Konsens selbst umfasst mehrere Probleme, und STARK hilft bei jedem einzelnen.

Durchsatz

Größere Blöcke generieren, ohne die Validierungskosten zu erhöhen. Sobald die Validatoren den Gültigkeitsnachweis überprüfen, anstatt den Block erneut auszuführen, können die Ersteller gültige Nachweise veröffentlichen, während sie die zugrunde liegenden Daten zurückhalten. Daher muss die Datenverfügbarkeit explizit gewährleistet werden. Der Ansatz "blocks-in-blobs" packt Transaktionen in Blobs, wobei die Validatoren die Verfügbarkeit stichprobenartig überprüfen, anstatt die gesamte Last herunterzuladen; der STARK des Vorschlagenden zielt darauf ab, zu beweisen, dass der Block korrekt ausgeführt und wahrheitsgemäß kodiert wurde. So steigen die Validierungskosten mit der Erweiterung des Nachweises, nicht mit der Blockgröße.

Slot-Zeit

Die Intervalle zwischen den Blöcken verkürzen, indem die verfügbare Kette von der Finalitätsmechanik entkoppelt wird. Ein zufällig ausgewähltes kleines Komitee generiert kontinuierlich Blöcke auf dem kritischen Pfad, wie in der schnellen LMD-GHOST-Schicht von mehreren Hundert Validatoren und im Design der entkoppelten Konsensfindung dargestellt; während die vollständige Validatorensammlung parallel außerhalb des kritischen Pfades die Finalität abschließt. Weniger Validatoren sind an jedem Schritt beteiligt, was bedeutet, dass weniger STARK-Aggregationen auf dem heißen Pfad und kürzere Slot-Zeiten erforderlich sind.

Finalität

Die heutige Finalitätszeit von etwa sechzehn Minuten verkürzen, beispielsweise durch eine einzelne Runde der Finalität, indem eine Abstimmungsrunde vom kritischen Pfad entfernt wird.

Diese drei stehen im Widerspruch zu den PQ-Anforderungen. Sobald die Nachweise (Attestierungen) auf hashbasierte Signaturen umschalten, die sich nicht wie BLS aggregieren lassen, wird jede der oben genannten Verbesserungen innerhalb eines angemessenen Bandbreitenbudgets extrem schwierig zu erreichen sein.

STARK wird erneut zur Lösung: Die Nachweise der gesamten Validatorensammlung innerhalb der Ziel-Slot-Zeit zu komprimieren und zu aggregieren. Das minimalistische Ketten-Design bringt dieselbe Technik in den Konsensstatus selbst ein: Jeder Validator beweist sein Guthaben und seinen Status, wobei der Status jedes Validators auf einige Bytes reduziert wird, was einen Weg zu Millionen von Validatoren darstellt.

Hier wird die rekursive STARK zur Grundlage des Protokolls. Diese Teile zusammenzuführen - Ausführungsaggregation, blocks-in-blobs-Nachweise und aggregierte post-quantum Nachweise - ist der Weg, den die Forschung als nächsten Schritt einschlagen muss.

* Die dritte Achse ist die Erweiterung der Datenschicht, aber dies steht in direktem Zusammenhang mit der PQ DA-Forschung.

Ausblick

Der Fahrplan ist ungewiss, Forschung ist nie linear. Aber einige Abhängigkeiten scheinen solide zu sein.

Die rekursive STARK-Aggregation macht stärkere Kryptographie erschwinglich. Stärkere Kryptographie macht post-quantensichere und datenschutzfreundliche Transaktionen auf Ethereum praktikabel. Daher wird Ethereum zur Infrastruktur für reale wirtschaftliche Aktivitäten, ohne seine Offenheit zu opfern. Ob diese stärkeren Primitiven jedoch praktikabel werden, ist nicht garantiert.

Ob STARK-Aggregation Ethereum tragen kann, hängt von einigen wenigen spezifischen und noch offenen Fragen ab:

• Aggregation heterogener Signaturen. In derselben Aggregation verschiedene PQ-Signaturen nachweisen und kombinieren, beispielsweise in demselben STARK hashbasierte Signaturen und gitterbasierte Signaturen aggregieren. Die Kontenebene wird keine einzelne Lösung auswählen, daher muss die Aggregation unabhängig von spezifischen Lösungen sein.
• Effizientes Nachweisen von Hashes. Die Nachweiskosten werden von den zugrunde liegenden Hashes dominiert, der Durchsatz ist noch weit von den Anforderungen entfernt. Dieser Kompromiss besteht darin, dass das Nachweisen von bewährten Hashes (wie Keccak und SHA) auf nicht-nativen Domänen arithmetische Overheads mit sich bringt; während zk-freundliche Hashes (wie Poseidon2) niedrige Nachweiskosten haben, aber weniger kryptographische Analyse erfahren.
• Cross-Domain-Aggregation. Verschiedene Arten von STARK in einem rekursiven Nachweis zusammenfalten - von PQ-Signaturverifikation, Datenschutzüberweisungen bis hin zu Rollup-Zustandsübergängen - ermöglicht es dem gesamten Stack, dasselbe Mal zu validieren.
• Aggregation an den Konsens anpassen. Die zeitlichen Anforderungen des Konsenses direkt angehen: Die vollständige Validatorensammlung innerhalb eines einzelnen Slots aggregieren und den besten Kompromiss zwischen Komitegröße, Slotlänge und Finalität finden, während die Slot-Zeit immer kürzer wird.
• Protokollbereitschaft. Sicherstellen, dass die Infrastruktur, die diese Aggregationen trägt, sowohl auf der Mempool-Ebene (z. B. durch Verwendung von Frame und EIP-8288) als auch auf der Konsensebene vorhanden ist: Bei Millionen von Validatoren müssen die PQ-Signatur-STARK-Nachweise jedes Validators ebenfalls aggregiert werden, genau wie die heutigen BLS-Signaturen.
• Die Anreize richtig gestalten. Aggregation hat die Kosten nur verlagert, nicht beseitigt: Die Nachweisarbeit wird auf die Blockbauer konzentriert, was reale Fragen zu Anreizen und Zentralisierung aufwirft.

Der Aufbau dieser Infrastruktur ist keine Nebenaufgabe, sondern eine Hauptaufgabe. Die Primitiven sind bereits vorhanden, und sie in etwas umzuwandeln, das als Protokoll tatsächlich funktioniert, bevor der Druck zur Migration, der uns dazu zwingt, uns mit diesem Problem auseinanderzusetzen, einsetzt, ist das, was in den kommenden Jahren erforderlich ist.