一种基于联盟链的通证方法、系统、电子设备及存储介质

摘要

本公开提供了一种基于联盟链的通证方法，包括：S1，发起交易请求，并对该笔交易类型进行判断，若该笔交易为合约交易，则进行步骤S2；若该笔交易为通证交易，则进行步骤S3；S2，对该笔合约交易进行模拟验证处理，完成该笔合约交易的背书，并根据服务端中该笔合约交易对应的本地数据生成读写集；S3，对该笔通证交易进行验证处理，完成该笔通证交易的UTXO输入输出计算，并生成UTXO交易结构；S4，根据S2中输出的读写集及该笔合约交易信息或S3输出的UTXO交易结构及该笔通证交易信息进行排序打包生成区块；S5，校验区块与其对应的服务端中本地数据的一致性。本公开还提供了一种基于联盟链的通证系统、电子设备及计算机可读存储介质。

说明书

技术领域

本公开涉及区块链交易技术领域，具体涉及一种基于联盟链的通证方法、系统、电子设备及存储介质。

背景技术

匿名、隐私等特性极大的促进了区块链技术的传播，然而凡事都具有两面性，区块链的私密性有着明显的缺陷。以比特币为例，在比特币交易中，地址通常以收款方出现，一旦比特币地址和人的真实身份挂钩，其匿名性将会荡然无存。由于比特币地址是公开的，其交易记录，比特币数量都可以清楚查到，一旦我的地址暴露，很容易被不法之徒盯上。而联盟链中的区块、数据如合约账户对应的世界状态(WorldState)大部分以明文文数字存储，这意味着无论是谁，都可以通过合约查询操作任意key值对应的value值或者通过遍历区块获取该合约账户的交易历史记录，合约账户没有隐私可言，因此支持隐私交易对区块链账户安全十分必要。

联盟链自诞生以来常常被用作分布式存储来使用，缺乏统一的区块链可靠交易账户：

1、联盟链采用了智能合约方式实现账户的定义，底层的key值由合约ID与账户ID拼接，账户转账需要通过智能合约来实现，合约容器资源负担沉重，一旦合约运行出现bug，业务将无法处理。

2、联盟链合约账户之间的转账需要通过同一个智能合约的逻辑处理，无法实现跨合约的逻辑处理；合约账户只能在特定场景发挥作用，无法实现全网跨合约间的处理。

3、联盟链合约账户数量受到合约容器的资源制约，合约账户数量容量有限，无法应对高并发的转账。

发明内容

本公开实施例提供的一种基于联盟链的通证方法、系统、电子设备及存储介质，该方法实现了合约交易与通证交易的兼容排序，并通过环签名算法解决交易隐私的问题。

本公开的第一个方面提供了一种基于联盟链的通证方法，包括：S1，发起交易请求，并对该笔交易类型进行判断，若该笔交易为合约交易，则进行步骤S2；若该笔交易为通证交易，则进行步骤S3；S2，对该笔合约交易进行模拟验证处理，完成该笔合约交易的背书，并根据服务端中该笔合约交易对应的本地数据生成读写集；S3，对该笔通证交易进行验证处理，完成该笔通证交易的UTXO输入输出计算，并生成UTXO交易结构；S4，根据S2中输出的读写集及该笔合约交易信息或S3输出的UTXO交易结构及该笔通证交易信息进行排序打包生成区块；S5，校验区块与其对应的服务端中本地数据的一致性，若一致，则更新交易账户对应的数据库数据，若不一致，则放弃该笔交易。

进一步地，该方法还包括：S0，用户申请所需的公钥、私钥及准入证书，以使其获得发起交易及进行交易签名的权限。

进一步地，S0步骤后还包括：客户端根据用户申请的私钥生成签名信息，该签名信息用于对发起该笔合约交易的用户身份验证；或客户端根据用户申请的准入证书及公钥生成环签名信息，该环签名信息用于对发起该笔通证交易的用户身份验证及该笔通证交易的有效性。

