Page 100 - 《软件学报》2021年第11期

3426 Journal of Software 软件学报 Vol.32, No.11, November 2021

[7]
方面,集成开发环境(integrated development environment,简称 IDE)对错误信息的支持差 使得智能合约调试困
难.工程师开发无漏洞智能合约具有挑战性.同时,部署升级效率的低下,使得无法及时更新链上存在漏洞的智
能合约.这些漏洞一旦被利用,就会给客户带来财产损失,动摇客户对智能合约的信心 [23] .
[5]
此外,当前系统缺乏一套涵盖不同层面的标准方法来监控区块链系统 ,尤其是智能合约层面.业务逻辑中
的请求、交易涉及多个智能合约,这些智能合约通常由多个团队开发.当出现问题或者性能不佳的时候,不仅执
行过程无法中断而且缺乏错误日志 [24] ,这使得开发人员很难从错综复杂的服务调用网络中找到问题根源,故障
难以检测、定位和修复.智能合约与共识节点耦合,对于智能合约的运行状态、消耗物理资源的情况现阶段不
可知.
综上,智能合约学习使用门槛高、部署效率低、监控标准不完善,严重限制了区块链技术的推广使用和大
规模落地.目前,亟需一体化、自动化的解决方案.
1.3 智能合约微服务化探索
为解决以智能合约为底层技术的区块链应用的一体化和自动化部署问题,学术界和工业界都进行了积极
的探索.Porru 等人 [23] 将区块链实现的软件定义为“面向区块链的软件(blockchain-oriented software,简称 BOS)”,
并指出,需要为区块链应用设计开发相应工具.考虑到区块链应用的独特性,Porru 认为:软件工程师可以从 BOS
开发实践应用中受益,这些实践将构成“面向区块链的软件工程(blockchain-oriented softare engineering,简称
BOSE)”.随后,Porru 总结了 BOSE 的挑战及其原因,提倡重点关注的大型团队之间的协作、测试活动和用于创
建智能合约的专门工具.虽然区块链即服务(blockchain as a service,简称 BaaS) [25] 平台白皮书(http://www.caict.
ac.cn/kxyj/qwfb/bps/201901/t20190111_192631.htm)以云计算为基础给出了通用 BaaS 平台的解决方案,但很难
有效利用已有工具.
区块链应用的开发与运维涉及全栈技术,但大多数工程师只专注于一个层次的专业知识,鲜有熟练的全栈
工程师 [26] ,采用区块链领域的新工具会给工程师们带来学习负担.以微服务为核心的 DevOps 在持续协作、持续
[5]
测试、持续集成、持续交付、持续监控等方面吸引了越来越多研究者与实践者的注意 ,自动化工具也在寻求
在其他领域的应用 [10] .如表 1 所示,微服务与智能合约在设计原则上有很大的相似性 [6,27] .微服务作为一组独立
自治的小型应用程序,业务目标明确且定义良好,它们很好地实现了模块化结构;智能合约也会根据业务需求进
行良好的定义并实现简单的功能,每个智能合约都运行在各自环境中,具有高度的模块化,通过特定的通信方式
与区块链网络进行通信.这种相似性为智能合约微服务化改造提供了可能.

Table 1 Design principles of microservices and smart contracts
表 1 微服务与智能合约设计原则
设计原则 微服务 适用智能合约 理由
服务体量小
高内聚 单一性职责 √ 智能合约拥有特定的范围和职责
低耦合
轻量级通信
独立开发
独立部署
高度自治 √ 智能合约独立运行在沙盒环境中
独立发布
进程隔离
分布式 分布式体系结构 √
去中心化 无中心化数据库 智能合约部署在分布式网络中
微服务即代表业务
以业务 快速响应业务变更 × 智能合约无法快速响应业务变更,团队需要
为中心 根据业务组织团队 兼顾智能合约开发运维和区块链网络维护
团队仅对业务负责

Hu 等人 [28] 提出一种建立智能合约的微服务化方法,提出将智能合约容器化,并将其发布在 Kubernetes 集群
中,使其满足可组合性、可扩展性.但是这种方法停留在理论阶段,无法对区块链各网络节点以及智能合约容器
进行统一的管理.Wang 等人 [29] 将基于区块链智能合约与云技术相结合,研究智能合约的可扩展性和性能问题,