想象一下，你正在寫一個(gè)Solidity智能合約，其中一個(gè)屬性可以被描述為類型或狀態(tài)。換句話說，來自一組有限的選項(xiàng)。你馬上對(duì)自己說：“太好了，我只會(huì)使用枚舉類型來表示這個(gè)狀態(tài)變量?！币环矫?，這種方法有一些好處，比如增加可讀性。另一方面，它很容易讓你走上一條可能導(dǎo)致問題的棘手道路。

好吧，如果枚舉（ENUM）成員僅封裝在一個(gè)合約中并且從未在其他文件中提及過，那么一切都可以。 然而DAPP通常由幾個(gè)相互連接的合約組成。當(dāng)相同的枚舉（ENUM）出現(xiàn)時(shí)，我要討論的問題會(huì)出現(xiàn)：

1. 枚舉成員出現(xiàn)在多個(gè)合約中

2. 在DApp生命周期中進(jìn)行修改

例如您有2份合約。第一個(gè)是存儲(chǔ)非常重要的信息。您還聲明了一個(gè)帶有枚舉定義的接口以引用它。

contract IStorage {

enum RecordState {StateA， StateB}

function setState（address user， RecordState newState） public;

}

contract Storage is IStorage {

mapping（address=》RecordState） public states;

constructor（） public {}

funcTIon setState（address user， RecordState newState） public {

states［user］ = newState;

}

}

每個(gè)用戶的記錄都用一個(gè)包含兩個(gè)可能選項(xiàng)的枚舉來表示：statea和stateb。setState函數(shù)可以更改用戶的狀態(tài)。還有另一個(gè)合約，終端用戶應(yīng)該與之交互（為了簡(jiǎn)單起見，我在存儲(chǔ)合約中省略了訪問控制修改器）。

contract StorageUser {

IStorage public recordStorage;

constructor（IStorage _recordStorage） public {

recordStorage = _recordStorage;

}

funcTIon changeStateA（） public {

recordStorage.setState（msg.sender， IStorage.RecordState.StateA）;

}

funcTIon changeStateB（） public {

recordStorage.setState（msg.sender， IStorage.RecordState.StateB）;

}

}

然后將這些合同部署到區(qū)塊鏈。

一切都很好：你調(diào)用changeStateA或changeStateB，并通過自己的setState函數(shù)相應(yīng)地修改存儲(chǔ)合約的數(shù)據(jù)。 但是有一天你意識(shí)到你需要一個(gè)全新的狀態(tài)選項(xiàng)來實(shí)現(xiàn)一些全新的功能。你稱之為Statec（哇！多好的名字?。。?。首先，通過在IStorage中添加新的枚舉成員來修改源代碼…

enum RecordState {StateA， StateB， StateC}

和StorageUser的新方法。

funcTIon changeStateC（） public {

recordStorage.setState（msg.sender， IStorage.RecordState.StateC）;

}

此外，作為一個(gè)負(fù)責(zé)任的開發(fā)人員，您編寫調(diào)用新方法的測(cè)試并報(bào)告成功。您的計(jì)劃是僅重新部署StorageUser合同，并且您不希望重新部署存儲(chǔ)，因此很多重要數(shù)據(jù)都采用映射形式，很難遷移。因此，StorageUser將使用當(dāng)前存儲(chǔ)作為其構(gòu)造函數(shù)參數(shù)進(jìn)行重新部署。你調(diào)用新的changeStateC函數(shù)。..。..它失敗了。

失敗的根源

你看，更新后的StorageUser知道RecordState枚舉的3個(gè)成員，但舊的Storage沒有關(guān)于新的StateC選項(xiàng)的線索。它無法將setState函數(shù)參數(shù)StateC轉(zhuǎn)換為其枚舉版本，因此失敗。

更重要的是，您的測(cè)試可能會(huì)欺騙您，因?yàn)樗麄兪褂昧藘蓚€(gè)合約的更新版本。

實(shí)際上，你甚至可以在官方文件中看到關(guān)于這個(gè)問題的警告。從整數(shù)顯式轉(zhuǎn)換在運(yùn)行時(shí)檢查該值是否在枚舉范圍內(nèi)，否則將導(dǎo)致失敗的斷言。

要吸取的教訓(xùn)

首先，在如上所述的情況下，用普通整數(shù)替換枚舉更好。是的，它們看起來不那么好但結(jié)果結(jié)構(gòu)更可靠和可擴(kuò)展。

其次，不要拋棄使用枚舉字段的整個(gè)想法。 如果這樣的領(lǐng)域只在一個(gè)合約內(nèi)，那絕對(duì)是安全的。 如果您可以確保在修改的情況下完全重新部署使用枚舉的所有合約，這也是安全的。 請(qǐng)記住，當(dāng)枚舉首次從IStorage導(dǎo)入到StorageUser合約時(shí)出現(xiàn)問題，并且只有在修改初始成員后才重新部署后者。

只是不要忘記，如果你真的想在合約中使用枚舉，最好三思而后行。
來源；區(qū)塊鏈研究實(shí)驗(yàn)室?