---
title: "CREATE2 コントラクトアドレスの検証方法"
description: "CREATE2 はデプロイヤー、salt、初期化コードのハッシュからアドレスを予測しますが、検証にはチェーン固有のファクトリー、バイトコード、デプロイ、プロキシ、所有権の証拠が必要です。"
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# CREATE2 コントラクトアドレスの検証方法
> 教育目的の参考情報であり、投資またはセキュリティ上の助言ではありません。予測アドレス、空アカウント、チェックサム、ファクトリーの名称は、デプロイ、コード、制御権、所有権、安全性の証明ではありません。
## 要点
CREATE2 は、特定のデプロイヤーコントラクトが `32-byte salt` と正確な `init_code` のハッシュから作成するアドレスを予測します。プロトコルの式は `address = keccak256(0xff || deployer(20 bytes) || salt(32 bytes) || keccak256(init_code))[12:]` です。`85-byte preimage` をハッシュし、最後の `20 bytes` を保持します。deployer は CREATE2 を実行するファクトリーであり、ファクトリーを呼び出したウォレットとは限りません。
`init_code` は作成バイトコードと ABI エンコードされたコンストラクター引数で構成され、1回だけ実行されてランタイムバイトコードを生成します。コンパイラーのバージョン、最適化設定、リンク済みライブラリ、メタデータ、コンストラクター引数、ファクトリーのエントリポイントがハッシュを変える可能性があります。ランタイムコードは出力であり、CREATE2 の入力ではありません。アドレスを比較できるのは、デプロイヤー、salt、初期化コード、EVM ルール、チェーン状態が同じ場合だけです。
カウンターファクチュアルアドレスはコードが存在する前でも資金を受け取れますが、検証済みの制御ロジックはまだありません。予測はデプロイ、所有権、認可、ファイナリティ、安全性を意味しません。対象チェーンとブロックで、ファクトリーのバイトコードと calldata、レシートとイベント、`eth_getCode`、nonce、ストレージ、残高、プロキシ実装、初期化、所有者を検証します。
## 仕組み
チェーンまたはドメイン、フォーク規則、RPC とブロック、ファクトリーアドレスとランタイムハッシュ、生の salt、正確な初期化バイト、コンストラクターのエンコード、コンパイラー、リンク済みライブラリを固定します。`keccak256(init_code)` と `85-byte preimage` を再計算し、ABI のパディング、エンディアン、チェックサム、最後の 20 バイトの抽出を確認します。
次にファクトリーの呼び出しと value をデコードします。意図したファクトリー、エントリポイント、salt ドメイン、コンストラクター、所有者、初期化が拘束されていることを確認します。最小プロキシでは実装アドレスを含むクローン作成バイトコードをハッシュし、実装のランタイムコードはハッシュしません。プロキシでは実装、管理者、ストレージスロット、アップグレード方針を個別に検証します。
EIP-684 により、宛先の nonce が非ゼロまたはコードが空でない場合、作成はリバートします。コンストラクターが失敗してもデプロイ成功は残りません。その後の `SELFDESTRUCT` と再デプロイの意味はフォーク規則に依存します。「コードはいつでも自由に置き換えられる」という古い前提を使わないでください。
デプロイの証拠には、トランザクションの取り込みとステータス、発行イベント、コードと nonce、ストレージと残高、そして安全または確定済みのチェーン状態という層があります。RPC の成功応答や予測チェックサムはレシートと状態検証の代わりになりません。別チェーンの同一アドレスには、異なるコード、所有者、ストレージ、資産があり得ます。
次の手順を使用します。
1. チェーン、フォーク、RPC、ブロック、ファクトリーまたはデプロイヤーのアドレスとランタイムハッシュ、salt のバイト、初期化コード、コンストラクター引数、コンパイラー、リンク済みライブラリを固定します。
2. 初期化コードのハッシュと正確な CREATE2 preimage を計算し、幅、パディング、`0xff`、最後の20バイト、チェックサムを確認します。
3. ファクトリー calldata と value をデコードし、予測アドレス、所有者、初期化、プロキシの対象、権限を比較します。
4. 正しいチェーンでレシート、ステータス、イベント、`eth_getCode`、nonce、残高、ストレージを検証し、未デプロイと衝突の状態を記録します。
5. ファクトリー、プロキシ、実装、管理者、初期化、アップグレード、シングルトンファクトリーの前提を調べ、ERC-1167 の対象も確認します。
6. コンストラクター失敗、nonce/コード衝突、フォーク依存の再デプロイ、ネストしたファクトリー、チェーンドメインとリプレイの前提をテストします。
7. 資金提供または署名前に表示額と生の額を照合し、デプロイ後はコードハッシュ、所有者、実装、ロール、イベント、ファイナリティを監視します。
## 例
- **EIP-1014 ベクトル：** デプロイヤー `0x0000000000000000000000000000000000000000`、全ゼロの salt、初期化コード `0x00` は `0x4D1A2e2bB4F88F0250f26Ffff098B0b30B26BF38` になります。
- **コンストラクターの拘束：** デプロイヤーと salt を固定しても、ABI エンコードされたコンストラクター引数を1つ変更すれば `keccak256(init_code)` が変わり、予測アドレスも変わります。ランタイムバイトコードをハッシュするのは誤った対象の検証です。
- **衝突：** 宛先 nonce が `0` より大きい、またはコードが空でない場合、EIP-684 により CREATE2 はリバートします。コードと nonce がゼロでも資金だけあるアドレスはカウンターファクチュアルにすぎず、未検証です。
- **最小プロキシ：** ERC-1167 クローンのアドレスは実装アドレスを含むクローン作成バイトコードをハッシュします。実装のランタイムコードをハッシュすると無関係な予測になります。
## リスク
- 誤ったファクトリーまたはデプロイヤーを使う。
- salt の幅、パディング、エンディアン、ドメインエンコードが誤る。
- 初期化コードとランタイムバイトコードを混同する。
- コンストラクター引数が欠落または順序違いになる。
- ファクトリーのエントリポイント、value、calldata が異なる。
- プロキシまたは delegate の対象が意図した実装ではない。
- チェーン、フォーク、EVM ドメインが異なる。
- 既存 nonce による衝突。
- 既存コードによる衝突。
- 古い SELFDESTRUCT 再デプロイ前提を使う。
- ネストした CREATE2 により有効なデプロイヤーが変わる。
- CREATE と CREATE2 の式を混同する。
- ERC-1167 の実装対象を検証しない。
- シングルトンファクトリーのアドレスやデプロイ前提を検証しない。
- 実装のアップグレードまたは管理者制御で挙動が変わる。
- コンパイラー、メタデータ、ライブラリ、ソース成果物が異なる。
- レシート、メンプール、失敗、ファイナリティの状態を混同する。
- チェックサムまたは UI ポイズニングが誤ったアドレスを隠す。
- 事前入金したカウンターファクチュアル資金に所有権の証拠がない。
- EIP-7702、リプレイ、ガス、DoS、古い監視の前提が誤る。
## よくある誤解
- **「空のアドレスは安全または所有済みだ。」** コードも検証済みの制御者もない可能性があります。
- **「アドレスは salt だけで決まる。」** デプロイヤーと初期化コードのハッシュも同じく拘束します。
- **「CREATE2 はランタイムバイトコードをハッシュする。」** コンストラクター引数を含む作成コードをハッシュします。
- **「2つのチェーンの同じアドレスは同じコードと制御を意味する。」** チェーン状態とデプロイを個別に確認します。
- **「予測に成功すればデプロイと安全性が証明される。」** レシート、コード、状態、権限、ファイナリティが存在を確定します。
## 関連トピック
- [プロキシコントラクト](/ja/crypto/proxy-contract/)
- [スマートコントラクト](/ja/crypto/smart-contract/)
- [トークンコントラクトアドレスの検証](/ja/crypto/token-contract-verification/)
## 出典
- [EIP-1014: Skinny CREATE2](https://eips.ethereum.org/EIPS/eip-1014) - Ethereum Improvement Proposals (参照日: 2026-08-13)
- [EIP-684: Revert creation in case of collision](https://eips.ethereum.org/EIPS/eip-684) - Ethereum Improvement Proposals (参照日: 2026-08-13)
- [Salted contract creations / CREATE2](https://docs.soliditylang.org/en/latest/control-structures.html#salted-contract-creations-create2) - Solidity (参照日: 2026-08-13)
- [ERC-1167: Minimal Proxy Contract](https://eips.ethereum.org/EIPS/eip-1167) - Ethereum Improvement Proposals (参照日: 2026-08-13)
- [ERC-2470: Singleton Factory](https://eips.ethereum.org/EIPS/eip-2470) - Ethereum Improvement Proposals (参照日: 2026-08-13)
- [Create2](https://docs.openzeppelin.com/contracts/5.x/api/utils#Create2) - OpenZeppelin (参照日: 2026-08-13)
- [EIP-155: Simple replay attack protection](https://eips.ethereum.org/EIPS/eip-155) - Ethereum Improvement Proposals (参照日: 2026-08-13)
- [Contract Metadata](https://docs.soliditylang.org/en/latest/metadata.html) - Solidity (参照日: 2026-08-13)
Source: https://wiki.fcontext.com/ja/crypto/create2-address-verification/index.mdx