Was ist das Delegation Toolkit und was lässt sich damit entwickeln?

Die Kontrolle über Ethereum-Konten war traditionell starr. Externally Owned Accounts (EOAs) sind einfach und weit verbreitet, aber in ihren Möglichkeiten begrenzt. Smart Contract Accounts (SCAs) bieten deutlich mehr Flexibilität, konnten bis vor Kurzem jedoch nicht eigenständig agieren. Man benötigte nach wie vor ein EOA, um jede Transaktion zu initiieren und zu bezahlen.

Das änderte sich mit ERC-4337: SCAs können nun nativ Funktionen wie Gas Sponsorship, Transaction Batching (das Zusammenfassen mehrerer Transaktionen zu einer), Session Keys und Chain Abstraction unterstützen – was zu mehr Sicherheit, Flexibilität und Kontrolle für Nutzer führt.

EOAs sind dennoch nicht verschwunden – und das aus gutem Grund: Nicht jeder Nutzer braucht ein Konto, das beliebige Verifikationslogik unterstützt. Warum also schon jetzt zu einem SCA wechseln?

Doch wie stellen wir dann sicher, dass Nutzer, wenn sie bereit sind zu wechseln – oder vorübergehend eine oder mehrere ERC-4337-Kontofunktionen nutzen möchten –, nicht gezwungen sind, von Grund auf ein neues Konto zu erstellen? Wie ermöglichen wir EOAs, die Funktionen eines SCA für bestimmte Transaktionen zu nutzen, ohne ihre vertraute Umgebung aufzugeben?

Genau hier kommt EIP-7702 (Set-EOA-account-code) ins Spiel.

Als Teil des bevorstehenden Pectra-Upgrades ermöglicht EIP-7702 EOAs, sich vorübergehend wie SCAs zu verhalten, indem sie die Kontrolle an Smart-Contract-Code delegieren, der direkt von ihren Adressen ausgeführt wird. Das bedeutet, dass Nutzer nicht zu neuen Konten migrieren müssen, um diese erweiterten Funktionen zu nutzen. Es gewährleistet Abwärtskompatibilität und treibt Ethereum gleichzeitig voran.

Trotz dieser Verbesserungen gibt es noch einen wesentlichen UX-Aspekt, der erschlossen werden muss, um ein web2-ähnliches Erlebnis vollständig zu erreichen: feingranulare und flexible Berechtigungen, bei denen Nutzer die Befugnis, eine bestimmte Aktion in ihrem Namen durchzuführen, einfach mit anderen Nutzern teilen können. Dies geschieht auf kontrollierte Weise, mit klaren Leitplanken und der Möglichkeit, Berechtigungen bei Bedarf zu widerrufen.

Das ist die Herausforderung, für die das Delegation Toolkit entwickelt wurde. Bevor wir jedoch darauf eingehen, was es ist und wie es funktioniert, werfen wir einen genaueren Blick auf die beiden ERCs, die diese nächste Phase der Ethereum-Konto-UX vorantreiben.

ERC 7710: Smart Contract Delegation

ERC-7710 ist ein Vorschlag zur Standardisierung, wie Smart Contract Accounts bestimmte Berechtigungen an andere Ethereum-Konten delegieren. Es führt eine gemeinsame Schnittstelle ein, über die Delegatoren Delegierten Befugnisse mit klaren, durchsetzbaren Regeln erteilen können.

Mit ERC-7710 können Entwickler Systeme aufbauen, in denen ein Konto einem anderen sicher erlaubt, unter bestimmten Bedingungen in seinem Namen zu handeln – etwa mit Ausgabenlimits, zeitlichen Einschränkungen oder aufgabenspezifischen Berechtigungen. All dies wird über einen sicheren und vorhersehbaren Delegationsablauf abgewickelt.

Was bedeutet „Delegation" in diesem Zusammenhang?

