智能合約可升級模式的優缺點
關於如何實現可升級智能合約等智能合約更新，已經有很多爭論。
我覺得 Proxycontract with Delegate-call是目前最著名的一種。但除此之外，還有其他模式。
因此，我列出了一些最知名的模式的摘要並比較了每個模式。
1.基於Delegatecall的代理模式
最廣為人知的一種。還由OpenZeppelin領導，它分發了出色的工具和開發工具包。代理模式將合約一分為二：一個持有邏輯的合約和一個持有數據的代理合約。在這種模式下，代理合約使用委託呼叫來呼叫邏輯合約。邏輯合約返回的數據將儲存在代理合約中。
- 優點：最靈活的開發團隊可以完全改變契約。這可以在未來實現不可預測的錯誤修復和平滑更新，無需任何使用者參與。
- 缺點：正如trailofbits 部落格中提到的這種模式是最複雜的，可能會對合約造成嚴重損害。實現這一點需要對 EVM 有深入的了解。感謝 OpenZeppelin，他們檢查了這些複雜的任務。但是，完全可升級的合約是否仍然“去中心化”是值得懷疑的。
2.數據分離模式
在trailofbits 部落格中也有介紹。這種模式還分離了數據和邏輯。但是，它們不使用委託呼叫，因此可以通過呼叫將數據儲存在同一合約上的新邏輯合約來實現升級。
- 優點：不使用複雜的委託呼叫函式，不需要對EVM有深入的了解，可以靈活升級。
- 缺點：它仍然使合約變得複雜，而且完全可升級的合約是否仍然是“去中心化的”也是值得懷疑的。
3. 註冊模式
這個模式在Consensys 部落格中介紹過
- 優點：簡單，易於審核。
- 缺點：更換合約時需要仔細考慮如何處理合約數據
4. 通過函式更新
這種模式不是標準化的。每個項目在部署之前都會考慮它們的可升級性，並使某些合約（例如，所有者等變數）可通過函式進行升級。我認為複合金融正在使用這種模式。
- 優點：簡單、易於審計，可以通過最小化可升級性來減少漏洞。
- 缺點：無法處理意外錯誤或錯誤。
感謝您到目前為止的閱讀。所以，我的問題是
- 如果我的解釋有問題，請給我回饋
- 您知道使用其中一種模式的任何活動項目嗎？
- 你覺得還有什麼其他的利弊，或者其他的模式嗎？
OpenZeppelin 使用“非結構化儲存”代理模式。
有關詳細資訊，請參閱文件： https ://docs.openzeppelin.com/sdk/2.5/pattern
代理模式部落格文章 ( https://blog.openzeppelin.com/proxy-patterns/ ) 中的 OpenZeppelin 探討了三種代理模式選項：
- 繼承的儲存
- 永恆的儲存
- 非結構化儲存
可升級的合約可以“去中心化”，具體取決於所使用的治理。
OpenZeppelin SDK 可升級智能合約的升級機制可以由任何類型的治理控制，無論是多重簽名錢包、簡單地址還是複雜的 DAO。
該文件顯示使用多重簽名錢包來管理合約升級： https ://docs.openzeppelin.com/sdk/2.5/upgrades-governance
範例項目
Coinbase 和 Circle 的 USDC 使用 ZeppelinOS（現在稱為 OpenZeppelin SDK）代理模式：https ://github.com/centrehq/centre-tokens
如果您對使用 OpenZeppelin 有任何疑問，可以在社區論壇中提問：https ://forum.openzeppelin.com/
披露：我是 OpenZeppelin 的社區經理
這 4 個是非常知名的模式。
(1) 在分析了基於Delegatecall的方法後，我放棄了，主要有兩個原因： 1. 只能添加新變數，不能刪除或更改現有變數。因此，如果您定義了一個結構，並且您想要更改類型或添加現有欄位，或者您想要刪除變數等……您不能。2. 代理低級。即使你使用 OpenZeppelin，這種模式也會破壞整個程式碼的透明度。我不明白你所說的“去中心化”是什麼意思。我認為情況並非如此。
(2) 我們正在使用數據分離模式。你可以看看ERC930。保持更新數據和模式的靈活性非常好。然而，這讓生活變得更加艱難。邏輯合約需要知道如何處理數據儲存。我們創建了一個映射契約來幫助實現這一點，並創建了一個內部函式來組裝業務對象。
(3) 我認為沒有低級的系統資料庫模式很好。我們在這裡使用它。低級程序集的選項類似於委託呼叫選項。
(4) 這是一種可以在特定情況下使用的有效方法。
我也推薦你看看 1504。我喜歡它引入升級合約的方式。Upgrader 就像數據庫世界中的治理決策和遷移腳本。