技術的サマリー：PoCo – スマートコントラクト向け自律的プロトタイプエクスプロイト生成

1. 問題定義

スマートコントラクトは、脆弱性が巨額の金銭的損失（2025 年 10 月時点で約 1,500 億ドル）につながる可能性のある、極めて敵対的な環境で動作します。セキュリティ監査はこれらの欠陥を特定するために不可欠ですが、脆弱性を示す実行可能なテストである**プロトタイプエクスプロイト（PoC）**を作成するプロセスは、重大なボトルネックとなっています。

手動での PoC 作成は時間がかかり、エラーが発生しやすく、しばしば厳格な監査スケジュールによって制約を受けます。既存の自動化アプローチにはいくつかの限界があります：

• 実行可能なテストコードではなく、ブロックチェーン取引シーケンスを生成することが多い。
• 直接的な金銭的搾取を伴う脆弱性のみを対象とし、アクセス制御や論理エラーを無視している。
• 現実世界のマルチコントラクトソフトウェアプロジェクトの具体的な文脈に適応できない固定パイプラインに依存している。

ここで扱われる核心的な問題は、監査人が記述した高レベルの自然言語による脆弱性記述から、現実世界の Solidity スマートコントラクト向けに実行可能な PoC エクスプロイトを自動生成することです。

2. 手法：PoCo フレームワーク

PoCo は、Foundry ベースのテストコードを自律的に生成するように設計された自律的エージェント（Agentic）フレームワークです。静的コード生成ツールとは異なり、PoCo は**Reason–Act–Observe（推論・行動・観察）**ループ内で単一の大型言語モデル（LLM）エージェントとして動作します。

2.1 エージェントアーキテクチャ

PoCo は、自律性を達成するために LLM を一連の外部ツールと連携させます：

• 基本ツール： ファイルシステム検索（glob、grep）、読み取り、編集/書き込み。
• 計画ツール： タスクの進捗を追跡するための軽量な Todo インターフェース。
• スマートコントラクトツール：
  • smart-contract-compile：Foundry の Forge を使用して Solidity コントラクトをコンパイルします。
  • smart-contract-test：生成された PoC を脆弱なコードベースに対して実行します。
• 環境： すべてのコード実行は、安全性と再現性を確保するために隔離された Docker コンテナ内で発生します。

2.2 運用ループ

エージェントは ReAct スタイルのループに従います：

1. 推論： エージェントは脆弱性の記述と対象コードベースを分析します。
2. 行動： 特定の関数の検索、テストファイルの作成、コンパイルなど、ツールを選択して実行します。
3. 観察： ツールからのフィードバック（コンパイルエラー、テスト失敗など）を受信します。
4. 改善： フィードバックに基づき、エージェントは構文、論理、または状態設定を反復的に修正し、テストがコンパイルされアサーションを通過するまで行います。

このシステムは、説明可能性、脆弱性分析、Foundry 固有の機能（例：vm.prank）、実行可能性、および反復的改善を強調するシステムプロンプトによって導かれます。

2.3 評価手法

著者らは、2022 年から 2025 年にかけての 23 の現実世界の脆弱性レポートを含む新しいデータセットPRoof-of-Patch上で PoCo を評価しました。

• RQ1（形式の適切性）： 生成された PoC はコンパイルおよび実行可能か？成功は、コンパイルの成功とテストアサーションの通過によって定義されます。
• RQ2（論理的妥当性）： PoC は実際に脆弱性を示していますか？著者らは新しいパッチベースの検証オラクルを導入しました：PoC が脆弱なコードを正常にエクスプロイトするが、開発者の真実の緩和パッチに対して実行された場合はブロックされる場合、論理的に正しいとみなされます。
• RQ3（注釈の感度）： 監査人の記述の詳細度（高レベル、詳細、手順的）が成功にどのように影響するか？

ベースラインには、ゼロショットプロンプティング（単一試行）と、フィードバックはあるが自律的計画がない固定の 2 フェーズパイプラインであるワークフロープロンプティングが含まれました。

3. 主要な貢献

1. PoCo フレームワーク： コードベースを自律的に探索し、状態を管理し、エクスプロイトを反復的にデバッグする、エージェント型 AI 駆動の PoC 生成の青写真。
2. PRoof-of-Patch データセット： 23 の現実世界の脆弱性を、対応する緩和パッチとソースコードとリンクさせた高品質なオープンソースデータセット。これにより、自動的な妥当性検証が可能になります。
3. 新規検証手法： 開発者が提供するパッチを独立したオラクルとして使用し、手動検査なしで生成された PoC の論理的妥当性を自動的に検証する技術。
4. 実証的証拠： エージェント型フレームワークが、高品質な PoC 生成において非エージェント型ベースラインを大幅に上回ることを示す実験キャンペーン。

4. 実験結果

評価には、Claude Sonnet 4.5、OpenAI o3、GLM 4.6の 3 つの最先端 LLM が使用されました。

• 形式の適切性（RQ1）：

  • ゼロショット： 69 回の試行のうち、形式が整った PoC は 4 つのみ生成されました（ほとんどがコンパイル失敗）。
  • ワークフロー： 22 の形式が整った PoC が生成されました。
  • PoCo： 50 の形式が整った PoCを生成しました（GLM で 16、o3 で 19、Claude で 15）。PoCo のコードベースの探索と反復的デバッグ能力が主な差別化要因でした。

• 論理的妥当性（RQ2）：

  • ゼロショット： 3 つの正しいエクスプロイト。
  • ワークフロー： 11 の正しいエクスプロイト。
  • PoCo： 32 の論理的に正しいエクスプロイトを生成しました（o3 で 14、Claude で 11、GLM で 7）。
  • PoCo は、最良のワークフローベースラインの約3 倍の正しいエクスプロイトを生成しました。

• 注釈の感度（RQ3）：

  • 成功率は手順的 > 詳細 > 高レベルという階層に従いました。
  • ただし、論文はあるニュアンスを指摘しています：いくつかの場合（例：#077）、過度に具体的な手順指示がエージェントを「過度に制約」し、失敗を招いた一方で、より高レベルの記述はエージェントが柔軟な解決策を見つけることを可能にしました。

5. 意義と主張

この論文は、このタスクにおいてエージェント自律性が、生粋のモデル能力よりも重要であると主張しています。最も能力の低いモデル（GLM 4.6）でさえ、ゼロショットまたはワークフローベースラインでは成功した PoC を 1 つも生成しませんでしたが、PoCo エージェントループを備えると、16 の形式が整った PoC と 7 つの正しいエクスプロイトを生成しました。

著者らは、PoCo がスマートコントラクトセキュリティライフサイクルにおける重要なボトルネック、すなわちテキストベースの脆弱性レポートを実行可能で検証可能なテストケースへ変換する課題に対処していると強調しています。このプロセスを自動化することで、PoCo は以下を可能にします：

• 監査人が、紛争の余地のない実行可能な脆弱性の証拠を提供すること。
• 開発者が、問題の修正のための即座に再現可能なテストケースを受け取ること。
• ステークホルダーが、リスクをより適切に評価し、修復の優先順位を決定すること。

この論文は、PoCo が脆弱性を自動的に発見するわけではありませんが、それらを検証し文書化するのに必要な努力を大幅に削減し、それによってスマートコントラクト監査全体のセキュリティと信頼性を向上させるものであると結論付けています。この研究は、Web3 エコシステムにおけるより堅牢で自動化されたセキュリティ検証への一歩として提示されています。