利益:
- 人工知能を使用してフレームワークを作成し、実績のあるライブラリ (OpenZeppelin など) に基づいてドラフトをテストし、レビューする能力と、人間が本番環境のセキュリティを保証していることを理解する能力
- コンパイル、テスト、テストネットを通じて人工知能によって生成されたコードのバージョン、パターン、アクセス制御を検証する機能
- コンパイルが安全であることを意味するものではなく、テストネットと監査が不可欠であることを区別できること。
スマート コントラクトの作成は通常のソフトウェアとは異なります。作成するコードは公開され、不変であり、お金を直接動かすプログラムです。この単元では、スマート コントラクト開発アシスタントとして AI を使用する方法を学びます。ドラフト制作からテストライティング、パターンリコールからガス（トランザクション手数料）の最適化までを学びます。ただし、最初から明確にしておきます。AI は青写真を生成します。人間は、本番環境に入るコードの安全性を確保します。
まずは地面から: 言語と環境
最も一般的なスマート コントラクト言語は Solidity (イーサリアムおよび EVM の言語、イーサリアム仮想マシン、コントラクトが実行される仮想マシン、互換性のあるチェーン) です。代わりに、Vyper (より制約があり読みやすくなることを目的とした Python に似た言語) があります。コードはガス (ブロックチェーンへの各トランザクションのコスト) を消費します。非効率なコードはコストがかかります。 AI に与えるコンテキスト内でこれらの用語を明確に保つことが、正確な出力を得る鍵となります。
AI が最も価値があるのは、「ゼロから作成する」ことではなく、フレームワークと優れた型、つまり標準に準拠した出発点、専門知識を追加するための青写真を作成することにあります。
コーディングで AI を使用するレイヤー
1. スケルトンの生成。 AI は、標準トークン (ERC-20) または NFT (ERC-721 - 独自のデジタル資産標準) のスケルトンを迅速にマイニングします。ただし、AI には実績のあるライブラリ、たとえば OpenZeppelin (コミュニティの信頼され、監査された標準契約ライブラリ) を使用させるようにしてください。ルールは、セキュリティを最初から作成するのではなく、テストされたブロックを使用することです。
2. 機能の説明とレビュー。既存の関数を AI に説明することで、ロジック エラーを早期に発見できます。
3. テストの生成。 AI は、ゼロ入力、非常に多数の数、不正な呼び出し元、繰り返しの呼び出しなど、エッジ ケースのテスト ケースを生成するのが得意です。これは、スキップしたシナリオの 1 つを思い出させます。
4. ガスと可読性。 AI は、不必要なストレージへの書き込みなどのコストのかかるパターンにフラグを立て、代替案を提案します。
ヒント: AI に「OpenZeppelin の監査済み契約を基にして、セキュリティを最初から書き直す」ように指示します。 AI にとって、テスト済みのライブラリを使用するよりも、オリジナルのセキュリティ コードを記述する方がはるかにリスクが高くなります。
弱いプロンプト / 強いプロンプト
弱いプロンプト:
トークンコントラクトを書いてください。
このプロンプトは危険です。どの標準、どのチェーン、どのライブラリ、どのセキュリティ要件かが明確ではありません。 AI は、古いコードや安全でない可能性のあるランダムなコードを生成します。
強力なプロンプト:
あなたの役割: シニア Solidity 開発者。 EVM 互換チェーンの ERC-20 トークン ドラフトを生成します。ルール:- OpenZeppelin の監査済み ERC20 および Ownable 契約に基づいています。- Solidity のバージョンとライセンス (SPDX) 行を明示的に記述します。- 所有者のみが鋳造する権限を持っています。無限押しに対するキャップを追加します。 - 各関数に NatSpec コメントを追加します。 - セキュリティを最初から作成します。標準ブロックを使用してください。 - 最後に警告を追加します:「これはドラフトです。監査とテストが必要です」。不明な部分には // TODO を付けてください。
違い: 強力なプロンプトにより、明確な役割、標準、ライブラリ、セキュリティ境界、ドキュメント、および検証の期待が示されます。
コピー可能な 4 つのテンプレート
1) 標準ベースのスケルトン:
あなたの役割: Solidity 開発者。 OpenZeppelin 監査済みライブラリに基づいて [ERC-20 / ERC-721 / ステーキング] 契約フレームワークを生成します。 SPDX ライセンスとプラグマ バージョンを書き込みます。各外部関数にアクセス制御 (誰が呼び出せるか) を追加します。セキュリティの再発明。標準ブロックを使用します。これは草案です。
2) 機能レビュー:
上級開発者のように次の関数を調べてください。関数は何をするのか、どのような状態が変化するのか、誰がそれを呼び出せるのか?考えられる論理エラーとセキュリティ リスクを仮説としてマークし、それぞれをコード内の行にリンクします。あからさまに「安全」とは言わないでください。注意点を列記するだけです。
3) テストシナリオのドラフト:
この契約のテスト ケースを提案します (Foundry/Hardhat の草案になる可能性があります)。具体的には、ゼロ入力、非常に大きな数、不正な呼び出し、再入可能な呼び出し、資金不足などの制限ケースをカバーします。各テストで確認された内容を書きます。
4) ガスと可読性のレビュー:
この契約では、ガスコストを削減できるパターン (不必要なストレージへの書き込み、ループ内の外部呼び出し、反復計算) をマークします。各提案の前後の違いを説明します。セキュリティを破壊する最適化を推奨します。不明な場合は、「監査人に質問してください」と言ってください。
ミニケース 3個（個数）
ケース 1 — スケルトンは 4 時間節約されました。あるチームは、AI を使用して監査済みの図書館ベースの権利確定契約の骨子を 30 分でマイニングしました。手動で約 4 時間かかりました。チームはセキュリティとテストに時間を費やしました。利益はセキュリティの移転によるものではなく、退屈なフレームワークの高速化によるものでした。
ケース 2 — 古いバージョンのトラップ。 AI は生のイーサを転送で送信するパターンを生成しましたが、トレーニング データが古いため推奨されなくなりました。開発者はこれに気づき、現在の呼び出しベースで再入保護されたパターンに変更しました。教訓: AI のライブラリ/パターンは常に最新であることが確認されます。 AI はトレーニングの締め切り日を超えることを知りません。
ケース 3 — テスト ドラフトで隠れたバグが発見されました。 AIが生成した「不正呼び出し元」テストにより、開発者が関数内のアクセス制御を忘れていたことが判明した。 OnlyOwner に 1 行欠落があり、テストネットで 5 分で捕捉されました。メインネット上の資金の損失があった可能性があります。教訓: AI はテストにおける人間の盲点をカバーします。
AIによるセキュリティパターンの記憶
AI は、チェックリストのように既知の脆弱性パターンを思い出させるのが得意です。最も一般的なパターン:
- 再入可能: ステータスを更新せずに外部呼び出しを行います。解決策: チェック、効果、インタラクションの順序、再入ガード。
- アクセス制御の欠如: 誰でも重要な機能を呼び出すことができます。
- 整数のオーバーフロー/アンダーフォール: Modern Solidity はそれらのほとんどを検出しますが、低レベルのコードでは依然としてリスクがあります。
- 不適切な入力検証: ゼロアドレス、ゼロ数量制御。
- Oracle への依存: 外部データ (価格など) に対する盲目的な信頼。
注意: AI はこのリストを呼び出すことができますが、リスト内の項目が特定のコードに含まれるかどうかは保証できません。チェックリストは出発点です。これはコンテナー制御に代わるものではありません。
コンテキストを正しく理解する: AI による優れたコードの秘密
AI が生成するコードの品質は、AI に与えられるコンテキストの品質に直接依存します。 Web3 では、1 つの小さな詳細 (どのチェーン、どの Solidity バージョン、どのトークン標準) によって出力全体が変更されるため、これは特に重要です。適切なコンテキストには次のものが含まれます。
- ターゲットチェーンと環境: イーサリアムメインネット、それともレイヤー 2 (メインチェーン上で実行される安価なサイドチェーン)?ガス料金と一部の機能はチェーンによって異なります。
- バージョンとライブラリ: Solidity のどのバージョン、OpenZeppelin のどのバージョンですか?バージョンが指定されていない場合、AI は古くなった非推奨のパターンを生成する可能性があります。
- セキュリティ要件: 上限はありますか? 一時停止できますか? 増やすことができますか?これらは最初から言うべきです。
- 制約: 「アセンブリを使用しない」、「外部呼び出しを避ける」、「ガスを最適化するが可読性を維持する」などの制限を明確にします。
もう 1 つの強力なテクニックは、最初に計画を AI に要求し、次にコードを要求することです。「まず、この契約の機能とそれぞれが何を行うかをリストアップします。承認したらコードを作成します。」これにより、間違った方向に進む AI を早期にキャッチし、アーキテクチャ上の決定を保持できるようになります。
ヒント: AI に「なぜこのコードをこのように書いたのですか?」と尋ねます。聞く。理論的根拠を説明すると、学習がスピードアップするだけでなく、論理的エラー (セキュリティの誤った仮定など) が表面化します。自身のコードを防御できない AI の出力を信頼しないでください。
よくある間違い
- AI にセキュリティをゼロから組み込む。テスト済みのライブラリを使用します。
- AIが生成したバージョン/パターンを確認していません。トレーニングデータが古い可能性があります。
- テストネットをバイパスします。すべてのドラフトは、公開する前にテスト ネットワークで実行する必要があります。
- NatSpec/ドキュメントは追加しません。点検や保守が困難になります。
- 「コンパイルされているから安全」という誤解。コンパイルされていることは安全であることを意味するものではありません。
- アクセス制御を忘れています。これは最も一般的で、高くつく間違いの 1 つです。
要約すると
- スマートコントラクトの作成では、AI がフレームワーク、テスト、レビュー草案を作成します。人間が生産の安全性を保証します。
- セキュリティを最初から構築するのではなく、実績のあるライブラリ (OpenZeppelin など) に基づいて構築します。
- YZ が作成したバージョンとパターンは常に最新であることが確認されます。
- テスト スタブは、人間の盲点 (制限ケース、アクセス制御) を捕捉するのに役立ちます。
- コンパイルされていることは安全であることを意味するものではありません。テストネットと監査は必須です。
アプリケーションタスク
単純な ERC-20 トークンの場合は、上記の「標準ベースのスケルトン」プロンプトを使用してドラフトを生成します。次に、(1) チェックされたライブラリが使用されているかどうかを確認し、(2) アクセス制御を確認し、(3) 「テスト ケース ドラフト」プロンプトでテストを生成し、少なくとも 1 つの不正呼び出し元テストを実際に実行します。 AI が見逃したセキュリティ ポイントを少なくとも 1 つ見つけてメモします。
チェックリスト
- [ ] プロンプトに規格とチェーンを明記しました。
- [ ] 実証済みのライブラリベースの制作が必要でした。
- [ ] SPDX ライセンスとプラグマ バージョンが利用可能です。
- [ ] すべての重要な機能にアクセス制御があります。
- [ ] 限界ケースのテストを作成して実行しました。
- [ ] ライブラリ/パターンが最新であることを確認しました。
- [ ] 監査とテスト用にコードにマークを付けました。メインネット上で監視されていない状態で入手したわけではありません。