在现代商业环境下，为了实现共同的商业目标，每个企业的业务过程常常需要与其他企业的业务过程进行交互和协作，形成协同优势并满足商业需求^[1]，这种复杂过程被称为业务过程协同^[2]。为了增加业务过程协同的信任度和透明度，区块链技术^[3]被引入，用于记录业务过程协同中各个企业的互操作行为。在区块链环境下，业务过程协同可以按照约定的顺序进行，并且协同的互操作信息不可篡改且可追溯审计^[4]。

在业务过程协同中，现有的数据通信方式主要有2种：1) 使用Wf-XML 2.0协议^[5]规定的方式传递数据。Wf-XML 2.0协议是一个工作流引擎之间的互操作标准，在数据通信时使用统一资源标识符(uniform resource identifier，URI)进行数据传递。然而，使用该方式进行数据通信时会将URI记录于区块链上，此时业务数据的可靠性和区块链的可追溯性会受到影响。一方面通过URI所能获取到的数据内容能被数据拥有者修改，另一方面区块链中的URI也会因实际数据的存放位置改变而失效，这两方面原因有可能导致业务过程协同的其他成员获取到错误的数据或者获取不到数据，从而影响数据的可靠性，也导致区块链没有数据的操作记录而影响可追溯性。2) 直接通过区块链传递数据。使用这种方式传递数据时，各个成员节点会复制该数据以保证区块链的不可篡改性，当数据过多或者过大时就会给区块链系统带来严重的存储开销。这2种数据传递方式都无法满足正常的业务过程协同需求。

此外，在业务过程协同中引入区块链会有泄漏数据隐私的风险。一般情况下，业务过程协同中对数据的要求为部分成员可见，而区块链上的记录对所有成员都是可见的，这导致了组织对数据隐私泄露的担忧^[6-7]。由此可见，在基于区块链的业务过程协同中数据通信仍存在挑战。

为了保持数据的可靠性、区块链的可追溯性以及解决数据隐私泄露问题，本文提出了一种面向业务过程协同的隐私数据通信方法，其贡献在于：1) 拓展了Wf-XML 2.0协议，使业务过程管理系统(business process management system，BPMS)^[8]能够对Activity的自定义字段进行操作从而支持基于区块链的业务过程协同的数据通信；2)结合IPFS(inter planetary file system)^[9]和非对称加密^[10]技术设计了面向业务过程协同的隐私数据传输方法及相应的算法；3)分别通过Dolev-Yao攻击者模型^[11]、实际案例、实验验证该方法的安全性、合理性、可行性。

1.   相关工作

目前已有不少研究将区块链技术应用于电子数据^[12-13]、电子健康记录^[14]、金融市场^[15]、能源供应^[16]、供应链^[17]和物联网^[18]等领域，同样也有不少研究推动了区块链技术与业务过程管理领域的集成。Corradini等^[19]提出了一种利用BPMN模型来描述过程协同的方法，并基于区块链实现FlexChain框架，解决了过程协同灵活性不够的问题。Fang等^[20]提出了一个理论框架和方法，用于解决区块链网络在制定工作流服务之间互操作性的建模问题。Suliman 等^[21]基于区块链提出BlockCheck框架，为复杂BPMN流程模型提供可信的一致性检查。López-Pintado等^[22-23]实现了Caterpillar流程引擎，从而实现了流程实例状态的监控和流程任务的执行功能，并且解决了任务实例没有操作权限的问题。

总体而言，将区块链技术集成到业务过程管理领域中的研究还处于比较早期的阶段^[24]，而且多数研究是一种仅适用于单个组织或公司的集中式架构，难以直接应用于业务过程协同。另外，不同企业的BPMS通常是异构的，将区块链应用于业务过程协同时异构的BPMS需要进行适配，这也成为组织间业务过程协同的一个阻碍。为了能在区块链环境下支持组织间的业务过程协同并支持标准化，唐玄昭等^[25]此前提出一个基于区块链的业务过程协同框架。然而这个框架还不能解决在协同过程中的数据隐私问题。因此，需要有一个安全、合理、可行的隐私数据通信方法来解决基于区块链的业务过程协同中的数据隐私问题。

