2 Posts getaggt mit "EIP-7702"

Am 7. Mai 2025 wurde Ethereums Pectra-Upgrade (Prague + Electra) im Mainnet aktiviert. Zu den für Entwickler sichtbarsten Änderungen gehört EIP-7702, das einem extern besessenen Konto (EOA) ermöglicht, Smart-Contract-Logik zu „implementieren“ – ohne Gelder zu migrieren oder Adressen zu ändern. Wenn Sie Wallets, DApps oder Relayer entwickeln, eröffnet dies einen einfacheren Weg zur Smart-Account-UX.

Im Folgenden finden Sie einen prägnanten, implementierungszentrierten Leitfaden: Was tatsächlich ausgeliefert wurde, wie 7702 funktioniert, wann Sie es gegenüber reinem ERC-4337 wählen sollten und ein sofort anpassbares Code-Gerüst.

Was tatsächlich ausgeliefert wurde​

• EIP-7702 ist im finalen Umfang von Pectra enthalten. Das Meta-EIP für den Pectra-Hardfork listet 7702 offiziell unter den enthaltenen Änderungen auf.
• Aktivierungsdetails: Pectra wurde am 7. Mai 2025 im Mainnet bei Epoch 364032 aktiviert, nach erfolgreichen Aktivierungen auf allen wichtigen Testnets.
• Hinweis zur Toolchain: Solidity v0.8.30 hat sein Standard-EVM-Ziel für die Pectra-Kompatibilität auf prague aktualisiert. Sie müssen Ihre Compiler und CI-Pipelines aktualisieren, insbesondere wenn Sie bestimmte Versionen festlegen.

EIP-7702 – Funktionsweise (Grundlagen)​

EIP-7702 führt einen neuen Transaktionstyp und einen Mechanismus ein, mit dem ein EOA seine Ausführungslogik an einen Smart Contract delegieren kann.

• Neuer Transaktionstyp (0x04): Eine Typ-4-Transaktion enthält ein neues Feld namens authorization_list. Diese Liste enthält ein oder mehrere Autorisierungs-Tupel – (chain_id, address, nonce, y_parity, r, s) – jeweils signiert mit dem privaten Schlüssel des EOA. Wenn diese Transaktion verarbeitet wird, schreibt das Protokoll einen Delegationsindikator in das Code-Feld des EOA: 0xef0100 || address. Von diesem Zeitpunkt an werden alle Aufrufe an das EOA an die angegebene address (die Implementierung) weitergeleitet, aber sie werden im Speicher- und Kontostandkontext des EOA ausgeführt. Diese Delegation bleibt aktiv, bis sie explizit geändert wird.
• Kettenumfang: Eine Autorisierung kann kettenspezifisch sein, indem eine chain_id angegeben wird, oder sie kann für alle Ketten gelten, wenn chain_id auf 0 gesetzt ist. Dies ermöglicht es Ihnen, denselben Implementierungsvertrag über mehrere Netzwerke hinweg bereitzustellen, ohne dass Benutzer für jedes Netzwerk eine neue Autorisierung unterzeichnen müssen.
• Widerruf: Um ein EOA auf sein ursprüngliches, nicht-programmierbares Verhalten zurückzusetzen, senden Sie einfach eine weitere 7702-Transaktion, bei der die Implementierungs-address auf die Null-Adresse gesetzt ist. Dies löscht den Delegationsindikator.
• Selbstfinanziert vs. weitergeleitet: Ein EOA kann die Typ-4-Transaktion selbst senden, oder ein Drittanbieter-Relayer kann sie im Namen des EOA senden. Letzteres ist üblich, um eine gaslose Benutzererfahrung zu schaffen. Die Nonce-Handhabung unterscheidet sich geringfügig je nach Methode, daher ist es wichtig, Bibliotheken zu verwenden, die diese Unterscheidung korrekt verwalten.

Verschiebung des Sicherheitsmodells: Da der ursprüngliche private Schlüssel des EOA weiterhin existiert, kann er Smart-Contract-Regeln (wie Social Recovery oder Ausgabenlimits) jederzeit außer Kraft setzen, indem er eine neue 7702-Transaktion zur Änderung der Delegation übermittelt. Dies ist eine grundlegende Verschiebung. Verträge, die sich auf tx.origin verlassen, um zu überprüfen, ob ein Aufruf von einem EOA stammt, müssen neu geprüft werden, da 7702 diese Annahmen brechen kann. Überprüfen Sie Ihre Abläufe entsprechend.

