ERC-7779 Live

Die Entwicklung von Ethereum-Standards verlangsamt sich selten. Da ERC-7779 nun live ist, stellen sich Nutzer, Entwickler und Wallet-Anbieter die gleiche Frage: Was verändert ein weiteres live geschaltetes ERC tatsächlich für das alltägliche Krypto- und DeFi-Erlebnis? Dieser Beitrag erläutert, warum neue ERCs wichtig sind, wie sie in die Produktion gelangen, welche praktischen Auswirkungen sie auf Genehmigungen und die Transaktions-UX haben und was OneKey-Nutzer erwarten können, wenn Ökosysteme die neuesten Schnittstellen übernehmen.

Zuerst eine kurze Auffrischung: Was ist ein ERC?

Ein ERC (Ethereum Request for Comments) ist ein Community-gesteuerter Standard auf Anwendungsebene, der definiert, wie Verträge und Apps verhalten sollen, damit sie zuverlässig interoperabel sind (denken Sie an ERC-20 oder ERC-721). ERCs entstehen durch den EIP-Prozess, von der Entwurfsphase bis zum Finale, mit offener Diskussion und Peer-Review. Wenn Sie neu darin sind, wie Standards erstellt werden, ist der EIP-Prozess im offiziellen Spezifikationsdokument detailliert beschrieben. Sehen Sie sich den EIP-Lebenszyklus und die Begründung in den Ethereum-Standarddokumenten und den EIP-Meta-Prozess an:

• Erfahren Sie, wie Ethereum-Standards funktionieren, im offiziellen Entwicklerportal (siehe Ethereum-Standards).
• Tauchen Sie tief in den EIP-Lebenszyklus und die Statusdefinitionen ein (siehe EIP-1).

Um Wallets, dapps und Layer 2s aufeinander abzustimmen, bauen ERCs oft auf grundlegenden EIPs auf, wie zum Beispiel:

• EIP-712 für menschenlesbare, strukturierte Datenunterschriften (siehe EIP-712).
• EIP-165 für Schnittstellenerkennung und Kompatibilitätsprüfungen (siehe EIP-165).
• EIP-2771 für Meta-Transaktionen über vertrauenswürdige Forwarder (siehe EIP-2771).

Was ERC-7779 verbessern soll

Während jeder neue ERC einzigartig ist, zielen neuere Standards auf zwei Hauptziele ab:

• Sicherere, granularere Genehmigungen und Transaktionsberechtigungen. Nutzer möchten genau autorisieren, was eine dapp tun kann, wie lange und mit klaren Aufforderungen auf dem Gerät. Diese Richtung folgt den Lehren aus dem approve/transferFrom-Flow von ERC-20 und der Entwicklung hin zu Signaturen im Permit-Stil. Siehe Hintergrund zu den Tücken von approve und sichereren Mustern (siehe OpenZeppelin approve notes).
• Bessere Wallet-UX durch reichhaltigeren Kontext. Standards kodieren zunehmend Metadaten, damit Wallets verständliche Aufforderungen anstelle von undurchsichtigem Bytecode rendern können, im Einklang mit menschenlesbaren Signaturkonventionen. Lesen Sie über typisierte strukturierte Daten für sicherere Aufforderungen (siehe EIP-712).

In der Praxis bedeutet "Live-Schaltung" von ERC-7779, dass Early Adopters (dapps, SDKs und Wallets) mit der Integration einer Schnittstelle begonnen haben, die darauf ausgelegt ist, sicherere Genehmigungen, bessere Dekodierung und weniger verwirrende Signaturen zu liefern – ohne die Kompatibilität mit bestehenden Tokens und Protokollen zu beeinträchtigen.

Warum das jetzt wichtig ist

Der Zeitpunkt ist bedeutsam. Die jüngsten Upgrades von Ethereum haben die L2-Gebühren gesenkt und die On-Chain-Aktivität erweitert, während Account Abstraction und neue Wallet-Muster reifen:

• Dencun im Mainnet hat günstigere Datenverfügbarkeit für Rollups freigeschaltet und die L2-Adoption gefördert (siehe Dencun announcement).
• Account Abstraction bewegt sich von der Theorie zur Implementierung und ermöglicht programmierbare Wallets (siehe EIP-4337).
• Ein vorgeschlagenes Transaktionsmodell (EIP-7702) führt neue Wege zur Autorisierung von Aktionen mit verbesserten UX- und Sicherheitskompromissen ein (siehe EIP-7702).
• Die langfristige Roadmap von Ethereum priorisiert weiterhin Skalierbarkeit und Sicherheit, was sich auf die Entwicklung von Wallets und Standards auswirkt (siehe Ethereum roadmap).