2.   隐私数据通信方法设计

2.1   方法框架

本文提出的隐私数据通信方法基于图1的业务过程协同框架。框架的主要功能模块有Broker、IPFS、控制模块和通信模块。

图  1  业务过程协同框架

Fig.  1  Business process collaboration framework

下载: 全尺寸图片

Broker　Broker是工作流引擎和区块链中间的操作代理，将Wf-XML2.0协议映射为区块链的概念和操作，从而接收工作流引擎的的互操作请求，调用区块链功能，并保存了区块链的一些关键信息(区块链成员身份信息、公钥对应关系及自身区块链私钥等)。

IPFS　IPFS是一种新型的去中心化存储架构，提供了一种更加安全、方便集成的链下存储解决方案。IPFS存储时将业务数据划分成固定大小的块，根据内容计算哈希值，块组合后再计算完整的业务数据地址哈希。本文后续将这个地址哈希简称为地址，只有通过该地址才能向IPFS获取到原始的业务数据。如图2所示，本文将Broker和IPFS结合，用以实现上传和获取业务数据的功能。

图  2  使用IPFS上传和获取数据

Fig.  2  Upload and retrieve data using IPFS

下载: 全尺寸图片

控制模块　控制模块是控制着业务过程协同正常进行的智能合约。控制模块代表业务过程协同实例，协同状态代表BPMS的互操作行为，加密地址记录着加密后的数据地址。可以同时存在多个过程协同模块，表示多个业务过程协同在同时进行。

通信模块　通信模块是用于业务数据发送获取的智能合约。数据请求记录了数据请求者对控制模块中加密地址的请求信息，数据响应记录了数据拥有者对请求的响应信息。在本文框架中仅用一个通信模块来进行数据通信。

2.2   Wf-XML2.0协议拓展及映射

工作流管理联盟(workflow management coalition, WfMC)对业务过程协同有深入的研究，在WfMC提出的工作流管理模型中，定义了一个工作流引擎间的互操作接口^[26]。随着网络技术的发展， Wf-XML 2.0协议作为工作流引擎间的互操作标准被提出，定义了工作流引擎间的互操作接口标准。由于在本文的框架中工作流引擎实际上是与区块链进行互操作，所以需要将Wf-XML 2.0协议的概念映射为区块链的概念。Wf-XML 2.0的基本概念映射如表1所示。

Wf-XML 2.0协议规定的方式无法满足正常的业务过程协同需求，为了保持引入区块链带来的可信性和支持Broker的自动化，本文拓展了Wf-XML 2.0协议，具体的概念映射如表2所示。在对Wf-XML2.0协议进行映射时，Activity实际上对应BPMS在一个协同流程实例中的一次互操作行为。因此，本文在拓展时将ActivityData定义为协同流程实例Activity中某个自定义字段，将SetActivityData和GetActivityData分别定义为对ActivityData的设置和获取操作。本文将数据通信视为一个带有数据的互操作行为，同时要求数据有访问控制列表用以保护数据隐私，因此本文的ActivityData特指原始数据和访问控制列表。

2.3   方法步骤与算法设计

拓展了Wf-XML2.0协议后， Broker也需要根据新的协议内容进行相应的设计与实现，满足在区块链场景下业务过程协同的数据通信需求。同时为了使BPMS对数据传输的隐私保护无感知，本文对Broker拓展了自动化的隐私数据通信功能。本文将Broker的隐私数据通信分为保存数据、请求数据和响应数据3个步骤，并为每个步骤的执行设计了算法。SetActivityData和GetActivityData执行时的工作流程分别如图3和图4的时序图所示。本文将保存数据的一方称为拥有方，请求数据的一方称为请求方。

图  3  SetActivityData

