可升級的以太坊智能合約

以太坊區(qū)塊鏈上的智能合約是不可變的。一旦部署了智能合約，就不可能更改合約地址的代碼。您可以完全刪除一個合約，或者更準確地說，如果這個函數最初是用代碼編寫的，那么一個智能合約可能會自我銷毀。一方面，信任問題得到了解決，用戶可以確保一切都完全由算法控制。另一方面，現在修復bug是毫無疑問的。

因此，可升級的以太坊智能合約拯救了我們。等等，什么？我們剛剛說過，以太坊中沒有這樣的合約（不像EOS）。然而，可升級的智能合約是可以模擬的。其思想是智能合約地址和代碼保持不變，代碼將執(zhí)行轉發(fā)給另一個合約，然后返回其結果。在本例中，主智能合約稱為代理。在變量中保存另一個合約地址之后，我們可以像更改合約狀態(tài)一樣輕松地更改它，而代碼仍然是不可變的。最終可以有多個智能合約版本;遷移是通過記錄新版本地址來進行的。

存儲可升級的智能合約狀態(tài)

與任何其他軟件類似，開發(fā)人員必須在發(fā)布新版本時解決數據遷移問題。對于代理，智能合約應該存儲在哪里？我們有三種完全不同的方法。

為每個版本分別存儲

第一種方法意味著每個版本分別將其狀態(tài)存儲在自己的存儲中。這確保了最大程度的隔離和控制，排除了沖突，同時增加了將單獨的記錄遷移到存儲中所引起的復雜性和GAS成本。讓我們假設一個基本的代幣合約正在開發(fā)中。在這種情況下，核心數據就是平衡：

mapping （address =》 uint256） private _balances;

不能直接從新版本中balance調用;為了實現它，必須首先從以前的版本遷移數據。注意，遷移只能執(zhí)行一次。

mapping （address =》 uint256） private _balances;

// previous version of a token smart contract

ERC20 private _previous;

// flag indicates that migration of certain user balance was performed

mapping （address =》 bool） private _migrated;

funcTIon balanceOf（address owner） public view returns （uint256） {

return _migrated［owner］ ？ _balances［owner］ ： _previous.balanceOf（owner）;

}

funcTIon setBalance（address owner， uint256 new_balance） private {

_balances［owner］ = new_balance;

if （！_migrated［owner］）

_migrated［owner］ = true;

}

此時還會出現其他問題：不能根據任何請求立即進行遷移，因為可能需要將數據記錄到存儲中，而且僅在視圖函數中不能使用數據記錄。因此，所有對balance的請求，即使是內部的，都必須通過balanceOf和setBalance函數來執(zhí)行。

在最壞的情況下，對僅限視圖的函數的調用將遍歷整個代幣版本鏈，收集數據，但并不能記錄與最新版本相關的操作結果，因為它們沒有修改權限。從最新版本之外的其他版本調用這些函數是可能的，但意義不大。

同時在最新的代幣代碼版本中為當前用戶遷移數據和記錄操作結果，需要調用能夠更改最新版本狀態(tài)的函數。因此，對任何其他函數的進一步調用都不需要經過整個代幣版本鏈。僅允許代理合約調用更改最新版本狀態(tài)的函數。

作為數據庫的合約

可以建議另一種存儲方式。讓我們看看在傳統(tǒng)的程序中如何處理這個問題。數據是從代碼中分離出來的！此外，當涉及到復雜的程序和系統(tǒng)時，數據存儲在SQL或NoSQL存儲中。

為此目的編寫的特殊智能合約可以用作存儲。因此，無論當前代幣代碼版本如何，數據都將始終保存在此合約的存儲中。這個合約的代碼可以移到庫中，但是現在不在日程上。不需要將數據從一個存儲遷移到另一個存儲;相反，存儲訪問權限從一個版本轉移到另一個版本。然而，使用這種類型的存儲并非沒有問題。它將需要定義一個可用于任何版本的代幣智能合約的接口，例如sql或WORD文檔。談到這種存儲類型的示例，請查看EOS表。

讓我們將結構、字段名和數據類型統(tǒng)一到數據方案中。存儲智能合約代碼可以由靜態(tài)部分（無論當前數據模式如何，都不會更改的代碼）和動態(tài)部分（依賴于模式的代碼）組成。動態(tài)部分包含許多樣板代碼，因此自動生成它是有意義的，因為它是在協議緩沖區(qū)或Apache Thrift中實現的。我碰巧在ETHBerlin hackathon上處理過一個類似的任務，即開發(fā)以太坊柱狀數據存儲原型。

數據項描述如下結構：

struct Cafe {

string name;

uint32 laTItude;

uint32 longitude;

address owner;

}

我們?yōu)镚itHub生成一個“驅動程序”。驅動程序調用來自Github的靜態(tài)代碼，例如，`CDF.writeString`，`CDF.chunkDataPosiTIon‘和其他函數。

正如我已經提到的，該解決方案涵蓋了其他問題，并作為外部存儲操作的一個示例。目前，我所知道的以太網智能合約存儲中沒有SQL / NoSQL存儲的工作實現。對于可變智能合約中的數據存儲問題而言，這似乎是一個很有意思的解決方案。

狀態(tài)存儲在用作DB的合約中，并通過調用而不是delegatecall指令調用。應該保護對寫入調用的訪問，并且只能用于代理協議。此DB合約的公共代碼可以移動到庫中。

委托調用并在代理合約中存儲數據

最后，第三個選項是在代理合約存儲中存儲數據。如果代理是獨立的智能合約，特定的代碼版本如何訪問數據？EVM delegatecall特性使其成為可能。它在目標地址執(zhí)行代碼，但是使用執(zhí)行了一個delegatecall指令的合約的存儲。

調用以前合約版本的函數沒有什么意義，因為它們只不過是“代碼片段”，所有狀態(tài)都存儲在代理合約中。Delegatecall用于調用庫合約。庫代碼很容易通過指針定位必要的數據。然而，該指令可能對代理合約構成潛在威脅。不幸的是，正式的Solidity文檔幾乎沒有警告我們：“如果狀態(tài)變量是通過低級委托訪問的，那么兩個合約的存儲布局必須對齊，以便被調用的合約能夠正確地按名稱訪問調用合約的存儲變量?！?/p>

結論

我們研究了可升級的智能合約開發(fā)，并研究了3種數據存儲方法。下次我們將深入探討委派任務和可能出現的問題。