Ethereums Vision 2030: Rechenarbeit wird durch kryptografische Beweise ersetzt – doch wer prüft das Ergebnis?

Vitalik Buterins Vision vom 27. September beschreibt, wie Ethereum von einem System, in dem jeder Verifizierer einen Großteil der Arbeit wiederholt, zu einem System übergeht, in dem Daten abgetastet und die Ausführung mit kompakten Beweisen überprüft werden können. Ein Teil, PeerDAS, wurde bereits ausgeliefert. Der größere Ausführungswandel befindet sich noch in Entwicklung. Ein Beweis kann belegen, dass eine Berechnung bestimmten Regeln folgte, aber Benutzer benötigen weiterhin Daten, eine Möglichkeit, Transaktionen einzureichen, und ein Protokoll, das entscheidet, wessen Ergebnis endgültig wird.

Die Schlagzeilenfrage hat zwei Antworten. Ein Prover erzeugt einen kryptografischen Beweis; ein Verifier, potenziell jeder validierende Node, der die relevante Software ausführt, prüft diesen Beweis anhand der Regeln und öffentlichen Eingaben. Die Ethereum-Roadmap für eine Basis-Schicht-zkEVM besagt, dass die Verifizierung viel kostengünstiger sein sollte als die erneute Ausführung jeder Transaktion. Aber die Entscheidung, ob ein Beweis stichhaltig ist, klärt allein nicht, ob Transaktionsdaten verfügbar sind oder ob ein Operator eine Transaktion eines Benutzers zurückhalten kann.

Buterins Essay vom 27. September, „The cryptographic world computer“, beschreibt das Ziel als eine Kombination aus einer Blockchain, kryptografischer Privatsphäre und Verifizierung sowie dezentralen Off-Chain-Komponenten. Er stellt ein älteres Muster des Herunterladens und erneuten Ausführens einem Modell gegenüber, in dem Nodes Daten abtasten und Beweise verifizieren. Er beschreibt weitere mögliche Änderungen an Konsens und Blockkonstruktion. Dies ist eine persönliche technische Vision, keine endgültige Upgrade-Spezifikation, die von allen Ethereum-Client-Teams ratifiziert wurde.

Die Unterscheidung zwischen dem, was existiert, und dem, was vorgesehen ist, ist wichtig. PeerDAS kam mit Fusaka im Dezember 2025, laut dem Protokoll-Update der Ethereum Foundation vom Februar 2026. Die Foundation sagt, dass Validatoren jetzt Blob-Daten abtasten, anstatt alle herunterzuladen. Ein netzwerkweiter Wechsel zur Verifizierung von prägnanten Ausführungsbeweisen für Basis-Schicht-Blöcke wird nicht als bereits eingesetzt beschrieben. Ein Leser, der hört, dass Ethereum „2030 Beweise verifizieren wird“, sollte fragen, welchen Beweis, welche Berechnung er abdeckt und welche Akteure ihn unabhängig testen können.

PeerDAS prüft den Zugang zu Daten, nicht jede Berechnung

Das bereits eingesetzte Stück ist PeerDAS, oder Peer-to-Peer-Datenverfügbarkeits-Sampling. Rollups legen Transaktionsdaten in den Ethereum-Blob-Speicher, damit andere Teilnehmer genügend Informationen abrufen können, um den Zustand zu rekonstruieren und einen Operator an die Regeln zu halten. Der alte Ansatz, jeden Node jeden Blob herunterladen zu lassen, würde größere Datenmengen für gewöhnliche Validatoren teuer machen. Sampling fordert Nodes auf, kleine Teile anhand kryptografischer Commitments zu prüfen, während das Netzwerk genügend kodierte Teile zur Rekonstruktion verteilt.

Ethereums Erklärung besagt, dass erweiterte Blob-Daten in 128 Spalten unterteilt werden. Ein regulärer Node tritt mindestens 8 zufällig ausgewählten Spalten-Subnetzen bei. Acht geteilt durch 128 ist ein Sechzehntel der erweiterten Daten. Die Kodierung fügt Redundanz hinzu, sodass diese Menge gemäß der Beschreibung der Dokumentation etwa einem Achtel des ursprünglichen Datenvolumens entspricht. Die Zahlen beziehen sich auf die Datenlast eines Standard-Nodes, nicht auf die Behauptung, dass ein Node persönlich die gesamte Historie jedes Rollups zu einem Achtel der Kosten halten kann.