Fig.  3  SetActivityData

下载: 全尺寸图片

图  4  GetActivityData

Fig.  4  GetActivityData

下载: 全尺寸图片

SetActivityData　如图3所示，拥有方的BPMS通过调用SetActivityData接口发出保存数据的请求，Broker将数据保存到IPFS中从而获得数据地址，设置该数据的访问控制列表并加密数据地址，在控制模块上保存加密地址。

GetActivityData　如图4所示，请求方的BPMS通过GetActivityData接口发出获取数据的请求，请求方的Broker收到请求后通过通信模块向拥有方请求原始数据，拥有方的Broker同样通过通信模块的智能合约发送响应数据的结果。请求方的Broker收到数据响应结果后进行验证，成功后向IPFS获取原始数据。

在GetActivityData的时序图中拥有方的BPMS没有参与该过程，因为在SetActivityData时拥有方设置了数据的访问控制列表，此时拥有方的Broker根据数据的访问控制列表自动执行并返回结果。

本文方法在进行数据通信时需要使用图1中的控制模块和通信模块来支持算法的实现。保存数据、请求数据和响应数据3个数据通信步骤的算法如下。

保存数据　Broker将数据d存储到IPFS上并获取业务数据的地址a，使用拥有方的区块链公钥p_own(后续区块链的公钥和私钥简称为公钥和私钥)对数据地址a进行非对称加密，将加密后数据地址e_a存储到控制模块上，在Broker设置该数据的访问控制列表l_a供后续数据响应步骤的自动执行，该步骤如算法1所示。通过执行该算法，控制模块上记录的加密地址仅有拥有者能使用私钥解密出原始数据的地址。

算法1　保存数据

输入　业务数据d，访问控制列表l_a，拥有方公钥p_own。

1)通过IPFS保存d，获得地址a

2)使用p_own加密a，获得e_a

3)调用智能合约将e_a保存到控制模块

4)将e_a的访问控制列表设置为l_a

请求数据　Broker通过通信模块发起数据请求，数据请求的内容为控制模块中的加密地址e_a，随后等待数据拥有方的数据响应结果r。成功获取数据时，数据响应结果r_a为数据请求者公钥p_req对数据地址a的加密结果。此时，请求者的Broker通过自身私钥s_req还原出数据地址a'，并用数据拥有者公钥p_own再次对a'加密获得e_a '，验证e_a '是否与e_a一致，从而判断数据是否与过程协同模块上的记录一致。该步骤如算法2所示。通过执行该算法，通信模块上记录的数据请求，仅拥有者能使用私钥解密出原始数据的地址。

算法2　请求数据

输入　数据加密地址e_a，请求方私钥s_req，拥有方公钥p_own。

输出　ret(原始数据或者NULL)。

1)使用e_a通过数据模块请求数据，获得响应r_a

2) IF r_a ≠ NULL THEN

3)使用s_req从r_a还原出数据地址a'

4)使用p_own再次加密a'得到e_a '

5) IF e_a ' == e_a THEN

6)使用a'从IPFS获取数据d

7) ret = d

8) END IF

9) END IF

10) RETURN ret

响应数据　Broker收到数据请求自动执行返回结果。Broker使用自身私钥s_own还原数据请求内容e_a得到数据地址a，判断请求者是否在访问控制列表l_a里，返回一个空数据响应，或请求者的公钥p_req对a的加密结果r_a。该步骤如算法3所示。通过执行该算法，数据通信模块上记录了该数据响应，仅有请求者能使用私钥还原出原始地址。

算法3　响应数据

输入　数据加密地址e_a，请求方私钥s_own，拥有方公钥p_req。

输出　ret(加密地址或者NULL)。

1)初始化ret为NULL

2)使用s_own从e还原出数据地址a

3) IF p_req在a的访问控制列表l_a里 THEN

4)使用p_req加密a获得加密地址r_a

5) ret = r_a

6) END IF

7) RETURN ret

