基于Petri网的区块链应用系统业务流程模型研究

李 嶒 徐济成,2 李 亮

1(安徽中澳科技职业学院 安徽 合肥 230041) 2(安徽农业大学 安徽 合肥 230036) 3(中国科学技术大学 安徽 合肥 230026)

0 引 言

区块链技术起源于比特币，它将密码学、时序数据、共识机制和对等网络等技术结合起来，在去中心化的系统环境下，保证价值交易的安全、可靠、不可篡改。随着国内外学者对区块链技术研究的不断深入，区块链的应用场景从数字货币逐步扩展到金融领域之外，成为了一种去中心化的应用系统解决方案[1]。建立在区块链技术架构之上的应用系统称为区块链应用系统，为了保证区块链应用系统稳定、高效、智能地运行，其业务流程的正确性至关重要，因此在区块链应用系统实施之前需要对业务流程进行建模和分析，以此避免在运行过程中出现异常而带来的损失。

区块链应用系统的运行机制和业务流程有别于传统的DBMS，其业务流程的建模和分析方法可以借鉴传统的工作流模型分析技术，结合区块链应用的运行机制，设计业务流程的图形化建模元素，定义形式化的数学描述方法，改造流程模型验证分析算法。Petri网是一种基于状态的建模方法，适用于各种系统业务流程建模分析，它具有图形化的模型表示方法、形式化的数学描述方法、多种分析技术等特点[2]，在工作流应用系统建模分析中已有不少成熟的应用，Petri网的建模分析方法具有很好的扩展性，也适用于区块链应用系统业务流程建模分析。

1 区块链应用

1.1 区块链技术简介

区块链是从比特币底层提取出来的一种由节点共同维护的分布式共享数据库(账本)技术，区块链的基本概念有：交易(Transaction)是一次对账本的写入操作，在区块链技术中交易信息只能查询和写入，不能更新和删除；区块(Block)用于记录一个时间点发生的交易及交易的处理结果，区块数据需要区块链网络节点达成共识后才能写入账本；链(Chain)是由一个个区块数据根据交易时间点的顺序串联链接而成，相当于账本状态的日志记录。区块链技术实现了去中心化、集体维护、不可篡改和交易可追溯的应用系统解决方案，主要特点如下。

(1) 去中心化：节点之间用P2P的方式进行交易，交易的地址由参与节点自行管理，数据存储在分布式共享账本上，交易的安全由全体节点共同验证，实现了区块链网络的互信机制。

(2) 交易透明不可篡改：区块链的共享账本是一种层次数据库，数据库中的记录按照产生的时间顺序永久保存，对区块链网络上的所有节点都是公开的，任何对数据的操作都将被记录下来。

(3) 交易可追溯：由于区块数据根据hash值彼此关联，一旦达成共识写入账本，则不能对记录进行更改和删除，只有不断地追加数据来表示不同的状态。

1.2 区块链应用的运行方式

共识机制是区块链技术的核心，在P2P网络中互不信任的节点通过一种预设的规则达到对新增数据的一致认可就是共识[3]。共识机制存在的意义是抵御网络攻击、防止数据被恶意篡改。区块链应用和传统中心化DBMS提供数据记录增、删、查、改的功能不同，严格来说在区块链应用中只有查询和新增区块数据，删除和更新操作是通过新增交易数据来实现，交易数据由所有节点根据共识算法共同计算验证，达成共识的交易数据记录在共享数据库中，区块链应用向用户展示的信息为某一时刻所有交易数据共同计算的结果。区块链这种数据操作和存储的方法保证了所有信息变动是可追溯的，而且绝不可能出现更新延迟导致的信息不对称。区块链应用数据操作流程示意如图1所示。

1.3 区块链应用系统和传统DBMS的比较分析

区块链应用系统和传统中心化的DBMS都是通过应用界面和用户进行交互，从用户操作的角度来讲，两者的前端操作是一致的。DBMS采用中心化的BS或CS系统架构，客户端交互应用通过开放数据连接(数据库控制接口)来调用数据库系统(DBS)，中心服务器在网络中有着不可替代的重要地位，它根据用户角色来分配操作权限[4]，通过验证用户的合法性来保证数据的合法性，其运行方式如图2所示。

图2 DBMS运行示意图

