CN110473081A - 基于区块链的电子票据报销方法及装置、电子设备 - Google Patents

Abstract

本说明书一个或多个实施例提供一种基于区块链的电子票据报销方法及装置、电子设备，应用于所述区块链中的节点设备；所述区块链中存证了电子票据；所述方法包括：在监听到由报销发起方发布至所述区块链的针对目标电子票据的报销交易时，确定维护的所述目标电子票据是否为未报销状态；如果所述目标电子票据为未报销状态，则将所述目标电子票据由未报销状态更新为报销锁定状态，并在将所述目标电子票据更新为报销锁定状态之后，指示报销受理方对所述目标电子票据进行报销处理；确定是否监听到所述报销受理方发布至所述区块链的与所述目标电子票据对应的报销结果；如果监听到所述报销结果，则将所述目标电子票据由报销锁定状态更新为已报销状态。

Description

基于区块链的电子票据报销方法及装置、电子设备

技术领域

本说明书一个或多个实施例涉及区块链技术领域，尤其涉及一种基于区块链的电子票据报销方法及装置、电子设备。

背景技术

区块链技术，也被称之为分布式账本技术，是一种由若干台计算设备共同参与“记账”，共同维护一份完整的分布式数据库的新兴技术。由于区块链技术具有去中心化、公开透明、每台计算设备可以参与数据库记录、并且各计算设备之间可以快速的进行数据同步的特性，使得区块链技术已在众多的领域中广泛的进行应用。

发明内容

本说明书提出一种基于区块链的电子票据报销方法，所述方法应用于所述区块链中的节点设备；所述区块链中存证了电子票据；所述方法包括：

在监听到由报销发起方发布至所述区块链的针对目标电子票据的报销交易时，确定维护的所述目标电子票据是否为未报销状态；

如果所述目标电子票据为未报销状态，则将所述目标电子票据由未报销状态更新为报销锁定状态，并在将所述目标电子票据更新为报销锁定状态之后，指示报销受理方对所述目标电子票据进行报销处理；

确定是否监听到所述报销受理方发布至所述区块链的与所述目标电子票据对应的报销结果；

如果监听到所述报销结果，则将所述目标电子票据由报销锁定状态更新为已报销状态。

可选地，所述在监听到由报销发起方发布至所述区块链的针对目标电子票据的报销交易时，确定维护的所述目标电子票据是否为未报销状态，包括：

响应于所述报销交易，调用部署在所述区块链上的智能合约中声明的报销校验逻辑，对所述报销发起方进行报销校验；

响应于监听到的由所述智能合约生成的与所述报销发起方对应的校验通过事件，进一步确定维护的所述目标电子票据是否为未报销状态。

可选地，所述报销条件包括：报销权限条件；报销额度条件；报销期限条件。

可选地，所述报销受理方订阅了所述节点设备维护的所述目标电子票据的票据状态；

所述在将所述目标电子票据更新为报销锁定状态之后，指示报销受理方对所述目标电子票据进行报销处理，包括：

在将所述目标电子票据更新为报销锁定状态之后，将所述目标电子票据的报销锁定状态推送至所述报销受理方，以触发所述报销受理方对处于报销锁定状态的所述目标电子票据进行报销处理。

可选地，所述方法还包括：

如果在预设时长内未监听到所述报销结果，则将所述目标电子票据由报销锁定状态更新为未报销状态。

可选地，所述方法还包括：

如果所述目标电子票据为报销锁定状态，则向所述报销发起方发送用于指示所述目标电子票据报销失败的通知消息。

本说明书还提出一种基于区块链的电子票据报销装置，所述装置应用于所述区块链中的节点设备；所述区块链中存证了电子票据；所述装置包括：

确定模块，用于在监听到由报销发起方发布至所述区块链的针对目标电子票据的报销交易时，确定维护的所述目标电子票据是否为未报销状态；

第一更新模块，用于在所述目标电子票据为未报销状态时，将所述目标电子票据由未报销状态更新为报销锁定状态，并在将所述目标电子票据更新为报销锁定状态之后，指示报销受理方对所述目标电子票据进行报销处理；

监听模块，用于确定是否监听到所述报销受理方发布至所述区块链的与所述目标电子票据对应的报销结果；

第二更新模块，用于在监听到所述报销结果时，将所述目标电子票据由报销锁定状态更新为已报销状态。

可选地，所述确定模块具体用于：

响应于所述报销交易，调用部署在所述区块链上的智能合约中声明的报销校验逻辑，对所述报销发起方进行报销校验；

响应于监听到的由所述智能合约生成的与所述报销发起方对应的校验通过事件，进一步确定维护的所述目标电子票据是否为未报销状态。

可选地，所述报销条件包括：报销权限条件；报销额度条件；报销期限条件。

可选地，所述报销受理方订阅了所述节点设备维护的所述目标电子票据的票据状态；

所述第一更新模块具体用于：

在将所述目标电子票据更新为报销锁定状态之后，将所述目标电子票据的报销锁定状态推送至所述报销受理方，以触发所述报销受理方对处于报销锁定状态的所述目标电子票据进行报销处理。

可选地，所述装置还包括：

第三更新模块，用于在预设时长内未监听到所述报销结果时，将所述目标电子票据由报销锁定状态更新为未报销状态。

可选地，所述装置还包括：

发送模块，用于在所述目标电子票据为报销锁定状态时，向所述报销发起方发送用于指示所述目标电子票据报销失败的通知消息。

本说明书还提出一种电子设备，包括：

处理器；

用于存储处理器可执行指令的存储器；

其中，所述处理器通过运行所述可执行指令以实现上述方法的步骤。

本说明书还提出一种计算机可读存储介质，其上存储有计算机指令，其特征在于，该指令被处理器执行时实现上述方法的步骤。

在上述技术方案中，可以在监听到由报销发起方发布至区块链的针对未报销状态的电子票据的报销交易时，将维护的该电子票据更新为报销锁定状态，而在将该电子票据更新为报销锁定状态之后，可以进一步指示报销受理方对该电子票据进行报销处理。后续，如果监听到该报销受理方发布至该区块链的与该电子票据对应的报销结果，则可以将维护该电子票据更新为已报销状态。采用这样的方式，即可实现对区块链中存证的电子票据的报销处理；此外，由于可以不对针对报销锁定状态或已报销状态的电子票据的报销交易进行后续处理，因此可以避免对电子票据的重复报销。

附图说明

图1是本说明书示出的一种将区块链的账户状态数据组织成MPT状态树的示意图；

图2是本说明书示出的一种MPT状态树上的node复用的示意图；

图3是本说明书示出的一种智能合约的创建流程的示意图；

图4是本说明书示出的一种智能合约的调用流程的示意图；

图5是本说明书示出的一种智能合约的创建和调用流程的示意图；

图6是本说明书一示例性实施例示出的一种基于区块链的电子票据报销系统的示意图；

图7是本说明书一示例性实施例示出的一种电子票据的票据状态更新流程的示意图；

图8是本说明书一示例性实施例示出的一种基于区块链的电子票据报销方法的流程图；

图9是本说明书一示例性实施例示出的一种电子设备的结构示意图；

图10是本说明书一示例性实施例示出的一种基于区块链的电子票据报销装置的框图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本说明书一个或多个实施例相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本说明书一个或多个实施例的一些方面相一致的装置和方法的例子。

需要说明的是：在其他实施例中并不一定按照本说明书示出和描述的顺序来执行相应方法的步骤。在一些其他实施例中，其方法所包括的步骤可以比本说明书所描述的更多或更少。此外，本说明书中所描述的单个步骤，在其他实施例中可能被分解为多个步骤进行描述；而本说明书中所描述的多个步骤，在其他实施例中也可能被合并为单个步骤进行描述。

区块链一般被划分为三种类型：公有链(Public Blockchain)，私有链(PrivateBlockchain)和联盟链(Consortium Blockchain)。此外，还可以有上述多种类型的结合，比如私有链+联盟链、联盟链+公有链等。

其中，去中心化程度最高的是公有链。公有链以比特币、以太坊为代表，加入公有链的参与者(也可称为区块链中的节点)可以读取链上的数据记录、参与交易、以及竞争新区块的记账权等。而且，各节点可自由加入或者退出网络，并进行相关操作。