7702 oder ERC-4337? (Und wann man sie kombiniert)​

Sowohl EIP-7702 als auch ERC-4337 ermöglichen Account Abstraction, dienen aber unterschiedlichen Zwecken.

• Wählen Sie EIP-7702, wenn…
  • Sie eine sofortige Smart-Account-UX für bestehende EOAs bereitstellen möchten, ohne Benutzer zum Migrieren von Geldern oder zum Ändern von Adressen zu zwingen.
  • Sie konsistente Adressen über Ketten hinweg benötigen, die schrittweise mit neuen Funktionen erweitert werden können.
  • Sie Ihren Übergang zur Account Abstraction schrittweise gestalten möchten, beginnend mit einfachen Funktionen und im Laufe der Zeit Komplexität hinzufügen.
• Wählen Sie reines ERC-4337, wenn…
  • Ihr Produkt von Anfang an volle Programmierbarkeit und komplexe Policy-Engines (z. B. Multi-Sig, erweiterte Wiederherstellung) erfordert.
  • Sie für neue Benutzer entwickeln, die keine bestehenden EOAs haben, wodurch neue Smart-Account-Adressen und die damit verbundene Einrichtung akzeptabel sind.
• Kombinieren Sie sie: Das leistungsstärkste Muster ist die Verwendung beider. Ein EOA kann eine 7702-Transaktion verwenden, um eine ERC-4337 Wallet-Implementierung als seine Logik zu bestimmen. Dies lässt das EOA wie ein 4337-Konto agieren, wodurch es gebündelt, von Paymastern gesponsert und von der bestehenden 4337-Infrastruktur verarbeitet werden kann – alles, ohne dass der Benutzer eine neue Adresse benötigt. Dies ist ein zukunftskompatibler Weg, der von den Autoren des EIP explizit gefördert wird.

Minimales 7702-Gerüst, das Sie anpassen können​

Hier ist ein praktisches Beispiel für einen Implementierungsvertrag und den clientseitigen Code zu dessen Aktivierung.

1. Ein kleiner, auditierbarer Implementierungsvertrag​

Dieser Vertragscode wird, sobald er bestimmt wurde, im Kontext des EOA ausgeführt. Halten Sie ihn klein, auditierbar und erwägen Sie, einen Upgrade-Mechanismus hinzuzufügen.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

/// @notice Executes calls from the EOA context when designated via EIP-7702.
contract DelegatedAccount {
    // Unique storage slot to avoid collisions with other contracts.
    bytes32 private constant INIT_SLOT =
        0x3fb93b3d3dcd1d1f4b4a1a8db6f4c5d55a1b7f9ac01dfe8e53b1b0f35f0c1a01;

    event Initialized(address indexed account);
    event Executed(address indexed to, uint256 value, bytes data, bytes result);

    modifier onlyEOA() {
        // Optional: add checks to restrict who can call certain functions.
        _;
    }

    function initialize() external payable onlyEOA {
        // Set a simple one-time init flag in the EOA's storage.
        bytes32 slot = INIT_SLOT;
        assembly {
            if iszero(iszero(sload(slot))) { revert(0, 0) } // Revert if already initialized
            sstore(slot, 1)
        }
        emit Initialized(address(this));
    }

    function execute(address to, uint256 value, bytes calldata data)
        external
        payable
        onlyEOA
        returns (bytes memory result)
    {
        (bool ok, bytes memory ret) = to.call{value: value}(data);
        require(ok, "CALL_FAILED");
        emit Executed(to, value, data, ret);
        return ret;
    }

    function executeBatch(address[] calldata to, uint256[] calldata value, bytes[] calldata data)
        external
        payable
        onlyEOA
    {
        uint256 n = to.length;
        require(n == value.length && n == data.length, "LENGTH_MISMATCH");
        for (uint256 i = 0; i < n; i++) {
            (bool ok, ) = to[i].call{value: value[i]}(data[i]);
            require(ok, "CALL_FAILED");
        }
    }
}

