Deterministic Deployment（CREATE2）

Deterministic Deployment（CREATE2）とは？

Deterministic Deployment（CREATE2）は、スマートコントラクトをデプロイする前に、そのアドレスを計算できるEthereum Virtual Machine（EVM）の方式です。

この方式では、オペコード値

で識別されるEVMオペコードを使用します。

CREATE2でデプロイされたコントラクトのアドレスは、デプロイを実行するコントラクト、開発者が指定するsalt、初期化コードのハッシュから導出されます。

これは、通常、デプロイヤーのアドレスとnonceを基に生成される通常のコントラクトデプロイとは異なります。

CREATE2は変化するデプロイヤーのデプロイnonceを使わないため、ファクトリーがその後ほかのコントラクトを作成していても、同じアドレスを予測できます。

この特性は、反実仮想スマートアカウント、予測可能なプロトコル構成要素、クロスチェーンアプリケーションインフラ、ステートチャネル、デプロイ前に暗号資産を受け取るコントラクトなどを支えます。

最終版のEIP-1014 CREATE2仕様では、オペコード、アドレス計算式、ガス処理、衝突時の動作、当初想定された反実仮想デプロイの用途が定義されています。

CREATE2によって、コントラクトが自動的に安全、永続的、分散型になるわけでも、すべてのブロックチェーン上で同一になるわけでもありません。

指定された入力値からデプロイアドレスを決定論的に導出する方式を提供するものです。

CREATE2が「決定論的」と呼ばれる理由

同じ入力が常に同じ出力を生み出す処理を、決定論的といいます。

CREATE2での出力は、スマートコントラクトのアドレスです。

入力となるのは、CREATE2を実行するデプロイヤーのアドレス、32バイトのsalt、初期化コードのハッシュです。

これらの入力を知っていれば、誰でもブロックチェーンのトランザクションを送信せずに、将来のアドレスを計算できます。

アドレスはデプロイ時刻、現在のブロック番号、ファクトリーが過去に作成したコントラクト数には左右されません。

アドレス計算式の入力を一つでも変えると、予測されるアドレスも変わります。

そのため、コントラクトのコードがオンチェーン上に存在する前に、デプロイを計画し、アドレスを参照し、資金を送付し、そのアドレスに関連付けた署名メッセージを含めることができます。

CREATE2のアドレス計算式

CREATE2のアドレスは、次の式で計算されます。

は1バイトのプレフィックスで、CREATE2で生成されるアドレスと通常のCREATEで生成されるアドレスを区別するために使われます。

は、CREATE2オペコードを直接実行するコントラクトの20バイトのアドレスです。

はCREATE2処理に渡される32バイトの値です。

は、コントラクト作成時に実行される初期化コードです。

初期化コードはハッシュ化されてから、最終的な85バイトのCREATE2ハッシュ入力に含まれます。

最終的なKeccak-256ハッシュの末尾20バイトが、コントラクトアドレスになります。

予測にブロックチェーンの状態変更は不要なため、ネットワーク手数料を払わずにローカルで計算できます。

CREATE2のデプロイヤーとは？

CREATE2のデプロイヤーとは、CREATE2オペコードを直接呼び出すスマートコントラクトです。

ファクトリー、デプロイヤーコントラクト、決定論的デプロイプロキシ、シングルトンファクトリーなどと呼ばれることがあります。

ファクトリーにトランザクションを送る外部所有アカウント（EOA）が、CREATE2の計算式で使われるアドレスになるとは限りません。

通常はファクトリー自身がオペコードを実行するため、ファクトリーのアドレスがデプロイヤーアドレスとして使われます。

saltと初期化コードが同じでも、異なるファクトリーを使用すると、予測されるコントラクトアドレスは異なります。

トランザクションを送信するウォレットを使って計算するのではなく、正確なファクトリーアドレスを確認する必要があるのはこのためです。

ファクトリーによっては、誰でも任意の初期化コードをデプロイできます。一方、承認済みアカウントやコントラクトテンプレートにデプロイを制限するものもあります。

ファクトリーの権限や実装によって、予測したコントラクトが実際にデプロイできるかどうかが左右される場合があります。

CREATE2のsaltとは？

CREATE2のsaltは、決定論的なアドレス計算に含まれる任意の32バイト値です。

saltを使えば、同じ初期化コードから複数のコントラクトをデプロイし、それぞれに異なるアドレスを割り当てられます。

saltは、ユーザーID、ウォレットアドレス、アカウント番号、トークンID、アプリケーションのバージョン、乱数、複数の項目の組み合わせから生成できます。

saltを秘密にする必要はありません。

ファクトリー、salt、初期化コードが分かれば、誰でも同じアドレスを計算できます。

符号化の違いによって予期しないアドレスが生成されないよう、開発者はsaltのエンコード方法を明確に定める必要があります。

たとえば、数値の

、文字列「1」、末尾がの32バイト値は、ソフトウェアによって異なる値として扱われる場合があります。

曖昧なエンコードを避けるため、プロジェクトによっては構造化データをハッシュ化して固定長の32バイトsaltを生成します。

初期化コードとは？

初期化コード（init codeと略されることが一般的）は、スマートコントラクト作成時に実行される一時的なEVMコードです。

コンストラクターの処理を実行し、新しいアドレスに残るランタイムバイトコードを返します。

初期化コード自体は、通常、コントラクトの永続的なコードとして保存されません。

CREATE2の計算式では、この初期化コードのハッシュが使われます。

Solidityでは、完全な初期化コードに、通常、コントラクト作成用バイトコードとABIエンコードされたコンストラクター引数が含まれます。

