Die Ethereum Foundation hat bestätigt, dass der kommende Fusaka Hard Fork eine Obergrenze auf Protokollebene einführen wird, die festlegt, wie viel Gas eine einzelne Transaktion verbrauchen darf, offiziell kodifiziert als EIP-7825. Die Obergrenze liegt bei 2²⁴ Gas – 16.777.216 Einheiten – und markiert damit das erste Mal, dass Ethereum ein Limit pro Transaktion erzwingt, das sich vom Blockgaslimit unterscheidet. Die Änderung ist bereits auf Holesky und Sepolia aktiv und wird im Mainnet live gehen, wenn Fusaka aktiviert wird.
In einem Beitrag veröffentlicht Am 21. Oktober formulierte Toni Wahrstätter die Begründung direkt: „Beginnend mit der kommenden Fusaka-Hard Fork führt EIP-7825 eine Gaslimitobergrenze pro Transaktion von 2²⁴ (≈ 16,78 Millionen Gas) ein.“ In der Mitteilung der Stiftung wird betont, dass die Obergrenze zwar einzelne Transaktionen einschränkt, die Blockgasgrenze jedoch nicht verändert; Stattdessen soll es Denial-of-Service-Vektoren abschwächen, bei denen ein einzelner übergroßer Aufruf einen ganzen Block monopolisiert, und die Vorhersehbarkeit der Blockpackung verbessern, während sich das Netzwerk auf die parallele Ausführung vorbereitet.
EIP-7825 zieht eine klare Grenze zwischen der Komplexität auf Transaktionsebene und dem Durchsatz auf Systemebene. Zuvor konnten außergewöhnlich große Anrufe das Ziel für den gesamten Gasblock erreichen (zeitweise etwa 45 Millionen), was zu zeitlichen und planungsbedingten Pathologien für Entwickler und Prüfer führte.
Die neue Obergrenze sieht vor, dass Arbeitslasten, die 16,78 Millionen Gas überschreiten würden, in kleinere, aufeinanderfolgende Aufrufe aufgeteilt werden. In den Leitlinien der Stiftung wird darauf hingewiesen, dass sich „für die meisten Benutzer nichts ändert“, da die statistische Verteilung realer Transaktionen bereits deutlich unter dem Schwellenwert liegt; Die Risikooberfläche betrifft hauptsächlich Batch-intensive Verträge, Bereitstellungsskripte und spezialisierte Router.
Was das für Ethereum und Benutzer bedeutet
Aus Sicht der Roadmap wird die Obergrenze ausdrücklich als Grundlage für die parallele Ausführung positioniert. Der Blogbeitrag verbindet die Änderung mit erwarteten Bemühungen wie EIP-7928 in der „Glamsterdam“-Ära, wo vorhersehbare, begrenzte Transaktionen eine Voraussetzung für sinnvolle Parallelität in der Ausführungsebene sind. Indem sichergestellt wird, dass mindestens mehrere unabhängige Transaktionen pro Block gepackt werden können – selbst unter pathologischen Mempool-Bedingungen – reduziert die Obergrenze Worst-Case-Konflikte und vereinfacht das Scheduler-Design für Entwickler, die mit parallelisierbaren Ausführungspfaden experimentieren.
Die Spezifikation selbst ist spärlich und mechanisch. In der Zusammenfassung von EIP-7825 wird die Absicht „auf 16.777.216 (2^24) Gas“ pro Transaktion dargelegt, wodurch die Widerstandsfähigkeit gegenüber bestimmten DoS-Vektoren verbessert und die Transaktionsverarbeitung bei steigenden Blocklimits vorhersehbarer wird. Diese Einfachheit macht einen Teil seiner Attraktivität in Core-Dev-Kanälen aus: eine kleine, gut abgegrenzte Einschränkung, die die Vorwärtskompatibilität mit ehrgeizigeren Skalierungsarbeiten gewährleistet.
Die Debatte darüber, wie die Obergrenze kodiert und kommuniziert werden soll, ist seit Monaten aktiv, einschließlich Diskussionen über Benennung und Parametrisierung bei Ethereum Magicians und während AllCoreDevs-Aufrufen. Ein Thread fasste die Kerngarantie zusammen, die von mehreren Mitwirkenden angestrebt wird: Ausrichtung der Blockziele auf Vielfache von 2²⁴, sodass Builder immer mindestens n Transaktionen einbeziehen können, wenn der Mempool n geeignete Transaktionen enthält – ein Argument für Vorhersagbarkeit und nicht für reinen Durchsatz.
Auf operativer Ebene gibt die Stiftung an, dass alle großen Kunden – Geth, Erigon, Reth, Nethermind und Besu – die Änderung in Fusaka-bereiten Versionen implementiert haben, wodurch das Risiko einer kundenübergreifenden Divergenz bei der Aktivierung verringert wird. Der Beitrag betont auch, dass die Semantik von eth_call davon nicht betroffen ist und dass vorsignierte Transaktionen, deren Gaslimits 2²⁴ überschreiten, unterhalb der Obergrenze neu signiert werden müssen. Der Upgrade-Pfad für Entwickler ist unkompliziert: Testen Sie gegen Holesky oder Sepolia, rüsten Sie Batch-Vorgänge um, die mit der Grenze fliehen, und passen Sie die Gasschätzungslogik und -warnungen an, damit sie schnell ausfallen, wenn Konstruktionen die neue Obergrenze überschreiten.
Es lohnt sich, den politischen Kontext zu analysieren. In der Geschichte von Ethereum wurden minimale, allgemeine Einschränkungen bevorzugt, wodurch die Komplexität auf höhere Schichten verlagert wurde. EIP-7825 passt in dieses Muster: Es gibt keine Meinung darüber, was Verträge tun sollen, sondern nur, dass sie eine Obergrenze respektieren, die die Lebendigkeit schützt und die Ausführungsschicht auf eine Zukunft mit mehreren Threads vorbereitet.
Es umgeht auch Änderungen am Gebührenmarkt und überlässt die Blob-Space-Ökonomie und Blockziele anderen EIPs und Forks. Wie die Stiftung es ausdrückte, schafft die Obergrenze „eine sicherere und vorhersehbarere Grundlage für einen höheren Durchsatz in zukünftigen Forks“, eine Aussage, die den Kompromiss kurz und bündig zusammenfasst.
Zum Zeitpunkt der Drucklegung wurde ETH bei 3.835 $ gehandelt.
Ausgewähltes Bild erstellt mit DALL.E, Diagramm von TradingView.com
Redaktioneller Prozess Bei Bitcoinist liegt der Schwerpunkt auf der Bereitstellung gründlich recherchierter, genauer und unvoreingenommener Inhalte. Wir halten strenge Beschaffungsstandards ein und jede Seite wird von unserem Team aus Top-Technologieexperten und erfahrenen Redakteuren sorgfältig geprüft. Dieser Prozess stellt die Integrität, Relevanz und den Wert unserer Inhalte für unsere Leser sicher.
