2 Posts getaggt mit "Smart Contracts"

Formale Verifikation bei Smart-Contract-Audits​

Formale Verifikation bezieht sich auf die Verwendung mathematischer und logikbasierter Techniken, um die Korrektheit und Sicherheit von Smart Contracts zu beweisen. In der Praxis umfasst dies ein Spektrum von Methoden: von eigenschaftsbasiertem Fuzz-Testing und symbolischer Ausführung bis hin zu rigorosem Theorembeweis und Model-Checking. Ziel ist es, sicherzustellen, dass ein Contract seine Spezifikationen erfüllt und über alle möglichen Inputs und Zustände hinweg keine ausnutzbaren Bugs enthält. Angesichts der hohen Einsätze (Milliarden von Dollar sind in DeFi-Protokollen gebunden) sind formale Methoden für Ethereum und andere Blockchain-Plattformen immer wichtiger geworden.

Traditionelle Ansätze: Frühe formale Methoden für Ethereum umfassten Tools zur symbolischen Ausführung wie Oyente und Mythril sowie statische Analysatoren wie Slither und Securify. Die symbolische Ausführung untersucht Programmpfade mit symbolischen Inputs, um Probleme (z. B. Reentrancy, Integer-Overflow) zu erkennen, während die statische Analyse regelbasiertes Pattern Matching verwendet. Diese Tools waren erfolgreich, hatten aber auch Einschränkungen: Zum Beispiel litt Oyente unter vielen Fehlalarmen selbst bei einfachen Contracts, und Slithers musterbasierte Detektoren können mehrere False Positives erzeugen. Darüber hinaus ergab eine Studie aus dem Jahr 2023, dass über 80 % der ausnutzbaren Contract-Bugs (insbesondere komplexe „Business-Logic“-Bugs) von den aktuellen Tools übersehen wurden, was die Notwendigkeit robusterer Verifikationstechniken unterstreicht.

Das Versprechen und die Herausforderung der vollständigen Verifikation: Theoretisch kann die formale Verifikation die Abwesenheit von Bugs beweisen, indem sie Invarianten für alle Zustände erschöpfend überprüft. Tools wie der Certora Prover oder das KEVM-Framework der Ethereum Foundation zielen darauf ab, Smart Contracts mathematisch gegen eine formale Spezifikation zu verifizieren. Zum Beispiel verwendet Certoras „automatisierter mathematischer Auditor“ eine Spezifikationssprache (CVL), um benutzerdefinierte Regeln zu beweisen oder zu widerlegen. In der Praxis ist das vollständige Beweisen von Eigenschaften bei realen Contracts jedoch oft unerreichbar oder sehr arbeitsintensiv. Code muss möglicherweise für die Verifikation in vereinfachte Formen umgeschrieben werden, benutzerdefinierte Spezifikationen müssen erstellt werden, Schleifen und komplexe Arithmetik erfordern möglicherweise manuelle Grenzen oder Abstraktionen, und SMT-Solver laufen bei komplexer Logik häufig in einen Timeout. Wie Ingenieure von Trail of Bits feststellten, ist „der Nachweis der Abwesenheit von Bugs bei nicht-trivialen Codebasen typischerweise unerreichbar“, und dies zu erreichen erfordert oft erhebliche Benutzereingriffe und Fachwissen. Aus diesem Grund wurden formale Verifikationstools traditionell sparsam für kritische Codeteile (z. B. die Verifikation einer Token-Invariante oder eines Konsensalgorithmus) eingesetzt, anstatt für ganze Contracts von Anfang bis Ende.

Foundrys Fuzz-Testing und Invarianten-Testing​

In den letzten Jahren hat sich das eigenschaftsbasierte Testen als praktische Alternative zu vollständigen formalen Beweisen etabliert. Foundry, ein beliebtes Ethereum-Entwicklungsframework, bietet integrierte Unterstützung für Fuzz-Testing und Invarianten-Testing – Techniken, die die Testabdeckung erheblich verbessern und als leichtgewichtige formale Verifikation angesehen werden können. Foundrys Fuzz-Testing generiert automatisch eine große Anzahl von Inputs, um zu versuchen, spezifizierte Eigenschaften zu verletzen, und das Invarianten-Testing erweitert dies auf Sequenzen von zustandsändernden Operationen:

• Fuzz-Testing: Anstatt Unit-Tests für spezifische Inputs zu schreiben, spezifiziert der Entwickler Eigenschaften oder Invarianten, die für jeden Input gelten sollen. Foundry generiert dann Hunderte oder Tausende von zufälligen Inputs, um die Funktion zu testen und überprüft, ob die Eigenschaft immer gilt. Dies hilft, Edge Cases abzufangen, die ein Entwickler manuell möglicherweise nicht testen würde. Zum Beispiel könnte ein Fuzz-Test behaupten, dass der Rückgabewert einer Funktion immer nicht-negativ ist oder dass eine bestimmte Nachbedingung unabhängig von den Inputs wahr ist. Foundrys Engine verwendet intelligente Heuristiken – sie analysiert Funktionssignaturen und führt Edge-Case-Werte (0, max uint usw.) ein –, um Grenzfälle zu treffen, die wahrscheinlich die Eigenschaft verletzen. Wenn eine Assertion fehlschlägt, meldet Foundry einen Gegenbeispiel-Input, der die Eigenschaft verletzt.

• Invarianten-Testing: Foundrys Invarianten-Testing (auch Stateful Fuzzing genannt) geht noch weiter, indem es mehrere Funktionsaufrufe und Zustandsübergänge nacheinander ausführt. Der Entwickler schreibt Invarianten-Funktionen, die während der gesamten Lebensdauer des Contracts wahr sein sollen (z. B. Gesamtvermögen = Summe der Benutzerguthaben). Foundry generiert dann zufällig Sequenzen von Aufrufen (mit zufälligen Inputs), um viele mögliche Nutzungsszenarien zu simulieren, und überprüft regelmäßig, ob die Invarianten-Bedingungen wahr bleiben. Dies kann komplexe Bugs aufdecken, die sich erst nach einer bestimmten Abfolge von Operationen manifestieren. Im Wesentlichen erforscht das Invarianten-Testing den Zustandsraum des Contracts gründlicher und stellt sicher, dass keine Abfolge gültiger Transaktionen die angegebenen Eigenschaften verletzen kann.

Warum Foundry wichtig ist: Foundry hat diese fortschrittlichen Testtechniken zugänglich gemacht. Die Fuzzing- und Invarianten-Funktionen sind nativ im Entwickler-Workflow – es wird kein spezielles Harness oder externes Tool benötigt, und Tests werden in Solidity neben Unit-Tests geschrieben. Dank einer Rust-basierten Engine kann Foundry Tausende von Tests schnell ausführen (sie parallelisieren) und detaillierte Fehler-Traces für jede Invarianten-Verletzung bereitstellen. Entwickler berichten, dass Foundrys Fuzzer einfach zu bedienen und hochperformant ist und nur eine geringe Konfiguration erfordert (z. B. die Einstellung der Anzahl der Iterationen oder das Hinzufügen von Annahmen zur Einschränkung der Inputs). Ein einfaches Beispiel aus Foundrys Dokumentation ist ein Fuzz-Test für eine divide(a,b)-Funktion, die vm.assume(b != 0) verwendet, um triviale ungültige Inputs zu vermeiden, und dann mathematische Nachbedingungen wie result * b <= a behauptet. Durch das Ausführen eines solchen Tests mit Tausenden von zufälligen (a,b)-Paaren könnte Foundry schnell Edge Cases (wie Überlaufgrenzen) entdecken, die durch manuelles Denken schwer zu finden wären.

Vergleiche: Foundrys Ansatz baut auf früheren Arbeiten in der Community auf. Der Echidna Fuzzer von Trail of Bits war ein früheres eigenschaftsbasiertes Testtool für Ethereum. Echidna generiert ebenfalls zufällige Transaktionen, um Verletzungen von Invarianten zu finden, die als Solidity-Funktionen ausgedrückt werden, die einen booleschen Wert zurückgeben. Es ist bekannt für die „intelligente“ Input-Generierung (einschließlich Coverage-Guided Fuzzing) und wurde verwendet, um viele Bugs zu finden. Tatsächlich stellen Sicherheitsforscher fest, dass Echidnas Engine äußerst effektiv ist – „der Trail of Bits Echidna ist der beste Fuzzer auf dem Markt aufgrund seiner intelligenten Zufallszahlenauswahl“ – obwohl Foundrys integrierter Workflow das Schreiben von Tests für Entwickler vereinfacht. In der Praxis wird Foundrys Fuzz-Testing oft als das neue „Minimum“ für die sichere Solidity-Entwicklung angesehen, das traditionelle Unit-Tests ergänzt. Es kann die Abwesenheit von Bugs nicht beweisen (da es randomisiert und nicht erschöpfend ist), aber es erhöht das Vertrauen erheblich, indem es eine große Bandbreite von Inputs und Zustandskombinationen abdeckt.

