uBaaS：一种统一区块链即服务
摘要
区块链是一种创新的分布式账本技术，因其在解决商业中缺乏信任问题方面的潜力而受到广泛关注，可用于构建下一代应用程序。区块链即服务（BaaS）是一种有前景的解决方案，可提高区块链应用开发的生产力。然而，现有的BaaS部署方案大多存在供应商锁定问题：它们要么绑定于特定云服务商，要么依赖于特定区块链平台。此外，基于区块链的应用程序的设计与实现是一项复杂任务，需要深厚的专业知识。因此，本文提出了一种统一区块链即服务（uBaaS）平台，以支持基于区块链的应用程序的设计与部署。uBaaS中的服务包括部署即服务、设计模式即服务和辅助服务。在uBaaS中，部署即服务具有平台无关性，可避免对特定云平台的锁定，而设计模式即服务则应用数据管理和智能合约设计方面的设计模式，以应对区块链的可扩展性和安全性问题。本文通过一个真实世界质量追溯用例对提出的解决方案进行了可行性与可扩展性的评估。
关键词
: 区块链, 架构, 设计模式, 部署, 区块链即服务
1. 引言
区块链技术作为一种分布式账本技术，已在商业领域建立数字信任方面引起了广泛关注。许多初创企业、企业和政府[1, 2]目前正在探索如何利用区块链技术在下一代应用程序中实现信任和去中心化。基于区块链的应用领域十分广泛，包括物理或数字资产所有权管理、代币、货币、身份管理、供应链、电子健康记录、投票、能源供应等。
区块链即服务（BaaS）是提高区块链应用开发生产力的一种有前景的解决方案。现有BaaS平台提供商主要提供更便捷的部署服务，例如微软 Azure¹、IBM² 和亚马逊³。然而，现有的BaaS部署解决方案通常存在供应商锁定问题，这些方案要么绑定到特定云服务商（例如微软Azure¹），要么绑定到特定区块链平台（例如IBM Hyperledger²）。
除了部署之外，基于区块链的应用程序的设计与实现对开发者来说颇具挑战性。首先，区块链是一项新兴技术，其工具和文档有限，因此开发者可能面临陡峭的学习曲线。根据Gartner的一项调查[3]，“23%的[相关受访] CIO表示，区块链是实施任何技术领域所需掌握新技能最多的领域，而18%的人表示，区块链技能是最难找到的。”其次，区块链在设计上是一个不可变的数据存储，因此更新已部署的区块链智能合约可能非常困难。这使得通过发布智能合约的新版本来修复漏洞变得困难。智能合约中的错误已导致巨大的经济损失，例如以太坊区块链上的DAO漏洞[4]。
软件设计模式被定义为在软件设计过程中特定上下文中常见问题的解决方案[5]。基于区块链应用程序的设计模式来自工业界的最佳实践，可封装为服务，以减轻开发者的负担并提高基于区块链的应用程序的质量。一个典型的例子是链上和链下设计模式，它为基于区块链应用程序的数据存储提供了相应的解决方案。分别进行
¹ https://azure.microsoft.com/zh-cn/solutions/blockchain/
² https://www.ibm.com/blockchain/platform/
³ https://aws.amazon.com/blockchain/
将数据存储在链上和链下是为了确保链上数据的完整性以及链下数据的隐私。该模式可实现为一项服务，根据开发者构建的数据模型，在传统数据库中生成链上数据注册表智能合约和链下数据表。例如，在质量追溯系统中，链上属性可以是追溯标识和追溯结果，而链下属性可以是产品价格、买家姓名等。
本文提出了一种名为uBaaS的统一区块链即服务，该平台有助于基于区块链的应用程序的设计与部署。本文的贡献如下：
– 一组用于基于区块链的应用程序的数据管理和智能合约设计的设计模式，旨在更好地在实践中利用区块链技术。这些设计模式包括链上和链下、哈希完整性、数据加密、多个权威机构、动态绑定和嵌入式权限。
– uBaaS平台方法：
–
部署即服务
，包括区块链部署服务和智能合约部署服务。部署即服务可以简化区块链网络部署和智能合约部署。所提出的区块链部署服务是平台无关的，能够避免锁定到特定云平台。
–
设计模式即服务
，由数据管理服务和智能合约设计服务组成。每项服务均基于一种设计模式进行设计，以更好地利用区块链的独特特性（即不可变性和数据完整性、透明性），并解决其局限性（即隐私和可扩展性）。
– 使用真实世界质量追溯用例评估所提出解决方案的可行性与可扩展性。评估结果表明，我们的解决方案是可行的，并且具有良好的可扩展性。
本文的其余部分组织如下。第2节讨论背景和相关工作。第3节总结了数据管理和智能合约设计的设计模式。第4节介绍了uBaaS平台的整体架构以及uBaaS提供的各项服务的设计。第5节介绍了实现细节。第6节从可行性与可扩展性方面评估了提出的解决方案。第6节总结了本文并概述了未来工作。
2. 相关工作
本节介绍我们研究的相关工作。首先介绍了区块链技术及其分类，因为这是本研究的基础。接着阐述了如何将区块链技术应用于软件系统，然后简要介绍了当前开发基于区块链的应用所面临的障碍。最后讨论了设计模式和区块链即服务。
2.1. 区块链技术
区块链是比特币背后的技术，它是一种去中心化数据存储，用于维护比特币网络的所有历史交易。区块链的概念已被推广到分布式账本系统，这类系统在无需使用代币的情况下验证和存储交易，且不依赖于任何中心化可信机构，例如传统银行系统。相反，区块链网络中的所有参与者可以通过对交易数据状态的共识来实现信任。
区块链的数据结构是一个由可识别区块组成的有序列表，每个区块都连接到链中的前一个区块。区块是用于聚合交易的容器，而交易则是存储参数（如货币价值）和对智能合约的函数调用的可识别数据包。智能合约是一种用户定义程序，部署并执行于区块链网络上[8]，能够表达触发器、条件和业务逻辑[9]，从而实现更复杂的可编程交易。智能合约可以作为交易的一部分来实现，并由区块链网络中所有连接的节点共同执行。区块链平台以太坊提供了一种内置的图灵完备脚本语言Solidity，用于编写智能合约。以太坊虚拟机 (EVM) 是以太坊的执行环境，由网络上的所有完整节点组成，负责执行从 Solidity 脚本编译而来的字节码。
2.2. 区块链类型
如表1所示，根据部署方式，区块链可分为三种类型，包括公有区块链、联盟区块链和私有区块链。公有区块链被大多数数字货币所采用，互联网上的任何人都可以访问。使用公有区块链可实现更高的数据透明性和可审计性，但会牺牲性能，并且具有
| 公有区块链 | ⊕⊕⊕ | ⊕ | ⊕ | ⊕ |
| 联盟区块链 | ⊕⊕ | ⊕⊕ | ⊕⊕ | ⊕⊕ |
| 私有区块链 | ⊕ | ⊕⊕⊕ | ⊕⊕⊕ | ⊕⊕⊕ |
不同的成本模型。联盟区块链通常在多个组织之间使用，并通过预先授权的节点来控制共识过程。在私有区块链网络中，写入权限通常由一个组织内部掌控，尽管这可能包括单个组织内的多个部门。对联盟区块链或私有区块链的读取权限可以是公开的，也可以限制为特定的一组参与者。在使用联盟区块链或私有区块链时，需要权限管理组件来授权区块链网络内的参与者。私有区块链在配置上最具灵活性，因为网络由单一组织治理和托管。我们的工作主要集中在联盟区块链和私有区块链上。
2.3. 区块链作为软件应用系统的组件
学术界的研究人员和工业界的开发者正在研究和探索如何利用区块链技术构建下一代应用[1, 2]。工业领域的应用领域包括但不限于数字货币、国际支付、注册系统、政府身份和税务管理、物联网（IoT）识别与安全管理，以及供应链[10, 11, 12, 13]。此外，还有多种学术研究利用区块链解决不同领域的问题。瞿等人[14]提出了一种支持快速查询处理的时空区块链技术，已被证明具有适用性和有效性。齐斯肯等人利用区块链构建了一个个人数据管理系统，确保用户以去中心化方式拥有和控制其数据[15]。
图1：区块链作为软件应用系统的组件
Bulat Nasrulin 等人提出了一种基于区块链构建的移动性分析应用[16]，并通过分布式数据库对区块链进行了改进[17]。
Namecoin[18]和PKI[19]是两个基于区块链的公钥平台。ProvChain为基于云的数据分析[20]实现数据溯源。
软件组件是软件架构的基本构建模块，而区块链可以作为一种提供计算能力的软件组件。区块链是复杂的基于网络的软件组件，能够提供数据存储、计算服务和通信服务。
图1展示了基于区块链的应用系统架构，该架构由四个水平层和两个垂直层组成。水平层包括表现层、逻辑层、数据层和平台层，而垂直层则分为链上和链下。
用户通过用户界面与区块链智能合约及链下组件（包括密钥管理组件）进行交互。基于区块链的应用系统可以通过不同的链下组件和链上智能合约实现业务逻辑。密钥管理是此类基于区块链的系统中一个关键的链下组件。区块链网络中的每个参与者都有一个或多个私钥，用于对交易进行数字签名。这些私钥的安全性
这一点很重要：如果私钥被盗，该账户持有的资产可能被访问，智能合约的受保护函数也可能被调用。
在数据层，区块链作为去中心化数据账本，用于存储需要完整性及/或透明性的数据。由于可扩展性和隐私性需求，通常需要链下传统数据库来存储私有或大规模数据。
在平台层，基本的区块链功能可以包括权限管理、激励机制、交易验证和密码学安全支付。预言机通过将信息作为交易中的数据添加到区块链上，通常向区块链提供有关外部世界的信息。
2.4. 区块链应用开发的挑战
区块链是一种新兴的分布式账本技术，开发者需要学习新技能并深入理解该技术才能构建基于区块链的应用。我们将区块链应用开发的挑战总结如下。
-
部署
。当前的区块链部署解决方案（例如 Microsoft Azure¹、IBM Hyperledger²、亚马逊 ³）将客户锁定在特定的云和/或区块链平台上。然而，许多企业或政府需要在自己的本地私有云上构建基于区块链的应用，现有区块链解决方案无法满足这一需求。此外，区块链的部署过程容易出错、耗时，并且需要频繁更新。
-
可扩展性
。区块链的存储能力有限，因为它包含了区块链网络中所有参与者的所有交易的完整历史。因此，区块链的大小会持续增长。不断增长的区块链规模给在区块链上存储数据带来了挑战。此外，由于区块链的区块大小有限（由网络[21]控制），在交易中存储大量数据或部署大型智能合约可能是不可能的。
-
数据隐私
。基于区块链的应用可能包含仅对某些特定区块链参与者可用的敏感数据。然而，区块链上的信息设计为所有参与者均可访问。无论区块链是公有链、联盟链还是私有链，区块链网络内都没有特权用户。
-
密钥管理
。区块链上的身份验证通过数字签名实现。然而，区块链并未提供任何机制来恢复丢失或已被泄露的私钥。一旦私钥丢失，将永久失去对该账户以及引用该账户的智能合约的控制权。
-
权限控制
。部署在区块链上的所有智能合约默认情况下均可被所有区块链参与者访问和调用。一个无权限限制的函数可能会被未授权用户意外触发，从而成为基于区块链的应用程序的漏洞。
2.5. 设计模式与区块链即服务
设计模式是一种可重用的解决方案，用于解决在软件设计过程中特定上下文中经常出现的问题[22]。目前关于基于区块链应用的设计模式的研究较少。J. Eberhardt 和 S. 太提出了一组主要关注链上和链下数据与计算的设计模式[23]。Zhang 等人将四种现有的面向对象软件模式应用于基于区块链的医疗应用上下文中的智能合约设计[24]。Liu 等人总结了八种智能合约设计模式，并将其分为四种类别[25]。Bartoletti 和 Pompianu 对智能合约进行了实证分析，他们收集了数百个智能合约，并将其划分为多个类别：代币、授权、预言机、随机性、投票、时间约束、终止、数学和分叉检查[26]。在近期的研究中，本文的部分作者提出了一套广泛的模式集合[27]。然而，目前针对基于区块链应用所总结的设计模式大多处于概念层面，需要用户自行实现这些解决方案。
区块链即服务（BaaS）提供了一种使开发者能够高效开发基于区块链的应用的解决方案。目前大多数 BaaS 平台旨在帮助开发者创建、部署和管理区块链网络，例如微软Azure¹, IBM²,和亚马逊³。然而，现有的 BaaS 部署解决方案通常被锁定在特定的公有云或区块链网络提供商中（例如微软Azure¹, IBM Hyperledger²）。许多政府或企业在私有云中部署其应用程序，并可能有不同的区块链网络偏好。此外，除了部署服务外，BaaS 平台还需要提供开发服务。区块链应用程序的架构设计
对开发者来说是一个挑战，因为他们需要学习区块链编程语言并对区块链技术有深入的理解。
3. 基于区块链应用的设计模式
在软件工程中，设计模式是针对在软件设计过程中特定上下文中常见问题的可重用解决方案[5]。在本节中，我们总结并分类了六种可用于基于区块链的应用系统架构设计的设计模式。这些模式根据其特性和作用被划分为数据管理设计模式和智能合约设计模式。
3.1. 数据管理设计模式
如第2节所述，在基于区块链的应用系统中，区块链可作为去中心化数据账本，并与传统数据库协同存储数据。由于区块链的基本特性（如数据透明性）和局限性（如区块链可扩展性），基于区块链的应用的数据管理具有挑战性。本文总结了三种数据管理设计模式：链上和链下、哈希完整性和数据加密。
3.1.1. 链上和链下
摘要
：链上和链下模式将数据分别存储在区块链上和区块链下来确保数据完整性，同时解决区块链的存储能力问题。
上下文
：一些应用程序考虑利用区块链来确保数据完整性，因为区块链上的所有数据都是透明且不可篡改的。
问题
：由于区块链上的所有信息对所有参与者都是可访问的，并且区块链的存储容量有限，因此可能无法在区块链上存储敏感和大量的数据。
解决方案
：与其将所有数据都存储在链上，不如仅将敏感且小量的数据存储在链上。例如，食品质量追溯系统可以将追溯法规所要求的追溯信息（如追溯编号和结果）存储在链上，而将工厂生产过程的照片存储在链下。
将数据分别存储在区块链上和区块链外的好处在于能够更好地利用各自的技术特性
区块链并避免区块链的局限性。区块链可以保证链上关键数据的完整性和不可变性。非微小文件存储在链下，从而防止区块链大小过快增长。存储链下文件的哈希值可以进一步确保链下文件的完整性。
3.1.2. 哈希完整性
摘要
：哈希完整性模式利用哈希技术来确保无法直接存储在区块链上的任意大规模数据集的完整性。
上下文
：一些基于区块链的应用考虑使用区块链来确保大量数据的完整性。
问题
：由于区块链的区块大小有限（例如，以太坊具有区块燃气限制，用于控制区块中包含的数据大小、计算复杂度和交易数量），在交易中存储大量数据可能是不可能的。因此，如何在区块链上存储任意大小的数据以保证数据完整性成为一个问题。
解决方案
：对于大尺寸数据（本质上是指大于其哈希值），而不是将原始数据直接存储在区块链上，而是将原始数据的哈希值存储在区块链上。该哈希值由哈希函数生成，哈希函数可将任意大小的数据映射为固定大小的数据，并且是不可逆的。对数据的任何更改都会导致其对应的哈希值发生变化。
3.1.3. 数据加密
摘要
：数据加密模式通过加密存储在区块链上的数据来确保数据的机密性。
上下文
：对于某些基于区块链的应用，商业敏感数据应仅由特定参与者访问。例如，服务提供商向其部分用户提供的特殊折扣价格。此类信息可能不应被未获得折扣的其他用户访问。
问题
：数据隐私的缺失是区块链的主要局限性之一。区块链上的所有信息对区块链参与者都是公开可用的。无论区块链是公有、联盟还是私有的，区块链网络内都没有特权用户。在公有
区块链上，新参与者可以自由加入区块链网络，并访问记录在区块链上的所有信息。任何存储在公有区块链上的机密数据都会暴露给公众。
解决方案
：可以使用非对称（或对称）加密在将数据存储到区块链之前对其进行加密。其中一个参与方生成密钥对，并将解密密钥分发给其他参与方。参与方可以在使用加密密钥将数据放置到区块链之前对数据进行加密。只有拥有解密密钥的参与方才能解密数据。
3.2. 智能合约设计模式
开发者可以定义智能合约（即区块链上的软件程序）来实现业务逻辑，并支持更复杂的可编程交易。然而，开发智能合约通常要求开发者具备深厚的区块链知识以及丰富的智能合约开发经验。因此，我们总结了三种设计模式，作为解决智能合约设计中常见问题（例如安全性）的方案。
3.2.1. 多个权威机构
摘要
：预先定义一组可以授权交易的区块链账户地址。仅需该组预定义账户地址中的一个子集即可授权交易。
上下文
：在基于区块链的应用中，某些活动可能需要多方（即区块链账户地址）授权。例如，一笔货币交易可能需要多个区块链账户地址的授权。
问题
：由于授权方的可用性，可能无法确定授权活动的实际地址。
解决方案
：为了实现更灵活的绑定，可以使用M-of-N机制来规定授权交易需要N个私钥中的M个。M是授权阈值。
3.2.2. 动态绑定
摘要
：动态绑定模式使用在链下创建的哈希来为交易动态绑定权限。
上下文
：在基于区块链的应用中，某些活动需要由一个或多个参与者授权，而在相应的智能合约部署时或交易提交到区块链时，这些参与者是未知的。
问题
：区块链不支持与未在交易或智能合约中定义的区块链账户地址进行动态绑定。所有能够授权第二笔交易的账户都必须在第一笔交易添加到区块链之前就定义好。
解决方案
：当授权交易的参与者事先未知时，可以使用链下密钥来实现动态绑定。在付款的上下文中，当发送方将资金存入托管智能合约时，会同时提交密钥的哈希。通过链下接收密钥的参与者可以通过揭示密钥从托管智能合约中申领资金。因此，资金的接收方无需在托管合约中预先定义。
3.2.3. 嵌入式权限
摘要
：智能合约使用嵌入式权限控制来限制对智能合约中定义的函数调用的访问。
上下文
：默认情况下，智能合约没有所有者，因为运行在区块链上的智能合约默认可被所有区块链参与者和其他智能合约访问和调用。
问题
：一旦智能合约被部署，其作者在调用该智能合约时并无特殊权限。一个无权限控制的函数可能被未授权用户意外触发，从而成为区块链应用中的漏洞。例如，在Parity多签钱包所使用的智能合约库中发现了一个无权限函数，导致约50万以太币被冻结⁴。2016年，公共以太坊上7%的智能合约可在无授权情况下被终止[28]。
解决方案
：可以在每个智能合约函数中添加权限控制，以在执行函数逻辑之前，基于调用者的区块链地址检查每个函数调用者的权限。来自未经授权的区块链地址的调用将被拒绝。
⁴ https://paritytech.io/a-postmortem-on-the-parity-multi-sig-library-self-destruct/
4. uBaaS的架构
在uBaaS中，我们提出了部署即服务以实现与供应商无关的部署，以及设计模式即服务，以解决基于区块链的应用程序的可扩展性和安全性问题。图2展示了uBaaS的整体架构。uBaaS中提出的服务分为三类：deployment as a service、design pattern as a service和auxiliary services。用户可以通过uBaaS前端用户界面构建区块链环境并设计基于区块链的应用程序，该界面通过API网关与后端服务进行交互。API网关将来自前端用户界面的API调用转发到相应的服务。
本节其余部分将分别介绍部署即服务、设计模式即服务和辅助服务。部署即
服务包含两种部署服务，设计模式即服务包括6种设计模式服务，以帮助开发者利用区块链的特性并解决区块链的局限性，而辅助服务可作为辅助手段，更好地利用设计模式即服务。
4.1. 部署即服务
部署即服务包括区块链部署服务和智能合约部署服务。用户可以配置区块链设置（如难度和参与节点IP），并使用uBaaS部署其自定义的区块链网络。基础设施即代码被应用于区块链部署服务中，通过开发的脚本实现部署、配置和任务管理的自动化。区块链建立后，用户可以实时监控区块链的状态，并在区块链上部署已开发的智能合约。由于我们专注于联盟区块链和私有区块链，因此假设我们可以访问参与节点。目前，支持以太坊区块链和Hyperledger Fabric区块链。我们计划在uBaaS中增加更多区块链平台作为部署选项。
智能合约部署服务使用户能够选择已开发的智能合约（即程序）文件，并将智能合约代码部署到区块链上。此外，智能合约地址和应用二进制接口（ABI）将存储在链下数据库中，以便调用已部署的智能合约。
4.2. 设计模式即服务
设计模式即服务由数据管理服务和智能合约设计服务组成。数据管理服务包括链上和链下服务、数据加密服务以及哈希完整性服务，而智能合约设计服务包含多权威机构服务、动态绑定服务以及嵌入式权限服务。每种类型的服务均基于一种设计模式进行设计，以提升基于区块链的应用的可扩展性、适应性和安全性。数据管理服务使用户能够通过 uBaaS 前端用户界面直接管理数据，而智能合约设计服务则将智能合约设计模式集成到原始智能合约中。
4.2.1. 数据管理服务
为了解决区块链存储能力受限和数据隐私问题，提出了一种链上和链下服务，将需要不可变的关键数据存储在链上，同时将所有数据保留在链下，以提高数据读取效率。用户可以定义数据模式，并确定哪些属性存储在链上或链下。基于用户构建的数据模型，该服务通过部署生成的链上数据注册表智能合约在区块链上建立数据注册表，并在传统数据库中设置链下数据表。链上数据注册表与链下数据表具有相同的名称。用户可向所选的数据存储写入/读取数据，而无需关心数据是存储在链上还是链下。
为了保护相关参与者的隐私，uBaaS提供了一项数据加密服务，对链上数据进行加密，以确保存储在区块链上的数据的机密性。uBaaS用户首先使用私钥（由辅助服务中的密钥生成服务生成）对数据项进行加密，然后将其存储到区块链上。拥有公钥的区块链参与者可访问该交易并解密信息。通过使用链上数据加密服务，未持有公钥的区块链参与者无法访问存储在区块链上的敏感数据。
为了在区块链上存储大容量数据（即文件），哈希完整性服务会生成该文件的哈希值，并将哈希值存储在链上文件注册表中，该注册表通过预定义的外键与链上数据注册表相关联。
4.2.2. 智能合约设计服务
智能合约设计服务专注于智能合约函数调用的权限控制。每项服务的输入是用户编写的智能合约代码，输出则是通过添加实现相应智能合约设计模式的模板代码而得到的更新后的智能合约代码。
多权威机构服务专注于只有在授权的区块链地址批准后才能调用的智能合约函数。用户可以预先定义一组能够授权交易（即调用智能合约中的函数）的区块链地址，并设置最小
用于交易批准的授权数量。用户需要选择他们编写的智能合约以及需要多个权威机构机制的函数。然后uBaaS会修改所选函数的代码，并生成包含多个权威机构代码的更新后的智能合约。
动态绑定服务使用链下密钥，在参与者批准交易（即调用智能合约中的函数）事先未知的情况下实现动态授权。用户需要提供一个密钥（例如随机数）并选择智能合约中对应的函数。该服务通过添加密钥的哈希值来修改函数代码，并生成更新后的智能合约。无需特殊协议来交换密钥，因为密钥可以通过任何链下方式进行交换。只有拥有密钥的用户才能调用智能合约中选定的函数。
嵌入式权限服务的目的是限制对智能合约中定义的函数调用的访问。用户可以通过提供授权地址来识别智能合约中选定函数的授权方。该服务会向智能合约函数添加权限控制代码，在执行函数逻辑之前，根据调用者的区块链地址对每次调用者进行权限检查。
4.3. 辅助服务
当前版本的uBaaS支持两种辅助服务，密钥管理服务和文件比对服务。
密钥管理服务用于生成数据加密的密钥对。开发者可以使用数据加密服务对数据进行加密，并在将加密数据存储到链上数据注册表之前，将解密密钥共享给其他平台用户（例如开发者或应用用户）。解密密钥的共享通道不在本文讨论范围内。
文件比对服务的目的是验证文件（例如高等教育证书）的真实性。用户可以从本地节点选择文件，并通过将其哈希值与存储在链上文件注册表中的关联原始文件的哈希值进行比较，以检查文件的真实性。
uBaaS：一种统一区块链即服务
5. 实现
图3使用类图说明了uBaaS的实现设计。BlockchainRegistry维护每个已部署的Blockchain网络，而Off ChainSmartContractRegistry 存储 SmartContract的源代码和信息。有三个类继承自SmartContract： OnChainDataRegistry、OnChainFileRegistry和DesignedContract。每个 OnChainDataRegistry都关联一个Off ChainDataRegistry 用于数据存储。 Record包含用户定义的数据记录属性，OnChainDataRegistry和 Off ChainDataRegistry 由Record组成。注意，存储在Record中的属性值 在存入OnChainDataRegistry之前必须使用KeyPair进行加密。File存储在 Off ChainFileRegistry 中，其哈希值存储在OnChainFileRegistry中。 DesignedContract将智能合约设计模式应用于用户编写的智能合约代码。
图3：uBaaS 实现的主类图。
该平台使用 Eclipse Java IDE 4.6.0 基于 Java 1.8 开发，并通过 Tomcat v7.0 服务器进行部署。为实现区块链部署作为
服务方面，我们使用SSH将部署文件（包括客户端文件，例如以太坊的 Geth，以及创世块文件，例如以太坊的genesis.json）传输到参与节点。 为实现数据管理服务，我们选择MySQL 5.7.17作为支持数据库，用于存 储链下数据。关于智能合约设计服务，智能合约设计模式模板已预先开发 并存储在数据库中，平台用户可选择所需应用的智能合约设计模式。对于 数据管理服务和智能合约设计服务，智能合约均使用Solidity编写，并通 过Solidity编译器版本0.4.24进行编译。编译完成后，通过web3 API将智 能合约部署到区块链上，若部署成功，则返回智能合约地址作为结果。
6. 评估
在本节中，我们评估uBaaS的可行性与可扩展性。我们首先介绍实验 环境。然后评估uBaaS中区块链部署服务和数据管理服务的可行性与可扩 展性。最后，通过一个真实世界质量追溯用例评估uBaaS中智能合约设计 服务的可行性。
6.1. 实验环境
uBaaS平台部署在阿里云⁵虚拟机（2 vCPU，8G 内存，20GB 磁盘） 上。采用的区块链为以太坊 1.5.9‐stable，其共识算法为工作量证明（ PoW）。用于链下数据存储的数据库选用 MySQL 5.7.17。我们建立了
⁵ https://www.aliyun.com/
100 台阿里云虚拟机（1 vCPU，1G 内存）作为区块链节点（节点数量根据实 验需求而变化）。
6.2. 区块链部署服务评估
我们通过测量不同节点数量的区块链的部署时间，评估了区块链部署 服务的可扩展性。我们将区块链类型设置为以太坊，难度设置为 0x4000， 并填写了用于部署的节点IP地址。根据这些设置，uBaaS在目标节点上自 动部署了以太坊区块链。
图4：区块链部署时间。
图4显示了使用uBaaS部署以太坊区块链时，随着节点数量增加的部 署时间测量结果。部署时间几乎呈线性增长，表现出良好的可扩展性。实 验结果还表明，uBaaS中的区块链部署服务是可行的。
6.3. 数据管理服务评估
数据管理服务提供的主要功能包括：1）生成链上数据注册表和链下数据 表
基于开发者构建的数据模型的传统数据库；2）向链上数据注册表和链下 数据表进行读写数据。因此，我们从两个方面评估了数据管理服务：首先， 测量在远程传统数据库中创建链下数据表以及在链上生成相应的数据注册 表智能合约的执行时间；然后，分别测试向链下表和链上智能合约读写数 据的执行时间。需要注意的是，uBaaS 当前版本在将数据存储到链上之前 会对其进行数据加密。因此，向链上数据注册表写入数据和读取数据的时 间包含了数据加密和解密的时间。
图5：生成链下数据表和链上数据注册智能合约的执行时间。
图5展示了随着数据记录属性数量的增加，创建链下数据表和生成相 关链上数据注册表的执行时间。由于以太坊中采用工作量证明（POW）机 制，在区块链上生成智能合约的执行时间远高于在传统数据库中创建表的 时间。此外，96.7%的链上数据注册表智能合约在50秒内生成。链上数据 注册表智能合约的生成时间是
由于以太坊的难度设置，区块生成时间在平均值上下波动。
图6：向链下数据表和链上数据注册智能合约写入数据的执行时间。
图6展示了随着属性数量增加，将数据写入链下数据表以及关联的链 上数据注册智能合约的执行时间。执行时间呈线性增长，显示出良好的可 扩展性。与将数据写入传统数据库中的链下数据表相比，将数据存储到链 上数据注册智能合约要慢得多，因为生成新区块并将交易包含在区块中是 耗时的。写入已部署智能合约时的时间波动也是由于上述提到的区块生成 时间不稳定所致。
图7：从链下表和链上智能合约读取数据的执行时间。
图7显示了从链上数据注册智能合约读取数据的执行时间，该时间远短于 生成链上数据注册智能合约和将数据写入已部署智能合约的时间，因为读取操 作来自区块链的本地节点。尽管如此，其仍高于从传统数据库读取数据的时间， 因为在uBaaS中，存储在链上的数据在呈现给用户之前需要进行解密。
图5‐7中的实验结果还展示了uBaaS中数据管理服务的可行性。
6.4. 智能合约设计服务评估
我们通过一个实际的质量追溯流程评估了智能合约设计服务的可行性。 图8展示了中国进口商品的质量追溯流程[29]。由中国政府认证的质量追溯 机构提供质量追溯服务，并在所有要求满足后签发商品追溯证书。该流程 始于产品供应商向追溯机构提交质量追溯申请。管理员处理申请文件（如 发票）和付款事项。一旦申请被验证通过，该机构将指派一名工厂检查员 检查工厂位置、生产能力、质量控制流程等。在完成工厂检查后，会派遣 货场检查员对放置在货场的产品进行检查，并检查现场装运过程。如果现 场装运过程符合法规要求，检查员将对集装箱进行封箱。同时，产品样品 将被送往实验室进行样品检测。当申请通过所有检查和检测后，质量追溯 机构将向供应商签发商品追溯证书。在质量追溯系统中，质量追溯机构负 责管理质量追溯流程和数据
而实验室通过质量追溯系统提交检测报告。质量监督局主要监控质量追溯 流程，不会向该系统提供任何输入。
图8：质量追溯流程。
根据质量追溯系统的设计，我们在三个节点上部署了以太坊区块链，每个 节点代表质量
追溯机构、实验室中的一个节点以及质量监督局中的一个节点。我们将难 度配置为 0x4000，并在 uBaaS 中提供了三个节点的 IP地址。随后， uBaaS 在这三个目标节点上自动部署了以太坊区块链。
contract MultipleAuthorities{
uint total;
address[] authority;
bool agreeing;
uint agreeThreshold;
mapping(address=> bool) agreeState;
bool agreePermission;
address agreeRequester;
…
function agreeSignature(){
agreeState[msg.sender]= true;
if(agreeResult())
agreePermission= true;
}
function agreeResult() internal returns(bool signatureResult){
uint k= 0;
for(uint i= 0; i<total; i++)
if(agreeState[authority[i]]== true)
k++;
if(k>= agreeThreshold)
return true;
else
return false;
}
function initialAgree() internal{
…
}
modifier isEnoughAgreement(){
if(agreeing== true && agreePermission== true && msg.sender== agreeRequester){
_;
initialAgree();
}
}
…
}
contract SampleTesting is MultipleAuthorities{
string sampleID;
bool passed;
function sampleTest(string ID){
sampleID= ID;
passed= false;
}
function pass() isEnoughAgreement(){
passed= true;
}
…
}
清单 1：使用 multiple authorities服务后更新的 SampleTesting代码。
contract DynamicBinding{
bytes32 hashKey;
bool init;
address owner;
function initial(bytes32 key){
if(init!= true){
hashKey= key;
init= true;
owner= msg.sender;
}
}
function changeKey(string oldKey, bytes32 newKey){
if(init== true)
if(hashKey== sha256(oldKey))
if(owner== msg.sender)
hashKey= newKey;
}
modifier verify(string inputKey){
if(hashKey== sha256(inputKey)){
_;
}
}
}
contract ServiceAgreement is DynamicBinding{
string firstParty;
string secondParty;
bytes32 contractHash;
…
function queryAgreement(string key) verify(key) constant returns (string, string, bytes32){
return (firstParty, secondParty, contractHash);
}
…
}
清单2：使用动态绑定服务后更新的ServiceAgreement代码。
如第4节所述，uBaaS 使用智能合约设计服务来限制对智能合约中函 数调用的访问。因此，我们选择了三种不同的功能（即样品测试结果审批、 服务协议查询和货运场图片存储），分别应用所提出的三种智能合约设计 服务：多个权威机构服务、动态绑定服务 和嵌入式权限服务。我们编写了 三个实现上述三个场景中业务逻辑的智能合约，并在每个智能合约中选择 一个函数来应用相应的智能合约设计服务。因此，uBaaS 的输出是针对智 能合约函数具备权限控制的更新后的智能合约代码。
调用。列表1‐3展示了uBaaS生成的代码。黑色部分的代码表示输入的智能 合约代码（即由开发者编写的智能合约代码），而红色高亮部分的代码则 是uBaaS中相应的智能合约设计服务生成的代码。
contract EmbeddedPermission{
address[] authority;
address owner;
function EmbeddedPermission(address[] temAuthority){
owner= msg.sender;
authority= temAuthority;
}
function changeAuthority(address[] temAuthority){
if(msg.sender== owner){
authority= temAuthority;
}
}
modifier permission(){
for(uint i= 0; i< authority.length; i++){
if(msg.sender== authority[i]){
_;
break;
}
}
}
}
contract FreightYardPic is EmbeddedPermission{
bytes32 [] freightYardPic;
address [] freightYardExaminer;
function FreightYardPic() embeddedPermission(addr){
address[] addr;
addr.push(/authority address/);
}
function setFreightYardPic(bytes32 pic, address uploader) permission(){
freightYardPic.push(pic);
freightYardExaminer.push(uploader);
}
function getFreightYardPic(uint i) constant returns (bytes32, address){
return (freightYardPic[i], freightYardExaminer[i]);
}
}
清单3：使用嵌入式权限服务后更新的 FreightYardPic代码。
样本测试智能合约实现了样品检测活动中的逻辑。根据流程设计，只 有当足够数量的实验室同意该产品通过样品检测时，产品才算通过（即调 用SampleTesting智能合约中的pass()函数）。因此，将 SampleTesting智能合约代码和所需的实验室地址作为uBaaS的输入，并 选择pass()函数，以应用多个权威机构设计模式来使用相应的服务。包含 修饰符isEnoughAgreement()附加到pass()上是在使用uBaaS mul-tiple authorities服务后添加的。 清单 1 展示了 uBaaS 中由 multiple authorities服务生成的更新后的智能合约代码。
产品供应商与质量追溯服务机构签订的质量追溯服务协议通过智能合 约ServiceAgreement实现。为了确保服务协议中的数据隐私，uBaaS通 过uBaaS在ServiceAgreement的queryAgreement()函数中添加了修饰 符verify()。只有能够提供密钥的一方才能成功读取链上存储的服务协议信 息。由uBaaS 动态绑定服务生成的智能合约代码如清单2所示。请注意， 密钥可通过调用函数changeKey()按需更改。
智能合约FreightYardPic用于维护在货场拍摄的图片。根据流程设计， 只有货运站检查员才能上传在货场拍摄的图片的哈希值。因此，我们在 uBaaS中使用EmbeddedPermission服务，为函数setFreightYardPic()添 加访问控制，仅允许特定的机构员工地址将货场图片的哈希值存储到区块 链上。由embedded permission服务生成的智能合约代码如清单3所示。
7. 结论与未来工作
本文提出了一种名为uBaaS的统一区块链即服务，该平台提供部署即 服务、设计模式即服务和辅助服务。uBaaS中的部署即服务不依赖于特定 供应商，并通过向用户隐藏部署脚本实现一键部署服务。设计模式即服务 利用设计模式来促进基于区块链的应用的数据管理和智能合约设计。我们 使用一个真实世界质量追溯用例对uBaaS的可行性和可扩展性进行了评估， 结果表明使用uBaaS设计和部署基于区块链的应用是可行且可扩展的。未 来工作包括增加更多区块链平台作为部署选项，以及在uBaaS中设计自主 身份即服务。