Vor diesem Hintergrund kann jeder ERC, der die Sicherheit von Genehmigungen erhöht und die Klarheit von Aufforderungen verbessert, eine überproportionale Auswirkung auf die reale Welt haben.

Für alltägliche Nutzer: Was sich in Ihrem Wallet ändert

• Klarere Aufforderungen, weniger blinde Signaturen. Wallets, die ERC-7779-ähnliche Metadaten implementieren, können Ihnen anzeigen, was ein Vertrag verlangt – und warum – unter Verwendung strukturierter Daten, wo immer dies möglich ist (siehe EIP-712).
• Granularere Berechtigungen. Erwarten Sie, dass pro Funktion oder pro Betrag steuerbare Kontrollen häufiger werden, wenn sich Ökosysteme auf Permit-ähnliche Flows und Best Practices einigen (siehe ERC-20 Permit-Erweiterung EIP-2612 und Permit2-Muster).
• Einfachere Allowance-Hygiene. Verwenden Sie weiterhin einen Allowance-Scanner, um riskante Genehmigungen zu erkennen und zu widerrufen, insbesondere beim Umstieg auf neue Standards (siehe Etherscan Token Approval Checker).
• Geringere kognitive Belastung über L2s hinweg. Da Standards konsistente Schnittstellen übernehmen, wird Ihre Erfahrung über Netzwerke hinweg einheitlicher.

Hilfreiche Werkzeuge und Referenzen:

• Etherscan Token Approval Checker für Widerrufe und Überwachung.
• Permit-ähnliche Flows und Widerrufsmuster, die in modernen DEXs übernommen wurden (siehe Permit2 overview).
• Die Anleitung von OpenZeppelin zu ERC-20-Genehmigungen und Sicherheitsvorbehalten (siehe OpenZeppelin approve notes).

Für Entwickler: Integrations-Playbook

• Zuerst abwärtskompatibel. Behalten Sie die ERC-20-Kompatibilität bei, während Sie neue Schnittstellen hinter der EIP-165-Erkennung schichten, damit ältere Wallets nicht kaputtgehen (siehe EIP-165).
• Bevorzugen Sie typisierte Daten gegenüber rohen Bytes. Verlagern Sie benutzerorientierte Signaturen, wo immer dies möglich ist, auf EIP-712, um klares Signieren in Hardware-Wallets und bessere Risikohinweise zu ermöglichen (siehe EIP-712).
• Erwägen Sie Permit-Flows. Wenn Ihr Anwendungsfall Ausgabeberechtigungen gewährt, nutzen Sie Permit-ähnliche Muster (EIP-2612) oder kampferprobte Bibliotheken, die die Angriffsfläche für Genehmigungen reduzieren (siehe EIP-2612 und Permit2 overview).
• Unterstützen Sie Meta-Tx, wo dies angebracht ist. Mit EIP-2771 ermöglichen Sie gasgesponserte Flows und behalten dabei Replay-Schutz und Domain-Trennung bei (siehe EIP-2771).
• Verwenden Sie geprüfte Bibliotheken. Verlassen Sie sich auf gepflegte Primitive und Schnittstellen, anstatt Ihre eigenen zu entwickeln (siehe OpenZeppelin Contracts).
• Bedrohungsmodellierung neuer Code-Pfade. Jeder neue Hook oder jede neue Berechtigungsfläche birgt potenzielle Risiken für Reentrancy und Missbrauch von Genehmigungen – ordnen Sie sie bekannten SWC-Kategorien zu und testen Sie gründlich (siehe SWC Registry).

Entwicklerreferenzen:

• EIP-2612 (Permit für ERC-20)
• Permit2-Übersicht und Best Practices für Genehmigungen
• OpenZeppelin Contracts 5.x für standardkonforme Implementierungen
• SWC Registry für Schwachstellenklassen

Wallet-Integration und Hardware-Überlegungen

Wenn ein neuer ERC eingeführt wird, hängt die tatsächliche Sicherheit der Nutzer davon ab, wie Wallets ihn implementieren:

