俞東進(jìn)，韋懿杰，孫笑笑，倪可，沈滬軍

（杭州電子科技大學(xué)計(jì)算機(jī)學(xué)院，浙江 杭州 310018）

1 引言

傳統(tǒng)的業(yè)務(wù)過(guò)程管理技術(shù)為企業(yè)提供了設(shè)計(jì)、記錄和執(zhí)行其業(yè)務(wù)過(guò)程的功能。然而，隨著業(yè)務(wù)變得越來(lái)越復(fù)雜，許多過(guò)程不再局限于單個(gè)組織。這種跨組織業(yè)務(wù)過(guò)程的出現(xiàn)給傳統(tǒng)的業(yè)務(wù)過(guò)程管理技術(shù)帶來(lái)了許多挑戰(zhàn)，其中最突出的是如何選擇負(fù)責(zé)過(guò)程管理的中央控制者，即業(yè)務(wù)過(guò)程由誰(shuí)來(lái)進(jìn)行主導(dǎo)。由于中央控制者利用自身權(quán)限謀取私利的現(xiàn)象難以避免，傳統(tǒng)分布式跨組織業(yè)務(wù)過(guò)程系統(tǒng)只有在組織之間相互信任或者求助于第三方權(quán)威機(jī)構(gòu)的情況下才能夠保證組織間交互消息的可靠性。最新的研究已經(jīng)意識(shí)到了這一問(wèn)題并且建議使用區(qū)塊鏈技術(shù)來(lái)解決上述信任缺失問(wèn)題[1]。

目前已經(jīng)有許多研究者在基于區(qū)塊鏈的業(yè)務(wù)過(guò)程管理領(lǐng)域提出了相關(guān)的研究方法與實(shí)現(xiàn)原型，這些工作的重點(diǎn)在于過(guò)程模型的執(zhí)行控制[2-6]。但是，它們一般都是通過(guò)將過(guò)程模型硬編碼為區(qū)塊鏈智能合約來(lái)支持過(guò)程實(shí)例的鏈上執(zhí)行，而無(wú)法適應(yīng)業(yè)務(wù)過(guò)程隨時(shí)發(fā)生變化的實(shí)際需求[7]，由此造成了過(guò)程實(shí)例化成本過(guò)高、版本迭代困難等問(wèn)題。

針對(duì)上述問(wèn)題，本文提出了一種編排圖驅(qū)動(dòng)的區(qū)塊鏈業(yè)務(wù)過(guò)程管理框架，并給出了相關(guān)的以太坊智能合約的原型實(shí)現(xiàn)，最后使用助聽(tīng)器行業(yè)的一個(gè)真實(shí)案例來(lái)評(píng)估本文框架的有效性。

與現(xiàn)有方法相比，本文具有以下創(chuàng)新之處。

1) 設(shè)計(jì)了包括業(yè)務(wù)過(guò)程編排元模型、模型部件版本和實(shí)例執(zhí)行狀態(tài)的通用智能合約。與該領(lǐng)域其他方法生成適應(yīng)于特定業(yè)務(wù)過(guò)程的智能合約不同，本文框架采用通用智能合約設(shè)計(jì)，將編排圖中包含的模型部件部署到智能合約的編排元模型內(nèi)，同時(shí)在創(chuàng)建過(guò)程實(shí)例時(shí)采用集成多過(guò)程實(shí)例和延遲元素實(shí)例化時(shí)機(jī)的方法，大幅降低創(chuàng)建過(guò)程實(shí)例成本開(kāi)銷。

2) 提供了一種基于投票機(jī)制和復(fù)用模型數(shù)據(jù)的版本控制方法，以實(shí)現(xiàn)基于區(qū)塊鏈的業(yè)務(wù)過(guò)程模型版本管理。該方法通過(guò)引入投票機(jī)制提高了版本控制的去中心化程度。

2 預(yù)備知識(shí)

2.1 業(yè)務(wù)過(guò)程建模標(biāo)注與編排圖

業(yè)務(wù)過(guò)程建模標(biāo)注（BPMN，business process modeling notation）是目前得到廣泛認(rèn)同和使用的建模語(yǔ)言[8]。BPMN 中包含編制圖、協(xié)作圖和編排圖，其中，協(xié)作圖和編排圖都可被用于描述跨組織業(yè)務(wù)過(guò)程的執(zhí)行過(guò)程。然而，協(xié)作圖沒(méi)有以簡(jiǎn)潔的方式描述編排過(guò)程；編排圖從組織間內(nèi)部編排細(xì)節(jié)中抽象而出，在一個(gè)以交互為中心的級(jí)別上描述業(yè)務(wù)過(guò)程，能夠在不暴露參與者內(nèi)部行為的基礎(chǔ)上描述參與者之間的交互邏輯。這些特性適用于基于區(qū)塊鏈的跨組織業(yè)務(wù)過(guò)程建模。

圖1 描述了編排圖常用的建模元素，包括開(kāi)始事件、結(jié)束事件、排他網(wǎng)關(guān)、并行網(wǎng)關(guān)、事件網(wǎng)關(guān)、編排任務(wù)和序列流。其中，開(kāi)始事件和結(jié)束事件分別表示編排的開(kāi)始和結(jié)束。各類網(wǎng)關(guān)用于控制編排中序列流的走向，其中排他網(wǎng)關(guān)和并行網(wǎng)關(guān)又可各自分為分離網(wǎng)關(guān)和合并網(wǎng)關(guān)。編排任務(wù)用于描述2 個(gè)參與者之間的消息交互，在圖1 中表示為3 個(gè)區(qū)域，中間為任務(wù)名稱，其余2 個(gè)為任務(wù)參與者。編排任務(wù)可以根據(jù)攜帶的消息數(shù)量分為單向任務(wù)和雙向任務(wù)。最后，序列流用于連接編排元素，控制業(yè)務(wù)過(guò)程的執(zhí)行。

圖1 編排圖常用的建模元素

2.2 區(qū)塊鏈和智能合約

區(qū)塊鏈最初源自比特幣的底層技術(shù)，隨后被用于支持不受信任的用戶之間的價(jià)值傳輸。以太坊是第一個(gè)以智能合約為基礎(chǔ)的可編程非許可鏈開(kāi)源平臺(tái)項(xiàng)目，支持使用區(qū)塊鏈網(wǎng)絡(luò)構(gòu)建分布式應(yīng)用[9]。智能合約的想法最早由Szabo[10]提出，其被定義為一套數(shù)字形式的承諾，并由合約參與方遵守執(zhí)行，但最初由于其環(huán)境和應(yīng)用場(chǎng)景的缺失并未得到廣泛關(guān)注。在區(qū)塊鏈技術(shù)出現(xiàn)后，智能合約概念再次被提出。文獻(xiàn)[11]指出，智能合約由于其去中心化、確定性、可觀察等特點(diǎn)在金融交易、供應(yīng)鏈等方面有著廣闊的應(yīng)用前景。以太坊通過(guò)圖靈完備腳本語(yǔ)言Solidity 實(shí)現(xiàn)復(fù)雜的程序邏輯，即智能合約。用戶能夠根據(jù)個(gè)人需求自定義智能合約邏輯，并且將智能合約部署到以太坊區(qū)塊鏈上。