进一步地，S2中对该笔合约交易进行模拟验证处理，完成该笔合约交易的背书，并根据服务端中该笔合约交易对应的本地数据生成读写集包括：S21，对该笔合约交易进行模拟验证处理，该模拟验证处理包括：客户端证书的有效性验证、用户私钥有效性验证、准入证书是否属于来自联盟链中区块链成员验证及根据该签名信息对用户身份验证；S22，若验证通过，则完成该笔合约交易的背书，并根据本地数据生成相应的读写集；若验证未通过，则放弃该笔合约交易。

进一步地，S3中对该笔通证交易进行验证处理，完成该笔通证交易的UTXO输入输出计算，生成UTXO交易结构包括：S31，对该笔通证交易进行验证处理，该验证处理包括：对客户端证书的有效性验证、准入证书是否属于来自联盟链中区块链成员验证、该环签名信息有效性验证及该笔通证交易是否提交过验证；S32，若验证通过，则完成该笔通证交易的UTXO输入输出计算，生成UTXO交易结构，若验证未通过，则放弃该笔交易。

进一步地，客户端根据用户申请的准入证书及公钥生成环签名信息包括：设置签名环生成所需的公钥数P；客户端随机选取包含真实用户ID

进一步地，S6中UTXO交易结构的输入及输出均包括：转入方、用户签名、交易金额及交易类型。

本公开的第二个方面提供了一种基于联盟链的通证系统，包括：交易发起模块，用于用户发起交易请求，客户端封装该笔交易请求的通证头信息，并根据头信息进行交易类型判别；背书节点网络模块，用于对合约交易进行模拟验证处理，完成该笔合约交易的背书，并根据服务端中相应的本地数据生成读写集；通证节点网络模块，用于对通证交易进行验证处理，完成该笔通证交易的UTXO输入输出计算，生成UTXO交易结构；排序节点网络模块，用于根据该读写集及该笔合约交易信息或UTXO交易结构及该笔通证交易信息进行排序打包生成区块；提交节点网络模块，用于校验该区块与其对应的服务端中本地数据的一致性，若一致，则更新交易账户对应的数据库数据，若不一致，则放弃该笔交易。

本公开的第三个方面提供了一种电子设备，包括：存储器，处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行计算机程序时，实现本公开的第一方面提供的基于联盟链的通证方法。

本公开的第四个方面提供了一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时，实现本公开的第一个方面提供的基于联盟链的通证方法。

本公开与现有技术相比，具备以下有益效果：

(1)本公开提供的方法通过通证转换处理，达到各种通证类型之间兑换及合约子账户-通证账户的通证转账，实现了不同场景账户操作的逻辑隔离，保障了账户安全。

(2)通过构建环签名验证，实现联盟链支持隐私交易，保护交易双方的账户隐私，减小不法分子通过区块公开信息获取特定账户的隐私信息的几率，以及通过构建签名环公钥镜像，实现隐私交易识别重复交易，提供防重放机制保护交易双方的账户安全。

(3)通过构建通证账户体系，解决了单个合约的账户资源受到容器资源限制的问题，提高了联盟链账户处理的系统吞吐量(TPS)。

(4)通过环签名算法解决交易隐私的问题，以及公钥镜像方案解决环签名交易双花的问题：在数据层制定统一的账户定义，用户通过注册得要一个全链唯一的账号。

附图说明

为了更完整地理解本公开及其优势，现在将参考结合附图的以下描述，其中：

图1示意性示出了根据本公开一实施例的基于联盟链的通证方法的应用场景图；

图2示意性示出了根据本公开一实施例的基于联盟链的通证方法的流程图；

图3示意性示出了根据本公开一实施例的环签名生成的具体流程图；

图4示意性示出了根据本公开一实施例的隐私交易环签名生成结构示意图；

图5示意性示出了根据本公开一实施例的合约交易处理详细流程图；

图6示意性示出了根据本公开一实施例的通证交易处理详细流程图；

图7示意性示出了根据本公开一实施例的传统UTXO模型与本公开实施例UTXO模型对比图；

