編排圖驅動的區塊鏈業務過程管理框架

俞東進，韋懿杰，孫笑笑，倪可，沈滬軍

（杭州電子科技大學計算機學院，浙江 杭州 310018）

1 引言

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

目前已經有許多研究者在基于區塊鏈的業務過程管理領域提出了相關的研究方法與實現原型，這些工作的重點在于過程模型的執行控制[2-6]。但是，它們一般都是通過將過程模型硬編碼為區塊鏈智能合約來支持過程實例的鏈上執行，而無法適應業務過程隨時發生變化的實際需求[7]，由此造成了過程實例化成本過高、版本迭代困難等問題。

針對上述問題，本文提出了一種編排圖驅動的區塊鏈業務過程管理框架，并給出了相關的以太坊智能合約的原型實現，最后使用助聽器行業的一個真實案例來評估本文框架的有效性。

與現有方法相比，本文具有以下創新之處。

1) 設計了包括業務過程編排元模型、模型部件版本和實例執行狀態的通用智能合約。與該領域其他方法生成適應于特定業務過程的智能合約不同，本文框架采用通用智能合約設計，將編排圖中包含的模型部件部署到智能合約的編排元模型內，同時在創建過程實例時采用集成多過程實例和延遲元素實例化時機的方法，大幅降低創建過程實例成本開銷。

2) 提供了一種基于投票機制和復用模型數據的版本控制方法，以實現基于區塊鏈的業務過程模型版本管理。該方法通過引入投票機制提高了版本控制的去中心化程度。

2 預備知識

2.1 業務過程建模標注與編排圖

業務過程建模標注（BPMN，business process modeling notation）是目前得到廣泛認同和使用的建模語言[8]。BPMN 中包含編制圖、協作圖和編排圖，其中，協作圖和編排圖都可被用于描述跨組織業務過程的執行過程。然而，協作圖沒有以簡潔的方式描述編排過程；編排圖從組織間內部編排細節中抽象而出，在一個以交互為中心的級別上描述業務過程，能夠在不暴露參與者內部行為的基礎上描述參與者之間的交互邏輯。這些特性適用于基于區塊鏈的跨組織業務過程建模。

圖1 描述了編排圖常用的建模元素，包括開始事件、結束事件、排他網關、并行網關、事件網關、編排任務和序列流。其中，開始事件和結束事件分別表示編排的開始和結束。各類網關用于控制編排中序列流的走向，其中排他網關和并行網關又可各自分為分離網關和合并網關。編排任務用于描述2 個參與者之間的消息交互，在圖1 中表示為3 個區域，中間為任務名稱，其余2 個為任務參與者。編排任務可以根據攜帶的消息數量分為單向任務和雙向任務。最后，序列流用于連接編排元素，控制業務過程的執行。

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

2.2 區塊鏈和智能合約

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

3 相關工作

近年來，區塊鏈由于其去中心化、不可篡改和可追溯等特性得到廣泛應用。這些特性尤其適用于跨組織業務過程消息交互場景，從而解決組織間的信任缺失問題。目前，許多研究者已經將區塊鏈技術應用到了業務過程領域，并取得了不少成果，相關工作主要圍繞應用理論、BPMN 編排圖、BPMN 過程圖、BPMN協作圖和場景應用等展開。

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

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

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

Sturm 等[17]基于BPMN 協作圖提供了一個包含通用數據結構的智能合約，該合約支持存儲過程模型和控制過程實例正確執行，但該文只關注業務過程的控制流邏輯，不支持創建多個過程實例。此外，Sturm 等[18]在其提出的智能合約中引入全局數據變量來支持基于數據的決策。Klinger 等[19]同樣基于協作圖提出了區塊鏈業務過程執行框架，但其工作重點放在過程模型部署和部署成本的平均分配上。

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

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

4 區塊鏈業務過程管理框架

4.1 框架設計與概念定義

本節從模型過程控制、訪問控制策略、模型版本控制和隱私控制策略4 個角度分析區塊鏈業務過程管理框架設計方案，并給出框架內部相關概念的定義說明。鏈上智能合約結構如圖2 所示。

