本文へ移動
Financial Context Wiki

CREATE2 コントラクトアドレスの検証方法

CREATE2 はデプロイヤー、salt、初期化コードのハッシュからアドレスを予測しますが、検証にはチェーン固有のファクトリー、バイトコード、デプロイ、プロキシ、所有権の証拠が必要です。

更新日

教育目的の参考情報であり、投資またはセキュリティ上の助言ではありません。予測アドレス、空アカウント、チェックサム、ファクトリーの名称は、デプロイ、コード、制御権、所有権、安全性の証明ではありません。

要点

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つのチェーンの同じアドレスは同じコードと制御を意味する。」 チェーン状態とデプロイを個別に確認します。
  • 「予測に成功すればデプロイと安全性が証明される。」 レシート、コード、状態、権限、ファイナリティが存在を確定します。

関連トピック

出典

ナビゲーション

Wiki を検索...