3 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.

Auszahlungen, Gas-Anpassungen und was danach kam – ohne den Hype.

Die Kurzfassung​

Das Shapella Upgrade, ein Kofferwort aus Shanghai (für die Ausführungsschicht) und Capella (für die Konsensschicht), wurde am 12. April 2023 auf Ethereum aktiviert. Sein wegweisendes Merkmal war die erstmalige Ermöglichung von Staking-Auszahlungen seit dem Start der Beacon Chain.

Die wichtigste Änderung, EIP-4895, führte ein System ein, bei dem Validator-Auszahlungen automatisch von der Konsensschicht zur Ausführungsschicht "gepusht" werden, ohne dass eine Benutzer-Transaktion oder Gasgebühren erforderlich sind. Daneben wurden vier kleinere EIPs implementiert, um die EVM zu optimieren, darunter Gas-Kosten-Reduzierungen (Warm COINBASE), Bytecode-Optimierungen (PUSH0) und Beschränkungen für die Vertragserstellung (Initcode metering). Das Upgrade diente auch als letzte Warnung an Entwickler, dass der SELFDESTRUCT-Opcode abgeschafft werden würde.

Shapella schloss den Kreis der Merge effektiv ab, und das nächste große Upgrade, Dencun, folgte am 13. März 2024, wobei der Fokus des Netzwerks mit EIP-4844 "Blobs" auf Skalierbarkeit verlagert wurde.

Warum Shapella ein entscheidender Meilenstein war​

Von der Einführung der Beacon Chain bis April 2023 war das Staking von ETH eine Einbahnstraße. Man konnte 32 ETH einzahlen, um das Netzwerk zu sichern und Belohnungen zu verdienen, aber man konnte weder das Kapital noch die Belohnungen der Konsensschicht wieder abheben. Diese gebundene Liquidität war eine erhebliche Verpflichtung und ein Hindernis für viele potenzielle Staker.

Shapella änderte alles, indem es die Ausfahrt öffnete.

Der Kern des Upgrades war EIP-4895, das auf geniale Weise eine systemweite "Auszahlungsoperation" konzipierte. Anstatt von Stakern zu verlangen, eine Transaktion zu erstellen und Gas zu zahlen, um abzuheben, zieht das Protokoll selbst nun automatisch berechtigte Gelder von der Konsensschicht ab und pusht sie in die Ausführungsschicht. Dieses saubere, Push-basierte Design minimierte Komplexität und Risiko, wodurch die Änderung viel einfacher sicher zu testen und zu implementieren war.

Was sich tatsächlich geändert hat: Die EIPs einfach erklärt​

Shapella war ein Bündel von fünf wichtigen Ethereum Improvement Proposals (EIPs):

• EIP-4895 — Beacon Chain Auszahlungen (Push-basiert) Dies war das Hauptereignis. Es ermöglichte sowohl teilweise (Belohnungen) als auch vollständige (Kapital + Belohnungen) Auszahlungen, die von der Konsensschicht an die angegebene Auszahlungsadresse eines Stakers fließen. Die zentrale Neuerung ist, dass dies keine vom Benutzer initiierten Transaktionen sind; es sind automatische Operationen, die in vorgeschlagenen Blöcken eingebettet sind.

• EIP-3651 — „Warm COINBASE“ Dieses EIP führte eine kleine, aber wichtige Gas-Optimierung ein. In der EVM bezieht sich COINBASE auf die Adresse des Blockproduzenten (des Validators), nicht auf die Börse. Vor Shapella verursachte der erste Zugriff eines Smart Contracts auf diese Adresse innerhalb einer Transaktion höhere Gaskosten. EIP-3651 machte die COINBASE-Adresse standardmäßig "warm", wodurch die Gaskosten für Protokolle reduziert wurden, die häufig mit ihr interagieren, wie z. B. solche, die MEV-Trinkgelder direkt an den Block-Builder zahlen.

• EIP-3855 — PUSH0 Opcode Eine einfache, aber elegante Ergänzung zur EVM. Dieser neue Opcode, PUSH0, tut genau das, was er sagt: Er legt den Wert Null auf den Stack. Zuvor mussten Entwickler schwerere, teurere Opcodes verwenden, um dies zu erreichen. PUSH0 macht den Bytecode etwas kleiner und gas-effizienter, insbesondere für die zahlreichen Verträge, die Variablen auf Null initialisieren.

• EIP-3860 — initcode begrenzen & messen Diese Änderung führte zwei Regeln für den Code ein, der zur Erstellung eines Smart Contracts (initcode) verwendet wird. Erstens wurde die maximale Größe von initcode auf 49.152 Bytes begrenzt. Zweitens wurde eine kleine Gasgebühr für jeden 32-Byte-Block dieses Codes hinzugefügt. Dies verhindert Denial-of-Service-Angriffe mit übermäßig großen Verträgen und macht die Kosten für die Vertragserstellung vorhersehbarer.

