契約變更登記處
如果我有一個智能合約儲存在第 10 塊，當我更改此合約的狀態時，更改後的合約將儲存在下一個塊中，或者合約的狀態將儲存在第 10 塊中（在這種情況下，舊狀態會被抹去嗎？）
這在概念上是關閉的。可能隱藏的假設是修改程式碼是一種選擇。
我將解釋預設條件，然後介紹一些前衛的解決方法。
預設情況
合約是不可變的。你不能修改它們。如果您可以任意更改它們，那麼它們將不是契約。契約產生的大部分信任是知道沒有人，甚至作者都不能改變任何事情。
即使是很小的缺陷也可能產生不小的後果，這意味著需要重新關注質量保證，因為在契約發布後更改一行程式碼可能很困難或不可能。
工作流程
不用說，在開始和開發過程中總是有大量的迭代。主網不是實驗的地方。您可以使用一個節點設置諸如 ganache 和私有鏈之類的工具是合適的。當您認為它已準備好公開亮相時，您可以在測試網上進行部署。當您在主網上發布合約時，這些都是隆重場合的前兆。通常，這為程式碼的進一步發展關閉了大門。它被描述為發射宇宙飛船。從那時起，船上的一切就變得遙不可及。
新契約是新實例
您可以使用相同的原始碼來部署同一合約的另一個版本。它擁有自己的地址並遵循相同的邏輯。它不會取代或乾擾原件。在某些情況下，使用者群已遷移到新實例。這通常涉及讀取原始數據集的完整數據集，將數據寫入新實現並將使用者重定向到新合約。這可能會令人困惑和有爭議。
可升級合約
可升級合約有多種方法。模組化設計是一個好的開始。合約可以保存組件合約的地址並來回傳遞消息。地址是數據 (
address myServantl)，因此它們可能是可變的，並且可用於創建工作流以進行可能的升級。永恆儲存模式將不可變數據與潛在可修改的邏輯合約分開。ENS 名稱服務可以幫助區分哪些邏輯合約是“官方的”。
有些代理合約模式使用不可升級的入口點，該入口點將所有操作委託給使用
DELEGATECALL.庫和模組化設計的無數其他組合是可能的。
TL; 博士;
在您設計升級過程的範圍內，契約是可升級的。預設情況下，僅附加 Universe 中不存在可升級性。
元問題
大多數可升級模式意味著特權使用者可以決定隨意更改合約規則。這意味著重新引入非平凡程度的集中化。看看這個：https ://medium.com/consensys-diligence/upgradeability-is-a-bug-dba0203152ce
無需信任的升級
無信任升級模式嚴重限制了作者的權限。
owner特權使用者（或組織，或 DAO）只能提議升級，而不是（出於某種原因）為每個人做出決定的合約。個人使用者決定他們是否願意接受它。如果升級解決了重大問題或實質性改善問題，這是一個解決方案。如果作者希望每個人都切換到竊取他們的錢的新版本，則預計使用者會拒絕它。它允許一些使用者想要升級而一些使用者不想要的情況。作為軟體架構師，您的任務是在這些選項中為您的項目選擇最佳的屬性組合。例如，許多案例不應該是可升級的。考慮一個價值代幣。如果可以更改規則，這可能是一個缺陷。在其他情況下，使用者同時使用不同版本的邏輯是不明智的。在某些情況下，無需信任將為生產程式碼的定期迭代提供升級路徑。
https://github.com/rob-Hitchens/TrustlessUpgrades
在一切都無法改變的基礎上進行，然後仔細考慮理由和方法，特別是在決定使用哪些可升級模式時應該存在的權限和權限限制。
希望能幫助到你。