私有链则相反，该网络的写入权限由某个组织或者机构控制，数据读取权限受组织规定。简单来说，私有链可以为一个弱中心化系统，其对节点具有严格限制且节点数量较少。这种类型的区块链更适合于特定机构内部使用。

联盟链则是介于公有链以及私有链之间的区块链，可实现“部分去中心化”。联盟链中各个节点通常有与之相对应的实体机构或者组织；节点通过授权加入网络并组成利益相关联盟，共同维护区块链运行。

基于区块链的基本特性，区块链通常是由若干个区块构成。在这些区块中分别记录有与该区块的创建时刻对应的时间戳，所有的区块严格按照区块中记录的时间戳，构成一条在时间上有序的数据链条。

对于物理世界产生的真实数据，可以将其构建成区块链所支持的标准的交易(transaction)格式，然后发布至区块链，由区块链中的节点设备对收到的交易进行共识处理，并在达成共识后，由区块链中作为记账节点的节点设备，将这笔交易打包进区块，在区块链中进行持久化存证。

其中，区块链中支持的共识算法可以包括：

第一类共识算法，即节点设备需要争夺每一轮的记账周期的记账权的共识算法；例如，工作量证明(Proof of Work,POW)、股权证明(Proof of Stake，POS)、委任权益证明(Delegated Proof of Stake，DPOS)等共识算法；

第二类共识算法，即预先为每一轮记账周期选举记账节点(不需要争夺记账权)的共识算法；例如，实用拜占庭容错(Practical Byzantine Fault Tolerance，PBFT)等共识算法。

在采用第一类共识算法的区块链网络中，争夺记账权的节点设备，都可以在接收到交易后执行该笔交易。争夺记账权的节点设备中可能有一个节点设备在本轮争夺记账权的过程中胜出，成为记账节点。记账节点可以将收到的交易与其它交易一起打包以生成最新区块，并将生成的最新区块或者该最新区块的区块头发送至其它节点设备进行共识。

在采用第二类共识算法的区块链网络中，具有记账权的节点设备在本轮记账前已经商定好。因此，节点设备在接收到交易后，如果自身不是本轮的记账节点，则可以将该交易发送至记账节点。对于本轮的记账节点，在将该交易与其它交易一起打包以生成最新区块的过程中或者之前，可以执行该交易。记账节点在生成最新区块后，可以将该最新区块或者该最新区块的区块头发送至其它节点设备进行共识。

如上所述，无论区块链采用以上示出的哪种共识算法，本轮的记账节点都可以将接收到的交易打包以生成最新区块，并将生成的最新区块或者该最新区块的区块头发送至其它节点设备进行共识验证。如果其它节点设备接收到最新区块或者该最新区块的区块头后，经验证没有问题，可以将该最新区块追加到原有的区块链末尾，从而完成区块链的记账过程。其它节点验证记账节点发来的新的区块或区块头的过程中，也可以执行该区块中的包含的交易。

在区块链领域，有一个重要的概念就是账户(Account)；以以太坊为例，以太坊通常将账户划分为外部账户和合约账户两类；外部账户就是由用户直接控制的账户，也称之为用户账户；而合约账户则是由用户通过外部账户创建的，包含合约代码的账户(即智能合约)。当然，对于一些基于以太坊的架构而衍生出的区块链项目(比如蚂蚁区块链)，还可以对区块链支持的账户类型，进行进一步的扩展，在本说明书中不进行特别限定。

对于区块链中的账户而言，通常会通过一个结构体，来维护账户的账户状态。当区块中的交易被执行后，区块链中与该交易相关的账户的状态通常也会发生变化。

以以太坊为例，账户的结构体通常包括Balance，Nonce，Code和Storage等字段。其中：

Balance字段，用于维护账户目前的账户余额；

Nonce字段，用于维护该账户的交易次数；它是用于保障每笔交易能且只能被处理一次的计数器，有效避免重放攻击；

Code字段，用于维护该账户的合约代码；在实际应用中，Code字段中通常仅维护合约代码的hash值；因而，Code字段通常也称之为Codehash字段。

Storage字段，用于维护该账户的存储内容(默认字段值为空)；对于合约账户而言，通常会分配一个独立的存储空间，用以存储该合约账户的存储内容；该独立的存储空间通常称之为该合约账户的账户存储。合约账户的存储内容通常会构建成MPT(MerklePatricia Trie)树的数据结构存储在上述独立的存储空间之中；其中，基于合约账户的存储内容构建成的MPT树，通常也称之为Storage树。而Storage字段通常仅维护该Storage树的根节点；因此，Storage字段通常也称之为StorageRoot字段。

其中，对于外部账户而言，以上示出的Code字段和Storage字段的字段值均为空值。

对于大多数区块链项目，通常都会使用Merkle树；或者，基于Merkle树的数据结构，来存储和维护数据。以以太坊为例，以太坊使用了MPT树(一种Merkle树变种)，作为数据组织形式，用来组织和管理账户状态、交易信息等重要数据。

以太坊针对区块链中需要存储和维护的数据，设计了三颗MPT树，分别是MPT状态树、MPT交易树和MPT收据树。其中，除了以上三颗MPT树以外，实际上还存在一颗基于合约账户的存储内容构建的Storage树。

MPT状态树，是由区块链中所有账户的账户状态(state)数据组织成的MPT树；MPT交易树，是由区块链中的交易(transaction)数据组织成的MPT树；MPT收据树，是区块中的交易在执行完毕后生成的与每笔交易对应的交易(receipt)收据组织成的MPT树。以上示出的MPT状态树、MPT交易树和MPT收据树的根节点的hash值，最终都会被添加至对应区块的区块头中。

其中，MPT交易树和MPT收据树均与区块相对应，即每一个区块都有自己的MPT交易树和MPT收据树。而MPT状态树是一个全局的MPT树，并不与某一个特定的区块相对应，而是涵盖了区块链中所有账户的账户状态数据。

对于组织成的MPT交易树、MPT收据树和MPT状态树，最终都会在采用多级数据存储结构的Key-Value型数据库(比如，LevelDB)中进行存储。

而采用多级数据存储结构的上述数据库，通常采用多级数据存储的结构，可以被划分为n级数据存储；例如，各级数据存储可以依次设为L0，L1，L2，L3，...，L(n-1)；对于上述数据库中的各级数据存储而言，等级编号越小通常级别越高；例如，L0存储的是最新的若干区块的数据，L1存储的是次新的若干区块的数据，以此类推。

其中，各级数据存储对应的存储介质的读写性能，通常也可以存在性能差异；例如，级别高(即等级编号较小的)的数据存储对应的存储介质的读写性能，可以高于级别低的数据存储对应的存储介质的读写性能。在实际应用中，级别高的数据存储，可以使用存储成本较高，存储性能较优的存储介质；而级别低的数据存储，可以使用单位成本低，且容量较大的存储介质。

在实际应用中，随着区块链的区块号的增长(也称之为区块高度)，在数据库中存储的数据，会包含很多历史数据；而且，区块号越小的区块中的数据越久远，越不重要。因此，为了降低整体的存储成本，通常可以对不同区块高度的数据进行“区别对待”；例如，可以将区块号较小的区块中的数据，存储至成本较低的存储介质上；而将区块号较大的区块中的数据，存储在成本较高的存储介质上。

需要说明的是，区块链每产生一个最新区块，则在该最新区块中的交易被执行之后，区块链中这些被执行交易的相关账户(可以是外部账户也可以是合约账户)的账户状态，通常也会随之发生变化；

例如，当区块中的一笔“转账交易”执行完毕后，与该“转账交易”相关的转出方账户和转入方账户的余额(即这些账户的Balance字段的字段值)，通常也会随之发生变化。

而节点设备在区块链产生的最新区块中的交易执行完毕后，由于当前区块链中的账户状态发生了变化，因此节点设备需要根据区块链中所有账户当前的账户状态数据，来构建MPT状态树，用于维护区块链中所有账户的最新状态。