• EIP-6049 — SELFDESTRUCT verwerfen (Warnung) Dies war keine Code-Änderung, sondern eine formelle Warnung an die Entwicklergemeinschaft. Sie signalisierte, dass die Funktionalität des SELFDESTRUCT-Opcodes, der es einem Vertrag erlaubt, sich selbst zu löschen und seine ETH an eine Zieladresse zu senden, in einem zukünftigen Upgrade drastisch geändert werden würde. Dies gab Entwicklern Zeit, ihre Abhängigkeit davon schrittweise zu reduzieren, bevor das Dencun-Upgrade später sein Verhalten mit EIP-6780 änderte.

Auszahlungen 101: Teilweise vs. Vollständig​

Shapella führte zwei Arten von automatischen Auszahlungen ein, jede mit ihren eigenen Regeln.

• Teilweise Auszahlungen Dies sind automatische Belohnungsabzüge. Wenn das Guthaben eines Validators durch Konsensschicht-Belohnungen über 32 ETH steigt, "schöpft" das Protokoll den überschüssigen Betrag automatisch ab und sendet ihn an die vorgesehene Auszahlungsadresse. Der Validator bleibt aktiv und setzt seine Aufgaben fort. Dies geschieht ohne erforderliche Aktion des Stakers.

• Vollständige Auszahlungen (Beenden) Dies ist für Staker, die die Validierung beenden und ihr gesamtes Guthaben abrufen möchten. Der Staker muss zuerst eine freiwillige Exit-Nachricht senden. Nach einer Wartezeit wird der Validator für eine vollständige Auszahlung berechtigt. Sobald diese im Abzugsprozess verarbeitet wurde, wird das gesamte Guthaben an die Auszahlungsadresse gesendet, und der Validator ist nicht mehr Teil des aktiven Sets.

Durchsatz und Kadenz​

Das Netzwerk ist so konzipiert, dass Auszahlungen reibungslos verarbeitet werden, ohne Instabilität zu verursachen.

• Bis zu 16 Auszahlungen können in jedem Block (alle 12 Sekunden) enthalten sein, was ein Maximum von ungefähr 115.200 Auszahlungen pro Tag ermöglicht.
• Der Block-Proposer scannt die Liste der aktiven Validatoren und nimmt die ersten 16 berechtigten Auszahlungen auf. Der nächste Block-Proposer macht dort weiter, wo der letzte aufgehört hat, um sicherzustellen, dass jeder Validator an die Reihe kommt.
• Um einen Massenexodus zu verhindern, der das Netzwerk destabilisieren könnte, ist die Anzahl der Validatoren, die pro Epoche (alle ~6,4 Minuten) austreten können, durch ein Churn-Limit begrenzt. Dieses Limit ist dynamisch und basiert auf der Gesamtzahl der aktiven Validatoren, wodurch Austrittswellen geglättet werden.

Es ist auch wichtig zu beachten, dass Konsensschicht-Belohnungen durch diesen EIP-4895-Auszahlungsmechanismus abgewickelt werden, während Ausführungsschicht-Belohnungen (Prioritätsgebühren und MEV) direkt an die konfigurierte Gebührenempfängeradresse eines Validators gesendet werden und sofort verfügbar sind.

Was danach kam: Dencun und der Weg zur Skalierbarkeit​

Shapella markierte den erfolgreichen Abschluss der "Merge-Ära". Da Staking nun ein vollständig liquider, zweiseitiger Prozess ist, wandten sich die Entwickler der nächsten großen Herausforderung von Ethereum zu: der Skalierbarkeit.

Das nächste große Upgrade, Dencun (Deneb + Cancun), wurde am 13. März 2024 aktiviert. Sein Kernstück war EIP-4844, das "Blobs" einführte – eine neue, günstigere Methode für Layer-2-Rollups, Transaktionsdaten im Ethereum-Mainnet zu veröffentlichen. Dies senkte die Transaktionsgebühren auf L2s drastisch und war ein großer Schritt auf dem Rollup-zentrierten Fahrplan. Dencun erfüllte auch das Versprechen von EIP-6049 durch die Implementierung von EIP-6780, das die Macht des SELFDESTRUCT-Opcodes erheblich einschränkte.

Das Gesamtbild​

Shapella war der entscheidende Vertrauens-Meilenstein für Ethereums Proof-of-Stake-Konsens. Durch die Ermöglichung von Auszahlungen wurde das Staking ent-riskiert, die Liquidität wiederhergestellt und die Fähigkeit des Netzwerks bestätigt, komplexe, koordinierte Upgrades durchzuführen. Es lieferte auch eine Reihe pragmatischer EVM-Verbesserungen, die technische Schulden bereinigten und den Weg für zukünftige Optimierungen ebneten.

Kurz gesagt, Shapella öffnete nicht nur die Ausfahrt für Staker – es festigte das Fundament der Post-Merge-Ära und ebnete den Weg für Ethereum, sich auf seine nächste Grenze zu konzentrieren: die Massenskalierbarkeit.