前言
近年來，加密貨幣和區塊鏈技術在業界和學術界獲得了巨大的歡迎和關注。截至2017年底，加密貨幣市場總資本已達到6000億左右。區塊鏈最初被提出用於在沒有信任的網絡對等體之間進行價值轉移。后來，有許多增強的區塊鏈平台支持智能合約。其中最受歡迎的是以太坊，它使用圖靈完整的編程語言增強了區塊鏈平台，允許開發人員編寫智能合約和去中心化應用程序。
根據區塊鏈不可篡改的特性，一旦合約被成功部署到以太坊主網絡，如果合約出現安全漏洞，要想更改此合約將會變成一件很麻煩的事情，所以在合約被部署之前提前測試保證其上線之后能夠穩定運行是一件非常重要的事情。
本工程實踐項目旨在開發一套用於檢測智能合約漏洞的系統。系統提取用戶部署合約的ABI接口和方法簽名，並在合約運行的同時檢測EVM來記錄智能合約運行時行為，並分析這些日志來報告安全漏洞。
一、項目設計方案
1.1 層次化軟件架構
層次系統組織成一個層次結構，每一層為上層服務，並作為下層客戶。在一些層次系統中，除了一些精心挑選的輸出函數外，內部的層只對相鄰的層可見。這樣的系統中構件在一些層實現了虛擬機（在另一些層次系統中層是部分不透明的）。連接件通過決定層間如何交互的協議來定義，拓撲約束包括對相鄰層間交互的約束。
這種風格支持基於可增加抽象層的設計。這樣，允許將一個復雜問題分解成一個增量步驟序列的實現。由於每一層最多只影響兩層，同時只要給相鄰層提供相同的接口，允許每層用不同的方法實現，同樣為軟件重用提供了強大的支持。
本項目主要定義了以下三個層次
- 應用層：部署運行合約並收集交易數據
- 轉發層：將底層數據轉發到以太坊客戶端
- 數據生成：根據合約ABI的接口生成合適的測試數據
軟件架構圖如下：
1.2 中介者模式
中介者模式是用一個中介對象來封裝一系列的對象交互，中介者使各對象不需要顯式地相互引用，從而使其耦合松散，而且可以獨立地改變它們之間的交互。例如，MVC模式中control就是model和view的中介者。
該模式優點有：
-
松散耦合、將多個對象之間的聯系緊耦合封裝到中介對象中，做到松耦合。不會導致一動牽全身。
-
將多個對象之間的交互聯系集中在中介對象中。發送變化僅需修改中介對象即可、提供系統的靈活性、使同事對象獨立而易於復用。
-
符合迪米特原則。就是說一個對象應當對其他對象有盡可能少的了解。減少各個對象之間的了解。
本項目主要包含三個模塊：geth（以太坊客戶端）、tester（測試器）、fuzz（混淆器），其中tester作為中介者正好可以對其他兩個模塊進行解耦，使得每個模塊專注於自身功能實現，而不必依賴於其他類的對象。
結構圖如下：
二、數據庫設計
用戶表：
| 字段名 | 類型 | 說明 |
|---|---|---|
| id | int | 用戶識別號 |
| name | string | 用戶名 |
| type | int | 用戶賬戶類型 |
| hash | string | 用戶賬戶密碼hash |
合約表：
| 字段名 | 類型 | 說明 |
|---|---|---|
| abi | string | abi對象描述符 |
| status | string | 合約運行狀態 |
| balance | int | 合約賬戶余額 |
| hash | string | 合約文件hash |
ABI接口表：
| 字段名 | 類型 | 說明 |
|---|---|---|
| name | string | abi名稱 |
| method_sig | string | 合約內置方法簽名 |
| input | string | 函數輸入類型 |
| output | string | 函數輸出類型 |
三、項目的目錄文件結構及重要接口API
3.1 目錄文件結構
fuzz模糊測試生成器模塊：
tester測試模塊：
3.2 重要接口API
四、項目視圖
4.1 分解視圖
分解是構建軟件架構模型的關鍵步驟，分解視圖也是描述軟件架構模型的關鍵視圖，一般分解視圖呈現為較為明晰的分解結構特點。分解視圖用軟件模塊勾划出系統結構，往往會通過不同抽象層級的軟件模塊形成層次化的結構。
分解視圖中常見的模塊有：子系統、包、類、庫等等
4.2 依賴視圖
依賴視圖展現了軟件模塊之間的依賴關系。比如一個軟件模塊A調用了另一個軟件模塊B，那么我們說軟件模塊A直接依賴軟件模塊B。如果一個軟件模塊依賴另一個軟件模塊產生的數據，那么這兩個軟件模塊也具有一定的依賴關系。
4.3 泛化視圖
泛化視圖展現了軟件模塊之間的一般化或具體化的關系，典型的例子就是面向對象分析和設計方法中類之間的繼承關系。值得注意的是，采用對象組合替代繼承關系，並不會改變類之間的泛化特征。因此泛化是指軟件模塊之間的一般化或具體化的關系，不能局限於繼承概念的應用。
泛化視圖有助於描述軟件的抽象層次，從而便於軟件的擴展和維護。比如通過對象組合或繼承很容易形成新的軟件模塊與原有的軟件架構兼容。
4.4 執行視圖
執行視圖展示了系統運行時的時序結構特點，比如流程圖、時序圖等。執行視圖中的每一個執行實體，一般稱為組件（Component），都是不同於其他組件的執行實體。如果有相同或相似的執行實體那么就把它們合並成一個。
4.5 工作分配視圖
工作分配視圖將系統分解成可獨立完成的工作任務，以便分配給各項目團隊和成員。工作分配視圖有利於跟蹤不同項目團隊和成員的工作任務的進度，也有利於在個項目團隊和成員之間合理地分配和調整項目資源，甚至在項目計划階段工作分配視圖對於進度規划、項目評估和經費預算都能起到有益的作用。
4.6 部署視圖
部署視圖是將執行實體和計算機資源建立映射關系。這里的執行實體的粒度要與所部署的計算機資源相匹配，比如以進程作為執行實體那么對應的計算機資源就是主機，這時應該描述進程對應主機所組成的網絡拓撲結構，這樣可以清晰地呈現進程間的網絡通信和部署環境的網絡結構特點。當然也可以用細粒度的執行實體對應處理器、存儲器等。
五、運行環境和技術選型
- 操作系統：Ubuntu 18
- 語言：Goland、JavaScript
- Goland用於處理fuzz數據生成邏輯
- JavaScript用於與geth客戶端進行交互
- 本地環境：geth客戶端、nodejs
- 容器：docker
六、系統概念原型的核心工作機制
6.1 概念原型
- 概念是人對能代表某種事物或發展過程的特點及意義所形成的思維結論。
- 概念原型是一種虛擬的、理想化的軟件產品形式。
- 概念原型=用例+數據模型
6.2 工作機制
用戶使用本系統時，首先需要搭建一條自己的私有區塊鏈並開啟一個客戶端，接着將自己使用以太坊solidity編寫的智能合約代碼部署到私鏈上，在提取abi接口規范和函數方法簽名之后可以開啟模糊測試器針對abi接口規范生成大量輸入，並使用JavaScript編寫測試器向合約發送交易並接受返回的結果，最后將結果寫入日志，對日志進行合並分析可以發現漏洞和測試結果的准確率。
總結
本篇博客通過學習軟件架構設計和軟件設計模式的相關知識，結合自己的工程實踐項目並對其在整體設計方案上進行了詳細的分析。通過數據庫以及核心API的設計使我對整個項目的實現目標有了一個整體的把握。后續可以繼續着手其他功能的實現。
參考資料
[1] https://gitee.com/mengning997/se/tree/master/ppt
[2] 軟件架構設計---軟件架構風格
https://blog.csdn.net/hu19930613/article/details/82749418
[3] 軟件設計模式詳解