確定性部署（CREATE2）

什麼是確定性部署（CREATE2）？

確定性部署（CREATE2）是 Ethereum Virtual Machine（EVM）的一種方法，讓開發者能在部署智能合約之前，先計算出合約地址。

此方法使用 EVM 操作碼

，其操作碼值為 。

透過 CREATE2 部署的合約，其地址取決於部署合約、開發者指定的 salt，以及合約初始化程式碼的雜湊值。

這與一般合約部署不同；一般部署產生的地址通常取決於部署者地址和 nonce。

由於 CREATE2 不會使用部署者持續變動的部署 nonce，即使工廠合約期間已建立其他合約，開發者仍可預測相同地址。

這項特性可支援反事實智能帳戶、可預測的協議元件、跨鏈應用程式基礎架構、狀態通道，以及在部署前即可接收加密貨幣的合約。

最終版 EIP-1014 CREATE2 規格定義了操作碼、地址公式、Gas 計算方式、碰撞處理方式，以及最初提出反事實部署的動機。

CREATE2 不會自動讓合約變得安全、永久、去中心化，也不會讓合約在所有區塊鏈上都完全相同。

它只提供一種確定性方法，根據指定輸入推導部署地址。

為什麼 CREATE2 被稱為確定性部署？

若相同輸入總是產生相同輸出，這個過程就具有確定性。

對 CREATE2 而言，相關輸出是智能合約地址。

相關輸入包括 CREATE2 部署者地址、32-byte salt，以及初始化程式碼的雜湊值。

任何知道這些輸入的人，都能在不提交區塊鏈交易的情況下計算未來地址。

該地址不受部署時間、目前區塊高度，或工廠合約先前建立的合約數量影響。

只要更改地址公式中的任何一項輸入，預測出的地址就會不同。

因此，即使合約程式碼尚未上鏈，仍可事先規劃或引用該合約、向其地址轉入資產，或在簽署訊息中納入該地址。

CREATE2 地址公式

CREATE2 地址使用以下公式計算：

是 1-byte 前綴，用於將 CREATE2 地址與一般 CREATE 公式產生的地址區分開來。

是直接執行 CREATE2 操作碼之合約的 20-byte 地址。

是提供給 CREATE2 操作的 32-byte 值。

是建立合約時執行的初始化程式碼。

初始化程式碼會先經過雜湊，再納入最終的 85-byte CREATE2 雜湊輸入。

最終 Keccak-256 雜湊值的最後 20 bytes 會成為合約地址。

由於預測結果不會改變區塊鏈狀態，因此可以在本機計算公式，不必支付網路手續費。

什麼是 CREATE2 部署者？

CREATE2 部署者是直接呼叫 CREATE2 操作碼的智能合約。

這類合約常稱為工廠合約、部署合約、確定性部署代理合約或單例工廠。

向工廠合約發送交易的外部擁有帳戶，不會自動成為 CREATE2 公式中使用的地址。

通常應使用工廠合約的地址作為部署者地址，因為實際執行操作碼的是工廠合約。

即使 salt 和初始化程式碼完全相同，只要使用不同工廠，預測出的合約地址也會不同。

因此，開發者必須確認工廠地址正確，不能只根據提交交易的錢包計算結果。

工廠合約可能允許任何人部署任意初始化程式碼，也可能只允許核准帳戶和合約範本進行部署。

工廠合約的權限和實作方式可能影響預測地址是否真的能部署合約。

什麼是 CREATE2 salt？

CREATE2 salt 是納入確定性地址計算的任意 32-byte 值。

salt 讓工廠合約能以相同初始化程式碼部署多個合約，同時為每個合約指定不同地址。

salt 可由使用者識別碼、錢包地址、帳戶編號、代幣識別碼、應用程式版本、隨機值，或多個欄位組合推導而來。

salt 不需要保密。

只要知道工廠、salt 和初始化程式碼，任何人都能計算出相同地址。

開發者應明確定義 salt 的編碼方式，避免編碼不一致而產生非預期地址。

例如，數字

、包含 的文字字串，以及以 結尾的 32-byte 值，可能會被軟體以不同方式解讀。

專案可以對結構化資料進行雜湊，產生固定的 32-byte salt，避免編碼方式不明確。

什麼是初始化程式碼？

初始化程式碼（通常簡稱 init code）是在建立智能合約時執行的臨時 EVM 程式碼。

它負責執行建構函式邏輯，並回傳將保留在新地址中的執行階段位元組碼。

初始化程式碼本身通常不會做為合約的永久程式碼儲存。

CREATE2 公式會以初始化程式碼的雜湊值作為依據。