Jenseits von Fuzzing: Formale Beweise und fortschrittliche Tools​

Während Fuzzing und Invarianten viele Probleme aufdecken, gibt es Fälle, in denen stärkere formale Methoden eingesetzt werden. Model-Checking und Theorembeweis beinhalten die Spezifikation gewünschter Eigenschaften in einer formalen Logik und die Verwendung automatischer Beweiser, um diese gegen den Contract-Code zu überprüfen. Der Certora Prover (kürzlich Open-Source gestellt) ist ein prominentes Tool in dieser Kategorie. Er ermöglicht es Entwicklern, Regeln in einer domänenspezifischen Sprache (CVL) zu schreiben und dann den Contract automatisch auf Verletzungen dieser Regeln zu überprüfen. Certora wurde verwendet, um kritische Invarianten in Protokollen wie MakerDAO und Compound zu verifizieren; zum Beispiel identifizierte es den „DAI debt invariant“-Bug in MakerDAO (eine subtile Buchhaltungsinkonsistenz), der vier Jahre lang unbemerkt blieb. Bemerkenswerterweise unterstützt Certoras Engine nun mehrere Plattformen (EVM, Solanas VM und eWASM), und durch die Open-Sourcing im Jahr 2025 wurde formale Verifikation in Industriequalität auf Ethereum, Solana und Stellar frei verfügbar gemacht. Dieser Schritt erkennt an, dass formale Beweise kein Luxus nur für gut finanzierte Teams sein sollten.

Andere formale Tools umfassen Ansätze zur Laufzeitverifikation (z. B. die KEVM-Semantik von Ethereum oder der Move Prover für Move-basierte Chains). Der Move Prover ist insbesondere in die Move-Sprache integriert (die von den Blockchains Aptos und Sui verwendet wird). Er ermöglicht das Schreiben formaler Spezifikationen neben dem Code und kann bestimmte Eigenschaften automatisch beweisen, mit einer Benutzererfahrung, die einem Linter oder Type-Checker ähnelt. Diese enge Integration senkt die Hürde für Entwickler auf diesen Plattformen, formale Verifikation als Teil der Entwicklung zu nutzen.

Zusammenfassung: Die heutige Smart-Contract-Prüfung kombiniert diese Methoden. Fuzzing und Invarianten-Testing (exemplifiziert durch Foundry und Echidna) sind weit verbreitet wegen ihrer Benutzerfreundlichkeit und Effektivität beim Aufspüren gängiger Bugs. Symbolische Ausführung und statische Analysatoren dienen weiterhin dazu, schnell nach bekannten Schwachstellenmustern zu suchen (wobei Tools wie Slither oft in CI-Pipelines integriert sind). Inzwischen reifen formale Verifikationstools und expandieren über Chains hinweg, sind aber aufgrund ihrer Komplexität typischerweise für spezifische kritische Eigenschaften reserviert oder werden von spezialisierten Prüfungsfirmen eingesetzt. In der Praxis kombinieren viele Audits diese Ansätze: z. B. die Verwendung von Fuzzern, um Laufzeitfehler zu finden, statische Tools, um offensichtliche Fehler zu kennzeichnen, und formale Spezifikationsprüfungen für Schlüsselinvarianten wie „kein Token-Guthaben überschreitet das Gesamtangebot“.

KI-gestützte Audits mit großen Sprachmodellen​

Das Aufkommen großer Sprachmodelle (LLMs) wie OpenAIs GPT-3/4 (ChatGPT) und Codex hat ein neues Paradigma für die Smart-Contract-Analyse eingeführt. Diese Modelle, die auf riesigen Mengen an Code und natürlicher Sprache trainiert wurden, können über Programmverhalten nachdenken, Code erklären und sogar bestimmte Schwachstellen durch Mustererkennung und „gesundes Menschenverstand“-Wissen erkennen. Die Frage ist: Kann KI Smart-Contract-Audits erweitern oder sogar automatisieren?

LLM-basierte Tools zur Schwachstellenanalyse​

Mehrere Forschungsbemühungen und Prototyp-Tools sind entstanden, die LLMs auf Smart-Contract-Audits anwenden:

• OpenAI Codex / ChatGPT (allgemeine Modelle): Frühe Experimente bestanden einfach darin, GPT-3 oder Codex mit Contract-Code zu versehen und nach potenziellen Bugs zu fragen. Entwickler stellten fest, dass ChatGPT einige bekannte Schwachstellenmuster identifizieren und sogar Korrekturen vorschlagen konnte. Die Antworten waren jedoch unzuverlässig und nicht durchgängig umfassend. Eine aktuelle akademische Bewertung stellte fest, dass die naive Aufforderung von ChatGPT zur Schwachstellenerkennung „keine signifikant besseren Ergebnisse im Vergleich zur Zufallsvorhersage“ auf einem Benchmark-Datensatz lieferte – im Wesentlichen kann das Modell, wenn es nicht richtig geführt wird, Probleme halluzinieren, die nicht existieren, oder echte Schwachstellen übersehen. Dies unterstrich die Notwendigkeit sorgfältig entwickelter Prompts oder eines Fine-Tunings, um nützliche Ergebnisse zu erzielen.

• AuditGPT (2024): Dies ist ein akademisches Tool, das ChatGPT (GPT-3.5/4) speziell zur Überprüfung der ERC-Standardkonformität in Ethereum-Contracts nutzte. Die Forscher stellten fest, dass viele ERC20/ERC721-Token-Contracts subtile Regeln des Standards verletzen (was zu Sicherheits- oder Kompatibilitätsproblemen führen kann). AuditGPT zerlegt den Audit in kleine Aufgaben und entwirft spezialisierte Prompts für jeden Regeltyp. Das Ergebnis war beeindruckend: Bei Tests an realen Contracts „identifizierte AuditGPT erfolgreich 418 ERC-Regelverletzungen und meldete nur 18 False Positives“, was eine hohe Genauigkeit demonstriert. Tatsächlich behauptet das Paper, dass AuditGPT einen professionellen Audit-Dienst übertraf beim Auffinden von ERC-Konformitäts-Bugs, und das zu geringeren Kosten. Dies deutet darauf hin, dass für gut definierte, enge Domänen (wie die Durchsetzung einer Liste von Standardregeln) ein LLM mit guten Prompts bemerkenswert effektiv und präzise sein kann.

• LLM-SmartAudit (2024): Ein weiteres Forschungsprojekt, LLM-SmartAudit, verfolgt einen breiteren Ansatz, indem es ein Multi-Agenten-Konversationssystem zur Prüfung von Solidity-Code verwendet. Es richtet mehrere spezialisierte GPT-3.5/GPT-4-Agenten ein (z. B. einen „Auditor“, der sich auf Korrektheit konzentriert, einen „Angreifer“, der überlegt, wie man ausnutzen kann), die miteinander kommunizieren, um einen Contract zu analysieren. In ihrer Bewertung konnte LLM-SmartAudit eine breite Palette von Schwachstellen erkennen. Bemerkenswerterweise erreichte das GPT-3.5-basierte System in einem Vergleichstest mit konventionellen Tools den höchsten Gesamtrecall (74 %) und übertraf alle traditionellen statischen und symbolischen Analysatoren, die sie testeten (der nächstbeste war Mythril mit 54 % Recall). Es konnte auch alle 10 Arten von Schwachstellen in ihrer Testsuite finden (während jedes traditionelle Tool mit einigen Kategorien zu kämpfen hatte). Darüber hinaus konnte das System durch den Wechsel zu GPT-4 und die Fokussierung der Analyse (was sie als Targeted Analysis Mode bezeichnen) komplexe logische Fehler erkennen, die Tools wie Slither und Mythril vollständig übersehen hatten. Zum Beispiel fand der LLM-basierte Ansatz bei einer Reihe von realen DeFi-Contracts Hunderte von Logik-Bugs, während die statischen Tools „keine Wirksamkeit beim Erkennen“ dieser Probleme zeigten. Diese Ergebnisse zeigen das Potenzial von LLMs, subtile Bugs zu erkennen, die über den Mustererkennungsbereich traditioneller Analysatoren hinausgehen.

