Der Ethereum-Mitbegründer Vitalik Buterin hat am 6. September ein langfristigeres Transaktionsmodell skizziert, das es dem Netzwerk ermöglichen könnte, einige Validierungsarbeiten parallel zu verarbeiten.
Zusammenfassung
- Buterin schlug vor, Transaktionsaktionen von Abhängigkeiten zu trennen, damit Ethereum später jede Komponente unabhängig optimieren kann.
- Zu den Abhängigkeiten gehören Signaturen, Zustandsnachweise und Gültigkeitsbedingungen, die Transaktionen erfüllen müssen, bevor die Ausführung beginnt.
- Reine Abhängigkeiten könnten einmalig von Mempools überprüft und später in rekursive STARK-Beweise komprimiert werden.
- EIP-8141 schlägt Rahmentransaktionen mit programmierbarer Validierung, Ausführung und Gaszahlung innerhalb eines Transaktionsformats vor.
- Ethereum-Entwickler haben EIP-8141 noch nicht für ein Mainnet-Upgrade genehmigt oder Bereitstellungstermine veröffentlicht.
Sein Vorschlag trennt die Auswirkungen, die durch Transaktionen erzeugt werden, von den Bedingungen, die erfüllt sein müssen, bevor diese Auswirkungen eintreten können.
Buterin beschrieb die beiden Komponenten in einem detaillierten Beitrag als „Aktionen“ und „Abhängigkeiten“. Aktionen ändern den Zustand von Ethereum, wie das Übertragen von ETH oder das Aufrufen eines Vertrags. Abhängigkeiten decken die Informationen ab, die erforderlich sind, um festzustellen, dass eine Transaktion gültig ist.
Eine digitale Signatur ist ein Beispiel für eine Abhängigkeit. Weitere Beispiele sind Merkle-Beweise, die zeigen, dass ein nicht ausgegebener Output existiert, Nullwissen-Beweise und Zustandsbedingungen, die wahr bleiben müssen, wenn eine Transaktion in einen Block aufgenommen wird.
Buterin argumentierte, dass die explizite Unterscheidung Ethereum helfen könnte, zu skalieren, ohne seine flexible Ausführungsumgebung aufzugeben. Der Vorschlag bleibt jedoch Teil der laufenden Protokollforschung. Ethereum-Entwickler haben das vollständige Design für die Bereitstellung nicht genehmigt.
Ethereum könnte Transaktionsabhängigkeiten parallel verarbeiten
Ethereum-Transaktionen kombinieren derzeit Autorisierung, Gebührenzahlung und Ausführung in einem gemeinsamen Verarbeitungsablauf. Knoten prüfen, ob eine Transaktion ordnungsgemäß signiert ist, ob der Absender sie bezahlen kann und ob ihre Anweisungen erfolgreich ausgeführt werden.
Einige dieser Prüfungen hängen nicht von den endgültigen Zustandsänderungen der Transaktion ab. Buterin sagte, solche Abhängigkeiten könnten separat und in vielen Fällen gleichzeitig verarbeitet werden.
Beispielsweise muss ein Validator möglicherweise eine Signatur bestätigen, bevor er eine Transaktion akzeptiert. Diese Verifizierung muss nicht unbedingt auf nicht zusammenhängende Signaturen warten, die an anderen Transaktionen hängen. Wenn mehrere unabhängige Prüfungen im Voraus bekannt sind, können Clients die Arbeit auf verfügbare Verarbeitungsressourcen verteilen.
Zustandsabhängige Prüfungen erfordern größere Sorgfalt. Eine Bedingung, die an einen Kontostand oder einen Speicherplatz gebunden ist, kann ungültig werden, wenn eine frühere Transaktion denselben Zustand ändert. Buterin sagte, Mempools könnten über diese Bedingungen effektiver nachdenken, wenn Transaktionen deklarieren, auf welche Teile des Zustands sie zugreifen.
Der Ansatz würde vorhersehbare Transaktionen belohnen. Operationen, die ihre Abhängigkeiten klar angeben, könnten niedrigere Gaskosten erhalten, da Clients sie effizienter verifizieren könnten. Transaktionen, die dynamische Aufrufe und unvorhersehbaren Zustandszugriff erfordern, würden möglich bleiben, könnten aber mehr kosten.
Buterin schätzte, dass mehr als 90 % der Ethereum-Aktivität nach Volumen nicht das volle Maß an dynamischer Flexibilität des Netzwerks erfordern. Diese Zahl ist seine Einschätzung und keine veröffentlichte Netzwerkmessung innerhalb des Beitrags. Das allgemeinere Argument ist, dass häufige Übertragungen und routinemäßige Vertragsinteraktionen restriktivere Formate verwenden könnten, ohne spezialisierte Anwendungen einzuschränken.
Das vorgeschlagene Modell würde das flexible Kontosystem von Ethereum für Transaktionen bewahren, die es benötigen. Vorhersehbarere Aktivitäten könnten statisch analysierbare Strukturen verwenden, die Teilen des Bitcoin-Transaktionsmodells ähneln.
Bitcoin verwendet ein Modell unverbrauchter Transaktionsausgaben, bei dem eine Transaktion die Ausgaben identifiziert, die sie ausgeben möchte. Ethereum verwendet normalerweise Konten mit Guthaben, Nonces und programmierbarem Vertragsspeicher. Buterin schlägt nicht vor, dass Ethereum sein Kontomodell durch die Architektur von Bitcoin ersetzt. Er beschrieb ein Spektrum, das Ideen aus beiden Systemen kombiniert.
EIP-8141 bietet einen allgemeinen Transaktionsrahmen
EIP-8141 ist ein Entwurf eines Ethereum-Verbesserungsvorschlags für einen neuen Transaktionstyp, der als Frame-Transaktion bezeichnet wird. Er unterteilt eine Transaktion in Vertragsaufruf-Frames, die die Berechtigung validieren, die Gaszahlung genehmigen und Benutzeroperationen ausführen können.
Der offizielle Vorschlag besagt, dass die Gültigkeit von Transaktionen und die Gebührenzahlung nicht mehr ausschließlich von einer Standardsignatur abhängen, die der äußeren Transaktion beigefügt ist. Stattdessen könnte der Kontocode die erforderlichen Autorisierungs- und Zahlungsregeln definieren.
Frame-Transaktionen könnten gesponserte Gebühren, Zahlungen in anderen Token als ETH, Schlüsselrotation und Transaktionsbündelung unterstützen. Sie könnten auch extern verwalteten Konten ermöglichen, Kontenabstraktionsfunktionen zu erhalten, ohne auf dieselbe Vertragsbereitstellung in jedem kompatiblen Netzwerk angewiesen zu sein.
Unter der vorgeschlagenen Struktur würden Verifizierungs-Frames feststellen, ob der Absender die Transaktion autorisiert hat. Separate Frames könnten festlegen, wer die Gebühren zahlt, und dann die angeforderten Operationen ausführen.
Diese Struktur entspricht Buterins Unterscheidung zwischen Abhängigkeiten und Aktionen. Verifizierungs-Frames behandeln Bedingungen, die erfüllt sein müssen. Absender-Frames behandeln die Operationen, die den Zustand ändern.
Das Format könnte auch die Interoperabilität zwischen Netzwerken der Ethereum Virtual Machine verbessern. Verschiedene Ketten könnten dieselbe minimale Transaktionsstruktur unterstützen, während sie ihre eigenen Verifizierungswerkzeuge, Precompiles oder Kontofunktionen anwenden.
Buterin beschrieb das potenzielle Format als eine grundlegende Liste von Aufrufen mit Flags, die ihre Funktion identifizieren. Ein Aufruf könnte als reine Abhängigkeit, als zustandsabhängige Verifizierung oder als Aktion markiert werden. Die Transaktion würde auch Standardinformationen wie ihren Ursprung und ihre Nonce enthalten.
EIP-8141 bleibt als Entwurf eines Kernvorschlags eingestuft. Seine aktuelle Spezifikation enthält detaillierte Regeln für die Aufnahme in den Mempool, Frame-Ausführung, Belege, Signaturen, Gasabrechnung und Transaktionsweitergabe. Diese Details können sich während der Überprüfung ändern.
Ethereum-Entwickler haben auch technische Bedenken diskutiert. Dazu gehören Denial-of-Service-Risiken, Regeln für Transaktionsersetzungen, Tooling-Änderungen, Grenzen für ausstehende Transaktionen und Einschränkungen für Verifizierungs-Frames.
Eine Diskussion stellte fest, dass der vorgeschlagene öffentliche Mempool normalerweise nur eine ausstehende Frame-Transaktion pro Absender behalten würde. Entwickler haben hinterfragt, wie sich diese Regel auf Konten auswirken würde, die regelmäßig mehrere Transaktionen innerhalb eines Blocks einreichen.
Andere Teilnehmer haben untersucht, ob das Format zusätzliche Komplexität für Wallets, Blockbuilder und die Remote Procedure Call-Schnittstellen von Ethereum mit sich bringt. Diese Fragen müssen gelöst werden, bevor Client-Teams eine stabile Spezifikation implementieren können.
Rekursive STARKs könnten wiederholte Verifizierung entfernen
Buterins langfristigeres Modell geht über EIP-8141 hinaus. Er schlug vor, dass Abhängigkeiten, die keinen Zustandszugriff erfordern, einmal auf der Mempool-Ebene überprüft werden könnten, anstatt von jedem Validator wiederholt zu werden.
Eine reine Abhängigkeit könnte eine kryptografische Signatur oder einen Beweis enthalten, dessen Gültigkeit sich nicht mit dem Zustand von Ethereum ändert. Nach der Überprüfung könnte das Netzwerk mehrere Verifizierungsarbeiten durch einen rekursiven STARK ersetzen, der bestätigt, dass alle Prüfungen korrekt durchgeführt wurden.
Ein STARK ist ein kryptografischer Beweis, der es einer Partei ermöglicht zu demonstrieren, dass eine Berechnung korrekt durchgeführt wurde. Rekursive Beweise können andere Beweise verifizieren, wodurch es möglich wird, viele Prüfungen zu einer kleineren Verifizierungsaufgabe zu kombinieren.
Der vorgeschlagene Mempool könnte Transaktionssignaturen, Gültigkeitsbeweise und andere Abhängigkeiten vor der Blockausführung aggregieren. Validatoren würden dann den aggregierten Beweis verifizieren, anstatt jede ursprüngliche Berechnung unabhängig zu wiederholen.
Buterin schlug vor, dass dieser Ansatz auch die Menge der on-chain platzierten Verifizierungsdaten reduzieren könnte. Wenn der rekursive Beweis feststellt, dass alle Abhängigkeiten gültig waren, könnten einige der ursprünglichen Daten möglicherweise weggelassen werden.
Dieses Ergebnis ist nicht Teil der aktuellen EIP-8141-Spezifikation. Es würde zusätzliche Forschung erfordern, die Beweiserzeugung, Mempool-Koordination, Datenverfügbarkeit und Schutz vor ungültiger Aggregation abdeckt.
Das Design steht auch im Zusammenhang mit Ethereums Vorbereitung auf Post-Quanten-Kryptographie. Quantenresistente Signaturen sind im Allgemeinen größer und teurer zu verifizieren als die ECDSA-Signaturen, die von gewöhnlichen Ethereum-Konten verwendet werden.
EIP-8141 könnte es Konten ermöglichen, neue Autorisierungsschemata zu definieren, ohne darauf zu warten, dass Ethereum einen einzigen festen Signaturstandard ersetzt. Rekursive Beweisaggregation könnte dann die Kosten für die Verifizierung großer Post-Quanten-Signaturen senken.
EIP-8141 könnte Ethereum-Konten helfen, Post-Quanten-Autorisierung zu übernehmen, wenn praktische Signatursysteme verfügbar werden. Das bleibt ein langfristiger Sicherheitspfad und keine unmittelbare Reaktion auf eine aktive Quantenbedrohung.
Schlüsselgebundene Nonces könnten Transaktionsengpässe beseitigen
Ethereum-Konten verwenden sequenzielle Nonces, um Transaktionswiedergabe zu verhindern. Wenn ein Konto Transaktionen mit den Nummern 10, 11 und 12 einreicht, verarbeitet das Netzwerk sie normalerweise in dieser Reihenfolge.
Die Sequenz kann einen Engpass erzeugen. Wenn Transaktion 10 hängen bleibt oder ungültig wird, können spätere Transaktionen desselben Kontos ebenfalls warten, selbst wenn ihre Operationen nicht zusammenhängen.
Schlüsselgebundene Nonces würden einem Konto mehrere unabhängige Nonce-Sequenzen geben. Transaktionen, die verschiedenen Schlüsseln zugeordnet sind, könnten fortfahren, ohne auf das Fortschreiten einer anderen Sequenz zu warten.
Dies könnte Smart Accounts, Datenschutzsystemen und Anwendungen helfen, die mehrere unabhängige Operationen gleichzeitig einreichen. Jeder Workflow könnte seine eigene Nonce-Domäne erhalten, während der Schutz vor Wiedergabe erhalten bleibt.
Crypto.news berichtete zuvor, dass schlüsselgebundene Nonces verhindern könnten, dass unabhängige private Transaktionen sich gegenseitig blockieren. Die Funktion ist Teil einer breiteren Anstrengung zur Verbesserung von Datenschutztransaktionen, flexiblen Konten und Zensurresistenz.
Buterin verband die Transaktionsarbeit auch mit alternativen Zustandsmodellen, einschließlich nativer UTXO-Designs und beweisbasierter Zustandsstrukturen. Diese Projekte untersuchen, ob einige Vermögenswerte oder Operationen vorhersehbare Zustandsregeln verwenden können, während komplexe Verträge die bestehende Flexibilität von Ethereum behalten.
Der Ansatz könnte mehrere Verarbeitungsebenen schaffen. Einfache, deklarierte Operationen wären einfacher zu analysieren und könnten niedrigere Gebühren erhalten. Dynamische Vertragsaufrufe würden weiterhin funktionieren, aber mehr Ressourcen verbrauchen, da Clients ihre Ausführung nicht auf die gleiche Weise vorbereiten können.
Eine solche differenzierte Preisgestaltung würde versuchen, Gebühren an die tatsächlichen Skalierungsbeschränkungen anzupassen, die durch jede Transaktion entstehen. Sie würde nicht niedrigere Gebühren für jeden Benutzer oder jede Anwendung garantieren.
EIP-8141 erfordert weiterhin Entwicklerfreigabe und Tests
EIP-8141 muss mehrere Phasen durchlaufen, bevor es Ethereum-Benutzer beeinflussen kann. Kernentwickler müssen zunächst zustimmen, dass Frame-Transaktionen einen besseren Weg bieten als konkurrierende Kontenabstraktionsdesigns.
Der Vorschlag würde dann Client-Implementierungen, Entwicklungsnetzwerke, Interoperabilitätstests, Wallet-Unterstützung und Sicherheitsüberprüfung erfordern. Entwickler müssten auch testen, wie Frame-Transaktionen mit Blockbuildern, Mempools, Gebührenmärkten und bestehenden Smart Contracts interagieren.
Frühere Entwicklerdiskussionen erwogen EIP-8141 für Ethereums zukünftiges Hegotá-Upgrade. Crypto.news berichtete jedoch, dass Frame-Transaktionen weiterhin in Erwägung gezogen, aber nicht formell geplant wurden.
FOCIL, ein separater Vorschlag zur Verbesserung der Zensurresistenz durch Transaktionsinklusionslisten, wurde ebenfalls zusammen mit EIP-8141 diskutiert. Die beiden Vorschläge adressieren unterschiedliche Probleme. Frame-Transaktionen betreffen Autorisierungs- und Ausführungsstruktur, während FOCIL die Aufnahme berechtigter Transaktionen in Blöcke betrifft.
Entwickler haben argumentiert, dass ihre gemeinsame Verwendung native Kontenabstraktion mit stärkerer Zensurresistenz bieten könnte. Diese Kombination ist immer noch ein vorgeschlagenes Paket, keine genehmigte Ethereum-Roadmap-Verpflichtung.
Buterins Kommentare vom 6. September beschreiben daher eine mögliche Richtung für das Ethereum-Transaktionsdesign. Sie kündigen kein abgeschlossenes Upgrade, kein Aktivierungsdatum und keine bestätigte Änderung der Mainnet-Gasgebühren an.
Die nächsten überprüfbaren Meilensteine wären formelle Entwicklerunterstützung, Aufnahme in einen Upgrade-Umfang und funktionierende Implementierungen auf Entwicklungsnetzwerken. Bis dahin bleiben EIP-8141 und rekursive STARK-Mempools aktive Forschungs- und Engineering-Vorschläge.
FAQs
Was ist EIP-8141?
EIP-8141 schlägt Frame-Transaktionen vor, die Validierung, Gebührenfreigabe und Ausführung in separate Vertragsaufruf-Frames aufteilen.
Es ist derzeit ein Core-Vorschlag im Entwurfsstadium. Ethereum-Entwickler können seine Spezifikation noch ändern oder ablehnen.
Was ist der Unterschied zwischen einer Aktion und einer Abhängigkeit?
Eine Aktion ändert den Zustand von Ethereum, z. B. das Senden von ETH oder das Aufrufen eines Vertrags. Eine Abhängigkeit ist eine Bedingung, die gültig sein muss, z. B. eine Signatur oder ein Zustandsnachweis.
Die Trennung könnte es ermöglichen, unabhängige Abhängigkeiten gleichzeitig zu verarbeiten, bevor zustandsändernde Operationen ausgeführt werden.
Wird EIP-8141 die Transaktionsgebühren von Ethereum senken?
Es könnte vorhersehbare Transaktionen billiger machen, wenn Entwickler eine Gaspreisgestaltung übernehmen, die statisch analysierbare Operationen belohnt.
Es ist keine Gebührensenkung bestätigt. Die Kosten hängen von der endgültigen Spezifikation, der Client-Implementierung und zukünftigen Upgrade-Entscheidungen ab.