2. Den Vertrag auf einem EOA (Typ-4-Transaktion) mit viem bestimmen​

Moderne Clients wie viem verfügen über integrierte Hilfsfunktionen zum Signieren von Autorisierungen und Senden von Typ-4-Transaktionen. In diesem Beispiel zahlt ein Relayer-Konto das Gas, um ein eoa zu aktualisieren.

import { createWalletClient, http, encodeFunctionData } from "viem";
import { sepolia } from "viem/chains";
import { privateKeyToAccount } from "viem/accounts";
import { abi, implementationAddress } from "./DelegatedAccountABI";

// 1. Define the relayer (sponsors gas) and the EOA to be upgraded
const relayer = privateKeyToAccount(process.env.RELAYER_PK as `0x${string}`);
const eoa = privateKeyToAccount(process.env.EOA_PK as `0x${string}`);

const client = createWalletClient({
  account: relayer,
  chain: sepolia,
  transport: http(),
});

// 2. The EOA signs the authorization pointing to the implementation contract
const authorization = await client.signAuthorization({
  account: eoa,
  contractAddress: implementationAddress,
  // If the EOA itself were sending this, you would add: executor: 'self'
});

// 3. The relayer sends a Type-4 transaction to set the EOA's code and call initialize()
const hash = await client.sendTransaction({
  to: eoa.address, // The destination is the EOA itself
  authorizationList: [authorization], // The new EIP-7702 field
  data: encodeFunctionData({ abi, functionName: "initialize" }),
});

// 4. Now, the EOA can be controlled via its new logic without further authorizations
// For example, to execute a transaction:
// await client.sendTransaction({
//   to: eoa.address,
//   data: encodeFunctionData({ abi, functionName: 'execute', args: [...] })
// });

3. Delegation widerrufen (Zurück zum einfachen EOA)​

Um das Upgrade rückgängig zu machen, lassen Sie das EOA eine Autorisierung unterzeichnen, die die Null-Adresse als Implementierung bestimmt, und senden Sie eine weitere Typ-4-Transaktion. Danach sollte ein Aufruf von eth_getCode(eoa.address) leere Bytes zurückgeben.

Integrationsmuster, die in der Produktion funktionieren​

• Direktes Upgrade für bestehende Benutzer: Erkennen Sie in Ihrer DApp, ob der Benutzer sich in einem Pectra-kompatiblen Netzwerk befindet. Falls ja, zeigen Sie eine optionale Schaltfläche „Konto aktualisieren“ an, die die einmalige Autorisierungssignatur auslöst. Behalten Sie Fallback-Pfade (z. B. klassisches approve + swap) für Benutzer mit älteren Wallets bei.
• Gasloses Onboarding: Verwenden Sie einen Relayer (entweder Ihr Backend oder einen Dienst), um die anfängliche Typ-4-Transaktion zu sponsern. Für fortlaufende gaslose Transaktionen leiten Sie Benutzeroperationen über einen ERC-4337-Bundler, um bestehende Paymaster und öffentliche Mempools zu nutzen.
• Kettenübergreifende Rollouts: Verwenden Sie eine chain_id = 0-Autorisierung, um denselben Implementierungsvertrag über alle Ketten hinweg zu bestimmen. Sie können dann Funktionen auf einer Pro-Kette-Basis innerhalb Ihrer Anwendungslogik aktivieren oder deaktivieren.
• Beobachtbarkeit: Ihr Backend sollte Typ-4-Transaktionen indizieren und die authorization_list parsen, um zu verfolgen, welche EOAs aktualisiert wurden. Überprüfen Sie nach einer Transaktion die Änderung, indem Sie eth_getCode aufrufen und bestätigen, dass der Code des EOA nun dem Delegationsindikator (0xef0100 || implementationAddress) entspricht.

Bedrohungsmodell & Fallstricke (Nicht überspringen)​

