Beosin: EIP-7702 und AA-Wallet-Sicherheitsaudit-Analyse der nächsten Generation

Account Abstraction (AA) ist eine wichtige Richtung der langfristigen Erkundung im Ethereum-Ökosystem, die darauf abzielt, die Grenze zwischen externen Konten (EOA) und Vertragskonten zu durchbrechen, damit die Wallet eine stärkere Programmierbarkeit, Sicherheit und Aufrüstbarkeit aufweist. EIP-4337 ist derzeit die gängigste AA-Implementierungslösung und wird in einer Reihe von EntryPoint-basierten Smart-Contract-Wallets (z. B. Safe, Stacks und Argent) häufig verwendet. EIP-4337 weist jedoch aufgrund der Einführung eines unabhängigen Transaktionspools und eines On-Ramp-Vertragsmechanismus immer noch gewisse Einschränkungen in Bezug auf die On-Chain-Nativeness, die betriebliche Komplexität und die ökologische Kompatibilität auf.

Um die Einstiegshürde weiter zu senken und die native Unterstützung für Kontoabstraktionen zu verbessern, schlug Vitalik EIP-7702 im Jahr 2024 vor und nahm es in das Petra-Upgrade auf. Die Kernidee von EIP-7702 besteht darin, einer ursprünglichen EOA zu ermöglichen, den Vertragscode (contract_code) einer bestimmten Adresse auszuführen, wenn eine Transaktion initiiert wird, und diesen Code zu verwenden, um die Ausführungslogik der Transaktion zu definieren.

EIP-7702 führt einen neuen Mechanismus für die "Code-Injektion auf Transaktionsebene" ein, der es Benutzerkonten ermöglicht, die Ausführungslogik in jeder Transaktion dynamisch anzugeben, anstatt sich auf vorab bereitgestellten Vertragscode zu verlassen. Dies bricht das traditionelle statische codebasierte Berechtigungsmodell, bringt mehr Flexibilität mit sich und bringt neue Sicherheitsherausforderungen mit sich: Verträge, die auf Beurteilungslogik wie isContract und extcodehash basieren, können ungültig werden, und einige Systeme, die davon ausgehen, dass es sich bei dem Aufrufer um eine reine EOA handelt, können ebenfalls umgangen werden. Für Auditoren ist es wichtig, nicht nur die Sicherheit des injizierten Codes selbst zu überprüfen, sondern auch seine potenziellen Auswirkungen auf andere Vertragssysteme in einem dynamischen Kontext zu bewerten.

In diesem Artikel konzentriert sich das Beosin-Sicherheitsteam auf die Designprinzipien und Schlüsselfunktionen von EIP-7702, sortiert systematisch die Sicherheitsrisiken, denen die darauf basierende AA-Wallet im Audit ausgesetzt sein kann, und stellt den Audit-Prozess und Vorschläge aus praktischer Perspektive vor, um Sicherheitsforschern zu helfen, die technischen Herausforderungen unter diesem neuen Paradigma besser zu bewältigen.

1. Einführung in EIP-77021

. EIP-7702 Technischer

ÜberblickEIP-7702 führt einen neuen Transaktionstyp ein, 0x 04 (SetCode), der es EOA ermöglicht, den Vertragscode zu autorisieren, der über diese Transaktion ausgeführt werden muss, mit der folgenden Transaktionsstruktur:

1. rlp([chain_id, nonce, max_priority_fee_per_gas, max_ fee_per_gas, gas_limit,

2. Ziel, Wert, Daten, access_list, authorization_list, signature_y_parity, signature_r, signature_s])

Wenn authorization_list mehrere Berechtigungslisten enthält und auch Berechtigungsaktionen von Nicht-Transaktionsinitiatoren enthalten kann, lautet die interne Struktur:

1. authorization_list = [[chain_id, address, nonce, y_parity, r, s]].

wobei chain_id die Kette darstellt, in der die Autorisierung des Benutzers wirksam wird, und ihr Wert gleich der Ketten-ID der ausführenden Kette oder 0 sein muss. Wenn chain_id 0 ist, wird die Autorisierung für alle EVM-Chains wirksam, die EIP-7702 unterstützen, jedoch nur, wenn andere Parameter (z. B. Nonce) übereinstimmen. address gibt die vom Benutzer autorisierte Zielvertragsadresse an.