在 Solidity 中，完整初始化程式碼通常包括合約建立位元組碼，以及以 ABI 編碼的建構函式參數。

Solidity 目前的 salt 合約建立文件確認，地址取決於建立位元組碼和建構函式參數。

更改建構函式參數會改變初始化程式碼的雜湊值，因此也會改變預測地址。

計算 CREATE2 地址時，開發者必須使用預定部署所需的確切編譯器輸出和建構函式編碼。

初始化程式碼與執行階段位元組碼的差異

初始化程式碼和執行階段位元組碼彼此相關，但並不相同。

初始化程式碼只會在部署期間執行一次。

部署完成後，執行階段位元組碼會儲存在合約地址中。

CREATE2 地址公式直接以初始化程式碼的雜湊值為依據，而不是最終執行階段程式碼的雜湊值。

這項差異帶來一個重要的安全考量。

建構函式可以讀取外部區塊鏈狀態，並據此決定要建立哪種執行階段程式碼或初始儲存值。

因此，即使初始化程式碼相同，在不同外部條件下執行時，也可能產生不同的部署行為。

若開發者希望建立更強的行為承諾，應避免使用依賴環境的建構函式，或在部署後驗證產生的執行階段程式碼和儲存內容。

建構函式參數與 CREATE2

在 Solidity 部署中，建構函式參數屬於初始化程式碼的一部分。

若合約的 owner 地址設為

，其 CREATE2 地址通常會與 owner 地址設為 的相同合約不同。

代幣名稱、供應量、實作地址、驗證者清單、費用設定及其他建構函式輸入，也適用相同規則。

開發者必須按照合約 ABI 預期的順序和格式編碼建構函式參數。

如果地址預測工具未納入建構函式參數，計算結果就會錯誤。

部署後呼叫的初始化函式不會影響 CREATE2 公式，除非初始化呼叫本身納入建構函式或工廠流程。

若部署和初始化分開進行，而初始化函式未受到保護，其他帳戶可能搶先呼叫，導致合約遭接管。

CREATE 與 CREATE2

CREATE 和 CREATE2 都是用來建立智能合約的 EVM 操作。

一般 CREATE 主要根據建立帳戶及其部署 nonce 推導新地址。

部署者每建立一個合約，nonce 就會增加。

因此，若要預測 CREATE 地址，開發者必須知道正確的部署順序。

CREATE2 以工廠地址、salt 和初始化程式碼雜湊值取代以 nonce 為基礎的地址公式。

CREATE2 不會改變建構函式程式碼的基本執行方式，也不會改變回傳的執行階段位元組碼的儲存方式。

它改變的是目標地址的推導方式，並增加初始化程式碼的雜湊成本。

若目標地址違反 EVM 的合約建立碰撞規則，這兩種操作都會失敗。

CREATE2 何時推出？

CREATE2 於 2018 年在 EIP-1014 中提出規格。

它被納入 Ethereum 的 Constantinople 網路升級。

Constantinople 升級規格將 EIP-1014 列為該次升級納入的協議變更之一。

此後，CREATE2 已成為 EVM 的成熟功能，並受到 Solidity 和常用開發工具支援。

EVM 相容網路在啟用相應協議行為後，可能支援 CREATE2。

開發者應確認網路相容性，不應假設所有使用類 EVM 環境的區塊鏈都採用完全相同的規則。

Solidity 中的 CREATE2

Solidity 提供高階語法，方便透過 CREATE2 部署合約。

工廠合約可以使用

語法。

Solidity 編譯器會準備建立位元組碼、編碼建構函式參數，並產生 CREATE2 操作。

使用

選項時，可付款建構函式也能在部署期間接收區塊鏈原生貨幣。

工廠合約應確認部署回傳的地址非零，且符合預期。

若需要直接控制初始化程式碼的記憶體、長度、salt 和附帶金額，開發者也可以透過 inline assembly 呼叫 CREATE2。

Inline assembly 會增加實作風險，因此應仔細測試。

簡化版 Solidity CREATE2 範例

在此範例中，預測的子合約地址取決於工廠地址、salt、Child 建立位元組碼，以及經編碼的

參數。

若這些輸入沒有改變，僅更換外部呼叫者不一定會改變地址。

更改

則會改變地址，因為建構函式參數屬於初始化程式碼的一部分。

預測 CREATE2 地址

開發者可以在智能合約、部署腳本、錢包或本機應用程式中計算 CREATE2 地址。

計算時必須使用實際執行 CREATE2 的確切工廠地址。

也必須使用 salt 最終的 32-byte 表示形式。

初始化程式碼雜湊值必須納入確切的建立位元組碼，以及經編碼的建構函式參數。