3 相關(guān)工作

近年來(lái)，區(qū)塊鏈由于其去中心化、不可篡改和可追溯等特性得到廣泛應(yīng)用。這些特性尤其適用于跨組織業(yè)務(wù)過(guò)程消息交互場(chǎng)景，從而解決組織間的信任缺失問(wèn)題。目前，許多研究者已經(jīng)將區(qū)塊鏈技術(shù)應(yīng)用到了業(yè)務(wù)過(guò)程領(lǐng)域，并取得了不少成果，相關(guān)工作主要圍繞應(yīng)用理論、BPMN 編排圖、BPMN 過(guò)程圖、BPMN協(xié)作圖和場(chǎng)景應(yīng)用等展開(kāi)。

Mendling 等[1]提出在傳統(tǒng)的業(yè)務(wù)過(guò)程背景下利用區(qū)塊鏈技術(shù)的挑戰(zhàn)和機(jī)遇，指出新興區(qū)塊鏈技術(shù)有可能徹底改變現(xiàn)有的組織間業(yè)務(wù)過(guò)程執(zhí)行方式。Viriyasitavat 等[12]提出了一個(gè)基于區(qū)塊鏈的業(yè)務(wù)流程架構(gòu)，以克服傳統(tǒng)業(yè)務(wù)流程執(zhí)行過(guò)程中的時(shí)間不一致和共識(shí)偏差問(wèn)題。Ladleif 等[13]分析了業(yè)務(wù)過(guò)程中外部數(shù)據(jù)交互模式在區(qū)塊鏈上的語(yǔ)義支持，擴(kuò)展了區(qū)塊鏈Oracle 的實(shí)現(xiàn)策略。K?pke 等[14]分析了智能合約在業(yè)務(wù)過(guò)程管理中體現(xiàn)的可觀察性、可執(zhí)行性和隱私性，并介紹了區(qū)塊鏈上執(zhí)行業(yè)務(wù)過(guò)程涉及的密鑰交換模式。盡管這些工作為后續(xù)研究指明了方向，但這些工作只停留在概念層面，缺乏相應(yīng)的案例和原型來(lái)支持其理論。

Weber 等[2]提出了將區(qū)塊鏈技術(shù)集成到過(guò)程編排中的方法，并為其實(shí)現(xiàn)了相關(guān)功能組件。該方法能夠有效支持編排過(guò)程的鏈上執(zhí)行，但其智能合約一旦部署就無(wú)法修改，使用工廠合約來(lái)創(chuàng)建過(guò)程實(shí)例智能合約的方式也額外增加了以太坊的成本開(kāi)銷。García-Ba?uelos 等[3]針對(duì)該問(wèn)題通過(guò)簡(jiǎn)化過(guò)程模型為Petri 網(wǎng)以及在智能合約中合理利用位向量來(lái)優(yōu)化合約部署和執(zhí)行成本開(kāi)銷，最后降低了以太坊智能合約部署和過(guò)程實(shí)例執(zhí)行的gas 消耗，但該方法難以支持業(yè)務(wù)過(guò)程模型的版本迭代。Ladleif 等[4]根據(jù)區(qū)塊鏈特性提出了區(qū)塊鏈編排圖的操作語(yǔ)義，通過(guò)智能合約全局變量來(lái)支持鏈上編排業(yè)務(wù)過(guò)程的執(zhí)行，并且使用3 個(gè)案例原型對(duì)其工作進(jìn)行評(píng)估。Corradini 等[5]提出了一種基于區(qū)塊鏈技術(shù)和編排圖模型驅(qū)動(dòng)的業(yè)務(wù)流程管理框架。該框架將輸入的BPMN 編排圖模型轉(zhuǎn)化為特定的智能合約，并且為編排的整個(gè)生命周期提供支持，但存在智能合約缺少靈活性的問(wèn)題。同時(shí)，該框架還存在為每個(gè)實(shí)例生成的智能合約中有大量冗余函數(shù)代碼、對(duì)于消息的支持停留在全局變量之上、缺乏消息的隱私控制機(jī)制等缺點(diǎn)。Lichtenstein 等[6]針對(duì)區(qū)塊鏈數(shù)據(jù)存儲(chǔ)的開(kāi)銷問(wèn)題，通過(guò)不同的編排過(guò)程復(fù)用相同的編排消息數(shù)據(jù)，在不改變數(shù)據(jù)完整性的情況下降低區(qū)塊鏈數(shù)據(jù)存儲(chǔ)成本。

López-Pintado 等[15]提出了Caterpillar，這是全球第一個(gè)開(kāi)源區(qū)塊鏈業(yè)務(wù)過(guò)程執(zhí)行引擎。該引擎基于BPMN 過(guò)程圖開(kāi)發(fā)。與其他實(shí)現(xiàn)原型相比，Caterpillar 支持更多類型的BPMN 元素，允許通過(guò)工廠合約創(chuàng)建過(guò)程實(shí)例智能合約并且支持跟蹤過(guò)程實(shí)例的執(zhí)行狀態(tài)，但在執(zhí)行過(guò)程中忽略了組織間的消息交互內(nèi)容，將跨組織協(xié)作業(yè)務(wù)過(guò)程視為組織內(nèi)部業(yè)務(wù)過(guò)程。此外，López-Pintado 等[16]還提出了一種用于協(xié)作業(yè)務(wù)過(guò)程執(zhí)行的動(dòng)態(tài)綁定模型和相應(yīng)的綁定策略規(guī)范語(yǔ)言，同時(shí)將該規(guī)范語(yǔ)言賦予Petri 網(wǎng)語(yǔ)義來(lái)檢測(cè)綁定策略是否會(huì)發(fā)生死鎖，最后將相關(guān)工作內(nèi)容集成到Caterpillar 框架中，但動(dòng)態(tài)綁定模型的引入增加了角色授權(quán)的復(fù)雜性，增大了在智能合約中進(jìn)行訪問(wèn)控制的成本開(kāi)銷。為了解決智能合約缺乏靈活性問(wèn)題，López-Pintado 等[7]還在Caterpillar 框架中加入基于動(dòng)態(tài)數(shù)據(jù)結(jié)構(gòu)的BPMN過(guò)程模型解釋器。該工作與本文類似，但沒(méi)有考慮模型改動(dòng)后導(dǎo)致的版本變動(dòng)問(wèn)題，即缺乏版本控制與修改控制機(jī)制。