salt付きコントラクト生成に関するSolidityの最新ドキュメントでは、アドレスが作成用バイトコードとコンストラクター引数に依存することが確認されています。

コンストラクター引数を変更すると初期化コードのハッシュが変わり、予測されるアドレスも変わります。

CREATE2アドレスを計算する際は、デプロイに使用するコンパイラ出力とコンストラクター引数のエンコードを正確に一致させる必要があります。

初期化コードとランタイムバイトコードの違い

初期化コードとランタイムバイトコードは関連していますが、別のものです。

初期化コードはデプロイ時に一度だけ実行されます。

ランタイムバイトコードは、デプロイ完了後にコントラクトアドレスに保存されるコードです。

CREATE2のアドレス計算式は、最終的なランタイムコードのハッシュではなく、初期化コードのハッシュを直接参照します。

この違いは、重要なセキュリティ上の考慮事項につながります。

コンストラクターは外部のブロックチェーン状態を読み取り、その情報に基づいて生成するランタイムコードや初期ストレージ値を決定できます。

そのため、同じ初期化コードでも、実行時の外部条件によってデプロイ後の挙動が変わる可能性があります。

強い動作上のコミットメントを求める開発者は、環境に依存するコンストラクターを避けるか、デプロイ後のランタイムコードとストレージを検証する必要があります。

コンストラクター引数とCREATE2

Solidityによるデプロイでは、コンストラクター引数は初期化コードの一部です。

たとえば、所有者アドレスが

のコントラクトは、所有者アドレスをとして同じコントラクトを生成する場合と、通常、CREATE2アドレスが異なります。

同じルールは、トークン名、供給量、実装アドレス、バリデーター一覧、手数料設定、その他のコンストラクター入力にも当てはまります。

開発者は、コントラクトのABIが求める順序と形式でコンストラクター引数をエンコードする必要があります。

コンストラクター引数を含めないアドレス予測ツールは、誤った結果を計算します。

デプロイ後に呼び出す初期化関数は、その初期化呼び出しがコンストラクターまたはファクトリーの処理に含まれない限り、CREATE2の計算式に影響しません。

デプロイと初期化を分離すると、別のアカウントが保護されていない初期化関数を先に呼び出すリスクが生じる場合があります。

CREATEとCREATE2の違い

CREATEとCREATE2は、スマートコントラクトの作成に使われるEVMオペレーションです。

通常のCREATEでは、新しいアドレスは主に作成元アカウントとデプロイnonceから導出されます。

デプロイヤーがコントラクトを作成すると、nonceは増加します。

そのため、CREATEアドレスを予測するには、正しいデプロイ順序を把握する必要があります。

CREATE2はnonceに基づく計算式を、ファクトリーアドレス、salt、初期化コードのハッシュに基づく計算式に置き換えます。

CREATE2は、コンストラクターコードの基本的な実行方法や、返されたランタイムバイトコードの保存方法を変更しません。

変更されるのは宛先アドレスの導出方法であり、初期化コードのハッシュ化に必要なガスコストが追加されます。

どちらのオペレーションも、宛先アドレスがEVMのコントラクト作成時の衝突ルールに違反すると失敗します。

CREATE2が導入された時期

CREATE2は2018年にEIP-1014で仕様化されました。

EthereumのConstantinopleネットワークアップグレードに含まれました。

Constantinopleアップグレード仕様には、アップグレードに含まれたプロトコル変更の一つとしてEIP-1014が記載されています。

その後、CREATE2はEVMの確立された機能となり、Solidityや広く使われている開発ツールでもサポートされています。

EVM互換ネットワークでも、該当するプロトコル動作を有効にすればCREATE2をサポートできます。

EVMに似た環境を使用するすべてのブロックチェーンで同じルールが実装されていると想定せず、ネットワークの互換性を確認してください。

SolidityにおけるCREATE2

Solidityでは、CREATE2を使ったコントラクトのデプロイを高水準の構文で記述できます。

ファクトリーでは、

の構文を使えます。

Solidityコンパイラは作成用バイトコードを用意し、コンストラクター引数をエンコードしてCREATE2オペレーションを生成します。

payableコンストラクターでは、

オプションによって、デプロイ時にブロックチェーンのネイティブ通貨を受け取ることもできます。

ファクトリーは、デプロイ後に想定されたゼロ以外のアドレスが返されたことを確認してください。

初期化コードのメモリ、長さ、salt、付与額を直接制御する必要がある場合、開発者はインラインアセンブリからCREATE2を呼び出すこともできます。

インラインアセンブリは実装リスクを高めるため、慎重にテストする必要があります。

SolidityでのCREATE2の簡単な例

この例では、予測される子コントラクトのアドレスは、ファクトリーのアドレス、salt、Childの作成用バイトコード、エンコードされた

引数に依存します。

これらの入力を変更しなければ、外部の呼び出し元を変えてもアドレスは変わらない場合があります。

を変えると、コンストラクター引数が初期化コードの一部であるため、アドレスも変わります。

CREATE2アドレスの予測

開発者は、スマートコントラクト、デプロイスクリプト、ウォレット、ローカルアプリケーションでCREATE2アドレスを計算できます。

計算には、CREATE2を実行する正確なファクトリーアドレスを使用する必要があります。

saltも最終的な32バイト形式で使用します。

初期化コードのハッシュには、正確な作成用バイトコードとエンコード済みコンストラクター引数を含める必要があります。

デプロイ後は、ファクトリーが返したアドレスと予測結果を照合してください。

予測アドレスと実際のアドレスが異なる場合、デプロイツールは処理を拒否する必要があります。