区块链应用则是通过智能合约发送交易请求[5]，经过共识机制由节点验证后写入共享账本，为了保证操作的合法性，节点产生的交易由其他节点根据共识算法来共同计算验证，验证的对象是交易数据的本身[6]，区块链应用底层采用P2P的对等网络，所有节点在网络中具有平等的地位。区块链应用系统的运行示意图如图3所示。

图3 区块链应用系统运行示意图

区块链应用系统和传统DBMS采用完全不同的技术架构，两者在网络环境、应用环境、数据操作方式、操作主体、数据对象、验证方式、访问控制、存储方式和数据结构等方面存在不同，因此在区块链应用系统业务流程的分析方法不能直接照搬DBMS成熟的工作流管理技术，需要根据区块链应用系统的特点对建模方法、正确性定义和验证算法进行改造。区块链应用系统和DBMS的对比如表1所示。

表1 传统数据库管理系统和区块链应用系统的对比

2 区块链应用业务流程的建模方法

2.1 区块链应用业务流程的形式化定义

参照Petri网对中心化DBMS的工作流定义，结合区块链应用业务流程的运行机制，提出区块链应用系统业务流程网的定义。

定义1区块链应用业务流程网是一个四元组PCN为(P，T，V，F)，其中：

(1)P为Petri网库所的集合，库所用于表示流程路径的Token容器，∀p∈P称为一个库所；

(2)T为交易的集合，区块链应用的原子任务称为交易，T有两个子集U和S，U是数据层操作交易的集合，S是应用层交易的集合，T=U∪S，U∩S=∅；

(3)V是对交易进行分布式共识计算后的验证状态的集合，∀v∈V∧∀v(v=0∨v=1)；

(4)F是连接交易和库所之间的弧的集合，∃t1∈T∧∃t2∈T⟹(t1,t2)∈F∨(t2,t1)∈F。

推理1在PCN中至少包含两个特殊的库所：s和e，•s=∅∧e•=∅，其中：s为起始库所，表示一个业务的开始，其前驱库所•s为空；e为终止库所，表示一个业务的完成，其后继库所e•为空。一个仅有起始库所和终止库所的PCN称为空业务流。

推理2如果在空业务流PCN中加入一个交易t0，t0的前驱库所为s，t0的后继库所为e，形式化表示为：t0→v0，•t0={s}，v0•={e}。

推理3如果在非空业务流PCN中加入一个交易tn，需要定义前驱库所fn和后继库所rn，fn为前一个交易的后继库所，rn为后一个交易的前驱库所，形式化表示为：tn→vn，•tn={rn-1}，vn•={fn+1}。

推理4一个数据操作交易t连接对应一个共识子过程v，v分别连接的前驱库所和后继库所，∀t⊆U→v，•v=•t，v•=t•。

2.2 交易模型的图形化表示

一个完整的区块链应用系统业务流程由若干个原子任务组成，原子任务是一个不可分割的交易，直至完成单个操作、查询到所需数据、接受写入区块数据或拒绝写入。一个原子任务在区块链应用系统模型中表示为一个原子交易模型，由前驱库所、后继库所、交易、共识标记、共识操作和账本六个部分组成。当模型中的Token进入任务的前驱库所时，由当前节点发起交易请求，根据交易的类型状态，应用层交易直接在本地执行完成后转至后继库所；数据层交易需要智能合约对交易区块数据进行加密，向P2P网络发送广播，请求验证交易，达成共识的数据写入共享账本，无法达成共识的交易数据被拒绝写入[7]，并将Token放入交易的前驱库所。原子交易模型如图4所示。

图4 原子交易

在区块链应用系统建模中，为了便于对模型进行图形表示，需要对原子交易模型进行简化，区块链应用系统的交易分为应用层交易和数据层交易，其中应用层交易的数据交换在本地完成，不对共享账本进行操作，如本地缓存操作、本机日志文件修改、用户数据校验等，化简后的应用层原子交易如图5所示。

图5 应用层交易简化图

数据层交易需要对保存在区块链网络中的共享账本进行操作，产生一个交易区块数据并在全网中广播并请求写入，此类交易需要其他节点共同验证，达成共识后写入成功，共识失败将拒绝写入。为了更清晰地描述数据交易，将交易对应的共识子过程看成一个虚拟的交易，交易的后继库所为虚拟交易的前驱库所，虚拟交易有两个后继库所：当前交易的前驱库所和后续交易的前驱库所，化简后的数据层原子交易如图6所示。