也即，每当区块链中产生一个最新区块，并且该最新区块中的交易执行完毕后，导致区块链中的账户状态发生变化，节点设备都需要基于区块链中所有账户最新的账户状态数据，重新构建一颗MPT状态树。换句话说，区块链中每一个区块，都有一个与之对应的MPT状态树；该MPT状态树，维护了在该区块中的交易在执行完毕后，区块链中所有账户最新的账户状态。

请参考图1，图1是本说明书示出的一种将区块链的账户状态数据组织成MPT状态树的示意图。

MPT树，是一种经过改良的Merkle树变种，其融合了Merkle树和Trie字典树(也称之为前缀树)两种树形结构的优点。

在MPT树中通常包括三种数据节点，分别为叶子节点(leaf node)，扩展节点(extension node)和分支节点(branch node)。

叶子节点，是表示为[key，value]的一个键值对，其中key是种特殊的十六进制编码字符，value是该叶子节点对应的账户地址的状态数据(即以上示出的结构体)。扩展节点，也是表示为[key，value]的一个键值对，其中key也是种特殊的十六进制编码字符，但是value是其他节点的hash值(hash指针)，也就是说可以通过hash指针链接到其他节点。

分支节点，包含17个元素，前16个元素对应着key中的16个可能的十六进制字符；一个字符对应一个nibble(半字节)。如果有一个[key，value]对在这个分支节点终止，则该分支节点可以充当叶子节点的角色，最后一个元素则代表叶子节点的value值；反之，分支节点的最后一个元素，可以为空值。

由于在MPT树上，从根节点到一个叶子节点的搜索路径上的字符，组成一个完整的账户地址；因此，对于分支节点而言，其既可以是上述搜索路径的终止节点，也可以是上述搜索路径的中间节点。

假设需要组织成MTP状态树的账户状态数据如下表1所示：

表1

在表1中，账户地址是由若干16进制的字符构成的字符串。账户状态state，是由上述Balance，Nonce，Code和Storage等字段构成的结构体。

最终按照表1中的账户状态数据组织成的MPT状态树，参考图1所示，该MPT状态树是由4个叶子节点，2个分支节点，和2个扩展节点构成。

在图1中，prefix字段为扩展节点和叶子节点共同具有的前缀字段。该prefix字段的不同字段值可以用于表示不同的节点类型。

例如，prefix字段的取值为0，表示包含偶数个nibbles的扩展节点；如前所述，nibble表示半字节，由4位二进制组成，一个nibble可以对应一个组成账户地址的字符。prefix字段的取值为1，表示包含奇数个nibble(s)的扩展节点；prefix字段的取值为2，表示包含偶数个nibbles的叶子节点；prefix字段的取值为3，表示包含奇数个nibble(s)的叶子节点。

而分支节点，由于其是并列单nibble的前缀节点，因此分支节点不具有上述prefix字段。

扩展节点中的Shared nibble字段，对应该扩展节点所包含的键值对的key值，表示账户地址之间的共同字符前缀；比如，上表中的所有账户地址均具有共同的字符前缀a7。Next Node字段中填充下一个节点的hash值(hash指针)。

分支节点中的16进制字符0～f字段，对应该分支节点所包含的键值对的key值；如果该分支节点为账户地址在MPT树上的搜索路径上的中间节点，则该分支节点的Value字段可以为空值。0～f字段中用于填充下一个节点的hash值。

叶子节点中的Key-end，对应该叶子节点所包含的键值对的key值，表示账户地址的最后几个字符。从根节点搜索到叶子节点的搜索路径上的各个节点的key值，构成了一个完整的账户地址。该叶子节点的Value字段填充账户地址对应的账户状态数据；例如，可以对上述Balance，Nonce，Code和Storage等字段构成的结构体进行编码后，填充至叶子节点的Value字段。

进一步的，如图1所示的MPT状态树上的node，最终也是以Key-Value键值对的形式存储在数据库中；

其中，当MPT状态树上的node在数据库中进行存储时，MPT状态树上的node的键值对中的key，为node所包含的数据内容的hash值；MPT状态树上的node的键值对中的Value，为node所包含的数据内容。

也即，在将MPT状态树上的node存储至数据库时，可以计算该node所包含的数据内容的hash值(即对node整体进行hash计算)，并将计算出的hash值作为key，将该node所包含的数据内容作为value，生成Key-Value键值对；然后，将生成的Key-Value键值对存储至数据库中。

由于MPT状态树上的node，是以node所包含的数据内容的hash值为Key，node所包含的数据内容为value进行存储；因此，在需要查询MPT状态树上的node时，通常可以基于node所包含的数据内容的hash值作为key来进行内容寻址。而采用“内容寻址”，对于一些“内容重复”的node，则通常可以进行“复用”，以节约数据存储的存储空间。

如图2所示，图2是本说明书示出的一种MPT状态树上的node复用的示意图。需要说明的是，在实际应用中，当区块链产生的一个最新区块中的交易执行完毕后，可能仅仅会导致部分账户的账户状态发生变化；因此，在构建MPT状态树时，并不需要基于区块链中所有的账户当前的状态数据，重新构建一颗完整的MPT状态树，而只需要在该最新区块之前的区块对应的MPT状态树的基础上，对部分账户状态发生变化的账户对应的node进行更新即可。而对于MPT状态树上与账户状态未发生变化的账户对应的node，由于这些node未发生数据更新，因此可以直接复用该最新区块之前的区块对应的MPT状态树上相应的node即可。

如图2所示，假设表1中的账户状态数据，为Block N中的交易执行完毕后，区块链上所有账户的最新账户状态；基于表1中的账户状态数据组织成的MPT状态树，仍如图1所示。

假设当Block N+1中的交易执行完毕后，导致上述表1中的账户地址为“a7f9365”的账户状态，由“state3”更新为“state5”；此时，在Block N+1更新MPT状态树时，并不需要在Block N+1中的交易执行完毕后，基于区块链中所有的账户当前的状态数据重新构建一颗MPT状态树。

在这种情况下，可以仅将Block N对应的MPT状态树上(即图1示出的MPT状态树)，“key-end”为“9365”的叶子节点中的Value，由“state3”更新为“state5”，并继续更新从root节点到该叶子节点的路径上的所有节点的hash指针；

也即，当MPT状态树上的叶子节点发生更新，由于该叶子节点整体的hash值发生更新，那么从根节点到该叶子节点的路径上的所有节点的hash指针也会随之发生更新。

例如，请继续参考图2，除了需要更新“key-end”为“9365”的叶子节点中的Value值以外，还需要更新该叶子节点的上一个分支节点(Branch Node)的f字段中填充的，指向该叶子节点的hash指针；进一步的，还可以继续向根节点追溯，继续更新该分支节点的上一个根节点(Root Extension Node)的“Next Node”字段中填充的，指向该分支节点的hash指针。

而除了以上发生更新的节点以外，其它未发生更新的节点，都可以直接复用BlockN的MPT状态树上对应的节点即可；

其中，由于Block N对应的MPT树，最终需要作为历史数据进行保留；因此，在BlockN+1更新MPT状态树时，对于这些发生更新的node，并不是在Block N对应的MPT状态树上原来的node的基础上，直接进行修改更新，而是在Block N+1对应的MPT树上重新创建这些发生更新的node。也即，在与Block N+1对应的MPT状态树上，实际上只需要重新创建少量发生更新的node，对于其它未发生更新的node，可以通过直接复用Block N对应的MPT状态树上对应的节点。

例如，如图2所示，对于Block N+1对应的MPT状态树上，实际上只需要重新创建一个作为根节点的扩展节点、一个分支节点和一个叶子节点；对于未发生更新的node，可以通过在该MPT状态树上这些重新创建的node中，添加指向Block N对应的MPT状态树上的相应node的hash指针来完成node的“复用”。而Block N对应的MPT状态树上那些更新之前的node，将作为历史账户状态数据进行保存；比如，图2示出的“key-end”为“9365”，且Value为“state3”的叶子节点，将作为历史数据进行保留。

在以上例子中，以Block N+1的MPT状态树上的少量node发生内容更新，从而可以“复用”上一个区块Block N的大多数node为例进行了说明。而在实际应用中，Block N+1的MPT状态树上也可能会较上一个区块Block N新增node。在这种情况下，该新增的node虽然无法直接从上一个区块Block N的MPT树中进行“复用”，但有可能从更早之前的区块的MPT状态树上进行“复用”；