部署後，應將預測地址與工廠合約回傳的地址比對。

如果預測地址與實際地址不同，部署工具應拒絕繼續執行。

常見的預測錯誤包括：使用執行階段位元組碼而非建立位元組碼、未納入建構函式參數、選錯工廠，或 salt 編碼錯誤。

什麼是反事實部署？

反事實部署是指在智能合約尚未部署程式碼前，就將其未來地址視為有效地址使用。

參與者可以先計算地址，並事先同意合約預期使用的初始化程式碼。

他們可以向該地址轉入資產、在其他合約中引用該地址，或建立與該地址相關的簽署授權。

只有在確實需要執行時，才部署合約。

這種方式可以避免立即提交部署交易，並降低初期使用成本。

EIP-1014 最初著重於狀態通道的反事實互動：只有在參與者發生爭議時，才可能需要合約。

如今，反事實部署也在智能合約錢包和帳戶抽象中扮演重要角色。

反事實智能合約帳戶

智能合約帳戶可以在帳戶合約部署前，先擁有可預測的 CREATE2 地址。

使用者可以分享該地址，也可能在該地址收到加密貨幣或代幣。

接著，第一次帳戶操作可以在同一個整體流程中部署錢包並執行動作。

如此一來，使用者不必先另外提交錢包建立交易，才能接收資產。

ERC-4337 帳戶抽象規格支援在帳戶尚不存在時，根據工廠初始化資料建立發送者智能合約帳戶。

帳戶工廠常使用 CREATE2，確保發送者地址能在部署前計算出來。

並非所有帳戶抽象設計都必須使用 CREATE2，因為較新的授權和帳戶模型可能採用其他機制。

向尚未部署的地址轉入加密貨幣

尚未部署的 CREATE2 地址可以接收區塊鏈原生加密貨幣，因為地址不需要有執行階段程式碼也能持有餘額。

只要代幣合約允許一般地址轉帳，也可以將同質化或非同質化代幣轉入預測地址。

即使該地址目前沒有合約程式碼，資產仍會記錄在該地址之下。

預定合約成功部署後，這些資產可能就能使用。

這項特性可簡化錢包導入流程和反事實應用程式設計。

但也伴隨重大風險：若預定工廠、salt 或初始化程式碼有誤，資產可能會無法取用。

向反事實地址轉入有實質價值的資產前，使用者應確認合約確實能夠部署。

空的 CREATE2 地址可以持有資金嗎？

可以。沒有程式碼的地址仍可持有原生加密貨幣和代幣。

只有正餘額本身，不會阻止 CREATE2 在該地址部署合約。

EVM 碰撞規則關注的是目標地址是否具有非零 nonce 或非空程式碼。

這項設計是為了讓反事實帳戶可以在部署前接收資金。

部署後，合約程式碼和授權規則會決定如何使用這些資產。

CREATE2 碰撞規則

若目標地址已有非空程式碼或非零 nonce，CREATE2 部署就會失敗。

這可避免工廠合約覆寫同一地址上的既有合約。

即使新的初始化程式碼原本會正確計算出該地址，這項規則仍然適用。

若初始化程式碼執行時還原（revert）、Gas 耗盡、回傳無效程式碼，或違反其他合約建立規則，部署也會失敗。

工廠合約應處理 CREATE2 操作碼回傳零值的情況，並盡可能提供清楚的錯誤訊息。

碰撞不代表 Keccak 雜湊函式遭到破解。

通常只是表示依確定性規則推導出的目標地址，已依 EVM 帳戶規則被占用。

兩次不同部署可能產生相同的 CREATE2 地址嗎？

若兩次部署使用相同的工廠地址、salt 和初始化程式碼雜湊值，計算出的地址就會相同。

不同初始化程式碼在理論上可能產生相同雜湊值，但在目前安全假設下，要找到實際可用的 Keccak-256 碰撞，被認為在計算上不可行。

由於地址只使用最後 20 bytes，隨機地址碰撞在理論上仍有可能，與其他 Ethereum 地址相同。

以目前的運算能力而言，刻意製造指定碰撞仍不切實際。

不過，開發者仍不應將外觀相似的地址視為部署輸入正確的證明。

重複使用 salt

若初始化程式碼不同，工廠合約可以重複使用相同 salt，因為初始化程式碼雜湊值不同，會產生不同地址。

只要原目標地址仍被占用，同一工廠就無法用相同 salt 和相同初始化程式碼成功部署第二次。

專案可以在應用程式層禁止重複使用 salt，讓部署目的更容易追蹤。

公開工廠可能允許任何人提交已使用過的 salt，因為完整公式也納入了初始化程式碼雜湊值。