Nachdem die Autorisierung abgeschlossen ist, ändert das System das Codefeld des autorisierten Benutzers in 0x ef 0100 || Adresse, wobei die Adresse die autorisierte Vertragsadresse ist. Wenn Sie die Autorisierung aufheben möchten, initiieren Sie einfach eine SetCode-Transaktion, bei der die Adresse auf 0 festgelegt ist.

arabische Ziffer. Vorteile von EIP 7702

(1) Flexibilität & Anpassung

Abstract AccountsDurch das Schreiben von Kontologik in Smart Contracts können Sie Funktionen flexibel an Ihre Bedürfnisse anpassen. Beispielsweise können Benutzer Multi-Signaturen, Wiederherstellung in sozialen Netzwerken und Kontingentsteuerung konfigurieren, um die Anforderungen von Einzelpersonen oder Unternehmen in verschiedenen Szenarien zu erfüllen. Dieses Design verbessert die funktionale Skalierbarkeit des Kontos erheblich und durchbricht die Einschränkungen herkömmlicher externer Konten (EOA).

(2) Erweiterte

SicherheitAbstract-Konten bieten einen mehrschichtigen Sicherheitsmechanismus, einschließlich Multi-Faktor-Authentifizierung, Transaktionslimits und Social Recovery. Selbst wenn ein Benutzer seinen privaten Schlüssel verliert, kann er sein Konto durch vertrauenswürdige Kontakte oder Multi-Faktor-Authentifizierung wiederherstellen, wodurch der dauerhafte Verlust von Vermögenswerten vermieden wird, der durch den Verlust des privaten Schlüssels in herkömmlichen Konten verursacht wird. Gleichzeitig können durch Funktionen wie die Limitkontrolle auch verhindert werden, dass große Geldbeträge böswillig gestohlen werden.

(3) Das Gas Optimized Abstraction

Account unterstützt einen flexiblen Gasentnahmemechanismus, der es den Nutzern ermöglicht, Gas über einen Dritten zu bezahlen und sogar andere Token direkt zur Zahlung von Transaktionsgebühren zu verwenden. Dieser Mechanismus reduziert nicht nur die Betriebskosten der Nutzer, sondern vereinfacht auch die Nutzung der Blockchain weiter, besonders geeignet für Anfänger oder komplexe mehrstufige Transaktionsszenarien.

(4) Förderung der Popularisierung von Web3Durch

die Optimierung des Erlebnisses und der Sicherheit verbergen abstrakte Konten die Komplexität der Blockchain an Orten, die die Benutzer nicht sehen können, und ermöglichen so bequeme Operationen, die näher am Web2 liegen. Dieses Design reduziert die Lernkosten normaler Benutzer, ermöglicht es mehr Menschen, ohne Barrieren an Web3-Anwendungen teilzunehmen, und fördert die Popularisierung dezentraler Technologie.

2. Analyse der Sicherheitsrisiken in EIP-7702 in der Praxis

Obwohl EIP-7702 dem Ethereum-Ökosystem neue Impulse verliehen und eine Fülle von Anwendungsszenarien erweitert hat, hat es gleichzeitig unweigerlich einige neue Sicherheitsrisiken mit sich gebracht:

1. Autorisierungs-Replay-Angriff

Nach dem EIP-7702-Modell, wenn der Benutzer die chain_ autorisiert Wenn das Feld id auf 0 gesetzt ist, kann die Autorisierung für mehrere Ketten wirksam werden. Obwohl dieses Design der "Cross-Chain Universal Authorization" die Flexibilität in einigen Szenarien verbessert, birgt es auch offensichtliche Sicherheitsrisiken.

Es ist wichtig zu beachten, dass, selbst wenn die Kontoidentität derselben Adresse auf verschiedenen Chains gleich ist, die Vertragsimplementierung dahinter völlig unterschiedlich sein kann. Das bedeutet, dass ein Angreifer eine bösartige Version des Vertrags auf einer anderen Chain bereitstellen und unbeabsichtigte Aktionen ausführen könnte, indem er die Autorisierung derselben Adresse in der Chain verwendet, wodurch ein Risiko für die Vermögenswerte der Benutzer besteht.

