Im Web3-Umfeld führen verwaiste Administratorrechte, veraltete Signer-Schlüssel und nicht ausreichend auditierte Module regelmäßig zu gravierenden Sicherheitsvorfällen. Statische Rechtevergaben, die nicht kontinuierlich überprüft oder sicher widerrufen werden, ermöglichen Authority Drift – das schleichende Wachstum von überdimensionierten oder ungenutzten Zugriffsrechten. Ein formaler, ganzheitlicher Account-Authority-Lifecycle (Account Authority Lifecycle) soll diese Schwachstellen schließen, indem er jede Phase von der Ausgabe über die Aktivierung bis hin zur Wiederherstellung definiert und verbindlich prüft.

Warum ein standardisiertes Lebenszyklusmodell unverzichtbar ist

Authority Drift als Hauptursache für Sicherheitsvorfälle

Ein Großteil der bekannten Verluste entsteht durch verbleibende oder zu breit eingerichtete Berechtigungen, die nach ihrem ursprünglichen Einsatzzweck nicht mehr bereinigt wurden. Hochprivilegierte Statuswechsel müssen an verifizierbare Transaktionssimulationen und an Scoped Capability Tokens gebunden werden, um Missbrauch zu verhindern.

Limitierungen bestehender Frameworks

Aktuelle Lösungen wie Safe und die modulare Standardisierung nach ERC-7579 decken den kompletten Berechtigungslebenszyklus – Review, temporäre Attenuierung, Zwangs-Revokation – bislang nicht formal ab. ERC-7579 definiert zwar vier Kernmodultypen (Validator, Executor, Fallback, Hook), jedoch fehlen globale Zustände wie Attenuated oder Suspended, die eine systemische Überwachung ermöglichen.

Integration in modulare Standards: ERC-7579 & Safe

Der vorliegende Entwurf schließt die Sicherheitslücke, indem er Hook- und Validator-Aufrufe an standardisierte Lifecycle-Zustände koppelt. Damit wird die bestehende Modul-Schnittstelle erweitert, ohne ERC-7579 neu schreiben zu müssen.

• Vier standardisierte Modultypen (Validator, Executor, Fallback, Hook) – Quelle: ERC-7579 (2024)
• Keine globalen Zustände in ERC-7579, jedoch durch den Entwurf eingeführt: Attenuated, Suspended, Revoked

Formalität des EIP-7702-Widerrufsmechanismus

EIP-7702 ermöglicht es Externally Owned Accounts (EOAs), ihre Ausführungslogik an Smart Contracts zu delegieren. Zur sicheren Bereinigung muss diese Delegation mit der Nulladresse (0x0) überschrieben werden. Der Entwurf operationalisiert die atomare Revokation durch einen definierten Endzustand Revoked.

• Länge des Delegations-Designators: 23 Bytes (0xef0100 gefolgt von einer 20-Byte-Zieladresse) – Quelle: EIP-7702 (2024)
• Der Übergang zu Revoked wird durch das Signieren eines Autorisierungs-Tupels auf die Nulladresse vollzogen.

Technische Spezifikation des Account Authority Lifecycle

Der ERC-Draft “Account Authority Lifecycle for STVA” definiert die folgenden Zustände und zwingende Prüfungen:

• Uninitialized – Konto ohne aktivierten Lifecycle.
• Active – Vollberechtigte Ausführung von Owner- und Modul-Aktionen.
• Attenuated – Nur Transaktionen über Scoped Capability Tokens zulässig.
• Suspended – Temporäre Sperrung bei fehlender Review-Compliance.
• Revoked – Atomare Entfernung der Delegations-Logik (z. B. EIP-7702).
• Recovered – Wiederherstellung nach erfolgreicher Capability-gesteuerter Wiederherstellung.

Hochriskante Änderungen wie das Hinzufügen eines Owners, das Ändern des Schwellenwerts, das Installieren eines Moduls, ein Upgrade des Implementationscodes oder das Setzen einer EIP-7702-Delegation müssen die folgenden Bedingungen erfüllen:

• Unabhängige Simulations-Resultate, die das vorgeschlagene Update exakt widerspiegeln.
• Explizite Autorisierung über ein Scoped Capability Token oder ein mehrseitiges Ritual.
• Optionaler Timelock oder Dual-Control-Mechanismus.

Zusätzlich kann ein Account einen lastAuthorityReview -Timestamp bereitstellen. Überschreitet das Review-Intervall die festgelegte Kadenz, wird der Zustand automatisch zu Suspended gewechselt – ein Mechanismus, der stale authority sichtbar macht.

Interface-Definition (IAccountAuthorityLifecycle)