例如，Block N+1的MPT状态树上新增的node，虽然没在Block N的MPT状态树上出现过，但可能出现在更早的Block的MPT状态树上；比如，出现在Block N-1的MPT状态树上；因此，Block N+1的MPT状态树上新增的node，可以直接复用Block N-1的MPT状态树上对应的node即可。

在实际应用中，不论是公有链、私有链还是联盟链，都可能提供智能合约(Smartcontract)的功能。区块链上的智能合约是在区块链上可以被交易触发执行的合约。智能合约可以通过代码的形式定义。

以以太坊为例，支持用户在以太坊网络中创建并调用一些复杂的逻辑。以太坊作为一个可编程区块链，其核心是以太坊虚拟机(EVM)，每个以太坊节点都可以运行EVM。EVM是一个图灵完备的虚拟机，通过它可以实现各种复杂的逻辑。用户在以太坊中发布和调用智能合约就是在EVM上运行的。实际上，EVM直接运行的是虚拟机代码(虚拟机字节码，下简称“字节码”)，所以部署在区块链上的智能合约可以是字节码。

如图3所示，Bob将一笔包含创建智能合约信息的交易(Transaction)发送到以太坊网络后，各节点均可以在EVM中执行这笔交易。其中，图中1中交易的From字段用于记录发起创建智能合约的账户的地址，交易的Data字段的字段值保存的合约代码可以是字节码，交易的To字段的字段值为一个null(空)的账户。当节点间通过共识机制达成一致后，这个智能合约成功创建，后续用户可以调用这个智能合约。

智能合约创建后，区块链上出现一个与该智能合约对应的合约账户，并拥有一个特定的地址；比如，图1中各节点中的“0x68e12cf284…”就代表了创建的这个合约账户的地址；合约代码(Code)和账户存储(Storage)将保存在该合约账户的账户存储中。智能合约的行为由合约代码控制，而智能合约的账户存储则保存了合约的状态。换句话说，智能合约使得区块链上产生包含合约代码和账户存储的虚拟账户。

前述提到，包含创建智能合约的交易的Data字段保存的可以是该智能合约的字节码。字节码由一连串的字节组成，每一字节可以标识一个操作。基于开发效率、可读性等多方面考虑，开发者可以不直接书写字节码，而是选择一门高级语言编写智能合约代码。例如，高级语言可以采用诸如Solidity、Serpent、LLL语言等。对于采用高级语言编写的智能合约代码，可以经过编译器编译，生成可以部署到区块链上的字节码。

以Solidity语言为例，用其编写的合约代码与面向对象编程语言中的类(Class)很相似，在一个合约中可以声明多种成员，包括状态变量、函数、函数修改器、事件等。状态变量是永久存储在智能合约的账户存储(Storage)字段中的值，用于保存合约的状态。

如图4所示，仍以以太坊为例，Bob将一笔包含调用智能合约信息的交易发送到以太坊网络后，各节点均可以在EVM中执行这笔交易。其中，图中4中交易的From字段用于记录发起调用智能合约的账户的地址，To字段用于记录被调用的智能合约的地址，交易的Data字段用于记录调用智能合约的方法和参数。调用智能合约后，合约账户的账户状态可能改变。后续，某个客户端可以通过接入的区块链节点(例如图4中的节点1)查看合约账户的账户状态。

智能合约可以以规定的方式在区块链网络中每个节点独立的执行，所有执行记录和数据都保存在区块链上，所以当这样的交易执行完毕后，区块链上就保存了无法篡改、不会丢失的交易凭证。

创建智能合约和调用智能合约的示意图如图5所示。以太坊中要创建一个智能合约，需要经过编写智能合约、变成字节码、部署到区块链等过程。以太坊中调用智能合约，是发起一笔指向智能合约地址的交易，各个节点的EVM可以分别执行该交易，将智能合约代码分布式的运行在以太坊网络中每个节点的虚拟机中。

以以太坊代表的传统的区块链项目，为了在区块链上实现“价值转移”，通常都支持将现实世界的货币转换为能够在链上流通的虚拟代币。

而在区块链领域，对于一些基于以太坊的架构而衍生出的区块链项目(比如蚂蚁区块链)，通常不再支持将现实世界的货币转换为能够在链上流通的虚拟代币的功能；取而代之的是，在这些区块链项目中，可以将现实世界中的一些非货币属性的实体资产，转化成为能够在区块链上流通的虚拟资产。

其中，需要说明的是，将现实世界中的非货币属性的实体资产转化为区块链上的虚拟资产，通常是指将该实体资产与区块链上的虚拟资产进行“锚定”，作为这些虚拟资产的价值支撑，进而在区块链上产生与实体资产的价值匹配，且能够在区块链上的区块链账户之间进行流通的虚拟资产的过程。

在实现时，可以对区块链支持的账户类型进行扩展，在区块链支持的账户类型的基础上，再扩展出一种资产账户(也称之为资产对象)；比如，可以在以太坊支持的外部账户、合约账户的基础上，再扩展出一种资产账户；扩展出的该资产账户，即为可以将现实世界中的非货币属性的实体资产作为价值支撑，且可以在区块链账户之间流通的虚拟资产。

对于接入这类区块链的用户而言，除了可以在区块链上完成用户账户、智能合约的创建以外，在区块链上创建一笔与现实世界的非货币属性的实体资产价值匹配的虚拟资产，在区块链上进行流通；

例如，用户可以将持有的房产、股票、贷款合同、票据、应收账款等非货币属性的实体资产，转换为价值匹配的虚拟资产在区块链上流通。

其中，对于上述资产账户而言，具体也可以通过一个结构体，来维护账户的账户状态。上述资产账户的结构体所包含的内容，可以与以太坊相同，当然也可以基于实际的需求进行设计；

在一种实现方式中，以上述资产账户的结构体所包含的内容与以太坊相同为例，上述资产账户的结构体也可以包括以上描述的Balance，Nonce，Code和Storage等字段。

需要说明的是，在以太坊中，Balance字段通常用于维护账户目前的账户余额；而对于基于以太坊的架构而衍生出的区块链项目而言，由于其可能并不支持将现实世界的货币转换为能够在链上流通的虚拟代币，因此在这类区块链中，可以对Balance字段的含义进行扩展，不再表示账户的“余额”，而是用于维护账户持有的“虚拟资产”对应的资产账户的地址信息。其中，在实际应用中，Balance字段中可以维护多笔“虚拟资产”对应的资产账户的地址信息。

在这种情况下，以上示出的外部账户、合约账户和资产账户，均可以通过在Balance字段中添加需要持有的“虚拟资产”对应的资产账户的地址信息，来持有这笔虚拟资产。即除了外部账户和合约账户以外，资产账户本身也可以持有虚拟资产。

对于资产账户而言，Nonce，Code字段的字段值可以为空值(也可以不为空)；而Storage字段的字段值可以不再是空值；Storage字段可以用于维护与该资产账户对应的“虚拟资产”的资产状态。其中，在Storage字段中维护与该资产账户对应的“虚拟资产”的资产状态的具体方式，可以基于需求灵活的进行设计，不再赘述。

在基于以太坊的架构而衍生出的区块链项目中，用户可以通过以下示出的实现方式，在区块链上创建一笔与现实世界的非货币属性的实体资产价值匹配的虚拟资产：

在一种实现方式中，可以对区块链支持的交易类型进行扩展，扩展出一种用于创建虚拟资产的交易；比如，以太坊支持的交易类型通常包括普通的转账交易、创建智能合约的交易和调用智能合约的交易，则可以在以上三种类型的交易的基础上，再扩展出一种用于创建虚拟资产的交易。

在这种情况下，用户可以通过客户端向区块链网络中发布一笔用于创建虚拟资产的交易，由区块链中的节点设备在本地的EVM中执行这笔交易，来为该用户创建虚拟资产。当各节点设备通过共识机制达成一致后，这笔虚拟资产成功创建，区块链上出现一个与这笔虚拟资产对应的资产账户，并拥有一个特定的地址。

