Interop-Roadmap „beschleunigt“: Nach dem Fusaka-Upgrade könnte Ethereum-Interoperabilität einen entscheidenden Sprung machen

Chainfeeds Zusammenfassung:

Ohne Echtzeit-ZK ist eine wirklich nutzbare Interop-UX kaum möglich.

Quelle des Artikels:

Autor des Artikels:

imToken Labs

Meinung:

imToken Labs: Am 4. Dezember wurde das Ethereum Fusaka-Upgrade offiziell im Mainnet aktiviert, jedoch nicht mit dem gleichen Aufsehen wie das Dencun-Upgrade damals. Der Fokus des Marktes lag hauptsächlich auf der Blob-Skalierung und PeerDAS, wobei die weitere Senkung der L2-Datenkosten im Mittelpunkt stand. Abseits dieses Trubels gibt es jedoch einen unscheinbaren Vorschlag, EIP-7825, der das größte Hindernis für die Implementierung von L1 zkEVM und Echtzeitnachweisen auf Ethereum beseitigt hat und sogar still und leise den Weg für das Endspiel der Interop ebnet. Beim Fusaka-Upgrade lag der Fokus fast ausschließlich auf der Skalierung: Die Blob-Kapazität wurde um das Achtfache erhöht, und durch die zufällige Stichprobenvalidierung von PeerDAS wurde das Kosten-Narrativ im DA-(Data Availability)-Sektor endgültig Geschichte. Günstigere L2s sind zweifellos eine gute Sache, aber für Ethereums langfristige ZK-Roadmap ist EIP-7825 der eigentliche Gamechanger, denn es setzt ein Gas-Limit für einzelne Transaktionen (ca. 16,78 Millionen Gas). Wie allgemein bekannt, wurde das Gas-Limit für Ethereum-Blöcke dieses Jahr bereits auf 60 Millionen erhöht. Doch selbst wenn das Limit weiter steigt, könnte theoretisch jemand mit extrem hohem Gas-Preis eine extrem komplexe „Mega-Transaktion“ senden, die den gesamten Block mit 60 Millionen Gas ausfüllt und so den Block verstopft. Warum also die Begrenzung der Transaktionsgröße? Für normale Nutzertransaktionen hat diese Änderung keinerlei Auswirkungen, aber für ZK Prover (Beweisgeneratoren) ist sie von existenzieller Bedeutung. Dies hängt eng mit der Art und Weise zusammen, wie ZK-Systeme Beweise generieren. Ein einfaches Beispiel: Vor EIP-7825, wenn ein Block eine „Mega-Transaktion“ mit 60 Millionen Gas enthielt, musste der ZK Prover diese extrem komplexe Transaktion sequentiell abarbeiten – keine Aufteilung, keine Parallelisierung möglich. Das ist wie eine einspurige Autobahn, auf der ein riesiger, langsamer LKW fährt und alle anderen Autos (Transaktionen) dahinter warten müssen. Das bedeutet das Aus für „Echtzeitbeweise“ – denn die Zeit zur Beweiserstellung ist völlig unvorhersehbar und kann Dutzende Minuten oder länger dauern. Nach EIP-7825 jedoch, selbst wenn die Blockkapazität in Zukunft auf 100 Millionen Gas steigt, wird jede Transaktion auf maximal 16,78 Millionen Gas begrenzt. Jeder Block wird so in vorhersehbare, begrenzte und parallel verarbeitbare „kleine Arbeitseinheiten“ zerlegt. Das bedeutet, dass die Beweiserstellung auf Ethereum von einem schwierigen „logischen Problem“ zu einem reinen „Rechenleistungsproblem (Money Problem)“ wird: Solange genügend parallele Rechenleistung bereitgestellt wird, können diese kleinen Aufgaben gleichzeitig in sehr kurzer Zeit bearbeitet werden, um ZK-Beweise für riesige Blöcke zu generieren. EIP-7825 ebnet zwar durch die Begrenzung der Transaktionsgröße den physischen Weg für Echtzeitbeweise (Parallelisierung), aber das ist nur eine Seite der Medaille. Die andere Seite ist, wie das Ethereum-Mainnet diese Fähigkeit nutzen kann. Hier kommt das härteste Narrativ der Ethereum-Roadmap ins Spiel – L1 zkEVM. Seit langem gilt zkEVM als der „Heilige Gral“ der Ethereum-Skalierung, nicht nur weil es Leistungsengpässe löst, sondern auch, weil es den Vertrauensmechanismus der Blockchain neu definiert. Der Kernansatz besteht darin, dass das Ethereum-Mainnet in der Lage ist, ZK-Beweise zu generieren und zu verifizieren. Mit anderen Worten: In Zukunft kann nach jeder Blockausführung auf Ethereum ein verifizierbarer mathematischer Beweis ausgegeben werden, sodass andere Nodes (insbesondere Light Nodes und L2s) das Ergebnis bestätigen können, ohne die Berechnung zu wiederholen. Wenn die Fähigkeit zur ZK-Beweiserstellung direkt in die Protokollschicht von Ethereum (L1) integriert wird, muss der Proposer bei jedem Block einen ZK-Beweis generieren. Die Validierungsknoten müssen dann die Transaktionen nicht mehr erneut ausführen, sondern nur noch diesen kleinen mathematischen Beweis verifizieren.