圖2 鏈上智能合約結構

1) 模型過程控制

本文所提框架將編排圖模型中相應的模型數據存儲于以太坊智能合約中，以控制區塊鏈上過程實例的正確執行。

定義1業務過程編排元模型。業務過程編排元模型M包含所有編排模型中可能存在的元素、消息、決策三類模型部件及其版本號，即M={＜ME|MM|MD,VID ＞}，其中，ME 表示編排模型中的元素，包含開始事件、結束事件、網關和編排任務等模型元素；MM 表示編排模型中包含的交互消息；MD 表示編排模型中包含的決策條件；VID 表示相應模型部件對應的版本號。

定義2編排合約。編排合約CC 是一個存儲M、V和I的智能合約，即CC={M,V,I}，其中，模型部件版本V={＜MEi,VIDi＞}∪{＜MMj,VIDj＞}∪{＜MDk,VIDk＞} 表示任取相關模型部件的某一版本所組成的模型部件集合；實例執行狀態I=＜IE,IM,IG＞由實例元素IE、實例執行消息內容IM、實例全局數據存儲IG 組成。

本文提出的編排合約CC 內含有表示業務過程編排元模型M的數據結構體。過程實例的執行受對應的模型部件控制，具體解析和執行過程將在執行步驟中詳細說明。

2) 訪問控制策略

當使用以太坊區塊鏈來協作跨越組織業務過程的執行時，需要有授權機制來限制對于智能合約的訪問。為此本文在合約框架中引入了基于角色訪問控制方法的訪問控制智能合約。

定義3編排過程組織。編排過程組織CO 表示包含所有業務過程參與者的組織結構，即CO={U,R,UR}，其中，U表示編排過程組織的參與者，R表示編排過程組織中包含的角色，UR 表示該編排過程組織中參與者與角色的映射關系。

定義4訪問控制合約。訪問控制合約ACC 是一個用于提供授權機制與訪問控制機制的智能合約，ACC 中存儲了編排合約與編排過程組織的映射關系CCmap，它將編排合約地址 CCaddr映射到CO 來唯一確定編排合約對應的編排過程組織。

過程管理者在完成編排合約CC 的部署后，使用CCaddr在ACC 中創建CO，在CO 中導入相關的U和R，并通過UR 給參與者分配角色。相關操作都以區塊鏈交易的形式存儲于以太坊區塊中，任何參與者都能夠對過程管理者的所有操作進行追溯。

3) 模型版本控制

業務過程模型往往會隨著時間發生變化，而現有的實現原型中沒有為基于區塊鏈的業務過程模型版本控制提供支持。本文所提出的區塊鏈業務過程管理框架通過復用模型部件版本V提供版本控制功能。同時，為了增強框架的去中心化程度，本文在模型部件版本V的發布過程中引入投票機制來限制過程管理者的權力。為了實現所述功能，本文在框架內增加了投票合約。

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

CC 的模型部件版本V創建后，會自動使用CCaddr和Vid在投票合約VC 中發布一個版本發布提案VP，只有當對應的CO 中所有的參與者U都投票贊成該版本發布VP 后，該提案中指向的V才能投入使用。

4) 隱私控制策略

區塊鏈上存儲的數據能夠被公共網絡的任意節點訪問，這不利于組織間的隱私數據的交互，為此本文引入非對稱加密算法用于加密實例執行過程中的消息交互內容。

定義6實例執行消息內容。實例執行消息內容IM 是存儲于編排合約CC 的過程實例所包含的消息交互數據，由公共數據IMP 和隱私數據IMS組成，即IM={IMP,IMS}。