• Prometheus (PromFuzz) (2023): Ein hybrider Ansatz besteht darin, LLMs zu verwenden, um andere Techniken zu leiten. Ein Beispiel ist PromFuzz, das einen GPT-basierten „Auditor-Agenten“ verwendet, um verdächtige Bereiche im Code zu identifizieren, dann automatisch Invarianten-Checker generiert und diese in eine Fuzzing-Engine einspeist. Im Wesentlichen führt das LLM eine Erstanalyse durch (sowohl aus einer gutartigen als auch aus einer Angreiferperspektive), um das Fuzz-Testing auf wahrscheinliche Schwachstellen zu konzentrieren. Bei Bewertungen erreichte dieser Ansatz sehr hohe Bug-Findungsraten – z. B. über 86 % Recall mit null False Positives in bestimmten Benchmark-Sets – und übertraf damit eigenständige Fuzzer oder frühere Tools erheblich. Dies ist eine vielversprechende Richtung: KI zu nutzen, um klassische Techniken wie Fuzzing zu orchestrierten und zu verbessern, indem die Stärken beider kombiniert werden.

• Andere KI-Tools: Die Community hat verschiedene andere KI-gestützte Audit-Konzepte gesehen. Zum Beispiel integrierte das „Toucan“-Projekt von Trail of Bits OpenAI Codex in ihren Audit-Workflow (mehr zu seinen Erkenntnissen weiter unten). Einige Sicherheits-Startups werben auch mit KI-Auditoren (z. B. „ChainGPT Audit“-Dienste), die typischerweise GPT-4 mit benutzerdefinierten Prompts umwickeln, um Contracts zu überprüfen. Open-Source-Enthusiasten haben ChatGPT-basierte Audit-Bots in Foren erstellt, die einen Solidity-Snippet entgegennehmen und potenzielle Probleme ausgeben. Während viele davon experimentell sind, ist der allgemeine Trend klar: KI wird auf jeder Ebene des Sicherheitsüberprüfungsprozesses erforscht, von der automatisierten Code-Erklärung und Dokumentationsgenerierung über die Schwachstellenerkennung bis hin zum Vorschlagen von Korrekturen.

Fähigkeiten und Einschränkungen von LLM-Auditoren​

LLMs haben bemerkenswerte Fähigkeiten bei Smart-Contract-Audits gezeigt:

• Breites Wissen: Ein LLM wie GPT-4 wurde auf unzähligen Codes und Schwachstellen trainiert. Es „weiß“ über gängige Sicherheitsfallen (Reentrancy, Integer-Overflow usw.) und sogar einige historische Exploits Bescheid. Dies ermöglicht es ihm, Muster zu erkennen, die auf einen Bug hindeuten könnten, und Best Practices aus der Dokumentation abzurufen. Zum Beispiel könnte es sich daran erinnern, dass ERC-20 transferFrom Allowances überprüfen sollte (und das Fehlen einer solchen Überprüfung als Verletzung kennzeichnen). Im Gegensatz zu einem statischen Tool, das nur bekannte Muster kennzeichnet, kann ein LLM Argumente auf neuen Code anwenden und Probleme ableiten, die von einem Tool-Entwickler nicht explizit in den Code programmiert wurden.

• Natürliche Erklärungen: KI-Auditoren können menschenlesbare Erklärungen potenzieller Probleme liefern. Dies ist äußerst wertvoll für die Entwicklererfahrung. Traditionelle Tools geben oft kryptische Warnungen aus, die Fachwissen zur Interpretation erfordern, während ein GPT-basiertes Tool einen Absatz generieren kann, der den Bug in einfachem Deutsch erklärt und sogar eine Behebung vorschlägt. AuditGPT kennzeichnete zum Beispiel nicht nur ERC-Regelverletzungen, sondern beschrieb auch, warum der Code die Regel verletzte und welche Auswirkungen dies hatte. Dies hilft, weniger erfahrene Entwickler in Sicherheitskonzepte einzuführen.

• Flexibilität: Mit Prompt Engineering können LLMs angewiesen werden, sich auf verschiedene Aspekte zu konzentrieren oder benutzerdefinierten Sicherheitsrichtlinien zu folgen. Sie sind nicht durch einen festen Regelsatz begrenzt – wenn Sie eine Eigenschaft oder ein Muster in Worten beschreiben können, kann das LLM versuchen, es zu überprüfen. Dies macht sie attraktiv für die Prüfung neuer Protokolle, die einzigartige Invarianten oder Logik aufweisen könnten (wo das Schreiben einer benutzerdefinierten statischen Analyse von Grund auf undurchführbar wäre).

Es wurden jedoch erhebliche Herausforderungen und Zuverlässigkeitsprobleme beobachtet:

• Einschränkungen des Denkvermögens: Aktuelle LLMs haben manchmal Schwierigkeiten mit der komplexen logischen Argumentation, die für die Sicherheitsanalyse erforderlich ist. Trail of Bits berichtete, dass „die Modelle nicht gut über bestimmte höherrangige Konzepte wie den Besitz von Contracts, Reentrancy und Beziehungen zwischen Funktionen nachdenken können“. Zum Beispiel könnte GPT-3.5/4 theoretisch verstehen, was Reentrancy ist (und es sogar erklären), aber es könnte eine Reentrancy-Schwachstelle nicht erkennen, wenn dies das Verständnis einer funktionsübergreifenden Abfolge von Aufrufen und Zustandsänderungen erfordert. Das Modell könnte auch Schwachstellen übersehen, die Multi-Contract-Interaktionen oder zeitabhängige Logik betreffen, da diese über den Umfang einer einzelnen Code-Snippet-Analyse hinausgehen.

• False Positives und Halluzinationen: Eine große Sorge ist, dass LLMs selbstbewusst klingende, aber falsche Schlussfolgerungen produzieren können. Bei Audits könnte eine „Halluzination“ bedeuten, eine Schwachstelle zu kennzeichnen, die tatsächlich nicht existiert, oder den Code falsch zu interpretieren. Das Experiment von Trail of Bits mit Codex (GPT) ergab, dass mit der Skalierung auf größere reale Contracts „die Raten für False Positives und Halluzinationen zu hoch wurden“, bis zu dem Punkt, dass es Auditoren mit zu vielen falschen Berichten verlangsamen würde. Diese Unvorhersehbarkeit ist problematisch – ein Tool, das zu oft „Wolf!“ ruft, wird von Entwicklern nicht vertraut werden. Der Erfolg von AuditGPT, False Positives niedrig zu halten (nur 18 von Hunderten von Funden), ist ermutigend, aber dies geschah in einem eingeschränkten Bereich. Im allgemeinen Gebrauch sind sorgfältiges Prompt-Design und möglicherweise menschliche Überprüfungsschleifen erforderlich, um KI-Ergebnisse zu filtern.

• Kontextbeschränkungen: LLMs haben eine Kontextfensterbeschränkung, was bedeutet, dass sie nur eine bestimmte Menge Code gleichzeitig „sehen“ können. Komplexe Contracts erstrecken sich oft über mehrere Dateien und Tausende von Zeilen. Wenn eine KI nicht die gesamte Codebasis aufnehmen kann, könnte sie wichtige Verbindungen übersehen. Techniken wie Code-Slicing (den Contract in Chunks füttern) werden verwendet, bergen aber das Risiko, das Gesamtbild zu verlieren. Das LLM-SmartAudit-Team stellte fest, dass sie mit der 4k-Token-Grenze von GPT-3.5 einige große reale Contracts nicht analysieren konnten, bis sie zu GPT-4 mit einem größeren Kontext wechselten. Selbst dann kann die Aufteilung der Analyse in Teile dazu führen, dass Bugs übersehen werden, die sich nur bei Betrachtung des Systems als Ganzes manifestieren. Dies macht die KI-Analyse ganzer Protokolle (mit mehreren interagierenden Contracts) derzeit zu einer echten Herausforderung.

• Integration und Tooling: Es mangelt an robusten Entwickler-Tools rund um KI-Auditoren. Eine LLM-Analyse durchzuführen ist nicht so einfach wie das Ausführen eines Linters. Es beinhaltet API-Aufrufe an ein Modell, die Handhabung von Prompt Engineering, Ratenbegrenzungen und das Parsen der KI-Antworten. „Das Software-Ökosystem rund um die Integration von LLMs mit traditioneller Software ist zu rudimentär und alles ist umständlich“, wie es ein Audit-Team formulierte. Es gibt praktisch keine vorgefertigten Frameworks für die kontinuierliche Bereitstellung eines KI-Auditors in CI-Pipelines, während dessen Unsicherheiten verwaltet werden. Dies verbessert sich langsam (einige Projekte erforschen CI-Bots, die GPT-4 für Code-Reviews verwenden), aber es ist noch früh. Darüber hinaus ist es schwierig, zu debuggen, warum eine KI ein bestimmtes Ergebnis geliefert hat – im Gegensatz zu deterministischen Tools kann man die Logik, die das Modell dazu veranlasst hat, etwas zu kennzeichnen oder zu übersehen, nicht einfach nachvollziehen.

