Categories
程式開發

智能合約編寫之 Solidity的設計模式


前 言

隨著區塊鏈技術發展,越來越多的企業與個人開始將區塊鏈與自身業務相結合。

區塊鏈所具有的獨特優勢,例如,數據公開透明、不可篡改,可以為業務帶來便利。但與此同時,也存在一些隱患。數據的公開透明,意味著任何人都可以讀取;不可篡改,意味著信息一旦上鍊就無法刪除,甚至合約代碼都無法被更改。

除此之外,合約的公開性、回調機制,每一個特點都可被利用,作為攻擊手法,稍有不慎,輕則合約形同虛設,重則要面臨企業機密洩露的風險。所以,在業務合約上鍊前,需要預先對合約的安全性、可維護性等方面作充分考慮。

幸運的是,通過近些年Solidity語言的大量實踐,開發者們不斷提煉和總結,已經形成了一些”設計模式”,來指導應對日常開發常見的問題。

智能合約設計模式概述

2019年,IEEE收錄了維也納大學一篇題為《Design Patterns For Smart Contracts In the Ethereum Ecosystem》的論文。這篇論文分析了那些火熱的Solidity開源項目,結合以往的研究成果,整理出了18種設計模式。

這些設計模式涵蓋了安全性、可維護性、生命週期管理、鑑權等多個方面。

智能合約編寫之 Solidity的設計模式 1

接下來,本文將從這18種設計模式中選擇最為通用常見的進行介紹,這些設計模式在實際開發經歷中得到了大量檢驗。

安全性(Security)

智能合約編寫,首要考慮的就是安全性問題。

在區塊鏈世界中,惡意代碼數不勝數。如果你的合約包含了跨合約調用,就要特別當心,要確認外部調用是否可信,尤其當其邏輯不為你所掌控的時候。

如果缺乏防人之心,那些“居心叵測”的外部代碼就可能將你的合約破壞殆盡。比如,外部調用可通過惡意回調,使代碼被反复執行,從而破壞合約狀態,這種攻擊手法就是著名的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字段,使其被任意地重複添加。

攻擊過程的時序圖如下:

智能合約編寫之 Solidity的設計模式 2

在這個例子中,AddService難以獲知調用者的回調邏輯,但依然輕信了這個外部調用,而攻擊者利用了AddService糟糕的代碼編排,導致悲劇的發生。

本例子中去除了實際的業務意義,攻擊後果僅僅是_count值失真。真正的重放攻擊,可對業務造成嚴重後果。比如在統計投票數目是,投票數會被改得面目全非。

打鐵還需自身硬,如果想屏蔽這類攻擊,合約需要遵循良好的編碼模式,下面將介紹兩個可有效解除此類攻擊的設計模式。

Checks-Effects-Interaction – 保證狀態完整,再做外部調用

該模式是編碼風格約束,可有效避免重放攻擊。通常情況下,一個函數可能包含三個部分:

  • 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 – 禁止遞歸

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,修飾符的第一行代碼會拋出錯誤。

可維護性(Maintaince)

在區塊鏈中,合約一旦部署,就無法更改。當合約出現了bug,通常要面對以下問題:

  • 合約上已有的業務數據怎麼處理?
  • 怎麼盡可能減少升級影響範圍,讓其餘功能不受影響?
  • 依賴它的其他合約該怎麼辦?

回顧面向對象編程,其核心思想是將變化的事物和不變的事物相分離,以阻隔變化在系統中的傳播。所以,設計良好的代碼通常都組織得高度模塊化、高內聚低耦合。利用這個經典的思想可解決上面的問題。

Data segregation – 數據與邏輯相分離

了解該設計模式之前,先看看下面這個合約代碼:

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 – 分解合約功能

一個複雜的合約通常由許多功能構成,如果這些功能全部耦合在一個合約中,當某一個功能需要更新時,就不得不去部署整個合約,正常的功能都會受到波及。

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;        
    }    
}

Contract Registry – 跟踪最新合約

在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 Relay – 代理調用最新合約

該設計模式所解決問題與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 = //...;
}

生命週期(Lifecycle)

在默認情況下,一個合約的生命週期近乎無限——除非賴以生存的區塊鏈被消滅。但很多時候,用戶希望縮短合約的生命週期。這一節將介紹兩個簡單模式提前終結合約生命。

Mortal – 允許合約自毀

字節碼中有一個selfdestruct指令,用於銷毀合約。所以只需要暴露出自毀接口即可:

contract Mortal{

    //自毁
    function destroy() public{
        selfdestruct(msg.sender);
    } 
}

Automatic Deprecation – 允許合約自動停止服務

如果你希望一個合約在指定期限後停止服務,而不需要人工介入,可以使用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層。

權限(Authorization)

前文中有許多管理性接口,這些接口如果任何人都可調用,會造成嚴重後果,例如上文中的自毀函數,假設任何人都能訪問,其嚴重性不言而喻。所以,一套保證只有特定賬戶能夠訪問的權限控制設計模式顯得尤為重要。

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修飾符就會先運行並檢測調用者是否與合約擁有者一致,從而將無授權的調用攔截在外。

行為控制(Action And Control)

這類模式一般針對具體場景使用,這節將主要介紹基於隱私的編碼模式和與鏈外數據交互的設計模式。

Commit - Reveal - 延遲秘密洩露

鏈上數據都是公開透明的,一旦某些隱私數據上鍊,任何人都可看到,並且再也無法撤回。

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會監聽該合約,讀取到這個查詢請求後,執行查詢,並調用業務合約響應接口使合約獲取結果。

智能合約編寫之 Solidity的設計模式 3

下面定義了一個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
    }
}

總 結

本文的介紹涵蓋了安全性、可維護性等多種設計模式,其中,有些偏原則性,如Security和Maintaince設計模式;有些是偏實踐,例如Authrization,Action And Control。

這些設計模式,尤其實踐類,並不能涵蓋所有場景。隨著對實際業務的深入探索,會遇到越來越多的特定場景與問題,開發者可對這些模式提煉、昇華,以沉澱出針對某類問題的設計模式。

上述設計模式是程序員的有力武器,掌握它們可應對許多已知場景,但更應掌握提煉設計模式的方法,這樣才能從容應對未知領域,這個過程離不開對業務的深入探索,對軟件工程原則的深入理解。

關於作者

儲雨知,FISCO BCOS 核心開發者。