CN115766024A - 区块链智能合约中获取真实交易提交人信息的方法 - Google Patents

Abstract

本发明涉及区块链智能合约中获取真实交易提交人信息的方法，包括：事先将业务系统认证服务的公钥提交到区块链账本中；用户登录并获取token，提交交易事务到业务系统中，业务系统校验token；业务系统将token透传，并和业务交易数据组装后一起发送至区块链应用程序；区块链应用程序继续透传到区块链网络，最终在区块链背书节点和记账节点上执行智能合约；如果token携带payload，智能合约直接解析token，获取payload；如果token不携带payload，则调用业务系统认证服务，使用token获取payload；使用公钥再次解析并验证token中签名有效性，验证通过则将交易提交人的用户名认定为真正提交人，提交交易到区块链账本中。本方案能够获取真实交易提交人信息，提高区块链应用记录的真实性。

Description

区块链智能合约中获取真实交易提交人信息的方法

技术领域

本发明涉及区块链技术领域，具体地涉及一种区块链智能合约中获取真实交易提交人信息的方法。

背景技术

随着区块链技术的发展，除了匿名公开的公链技术以外，目前越来越多的企业、行业引入了基于智能合约的、实名的不公开或半公开的私链或联盟链技术，主要用于利用区块链技术分布式、不可篡改的特性，记录企业内部或行业内部的交易数据(任何事务处理都可以理解为交易)。

很多同行业者会把区块链理解为“分布式账本”，类似数据库的作用。目前通常地，需要记录到区块链上的数据(事务)都是外部系统准备好之后提交到智能合约，再通过智能合约经过背书、排序、广播等过程，最终提交到区块链网络中各个记账节点(区块链账本所在节点)上进行记录的。由于区块链的数据是不可篡改的，因此会产生一个问题，即，如何确保数据记录的提交人身份是真实的。如果无法确保，那么区块链账本中可能记录的是错误的提交人身份，并且不可篡改，区块链应用程序记录的交易将被质疑。

为解决此问题，现有的方法有以下几种：

方法1：使用外部应用系统校验用户身份，然后区块链直接记录外部应用提交的数据记录，不再校验，直接将已有数据记录到区块链账本中，比如车辆管理部门、房屋管理部门等权威部门提供的数据。

此种方法的缺点很明显，区块链没有利用智能合约对事务进行校验，而是无条件的信任外部应用系统的数据。当外部应用系统出现错误时或被人恶意篡改时则无法发现。

方法2：区块链给外部应用系统颁发一个身份，无论外部应用提交的数据是什么，都记做是这个身份提交的数据记录。

此种方法的缺点也很明显，区块链记录的所有事务的提交人不是操作人，而是“某外部应用系统”，当需要对交易溯源时，只能追溯到提交系统，而无法追溯真正的操作人。

方法3：区块链需要对应外部应用系统，同步建立等量的用户身份，当外部应用系统提交数据时，区块链选择使用与外部应用系统上相同的用户身份进行记录。

此种方法看似没有问题，但实际上用户的同步建立、同步启用停用、同步修改、同步注销都是比较复杂的逻辑；并且仍然没有对提交人身份进行有效校验。

发明内容

本发明所要解决的技术问题在于：提供一种新的方式实现区块链智能合约中获取真实交易提交人信息；在区块链智能合约中，使用与外部应用系统一致的校验材料和校验逻辑，自主对业务系统操作人身份进行校验，并如实反应操作人信息，并将操作人信息连同提交的数据，一同记录到区块链账本中。

依据本发明的技术方案，本发明提供了一种区块链智能合约中获取真实交易提交人信息的方法，包括：

步骤一，事先将要进行操作的机构的业务系统认证服务使用的私钥所对应的公钥作为区块链网络中智能合约的初始化数据提交到区块链账本中；

步骤二，用户在业务系统认证服务登录并获取业务系统的token，提交交易事务到业务系统中，业务系统校验token；

步骤三，业务系统将交易提交人的token透传，并和业务交易数据组装后一起发送至区块链应用程序；

步骤四，区块链应用程序继续透传包含交易提交人token的业务交易数据发送到区块链网络，最终在区块链背书节点和记账节点上执行智能合约；

步骤五，在区块链网络中执行智能合约时，对token进行解析；解析token时，先从token中的payload中解析出机构名，然后从区块链账本中获取步骤一所提交的该机构的公钥，使用该公钥再次解析并验证token中签名有效性，验证通过则信任此token中payload内容，并将交易提交人的用户名认定为真正提交人，提交交易到区块链账本中。

进一步地，还包括步骤六，在进行生命周期维护交易时，将生命周期维护交易视为普通业务交易一样，智能合约采用相同方法验证私钥签发的token，并最终提交至记账节点记录到区块链账本中。