• Kosten und Performance: Die Verwendung großer Modelle wie GPT-4 ist teuer und kann langsam sein. Wenn Sie einen KI-Audit in eine CI/CD-Pipeline integrieren möchten, könnte dies mehrere Minuten pro Contract hinzufügen und erhebliche API-Kosten für großen Code verursachen. Feinabgestimmte Modelle oder Open-Source-LLMs könnten die Kosten mindern, sind aber tendenziell weniger leistungsfähig als GPT-4. Es gibt laufende Forschung zu kleineren, spezialisierten Modellen für Codesicherheit, aber derzeit stammen die besten Ergebnisse von den großen proprietären Modellen.

Zusammenfassend lässt sich sagen: LLM-gestützte Audits sind vielversprechend, aber keine Patentlösung. Wir sehen hybride Ansätze, bei denen KI hilft, Tests zu generieren oder spezifische Aspekte zu analysieren, anstatt den gesamten Audit von Anfang bis Ende durchzuführen. Zum Beispiel könnte eine KI potenzielle Invarianten oder riskante Bereiche vorschlagen, die dann ein Mensch oder ein anderes Tool untersucht. Wie ein Sicherheitsingenieur bemerkte, ist die Technologie noch nicht bereit, menschliche Auditoren für kritische Aufgaben zu ersetzen, angesichts der Argumentationslücken und Integrationshürden. Es kann jedoch bereits ein nützlicher Assistent sein – „etwas Unvollkommenes kann viel besser sein als nichts“ in Fällen, in denen traditionelle Tools versagen.

Genauigkeit und Zuverlässigkeit verschiedener Toolchains​

Es ist aufschlussreich, die Genauigkeit, Abdeckung und Zuverlässigkeit der verschiedenen besprochenen Audit-Ansätze zu vergleichen. Nachfolgend finden Sie eine Zusammenfassung der Ergebnisse aus Forschungs- und Industrieauswertungen:

• Statische Analyse-Tools: Statische Analysatoren wie Slither werden für schnelles Feedback und Benutzerfreundlichkeit geschätzt. Sie haben typischerweise eine hohe Präzision, aber einen moderaten Recall – das bedeutet, dass die meisten der von ihnen gemeldeten Probleme echte Probleme sind (wenige False Positives per Design), aber sie erkennen nur bestimmte Klassen von Schwachstellen. Eine Benchmarking-Studie aus dem Jahr 2024 (LLM-SmartAudits RQ1) ergab, dass Slither etwa 46 % der bekannten Schwachstellen in einer Testsuite aufdeckte. Mythril (symbolische Ausführung) schnitt mit 54 % Recall etwas besser ab. Jedes Tool hatte Stärken bei bestimmten Bug-Typen (z. B. ist Slither sehr gut darin, arithmetische Probleme oder die Verwendung von tx.origin zu erkennen, während symbolische Tools hervorragend darin sind, einfache Reentrancy-Szenarien zu finden), aber keines hatte eine umfassende Abdeckung. False Positives für ausgereifte Tools wie Slither sind relativ gering – seine Entwickler werben mit „minimalen Fehlalarmen und schneller Ausführung (unter 1s pro Contract)“, was es für den CI-Einsatz geeignet macht. Dennoch können statische Tools fehlerhaft sein, wenn der Code komplexe Muster verwendet; sie könnten Edge Cases kennzeichnen, die tatsächlich behandelt werden, oder tiefe Logik-Bugs übersehen, die keinem bekannten Anti-Pattern entsprechen.

• Fuzzing und Eigenschaftstests: Fuzzer wie Foundrys Fuzz-/Invarianten-Tests oder Trail of Bits’ Echidna haben sich als sehr effektiv erwiesen, um Laufzeitfehler und Invariantenverletzungen zu finden. Diese Tools neigen dazu, nahezu null False Positives zu haben, in dem Sinne, dass, wenn ein Bug gemeldet wird (eine Assertion fehlgeschlagen ist), es sich um eine echte Gegenbeispielausführung handelt. Der Kompromiss liegt in den False Negatives – wenn sich ein Bug nicht innerhalb des getesteten Input-Raums oder der Anzahl der Läufe manifestiert, kann er übersehen werden. Die Abdeckung hängt davon ab, wie gut der Fuzzer den Zustandsraum erforscht. Mit genügend Zeit und guten Heuristiken haben Fuzzer viele schwerwiegende Bugs gefunden, die die statische Analyse übersehen hat. Zum Beispiel konnte Echidna die MakerDAO- und Compound-Bugs schnell reproduzieren, deren Auffindung formale Verifikationsbemühungen erforderte. Fuzzing garantiert jedoch nicht, jeden Logikfehler zu finden. Wenn Contracts komplexer werden, erfordern Fuzzer möglicherweise das Schreiben zusätzlicher Invarianten oder die Verwendung intelligenterer Suchstrategien, um tiefere Zustände zu erreichen. In Bezug auf Metriken hat Fuzzing keine einzelne „Recall“-Zahl, aber anekdotische Beweise zeigen, dass wichtige Invarianten normalerweise von einem Fuzzer gebrochen werden können, wenn sie brechbar sind. Die Zuverlässigkeit ist hoch für das, was es findet (keine manuelle Triage für Fehlermeldungen erforderlich), aber man muss bedenken, dass ein bestandener Fuzz-Test kein Korrektheitsbeweis ist – nur eine Erhöhung des Vertrauens.

• Formale Verifikationstools: Wo anwendbar, bietet formale Verifikation die höchste Sicherheit – ein erfolgreicher Beweis bedeutet, dass 100 % der Zustände die Eigenschaft erfüllen. In Bezug auf die Genauigkeit ist es für die Eigenschaften, die es beweisen kann, effektiv perfekt (sound und vollständig). Das größte Problem hier ist nicht die Genauigkeit der Ergebnisse, sondern die Schwierigkeit der Anwendung und der enge Anwendungsbereich. Formale Tools können in der Praxis auch False Negatives aufweisen: Sie könnten einfach nicht in der Lage sein, eine wahre Eigenschaft aufgrund von Komplexität zu beweisen (was kein Ergebnis oder einen Timeout liefert, was kein False Positive ist, aber es bedeutet, dass wir etwas nicht verifizieren können, das tatsächlich sicher ist). Sie können auch Spezifikationsfehler aufweisen, bei denen das Tool etwas „beweist“, das nicht die von Ihnen beabsichtigte Eigenschaft war (Benutzerfehler). Bei realen Audits haben formale Methoden einige kritische Bugs aufgedeckt (zu Certoras Erfolgen gehören das Aufdecken eines subtilen SushiSwap-Bugs und eines PRBMath-Bibliotheksproblems vor der Bereitstellung). Ihre Erfolgsbilanz ist jedoch dadurch begrenzt, wie selten sie umfassend angewendet werden – wie Trail of Bits feststellte, war es „schwierig, öffentliche Probleme zu finden, die ausschließlich durch formale Verifikation entdeckt wurden, im Gegensatz zu den vielen Bugs, die durch Fuzzing gefunden wurden“. Obwohl formale Verifikation bei Erfolg äußerst zuverlässig ist, ist ihr Einfluss auf die gesamte Toolchain-Abdeckung durch den erforderlichen Aufwand und das Fachwissen begrenzt.