3.   方法验证

3.1   安全性

本文使用Dolev-Yao攻击者模型对本文所提方法的安全性进行分析。Dolev-Yao攻击者模型在既定完善的密码系统的基础上分析安全协议的正确性、安全性和冗余性等，该模型刻画了攻击者的行为：窃听和拦截所有经过网络的消息、存储拦截到的或自己构造的消息、发送拦截到的或自己构造的消息以及作为合法主体参与协议的运行。由于区块链的数据共享，区块链网络中所有成员都是潜在的攻击者。下面将通过Dolev-Yao攻击者模型的形式化描述^[27]分析攻击者于本文方法框架中是否能窃取到业务数据。

定义以下符号：

S_PKS，区块链所有成员公钥的集合。

P_X，成员X的公钥。

S_X，成员X的私钥。

P_X(I)，使用P_x加密信息I。

S_X(I)，使用S_x解密信息I。

假设有3个成员：攻击者A，拥有者O，请求者R。O直接将数据或者数据的IPFS地址a保存在区块链中是不安全的，因为A可以轻松获取。而使用本文通信方法时，O在执行保存数据步骤后，A的信息集T为

R执行请求数据且O执行相应数据后，A的信息集T更新为

由于本文方法使用了非对称加密，因此有以下关系：

因此，通过本文方法传输数据后，A只能通过S_O或S_R来获取数据地址a，由于S_O和S_R都不在攻击者A的信息集T里，A无法获取到原始的数据，从而说明本文方法的安全性。

3.2   合理性

本小节通过一个实际案例分析本文方法的合理性。图5是一个论文审查协同流程模型^[28]，该过程协同有1个程序委员会主席、3个审核专家和1个联系作者，假设这些成员分别代表不同组织的BPMS，本文仅关注程序委员会主席向3个审核专家发送评审请求这一数据通信部分。不妨假设数据包含了业务数据(比如评审请求里包含了论文)，按照Wf-XML 2.0协议的方式和或直接通过区块链传输的方式进行数据传输时会将业务数据的信息保存在区块链上。由于区块链上的数据对所有成员可见，当区块链中存在其他的联系作者时，业务数据可以轻易被其他联系作者获取，这极其不合理。

图  5  论文审查协同流程模型

Fig.  5  Collaborative process model for paper review

下载: 全尺寸图片

显然，对数据进行加密传输是非常必要的。然而在本文的方法框架上(如图1所示)，还存在着一对一的非对称加密数据通信方法(简称一对一方法)。就图5的论文审查协同流程而言，程序委员会主席向3个审核专家发送评审请求这一数据通信部分使用一对一方法需要分别对每一个审核专家发送加密数据地址，对应着图1控制模块中的3个协同状态和3个加密地址字段。而1个协同状态代表着BPMS的1次互操作行为，所以程序委员会主席在发送同样的评审请求时，需要执行3次互操作行为。在审核专家数量不同的情况下，程序委员会主席需要执行的互操作行为次数等同于审核专家的个数，当有大量的审核专家时，论文审查协同的互操作行为次数就非常不合理。

相比之下，本文的方法不仅使用了非对称加密技术，而且通过访问控制列表实现Broker的自动化执行，所以程序委员会主席发送评审请求需要1个协同状态记录程序委员会主席的保存行为，1个加密地址用来记录程序委员会主席传输的加密地址。图6为一对一非对称加密通信方法(记为一对一方法)和本文方法的协同开销对比(协同状态个数或加密地址个数)，不难发现一对一方法的协同开销会随着数据接收对象数量增加而线性增加，而本文方法的协同开销固定为1个协同状态和1个加密地址。由于在不同数据接收对象的情况下一对一方法需要进行多次互操作行为，而本文方法仅需进行一次互操作行为，所以本文方法更加合理。

图  6  协同开销

Fig.  6  Collaboration cost

下载: 全尺寸图片

3.3   可行性

