Die Core-Developer-Agenda vom 6. August beschrieb das Datum als Stichtag für die Einreichung von Vorschlägen, nicht als Entscheidung über Hegotas endgültigen Funktionsumfang.

Frame Transactions gehört zu den Vorschlägen, die derzeit geprüft werden. Zwei abhängige Entwürfe, Keyed Nonces und Recent Roots, zeigen, wie dieses Transaktionsmodell Wallets und Privacy-Anwendungen unterstützen könnte, falls es angenommen wird.

Frame Transactions teilen eine Transaktion in programmierbare Stufen auf

EIP-8141, bekannt als Frame Transactions, schlägt einen neuen Ethereum-Transaktionstyp vor, der aus programmierbaren Frames besteht.

Unterschiedliche Frames könnten eine Aktion validieren, die Zahlung von Gas genehmigen oder den vom Nutzer beabsichtigten Aufruf ausführen. Ausgewählte Frames könnten außerdem zu einem atomaren Batch zusammengefasst werden: Wenn einer fehlschlägt, würden die von den anderen Frames in diesem Batch vorgenommenen Zustandsänderungen zurückgesetzt.

Die Struktur könnte Wallets mehr native Optionen für Batching, Schlüsselrotation und komplexe Transaktionsautorisierung bieten. Sie könnte außerdem ermöglichen, dass ein Konto oder Dienst das Gas bezahlt, während ein anderes Konto die Aktion autorisiert. Damit ist der Vorschlag nicht nur für Privacy-Tools relevant, da er berührt, wie Konten Aktionen on-chain delegieren und koordinieren.

Keyed Nonces schaffen getrennte Replay-Schutz-Domänen

Ethereum verwendet normalerweise für jedes Konto einen einzelnen sequenziellen Nonce. Diese Zahl bestimmt die Transaktionsreihenfolge und verhindert, dass dieselbe Transaktion zweimal ausgeführt wird.

EIP-8250 würde diesen einzelnen Nonce für Frame Transactions durch eine Menge von Nonce-Keys und eine Sequenznummer ersetzen. Transaktionen mit nicht überlappenden, nicht-Null Key-Sets wären voneinander unabhängig gegenüber Replay.

Das ist für Privacy-Protokolle wichtig, die einen gemeinsamen Absender verwenden, damit nicht jeder Nutzer eine eigene öffentliche Absenderadresse offenlegt. Mit einer einzelnen Nonce-Sequenz kann eine verzögerte Aktion andere, über denselben Absender eingereichte Aktionen beeinträchtigen.

Keyed Nonces adressieren diese Replay-Schutz-Beschränkung, bieten aber für sich genommen keine Privatsphäre. Die Nonce-Keys bleiben in den Transaktionsdaten sichtbar.

Der Vorschlag behält außerdem die Regel aus EIP-8141 bei, nach der im öffentlichen Mempool nur eine ausstehende Frame Transaction pro Absender erlaubt ist. Getrennte Nonce-Domänen würden daher allein nicht dazu führen, dass mehrere Frame Transactions desselben Absenders gleichzeitig öffentlich ausstehend bleiben können.

Recent Roots vermeiden das Lesen veränderlicher Speicherung während der Validierung

Privacy-Anwendungen verwenden oft einen Commitment-Baum, wobei ein aktueller Root die Commitments repräsentiert, gegen die ein Nutzer einen Spend nachweisen kann.

Die Validierung einer Frame Transaction kann nicht beliebigen externen Speicher lesen, der von einer anderen Anwendung kontrolliert wird. Dieser Speicher könnte sich ändern, während eine Transaktion aussteht.

EIP-8272, bekannt als Recent Roots, schlägt eine eingeschränkte Alternative vor. Eine Root-Quelle würde Roots in einen Systemvertrag schreiben, während eine Frame Transaction in ihren signierten Daten eine bestimmte Quelle, einen Slot und einen Root benennen könnte.

Ethereum-Clients würden diese Referenz vor der Frame-Ausführung prüfen. Die Anwendung könnte dann einen Beweis gegen einen aktuellen Commitment-Root validieren, ohne sich bei der Validierung auf sich ändernden externen Speicher zu stützen.

Der Vorschlag erlaubt bis zu 16 Root-Referenzen in einer Transaktion und begrenzt, wie lange jede gültig bleibt.

Er würde gewöhnliche ETH-Transfers nicht privat machen. Er würde eine Infrastruktur-Ebene bereitstellen, die Privacy-Anwendungen zusammen mit Frame Transactions nutzen könnten, was erklärt, warum das Design als Baustein und nicht als vollständiges Privacy-System beschrieben wird.

Die Frist hat Hegota nicht finalisiert

Alle drei EIPs sind weiterhin Entwürfe. EIP-8250 und EIP-8272 setzen außerdem EIP-8141 voraus, sodass keines von beiden unabhängig aktiviert werden könnte.

Die Frist vom 6. August schloss lediglich das Zeitfenster für neue nicht führende Vorschläge. Entwickler müssen weiterhin entscheiden, ob Frame Transactions zu Hegota gehören und, falls ja, ob die abhängigen Designs bereit sind, zu folgen. Praktisch bedeutet das, dass sich die Prüfung weiterhin um Eignung und Reife dreht, nicht nur darum, ob die Ideen technisch interessant sind.

Diese Kombination aus Kontoflexibilität, Privatsphäre und kryptografischer Widerstandsfähigkeit zeigt sich auch in Ethereums sich wandelnder Roadmap. Derzeit handelt es sich jedoch um Vorschläge in Prüfung, nicht um Funktionen, die Ethereum-Nutzern zur Verfügung stehen.

Hinweis: Der Artikel dient nur zu Informationszwecken. EIP-8141, EIP-8250 und EIP-8272 sind Entwürfe, die sich ändern, von Hegota ausgeschlossen werden oder nie aktiviert werden können.

Methode: Dieser Artikel basiert auf der offiziellen Hegota-Developer-Agenda und den Entwurfsspezifikationen für EIP-8141, EIP-8250 und EIP-8272.