图8示意性示出了根据本公开一实施例的基于联盟链的通证方法采用的账本存储区块结构图；

图9示意性示出了根据本公开一实施例的基于联盟链的通证系统的转账交易详细流程图；

图10示意性示出了根据本公开一实施例的基于联盟链的通证系统的方框图；

图11示意性示出了根据本公开一实施例的基于联盟链的通证系统采用的网络拓扑图；

图12示意性示出了根据本公开一实施例的基于联盟链的通证系统采用的合约账户关系图；

图13示意性示出了根据本公开一实施例的适于实现上文描述的方法的电子设备的方框图。

具体实施方式

以下，将参照附图来描述本公开的实施例。但是应该理解，这些描述只是示例性的，而并非要限制本公开的范围。在下面的详细描述中，为便于解释，阐述了许多具体的细节以提供对本公开实施例的全面理解。然而，明显地，一个或多个实施例在没有这些具体细节的情况下也可以被实施。此外，在以下说明中，省略了对公知结构和技术的描述，以避免不必要地混淆本公开的概念。

在此使用的术语仅仅是为了描述具体实施例，而并非意在限制本公开。在此使用的术语“包括”、“包含”等表明了所述特征、步骤、操作和/或部件的存在，但是并不排除存在或添加一个或多个其他特征、步骤、操作或部件。

在此使用的所有术语(包括技术和科学术语)具有本领域技术人员通常所理解的含义，除非另外定义。应注意，这里使用的术语应解释为具有与本说明书的上下文相一致的含义，而不应以理想化或过于刻板的方式来解释。

在使用类似于“A、B和C等中至少一个”这样的表述的情况下，一般来说应该按照本领域技术人员通常理解该表述的含义来予以解释(例如，“具有A、B和C中至少一个的系统”应包括但不限于单独具有A、单独具有B、单独具有C、具有A和B、具有A和C、具有B和C、和/或具有A、B、C的系统等)。在使用类似于“A、B或C等中至少一个”这样的表述的情况下，一般来说应该按照本领域技术人员通常理解该表述的含义来予以解释(例如，“具有A、B或C中至少一个的系统”应包括但不限于单独具有A、单独具有B、单独具有C、具有A和B、具有A和C、具有B和C、和/或具有A、B、C的系统等)。

附图中示出了一些方框图和/或流程图。应理解，方框图和/或流程图中的一些方框或其组合可以由计算机程序指令来实现。这些计算机程序指令可以提供给通用计算机、专用计算机或其他可编程数据处理装置的处理器，从而这些指令在由该处理器执行时可以创建用于实现这些方框图和/或流程图中所说明的功能/操作的装置。本公开的技术可以硬件和/或软件(包括固件、微代码等)的形式来实现。另外，本公开的技术可以采取存储有指令的计算机可读存储介质上的计算机程序产品的形式，该计算机程序产品可供指令执行系统使用或者结合指令执行系统使用。

图1示意性示出了根据本公开的实施例的基于联盟链的通证方法的应用场景。需要注意的是，图1所示仅为可以应用本公开实施例的场景的示例，以帮助本领域技术人员理解本公开的技术内容，但并不意味着本公开实施例不可以用于其他设备、系统、环境或场景。

如图1所示，该应用场景中包括客户端110和服务端120。客户端110可以与服务端120通信，以对服务端120进行管理及存储数据读取与写入。

客户端110可以为存储在用户终端上的软件系统，如：通证系统，用户终端可以为银行柜机、台式计算机、笔记本电脑、平板电脑等，用户可以在该客户端110中进行操作，向服务端120发起用户请求，并接收服务端120的响应数据，用户可以在该客户端110的应用界面中查看各交易的结果等。服务端120可以为存储在服务器或云服务器上的数据库系统，其包括网卡用以与客户端110通信，客户端110通过网卡与服务端120通信能够实现对服务端120进行数据读取与写入，以及服务端120系统更新、升级等操作。