• LLM-basierte Analyse: Die Genauigkeit von KI-Auditoren ist derzeit ein sich ständig änderndes Ziel, da neue Techniken (und neuere Modelle) die Grenzen schnell verschieben. Wir können einige Datenpunkte entnehmen:

  • Das AuditGPT-System, das sich auf ERC-Regeln konzentrierte, erreichte eine sehr hohe Präzision (≈96 % nach False-Positive-Anzahl) und fand Hunderte von Problemen, die statische Tools oder Menschen übersehen hatten. Dies geschah jedoch in einem engen Bereich mit strukturierten Prompts. Wir sollten nicht verallgemeinern, dass ChatGPT bei der willkürlichen Schwachstellensuche zu 96 % genau sein wird – außerhalb einer kontrollierten Umgebung ist seine Leistung geringer.
  • Bei der breiteren Schwachstellenerkennung zeigte LLM-SmartAudit (GPT-3.5) einen Recall von ~74 % auf einem Benchmark mit moderater False-Positive-Rate, was besser ist als jedes einzelne traditionelle Tool. Als es auf GPT-4 mit spezialisiertem Prompting (TA-Modus) aufgerüstet wurde, verbesserte es sich erheblich – zum Beispiel fand der GPT-4-Agent bei einem Satz von 1.400 realen Schwachstellen ~48 % der spezifischen Probleme und ~47 % der komplexen Logikprobleme, während Slither/Mythril/Conkas jeweils ~0 % (keine) dieser speziellen komplexen Probleme fanden. Dies zeigt, dass LLMs die Abdeckung dramatisch auf Bug-Typen erweitern können, die die statische Analyse vollständig übersieht. Andererseits fand das LLM nicht über die Hälfte der Probleme (es hat also auch erhebliche False Negatives), und es ist nicht klar, wie viele False Positives unter den gemeldeten waren – die Studie konzentrierte sich mehr auf Recall als auf Präzision.
  • Das Codex/GPT-4 „Toucan“-Experiment von Trail of Bits veranschaulicht Zuverlässigkeitsprobleme. Anfangs konnte Codex bei kleinen Beispielen bekannte Schwachstellen (Eigentumsprobleme, Reentrancy) mit sorgfältigem Prompting identifizieren. Sobald sie jedoch versuchten, zu skalieren, stießen sie auf inkonsistente und falsche Ergebnisse. Sie berichteten, dass „die Anzahl der Fehler selbst in durchschnittlich großem Code hoch war“ und schwer vorherzusagen. Letztendlich kamen sie zu dem Schluss, dass GPT-4 (Anfang 2023) nur eine inkrementelle Verbesserung darstellte und immer noch „Schlüsselfunktionen fehlten“ wie die Argumentation über funktionsübergreifende Abläufe. Das Ergebnis war, dass die KI die False Positives ihrer statischen Tools nicht wesentlich reduzierte, noch beschleunigte sie zuverlässig ihren Audit-Workflow. Mit anderen Worten, die aktuelle Zuverlässigkeit eines allgemeinen LLM als Auditor wurde von professionellen Auditoren in diesem Test als unzureichend befunden.

Zusammenfassend lässt sich sagen, dass jede Toolchain unterschiedliche Stärken hat:

• Statische Tools: Zuverlässig für die schnelle Erkennung bekannter Probleme; geringes Rauschen, aber begrenzte Bug-Typen (mittlerer Recall ~40–50 % bei Benchmarks).
• Fuzz-/Invarianten-Testing: Sehr hohe Präzision (fast keine Fehlalarme) und stark beim Auffinden von funktionalen und zustandsabhängigen Bugs; die Abdeckung kann breit sein, ist aber nicht garantiert (keine einfache Metrik, hängt von Zeit und Invariantenqualität ab). Findet oft dieselben Bugs, die formale Beweise finden würden, wenn genügend Anleitung gegeben wird.
• Formale Verifikation: Goldstandard für absolute Korrektheit bei spezifischen Eigenschaften; im Wesentlichen 100 % Recall/Präzision für diese Eigenschaften, wenn erfolgreich angewendet. Aber praktisch auf enge Probleme beschränkt und erfordert erheblichen Aufwand (noch keine Ein-Knopf-Lösung für vollständige Audits).
• KI (LLM)-Analyse: Potenziell hohe Abdeckung – kann Bugs in verschiedenen Kategorien finden, einschließlich derer, die von anderen Tools übersehen wurden – aber variable Präzision. Mit spezialisierten Setups kann sie sowohl präzise als auch breit sein (wie AuditGPT für ERC-Prüfungen zeigte). Ohne sorgfältige Einschränkungen kann sie ein weites Netz werfen und eine menschliche Überprüfung der Ergebnisse erfordern. Die „durchschnittliche“ Genauigkeit von ChatGPT bei der Schwachstellenerkennung ist nicht spektakulär (nahezu Raten, in einer Studie), aber die besten entwickelten Systeme, die LLMs verwenden, treiben die Leistung über traditionelle Tools hinaus. Es gibt aktive Forschung, um KI-Outputs vertrauenswürdiger zu machen (z. B. durch die gegenseitige Überprüfung mehrerer Agenten oder die Kombination von LLM mit statischer Argumentation, um KI-Schlussfolgerungen zu überprüfen).

Es ist erwähnenswert, dass die Kombination von Ansätzen die besten Ergebnisse liefert. Zum Beispiel könnte man Slither ausführen (um offensichtliche Probleme ohne Rauschen zu finden), dann Foundry/Echidna verwenden, um tiefere Verhaltensweisen zu fuzzing, und vielleicht ein LLM-basiertes Tool verwenden, um nach Mustern oder Invarianten zu suchen, die nicht berücksichtigt wurden. Jedes wird unterschiedliche blinde Flecken der anderen abdecken.

Herausforderungen und Einschränkungen der realen Adoption​

In der Praxis bringt die Einführung formaler Verifikations- oder KI-Tools in einem Entwicklungs-Workflow pragmatische Herausforderungen mit sich. Einige Schlüsselprobleme sind:

• Entwicklererfahrung und Fachwissen: Traditionelle formale Verifikation hat eine steile Lernkurve. Das Schreiben formaler Spezifikationen (in CVL, Coq, Moves Spezifikationssprache usw.) ähnelt eher dem Schreiben mathematischer Beweise als dem Schreiben von Code. Vielen Entwicklern fehlt dieser Hintergrund, und Experten für formale Methoden sind Mangelware. Im Gegensatz dazu ist Fuzzing mit Foundry oder das Schreiben von Invarianten in Solidity viel zugänglicher – es fühlt sich an wie das Schreiben zusätzlicher Tests. Dies ist ein wichtiger Grund, warum Fuzz-Testing in der Ethereum-Community eine schnellere Akzeptanz gefunden hat als formale Beweise. Das Trail of Bits-Team stellte explizit fest, dass Fuzzing „ähnliche Ergebnisse liefert, aber in vielen Fällen deutlich weniger Geschick und Zeit erfordert“ als formale Methoden. Obwohl formale Verifikation unterschiedliche Bugs aufdecken kann, entscheiden sich viele Teams daher für den einfacheren Ansatz, der mit geringerem Aufwand ausreichend gute Ergebnisse liefert.

• Integration in den Entwicklungs-Workflow: Damit ein Tool weit verbreitet ist, muss es in CI/CD-Pipelines und den täglichen Coding-Alltag passen. Tools wie Slither glänzen hier – es „integriert sich leicht in CI/CD-Setups, optimiert die Automatisierung und unterstützt Entwickler.“ Ein Entwickler kann Slither oder Mythril zu einer GitHub Action hinzufügen und den Build fehlschlagen lassen, wenn Probleme gefunden werden. Foundrys Fuzz-Tests können jedes Mal als Teil von forge test ausgeführt werden. Invarianten-Tests können sogar kontinuierlich in der Cloud mit Tools wie CloudExec ausgeführt werden, und jeder Fehler kann automatisch mit fuzz-utils in einen Unit-Test umgewandelt werden. Diese Integrationen bedeuten, dass Entwickler schnelles Feedback erhalten und iterieren können. Im Gegensatz dazu wurde etwas wie der Certora Prover historisch als separater Prozess (oder von einem externen Audit-Team) ausgeführt und konnte Stunden dauern, um ein Ergebnis zu liefern – nichts, was man bei jedem Commit ausführen würde. KI-basierte Tools stehen ebenfalls vor Integrationshürden: Das Aufrufen einer API und die deterministische Handhabung ihrer Ausgabe in CI ist nicht trivial. Es gibt auch die Frage der Sicherheit und des Datenschutzes – viele Organisationen sind beunruhigt darüber, proprietären Contract-Code zur Analyse an einen Drittanbieter-KI-Dienst zu senden. Selbst gehostete LLM-Lösungen sind noch nicht so leistungsfähig wie die großen Cloud-APIs, daher ist dies ein Knackpunkt für die CI-Einführung von KI-Auditoren.

• False Positives und Rauschen: Ein Tool, das viele False Positives oder geringfügige Befunde meldet, kann das Vertrauen der Entwickler verringern. Statische Analysatoren hatten in der Vergangenheit damit zu kämpfen – z. B. überfluteten frühe Versionen einiger Tools Benutzer mit Warnungen, von denen viele irrelevant waren. Das Gleichgewicht zwischen Signal und Rauschen ist entscheidend. Slither wird für minimale Fehlalarme gelobt, während ein Tool wie Securify (in seiner Forschungsform) oft viele Warnungen produzierte, die eine manuelle Filterung erforderten. LLMs können, wie besprochen, Rauschen erzeugen, wenn sie nicht richtig ausgerichtet sind. Deshalb werden KI-Vorschläge derzeit meist als beratend und nicht als absolut angesehen. Teams werden ein rauschbehaftetes Tool eher übernehmen, wenn es von einem separaten Sicherheitsteam oder im Rahmen eines Audits betrieben wird, aber für den täglichen Gebrauch bevorzugen Entwickler Tools, die klare, umsetzbare Ergebnisse mit geringem Rauschen liefern. Das Ideal ist, den „Build fehlschlagen zu lassen“ nur bei definitiven Bugs, nicht bei Hypothesen. Diese Zuverlässigkeit zu erreichen, ist eine ständige Herausforderung, insbesondere für KI-Tools.