Vereinfacht gesagt geht es darum, Kontoeigentümerschaft von der Kontoausführung zu trennen. Ein Delegator besitzt weiterhin die Assets oder die Logik, kann aber bestimmte Befugnisse vorübergehend oder dauerhaft an jemand anderen abgeben, ohne die vollständige Kontrolle aufzugeben.

Aus Netzwerkperspektive bringt ERC-7710 Klarheit und Composability in die Art und Weise, wie Berechtigungen zwischen Konten weitergegeben werden. Anstatt dass jede App ihre eigene Delegationslogik entwickelt, gibt es nun eine gemeinsame Grundlage, auf der Contracts und Tools aufbauen können.

ERC 7715: Berechtigungen von Wallets erteilen

ERC-7715 ist ein Vorschlag zur Vereinfachung der Art und Weise, wie Dapps Berechtigungen von Nutzer-Wallets anfordern. Es führt ein Berechtigungsmodell ein, das es Dapps ermöglicht, klar abgegrenzte, vorab genehmigte Zugriffsrechte auf das Konto eines Nutzers anzufordern – ohne bei jeder Interaktion erneute Bestätigungen zu benötigen.

Heute ist der typische Interaktionsablauf umständlich: Eine Dapp fordert auf, eine Transaktion zu senden oder mit einem Contract zu interagieren, und die Wallet fordert den Nutzer jedes Mal zur Genehmigung auf. Es gibt keine Möglichkeit, Limits, Zeiträume oder den Umfang der Aktionen einer Dapp festzulegen, und keine standardisierte Möglichkeit für Nutzer, diese Genehmigungen später einzusehen oder zu widerrufen.

ERC-7715 ändert das. Es führt eine neue Methode ein, wallet_grantPermissions, mit der eine Dapp im Voraus bestimmte Funktionen anfordern kann. Zum Beispiel könnte sie die Erlaubnis anfordern, in der nächsten Stunde bis zu 10 USDC auszugeben oder für die nächsten paar Sitzungen mit einem einzigen Smart Contract zu interagieren. Der Nutzer prüft dies im Voraus und genehmigt oder lehnt es mit vollständiger Transparenz ab.

Aus Sicht einer Dapp macht dies das Onboarding reibungsloser und ermöglicht sitzungsbasierte oder automatisierte Erlebnisse, die den Nutzer nicht ständig unterbrechen. Für Wallets führt es eine klare, nachvollziehbare Struktur für die Verwaltung von Berechtigungen ein. Für Nutzer bietet es bessere Übersicht, mehr Kontrolle und weniger lästige Pop-ups – ohne Abstriche bei der Sicherheit.

Was können Entwickler mit diesen Standards bauen?

Hier sind einige Funktionen, die durch die Kombination von ERC-7710 und ERC-7715 ermöglicht werden:

• Tägliche Ausgabenlimits aus einer sicheren Wallet festlegen, indem ERC-7710 genutzt wird, um ein festes Guthaben an eine häufiger verwendete Wallet zu delegieren und den Großteil der Mittel sicher offline zu halten.

• Onboarding vereinfachen, indem Nutzer Aktionen wie das Minten oder Einfordern von Rewards ohne vorherige Wallet-Einrichtung oder Transaktionsgenehmigungen durchführen können – mithilfe vorab definierter Delegationen, die automatisch begrenzte Berechtigungen erteilen.

• KI-Agenten in Ihrem Namen handeln lassen, indem begrenzte Ausführungsberechtigungen über ERC-7710 zugewiesen werden, wobei ERC-7715 die Genehmigung dieser Berechtigungen über Ihre Wallet erleichtert.

• Eine Dapp die Gas-Gebühren der Nutzer übernehmen lassen, indem Sponsorship-Rechte an ein SCA delegiert werden, das ERC-7710-Delegation nutzt, sodass bestimmte Transaktionen ohne ETH-Guthaben des Nutzers durchgeführt werden können.

• Token-Genehmigungen sicher widerrufen, indem die Berechtigung an einen Hilfs-Contract delegiert wird, der approve(0) in Ihrem Namen aufruft – mit ERC-7710, um den Umfang der Aktionen genau einzugrenzen und die Kompatibilität mit jedem Standard-ERC-20-Token sicherzustellen.

