solidity-core: Solidity 開発基盤スキル

Solidity スマートコントラクト開発における言語ベストプラクティス、セキュリティ、ガス最適化、Foundry テスト戦略を提供する基盤スキル。

対象

• Solidity 0.8.x 以降のスマートコントラクト開発全般
• Foundry（forge / cast / anvil / chisel）を使った開発フロー
• コントラクトのセキュリティレビュー・最適化

ワークフロー

Step 1: プロジェクト構造の確認

1. プロジェクトルートで Foundry プロジェクトか確認する:
   • foundry.toml の存在をチェック
   • hardhat.config.* が存在する場合は Hardhat プロジェクトとして扱う
   • いずれも存在しない場合は AskUserQuestion で開発環境を確認する
2. Solidity バージョンを確認する:
   • foundry.toml の solc_version を読み取る
   • または pragma solidity 宣言を Grep で検出する
   • バージョンが 0.8.0 未満の場合はアップグレードを推奨する
3. 依存関係を確認する:
   • lib/ ディレクトリ（Foundry）または node_modules/ （Hardhat）をスキャン
   • OpenZeppelin、Solmate、Solady 等のライブラリ使用状況を把握する
4. 既存のコントラクト構造を Glob でスキャンする:
   • src/**/*.sol または contracts/**/*.sol
   • テストファイル: test/**/*.sol
   • スクリプト: script/**/*.sol

検証ゲート: foundry.toml または hardhat.config.* が存在し、Solidity バージョンが 0.8.0 以上であること。

Step 2: リファレンス読み込み

タスクに応じて以下のリファレンスを読み込み、該当セクションを選択する:

判断が不明な場合: 複数のリファレンスが関連する場合は全て読み込む。特にセキュリティは常に確認する。

検証ゲート: 少なくとも 1 つのリファレンスファイルが正常に読み込めること。

Step 3: コード生成・レビュー

1. 新規コントラクト作成時:
   • language-patterns.md に従い、NatSpec・コーディング規約を適用する
   • security-checklist.md の該当パターンを確認し、防御コードを組み込む
   • gas-optimization.md の最適化ポイントを考慮する
   • OpenZeppelin コントラクトの継承で実装可能な機能は独自実装を避ける
2. 既存コード修正時:
   • 変更箇所に関連するセキュリティパターンを security-checklist.md で確認する
   • ガスコストへの影響を gas-optimization.md で評価する
   • 変更がインターフェースに影響する場合は NatSpec も更新する
3. テスト作成時:
   • foundry-workflow.md に従い、forge test の構成を決定する
   • 正常系・異常系・境界値のテストケースを網羅する
   • Fuzz テストの適用可否を判断する（数値入力がある関数は原則 Fuzz テスト）
   • Invariant テストの適用可否を判断する（状態を持つコントラクトは推奨）

検証ゲート: forge build がエラーなく完了すること。forge test で全テストがパスすること。

Step 4: セキュリティ最終チェック

コード生成・修正後、security-checklist.md の該当項目で最終確認を行う:

1. Reentrancy: Checks-Effects-Interactions パターンの遵守。外部呼び出しの前に状態を更新しているか。
2. Access Control: 適切な修飾子（onlyOwner, onlyRole）の使用。OpenZeppelin の Ownable / AccessControl を推奨。
3. Integer: unchecked ブロックの安全性。明確にオーバーフローが発生しない場合にのみ使用しているか。
4. External Call: 外部呼び出しの戻り値チェック。call の返り値を確認しているか。
5. Input Validation: require / カスタムエラーで入力値を検証しているか。

検証ゲート: セキュリティチェックリストの CRITICAL 項目に該当する問題が 0 件であること。

使用例

例 1: ERC20 トークンの作成

ユーザー入力: 「Foundry で ERC20 トークンを作りたい」

アクション:

1. Step 1: foundry.toml 確認 → Foundry プロジェクト。lib/openzeppelin-contracts の存在を確認
2. Step 2: language-patterns.md（NatSpec 規約）+ foundry-workflow.md（テスト構成）を読み込み
3. Step 3: 以下を生成:
   • src/MyToken.sol — OpenZeppelin ERC20 を継承、NatSpec 付き、ミント関数に onlyOwner
   • test/MyToken.t.sol — デプロイ、transfer、mint 権限、ゼロアドレスチェックのテスト
   • script/DeployMyToken.s.sol — デプロイスクリプト
4. Step 4: セキュリティチェック → アクセス制御確認、ミント上限の有無を確認

結果: OpenZeppelin ベースの型安全な ERC20 トークンがテスト付きで生成される。

例 2: 既存コントラクトのセキュリティレビュー