Reed-Solomon-Kodierung erzeugt redundante Datenteile, und kryptografische Commitments helfen einem Knoten zu überprüfen, dass ein abgetastetes Teil zu dem gehört, was angekündigt wurde. Sampling bietet eine probabilistische Verfügbarkeitsgarantie über teilnehmende Knoten hinweg. Es ersetzt nicht die Ausführungsvalidierung. Ein perfekt verfügbarer Stapel von Transaktionen kann einen ungültigen Zustandsübergang enthalten. Ebenso reicht ein gültiger Beweis über einen Zustandsübergang nicht aus, damit ein Benutzer einen Kontozustand rekonstruieren kann, wenn die dafür benötigten Daten außerhalb der Verfügbarkeitsgarantien zurückgehalten werden.

Die Ethereum Foundation sagte, Fusaka habe eine achtfache Erhöhung der theoretischen Blob-Kapazität ermöglicht. Das Wort theoretisch ist wichtig: Der tatsächliche nachhaltige Durchsatz hängt von geplanten Parametererhöhungen, Netzwerkbedingungen und der Rollup-Nutzung ab. Crypto.news hat erklärt, wie Rollups Ethereums Datenschicht nutzen. Buterins neuer Essay behandelt PeerDAS als den ersten sichtbaren Schritt hin zu einem System, das mehr verifiziert und weniger wiederholt; es sollte nicht als das endgültige Proof-of-Execution-Upgrade umgedeutet werden.

Der Prover leistet die Schwerarbeit; unabhängige Knoten überprüfen sie

In einem beweisbasierten Ausführungsmodell muss immer noch jemand Transaktionen ausführen und Beweise über das Ergebnis konstruieren. Diese Partei kann teure Spezialhardware und -software verwenden. Ein prägnanter Beweis ermöglicht es einem Verifizierer, mit viel geringerem Aufwand zu überprüfen, dass die behauptete Zustandsänderung dem Programm und den Eingaben folgt, die unter den Regeln des Protokolls festgeschrieben wurden. Eine mathematische Überprüfung erfordert nicht, dass der Verifizierer dem beweiserstellenden Unternehmen allein deshalb vertraut, weil es den Beweis erzeugt hat.

An diese Aussage sind Bedingungen geknüpft. Der Verifizierer muss ein solides Beweissystem mit dem richtigen Verifikationsschlüssel, öffentlichen Eingaben und vereinbarten Ausführungsregeln betreiben. Ein fehlerhafter Schaltkreis könnte die falsche Aussage perfekt beweisen. Ein Fehler in einer Client-Implementierung könnte einen Beweis akzeptieren, den er ablehnen sollte. Ein Upgrade-Schlüssel, der Verifizierercode ohne robuste Kontrollen ändern kann, könnte die Garantie schwächen. In einem Live-Protokoll sind unabhängige Implementierungen und Überprüfung ebenso wichtig wie schnelle Beweiserzeugung.

Ethereums L1-zkEVM-Roadmap-Seite beschreibt eine Zukunft, in der ein Knoten einen Beweis der Blockausführung überprüft, anstatt jede Transaktion zu wiederholen. Das erklärte Ziel ist es, die Ressourcenkosten der Verifikation zu senken. Das würde es mehr Menschen erleichtern, Blöcke zu überprüfen, wenn die Beweisverifikation auf zugänglicher Hardware praktikabel bleibt. Es bedeutet nicht, dass jeder Haushalt einen Blockbeweis erzeugen kann, noch dass die Beweiserzeugung gleichmäßig verteilt sein wird.

Crypto.news berichtete über einen Hardware-Wettbewerb rund um das Beweisen. Die nützliche Unterscheidung ist die zwischen denen, die einen Beweis rechtzeitig für die Chain erzeugen können, und denen, die einen Beweis kostengünstig verifizieren können. Die Beweiserzeugung könnte sich bei Firmen mit spezialisierter Hardware konzentrieren, ohne dass diese Firmen automatisch einen gültigen Zustandsübergang fälschen könnten. Sie könnte dennoch eine Liveness-Abhängigkeit einführen: Wenn zu wenige Parteien Beweise schnell genug erzeugen können, könnten Blöcke oder Finalität langsamer werden, selbst wenn das Beweissystem mathematisch solide bleibt. Das ist ein anderes Risiko als die Akzeptanz eines ungültigen Beweises.