Und vieles mehr.

Das Delegation Toolkit definiert

Am einfachsten lässt sich das Delegation Toolkit als eine Suite von Tools beschreiben, die zwei Hauptpakete umfasst:

1. Das Delegation Core SDK – Ein Paket, das Entwicklern ermöglicht, ERC-4337-konforme Smart Contract Accounts (Delegator-Konten) zu erstellen, die von allen durch ERC-4337 Account Abstraction eingeführten Funktionen profitieren.

2. Das Delegation Framework – Ein System, das Smart Contract Accounts ermöglicht, Berechtigungen über den ERC-7710-Standard an andere Ethereum-Konten zu delegieren, und das Websites, Dapps oder letztendlich allem ermöglicht, Berechtigungen von Ihrem Konto über ERC-7715 anzufordern (demnächst verfügbar).

Einfach ausgedrückt ermöglicht das Delegation Toolkit den Aufbau von Dapps, die ERC-4337 Smart Contract Accounts (SCAs) unterstützen, Berechtigungen an andere SCAs oder EOAs delegieren und Dapps in die Lage versetzen, diese Berechtigungen anzufordern – ob von Smart Accounts oder, nach dem Pectra-Upgrade, sogar von EOAs.

Wenn Sie mit der Funktionsweise von Smart Contract Accounts vertraut sind, wissen Sie bereits, was Sie vom Delegation Core VIEM-Paket erwarten können. Falls nicht, schauen Sie gerne in die offizielle Dokumentation für einen tieferen Einblick. Im weiteren Verlauf dieses Artikels konzentrieren wir uns auf das Delegation Framework selbst und beleuchten einige der wichtigsten Prinzipien, die es so leistungsfähig machen.

Off-Chain-Delegation

Delegationen müssen nicht On-Chain gespeichert sein, um gültig zu sein. Sobald Konto A eine Delegation für Konto B signiert hat, kann sie überall gespeichert werden – IPFS, Browser-Cache, Cloud-Speicher oder sogar lokal heruntergeladen –, da sie kryptografisch gesichert und nur vom vorgesehenen Delegierten verwendbar ist. Das macht das gesamte System skalierbarer und flexibler.

Zum Beispiel kann B die signierte Delegation bei Bedarf abrufen und in einer Transaktion verwenden, ohne On-Chain-Speicherung oder vorab anfallende Gas-Kosten zu benötigen.

Widerrufbare Berechtigungen

Delegationen sind nicht dauerhaft. Der ursprüngliche Delegator, etwa Konto A, kann jede aktive Delegation, die er ausgestellt hat, widerrufen – selbst wenn diese Delegation bereits durch transitive Delegation weitergegeben wurde (siehe Abschnitt zur transitiven oder verketteten Delegation weiter unten). Nach dem Widerruf lehnt der Delegation Manager jeden Versuch ab, sie einzulösen, einschließlich aller Sub-Delegationen, die davon abhängen. Dies ist entscheidend für die Sicherheit.

Wenn Konto A eine Kompromittierung vermutet oder Berechtigungen aktualisieren möchte, kann es den Zugriff sofort unterbrechen und damit die gesamte Vertrauenskette ungültig machen. Es ist, als könnte man jederzeit den Stecker ziehen, ohne alle Beteiligten ausfindig machen zu müssen.

Abgegrenzte Delegationen

Mit dem Delegation Toolkit sind Delegationen in der Regel auf einen bestimmten Delegierten beschränkt. Das bedeutet: Wenn Konto A eine Delegation an Konto B signiert, kann nur B sie einlösen. Selbst wenn jemand anderes in den Besitz der signierten Delegation gelangt, ist sie für ihn nutzlos, da sie kryptografisch an B gebunden ist.