服务端120可以是提供各种服务的服务器，例如接收客户端110发送的用户请求，并响应于该用户请求获取该笔交易对应的本地数据等，并反馈给客户端110。

下面参考图2至图9说明本公开实施例的实施方式。

图2示意性示出了根据本公开一实施例的基于联盟链的通证方法的流程图。

如图2所示，该方法包括步骤S1～S5。

S1，发起交易请求，并对该笔交易类型进行判断，若该笔交易为合约交易，则进行步骤S2；若该笔交易为通证交易，则进行步骤S3。

根据本公开的实施例，在客户端(Client)的用户发起交易请求前，其可以先向证书颁发机构(Certificate Authority，CA)申请所需的公钥、私钥及准入证书，以使其获得发起交易及进行交易签名的权限。然后，客户端根据发起的交易请求，先将该笔交易请求的头信息进行封装，并根据封装后的头信息进行交易类型判别。

本公开的实施例中，该CA位于本系统的成员管理模块，该成员管理模块调用原有的权限管理模块(MSP)功能，成员身份基于标准的X.509证书，密钥使用椭圆曲线数字签名算法(ECDSA)，利用PKI(Public Key Infrastructure)体系给每个用户颁发证书，发起通证交易请求需要利用成员证书进行签名。

具体地，该成员管理模块基于全新的账户权限管理体系，通过设计联盟链的组织管理员账户(含ACL中admin角色)，即代表组织内最高所有权，可进行所有角色权限操作(如发行、转账、回收、投票等权限)，可由一对或多对玺链公私钥或者另一账户的某权限实现权限控制，设计联盟链的普通账户自带Owner权限。Owner即代表账户所有权，可进行所有角色权限操作(转账、投票等权限)，包括更改Owner权限，可由一对或多对玺链公私钥或者另一账户的某权限实现权限控制。同时支持将A账户的某一操作权限分配给其他人所拥有的公私钥或者账户B，从而实现基于角色的权限控制。

根据本公开的实施例，客户端根据用户申请的私钥生成签名信息，该签名信息用于对发起的该笔合约交易的用户身份验证；或客户端根据用户申请的准入证书及公钥生成环签名信息，该环签名信息用于对发起该笔通证交易的用户身份验证及该笔通证交易的有效性。

具体地，如图3所示，客户端根据用户申请的准入证书及公钥生成环签名信息包括：

S301，初始参数生成，设置签名环生成所需的公钥数P。

S302，客户端随机选取包含真实用户ID

S303，PKG

S304，对于需要签名的消息，真实用户ID

本公开实施例中，采用验证节点验证环签名等式是否成立，从而验证环签名的有效性，真实签名者如果需要证明自己的身份，则需要透露秘密信息给验证节点，验证节点通过验证签名等式是否成立从而验证该消息的真实签名者。待环签名信息验证通过后，验证节点根据生成的签名公钥镜像，查询是否存在历史记录，如果不存在则证明该记录为全新唯一，完成该笔交易验证。

本公开实施例中，如图4所示为本公开实施例采用的隐私交易签名环生成图，在链上交易里相似交易的用户公钥(Public key)，需要根据签名环的R值(需要多少公钥生成环签名)获取链上的用户公钥用于签名环的生成，然后根据交易发起方的私钥(PrivateKey)，证明该笔金额的归属，即只可以使用属于自己的金额进行转账。其中，若存在临时接收账户(Tmp Public key)时，真正接收方拥有该临时接收账户的私钥，当共识完成，真正接收方既可以使用该临时账户金额。

S2，对该笔合约交易进行模拟验证处理，完成该笔合约交易的背书，并根据服务端中该笔合约交易对应的本地数据生成读写集。

本公开实施例中，在区块链中承担背书任务的节点即为背书节点，背书节点必须通过有效证书的预期信息的有效签名来证明交易的合法性。

根据本公开的实施例，如图5所示，步骤S2包括：

S21，对该笔合约交易进行模拟验证处理，该模拟验证处理包括：客户端证书的有效性验证、用户私钥有效性验证、准入证书是否属于来自联盟链中区块链成员验证。