Die Verifikationsfrage hat daher eine menschliche Antwort ebenso wie eine mathematische. Entwickler legen den Schaltkreis fest, Forscher prüfen ihn, Client-Teams implementieren ihn, Knotenbetreiber betreiben Verifizierer, und Teilnehmer entscheiden, ob sie Protokoll-Upgrades akzeptieren. Buterin kann eine Richtung vorschlagen. Er kann nicht allein einen zukünftigen Verifizierer sicher oder für das Netzwerk verpflichtend machen.

Drei Versprechen werden oft in das Wort Beweis gefaltet

Nehmen wir einen Benutzer, der eine Zahlung über ein Rollup sendet. Die Transaktion muss in einen geordneten Stapel aufgenommen werden. Die Daten des Stapels müssen unter dem vom Rollup gewählten Modell verfügbar gemacht werden. Schließlich muss die resultierende Zustandsänderung ihren Regeln folgen. Reihenfolge, Verfügbarkeit und Korrektheit sind separate Versprechen. Ein Korrektheitsbeweis adressiert das letzte für eine spezifizierte Berechnung. PeerDAS adressiert die Verfügbarkeit von Ethereum-Blob-Daten. Ein Sequencer- oder Blockbildungsmechanismus beeinflusst, welche Transaktionen aufgenommen werden und in welcher Reihenfolge.

Crypto.news untersuchte Sequencer als einen eigenständigen Kontrollpunkt. Ein vollkommen gültiger Beweis kann bestätigen, dass ein Batch gemäß den Regeln verarbeitet wurde, selbst wenn sein Betreiber die Transaktion eines bestimmten Kunden ausgeschlossen hat. Ein Nutzer könnte je nach Design des Rollups einen Ausweg oder eine erzwungene Einbeziehung haben, aber der Beweis selbst erzwingt keinen fairen Zugang. Ein Sequencer kann auch Transaktionen umordnen und dennoch einen gültigen Zustandsübergang erzeugen. Die bewiesene Aussage darf nicht mit allen Eigenschaften verwechselt werden, die Nutzer von einem Markt erwarten.

Die Datenseite ist genauso leicht zu verwischen. Ethereums Validium-Dokumentation beschreibt Systeme, die Gültigkeitsbeweise verwenden, aber keine Transaktionsdaten an die Ethereum-Hauptkette senden. Ihre Ausführung mag gemäß einem Verifizierer korrekt sein, doch ein Datenverfügbarkeitsfehler kann Nutzer daran hindern, den Zustand zu rekonstruieren oder wie erwartet abzuheben. Ein Ethereum-Rollup, das ausreichende Daten auf Ethereum veröffentlicht, hat ein anderes Verfügbarkeitsmodell. Beide einfach „ZK“ zu nennen, verbirgt einen kritischen Unterschied in der Fähigkeit eines Nutzers, einen Kontozustand ohne den Betreiber wiederherzustellen.

Der einfachste Test ist eine mentale Checkliste mit drei Spalten. Fragen Sie, wer eine Transaktion in den Batch bekommt. Fragen Sie, wo die Daten abgerufen werden können, die zur Rekonstruktion der Guthaben benötigt werden. Fragen Sie, welcher Vertrag oder Knoten den Beweis der Zustandskorrektheit verifiziert. Wenn ein Projekt nur die dritte Frage beantwortet, hat es die ersten beiden nicht beantwortet. Deshalb spricht Buterins Essay über Blockkonstruktion und Netzwerkdatenverteilung neben Kryptographie, anstatt das gesamte System durch einen einzigen magischen Beweis zu ersetzen.

Die Basisschicht kann nicht jede Eigenschaft von bestehenden Rollups übernehmen

ZK-Rollups übermitteln bereits Gültigkeitsbeweise an Ethereum unter ihren eigenen Verträgen und Regeln. Die Ethereum-Dokumentation zu ZK-Rollups beschreibt einen Betreiber, der einen Beweis für einen Batch erstellt, und einen Verifizierer-Vertrag, der einen neuen Zustandswurzel erst nach der Verifizierung akzeptiert. Das ist ein nützlicher Präzedenzfall für die Beweisführung von Berechnungen. Es bedeutet nicht, dass Ethereums Basisschicht bereits die gesamte Ausführungsvalidierung auf solche Beweise verlagert hat.

Der Umfang unterscheidet sich. Ein Rollup beweist seinen eigenen Zustandsübergang unter seiner eigenen virtuellen Maschine und seinem eigenen Vertrag, während Ethereums Basisschicht-Verifizierer die Blockausführung des Protokolls auf eine Weise prüfen müsste, die Client-Teams akzeptieren. Eine Diskrepanz zwischen der benutzerdefinierten Logik eines Rollups und den Ausführungsregeln des Ethereum-Mainnets ist kein Detail, das ein schnellerer Beweiser wegwünschen kann. Beweissysteme müssen auch durch Protokoll-Upgrades, neue Transaktionstypen und feindselige Eingaben hindurch robust bleiben.