Es gibt jedoch auch Unterstützung für offene Delegationen. Das sind Delegationen, die im Voraus keinen Delegierten festlegen und von jedem Konto eingelöst werden können. Offene Delegationen sind nützlich, wenn der Delegierte noch nicht bekannt ist, sollten aber mit Vorsicht verwendet werden, um Missbrauch zu vermeiden. Sie können eine erstellen, indem Sie das Delegate-Feld auf die spezielle Konstante ANY_BENEFICIARY (0x0000000000000000000000000000000000000a11) setzen.

Wenn Konto B später eine abgegrenzte Berechtigung an Konto C weitergeben möchte, muss es explizit eine neue Delegation von B an C erstellen. Dadurch bleiben Berechtigungsgrenzen klar und intentional – auch bei der Verwendung offener oder transitiver Abläufe.

Caveats

Caveats sind die Regeln, die definieren, wie eine Delegation verwendet werden kann. Stellen Sie sie sich als benutzerdefinierte Bedingungen vor, die der Delegator einer Delegation anhängen kann. Wenn Konto A beispielsweise an Konto B delegiert, könnte es einen Caveat einschließen, der besagt, dass B nur bis zu 1 ETH transferieren oder nur innerhalb der nächsten 24 Stunden mit einem bestimmten Contract interagieren darf.

Caveats werden zur Laufzeit mithilfe spezieller Caveat-Enforcer-Contracts durchgesetzt, die sicherstellen, dass die Regeln eingehalten werden, bevor eine Aktion ausgeführt wird. Selbst wenn B das Recht hat zu handeln, agiert er noch immer innerhalb eines klar definierten Rahmens, der von A festgelegt wurde. Die vollständige Liste der unterstützten Caveats finden Sie hier, oder erfahren Sie, wie Sie Ihren eigenen Custom Caveat erstellen.

Transitive oder verkettete Delegation

Eine der leistungsfähigsten Funktionen des Delegation Frameworks ist, dass Delegation nicht bei einer einzigen Übergabe enden muss. Bei transitiver Delegation kann ein Konto, das eine Berechtigung erhält – etwa Konto B –, diese Befugnis ganz oder teilweise an ein anderes Konto weiterdelegieren und so eine Delegationskette bilden, die von einem Konto ausgeht.

Jedes Glied in der Kette ist kryptografisch signiert und mit eigenen Caveats abgegrenzt, was bedeutet, dass Berechtigungen auf jeder Ebene eingeschränkt oder neu definiert werden können. Mit anderen Worten: Diese Sub-Delegationen können eine Teilmenge des Originals sein, mit strengeren Einschränkungen oder begrenzten Fähigkeiten.

Wichtig ist, dass der ursprüngliche Delegator die volle Kontrolle behält und die anfängliche Delegation jederzeit widerrufen kann, was automatisch alle nachgelagerten Delegationen in der Kette ungültig macht – und so eine flexible, aber sichere Vertrauenskette schafft, ideal für komplexe Berechtigungsstrukturen wie DAOs und gemeinsam genutzte Wallets.

Was kommt als Nächstes?

Das Delegation Toolkit gibt Ihnen die Werkzeuge an die Hand, um sicherere, intelligentere und flexiblere Berechtigungssysteme in Ihre Dapps zu integrieren. Ob Sie delegiertes Spending, Gas Sponsorships, automatisierte Workflows oder nahtloses Onboarding ermöglichen möchten – all das ist jetzt möglich, ohne das Rad neu erfinden zu müssen.

In den nächsten Beiträgen werden wir praktisch, beginnend mit einem Tutorial zum Aufbau einer „Freund einladen"-Funktion – ein praktisches Beispiel für Delegation in Aktion. Bleiben Sie dran für den Rest der Serie, in der wir weitere Funktionen vorstellen, die Sie heute bereits implementieren können.

Wenn Sie diese Ideen weiter erkunden möchten, halten Sie Ausschau nach dem bevorstehenden April Gator Hackathon, bei dem Sie die Möglichkeit haben, gemeinsam mit anderen Entwicklern mit dem Delegation Toolkit zu bauen.