图6 数据层交易简化图

2.3 模型的组合结构

2.3.1串行结构

具有先后顺序的交易由库所连接，前一交易的后继库所和后一交易的前驱库所为同一库所，这种模型的组合方式为串行结构。一个完整的流程模型中包含一个存在库所中的Token，图7所示为一个应用层交易和一个数据层交易顺序执行构成的组合模型。

图7 串行结构模型

2.3.2并行与结构

两个或以上交易同时执行完毕后，后续交易才能得到执行，这种模型的组合方式为并行与结构。在模型表示中，后续交易有两个或以上前驱库所，当所有前驱库所中均包含Token，才能驱动后续交易的执行，图8为一个包含并行与结构的组合模型，其中：交易t1和t2组成的并行与结构，交易t3为后续交易。

图8 并行与结构模型

2.3.3并行或结构

两个或以上的交易的其中一个执行完毕后即可执行后续交易，这种交易模型的组合方式为并行或结构。在模型表示中，两个或以上交易拥有共同的后继库所，该后继库所为后续交易的前驱库所，任意交易执行后Token均可进入后继库所，图9所示为一个包含并行或结构的组合模型，其中：交易t1和t2组成了并行或结构，交易t3为后续交易。

图9 并行或结构模型

2.4 模型的正确性定义

区块链应用系统去中心化的特性需要其在区块链网络中高度智能化地自动运行，所以该系统在实施一个业务流程模型前，要保证业务流程模型的正确性，避免应用系统在运行过程中实施维护[8]。一个区块链应用系统业务流程模型PCN为(P，T，V，F)的正确性可描述为流程的可达性、结果的唯一性、任务的必要性和共识状态的完整性[9]四个方面。

定义5共识状态的完整性：∀v⊆V∧(t→e)∧(v=1)，当模型执行完毕后，所有需要共识的任务均已经达成了共识，共识标记集合V中所有的元素的值均为1。

3 区块链应用的模型分析及应用

3.1 验证方法

数据层交易需要进行共识验证，应用系统响应了交易并不意味着交易将成功执行[10]，为了保证业务流程模型和实际相符，引入了虚拟交易的概念。将数据层交易对应的共识子过程虚拟成一个交易，若共识失败流程跳转到交易的前驱库所；共识成功则跳转到后继库所。

定义6虚拟交易。虚拟交易的前驱库所为交易的后继库所，虚拟交易的后继库所有两个：对应交易的前驱库所和后续交易的前驱库所。交易关系矩阵和交易集合中包含虚拟交易，具体形式化描述为：∀t∈U⟹∃v(•v=t•∧v•=•t∧v•=t•)，T=T∪{v}。

根据区块链应用系统业务系统模型PCN正确性四个方面的定义，利用交易关系矩阵表示交易之间的模型的弧，通过库所向量、交易集合和共识向量三个数据来动态描述每个交易执行后的模型状态。具体算法描述如下：

(1) 构造交易关系矩阵，矩阵中包含模型中的所有交易和虚拟交易，矩阵的列表和行号分别为交易，行和列交叉处的值表示为交易之间的前后关系，如交易之间存在先后关系则值为1，否则值为0。

(2) 库所向量表示Token在模型库所的存在情况，向量的维数为库所的数量，向量元素的顺序不可更改，包含Token的库所所对应的库所向量元素的值为1，空库所对应库所向量元素的值为0。模型在初始状态时，Token存在于起始库所，库所向量p=(1,0,0,0,…)；终止状态时，Token存在于终止库所，库所向量p=(0,0,0,…,0,1)；中间状态根据模型的实际执行情况作相应的修改。

(4) 共识向量表示模型中交易达成共识的情况，向量的维数为虚拟交易的数量，向量元素的顺序不可更改，在起始状态，所有查询交易对应的向量元素值为0，v=(0,0,0,…)；在终止状态时，所有交易都应该得到执行，所有虚拟交易都已经达成了共识，共识向量v=(1,1,1,…)；在中间状态，当交易集合中虚拟交易的后续交易从交易集合中删除后，更新共识向量对应元素的值。

该算法的思想就是从起始库所指向的交易开始，根据交易关系矩阵所表示的交易顺序，由交易的前驱库所引出当前交易，再将Token放入所有当前交易的后继库所，反复执行这个过程，直至流程终止。在改变当前交易的每一个步骤中，将当前的一个或多个交易从交易集合中删除，修改库所向量和共识向量，直到交易集合为空，如果库所向量和共识向量达到了最终状态，则证明该模型的正确性。