予測が誤る主な原因には、作成用バイトコードではなくランタイムバイトコードを使うこと、コンストラクター引数の欠落、誤ったファクトリーの選択、saltのエンコードミスがあります。

反実仮想デプロイとは？

反実仮想デプロイとは、スマートコントラクトがまだデプロイされていない段階で、将来のコントラクトアドレスを有効なものとして扱うことです。

関係者はアドレスを計算し、想定する初期化コードについて事前に合意できます。

そのアドレスに資産を送付したり、別のコントラクトに含めたり、関連する署名付き承認を作成したりできます。

実行が必要になるまで、コントラクトはデプロイされません。

これにより、すぐにデプロイトランザクションを行う必要がなくなり、初期設定のコストを抑えられる場合があります。

EIP-1014では、参加者が紛争に入った場合にのみコントラクトが必要となるステートチャネルシステムでの反実仮想的なやり取りが、当初の主な用途として挙げられていました。

現在では、スマートコントラクトウォレットやアカウント抽象化でも重要な仕組みとなっています。

反実仮想スマートコントラクトアカウント

スマートコントラクトアカウントは、アカウントコントラクトをデプロイする前でも、CREATE2によって予測可能なアドレスを持つことができます。

ユーザーはそのアドレスを共有し、暗号資産やトークンを受け取れる場合があります。

その後、最初のアカウント操作でウォレットをデプロイし、より大きな一連の処理の中でアクションを実行できます。

これにより、資産を受け取る前に別途ウォレット作成のトランザクションを完了する必要がなくなる場合があります。

ERC-4337のアカウント抽象化仕様では、アカウントがまだ存在しない場合、ファクトリーの初期化データから送信者となるスマートコントラクトアカウントを作成できます。

アカウントファクトリーでは、デプロイ前に送信者アドレスを計算できるよう、CREATE2がよく利用されます。

新しい認証方式やアカウントモデルでは別の仕組みを使う場合があるため、すべてのアカウント抽象化設計でCREATE2が必須というわけではありません。

未デプロイのアドレスへの暗号資産送付

アドレスに残高を保有するためにランタイムコードは必要ないため、未デプロイのCREATE2アドレスでもブロックチェーンのネイティブ暗号資産を受け取れます。

トークンコントラクトが通常のアドレスへの送付を許可していれば、代替可能トークンや非代替性トークンも予測アドレスに送れます。

まだコントラクトコードが存在しなくても、資産はそのアドレスにひも付けられます。

想定したコントラクトが正常にデプロイされれば、その資産を利用できるようになる場合があります。

この仕組みは、ウォレットの初期設定や反実仮想アプリケーションの設計を簡素化できます。

一方、ファクトリー、salt、初期化コードが誤っていると資産を利用できなくなる深刻なリスクもあります。

価値のある資産を反実仮想アドレスに送る前に、実際にデプロイできることを確認してください。

空のCREATE2アドレスに資金を保有できる？

はい。コードのないアドレスでも、ネイティブ暗号資産やトークンの残高を持てます。

残高があるだけで、そのアドレスへのCREATE2デプロイが妨げられることはありません。

EVMの衝突ルールでは、宛先のnonceがゼロ以外か、コードが空でないかが主に判定されます。

この仕組みは、デプロイ前に資金を受け取る反実仮想アカウントに必要です。

デプロイ後は、コントラクトコードと認可ルールによって、資産の利用方法が決まります。

CREATE2の衝突ルール

宛先アドレスに空でないコードがある場合、またはnonceがゼロ以外の場合、CREATE2によるデプロイは失敗します。

これにより、ファクトリーが同じアドレスに存在するコントラクトを上書きできないようになっています。

新しい初期化コードが本来そのアドレスを正しく計算できる場合でも、このルールは適用されます。

初期化コードがrevertする、ガス不足になる、無効なコードを返す、その他のコントラクト作成ルールに違反すると、デプロイは失敗します。

ファクトリーはCREATE2オペコードがゼロ値を返した場合に処理し、可能であれば分かりやすいエラーを返す必要があります。

衝突は、Keccakハッシュ関数が暗号学的に破られたことを意味するわけではありません。

通常は、EVMのアカウントルール上で決定論的な宛先がすでに使用されていることを意味します。

異なるデプロイで同じCREATE2アドレスが生成されることはある？

同じファクトリーアドレス、salt、初期化コードのハッシュを使うと、2回のデプロイ試行で同じ計算アドレスが生成されます。

異なる初期化コードが理論上同じハッシュを持つ可能性はありますが、現在のセキュリティ上の前提では、実用的なKeccak-256衝突を発見するのは計算上実行不可能と考えられています。

アドレスにはハッシュの末尾20バイトだけを使うため、ほかのEthereumアドレスと同様、ランダムなアドレス衝突は理論上起こり得ます。

現在の計算能力で、意図した衝突を生成することは現実的ではありません。

それでも、見た目が似たアドレスだけを根拠に、デプロイ入力が正しいと判断してはいけません。

saltの再利用

初期化コードが異なれば、初期化コードのハッシュによってアドレスも変わるため、ファクトリーは同じsaltを再利用できます。

同じファクトリーで同じsaltと初期化コードを使っても、元の宛先が使用中である限り、同じコントラクトを再度デプロイすることはできません。

プロジェクトによっては、デプロイの意図を追跡しやすくするため、アプリケーションレベルでsaltの再利用を禁止する場合があります。

公開ファクトリーでは、完全な計算式に初期化コードのハッシュも含まれるため、誰でも過去に使用されたsaltを送信できる場合があります。

saltが一意であることだけでは、十分なセキュリティ特性とはいえません。

ファクトリー、salt、初期化コードの組み合わせ全体を確認する必要があります。

