2019年9月23日,Starteos与电子科技大学共建的区块链技术研究与应用联合实验室开展“ 全球首个基于EOS智能合约的形式化验证”项目验收及成果汇报工作。
历时一年零5个月,在数十名电子科技大学的博士生导师、博士研究生夜以继日的努力之下,项目克服种种技术难关正式落地。



希望是推动人类文明不断前进的火种,时间让火种酝酿出燎原之势。
未来,联合实验室将继续深耕此项目,力求打造一个有深度、有广度的形式化验证项目,优化目前DApp开发模式,提供更安全、更高效的智能合约服务。
什么是更严谨的测试和安全审计?让无数程序员头疼的bug问题该如何解决?随着全球首个基于EOS智能合约的形式化验证项目的正式落地,答案呼之欲出。
???
形式化验证项目简介目前,Starteos与电子科技大学共建的区块链技术研究与应用联合实验室是世界首个研发基于EOS智能合约的形式化验证项目团队。
形式化验证是用逻辑来验证程序的可靠性,就是把一段程序用逻辑的方法证明一遍,证明它能得到预期的结果,没有bug。
目前验证方式有两种:
第一种是定理证明,全称为基于符号执行的定理证明;第二种是符号执行,全称为基于符号执行的动态约束求解。
该项目研发目标在于实现从原始合约C++语法的编译、转换和解释验证,提供针对EOS智能合约的形式化验证工具链原型系统。

在项目系统中存在4种角色:需求用户、分析员、评估员和管理员。
需求用户可登录网站上传EOS智能合约;评估员分析合约、反馈验证结果;评估员仲裁存在分歧的合约;管理员管理网站平台的权限。
△ 项目运作流程示意图
第三阶段工作主要内容与第二阶段相比,本阶段的主要工作为:为系统中引入KLEE,为EOS智能合约提供除定理证明之外的另一种验证方式——符号执行。了解第一阶段项目成果请戳:
形式化验证 | 上帝视角下的智能合约审计
了解第二阶段项目成果请戳:
全球首个基于EOS智能合约的形式化验证项目取得突破性进展
根据需求本项目对多个合约进行过验证,在验证之前完成了对静态链接库的编译工作。
编译静态链接库以支持EOS智能合约的KLEE验证是项目进程中无法绕过的一步。
因为KLEE默认不加载任何外部库,而自身提供的uclibc仅仅是小型的c库,无法达到对EOS智能合约的逻辑验证,于是我们尝试将eosio.cdt中的库文件链入。
紧接着第二个难点出现,eosio环境的库文件是采用gcc进行编译,KLEE只支持LLVM编译生成的.a文件和.so文件,所以我们需要对eosio下的所有库文件采用LLVM重新编译。
最后将生成的库文件链入KLEE执行,才能够顺利获得验证结果。
项目中我们一共编译生成了libc++.a、libc.a、libnative.a、librt.a、libeosio.a五个静态链接库文件来支持我们的验证。
项目还系统性的验证了hello合约、multi_index_example合约、multibetting合约、NBA合约和error_check合约。
符号执行的优势作为最流行的符号执行引擎之一,KLEE提供灵活的模块化框架,可在其上构建许多不同的基于符号执行的技术。
目前主要支持的漏洞检测类型包括:内存泄漏、数组越界、空指针、除法分母为0、求余分母为0等。
在实际的程序测试方面,KLEE作为一个较为成熟的符号执行、错误检测工具有着众多的突出表现。
KLEE的优势包括:
1、极高覆盖率。
KLEE自动生成的测试用例覆盖了COREUTILS总线路的84.5%和BUSYBOX的90.5%(忽略库代码)。
平均而言,这些测试在每个工具代码中覆盖了90%以上的路径(中位数:超过94%),在16个COREUTILS工具和31个BUSYBOX工具中实现了100%的完全覆盖。
2、极高的测试准确度。
KLEE能够检测出许多难以被人工检测出的漏洞,并且KLEE并不局限于低级编程错误,当用于交叉检查据称相同的BUSYBOX和GNU COREUTILS工具时,它会自动发现功能正确性错误和很多的不一致。
3、极高的测试效率。
KLEE在COREUTILS上89小时的测试路径覆盖率相较于该项目开发人员在15年的逐步累加的测试集测试路径覆盖率多16.8%。
KLEE测试用例可以在代码的原始版本上运行,这大大简化了调试和错误报告。
KLEE在项目中的应用包括:
1、合约验证所需代码库编译
对EOS相关函数库,通过Clang和llvm的编译、链接形成llvm bitcode格式的静态库。
2、合约验证代码构建
通过在关键点插入函数调用(klee_make_symbolic)对合约内存进行符号化操作。
与定理证明相比,符号执行验证只需一个分析员,且且对分析员的专业要求较低,大幅提升合约验证效率。由于定理证明一般而言需要大量的人工参与,广泛应用的实际成本较为高昂。
因此项目从基于符号执行的定理证明验证方式的角度出发思考问题:
首先,智能合约代码通过人工编写的翻译器、解释器自动转变为等价的形式化模型。
其次,通过人工的方式,对待验证的功能或设计需求进行手动抽象建模,给出待证的形式化定理。
然后,通过定理证明技术证明待证定理,系统获得证明结果(正确的、错误的、不可证明的)。
最后,系统利用证明结果表述平台智能合约代码的正确性评估(正确的、错误的、无法验证的)。
基于符号执行的定理证明优势在于:
1、自动化:
该项目所提供的方法能够自动化对智能合约原代码进行自动识别、转译与建模,并且通过整合证明流程,为自动化证明策略的实现提供了便利。
2、 一致性:
该框架能够同时保障模型一致性与运行环境一致性。其中:
模型一致性是指该方法具有将待验证源码逐行进行等价转译与建模,形成与源码行为一致的形式化规格模型;
运行环境一致性是指在形式化验证系统中对源代码语义行为进行了准确建模,能够精确地重现程序的原始行为。
3、灵活性:
该方法能够支持具有一定工作经验的验证人员在不修改原始验证框架内核的前提下针对特定问题进行形式化建模;
4、扩展性:
该方法基于模块组件化设计,由数个独立功能模块组件而成,每个模块都拥有独立扩展接口,能针对不同语言不同验证环境进行修改与扩展。
项目成果输出1、软件完成情况:
√ 翻译器:针对合约的编译(语法层)和转换。√ 全形式化证明引擎:针对EOS的开发语言(C++11)开发,基于KLEE机制的EOS符号化验证子系统。
√ WEB集成。
2、文档输出:
√ 软件过程文档:需求分析说明书、概要设计、详细设计(WEB)、用户手册、测试报告。
√ 项目验收报告。
√ 区块链现状分析。
√ 形式化验证调研报告。
√ 形式化验证结论报告。
√ 智能合约形式化验证平台开发白皮书。
3、知识产权情况
√ 国内外权威期刊杂志文章发表。
√ 发明专利申请。
√ 软件著作权:EOS智能合约翻译器、形式化验证平台。