在另一种实现方式中，也可以在区块链上部署用于创建虚拟资产的智能合约；其中，部署用于创建虚拟资产的智能合约的过程不再赘述。

在这种情况下，用户可以通过客户端向区块链网络中发布一笔用于调用该智能合约的交易，由区块链中的节点设备在本地的EVM中执行这笔交易，并在EVM中运行智能合约相关的合约代码，来为该用户创建虚拟资产。当各节点设备通过共识机制达成一致后，这笔虚拟资产成功创建，区块链上出现一个与这笔虚拟资产对应的资产账户，并拥有一个特定的地址。

当然，对于一些基于以太坊的架构而衍生出的区块链项目，如果其也支持将现实世界的货币转换为能够在链上流通的虚拟代币的功能，那么仍然可以将现实世界中的一些非货币属性的实体资产，转化成为能够在区块链上流通的虚拟代币的形式，在区块链上流通，在本说明书中不再赘述。

在跨链场景下，多个区块链可以通过跨链中继实现跨链对接。

其中，跨链中继，可以通过桥接接口与多个区块链分别进行对接，并基于实现的数据搬运逻辑，完成该多个区块链之间的跨链数据同步。

在实现上述跨链中继时所采用的跨链技术，在本说明书中不进行特别限定；例如，在实际应用中，可以通过侧链技术、公证人技术等跨链机制，将多个区块链连接起来。

当多个区块链通过跨链中继实现对接之后，区块链之间就可以去读取并认证其它区块链上的数据，也可以通过跨链中继去调用其它区块链上部署的智能合约。

区块链上部署的智能合约，除了可以使用区块链上存证的数据以外，也可以通过Oracle预言机，来引用链外的数据实体上的数据，进而实现智能合约与真实世界的数据实体之间的数据交互。链外的数据实体，可以包括诸如部署在链外的中心化的服务器或者数据中心，等等。

其中，与跨链中继不同的是，Oracle预言机的功能并不是将一个区块链上的数据同步到另一个区块链上，而是将链外的数据实体上的数据同步到区块链上；

也即，跨链中继用于连接两个区块链，而Oracle预言机用于连接区块链与链外的数据实体，实现区块链与真实世界的数据交互。

本说明书旨在提供一种对区块链中存证的电子票据进行报销处理，并维护该电子票据的报销状态的技术方案。

在具体实现时，上述区块链中的节点设备在监听到由报销发起方发布至该区块链的针对目标电子票据的报销交易时，可以先确定维护的该目标电子票据是否为未报销状态。

如果该目标电子票据为未报销状态，则可以认为该目标电子票据尚未被报销，从而该区块链中的节点设备可以将该目标电子票据由未报销状态更新为报销锁定状态。此外，在将该目标电子票据更新为报销锁定状态之后，该区块链中的节点设备可以指示报销受理方对该目标电子票据进行报销处理。

举例来说，该报销受理方可以订阅该节点设备维护的该目标电子票据的票据状态。在这种情况下，该节点设备可以在将该目标电子票据更新为报销锁定状态之后，将该目标电子票据的报销锁定状态推送至该报销受理方，以触发该报销受理方对该目标电子票据进行报销处理。

后续，该区块链中的节点设备可以确定是否监听到该报销受理方发布至该区块链的与该目标电子票据对应的报销结果。

如果监听到该报销结果，则可以认为该报销受理方对该目标电子票据的报销处理已经完成，从而该区块链中的节点设备可以将维护的该目标电子票据由报销锁定状态更新为已报销状态。

另一方面，如果该目标电子票据为报销锁定状态，则可以认为对该目标电子票据的报销处理正在进行中。在这种情况下，为了避免重复报销，该区块链中的节点设备可以不再对该报销交易进行后续处理，即无需指示该报销受理方对该目标电子票据进行报销处理。此外，该区块链中的节点设备还可以通知该报销发起方该目标电子票据报销失败。

在上述技术方案中，可以在监听到由报销发起方发布至区块链的针对未报销状态的电子票据的报销交易时，将维护的该电子票据更新为报销锁定状态，而在将该电子票据更新为报销锁定状态之后，可以进一步指示报销受理方对该电子票据进行报销处理。后续，如果监听到该报销受理方发布至该区块链的与该电子票据对应的报销结果，则可以将维护该电子票据更新为已报销状态。采用这样的方式，即可实现对区块链中存证的电子票据的报销处理；此外，由于可以不对针对报销锁定状态或已报销状态的电子票据的报销交易进行后续处理，因此可以避免对电子票据的重复报销。

请参考图6，图6是本说明书一示例性实施例示出的一种基于区块链的电子票据报销系统的示意图。

在如图6所示的基于区块链的电子票据报销系统中，电子票据可以在该区块链中进行存证。

举例来说，针对某笔账单，该账单的收款方可以在确认已经收到付款之后，向该账单的付款方开具与该账单对应的电子票据，并将该电子票据发布至区块链进行存证。

针对该区块链中存证的某张电子票据，报销发起方可以向报销受理方发起针对该电子票据的报销请求，以由报销受理方对该电子票据进行报销处理。

举例来说，与该电子票据对应的账单(例如：医疗账单)的付款方可以作为报销发起方，向作为报销受理方的该付款方所属机构(例如：医疗保险机构)发起针对该电子票据的报销请求，以由该报销受理方将该电子票据上记载的金额支付给该报销发起方，从而实现对该电子票据的报销处理。

具体地，该报销发起方可以直接构造针对该电子票据的报销交易，并将该报销交易发布至该区块链进行存证，以触发该报销受理方对该区块链中存证的该电子票据进行报销处理。

或者，该报销发起方可以向该报销受理方发送针对该电子票据的报销请求，该报销受理方在接收到该报销请求时，可以基于该报销请求，构造针对该电子票据的报销交易，并将该报销交易发布至该区块链进行存证，以进一步触发该报销受理方对该区块链中存证的该电子票据进行报销处理。

需要说明的是，上述区块链中的每台节点设备都可以维护该区块链中存证的每张电子票据的票据状态。由于电子票据的票据状态可能会发生变化，而区块链中存证的数据通常无法被修改，因此该区块链中的每台节点设备维护的每张电子票据的票据状态都是存储在该节点设备本地的，而不会被发布至该区块链进行存证。

请参见图7，图7是本说明书一示例性实施例示出的一种电子票据的票据状态更新流程的示意图。

如图7所示，在开票方开具电子票据之后，可以将该电子票据发布至区块链进行存证，此时该电子票据为未报销状态。当用票单位等票据相关方(称为报销发起方)发起对该电子票据进行报销处理时，可以将该电子票据由未报销状态更新为报销锁定状态，以防止其他用票单位对该电子票据进行报销处理，从而避免出现重复报销的问题。当完成针对该电子票据的报销处理(例如：将该电子票据上记载的金额转账至用票单位的指定账户)时，可以将该电子票据由报销锁定状态更新为已报销状态。当完成针对该电子票据的入账处理(例如：由开票方或受票方将该电子票据上记载的付款方、收款方以及金额重新记载在账本上)时，可以将该电子票据由已报销状态更新为已入账状态。

在实际应用中，也可以不对电子票据进行报销处理，而直接对该电子票据进行入账处理，此时可以将该电子票据由未报销状态更新为已入账状态。

在将该电子票据更新为报销锁定状态之后，如果在一段时间内未监听到发布至该区块链的与该电子票据对应的报销结果，则可以将该电子票据由报销锁定状态更新为未报销状态(即图中的“过期”过程)。类似的，如果该电子票据未通过报销校验，则可以将该电子票据由报销锁定状态更新为未报销状态(即图中的“解除报销”过程)。

除了对处于未报销状态的电子票据进行报销处理之外，还可以对该电子票据进行冲红、打印(例如：使用财政空白票打印)、作废等处理，此时可以将该电子票据相应更新为已开红票状态、已打印状态、已作废状态。

在实际应用中，可以将未报销状态、报销锁定状态、已报销状态、已入账状态视为电子票据的有效状态；而将已开红票状态、已打印状态、已作废状态视为电子票据的失效状态。对于处于失效状态的电子票据而言，无法对该电子票据执行任何操作。