S22，若验证通过，则完成该笔合约交易的背书，并根据本地数据生成相应的读写集；若验证未通过，则放弃该笔合约交易。

具体地，客户端根据用户请求生成一个合约交易请求发送至背书节点进行模拟执行并进行背书，背书节点(Endorser)会进行相应的校验，包括：客户端证书的有效性验证、用户私钥有效性验证、准入证书是否属于来自联盟链中区块链成员验证及根据用户申请的私钥生成的签名信息对用户身份验证，若验证通过，则将该笔交易交由对应的链码(Chaincode)进行模拟执行，之后背书节点会对执行结果进行背书，最后将背书结果(即背书节点生成的读写集)返回至客户端。随之，客户端收集到符合背书策略的背书结果后，将其封装成一个交易(Transaction)，调用排序节点(Orderer)的广播接口(Broadcast)，将该笔交易生成的读写集发送至排序节点进行排序。否则，验证未通过，放弃该笔交易。

S3，对该笔通证交易进行验证处理，完成该笔通证交易的UTXO输入输出计算，并生成UTXO交易结构。

本公开实施例中，通过新增设计Prover节点处理通证交易请求并将其转换为INPUT-OUTPUT结果集合，最后加上交易header(交易头信息)，组装成最终交易信息(即UTXO交易结构)发往排序节点进行排序。

根据本公开的实施例，如图6所示，步骤S3包括：

S31，对该笔通证交易进行验证处理，该验证处理包括：对客户端证书的有效性验证、准入证书是否属于来自联盟链中区块链成员验证、环签名信息有效性验证及该笔通证交易是否提交过验证；

S32，若验证通过，则完成该笔通证交易的UTXO输入输出计算，生成UTXO交易结构，若验证未通过，则放弃该笔交易。

具体地，客户端根据用户请求生成一个通证交易发送至通证节点进行交易处理，包括：加载通道配置、MSP配置、交易签名、生成通证类型交易头等，并该笔通证交易进行验证处理，该验证处理过程由位于通证节点中的交易合法性验证子节点进行验证，主要包括：对客户端证书的有效性验证、准入证书是否属于来自联盟链中区块链成员验证、该环签名信息有效性验证(包括用户身份的真实性)及该笔通证交易是否提交过验证等，若验证通过，则根据通证交易类型(转账交易需要先查询账本中转账多方的存量值作为INPUT，转账计算完成后的状态为OUTPUT；发行交易仅产生OUTPUT)生成对应的UTXO交易结构，并调用排序节点的广播接口，进行发送交易结果至排序节点；同步请求调用提交节点(Committer)的交付接口(Deliver)，获取消息通知，返回true则表示该笔交易成功交易。否则，若验证未通过，则放弃该笔交易。

如图7所示，该UTXO模型是指关联比特币地址的比特币金额的集合，是一个包含数据和可执行代码的数据结构，其包括INPUT总量的各子量成分和OUTPUT总量的各子量成分，如图7所示，传统的UTXO模型由一系列的“有效的输出”组成。每个UTXO都有拥有者和自身的价值属性，一笔交易在消费若干个UTXO同时也会生成若干个新的UTXO，其中，UTXO模型“有效的输出”中有效需满足四点约束，包括：1)每个被引用的输入必须有效，且未被使用过；2)交易的签名必须与每笔输入的所有者签名匹配；3)输入的总值必须等于或大于输出的总值；4)仅支持同种资产的转账。而本方案改进的UTXO模型通过补充资产号字段，实现横向扩展，同笔交易可支持多通证类型输入、Prover逻辑通证比例兑换，多通证类型输出，达到不同资产可以在同一笔交易中转换。

S4，根据S2中输出的读写集及该笔合约交易信息或S3输出的UTXO交易结构及该笔通证交易信息进行排序打包生成区块，即区块为若干笔交易的数据集合。