△ 部分成果展示
项目后期发展规划在第一阶段项目成果汇报之时,本项目发起人、Starteos CEO 李昂先生就曾表示:“首个基于EOS的形式化验证项目的意义应该聚焦实用性与应用性方面,力求打造一个不仅是服务本公司产品,而是服务于整个EOS生态,甚至整个区块链行业的产品。”因此,在本次项目验收报告会上李昂先生指出:“目前基于EOS智能合约的形式化验证现阶段还没有成熟的方案,我们在这片“荒芜”的市场的努力耕耘有了一定成果。但要想真正的应用于市场,大规模服务生态开发者,我们还需要进一步减少人工干预,从而降低使用门槛。”对此, 首个基于EOS智能合约的形式化验证项目在完成项目验收后,未来还将在以下方面继续努力:1、完善C++支持度:未完善模块逐步增加标准库的支持,逐步完成对eosiocpp的全面支持。2、规范验证需求:统一定理的设计格式,设计泛用性更强的验证策略。3、降低人工参与度:目前定理证明验证中仍然存在大量工作需要分析员参与分析与设计,包括:前后置条件的形式化建模,待证形式化定理的建模和自动化证明策略的选择调用。4、优化算法,提高效率:定理证明验证框架中仍然存在若干可以优化的结构,针对这些结构进行优化以提升验证效率。

我们坚信,这个让世界为之惊艳的全球首个基于EOS的形式化验证项目,一定能够做到优化目前DApp开发模式,创造出更安全、更高效的智能合约服务,造福行业,助力生态发展。
为了这个理念,我们也将继续努力。
一起期待形式化验证项目未来的更多精彩。


今 日 互 动
①
你认为首个基于EOS智能合约的
形式化验证项目能为生态带来什么?
围绕此话题,文末评论区留言你的观点即可参与活动,Starteos 将选出20条精华留言,入选者将获得100枚AC奖励。
活时间截止至9月24日(今晚)24:00。
Starteos小秘将于9月25日主动联系获奖用户填写信息领取奖励,信息填写时间为24小时之内,逾期将视为自动放弃领奖资格。
②
转发活动
转发此文到200人以上与EOS相关的微信群后,发送间隔3分钟以上的转发截图+12位EOS账号+手机号至Starteos微信公众号后台。
依据转发截图的发送时间,前20名发送信息至微信公众号后台的用户将获得66枚AC奖励,先到先得,送完为止。
如发现有同一个微信昵称,则取第一时间发送过来的为准。
活动截止至今晚(9月24日)24:00,Starteos小秘将会在9月25日统计并发放奖励。
领奖须知
1. 转发群必须是200人以上与EOS/区块链相关的微信群,且“Starteos”的微信群除外。
2. 转发截图+12位EOS账号+手机号至微信公众号后台(三项缺一不可,如不按照此格式发送,则取消领奖资格)
3. 转发之后禁止撤回,截图里您的转发时间(时间1处)比截图时间(时间2处)需晚3分钟以上。
(本活动最终解释权归Starteos所有)