單靠 salt 唯一性並不能構成完整的安全保障。

必須一併檢視工廠、salt 和初始化程式碼的完整組合。

CREATE2 部署的搶先交易風險

尚未納入區塊的 CREATE2 待處理交易可能會被其他人看見。

其他使用者可能複製工廠呼叫，並嘗試搶先部署合約。

若免許可工廠使用相同 salt 和完全相同的初始化程式碼，複製的部署理應在相同預測地址建立具有相同程式碼承諾的合約。

原始交易之後可能因目標地址已被占用而失敗。

即使如此，仍可能造成時程問題、浪費 Gas，或干擾應用程式流程。

若建構函式行為會讀取變動的環境資訊，例如區塊資料、交易來源、外部合約狀態，或依呼叫者而異的工廠參數，風險會更加嚴重。

目前的確定性工廠提案建議，完全確定性的合約應使用廣為人知的工廠，而不是依執行環境決定結果的部署方式。

建構函式遭搶先交易的風險

CREATE2 地址會依據初始化程式碼，但不會固定建構函式可能讀取的所有外部狀態。

若攻擊者能控制部署時機，就可能使建構函式讀取到不同的價格、區塊值、註冊表項目或外部合約狀態。

產生的執行階段程式碼或初始儲存內容，可能因此與原使用者預期不同。

只要實際可行，建構函式應透過已納入承諾的建構函式參數接收關鍵設定，而非讀取可變動的外部狀態。

部署腳本應在建立合約後驗證執行階段位元組碼、所有權、儲存內容和發出的事件。

未受保護的初始化函式風險

代理合約和最小代理合約常使用初始化函式，而非建構函式。

初始化函式會在部署後設定所有權、權限、實作細節或其他重要狀態。

可預測 CREATE2 地址並不會自動保護初始化函式。

若部署和初始化分別在不同交易中執行，攻擊者可能搶先呼叫初始化函式。

工廠合約應在部署交易中原子化初始化合約，或強制採用嚴格的授權機制。

確定性地址無法彌補未受保護的初始化設計。

CREATE2 工廠

CREATE2 工廠是可重複使用的智能合約，會接收 salt 和初始化程式碼，並執行 CREATE2 操作碼。

使用工廠可讓外部擁有帳戶和其他智能合約，透過一致介面使用確定性部署功能。

簡易工廠可能允許任何人提交任意程式碼，而不要求權限。

專用工廠則可能只部署核准的帳戶實作或應用程式模組。

開發者應檢查工廠的執行階段位元組碼、部署紀錄、權限、失敗處理方式和價值轉移行為。

惡意工廠可能更改輸入、限制部署、扣留資金，或執行非預期程式碼。

單例工廠

單例工廠是一種確定性工廠，目標是在多個 EVM 網路上部署至相同地址。

共用工廠地址有助於開發者在每個支援的網路上推導出相同的子合約地址。

ERC-2470 提議建立免許可的 CREATE2 單例工廠，供確定性部署使用。

該提案採用無金鑰部署方法，讓工廠可以在相容網路上建立於已知地址。

截至 2026 年 7 月，ERC-2470 在 EIP 儲存庫中標記為 Stagnant，但更廣泛的確定性工廠概念仍具有重要意義。

提案在儲存庫中的狀態，與合約在實際環境中的部署狀態是兩回事。

多鏈確定性部署

CREATE2 可協助在多個 EVM 網路上將合約部署至相同地址。

要在各網路上得到相同結果，必須使用相同的 CREATE2 工廠地址、salt 和初始化程式碼雜湊值。

若應用程式部署者錢包呼叫的是不同工廠地址，僅使用同一個錢包並不足以得到相同結果。

編譯器中繼資料、函式庫連結、建構函式參數和合約原始碼變更，都可能改變初始化程式碼雜湊值。

基本 CREATE2 公式不會直接納入 chain ID。

不過，建構函式或部署工具可能納入特定鏈的資料，進而改變初始化程式碼或部署狀態。

即使地址相同，開發者仍應在每個網路上分別驗證部署程式碼。

在多條鏈上部署至相同地址有何用途？

合約地址一致，可減少錢包、介面、軟體函式庫和其他合約必須儲存的地址數量。

開發者可以在多個支援的網路上使用同一個地址常數。

使用者也比較不容易從錯誤的網路複製合約地址。

智能合約帳戶也可以在多條鏈上使用一致的地址。

這能改善易用性，但若某個網路上的同一地址部署了不同程式碼或設定，也可能讓人產生錯誤的安全感。

評估地址時，應一併確認鏈識別碼和經驗證的位元組碼。

