具体实施方式
这里将详细地对示例性实施例进行说明,其示例表示在附图中。下面的描述涉及附图时,除非另有表示,不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本说明书一个或多个实施例相一致的所有实施方式。相反,它们仅是与如所附权利要求书中所详述的、本说明书一个或多个实施例的一些方面相一致的装置和方法的例子。
需要说明的是:在其他实施例中并不一定按照本说明书示出和描述的顺序来执行相应方法的步骤。在一些其他实施例中,其方法所包括的步骤可以比本说明书所描述的更多或更少。此外,本说明书中所描述的单个步骤,在其他实施例中可能被分解为多个步骤进行描述;而本说明书中所描述的多个步骤,在其他实施例中也可能被合并为单个步骤进行描述。
区块链一般被划分为三种类型:公有链(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所示的基于区块链的电子票据管理***中,该区块链可以包括用于维护电子票据号段的多级账户,例如:执收单位账户;市财政局账户(即与该执收单位账户对应的上级账户);省财政厅账户(即与该市财政局账户对应的上级账户)。
在实际应用中,可以由各级账户的账户管理者(例如:执收单位账户的账户管理者为该执收单位;市财政局账户的账户管理者为该市财政局;省财政厅账户的账户管理者为该省财政厅)在该区块链中建立该账户。具体地,该账户管理者可以通过其使用的客户端,在该区块链中进行注册,从而建立该账户。
其中,参考前述对区块链中的账户的说明,该账户可以是该区块链中的外部账户,也可以是该区块链中的合约账户,本说明书对此不作限制;该账户维护的电子票据号段可以存储在该账户的Storage字段中,也可以存储在该账户的Balance字段中,本说明对此不作限制。
对于各级账户而言,参考前述对区块链中账户的说明,可以将与该账户对应的上级账户的账户标识存储至该账户的Storage字段,即后续可以基于该账户的Storage字段,直接确定与该账户对应的上级账户。
其中,账户标识可以是账户地址,即可以将与该账户对应的上级账户的账户地址存储至该账户的Storage字段。或者,账户标识可以是为账户设置的名称或编号等标识信息,此时该账户的标识信息以及与该账户对应的上级账户的标识信息都可以存储至该账户的Storage字段。
请参考图7,图7是本说明书一示例性实施例示出的一种基于区块链的电子票据号码申领方法的流程图。该方法可以应用于图6所示的基于区块链的电子票据管理***中作为节点设备加入至该区块链的电子设备;其中,该电子设备可以是服务器、计算机、手机、平板设备、笔记本电脑或掌上电脑(PDAs,Personal Digital Assistants)等,本说明书对此不作限制。该方法可以包括以下步骤:
步骤702,接收发布至所述区块链的号码申领交易;其中,所述号码申领交易包括号码申领方账户的账户标识;
步骤704,响应于所述号码申领交易,从与所述号码申领方账户对应的上级账户维护的电子票据号段中为所述号码申领方分配电子票据号码;
步骤706,将为所述号码申领方分配的电子票据号码添加至所述号码申领方账户进行维护。
以下以采用MPT树的数据结构,将区块链中的账户状态数据组织成MPT状态树为例,对本说明书的技术方案进行详细描述;
其中,需要强调的是,以采用MPT树的数据结构来组织区块链中的账户状态数据,仅为示例性的。
在实际应用中,对于基于以太坊架构而衍生出的区块链项目,除了可以采用诸如MPT树等改良版的Merkle树以外,也可以采用类似于MPT树的融合了Trie字典树的Merkle树变种,在本说明书中不再进行一一列举。
对于上述区块链中的任意一级账户而言,可以由该账户的账户管理者作为号码申领方,主动从与该号码申领方账户对应的上级账户维护的电子票据号段中申领电子票据号码。
具体地,该账户的账户管理者可以作为号码申领方,主动构建号码申领交易,并将构建的该号码申领交易发布至该区块链进行存证。其中,该号码申领交易可以包括该号码申领方账户(即该账户)的账户标识。
在示出的一种实施方式中,可以由该区块链中的节点设备周期性确定该区块链中的各级账户维护的电子票据号段的数量是否充足。
具体地,可以分别为各级账户设置用于指示该账户维护的电子票据号段的数量是否充足的阈值。如果某级账户维护的电子票据号段的数量小于为该账户设置的阈值,则可以认为该账户维护的电子票据号段的数量不充足;如果该账户维护的电子票据号段的数量大于或等于该阈值,则可以认为该账户维护的电子票据号段的数量充足。
举例来说,假设为某级账户设置的阈值为1000,进一步假设该账户维护的电子票据号段为80001-80900,则由于该账户维护的电子票据号段的数量为899,小于作为阈值的1000,因此可以认为该账户维护的电子票据号段的数量不充足。
在实际应用中,可以为不同的账户设置不同的阈值,也可以为不同的账户设置相同的阈值;或者,也可以为所有账户设置同一个阈值,本说明书对此不作限制。
如果确定任意一级账户(称为目标账户)维护的电子票据号段的数量不充足,则该区块链中的节点设备可以向该目标账户对应的客户端(即该目标账户的账户管理者所使用的客户端)发送告警指示。该客户端在接收到该告警指示时,可以构建上述号码申领交易,并将构建的该号码申领交易发布至该区块链;此外,该客户端也可以通过声光报警或文字输出等方式,提示该目标账户的账户管理者该目标账户当前维护的电子票据号段的数量不充足。
也即,此时该目标账户的账户管理者可以作为号码申领方,主动构建该号码申领交易,并将构建的该号码申领交易发布至该区块链进行存证,以触发后续的从与该目标账户对应的上级账户维护的电子票据号段中为该目标账户分配电子票据的流程。
参考前述将物理世界产生的真实数据在区块链中进行持久化存证的流程,该区块链中的节点设备可以接收到该号码申领交易,进而可以对接收到的该号码申领交易进行共识处理,并在达成共识之后,将该号码申领交易打包进区块,在区块链中进行持久化存证。
对于打包进区块的该号码申领交易,该区块链中的节点设备可以执行该号码申领交易,即响应于该号码申领交易,先基于该号码申领交易中的账户标识确定该号码申领方账户,进而确定与该号码申领方账户对应的上级账户,再从该上级账户维护的电子票据号段中为该号码申领方分配电子票据号码,最后将为该号码申领方分配的电子票据号码添加至该号码申领方账户进行维护。
在示出的一种实施方式中,该号码申领交易可以包括调用智能合约的信息。该区块链中的节点设备可以响应于该号码申领交易,调用部署在该区块链上的智能合约,实现从与该号码申领方账户对应的上级账户维护的电子票据号段中为该号码申领方分配电子票据号码。
其中,创建和调用该智能合约的流程可以参考前述智能合约的创建和调用流程,本说明书在此不再赘述。
在示出的另一种实施方式中,可以将该号码申领交易定义为特定的交易类型,即属于该交易类型的交易可以触发从与发布该交易的用户账户对应的上级账户维护的电子票据号段中为该用户账户分配电子票据。
在这种情况下,该区块链中的节点设备可以响应于该号码申领交易,直接执行后续的从与该号码申领方账户对应的上级账户维护的电子票据号段中为该号码申领方分配电子票据号码的操作。
在实际应用中,该区块链中的节点设备在从与该号码申领方账户对应的上级账户维护的电子票据号段中为该号码申领方分配电子票据号码时,可以先确定与该号码申领方账户对应的上级账户维护的电子票据号段的数量是否充足。
如果该上级账户维护的电子票据号段的数量充足,则该区块链中的节点设备可以直接从该上级账户维护的电子票据号段中为该号码申领方分配电子票据号码。
具体地,可以分别为各级账户设置用于分配电子票据号码的数量。该区块链中的节点设备可以按照特定的电子票据号码分配规则,将该上级账户维护的电子票据号段中数量等于为该上级账户设置的数量的电子票据号码分配给该号码申领方,例如:将该上级账户维护的电子票据号段中排在前列,且数量等于为该上级账户设置的数量的电子票据号码分配给该号码申领方。
如果该上级账户维护的电子票据号段的数量不充足,则该区块链中的节点设备可以进一步从与该上级账户对应的上级账户维护的电子票据号段中为该上级账户分配电子票据号码,再从与该号码申领方账户对应的上级账户维护的电子票据号段中为该号码申领方分配电子票据号码。
为了简化电子票据号码申领的逻辑,在示出的一种实施方式中,如果该上级账户维护的电子票据号段的数量不充足,则该区块链中的节点设备可以向与该上级账户对应的客户端(即该上级账户的账户管理者所使用的客户端)发送告警指示。该客户端在接收到该告警指示时,可以构建上述号码申领交易,并将构建的该号码申领交易发布至该区块链;此外,该客户端也可以通过声光报警或文字输出等方式,提示该上级账户的账户管理者该上级账户当前维护的电子票据号段的数量不充足。
也即,此时该上级账户的账户管理者可以作为号码申领方,主动构建该号码申领交易,并将构建的该号码申领交易发布至该区块链进行存证,以触发后续的从与该上级账户对应的上级账户维护的电子票据号段中为该上级账户分配电子票据的流程。
或者,可以由上述智能合约生成该上级账户维护的电子票据号段的数量不充足的事件信息,并将该事件信息发布至该区块链进行存证。该上级账户对应的客户端可以对该区块链中存证的数据进行监听,从而可以监听到该事件信息。该客户端在监听到该事件信息时,可以构建上述号码申领交易,并将构建的该号码申领交易发布至该区块链,以触发后续的从与该上级账户对应的上级账户维护的电子票据号段中为该上级账户分配电子票据的流程。
在为上述号码申领方分配了电子票据号码之后,即可将为该号码申领方分配的电子票据号码添加至该号码申领方账户进行维护。
下面通过举例对图7所示的实施例进行描述。
假设上述区块链包括:执收单位A账户、市财政局A账户(即与执收单位A账户对应的上级账户)、省财政厅A账户(即与市财政局A账户对应的上级账户)。
在一个例子中,假设为执收单位A账户设置的用于指示账户维护的电子票据号段的数量是否充足的阈值为1000,则该区块链中的节点设备可以确定执收单位A账户当前维护的电子票据号段为70101-70900,数量为799,小于作为阈值的1000,因此该区块链中的节点设备可以向执收单位A账户对应的客户端发送告警指示,以指示该客户端构建号码申领交易,并将该号码申领交易发布至该区块链进行存证。
对于打包进区块的该号码申领交易,该区块链中的节点设备可以响应于该号码申领交易,调用部署在该区块链上的智能合约中声明的号码申领逻辑,确定市财政局A账户维护的电子票据号段的数量是否充足。
其中,号码申领逻辑具体可以是声明在该智能合约中的,与申领电子票据号码的执行逻辑相关的程序代码(例如:一些可供调用的程序方法或者函数)。
假设为市财政局A账户设置的用于指示账户维护的电子票据号段的数量是否充足的阈值为2000,则该区块链中的节点设备可以确定市财政局A账户当前维护的电子票据号段为71001-79999,数量为8999,大于作为阈值的2000,因此该区块链中的节点设备可以进一步调用部署在该区块链上的智能合约中声明的号码分配逻辑,从市财政局A账户当前维护的电子票据号段中为执收单位A分配电子票据号码。
其中,号码分配逻辑具体可以是声明在该智能合约中的,与分配电子票据号码的执行逻辑相关的程序代码(例如:一些可供调用的程序方法或者函数)。
需要说明的是,以上描述的用于进行电子票据号码申领的智能合约,和用于进行电子票据号码分配的智能合约,可以整合为一个智能合约在上述区块链上进行部署,也可以作为两个不同的智能合约在该区块链上进行部署,本说明书对此不作限定。
假设为市财政局A账户设置的用于分配电子票据号码的数量为2000,该号码分配逻辑为将账户维护的电子票据号段中排在前列,且数量等于为该账户设置的数量的电子票据号码分配给号码申领方,则该区块链中的节点设备可以将71001-73000分配给执收单位A,并将为执收单位A分配的电子票据号码添加至执收单位A账户进行维护,即后续执收单位A账户维护的电子票据号段为70101-70900和71001-73000。
在另一个例子中,假设为执收单位B账户设置的用于指示账户维护的电子票据号段的数量是否充足的阈值为1000,则该区块链中的节点设备可以确定执收单位B账户当前维护的电子票据号段为80101-80900,数量为799,小于作为阈值的1000,因此该区块链中的节点设备可以向执收单位B账户对应的客户端发送告警指示,以指示该客户端构建号码申领交易,并将该号码申领交易发布至该区块链进行存证。
对于打包进区块的该号码申领交易,该区块链中的节点设备可以响应于该号码申领交易,调用上述号码申领逻辑,确定市财政局B账户维护的电子票据号段的数量是否充足。
假设为市财政局B账户设置的用于指示账户维护的电子票据号段的数量是否充足的阈值为2000,则该区块链中的节点设备可以确定市财政局B账户当前维护的电子票据号段为88001-89999,数量为1999,小于作为阈值的2000,因此该区块链中的节点设备可以向市财政局B账户对应的客户端发送告警指示,以指示该客户端构建号码申领交易,并将该号码申领交易发布至该区块链进行存证。
对于打包进区块的该号码申领交易,该区块链中的节点设备可以响应于该号码申领交易,调用上述号码申领逻辑,确定省财政厅A账户维护的电子票据号段的数量是否充足。
假设为省财政厅A账户设置的用于指示账户维护的电子票据号段的数量是否充足的阈值为5000,则该区块链中的节点设备可以确定省财政厅A账户当前维护的电子票据号段为60001-69999,数量为9999,大于作为阈值的5000,因此该区块链中的节点设备可以进一步调用上述号码分配逻辑,从省财政厅A账户当前维护的电子票据号段中为市财政局B分配电子票据号码。
假设为省财政厅A账户设置的用于分配电子票据号码的数量为2000,则该区块链中的节点设备可以将60001-62000分配给市财政局B,并将为市财政局B分配的电子票据号码添加至市财政局B账户进行维护,即后续市财政局B账户维护的电子票据号段为88001-89999和60001-62000。
该区块链中的节点设备可以再进一步调用上述号码分配逻辑,从市财政局B账户当前维护的电子票据号段中为执收单位B分配电子票据号码。
假设为市财政局B账户设置的用于分配电子票据号码的数量为2000,则该区块链中的节点设备可以将60001-62000分配给执收单位B,并将为执收单位B分配的电子票据号码添加至执收单位B账户进行维护,即后续执收单位B账户维护的电子票据号段为80101-80900和60001-62000。
在上述技术方案中,可以由上述区块链中的任意一级账户的账户管理者作为号码申领方,主动从与该号码申领方账户对应的上级账户维护的电子票据号段中申领电子票据号码。采用这样的方式,可以实现各级账户维护的电子票据号段的自动申领,避免出现区块链中的各级账户维护的电子票据号段的数量不充足的问题。
请参考图8,图8是本说明书一示例性实施例示出的一种基于区块链的开票方法的流程图。该方法可以应用于图6所示的基于区块链的电子票据管理***中作为节点设备加入至该区块链的电子设备;其中,该电子设备可以是服务器、计算机、手机、平板设备、笔记本电脑或掌上电脑(PDAs,Personal Digital Assistants)等,本说明书对此不作限制。该方法可以包括以下步骤:
步骤802,接收发布至所述区块链的开票交易;其中,所述开票交易包括开票信息和开票方账户的账户标识;
步骤804,响应于所述开票交易,调用部署在所述区块链上的智能合约,确定所述开票方账户维护的电子票据号段的数量是否充足;
步骤806,如果所述开票方账户维护的电子票据号段的数量不充足,则从与所述开票方账户对应的上级账户维护的电子票据号段中为所述开票方分配电子票据号码,并将为所述开票方分配的电子票据号码添加至所述开票方账户进行维护;
步骤808,从为所述开票方账户分配的电子票据号码中为所述开票方分配目标电子票据号码,并基于所述目标电子票据号码和所述开票信息创建电子票据。
以下以采用MPT树的数据结构,将区块链中的账户状态数据组织成MPT状态树为例,对本说明书的技术方案进行详细描述;
其中,需要强调的是,以采用MPT树的数据结构来组织区块链中的账户状态数据,仅为示例性的。
在实际应用中,对于基于以太坊架构而衍生出的区块链项目,除了可以采用诸如MPT树等改良版的Merkle树以外,也可以采用类似于MPT树的融合了Trie字典树的Merkle树变种,在本说明书中不再进行一一列举。
对于上述区块链中的任意一级账户而言,如果该账户的账户管理者作为开票方发起开票处理,则该区块链中的节点设备可以在确定该账户维护的电子票据号段的数量不充足时,从与该账户对应的上级账户维护的电子票据号段中申领电子票据号码,以完成开票处理。
具体地,该开票方可以构建开票交易,并将构建的该开票交易发布至区块链进行存证。其中,该开票交易可以包括开票信息以及该开票方账户的账户标识。
参考前述将物理世界产生的真实数据在区块链中进行持久化存证的流程,该区块链中的节点设备可以接收到该开票交易,进而可以对接收到的该开票交易进行共识处理,并在达成共识之后,将该开票交易打包进区块,在区块链中进行持久化存证。
对于打包进区块的该开票交易,该区块链中的节点设备可以执行该开票交易,即响应于该开票交易,调用部署在该区块链上的智能合约,先确定该开票方账户维护的电子票据号段的数量是否充足。
如果该开票方账户维护的电子票据号段的数量不充足(例如:该开票方账户维护的电子票据号段的数量小于预设的阈值或者为0),则可以进一步从与该开票账户对应的上级账户维护的电子票据号段中为该开票方分配电子票据号码,并将为该开票方分配的电子票据号码添加至该开票方账户进行维护。后续,可以从为该开票方账户分配的电子票据号码中为该开票方分配用于当前的开票处理的目标电子票据号码,从而可以基于该目标电子票据号码,以及上述开票交易中的开票信息,创建对应的电子票据。
相应地,如果该开票方账户维护的电子票据号段的数量充足,则可以直接从该开票方账户维护的电子票据号段中为该开票方分配用于当前的开票处理的目标电子票据号码,从而可以基于该目标电子票据号码,以及上述开票交易中的开票信息,创建对应的电子票据。
具体地,该区块链中的节点设备可以调用部署在该区块链上的智能合约中声明的号码申领逻辑,确定该开票方账户维护的电子票据号段的数量是否充足。
如果该开票方账户维护的电子票据号段的数量不充足,则可以进一步调用部署在该区块链上的智能合约中声明的号码分配逻辑,从与该开票账户对应的上级账户维护的电子票据号段中为该开票方分配电子票据号码,并将为该开票方分配的电子票据号码添加至该开票方账户进行维护;后续,可以再进一步调用部署在该区块链上的智能合约中声明的开票逻辑,从为该开票方账户分配的电子票据号码中为该开票方分配用于当前的开票处理的目标电子票据号码,并基于该目标电子票据号码,以及上述开票信息,创建对应的电子票据。
相应地,如果该开票方账户维护的电子票据号段的数量充足,则可以直接调用部署在该区块链上的智能合约中声明的开票逻辑,从为该开票方账户分配的电子票据号码中为该开票方分配用于当前的开票处理的目标电子票据号码,并基于该目标电子票据号码,以及上述开票信息,创建对应的电子票据。
其中,号码申领逻辑具体可以是声明在该智能合约中的,与申领电子票据号码的执行逻辑相关的程序代码(例如:一些可供调用的程序方法或者函数);号码分配逻辑具体可以是声明在该智能合约中的,与分配电子票据号码的执行逻辑相关的程序代码;开票逻辑具体可以是声明在该智能合约中的,与创建电子票据的执行逻辑相关的程序代码。
需要说明的是,以上描述的用于进行电子票据号码申领的智能合约、用于进行电子票据号码分配的智能合约,以及用于创建电子票据的智能合约,可以整合为一个智能合约在上述区块链上进行部署,也可以作为两个不同的智能合约在该区块链上进行部署,本说明书对此不作限定。
图8所示的实施例中的电子票据号码申领和分配的具体实施方式还可以参考图7所示的实施例,本说明书在此不再赘述。
在上述技术方案中,可以在确定基于上述区块链进行开票处理的开票方的账户维护的电子票据号段的数量不充足时,从与该开票方账户对应的上级账户维护的电子票据号段中申领电子票据号码。采用这样的方式,可以实现各级账户维护的电子票据号段的自动申领,避免出现区块链中的各级账户维护的电子票据号段的数量不充足的问题。
与前述基于区块链的电子票据号码申领方法的实施例相对应,本说明书还提供了基于区块链的电子票据号码申领装置的实施例。
本说明书基于区块链的电子票据号码申领装置的实施例可以应用在电子设备上。装置实施例可以通过软件实现,也可以通过硬件或者软硬件结合的方式实现。以软件实现为例,作为一个逻辑意义上的装置,是通过其所在电子设备的处理器将非易失性存储器中对应的计算机程序指令读取到内存中运行形成的。
从硬件层面而言,如图9所示,为本说明书基于区块链的电子票据号码申领装置所在电子设备的一种硬件结构图,除了图9所示的处理器、内存、网络接口、以及非易失性存储器之外,实施例中装置所在的电子设备通常根据该基于区块链的电子票据号码申领的实际功能,还可以包括其他硬件,对此不再赘述。
请参考图10,图10是本说明书一示例性实施例示出的一种基于区块链的电子票据号码申领装置的框图。所述装置100可以应用于图9所示的电子设备,所述电子设备可以作为节点设备加入至所述区块链;所述区块链包括用于维护电子票据号段的多级账户;所述装置100可以包括:
接收模块1001,用于接收发布至所述区块链的号码申领交易;其中,所述号码申领交易包括号码申领方账户的账户标识;
分配模块1002,用于响应于所述号码申领交易,从与所述号码申领方账户对应的上级账户维护的电子票据号段中为所述号码申领方分配电子票据号码;
维护模块1003,用于将为所述号码申领方分配的电子票据号码添加至所述号码申领方账户进行维护。
在本实施例中,所述分配模块1002具体可以用于:
响应于所述号码申领交易,调用部署在所述区块链上的智能合约,从与所述号码申领方账户对应的上级账户维护的电子票据号段中为所述号码申领方分配电子票据号码。
在本实施例中,所述分配模块1002具体可以用于:
确定与所述号码申领方账户对应的上级账户维护的电子票据号段的数量是否充足;
如果所述上级账户维护的电子票据号段的数量充足,则从所述上级账户维护的电子票据号段中为所述号码申领方分配电子票据号码。
在本实施例中,所述装置100还可以包括:
第一指示模块1004,用于如果所述上级账户维护的电子票据号段的数量不充足,则向所述上级账户对应的客户端发送告警指示,以指示所述客户端构建所述号码申领交易,并将所述号码申领交易发布至所述区块链;
或者,如果所述上级账户维护的电子票据号段的数量不充足,则生成所述上级账户维护的电子票据号段的数量不充足的事件信息,并将所述事件信息发布至所述区块链进行存证,以使所述上级账户对应的客户端在监听到所述事件信息时,构建所述号码申领交易,并将所述号码申领交易发布至所述区块链。
在本实施例中,所述装置100还可以包括:
确定模块1005,用于周期性确定所述多级账户中的各级账户维护的电子票据号段的数量是否充足;
第二指示模块1006,用于如果所述多级账户中的任意一级目标账户维护的电子票据号段的数量不充足,则向所述目标账户对应的客户端发送告警指示,以指示所述客户端构建所述号码申领交易,并将所述号码申领交易发布至所述区块链。
与前述基于区块链的开票方法的实施例相对应,本说明书还提供了基于区块链的开票装置的实施例。
本说明书基于区块链的开票装置的实施例可以应用在电子设备上。装置实施例可以通过软件实现,也可以通过硬件或者软硬件结合的方式实现。以软件实现为例,作为一个逻辑意义上的装置,是通过其所在电子设备的处理器将非易失性存储器中对应的计算机程序指令读取到内存中运行形成的。
从硬件层面而言,如图11所示,为本说明书基于区块链的开票装置所在电子设备的一种硬件结构图,除了图11所示的处理器、内存、网络接口、以及非易失性存储器之外,实施例中装置所在的电子设备通常根据该基于区块链的开票的实际功能,还可以包括其他硬件,对此不再赘述。
请参考图12,图12是本说明书一示例性实施例示出的一种基于区块链的开票装置的框图。所述装置120可以应用于图11所示的电子设备,所述电子设备可以作为节点设备加入至所述区块链;所述区块链包括用于维护电子票据号段的多级账户;所述装置120可以包括:
接收模块1201,用于接收发布至所述区块链的开票交易;其中,所述开票交易包括开票信息和开票方账户的账户标识;
确定模块1202,用于响应于所述开票交易,调用部署在所述区块链上的智能合约,确定所述开票方账户维护的电子票据号段的数量是否充足;
第一开票模块1203,用于如果所述开票方账户维护的电子票据号段的数量不充足,则从与所述开票方账户对应的上级账户维护的电子票据号段中为所述开票方分配电子票据号码,并将为所述开票方分配的电子票据号码添加至所述开票方账户进行维护;以及,从为所述开票方账户分配的电子票据号码中为所述开票方分配目标电子票据号码,并基于所述目标电子票据号码和所述开票信息创建电子票据。
在本实施例中,所述装置120还可以包括:
第二开票模块1204,用于如果所述开票方账户维护的电子票据号段的数量充足,从所述开票方账户维护的电子票据号段中为所述开票方分配目标电子票据号码,并基于所述目标电子票据号码和所述开票信息创建电子票据。
在本实施例中,所述第一开票模块1203具体可以用于:
确定与所述开票方账户对应的上级账户维护的电子票据号段的数量是否充足;
如果所述上级账户维护的电子票据号段的数量充足,则从所述上级账户维护的电子票据号段中为所述开票方分配电子票据号码。
在本实施例中,所述装置120还可以包括:
指示模块1205,用于如果所述上级账户维护的电子票据号段的数量不充足,则向所述上级账户对应的客户端发送告警指示,以指示所述客户端构建所述号码申领交易,并将所述号码申领交易发布至所述区块链;
或者,如果所述上级账户维护的电子票据号段的数量不充足,则生成所述上级账户维护的电子票据号段的数量不充足的事件信息,并将所述事件信息发布至所述区块链进行存证,以使所述上级账户对应的客户端在监听到所述事件信息时,构建所述号码申领交易,并将所述号码申领交易发布至所述区块链。
上述装置中各个模块的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程,在此不再赘述。
对于装置实施例而言,由于其基本对应于方法实施例,所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的,其中所述作为分离部件说明的模块可以是或者也可以不是物理上分开的,作为模块显示的部件可以是或者也可以不是物理模块,即可以位于一个地方,或者也可以分布到多个网络模块上。可以根据实际的需要选择其中的部分或者全部模块来实现本说明书方案的目的。本领域普通技术人员在不付出创造性劳动的情况下,即可以理解并实施。
上述实施例阐明的***、装置、模块或单元,具体可以由计算机芯片或实体实现,或者由具有某种功能的产品来实现。一种典型的实现设备为计算机,计算机的具体形式可以是个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件收发设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任意几种设备的组合。
在一个典型的配置中,计算机包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器,随机存取存储器(RAM)和/或非易失性内存等形式,如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括,但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带、磁盘存储、量子存储器、基于石墨烯的存储介质或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。按照本文中的界定,计算机可读介质不包括暂存电脑可读媒体(transitory media),如调制的数据信号和载波。
还需要说明的是,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下,在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外,在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中,多任务处理和并行处理也是可以的或者可能是有利的。
在本说明书一个或多个实施例使用的术语是仅仅出于描述特定实施例的目的,而非旨在限制本说明书一个或多个实施例。在本说明书一个或多个实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式,除非上下文清楚地表示其他含义。还应当理解,本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。
应当理解,尽管在本说明书一个或多个实施例可能采用术语第一、第二、第三等来描述各种信息,但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如,在不脱离本说明书一个或多个实施例范围的情况下,第一信息也可以被称为第二信息,类似地,第二信息也可以被称为第一信息。取决于语境,如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。
以上所述仅为本说明书一个或多个实施例的较佳实施例而已,并不用以限制本说明书一个或多个实施例,凡在本说明书一个或多个实施例的精神和原则之内,所做的任何修改、等同替换、改进等,均应包含在本说明书一个或多个实施例保护的范围之内。