Sturm 等[17]基于BPMN 協(xié)作圖提供了一個(gè)包含通用數(shù)據(jù)結(jié)構(gòu)的智能合約，該合約支持存儲(chǔ)過(guò)程模型和控制過(guò)程實(shí)例正確執(zhí)行，但該文只關(guān)注業(yè)務(wù)過(guò)程的控制流邏輯，不支持創(chuàng)建多個(gè)過(guò)程實(shí)例。此外，Sturm 等[18]在其提出的智能合約中引入全局?jǐn)?shù)據(jù)變量來(lái)支持基于數(shù)據(jù)的決策。Klinger 等[19]同樣基于協(xié)作圖提出了區(qū)塊鏈業(yè)務(wù)過(guò)程執(zhí)行框架，但其工作重點(diǎn)放在過(guò)程模型部署和部署成本的平均分配上。

還有一些研究者針對(duì)不同場(chǎng)景下的區(qū)塊鏈業(yè)務(wù)流程管理提出相應(yīng)的方法。Madsen 等[20]提出了一種在對(duì)抗環(huán)境下執(zhí)行分布式聲明性工作過(guò)程的方法，該方法基于動(dòng)態(tài)條件響應(yīng)（DCR,dynamic condition response）圖解決對(duì)抗環(huán)境下組織間缺乏受信任第三方的問(wèn)題。其中，DCR 圖是一種基于事件的聲明性過(guò)程模型描述，用于指定一個(gè)預(yù)先約定的工作流。Haarmann 等[21]等以決策模型和符號(hào)為基礎(chǔ)，提出了一種在區(qū)塊鏈上存儲(chǔ)過(guò)程決策信息的方法，并使用概念驗(yàn)證原型對(duì)該方法進(jìn)行了評(píng)估。為了適應(yīng)決策信息包含敏感數(shù)據(jù)的實(shí)際場(chǎng)景，Haarmann 等[22]提出了一種不需要揭示敏感數(shù)據(jù)來(lái)支持決策的方法，允許參與者對(duì)決策結(jié)果提出質(zhì)疑，通過(guò)揭示決策結(jié)果來(lái)解決相應(yīng)的沖突并對(duì)惡意質(zhì)疑者進(jìn)行懲罰。Ladleif 等[23]提出了一種多鏈業(yè)務(wù)過(guò)程管理架構(gòu)，針對(duì)不同級(jí)別的風(fēng)險(xiǎn)容忍度和保密性的實(shí)踐需求可支持多鏈環(huán)境下的業(yè)務(wù)過(guò)程編排。

上述工作的重點(diǎn)在于過(guò)程模型中序列流的執(zhí)行控制，相關(guān)的大多數(shù)實(shí)現(xiàn)框架和原型將業(yè)務(wù)過(guò)程模型硬編碼為特定的以太坊智能合約來(lái)實(shí)現(xiàn)，這種方式忽略了以太坊智能合約一旦部署就無(wú)法進(jìn)行修改的特性。在業(yè)務(wù)過(guò)程需要進(jìn)行修改或者智能合約出現(xiàn)錯(cuò)誤時(shí)會(huì)造成大量的以太坊gas 資源浪費(fèi)。少數(shù)原型考慮了這一問(wèn)題并且采用通用智能合約和通用數(shù)據(jù)結(jié)構(gòu)的設(shè)計(jì)方式來(lái)解決靈活性低下問(wèn)題，但對(duì)于模型實(shí)例如何集成以及模型修改如何控制還缺乏完整的設(shè)計(jì)方案。與現(xiàn)有方法不同，本文使用通用智能合約來(lái)控制跨組織業(yè)務(wù)過(guò)程的執(zhí)行過(guò)程，在保持靈活性的基礎(chǔ)上使用引入投票機(jī)制的版本控制方法，即利用群體智慧管理業(yè)務(wù)過(guò)程模型的修改和更新。

4 區(qū)塊鏈業(yè)務(wù)過(guò)程管理框架

4.1 框架設(shè)計(jì)與概念定義

本節(jié)從模型過(guò)程控制、訪問(wèn)控制策略、模型版本控制和隱私控制策略4 個(gè)角度分析區(qū)塊鏈業(yè)務(wù)過(guò)程管理框架設(shè)計(jì)方案，并給出框架內(nèi)部相關(guān)概念的定義說(shuō)明。鏈上智能合約結(jié)構(gòu)如圖2 所示。

圖2 鏈上智能合約結(jié)構(gòu)

1) 模型過(guò)程控制

本文所提框架將編排圖模型中相應(yīng)的模型數(shù)據(jù)存儲(chǔ)于以太坊智能合約中，以控制區(qū)塊鏈上過(guò)程實(shí)例的正確執(zhí)行。

定義1業(yè)務(wù)過(guò)程編排元模型。業(yè)務(wù)過(guò)程編排元模型M包含所有編排模型中可能存在的元素、消息、決策三類模型部件及其版本號(hào)，即M={＜ME|MM|MD,VID ＞}，其中，ME 表示編排模型中的元素，包含開(kāi)始事件、結(jié)束事件、網(wǎng)關(guān)和編排任務(wù)等模型元素；MM 表示編排模型中包含的交互消息；MD 表示編排模型中包含的決策條件；VID 表示相應(yīng)模型部件對(duì)應(yīng)的版本號(hào)。

定義2編排合約。編排合約CC 是一個(gè)存儲(chǔ)M、V和I的智能合約，即CC={M,V,I}，其中，模型部件版本V={＜MEi,VIDi＞}∪{＜MMj,VIDj＞}∪{＜MDk,VIDk＞} 表示任取相關(guān)模型部件的某一版本所組成的模型部件集合；實(shí)例執(zhí)行狀態(tài)I=＜IE,IM,IG＞由實(shí)例元素IE、實(shí)例執(zhí)行消息內(nèi)容IM、實(shí)例全局?jǐn)?shù)據(jù)存儲(chǔ)IG 組成。

本文提出的編排合約CC 內(nèi)含有表示業(yè)務(wù)過(guò)程編排元模型M的數(shù)據(jù)結(jié)構(gòu)體。過(guò)程實(shí)例的執(zhí)行受對(duì)應(yīng)的模型部件控制，具體解析和執(zhí)行過(guò)程將在執(zhí)行步驟中詳細(xì)說(shuō)明。

2) 訪問(wèn)控制策略

當(dāng)使用以太坊區(qū)塊鏈來(lái)協(xié)作跨越組織業(yè)務(wù)過(guò)程的執(zhí)行時(shí)，需要有授權(quán)機(jī)制來(lái)限制對(duì)于智能合約的訪問(wèn)。為此本文在合約框架中引入了基于角色訪問(wèn)控制方法的訪問(wèn)控制智能合約。

定義3編排過(guò)程組織。編排過(guò)程組織CO 表示包含所有業(yè)務(wù)過(guò)程參與者的組織結(jié)構(gòu)，即CO={U,R,UR}，其中，U表示編排過(guò)程組織的參與者，R表示編排過(guò)程組織中包含的角色，UR 表示該編排過(guò)程組織中參與者與角色的映射關(guān)系。

定義4訪問(wèn)控制合約。訪問(wèn)控制合約ACC 是一個(gè)用于提供授權(quán)機(jī)制與訪問(wèn)控制機(jī)制的智能合約，ACC 中存儲(chǔ)了編排合約與編排過(guò)程組織的映射關(guān)系CCmap，它將編排合約地址 CCaddr映射到CO 來(lái)唯一確定編排合約對(duì)應(yīng)的編排過(guò)程組織。