3.2 应用案例

3.2.1案例描述

身份认证系统是在区块链技术架构上建立的应用系统，身份信息修改模块中既包含了应用层的交易，也包含了数据层的交易。本案例选取了身份认证系统中身份信息修改模块，对其操作流程设计如下。

(1) 用户信息查询。进入系统后，要求用户登录系统并进行身份认证，根据用户输入的用户信息查询共享账本，共识失败后重新请求认证，共识成功后对账本进行查询，查询不到信息则转入用户注册，查询成功后进行身份信息的对比。

(2) 登录判断。将共享账本中查询的身份信息和用户录入的信息进行比对，比对成功则表示认证通过，允许用户执行修改操作，比对不成功则转入密码重设，重设密码操作需要进行共识计算。

(3) 注册用户。共享账本中不存在需要查询的身份信息时自动转入注册，用户注册操作时需要对账本进行写入，共识成功后转入认证请求，共识失败后返回注册。

(4) 身份信息修改。在本地对用户录入的身份信息进行判断，数据完成合法性校验则提交修改请求，执行共识操作，共识成功写入交易，不成功则重新提交请求。

根据以上应用案例的操作流程描述，身份信息修改业务流程如图10所示。

图10 身份信息修改业务流程图

3.2.2建立模型

根据业务流程描述，对业务流程中的交易进行分析整理，将共识操作抽象为虚拟交易，对非虚拟交易进行应用层和数据层分类，具体交易描述见表2。根据原子模型的表示方法和模型的组合方式，对业务流程进行图形化的建模如图11所示。

表2 业务流程交易表

图11 业务流程模型

3.2.3正确性推算

图12 身份信息修改业务流程关系矩阵

具体的推算步骤如下：

步骤1当前交易为t1，Token进入p2，则：

p=(0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0)

v=(0,0,0,0)

步骤2当前交易为t2，Token进入p3，则：

p=(0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0)

v=(0,0,0,0)

步骤3当前交易为t3，Token进入p4和p5，则：

p=(0,0,0,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0)

v=(0,0,0,0)

步骤4当前交易为v1和t4，Token进入p6、p3和p8，则：

p=(0,0,1,0,0,1,0,1,0,0,0,0,0,0,0,0,0,0,0)

v=(0,0,0,0)

步骤5当前交易为v2、t7和t9，Token进入p7、p9和p12，则：

p=(0,0,0,0,0,0,1,0,1,0,0,1,0,0,0,0,0,0,0)

v=(1,0,0,0)

步骤6当前交易为v2、t7和t9，Token进入p2、p6、p10和p13，则：

p=(0,1,0,0,0,1,0,0,0,1,0,0,1,0,0,0,0,0,0)

v=(1,0,0,0)

步骤7当前交易为t8和t10，Token进入p11和p14，则：

p=(0,0,0,0,0,0,0,0,0,0,1,0,0,1,0,0,0,0,0)

v=(1,1,0,0)

步骤8当前交易为v3和t11，Token进入p2、p10和p15，则：

p=(0,1,0,0,0,0,0,0,0,1,0,0,0,0,1,0,0,0)

v=(1,1,0,0)

步骤9当前交易为t12，Token进入p16，则：

p=(0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0,0)

v=(1,1,1,0)

步骤10当前交易为v4，Token进入p15和p17，则：

p=(0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0,1,0)

v=(1,1,1,0)

步骤11当前交易为t13，Token进入p18，则：

p=(0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1)

v=(1,1,1,1)

经过以上步骤验证，在最终状态，交易集合为空，表示所有交易都得到了执行，满足交易的必要性定义；库所向量仅最后一个元素为1，满足了结果的唯一性和流程的可达性定义；共识向量所有元素均为1，满足了共识的完整性定义。综上，该业务流程是正确的。

3.3 业务流程的实现

3.3.1区块链应用系统技术架构