Daher sollten Benutzer von Wallet-Dienstleistern oder Front-End-Interaktionsplattformen, wenn sie solche Autorisierungsvorgänge durchführen, eindeutig überprüfen, ob die in der Autorisierung des Benutzers deklarierte chainId mit dem aktuellen Verbindungsnetzwerk konsistent ist. Wenn ein Benutzer erkannt wird, dass er die chainId auf 0 setzt, sollte eine klare Risikowarnung ausgegeben werden, um den Benutzer daran zu erinnern, dass die Autorisierung für alle EVM-kompatiblen Chains wirksam wird und möglicherweise durch böswillige Verträge missbraucht wird.

Darüber hinaus sollte der Dienstanbieter auch prüfen, ob die Autorisierung mit chainId 0 standardmäßig auf der UI-Ebene eingeschränkt oder verboten werden soll, um das Risiko von Fehlbedienungen oder Phishing-Angriffen zu verringern.

2. Vertragskompatibilität

1) Kompatibilität von Vertragsrückrufen

Sie Geld an eine Vertragsadresse für bestehende Token-Verträge wie ERC-721, ERC-777 und ERC 1155 überweisen, rufen sie Standard-Rückrufschnittstellen (z. B. onERC 721 Received, tokensReceived) auf, um den Überweisungsvorgang abzuschließen. Wenn die Empfängeradresse die entsprechende Schnittstelle nicht implementiert, schlägt die Übertragung fehl oder führt sogar dazu, dass das Asset gesperrt wird.

In EIP-7702 kann eine Benutzeradresse in ein Vertragskonto umgewandelt werden, indem durch den Vorgang "set_code" ein Vertragscode zugewiesen wird. In diesem Fall:

• Die Nutzeradresse gilt als Vertrag;

• Wenn der Vertrag die erforderliche Rückrufschnittstelle nicht implementiert, schlägt die Tokenübertragung fehl.

• Benutzer sind möglicherweise nicht in der Lage, Mainstream-Token ohne ihr Wissen zu erhalten.

Daher sollten Entwickler sicherstellen, dass der vom Benutzer delegierte Zielvertrag die entsprechende Callback-Schnittstelle implementiert, um die Kompatibilität mit Mainstream-Token sicherzustellen.

(2) Die "tx.origin"-Verifizierung schlägt fehlIn

herkömmlichen Verträgen wird "tx.origin" häufig verwendet, um festzustellen, ob die Transaktion direkt vom Benutzer initiiert wird, und wird verwendet, um Sicherheitskontrollen wie Vertragsaufrufe zu verhindern.

Im EIP-7702-Szenario

• signiert der Benutzer jedoch eine Autorisierungstransaktion, und der Relayer oder Bundler sendet sie im Namen des Benutzers. Wenn eine Transaktion ausgeführt wird, ist "tx.origin" die Relayer-Adresse, nicht die Benutzeradresse.

• "msg.sender" ist ein Wallet-Vertrag, der die Identität des Benutzers darstellt.

Daher führt die Berechtigungsüberprüfung auf der Grundlage von "tx.origin == msg.sender" dazu, dass legitime Benutzervorgänge abgelehnt werden und die Zuverlässigkeit verloren geht, und dieselben eingeschränkten Vertragsaufrufe wie "tx.origin == user" werden ebenfalls ungültig. Es wird empfohlen, "tx.origin" als Grundlage für die Sicherheitsbeurteilung aufzugeben und stattdessen einen Signaturüberprüfungs- oder Autorisierungsmechanismus zu verwenden.

(3) "isContract"-FehleinschätzungenViele

Verträge verhindern, dass Vertragskonten an bestimmten Operationen, wie z.B. Airdrops, Flash-Verkäufen usw., teilnehmen, und zwar durch "isContract(address)":

require(!isContract(msg.sender), "Contracts not allowed"

). Im Rahmen des EIP-7702-Mechanismus kann die Adresse des Benutzers durch eine "set_code"-Transaktion in ein Vertragskonto geändert werden, und "isContract" gibt true zurück, und der Vertrag identifiziert den legitimen Benutzer fälschlicherweise als das Vertragskonto und weigert sich, an der Operation teilzunehmen, was dazu führt, dass der Benutzer bestimmte Dienste nicht nutzen kann und die Erfahrung blockiert wird.

Mit der allmählichen Popularisierung von Vertrags-Wallets wird das Design, sich auf "isContract" zu verlassen, um festzustellen, ob "ein menschlicher Benutzer" nicht mehr sicher ist, und es wird empfohlen, genauere Methoden zur Benutzeridentifizierung wie die Überprüfung von Unterschriften zu verwenden.

3. Phishing-AngriffNach