實例執行消息內容中的IMP 存儲于實例全局數據IG 中，包括能夠向所有參與者公開的消息內容和參與決策網關決策條件的數據內容；而IMS是指包含敏感數據的消息內容，只能被消息的發送者和接收者獲取。本文框架采用非對稱加密算法，其中每個參與者都在CO 中存有各自的公鑰，當消息發送者向消息接收者發送消息時，能夠在CO 獲取消息接收者的公鑰，并且使用公鑰加密消息數據并將消息發布到IM 中，消息接收者讀取相應消息并使用私鑰對加密消息數據解密，根據解密后消息內容選擇接收或者拒絕該消息，被拒絕的消息能夠由發送者重新發送。

4.2 框架架構

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

圖3 編排圖驅動的區塊鏈業務過程管理框架架構

建模器。本文使用的建模器[24]基于BPMN-JS開發，能夠涵蓋本文支持的所有編排圖元素，并且具有可擴展、直觀性較強和易于集成等優點，使用該建模器能夠生成xml 格式的編排圖文件F。

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

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

事件監聽器。事件監聽器用于監聽編排合約CC 內實例執行狀態I的狀態變化事件以及投票合約VC 中版本發布提案VP 的生成事件，并以此跟蹤過程實例的執行，將相關信息通知過程參與者。

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

4.3 執行步驟

本文提供的框架執行過程主要包括3 個階段，具體步驟如圖4 所示。

圖4 框架執行過程

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

步驟1過程管理者部署訪問控制合約ACC、投票合約VC、編排合約CC 與公共函數庫C。在部署投票合約時需要傳入訪問控制合約地址ACCaddr；在部署編排合約時需要傳入訪問控制合約地址ACCaddr以及投票合約地址VCaddr，以便在后續的合約訪問控制和投票決策過程中進行合約調用，相關智能合約的部署成本由過程管理者負擔或者由過程參與者進行協商負擔。完成ACC 和CC 部署后，過程管理者導入對應業務過程組織CO 中包含的U和R，并通過UR 來完成參與者角色的靜態分配。

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

算法1parsingChor (BPMN-FileF)

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

輸出編排圖文件F中所包含的元素ME、消息MM 和決策MD 等模型部件

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

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

算法2deployM(ME,MM,MD)

輸入算法1 解析模型所得元素ME、消息MM、決策MD 等模型部件

輸出導入編排元模型M后的編排合約CC

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

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

步驟4在完成步驟3 之后，CC 已存儲M，此時需要對比鏈下模型部件和鏈上模型部件并得到V，對比方式與算法2 相似。過程管理者調用編排合約的發布版本函數addVersion，將V發布到CC中，隨后在該函數內部發起對VC 的合約函數調用，在投票合約中新增VP。然后，鏈下事件監聽器組件監聽投票合約內部事件，并通過VP 內CCaddr和Vid檢索到V，讀取V中引用對應版本號的模型部件，并通知相應CO 的U。

步驟5過程參與者U收到步驟4 中的通知后查看V中引用的模型部件，通過對比鏈下過程模型與鏈上模型部件版本來核查過程管理者發布模型版本的正確性，此處也可使用現有的模型校驗工具[25-26]校驗鏈上模型部件版本的可執行性。參與者在確認V的正確性后，在VC 中對該VP 進行表決。只有當所有的過程參與者都支持VP 時，對應的V才能投入使用。同時，編排合約中現有過程實例遵循原有模型部件版本繼續執行。

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

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

5 實驗評估

5.1 案例與實驗環境說明

本文建模、執行和分析了以HE 助聽器公司為主導的一個真實商品訂購業務過程，如圖 5所示。

圖5 所示場景涉及了4 個參與者（加盟門店、生產商、物流商、發貨承運商）、14 個編排圖元素、11 條消息。如果在消息交互過程出現延誤或差錯，參與者之間可能會相互指責，而且加盟門店沒有自己的數據存儲，當其與生產商產生沖突時，生產商能夠通過篡改數據來使自己獲利。引入區塊鏈業務過程管理系統后可解決上述問題。例如，當門店與生產商產生沖突時，門店只需要追溯過程實例的消息內容與對應以太坊交易的時間戳即可維護利益，不再需要受信任第三方。此外，本文框架還支持商品訂購編排過程的實時更新，對于模型的更新需要得到所有參與者認可后才會生效。