• Delegation ist persistent: Behandeln Sie Änderungen am Implementierungsvertrag eines EOA mit der gleichen Ernsthaftigkeit wie ein Standard-Smart-Contract-Upgrade. Dies erfordert Audits, klare Benutzerkommunikation und idealerweise einen Opt-in-Flow. Pushen Sie niemals stillschweigend neue Logik an Benutzer.
• tx.origin-Fallstricke: Jede Logik, die msg.sender == tx.origin verwendete, um sicherzustellen, dass ein Aufruf direkt von einem EOA stammte, ist nun potenziell anfällig. Dieses Muster muss durch robustere Prüfungen ersetzt werden, wie EIP-712-Signaturen oder explizite Whitelists.
• Nonce-Berechnung: Wenn ein EOA seine eigene 7702-Transaktion (executor: 'self') sponsert, interagieren seine Autorisierungs-Nonce und Transaktions-Nonce auf eine spezifische Weise. Verwenden Sie immer eine Bibliothek, die dies korrekt handhabt, um Replay-Probleme zu vermeiden.
• Verantwortung der Wallet-UX: Die EIP-7702-Spezifikation warnt davor, dass DApps Benutzer nicht auffordern sollten, beliebige Bestimmungen zu unterzeichnen. Es liegt in der Verantwortung der Wallet, vorgeschlagene Implementierungen zu prüfen und deren Sicherheit zu gewährleisten. Gestalten Sie Ihre UX so, dass sie diesem Prinzip der Wallet-vermittelten Sicherheit entspricht.

Wann 7702 ein klarer Gewinn ist​

Diese Anwendungsfälle repräsentieren die gleichen Kernvorteile, die ERC-4337 verspricht, sind aber jetzt für jedes bestehende EOA mit nur einer einzigen Autorisierung verfügbar.

• DEX-Abläufe: Ein mehrstufiger approve- und swap-Vorgang kann mit der executeBatch-Funktion zu einem einzigen Klick zusammengefasst werden.
• Spiele & Sessions: Gewähren Sie Session-Key-ähnliche Berechtigungen für eine begrenzte Zeit oder einen begrenzten Umfang, ohne dass der Benutzer eine neue Wallet erstellen und finanzieren muss.
• Unternehmen & Fintech: Ermöglichen Sie gesponserte Transaktionen und wenden Sie benutzerdefinierte Ausgabenrichtlinien an, während Sie für Buchhaltung und Identität auf jeder Kette dieselbe Unternehmensadresse beibehalten.
• L2-Bridges & Intents: Erstellen Sie reibungslosere Meta-Transaktions-Abläufe mit einer konsistenten EOA-Identität über verschiedene Netzwerke hinweg.

Bereitstellungs-Checkliste​

Protokoll​

• Stellen Sie sicher, dass Nodes, SDKs und Infrastrukturanbieter Typ-4-Transaktionen und Pectras „prague“-EVM unterstützen.
• Aktualisieren Sie Indexer und Analysetools, um das Feld authorization_list in neuen Transaktionen zu parsen.

Verträge​

• Entwickeln Sie einen minimalen, geprüften Implementierungsvertrag mit wesentlichen Funktionen (z. B. Batching, Widerruf).
• Testen Sie die Abläufe zum Widerrufen und Neubestimmen gründlich auf Testnets, bevor Sie im Mainnet bereitstellen.

Clients​

• Aktualisieren Sie clientseitige Bibliotheken (viem, ethers usw.) und testen Sie die Funktionen signAuthorization und sendTransaction.
• Überprüfen Sie, dass sowohl selbstfinanzierte als auch weitergeleitete Transaktionspfade Nonces und Replays korrekt handhaben.

Sicherheit​

• Entfernen Sie alle Annahmen, die auf tx.origin basieren, aus Ihren Verträgen und ersetzen Sie diese durch sicherere Alternativen.
• Implementieren Sie eine Überwachung nach der Bereitstellung, um unerwartete Codeänderungen bei Benutzeradressen zu erkennen und bei verdächtigen Aktivitäten zu alarmieren.

Fazit: EIP-7702 bietet einen reibungslosen Einstieg in die Smart-Account-UX für die Millionen bereits genutzter EOAs. Beginnen Sie mit einer kleinen, geprüften Implementierung, nutzen Sie einen weitergeleiteten Pfad für die gaslose Einrichtung, gestalten Sie den Widerruf klar und einfach, und Sie können 90 % der Vorteile der vollständigen Account Abstraction liefern – ohne den Aufwand von Adresswechseln und Asset-Migrationen.

