溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
本篇內容介紹了“Solidity的設計模式是什么”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！
2019年，IEEE收錄了維也納大學一篇題為《Design Patterns For Smart Contracts In the Ethereum Ecosystem》的論文。這篇論文分析了那些火熱的Solidity開源項目，結合以往的研究成果，整理出了18種設計模式。
這些設計模式涵蓋了安全性、可維護性、生命周期管理、鑒權等多個方面。
接下來，本文將從這18種設計模式中選擇最為通用常見的進行介紹，這些設計模式在實際開發經歷中得到了大量檢驗。
智能合約編寫，首要考慮的就是安全性問題。
在區塊鏈世界中，惡意代碼數不勝數。如果你的合約包含了跨合約調用，就要特別當心，要確認外部調用是否可信，尤其當其邏輯不為你所掌控的時候。
如果缺乏防人之心，那些“居心叵測”的外部代碼就可能將你的合約破壞殆盡。比如，外部調用可通過惡意回調，使代碼被反復執行，從而破壞合約狀態，這種攻擊手法就是著名的Reentrance Attack（重放攻擊）。
這里，先引入一個重放攻擊的小實驗，以便讓讀者了解為什么外部調用可能導致合約被破壞，同時幫助更好地理解即將介紹的兩種提升合約安全性的設計模式。
關于重放攻擊，這里舉個精簡的例子。
AddService合約是一個簡單的計數器，每個外部合約可以調用AddService合約的addByOne來將字段_count加一，同時通過require來強制要求每個外部合約最多只能調用一次該函數。
這樣，_count字段就精確的反應出AddService被多少合約調用過。在addByOne函數的末尾，AddService會調用外部合約的回調函數notify。AddService的代碼如下：
contract AddService{
uint private _count;
mapping(address=>bool) private _adders;
function addByOne() public {
//強制要求每個地址只能調用一次
require(_adders[msg.sender] == false, "You have added already");
//計數
_count++;
//調用賬戶的回調函數
AdderInterface adder = AdderInterface(msg.sender);
adder.notify();
//將地址加入已調用集合
_adders[msg.sender] = true;
}
}
contract AdderInterface{
function notify() public;
}如果AddService如此部署，惡意攻擊者可以輕易控制AddService中的_count數目，使該計數器完全失效。
攻擊者只需要部署一個合約BadAdder，就可通過它來調用AddService，就可以達到攻擊效果。BadAdder合約如下：
contract BadAdder is AdderInterface{
AddService private _addService = //...;
uint private _calls;
//回調
function notify() public{
if(_calls > 5){
return;
}
_calls++;
//Attention !!!!!!
_addService.addByOne();
}
function doAdd() public{
_addService.addByOne();
}
}BadAdder在回調函數notify中，反過來繼續調用AddService，由于AddService糟糕的代碼設計，require條件檢測語句被輕松繞過，攻擊者可以直擊_count字段，使其被任意地重復添加。
攻擊過程的時序圖如下：
在這個例子中，AddService難以獲知調用者的回調邏輯，但依然輕信了這個外部調用，而攻擊者利用了AddService糟糕的代碼編排，導致悲劇的發生。
本例子中去除了實際的業務意義，攻擊后果僅僅是_count值失真。真正的重放攻擊，可對業務造成嚴重后果。比如在統計投票數目是，投票數會被改得面目全非。
打鐵還需自身硬，如果想屏蔽這類攻擊，合約需要遵循良好的編碼模式，下面將介紹兩個可有效解除此類攻擊的設計模式。
該模式是編碼風格約束，可有效避免重放攻擊。通常情況下，一個函數可能包含三個部分：
Checks：參數驗證
Effects：修改合約狀態
Interaction：外部交互
這個模式要求合約按照Checks-Effects-Interaction的順序來組織代碼。它的好處在于進行外部調用之前，Checks-Effects已完成合約自身狀態所有相關工作，使得狀態完整、邏輯自洽，這樣外部調用就無法利用不完整的狀態進行攻擊了。
回顧前文的AddService合約，并沒有遵循這個規則，在自身狀態沒有更新完的情況下去調用了外部代碼，外部代碼自然可以橫插一刀，讓_adders[msg.sender]=true永久不被調用，從而使require語句失效。我們以checks-effects-interaction的角度審閱原來的代碼：
//Checks require(_adders[msg.sender] == false, "You have added already"); //Effects _count++; //Interaction AdderInterface adder = AdderInterface(msg.sender); adder.notify(); //Effects _adders[msg.sender] = true;
只要稍微調整順序，滿足Checks-Effects-Interaction模式，悲劇就得以避免：
//Checks require(_adders[msg.sender] == false, "You have added already"); //Effects _count++; _adders[msg.sender] = true; //Interaction AdderInterface adder = AdderInterface(msg.sender); adder.notify();
由于_adders映射已經修改完畢，當惡意攻擊者想遞歸地調用addByOne，require這道防線就會起到作用，將惡意調用攔截在外。
雖然該模式并非解決重放攻擊的唯一方式，但依然推薦開發者遵循。
Mutex模式也是解決重放攻擊的有效方式。它通過提供一個簡單的修飾符來防止函數被遞歸調用：
contract Mutex {
bool locked;
modifier noReentrancy() {
//防止遞歸
require(!locked, "Reentrancy detected");
locked = true;
_;
locked = false;
}
//調用該函數將會拋出Reentrancy detected錯誤
function some() public noReentrancy{
some();
}
}在這個例子中，調用some函數前會先運行noReentrancy修飾符，將locked變量賦值為true。如果此時又遞歸地調用了some，修飾符的邏輯會再次激活，由于此時的locked屬性已為true，修飾符的第一行代碼會拋出錯誤。
在區塊鏈中，合約一旦部署，就無法更改。當合約出現了bug，通常要面對以下問題：
合約上已有的業務數據怎么處理？
怎么盡可能減少升級影響范圍，讓其余功能不受影響？
依賴它的其他合約該怎么辦？
回顧面向對象編程，其核心思想是將變化的事物和不變的事物相分離，以阻隔變化在系統中的傳播。所以，設計良好的代碼通常都組織得高度模塊化、高內聚低耦合。利用這個經典的思想可解決上面的問題。
了解該設計模式之前，先看看下面這個合約代碼：
contract Computer{
uint private _data;
function setData(uint data) public {
_data = data;
}
function compute() public view returns(uint){
return _data * 10;
}
}此合約包含兩個能力，一個是存儲數據(setData函數)，另一個是運用數據進行計算(compute函數）。如果合約部署一段時間后，發現compute寫錯了，比如不應是乘以10，而要乘以20，就會引出前文如何升級合約的問題。
這時，可以部署一個新合約，并嘗試將已有數據遷移到新的合約上，但這是一個很重的操作，一方面要編寫遷移工具的代碼，另一方面原先的數據完全作廢，空占著寶貴的節點存儲資源。
所以，預先在編程時進行模塊化十分必要。如果我們將"數據"看成不變的事物，將"邏輯"看成可能改變的事物，就可以完美避開上述問題。Data Segregation（意為數據分離）模式很好地實現了這一想法。
該模式要求一個業務合約和一個數據合約：數據合約只管數據存取，這部分是穩定的；而業務合約則通過數據合約來完成邏輯操作。
結合前面的例子，我們將數據讀寫操作專門轉移到一個合約DataRepository中：
contract DataRepository{
uint private _data;
function setData(uint data) public {
_data = data;
}
function getData() public view returns(uint){
return _data;
}
}計算功能被單獨放入一個業務合約中：
contract Computer{
DataRepository private _dataRepository;
constructor(address addr){
_dataRepository =DataRepository(addr);
}
//業務代碼
function compute() public view returns(uint){
return _dataRepository.getData() * 10;
}
}這樣，只要數據合約是穩定的，業務合約的升級就很輕量化了。比如，當我要把Computer換成ComputerV2時，原先的數據依然可以被復用。
一個復雜的合約通常由許多功能構成，如果這些功能全部耦合在一個合約中，當某一個功能需要更新時，就不得不去部署整個合約，正常的功能都會受到波及。
Satellite模式運用單一職責原則解決上述問題，提倡將合約子功能放到子合約里，每個子合約（也稱為衛星合約）只對應一個功能。當某個子功能需要修改，只要創建新的子合約，并將其地址更新到主合約里即可，其余功能不受影響。
舉個簡單的例子，下面這個合約的setVariable功能是將輸入數據進行計算（compute函數），并將計算結果存入合約狀態_variable：
contract Base {
uint public _variable;
function setVariable(uint data) public {
_variable = compute(data);
}
//計算
function compute(uint a) internal returns(uint){
return a * 10;
}
}如果部署后，發現compute函數寫錯，希望乘以的系數是20，就要重新部署整個合約。但如果一開始按照Satellite模式操作，則只需部署相應的子合約。
首先，我們先將compute函數剝離到一個單獨的衛星合約中去：
contract Satellite {
function compute(uint a) public returns(uint){
return a * 10;
}
}然后，主合約依賴該子合約完成setVariable：
contract Base {
uint public _variable;
function setVariable(uint data) public {
_variable = _satellite.compute(data);
}
Satellite _satellite;
//更新子合約（衛星合約）
function updateSatellite(address addr) public {
_satellite = Satellite(addr);
}
}這樣，當我們需要修改compute函數時，只需部署這樣一個新合約，并將它的地址傳入到Base.updateSatellite即可：
contract Satellite2{
function compute(uint a) public returns(uint){
return a * 20;
}
}在Satellite模式中，如果一個主合約依賴子合約，在子合約升級時，主合約需要更新對子合約的地址引用，這通過updateXXX來完成，例如前文的updateSatellite函數。
這類接口屬于維護性接口，與實際業務無關，過多暴露此類接口會影響主合約美觀，讓調用者的體驗大打折扣。Contract Registry設計模式優雅地解決了這個問題。
在該設計模式下，會有一個專門的合約Registry跟蹤子合約的每次升級情況，主合約可通過查詢此Registyr合約取得最新的子合約地址。衛星合約重新部署后，新地址通過Registry.update函數來更新。
contract Registry{
address _current;
address[] _previous;
//子合約升級了，就通過update函數更新地址
function update(address newAddress) public{
if(newAddress != _current){
_previous.push(_current);
_current = newAddress;
}
}
function getCurrent() public view returns(address){
return _current;
}
}主合約依賴于Registry獲取最新的衛星合約地址。
contract Base {
uint public _variable;
function setVariable(uint data) public {
Satellite satellite = Satellite(_registry.getCurrent());
_variable = satellite.compute(data);
}
Registry private _registry = //...;
}該設計模式所解決問題與Contract Registry一樣，即主合約無需暴露維護性接口就可調用最新子合約。該模式下，存在一個代理合約，和子合約享有相同接口，負責將主合約的調用請求傳遞給真正的子合約。衛星合約重新部署后，新地址通過SatelliteProxy.update函數來更新。
contract SatelliteProxy{
address _current;
function compute(uint a) public returns(uint){
Satellite satellite = Satellite(_current);
return satellite.compute(a);
}
//子合約升級了，就通過update函數更新地址
function update(address newAddress) public{
if(newAddress != _current){
_current = newAddress;
}
}
}
contract Satellite {
function compute(uint a) public returns(uint){
return a * 10;
}
}主合約依賴于SatelliteProxy：
contract Base {
uint public _variable;
function setVariable(uint data) public {
_variable = _proxy.compute(data);
}
SatelliteProxy private _proxy = //...;
}在默認情況下，一個合約的生命周期近乎無限——除非賴以生存的區塊鏈被消滅。但很多時候，用戶希望縮短合約的生命周期。這一節將介紹兩個簡單模式提前終結合約生命。
字節碼中有一個selfdestruct指令，用于銷毀合約。所以只需要暴露出自毀接口即可：
contract Mortal{
//自毀
function destroy() public{
selfdestruct(msg.sender);
}
}如果你希望一個合約在指定期限后停止服務，而不需要人工介入，可以使用Automatic Deprecation模式。
contract AutoDeprecated{
uint private _deadline;
function setDeadline(uint time) public {
_deadline = time;
}
modifier notExpired(){
require(now <= _deadline);
_;
}
function service() public notExpired{
//some code
}
}當用戶調用service，notExpired修飾符會先進行日期檢測，這樣，一旦過了特定時間，調用就會因過期而被攔截在notExpired層。
前文中有許多管理性接口，這些接口如果任何人都可調用，會造成嚴重后果，例如上文中的自毀函數，假設任何人都能訪問，其嚴重性不言而喻。所以，一套保證只有特定賬戶能夠訪問的權限控制設計模式顯得尤為重要。
Ownership
對于權限的管控，可以采用Ownership模式。該模式保證了只有合約的擁有者才能調用某些函數。首先需要有一個Owned合約：
contract Owned{
address public _owner;
constructor() {
_owner = msg.sender;
}
modifier onlyOwner(){
require(_owner == msg.sender);
_;
}
}如果一個業務合約，希望某個函數只由擁有者調用，該怎么辦呢？如下：
contract Biz is Owned{
function manage() public onlyOwner{
}
}這樣，當調用manage函數時，onlyOwner修飾符就會先運行并檢測調用者是否與合約擁有者一致，從而將無授權的調用攔截在外。
這類模式一般針對具體場景使用，這節將主要介紹基于隱私的編碼模式和與鏈外數據交互的設計模式。
鏈上數據都是公開透明的，一旦某些隱私數據上鏈，任何人都可看到，并且再也無法撤回。
Commit And Reveal模式允許用戶將要保護的數據轉換為不可識別數據，比如一串哈希值，直到某個時刻再揭示哈希值的含義，展露真正的原值。
以投票場景舉例，假設需要在所有參與者都完成投票后再揭示投票內容，以防這期間參與者受票數影響。我們可以看看，在這個場景下所用到的具體代碼：
contract CommitReveal {
struct Commit {
string choice;
string secret;
uint status;
}
mapping(address => mapping(bytes32 => Commit)) public userCommits;
event LogCommit(bytes32, address);
event LogReveal(bytes32, address, string, string);
function commit(bytes32 commit) public {
Commit storage userCommit = userCommits[msg.sender][commit];
require(userCommit.status == 0);
userCommit.status = 1; // comitted
emit LogCommit(commit, msg.sender);
}
function reveal(string choice, string secret, bytes32 commit) public {
Commit storage userCommit = userCommits[msg.sender][commit];
require(userCommit.status == 1);
require(commit == keccak256(choice, secret));
userCommit.choice = choice;
userCommit.secret = secret;
userCommit.status = 2;
emit LogReveal(commit, msg.sender, choice, secret);
}
}目前，鏈上的智能合約生態相對封閉，無法獲取鏈外數據，影響了智能合約的應用范圍。
鏈外數據可極大擴展智能合約的使用范圍，比如在保險業中，如果智能合約可讀取到現實發生的意外事件，就可自動執行理賠。
獲取外部數據會通過名為Oracle的鏈外數據層來執行。當業務方的合約嘗試獲取外部數據時，會先將查詢請求存入到某個Oracle專用合約內；Oracle會監聽該合約，讀取到這個查詢請求后，執行查詢，并調用業務合約響應接口使合約獲取結果。
下面定義了一個Oracle合約：
contract Oracle {
address oracleSource = 0x123; // known source
struct Request {
bytes data;
function(bytes memory) external callback;
}
Request[] requests;
event NewRequest(uint);
modifier onlyByOracle() {
require(msg.sender == oracleSource); _;
}
function query(bytes data, function(bytes memory) external callback) public {
requests.push(Request(data, callback));
emit NewRequest(requests.length - 1);
}
//回調函數，由Oracle調用
function reply(uint requestID, bytes response) public onlyByOracle() {
requests[requestID].callback(response);
}
}業務方合約與Oracle合約進行交互：
contract BizContract {
Oracle _oracle;
constructor(address oracle){
_oracle = Oracle(oracle);
}
modifier onlyByOracle() {
require(msg.sender == address(_oracle));
_;
}
function updateExchangeRate() {
_oracle.query("USD", this.oracleResponse);
}
//回調函數，用于讀取響應
function oracleResponse(bytes response) onlyByOracle {
// use the data
}
}“Solidity的設計模式是什么”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