目前的確定性工廠提案

隨著更多 EVM 網路和 Rollup 建立，確定性工廠基礎設施也持續發展。

截至 2026 年 7 月，EIP-7997 處於 Review 階段，提議正式要求在 EVM 鏈上的指定地址部署廣泛使用的確定性工廠。

此提案尚未定案，不應視為對所有網路都適用的普遍保證。

ERC-7955 仍是 Draft 提案，內容是透過 EIP-7702 功能，以免許可方式啟動通用 CREATE2 工廠。

這些提案旨在解決 CREATE2 本身無法確保原始工廠在所有地方都位於相同地址的問題。

依賴通用工廠前，開發者應確認提案目前狀態和實際網路狀態。

CREATE2 與帳戶抽象

帳戶抽象讓智能合約帳戶能使用可程式化的驗證和執行規則。

錢包可以支援多個簽署者、Passkey、復原監護人、支出上限、批次操作和手續費代付。

CREATE2 讓錢包工廠能在部署錢包合約前計算帳戶地址。

使用者可以先在該地址收款，並在處理第一次操作時部署帳戶。

ERC-4337 可以納入工廠資料，在發送者尚不存在時建立帳戶。

帳戶的反事實地址必須與工廠呼叫產生的地址相符。

若工廠將程式碼部署到其他位置，帳戶操作就會在該標準的驗證流程中失敗。

CREATE2 與部署前簽章

反事實合約帳戶可能需要在部署前簽署驗證訊息。

由於該地址沒有執行階段程式碼，一般合約簽章驗證無法呼叫該帳戶。

ERC-6492 定義了一種包裝格式，用於驗證代表部署前合約帳戶所簽署的訊息。

驗證流程可以模擬或執行必要的工廠部署，再檢查合約的簽章邏輯。

此標準建議使用 CREATE2 合約，因為其地址可以預測。

反事實帳戶的簽章應透過適用的合約簽章標準驗證，不應視為一般外部擁有帳戶簽章。

CREATE2 與代幣綁定帳戶

代幣綁定帳戶是與非同質化代幣相關聯的智能合約帳戶。

該帳戶可以持有加密貨幣、代幣、NFT 和其他鏈上資產。

ERC-6551 使用 CREATE2，讓代幣綁定帳戶地址在部署前就能以反事實方式存在。

如此一來，即使尚未有人支付費用部署帳戶合約，資產仍可先轉入代幣的帳戶。

依照標準規則，帳戶地址取決於註冊表、實作、salt、區塊鏈識別碼、代幣合約和代幣識別碼。

通常由控制該帳戶的 NFT 所有權決定誰能透過代幣綁定帳戶執行操作。

CREATE2 與狀態通道

狀態通道讓參與者在鏈下反覆互動，同時使用區塊鏈合約執行最終結果或處理爭議。

參與者可以事先同意爭議合約的程式碼和地址。

CREATE2 讓他們無須立即部署合約，也能計算該地址。

鏈下流程進行期間，他們可以引用這個反事實合約。

只有在需要執行強制處理時，才必須部署合約。

這是 EIP-1014 描述的原始使用情境之一。

CREATE2 與最小代理合約

最小代理合約是一種小型合約，會將呼叫委派給實作合約。

工廠可以結合最小代理合約和 CREATE2，建立可預測的帳戶或應用程式地址。

實作地址可能屬於代理合約初始化程式碼的一部分。

因此，更改實作地址可能會改變預測的代理地址。

有些工廠會在同一筆交易中，將初始化參數寫入已部署代理合約的儲存空間。

開發者必須確認確定性承諾涵蓋的是實作、初始化資料，還是只有通用代理外殼。

CREATE2 與可升級合約

CREATE2 本身不是升級系統。

若合約使用代理或其他明確的升級架構，就可以透過 CREATE2 部署為可升級合約。

在此設計中，代理合約維持在確定性地址，而其實作參照可能會改變。

代理管理員、治理規則、延遲時間和實作驗證方式，決定升級安全性。

確定性代理地址不代表行為不可變。

使用者應檢查升級權限，不應假設可預測地址就代表程式碼永久不變。

CREATE2、SELFDESTRUCT 與重新部署

早期的 CREATE2 設計有時會使用

移除合約，之後再於相同地址部署不同行為。

這類設計通常稱為變形合約（metamorphic contracts）。

Ethereum 目前的 EIP-6780 SELFDESTRUCT 規則通常會阻止長期存在的合約刪除其程式碼和儲存內容。

若呼叫 SELFDESTRUCT 的合約並非在同一筆交易中建立，該操作只會轉移餘額，不會刪除程式碼、儲存內容或帳戶。