Eine Anwendung kann ihre Arithmetik an einen Coprozessor auslagern und ein Ergebnis mit einem Beweis liefern, aber die Basiskette entscheidet weiterhin, ob sie die öffentlichen Eingaben akzeptiert, Verpflichtungen speichert und den resultierenden Zustand abwickelt. Eine App kann möglicherweise ihr eigenes Beweiser-Design wählen; eine Basisschicht-Regel erfordert eine breite Koordination über Clients und Validatoren hinweg. Buterins Formulierung „kryptographischer Weltcomputer“ ist als architektonische Richtung nützlich, nicht als Versprechen, dass ein einziger Beweisdienst ganz Ethereum betreiben wird.

Es gibt einen offensichtlichen Widerspruch, der es wert ist, aufgelöst zu werden. Wenn Knoten aufhören, erneut auszuführen, wie findet dann jemand einen Fehler in der Berechnung, die bewiesen wird? Eine Antwort ist, dass Entwickler eine unabhängige vollständige Ausführung durchführen und sie während der Entwicklung und nach dem Deployment mit Beweisergebnissen vergleichen können. Eine andere sind mehrere Beweisimplementierungen und formale Überprüfungen von Schaltkreisen. Das genaue Ethereum-Design ist noch nicht finalisiert. Ein Protokoll, das die erforderliche erneute Ausführung reduziert, verbietet es nicht, dass Menschen zusätzliche Überprüfungen durchführen; es ändert, was jeder gewöhnliche validierende Knoten für den Konsens tun muss.

Das Update zu den Protokollprioritäten vom September der Foundation behandelt eine L1-zkEVM und formale Verifikation als wichtige Arbeitsströme. Das ist ein Beweis für aktive Entwicklung, nicht für ein festgelegtes Startdatum. Der Sicherheitsstandard ist hoch, weil ein Fehler in einem Basisschicht-Beweissystem die Grundlage beeinträchtigen würde, auf die andere Anwendungen angewiesen sind.

Beweise können die Verifikation verbessern, während das Zustandsproblem wächst

Buterin nennt den Zugang zu einem sehr großen gemeinsamen Zustand als ein besonders schwieriges ungelöstes Problem. Crypto.news untersuchte seinen separaten Vorschlag für proof-basiertes Mempool-Scaling, der auf einen anderen Engpass als die finale Zustandsausführung abzielt. Ein Beweis kann eine Berechnung bestätigen, aber der Beweiser muss die Informationen beschaffen, von denen diese Berechnung abhängt: Guthaben, Vertragsspeicher und anderer Kontozustand. Wenn viele Transaktionen gleichzeitig denselben Zustand berühren, wird es schwieriger, die Berechnung auf Maschinen aufzuteilen. Eine Zahlung von einem Konto und ein Swap, der einen Liquiditätspool berührt, können nicht beide aus inkonsistenten Momentaufnahmen finalisiert werden.

Der Aufsatz legt nahe, dass Anwendungen die Reihenfolge und nicht-kommutative Zustandsänderungen onchain platzieren könnten, während sie andere Berechnungen vor der Aufnahme aggregieren. Das ist ein architektonischer Anreiz, keine bindende Regel für Entwickler heute. „Nicht-kommutativ“ bedeutet, dass eine Änderung der Reihenfolge das Ergebnis ändert. Zwei Personen, die aus demselben dünnen Pool kaufen, können unterschiedliche Preise erhalten, je nachdem, welche Reihenfolge zuerst verarbeitet wird. Kein Beweis macht diese beiden Reihenfolgen wirtschaftlich äquivalent.

Dies ist ein nützliches Gegengewicht zu einem simplistischen Versprechen kostenloser Skalierung. Parallele Arbeit ist einfacher, wenn Aufgaben sicher getrennt werden können. Gemeinsamer Zustand erzeugt Abhängigkeiten. Ein Prover kann viele unabhängige Berechnungen schnell ausführen und dennoch auf den Zugriff auf umkämpften Zustand oder die Reihenfolgewahl eines Block Builders warten. Die alleinige Verbesserung der Beweisgeschwindigkeit löst weder Datenbankkonkurrenz noch Zensur oder die Kosten dafür, genügend Informationen für andere Teilnehmer verfügbar zu machen.