优选地，在步骤三中，在组装业务交易数据后、访问区块链应用程序前，还包括使用业务系统的私钥，对组装的交易数据进行二次签名；

进一步地，在步骤四S4后，执行到智能合约时，首先使用业务系统的公钥对整个组装的交易数据进行验证token签名有效性；验证通过后再进行步骤五。

进一步地，若存在多个业务系统对应同一套区块链网络，则在每个业务系统执行业务交易前，生成两对公私钥对，私钥分别由业务系统的认证服务和业务系统本身各自持有，公钥都提交到区块链账本中记录。

在一实施例中，步骤二包括：

用户登录业务系统的认证服务，业务系统的认证服务验证用户信息后，使用私钥签发token，token中含有签名，将token返回给用户；

用户携带此token，提交事务到业务系统中；

业务系统首先拦截提交事务请求，用业务系统的认证服务预先分发的公钥，来验证token中的签名，若验证通过才继续进行后续步骤三。

与现有技术相比，本发明的有益技术效果如下：

本发明利用智能合约，将普通业务交易和公钥管理交易一视同仁，都需要在区块链智能合约中进行交易提交人的身份自主验证，以自主验证并获取到的身份作为记录提交到区块链账本中。总结而言，本发明主要利用了签名、验签机制(包括用到了非对称加密、散列算法、数字签名技术)、区块链中智能合约的自动隔离执行特性(确保对执行过程不受外界干扰，对执行逻辑无异议，满足条件就执行)、区块链账本数据不可篡改的特性(公钥已经提交到区块链账本中)、区块链分布式特性(信任各方已经成功提交并记录到区块链账本中的数据)，从而确保了数据记录的提交人身份是真实的，提高了区块链应用程序记录的真实性，解决了从业务系统到区块链系统间事务链的消息防篡改难题、消息防抵赖难题，以及联合审计方法不能满足上链内容的一致性、完整性的难题。

附图说明

图1是本发明一实施例的方法流程图。

图2是本发明又一实施例的方法流程图。

图3是现有技术方案的方法流程图。

具体实施方式

首先需要补充解释的是，本发明所述“记账节点”指的是一个物理机、虚拟机或docker容器，它相当于一台电脑，这台电脑的职责是记账；而本发明所述“区块链账本”存在于每一个记账节点上，并且一致，区块链账本是记下来的交易数据存在于记账节点上的一组文件。

以及，本发明中所述的token，一般指代JWT(JSON Web Token)，一个JWT包含Header(头部)、Payload(负载)、Signature(签名)三个部分。Header(头部)包含签名算法和token类型等信息；Payload(负载)用来存放实际需要传递的数据，一般包含token编号、用户名、用户包含角色、过期时间、生效时间等；Signature(签名)是由token签发者使用自己独自持有的私钥和Header中标识的签名算法，对前两部分(的散列值)签名，防止数据篡改。任何持有私钥对应公钥的程序可以验证token中签名部分，验证通过则可以证明token确实是签发者签发的，并且没有被篡改。

进一步地，本发明中所述的签名(即数字签名，又称公钥数字签名)是只有信息的发送者才能产生的、别人无法伪造的一段数字串，这段数字串同时也是对信息的发送者发送信息真实性的一个有效证明。它是一种类似写在纸上的普通的物理签名，但是在使用了公钥加密领域的技术来实现的、用于鉴别数字信息的方法。一套数字签名通常定义两种互补的运算，一个用于签名，另一个用于验证。数字签名是非对称密钥加密技术与数字摘要技术的应用。

以前文背景技术中所述的现有方法2为例，请参阅图3，该方法2具体包括如下步骤。

1、首先用户以用户名、密码或生物识别等方式登录业务系统的认证服务，业务系统的认证服务验证用户名、密码或生物等信息后，使用私钥签发token(令牌)，token中含有签名，将token返回给用户。

2、用户携带此token，提交事务到业务系统中(向业务系统发送提交事务请求)。业务系统首先拦截提交事务请求，用业务系统的认证服务预先分发的公钥，来验证token中的签名。私钥、公钥是一对非对称加密算法的秘钥，公钥可以验证私钥签名过的token，若验证通过，则业务系统认可此token，也可以证实交易提交人(提交交易事务的用户)是认证系统认证过的真实用户。

3、区块链网络将业务系统作为一个客户端，也为其事先分配了区块链成员身份信息。需要注意的是，这里是将身份信息分配给业务系统，而不是直接分配给交易提交人。