本小节将通过实验分析以下3种数据通信方法的开销: 1) 直接通信。通过区块链直接传输数据，记为方法1。2) 使用非对称加密一对一通信。发送方使用非对称加密传输数据，接收方获取数据，记为方法2。3) 使用本文方法通信，通过保存数据、请求数据和相应数据3个步骤传输数据，记为方法3。实验内容为在使用不同大小的数据进行多次双方通信，对比上述3种方法的平均存储开销和运行时间开销，来验证本文方法的可行性。实验环境如表3所示。

在区块链上传输数据时，除了存储该数据，还需要存储其他信息(记为C_m，视为常量)，故操作一次大小为d的数据的需要的存储空间M(d)为

式中N为节点个数，假设节点同步速率为S(视为常量)，操作一次大小为d的数据所需时间T(d)为

对于数据操作次数，方法1和方法2需要2次(保存1次，获取1次)，方法3操作3次数据(对应本文方法3个步骤)。对于数据的大小，方法1为原始数据大小d，方法2和方法3为数据地址大小A(常量)。因此3种方法的时间和空间开销会有所不同。其中方法1的时间开销为2T(d)，空间开销为2M(d)， 方法2的时间开销为2T(A)，空间开销为2M(A)，方法3的时间开销为3T(A)，空间开销为3M(A)。

在给定实验环境T(d)以及M(d)都为数据大小d的线性函数，故对实验结果有以下预测：方法1的时间与空间开销将与数据大小呈线性关系，方法2和方法3的时间与空间开销为常量，方法3相较于方法2开销多了50%。通过表3的实验环境进行实验，3种方法的运行时间开销和存储开销分别如图7和图8所示，基本与上述预测结果一致。

图  7  运行时间开销

Fig.  7  Runtime cost

下载: 全尺寸图片

图  8  空间开销

Fig.  8  Memory cost

下载: 全尺寸图片

这个实验结果是基于双方的数据通信，但在过程协同中，普遍有多个数据接收方。假设有n个数据接收方，方法2需要操作2n次数据(保存数据n次，获取数据n次)，方法3需要操作1+2n次数据(保存数据1次，请求数据n次，响应数据n次)。如图9所示，本文方法开销相较于方法2增加的比例随接收方个数增加而降低，即成反比例关系。

图  9  本文方法在时间、空间开销相较于方法2增加的比例

Fig.  9  Proportion of time and space cost increase in this method compared to method 2

下载: 全尺寸图片

本文方法在时间与空间二者的开销方面相比于方法2开销的增加比例在3个数据接收方时约为16.7%，在4个接收方时约为12.5%。在真实协同场景中，本文方法的时间开销通常会比方法2更小，这是因为方法2随着接收方个数的增加需要多次使用BPMS进行互操作行为，而这会增加更多的时间开销。因此，使用本文方法进行数据通信时的开销是可以接受的，本文方法具有可行性。

4.   结束语

本文旨在为基于区块链的业务过程协同提供一个可信的数据通信方法。为实现该目标，本文提出了面向业务过程协同的隐私数据通信方法，该方法拓展了Wf-XML2.0协议进行数据通信，基于IPFS和非对称加密技术，将数据通信的过程设计成保存数据、请求数据和响应数据3个步骤，并为每个步骤设计相应的算法，从而使本文方法能够保障数据隐私。最后本文还对提出的数据通信方法进行验证：首先通过Dolev-Yao攻击者模型得出攻击者无法获取到业务数据的结论，从而验证安全性；其次通过过程协同实际案例分析得出本文方法相较于其他方法更加具有合理性；最后通过实验得出本文方法的运行时间开销和空间开销在可以接受的范围，从而验证方法可行性。

未来，希望基于区块链的业务过程协同框架能够应用于更加广泛的场景，但通常情况下，随着成员节点的增加区块链的性能会有所降低。因此，后续将考虑改进区块链共识机制来提高区块链性能，为基于区块链的业务过程协同带来效率上的提升。