過(guò)程管理者在完成編排合約CC 的部署后，使用CCaddr在ACC 中創(chuàng)建CO，在CO 中導(dǎo)入相關(guān)的U和R，并通過(guò)UR 給參與者分配角色。相關(guān)操作都以區(qū)塊鏈交易的形式存儲(chǔ)于以太坊區(qū)塊中，任何參與者都能夠?qū)^(guò)程管理者的所有操作進(jìn)行追溯。

3) 模型版本控制

業(yè)務(wù)過(guò)程模型往往會(huì)隨著時(shí)間發(fā)生變化，而現(xiàn)有的實(shí)現(xiàn)原型中沒(méi)有為基于區(qū)塊鏈的業(yè)務(wù)過(guò)程模型版本控制提供支持。本文所提出的區(qū)塊鏈業(yè)務(wù)過(guò)程管理框架通過(guò)復(fù)用模型部件版本V提供版本控制功能。同時(shí)，為了增強(qiáng)框架的去中心化程度，本文在模型部件版本V的發(fā)布過(guò)程中引入投票機(jī)制來(lái)限制過(guò)程管理者的權(quán)力。為了實(shí)現(xiàn)所述功能，本文在框架內(nèi)增加了投票合約。

定義5投票合約。投票合約VC 是一個(gè)用于生成版本發(fā)布提案VP 和提供投票決策功能的智能合約。其中，VP={CCaddr,Vid}，表示通過(guò)CCaddr和模型部件版本標(biāo)識(shí)Vid能夠唯一確定一個(gè)編排模型。

CC 的模型部件版本V創(chuàng)建后，會(huì)自動(dòng)使用CCaddr和Vid在投票合約VC 中發(fā)布一個(gè)版本發(fā)布提案VP，只有當(dāng)對(duì)應(yīng)的CO 中所有的參與者U都投票贊成該版本發(fā)布VP 后，該提案中指向的V才能投入使用。

4) 隱私控制策略

區(qū)塊鏈上存儲(chǔ)的數(shù)據(jù)能夠被公共網(wǎng)絡(luò)的任意節(jié)點(diǎn)訪問(wèn)，這不利于組織間的隱私數(shù)據(jù)的交互，為此本文引入非對(duì)稱加密算法用于加密實(shí)例執(zhí)行過(guò)程中的消息交互內(nèi)容。

定義6實(shí)例執(zhí)行消息內(nèi)容。實(shí)例執(zhí)行消息內(nèi)容IM 是存儲(chǔ)于編排合約CC 的過(guò)程實(shí)例所包含的消息交互數(shù)據(jù)，由公共數(shù)據(jù)IMP 和隱私數(shù)據(jù)IMS組成，即IM={IMP,IMS}。

實(shí)例執(zhí)行消息內(nèi)容中的IMP 存儲(chǔ)于實(shí)例全局?jǐn)?shù)據(jù)IG 中，包括能夠向所有參與者公開(kāi)的消息內(nèi)容和參與決策網(wǎng)關(guān)決策條件的數(shù)據(jù)內(nèi)容；而IMS是指包含敏感數(shù)據(jù)的消息內(nèi)容，只能被消息的發(fā)送者和接收者獲取。本文框架采用非對(duì)稱加密算法，其中每個(gè)參與者都在CO 中存有各自的公鑰，當(dāng)消息發(fā)送者向消息接收者發(fā)送消息時(shí)，能夠在CO 獲取消息接收者的公鑰，并且使用公鑰加密消息數(shù)據(jù)并將消息發(fā)布到IM 中，消息接收者讀取相應(yīng)消息并使用私鑰對(duì)加密消息數(shù)據(jù)解密，根據(jù)解密后消息內(nèi)容選擇接收或者拒絕該消息，被拒絕的消息能夠由發(fā)送者重新發(fā)送。

4.2 框架架構(gòu)

本文提出框架的架構(gòu)如圖3 所示，主要分為鏈下組件和鏈上智能合約兩部分，其中鏈下組件由建模器、翻譯器、部署器和事件監(jiān)聽(tīng)器等提供功能支持。

圖3 編排圖驅(qū)動(dòng)的區(qū)塊鏈業(yè)務(wù)過(guò)程管理框架架構(gòu)

建模器。本文使用的建模器[24]基于BPMN-JS開(kāi)發(fā)，能夠涵蓋本文支持的所有編排圖元素，并且具有可擴(kuò)展、直觀性較強(qiáng)和易于集成等優(yōu)點(diǎn)，使用該建模器能夠生成xml 格式的編排圖文件F。

翻譯器。翻譯器是用于解析建模器輸出的編排圖文件F的鏈下組件，使用該組件能夠從F中解析出元素ME、消息MM 和決策M(jìn)D 等模型部件，并且以JS 對(duì)象簡(jiǎn)譜（JSON,JavaScript object notation）文件格式輸出。

部署器。部署器用于部署編排合約CC、投票合約VC、訪問(wèn)控制合約ACC、公共函數(shù)庫(kù)C以及業(yè)務(wù)過(guò)程編排元模型M中包含的元素ME、消息MM 和決策M(jìn)D 等模型部件。以太坊智能合約可直接部署；業(yè)務(wù)過(guò)程編排元模型M中包含的模型部件則由部署器通過(guò)獲取翻譯器輸出的JSON 文件內(nèi)容，同時(shí)對(duì)比編排合約CC 內(nèi)已存在的模型部件，進(jìn)行選擇性部署。

事件監(jiān)聽(tīng)器。事件監(jiān)聽(tīng)器用于監(jiān)聽(tīng)編排合約CC 內(nèi)實(shí)例執(zhí)行狀態(tài)I的狀態(tài)變化事件以及投票合約VC 中版本發(fā)布提案VP 的生成事件，并以此跟蹤過(guò)程實(shí)例的執(zhí)行，將相關(guān)信息通知過(guò)程參與者。

鏈上智能合約包括公共函數(shù)庫(kù)C、訪問(wèn)控制合約ACC、投票合約VC 和編排合約CC。其中ACC、VC 和C只需部署一次，訪問(wèn)控制合約ACC 與投票合約VC 用于控制不同編排合約CC 中的訪問(wèn)控制權(quán)限和模型版本迭代，公共函數(shù)庫(kù)C為其余合約提供了公共計(jì)算函數(shù)。

4.3 執(zhí)行步驟

本文提供的框架執(zhí)行過(guò)程主要包括3 個(gè)階段，具體步驟如圖4 所示。

圖4 框架執(zhí)行過(guò)程

階段1 為智能合約部署與數(shù)據(jù)上傳階段，主要包含以太坊智能合約部署、編排圖文件解析以及模型部件部署3 個(gè)步驟。