• Skalierbarkeit und Performance: Formale Verifikation kann rechenintensiv sein. Wie bereits erwähnt, könnten Solver bei komplexen Contracts in einen Timeout laufen. Dies erschwert die Skalierung auf große Systeme. Wenn die Verifikation einer Eigenschaft Stunden dauert, werden Sie nicht Dutzende von Eigenschaften bei jeder Codeänderung überprüfen. Fuzz-Testing stößt ebenfalls an Skalierbarkeitsgrenzen – das Erforschen eines riesigen Zustandsraums oder eines Contracts mit vielen Methoden kombinatorisch kann langsam sein (obwohl Fuzzer in der Praxis im Hintergrund oder über Nacht laufen können, um ihre Suche zu vertiefen). KI-Modelle haben feste Kontextgrößen, und die Erhöhung der Kapazität eines Modells ist teuer. Während der 128k-Token-Kontext von GPT-4 ein Segen ist, ist das Füttern mit Hunderten von Kilobytes an Contract-Code kostspielig und immer noch nicht ausreichend für sehr große Projekte (stellen Sie sich ein komplexes Protokoll mit vielen Contracts vor – Sie könnten diese Grenze überschreiten). Es gibt auch die Multi-Chain-Skalierung: Wenn Ihr Projekt Interaktionen zwischen Contracts auf verschiedenen Chains (Ethereum ↔ einer anderen Chain) beinhaltet, ist die Verifikation oder Analyse dieser Cross-Chain-Logik noch komplexer und wahrscheinlich jenseits der aktuellen Tools.

• Menschliche Aufsicht und Verifikation: Letztendlich verlassen sich die meisten Teams immer noch auf erfahrene menschliche Auditoren für die endgültige Freigabe. Automatisierte Tools sind Hilfsmittel, keine Ersatzmittel. Eine Einschränkung all dieser Tools ist, dass sie innerhalb der Grenzen bekannter Eigenschaften oder Muster operieren. Sie könnten einen völlig neuartigen Bug oder einen subtilen ökonomischen Fehler im Design eines DeFi-Protokolls übersehen. Menschliche Auditoren nutzen Intuition und Erfahrung, um zu überlegen, wie ein Angreifer das System angehen könnte, manchmal auf Weisen, die kein Tool explizit programmiert ist. Es gab Fälle, in denen Contracts alle automatisierten Prüfungen bestanden, aber ein Mensch später eine Schwachstelle in der Geschäftslogik oder einen kreativen Angriffsvektor fand. Eine Herausforderung besteht also darin, ein falsches Sicherheitsgefühl zu vermeiden – Entwickler müssen die Ausgabe formaler Tools und KI korrekt interpretieren und nicht annehmen, dass „keine Probleme gefunden“ bedeutet, dass der Code 100 % sicher ist.

• Pflege von Spezifikationen und Tests: Insbesondere bei der formalen Verifikation ist ein praktisches Problem die Spezifikationsdrift. Die Spezifikation (Invarianten, Regeln usw.) könnte veraltet werden, wenn sich der Code entwickelt. Sicherzustellen, dass der Code und seine formale Spezifikation synchron bleiben, ist eine nicht-triviale Managementaufgabe. Wenn Entwickler nicht wachsam sind, könnten die Beweise „bestehen“, einfach weil sie etwas beweisen, das für die tatsächlichen Anforderungen des Codes nicht mehr relevant ist. Ähnlich müssen Invarianten-Tests aktualisiert werden, wenn sich das erwartete Verhalten des Systems ändert. Dies erfordert eine Kultur der invarianten-getriebenen Entwicklung, die nicht alle Teams haben (obwohl es Bestrebungen gibt, diese zu fördern).

Zusammenfassend sind die Hauptbeschränkungen Menschen und Prozesse und nicht die reine Leistungsfähigkeit der Technologie. Formale und KI-gestützte Methoden können die Sicherheit erheblich verbessern, müssen aber so eingesetzt werden, dass sie zu den Workflows und Fähigkeiten der Entwickler passen. Erfreulicherweise gewinnen Trends wie die invarianten-getriebene Entwicklung (das Aufschreiben kritischer Invarianten von Anfang an) an Bedeutung, und die Tools verbessern sich langsam, um fortgeschrittene Analysen einfacher zu machen. Die Open-Sourcing großer Tools (z. B. Certora Prover) und die Integration von Fuzzing in beliebte Frameworks (Foundry) senken die Hürden. Im Laufe der Zeit erwarten wir, dass sich die Lücke zwischen dem, was „ein durchschnittlicher Entwickler“ tun kann, und dem, was „ein promovierter Forscher“ tun kann, in Bezug auf die Verwendung dieser leistungsstarken Verifikationstechniken verringern wird.

Open-Source vs. kommerzielle Audit-Tools​

Die Landschaft der Smart-Contract-Sicherheitstools umfasst sowohl Open-Source-Projekte als auch kommerzielle Dienste. Jeder hat seine Rolle, und oft ergänzen sie sich gegenseitig:

• Open-Source-Tools: Die Mehrheit der weit verbreiteten Audit-Tools im Ethereum-Ökosystem ist Open-Source. Dazu gehören Slither (statischer Analysator), Mythril (symbolische Ausführung), Echidna (Fuzzer), Manticore (symbolische/konkolische Ausführung), Securify (Analysator der ETH Zürich), Solhint/Ethlint (Linter) und natürlich Foundry selbst. Open-Source-Tools werden aus mehreren Gründen bevorzugt: (1) Transparenz – Entwickler können sehen, wie das Tool funktioniert und darauf vertrauen, dass nichts Bösartiges oder Verborgenes geschieht (wichtig in einem offenen Ökosystem). (2) Community-Beitrag – Regeln und Funktionen werden von einer breiten Community hinzugefügt (Slither hat zum Beispiel viele von der Community beigesteuerte Detektoren). (3) Kosten – sie sind kostenlos nutzbar, was für die vielen kleinen Projekte/Startups in Web3 wichtig ist. (4) Integration – offene Tools können in der Regel lokal oder in CI ohne rechtliche Hürden ausgeführt werden, und oft können sie für projektspezifische Anforderungen angepasst oder gescriptet werden.

  Open-Source-Tools haben sich schnell weiterentwickelt. Zum Beispiel wird Slithers Unterstützung für neue Solidity-Versionen und -Muster kontinuierlich von Trail of Bits aktualisiert. Mythril, entwickelt von ConsenSys, kann nicht nur Ethereum, sondern jede EVM-kompatible Chain durch die Arbeit am Bytecode analysieren – was zeigt, wie offene Tools leicht über Chains hinweg wiederverwendet werden können. Viele DeFi-Projekte auf diesen Chains führen Slither und Echidna genauso aus wie ein Ethereum-Projekt. Die Audits von Protokollen auf BSC oder Avalanche verwenden typischerweise das identische Toolkit wie Ethereum-Audits. Cross-Chain im EVM-Kontext bedeutet also meistens die Wiederverwendung von Ethereums Toolchain. Der Nachteil von Open-Source-Tools ist, dass sie oft mit „Nutzung auf eigenes Risiko“ einhergehen – ohne offiziellen Support oder Garantien. Sie skalieren möglicherweise nicht oder haben nicht den Feinschliff der Benutzeroberfläche eines kommerziellen Produkts. Aber in der Blockchain verwenden selbst viele Unternehmen Open-Source als ihre internen Kern-Tools (manchmal mit geringfügigen benutzerdefinierten Modifikationen).