der Implementierung des Delegationsmechanismus von EIP-7702 werden die Vermögenswerte im Benutzerkonto vollständig durch den delegierten Smart Contract kontrolliert. Sobald ein Benutzer einen böswilligen Vertrag autorisiert, kann ein Angreifer die volle Kontrolle über das Kontovermögen erlangen, was zu einer schnellen Überweisung oder einem Diebstahl von Geldern führt, was äußerst riskant ist.

Daher ist es für Anbieter von Wallet-Diensten notwendig, den EIP-7702-Mechanismus zur Transaktionsauflösung und Risikoidentifizierung so bald wie möglich zu unterstützenEntscheidend. Wenn ein Benutzer eine Betrauungstransaktion unterzeichnet, sollte das Front-End die Zielvertragsadresse klar und deutlich anzeigen und unterstützende Informationen wie Vertragsquelle und Bereitstellungsinformationen kombinieren, um Benutzern zu helfen, potenzielle Phishing- oder betrügerische Verhaltensweisen zu erkennen und so das Risiko einer Fehlsignierung zu verringern. Darüber hinaus sollte der Wallet-Dienst automatische Sicherheitsanalysefunktionen für den Zielvertrag integrieren, wie z. B. die Überprüfung des Open-Source-Status des Vertragscodes, die Analyse des Berechtigungsmodells und die Identifizierung potenziell gefährlicher Operationen, um den Benutzern zu helfen, vor der Autorisierung sicherere Urteile zu treffen.

Insbesondere führt EIP-7702 ein delegiertes Signaturformat ein, das nicht mit den bestehenden Signaturstandards EIP-191 und EIP-712 kompatibel ist. Seine Signatur kann die ursprüngliche Signaturwarnung und Interaktionsaufforderung der Wallet leicht umgehen, was das Risiko weiter erhöht, dass Benutzer dazu verleitet werden, böswillige Operationen zu signieren. Daher wird die Einführung des Identifikations- und Verarbeitungsmechanismus der Signaturstruktur in der Wallet-Implementierung ein wichtiges Bindeglied sein, um die Sicherheit der Benutzer zu gewährleisten.

4. Wallet-Vertragsrisiken

( 1) Verwaltung von Wallet-Vertragsberechtigungen

Viele EIP-7702-Wallet-Verträge verwenden eine Proxy-Architektur (oder integrierte Verwaltungsberechtigungen), um logische Upgrades zu unterstützen. Dies birgt jedoch auch ein höheres Risiko für die Rechtewahrnehmung. Wenn die Eskalationsberechtigungen nicht streng eingeschränkt sind, kann ein Angreifer den Implementierungsvertrag ersetzen und bösartigen Code einschleusen, was dazu führt, dass das Konto des Benutzers manipuliert oder Gelder gestohlen werden.

• Sicherheitsempfehlungen: Verwenden Sie Multi-Signatur-, Multi-Faktor-Authentifizierungs- oder Timelock-Mechanismen, um Eskalationsberechtigungen zu steuern.

• Code- und Berechtigungsänderungen unterliegen einer strengen Überwachung und Sicherheitsüberprüfung.

• Der Upgrade-Prozess ist offen und transparent, um das Recht der Benutzer auf Wissen und Teilnahme zu gewährleisten.

(2) Das Risiko von Speicherkonflikten und Datenisolierung,

Wallet-Vertragsversionen oder verschiedene Wallet-Dienstleister können denselben Speicherplatz wiederverwenden. Wenn der Benutzer den Wallet-Dienstanbieter wechselt oder die Wallet-Logik aktualisiert, führt die Wiederverwendung des Speicherplatzes zu Konflikten mit der Statusvariablen, zum Überschreiben von Daten, zu Leseausnahmen und anderen Problemen. Dies kann nicht nur die normale Funktion der Wallet stören, sondern auch zum Verlust von Geldern oder abnormalen Berechtigungen führen.

Sicherheitsempfehlungen:

• Verwenden Sie ein spezielles Speicherisolationsschema, z. B. den EIP-1967-Standard, oder nutzen Sie einen eindeutigen Namespace zur Verwaltung von Speichersteckplätzen.

• Achten Sie beim Upgrade des Vertrags darauf, dass das Speicherlayout kompatibel ist, und vermeiden Sie überlappende Variablen.

• Testen Sie während des Upgrade-Prozesses rigoros die Plausibilität des gespeicherten Status.