另一方面，上述票据相关方可以向上述区块链中的节点设备发送票据状态订阅请求，例如：可以通过与该节点设备对接的客户端向该节点设备发送票据状态订阅请求，以实现对该节点设备维护的电子票据的票据状态的订阅。

在票据相关方订阅了上述区块链中的节点设备维护的某张电子票据的票据状态之后，如果该电子票据的票据状态发生更新，则该节点设备可以主动向该票据相关方推送该电子票据的更新后的票据状态。

请参考图8，图8是本说明书一示例性实施例示出的一种基于区块链的电子票据报销方法的流程图。该方法可以应用于图6所示的基于区块链的电子票据报销系统中作为节点设备加入至该区块链的电子设备；其中，该电子设备可以是服务器、计算机、手机、平板设备、笔记本电脑或掌上电脑(PDAs，Personal Digital Assistants)等，本说明书对此不作限制。该方法可以包括以下步骤：

步骤802，在监听到由报销发起方发布至所述区块链的针对目标电子票据的报销交易时，确定维护的所述目标电子票据是否为未报销状态；

步骤804，如果所述目标电子票据为未报销状态，则将所述目标电子票据由未报销状态更新为报销锁定状态，并在将所述目标电子票据更新为报销锁定状态之后，指示报销受理方对所述目标电子票据进行报销处理；

步骤806，确定是否监听到所述报销受理方发布至所述区块链的与所述目标电子票据对应的报销结果；

步骤808，如果监听到所述报销结果，则将所述目标电子票据由报销锁定状态更新为已报销状态。

以下以采用MPT树的数据结构，将区块链中的账户状态数据组织成MPT状态树为例，对本说明书的技术方案进行详细描述；

其中，需要强调的是，以采用MPT树的数据结构来组织区块链中的账户状态数据，仅为示例性的。

在实际应用中，对于基于以太坊架构而衍生出的区块链项目，除了可以采用诸如MPT树等改良版的Merkle树以外，也可以采用类似于MPT树的融合了Trie字典树的Merkle树变种，在本说明书中不再进行一一列举。

针对上述区块链中存证的某张电子票据(称为目标电子票据)，如果报销发起方需要向报销受理方报销该目标电子票据，则该报销发起方可以直接构造针对该目标电子票据的报销交易，并将该报销交易发布至该区块链进行存证；或者，该报销发起方可以向该报销受理方发送针对该目标电子票据的报销请求，以由该报销受理方基于该报销请求构造针对该电子票据的报销交易，并将该报销交易发布至该区块链进行存证。其中，将该报销交易发布至该区块链进行存证的流程，可以参考前述将物理世界产生的真实数据在区块链中进行持久化存证的流程，本说明书在此不再赘述。

该区块链中的节点设备可以对在该区块链中存证的数据进行监听，从而可以监听到上述报销交易。该区块链中的节点设备在监听到该报销交易时，可以先确定维护的该目标电子票据是否为未报销状态。

在实际应用中，针对上述区块链中存证的某张电子票据，该区块链中的节点设备可以通过维护该电子票据的标识(例如：电子票据号码)与状态的对应关系，实现维护该电子票据的票据状态。

在这种情况下，该报销交易中的数据可以包括该目标电子票据的标识。该区块链中的节点设备在监听到该报销交易时，可以基于该报销交易中的该目标电子票据的标识，在维护的电子票据的标识与状态的对应关系中，查找到与该目标电子票据的标识对应的票据状态，作为该目标电子票据的票据状态。

举例来说，该区块链中的每台节点设备维护的该区块链中存证的每张电子票据的票据状态可以如下表1所示：

电子票据	状态
		电子票据1	报销锁定
电子票据2	已报销
		电子票据3	未报销
……	……

表1

如表1所示，该区块链中的节点设备在监听到报销发起方1针对电子票据1的报销交易1时，可以确定电子票据1为报销锁定状态；该区块链中的节点设备在监听到报销发起方2针对电子票据2的报销交易2时，可以确定电子票据2为已报销状态；该区块链中的节点设备在监听到报销发起方3针对电子票据3的报销交易3时，可以确定电子票据3为未报销状态。

如果上述区块链中的节点设备确定上述目标电子票据为未报销状态，则可以认为尚未对该目标电子票据进行报销处理，因此该区块链中的节点设备可以将维护的该目标电子票据由未报销状态更新为报销锁定状态。

需要说明的是，由于该区块链中的每台节点设备都可以监听到上述报销交易，因此该区块链中的每台节点设备都可以在确定该目标电子票据为未报销状态时，将其维护的该目标电子票据由未报销状态更新为报销锁定状态。

对于报销锁定状态的电子票据而言，可以认为正在对该电子票据进行报销处理，因此该区块链中的节点设备在监听到针对该电子票据的报销交易时，可以不再处理该报销交易，以避免重复报销。此外，该区块链中的节点设备可以向该报销发起方发送用于指示该目标电子票据报销失败的通知消息，以通知该报销发起方对该电子票据的报销处理正在进行中。

对于已报销状态的电子票据而言，可以认为已经完成对该电子票据的报销处理，因此该区块链中的节点设备在监听到针对该电子票据的报销交易时，也可以不再处理该报销交易，而可以向该报销发起方发送通知消息，以通知该报销发起方对该电子票据的报销处理已经完成。

继续以表1为例，该区块链中的节点设备在监听到报销发起方1针对电子票据1的报销交易1时，由于可以确定电子票据1为报销锁定状态，因此该区块链中的节点设备可以不再处理报销交易1，而可以向报销发起方1发送用于指示电子票据1报销失败的通知消息，以通知报销发起方1对电子票据1的报销处理正在进行中。

该区块链中的节点设备在监听到报销发起方2针对电子票据2的报销交易2时，由于可以确定电子票据2为已报销状态，因此该区块链中的节点设备可以不再处理报销交易2，而可以向报销发起方2发送通知消息，以通知报销发起方2对电子票据2的报销处理已经完成。

该区块链中的节点设备在监听到报销发起方3针对电子票据3的报销交易3时，由于可以确定电子票据3为未报销状态，因此该区块链中的节点设备可以将电子票据3由未报销状态更新为报销锁定状态。

在实际应用中，由于该区块链中的每台节点设备都可以监听到报销交易3，因此该区块链中的每台节点设备都可以将其维护的该区块链中存证的每张电子票据的票据状态更新为如下表2所示：

电子票据	状态
		电子票据1	报销锁定
电子票据2	已报销
		电子票据3	报销锁定
……	……

表2

进一步地，上述区块链中的节点设备在将上述目标电子票据更新为报销锁定状态之后，可以指示上述报销受理方对该目标电子票据进行报销处理。

具体地，该报销受理方可以向该区块链中的节点设备订阅其维护的该目标电子票据的票据状态。在这种情况下，该节点设备在将该目标电子票据更新为报销锁定状态之后，可以将该目标电子票据的报销锁定状态推送至订阅了该目标电子票据的票据状态的该报销受理方，以触发该报销受理方对处于报销锁定状态的该目标电子票据进行报销处理，即该报销受理方可以在接收到该节点设备推送的该目标电子票据的报销锁定状态之后，对该目标电子票据进行报销处理，例如：该报销受理方可以通过与该节点设备对接的客户端接收到该节点设备推送的该目标电子票据的报销锁定状态，并通过该客户端对该目标电子票据进行报销处理。

或者，该节点设备在将该目标电子票据更新为报销锁定状态之后，可以直接向该报销受理方发送用于指示对该目标电子票据进行报销处理的通知消息，以通知该报销受理方可以对该目标电子票据进行报销处理，即该报销受理方可以在接收到该节点设备发送的该通知消息之后，对该目标电子票据进行报销处理。

在示出的一种实施方式中，上述区块链中的节点设备在监听到上述报销交易时，可以先确定上述目标电子票据是否符合报销条件。如果该目标电子票据符合报销条件，再进一步确定维护的该目标电子票据是否为未报销状态。

如果该目标电子票据符合报销条件，则可以进一步确定维护的该目标电子票据是否为未报销状态。相应地，如果该目标电子票据不符合报销条件，则可以不再执行后续操作。这样，可以避免对不符合报销条件的电子票据进行后续的报销处理，从而可以提高电子票据报销的效率和安全性。