• Kommerzielle Dienste und Tools: Einige Unternehmen haben Sicherheitsanalysen als Produkt angeboten. Beispiele sind MythX (eine Cloud-basierte Scanning-API von ConsenSys Diligence), Certora (das seinen Prover als Dienst anbot, bevor es ihn Open-Source stellte), CertiK und SlowMist (Firmen, die interne Scanner und KI haben, die sie in Audits verwenden oder über Dashboards anbieten), und einige neuere Anbieter wie Securify von ChainSecurity (das Unternehmen wurde übernommen und sein Tool intern verwendet) oder SolidityScan (ein Cloud-Scanner, der einen Audit-Bericht ausgibt). Kommerzielle Tools zielen oft darauf ab, eine benutzerfreundlichere Erfahrung oder einen integrierten Dienst zu bieten. Zum Beispiel integrierte sich MythX mit IDE-Erweiterungen und CI-Plugins, sodass Entwickler ihre Contracts an MythX senden und einen detaillierten Bericht zurückerhalten konnten, einschließlich eines Schwachstellen-Scores und Details zur Behebung von Problemen. Diese Dienste führen typischerweise eine Kombination von Analysetechniken im Hintergrund aus (Mustererkennung, symbolische Ausführung usw.), die darauf abgestimmt sind, False Positives zu minimieren.

  Das Wertversprechen kommerzieller Tools ist in der Regel Bequemlichkeit und Support. Sie pflegen möglicherweise eine kontinuierlich aktualisierte Wissensdatenbank über Schwachstellen und bieten Kundensupport bei der Interpretation der Ergebnisse. Sie könnten auch rechenintensive Aufgaben in der Cloud übernehmen (sodass Sie keinen Solver lokal ausführen müssen). Kosten sind jedoch ein Faktor – viele Projekte entscheiden sich angesichts der Verfügbarkeit kostenloser Alternativen dafür, diese Dienste nicht zu bezahlen. Darüber hinaus zögern einige Entwickler im Geiste der Dezentralisierung, sich bei der Sicherheit auf Closed-Source-Dienste zu verlassen (das „verify, don’t trust“-Ethos). Die Open-Sourcing des Certora Provers im Jahr 2025 ist ein bemerkenswertes Ereignis: Es verwandelte ein High-End-Kommerztool in eine Community-Ressource. Dieser Schritt wird voraussichtlich die Akzeptanz beschleunigen, da nun jeder versuchen kann, seine Contracts ohne kostenpflichtige Lizenz formal zu verifizieren, und die Offenheit des Codes es Forschern ermöglichen wird, das Tool zu verbessern oder an andere Chains anzupassen.

• Menschliche Audit-Dienste: Es ist erwähnenswert, dass über Software-Tools hinaus viele Audits von professionellen Firmen (Trail of Bits, OpenZeppelin, Certik, PeckShield usw.) durchgeführt werden. Diese Firmen verwenden eine Mischung aus den oben genannten Tools (meist Open-Source) und proprietären Skripten. Die Ergebnisse dieser Bemühungen werden oft privat gehalten oder nur in Audit-Berichten zusammengefasst. Es gibt hier keine genaue „Open-Source vs. kommerziell“-Dichotomie, da selbst kommerzielle Audit-Firmen stark auf Open-Source-Tools angewiesen sind. Die Differenzierung liegt eher in Fachwissen und manuellem Aufwand. Dennoch entwickeln einige Firmen proprietäre KI-gestützte Audit-Plattformen, um sich einen Vorteil zu verschaffen (zum Beispiel gab es Berichte über die Verwendung von „ChainGPT“ für interne Audits oder CertiK, das eine KI namens Skynet für das On-Chain-Monitoring entwickelt). Diese sind per se keine öffentlichen Tools, daher sind ihre Genauigkeit und Methoden nicht weitgehend dokumentiert.

In der Praxis ist ein gängiges Muster Open-Source zuerst, kommerziell optional. Teams werden Open-Source-Tools während der Entwicklung und des Testens verwenden (weil sie diese leicht integrieren und so oft wie nötig ausführen können). Dann könnten sie einen oder zwei kommerzielle Dienste als zusätzliche Prüfung vor der Bereitstellung nutzen – zum Beispiel einen MythX-Scan durchführen, um eine „zweite Meinung“ einzuholen, oder eine Firma beauftragen, die fortschrittliche Tools wie Certora verwendet, um eine kritische Komponente formal zu verifizieren. Da die Grenzen verschwimmen (Certora Open Source, MythX-Ergebnisse oft mit Open-Source-Tools überlappend), geht es bei der Unterscheidung weniger um Leistungsfähigkeit als vielmehr um Support und Bequemlichkeit.

Ein bemerkenswerter Übergang ist Certoras Multi-Chain-Support – durch die formale Unterstützung von Solana und Stellar adressieren sie Plattformen, auf denen weniger offene Alternativen existieren (z. B. Ethereum hat viele offene Tools, Solana hatte bis vor kurzem fast keine). Wenn sich Sicherheitstools auf neue Ökosysteme ausweiten, könnten wir sehen, dass mehr kommerzielle Angebote Lücken füllen, zumindest bis Open-Source aufholt.

Schließlich ist anzumerken, dass Open-Source vs. kommerziell hier nicht antagonistisch ist; sie lernen oft voneinander. Zum Beispiel finden Techniken, die in akademischen/kommerziellen Tools (wie die in Securify verwendete abstrakte Interpretation) entwickelt wurden, schließlich ihren Weg in Open-Source-Tools, und umgekehrt können Daten aus der Nutzung von Open-Source-Tools Verbesserungen bei kommerziellen Tools leiten. Das von beiden Seiten angestrebte Endergebnis ist eine bessere Sicherheit für das gesamte Ökosystem.

Cross-Chain-Anwendbarkeit​

Während Ethereum der Schwerpunkt für die meisten dieser Tools war (angesichts seiner Dominanz bei Smart-Contract-Aktivitäten), sind die Konzepte der formalen Verifikation und KI-gestützter Audits auch auf andere Blockchain-Plattformen anwendbar. So lassen sie sich übertragen:

• EVM-kompatible Chains: Blockchains wie BSC, Polygon, Avalanche C-Chain usw., die die Ethereum Virtual Machine verwenden, können alle dieselben Tools direkt nutzen. Ein Fuzz-Test oder eine statische Analyse kümmert sich nicht darum, ob Ihr Contract auf dem Ethereum-Mainnet oder auf Polygon bereitgestellt wird – der Bytecode und die Quellsprache (Solidity/Vyper) sind dieselben. Tatsächlich können Mythril und Slither Contracts von jeder EVM-Chain analysieren, indem sie den Bytecode von einer Adresse abrufen (Mythril benötigt lediglich einen RPC-Endpunkt). Viele DeFi-Projekte auf diesen Chains führen Slither und Echidna genauso aus wie ein Ethereum-Projekt. Die Audits von Protokollen auf BSC oder Avalanche verwenden typischerweise das identische Toolkit wie Ethereum-Audits. Cross-Chain im EVM-Kontext bedeutet also meistens die Wiederverwendung von Ethereums Toolchain.

• Solana: Solanas Smart Contracts sind in Rust geschrieben (normalerweise über das Anchor-Framework) und laufen auf der BPF Virtual Machine. Dies ist eine sehr andere Umgebung als Ethereum, daher funktionieren Ethereum-spezifische Tools nicht sofort. Die gleichen Prinzipien gelten jedoch. Zum Beispiel kann man Fuzz-Testing an Solana-Programmen mit Rusts nativen Fuzzing-Bibliotheken oder Tools wie cargo-fuzz durchführen. Formale Verifikation auf Solana war bis vor kurzem fast nicht existent. Die Zusammenarbeit zwischen Certora und Solana-Ingenieuren führte zu einem internen Verifikationstool für Solana-Programme, das Rust/Anchor-Contracts gegen Spezifikationen beweisen kann. Wie erwähnt, erweiterte Certora seinen Prover auf Solanas VM, was bedeutet, dass Entwickler Regeln über das Verhalten von Solana-Programmen schreiben und diese überprüfen können, genau wie sie es für Solidity tun würden. Dies ist bedeutsam, da Solanas „Move-Fast“-Ansatz bedeutete, dass viele Contracts ohne die Art von rigorosen Tests gestartet wurden, die in Ethereum zu sehen sind; formale Tools könnten dies verbessern. KI-Audits für Solana sind ebenfalls plausibel – ein LLM, das Rust versteht, könnte aufgefordert werden, ein Solana-Programm auf Schwachstellen zu überprüfen (wie fehlende Eigentumsprüfungen oder arithmetische Fehler). Es könnte ein Fine-Tuning auf Solana-spezifische Muster erfordern, aber angesichts der Popularität von Rust ist GPT-4 ziemlich versiert im Lesen von Rust-Code. Wir könnten bald auch „ChatGPT für Anchor“-ähnliche Tools sehen.

