# EIP-3541 禁止以 0xEF
開頭的新智慧合約
# 注意事項
本文並沒有經過作者外的其他審查者審核,因此若內容有誤,請到 issue 區提出問題,我會儘速修改,謝謝。
# 簡介
這個提案的目的很簡單:不允許任何人部署以 0xEF
這個特殊數字開頭的新智慧合約。但對於那些已經存在於以太坊網路上且恰好以 0xEF
開頭的智慧合約則不會受到任何影響,它們仍可照常執行。
# 為什麼要這樣做?
以太坊團隊正在計劃未來推出一種全新的智慧合約格式,「EVM Object Format」(大家簡稱 EOF)。這種新格式的合約會在部署到鏈上時先進行檢查,以減少在鏈上執行時期的檢查成本,同時能提高合約的安全性和效率。
為了確保未來使用這種新格式的所有合約都是經過檢查且安全的,我們需要有辦法區分新舊格式。最簡單的方法就是選一個特殊的「標記」或稱「魔術符號」,就像是一個獨特的印章,放在合約的最前面。
就像操作系統會檢查文件標頭檔來決定如何處理一個文件,以太坊虛擬機(EVM)未來也將通過檢查合約的第一個位元組來確定如何解釋和執行該合約。
我們選擇了 0xEF
這個數字作為標記的第一部分,因為調查顯示,目前以太坊上並沒有任何有效合約是以這個數字開頭。這樣一來,我們就能確保舊合約不會被誤認為是新格式的合約。
如果未來決定不使用這種新格式,這個特殊標記也可以用於其他功能。如果將來完全不需要這個限制了,我們也可以輕鬆地取消它,再次允許以 0xEF
開頭的合約部署。
# 補充資料:二進位格式的標記比較
在二進位格式中,使用魔術標記/特殊標記(magic numbers)來辨別文件類型是很常見的做法。這些標記通常位於文件的開頭,起到「簽名(Signature)」的作用。以下是一些常見的例子:
- Windows 可執行文件 (PE): 以
0x4D5A
("MZ") 開頭 - Linux 可執行文件 (ELF): 以
0x7F 0x45 0x4C 0x46
(0x7F
後跟 "ELF") 開頭 - PDF 文件: 以
0x25 0x50 0x44 0x46
("%PDF") 開頭 - PNG 圖像: 以
0x89 0x50 0x4E 0x47
開頭 - JPEG 圖像: 以
0xFF 0xD8
開頭
Ethereum 選擇以 0xEF
作為 EOF 合約的標記,概念上與這些例子類似,它提供了一種簡單有效的方式來區分新舊格式,並允許 EVM 能依據這個標記進行不同處理。
# 實際的運作方式
這項規定會在特定的區塊(HF_BLOCK
)之後開始生效。從那時起,如果有人嘗試部署一個以 0xEF
開頭的新智慧合約,無論是透過交易還是使用智慧合約中的 CREATE
或 CREATE2
指令,這個部署過程都會直接失敗。
# 補充資料
當建立智慧合約時,會先執行一段叫做「初始化程式碼(initcode)」的程式。這段程式執行完後,會通過
RETURN
指令將最終的合約程式碼傳回,然後這段程式碼會被儲存在區塊鏈上。0xEF
目前在以太坊的程式語言中還沒有被定義具體功能,如果有程式執行到這個指令,會直接停止運行。所以已經存在且以這個指令開頭的合約本來就無法正常運行。如果因為合約程式碼以
0xEF
開頭而導致部署失敗,這種失敗的處理方式和其他部署合約失敗的情況完全相同。特別注意的是,所有為這次操作提供的燃料(gas,以太坊網路的手續費)都會被消耗掉,不會退還。
# 為什麼選擇 0xEF 這個數字?
為什麼選 0xEF
呢?有幾個原因:
0xEF
的英文縮寫不是來自 Ethereum Foundation(以太坊基金會)的縮寫,雖然說謠言都這麼説(/ω\)。0xEF
的英文縮寫看起來像是 Executable Format(可執行格式)的縮寫,很容易記住。- 這個數字目前在以太坊指令集中沒有被指定任何特殊功能。如果我們選擇了已經有特定功能的指令(比如
0xFD
、0xFE
或0xFF
),可能會對現有系統造成更大干擾。 - 研究人員在2021年5月對以太坊上超過1,800萬個合約進行了全面掃描,結果發現:
- 沒有任何合約是以
0xEF
開頭的 - 以
0xFD
開頭的有1個 - 以
0xFE
開頭的有4個 - 以
0xFF
開頭的有12個
- 沒有任何合約是以
所以選擇 0xEF
是影響最小的選項。
# 這個改變會影響現有系統嗎?
這項改變確實是屬於「破壞性(Breaking)」的更新,因為它會讓某些程式碼無法部署到以太坊上。但實際上,影響非常小,因為:
- 已經存在的合約不會受到任何影響
- 以
0xEF
開頭的程式碼其實本來就不能正常運行(因為這個指令目前沒有定義任何功能) - 目前沒有任何正在使用的合約是以
0xEF
開頭的
唯一的限制是,未來不能再部署以 0xEF
開頭、僅用來儲存資料的智慧合約了。