圖5 商品訂購編排圖

本文基于所提區塊鏈業務過程管理系統框架重現了10 個該案例的過程實例執行過程，相關過程實例覆蓋了案例模型中包含的所有元素、消息和決策，鏈下組件基于node.js 和Java 實現，鏈上智能合約使用Solidity 編輯器solc-js 編譯，通過remix-ide 部署于本地以太坊私鏈之上，相應智能合約代碼已在GitHub 上公開。以太坊私鏈則由以太坊節點仿真器Ganache 搭建，并選取其中的10 個以太坊賬戶作為過程參與者。

5.2 成本分析

在以太坊區塊鏈上計算、存儲數據和部署智能合約需要向以太坊礦工支付加密貨幣作為手續費，而需要支付的手續費為衡量相關操作復雜性的gas 數量和由調用者自行設置的gas 單價的乘積，手續費較高的交易會優先被以太坊礦工打包到新的區塊中。為了公平起見，本文將使用gas數量作為區塊鏈業務過程管理框架的成本衡量指標。

本文所提框架的執行總成本主要分為合約部署成本、合約數據導入與版本投票決策成本、過程實例創建與執行成本三部分。

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

表1 合約部署成本

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

其中，ACCcost為訪問控制合約部署成本，VCcost為投票合約部署成本，Ccost為公共函數庫部署成本，CCcost為編排合約部署成本，i為業務過程模型個數。

以太坊智能合約部署完成后，無法直接創建業務過程實例，需要在創建實例前導入CO、M和V，并且由U對VC 中的VP 進行投票表決。將本地測試環境Ganache（以太坊節點仿真器）中包含的10個以太坊賬戶作為過程參與者導入訪問控制合約，并為其隨機分配過程角色R。執行上述操作需要調用的智能合約函數和相應的以太坊gas 消耗如表2所示。

表2 合約數據導入與版本投票決策成本

合約數據導入與版本投票決策成本CIpre可由式(2)計算得到。

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

在完成合約數據導入和版本投票表決后，CC就能夠創建基于V的過程實例，并且按照V中引用的模型部件實現過程實例消息的交互，完成過程實例的執行。表3 給出了商品訂購場景下執行10 個過程實例的gas 消耗。

表3 過程實例創建與執行成本（10 個實例）

本文框架中的過程實例創建與執行成本Icexec為

其中，Icreate為實例創建成本，Iexec為實例執行成本，i為過程實例個數。

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

由表3 可知，對于本文案例的編排模型而言，單個過程實例創建和執行成本的平均gas 消耗約為345×104；由表1 和表2 可知，合約部署成本、合約數據導入與版本投票決策成本的gas 數量消耗合計約為1 800×104，而隨著過程實例數目的增加，該成本能夠被均攤到每一個過程實例中，故每一個過程實例的平均成本為

其中，i表示過程實例的個數。

5.3 與現有工作的比較

本節將本文工作與當前區塊鏈上針對BPMN編排圖實現業務過程管理的最新研究進展的代表工作文獻[2,4-6]進行定性比較，結果如表4 所示，其中，★越多代表在相關方面越具有優勢。

表4 相關工作的定性比較

控制支持。大多數實現原型能夠在區塊鏈上控制業務過程的走向，同時提供了基于網關數據決策的支持。文獻[4]提出的原型擴展了編排圖在區塊鏈上的定義，相比其他的實現原型支持更多的編排圖元素。

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

版本控制。本文框架是目前該領域少數提供區塊鏈上過程模型的版本控制支持的實現原型。通過復用編排元模型和采用模型部件版本集合的設計方法來實現版本控制功能，以降低以太坊存儲開銷。

隱私控制。文獻[5-6]提出的原型沒有為業務過程中消息數據提供隱私控制支持，相應的消息內容被存儲在智能合約中，任何參與者都能夠訪問消息內容。而文獻[2,4]和本文框架將編排消息作為通用數據結構存儲，便于使用加密算法對鏈上消息數據進行加密。