CREATE2デプロイのフロントランニング

保留中のCREATE2トランザクションは、ブロックに取り込まれる前に外部から確認できる場合があります。

別のユーザーがファクトリー呼び出しをコピーし、先にコントラクトをデプロイしようとする可能性があります。

パーミッションレスなファクトリーが同じsaltと同じ初期化コードを使う場合、コピーされたデプロイでも、同じ予測アドレスに同じコードへのコミットメントが作成されるはずです。

その後、宛先がすでに使用されているため、元のトランザクションが失敗する場合があります。

その場合でも、実行タイミングの問題、ガスの無駄、アプリケーションの処理の中断が生じる可能性があります。

コンストラクターの動作が、ブロックデータ、トランザクションの送信元、外部コントラクトの状態、呼び出し元に依存するファクトリーパラメーターなど、変化する環境情報を参照する場合は、リスクがより深刻になります。

現在の決定論的ファクトリー提案では、実行環境に依存するデプロイではなく、完全に決定論的なコントラクトには既知のファクトリーを使うことが推奨されています。

コンストラクターのフロントランニングリスク

CREATE2アドレスは初期化コードへのコミットメントを示しますが、コンストラクターが参照するすべての外部状態を固定するものではありません。

デプロイのタイミングを制御する攻撃者は、コンストラクターが異なる価格、ブロック値、レジストリエントリー、外部コントラクトの状態を参照するよう誘導する可能性があります。

結果として生成されるランタイムコードや初期ストレージが、当初ユーザーが想定したものと異なる場合があります。

可能な場合、重要な設定は変化する外部状態から読み取るのではなく、コミットメントの対象となるコンストラクター引数として渡すべきです。

デプロイスクリプトでは、作成後にランタイムバイトコード、所有権、ストレージ、イベントを検証してください。

保護されていない初期化関数のリスク

プロキシコントラクトや最小クローンでは、コンストラクターの代わりに初期化関数を使うことがよくあります。

初期化関数は、デプロイ後に所有権、権限、実装の詳細、その他の重要な状態を設定します。

CREATE2でアドレスを予測できても、初期化関数が自動的に保護されるわけではありません。

デプロイと初期化を別々のトランザクションで行うと、攻撃者が先に初期化関数を呼び出す可能性があります。

ファクトリーはデプロイトランザクション内でコントラクトをアトミックに初期化するか、厳格な認可を実施する必要があります。

決定論的なアドレスを使っても、初期化設計が保護されていない問題は解消されません。

CREATE2ファクトリー

CREATE2ファクトリーは、saltと初期化コードを受け取り、CREATE2オペコードを実行する再利用可能なスマートコントラクトです。

ファクトリーを使用すると、EOAやほかのスマートコントラクトが、共通のインターフェースを通じて決定論的なデプロイを利用できます。

最小構成のファクトリーでは、権限確認なしに任意のコードを受け付ける場合があります。

専用ファクトリーでは、承認済みのアカウント実装やアプリケーションモジュールのみをデプロイする場合があります。

ファクトリーのランタイムバイトコード、デプロイ履歴、権限、失敗時の処理、価値の移転方法を確認してください。

悪意あるファクトリーは、入力の変更、デプロイの制限、資金の保持、予期しないコードの実行を行う可能性があります。

シングルトンファクトリー

シングルトンファクトリーは、複数のEVMネットワークで同じアドレスに存在することを意図した決定論的ファクトリーです。

共通のファクトリーアドレスを使用すると、開発者は対応ネットワークごとに同じ子コントラクトアドレスを導出できます。

ERC-2470は、決定論的デプロイのためのパーミッションレスなCREATE2シングルトンファクトリーを提案しました。

この提案では、互換性のあるネットワークで既知のアドレスにファクトリーを作成できるよう、秘密鍵を必要としないデプロイ方式を採用しました。

2026年7月時点でERC-2470はEIPリポジトリ上でStagnantとされていますが、決定論的ファクトリーという考え方は広く重要であり続けています。

提案のリポジトリ上のステータスと、コントラクトの実際のデプロイ状況は別の問題です。

マルチチェーンでの決定論的デプロイ

CREATE2を使うと、複数のEVMネットワークで同じアドレスにコントラクトをデプロイできる場合があります。

同じ結果を得るには、各ネットワークでCREATE2ファクトリーのアドレス、salt、初期化コードのハッシュを一致させる必要があります。

同じアプリケーションデプロイヤーのウォレットを使っても、ネットワークごとに呼び出すファクトリーのアドレスが異なれば不十分です。

コンパイラのメタデータ、ライブラリのリンク、コンストラクター引数、コントラクトソースの変更によって、初期化コードのハッシュは変わる場合があります。

基本的なCREATE2の計算式にチェーンIDは直接含まれません。

ただし、コンストラクターやデプロイツールがチェーン固有のデータを含めると、初期化コードやデプロイ後の状態が変わる可能性があります。

アドレスが一致していても、各ネットワークのデプロイ済みコードを個別に確認してください。

複数チェーンで同じアドレスを使うメリット

コントラクトアドレスが同じであれば、ウォレット、インターフェース、ソフトウェアライブラリ、ほかのコントラクトが保存するアドレスの数を減らせます。

開発者は複数の対応ネットワークで一つのアドレス定数を使用できます。

ユーザーが誤ったネットワークのコントラクトアドレスをコピーする可能性も減ります。

スマートコントラクトアカウントも、複数のチェーンで一貫したアドレスを提示できます。

利便性が高まる一方、同じアドレスに異なるコードや設定が存在するネットワークでも、誤った安心感が生まれるおそれがあります。