因此，過去依賴摧毀已部署合約，再於相同 CREATE2 地址重新建立合約的一般升級模式，已無法運作。

EIP-6780 明確建議使用成熟的代理升級設計，而非透過 CREATE2 重新部署來實現升級。

SELFDESTRUCT 仍已棄用，新系統不應依賴其行為永遠維持不變。

變形合約風險

變形合約的設計目的是透過銷毀和重新部署，在穩定地址上更換執行程式碼。

在目前的 SELFDESTRUCT 限制生效前，這種模式可能使依地址建立信任特別危險。

使用者可能先確認某個版本的程式碼，之後卻在相同地址與不同程式碼互動。

Ethereum 目前的規則已阻止一般長期合約重新部署模式，但較早期的網路或不同 EVM 環境，可能採用不同的 SELFDESTRUCT 行為。

安全工具應依據所分析的特定區塊鏈和區塊時期規則進行評估。

解讀歷史交易時，應依交易發生當時有效的協議規則判斷。

CREATE2 Gas 成本

CREATE2 的 Gas 結構與一般 CREATE 類似，但會額外收取初始化程式碼的雜湊成本。

EIP-1014 定義，這項額外雜湊成本取決於初始化程式碼包含多少個 32-byte 區塊。

因此，初始化程式碼越大，地址推導所需的 Gas 越多，記憶體操作和建構函式執行也會消耗更多 Gas。

部署還需支付儲存產生的執行階段位元組碼，以及執行建構函式操作的費用。

網路 Gas 費率表可能因協議升級而改變，因此固定 Gas 預估不應視為永久適用。

已預先注資的反事實帳戶，最終部署時仍可能需要足夠的原生加密貨幣，或由手續費代付服務支付費用。

初始化程式碼大小限制

Ethereum 對合約初始化程式碼設有協議限制和計量規則。

EIP-3860 引入額外的 init code 計量方式和初始化程式碼大小上限。

這些規則同時適用於 CREATE 和 CREATE2 部署。

大型工廠不應假設任意大小的建構函式邏輯都能成功提交。

開發工具應依目前網路限制測試最終編譯出的初始化程式碼。

自訂智能合約地址

開發者可以反覆搜尋不同 salt，直到預測的 CREATE2 地址包含所需的前綴或樣式。

這個過程稱為挖掘自訂智能合約地址。

容易辨識的短前綴可讓地址在視覺上更容易辨認。

這不會提升智能合約的安全性或權限。

使用者應確認完整地址，因為詐騙者可能生成前綴或後綴相似的地址。

自訂地址不能取代位元組碼驗證和可信的部署紀錄。

CREATE2 與地址投毒

地址投毒會試圖讓欺騙性地址出現在使用者的交易紀錄或錢包介面中。

攻擊者可能生成字元看起來與可信地址相似的地址。

透過變更 salt，CREATE2 可協助搜尋具有指定視覺樣式的合約地址。

此類攻擊不需要破解 CREATE2 或 Keccak-256。

它利用的是使用者只檢查地址開頭或結尾的習慣。

轉出加密貨幣前，使用者應確認完整地址，或使用可信的地址簿系統。

跨鏈地址混淆

相同的十六進位地址可以存在於多個 EVM 網路上。

該地址在不同網路上可能具有相同程式碼、不同程式碼，或完全沒有程式碼。

確定性部署計畫可以建立相同地址，但區塊鏈識別碼仍然不可忽略。

若將資產轉至錯誤網路上的正確地址，可能無法透過預期的應用程式取用資產。

錢包和介面應清楚顯示合約地址及所選網路。

開發者應在每條支援的鏈上驗證程式碼雜湊值和設定。

工廠信任風險

確定性地址計算以所選工廠會依預期運作為前提。

工廠可能更改 salt、修改初始化程式碼、套用存取控制、收取費用，或以非預期方式轉移部署金額。

可升級工廠可能在開發者初次審查後改變。

由單一私鑰控制的工廠，可能因金鑰遺失或遭入侵而無法使用，甚至執行惡意行為。

免許可工廠可降低部分控制風險，但也可能帶來搶先交易和垃圾訊息問題。

依賴預測地址前，開發者應驗證工廠執行階段程式碼及其部署方式。

編譯器與中繼資料風險

不同 Solidity 編譯器版本，可能會從相同原始碼產生不同的建立位元組碼。

最佳化執行次數、中繼資料設定、連結函式庫和目標 EVM 版本等編譯器設定，也可能改變位元組碼。

位元組碼只要有些微差異，就會產生不同的初始化程式碼雜湊值和 CREATE2 地址。