實例化成本與執行成本。從表4 可以看出，除本文框架外的其他所有實現原型都需要為單個過程實例創建智能合約，這種實現方式使過程實例化成本大幅度上升。而本文采用復用編排元模型和延遲實例元素創建時機的設計方式，過程實例化的成本大幅降低，而代價是過程實例的執行成本上升。

本文框架與chorChain[5]的成本對比如圖6 所示。選擇chorChain 進行成本定量比較的原因是該框架支持通用編排過程的鏈上執行，并已公開其實現代碼；而文獻[2]、文獻[4]和文獻[6]各自的工作側重點不同，導致相應的智能合約設計與實現方式截然不同，只針對特定編排過程進行驗證或者尚未公開具體的實現代碼，從而難以進行合理的成本定量對比。

根據前文所述，本文所提框架的執行總成本主要分為合約部署成本、合約數據導入與版本投票決策成本、過程實例創建與執行成本三部分。其中，合約部署成本、合約數據導入與投票決策成本對于單個過程模型只需消耗一次，所以在圖6 中統一表示為框架部署成本；而實例創建成本和實例執行成本隨著實例數目的增加而增長。另一方面，chorChain 的執行總成本主要分為實例創建成本和實例執行成本，其中，實例創建成本反映了為每一個過程實例部署一個實例智能合約需要付出的gas 消耗，實例執行成本反映了在每一個實例智能合約中完成對應實例的執行過程需要付出的gas 消耗。顯然，這兩者都會隨著實例數目的增加而增長。

圖6 成本對比

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

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

5.4 商品訂購實例說明

本節給出某公司的一個商品訂購實例，說明基于本文框架的執行過程，其消息發送時序的簡化示意如圖7 所示。

圖7 商品訂購實例的消息時序示意

該商品訂購實例包含4 個參與者，分別為某公司門店、生產商、物流商和發貨承運商。其執行過程涉及6 次發送消息函數調用和6 次確認消息函數調用。該實例的執行總gas 消耗為2 934 666。

5.5 局限性

盡管本文提出的框架具有靈活、實例化成本低和支持版本控制等優點，但該框架并不適用于所有的編排過程。因此本節將介紹該框架的局限性。

過程模型。本文提出的框架只支持編排圖中部分元素，缺乏對于編排子過程、標記等相關內容的支持，而區塊鏈與外部數據交互的復雜性與智能合約基礎技術的限制也導致智能合約難以支持過程模型中的計時器。因此，目前本文框架只支持基礎編排圖元素，該限制可以通過擴展智能合約結構、添加鏈下中介器等方式來解決，這超出了本文的工作范圍，留待后續工作進行補充。

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

訪問控制方法。本文框架支持傳統的基于角色的訪問控制方法，但參與者和角色需要管理者提前進行導入和分配，過程管理者的引入降低了在訪問控制方面的去中心化程度。現有解決方案包括在訪問控制方法中引入投票機制或者使用文獻[10]提出的動態綁定模型和綁定策略規范語言來支持去中心的訪問控制方法。

除上述局限性以外，基于區塊鏈的業務流程管理框架普遍存在吞吐量低、交易驗證時延等區塊鏈本身所帶來的局限性，這些限制需要依賴現有區塊鏈技術的進一步發展來解決。

6 結束語

本文提出了一種編排圖驅動的區塊鏈業務過程管理框架，本文框架與傳統業務過程管理技術相比，具有去中心化、過程透明和防止篡改等優點。與當前領域相關工作相比，本文框架通過復用模型數據和引入投票機制來支持區塊鏈上業務過程的版本控制；能夠在單個智能合約中支持多個版本的編排業務過程模型，且多過程實例集成和延遲元素實例化時機的設計方法也大幅降低了創建過程實例的以太坊成本開銷。

下一步工作將優化本文提出框架內的以太坊智能合約、完善框架功能、開發可視化的框架執行界面，并且在添加了版本控制的框架中提供實例遷移支持。