アドレスは必ずチェーンIDと検証済みバイトコードを合わせて確認してください。

現在の決定論的ファクトリー提案

EVMネットワークやロールアップの増加に伴い、決定論的ファクトリーのインフラは発展を続けています。

2026年7月時点で、EIP-7997はReview段階にあり、EVMチェーン間で広く利用される決定論的ファクトリーを指定アドレスに配置することを正式に求める提案です。

この提案はまだ最終決定されておらず、すべてのネットワークで普遍的に保証されるものとして扱うべきではありません。

ERC-7955は、EIP-7702の機能を通じて汎用CREATE2ファクトリーをパーミッションレスに起動するDraft提案です。

こうした提案は、CREATE2だけでは最初のファクトリーをどこでも同じアドレスに配置する問題を解決できないことに対処します。

汎用ファクトリーを前提とする前に、提案の最新ステータスと実際のネットワーク状態を確認してください。

CREATE2とアカウント抽象化

アカウント抽象化では、スマートコントラクトアカウントがプログラム可能な検証ルールや実行ルールを使えます。

ウォレットは、複数の署名者、パスキー、リカバリー用ガーディアン、支出上限、操作の一括処理、手数料スポンサーに対応できる場合があります。

CREATE2を使うと、ウォレットファクトリーはウォレットコントラクトのデプロイ前にアカウントアドレスを計算できます。

ユーザーはそのアドレスで資金を受け取り、最初の操作が処理される際にアカウントをデプロイできます。

ERC-4337では、送信者アカウントがまだ存在しない場合、ファクトリーデータにその作成処理を含められます。

反実仮想アドレスは、ファクトリー呼び出しによって生成されるアドレスと一致していなければなりません。

ファクトリーが別の場所にコードをデプロイすると、標準の検証フローではアカウント操作が失敗します。

CREATE2とデプロイ前の署名

反実仮想コントラクトアカウントでは、デプロイ前に認証メッセージへ署名する必要が生じる場合があります。

アドレスにランタイムコードが存在しないため、通常のコントラクト署名検証ではアカウントを呼び出せません。

ERC-6492は、デプロイ前のコントラクトアカウントに代わって作成された署名を検証するためのラッパー形式を定義しています。

検証時に、コントラクトの署名ロジックを確認する前に、必要なファクトリーデプロイをシミュレーションまたは実行できます。

アドレスを予測できるため、この規格ではCREATE2コントラクトの利用が推奨されています。

反実仮想アカウントの署名は、通常のEOA署名とみなすのではなく、該当するコントラクト署名規格に基づいて検証してください。

CREATE2とトークンバウンドアカウント

トークンバウンドアカウントは、非代替性トークンに関連付けられたスマートコントラクトアカウントです。

このアカウントは暗号資産、トークン、NFTなどのオンチェーン資産を保有できます。

ERC-6551ではCREATE2を使い、デプロイ前でもトークンバウンドアカウントのアドレスを反実仮想的に利用できるようにしています。

これにより、アカウントコントラクトのデプロイ費用を支払う前に、トークンのアカウントへ資産を送付できます。

規格のルールでは、レジストリ、実装、salt、ブロックチェーン識別子、トークンコントラクト、トークンIDに基づいてアカウントアドレスが決まります。

通常、制御対象のNFTを保有する人がトークンバウンドアカウントを通じて操作を実行できます。

CREATE2とステートチャネル

ステートチャネルでは、参加者がオフチェーンで繰り返しやり取りし、最終結果の強制や紛争解決にはブロックチェーン上のコントラクトを利用します。

参加者は、紛争解決コントラクトのコードとアドレスに事前に合意できます。

CREATE2を使うと、コントラクトをすぐにデプロイせずにアドレスを計算できます。

オフチェーンの処理全体を通じて、反実仮想コントラクトを参照できます。

強制執行が必要になった場合にのみ、コントラクトをデプロイします。

これはEIP-1014で説明された当初のユースケースの一つです。

CREATE2と最小プロキシコントラクト

最小プロキシは、実装コントラクトに呼び出しを委任する小規模なコントラクトです。

ファクトリーは最小プロキシとCREATE2を組み合わせ、予測可能なアカウントやアプリケーションのアドレスを作成できます。

実装アドレスがプロキシの初期化コードに含まれる場合があります。

そのため、実装アドレスを変えると予測されるプロキシアドレスも変わる可能性があります。

一部のファクトリーでは、同じトランザクション内でデプロイ済みプロキシのストレージに初期化パラメーターを設定します。

決定論的なコミットメントが実装、初期化データ、または汎用的なプロキシの殻だけを対象としているのか確認してください。

CREATE2とアップグレード可能なコントラクト

CREATE2自体はアップグレードシステムではありません。

プロキシなど明示的なアップグレード方式を使用すれば、CREATE2でデプロイしたコントラクトをアップグレード可能にできます。

その設計では、プロキシは決定論的なアドレスに残り、実装先を変更できます。

アップグレードのセキュリティは、プロキシの管理者、ガバナンスルール、遅延時間、実装の検証方法によって決まります。

プロキシのアドレスが決定論的であっても、動作が不変とは限りません。

予測可能なアドレスだからコードも永続的だと考えず、アップグレード権限を確認してください。

CREATE2、SELFDESTRUCT、再デプロイ

過去のCREATE2設計では、

を使ってコントラクトを削除し、後から同じアドレスに異なる動作をデプロイする場合がありました。

こうした設計は、メタモーフィックコントラクトと呼ばれることがよくありました。

Ethereumの現行のEIP-6780のSELFDESTRUCTルールでは、一般に、長期間存在するコントラクトのコードやストレージを削除できません。