Seit Jahren wird die Krypto-Welt durch ein kritisches Usability-Problem behindert: die Wallet. Traditionelle Wallets, bekannt als Externally Owned Accounts (EOAs), sind unerbittlich. Eine einzige verlorene Seed-Phrase bedeutet, dass Ihre Gelder für immer verloren sind. Jede Aktion erfordert eine Signatur, und Gasgebühren müssen im nativen Token der Kette bezahlt werden. Dieses klobige, risikoreiche Erlebnis ist ein großes Hindernis für die Massenadoption.

Hier kommt die Account Abstraction (AA) ins Spiel, ein Paradigmenwechsel, der die Art und Weise, wie wir mit der Blockchain interagieren, neu definieren wird. Im Kern verwandelt AA das Konto eines Benutzers in einen programmierbaren Smart Contract, der Funktionen wie soziale Wiederherstellung, Ein-Klick-Transaktionen und flexible Gaszahlungen ermöglicht.

Der Weg in diese intelligentere Zukunft entfaltet sich entlang dreier unterschiedlicher Pfade: der kampferprobte ERC-4337, die effiziente Native AA und der mit Spannung erwartete EIP-7702. Lassen Sie uns aufschlüsseln, was jeder Ansatz für Entwickler und Benutzer bedeutet.

💡 Pfad 1: Der Pionier — ERC-4337​

ERC-4337 war der Durchbruch, der die Account Abstraction auf Ethereum und EVM-Ketten ohne das Kernprotokoll zu ändern, brachte. Stellen Sie es sich vor wie das Hinzufügen einer intelligenten Schicht über dem bestehenden System.

Es führt einen neuen Transaktionsfluss ein, der Folgendes umfasst:

• UserOperations: Ein neues Objekt, das die Absicht eines Benutzers darstellt (z. B. „100 USDC gegen ETH tauschen“).
• Bundlers: Off-Chain-Akteure, die UserOperations aufnehmen, bündeln und an das Netzwerk übermitteln.
• EntryPoint: Ein globaler Smart Contract, der die gebündelten Operationen validiert und ausführt.

Die Vorteile:

• Universelle Kompatibilität: Es kann auf jeder EVM-Kette eingesetzt werden.
• Flexibilität: Ermöglicht umfangreiche Funktionen wie Session Keys für Spiele, Multi-Signatur-Sicherheit und Gas-Sponsoring über Paymaster.

Der Kompromiss:

• Komplexität & Kosten: Es führt einen erheblichen Infrastruktur-Overhead ein (Betrieb von Bundlern) und hat die höchsten Gasgebühren der drei Ansätze, da jede Operation die zusätzliche EntryPoint-Logik durchläuft. Aus diesem Grund hat sich seine Akzeptanz hauptsächlich auf gasfreundlichen L2s wie Base und und Polygon entwickelt.

ERC-4337 ebnete den Weg, damit andere AA-Lösungen folgen konnten. Es bewies die Nachfrage und legte den Grundstein für ein intuitiveres Web3-Erlebnis.

🚀 Pfad 2: Das integrierte Ideal — Native Account Abstraction​

Wenn ERC-4337 ein Add-on ist, baut Native AA intelligente Funktionen direkt in das Fundament der Blockchain ein. Ketten wie zkSync Era und Starknet wurden von Grund auf mit AA als Kernprinzip konzipiert. In diesen Netzwerken ist jedes Konto ein Smart Contract.

Die Vorteile:

• Effizienz: Durch die Integration der AA-Logik in das Protokoll werden zusätzliche Schichten entfernt, was zu deutlich niedrigeren Gasgebühren im Vergleich zu ERC-4337 führt.
• Einfachheit für Entwickler: Entwickler müssen keine Bundler oder einen separaten Mempool verwalten. Der Transaktionsfluss fühlt sich viel mehr wie ein Standardfluss an.

Der Kompromiss:

• Ökosystem-Fragmentierung: Native AA ist ketten-spezifisch. Ein Konto auf zkSync unterscheidet sich von einem Konto auf Starknet, und keines von beiden ist nativ zum Ethereum-Mainnet. Dies schafft eine fragmentierte Erfahrung für Benutzer und Entwickler, die über mehrere Ketten hinweg arbeiten.

