Gewinne:
- Fähigkeit, künstliche Intelligenz zu nutzen, um Frameworks, Tests und Review-Entwürfe auf Basis bewährter Bibliotheken (z. B. OpenZeppelin) zu erstellen und zu verstehen, dass Menschen die Produktionssicherheit garantieren
- Möglichkeit zur Überprüfung der Codeversion, des Musters und der Zugriffskontrolle, die durch künstliche Intelligenz durch Kompilierung, Tests und Testnetz erzeugt werden
- Zu erkennen, dass Kompilierung nicht bedeutet, sicher zu sein, und dass Testnetz und Prüfung unerlässlich sind.
Das Schreiben eines Smart Contracts unterscheidet sich von gewöhnlicher Software: Der Code, den Sie schreiben, ist öffentlich, unveränderlich und ein Programm, das direkt Geld bewegt. In dieser Einheit erfahren Sie, wie Sie KI als intelligenten Vertragsentwicklungsassistenten nutzen. Wir werden von der Entwurfserstellung bis zum Testschreiben, vom Musterrückruf bis zur Gasoptimierung (Transaktionsgebühr) lernen. Aber lassen Sie uns von Anfang an klar sein: KI produziert Blaupausen; Menschen sorgen für sicheren Code, der in die Produktion geht.
Grund zuerst: Sprache und Umwelt
Die gebräuchlichste intelligente Vertragssprache ist Solidity (die Sprache von Ethereum und EVM – Ethereum Virtual Machine, die virtuelle Maschine, auf der Verträge laufen – kompatible Ketten). Die Alternative ist Vyper (eine Python-ähnliche Sprache, die eingeschränkter und lesbarer sein soll). Ihr Code verbraucht Gas (die Kosten jeder Transaktion für die Blockchain); Ineffizienter Code ist teuer. Um eine genaue Ausgabe zu erhalten, ist es wichtig, diese Begriffe in dem Kontext klar zu halten, den Sie der KI geben.
Der größte Wert von KI liegt nicht darin, „von Grund auf neu zu schreiben“, sondern darin, das Framework + eine gute Form zu erstellen: ein standardkonformer Start, eine Blaupause, zu der Sie Ihr Fachwissen hinzufügen können.
Ebenen der Verwendung von KI beim Codieren
1. Skelette erzeugen. KI schürft schnell das Grundgerüst eines Standard-Tokens (ERC-20) oder NFTs (ERC-721 – ein einzigartiger Standard für digitale Vermögenswerte). Stellen Sie jedoch sicher, dass die KI eine bewährte Bibliothek verwendet: zum Beispiel OpenZeppelin (die vertrauenswürdige, geprüfte Standard-Vertragsbibliothek der Community). Die Regel besteht darin, den getesteten Block zu verwenden, anstatt die Sicherheit von Grund auf neu zu schreiben.
2. Funktionsbeschreibung und Überprüfung. Indem Sie der KI eine bestehende Funktion erklären, können Sie logische Fehler frühzeitig erkennen.
3. Testgenerierung. KI ist gut darin, Testfälle für Grenzfälle zu generieren: keine Eingabe, sehr große Zahl, nicht autorisierter Anrufer, wiederholter Anruf. Das erinnert einen an die Szenarien, die man überspringt.
4. Gas und Lesbarkeit. KI markiert teure Muster wie unnötige Speicherschreibvorgänge und schlägt Alternativen vor.
Hinweis: Weisen Sie die KI an, „auf den geprüften Verträgen von OpenZeppelin aufzubauen und die Sicherheit von Grund auf neu zu schreiben.“ Für eine KI ist es viel riskanter, Original-Sicherheitscode zu schreiben, als eine getestete Bibliothek zu verwenden.
Schwache Eingabeaufforderung / Starke Eingabeaufforderung
Schwache Eingabeaufforderung:
Schreiben Sie mir einen Token-Vertrag.
Diese Aufforderung ist gefährlich: Es ist nicht klar, welcher Standard, welche Kette, welche Bibliothek, welche Sicherheitsanforderung. Die KI generiert zufälligen, möglicherweise veralteten oder unsicheren Code.
Kraftvolle Aufforderung:
Ihre Rolle: leitender Solidity-Entwickler. Generieren Sie einen ERC-20-Token-Entwurf für eine EVM-kompatible Kette. Regeln:- Basierend auf den geprüften ERC20- und Ownable-Verträgen von OpenZeppelin.- Schreiben Sie die Solidity-Versions- und Lizenzzeile (SPDX) explizit.- Nur der Eigentümer hat die Erlaubnis zum Prägen; Fügen Sie eine Kappe gegen unendliches Drücken hinzu. - Fügen Sie jeder Funktion einen NatSpec-Kommentar hinzu. - Sicherheit von Grund auf neu schreiben; Verwenden Sie den Standardblock. - Fügen Sie am Ende eine Warnung hinzu: „Dies ist ein Entwurf; Prüfungen und Tests sind erforderlich.“ Markieren Sie die Bereiche, bei denen Sie sich nicht sicher sind, mit // TODO.
Unterschied: Eine starke Eingabeaufforderung gibt klare Rollen-, Standard-, Bibliotheks-, Sicherheitsgrenzen-, Dokumentations- und Validierungserwartungen an.
Vier kopierbare Vorlagen
1) Auf Standards basierendes Grundgerüst:
Ihre Rolle: Solidity-Entwickler. Generieren Sie ein [ERC-20 / ERC-721 / Staking]-Vertragsrahmenwerk basierend auf der von OpenZeppelin geprüften Bibliothek. Schreiben Sie eine SPDX-Lizenz und eine Pragma-Version. Fügen Sie jeder externen Funktion eine Zugriffskontrolle (wer kann anrufen) hinzu. Sicherheit neu erfinden; Verwenden Sie Standardblöcke. Dies ist ein Entwurf.
2) Funktionsüberprüfung:
Untersuchen Sie die folgende Funktion wie ein leitender Entwickler: Was macht sie, welche Zustände ändert sie, wer kann sie aufrufen? Markieren Sie mögliche Logikfehler und Sicherheitsrisiken als HYPOTHESE und verknüpfen Sie sie jeweils mit einer Zeile im Code. Sagen Sie nicht direkt „sicher“. Listen Sie einfach die Punkte auf, auf die Sie achten sollten.
3) Testszenario-Entwurf:
Schlagen Sie Testfälle für diesen Vertrag vor (könnte ein Entwurf für Foundry/Hardhat sein). Deckt insbesondere Grenzfälle ab: Nulleingabe, sehr große Anzahl, unbefugter Anruf, erneuter Anruf, unzureichende Mittel. Schreiben Sie, WAS jeder Test bestätigt.
4) Gas- und Lesbarkeitsüberprüfung:
Markieren Sie in diesem Vertrag die Muster, die die Gaskosten senken können: unnötiges Schreiben in den Speicher, externer Aufruf in der Schleife, sich wiederholende Berechnungen. Erklären Sie den Vorher-/Nachher-Unterschied in jedem Vorschlag. Empfehlen Sie sicherheitsrelevante Optimierungen; Wenn es nicht klar ist, sagen Sie „Fragen Sie den Prüfer“.
Drei Minikoffer (in Zahlen)
Fall 1 – Skeleton sparte 4 Stunden. Ein Team hat in 30 Minuten das Gerüst eines geprüften bibliotheksbasierten Vesting-Vertrags mit AI durchforstet; Es dauerte manuell ca. 4 Stunden. Das Team widmete sich der Sicherheit und dem Testen. Der Gewinn resultierte nicht aus der Übertragung von Sicherheit, sondern aus der Beschleunigung des langwierigen Rahmenwerks.
Fall 2 – Falle einer veralteten Version. Die KI hat ein Muster erstellt, das Roh-Ether per Transfer sendet, was nicht mehr empfohlen wird, da die Trainingsdaten veraltet sind. Der Entwickler bemerkte dies und änderte es auf das aktuelle aufrufbasierte und wiedereintrittsgeschützte Muster. Lektion: Es wird immer bestätigt, dass die Bibliothek/das Muster der KI auf dem neuesten Stand ist. AI weiß nichts über den Trainingsstichtag hinaus.
Fall 3 – Der Testentwurf hat einen versteckten Fehler entdeckt. Der von der KI erstellte „Unautorisierte Anrufer“-Test ergab, dass der Entwickler die Zugriffskontrolle in einer Funktion vergessen hatte. onlyOwner fehlt 1 Zeile, in 5 Minuten im Testnetz erwischt; Es könnte zu einem Geldverlust im Mainnet gekommen sein. Lektion: KI deckt beim Testen den blinden Fleck des Menschen ab.
Erinnern Sie sich an Sicherheitsmuster mit KI
KI ist gut darin, Sie wie eine Checkliste an bekannte Schwachstellenmuster zu erinnern. Die häufigsten Muster:
- Wiedereintritt: Einen externen Anruf tätigen, ohne den Status zu aktualisieren. Lösung: Checks-Effects-Interactions-Reihenfolge, Wiedereintrittsschutz.
- Fehlende Zugriffskontrolle: Jeder kann die kritische Funktion aufrufen.
- Ganzzahlüberlauf/-unterschreitung: Modern Solidity fängt die meisten davon ab, stellt aber immer noch ein Risiko in Low-Level-Code dar.
- Unzureichende Eingabevalidierung: Nulladresse, Nullmengenkontrolle.
- Oracle-Abhängigkeit: Blindes Vertrauen in externe Daten (z. B. Preis).
Achtung: AI kann diese Liste abrufen, kann jedoch nicht garantieren, ob ein Element in der Liste in Ihrem spezifischen Code enthalten ist. Die Checkliste ist ein Anfang; Es ist kein Ersatz für die Containerkontrolle.
Den richtigen Kontext finden: Das Geheimnis guten Codes durch KI
Die Qualität des von der KI erzeugten Codes hängt direkt von der Qualität des Kontexts ab, den Sie ihm geben. In Web3 ist dies besonders kritisch, da ein kleines Detail (welche Kette, welche Solidity-Version, welcher Token-Standard) die gesamte Ausgabe verändert. Ein guter Kontext umfasst:
- Zielkette und Umgebung: Ethereum-Mainnet oder ein Layer 2 (günstigere Sidechain, die auf der Mainchain läuft)? Die Benzinkosten und einige Funktionen variieren je nach Kette.
- Version und Bibliothek: Welche Solidity-Version, welche OpenZeppelin-Version? Wenn keine Version angegeben ist, kann die KI veraltete, veraltete Muster erzeugen.
- Sicherheitsanforderungen: Gibt es eine Obergrenze, kann man pausieren, kann man sie erhöhen? Diese sollten von Anfang an gesagt werden.
- Einschränkungen: Klare Grenzen wie „keine Assembly verwenden“, „externen Aufruf vermeiden“, „Gas optimieren, aber Lesbarkeit beibehalten“.
Eine weitere leistungsstarke Technik besteht darin, die KI zuerst nach dem Plan und dann nach dem Code zu fragen: „Listen Sie zuerst die Funktionen dieses Vertrags auf und was jeder tun wird; schreiben Sie den Code, sobald ich ihn genehmigt habe.“ Dadurch wird frühzeitig erkannt, dass die KI in die falsche Richtung geht, und Sie können die architektonische Entscheidung beibehalten.
Hinweis: Fragen Sie die KI: „Warum haben Sie diesen Code so geschrieben?“ fragen. Das Erläutern der Gründe beschleunigt Ihr Lernen und bringt logische Fehler (z. B. eine falsche Sicherheitsannahme) an die Oberfläche. Vertrauen Sie nicht der Ausgabe einer KI, die ihren eigenen Code nicht verteidigen kann.
Häufige Fehler
- Sicherheit von Grund auf in die KI integrieren. Verwenden Sie eine getestete Bibliothek.
- Keine Bestätigung der von der KI erstellten Version/des Musters. Trainingsdaten sind möglicherweise alt.
- Testnetz umgehen. Jeder Entwurf sollte im Testnetzwerk ausgeführt werden, bevor er live geht.
- NatSpec/Dokumentation wird nicht hinzugefügt. Inspektion und Wartung werden schwierig.
- „Es ist kompiliert, also ist es sicher“-Missverständnis. Kompiliert zu sein bedeutet nicht, sicher zu sein.
- Zugangskontrolle vergessen. Es ist einer der häufigsten und teuersten Fehler.
Zusammenfassend
- Beim Schreiben intelligenter Verträge erstellt KI Frameworks, Tests und Überprüfungsentwürfe. Der Mensch garantiert Produktionssicherheit.
- Bauen Sie Sicherheit nicht von Grund auf auf, sondern basieren Sie auf bewährten Bibliotheken (z. B. OpenZeppelin).
- Die Aktualität der von YZ erstellten Versionen und Muster wird stets bestätigt.
- Test-Stubs sind wertvoll bei der Erfassung menschlicher blinder Flecken (Grenzfälle, Zugangskontrolle).
- Kompiliert zu sein bedeutet nicht, sicher zu sein; Testnet und Auditing sind ein Muss.
Anwendungsaufgabe
Erstellen Sie für einen einfachen ERC-20-Token einen Entwurf, indem Sie die obige Eingabeaufforderung „Standardbasiertes Grundgerüst“ verwenden. Dann: (1) prüfen, ob eine geprüfte Bibliothek verwendet wird, (2) die Zugriffskontrollen prüfen, (3) Tests mit der Eingabeaufforderung „Testfallentwurf“ generieren und tatsächlich mindestens einen Rogue-Caller-Test ausführen. Suchen und notieren Sie mindestens einen Sicherheitspunkt, den die KI übersehen hat.
Checkliste
- [ ] Ich habe den Standard und die Kette in der Eingabeaufforderung klar angegeben.
- [ ] Ich wollte eine bewährte bibliotheksbasierte Produktion.
- [ ] SPDX-Lizenz und Pragma-Version verfügbar.
- [ ] In jeder kritischen Funktion gibt es eine Zugriffskontrolle.
- [ ] Ich habe Tests für Grenzfälle erstellt und ausgeführt.
- [ ] Ich habe bestätigt, dass die Bibliothek/das Muster auf dem neuesten Stand ist.
- [ ] Ich habe den Code zur Prüfung und zum Testen markiert; Ich habe es nicht unbeaufsichtigt im Mainnet bekommen.