同じトランザクション内で作成されていないコントラクトがSELFDESTRUCTを呼び出すと、残高は移転しますが、コード、ストレージ、アカウントは削除されません。

その結果、デプロイ済みコントラクトを破棄して同じCREATE2アドレスに再作成する従来のアップグレード方式は、現在は機能しません。

EIP-6780は、アップグレードにはCREATE2による再デプロイではなく、確立されたプロキシ方式を使うよう明示的に推奨しています。

SELFDESTRUCTは引き続き非推奨であり、新しいシステムはその挙動が今後も変わらないと想定すべきではありません。

メタモーフィックコントラクトのリスク

メタモーフィックコントラクトは、破棄と再デプロイを通じて、安定したアドレスで動作するコードを変更することを意図したものです。

現在のSELFDESTRUCT制限が導入される前は、この方式により、アドレスだけを信頼することが特に危険になり得ました。

ユーザーが一つのコードを確認した後、同じアドレスにある別のコードとやり取りすることになる可能性がありました。

Ethereumの現行ルールでは、長期的な再デプロイ方式は一般に使えなくなりましたが、旧ネットワークや異なるEVM環境ではSELFDESTRUCTの挙動が異なる場合があります。

セキュリティツールは、分析対象となる特定のブロックチェーンとブロック期間のルールを確認する必要があります。

過去のトランザクションは、実行当時に有効だったプロトコルルールに基づいて解釈してください。

CREATE2のガスコスト

CREATE2のガス構造は通常のCREATEと似ていますが、初期化コードのハッシュ化に伴うコストが追加されます。

EIP-1014では、初期化コードの32バイトワード数に応じて追加のハッシュコストが定められています。

初期化コードが大きいほど、アドレス導出に加え、メモリやコンストラクターの実行にも多くのガスが必要になります。

デプロイでは、生成したランタイムバイトコードの保存やコンストラクター処理にもガスがかかります。

ネットワークのガス料金体系はプロトコルアップグレードで変化する可能性があるため、固定のガス見積もりを永続的なものとみなさないでください。

事前に資金を入れた反実仮想アカウントでも、最終的なデプロイ費用を支払うには十分なネイティブ暗号資産または手数料スポンサーが必要となる場合があります。

初期化コードのサイズ制限

Ethereumでは、コントラクトの初期化コードにプロトコル上の制限や計量ルールが適用されます。

EIP-3860では、初期化コードに対する追加のガス計量と最大サイズが導入されました。

このルールはCREATEとCREATE2の両方によるデプロイに適用されます。

大規模なファクトリーは、任意に大きなコンストラクター処理を問題なく送信できると想定すべきではありません。

開発ツールでは、コンパイル後の初期化コードが現在のネットワーク制限を満たすかテストしてください。

バニティコントラクトアドレス

開発者は多数のsaltを試し、予測されるCREATE2アドレスが特定のプレフィックスやパターンを含むまで検索できます。

この処理は、バニティコントラクトアドレスのマイニングと呼ばれます。

短く覚えやすいプレフィックスを使うと、アドレスを視覚的に識別しやすくなります。

それによってスマートコントラクトのセキュリティや権限が高まるわけではありません。

詐欺師は似たプレフィックスやサフィックスを持つアドレスを生成できるため、アドレス全体を確認してください。

バニティアドレスを、バイトコードの検証や信頼できるデプロイ記録の代わりにしてはいけません。

CREATE2とアドレスポイズニング

アドレスポイズニングは、ユーザーの取引履歴やウォレット画面に偽のアドレスを表示し、信頼できるアドレスだと思わせようとする攻撃です。

攻撃者は、信頼されているアドレスに似た文字列を含むアドレスを生成することがあります。

CREATE2を使うと、saltを変えながら検索して、特定の見た目のパターンを持つコントラクトアドレスを探せます。

この攻撃にCREATE2やKeccak-256を破る必要はありません。

アドレスの先頭や末尾だけを確認するユーザーを狙うものです。

暗号資産を送る前に、アドレス全体を確認するか、信頼できるアドレス帳を利用してください。

クロスチェーンでのアドレス混同

同じ16進数のアドレスが、複数のEVMネットワーク上に存在する場合があります。

ネットワークによって、同じコード、異なるコード、またはコードがない状態になる可能性があります。

決定論的デプロイによって同一アドレスを作成できる場合でも、ブロックチェーンの識別情報は欠かせません。

正しいアドレスでもネットワークを間違えて資産を送ると、意図したアプリケーションで利用できなくなることがあります。

ウォレットやインターフェースには、コントラクトアドレスと選択中のネットワークの両方を明確に表示する必要があります。

開発者は、対応する各チェーンでコードハッシュと設定を検証してください。

ファクトリーを信頼するリスク

決定論的なアドレス計算は、選択したファクトリーが想定どおりに動作することを前提としています。

ファクトリーがsaltを変更したり、初期化コードを書き換えたり、アクセス制御を適用したり、手数料を請求したり、デプロイ時の価値を予期せず移転したりする場合があります。

アップグレード可能なファクトリーは、開発者が最初に確認した後で変更される可能性があります。

一つの秘密鍵で管理されるファクトリーは、その鍵の紛失や侵害によって利用できなくなったり、悪意ある動作をしたりするおそれがあります。

パーミッションレスなファクトリーは一部の管理リスクを減らす一方、フロントランニングやスパムの問題を生じさせることがあります。

予測アドレスに依存する前に、ファクトリーのランタイムコードとデプロイ方式を確認してください。

コンパイラとメタデータのリスク

Solidityのコンパイラバージョンが異なると、同じソースコードから別の作成用バイトコードが生成される場合があります。