Nach Buterins Ansicht könnte eine stärkere dezentrale mittlere Schicht Arbeit parallel verarbeiten und in einigen Fällen Metadaten darüber schützen, woher Anfragen stammen. Solche Infrastruktur könnte die Leistung oder Privatsphäre verbessern, müsste aber spezifizieren, wie Daten verteilt werden, wer beitreten kann und welche Fehler einen Ausweg haben. Die Privatsphäre für die Zahlung eines Nutzers ist keine automatische Folge der Verwendung eines Gültigkeitsbeweises. Öffentliche Eingaben, Wallet-Aktivität und Netzwerk-Metadaten können weiterhin Informationen preisgeben, es sei denn, ein System schützt auch diese Teile.

Unabhängigkeit kann vor dem endgültigen Fork gemessen werden

„Jeder kann verifizieren“ hat praktische Bedingungen. Ein gewöhnlicher Knoten benötigt den Verifier-Code, die relevanten öffentlichen Eingaben, eine Verbindung zum akzeptierten Zustand der Chain und genügend Verarbeitungskapazität, um die Prüfung innerhalb der Protokollzeitlimits abzuschließen. Wenn ein Beweis Sekunden zur Überprüfung auf einer bescheidenen Maschine benötigt, aber Stunden zur Erzeugung auf teurer Hardware, kann das System eine breite Verifikation mit schmaler Produktion erreichen. Das kann ein akzeptabler technischer Kompromiss für Korrektheit sein, vorausgesetzt, ein Ausfall eines Produzenten wird nicht zu einer dauerhaften Blockade der Abwicklung.

Das Experiment ist in groben Zügen unkompliziert. Führen Sie Verifier-Software von mehr als einem Client-Team gegen denselben gültigen Blockbeweis aus und bestätigen Sie, dass sie ihn akzeptieren. Liefern Sie veränderte öffentliche Eingaben und bestätigen Sie die Ablehnung. Fragen Sie, ob separate Proving-Teams akzeptierte Beweise für dieselben Regeln erzeugen können, wie schnell sie dies tun können und welche Hardware jeweils erforderlich ist. Die Wiederholung auf einem öffentlichen Testnetz unter hoher Last würde mehr über die Bereitschaft aussagen als eine Labordemonstration eines schnellen Beweises. Die genauen Ethereum-Akzeptanzkriterien bleiben Protokollarbeit unterworfen; dies sind beobachtbare Fragen, keine offiziellen Bestehensgrenzen.

Die Beweiserzeugung hat einen weiteren Fehlermodus, den eine Gültigkeitsprüfung allein nicht erfassen kann. Ein Prover könnte es ablehnen, einen Beweis für einen vorgeschlagenen Block zu erstellen. Ein Verifier kann einen Beweis nicht akzeptieren, der nicht angekommen ist. Ein Design kann dies adressieren, indem es mehrere unabhängige Prover, einen Fallback-Ausführungspfad, angepasste Timing oder andere Mechanismen ermöglicht. Die Wahl wirkt sich auf Komplexität, Kosten und Zeit bis zur Finalität aus. Ethereums aktuelle Basis-Schicht-Regeln sollten nicht als Auswahl einer dieser zukünftigen Lösungen beschrieben werden, nur weil eine Roadmap besagt, dass Beweisverifikation ein Ziel ist.

Unabhängigkeit bedeutet auch, dass ein Nutzer die Informationen erhalten kann, die benötigt werden, um seinen eigenen Anspruch auf Vermögenswerte zu verifizieren. Ein Beweis, dass ein Zustandswurzel dem Code folgte, ist mächtig, aber ein Nutzer, der den Pfad von seinen Kontodaten zu dieser Wurzel nicht rekonstruieren kann, ist für eine praktische Kontostandsprüfung immer noch auf einen Vermittler angewiesen. PeerDAS macht die Verfügbarkeit von Blob-Daten für jeden Knoten weniger anspruchsvoll, während es auf Verteilung und Sampling über das Netzwerk angewiesen ist. Anwendungsdaten, die anderswo gespeichert werden, benötigen ihre eigenen Verfügbarkeitsgarantien. Der Beweisverifier der Chain kann einen externen Betreiber nicht zwingen, zurückgehaltene Aufzeichnungen zu veröffentlichen.