4、业务系统使用预先分配的区块链成员身份信息，连接区块链应用程序，让区块链应用程序代理其发送交易数据(即用户提交的事务的数据)到区块链网络中，执行智能合约，由区块链应用程序代理为该交易数据找到足够数量的背书节点进行背书，然后收集足够数量的背书过的交易读写集，打包发送给排序节点，等待排序节点排序、出块后广播到记账节点(区块链账本所在节点)，等待区块链账本完成校验并记账，完成这一套完整的过程。

在上述智能合约获取交易数据的过程中，遇到的问题就是业务系统中token无法传递到智能合约中，智能合约无法校验业务系统token有效性，也就无法确认记录到区块链账本中的交易提交人的身份。对上链数据的真实性无法自主验证。所以这里只能无条件地信任业务系统的校验结果，并且信任业务系统自身以及传输过程中，交易数据、交易提交人身份没有被篡改。

本发明在此基础上进行的改进之一，其主旨在于，扩展业务系统token的作用域，覆盖完整业务系统以及区块链系统。请参阅图1，具体包括如下步骤。

步骤一S1，首先事先将要进行操作的机构的业务系统认证服务的私钥对应的公钥，作为区块链网络中智能合约的初始化数据提交到区块链账本中。

步骤二S2，用户在业务系统认证服务登录并获取业务系统的token，提交事务到业务系统中，业务系统校验token。这部分过程与前述现有方法一致，即，具体包括：

步骤S21，用户登录业务系统的认证服务，业务系统的认证服务验证用户信息后，使用私钥签发token，token中含有签名，将token返回给用户。

步骤S22，用户携带此token，提交交易事务到业务系统中(向业务系统发送提交事务请求)。

步骤S23，业务系统首先拦截提交事务请求，用业务系统的认证服务预先分发的公钥，来验证token中的签名，若验证通过则继续后续步骤。

步骤三S3，业务系统将交易提交人(提交交易事务的用户)的token透传，并组装业务交易数据(将用户token和业务交易数据进行组装)，组装后一起发送至区块链应用程序。

步骤四S4，区块链应用程序继续透传包含交易提交人token的业务交易数据发送到区块链网络(对应的区块链节点)，最终在区块链背书节点和记账节点上执行智能合约。

步骤五S5，在区块链网络(对应的区块链节点)中执行智能合约时，对token进行解析。需要说明的是，本方案暂且仅针对token携带payload的情况进行实施及详细介绍，如果token不携带payload，则笼统而言可以通过例如调用业务系统认证服务，使用token获取机构信息，从而获取payload，但实际情况会较为复杂，在此不进行详细介绍；

解析token时的步骤具体例如，先从token中的payload中解析出机构名，然后从区块链账本中获取事先存证的(步骤一S1所提交的)该机构的公钥，使用该公钥再次解析并验证token中签名的有效性(验签)，验证通过则信任此token中payload内容，并将交易提交人的用户名认定为真正提交人，提交交易到区块链账本中。

还可以在需要时进行步骤六S6，如果需要进行生命周期维护交易，也就是更换、吊销各现有机构或增加新加入机构的业务系统认证服务使用的私钥对应的公钥，只需要将这些生命周期维护交易视为普通业务交易一样，智能合约也要用上述相同的办法，验证私钥签发的token，并最终提交至记账节点记录到区块链账本中。

进一步地，请参阅图2，本发明优选还包括如下改进：

除了认证交易提交人身份，还要认证业务系统身份。因此也要事先生成公私钥对，将私钥由业务系统自己保存，将公钥像执行普通业务交易一样，验证操作人身份，并将业务系统公钥提交区块链账本进行记账。

在步骤三S3中，在组装业务交易数据后、访问区块链应用程序前，再使用业务系统的私钥，再次对组装的交易数据进行二次签名。

在步骤四S4后，执行到智能合约时，首先使用业务系统的公钥对整个组装的交易数据进行验证token签名有效性。验签通过后，再进行步骤五S5对交易提交人身份进行验签。

需要说明的是，如果有多个业务系统，对应同一套区块链网络，也可采用本发明的方法，只是需要每套业务系统在执行业务交易前，生成两对公私钥对，私钥分别由业务系统的认证服务和业务系统本身各自持有，公钥均通过上述步骤六S6(或步骤一S1)提交到区块链账本中记录备用。本发明方案采用非对称加密。对称加密算法在加密和解密时使用的是同一个秘钥，而非对称加密算法需要两个密钥来进行加密和解密，这两个密钥是公开密钥(public key，简称公钥)和私有密钥(private key，简称私钥)。

非对称加密的过程及原理为：

1、乙方生成一对密钥(公钥和私钥)并将公钥向其它方公开。

2、得到该公钥的甲方使用该密钥对机密信息进行加密后再发送给乙方。

3、乙方再用自己保存的私钥对加密后的信息进行解密。乙方只能用其专用密钥(私钥)解密由对应的公钥加密后的信息。

