文章閱讀頁通欄

河南22选5胆拖:存儲可升級的以太坊智能合約

來源: 區塊網 作者:考拉
這是“可升級的智能合約:存儲亮點和挑戰”系列文章的第一篇。我們將更深入地研究可升級的智能合約、它們的功能和可供開發人員使用的存儲選項。 ......
這是“可升級的智能合約:存儲亮點和挑戰”系列文章的第一篇。我們將更深入地研究可升級的智能合約、它們的功能和可供開發人員使用的存儲選項。

可升級的以太坊智能合約

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

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

存儲可升級的智能合約狀態

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

為每個版本分別存儲

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

mapping (address => uint256) private _balances;

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

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;

河南22选5第202期开奖 www.lyedr.com }

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

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

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

作為數據庫的合約

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

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

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

數據項描述如下結構:

struct Cafe {
        string name;
        uint32 latitude;
        uint32 longitude;
        address owner;
    }

我們為GitHub生成一個“驅動程序”。驅動程序調用來自Github的靜態代碼,例如,`CDF.writeString`,`CDF.chunkDataPosition'和其他函數。

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

狀態存儲在用作DB的合約中,并通過調用而不是delegatecall指令調用。應該?;ざ孕慈氳饔玫姆夢?,并且只能用于代理協議。此DB合約的公共代碼可以移動到庫中。

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

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

調用以前合約版本的函數沒有什么意義,因為它們只不過是“代碼片段”,所有狀態都存儲在代理合約中。Delegatecall用于調用庫合約??獯牒莧菀淄ü剛攵ㄎ槐匾氖?。然而,該指令可能對代理合約構成潛在威脅。不幸的是,正式的Solidity文檔幾乎沒有警告我們:“如果狀態變量是通過低級委托訪問的,那么兩個合約的存儲布局必須對齊,以便被調用的合約能夠正確地按名稱訪問調用合約的存儲變量?!?/span>

結論

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

關鍵詞: 以太坊  智能合約  
0/300
?