Schließlich muss das verifizierte Programm das Programm sein, das Nutzer denken, dass es ist. Ein öffentlicher Hash des Verifier-Codes, ein dokumentierter Upgrade-Prozess und unabhängige Tests des Schaltkreisverhaltens ermöglichen es Außenstehenden, die beworbene Regel mit dem zu vergleichen, was Knoten tatsächlich durchsetzen. Formale Verifikation kann die Wahrscheinlichkeit eines Logikfehlers verringern, aber auch sie beginnt mit einer von Menschen geschriebenen Spezifikation. Das überprüfbare Ergebnis ist nicht „Kryptographie hat Vertrauen gelöst“. Es ist, dass eine spezifizierte Behauptung unabhängig abgelehnt werden kann, wenn ihre Evidenz ungültig ist, ohne dass jeder Knoten die vollen Kosten für ihre Erzeugung tragen muss.

Hegota ist ein Marker, keine Garantie für eine Veröffentlichung im Jahr 2030

Buterin bezieht sich auf Hegota, einen für 2027 geplanten Fork, als möglicherweise das letzte Upgrade, dessen Komponenten einem Ethereum-Beobachter von 2015 vertraut wären. Spätere Arbeiten in seiner Darstellung würden rekursive STARKs, formale Verifikation, optimierten Konsens und Quantensicherheit umfassen. Crypto.news berichtete über das separate Quantenziel für 2029 als Planungsziel. Weder der Essay noch ein Zieldatum beweisen, dass jede vorgeschlagene Komponente termingerecht fertiggestellt und übernommen wird.

Ethereum-Upgrades erfordern Spezifikationen, Client-Implementierungen, Testnetzwerke, Sicherheitsüberprüfungen und Koordination zwischen den Teilnehmern. Eine Strawmap ist eine Karte von Forschung und möglichen Meilensteinen, keine Onchain-Umsetzung. Man kann verifizieren, dass PeerDAS eingesetzt wird, indem man sich die Fusaka-Veröffentlichung und die aktuellen Knotenregeln ansieht. Man kann ein zukünftiges allgemeines Basis-ZkEVM nicht verifizieren, indem man die blaue Spalte 2030 eines Essays betrachtet. Beweise werden zuerst in öffentlichen Spezifikationen und Tests erscheinen, dann in einem konkreten Fork-Plan und der Produktionsaktivierung.

Das Argument für Buterins Ansatz ist stark. Wenn Verifizierung kostengünstig wird und Daten sicher gesampelt werden können, können mehr Nutzer unabhängig ein größeres System überprüfen, ohne Maschinen zu kaufen, die proportional zu all seiner Berechnung und seinen Daten sind. Die Herausforderung ist ebenso real: Der Proving-Stack muss sicher, wettbewerbsfähig produziert und schnell genug sein, um das System am Laufen zu halten, während Daten und Reihenfolge zugänglich bleiben. Ein Netzwerk mit kostengünstiger Verifizierung, aber einem einzigen unverzichtbaren Prover oder Sequencer kann immer noch fragil sein.

Der Essay klärt nicht, wer jeden Beweis erstellen wird oder welches Beweissystem gewinnt. Er identifiziert einen Test, der für Nutzer wichtig ist: Kann ein gewöhnlicher unabhängiger Teilnehmer ein schlechtes Ergebnis ablehnen, die Daten wiederherstellen, die er benötigt, um seinen eigenen Zustand zu kennen, und eine Transaktion trotz eines einzelnen Operators einreichen? Jede Antwort erfordert einen separaten Mechanismus. Die kryptografische Überprüfung ist gerade deshalb leistungsstark, weil sie von Personen wiederholt werden kann, die nicht die schwere Arbeit geleistet haben.

Worauf man achten sollte

• L1-zkEVM-Spezifikationen. Achten Sie auf einen konkreten Verifier, ein öffentliches Input-Format und Ausführungsregeln, die von allen Clients akzeptiert werden.
• Prover-Vielfalt. Mehrere unabhängige Implementierungen und gemessene Hardware-Anforderungen werden zeigen, ob die Proof-Erstellung einen einzigen Engpass hat.
• PeerDAS-Messungen. Prüfen Sie den Blob-Durchsatz und die Knoten-Bandbreite, während die Parameter nach dem Start im Dezember 2025 erhöht werden.
• Hegota-Entscheidungen. Ein endgültiger Fork-Umfang ist wichtiger als Kandidaten-Features in einer Roadmap-Entwurfsversion.
• Absicherungen für Daten und Reihenfolge. Untersuchen Sie, ob Rollups und zukünftige Base-Layer-Designs die unabhängige Rekonstruktion und die Aufnahme von Transaktionen gewährleisten.

FAQ