具体地，在将该报销交易发布至该区块链进行存证时，该区块链中的节点设备可以接收到该报销交易，并对该报销交易进行共识处理。在达成共识后，该区块链中的节点设备可以将该报销交易打包进区块，在该区块链中进行持久化存证。

对于打包进区块的该报销交易，该区块链中的节点设备可以执行该报销交易，即响应于该报销交易，调用部署在该区块链上的智能合约中声明的报销校验逻辑，对该目标电子票据进行报销校验，即确定该目标电子票据是否符合报销条件。

其中，报销校验逻辑具体可以是声明在该智能合约中的，与对电子票据进行报销校验的执行逻辑相关的程序代码(例如：一些可供调用的程序方法或者函数)；创建和调用该智能合约的流程可以参考前述智能合约的创建和调用流程，本说明书在此不再赘述。

如果该目标电子票据符合报销条件，即对该目标电子票据的报销校验通过，则可以由该智能合约生成与该目标电子票据对应的校验通过事件。该节点设备在监听到该校验通过事件时，即可进一步确定维护的该目标电子票据是否为未报销状态，从而可以在该目标电子票据为未报销状态时，将该目标电子票据由未报销状态更新为报销锁定状态，并在将该目标电子票据更新为报销锁定状态之后，指示报销受理方对该目标电子票据进行报销处理。

在实际应用中，该智能合约在生成该校验通过事件之后，可以将该校验通过事件存储至与该报销交易对应的交易日志。该节点设备可以进行日志监听，从而可以监听到与该报销交易对应的交易日志中存储的该校验通过事件。该节点设备在监听到该校验通过事件时，即可进一步确定维护的该目标电子票据是否为未报销状态。

在示出的一种实施方式中，针对电子票据的报销条件可以包括：报销权限条件、报销额度条件以及报销期限条件等维度。

其中，针对上述目标电子票据的报销权限条件可以是上述报销发起方(即发起针对该目标电子票据的报销处理的用户)具有该目标电子票据的报销权限，例如：该报销发起方是否为该目标电子票据上记载的付款方；或者，该报销发起方是否属于该报销受理方的员工。

举例来说，上述报销交易中的数据可以包括该报销发起方的用户标识(例如：纳税人识别号)。该区块链中的节点设备可以先确定该目标电子票据上记载的付款方的用户标识，再比较这两个用户标识是否一致。如果这两个用户标识一致，则该区块链中的节点设备可以确定该报销发起方为该目标电子票据上记载的付款方，从而可以确定该目标电子票据符合报销权限条件。

针对上述目标电子票据的报销额度条件可以是该目标电子票据上记载的金额小于上述报销发起方的剩余报销额度。

举例来说，该区块链中的节点设备可以在本地维护该报销发起方的剩余报销额度，假设该报销发起方的剩余报销额度为10000。在这种情况下，该区块链中的节点设备可以确定该目标电子票据上记载的金额是否小于该报销发起方的剩余报销额度。假设该目标电子票据上记载的金额为1000，小于维护的报销发起方的剩余报销额度，因此该区块链中的节点设备可以确定该目标电子票据符合报销额度条件。此外，该区块链中的节点设备可以将维护的该报销发起方的剩余报销额度更新为9000，用于后续的报销额度校验。

针对上述目标电子票据的报销期限条件可以是该目标电子票据上记载的开票时刻与监听到上述报销交易的时刻之间的时间间隔小于允许报销的时间间隔。其中，该允许报销的时间间隔可以由票据管理方预先设置。

举例来说，该区块链中的节点设备可以在本地维护预先设置的允许报销的时间间隔，假设该允许报销的时间间隔为72小时。在这种情况下，该区块链中的节点设备可以确定该目标电子票据上记载的开票时刻与监听到该报销交易的时刻之间的时间间隔是否小于该允许报销的时间间隔。假设该目标电子票据上记载的开票时刻为5月31日15点整，该区块链中的节点设备监听到该报销交易的时刻为6月1日20点整，两者之间的时间间隔为29小时，小于该允许报销的时间间隔，因此该区块链中的节点设备可以确定该目标电子票据符合报销期限条件。

另一方面，上述报销受理方在完成对上述目标电子票据的报销处理后，可以将与该目标电子票据对应的报销结果发布至上述区块链进行存证。其中，将该报销结果发布至该区块链进行存证的流程，可以参考前述将物理世界产生的真实数据在区块链中进行持久化存证的流程，本说明书在此不再赘述。

由于该区块链中的节点设备可以对在该区块链中存证的数据进行监听，因此该区块链中的节点设备可以确定是否监听到上述报销结果。

如果该区块链中的节点设备监听到该报销结果，则可以认为对该目标电子票据的报销处理已经完成，从而可以将维护的该目标电子票据由报销锁定状态更新为已报销状态。

然而，如果该区块链中的节点设备在预设时长内未监听到该报销结果，则可以认为对该目标电子票据的报销处理失败，从而可以将维护的该目标电子票据由报销锁定状态重新恢复为未报销状态。其中，预设时长可以由技术人员预先设置，也可以是系统默认的缺省值，本说明书对此不作限制。

在实际应用中，上述报销结果中的数据可以包括上述目标电子票据的标识，该区块链中的节点设备在监听到该报销结果时，可以基于该报销结果中的该目标电子票据的标识，将维护的电子票据的标识与状态的对应关系中，与该目标电子票据的标识对应的票据状态由报销锁定状态更新为已报销状态。

然而，如果该区块链中的节点设备在预设时长内，并未监听到其中的电子票据标识为该目标电子票据的标识的报销结果，则可以将维护的电子票据的标识与状态的对应关系中，与该目标电子票据的标识对应的票据状态由报销锁定状态重新恢复为未报销状态。

继续以表1为例，该区块链中的节点设备在监听到报销发起方3针对电子票据3的报销交易3时，可以将维护的电子票据3由未报销状态更新为报销锁定状态。该区块链中的节点设备在将电子票据3更新为报销锁定状态后，可以指示与电子票据3对应的报销受理方3对电子票据3进行报销处理。

报销受理方3在完成对电子票据3的报销处理后，可以将与电子票据3对应的报销结果3发布至该区块链进行存证。

在实际应用中，由于该区块链中的每台节点设备都可以监听到报销结果3，因此该区块链中的每台节点设备都可以将其维护的该区块链中存证的每张电子票据的票据状态更新为如下表3所示：

电子票据	状态
		电子票据1	报销锁定
电子票据2	已报销
		电子票据3	已报销
……	……

表3

即该区块链中的每台节点设备都可以将维护的电子票据3由报销锁定状态更新为已报销状态。

继续以表1为例，该区块链中的节点设备在将电子票据1更新为报销锁定状态后，可以指示与电子票据1对应的报销受理方1对电子票据1进行报销处理。

假设报销受理方1对电子票据1的报销处理失败，则在这种情况下，报销受理方1不会将与电子票据1对应的报销结果发布至该区块链。

在实际应用中，由于该区块链中的每台节点设备都无法在预设时长内监听到与电子票据1对应的报销结果，因此该区块链中的每台节点设备都可以将其维护的该区块链中存证的每张电子票据的票据状态更新为如下表4所示：

电子票据	状态
		电子票据1	未报销
电子票据2	已报销
		电子票据3	已报销
……	……

表4

即该区块链中的每台节点设备都可以将维护的电子票据1由报销锁定状态重新恢复为未报销状态。

在上述技术方案中，可以在监听到由报销发起方发布至区块链的针对未报销状态的电子票据的报销交易时，将维护的该电子票据更新为报销锁定状态，而在将该电子票据更新为报销锁定状态之后，可以进一步指示报销受理方对该电子票据进行报销处理。后续，如果监听到该报销受理方发布至该区块链的与该电子票据对应的报销结果，则可以将维护该电子票据更新为已报销状态。采用这样的方式，即可实现对区块链中存证的电子票据的报销处理；此外，由于可以不对针对报销锁定状态或已报销状态的电子票据的报销交易进行后续处理，因此可以避免对电子票据的重复报销。

与前述基于区块链的电子票据报销方法的实施例相对应，本说明书还提供了基于区块链的电子票据报销装置的实施例。

