可升級(jí)的以太坊智能合約

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

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

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

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

為每個(gè)版本分別存儲(chǔ)

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

mapping （address =》 uint256） private _balances;

不能直接從新版本中balance調(diào)用;為了實(shí)現(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;

}

此時(shí)還會(huì)出現(xiàn)其他問題：不能根據(jù)任何請(qǐng)求立即進(jìn)行遷移，因?yàn)榭赡苄枰獙?shù)據(jù)記錄到存儲(chǔ)中，而且僅在視圖函數(shù)中不能使用數(shù)據(jù)記錄。因此，所有對(duì)balance的請(qǐng)求，即使是內(nèi)部的，都必須通過balanceOf和setBalance函數(shù)來執(zhí)行。

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

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

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

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

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

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

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

struct Cafe {

string name;

uint32 laTItude;

uint32 longitude;

address owner;

}

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

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

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

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

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

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

結(jié)論

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