Consensus
如何修復受“重大變更”影響的已部署合約
Remix 的一位開發人員告訴我，如果已部署的合約發生重大更改，那麼它可能會成為“死”合約。這意味著它在其執行時環境中變得無法訪問。
如果這是真的：作為 Solidity 程序員，我可以做些什麼來為重大更改做準備，以便移植並保留我過去版本的現有契約？
集中我的問題：這是一個關於硬分叉情況下現有合約的向後兼容性的一般問題。
一般來說，乙太坊的未來版本不應破壞現有合約。未來的升級應該尊重現有契約繼續工作的需要。如果他們這樣做了，您就不太可能修復您的契約。
但是，系統的某些方面可能會發生變化，如果您想盡量減少未來協議升級破壞契約的可能性，則應避免依賴這些方面。突然想到的一對：
- 不要試圖通過計算積木來衡量時間。有時人們會建議使用塊號作為時間的代理，因為時間戳的可信度存在一些問題。（有關這些問題的討論，請參閱Solidity: Timestamp dependency, is it possible to do safe?）。但是由於冰河時代，區塊間隔的長度已經發生了變化，並且在向權益證明的過渡過程中可能會發生根本性的變化。
- 不要依賴汽油價格保持不變。Gas 價格在協議中被硬編碼，並列在黃皮書中。但是，它們是根據執行不同操作的大致相對成本來決定的，而這又取決於執行它們的硬體和軟體的性能。已經有一個硬分叉改變了一些操作的價格，這些操作被證明比預期的相對昂貴，使得 DoS 更容易，並且它們很可能在未來重新定價。
最後，如果您能夠在您的合約中創建逃生艙口，它們可以保護您因協議升級和新發現的安全問題而引起的問題。這些通常以額外信任要求的形式進行權衡，但有時權衡是值得的。例如，一些合約賦予開發者或策展人凍結合約並在緊急情況下返還使用者資金的能力。其他人允許批量升級合約邏輯 - 請參閱此答案以討論如何執行此操作：可升級的智能合約