(3) Das Nonce-Management innerhalb des Wallets

Der Wallet-Vertrag richtet in der Regel eine Nonce im Inneren ein und verwaltet sich selbst, um die Ausführungsreihenfolge von Benutzeroperationen sicherzustellen und Replay-Angriffe zu verhindern. Wenn die Nonce falsch verwendet wird, wird der Benutzervorgang nicht ordnungsgemäß ausgeführt.

Sicherheitsempfehlung:

• Die Nonce muss zwangsweise auf einen entsprechenden Wert (oder ein Inkrement) überprüft werden und kann nicht übersprungen werden.

• Es ist verboten, dass Funktionen die Nonce direkt ändern, und die Nonce wird nur aktualisiert, wenn die Benutzeroperation ausgeführt wird.

• Entwerfen Sie Fehlertoleranz- und Wiederherstellungsmechanismen für Nonce-Ausnahmen, um Nonce-Deadlocks zu vermeiden.

(4) Prüfung der FunktionsaufruferberechtigungUm

die Sicherheit zu gewährleisten, muss der Wallet-Vertrag sicherstellen, dass der Aufrufer der Schlüsselfunktion das Besitzerkonto des Wallets ist. Zu den beiden gängigen Methoden gehören:

• Die Off-Chain-Signierung autorisiert

Benutzer, eine Reihe von Operationen über den privaten Schlüssel zu signieren, und der Wallet-Vertrag überprüft, ob die Signatur legitim und abgelaufen ist und die entsprechende Nonce auf der Chain erfüllt. Diese Methode ist auf den von EIP-7702 befürworteten Relay-Transaktionsmodus anwendbar (Benutzer-Offline-Signatur + Relayer sendet Transaktion im Namen des Benutzers).

• Constraint" (msg.sender == address(this))

darf nur durch den Vertrag selbst ausgelöst werden, bei dem es sich im Wesentlichen um einen Mechanismus zur Steuerung des Anrufpfads handelt, der sicherstellt, dass der externe Initiator das Konto selbst sein muss. Dies ist praktisch gleichbedeutend mit der Anforderung, dass der Anrufer der ursprüngliche EOA sein muss, da die Vertragsadresse die EOA-Adresse ist.

3. Ausblick: Der Vorschlag von EIP-7702 und dem zukünftigen AA-Wallet-Standard

EIP-7702 ist nicht nur eine Innovation des traditionellen Kontomodells, sondern auch eine wichtige Förderung des Ökosystems der Kontoabstraktion. Die Möglichkeit, Vertragscode zu laden, der dadurch eingeführt wurde, bietet einen breiten Spielraum für die Erforschung des zukünftigen Wallet-Designs und des Vertragssystems und stellt auch neue Anforderungen an Sicherheitsprüfungsstandards.

1. Co-Evolution mit EIP-4337: Auf dem Weg zur Dual-Mode-KompatibilitätObwohl

EIP-7702 und EIP-4337 unterschiedliche Designziele verfolgen, rekonstruiert EIP-7702 und EIP-4337 den Code-Lademechanismus des Kontos, während letzteres ein vollständiges Ökosystem für Transaktionseingaben und -pakete aufbaut. Die beiden stehen jedoch nicht im Widerspruch, sondern ergänzen sich stark:

● EIP-4337 bietet einen "gemeinsamen Transaktionskanal" und eine "abstrakte Schnittstelle für die Kontoausführung";

● EIP-7702 ermöglicht es Benutzerkonten, Vertragslogikfunktionen dynamisch zu gewähren, ohne die Adresse zu ändern.

Daher könnten Wallets in Zukunft eine "Dual-Mode-Support-Architektur" annehmen: Verwenden Sie EIP-7702 als leichtgewichtigen Ersatz für Chains, die EIP-4337 nicht unterstützen, und verlassen Sie sich weiterhin auf den vollständigen Protokollstack von EIP-4337 in Szenarien, die Off-Chain-Packaging und Multi-User-Aggregation erfordern.

Dieser Dual-Mode-Mechanismus wird es Wallets auch ermöglichen, flexiblere Kontoberechtigungsmodelle, Downgrade-Mechanismen und Rollback-Schemata auf der Kernel-Ebene zu unterstützen.

2. Unterstützung und Inspiration für neue Wallet-Logiken wie MPC und ZK, und der