最適化の実行回数、メタデータ設定、リンク済みライブラリ、対象EVMバージョンなどのコンパイラ設定もバイトコードに影響します。

バイトコードがわずかに異なるだけでも初期化コードのハッシュが変わり、CREATE2アドレスも変わります。

開発者は決定論的デプロイに使うコンパイラのバージョンとビルド設定を固定してください。

再現可能なビルド手順があれば、公開されたソースコードからデプロイ済みバイトコードが生成されることを第三者が検証しやすくなります。

ビルド設定を含めずSolidityソースだけをコピーしても、予測アドレスを再現するには不十分な場合があります。

ライブラリのリンク

Solidityコントラクトには、デプロイ済みライブラリアドレスに置き換える必要があるプレースホルダーが含まれる場合があります。

リンク後の作成用バイトコードは、CREATE2の初期化コードの一部になります。

ライブラリアドレスを変えると、予測されるコントラクトアドレスも変わります。

そのため、リンク済みライブラリが異なるアドレスにある場合、クロスチェーンデプロイで同一アドレスを生成できないことがあります。

複数チェーンで同じアドレスを目指すプロジェクトでは、依存コントラクトをデプロイする前にライブラリを決定論的にデプロイする必要がある場合があります。

CREATE2の検証チェックリスト

予測先を計算する前に、ブロックチェーンとファクトリーアドレスを確認してください。

saltが正確に32バイトでエンコードされていることを確認します。

ランタイムバイトコードではなく、作成用バイトコードを使用してください。

ABIエンコードされたコンストラクター引数を初期化コードに含めます。

コンパイラのバージョン、最適化設定、リンク済みライブラリ、メタデータ設定を固定します。

予測アドレスにすでにコードがあるか、nonceがゼロ以外かを確認します。

ファクトリー呼び出しをシミュレーションし、コンストラクターが外部状態に依存していないか確認します。

デプロイ後、実際のアドレス、ランタイムバイトコード、ストレージ設定、所有者、実装、発行イベントを想定結果と比較してください。

CREATE2のメリット

CREATE2では、デプロイ前にコントラクトアドレスを把握できます。

反実仮想ウォレットや、コード作成前に資産を受け取るコントラクトを実現できます。

ファクトリーの変化するデプロイnonceに依存しません。

必要な入力がすべて一致すれば、互換性のあるEVMネットワーク間で一貫したアプリケーションアドレスを作成できます。

ステートチャネルや紛争解決コントラクトの効率的な設計を支えます。

ウォレット、ソフトウェアライブラリ、スマートコントラクト、マルチチェーンインターフェースでのアドレス管理を簡素化できます。

ユーザーが予測先を独自に検証できる、再現可能なデプロイシステムにも利用できます。

CREATE2の制約

CREATE2は、コントラクトが実際にデプロイされることを保証しません。

ファクトリーが信頼できることや、すべてのネットワークで利用可能であることも保証しません。

複数のチェーンでアドレスが同一でも、ランタイムコードや状態が同一であることは保証されません。

未初期化のプロキシ、安全でないコンストラクター、侵害された管理者、脆弱なスマートコントラクトを保護するものではありません。

宛先にコードまたはゼロ以外のnonceがある場合、既存コントラクトを上書きすることはできません。

現行のSELFDESTRUCTルールにより、長期間存在するコントラクトを破棄して再デプロイする一般的なアップグレード方式は利用できません。

デプロイ入力を十分に検証せず、予測アドレスに資金を送ることによる運用リスクもあります。

よくある質問

CREATE2を簡単に説明すると？

CREATE2は、コントラクトのデプロイ前にスマートコントラクトアドレスを計算できるEVM命令です。

決定論的デプロイとは？

定義された同じデプロイ入力から、同じ計算アドレスが生成されることです。

CREATE2を導入したEIPは？

CREATE2はEIP-1014で導入されました。

CREATE2オペコードとは？

CREATE2オペコードは

です。

CREATE2アドレスを決める入力は？

CREATE2ファクトリーのアドレス、32バイトのsalt、初期化コードのハッシュによって決まります。

CREATE2はnonceを使いますか？

CREATE2のアドレス計算式では、ファクトリーの変化するコントラクト作成nonceを使いません。

トランザクション送信者はCREATE2の計算式に含まれますか？

CREATE2を直接実行するコントラクトが含まれます。通常は、呼び出し元の外部ウォレットではなくファクトリーです。

CREATE2のsaltとは？

saltは、決定論的なデプロイを区別し、異なるアドレスを生成するための32バイト値です。

CREATE2のsaltは秘密にする必要がありますか？

いいえ。通常、saltを秘密にしておく必要はありません。

init codeとは？

init codeは、コンストラクターを実行し、新しいアドレスに保存されるランタイムバイトコードを返す一時的な作成用コードです。

CREATE2はランタイムバイトコードをハッシュ化しますか？

アドレス計算式では最終ランタイムバイトコードのみを直接ハッシュ化するのではなく、初期化コードをハッシュ化します。

コンストラクター引数はCREATE2アドレスを変えますか？

はい。Solidityのコンストラクター引数は初期化コードに含まれるため、通常、予測アドレスが変わります。

オフチェーンでCREATE2アドレスを予測できますか？

はい。ブロックチェーンのトランザクションを送信せずにローカルで計算できます。

未デプロイのCREATE2アドレスで暗号資産を受け取れますか？

はい。コントラクトのデプロイ前でも、予測アドレスはネイティブ暗号資産や対応トークンを受け取れます。

未デプロイアドレスへの送金は安全ですか？

ファクトリー、salt、初期化コード、デプロイ可能性、今後の認可ルールを検証しない限り、リスクがあります。

