OpenZeppelin 可昇級合約插件 7/9 不同網路的設定檔
不同網路的設定檔 Network Files
OpenZeppelin 可昇級合約會持續追綜已經部署的合約，透過在根目錄底下的 .openzeppelin 資料夾內的設定檔，以及代理合約管理員。在 .openzeppelin 資料夾裡面，每個網路會有一個設定檔。建議把所有的設定檔案都納入源碼的版本控制，除了正在開發的這個設定檔。可以看到這些檔案大約長成 ./openzeppelin/unknown-*.json
注意：./openzeppelin 資料夾不相容於 OpenZeppelin CLI , 下一篇會說明如何使用 OpenZeppelin CLI 專案來部署。
<network_name>.json
OpenZeppelin 可昇級合約插件會建立設定檔，每個使用的網路都會建立一個，像是 mainnet , ropsten 各會有自己的設定檔，結構如下
// .openzeppelin/.json
{
"manifestVersion": "3.0",
"impls": {
"...": {
"address": "...",
"txHash": "...",
"layout": {
"storage": [...],
"types": {...}
}
},
"...": {
"address": "...",
"txHash": "...",
"layout": {
"storage": [...],
"types": {...}
}
}
},
"admin": {
"address": "...",
"txHash": "..."
}
}
每個一邏輯合約都會追蹤，除了部署地址會追蹤之外，以下的欄位也會追蹤
types 所有在合約內使用的類型，包括基本類型如 uint256 到自定義的 struct 類型(前面的文件說不能使用？)
storage 追蹤同一條線上合約的存儲的順序及規則(代理及委派的邏輯合約)。引用 type 欄位定義的類型，用於驗証後續版本之間的任何存儲順序及規則的變化是否相容。
檔案名稱 <network_name>.json ，注意這裡的 network_name 不是 Truffle 或是 Buidler 檔定檔內的網路名稱，而是從 chain id 來的。
這裡有個公鏈上的命名規則，如果鏈沒有被收錄官方列表，像是 Ethereum Classic ，就以 unknown-<chain_id>.json 的方式命名
設定檔和版本管理
公鏈的設定檔像是 mainnet.json 或是 ropsten.json 應該被納入版本控制。這些包括專案在想應網路中的狀態，這些信息是很有用的。像是合約各版本被部署後的地址。
然而本地的私有鏈像是 unknow-.json 只有表示專案開發時的私有鏈像是 ganache-cli 只跟單一貢獻者有關的就不用納入版本管理。
以下是 .gitignore 的參考範例
// .gitignore # OpenZeppelin .openzeppelin/unknown-*.json
參考
https://docs.openzeppelin.com/upgrades-plugins/1.x/network-files