具体地，排序节点判断该笔交易(合约交易或通证交易)类型，并将该笔交易进入缓存排序，将交易统一排序生成区块，将区块推送至底层raft状态机进行应用同步，最后通过Gossip协议中的主节点(Leader Peer)将区块广播至组织内其余节点，即发送至包括但不限于提交节点。

根据本公开的实施例，图8所示为基于联盟链的通证方法/系统采用的账本存储区块结构图。如图8所示，本公开通过改造现有区块结构，支持实现横向扩展存储通证交易信息。传统的合约区块头包含当前区块哈希、区块序号、前驱区块哈希，传统合约区块数据为交易组成的数组，一个交易包括：交易发送者的签名、数据载荷payload、背书结果读写集等，元数据为当前区块相关的元数据信息。而本公开采用的通证交易的区块，其主要扩展部分为区块数据记录通证交易中的INPUT及OUTPUT结构，其输入及输出均包括转入方、签名、金额、类型等。

S5，校验该区块与其对应的服务端中本地数据的一致性，若一致，则更新交易账户对应的数据库数据，若不一致，则放弃该笔交易。

具体地，每个提交节点在收到区块之后会对区块进行校验，校验该区块与其对应的服务端中本地数据的一致性，包括签名、背书策略以及读写集(合约交易读写集从请求中获取；当接收到的是通证交易，检查是否符合UTXO模型，INPUT中总量与OUTPUT中总量是否一致或INPUT中总量大于OUTPUT中总量，以及基础资产是否被重复使用或者超额使用)的校验，在校验无误的情况下进行提交到账本，同时更新世界状态，同时订阅了相应事件的节点会收到来自消息中心的消息通知。若区块进行校验结果不一致，则放弃该笔交易。

为方便本领域技术人员理解本公开的技术内容，下面详细介绍本公开一实施例转账交易具体流程。

图9为基于联盟链的通证系统的转账交易详细流程图。

如图9所示，基于联盟链的通证系统采用的转账交易包括：S601～S606步骤。

S901，用户申请所需的准入证书，以使其获得发起交易及进行交易签名的权限。

S902，用户在客户端发起转账请求，封装该笔转账请求的通证头信息，该通证头信息用于后续判断交易类型；

S903，Prover节点接收到来自客户端的请求，对该笔转账交易进行通道检查、MSP策略检查(背书策略是否满足要求、是否对应的节点处理)，符合则建立交易事务(先查询本地账本中转账双方的状态，作为INPUT信息写入，进行转账计算后得出OUTPUT信息写入)，然后将生成的UTXO交易结构返回给客户端。此处，若转账者仍有剩余，将创建一个新的OUTPUT信息重新转给转账者自己。

S904，客户端建立与排序节点、提交节点的连接，通过Broadcast接口将交易广播到排序节点进行排序。其中，排序节点将交易统一排序生成区块，将区块推送至底层raft状态机进行应用同步。

S905，排序节点排序成功后将排序结果返回给客户端，然后通过Gossip协议中的主节点将区块广播至组织内其余各个节点。

S906，提交节点进行区块提交操作，当检查到交易头为通证交易信息时进入通证处理分支，包括：校验交易请求中INPUT中总量与OUTPUT中总量是否一致、校验区块与其对应的服务端中本地数据的一致性等，在校验无误的情况下进行提到账本，同时更新世界状态，同时订阅了相应事件的节点会收到来自消息中心的消息通知。若校验结果未通过，则放弃该笔交易。

S907，客户端接收排序节点的返回结果及提交节点的消息通知，当两个返回同时为true，即转账交易成功。

本公开实施例中，针对发行交易流程，其原理同转账交易。但生成通证交易信息没有INPUT信息，同时在提交节点不会判断INPUT与OUTPUT是否一致。支持同币种重复发行(每次发行或转账都会更新世界状态(WorldState)中对应的key值为当前交易编号(TxID))。

本公开实施例中，针对回收交易流程，原理同转账交易。但生成通证交易信息是无OUTPUT信息，同时在提交节点不会判断INPUT与OUTPUT是否一致。