• Polkadot und Substrate-basierte Chains: Polkadots Smart Contracts können in Rust (kompiliert zu WebAssembly) unter Verwendung des ink!-Frameworks geschrieben werden, oder man kann ein EVM-Pallet (wie es Moonbeam tut) ausführen, das wiederum Solidity ermöglicht. Im Fall von ink!/Wasm sind die Verifikationstools noch im Entstehen. Man könnte versuchen, die Eigenschaften eines Wasm-Contracts formal zu verifizieren, indem man allgemeine Wasm-Verifikations-Frameworks verwendet (zum Beispiel haben Microsofts Project Verona oder andere die Wasm-Sicherheit untersucht). Certoras Open-Source-Prover erwähnt auch die Unterstützung für Stellars WASM Smart Contracts, die konzeptionell jeder Wasm-basierten Chain ähneln. Es ist also wahrscheinlich auch auf Polkadots Wasm-Contracts anwendbar. Fuzz-Testing von ink!-Contracts kann durch das Schreiben von Rust-Tests erfolgen (Eigenschaftstests in Rust können eine ähnliche Rolle spielen). KI-Audits von ink!-Contracts würden ebenfalls die Analyse von Rust-Code beinhalten, was ein LLM mit dem richtigen Kontext wieder tun kann (obwohl es ohne einige Hinweise möglicherweise nichts über die spezifischen ink!-Makros oder Traits weiß).

  Zusätzlich erforscht Polkadot die Move-Sprache für die parallele Smart-Contract-Entwicklung (wie in einigen Community-Foren angedeutet). Wenn Move auf Polkadot-Parachains verwendet wird, kommt der Move Prover mit, der von Haus aus formale Verifikationsfähigkeiten mitbringt. Moves Betonung auf Sicherheit (ressourcenorientierte Programmierung) und der eingebaute Prover zeigen eine Cross-Chain-Verbreitung formaler Methoden von Anfang an.

• Andere Blockchains: Plattformen wie Tezos (Michelson Smart Contracts) und Algorand (TEAL-Programme) hatten jeweils formale Verifikationsbemühungen. Tezos hat zum Beispiel ein Tool namens Mi-Cho-Coq, das eine formale Semantik von Michelson bereitstellt und das Beweisen von Eigenschaften ermöglicht. Diese sind eher akademischer Natur, zeigen aber, dass jede Blockchain mit einer gut definierten Contract-Semantik einer formalen Verifikation unterzogen werden kann. KI-Audits könnten prinzipiell auf jede Programmiersprache angewendet werden – es ist eine Frage des angemessenen Trainings oder Promptings des LLM. Für weniger gebräuchliche Sprachen könnte ein LLM ein Fine-Tuning benötigen, um effektiv zu sein, da es möglicherweise nicht auf genügend Beispielen vortrainiert wurde.

• Cross-Chain-Interaktionen: Eine neuere Herausforderung ist die Verifikation von Interaktionen über Chains hinweg (wie Bridges oder Inter-Chain-Messaging). Formale Verifikation könnte hier die Modellierung des Zustands mehrerer Chains und des Kommunikationsprotokolls umfassen. Dies ist sehr komplex und übersteigt derzeit die meisten Tools, obwohl spezifische Bridge-Protokolle manuell auf Sicherheit analysiert wurden. KI könnte bei der Überprüfung von Cross-Chain-Code helfen (zum Beispiel die Überprüfung eines Solidity-Contracts, der mit einem IBC-Protokoll auf Cosmos interagiert), aber es gibt noch keine sofort einsatzbereite Lösung.

Im Wesentlichen hat Ethereums Tooling den Weg geebnet für andere Chains. Viele der Open-Source-Tools werden angepasst: z. B. gibt es Bemühungen, einen Slither-ähnlichen statischen Analysator für Solana (Rust) zu erstellen, und die Konzepte des Invarianten-Testings sind sprachunabhängig (eigenschaftsbasiertes Testen existiert in vielen Sprachen). Die Open-Sourcing leistungsstarker Engines (wie Certoras für mehrere VMs) ist besonders vielversprechend für die Cross-Chain-Sicherheit – dieselbe Plattform könnte verwendet werden, um einen Solidity-Contract, ein Solana-Programm und einen Move-Contract zu verifizieren, vorausgesetzt, jeder hat eine ordnungsgemäße Spezifikation. Dies fördert eine einheitlichere Sicherheitshaltung in der gesamten Branche.

Es ist auch erwähnenswert, dass KI-gestützte Audits allen Chains zugutekommen werden, da das Modell über Schwachstellen in jedem Kontext unterrichtet werden kann. Solange die KI mit den richtigen Informationen (Sprachspezifikationen, bekannte Bug-Muster in diesem Ökosystem) versorgt wird, kann sie ähnliche Argumentationen anwenden. Zum Beispiel könnte ChatGPT aufgefordert werden, einen Solidity-Contract oder ein Move-Modul mit dem entsprechenden Prompt zu prüfen, und es wird beides tun – es könnte sogar etwas wie „dieses Move-Modul könnte die Ressourcenerhaltung verletzen“ erkennen, wenn es dieses Konzept hat. Die Einschränkung ist, ob die KI genügend Trainingsdaten für diese Chain erhalten hat. Ethereum, als beliebteste, hat die Modelle wahrscheinlich dazu veranlasst, am besten in Solidity zu sein. Wenn andere Chains wachsen, könnten zukünftige LLMs oder feinabgestimmte Derivate diese ebenfalls abdecken.

Fazit​

Formale Verifikation von Smart Contracts und KI-gestützte Audits ist ein sich schnell entwickelndes Feld. Wir verfügen nun über ein reichhaltiges Toolkit: von deterministischen statischen Analysatoren und Fuzzing-Frameworks, die die Code-Zuverlässigkeit verbessern, bis hin zu modernster KI, die über Code auf menschenähnliche Weise nachdenken kann. Formale Verifikation, einst ein akademisches Nischengebiet, wird durch bessere Tools und Integration praktischer. KI hat trotz ihrer aktuellen Einschränkungen Ansätze von bahnbrechenden Fähigkeiten bei der Automatisierung der Sicherheitsanalyse gezeigt.

Es gibt noch keine Einheitslösung – reale Audits kombinieren mehrere Techniken, um eine mehrschichtige Verteidigung zu erreichen. Foundrys Fuzz- und Invarianten-Testing erhöhen bereits die Messlatte für das, was vor der Bereitstellung erwartet wird (viele Fehler werden abgefangen, die bei grundlegenden Tests durchrutschen würden). KI-gestützte Audits können, wenn sie sorgfältig eingesetzt werden, als Multiplikator für Auditoren wirken, indem sie Probleme hervorheben und die Compliance in einem Umfang und einer Geschwindigkeit überprüfen, die eine manuelle Überprüfung allein nicht erreichen kann. Menschliches Fachwissen bleibt jedoch entscheidend, um diese Tools zu steuern, ihre Ergebnisse zu interpretieren und die richtigen zu überprüfenden Eigenschaften zu definieren.

Zukünftig können wir eine stärkere Konvergenz dieser Ansätze erwarten. Zum Beispiel könnte KI helfen, formale Spezifikationen zu schreiben oder Invarianten vorzuschlagen („KI, welche Sicherheitseigenschaften sollten für diesen DeFi-Contract gelten?“). Fuzzing-Tools könnten KI integrieren, um die Input-Generierung intelligenter zu steuern (wie PromFuzz es tut). Formale Verifikations-Engines könnten maschinelles Lernen nutzen, um zu entscheiden, welche Lemmata oder Heuristiken angewendet werden sollen. All dies wird zu sichereren Smart Contracts beitragen, nicht nur auf Ethereum, sondern auf allen Blockchain-Plattformen. Die ultimative Vision ist eine Zukunft, in der kritische Smart Contracts mit hoher Zuversicht in ihre Korrektheit bereitgestellt werden können – ein Ziel, das wahrscheinlich durch den synergetischen Einsatz formaler Methoden und KI-Unterstützung erreicht wird, anstatt durch eines allein.

Quellen:

• Foundry Fuzzing und Invarianten-Testing Überblick
• Trail of Bits über Fuzzing vs. formale Verifikation
• Trail of Bits über Einschränkungen der formalen Verifikation
• Patrick Collins über Fuzz/Invarianten vs. formale Methoden
• Trail of Bits über Invarianten in Audits
• Medium (BuildBear) über Slither- und Mythril-Nutzung
• AuditGPT-Ergebnisse (ERC-Konformität)
• Trail of Bits über LLM (Codex/GPT-4) Einschränkungen
• LLM-SmartAudit-Performance vs. traditionelle Tools
• Studie „Detection Made Easy“ zur ChatGPT-Genauigkeit
• PromFuzz (LLM+Fuzz) Performance
• Certora Open-Source-Ankündigung (Multi-Chain)
• Move Prover Beschreibung (Aptos)
• Hintergrund zur statischen Analyse (Smart Contract Security Literatur)

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.