软件系统设计方案
前言
近年来，加密货币和区块链技术在业界和学术界获得了巨大的欢迎和关注。截至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] 软件设计模式详解