von EIP-7702 befürwortete Kontovertragsmechanismus hat ein natürliches Integrationspotenzial mit der derzeit beliebten MPC-Wallet, der ZK-Wallet, der modularen Wallet und anderen neuen Architekturen:

● Im MPC-Modell beruht das Signaturverhalten nicht mehr auf einem einzigen privaten Schlüssel, sondern ist eine kollaborative Entscheidungsfindung mehrerer Parteien. Signaturen, die durch die Konvergenz von EIP-7702 und MPC generiert werden, steuern die dynamisch geladene Vertragslogik und ermöglichen so flexiblere Ausführungsstrategien.

● Die ZK-Wallet überprüft die Identität oder Autorisierung des Benutzers durch Zero-Knowledge-Proofs, ohne Informationen über private Schlüssel preiszugeben. In Kombination mit EIP-7702 können ZK-Wallets nach Abschluss der Verifizierung vorübergehend bestimmte Logikverträge injizieren, um den Einsatz personalisierter Verhaltensweisen nach dem Privacy Computing zu realisieren, wie z. B. die automatische Ausführung einer bestimmten Logik erst nachdem bestimmte Datenschutzbedingungen erfüllt sind.

● Modulare Wallets können EIP-7702 verwenden, um die Kontologik in mehrere Module zu zerlegen und diese bei Bedarf dynamisch zu laden.

Daher bietet EIP-7702 einen nativeren "Ausführungscontainer" für die oben genannten erweiterten Wallets: Unterschiedliche Vertragslogiken können mit derselben Benutzeradresse injiziert werden, wodurch das Problem der Adressabhängigkeit im traditionellen Vertragsbereitstellungsprozess vermieden und die Notwendigkeit einer Vorabbereitstellung eliminiert wird, wodurch die Flexibilität und Kombination des Kontoverhaltens erheblich verbessert wird.

3. Auswirkungen auf Vertragsentwickler und

wird zu einem tiefgreifenden Wandel des Entwicklungsparadigmas führen. Vertragsentwickler behandeln den Anrufer nicht mehr einfach wie ein traditionelles EOA- oder Festvertragskonto, sondern müssen sich auf einen neuen Mechanismus einstellen: Die Identität des Anrufers kann während der Transaktion dynamisch zwischen EOA- und Vertragsstatus umgeschaltet werden, und die Kontoverhaltenslogik ist nicht mehr statisch verfestigt, sondern kann flexibel je nach Bedarf geändert werden. Dies erfordert von Entwicklern und Auditoren:

• Einführung einer strengeren Logik für die Anruferüberprüfung und Berechtigungsbeurteilung;

• Prüfen Sie, ob der Aufrufpfad von der dynamischen Vertragslogik beeinflusst wird.

• Identifizierung potenzieller Schwachstellen, die auf Verhaltensweisen wie msg.sender.code.length == 0, isContract() usw. beruhen;

• Klären Sie die "Kontextabhängigkeiten" der Vertragslogik, z. B. die Grenzsteuerung von statischen Aufrufen und Delegate-Aufrufen;

• Auf der Ebene der Toolchain werden die Simulation und die Revert-Analyse von setCode-Szenarien unterstützt.

Mit anderen Worten: Codesicherheit ist nicht mehr nur ein "Pre-Deployment-Problem", sondern ein "dynamischer Prozess, der während des Aufrufs und der Transaktion überprüft werden muss".

4.

führt eine leichtere, native und flexiblere Implementierung von Account Abstraction (AA) ein, so dass gewöhnliche EOA Vertragslogik tragen und in einer einzigen Transaktion ausführen kann. Dieser Mechanismus bricht die traditionellen statischen Annahmen über das Kontoverhalten, und Entwickler können sich nicht mehr einfach auf den Codestatus der Kontoadresse verlassen, um ihr Verhaltensmodell zu beurteilen, sondern müssen das Verständnis der Identitäts- und Autoritätsgrenze des Aufrufers rekonstruieren.

Damit einher geht ein Paradigmenwechsel in der Sicherheitsanalytik. Der Fokus des Audits beschränkt sich nicht mehr darauf, "ob eine Adresse Berechtigungen hat", sondern darauf, "was die in der Transaktion mitgeführte Vertragslogik im aktuellen Kontext leisten kann". Jede Transaktion kann eine unabhängige Verhaltensdefinition haben, die dem Konto eine größere Funktionalität verleiht und höhere Anforderungen an Sicherheitsüberprüfungen stellt.