本公开实施例中，针对查询交易流程，根据MSP信息查询本地WorldState中所有组织内发行过的币种返回信息。

本公开提供的基于联盟链的通证方法，该方法通过新增Prover模块，实现处理与通证相关的请求，完成统一账户的权限验证、达到统一账户与通证余额的绑定，并优化交易提交处理逻辑，兼容支持提交通证相关交易；新增通证交易处理，实现UTXO模型交易排序记录，解决当前共识逻辑不支持UTXO排序的问题，并计算签名环公钥镜像，解决环签名交易中无法防重放的问题；实现账本记录通证交易、账本记录签名环隐私交易、世界状态记录通证账户，解决了当前账本仅记录合约交易，无法记录跨合约账户交易、交易无法隐藏上链的问题；通过优化UTXO模型，解决当前联盟链缺乏账户模型的问题，通过UTXO的记账模式，实现以账户维度的逻辑记账，并支持不同通证可以在同一笔交易中转换，解决了当前联盟链查账需要依赖智能合约的问题；支持通证类账户交易，完成统一账户与合约账户的1：N绑定，从而实现跨合约账户的交易。

图10示意性示出了根据本公开一实施例的基于联盟链的通证系统的方框图。

如图10所示，该基于联盟链的通证系统100包括：交易发起模块110、背书节点网络模块120、通证节点网络模块130、排序节点网络模块740及提交节点网络模块150，该系统可以用于实现参考图2所描述的基于联盟链的通证方法。

交易发起模块110，用于用户发起交易请求，客户端封装该笔交易请求的通证头信息，并根据头信息进行交易类型判别。

背书节点网络模块120，用于对合约交易进行模拟验证处理，完成该笔合约交易的背书，并根据服务端中相应的本地数据生成读写集。

通证节点网络模块130，用于对通证交易进行验证处理，完成该笔通证交易的UTXO输入输出计算，生成UTXO交易结构。

排序节点网络模块140，用于根据该读写集及该笔合约交易信息或UTXO交易结构及该笔通证交易信息进行排序打包生成区块。

提交节点网络模块150，用于校验该区块与其对应的服务端中本地数据的一致性，若一致，则更新交易账户对应的数据库数据，若不一致，则放弃该笔交易。

本公开提供的基于联盟链的通证系统用以实现参考图2所描述的基于联盟链的通证方法，其各子模块包括的内容及实现的具体功能如上文所示，此处不再详细表述。

本公开实施例中，图11所示为本公开一实施例的基于联盟链的通证系统采用的网络拓扑图，如图11所示，各相连不同节点间相互通信交互以完成如上文所述的方法中的各个步骤。

本公开实施例中，图12所示为基于联盟链的通证系统采用的合约账户关系图。如图12所示，传统联盟链合约基于原有智能合约处理逻辑中，其合约账户是智能合约性隔离的，也就是说对A合约账户进行操作必须通过发送A合约操作请求，B合约无法进行操作，造成一个合约维护一套账户的问题。而本公开基于通证联盟链合约，通过改造新增处理通证账户分支，更新或者查询世界状态时根据是否含通证字符进行分支处理，实现改造后处理逻辑中，既支持原有合约账户的隔离，还支持合约账户与通证账户的关联管理，并实现合约操作通证账户，解决了账户冗余的问题。

根据本公开的实施例的模块、子模块、单元、子单元中的任意多个、或其中任意多个的至少部分功能可以在一个模块中实现。根据本公开实施例的模块、子模块、单元、子单元中的任意一个或多个可以被拆分成多个模块来实现。根据本公开实施例的模块、子模块、单元、子单元中的任意一个或多个可以至少被部分地实现为硬件电路，例如现场可编程门阵列(FPGA)、可编程逻辑阵列(PLA)、片上系统、基板上的系统、封装上的系统、专用集成电路(ASIC)，或可以通过对电路进行集成或封装的任何其他的合理方式的硬件或固件来实现，或以软件、硬件以及固件三种实现方式中任意一种或以其中任意几种的适当组合来实现。或者，根据本公开实施例的模块、子模块、单元、子单元中的一个或多个可以至少被部分地实现为计算机程序模块，当该计算机程序模块被运行时，可以执行相应的功能。

