}
此時還會出現其他問題:不能根據任何請求立即進行遷移，因為可能需要將資料記錄到儲存中，而且僅在檢視函式中不能使用資料記錄。因此，所有對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文件幾乎沒有警告我們:“如果狀態變數是透過低階委託訪問的，那麼兩個合約的儲存佈局必須對齊，以便被呼叫的合約能夠正確地按名稱訪問呼叫合約的儲存變數。”
結論
我們研究了可升級的智慧合約開發，並研究了3種資料儲存方法。下次我們將深入探討委派任務和可能出現的問題。