ユーザー入力: 「このコントラクトのセキュリティをチェックして」

アクション:

1. Step 1: 対象コントラクトを読み込み、言語バージョン・外部依存を把握
2. Step 2: security-checklist.md を読み込み、全カテゴリのチェック項目を確認
3. Step 3: コントラクトの各関数を検査:
   • external / public 関数のアクセス制御を確認
   • 外部呼び出しの有無と CEI パターンの遵守を確認
   • ストレージ操作の安全性を確認
   • delegatecall / selfdestruct の使用有無を確認
4. Step 4: 発見した問題を重要度別（CRITICAL / WARNING / INFO）に分類して報告

結果: 脆弱性の一覧と修正推奨事項が重要度順に出力される。

例 3: ガス最適化

ユーザー入力: 「このコントラクトのガスを最適化して」

アクション:

1. Step 1: 対象コントラクトを読み込み、forge test --gas-report でベースラインを計測
2. Step 2: gas-optimization.md を読み込み、適用可能なテクニックを選択
3. Step 3: 以下の最適化を検討・適用:
   • storage → memory の読み込み回数削減
   • immutable / constant の適用
   • unchecked の安全な適用（ループカウンタ等）
   • カスタムエラーへの置き換え（require(cond, "msg") → if (!cond) revert CustomError()）
   • ストレージパッキングの最適化
4. Step 4: 最適化後に forge test --gas-report で改善量を確認。テストが全件パスすることを確認

結果: ガスコストの改善量がベースラインとの比較で表示される。

トラブルシューティング

1. Foundry が検出されない

症状: forge コマンドが見つからない

原因と対策:

• Foundry 未インストール: curl -L https://foundry.paradigm.xyz | bash && foundryup でインストールを案内する。
• PATH 未設定: ~/.foundry/bin が PATH に含まれているか確認する。
• Hardhat プロジェクト: hardhat.config.* が存在する場合は Hardhat ワークフローに切り替える。npx hardhat compile / npx hardhat test を使用。

2. Solidity バージョン不一致

症状: forge build でコンパイルエラー（Source file requires different compiler version）

原因と対策:

• pragma と foundry.toml の不一致: foundry.toml の solc_version を pragma solidity のバージョン範囲に合わせる。
• 依存ライブラリのバージョン制約: OpenZeppelin の最新版は ^0.8.20 を要求することがある。forge install openzeppelin/openzeppelin-contracts@v4.x で旧バージョンを指定するか、プロジェクトの Solidity バージョンを上げる。
• remappings の不備: remappings.txt に正しいマッピングが設定されているか確認する。forge remappings > remappings.txt で再生成可能。

3. コンパイルエラー（Stack too deep）

症状: CompilerError: Stack too deep

原因と対策:

• ローカル変数が多すぎる: 関数内のローカル変数を struct にまとめる。
• 関数の引数/戻り値が多い: struct を引数/戻り値に使用する。
• via-ir の有効化: foundry.toml に via_ir = true を追加する。コンパイル時間が長くなるが、stack depth の制限が緩和される。

4. テストの forge test が失敗する

症状: テストが setUp で失敗、または予期しない revert

原因と対策:

• fork テストの RPC 問題: --fork-url の RPC エンドポイントがレート制限に引っかかっている。環境変数で有料 RPC を設定する。
• ブロックタイムスタンプ: vm.warp でタイムスタンプを設定していない。時間依存のロジックがある場合は明示的に設定する。
• msg.sender の不一致: vm.prank / vm.startPrank でテスト用のアドレスを設定しているか確認する。

5. 依存関係のインストール失敗

症状: forge install がエラー、またはインポートが解決できない

原因と対策:

• git submodule の問題: git submodule update --init --recursive で再初期化する。
• remappings の未設定: forge remappings > remappings.txt で remappings を生成する。VS Code の Solidity 拡張もこのファイルを参照する。
• バージョン指定: forge install openzeppelin/openzeppelin-contracts@v5.0.0 のようにタグを指定する。

注意事項

• Solidity 0.8.0 以降は算術オーバーフロー/アンダーフローが組み込みでチェックされるため、SafeMath は不要。
• unchecked ブロックは明確にオーバーフローが発生しない場合にのみ使用する。
• DeFi、NFT、ガバナンス等のドメイン固有パターンは、対応する専門スキル（solidity-defi、solidity-nft、solidity-governance）を参照する。
• クロスチェーンパターンは solidity-crosschain を参照する。
• フロントエンド統合は web3-frontend を参照する。
• アカウント抽象化は web3-account-abstraction を参照する。
• OpenZeppelin コントラクトの利用を推奨し、独自実装は避ける。