• Genaue Methodendekodierung: Wallets sollten Schnittstellen über EIP-165, wo anwendbar, dekodieren und menschenlesbare Absichten anstelle von Funktionsselektoren anzeigen.
• Klare Signatur auf dem Gerät: Wo strukturierte Daten verfügbar sind, sollten Hardware-Wallets menschenlesbare Felder anzeigen, damit Nutzer verifizieren können, was sie signieren (siehe EIP-712).
• Simulation und Risikohinweise: Vorab-Simulations-, Allowance-Differenz- und Contract-Provenance-Hinweise helfen, böswillige Genehmigungen zu erkennen, bevor sie On-Chain landen.

Was OneKey-Nutzer erwarten können:

• Standards-First-Signierung: OneKey unterstützt gängige Ethereum-Standards, einschließlich der Signierung strukturierter Daten, was Ihnen hilft, mehrdeutige Bytecode-Aufforderungen zu vermeiden (siehe EIP-712).
• Transparente Transaktionsprüfung: Die OneKey-App zeigt vor der Bestätigung auf dem Gerät Details zu Methode, Asset und Betrag an.
• Open-Source-Ethos: Mit einer offenen Codebasis können unabhängige Prüfer und die Community untersuchen, wie neue Standards integriert werden – unerlässlich, wenn ERCs neue Berechtigungspfade einführen.

Da die Akzeptanz von ERC-7779 zunimmt, wird OneKey weiterhin klare Signierung und Kompatibilität über L1- und L2-Netzwerke hinweg priorisieren und dabei strenge Sicherheitspraktiken beibehalten.

Sicherheits-Hygiene: Die Grundlagen ändern sich nicht

• Verwenden Sie, wo immer möglich, dapp-spezifische, minimale Allowances; vermeiden Sie unbegrenzte Genehmigungen, es sei denn, dies ist zwingend erforderlich.
• Widerrufen Sie regelmäßig veraltete Genehmigungen, insbesondere nach dem Ausprobieren neuer dapps oder dem Umstieg auf neue Standards (verwenden Sie Etherscan Token Approval Checker).
• Behandeln Sie neue Flows wie neue Angriffsflächen. Phishing-Kits entwickeln sich weiter, um frische Wallet-Aufforderungen zu imitieren – überprüfen Sie Domains, Contract-Adressen und Chain-IDs.
• Bevorzugen Sie geprüfte, gut gewartete Verträge und Bibliotheken (siehe OpenZeppelin Contracts) und verstehen Sie gängige Schwachstellenklassen für Smart Contracts (siehe SWC Registry).

Ausblick

ERC-7779 ist Teil eines breiteren Zyklus von Wallet- und UX-Upgrades, der Account Abstraction (siehe EIP-4337), vorgeschlagene Transaktionsautorisationsmodelle (siehe EIP-7702) und die stetige Kadenz von Netzwerkverbesserungen auf der Roadmap von Ethereum umfasst. Da sich Standards weiterentwickeln und konvergieren, sollten Nutzer weniger verwirrende Aufforderungen, standardmäßig sicherere Genehmigungen und ein konsistenteres Erlebnis über L2s hinweg sehen.

Wenn Sie signifikante On-Chain-Werte verwalten, sollten Sie Ihre bevorzugte Software-Wallet mit einer Hardware-Wallet kombinieren. OneKey legt Wert auf klare Signierung für Standards wie EIP-712, Open-Source-Transparenz und Multi-Chain-Kompatibilität – praktische Leitplanken, wenn neue ERCs eingeführt werden und sich die Transaktionsfläche weiterentwickelt.

Referenzen und weiterführende Lektüre:

• Übersicht über Ethereum-Standards auf ethereum.org (siehe Ethereum-Standards).
• Der EIP-Prozess (siehe EIP-1).
• Dencun Mainnet-Ankündigung und Auswirkungen auf L2s (siehe Dencun announcement).
• EIP-712 (strukturierte Daten).
• EIP-165 (Schnittstellenerkennung).
• EIP-2771 (Meta-Transaktionen).
• EIP-2612 (Permit).
• Permit2-Übersicht.
• EIP-4337 (Account Abstraction).
• EIP-7702 (vorgeschlagenes Autorisierungsmodell).
• Ethereum-Roadmap.
• OpenZeppelin Contracts.
• SWC Registry.
• Etherscan Token Approval Checker.

Alle oben genannten Links führen zu maßgeblichen Quellen für tiefere technische Hintergründe.