開發者應固定確定性部署所使用的編譯器版本和建置設定。

可重現的建置流程有助於獨立使用者確認已發布的原始碼會產生與部署內容相符的位元組碼。

若只複製 Solidity 原始碼而未取得建置設定，可能不足以重現預測地址。

函式庫連結

Solidity 合約可能包含佔位符，部署前必須替換為已部署函式庫的地址。

連結完成的建立位元組碼會成為 CREATE2 初始化程式碼的一部分。

更改函式庫地址會改變預測的合約地址。

因此，若連結函式庫在不同鏈上的地址不同，跨鏈部署可能無法產生相同地址。

希望在多條鏈上使用相同地址的專案，可能需要先確定性地部署函式庫，再部署相依合約。

CREATE2 驗證檢查清單

計算預測地址前，請確認區塊鏈和工廠地址。

確認 salt 的確切 32-byte 編碼。

使用建立位元組碼，而非執行階段位元組碼。

在初始化程式碼中納入以 ABI 編碼的建構函式參數。

固定編譯器版本、最佳化設定、連結函式庫和中繼資料設定。

確認預測地址是否已有程式碼或非零 nonce。

模擬工廠呼叫，並檢視建構函式是否依賴外部狀態。

部署後，請將實際地址、執行階段位元組碼、儲存設定、owner、實作和發出的事件，與預期結果逐一比對。

CREATE2 的優點

CREATE2 讓合約地址能在部署前就被得知。

它支援反事實錢包和可在程式碼建立前接收資產的合約。

它不再依賴工廠持續變動的部署 nonce。

當所有必要輸入都相同時，它可在相容的 EVM 網路上建立一致的應用程式地址。

它支援高效率的狀態通道和爭議合約設計。

它可簡化錢包、軟體函式庫、智能合約和多鏈介面中的地址管理。

它也支援可重現的部署系統，讓使用者能獨立驗證預期地址。

CREATE2 的限制

CREATE2 不保證合約一定會成功部署。

它不保證工廠可信，也不保證工廠在每個網路上都可使用。

它不保證不同鏈上的相同地址會具有相同執行階段程式碼或狀態。

它無法保護未初始化的代理、不安全的建構函式、遭入侵的管理員或有漏洞的智能合約。

若目標地址已有程式碼或非零 nonce，就不能覆寫該地址上的既有合約。

目前的 SELFDESTRUCT 規則會阻止一般長期合約透過銷毀再部署的方式升級。

若使用者在尚未充分驗證部署輸入前，就向預測地址轉入資金，也會產生操作風險。

常見問題

簡單來說，什麼是 CREATE2？

CREATE2 是一種 EVM 指令，讓開發者能在部署智能合約前計算其地址。

確定性部署是什麼意思？

確定性部署表示相同且明確定義的部署輸入，會產生相同的計算合約地址。

哪個 EIP 引入了 CREATE2？

CREATE2 是透過 EIP-1014 引入的。

CREATE2 操作碼是什麼？

CREATE2 操作碼是

。

哪些輸入會決定 CREATE2 地址？

地址取決於 CREATE2 工廠地址、32-byte salt 和初始化程式碼的雜湊值。

CREATE2 會使用 nonce 嗎？

CREATE2 的地址公式不會使用工廠持續變動的合約建立 nonce。

交易發送者會納入 CREATE2 公式嗎？

公式會納入直接執行 CREATE2 的合約，通常是工廠，而非呼叫工廠的外部錢包。

什麼是 CREATE2 salt？

salt 是用來區分確定性部署並產生不同地址的 32-byte 值。

CREATE2 salt 需要保密嗎？

不需要，通常無須對 salt 保密。

什麼是 init code？

Init code 是臨時建立程式碼，會執行建構函式，並回傳儲存在新地址中的執行階段位元組碼。

CREATE2 會雜湊執行階段位元組碼嗎？

地址公式雜湊的是初始化程式碼，而非只直接雜湊最終執行階段位元組碼。

建構函式參數會改變 CREATE2 地址嗎？

會。Solidity 建構函式參數會納入初始化程式碼，通常會改變預測地址。

可以在鏈下預測 CREATE2 地址嗎？

可以，無須提交區塊鏈交易，就能在本機計算地址。

尚未部署的 CREATE2 地址可以接收加密貨幣嗎？

可以。合約部署前，預測地址可以接收原生加密貨幣和相容代幣。

向尚未部署的地址轉入資金安全嗎？

除非已確認工廠、salt、初始化程式碼、部署可行性和未來授權規則，否則這麼做有風險。

CREATE2 可以覆寫既有合約嗎？

