针对智能合约漏洞检测系统的需求分析和概念原型设计
1、前言
本文基于工程实践项目：《基于模糊测试的智能合约安全漏洞检测》。并在项目的初始阶段应用软件工程的思想，对整个项目进行用例建模、业务领域建模和数据建模等规划操作。首先在此部分简单介绍一下该项目。
本项目的目标是对于在区块链上运行的智能合约进行漏洞检测，使用模糊测试工具产生针对合约调用的大量输入，并同时监测其输出是否符合预期。根据运行时调用的api特征序列判断合约是否存在漏洞，最后还需要评估检测的效果。
2、需求分析
在 2008 年，密码学家中本聪构建了一种名为“比特币”的虚拟货币系统，正式提出了区块链的概念。区块链是一种按照时间顺序将数据区块以链条的方式组合成特定数据结构，并以密码学方式保证的不篡改和不可伪造的去中心化共享账本。在不需要第三方信用机构的前提下，区块链技术通过分布式数据库、数字加密技术和独特的共识算法解决了去中心化系统的双重支付问题，对金融领域为代表的的应用场景有着革命性意义。
智能合约是计算机科学家尼克萨博在 1994 年提出的概念，是传统合同或协议的网络化表现，需要在区块链平台上进行存储，同时根据合约代码逻辑，接收用户输入并得到合适的输出。此外，由于传统合同需要双方或多方互信签订，智能合约也应当满足全网区块链用户节点的信任，若合约经确认后部署在区块中，开发者将无法对合约的内容进行修正。智能合约代码中包含全局变量，执行方法及通知事件等要素，用户可以利用这些接口完成代币存储、转账以及其他复杂操作，且无需人为干预。正是由于区块链具有去中心化、信息透明、健壮性强、难以篡改等特征，智能合约才具有了安全稳定的存储介质及运行环境，大大拓展了应用范围。
智能合约的关键特点是它的执行力不依赖任何信用背书。因此，执行合约中的各种条款不需要依赖权威的第三方机构。这里有几个明显的问题：
一、程序员无法创建完全无错的代码，特别是具有图灵完备性的智能合约这样复杂的程序，总会存在意想不到的执行路径或者漏洞。
二、智能合约具有相当的约束力，并被诠释为具有法律效力的文件，但即使是法律文件，也不能做到毫无漏洞，仲裁机构和法庭就是应对某些条款不适用而需要解释的情况而产生的。而且计算机只会执行无法变通的代码命令，对于逻辑不严谨的智能合约，区块链的不可篡改的特性可能会带来更多的麻烦。
三、智能合约一旦部署就不能更改的特性，导致智能合约发现漏洞后不能及时进行软件更新，只能通过暂停交易或分叉等手段减少损失。
四、智能合约中承载着巨大的经济价值，智能合约自身缺陷所导致的安全问题，将会带来非常巨大的经济损失。
软件漏洞分析是指从架构安全分析、源代码漏洞分析、二进制漏洞分析和运行系统漏洞分析等多个方面对软件生命周期的各个阶段进行分析，以发现其中的安全漏洞。将软件漏洞分析技术应用于智能合约，可以有效检测合约的代码缺陷，保证智能合约的高安全性，具有很高的现实意义。 为了保证智能合约的安全性，本项目采用软件漏洞分析方法分析智能合约漏洞在源码、抽象语法树和字节码上的特征，并着手开发面向智能合约的自动化安全检测系统，验证智能合约的安全性。面向智能合约的安全检测系统能够及时有效地发现开发者设计的智能合约缺陷，更好的推动区块链技术的发展。
3、用例建模
3.1 用例（Use Case）的核心概念
首先它是一个业务过程，经过逻辑整理抽象出来的一个业务过程，这是用例的实质。什么是业务过程？在待开发软件所处的业务领域内完成特定业务任务的一系列活动就是业务过程。 接下来我们具体看看用例的几个基本要素：
- 一个用例应该由业务领域内的某个参与者（Actor）所触发。
- 用例必须能为特定的参与者完成一个特定的业务任务。
- 一个用例必须终止于某个特定参与者，也就是特定参与者明确地或者隐含地得到了业务任务完成的结果。
3.2 用例建模的基本步骤
- 第一步，从需求表述中找出用例，往往是动名词短语表示的抽象用例；
- 第二步，描述用例开始和结束的状态，用TUCBW和TUCEW表示的高层用例；
- 第三步，对用例按照子系统或不同的方面进行分类，描述用例与用例、用例与参与者之间的上下文关系，并画出用例图；
- 第四步，进一步逐一分析用例与参与者的详细交互过程，完成一个两列的表格将参与者和待开发软件系统之间从用例开始到用例结束的所有交互步骤都列举出来扩展用例。 其中第一步到第三步是计划阶段，第四步是增量实现阶段。
本项目中参与者主要为用户，通过此系统用户可以完成例如搭建私有链、部署合约、测试合约安全性等操作
3.3 项目的用例图
4、业务类图
业务领域建模是开发团队用于获取业务领域知识的过程。因为软件工程师往往需要工作在不同的业务领域或者不同项目中，他们需要业务领域知识来开发软件系统。软件工程师往往来自不同的专业背景，这可能会影响他们对业务领域的认知。因此业务领域建模有助于开发团队获取业务领域知识形成统一的业务认知。
4.1 业务建模一般步骤
1）收集应用业务领域的信息。聚焦在功能需求层面，也考虑其他类型的需求和资料。
2）头脑风暴。列出重要的应用业务领域概念，给出这些概念的属性，以及这些概念之间的关系
3）给这些应用业务领域概念分类。分别列出哪些是类、哪些属性和属性值、以及列出类之间的继承关系、聚合关系和关联关系。
4）将结果用 UML 类图画出来。
4.2 业务分类
用户：
属性：id（用户序列号）
属性：name
方法：ChainBuild()
方法：DeployContract()
方法：TestContract()
合约：
属性：abi（接口规范）
属性：status
属性： balance
方法：ReturnABI()
方法：ReturnMethodSig()
ABI:
属性：name
属性：method_sig
属性：input
属性：output
4.3 项目UML类图
5、数据模型
根据前面的分析可以得到以下数据模型：
用户表：
合约表：
ABI接口表：
6、概念原型及工作过程
- 概念是人对能代表某种事物或发展过程的特点及意义所形成的思维结论。
- 概念原型是一种虚拟的、理想化的软件产品形式。
- 概念原型=用例+数据模型
基于以上定义可以得出本项目概念原型的工作过程：
用户使用本系统时，首先需要搭建一条自己的私有区块链并开启一个客户端，接着将自己使用以太坊solidity编写的智能合约代码部署到私链上，在提取abi接口规范和函数方法签名之后可以开启模糊测试器针对abi接口规范生成大量输入，并使用JavaScript编写测试器向合约发送交易并接受返回的结果，最后将结果写入日志，对日志进行合并分析可以发现漏洞和测试结果的准确率。
7、总结
通过软件工程课程的学习，我逐渐了解到很多软件设计的规范，也从书本中获得了很多前人的智慧。本次实践中我通过对自己的工程实践项目进行从需求分析到用例建模到概念原型全过程的分析，对项目做出了一个整体上的建模分析，使我在以后的工作中目标性更加明确。在以后面对一个大系统的开发时，我也将不会手足无措或是匆忙开始编码，首先运用软件工程的思想对整个系统进行建模才是优先级更高的步骤。
8、参考资料
[1]https://gitee.com/mengning997/se/blob/master/ppt/%E4%BB%8E%E9%9C%80%E6%B1%82%E5%88%86%E6%9E%90%E5%88%B0%E8%BD%AF%E4%BB%B6%E8%AE%BE%E8%AE%A1.pptx
[2]https://www.cnblogs.com/southx/p/9334639.html