例如，交易发起模块110、背书节点网络模块120、通证节点网络模块130、排序节点网络模块140及提交节点网络模块150中的任意多个可以合并在一个模块中实现，或者其中的任意一个模块可以被拆分成多个模块。或者，这些模块中的一个或多个模块的至少部分功能可以与其他模块的至少部分功能相结合，并在一个模块中实现。根据本公开的实施例，交易发起模块110、背书节点网络模块120、通证节点网络模块130、排序节点网络模块140及提交节点网络模块150中的至少一个可以至少被部分地实现为硬件电路，例如现场可编程门阵列(FPGA)、可编程逻辑阵列(PLA)、片上系统、基板上的系统、封装上的系统、专用集成电路(ASIC)，或可以通过对电路进行集成或封装的任何其他的合理方式等硬件或固件来实现，或以软件、硬件以及固件三种实现方式中任意一种或以其中任意几种的适当组合来实现。或者，交易发起模块110、背书节点网络模块120、通证节点网络模块130、排序节点网络模块140及提交节点网络模块150中的至少一个可以至少被部分地实现为计算机程序模块，当该计算机程序模块被运行时，可以执行相应的功能。

图13示意性示出了根据本公开实施例的适于实现上文描述的方法的电子设备的方框图。图13示出的电子设备仅仅是一个示例，不应对本公开实施例的功能和使用范围带来任何限制。

如图9所示，本实施例中所描述的电子设备1300，包括：存储器1310、处理器1320及存储在存储器1310上并可在处理器上运行的计算机程序，处理器1320执行该程序时实现前述图2所示实施例中描述的基于联盟链的通证方法。

根据本公开的实施例，该电子设备还包括：至少一个输入设备1330；至少一个输出设备1340。上述存储器1310、处理器1320输入设备1330和输出设备1340通过总线1350连接。

其中，输入设备1330具体可为触控面板、物理按键或者鼠标等等。输出设备1340具体可为显示屏。存储器1310可以是高速随机存取记忆体(RAM，Random Access Memory)存储器，也可为非不稳定的存储器(non-volatile memory)，例如磁盘存储器。存储器1310用于存储一组可执行程序代码，处理器1320与存储器1310耦合。

本发明实施例还提供了一种计算机可读存储介质，该计算机可读存储介质可以是上述实施例中描述的设备/装置/系统中所包含的；也可以是单独存在，而未装配入该设备/装置/系统中。上述计算机可读存储介质承载有一个或者多个程序，当上述一个或者多个程序被执行时，实现根据本公开实施例的基于联盟链的通证方法。

根据本公开的实施例，计算机可读存储介质可以是非易失性的计算机可读存储介质，例如可以包括但不限于：便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本公开中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。

需要说明的是，在本发明各个实施例中的各功能模块可以集成在一个处理模块中，也可以是各个模块单独物理存在，也可以两个或两个以上模块集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。所述集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来。

附图中的流程图和框图，图示了按照本公开各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

本领域技术人员可以理解，本公开的各个实施例和/或权利要求中记载的特征可以进行多种组合和/或结合，即使这样的组合或结合没有明确记载于本公开中。特别地，在不脱离本公开精神和教导的情况下，本公开的各个实施例和/或权利要求中记载的特征可以进行多种组合和/或结合。所有这些组合和/或结合均落入本公开的范围。

尽管已经参照本公开的特定示例性实施例示出并描述了本公开，但是本领域技术人员应该理解，在不背离所附权利要求及其等同物限定的本公开的精神和范围的情况下，可以对本公开进行形式和细节上的多种改变。因此，本公开的范围不应该限于上述实施例，而是应该不仅由所附权利要求来进行确定，还由所附权利要求的等同物来进行限定。