Ethereum könnte bald eine Gasgrenze von 16,77 Millionen für einzelne Transaktionen gemäß EIP-7983 erzwingen, die von Vitalik Buterin und dem Forscher Toni Besstätter vorgeschlagen wurde, um die Leistung zu verbessern und Angriffsflächen zu reduzieren.
Laut dem 6. Juli VorschlagEthereum kann „seine Widerstandsfähigkeit gegen bestimmte Dosvektoren verbessern, die Netzwerkstabilität verbessern und mehr Vorhersehbarkeit für die Transaktionsverarbeitungskosten bieten“, indem eine Obergrenze auf Protokollebene für einzelne Transaktionen implementiert wird.
Unter der aktuellen Struktur kann eine einzelne Ethereum-Transaktion theoretisch die Gasgrenze des gesamten Blocks konsumieren und das Netzwerk den Denial-of-Service-Angriffen und potenziellen Instabilität aussetzen. EIP-7983 befasst sich mit dem Problem, indem er eine Obergrenze von 16,77 Millionen Gaseinheiten pro Transaktion einführt, wobei jede Einheit ein Maß für die Rechenarbeit im Ethereum-Netzwerk darstellt.
Dies würde verhindern, dass eine einzelne Transaktion den Blockraum monopolisiert, und eine gleichmäßigere Verteilung des Gasverbrauchs über Transaktionen hinweg sicherstellen. Transaktionen, die eine Gasgrenze von mehr als 16,77 Mio. angeben, würden während der Blockvalidierung abgelehnt, wodurch sie für die Aufnahme in neue Blöcke nicht berechtigt sind.
Der Vorschlag ändert nicht die gesamte Blockgasgrenze, die von Bergarbeitern und Validatoren im Rahmen des vorhandenen Konsensrahmens einstellbar bleibt. Stattdessen wird eine Einschränkung auf Protokollebene eingeführt, die die Gasverbrauch einzelner Transaktionen einschränken und so die Vorhersehbarkeit und Sicherheit verbessert.
Buterin und Vollstätter argumentieren, dass die 16,77 Mio. CAP einen Gleichgewicht zwischen den angemessenen komplexen Anwendungsfällen wie DEFI -Interaktionen und Vertragsbereitstellungen einräumt und gleichzeitig die Betriebs- und Sicherheitsrisiken verringert.
Die meisten aktuellen Transaktionen liegen Berichten zufolge weit unter diesen Schwellenwert, was bedeutet, dass der Vorschlag die typische Benutzer- oder Entwickleraktivität wahrscheinlich nicht stört.
Die Kappe unterstützt auch eine bessere Kompatibilität mit virtuellen Maschinen (Virtual Machines Null-Wissen), die davon profitieren, dass Transaktionen in kleinere, überschaubarere Komponenten unterteilt werden.
Durch die Durchsetzung von Gasbeschränkungen von Pro-Transaktion fördert EIP-7983 die Zerlegung großer Transaktionen in kleinere, modulare Einheiten. Dieser Ansatz entspricht gut mit den betrieblichen Anforderungen von ZK-basierten Ausführungsumgebungen und kann möglicherweise eine effizientere Erzeugung und Integration von Proofs auf Protokollebene ermöglichen.
EIP-7983 baut auf früheren Arbeiten auf, einschließlich EIP-7825, die in ähnlicher Weise die Vorhersagbarkeit der Transaktionsausführung verbessern wollten. Beide Vorschläge spiegeln eine breitere Bewegung innerhalb des Ethereum -Ökosystems wider, um Komplexität und Leistungs Engpässe auf Protokollebene anzugehen.
Der Vorschlag kommt, als Ethereum die Montage gegenübersteht Wettbewerb von schnelleren und effizienteren Smart Contract -Plattformen.
Zum Beispiel im Juni Solana übertroffen Ethereum in Bezug auf dezentrale Anwendungseinnahmen, die über 146 Millionen US -Dollar generiert. Solana behielt auch einen höheren Anteil an DEX -Volumen bei und zog im Vergleich zu den 4,7 Milliarden US -Dollar von Ethereum 5,78 Milliarden US -Dollar auf.
Inmitten dieser Kulisse hat Buterin nachgefordert Vereinfachung von Ethereums Kerndesign Um die Sicherheit zu verbessern, die Kosten zu senken und die Entwicklung zu erleichtern. Er argumentierte, dass ein schlankeres, zugänglicheres Ethereum die Infrastruktur- und Wartungskosten senken und die Dezentralisierung und Sicherheit verbessern würde.
Getrennt hat Buterin die Reduzierung vorgeschlagen Knotenhardwareanforderungen durch teilweise Staatenlosigkeit. In einem später veröffentlichten Beitrag stellte er ein Konzept ein, bei dem vollständige Knoten die gesamte Kette verifizieren, aber nur den für den Benutzer relevanten Zustand speichern.