CREATE2で既存コントラクトを上書きできますか？

いいえ。対象アドレスに空でないコードまたはゼロ以外のnonceがあるとデプロイは失敗します。

CREATE2で同じコントラクトを2回デプロイできますか？

元の宛先が使用中である限り、同じファクトリー、salt、初期化コードでの再デプロイは成功しません。

同じsaltを再利用できますか？

はい。ファクトリーまたは初期化コードのハッシュが異なれば、同じsaltから別のアドレスを生成できます。

CREATE2のデプロイをフロントランニングできますか？

公開ファクトリーの呼び出しをコピーして先にデプロイすることは可能です。実行タイミングが乱れる場合があり、コンストラクターの動作が変化する外部データに依存する場合は危険となることがあります。

CREATE2は複数チェーンで同一コードを保証しますか？

いいえ。同一アドレスには入力の一致が必要ですが、コンストラクターの実行環境、初期化、設定、ネットワーク状態によって重要な違いが生じる場合があります。

CREATE2で複数ネットワーク上に同じアドレスを作る方法は？

互換性のある各ネットワークで、同じファクトリーアドレス、salt、初期化コードのハッシュを使う必要があります。

チェーンIDはCREATE2の計算式に含まれますか？

基本の計算式にはチェーンIDが直接含まれません。ただし、デプロイコードやコンストラクター引数にチェーン固有の情報が含まれる場合があります。

CREATE2ファクトリーとは？

CREATE2ファクトリーは、ユーザーやほかのコントラクトのために決定論的デプロイを実行するスマートコントラクトです。

シングルトンファクトリーとは？

複数ネットワークで既知の同一アドレスに存在することを意図したCREATE2デプロイヤーです。

反実仮想デプロイとは？

コントラクトがまだデプロイされていない段階で、予測可能なコントラクトアドレスを利用または参照することです。

CREATE2はスマートコントラクトウォレットにどう役立ちますか？

ウォレットコントラクトの作成前にアドレスを計算し、資金を受け取れるようにします。

CREATE2とERC-4337の関係は？

ERC-4337のアカウントファクトリーでは、予測可能なスマートコントラクトアカウントのアドレスを導出してデプロイするために、CREATE2がよく使われます。

未デプロイのコントラクトはメッセージに署名できますか？

ERC-6492は、特定の反実仮想コントラクトアカウントに関連する署名を、デプロイ前に検証する方法を提供します。

CREATE2はアップグレードの仕組みですか？

いいえ。アップグレードには別途、プロキシやガバナンスの設計が必要です。

SELFDESTRUCTでコントラクトを消去し、CREATE2で再デプロイできますか？

Ethereumの現行ルールでは、既存コントラクトのコードとストレージは通常保持されるため、長期間存在するコントラクトを破棄して再デプロイするアップグレード方式は利用できません。

メタモーフィックコントラクトとは？

一つのアドレスのコードを、破棄と決定論的な再デプロイによって変更することを意図した旧来の設計です。

CREATE2はCREATEよりガスがかかりますか？

CREATE2では通常の作成、メモリ、コンストラクター、コード保存のコストに加えて、初期化コードのハッシュ化コストが発生します。

CREATE2でバニティアドレスを生成できますか？

はい。予測アドレスが希望する見た目のパターンになるまで、多数のsaltを試せます。

バニティCREATE2アドレスはセキュリティを高めますか？

いいえ。見分けやすいプレフィックスやサフィックスは、コードの安全性、所有権、真正性を証明しません。

予測したCREATE2アドレスとデプロイ結果が異なるのはなぜですか？

ファクトリー、saltのエンコード、コンパイラ出力、リンク済みライブラリ、コンストラクター引数の誤りや、作成用バイトコードとランタイムバイトコードの混同が主な原因です。

CREATE2のデプロイを検証する方法は？

正確な入力からアドレスを再計算し、デプロイ済みのランタイムコード、ストレージ、所有者、実装、イベントを想定値と比較します。

まとめ

CREATE2による決定論的デプロイでは、Ethereum互換のスマートコントラクトがオンチェーン上に存在する前に、そのアドレスを計算できます。

アドレスは、固定プレフィックス、CREATE2ファクトリーのアドレス、32バイトのsalt、初期化コードのハッシュから導出されます。

コンストラクター引数、コンパイラ出力、リンク済みライブラリ、ビルド設定によって初期化コードが変わり、アドレスも変わる場合があります。

CREATE2は、反実仮想スマートアカウント、ステートチャネル、トークンバウンドアカウント、予測可能なアプリケーション構成要素、複数チェーンで同じアドレスを使うデプロイを支えます。

予測アドレスはデプロイ前に暗号資産を受け取れますが、想定したコントラクトを作成できないと、資産を利用できなくなる可能性があります。

複数ネットワークで同じアドレスを使うには、ファクトリー、salt、初期化コードのハッシュを一致させる必要があります。それだけでコード、状態、セキュリティが同一になるわけではありません。

開発者は、初期化関数の保護、環境依存のコンストラクターの回避、ファクトリーの動作確認、フロントランニングリスクへの対処も必要です。

Ethereumの現行SELFDESTRUCTルールにより、長期間存在するコントラクトを破棄し、同じアドレスに再作成する一般的なアップグレード方式は利用できません。

したがってCREATE2は、自動的なセキュリティ対策やアップグレード手段ではなく、アドレス導出とデプロイのためのツールとして扱う必要があります。

入力、ファクトリー、バイトコード、初期化手順を慎重に検証すれば、CREATE2は予測可能で使いやすい暗号資産アプリケーションを構築するための強力な基盤となります。