可升級的以太坊智能合約

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

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

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

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

為每個版本分別存儲

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

mapping （address =》 uint256） private _balances;

不能直接從新版本中balance調(diào)用;為了實現(xiàn)它，必須首先從以前的版本遷移數(shù)據(jù)。注意，遷移只能執(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;

}

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

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

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

作為數(shù)據(jù)庫的合約

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

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

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

數(shù)據(jù)項描述如下結(jié)構(gòu)：

struct Cafe {

string name;

uint32 laTItude;

uint32 longitude;

address owner;

}

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

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

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

委托調(diào)用并在代理合約中存儲數(shù)據(jù)

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

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

結(jié)論

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