interface IAccountAuthorityLifecycle { enum AuthorityState { Uninitialized, Active, Attenuated, Suspended, Revoked, Recovered } function authorityState() external view returns (AuthorityState); function listAuthorities() external view returns (address[] memory, bytes32[] memory roles); function lastReviewTimestamp() external view returns (uint48); function transitionAuthority( bytes32 capabilityHash, bytes calldata capabilitySig, SimulationResult calldata simResult, bytes calldata newAuthorityData ) external; event AuthorityTransitioned(AuthorityState from, AuthorityState to, bytes32 capabilityHash); event AuthorityReviewed(uint48 timestamp); }

Stärken und Nutzen des Entwurfs

• Schließt die Lücke zwischen bestehenden Modul-Schnittstellen und übergeordneter Governance.
• Verhindert unsichere Implementierungen beim Entzug von Vollmachten (z. B. EIP-7702).
• Ermöglicht die operative Nutzung von Scoped Capability Tokens und unabhängiger Simulations-Logik für hochwertige Konten und Multisigs.
• Erfordert keine Neuentwicklung von ERC-7579, sondern fügt lediglich Zustands-Checks hinzu.

Gegenargumente und Risikobetrachtung

Erhöhte Gas-Kosten und State-Bloat

Die zusätzlichen On-Chain-Zustandsprüfungen und Review-Timestamps können einfache Transaktionen verteuern. Dies könnte die Vorteile von Layer-2-Lösungen mindern, weil jeder Aufruf zusätzliche Prüflogik ausführen muss.

DoS-Risiko bei strikter Review-Kadenz

Wird ein Account nach Überschreiten des Review-Intervalls automatisch in den Suspended -Zustand versetzt, kann ein temporärer Lockout von Liquidität entstehen, insbesondere wenn Signer ausfallen oder die Review-Prozesse nicht rechtzeitig erfüllt werden.

FAQ – häufige Fragen zum Account Authority Lifecycle

Was unterscheidet ‘Attenuated’ von einem herkömmlichen Multisig-Status?Im Status Attenuated sind Root- und Generalvollmachten deaktiviert; der Account akzeptiert Transaktionen ausschließlich über kryptografisch feingranular eingeschränkte Scoped Capability Tokens.Wie wird eine Berechtigung unter EIP-7702 formal widerrufen?Durch das Signieren und Übermitteln eines Autorisierungs-Tupels, das auf die Adresse 0x0000000000000000000000000000000000000000 verweist und den Delegations-Code im Account löscht.

Zusammenfassung des Draft-Abschnitts “Specification”

Die Notwendigkeit eines formalisierten Lebenszyklusmodells wird besonders beim Zusammenspiel mit modularen Account-Abstraction-Architekturen deutlich. Während ERC-7579 die Registrierung von vier Kernmodultypen regelt, fehlt bisher eine systemische Überwachung über deren Gültigkeitsdauer hinweg. Ein Validator, der befristet autorisiert wurde, bleibt ohne expliziten Lifecycle dauerhaft aktiv. Die Einführung definierter Zustände wie Attenuated oder Suspended bindet Modulaufrufe an verifizierte Zeitstempel und schützt vor unbemerkt veralteten Ausführungsrechten.

Im Kontext von EIP-7702 bietet die Schnittstelle eine standardisierte Schutzschicht für delegierte EOAs. Da eine Code-Delegation über einen 23-Byte-Designator persistent im Account verankert bleibt, birgt eine unvollständige Bereinigung erhebliche Risiken. Die vorgeschlagene Transition Authority stellt sicher, dass der Übergang in den Status Revoked deterministisch über die Autorisierung der Nulladresse vollzogen wird. Verpflichtende Simulationsergebnisse schließen aus, dass privilegierte Module ohne vorherige Prüfung des Ausführungskontexts Berechtigungen manipulieren.

Fazit

Der vorgestellte Account Authority Lifecycle definiert einen klaren, technisch fundierten Rahmen für die kontinuierliche Verwaltung von Berechtigungen in modularen Smart Accounts, Multisigs und EIP-7702-kontrollierten Konten. Durch die Verknüpfung von Zustands-Checks, unabhängigen Simulations-Ergebnissen und Scoped Capability Tokens wird Authority Drift effektiv reduziert. Trotz berechtigter Bedenken hinsichtlich Gas-Kosten und möglicher DoS-Risiken liefert das Modell ein notwendiges Governance-Backbone, das bestehende Standards wie ERC-7579 und Safe ergänzen kann, ohne deren Kernspecifikationen zu ändern. Damit bietet es eine praktikable Lösung für die wachsende Komplexität und den Sicherheitsbedarf hochpreisiger Web3-Konten.