這是可升級的智能合約:存儲亮點和挑戰(zhàn)系列文章的第一篇。我們將更深入地研究可升級的智能合約、它們的功能和可供開發(fā)人員使用的存儲選項。
這是“可升級的智能合約:存儲亮點和挑戰(zhàn)”系列文章的第一篇。我們將更深入地研究可升級的智能合約、它們的功能和可供開發(fā)人員使用的存儲選項。
可升級的以太坊智能合約
以太坊區(qū)塊鏈上的智能合約是不可變的。一旦部署了智能合約，就不可能更改合約地址的代碼。您可以完全刪除一個合約，或者更準確地說，如果這個函數(shù)最初是用代碼編寫的，那么一個智能合約可能會自我銷毀。一方面，信任問題得到了解決，用戶可以確保一切都完全由算法控制。另一方面，現(xiàn)在修復bug是毫無疑問的。
因此，可升級的以太坊智能合約拯救了我們。等等,什么?我們剛剛說過，以太坊中沒有這樣的合約(不像EOS)。然而，可升級的智能合約是可以模擬的。其思想是智能合約地址和代碼保持不變，代碼將執(zhí)行轉(zhuǎn)發(fā)給另一個合約，然后返回其結(jié)果。在本例中，主智能合約稱為代理。在變量中保存另一個合約地址之后，我們可以像更改合約狀態(tài)一樣輕松地更改它，而代碼仍然是不可變的。最終可以有多個智能合約版本;遷移是通過記錄新版本地址來進行的。
存儲可升級的智能合約狀態(tài)
與任何其他軟件類似，開發(fā)人員必須在發(fā)布新版本時解決數(shù)據(jù)遷移問題。對于代理，智能合約應該存儲在哪里?我們有三種完全不同的方法。
為每個版本分別存儲
第一種方法意味著每個版本分別將其狀態(tài)存儲在自己的存儲中。這確保了最大程度的隔離和控制，排除了沖突，同時增加了將單獨的記錄遷移到存儲中所引起的復雜性和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ù)是可能的，但意義不大。
同時在最新的代幣代碼版本中為當前用戶遷移數(shù)據(jù)和記錄操作結(jié)果，需要調(diào)用能夠更改最新版本狀態(tài)的函數(shù)。因此，對任何其他函數(shù)的進一步調(diào)用都不需要經(jīng)過整個代幣版本鏈。僅允許代理合約調(diào)用更改最新版本狀態(tài)的函數(shù)。
作為數(shù)據(jù)庫的合約
可以建議另一種存儲方式。讓我們看看在傳統(tǒng)的程序中如何處理這個問題。數(shù)據(jù)是從代碼中分離出來的!此外，當涉及到復雜的程序和系統(tǒng)時，數(shù)據(jù)存儲在SQL或NoSQL存儲中。
為此目的編寫的特殊智能合約可以用作存儲。因此，無論當前代幣代碼版本如何，數(shù)據(jù)都將始終保存在此合約的存儲中。這個合約的代碼可以移到庫中，但是現(xiàn)在不在日程上。不需要將數(shù)據(jù)從一個存儲遷移到另一個存儲;相反，存儲訪問權(quán)限從一個版本轉(zhuǎn)移到另一個版本。然而，使用這種類型的存儲并非沒有問題。它將需要定義一個可用于任何版本的代幣智能合約的接口，例如sql或WORD文檔。談到這種存儲類型的示例，請查看EOS表。
讓我們將結(jié)構(gòu)、字段名和數(shù)據(jù)類型統(tǒng)一到數(shù)據(jù)方案中。存儲智能合約代碼可以由靜態(tài)部分(無論當前數(shù)據(jù)模式如何，都不會更改的代碼)和動態(tài)部分(依賴于模式的代碼)組成。動態(tài)部分包含許多樣板代碼，因此自動生成它是有意義的，因為它是在協(xié)議緩沖區(qū)或Apache Thrift中實現(xiàn)的。我碰巧在ETHBerlin hackathon上處理過一個類似的任務，即開發(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)用。應該保護對寫入調(diào)用的訪問，并且只能用于代理協(xié)議。此DB合約的公共代碼可以移動到庫中。
委托調(diào)用并在代理合約中存儲數(shù)據(jù)
最后，第三個選項是在代理合約存儲中存儲數(shù)據(jù)。如果代理是獨立的智能合約，特定的代碼版本如何訪問數(shù)據(jù)?EVM delegatecall特性使其成為可能。它在目標地址執(zhí)行代碼，但是使用執(zhí)行了一個delegatecall指令的合約的存儲。
調(diào)用以前合約版本的函數(shù)沒有什么意義，因為它們只不過是“代碼片段”，所有狀態(tài)都存儲在代理合約中。Delegatecall用于調(diào)用庫合約。庫代碼很容易通過指針定位必要的數(shù)據(jù)。然而，該指令可能對代理合約構(gòu)成潛在威脅。不幸的是，正式的Solidity文檔幾乎沒有警告我們:“如果狀態(tài)變量是通過低級委托訪問的，那么兩個合約的存儲布局必須對齊，以便被調(diào)用的合約能夠正確地按名稱訪問調(diào)用合約的存儲變量。”
結(jié)論
我們研究了可升級的智能合約開發(fā)，并研究了3種數(shù)據(jù)存儲方法。（考拉）