一个完整的区块链应用由用户交互层、智能合约层和区块链核心层[11]三个部分组成：最底层是区块链核心层，是区块链应用系统运行的基础，它包含了区块数据存储、区块头的链式结构、Mekel树层次结构，通过Hash函数确定区块数据的地址关系，P2P的网络结构决定了去中心化的系统架构；智能合约层是用户交互层和区块链核心层之间数据交换的桥梁，是区块链应用程序区别于传统数据库管理系统最关键的部分，智能合约决定了应用系统的功能，系统对数据的操作通过调用职能合约完成，智能合约编译后存放在合约容器中，智能合约虚拟机是智能合约的运行环境；用户交互层是区块链应用系统的前端程序集合，由用户交互界面、前端程序运行环境、本地数据和文件、操作函数和应用接口等部分构成，其中操作函数主要作用是通过调用智能合约中定义的函数进行区块数据的操作，本地数据临时保存在本地计算机上，对本地数据的修改和访问不需要其他节点参与共识验证，流程引擎是用于注册和执行业务流程模型。区块链应用系统的体系架构如图13所示。

3.3.2数据传递方式

区块链应用系统用户界面处在应用层，其中包含本地数据和本地函数，流程引擎对本地操作提供运行支持，当用户需要对应用系统进行操作时，系统调用本地函数来响应用户的请求，如果所处理的数据为本地数据，则直接在应用层处理完毕后返回结果。系统对共享账本的操作需要通过本地函数调用智能合约函数，由智能合约对交易进行加密并向全网广播，其他节点参与交易的验证，向区块链网络返回共识计算结果，并执行交易的写入。交易写入操作完成后，返回的数据保存在合约变量中，由合约函数对数据进行解密后传递给本地应用层函数，最终向用户返回结果[12]。区块链应用系统的数据传递方式如图14所示。

3.3.3流程引擎的应用

流程引擎的作用是将流程模型实施应用，区块链应用系统是建立在区块链技术架构上，应用的特殊性要求引擎必须是轻量级的，以便于将用户界面、流程引擎、智能合约和虚拟机打包在一起分发到节点计算机上。Bigbross Bossa是一个按嵌入式设计的轻量级的流程引擎[13]，适合实施使用Petri网定义工作流模型，完全支持层次数据库，能方便集成到应用系统中。在应用程序中调用Bossa引擎时，需要通过BossaFactory类生成一个对象，并通过此对象创建一个流程模型实例，注册模型对象，最后执行模型，具体方法如下：

(1) 流程引擎的实例化：

BossaFactory factory01 = new BossaFactory();

factory.setModel(″dir″);

(2) 创建一个空模型：

bossaModel = factory.createModel();

(3) 模型的定义：

Place place = bossaModel.registerPlace(″p1″, 1);

//建立库所，第一个参数为库所名，第二个参数表示库所

//中是否包含Token

Transition t = caseType.registerTransition(″t1″, ″explain″);

//创建交易，第一个参数为交易名，第二个参数为交易说明

t.input(p1, ″1″);

t.output(p2, ″1″);

//定义交易t的前驱库所和后继库所

(4) 模型的注册和执行：

factory01 .buildTemplate(bossaModel);

//注册模型

Activity activity =factory01.open(bossaModel);

//开始执行模型

structure activity.cancel();

//执行完毕，返回操作结果

4 结 语

由于区块链应用系统和传统数据库管理系统在数据验证和操作机制的不同，需要在传统工作流建模与验证方法上进行改造，使业务流程模型的表示方式和验证算法能满足区块链的运行特点。本文给出的建模方法以传统工作流技术为基础，根据Petri网提供的图形元素，结合区块链的技术特点和运行机制，对业务流程中的交易进行抽象和表达，给出业务流程的图形化模型。在模型的正确性定义上，增加了区块链共识计算的部分，一个业务流程执行完毕需要完成所有交易的共识计算。模型正确性验证过程中，将共识计算抽象为一个虚拟交易，和其他交易一起共同参与交易关系矩阵的构造，算法根据交易顺序模拟流程的执行过程，每次执行都按照规则改变状态向量的值，直到所有交易执行完毕，根据状态向量的结果判断流程模型的正确性。

本文提出的模型符合区块链应用程序的运行机制和特点，其建模方法能够完整地表达区块链应用业务流程，正确性定义中对区块链共识计算部分进行了描述，验证算法能方便地对模型正确性定义进行推导。由于共识计算和普通交易不完全一致，为了更清晰地描述区块链应用系统模型，未来需要寻找一种比Petri网语义和图形元素更为丰富的建模工具，模型正确性验证方法也有待进一步研究和探索。