Der Ethereum-Entwickler Derek Chiang sagte am 7. September, dass die Autoren von EIP-8141 einen Weg gefunden hätten, mehrere Transaktionsfunktionen als programmierbare Vertragsaufrufe auszudrücken, anstatt sie separat zum Ethereum-Transaktionsenvelope hinzuzufügen.
Zusammenfassung
- Ethereum-Entwickler sagen, dass EIP-8141 Transaktionsfunktionen durch Vertragsaufrufe ausdrücken kann, die als programmierbare Frames bekannt sind.
- Frames könnten Ablauf, Signaturaggregation, Datenschutzbeweise und Post-Transaktions-Assertions unterstützen, ohne neue Envelope-Felder.
- EIP-8141 ist für Hegotá geplant, obwohl seine Spezifikation noch im Entwurfsstadium ist und Aktivierungstermine noch nicht festgelegt sind.
- Entwickler koordinieren EIP-8141 mit EIP-8130, um die Struktur zu erhalten und die Transaktionslesbarkeit für die Infrastruktur zu verbessern.
- Vitalik Buterin argumentiert, dass die Trennung von Transaktionsaktionen und -abhängigkeiten eine parallele Validierung und niedrigere Kosten ermöglichen könnte.
Chiang, ein Mitautor von EIP-8141 und Mitarbeiter von Ethlabs, beschrieb die Entwicklung als "Design-Durchbruch" in einem Beitrag, in dem er die jüngsten Arbeiten der Autoren des Vorschlags diskutierte. Der Ansatz behandelt Transaktionsablauf, aggregierte Signaturen, Merkle-Wurzeln von Datenschutz-Pools und Post-Transaktions-Assertions als Aufrufe, die "Frames" genannt werden.
Die offizielle Entwurfsspezifikation definiert eine Frame-Transaktion als eine Sequenz von Vertragsaufrufen. Verschiedene Frames können eine Transaktion validieren, ihre Gaszahlung genehmigen oder Benutzeroperationen ausführen. Der Vorschlag bietet derzeit drei Modi: DEFAULT, VERIFY und SENDER.
Ein VERIFY-Frame kann prüfen, ob eine erforderliche Bedingung erfüllt ist. Ein SENDER-Frame führt eine Operation von dem Konto aus, das als Transaktionssender identifiziert wird. Frames können auch in atomaren Batches gruppiert werden, was bedeutet, dass jede Operation in einem Batch gemeinsam erfolgreich ist oder die gesamte Gruppe zurückgesetzt wird.
Der Vorschlag definiert weiterhin einen Basis-Transaktionsenvelope, der Felder wie Kettenkennung, Nonce, Sender, Gebühren, Signaturen und Frameliste enthält. Chiangs Punkt ist enger gefasst: Entwickler könnten in der Lage sein, mehr Funktionalität durch neue Frame-Ziele und Aufrufmuster einzuführen, ohne für jede Funktion ein weiteres Envelope-Format zu erstellen.
Ein stabiler Envelope könnte Koordinationsarbeit reduzieren
Die Änderung eines Ethereum-Transaktionsenvelopes betrifft mehr als nur Ausführungsknoten. Wallets, Layer-2-Netzwerke, Block-Explorer, Signiergeräte, Softwarebibliotheken und Infrastrukturanbieter müssen alle das neue Format verstehen.
Chiang sagte, dass Ethereum-Upgrades ungefähr alle neun Monate stattfinden, was wiederholte Envelope-Änderungen langsam und koordinationsintensiv macht. Ein ausreichend allgemeines Frame-Format könnte als stabile Schnittstelle dienen, während Verträge oder designierte Protokollkomponenten neue Validierungsmethoden bereitstellen.
Das bedeutet nicht, dass zukünftige Funktionalität niemals ein Netzwerk-Upgrade erfordern würde. EIP-8141 selbst ändert Ethereums Konsensregeln und erfordert eine Client-Implementierung. Neue Opcodes, Precompiles oder Gasregeln könnten ebenfalls Hard Forks erfordern. Der vorgeschlagene Vorteil ist, dass Entwickler nicht unbedingt jedes Mal den Transaktionscontainer neu entwerfen müssten.
Die EIP-8141-Spezifikation listet native Kontenabstraktion unter ihren Hauptzielen auf. Sie könnte Schlüsselrotation, alternative Signatursysteme, gesponserte Gaszahlungen und Transaktionsbatching unterstützen. Sie zielt auch darauf ab, die Abhängigkeit von Ethereum-Konten vom secp256k1-Signatursystem zu verringern, das von herkömmlichen extern verwalteten Konten verwendet wird.
Wie crypto.news in seiner Berichterstattung über Vitalik Buterins vorgeschlagenes Ethereum-Transaktions-Redesign berichtete, könnte die programmierbare Validierung Ethereum letztendlich dabei helfen, neue Authentifizierungssysteme zu übernehmen, ohne ein festes Signaturschema durch ein anderes zu ersetzen.
EIP-8130 könnte Frames leichter überprüfbar machen
Chiang räumte auch einen Kompromiss ein. Hochabstrakte Transaktionen können für Wallets, Sequencer und andere Infrastruktur schwierig zu analysieren sein, bevor sie ausgeführt werden. Ein Layer-2-Sequencer könnte beispielsweise nur bestimmte Signaturmethoden akzeptieren wollen, weil deren Rechenkosten vorhersehbar sind.
Entwickler untersuchen daher, wie Frames mit EIP-8130, einem weiteren Entwurf für Kontenabstraktion, funktionieren könnten. EIP-8130 schafft einen Onchain-Keystore, in dem Konten Akteure und Authentifikator-Verträge registrieren. Transaktionen identifizieren explizit ihre Authentifizierungsmethode.
Diese Struktur ermöglicht es einem Knoten, zu bestimmen, welchen Validierungsprozess eine Transaktion erfordert, bevor beliebiger Wallet-Code ausgeführt wird. Unter dem vorgeschlagenen Layer-2-Profil von EIP-8130 könnte eine Kette ihren Transaktionspfad auf einen kanonischen Satz von Authentifikatoren mit festen Kosten beschränken, während andere Authentifizierungsmethoden über die normale EVM-Ausführung verfügbar bleiben.
Chiang sagte, EIP-8130 könnte definierte Strukturen über EIP-8141-Frames legen. Die Zusammenarbeit könnte die Flexibilität von Frames bewahren und gleichzeitig Wallets und Hochdurchsatz-Ketten ein besser lesbares Transaktionsformat bieten. Das kombinierte Design ist noch nicht finalisiert, und beide Spezifikationen bleiben für Überarbeitungen offen.
Frühere crypto.news-Berichterstattung untersuchte den Wettbewerb zwischen EIP-8141 und EIP-8130 während des anfänglichen Hegotá-Abgrenzungsprozesses. Die neuesten Kommentare deuten darauf hin, dass Entwickler nun nach kompatiblen Elementen suchen, anstatt die Vorschläge nur als sich gegenseitig ausschließende Alternativen zu behandeln.
Buterin verbindet Frames mit paralleler Validierung
Vitalik Buterin erweiterte die technische Richtung in einem separaten Beitrag, in dem er zwischen Transaktions-"Aktionen" und "Abhängigkeiten" unterschied. Eine Aktion ändert den Zustand von Ethereum, wie das Übertragen von ETH. Eine Abhängigkeit ist eine Bedingung, die erfüllt sein muss, wie eine Signatur, ein Merkle-Beweis oder ein Zero-Knowledge-Beweis.
Buterin argumentierte, dass unabhängige Abhängigkeiten parallel überprüft werden könnten. Bedingungen, die nicht auf den Ethereum-Zustand zugreifen, könnten möglicherweise einmal vom Mempool verarbeitet werden, anstatt während der Ausführung wiederholt zu werden. Mehrere Prüfungen könnten schließlich durch einen rekursiven STARK-Beweis dargestellt werden, obwohl dies eine Forschungsrichtung und kein genehmigtes Feature bleibt.
Die Unterscheidung könnte Clients auch dabei helfen, vorhersehbare Transaktionen von Operationen zu trennen, die die vollständige dynamische Ausführungsumgebung von Ethereum erfordern. Buterin sagte, dass statisch besser analysierbare Aktivitäten niedrigere Gaskosten erhalten und weiter skalieren könnten. Ein solcher Gebührenplan wurde nicht genehmigt.
Das Frame-Modell bietet eine potenzielle Schnittstelle für diesen Ansatz, da Validierung und Ausführung als identifizierbare Aufrufe erscheinen. Ethereum würde die flexible Vertragsausführung beibehalten, während einfachere Transaktionen mehr Informationen über ihre Anforderungen deklarieren könnten.
EIP-8141 ist geplant, aber Daten bleiben offen
Die offizielle Hegotá-Meta-EIP listet nun Frame-Transaktionen und FOCIL als für die Aufnahme in das Ethereum-Hegotá-Upgrade geplant. Das stellt einen stärkeren Status dar als die frühere Erwägung, friert jedoch das aktuelle technische Design von EIP-8141 nicht ein.
EIP-8141 bleibt als Core-Entwurf markiert. Seine Autoren können die Frame-Modi, die Signaturbehandlung, die Gas-Abrechnung und die Beziehung zu EIP-8130 überarbeiten, während die Implementierungsarbeit fortgesetzt wird. Das Hegotá-Dokument lässt auch die Aktivierungsfelder für Sepolia, Hoodi und Mainnet leer.
Die nächsten messbaren Schritte umfassen aktualisierte Spezifikationen, Implementierungen der Ausführungs-Clients, Entwicklungsnetzwerke und Interoperabilitätstests mit Wallets und Layer-2-Systemen. Entwickler müssen auch Denial-of-Service-Risiken im Mempool untersuchen, da programmierbare Validierung das Ablehnen ungültiger Transaktionen rechenintensiver machen kann.
Tests werden zeigen, ob die vorgeschlagene Kombination aus flexiblen Frames und strukturierten Authentifikatoren den Anforderungen der Basisschicht von Ethereum und schnelleren EVM-Ketten gerecht werden kann. Bis zur Veröffentlichung der Aktivierungsparameter bleibt EIP-8141 ein geplanter, aber noch nicht abgeschlossener Teil von Hegotá.