步驟1過(guò)程管理者部署訪問(wèn)控制合約ACC、投票合約VC、編排合約CC 與公共函數(shù)庫(kù)C。在部署投票合約時(shí)需要傳入訪問(wèn)控制合約地址ACCaddr；在部署編排合約時(shí)需要傳入訪問(wèn)控制合約地址ACCaddr以及投票合約地址VCaddr，以便在后續(xù)的合約訪問(wèn)控制和投票決策過(guò)程中進(jìn)行合約調(diào)用，相關(guān)智能合約的部署成本由過(guò)程管理者負(fù)擔(dān)或者由過(guò)程參與者進(jìn)行協(xié)商負(fù)擔(dān)。完成ACC 和CC 部署后，過(guò)程管理者導(dǎo)入對(duì)應(yīng)業(yè)務(wù)過(guò)程組織CO 中包含的U和R，并通過(guò)UR 來(lái)完成參與者角色的靜態(tài)分配。

步驟2鏈下翻譯器輸入一個(gè)描述跨組織業(yè)務(wù)過(guò)程的信息交互和過(guò)程執(zhí)行過(guò)程的BPMN 文件（該文件由過(guò)程管理者通過(guò)建模器建模獲得），解析該文件中包含的元素、消息和決策等模型部件并以JSON 格式輸出。該步驟涉及的解析過(guò)程如算法1所示。

算法1parsingChor (BPMN-FileF)

輸入建模器建模輸出的BPMN 編排圖文件F

輸出編排圖文件F中所包含的元素ME、消息MM 和決策M(jìn)D 等模型部件

在算法1 中，第3)行將BPMN 文件F解析為包含模型部件ME、MM 和MD 的編排圖模型Model。第4)～19)行遍歷編排圖模型中的每一個(gè)序列流，其中第5)～8)行解析包含決策條件的序列流，獲得決策模型部件MD；第9)～16)行解析該序列流的前驅(qū)元素為元素模型部件ME，并將其內(nèi)部包含的消息解析為消息模型部件MM；第17)～18)行以相同方式解析序列流目標(biāo)元素。第20)行返回該編排圖文件中包含的模型部件(ME,MM,MD)。

步驟3部署器將算法1 解析所得的鏈下業(yè)務(wù)過(guò)程模型中模型部件(ME,MM,MD)與從編排合約CC 的業(yè)務(wù)過(guò)程編排元模型M中讀取的鏈上模型部件(MEonline,MMonline,MDonline)進(jìn)行對(duì)比，并將其導(dǎo)入編排合約CC 的業(yè)務(wù)過(guò)程編排元模型M中，如算法2 所示。

算法2deployM(ME,MM,MD)

輸入算法1 解析模型所得元素ME、消息MM、決策M(jìn)D 等模型部件

輸出導(dǎo)入編排元模型M后的編排合約CC

在算法2 中，第2)～第4)行表示從當(dāng)前CC 中讀取鏈上已存在的元素、消息和決策等模型部件。第6)行比較鏈下元素模型部件是否已經(jīng)存在于鏈上。如不存在，則創(chuàng)建版本號(hào)為1 的元素模型部件并將其部署于CC 的M中。第9)行比較當(dāng)前鏈下元素模型部件內(nèi)容是否與鏈上元素模型部件相同，如果相同，則跳過(guò)當(dāng)前元素，否則更新該元素模型部件的版本號(hào)為最新的版本號(hào)（鏈上對(duì)應(yīng)最大版本號(hào)加1)，然后同樣部署于CC 的M中。消息和決策模型部件的部署方式與元素模型部件相同。

階段2 為模型的版本控制階段，主要包含在CC中創(chuàng)建V、在VC 中創(chuàng)建VP 以及由過(guò)程參與者U對(duì)VP 進(jìn)行投票表決的過(guò)程，具體步驟如下。

步驟4在完成步驟3 之后，CC 已存儲(chǔ)M，此時(shí)需要對(duì)比鏈下模型部件和鏈上模型部件并得到V，對(duì)比方式與算法2 相似。過(guò)程管理者調(diào)用編排合約的發(fā)布版本函數(shù)addVersion，將V發(fā)布到CC中，隨后在該函數(shù)內(nèi)部發(fā)起對(duì)VC 的合約函數(shù)調(diào)用，在投票合約中新增VP。然后，鏈下事件監(jiān)聽(tīng)器組件監(jiān)聽(tīng)投票合約內(nèi)部事件，并通過(guò)VP 內(nèi)CCaddr和Vid檢索到V，讀取V中引用對(duì)應(yīng)版本號(hào)的模型部件，并通知相應(yīng)CO 的U。

步驟5過(guò)程參與者U收到步驟4 中的通知后查看V中引用的模型部件，通過(guò)對(duì)比鏈下過(guò)程模型與鏈上模型部件版本來(lái)核查過(guò)程管理者發(fā)布模型版本的正確性，此處也可使用現(xiàn)有的模型校驗(yàn)工具[25-26]校驗(yàn)鏈上模型部件版本的可執(zhí)行性。參與者在確認(rèn)V的正確性后，在VC 中對(duì)該VP 進(jìn)行表決。只有當(dāng)所有的過(guò)程參與者都支持VP 時(shí)，對(duì)應(yīng)的V才能投入使用。同時(shí)，編排合約中現(xiàn)有過(guò)程實(shí)例遵循原有模型部件版本繼續(xù)執(zhí)行。

階段3 為模型的實(shí)例化以及鏈上的實(shí)例執(zhí)行控制階段，主要包括版本模型實(shí)例化、過(guò)程參與者間消息交互以及過(guò)程實(shí)例執(zhí)行，具體步驟如下。

步驟6當(dāng)模型部件版本V得到所有過(guò)程參與者U的認(rèn)可后，過(guò)程管理者就能夠使用該模型部件版本V創(chuàng)建過(guò)程實(shí)例。對(duì)應(yīng)過(guò)程實(shí)例存儲(chǔ)在實(shí)例執(zhí)行狀態(tài)中，每一個(gè)過(guò)程實(shí)例包含實(shí)例所屬版本、實(shí)例狀態(tài)、實(shí)例元素?cái)?shù)據(jù)信息、實(shí)例消息數(shù)據(jù)信息以及實(shí)例全局?jǐn)?shù)據(jù)變量等相關(guān)數(shù)據(jù)。其中，實(shí)例元素存在等待、可執(zhí)行和已完成3 種狀態(tài)，實(shí)例消息存在發(fā)送、接收和拒絕3 種狀態(tài)。當(dāng)實(shí)例元素處于可執(zhí)行狀態(tài)時(shí)，流程參與者即可發(fā)送該實(shí)例元素包含的消息，此時(shí)對(duì)應(yīng)消息被創(chuàng)建并被置為發(fā)送狀態(tài)，消息中用于決策網(wǎng)關(guān)路由的變量被存儲(chǔ)到實(shí)例全局?jǐn)?shù)據(jù)中，消息中包含的隱私數(shù)據(jù)能夠使用消息接收者的以太坊公鑰進(jìn)行加密。隨后，消息接收者選擇接收或者拒絕該消息，并觸發(fā)對(duì)應(yīng)的消息狀態(tài)轉(zhuǎn)換函數(shù)。當(dāng)該實(shí)例元素中所有消息都處于已接收狀態(tài)時(shí)將會(huì)觸發(fā)實(shí)例元素的狀態(tài)轉(zhuǎn)換函數(shù)，其將該實(shí)例元素轉(zhuǎn)換為已完成狀態(tài)，并根據(jù)該過(guò)程實(shí)例綁定的模型部件版本和實(shí)例全局?jǐn)?shù)據(jù)啟用后繼元素，將相應(yīng)元素轉(zhuǎn)換為可執(zhí)行狀態(tài)。此外，本文框架采用延遲元素實(shí)例化時(shí)機(jī)的設(shè)計(jì)方法，過(guò)程實(shí)例包含的元素不會(huì)在創(chuàng)建實(shí)例時(shí)生成，而是根據(jù)過(guò)程實(shí)例的執(zhí)行路由動(dòng)態(tài)實(shí)例化對(duì)應(yīng)的實(shí)例元素。值得注意的是，上述操作都會(huì)在ACC 中進(jìn)行權(quán)限驗(yàn)證，沒(méi)有對(duì)應(yīng)角色的參與者相關(guān)操作會(huì)被CC 拒絕。

