uBaaS：一个统一的区块链即服务平台
摘要
区块链是一种创新的分布式账本技术，已引起广泛关注，可用于构建下一代应用，以解决商业中的信任缺失问题。区块链即服务（BaaS）是提高区块链应用开发生产力的一种有前景的解决方案。然而，现有的BaaS部署方案大多存在厂商锁定问题：它们要么绑定特定的云提供商，要么依赖于特定的区块链平台。此外，基于区块链的应用的设计与实现是一项复杂任务，需要深厚的专业知识。因此，本文提出了一种统一的区块链即服务平台（uBaaS），以支持基于区块链应用的设计与部署。uBaaS中的服务包括部署即服务、设计模式即服务和辅助服务。在uBaaS中，部署即服务具有平台无关性，可避免对特定云平台的厂商锁定，而设计模式即服务则应用数据管理和智能合约设计方面的设计模式，以应对区块链的可扩展性和安全性问题。所提出的解决方案通过一个真实世界质量追溯用例，从可行性和可扩展性方面进行了评估。
关键词 ：区块链，架构，设计模式，部署，区块链即服务
第1章 引言
区块链技术作为一种用于建立商业数字信任的分布式账本技术，已引起广泛关注。许多初创企业、企业和政府[1, 2]目前正在探索如何利用区块链技术在下一代应用中实现信任和去中心化。基于区块链的应用领域十分广泛，包括实物或数字资产所有权管理、代币、货币、身份管理、供应链、电子健康记录、投票、能源供应等。
区块链即服务（BaaS）是提高区块链应用开发生产力的一项有前景的解决方案。现有BaaS平台提供商主要提供的服务是更便捷的部署，例如微软Azure¹、IBM²和亚马逊³。然而，现有的BaaS部署解决方案通常存在供应商锁定问题，这些方案往往绑定于某个云服务商（例如微软Azure¹）或某个区块链平台（例如IBM Hyperledger²）。
除了部署之外，基于区块链的应用程序在设计和实现上对开发者来说也颇具挑战。首先，区块链是一项新技术，工具和文档有限，因此开发者可能面临陡峭的学习曲线。根据高德纳的一项调查[3]，“23%的[相关受访]首席信息官表示，区块链是实施任何技术领域所需新技能最多的，而18%的人认为区块链技能最难找到。”其次，区块链在设计上是一个不可变的数据存储，因此更新已部署的区块链智能合约可能非常困难。这使得通过发布智能合约的新版本来修复漏洞变得困难。智能合约中的错误已导致巨大的经济损失，例如以太坊区块链上的DAO攻击[4]。
软件设计模式被定义为在软件设计过程中特定上下文中常见问题的解决方案[5]。基于区块链应用的设计模式是来自工业界的最佳实践，可以作为封装服务，以减轻开发者的负担并提高基于区块链的应用的质量。一个典型的例子是链上与链下设计模式，它为基于区块链应用的数据存储提供了解决方案。分别处理的目的是在链上和链下存储数据旨在确保链上数据的完整性以及链下数据的隐私。该模式可实现为一项服务，根据开发者构建的数据模型，在传统数据库中生成链上数据注册表智能合约和链下数据表。例如，在质量追溯系统中，链上属性可以是追溯标识和追溯结果，而链下属性可以是产品价格、买家姓名等。
本文提出了一种名为uBaaS的统一的区块链即服务平台，该平台有助于基于区块链的应用程序的设计与部署。本文的贡献如下。
- 一组用于基于区块链的应用的数据管理和智能合约设计的设计模式，旨在更好地在实践中利用区块链技术。这些设计模式包括链上和链外、哈希完整性、数据加密、多个权威机构、动态绑定和嵌入式权限。
- uBaaS平台方法：
- 部署即服务 ，包括区块链部署服务和智能合约部署服务。部署即服务可以简化区块链网络部署和智能合约部署。所提出的区块链部署服务是平台无关的，可避免被锁定到特定云平台。
- 设计模式即服务 ，由数据管理服务和智能合约设计服务组成。每项服务均基于一种设计模式进行设计，以更好地利用区块链的独特特性（即不可篡改性和数据完整性、透明性），并应对局限性（即隐私和可扩展性）。
- 使用真实世界质量追溯用例评估了所提出解决方案的可行性与可扩展性。评估结果表明，我们的解决方案是可行的，并且具有良好的可扩展性。
本文其余部分组织如下。第2节讨论背景和相关工作。第3节总结了数据管理和智能合约设计的设计模式。第4节介绍了uBaaS平台的整体架构以及uBaaS提供的各项服务的设计。第5节介绍了实现细节。第6节从可行性与可扩展性方面对所提出的解决方案进行评估。第6节总结全文并展望未来工作。
2. 相关工作
本节介绍了我们研究的相关工作。首先介绍了区块链技术及其分类，因为这是本研究的基础。接着阐述了如何将区块链技术应用于软件系统，并简要介绍了当前开发基于区块链的应用所面临的障碍。最后讨论了设计模式和区块链即服务。
2.1. 区块链技术
区块链是比特币背后的技术，它是一种去中心化的数据存储，用于维护比特币网络的所有历史交易。区块链的概念已被推广到分布式账本系统，这类系统可以在不依赖任何中心化可信机构（例如传统银行系统）的情况下验证和存储交易，且无需使用代币或数字货币。相反，区块链网络中的所有参与者可以通过达成共识来确认交易数据的状态，从而建立信任。
区块链的数据结构是一个有序的可识别区块列表，每个区块都连接到链中的前一个区块。区块是聚合交易的集装箱，而交易则是存储参数（如货币价值）和对智能合约的函数调用的可识别数据包。智能合约是一种用户定义的程序，部署并执行于区块链网络上[8]，可用于表达触发器、条件和业务逻辑[9]，从而实现更复杂的可编程交易。智能合约可以作为交易的一部分来实现，并由区块链网络中所有连接的节点共同执行。以太坊区块链平台提供了一种内置的图灵完备脚本语言Solidity，用于编写智能合约。以太坊虚拟机（EVM）是以太坊的执行环境，由网络上的所有全节点组成，负责执行从Solidity脚本编译而来的字节码。
2.2. 区块链类型
如表1所示，根据部署方式，区块链分为三种类型，包括公有区块链、联盟区块链和私有区块链。公有区块链被大多数数字货币所采用，互联网上的任何人都可以访问。使用公有区块链可实现更高的数据透明性和可审计性，但会牺牲性能并具有
| Type | Cost | 效率 | 性能 | 灵活性 |
|---|---|---|---|---|
| 公有区块链 | ⊕⊕⊕ | ⊕ | ⊕ | ⊕ |
| 联盟区块链 | ⊕⊕ | ⊕⊕ | ⊕⊕ | ⊕⊕ |
| 私有区块链 | ⊕ | ⊕⊕⊕ | ⊕⊕⊕ | ⊕⊕⊕ |
不同的成本模型。联盟区块链通常在多个组织之间使用，并通过预先授权的节点来控制共识过程。在私有区块链网络中，写入权限通常由一个组织内部掌控，尽管这可能包括单个组织内的多个部门。对联盟或私有区块链的读取权限可以是公共的，也可以限制给特定的一组参与者。在使用联盟区块链或私有区块链时，需要权限管理组件来授权区块链网络内的参与者。
私有区块链在配置上最具灵活性，因为网络由单一组织进行管理和托管。我们的工作主要集中在联盟区块链和私有区块链上。
2.3. 区块链作为软件应用系统的组件
学术界的研究人员和工业界的开发者正在研究和探索如何利用区块链技术构建下一代应用[1, 2]。工业领域的应用范围包括但不限于数字货币、国际支付、注册机构、政府身份和税务管理、物联网（IoT）身份识别与安全管理，以及供应链[10, 11, 12, 13]。此外，已有大量学术研究利用区块链解决不同领域中的问题。Qu 等人[14]提出了支持快速查询处理的时空区块链技术，已被证明具有适用性和有效性。Zyskind 等人利用区块链构建了一个个人数据管理系统，确保用户以去中心化方式拥有并控制其数据[15]。Bu-lati Nasrulin 等人提出了一种基于区块链构建的移动性分析应用[16]，并通过分布式数据库对区块链进行了改进[17]。
管理 智能合约
去中心化的 数据账本 传统数据库
组件
链上
数据层
逻辑层
表现层 用户界面
| 权限 管理||激励 机制|
| —|—|—|
| 验证||密码学|
预言机
平台层
链下
图1：区块链作为软件应用系统的组成部分。
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]。
解决方案 ：可以在每个智能合约函数中添加权限控制，以在执行函数逻辑之前，基于调用者的区块链地址检查每个函数调用者的权限。来自未经授权的区块链地址的调用将被拒绝。
4. uBaaS架构
在uBaaS中，我们提出了部署即服务以实现与供应商无关的部署，以及设计模式即服务以解决基于区块链的应用的可扩展性和安全性问题。图2展示了uBaaS的整体架构。uBaaS中提出的服务分为三类：deployment as a service、design pattern as a service和auxiliary services。用户可以通过uBaaS前端用户界面构建区块链环境并设计基于区块链的应用，该前端用户界面通过API网关与后端服务进行交互。API网关将来自前端用户界面的API调用转发到相应的服务。
本节其余部分将分别介绍部署即服务、设计模式即服务和辅助服务。部署 即服务
A
u x
i l i
a
r
y
s e
r
v
i
c e s
区块链 部署
智能合约 部署
密钥生成
文件比较
数据管理服务 智能合约设计 服务
开发者
区块链
node
数据加密
哈希完整性 多个权威机构
动态绑定
嵌入式 权限
部署 参数
智能 合约
智能 合约
code
链下 数据库
文件哈希
Data
模式
链下
data
模式
链上数据/文件 注册表智能合约
操作员
User
File
Data
Key
请求
Key pair
加密密钥
链下
数据/文件
链上和链下
包括链上数据 加密数据和 哈希文件
智能 合约
图2：uBaaS架构。
服务包含两种部署服务，设计模式即服务包括6种设计模式服务，以帮助开发者利用区块链的特性并应对区块链的局限性，而辅助服务可作为辅助手段，更好地发挥设计模式即服务的作用。
4.1. 部署即服务
部署即服务包括区块链部署服务和智能合约部署服务。用户可以配置区块链设置（如难度和参与节点IP），并使用uBaaS部署其自定义的区块链网络。基础设施即代码被应用于区块链部署服务中，通过开发的脚本实现部署、配置和任务管理的自动化。区块链建立后，用户可以实时监控区块链的状态，并在区块链上部署已开发的智能合约。由于我们专注于联盟区块链和私有区块链，因此假设我们可以访问参与节点。目前，支持以太坊区块链和Hyperledger Fabric区块链。我们计划在uBaaS中增加更多区块链平台作为部署选项。
智能合约部署服务使用户能够选择已开发的智能合约（即程序）文件，并将智能合约代码部署到区块链上。此外，智能合约地址和应用二进制接口（ABI）将存储在链下数据库中，以便调用已部署的智能合约。
4.2. 设计模式即服务
设计模式即服务由数据管理服务和智能合约设计服务组成。数据管理服务包括链上和链下服务、数据加密服务以及哈希完整性服务，而智能合约设计服务包含多权限机构服务、动态绑定服务和嵌入式权限服务。每种服务类型均基于一种设计模式进行设计，以提升基于区块链的应用的可扩展性、适应性和安全性。数据管理服务使用户能够通过uBaaS前端用户界面直接管理数据，而智能合约设计服务则将智能合约设计模式集成到原始智能合约中。
4.2.1. 数据管理服务
为了解决区块链存储能力有限和数据隐私的问题，提出了一种链上和链下服务，将需要不可篡改的关键数据存储在链上，而将所有数据保留在链下，以提高数据读取效率。用户可以定义数据模式，并确定哪些属性存储在链上、哪些存储在链下。基于用户构建的数据模型，该服务通过部署生成的链上数据注册智能合约在区块链上建立链上数据注册表，并在传统数据库中设置链下数据表。链上数据注册表与链下数据表具有相同的名称。用户可向所选的数据存储中写入/读取数据，而无需关心数据是存储在链上还是链下。
为了保护相关参与者的隐私，uBaaS提供了一项数据加密服务，对链上数据进行加密，以确保存储在区块链上的数据的机密性。uBaaS用户首先使用私钥（由辅助服务中的密钥生成服务生成）对数据项进行加密，然后将其存储在区块链上。拥有公钥的区块链参与者可以访问交易并解密信息。通过使用链上数据加密服务，未持有公钥的区块链参与者无法访问存储在区块链上的敏感数据。
为了在区块链上存储大容量数据（即文件），hash integrityservice 会生成该文件的哈希值，并将该哈希值存储在链上文件注册表中，该注册表通过预定义的外键与链上数据注册表相关联。
4.2.2. 智能合约设计服务
智能合约设计服务专注于智能合约函数调用的权限控制。每项服务的输入是用户编写的智能合约代码，输出则是通过添加实现相应智能合约设计模式的模板代码而得到的更新后的智能合约代码。
多权限机构服务专注于仅在授权区块链地址批准后才能调用的智能合约函数。用户可以预先定义一组能够授权交易（即调用智能合约中的函数）的区块链地址，并设置最小
用于交易批准的授权数量。用户需要选择他们编写的智能合约以及需要多个权威机构机制的函数。然后uBaaS会修改所选函数的代码，并生成包含多个权威机构代码的更新后的智能合约。
动态绑定服务使用链下密钥，以便在批准交易（即调用智能合约中的函数）的参与者事先未知时实现动态授权。用户需要提供一个密钥（例如一个随机数），并选择智能合约中对应的函数。该服务通过添加密钥的哈希值来修改函数代码，并生成更新后的智能合约。无需专门的协议来交换密钥，因为密钥可以通过任意链下方式进行交换。只有拥有密钥的用户才能调用智能合约中选定的函数。
嵌入式权限服务的目的是限制对智能合约中定义的函数调用的访问。用户可以通过提供授权地址来识别智能合约中选定函数的授权方。该服务将权限控制代码添加到智能合约函数中，在执行函数逻辑之前，根据调用者的区块链地址对每次调用者进行权限检查。
4.3. 辅助服务
当前版本的uBaaS支持两种辅助服务：密钥管理服务 和文件比对服务。
密钥管理服务 用于为数据加密生成密钥对。开发者可以使用数据加密服务对数据进行加密，并在将加密数据存储到链上数据注册表之前，将解密密钥共享给其他平台用户（例如开发者或申请用户）。解密密钥的共享通道不在本文讨论范围内。
文件比对服务
的目的是验证文件（例如高等教育证书）的真实性。用户可以从本地节点选择文件，并通过将其哈希值与存储在链上文件注册表中的相关原始文件的哈希值进行比较，来检查文件的真实性。
区块链区块链
标识: 字符串 IP地址: 字符串
区块链类型: 字符串 难度: 字符串
部署Fabric(IP地址): 布尔值
部署Ethereum(IP地址, 难度): 布尔值
1
0..*
离链数据注册表离链数据注册 表
记录: 记录
添加记录(): 无返回值
获取记录(): 记录
1 1
文件 文件
标识: 字符串
路径: 字符串 名称: 字符串 文件内容:字符串
文件哈希: 字符串
获取文件 () : 无返回值
SHA256(文件内容): 字符串
密钥对密 钥对
publicKey: 公钥 privateKey: 私钥
生成密钥对(): 无返回值
获取公钥(): 公钥 获取私钥(): 私钥
链上文件注册表链上文件注 册表
文件ID: 字符串 文件哈希: 字符串
设置文件哈希(文件ID, 文件哈希): 无返回值
获取文件哈希(文件ID)：字符串
1
记录记录
属性名称: 字符串 属性：类型 （用户定义的属性） 加密属性值（公钥，属性）：字符串 解密属性值（私钥，属性）：类型 设置属性值（属性名称，属性）：无返回值 获取属性值（属性名称）：类型 检查完整性（属性，在链属性）：布尔值
链下文件注册表链下文件注 册表
文件ID: 字符串 文件哈希: 字符串
设置文件哈希(文件ID, 文件哈希): 无返回值
获取文件哈希(文件ID)：字符串
检查完整性(文件哈希,
链上文件哈希）：布尔值
setContractInfo(地址,
源代码,应用二进制接口 ) : 无返回值
getContractInfo(): 字符串[]
区块链注册表区块链注册 表
标识: 字符串 IP地址: 字符串
区块链类型: 字符串
setBlockchainInfo(标识,IP地址,
区块链平台）：无返回值
getBlockchainInfo()：字符串[]
1
1
*
图3：uBaaS实现的主类图。
0
1000
2000
3000
4000
5000
6000
7000
8000
9000
10000
0 10 20 30 40 50 60 70 80 90 100
D
e p
l
o y
m
e n
t t
i
m
e
( s )
节点数量
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将智能合约设计模式应用于用户编写的智能合约代码。 该平台使用Eclipse Java IDE 4.6.0基于Java 1.8开发，并通过Tomcat v7.0服务器发布。为实现区块链部署作为一项
0
10
20
30
40
50
60
70
0 10 20 30 40 50 60 70 80 90 100
E x e c
t
u
i
o n
t
i
m
e
( s )
属性数量
链下表 链上合约
服务，我们使用SSH将部署文件（例如以太坊的Geth客户端文件和创世块 文件genesis.json）传输到参与节点。为了实现数据管理服务，我们选择 MySQL 5.7.17作为支撑数据库，用于存储链下数据。在智能合约设计服 务方面，智能合约设计模式模板已预先开发并存储在数据库中，平台用户 可以选择希望应用的智能合约设计模式。对于数据管理服务和智能合约设 计服务，智能合约均使用Solidity编写，并通过Solidity编译器版本 0.4.24进行编译。编译完成后，通过web3 API将智能合约部署到区块链 上，若部署成功，则返回智能合约地址作为结果。
0
20
40
60
80
100
120
140
0 10 20 30 40 50 60 70 80 90 100
E
c
e
c
u
t
i
o n
t
i
m
e
( s )
属性数量
链下表 链上合约
6. 评估
在本节中，我们评估uBaaS的可行性与可扩展性。首先介绍实验环境。 然后评估uBaaS中区块链部署服务和数据管理服务的可行性与可扩展性。 最后，通过一个真实世界质量追溯用例来评估uBaaS中智能合约设计服务 的可行性。
6.1. 实验环境
uBaaS 平台部署在阿里云5虚拟机（2 核虚拟CPU，8G 内存，20GB 磁盘）上。采用的区块链是 Ethereum 1.5.9‐stable，其共识算法为工作量证明 （PoW）。用于链下数据存储的数据库选用的是 MySQL 5.7.17。我们建立了
5https://www.aliyun.com/
0
200
400
600
800
1000
1200
1400
1600
1800
2000
0 10 20 30 40 50 60 70 80 90 100
E
x
e
c
u
t
i
o n
t
i
m
e
(
m
s )
属性数量
链下表 链上合约
100 台阿里云虚拟机（1 核虚拟CPU，1GB内存）作为区块链节点（节点数量 根据实验需求而变化）。
6.2. 区块链部署服务评估
我们通过测量不同节点数量的区块链的部署时间，评估了区块链部署 服务的可扩展性。我们将区块链类型设置为以太坊，难度设置为 0x4000， 并填写了用于部署的节点IP地址。根据这些设置，uBaaS在目标节点上自 动部署了以太坊区块链。
图4显示了使用uBaaS增加节点数量时以太坊区块链部署时间的测量 结果。部署时间几乎呈线性增长，表现出良好的可扩展性。实验结果还表 明，uBaaS中的区块链部署服务是可行的。
6.3. 数据管理服务评估
数据管理服务提供的主要功能包括：1）生成链上数据注册表和链下数据 表
提交 申请
处理 申请
检查 工厂
检查 产品 监督 装货
Seal
集装箱
Test
样本
接收 证书
颁发 证书
S
u p p
l i
e
r
Q
u a
l i
t
y
t
ci
r
a
n g
a g e n
c y
F a
c
t
o
r
y
i
n
s
p e
c
t
o
r
F
r
e
i
gh
t
y
a
r
d
i
n
s
t cpe
o
r
A
d
m
i
n
L a b
基于开发者构建的数据模型的传统数据库；2）向链上数据注册表和链下 数据表写入/读取数据。因此，我们从两个方面评估了数据管理服务：首先， 测量在远程传统数据库中创建链下数据表并在链上生成相应数据注册表智 能合约的执行时间；然后，分别测试向链下表和链上智能合约写入/读取数 据的执行时间。需要注意的是，uBaaS 当前版本在将数据存储到链上之前 会对其进行数据加密。因此，向链上数据注册表写入和读取数据的时间包 括了数据加密和解密的时间。
图5展示了随着数据记录属性数量的增加，创建链下数据表和生成相 关链上数据注册表的执行时间。由于以太坊中采用工作量证明（POW）机 制，在区块链上生成智能合约的执行时间远高于在传统数据库中创建表的 时间。此外，96.7%的链上数据注册表智能合约在50秒内生成。链上数据 注册表智能合约的生成时间是
由于以太坊的难度设置，区块生成时间在平均值上下波动。
图6展示了随着属性数量的增加，将数据写入链下数据表和关联的链 上数据注册智能合约的执行时间。执行时间呈线性增长，表现出良好的可 扩展性。与在传统数据库中将数据写入链下数据表相比，将数据存储到链 上数据注册智能合约要慢得多，因为生成新区块并将交易包含在区块中需 要耗费时间。部署的智能合约在写入数据时的波动也是由于上述提到的区 块生成时间不稳定所致。
图7显示了从链上数据注册表智能合约读取数据的执行时间，由于读取操 作来自区块链的本地节点，因此该时间远短于生成链上数据注册表智能合约以 及向已部署的智能合约写入数据的时间。然而，与从传统数据库读取数据相比， 其执行时间仍然较高，因为在uBaaS中，存储在链上的数据在呈现给用户之前 需要先进行解密。
图5‐7中的实验结果还展示了uBaaS中数据管理服务的可行性。
6.4. 智能合约设计服务评估
我们通过一个真实的质量追溯流程评估了智能合约设计服务的可行性。 图8展示了中国进口商品的质量追溯流程[29]。由中国政府认可的质量追溯 机构提供质量追溯服务，并在所有要求满足后颁发商品追溯证书。该流程 始于产品供应商向追溯机构提交质量追溯申请。管理员处理申请文件（如 发票）和付款事项。一旦申请被验证，该机构将指派一名工厂检查员检查 工厂位置、生产能力、质量控制流程等。在完成工厂检查后，货场检查员 将被派往货场检查存放的产品，并监督现场装货过程。如果现场装货过程 符合规定，检查员将对集装箱进行封箱。同时，产品样品将被送往实验室 进行样品检测。当申请通过各项检查和检测后，质量追溯机构将向供应商 颁发商品追溯证书。在质量追溯系统中，质量追溯机构负责管理质量追溯 流程和数据
而实验室通过质量追溯系统提交测试报告。质量监督局主要监控质量追溯 流程，不会向该系统提供任何输入。
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{ str ing samp leID; bool passed; fun ct ion sam p leTest(str ing ID){ sam p leID= ID; p assed= false; } fun ct ion p ass() isEnou g hA g reement(){ p assed= true; }
...
}
列表 1：使用 multiple auhtorities服务后更新的 SampleTesting代码。
根据质量追溯系统的设计，我们在三个节点上部署了以太坊区块链，每个 节点代表质量
追溯机构、实验室中的一个节点以及质量监督局的一个节点。我们将难度 配置为 0x4000，并在uBaaS中提供了三个节点的IP地址。随后，uBaaS 在三个目标节点上自动部署了以太坊区块链。
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{ str ing firstParty; str ing secondParty; bytes32 contractHash;
...
fun ct ion queryAgreem ent(string key) verify(key) con stant return s (string, string bytes32){
第1卷, 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/);
}
fun ct ion setFreightYardPic(bytes32第1卷 address uploader) permission(){ freightYardPic. push(pic); freightYardExaminer. push(uploader); } fun ct ion getFreightYardPic(u int i) con stant return s (bytes32, address){ return (freightYardPic[i], freightYardExaminer[i]); } }
清单3：使用嵌入式权限服务后更新的FreightYardPic代码。
SampleTesting 智能合约实现了样品检测活动中的逻辑。根据流程 设计，只有当足够数量的实验室确认产品通过样品检测时，产品才算通过 （即调用 SampleTesting 智能合约中的 pass() 函数）。因此，将 SampleTesting 智能合约代码和所需实验室地址作为 uBaaS 的输入，并 选择 pass() 函数以应用 multiple authorities设计模式并使用相应的服务。包含 修饰符 isE‐ 的 MutlipleAuthorities 智能合约
附加到 pass() 的 noughAgreement() 是在使用 uBaaS mul-tiple authorities服务后添 加的。列表 1 展示了 uBaaS 中 multiple authorities服务生成的更新后的智能合约代码。
产品供应商与质量追溯服务机构签订的质量追溯服务协议通过智能合 约ServiceAgreement实现。为了确保服务协议中的数据隐私，uBaaS通 过uBaaS在ServiceAgreement的queryAgreement()函数中添加了修饰 符verfy()。只有能够提供密钥的一方才能成功读取链上存储的服务协议信 息。由uBaaS 动态绑定服务生成的智能合约代码如清单2所示。请注意， 密钥可通过调用函数changeKey()按需更改。
智能合约FreightYardPic用于维护在货场拍摄的图片。根据流程设计， 只有货运站检查员才能上传在货场拍摄的图片的哈希值。因此，我们在 uBaaS中使用EmbeddedPermission服务，为函数setFreightYardPic()添 加访问控制，仅允许特定机构员工地址将货场图片的哈希值存储到区块链 上。由嵌入式权限服务生成的智能合约代码如清单3所示。
7. 结论与未来工作
本文提出了一种名为uBaaS的统一的区块链即服务平台，该平台提供 部署即服务、设计模式即服务以及辅助服务。uBaaS中的部署即服务不依 赖于特定供应商，并通过向用户隐藏部署脚本实现一键部署服务。设计模 式即服务利用设计模式来促进基于区块链的应用的数据管理和智能合约设 计。我们通过一个真实世界质量追溯用例对uBaaS的可行性和可扩展性进 行了评估，结果表明使用uBaaS设计和部署基于区块链的应用是可行且具 备可扩展性的。未来工作包括增加更多区块链平台作为部署选项，以及在 uBaaS中设计自主身份即服务。
扫一扫
1339
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