不可以。若目標地址已有非空程式碼或非零 nonce，部署就會失敗。

CREATE2 可以部署相同合約兩次嗎？

只要原目標地址仍被占用，相同工廠、salt 和初始化程式碼就無法成功部署第二次。

可以重複使用相同 salt 嗎？

可以。如果工廠或初始化程式碼雜湊值不同，相同 salt 可以產生不同地址。

有人可以搶先部署 CREATE2 合約嗎？

有人可能複製公開的工廠呼叫並搶先部署，造成時程干擾；若建構函式行為依賴變動的外部資料，風險可能更高。

CREATE2 能保證不同鏈上的程式碼完全相同嗎？

不能。相同地址需要相同輸入，但建構函式環境、初始化、設定和網路狀態仍可能造成重要差異。

CREATE2 如何在多個網路上建立相同地址？

每個相容網路都必須使用相同的工廠地址、salt 和初始化程式碼雜湊值。

chain ID 是 CREATE2 公式的一部分嗎？

基本公式不會直接納入 chain ID，但部署程式碼或建構函式參數可能包含特定鏈的資訊。

什麼是 CREATE2 工廠？

CREATE2 工廠是為使用者或其他合約執行確定性部署的智能合約。

什麼是單例工廠？

單例工廠是 CREATE2 部署者，目標是在多個網路上都部署於已知且相同的地址。

什麼是反事實部署？

反事實部署是指在合約尚未部署前，先使用或引用可預測的合約地址。

CREATE2 如何協助智能合約錢包？

它讓錢包合約建立前就能計算錢包地址並向該地址注資。

CREATE2 與 ERC-4337 有何關聯？

ERC-4337 帳戶工廠常使用 CREATE2 推導並部署可預測的智能合約帳戶地址。

尚未部署的合約可以簽署訊息嗎？

ERC-6492 提供一種方法，可在部署前驗證與特定反事實合約帳戶相關的簽章。

CREATE2 是升級機制嗎？

不是。可升級性需要另外設計代理架構或治理機制。

SELFDESTRUCT 可以清除合約，讓 CREATE2 重新部署嗎？

Ethereum 目前的規則通常會保留既有合約的程式碼和儲存內容，因此長期合約透過銷毀再部署的升級模式已無法運作。

什麼是變形合約？

變形合約是一種較早期的設計，目的是透過銷毀和確定性重新部署，在同一地址更換程式碼。

CREATE2 的 Gas 費用比 CREATE 高嗎？

除了一般合約建立、記憶體、建構函式和程式碼儲存成本外，CREATE2 還會額外收取初始化程式碼的雜湊費用。

CREATE2 可以產生自訂地址嗎？

可以。開發者可以測試大量 salt，直到預測地址符合所需的視覺樣式。

自訂 CREATE2 地址能提升安全性嗎？

不能。容易辨認的前綴或後綴無法證明程式碼安全、所有權或真實性。

為什麼我預測的 CREATE2 地址與部署結果不同？

常見原因包括工廠選錯、salt 編碼錯誤、編譯器輸出不同、連結函式庫不同、建構函式參數錯誤，或混淆建立位元組碼和執行階段位元組碼。

如何驗證 CREATE2 部署？

使用確切輸入重新計算地址，並將已部署的執行階段程式碼、儲存內容、owner、實作和事件與預期值比對。

結語

透過 CREATE2 進行確定性部署，可在 Ethereum 相容智能合約尚未上鏈前，先計算其地址。

該地址由固定前綴、CREATE2 工廠地址、32-byte salt 和初始化程式碼雜湊值推導而來。

建構函式參數、編譯器輸出、連結函式庫和建置設定都可能改變初始化程式碼，進而改變地址。

CREATE2 支援反事實智能帳戶、狀態通道、代幣綁定帳戶、可預測的應用程式元件，以及多鏈同地址部署。

預測地址可以在部署前接收加密貨幣，但若預定合約無法建立，資產可能會無法取用。

不同網路上的地址要相同，必須使用相同工廠、salt 和初始化程式碼雜湊值；但這不會自動保證程式碼、狀態或安全性完全一致。

開發者也必須保護初始化函式、避免依賴環境的建構函式、驗證工廠行為，並考量搶先交易風險。

Ethereum 目前的 SELFDESTRUCT 規則，會阻止一般系統透過銷毀長期存在的合約，再於相同地址重新建立合約來實現升級。

因此，CREATE2 應視為地址推導和部署工具，而非自動提供安全性或升級功能的解決方案。

若能仔細驗證其輸入、工廠、位元組碼和初始化流程，CREATE2 就能為可預測且易於使用的加密貨幣應用程式提供強大基礎。