Native AA zeigt uns das „Endspiel“ für Effizienz, aber seine Akzeptanz ist an das Wachstum seiner Host-Ökosysteme gebunden.

🌉 Pfad 3: Die pragmatische Brücke — EIP-7702​

EIP-7702, das in das Ethereum-Upgrade „Pectra“ von 2025 aufgenommen werden soll, ist ein Game-Changer, der darauf abzielt, AA-Funktionen den Massen bestehender EOA-Benutzer zugänglich zu machen. Es verfolgt einen hybriden Ansatz: Es ermöglicht einem EOA, seine Autorität vorübergehend an einen Smart Contract zu delegieren für eine einzelne Transaktion.

Stellen Sie es sich so vor, als würden Sie Ihrem EOA vorübergehend Superkräfte verleihen. Sie müssen Ihre Gelder nicht migrieren oder Ihre Adresse ändern. Ihre Wallet kann einfach eine Autorisierung zu einer Transaktion hinzufügen, wodurch sie gebündelte Operationen durchführen kann (z. B. Genehmigen + Tauschen mit einem Klick) oder ihre Gasgebühren gesponsert werden.

Die Vorteile:

• Abwärtskompatibilität: Es funktioniert mit den Milliarden von Dollar, die durch bestehende EOAs gesichert sind. Keine Migration erforderlich.
• Geringe Komplexität: Es verwendet den Standard-Transaktionspool, wodurch die Notwendigkeit von Bundlern entfällt und die Infrastruktur drastisch vereinfacht wird.
• Katalysator für die Massenadoption: Indem intelligente Funktionen jedem Ethereum-Benutzer über Nacht zugänglich gemacht werden, könnte die Einführung besserer UX-Muster schnell beschleunigt werden.

Der Kompromiss:

• Keine „volle“ AA: EIP-7702 löst das Schlüsselmanagement für das EOA selbst nicht. Wenn Sie Ihren privaten Schlüssel verlieren, haben Sie immer noch Pech. Es geht mehr darum, die Transaktionsfähigkeiten zu verbessern, als die Kontosicherheit grundlegend zu überarbeiten.

Kopf-an-Kopf: Ein klarer Vergleich​

Die Zukunft ist konvergent und benutzerzentriert​

Diese drei Pfade schließen sich nicht gegenseitig aus; sie konvergieren zu einer Zukunft, in der die Wallet kein Reibungspunkt mehr ist.

1. Soziale Wiederherstellung wird Standard 🛡️: Die Ära der „verlorenen Schlüssel, verlorenen Gelder“ geht zu Ende. AA ermöglicht eine wächterbasierte Wiederherstellung, wodurch die Selbstverwahrung so sicher und nachsichtig wird wie ein traditionelles Bankkonto.
2. Gaming UX neu gedacht 🎮: Session Keys ermöglichen nahtloses Gameplay ohne ständige „Transaktion genehmigen“-Pop-ups, wodurch sich Web3-Gaming endlich wie Web2-Gaming anfühlt.
3. Wallets als programmierbare Plattformen: Wallets werden modular. Benutzer könnten ein „DeFi-Modul“ für automatisiertes Yield Farming oder ein „Sicherheitsmodul“ hinzufügen, das eine 2FA für große Überweisungen erfordert.

Für Entwickler und Infrastrukturanbieter wie Blockeden.xyz ist diese Entwicklung unglaublich spannend. Die Komplexität von Bundlern, Paymastern und verschiedenen AA-Standards schafft eine enorme Chance, robuste, zuverlässige und abstrahierte Infrastruktur bereitzustellen. Ziel ist ein einheitliches Erlebnis, bei dem ein Entwickler AA-Funktionen einfach integrieren kann und die Wallet intelligent ERC-4337, Native AA oder EIP-7702 im Hintergrund verwendet, je nachdem, was die Kette unterstützt.

Die Wallet erhält endlich das Upgrade, das sie verdient. Der Übergang von statischen EOAs zu dynamischen, programmierbaren Smart Accounts ist nicht nur eine Verbesserung – es ist die Revolution, die Web3 für die nächsten Milliarden Benutzer zugänglich und sicher machen wird.