在传输过程中，即使攻击者截获了传输的密文，并得到了乙方的公钥，也无法破解密文，因为只有乙的私钥才能解密密文。

同样，如果乙方要回复加密信息给甲方，那么需要甲方先公布甲方的公钥给乙方用于加密，甲方自己保存甲方的私钥用于解密。发送报文时，发送方用一个散列函数从报文文本中生成报文摘要，然后用发送方的私钥对这个摘要进行加密，这个加密后的摘要将作为报文的数字签名和报文一起发送给接收方，接收方首先用与发送方一样的散列函数从接收到的原始报文中计算出报文摘要，接着再公钥来对报文附加的数字签名进行解密，如果这两个摘要相同、那么接收方就能确认该报文是发送方的。

数字签名有两种功效：一是能确定消息确实是由发送方签名并发出来的，因为别人假冒不了发送方的签名；二是数字签名能确定消息的完整性，因为数字签名的特点是它代表了文件的特征，文件如果发生改变，数字摘要的值也将发生变化，不同的文件将得到不同的数字摘要，一次数字签名涉及到一个散列函数、接收者的公钥以及发送方的私钥。

本发明改进重点是利用智能合约，将普通业务交易和公钥管理交易一视同仁，都需要在区块链智能合约中进行交易提交人的身份自主验证，以自主验证并获取到的身份作为记录提交到区块链账本中。并且对原业务系统几乎没有改造。总结而言，本发明主要利用了签名、验签机制(包括用到了非对称加密、散列算法、数字签名技术)、区块链中智能合约的自动隔离执行特性(确保对执行过程不受外界干扰，对执行逻辑无异议，满足条件即执行)、区块链账本数据不可篡改的特性(公钥已经提交到区块链账本中)、区块链分布式特性(信任各方提交的数据)，从而确保了数据记录的提交人身份是真实的，提高了区块链应用程序记录的真实性，解决了从业务系统到区块链系统间事务链的消息防篡改难题、消息防抵赖难题，以及联合审计方法不能满足上链内容的一致性、完整性的难题。

Claims (6)

1.一种区块链智能合约中获取真实交易提交人信息的方法，其特征在于，包括：

步骤一，事先将要进行操作的机构的业务系统认证服务使用的私钥所对应的公钥作为区块链网络中智能合约的初始化数据提交到区块链账本中；

步骤二，用户在业务系统认证服务登录并获取业务系统的token，提交交易事务到业务系统中，业务系统校验token；

步骤三，业务系统将交易提交人的token透传，并和业务交易数据组装后一起发送至区块链应用程序；

步骤四，区块链应用程序继续透传包含交易提交人token的业务交易数据发送到区块链网络，最终在区块链背书节点和记账节点上执行智能合约；

步骤五，在区块链网络中执行智能合约时，对token进行解析；解析token时，先从token中的payload中解析出机构名，然后从区块链账本中获取步骤一所提交的该机构的公钥，使用该公钥再次解析并验证token中签名有效性，验证通过则信任此token中payload内容，并将交易提交人的用户名认定为真正提交人，提交交易到区块链账本中。

2.如权利要求1所述的区块链智能合约中获取真实交易提交人信息的方法，其特征在于，还包括步骤六，在进行生命周期维护交易时，将生命周期维护交易视为普通业务交易一样，智能合约采用相同方法验证私钥签发的token，并最终提交至记账节点记录到区块链账本中。

3.如权利要求1所述的区块链智能合约中获取真实交易提交人信息的方法，其特征在于，在步骤三中，在组装业务交易数据后、访问区块链应用程序前，还包括使用业务系统的私钥，对组装的交易数据进行二次签名。

4.如权利要求3所述的区块链智能合约中获取真实交易提交人信息的方法，其特征在于，在步骤四S4后，执行到智能合约时，首先使用业务系统的公钥对整个组装的交易数据进行验证token签名有效性；验证通过后再进行步骤五。

5.如权利要求1-4中任意一项所述的区块链智能合约中获取真实交易提交人信息的方法，其特征在于，若存在多个业务系统对应同一套区块链网络，则在每个业务系统执行业务交易前，生成两对公私钥对，私钥分别由业务系统的认证服务和业务系统本身各自持有，公钥都提交到区块链账本中记录备用。

6.如权利要求1-4中任意一项所述的区块链智能合约中获取真实交易提交人信息的方法，其特征在于，步骤二包括：

用户登录业务系统的认证服务，业务系统的认证服务验证用户信息后，使用私钥签发token，token中含有签名，将token返回给用户；

用户携带此token，提交事务到业务系统中；

业务系统首先拦截提交事务请求，用业务系统的认证服务预先分发的公钥，来验证token中的签名，若验证通过才继续进行后续步骤三。

Images