本说明书基于区块链的电子票据报销装置的实施例可以应用在电子设备上。装置实施例可以通过软件实现，也可以通过硬件或者软硬件结合的方式实现。以软件实现为例，作为一个逻辑意义上的装置，是通过其所在电子设备的处理器将非易失性存储器中对应的计算机程序指令读取到内存中运行形成的。

从硬件层面而言，如图9所示，为本说明书基于区块链的电子票据报销装置所在电子设备的一种硬件结构图，除了图9所示的处理器、内存、网络接口、以及非易失性存储器之外，实施例中装置所在的电子设备通常根据该基于区块链的电子票据报销的实际功能，还可以包括其他硬件，对此不再赘述。

请参考图10，图10是本说明书一示例性实施例示出的一种基于区块链的电子票据报销装置的框图。所述装置100可以应用于图9所示的电子设备，所述电子设备可以作为节点设备加入至所述区块链；所述区块链中存证了电子票据；所述装置100可以包括：

确定模块1001，用于在监听到由报销发起方发布至所述区块链的针对目标电子票据的报销交易时，确定维护的所述目标电子票据是否为未报销状态；

第一更新模块1002，用于在所述目标电子票据为未报销状态时，将所述目标电子票据由未报销状态更新为报销锁定状态，并在将所述目标电子票据更新为报销锁定状态之后，指示报销受理方对所述目标电子票据进行报销处理；

监听模块1003，用于确定是否监听到所述报销受理方发布至所述区块链的与所述目标电子票据对应的报销结果；

第二更新模块1004，用于在监听到所述报销结果时，将所述目标电子票据由报销锁定状态更新为已报销状态。

在本实施例中，所述确定模块1001具体可以用于：

响应于所述报销交易，调用部署在所述区块链上的智能合约中声明的报销校验逻辑，对所述报销发起方进行报销校验；

响应于监听到的由所述智能合约生成的与所述报销发起方对应的校验通过事件，进一步确定维护的所述目标电子票据是否为未报销状态。

在本实施例中，所述报销条件可以包括：报销权限条件；报销额度条件；报销期限条件。

在本实施例中，所述报销受理方订阅了所述节点设备维护的所述目标电子票据的票据状态；

所述第一更新模块1002具体可以用于：

在将所述目标电子票据更新为报销锁定状态之后，将所述目标电子票据的报销锁定状态推送至所述报销受理方，以触发所述报销受理方对处于报销锁定状态的所述目标电子票据进行报销处理。

在本实施例中，所述装置100还可以包括：

第三更新模块1005，用于在预设时长内未监听到所述报销结果时，将所述目标电子票据由报销锁定状态更新为未报销状态。

在本实施例中，所述装置100还可以包括：

发送模块1006，用于在所述目标电子票据为报销锁定状态时，向所述报销发起方发送用于指示所述目标电子票据报销失败的通知消息。

上述装置中各个模块的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。

对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块显示的部件可以是或者也可以不是物理模块，即可以位于一个地方，或者也可以分布到多个网络模块上。可以根据实际的需要选择其中的部分或者全部模块来实现本说明书方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机，计算机的具体形式可以是个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件收发设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任意几种设备的组合。

在一个典型的配置中，计算机包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带、磁盘存储、量子存储器、基于石墨烯的存储介质或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

在本说明书一个或多个实施例使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本说明书一个或多个实施例。在本说明书一个或多个实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本说明书一个或多个实施例可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本说明书一个或多个实施例范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

以上所述仅为本说明书一个或多个实施例的较佳实施例而已，并不用以限制本说明书一个或多个实施例，凡在本说明书一个或多个实施例的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本说明书一个或多个实施例保护的范围之内。

Claims (14)

1.一种基于区块链的电子票据报销方法，所述方法应用于所述区块链中的节点设备；所述区块链中存证了电子票据；所述方法包括：

在监听到由报销发起方发布至所述区块链的针对目标电子票据的报销交易时，确定维护的所述目标电子票据是否为未报销状态；

如果所述目标电子票据为未报销状态，则将所述目标电子票据由未报销状态更新为报销锁定状态，并在将所述目标电子票据更新为报销锁定状态之后，指示报销受理方对所述目标电子票据进行报销处理；

确定是否监听到所述报销受理方发布至所述区块链的与所述目标电子票据对应的报销结果；

如果监听到所述报销结果，则将所述目标电子票据由报销锁定状态更新为已报销状态。

2.根据权利要求1所述的方法，所述在监听到由报销发起方发布至所述区块链的针对目标电子票据的报销交易时，确定维护的所述目标电子票据是否为未报销状态，包括：

响应于所述报销交易，调用部署在所述区块链上的智能合约中声明的报销校验逻辑，确定所述目标电子票据是否符合报销条件；

响应于监听到的由所述智能合约生成的与所述目标电子票据对应的校验通过事件，进一步确定维护的所述目标电子票据是否为未报销状态。

3.根据权利要求2所述的方法，所述报销条件包括：报销权限条件；报销额度条件；报销期限条件。

4.根据权利要求1所述的方法，所述报销受理方订阅了所述节点设备维护的所述目标电子票据的票据状态；

所述在将所述目标电子票据更新为报销锁定状态之后，指示报销受理方对所述目标电子票据进行报销处理，包括：

在将所述目标电子票据更新为报销锁定状态之后，将所述目标电子票据的报销锁定状态推送至所述报销受理方，以触发所述报销受理方对处于报销锁定状态的所述目标电子票据进行报销处理。

5.根据权利要求1所述的方法，所述方法还包括：

如果在预设时长内未监听到所述报销结果，则将所述目标电子票据由报销锁定状态更新为未报销状态。

6.根据权利要求1所述的方法，所述方法还包括：

如果所述目标电子票据为报销锁定状态，则向所述报销发起方发送用于指示所述目标电子票据报销失败的通知消息。

7.一种基于区块链的电子票据报销装置，所述装置应用于所述区块链中的节点设备；所述区块链中存证了电子票据；所述装置包括：

确定模块，用于在监听到由报销发起方发布至所述区块链的针对目标电子票据的报销交易时，确定维护的所述目标电子票据是否为未报销状态；

第一更新模块，用于在所述目标电子票据为未报销状态时，将所述目标电子票据由未报销状态更新为报销锁定状态，并在将所述目标电子票据更新为报销锁定状态之后，指示报销受理方对所述目标电子票据进行报销处理；

监听模块，用于确定是否监听到所述报销受理方发布至所述区块链的与所述目标电子票据对应的报销结果；

第二更新模块，用于在监听到所述报销结果时，将所述目标电子票据由报销锁定状态更新为已报销状态。

8.根据权利要求7所述的装置，所述确定模块具体用于：

响应于所述报销交易，调用部署在所述区块链上的智能合约中声明的报销校验逻辑，对所述报销发起方进行报销校验；

响应于监听到的由所述智能合约生成的与所述报销发起方对应的校验通过事件，进一步确定维护的所述目标电子票据是否为未报销状态。

9.根据权利要求8所述的装置，所述报销条件包括：报销权限条件；报销额度条件；报销期限条件。

10.根据权利要求7所述的装置，所述报销受理方订阅了所述节点设备维护的所述目标电子票据的票据状态；

所述第一更新模块具体用于：

在将所述目标电子票据更新为报销锁定状态之后，将所述目标电子票据的报销锁定状态推送至所述报销受理方，以触发所述报销受理方对处于报销锁定状态的所述目标电子票据进行报销处理。

11.根据权利要求7所述的装置，所述装置还包括：

第三更新模块，用于在预设时长内未监听到所述报销结果时，将所述目标电子票据由报销锁定状态更新为未报销状态。

12.根据权利要求7所述的装置，所述装置还包括：

发送模块，用于在所述目标电子票据为报销锁定状态时，向所述报销发起方发送用于指示所述目标电子票据报销失败的通知消息。

13.一种电子设备，包括：

处理器；

用于存储处理器可执行指令的存储器；

其中，所述处理器通过运行所述可执行指令以实现如权利要求1至6中任一项所述方法的步骤。

14.一种计算机可读存储介质，其上存储有计算机指令，其特征在于，该指令被处理器执行时实现如权利要求1至6中任一项所述方法的步骤。