5 實(shí)驗(yàn)評(píng)估

5.1 案例與實(shí)驗(yàn)環(huán)境說(shuō)明

本文建模、執(zhí)行和分析了以HE 助聽(tīng)器公司為主導(dǎo)的一個(gè)真實(shí)商品訂購(gòu)業(yè)務(wù)過(guò)程，如圖 5所示。

圖5 所示場(chǎng)景涉及了4 個(gè)參與者（加盟門店、生產(chǎn)商、物流商、發(fā)貨承運(yùn)商）、14 個(gè)編排圖元素、11 條消息。如果在消息交互過(guò)程出現(xiàn)延誤或差錯(cuò)，參與者之間可能會(huì)相互指責(zé)，而且加盟門店沒(méi)有自己的數(shù)據(jù)存儲(chǔ)，當(dāng)其與生產(chǎn)商產(chǎn)生沖突時(shí)，生產(chǎn)商能夠通過(guò)篡改數(shù)據(jù)來(lái)使自己獲利。引入?yún)^(qū)塊鏈業(yè)務(wù)過(guò)程管理系統(tǒng)后可解決上述問(wèn)題。例如，當(dāng)門店與生產(chǎn)商產(chǎn)生沖突時(shí)，門店只需要追溯過(guò)程實(shí)例的消息內(nèi)容與對(duì)應(yīng)以太坊交易的時(shí)間戳即可維護(hù)利益，不再需要受信任第三方。此外，本文框架還支持商品訂購(gòu)編排過(guò)程的實(shí)時(shí)更新，對(duì)于模型的更新需要得到所有參與者認(rèn)可后才會(huì)生效。

圖5 商品訂購(gòu)編排圖

本文基于所提區(qū)塊鏈業(yè)務(wù)過(guò)程管理系統(tǒng)框架重現(xiàn)了10 個(gè)該案例的過(guò)程實(shí)例執(zhí)行過(guò)程，相關(guān)過(guò)程實(shí)例覆蓋了案例模型中包含的所有元素、消息和決策，鏈下組件基于node.js 和Java 實(shí)現(xiàn)，鏈上智能合約使用Solidity 編輯器solc-js 編譯，通過(guò)remix-ide 部署于本地以太坊私鏈之上，相應(yīng)智能合約代碼已在GitHub 上公開(kāi)。以太坊私鏈則由以太坊節(jié)點(diǎn)仿真器Ganache 搭建，并選取其中的10 個(gè)以太坊賬戶作為過(guò)程參與者。

5.2 成本分析

在以太坊區(qū)塊鏈上計(jì)算、存儲(chǔ)數(shù)據(jù)和部署智能合約需要向以太坊礦工支付加密貨幣作為手續(xù)費(fèi)，而需要支付的手續(xù)費(fèi)為衡量相關(guān)操作復(fù)雜性的gas 數(shù)量和由調(diào)用者自行設(shè)置的gas 單價(jià)的乘積，手續(xù)費(fèi)較高的交易會(huì)優(yōu)先被以太坊礦工打包到新的區(qū)塊中。為了公平起見(jiàn)，本文將使用gas數(shù)量作為區(qū)塊鏈業(yè)務(wù)過(guò)程管理框架的成本衡量指標(biāo)。

本文所提框架的執(zhí)行總成本主要分為合約部署成本、合約數(shù)據(jù)導(dǎo)入與版本投票決策成本、過(guò)程實(shí)例創(chuàng)建與執(zhí)行成本三部分。

表1 給出了部署框架內(nèi)的訪問(wèn)控制合約ACC、投票合約VC、編排合約CC 以及公共函數(shù)庫(kù)C的合約部署成本。

表1 合約部署成本

值得注意的是，不同組織業(yè)務(wù)過(guò)程模型需要部署不同的編排合約，故合約的部署成本SCdeploy可由式(1)得到。

其中，ACCcost為訪問(wèn)控制合約部署成本，VCcost為投票合約部署成本，Ccost為公共函數(shù)庫(kù)部署成本，CCcost為編排合約部署成本，i為業(yè)務(wù)過(guò)程模型個(gè)數(shù)。

以太坊智能合約部署完成后，無(wú)法直接創(chuàng)建業(yè)務(wù)過(guò)程實(shí)例，需要在創(chuàng)建實(shí)例前導(dǎo)入CO、M和V，并且由U對(duì)VC 中的VP 進(jìn)行投票表決。將本地測(cè)試環(huán)境Ganache（以太坊節(jié)點(diǎn)仿真器）中包含的10個(gè)以太坊賬戶作為過(guò)程參與者導(dǎo)入訪問(wèn)控制合約，并為其隨機(jī)分配過(guò)程角色R。執(zhí)行上述操作需要調(diào)用的智能合約函數(shù)和相應(yīng)的以太坊gas 消耗如表2所示。

表2 合約數(shù)據(jù)導(dǎo)入與版本投票決策成本

合約數(shù)據(jù)導(dǎo)入與版本投票決策成本CIpre可由式(2)計(jì)算得到。

其中，Rcost為添加單個(gè)角色成本，Ucost為添加單個(gè)過(guò)程參與者成本，URcost為參與者分配角色成本，Vcost為發(fā)布單個(gè)版本成本，Votecost為單個(gè)參與者投票決策成本，i為角色個(gè)數(shù)，j為參與者個(gè)數(shù)，k為版本個(gè)數(shù)，Mimport為編排元模型導(dǎo)入成本。Mimport由元素模型部件導(dǎo)入總成本MEcost、消息模型部件導(dǎo)入總成本MMcost和決策模型部件導(dǎo)入總成本MDcost合計(jì)而成，如式(3)所示。

