本文主要說明以太坊的注冊表合約、代理合約、繼承的存儲可升級性，以及更多的可升級性方法。
在軟件工程中，當發(fā)現(xiàn)新的bug和安全風險時，通常會對它們進行修補，并實時推送更新的版本。在智能合約開發(fā)中，可升級性并不是那么簡單。因此，我們必須采取不同的做法。
以太坊仍處于起步階段，關于如何升級智能合約版本的爭議很多，但我們將介紹一些當今最好的選擇。
注意：智能合約版本的可升級性仍然是研究的活躍領域。以下任何一種方法都可能由于濫用或新發(fā)現(xiàn)的漏洞而導致智能合約失敗。
智能合約可升級性的基本方法
在這里，我們將介紹一些更平易近人但不太適合的智能合約可升級性解決方案。盡管這些不是最佳方法，但它們是當今使用的核心。
注冊合約
注冊表合約可能是最簡單的可升級性方法，但是在這種方法，簡單性帶來了一些嚴重的缺陷。
它使用兩個智能合約的工作：注冊表合約和邏輯合約。注冊表協(xié)定僅用于將用戶指向邏輯協(xié)定的當前版本。每當邏輯合約被升級時，注冊表合約的所有者就可以更新邏輯合約被升級的地址。
contract SomeRegister {
address backendContract;
address［］ previousBackends;
address owner;
function SomeRegister（） {
owner = msg.sender;
}
modifier onlyOwner（） {
require（msg.sender == owner）
_;
}
funcTIon changeBackend（address newBackend） public
onlyOwner（）
returns （bool）
{
if（newBackend ！= backendContract） {
previousBackends.push（backendContract）;
backendContract = newBackend;
return true;
}
return false;
}
}
這種方法是非常不利的，因為當用戶想要使用合約時，他們必須首先查找當前地址。否則可能導致資金損失。將數(shù)據(jù)遷移到新合約中也非常困難，因此必須仔細考慮此過程以避免失敗。
代理合約
代理合約用于將數(shù)據(jù)和調(diào)用轉(zhuǎn)發(fā)到邏輯合約。使用代理合約，用戶可以始終調(diào)用相同的合約地址，并且將其簡單地轉(zhuǎn)發(fā)到當前邏輯合約。
這種方法通過使用DELEGATECALL操作碼來工作。DELEGATECALL是EVM提供的用于程序集的操作碼。它的工作方式與普通調(diào)用類似，只是目標地址的代碼是在調(diào)用協(xié)定的上下文中執(zhí)行的。這意味著像“msg.sender”和“msg.value”這樣的值將被保留。實際上，DELEGATECALL允許目標協(xié)定代表被調(diào)用方進行調(diào)用。
contract Relay {
address public currentVersion;
address public owner;
modifier onlyOwner（） {
require（msg.sender == owner）;
_;
}
funcTIon Relay（address initAddr） {
currentVersion = initAddr;
owner = msg.sender; // this owner may be another contract with mulTIsig， not a single contract owner
}
funcTIon changeContract（address newVersion） public
onlyOwner（）
{
currentVersion = newVersion;
}
function（） {
require（currentVersion.delegatecall（msg.data））;
}
}
盡管這種方法避免了與注冊表合同有關的問題，但它也有其自身的問題。 例如如果管理不當，數(shù)據(jù)存儲很容易失敗。如果新合約的存儲布局與以前的合約不同，則數(shù)據(jù)可能已損壞。此實現(xiàn)還防止您從函數(shù)接收返回值，從而限制了其用例。
儲存合約
與以前的方法一樣，此方法需要您的邏輯合約以及輔助合約。在這種情況下，輔助合約是永久存儲合約。該技術通過分離邏輯和數(shù)據(jù)來起作用。邏輯合約可以隨時升級，并且由于數(shù)據(jù)存儲在外部，因此您的數(shù)據(jù)受到保護。
當然，這種方法也存在根本缺陷。如果在存儲合約中發(fā)現(xiàn)錯誤或漏洞，則在不破壞當前數(shù)據(jù)存儲的情況下無法對其進行升級。 這種方法的另一個問題是邏輯協(xié)定需要使用額外的氣體來進行外部調(diào)用以查看或修改數(shù)據(jù)。
更合適的升級方法
現(xiàn)在讓我們來看看一些更復雜、更合適的智能合約升級方法。
繼承的存儲可升級性
這種技術使用三種不同的合約：代理合約來委托調(diào)用并充當永久存儲；邏輯合約將處理數(shù)據(jù)；還有存儲合約。代理合約和邏輯合約都繼承自存儲合約，因此它們的存儲引用是對齊的。
當邏輯合約更新時，我們只需要更改代理合約所指向的位置即可使用僅管理員功能。由于代理和邏輯協(xié)定具有相同的存儲指針，因此無需進行外部調(diào)用即可查看和修改數(shù)據(jù)。
不幸的是，這種方法也有其自身的陷阱。由于代理合約和存儲合約都是永恒的，因此，如果在任何一個合約中發(fā)現(xiàn)錯誤或漏洞，都無法修復。 因此務必仔細考慮您的代理和存儲結構。
非結構化存儲可升級性
非結構化存儲可能是當前最大的可升級性方法，它使我們能夠利用存儲中狀態(tài)變量的布局。此方法僅需要兩個合約-代理合約和實施合約-實施合約包含數(shù)據(jù)和存儲。
該技術的工作原理是將可升級性所需的數(shù)據(jù)保存在存儲中的固定位置，以防止被新數(shù)據(jù)覆蓋。我們可以使用SLOAD和SSTORE操作碼進行匯編。由于存儲插槽只是從0x0開始遞增，因此我們使用很高的存儲插槽來防止覆蓋 我們可以通過對常量變量進行散列來生成存儲槽。 由于恒定狀態(tài)變量不會占用存儲空間，因此我們不必擔心它會被覆蓋。
bytes32 private constant implementationPosition =
keccak256（“org.zeppelinos.proxy.implementation”）;
由于代理不再從存儲合約繼承而來，因此我們現(xiàn)在也可以更新存儲，從而防止存儲錯誤/漏洞變成災難性的。 但是在升級實施合約時，我們必須繼承以前的合約。由于不需要更改實施合約，因此該方法甚至可以與現(xiàn)有合約一起使用。
盡管這可能是當前可升級性最好的方法，但也有不少批評。代理所有者擁有巨大的權力，并且需要一定程度的信任。對于更復雜的系統(tǒng)，這可能也不是合適的解決方案。
升級依賴于構造函數(shù)的合約
當使用依賴于構造函數(shù)的合約來設置一些初始狀態(tài)時，與代理工作并不太簡單。由于構造函數(shù)只運行一次，而代理不知道邏輯合約構造函數(shù)中設置的值，因此我們需要一種方法在代理中初始化其中的一些值。
創(chuàng)建邏輯合約后，EVM會丟棄構造函數(shù)，因此我們不能簡單地重用代碼。相反，我們必須采取獨特的方法來解決此問題。
初始化函數(shù)
一種可能的替代方法是在常規(guī)函數(shù)中使用構造函數(shù)代碼。我們只需確保這個函數(shù)（我們將調(diào)用初始化函數(shù)）只能運行一次。
contract Initializable {
/**
* @dev Indicates that the contract has been initialized.
*/
bool private initialized;
/**
* @dev Indicates that the contract is in the process of being initialized.
*/
bool private initializing;
/**
* @dev Modifier to use in the initializer function of a contract.
*/
modifier initializer（） {
require（initializing || ！initialized， “Contract instance has already been initialized”）;
bool wasInitializing = initializing;
initializing = true;
initialized = true;
_;
initializing = wasInitializing;
}
}
在使用初始值設定項函數(shù)時，必須打起十二分精神?？紤]邏輯合約繼承的基本合約也很重要。這部分特別復雜，因為Solidity也支持多重繼承。
結論
確保智能合約是可升級的，并仔細考慮可升級過程，這兩點都很重要。雖然這并不是一個關于智能合約可升級性的選項的詳盡列表，但這應該是關于這個主題的適當指南。
下載文檔
