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