在完成合約數(shù)據(jù)導(dǎo)入和版本投票表決后，CC就能夠創(chuàng)建基于V的過(guò)程實(shí)例，并且按照V中引用的模型部件實(shí)現(xiàn)過(guò)程實(shí)例消息的交互，完成過(guò)程實(shí)例的執(zhí)行。表3 給出了商品訂購(gòu)場(chǎng)景下執(zhí)行10 個(gè)過(guò)程實(shí)例的gas 消耗。

表3 過(guò)程實(shí)例創(chuàng)建與執(zhí)行成本（10 個(gè)實(shí)例）

本文框架中的過(guò)程實(shí)例創(chuàng)建與執(zhí)行成本Icexec為

其中，Icreate為實(shí)例創(chuàng)建成本，Iexec為實(shí)例執(zhí)行成本，i為過(guò)程實(shí)例個(gè)數(shù)。

合并式(1)、式(2)和式(4)可得本文框架執(zhí)行總成本Csum為

由表3 可知，對(duì)于本文案例的編排模型而言，單個(gè)過(guò)程實(shí)例創(chuàng)建和執(zhí)行成本的平均gas 消耗約為345×104；由表1 和表2 可知，合約部署成本、合約數(shù)據(jù)導(dǎo)入與版本投票決策成本的gas 數(shù)量消耗合計(jì)約為1 800×104，而隨著過(guò)程實(shí)例數(shù)目的增加，該成本能夠被均攤到每一個(gè)過(guò)程實(shí)例中，故每一個(gè)過(guò)程實(shí)例的平均成本為

其中，i表示過(guò)程實(shí)例的個(gè)數(shù)。

5.3 與現(xiàn)有工作的比較

本節(jié)將本文工作與當(dāng)前區(qū)塊鏈上針對(duì)BPMN編排圖實(shí)現(xiàn)業(yè)務(wù)過(guò)程管理的最新研究進(jìn)展的代表工作文獻(xiàn)[2,4-6]進(jìn)行定性比較，結(jié)果如表4 所示，其中，★越多代表在相關(guān)方面越具有優(yōu)勢(shì)。

表4 相關(guān)工作的定性比較

控制支持。大多數(shù)實(shí)現(xiàn)原型能夠在區(qū)塊鏈上控制業(yè)務(wù)過(guò)程的走向，同時(shí)提供了基于網(wǎng)關(guān)數(shù)據(jù)決策的支持。文獻(xiàn)[4]提出的原型擴(kuò)展了編排圖在區(qū)塊鏈上的定義，相比其他的實(shí)現(xiàn)原型支持更多的編排圖元素。

訪問(wèn)控制。文獻(xiàn)[2]最早提出在區(qū)塊鏈上執(zhí)行編排業(yè)務(wù)過(guò)程的框架，但其未對(duì)此添加訪問(wèn)控制支持，文獻(xiàn)[6]的實(shí)現(xiàn)與其類似，而文獻(xiàn)[4]提出的框架和本文框架都提供額外用于訪問(wèn)控制的智能合約。文獻(xiàn)[5]提出的框架將參與者角色分為必須角色和可選角色，其中角色必須通過(guò)預(yù)先分配方式在合約部署時(shí)導(dǎo)入。

版本控制。本文框架是目前該領(lǐng)域少數(shù)提供區(qū)塊鏈上過(guò)程模型的版本控制支持的實(shí)現(xiàn)原型。通過(guò)復(fù)用編排元模型和采用模型部件版本集合的設(shè)計(jì)方法來(lái)實(shí)現(xiàn)版本控制功能，以降低以太坊存儲(chǔ)開(kāi)銷。

隱私控制。文獻(xiàn)[5-6]提出的原型沒(méi)有為業(yè)務(wù)過(guò)程中消息數(shù)據(jù)提供隱私控制支持，相應(yīng)的消息內(nèi)容被存儲(chǔ)在智能合約中，任何參與者都能夠訪問(wèn)消息內(nèi)容。而文獻(xiàn)[2,4]和本文框架將編排消息作為通用數(shù)據(jù)結(jié)構(gòu)存儲(chǔ)，便于使用加密算法對(duì)鏈上消息數(shù)據(jù)進(jìn)行加密。

實(shí)例化成本與執(zhí)行成本。從表4 可以看出，除本文框架外的其他所有實(shí)現(xiàn)原型都需要為單個(gè)過(guò)程實(shí)例創(chuàng)建智能合約，這種實(shí)現(xiàn)方式使過(guò)程實(shí)例化成本大幅度上升。而本文采用復(fù)用編排元模型和延遲實(shí)例元素創(chuàng)建時(shí)機(jī)的設(shè)計(jì)方式，過(guò)程實(shí)例化的成本大幅降低，而代價(jià)是過(guò)程實(shí)例的執(zhí)行成本上升。

本文框架與chorChain[5]的成本對(duì)比如圖6 所示。選擇chorChain 進(jìn)行成本定量比較的原因是該框架支持通用編排過(guò)程的鏈上執(zhí)行，并已公開(kāi)其實(shí)現(xiàn)代碼；而文獻(xiàn)[2]、文獻(xiàn)[4]和文獻(xiàn)[6]各自的工作側(cè)重點(diǎn)不同，導(dǎo)致相應(yīng)的智能合約設(shè)計(jì)與實(shí)現(xiàn)方式截然不同，只針對(duì)特定編排過(guò)程進(jìn)行驗(yàn)證或者尚未公開(kāi)具體的實(shí)現(xiàn)代碼，從而難以進(jìn)行合理的成本定量對(duì)比。

根據(jù)前文所述，本文所提框架的執(zhí)行總成本主要分為合約部署成本、合約數(shù)據(jù)導(dǎo)入與版本投票決策成本、過(guò)程實(shí)例創(chuàng)建與執(zhí)行成本三部分。其中，合約部署成本、合約數(shù)據(jù)導(dǎo)入與投票決策成本對(duì)于單個(gè)過(guò)程模型只需消耗一次，所以在圖6 中統(tǒng)一表示為框架部署成本；而實(shí)例創(chuàng)建成本和實(shí)例執(zhí)行成本隨著實(shí)例數(shù)目的增加而增長(zhǎng)。另一方面，chorChain 的執(zhí)行總成本主要分為實(shí)例創(chuàng)建成本和實(shí)例執(zhí)行成本，其中，實(shí)例創(chuàng)建成本反映了為每一個(gè)過(guò)程實(shí)例部署一個(gè)實(shí)例智能合約需要付出的gas 消耗，實(shí)例執(zhí)行成本反映了在每一個(gè)實(shí)例智能合約中完成對(duì)應(yīng)實(shí)例的執(zhí)行過(guò)程需要付出的gas 消耗。顯然，這兩者都會(huì)隨著實(shí)例數(shù)目的增加而增長(zhǎng)。

圖6 成本對(duì)比

由表1、表2 和圖6 可知，本文框架需要付出合約部署成本gas 消耗為8 070 391，合約數(shù)據(jù)導(dǎo)入與版本投票決策成本gas 消耗為10 285 234，即在創(chuàng)建過(guò)程實(shí)例前需要付出框架部署成本gas 消耗18 355 625。而在此之后，本文框架每創(chuàng)建一個(gè)過(guò)程實(shí)例僅需gas 消耗206 152，而完成實(shí)例執(zhí)行的平均gas 消耗為3 245 908。另一方面，雖然chorChain不需要額外負(fù)擔(dān)框架部署成本開(kāi)銷，但在執(zhí)行過(guò)程中需要為每個(gè)實(shí)例部署一個(gè)實(shí)例智能合約，從而付出實(shí)例創(chuàng)建成本gas 消耗為4 730 220，這遠(yuǎn)大于本文框架的實(shí)例創(chuàng)建成本。對(duì)于已部署的實(shí)例智能合約，chorChain 完成該實(shí)例執(zhí)行的平均成本gas 消耗為665 238。

綜上所述，盡管本文框架需要在實(shí)例創(chuàng)建前付出額外的框架部署成本且實(shí)例執(zhí)行平均成本大于chorChain 框架，但由于區(qū)塊鏈智能合約部署成本遠(yuǎn)大于調(diào)用合約函數(shù)成本，因此本文框架所需執(zhí)行總成本在執(zhí)行較多的實(shí)例數(shù)時(shí)整體上優(yōu)于chorChain。由圖6 可知，當(dāng)實(shí)例數(shù)目大于9 時(shí)，本文框架的gas消耗就低于chorChain，并且隨著實(shí)例數(shù)的增加，gas消耗差距將被進(jìn)一步拉大。因此本文框架在實(shí)例執(zhí)行上付出的額外開(kāi)銷是能夠被接受的。值得注意的是，本文框架的設(shè)計(jì)原理決定了其在其他場(chǎng)景下仍可表現(xiàn)出更低的成本開(kāi)銷。當(dāng)然，如果編排圖模型過(guò)于復(fù)雜，將可能導(dǎo)致本文框架中實(shí)例執(zhí)行成本超過(guò)chorChain 的實(shí)例執(zhí)行成本。但事實(shí)上，單個(gè)以太坊區(qū)塊存在gas 消耗上限，難以支持過(guò)于復(fù)雜的編排圖模型過(guò)程實(shí)例合約，故這種情況很難發(fā)生。

5.4 商品訂購(gòu)實(shí)例說(shuō)明

本節(jié)給出某公司的一個(gè)商品訂購(gòu)實(shí)例，說(shuō)明基于本文框架的執(zhí)行過(guò)程，其消息發(fā)送時(shí)序的簡(jiǎn)化示意如圖7 所示。

圖7 商品訂購(gòu)實(shí)例的消息時(shí)序示意

該商品訂購(gòu)實(shí)例包含4 個(gè)參與者，分別為某公司門店、生產(chǎn)商、物流商和發(fā)貨承運(yùn)商。其執(zhí)行過(guò)程涉及6 次發(fā)送消息函數(shù)調(diào)用和6 次確認(rèn)消息函數(shù)調(diào)用。該實(shí)例的執(zhí)行總gas 消耗為2 934 666。

5.5 局限性

盡管本文提出的框架具有靈活、實(shí)例化成本低和支持版本控制等優(yōu)點(diǎn)，但該框架并不適用于所有的編排過(guò)程。因此本節(jié)將介紹該框架的局限性。

過(guò)程模型。本文提出的框架只支持編排圖中部分元素，缺乏對(duì)于編排子過(guò)程、標(biāo)記等相關(guān)內(nèi)容的支持，而區(qū)塊鏈與外部數(shù)據(jù)交互的復(fù)雜性與智能合約基礎(chǔ)技術(shù)的限制也導(dǎo)致智能合約難以支持過(guò)程模型中的計(jì)時(shí)器。因此，目前本文框架只支持基礎(chǔ)編排圖元素，該限制可以通過(guò)擴(kuò)展智能合約結(jié)構(gòu)、添加鏈下中介器等方式來(lái)解決，這超出了本文的工作范圍，留待后續(xù)工作進(jìn)行補(bǔ)充。

隱私性。盡管本文在編排過(guò)程的消息交互過(guò)程中提供了非對(duì)稱加密算法來(lái)加密消息的內(nèi)容，但涉及決策網(wǎng)關(guān)的消息數(shù)據(jù)必須顯式地存儲(chǔ)在實(shí)例的全局變量中，整個(gè)編排過(guò)程的過(guò)程模型也以編排元模型中模型部件的形式顯式存儲(chǔ)在智能合約中。當(dāng)編排過(guò)程模型和決策條件中包含敏感數(shù)據(jù)時(shí)不建議使用本文提出的框架，該限制可以考慮使用許可的區(qū)塊鏈或者基于現(xiàn)有的相關(guān)工具[27]來(lái)解決。

訪問(wèn)控制方法。本文框架支持傳統(tǒng)的基于角色的訪問(wèn)控制方法，但參與者和角色需要管理者提前進(jìn)行導(dǎo)入和分配，過(guò)程管理者的引入降低了在訪問(wèn)控制方面的去中心化程度?，F(xiàn)有解決方案包括在訪問(wèn)控制方法中引入投票機(jī)制或者使用文獻(xiàn)[10]提出的動(dòng)態(tài)綁定模型和綁定策略規(guī)范語(yǔ)言來(lái)支持去中心的訪問(wèn)控制方法。

除上述局限性以外，基于區(qū)塊鏈的業(yè)務(wù)流程管理框架普遍存在吞吐量低、交易驗(yàn)證時(shí)延等區(qū)塊鏈本身所帶來(lái)的局限性，這些限制需要依賴現(xiàn)有區(qū)塊鏈技術(shù)的進(jìn)一步發(fā)展來(lái)解決。

6 結(jié)束語(yǔ)

本文提出了一種編排圖驅(qū)動(dòng)的區(qū)塊鏈業(yè)務(wù)過(guò)程管理框架，本文框架與傳統(tǒng)業(yè)務(wù)過(guò)程管理技術(shù)相比，具有去中心化、過(guò)程透明和防止篡改等優(yōu)點(diǎn)。與當(dāng)前領(lǐng)域相關(guān)工作相比，本文框架通過(guò)復(fù)用模型數(shù)據(jù)和引入投票機(jī)制來(lái)支持區(qū)塊鏈上業(yè)務(wù)過(guò)程的版本控制；能夠在單個(gè)智能合約中支持多個(gè)版本的編排業(yè)務(wù)過(guò)程模型，且多過(guò)程實(shí)例集成和延遲元素實(shí)例化時(shí)機(jī)的設(shè)計(jì)方法也大幅降低了創(chuàng)建過(guò)程實(shí)例的以太坊成本開(kāi)銷。

下一步工作將優(yōu)化本文提出框架內(nèi)的以太坊智能合約、完善框架功能、開(kāi)發(fā)可視化的框架執(zhí)行界面，并且在添加了版本控制的框架中提供實(shí)例遷移支持。