CN109523385A - 在区块链网络中查询交易信息的方法、记账节点和介质 - Google Patents

Abstract

本公开提供了一种在区块链网络中查询交易信息的方法、记账节点和介质。所述区块链网络包括记账节点子网络和业务节点子网络。所述方法由记账节点子网络中的一个记账节点执行。所述方法包括：接收业务节点对数据区块中的交易信息的查询请求；从业务节点与区块链运营方的智能合约中，获取该业务节点的权限数据；如果根据该业务节点的权限数据确定该业务节点对该交易信息有查询权限，向该业务节点返回该交易信息，反之，向该业务节点返回该交易信息的哈希值。本公开实施例能够在共享信息达成共识的基础上，对上链的数据进行隐私保护。

Description

在区块链网络中查询交易信息的方法、记账节点和介质

技术领域

本公开涉及区块链领域，具体涉及一种在区块链网络中查询数据区块中的交易信息的方法、记账节点和介质。

背景技术

传统的区块链网络分为两种。第一种区块链网络中，每个记账节点同时又是交易发生从而需要将交易信息上链的节点。第二种区块链网络中，记账节点只负责向区块链上记账，即数据上链，实际发生交易、需要交易信息上链的节点在记账节点之外。当需要交易信息上链时，需要交易信息上链的节点将需要上链的交易信息发给对应的记账节点，由记账节点将交易信息上链。

在第一种区块链网络中，每个需要交易信息上链的节点就是记账节点，其能看到区块链上上链的每个数据区块的详细信息，在有些企业不想让自己的交易信息被不相关企业查询到时无能为力。在第二种区块链网络中，需要查询区块链上的数据区块信息的节点通过对应的记账节点在区块链上进行查询，由于所有记账节点都有权限查询区块链上的所有数据区块中的详细信息，需要查询区块链上的数据区块信息的节点能够查询到区块链上的所有数据区块中的详细信息，对于需要上链信息保密的企业来说无法做到信息保密。

现有技术缺少一种能够在共享信息达成共识的基础上，对上链的数据进行隐私保护的方案。

发明内容

本公开的一个目的在于提出一种能够在共享信息达成共识的基础上，对上链的数据进行隐私保护的方法、记账节点和介质。

根据本公开实施例的一方面，公开了一种在区块链网络中查询数据区块中的交易信息的方法，所述区块链网络包括记账节点子网络和业务节点子网络，所述记账节点子网络包括将数据区块记录到区块链上的记账节点，所述业务节点子网络包括对记账节点记录到区块链上的数据区块进行验证的业务节点，所述方法由记账节点子网络中的一个记账节点执行，所述方法包括：接收业务节点对数据区块中的交易信息的查询请求；从业务节点与区块链运营方的智能合约中，获取该业务节点的权限数据；如果根据该业务节点的权限数据确定该业务节点对该交易信息有查询权限，向该业务节点返回该交易信息，反之，向该业务节点返回该交易信息的哈希值。

根据本公开实施例的一方面，公开了一种在区块链网络中查询数据区块中的交易信息的记账节点，所述区块链网络包括记账节点子网络和业务节点子网络，所述记账节点子网络包括将数据区块记录到区块链上的记账节点，所述业务节点子网络包括对记账节点记录到区块链上的数据区块进行验证的业务节点，所述方法包括：查询请求接收单元，用于接收业务节点对数据区块中的交易信息的查询请求；权限数据获取单元，用于从业务节点与区块链运营方的智能合约中，获取该业务节点的权限数据；交易信息返回单元，用于如果根据该业务节点的权限数据确定该业务节点对该交易信息有查询权限，向该业务节点返回该交易信息，反之，向该业务节点返回该交易信息的哈希值。

根据本公开实施例的一方面，公开了一种记账节点，包括：存储器，存储有计算机可读指令；处理器，读取存储器存储的计算机可读指令，以执行如上所述的方法。

根据本公开实施例的一方面，公开了一种计算机程序介质，其上存储有计算机可读指令，当所述计算机可读指令被计算机的处理器执行时，使计算机执行如上所述的方法。

本公开实施例中，记账节点子网络与业务节点子网络是分开的。数据区块在上链之前在记账节点之间进行共识，并记录在区块链上，但实际有交易发生需要交易信息上链的业务节点是在记账节点子网络外的，其通过记账节点进行交易信息上链。因而，在业务节点间不会发生共识，因而不会互相看见其它业务节点上链、但需要隐私保护的信息。另外，当业务节点向记账节点查询数据区块中的交易信息时，记账节点根据其与区块链运营方的智能合约中的权限数据，来确定哪些交易信息可以返回给该业务节点，哪些交易信息不能返回给该业务节点，从而保证上链信息的隐私性。在不能给业务节点返回交易信息的情况下，向业务节点返回交易信息的哈希值，从而保证业务节点在不了解该交易信息的详细内容的前提下，却可以对数据区块是否被篡改进行验证，实现了对记账节点记账的监督。

本公开的其他特性和优点将通过下面的详细描述变得显然，或部分地通过本公开的实践而习得。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性的，并不能限制本公开。

附图说明

通过参照附图详细描述其示例实施例，本公开的上述和其它目标、特征及优点将变得更加显而易见。

图1A-1C示出了根据本公开一个实施例的在区块链网络中查询数据区块中的交易信息的方法的三种体系构架图。

图2A-2C示出了根据本公开一个实施例的在区块链网络中查询数据区块中的交易信息的方法应用在供应链金融、电子***、法定数字货币三种不同的应用场景下的场景构架图。

图3A-3G示出了根据本公开一个实施例的在区块链网络中查询数据区块中的交易信息的方法应用在供应链金融应用场景下的业务节点显示界面图，这些界面图表示了供应链金融应用场景下从交易信息上链到查询交易信息并验证数据区块内容的大体过程。

图4A-4G示出了根据本公开一个实施例的在区块链网络中查询数据区块中的交易信息的方法应用在电子***应用场景下的业务节点显示界面图，这些界面图表示了电子***应用场景下从交易信息上链到查询交易信息并验证数据区块内容的大体过程。

图5A-5G示出了根据本公开一个实施例的在区块链网络中查询数据区块中的交易信息的方法应用在法定数字货币应用场景下的业务节点显示界面图，这些界面图表示了法定数字货币应用场景下从交易信息上链到查询交易信息并验证数据区块内容的大体过程。

图6示出了根据本公开一个实施例的在区块链网络中查询数据区块中的交易信息的方法的流程图。

图7示出了根据本公开一个实施例的在区块链网络中查询数据区块中的交易信息的方法的流程图。

图8示出了根据本公开一个实施例的在区块链网络中查询数据区块中的交易信息的方法的流程图。

图9示出了根据本公开一个实施例的在区块链网络中查询数据区块中的交易信息的方法的流程图。

图10示出了根据本公开一个实施例的在区块链网络中查询数据区块中的交易信息的方法的流程图。

图11示出了根据本公开一个实施例的确定所述在区块链网络中查询数据区块中的交易信息的方法的记账节点的流程图。

图12示出了根据本公开一个实施例的图11中步骤430的详细流程图。

图13示出了根据本公开一个实施例的图12中步骤4303的详细流程图。

图14示出了根据本公开一个实施例的确定所述在区块链网络中查询数据区块中的交易信息的方法的记账节点的流程图。

图15示出了根据本公开一个实施例的图14中步骤530的详细流程图。

图16示出了根据本公开一个实施例的在区块链网络中查询数据区块中的交易信息的记账节点的模块框图。

图17示出了根据本公开一个实施例的记账节点的硬件结构图。

具体实施方式

现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些示例实施方式使得本公开的描述将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。附图仅为本公开的示意性图解，并非一定是按比例绘制。图中相同的附图标记表示相同或类似的部分，因而将省略对它们的重复描述。

此外，所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多示例实施方式中。在下面的描述中，提供许多具体细节从而给出对本公开的示例实施方式的充分理解。然而，本领域技术人员将意识到，可以实践本公开的技术方案而省略所述特定细节中的一个或更多，或者可以采用其它的方法、组元、步骤等。在其它情况下，不详细示出或描述公知结构、方法、实现或者操作以避免喧宾夺主而使得本公开的各方面变得模糊。

附图中所示的一些方框图是功能实体，不一定必须与物理或逻辑上独立的实体相对应。可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。

下面先参照图1A-1C描述一下本公开实施例所应用的体系构架和整体流程。

图1A示出了本公开实施例所应用的一种区块链网络的体系构架。区块链网络包括记账节点子网络2和业务节点子网络1。记账节点子网络2包括将数据区块记录到区块链上的记账节点21。业务节点子网络1包括对记账节点记录到区块链上的数据区块进行验证的业务节点11。记账节点子网络2和业务节点子网络1之间通过代理节点12连接。代理节点12是业务节点子网络1的一个业务节点，但是比较特殊的一个业务节点。它负责将记账节点21要向业务节点11传递的信息传递给业务节点11。业务节点11是产生各种需上链的交易信息的交易方的终端。它们产生了交易信息，但没有权利直接记录到区块链上，必须通过一个记账节点21将交易信息记录到区块链上。由少数记账节点21统一记账，也有利于事务的统一处理和监管，而业务节点11能够通过记账节点21经由代理节点12发送来的信息进行交易信息上链的监督和见证。这在某些既需要统一监管、但又怕监管的节点集体作弊因而需要民众监督的场景中有十分重要的意义。记账节点子网络2中，每个记账节点21产生一个数据区块后，广播到其它记账节点21进行共识，然后进行上链。图1A中，业务节点子网络1采用P2P网络模式。P2P网络是一种在对等者(Peer)之间分配任务和工作负载的分布式应用架构，是对等计算模型在应用层形成的一种组网或网络形式，即“点对点”或者“端对端”网络。其可以定义为：网络的参与者共享他们所拥有的一部分硬件资源(处理能力、存储能力、网络连接能力、打印机等)，这些共享资源通过网络提供服务和内容，能被其它对等节点直接访问而无需经过中间实体。在此网络中的参与者既是资源、服务和内容的提供者，又是资源、服务和内容的获取者。因此，在业务节点子网络1中，当代理节点12接收到从记账节点21传递过来的消息，向周围的业务节点11传播。周围的业务节点11接收到该消息，再向其周围的业务节点11传递，层层传播，达到了该消息在业务节点子网络1的每个业务节点11的传播。

图1B示出了本公开实施例所应用的另一种区块链网络的体系构架。该体系构架与图1A的体系构架不同之处在于，在业务节点子网络1中，没有采取P2P网络模式，采取广播网络的模式。代理节点12接收到从记账节点21传递过来的消息，将该消息广播到业务节点子网络1中的其它业务节点11。这样，也实现了该消息在业务节点子网络1的每个业务节点11的传播。

图1C示出了本公开实施例所应用的另一种区块链网络的体系构架。该体系构架与图1A的体系构架不同之处在于，其记账节点子网络2分成了多个分支记账节点子网络。每个分支记账节点子网络可以负责某一种类型的交易信息的记录。例如，某一企业可能具有供应链金融业务，可能需要将供销过程中产生的合同信息、货款赊欠等信息记录到区块链上，同时该企业还要开具***，也要把开票信息、***报销信息等记录到区块链上。这时，为了有利于记账节点被同一部门监管的需要，可能记录供应链金融业务交易的记账节点和记录***流转过程中的交易的记账节点要分属于不同部门。例如，记录供应链金融业务交易的记账节点是银行设置的记账终端，而记录***流转过程中的交易的记账节点是国税局设置的记账终端。而供应链金融业务交易和记录***流转过程中的交易可能也最终会记录在不同的子区块链上。这时，代理节点12要根据从业务节点11发来的交易信息中携带的交易类型，将该交易信息发送到与该交易类型对应的分支记账节点子网络中。

图2A示出了根据本公开一个实施例的在区块链网络中查询数据区块中的交易信息的方法应用在供应链金融的应用场景下的场景构架图。

供应链金融是这样一种业务：制造企业生产一个设备或产品，往往不一定是自己的企业生产该设备或产品的所有零件或组成部分，其中一些零件或组成部分的生产需要外包到其它企业去生产。制造企业虽然与订货方提前订立了供销合同，但只有在生产出来整个设备或产品时才能够拿到货款，而在这个过程中采购零件或组成部分的钱需要自己垫付，造成制造企业***困难。因此，产生了这样一种需求，即制造企业可以凭整个设备或产品订立的总采购合同(其中有价款和订购方信息)到银行进行担保，当需要进行零件或组成部分的采购时，以在银行担保过的整个设备或产品的总采购合同为依据，从该设备或产品的总采购合同中价款中划转出一部分用于该零件或组成部分的采购的担保。这样，生成零件或组成部分的企业可以放心进行该零件或组成部分的生产，由于由银行担保，不用担心该划转出的一部分货款收不到。同时，制造企业此时并没有真正拿出这笔钱，而是等到得到整个设备或产品的采购方的实际货款时才将相应一部分付给零件或组成部分的生产商。

在传统的区块链网络中，由于由银行设置了所有的记账节点，而这个网络是封闭的，供销链上的各节点企业是与供应链金融的数据区块上链利益相关的节点，却不能监督和见证，只能完全信任这个利益无关方的由记账节点组成的记账网络。例如，制造企业与整个设备或产品的订购方订立了总采购合同，或者与零件或组成部分的生成方签订了分采购合同，都需要将这些合同传给银行设置的记账节点上链。这时，银行设置的各记账节点可以互相监督和见证，但供销链上的各节点企业却不能监督和见证。另外，在传统的区块链网络中，与当前供销链无关的其它任何企业节点，也可能通过对应的记账节点查询到当前供销链上的企业节点上链的任何交易信息。因此，带来了极大的交易信息泄露隐患。

然而，在图2A中，由于记账节点子网络2与业务节点子网络1分开，记账节点子网络2专用于记账，而业务节点子网络1包含了供销链上的各节点企业终端，对记账节点21的记账进行见证。一旦记账节点21集体作弊，见证的各业务节点11会保留有具体记账节点作恶的证据。同时，业务节点需要查询交易信息时，不是所有的交易信息都可以向该业务节点返回，而是根据其与区块链运营方的智能合约中该业务节点的权限数据，确定是否向该业务节点返回交易数据。这样，与当前供销链无关的其它任何企业节点就不能查询到当前供销链上的企业节点上链的任何交易信息,消除了交易信息泄露隐患。

在一个汽车供应链金融的例子中，如图2A所示，各业务节点11包括汽车制造商终端、轮胎制造商终端、橡胶生产商终端、车零部件供应商终端、银行终端等。汽车制造商与汽车订购方订立了总采购合同，从总采购合同的价款中拨出一部分用于轮胎的采购，再拨出相应的部分用于车零部件的采购。轮胎制造商以与汽车制造商订立的合同为依据，再从该合同的价款中拨出一部分用于制造轮胎所需橡胶的采购。这样，就建立起了层层采购关系。

当汽车制造商与汽车订购方订立了总采购合同，或者汽车制造商与轮胎制造商、车零部件供应商订立分采购合同，或者轮胎制造商与橡胶生产商订立分采购合同时，将相应的交易信息传递给代理节点12，由代理节点12选择一个记账节点21。代理节点12将相应的交易信息发送给选择的记账节点21缓存。记账节点21一般不会单独为一条交易信息打包成一个数据区块上链，而是按照区块打包要求(例如凑齐足够的条数或大小)，打包成一个数据区块。事先给每个记账节点分配签名用的密钥，该密钥是特定于该记账节点的。记账节点21利用特定于该记账节点的密钥，基于要添加到区块链上的一个数据区块中所要包括的交易信息，生成签名。生成签名的方法是先对数据区块中的交易信息生成摘要，再用特定于该记账节点的密钥对摘要利用签名算法签名。记账节点21将所述交易信息和生成的签名加入所述数据区块，在所有记账节点21之间进行共识后上链，同时将签名通过代理节点12发送到业务节点子网络中的每个业务节点11。

与签名同时发送到各业务节点11的还可以有数据区块中的交易信息，或者交易信息的摘要。

在同时发送交易信息的情况下，业务节点11获取特定于记账节点的密钥。在非对称公私钥对的情况下，记账节点21在记账的过程中采用的密钥是由认证中心(CA)分配给记账节点21的私钥。在分配私钥的同时，还为记账节点21分配一个公钥。该公钥存储在认证中心。业务节点11就可以从认证中心请求到为该记账节点21分配的公钥。这个公钥就是业务节点11获取到的特定于记账节点的密钥。业务节点11用该密钥对所述签名进行解密，得到所述数据区块中的交易信息的摘要。业务节点11对同时接收到的所述数据区块中的交易信息计算摘要。如果计算出的摘要与解密得到的摘要一致，则签名验证成功。

在同时发送交易信息的摘要(例如摘要和签名放在区块头中一起发送)的情况下，业务节点11获取特定于该记账节点的密钥，例如从认证中心请求到为该记账节点21分配的公钥。业务节点11用特定于该记账节点的密钥对所述签名进行解密，得到所述数据区块中的交易信息的摘要。如果与签名同时接收到的摘要与解密得到的摘要一致，则签名验证成功。

在同时发送交易信息的摘要(例如摘要和签名放在区块头中一起发送，该摘要可以是根据该数据区块中要包括的每条交易信息的哈希值计算出的默克尔树根)的情况下，业务节点11是接收不到每个交易信息的。业务节点11要查看交易信息时，需要向记账节点21请求。每个业务节点11都和区块链运营方签订有智能合约，智能合约中有业务节点的权限数据。根据该业务节点11的权限数据，对于该数据区块中该业务节点有权获取的交易信息，向该业务节点11返回该交易信息。对于该数据区块中该业务节点11无权获取的交易信息，仅向该业务节点11返回该交易信息的哈希值。这样，就达到了一些单位不希望自己的交易信息被无关方看到的目的，提高了上链交易信息的隐私性。由于默克尔树根仅凭每条交易信息的哈希值就可以计算出，这样，就达到既隐藏信息又不影响数据区块中的内容验证的目的。该业务节点11可以对获取到的非隐藏的交易信息计算哈希值，根据这些哈希值和接收到的隐藏的交易信息的哈希值计算出默克尔树根，与区块头中包含的默克尔树根比较，如果一致，则说明数据区块的内容没有被篡改，内容验证通过。而业务节点11也可以接收到的从非隐藏的交易信息中验证该交易信息是否与自己发给记账节点21的交易信息一致。如不一致，说明业务节点11作恶，达到了监督的目的。

下面结合图3A-3G说明供应链金融应用场景下从交易信息上链到查询并验证的大体过程。图3A-3G是根据本公开一个实施例的在区块链网络中查询数据区块中的交易信息的方法应用在供应链金融应用场景下的业务节点显示界面图。

如图3A所示，B汽车厂以A销售商采购B汽车厂1000万采购订单为基础，用1000万中的200万作保，委托C轮胎厂生产200万售价的轮胎。B汽车厂的业务员在B汽车厂的业务节点11录入以上交易信息后，点击“提交到记账节点”选项，交易信息通过代理节点12发送到记账节点21。记账节点21将要添加到区块链上的一个数据区块中所要包括的交易信息放在一个区块体中。记账节点21还生成这些交易信息的摘要，如图3B的默克尔树根。记账节点21还利用特定于该记账节点的密钥，基于该数据区块中的交易信息，生成签名。将默克尔树根、签名以及区块链上前一数据区块的摘要一同放在区块头中。区块头和区块体组成上链的数据区块，经所有记账节点21共识后上链。

记账节点21还将区块头发送到每个业务节点11。在业务节点11的屏幕上显示默克尔树根、签名以及区块链上前一数据区块的摘要，如图3B所示。这时，记账节点21就获取特定于该记账节点的密钥(例如通过请求认证中心)，用特定于该记账节点的密钥对所述签名进行解密，得到所述数据区块中的交易信息的摘要，即默克尔树根。如果接收到的区块头中的默克尔树根与解密得到的默克尔树根不一致，则签名验证失败，显示如图3C所示的界面。如果接收到的区块头中的默克尔树根与解密得到的默克尔树根一致，则签名验证成功，显示如图3D所示的界面。由于在以上的过程中，业务节点11仅获得了数据区块的区块头，还没有获得区块头中的交易信息。此时，在图3D的界面中询问用户是否请求该数据区块中的交易信息。

如果用户选择“是”，业务节点11通过代理节点12向记账节点21请求交易信息。记账节点21从业务节点与区块链运营方的智能合约中，获取该业务节点的权限数据。对于该数据区块中该业务节点11有权获取的交易信息，向该业务节点11返回该交易信息，如图3E中交易信息ID 000083的具体信息、交易信息ID 000153的具体信息；对于该数据区块中该业务节点11无权获取的交易信息，如交易信息ID 000258的交易信息、交易信息ID 000256的交易信息、交易信息ID 078365的交易信息、交易信息ID 018387的交易信息，仅向给业务节点11返回哈希值，如图3E所示。

当用户在图3E的界面上选择“进行内容验证”后，对于图3E中交易信息ID 000083的具体信息、交易信息ID 000153的具体信息，业务节点11计算其哈希值，然后再与接收到的交易信息ID 000258的交易信息的哈希值、交易信息ID 000256的交易信息的哈希值、交易信息ID 078365的交易信息的哈希值、交易信息ID 018387的交易信息的哈希值一起，计算出默克尔树根，与区块头中包含的默克尔树根进行比较，从而进行内容验证。如果记账节点21篡改过数据区块的内容，则计算出的默克尔树根与区块头中包含的默克尔树根不一致，显示如图3F所示的“内容验证失败”的界面。如果计算出的默克尔树根与区块头中包含的默克尔树根一致，显示如图3G所示的“内容验证成功”的界面。

图2B示出了根据本公开一个实施例的在区块链网络中查询数据区块中的交易信息的方法应用在电子***的应用场景下的场景构架图。

在传统的电子***的区块链应用场景中，地税局向开票企业发放***，开票企业向领票人开出***，领票人向领票人所在的报销单位报销***。所有这些交易都需要上链，即记录到区块链上。但是，地税局、开票企业、报销单位这些节点不是记账节点21。它们要委托对应的记账节点或超级节点将这些交易记录在区块链上。所有这些记账节点或超级节点都是国税部门统一设置的。它们之间可以互相监督和见证，但地税局、开票企业、报销单位这些节点是***的直接关系人，却不能监督和见证，只能完全信任记账节点21。另外，任何企业都可以通过其对应的记账节点查询区块链上任何交易信息。但在某些情况下，企业的***相关信息并不希望被其它企业获知。在本公开实施例中，由于记账节点子网络2与业务节点子网络1分开，记账节点子网络2专用于记账，而业务节点子网络1包含了这些***利益相关的节点，对记账节点21的记账进行见证。一旦记账节点21集体作弊，见证的各业务节点11会保留有具体记账节点作恶的证据。当任何一个业务节点1需要查询数据区块中的交易信息时，记账节点要根据其与区块链运营方的智能合约中的权限数据来判断该业务节点1是否有这样的权限。如果业务节点1有这样的权限，才能向其返回交易信息，反之则不返回交易信息。通过这种方法，保证了上链交易信息的隐私性。在业务节点没有权限的情况下，向该业务节点不返回交易信息，但返回交易信息的哈希值，从而保证业务节点利用哈希值同样可以对区块头中的默克尔树根进行验证，达到内容验证的目的。

在一个电子***的例子中，如图2B所示，各业务节点11包括开票单位终端、报销人手机、报销单位终端、地税局终端等。

当地税局为开票单位发放***，或者开票单位开出***，或者报销人到报销单位报销时，将相应的交易信息(***所有权的转移)传递给代理节点12，由代理节点12选择一个记账节点21。代理节点12将相应的交易信息发送给选择的记账节点21缓存。然后，记账节点21按照区块打包要求打包成数据区块。记账节点21基于数据区块中的交易信息，生成签名，将签名加入数据区块的区块头后上链并将签名发送给业务节点11，这些过程与结合图2A所示的过程类似。

与签名同时发送到各业务节点11的还可以有数据区块中的交易信息，或者交易信息的摘要。在同时发送交易信息的情况下和同时发送摘要的情况下，在业务节点11的签名验证方式不同，但在业务节点11处都能进行签名验证。这与上面结合图2A所示的过程类似，可以参照以上结合图2A所示的相关描述。另外，在同时发送交易信息的摘要的情况下，业务节点11可以进行数据区块的内容验证，验证过程也与上面结合图2A所示的过程类似，故不赘述。

图4A-4G示出了根据本公开一个实施例的在区块链网络中查询数据区块中的交易信息的方法应用在电子***应用场景下的业务节点显示界面图，这些界面图表示了电子***应用场景下交易信息上链、查询并验证的大体过程。

如图4A所示，在2018年10月22日，刘山到彩虹电脑公司为所在单位宏生公司购买一台电脑，花了3000元。彩虹电脑公司为刘山开具了一张***，交易ID为000083。彩虹电脑公司的工作人员录入以上信息后，点击“提交到记账节点”选项，交易信息通过代理节点12发送到记账节点21。记账节点21将要添加到区块链上的一个数据区块中所要包括的交易信息放在一个区块体中。记账节点21还生成默克尔树根和签名，将默克尔树根、签名以及区块链上前一数据区块的摘要一同放在区块头中。记账节点21将数据区块上链，并将区块头发送到每个业务节点11。在业务节点11的屏幕上显示默克尔树根、签名以及区块链上前一数据区块的摘要，如图4B所示。

然后，记账节点21进行签名验证，根据验证结果显示图4C或图4D的界面，并向记账节点21请求交易信息，显示图4E所示的获取的交易信息或交易信息的哈希值的界面，然后根据内容验证的验证结果，分别显示图4F-4G的界面。这些过程与图3C-3G所示的过程类似，故不赘述。

图2C示出了根据本公开一个实施例的在区块链网络中查询数据区块中的交易信息的方法应用在法定数字货币的应用场景下的场景构架图。

在传统的例如比特币的民间数字货币的场景以下，比特币的流转过程中的每一笔交易，都由交易的当事方进行上链。每个当事方既可以作为记账节点进行上链操作，也可以见证其它节点上链的数据区块。由于每个节点既作为记账节点，又作为见证节点，使得公众对于这种数字货币的使用比较信赖。然而，在法定数字货币的场景下，该数字货币由官方发行，必须由官方进行监管，而公众又需要对其信任，防止官方记账节点集体作弊，产生了现有网络体系面对政府监管和民众信任的平衡方面的问题。而且，现有比特币区块链网络中，每个节点既作为记账节点，又作为见证节点，这样每个节点的用户都能看到区块链上记录的所有交易信息，而有些单位的交易信息是不希望暴露给所有人的，又产生了隐私保护的问题。

在这种情况下，本公开实施例的记账节点子网络和业务节点子网络分开的方案，完全避免了这一问题。首先，记账节点子网络的每个记账节点属于官方。任一业务节点处发生了法定数字货币的交易，都要将该法定数字货币的交易通过对应的记账节点记录到区块链上。但是,业务节点子网络中的每个业务节点可以对记账节点21的记账进行见证。一旦记账节点21集体作弊，见证的各业务节点11会保留有具体记账节点作恶的证据，兼顾了政府监管和民众信任。同时，业务节点要想查询交易信息，要根据其与与区块链运营方的智能合约中的权限数据，判断其是否具有权限，只有在有权限时才向其返回交易信息，保证了上链交易信息的隐私性。在业务节点不具有权限时，虽然不向其返回交易信息，但返回交易信息的哈希值，通过该哈希值同样可以验证区块头中的默克尔树根，实现内容验证。

在一个法定数字货币的例子中，如图2C所示，各业务节点11包括法定数字货币流通中涉及的各个交易终端。当发送法定数字货币的交易信息时，交易终端将相应的交易信息(法定数字货币所有权的转移)传递给代理节点12，由代理节点12选择一个记账节点21。代理节点12将相应的交易信息发送给选择的记账节点21缓存。然后，记账节点21按照区块打包要求打包成数据区块。记账节点21基于数据区块中的交易信息，生成签名，将签名加入数据区块的区块头后上链并将签名发送给业务节点11，这些过程与结合图2A所示的过程类似。

与签名同时发送到各业务节点11的还可以有数据区块中的交易信息，或者交易信息的摘要。在同时发送交易信息的情况下和同时发送摘要的情况下，在业务节点11的签名验证方式不同，但在业务节点11处都能进行签名验证。这与上面结合图2A所示的过程类似，可以参照以上结合图2A所示的相关描述。另外，在同时发送交易信息的摘要的情况下，业务节点11可以进行数据区块的内容验证，验证过程也与上面结合图2A所示的过程类似，故不赘述。

图5A-5G示出了根据本公开一个实施例的在区块链网络中查询数据区块中的交易信息的方法应用在法定数字货币应用场景下的业务节点显示界面图，这些界面图表示了法定数字货币应用场景下记账和见证的大体过程。

如图5A所示，在2018年8月29日，因X公司从Y公司买入一台售价3000单位的法定数字货币的家具，付给Y公司人民币3000单位的法定数字货币。X公司的经办人录入以上信息后，点击“提交到记账节点”选项，交易信息通过代理节点12发送到记账节点21。记账节点21将要添加到区块链上的一个数据区块中所要包括的交易信息放在一个区块体中。记账节点21还生成默克尔树根和签名，将默克尔树根、签名以及区块链上前一数据区块的摘要一同放在区块头中。记账节点21将数据区块上链，并将区块头发送到每个业务节点11。在业务节点11的屏幕上显示默克尔树根、签名以及区块链上前一数据区块的摘要，如图5B所示。

然后，记账节点21进行签名验证，根据验证结果显示图5C或图5D的界面，并向记账节点21请求交易信息，显示图5E所示的获取的交易信息或交易信息的哈希值的界面，然后根据内容验证的验证结果，分别显示图5F-5G的界面。这些过程与图3C-3G所示的过程类似，故不赘述。

如图6所示，根据本公开的一个实施例，提供了一种在区块链网络中查询数据区块中的交易信息的方法。如图1A-1C所示，所述区块链网络包括记账节点子网络2和业务节点子网络1。所述记账节点子网络2包括将数据区块记录到区块链上的记账节点21。所述业务节点子网络1包括对记账节点记录到区块链上的数据区块进行验证的业务节点11。所述方法由记账节点子网络2中的一个记账节点21执行。所述方法包括：

步骤310、接收业务节点对数据区块中的交易信息的查询请求；

步骤320、从业务节点与区块链运营方的智能合约中，获取该业务节点的权限数据；

步骤330、如果根据该业务节点的权限数据确定该业务节点对该交易信息有查询权限，向该业务节点返回该交易信息，反之，向该业务节点返回该交易信息的哈希值。

在一个实施例中，上述步骤310-330可以作为一个独立的过程来执行，也就是说，它不依赖于交易信息的上链。也就是说，步骤310之前可以没有其它步骤。即使业务节点查询的交易信息根本没有上链，步骤310-330同样会执行，只是此时在步骤330中查询不到交易信息，向业务节点返回空消息而已。

在另一个实施例中，步骤310-330之前是有交易信息上链的步骤的。在该实施例中，在交易信息上链后，要将记账节点对交易信息生成的签名发送到业务节点，由业务节点对签名进行验证。在签名验证时，业务节点可能并没有得到整个的交易信息，可能仅得到了交易信息的摘要。根据摘要也可以进行签名验证。在验证通过后，业务节点可以立即请求查询该交易信息的详细信息，即向代理节点发送对交易信息的查询请求。代理节点接收到该查询请求后，转发到相应的记账节点，记账节点根据上述过程，基于业务节点的权限数据确定是否向其返回交易信息。

在步骤310-330之前有交易上链的步骤的情况下，也分成两种情况。一种情况是在交易上链后立即请求交易信息，另一种情况是在交易上链后业务节点不立即发出查询请求，而是响应于业务节点的用户输入查询指令，而发出所述查询请求。无论是哪种情况，在该实施例中，在步骤310之前，所述方法都包括：

利用特定于该记账节点的密钥，基于要添加到区块链上的一个数据区块中所要包括的交易信息，生成签名；

将所述交易信息和生成的签名加入所述数据区块，添加到区块链上；

将所述签名发往所述业务节点子网络中的业务节点，使业务节点根据特定于该记账节点的密钥对所述签名进行签名验证。

特定于记账节点的密钥是预先由认证中心为每个记账节点分配的、专用于其对交易信息进行签名所使用的密钥。一般来说，签名的过程是这样的：将待签名的消息施加摘要运算，得到待签名的消息的摘要，然后用签名使用的密钥对摘要加密，得到了签名。对签名进行验证时，需要利用解签名使用的密钥对签名解密，得到了待签名的消息的摘要，然后对待签名的消息重新施加同样的摘要运算，得到重新确定的摘要。如果解密后的摘要与重新确定的摘要一致，则签名验证成功。通过签名验证，能够验证出待签名的消息是否是签名者所发出的、以及消息是否完整。如果该消息不是签名者所发，或者消息在传输过程中丢失了一部分，签名验证均不通过。

签名使用的密钥和解签名使用的密钥可以相同，即对称密钥的情形，也可以不相同，即非对称密钥的情形。无论是哪种密钥，在一个实施例中，可以在每个记账节点设立时，由记账节点向认证中心请求该特定于该记账节点的密钥，由认证中心为记账节点生成该密钥并存储，然后发送到该记账节点。而业务节点在签名验证时，也向认证中心请求该特定于该记账节点的密钥，认证中心将该密钥发送给业务节点，供业务节点签名验证使用。

在一个实施例中，当业务节点11通过代理节点12向记账节点21发送交易信息时，代理节点12可以不急于将接收到的该交易信息作为要添加到区块链上的一个数据区块中所要包括的交易信息，对该交易信息施加签名算法，生成签名，而是将其放在缓存中，等待缓存中缓存了足够的交易信息，即达到了预设的区块打包要求(例如，缓存中的待上链交易信息的总大小达到预定大小阈值，缓存中的待上链交易信息的总条数达到预定条数阈值)时，才将其打在一个包中，生成签名，并上链。该实施例的好处是，提高数据区块的利用效率。在一个数据区块中，可能装有多条交易信息，避免区块链上的数据区块过多过于分散，也减少了区块链上链的工作负荷。

生成签名的签名算法如上所述，包括摘要算法和对摘要的加密。在一个实施例中，摘要是默克尔树根。在该实施例中，基于要添加到区块链上的一个数据区块中所要包括的交易信息，通过以下方式生成默克尔树根：

确定数据区块中的每个交易信息的哈希值；

将数据区块中的交易信息按照进入缓存的顺序排序，顺序排在第奇数位的交易信息和之后的顺序排在第偶数位的交易信息组成一个对；

将每个对的两个交易信息的哈希值进行哈希运算，得到该对的哈希值；

将各个对按照进入缓存的顺序排序，顺序排在第奇数位的对和之后的顺序排在第偶数位的对组成一个更上一级的对，将每个更上一级的对中的两个对的哈希值进行哈希运算，得到该更上一层的对的哈希值，直到得到最上一层的对的哈希值，即为默克尔树根。

在上述过程中，如果顺序排在第奇数位的交易信息是缓存中最后一个交易信息，则将该交易信息本身作为一个对；如果顺序排在第奇数位的对是缓存中最后一个对，将该对本身作为更上一级的对。

例如，缓存中有9条交易信息，按进入缓存的时间顺序分别是A1-A9，要放到数据区块中上链。A1-A2组成一个对B1，对A1的哈希值和A2的哈希值进行哈希值运算，得到B1的哈希值；A3-A4组成一个对B2，对A3的哈希值和A4的哈希值进行哈希值运算，得到B2的哈希值；A5-A6组成一个对B3，对A5的哈希值和A6的哈希值进行哈希值运算，得到B3的哈希值；A7-A8组成一个对B4，对A7的哈希值和A8的哈希值进行哈希值运算，得到B4的哈希值；A9本身是一个对B5，A9的哈希值就是B5的哈希值。

针对B1-B5,B1-B2组成一个更上层的对C1，对B1的哈希值和B2的哈希值进行哈希值运算，得到C1的哈希值；B3-B4组成一个更上层的对C2，对B3的哈希值和B4的哈希值进行哈希值运算，得到C2的哈希值；B5本身是一个对C3，B5的哈希值就是C3的哈希值。

针对C1-C3,C1-C2组成一个更上层的对D1，对C1的哈希值和C2的哈希值进行哈希值运算，得到D1的哈希值；C3本身是一个对D2，C3的哈希值就是D2的哈希值。

针对D1-D2，对D1的哈希值和D2的哈希值进行哈希值运算，得到默克尔树根。

在一个实施例中，数据区块分为区块头和区块体。区块体是数据区块的主体，其中包含有数据区块存储的交易信息。区块头是数据区块的头部，其不含有交易信息，而是含有辅助性信息，包括基于本数据区块中的所有交易信息计算出的摘要(例如默克尔树根)、签名以及前一数据区块的摘要。前一数据区块的摘要的作用是，由于每个数据区块中包括前一数据区块的信息，而该数据区块本身的摘要又包含在区块链上其后的数据区块中。这样，每个数据区块相互关联，一旦某一数据区块被篡改，其后一数据区块中包含的该数据区块的摘要就会与其不对应，从而识别出篡改，保证了区块链上存储信息的安全性。

数据区块上链后，将所述签名发往所述业务节点子网络中的业务节点，使业务节点根据特定于该记账节点的密钥对所述签名进行签名验证。

具体地，在数据区块中包含区块头和区块体的情形下，区块头中含有上述摘要和签名。在一个实施例中，可以将区块头发往所述业务节点子网络中的业务节点，使业务节点根据特定于该记账节点的密钥、接收到的区块头中的摘要对该区块头中的所述签名进行签名验证。

在一个实施例中，根据特定于该记账节点的密钥、接收到的区块头中的摘要对所述区块头中的签名进行签名验证的具体过程包括：

获取特定于该记账节点的密钥；

用特定于该记账节点的密钥对所述签名进行解密，得到所述数据区块中的交易信息的摘要；

如果接收到的摘要与解密得到的摘要一致，则签名验证成功。

获取特定于该记账节点的密钥可以采用以上所述的向认证中心发送密钥请求，从认证中心接收与该标识对应的特定于记账节点的密钥的方式，故不赘述。

如图7所示，在步骤310之前，所述方法还包括：

步骤301、生成业务节点与区块链运营方的智能合约；

步骤302、将生成的智能合约同步到记账节点子网络中的各记账节点存储。

该实施例中，步骤302包括：

步骤3201、从该记账节点存储的该业务节点与区块链运营方的智能合约中，获取该业务节点的权限数据。

该实施例中，每个业务节点与区块链运营方的智能合约都会存储在记账节点子网络中的各记账节点中。该实施例的好处是，由于智能合约都在各个记账节点本地存储，大大提高了向业务节点返回交易信息或哈希值的处理速度。

智能合约是存储着业务节点在查询交易信息方面的各种权限数据的合约，它是业务节点与区块链运营方事先订立的。权限数据包括允许查询的交易信息所属的业务节点权限、允许查询交易信息的每日允许时间段、允许查询的交易信息对应的交易类型。

允许查询的交易信息所属的业务节点权限是指对涉及哪些业务节点的交易信息有查询权限。交易信息所属的业务节点是指交易信息中交易双方的业务节点。例如，在电子***开票的交易中，开票单位的终端和领票人(报销人)的终端是该交易信息所属的业务节点，该开票的交易信息涉及的业务节点是开票单位的终端和领票人(报销人)的终端。例如，A节点与区块链运营方订立的智能合约中，规定允许查询的交易信息所属的业务节点权限是A节点，即只允许A节点查询涉及其自己的交易信息，则只要A节点是开票单位的终端和领票人(报销人)的终端中的一个，就认为对该交易信息有查询权限，否则没有查询权限。再例如，A节点与区块链运营方订立的智能合约中，规定允许查询的交易信息所属的业务节点权限是A节点和其下属单位节点，即A1节点，即只允许A节点查询涉及A节点和A1的交易信息，则只要A节点或A1节点是开票单位的终端和领票人(报销人)的终端中的一个，就认为对该交易信息有查询权限，否则没有查询权限。

允许查询交易信息的每日允许时间段是指允许每日的什么时间上链的查询交易信息。例如，A节点与区块链运营方订立的智能合约中规定，允许查询交易信息的每日允许时间段是9:00-17:00,则只有在每日9:00-17:00接收到A节点对数据区块中的交易信息的查询请求，才认为对交易信息有查询权限，否则没有查询权限。

所述权限数据包括允许查询的交易信息对应的交易类型。例如，可能同时在同一区块链上上链三种交易类型的交易信息，即供应链金融交易信息、电子***交易信息、法定数字货币交易信息。例如，A节点与区块链运营方订立的智能合约中规定，允许查询的交易信息对应的交易类型是电子***交易信息，只有当交易信息对应的交易类型是电子***交易信息时，A节点才有查询权限，否则没有查询权限。

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

发布合约模板，所述合约模板中含有合约函数；

接收利用所述合约函数设置的该业务节点的权限数据；

将所述权限数据整合到所述合约模板中，形成该业务节点与区块链运营方的智能合约。

合约模板是对于所有业务节点与区块链运营方的智能合约都适用于的合约样式。每个智能合约都可以套用该样式，只不过其中具体的权限数据不同而已。它是智能合约中除掉随着不同业务节点而不同的权限数据之后的格式段。合约函数是合约中设置的函数，用户通过调用该函数，可以设置不同的权限数据。发布合约模板可以包括向该记账节点发布合约模板，也可以包括向记账节点子网络中所有记账节点发布合约模板。在前者的情况下，操作该记账节点的管理员可以在审核业务节点的具体情况后，为该业务节点确定权限数据并输入该记账节点。在后者的情况下，任一个记账节点的管理员都可以在审核业务节点的具体情况后，为该业务节点确定权限数据并输入该记账节点。

审核的业务节点的具体情况包括业务节点运营属性数据等。业务节点运营属性数据是业务节点所属单位运营中表现出来的数据。在一个实施例中，它包括业务节点运营属性数据业务节点所属单位下属单位或管辖单位的业务节点、业务节点所属单位的每日工作时间段、业务节点所属单位的交易类型等。

每个业务节点是一个单位中的终端。业务节点所属单位就是该终端归属的单位。例如，***开票企业的一台电脑作为业务节点，其所述单位就是该***开票企业。该业务节点所属单位可能是它的分公司。另外，该业务节点所属单位可能是一个职能部门，其管辖单位就是该职能部门管辖的所有单位。例如，XX市地税局的管辖单位可以是XX市所有纳税单位。管理员可以将所述业务节点、以及该业务节点所属单位下属单位或管辖单位的业务节点确定为允许查询的交易信息所属的业务节点权限。例如，A公司由两个分公司A1、A2，可以将A、A1、A2确定为允许查询的交易信息所属的业务节点权限，即当交易信息的交易双方中出现A、A1、A2中的一个时，认为A公司具有对该交易信息的查询权限。

业务节点所属单位的每日工作时间段是指业务节点所属单位每日在哪个时间段工作。管理员可以将业务节点所属单位的每日工作时间段确定为允许查询交易信息的每日允许时间段。例如，A公司每天9:00-17:00上班，可以如果在9：00-17:00接收到A公司的查询请求，可以认为A公司具有对该交易信息的查询权限。

业务节点所属单位的交易类型是指业务节点所属单位从事何种交易。例如，该业务节点所属单位有供销链金融业务，则其交易类型包括供销链金融交易。例如，该业务节点所属单位用法定数字货币交易，则其交易类型包括法定数字货币交易。管理员可以将业务节点所属单位的交易类型确定为允许查询的交易信息对应的交易类型。例如，A公司从事供销链金融业务，如果接收到A公司对一个上链的供销链金融交易信息的查询请求，可以认为A公司具有对该交易信息的查询权限。

管理员确定权限数据后，就在记账节点利用所述合约函数设置该业务节点的权限数据，这样，该记账节点就接收到利用所述合约函数设置的该业务节点的权限数据，将所述权限数据整合到所述合约模板中，就形成了该业务节点与区块链运营方的智能合约。

该实施例的优点是，合约模板提供合约函数，让管理员根据业务节点的情况灵活设置权限数据，提高了权限数据设置的灵活性。

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

接收来自业务节点的智能合约生成请求，所述智能合约生成请求中含有业务节点运营属性数据；

根据所述业务节点运营属性数据，确定与所述业务节点运营属性数据对应的权限数据；

将所述权限数据整合到所述合约模板中，形成该业务节点与区块链运营方的智能合约。

该实施例中，业务节点要生成智能合约时，发送一个智能合约生成请求，所述智能合约生成请求中含有业务节点运营属性数据。记账节点接收该该智能合约生成请求后，根据所述业务节点运营属性数据，自动确定与所述业务节点运营属性数据对应的权限数据，并将自动确定的所述权限数据整合到所述合约模板中。

该实施例的优点是，实现了智能合约生成的自动化。

上述的自动确定权限数据的方法如下。

在一个实施例中，所述业务节点运营属性数据包括业务节点所属单位下属单位或管辖单位的业务节点，所述权限数据包括允许查询的交易信息所属的业务节点权限。所述根据所述业务节点运营属性数据，确定与所述业务节点运营属性数据对应的权限数据，包括：将所述业务节点、以及该业务节点所属单位下属单位或管辖单位的业务节点确定为允许查询的交易信息所属的业务节点权限。

该实施例与如上所述的管理员根据该业务节点所属单位下属单位或管辖单位的业务节点确定允许查询的交易信息所属的业务节点权限的方法类似，只不过它是由机器直接将接收到的智能合约生成请求中的该业务节点所属单位下属单位或管辖单位的业务节点、以及所述业务节点本身，直接确定为允许查询的交易信息所属的业务节点权限，实现了确定的自动化。

在一个实施例中，所述业务节点运营属性数据包括业务节点所属单位的每日工作时间段，所述权限数据包括允许查询交易信息的每日允许时间段。所述根据所述业务节点运营属性数据，确定与所述业务节点运营属性数据对应的权限数据，包括：将业务节点所属单位的每日工作时间段确定为允许查询交易信息的每日允许时间段。

该实施例与如上所述的管理员根据业务节点所属单位的每日工作时间段确定允许查询交易信息的每日允许时间段的方法类似，只不过它是由机器自动执行，实现了确定的自动化。

在一个实施例中，所述业务节点运营属性数据包括业务节点所属单位的交易类型，所述权限数据包括允许查询的交易信息对应的交易类型。所述根据所述业务节点运营属性数据，确定与所述业务节点运营属性数据对应的权限数据，包括：将业务节点所属单位的交易类型确定为允许查询的交易信息对应的交易类型。

该实施例与如上所述的管理员根据业务节点所属单位的交易类型确定允许查询的交易信息对应的交易类型的方法类似，只不过它是由机器自动执行，实现了确定的自动化。

在另一个实施例中，智能合约不是实现存储在记账节点子网络的每个记账节点中，而是也上链记录。这样，每个记账节点需要从智能合约中获取权限数据时，可以上链查找。该实施例的优点是，相比于每个记账节点内部维护一个数据库存储每个业务节点的智能合约，节省了节点内部存储空间的占用。

如图8所示，在该实施例中，在步骤310之前，所述方法包括：

步骤301、生成业务节点与区块链运营方的智能合约；

步骤303、将生成的智能合约加入与该业务节点对应的智能合约区块，记录在区块链上。

相应地，步骤320包括：

步骤3202、从区块链上与该业务节点对应的智能合约区块，获取该业务节点与区块链运营方的智能合约；

步骤3203、从该智能合约中，获取该业务节点的权限数据。

图8的步骤301与图7的步骤301相同，故不赘述。

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

将生成的智能合约与该业务节点标识对应存储在该智能合约区块的区块体；

对生成区块体施加摘要运算和签名运算，得到摘要和签名；

将所述摘要、签名以及区块链上前一区块的摘要，加入智能合约区块的区块头；

将该智能合约区块在记账节点子网络的所有记账节点间进行共识后，记录在区块链上。

业务节点标识的作用是便于在步骤3202中获取与业务节点对应的智能合约。

摘要和签名、以及区块链上前一区块的摘要的作用如前结合图2A-2C、图3A-3G、图4A-4G、图5A-5G所述，故不赘述。

关于智能合约区块在记账节点子网络的所有记账节点间进行共识，目前有很多共识算法，故不赘述。

相应地，步骤3202可以包括：

从区块链上记录的智能合约区块的区块体中，查找该业务节点的标识；

获取该区块体中与该标识对应的智能合约，作为该业务节点与区块链运营方的智能合约。

在一个实施例中，可以在智能合约区块的区块头上添加特定标识，依靠该特定标识可以从区块链上的所有数据区块中定位到智能合约区块。该实施例的优点是，相对于在所有数据区块中逐一搜索业务节点的标识，大大提高了搜索业务节点的智能合约的效率。

在步骤330中，在所述权限数据包括允许查询的交易信息所属的业务节点权限的情况下，所述根据该业务节点的权限数据确定该业务节点对该交易信息有查询权限，包括：

如果该交易信息中的交易双方至少有一方与允许查询的交易信息所属的业务节点权限匹配的情况下，确定该业务节点对该交易信息有查询权限。

该交易信息中的交易双方至少有一方与允许查询的交易信息所属的业务节点权限匹配，是指该交易信息中的交易双方至少有一方是允许查询的交易信息所属的业务节点中的一个。

例如，允许查询的交易信息所属的业务节点权限包括业务节点A、A1、A2。某一条交易信息是一个电子***开票交易信息，开票的双方即开票单位终端和报销人终端。如果开票单位终端和报销人终端中有一个终端是A，或者A1，或者A2，则确定该业务节点对该交易信息有查询权限。

在步骤330中，在所述权限数据包括允许查询交易信息的每日允许时间段的情况下，所述根据该业务节点的权限数据确定该业务节点对该交易信息有查询权限，包括：

如果该查询请求的接收时间在所述允许查询交易信息的每日允许时间段，确定该业务节点对该交易信息有查询权限。

例如，允许A节点查询交易信息的每日允许时间段为每日9:00-17:00，接收到A节点的查询请求的时间是15:03，则认为A节点对该交易信息有查询权限。

在步骤330，在所述权限数据包括允许查询的交易信息对应的交易类型的情况下，所述根据该业务节点的权限数据确定该业务节点对该交易信息有查询权限，包括：

如果所述查询请求中包含的交易类型是允许查询的交易信息对应的交易类型，确定该业务节点对该交易信息有查询权限。

例如，允许A节点查询的交易信息对应的交易类型由供应链金融交易和法定数字货币交易。A节点发出的查询请求中包含的交易类型是供应链金融交易类型，则认为A节点对该交易信息有查询权限。

由于在步骤330中，对于业务节点的查询请求，要么返回交易信息，要么返回交易信息的哈希值。由上述默克尔树根的计算方式可知，如果不知道数据区块中的一些交易信息，但指定这些交易信息的哈希值，同样可以最后计算出上述默克尔树根。业务节点计算出的默克尔树根与记账节点返回的数据区块的区块头的默克尔树根进行比对，就可以进行内容验证。如果两个默克尔树根一致，则说明记账节点对每个交易信息没有篡改。如果两个默克尔树根不一致，则存在记账节点篡改了其中一些交易消息，导致最后业务节点重新计算的默克尔树根与区块头中的默克尔树根不一致的可能。

如图9所示，在一个实施例中，在步骤302之后，所述方法还包括：

步骤304、接收对业务节点与区块链运营方的智能合约的更新；

步骤305、将所述更新同步到记账节点子网络中的各记账节点存储。

在步骤302中，将生成的智能合约同步到记账节点子网络中的各记账节点存储之后，如果业务节点的运营属性有变化，例如，之前业务节点A所属公司只有一家分公司，对应的业务节点为A1，现在变化为有两家分公司，对应的业务节点为A1和A2,就需要对智能合约进行更新。此时，就需要接收对智能合约的更新，然后将所述更新同步到记账节点子网络中的各记账节点存储。这样，记账节点子网络中的各记账节点就保留有最新的业务节点与区块链语音方的智能合约。

该实施例的好处是，在记账节点子网络中的各记账节点分别维护各业务节点的智能合约的情况下，能够快速更新各记账节点维护的各业务节点的智能合约。

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

发布合约模板，所述合约模板中含有合约函数；

接收利用所述合约函数设置的该业务节点的权限数据的更新；

将所述权限数据的更新整合到所述合约模板中，形成该业务节点与区块链运营方的智能合约的更新。

发布合约模板的方式与前述在生成智能合约时发布合约模板的方式相同。

接收利用所述合约函数设置的该业务节点的权限数据的更新的方式与前述在生成智能合约时接收利用所述合约函数设置的该业务节点的权限数据的方式基本一致，只不过哪些权限数据发生了变动，仅接收利用合约函数设置的这些发生变动的权限数据就可以。

同理，将所述权限数据的更新整合到所述合约模板中也与在生成智能合约时将所述权限数据整合到所述合约模板中的方式类似，故不赘述。

上述实施例的好处是，可以人工方式录入对权限数据的更新，管理员可以根据业务节点的具体情况灵活为业务节点设置权限数据，增加智能合约更新的灵活性。

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

接收来自业务节点的智能合约更新请求，所述智能合约更新请求中含有变化的业务节点运营属性数据；

根据所述变化的业务节点运营属性数据，确定与所述业务节点运营属性数据对应的权限数据的更新；

将所述权限数据的更新整合到所述合约模板中，形成更新后的该业务节点与区块链运营方的智能合约。

所述智能合约更新请求中可以仅含有变化的业务节点运营属性数据，对于未变化的运营属性数据可以不包含。

所述根据所述变化的业务节点运营属性数据，确定与所述业务节点运营属性数据对应的权限数据的更新，是记账节点自动进行的。自动更新的规则与生成智能合约时自动确定权限数据的方式类似，只不过仅需考虑变化的运营属性数据，确定与该变化后的运营属性数据对应的权限数据，替换之前的权限数据。例如，业务节点A所述公司的下属公司原来只有一家，对应着业务节点A1，现在变成两家A1和A2，这时，与变化后的运营属性数据对应的权限数据为：允许查询交易信息所属的业务节点有A、A1和A2。该权限数据替代之前仅允许查询交易信息所属的业务节点为A和A1的权限数据。

将所述权限数据的更新整合到所述合约模板中也与生成智能合约时将将所述权限数据整合到所述合约模板中的过程类似，故不赘述。

该实施例的优点是，实现了对业务节点的智能合约的更新的自动化，不需要人工干预。

如图10所示，在一个实施例中，在步骤303之后，所述方法还包括：

步骤306、接收对业务节点与区块链运营方的智能合约的更新；

步骤307、将所述更新加入与该业务节点对应的智能合约更新区块，记录在区块链上。

步骤306的内容与步骤304相同，故不赘述。

由于区块链上的数据区块是不可更改的，如果区块链上的区块数据有变化，需要更新，只能重记一个数据区块。在一个实施例中，在步骤307中，可以将更新后的智能合约加入与该业务节点对应的智能合约更新区块，记录在区块链上。这样，当记账节点为了查找业务节点的权限数据在区块链上查找业务节点与区块链运营方的智能合约时，可能在多个数据区块中找到业务节点与区块链运营方的智能合约，将最近一个数据区块中的智能合约作为更新后的智能合约，据此来决定是否向业务节点返回交易信息。

该实施例在智能合约生成后上链记录的情况下，以较快的方式实现了智能合约在区块链上的更新。

在一个实施例中，业务节点与区块链运营方的智能合约中不仅含有业务节点的权限数据，还含有业务节点是否是注册用户的信息。当需要获取权限数据来判断是否为业务节点返回交易信息前，先从智能合约中获取该业务节点是否是注册用户的信息。如果不是注册用户，则该业务节点根本没有权限查询上链的任何交易数据，不为其返回任何交易数据。如果是注册用户，才获取权限数据并判断是否为业务节点返回交易信息。

该实施例的优点是，仅对注册用户进行返回交易信息还是交易信息的哈希值的判定，对非注册用户不返回任何数据，防止了非注册用户通过本公开实施例的方法查询上链交易信息，提高了上链数据查询的安全性。

该实施例中，步骤320包括：

从业务节点与区块链运营方的智能合约中，获取该业务节点是否是注册用户的信息；

如果所述信息指示该业务节点是注册用户，从业务节点与区块链运营方的智能合约中，获取该业务节点的权限数据。

在一个实施例中，可以在智能合约中特定位置设置一个字段。该字段中为1，表示业务节点是注册用户。该字段为0，表示业务节点是非注册用户。通过该字段，获取该业务节点是否是注册用户的信息。如果该字段为1，从业务节点与区块链运营方的智能合约中另一个存放权限数据的字段，获取该业务节点的权限数据。如果该字段为0，不向业务节点返回交易数据。这可以包括不向业务节点返回任何数据，或者向业务节点返回空数据。空数据即只有一个存放数据的结构，但该结构中没有任何内容的数据。

在业务节点与区块链运营方的智能合约中还含有业务节点是否是注册用户的信息的情况下，在一个实施例中，步骤301包括：

发布合约模板，所述合约模板中含有合约函数；

接收利用所述合约函数设置的该业务节点的权限数据、和该业务节点是否是注册用户的信息；

将所述权限数据、和该业务节点是否是注册用户的信息整合到所述合约模板中，形成该业务节点与区块链运营方的智能合约。

该实施例与如上所述的在业务节点与区块链运营方的智能合约中不含有业务节点是否是注册用户的信息的情况下的步骤301的具体过程的区别在于：

第一，管理员不但要利用所述合约函数设置业务节点的权限数据，还要利用合约函数设置该业务节点是否是注册用户的信息，并把两者输入记账节点。该合约函数可以将这两种信息都设置进去。在管理员设置该业务节点是否是注册用户的信息之前，管理员要向负责业务节点向区块链网络注册的节点查询该业务节点是否是注册用户。查询的方法可以是向负责业务节点向区块链网络注册的节点发出查询请求，并接收负责业务节点向区块链网络注册的节点发出的该业务节点是否是注册用户的信息。在业务节点注册时，向负责业务节点向区块链网络注册的节点发送注册请求，并填写注册信息。负责业务节点向区块链网络注册的节点将业务节点的标识与注册信息相对应地存储。当接收到查询请求时，该查询请求带有业务节点的标识，负责业务节点向区块链网络注册的节点通过查询是否有存储的与该业务节点的标识对应的注册信息，就可以判断该业务节点是否是注册节点。负责业务节点向区块链网络注册的节点可以是记账节点子网络中一个指定的记账节点，也可以是记账节点子网络之外的一个专用节点。

第二，接收到这两个信息后，记账节点将这两个信息都整合到所述合约模板中，形成该业务节点与区块链运营方的智能合约，而不是只整合权限数据。

在业务节点与区块链运营方的智能合约中还含有业务节点是否是注册用户的信息的情况下，在另一个实施例中，步骤301包括：

接收来自业务节点的智能合约生成请求，所述智能合约生成请求中含有业务节点运营属性数据；

根据所述业务节点运营属性数据，确定与所述业务节点运营属性数据对应的权限数据；

向负责业务节点向区块链网络注册的节点发出查询请求；

接收负责业务节点向区块链网络注册的节点发出的该业务节点是否是注册用户的信息；

将所述权限数据、和该业务节点是否是注册用户的信息整合到所述合约模板中，形成该业务节点与区块链运营方的智能合约。

上述过程与在业务节点与区块链运营方的智能合约中不含有业务节点是否是注册用户的信息的情况下步骤301的详细过程的区别在于，由于智能合约中除了需要包括权限数据之外，还需要包括该业务节点是否是注册用户的信息，为了获取该信息，需要向负责业务节点向区块链网络注册的节点发出查询请求，并接收负责业务节点向区块链网络注册的节点发出的该业务节点是否是注册用户的信息。发出查询请求并接收该业务节点是否是注册用户的信息与前述管理员通过合约函数设置权限数据和该业务节点是否是注册用户的信息的实施例中管理员获得该业务节点是否是注册用户的信息的过程相同，只不过在这里不是由管理员完成的，而且机器自动完成的。

如上所述，根据本公开一个实施例的在区块链网络中查询数据区块中的交易信息的方法由记账节点子网络中的一个记账节点执行。下面详细描述该记账节点的选出过程。

在一个实施例中，如图11所示，执行所述方法的记账节点从记账节点子网络中按照以下方式选出。在一个实施例中，业务节点的查询请求先发送给代理节点，由代理节点按照以下步骤选出记账节点：

步骤410、获取记账节点子网络中每个记账节点的处理负荷；

步骤420、确定记账节点子网络中每个记账节点到发送所述查询请求的业务节点的距离；

步骤430、基于所述处理负荷和所述距离，确定接收所述待上链交易信息的记账节点。

处理负荷是表示记账节点正在处理的任务的负担的参数。在一个实施例中，处理负荷可以用记账节点未处理完的任务数来衡量。这里的任务包括交易信息上链任务和查询任务。这些未处理完的任务数就能够代表记账节点的处理负荷。

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

获取每个记账节点定期发送的处理负荷并存储；

将记账节点最近一次存储的记账节点的处理负荷作为获取的该记账节点的处理负荷。

也就是说，在该实施例中，处理负荷可以由各记账节点定期(例如，每隔5秒)发送给代理节点。代理节点维护一张处理负荷表，该处理负荷表中记录接收到的各记账节点定期广播的处理负荷。这样，代理节点就可以将记账节点最近一次存储的记账节点的处理负荷作为获取的该记账节点的处理负荷。

在该实施例中，代理节点被动接收记账节点定期发送的处理负荷。在另一个实施例中，代理节点主动查询记账节点的处理负荷。在该实施例中，步骤410包括：

向记账节点子网络中每个记账节点发送处理负荷查询请求；

接收每个记账节点发送来的该记账节点的处理负荷。

在一个实施例中，步骤420中，确定记账节点子网络中每个记账节点到发送所述查询请求的业务节点的距离，包括：

向记账节点子网络中每个记账节点、以及发送所述查询请求的业务节点发出定位信息请求；

从各记账节点、以及发送所述查询请求的业务节点接收各记账节点、以及发送所述查询请求的业务节点的定位信息；

利用各记账节点、以及发送所述查询请求的业务节点的定位信息，确定各记账节点到发送所述查询请求的业务节点的距离。

每个业务节点和记账节点都可以具有GPS等定位***，因此，它们从自身具有的GPS定位***中就能够获得自身的定位信息。当接收到代理节点发来的定位信息请求时，将从GPS***中获得的自身的定位信息发送给代理节点。当代理节点获得了各记账节点、以及发送所述查询请求的业务节点的定位信息后，利用这些定位信息，就能够确定出各记账节点到发送所述查询请求的业务节点的距离。

在上述实施例中，获得定位信息采用的是由代理节点主动请求的方式，与处理负荷一样，该定位信息也可以采用由各记账节点、以及发送所述查询请求的业务节点定期向代理节点发送的方式，故不赘述。

该实施例的优点是，在确定执行所述方法的记账节点时，不仅考虑到每个记账节点的处理负荷，还考虑到每个记账节点离发送所述查询请求的业务节点的距离。虽然，可能某一记账节点的处理负荷最小，但是该记账节点离发送所述查询请求的业务节点可能非常远，将其选为执行所述方法的记账节点，增加了网络传输负担，也降低了查询处理速度。该实施例综合考虑了距离和处理负荷，比单纯根据距离或处理负荷来确定执行查询的记账节点的方案，既能大致均衡每个记账节点的处理负荷，又不给网络造成太大传输负担。

在一个实施例中，如图12所示，步骤430可以包括：

步骤4301、基于记账节点子网络中每个记账节点的所述处理负荷，确定每个记账节点的第一分数；

步骤4302、基于记账节点子网络中每个记账节点的所述距离，确定每个记账节点的第二分数；

步骤4303、基于每个记账节点的第一分数和第二分数，确定执行所述方法的记账节点。

在步骤4301中，基于记账节点子网络中每个记账节点的所述处理负荷，确定每个记账节点的第一分数可以采取查找预先设置的处理负荷与第一分数对应关系表的形式。该处理负荷与第一分数对应关系表预先设置，其中处理负荷越大，第一分数越低。例如：

表1处理负荷与第一分数对应关系表

步骤4302中，基于记账节点子网络中每个记账节点的所述距离，确定每个记账节点的第二分数可以采取查找预先设置的距离与第二分数对应关系表的形式。该距离与第二分数对应关系表预先设置，其中距离越大，第二分数越低。例如：

距离	第二分数
		50米之内	5
50-200米	4
		200-1000米	3
1000-5000米	2
		5000-20000米	1
20000米以上	0

表2距离与第二分数对应关系表

有了每个记账节点的第一分数和第二分数，就可以根据第一分数和第二分数确定执行所述方法的记账节点。该实施例的优点在于，将记账节点子网络中每个记账节点的所述处理负荷、和记账节点子网络中每个记账节点的所述距离这两个因素对选择执行所述方法的记账节点的影响分数化，提高了选择执行所述方法的记账节点的精确性。

在一个实施例中，如图13所示，步骤4303包括：

步骤43031、确定每个记账节点的第一分数和第二分数的加权和；

步骤43032、基于所述加权和，确定执行所述方法的记账节点。

在步骤43031中，确定加权和时，为第一分数和第二分数分配的权重可以是根据经验预设的。

在步骤43032中，可以将所述加权和最大的记账节点，确定为接收所述待上链交易信息的记账节点，也可以将加权和大于预定加权和阈值的记账节点中任选一个，作为接收所述待上链交易信息的记账节点。可以认为，只要加权和大于预定加权和阈值，其都是负荷不算太大且距离发送待上链交易信息的业务节点不算太远的，选取哪一个作为执行所述方法的记账节点都是一样的。按照后一种方式，还有利于负载的均衡，防止在相同时间都选择加权和最大的记账节点，又造成该加权和最大的记账节点显然超负荷状态。

该实施例的优点是，基于每个记账节点的第一分数和第二分数的加权和，确定接收所述待上链交易信息的记账节点，相比于基于第一分数和第二分数的和或平均值确定接收所述待上链交易信息的记账节点的方案，充分考虑到了第一分数和第二分数对于确定执行所述方法的记账节点的贡献的差异性，提高了确定执行所述方法的记账节点的合理性。

上述确定接收所述待上链交易信息的记账节点的实施例主要针对图1A-1B的在记账节点子网络端没有分支记账节点子网络的情况。但在图1C所示的记账节点子网络端分为分支记账节点子网络的实施例中，则是另外一种情况。

在该实施例中，查询请求中带有交易信息类型，例如是供应链金融交易，或电子***交易，或法定数字货币交易。记账节点子网络中的记账节点预先按照处理的交易信息类型分类，分成的每一类的记账节点分别组成相应的一个分支记账节点子网络，例如，供应链金融交易分支记账节点子网络，或电子***交易分支记账节点子网络，或法定数字货币交易分支记账节点子网络，每个分支记账节点子网络专门处理与一种交易类型对应的交易类型。因此，代理节点要根据查询请求中携带的交易信息类型，将该查询请求发到相应类型的分支记账节点子网络中的一个记账节点中。为了达到这一点，在代理节点中存储记账节点标识和交易信息类型对应关系表，记账节点标识和处理的交易信息类型对应记录在记账节点标识和交易信息类型对应关系表中。

在该实施例中，如图14所示，执行所述方法的记账节点从记账节点子网络中按照以下方式选出：

步骤510、获取查询请求中的交易信息类型；

步骤520、从记账节点标识和交易信息类型对应关系表中，查找与查询请求中的交易信息类型对应的记账节点标识；

步骤530、从找到的记账节点标识的记账节点中，确定接收所述待上链交易信息的记账节点。

该实施例的好处是，对于图1C所示的记账节点子网络端分为分支记账节点子网络的体系构架，提出了一种适合该体系构架的合理选择执行所述方法的记账节点的方式。

在一个实施例中，查询请求中的交易信息类型字段中包含交易信息类型。步骤510中，可以直接从该交易信息类型字段读出交易信息类型。

由于代理节点上设置有记账节点标识和交易信息类型对应关系表，在一个实施例中，步骤520中，从该表中，可以查找到与查询请求中的交易信息类型对应的记账节点标识。

如图15所示，在一个实施例中，步骤530包括：

步骤5301、确定每个找到的记账节点标识的记账节点的处理负荷；

步骤5302、确定每个找到的记账节点标识的记账节点到发送所述查询请求的业务节点的距离；

步骤5303、基于所述处理负荷和所述距离，确定执行所述方法的记账节点。

步骤5301-5303的具体实现过程与步骤410-430的具体实现过程类似，区别仅在于图15的实施例中确定处理负荷和到发送所述查询请求的业务节点的距离的记账节点的范围仅限于步骤520中找到的与查询请求中的交易信息类型对应的记账节点标识的记账节点，不是记账节点子网络中的所有记账节点，故不赘述。

根据本公开的一个实施例，如图16所示，还提供了一种在区块链网络中查询数据区块中的交易信息的记账节点。所述区块链网络包括记账节点子网络和业务节点子网络。所述记账节点子网络包括将数据区块记录到区块链上的记账节点，所述业务节点子网络包括对记账节点记录到区块链上的数据区块进行验证的业务节点。所述记账节点包括：

查询请求接收单元610，用于接收业务节点对数据区块中的交易信息的查询请求；

权限数据获取单元620，用于从业务节点与区块链运营方的智能合约中，获取该业务节点的权限数据；

交易信息返回单元630，用于如果根据该业务节点的权限数据确定该业务节点对该交易信息有查询权限，向该业务节点返回该交易信息，反之，向该业务节点返回该交易信息的哈希值。

在一个实施例中，所述记账节点还包括：

智能合约生成单元(未示)，用于生成业务节点与区块链运营方的智能合约；

同步单元(未示)，用于将生成的智能合约同步到记账节点子网络中的各记账节点存储。

权限数据获取单元进一步用于：从该记账节点存储的该业务节点与区块链运营方的智能合约中，获取该业务节点的权限数据。

在一个实施例中，所述记账节点还包括：

智能合约生成单元(未示)，用于生成业务节点与区块链运营方的智能合约；

智能合约区块上链单元(未示)，用于将生成的智能合约加入与该业务节点对应的智能合约区块，记录在区块链上，

权限数据获取单元进一步用于：

从区块链上与该业务节点对应的智能合约区块，获取该业务节点与区块链运营方的智能合约；

从该智能合约中，获取该业务节点的权限数据。

在一个实施例中，智能合约生成单元进一步用于：

发布合约模板，所述合约模板中含有合约函数；

接收利用所述合约函数设置的该业务节点的权限数据；

将所述权限数据整合到所述合约模板中，形成该业务节点与区块链运营方的智能合约。

在一个实施例中，智能合约生成单元进一步用于：

接收来自业务节点的智能合约生成请求，所述智能合约生成请求中含有业务节点运营属性数据；

根据所述业务节点运营属性数据，确定与所述业务节点运营属性数据对应的权限数据；

将所述权限数据整合到所述合约模板中，形成该业务节点与区块链运营方的智能合约。

在一个实施例中，所述业务节点运营属性数据包括业务节点所属单位下属单位或管辖单位的业务节点，所述权限数据包括允许查询的交易信息所属的业务节点权限。所述根据所述业务节点运营属性数据，确定与所述业务节点运营属性数据对应的权限数据，包括：将所述业务节点、以及该业务节点所属单位下属单位或管辖单位的业务节点确定为允许查询的交易信息所属的业务节点权限。

在一个实施例中，所述业务节点运营属性数据包括业务节点所属单位的每日工作时间段，所述权限数据包括允许查询交易信息的每日允许时间段。所述根据所述业务节点运营属性数据，确定与所述业务节点运营属性数据对应的权限数据，包括：将业务节点所属单位的每日工作时间段确定为允许查询交易信息的每日允许时间段。

在一个实施例中，所述业务节点运营属性数据包括业务节点所属单位的交易类型，所述权限数据包括允许查询的交易信息对应的交易类型。所述根据所述业务节点运营属性数据，确定与所述业务节点运营属性数据对应的权限数据，包括：将业务节点所属单位的交易类型确定为允许查询的交易信息对应的交易类型。

在一个实施例中，在所述权限数据包括允许查询的交易信息所属的业务节点权限的情况下，所述根据该业务节点的权限数据确定该业务节点对该交易信息有查询权限，包括：如果该交易信息中的交易双方至少有一方与允许查询的交易信息所属的业务节点权限匹配的情况下，确定该业务节点对该交易信息有查询权限。

在一个实施例中，在所述权限数据包括允许查询交易信息的每日允许时间段的情况下，所述根据该业务节点的权限数据确定该业务节点对该交易信息有查询权限，包括：如果该查询请求的接收时间在所述允许查询交易信息的每日允许时间段，确定该业务节点对该交易信息有查询权限。

在一个实施例中，在所述权限数据包括允许查询的交易信息对应的交易类型的情况下，所述根据该业务节点的权限数据确定该业务节点对该交易信息有查询权限，包括：如果所述查询请求中包含的交易类型是允许查询的交易信息对应的交易类型，确定该业务节点对该交易信息有查询权限。

在一个实施例中，所述记账节点还包括：

智能合约更新接收单元(未示)，用于接收对业务节点与区块链运营方的智能合约的更新；

更新同步单元(未示)，用于将所述更新同步到记账节点子网络中的各记账节点存储。

在一个实施例中，所述记账节点还包括：

智能合约更新接收单元(未示)，用于接收对业务节点与区块链运营方的智能合约的更新；

更新上链单元(未示)，用于将所述更新加入与该业务节点对应的智能合约更新区块，记录在区块链上。

在一个实施例中，智能合约更新接收单元进一步用于：

发布合约模板，所述合约模板中含有合约函数；

接收利用所述合约函数设置的该业务节点的权限数据的更新；

将所述权限数据的更新整合到所述合约模板中，形成该业务节点与区块链运营方的智能合约的更新。

在一个实施例中，接收对业务节点与区块链运营方的智能合约的更新，包括：

接收来自业务节点的智能合约更新请求，所述智能合约更新请求中含有变化的业务节点运营属性数据；

根据所述变化的业务节点运营属性数据，确定与所述业务节点运营属性数据对应的权限数据的更新；

将所述权限数据的更新整合到所述合约模板中，形成更新后的该业务节点与区块链运营方的智能合约。

在一个实施例中，所述记账节点还包括：

签名生成单元(未示)，用于利用特定于该记账节点的密钥，基于要添加到区块链上的一个数据区块中所要包括的交易信息，生成签名；

交易信息和签名上链单元(未示)，用于将所述交易信息和生成的签名加入所述数据区块，添加到区块链上；

签名发送单元(未示)，用于将所述签名发往所述业务节点子网络中的业务节点，使业务节点根据特定于该记账节点的密钥对所述签名进行签名验证。

在一个实施例中，所述在区块链网络中查询数据区块中的交易信息的记账节点从记账节点子网络中按照以下方式选出：

获取记账节点子网络中每个记账节点的处理负荷；

确定记账节点子网络中每个记账节点到发送所述查询请求的业务节点的距离；

基于所述处理负荷和所述距离，确定在区块链网络中查询数据区块中的交易信息的记账节点。

在一个实施例中，所述基于所述处理负荷和所述距离，确定在区块链网络中查询数据区块中的交易信息的记账节点，包括：

基于记账节点子网络中每个记账节点的所述处理负荷，确定每个记账节点的第一分数；

基于记账节点子网络中每个记账节点的所述距离，确定每个记账节点的第二分数；

基于每个记账节点的第一分数和第二分数，确定在区块链网络中查询数据区块中的交易信息的记账节点。

在一个实施例中，所述基于每个记账节点的第一分数和第二分数，确定在区块链网络中查询数据区块中的交易信息的记账节点，包括：

确定每个记账节点的第一分数和第二分数的加权和；

基于所述加权和，确定在区块链网络中查询数据区块中的交易信息的记账节点。

在一个实施例中，所述基于所述加权和，确定在区块链网络中查询数据区块中的交易信息的记账节点，包括：

将所述加权和最大的记账节点，确定为在区块链网络中查询数据区块中的交易信息的记账节点。

在一个实施例中，所述查询请求中带有查询的交易信息类型，记账节点子网络中的记账节点预先按照处理的交易信息类型分类，记账节点标识和处理的交易信息类型对应记录在记账节点标识和交易信息类型对应关系表中。所述在区块链网络中查询数据区块中的交易信息的记账节点从记账节点子网络中按照以下方式选出：

获取查询请求中的交易信息类型；

从记账节点标识和交易信息类型对应关系表中，查找与获取的交易信息类型对应的记账节点标识；

从找到的记账节点标识的记账节点中，确定在区块链网络中查询数据区块中的交易信息的记账节点。

在一个实施例中，所述从找到的记账节点标识的记账节点中，确定在区块链网络中查询数据区块中的交易信息的记账节点，包括：

获取每个找到的记账节点标识的记账节点的处理负荷；

确定每个找到的记账节点标识的记账节点到发送所述查询请求的业务节点的距离；

基于所述处理负荷和所述距离，确定在区块链网络中查询数据区块中的交易信息的记账节点。

在一个实施例中，权限数据获取单元620进一步用于：

从业务节点与区块链运营方的智能合约中，获取该业务节点是否是注册用户的信息；

如果所述信息指示该业务节点是注册用户，从业务节点与区块链运营方的智能合约中，获取该业务节点的权限数据。

根据本公开实施例的在区块链网络中查询数据区块中的交易信息的方法可以由图17的在区块链网络中查询数据区块中的交易信息的记账节点21实现。下面参照图17来描述根据本公开实施例的在区块链网络中查询数据区块中的交易信息的记账节点21。图17显示的在区块链网络中查询数据区块中的交易信息的记账节点21仅仅是一个示例，不应对本公开实施例的功能和使用范围带来任何限制。

如图17所示，在区块链网络中查询数据区块中的交易信息的记账节点21以通用计算设备的形式表现。在区块链网络中查询数据区块中的交易信息的记账节点21的组件可以包括但不限于：上述至少一个处理单元810、上述至少一个存储单元820、连接不同***组件(包括存储单元820和处理单元810)的总线830。

其中，所述存储单元存储有程序代码，所述程序代码可以被所述处理单元810执行，使得所述处理单元810执行本说明书上述示例性方法的描述部分中描述的根据本发明各种示例性实施方式的步骤。例如，所述处理单元810可以执行如图6中所示的各个步骤。

存储单元820可以包括易失性存储单元形式的可读介质，例如随机存取存储单元(RAM)8201和/或高速缓存存储单元8202，还可以进一步包括只读存储单元(ROM)8203。

存储单元820还可以包括具有一组(至少一个)程序模块8205的程序/实用工具8204，这样的程序模块8205包括但不限于：操作***、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。

总线830可以为表示几类总线结构中的一种或多种，包括存储单元总线或者存储单元控制器、***总线、图形加速端口、处理单元或者使用多种总线结构中的任意总线结构的局域总线。

在区块链网络中查询数据区块中的交易信息的记账节点21也可以与一个或多个外部设备700(例如键盘、指向设备、蓝牙设备等)通信，还可与一个或者多个使得用户能与该在区块链网络中查询数据区块中的交易信息的在区块链网络中查询数据区块中的交易信息的记账节点21交互的设备通信，和/或与使得该在区块链网络中查询数据区块中的交易信息的记账节点21能与一个或多个其它计算设备进行通信的任何设备(例如路由器、调制解调器等等)通信。这种通信可以通过输入/输出(I/O)接口650进行。并且，在区块链网络中查询数据区块中的交易信息的记账节点21还可以通过网络适配器860与一个或者多个网络(例如局域网(LAN)，广域网(WAN)和/或公共网络，例如因特网)通信。如图所示，网络适配器860通过总线830与在区块链网络中查询数据区块中的交易信息的记账节点21的其它模块通信。应当明白，尽管图中未示出，可以结合在区块链网络中查询数据区块中的交易信息的记账节点21使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、RAID***、磁带驱动器以及数据备份存储***等。

通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本公开实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、终端装置、或者网络设备等)执行根据本公开实施方式的方法。

在本公开的示例性实施例中，还提供了一种计算机程序介质，其上存储有计算机可读指令，当所述计算机可读指令被计算机的处理器执行时，使计算机执行上述方法实施例部分描述的方法。

根据本公开的一个实施例，还提供了一种用于实现上述方法实施例中的方法的程序产品，其可以采用便携式紧凑盘只读存储器(CD-ROM)并包括程序代码，并可以在终端设备，例如个人电脑上运行。然而，本发明的程序产品不限于此，在本文件中，可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行***、装置或者器件使用或者与其结合使用。

所述程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以为但不限于电、磁、光、电磁、红外线、或半导体的***、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。

计算机可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质，该可读介质可以发送、传播或者传输用于由指令执行***、装置或者器件使用或者与其结合使用的程序。

可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于无线、有线、光缆、RF等等，或者上述的任意合适的组合。

可以以一种或多种程序设计语言的任意组合来编写用于执行本发明操作的程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如Java、C++等，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络，包括局域网(LAN)或广域网(WAN)，连接到用户计算设备，或者，可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。

应当注意，尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元，但是这种划分并非强制性的。实际上，根据本公开的实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。

此外，尽管在附图中以特定顺序描述了本公开中方法的各个步骤，但是，这并非要求或者暗示必须按照该特定顺序来执行这些步骤，或是必须执行全部所示的步骤才能实现期望的结果。附加的或备选的，可以省略某些步骤，将多个步骤合并为一个步骤执行，以及/或者将一个步骤分解为多个步骤执行等。

通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本公开实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、移动终端、或者网络设备等)执行根据本公开实施方式的方法。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其它实施方案。本申请旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由所附的权利要求指出。

Claims (15)

1.一种在区块链网络中查询数据区块中的交易信息的方法，其特征在于，所述区块链网络包括记账节点子网络和业务节点子网络，所述记账节点子网络包括将数据区块记录到区块链上的记账节点，所述业务节点子网络包括对记账节点记录到区块链上的数据区块进行验证的业务节点，所述方法由记账节点子网络中的一个记账节点执行，所述方法包括：

接收业务节点对数据区块中的交易信息的查询请求；

从业务节点与区块链运营方的智能合约中，获取该业务节点的权限数据；

如果根据该业务节点的权限数据确定该业务节点对该交易信息有查询权限，向该业务节点返回该交易信息，反之，向该业务节点返回该交易信息的哈希值。

2.根据权利要求1所述的方法，其特征在于，在接收业务节点对数据区块中的交易信息的查询请求之前，所述方法还包括：

生成业务节点与区块链运营方的智能合约；

将生成的智能合约同步到记账节点子网络中的各记账节点存储，

所述从业务节点与区块链运营方的智能合约中，获取该业务节点的权限数据，包括：

从该记账节点存储的该业务节点与区块链运营方的智能合约中，获取该业务节点的权限数据。

3.根据权利要求1所述的方法，其特征在于，在接收业务节点对数据区块中的交易信息的查询请求之前，所述方法还包括：

生成业务节点与区块链运营方的智能合约；

将生成的智能合约加入与该业务节点对应的智能合约区块，记录在区块链上，

所述从业务节点与区块链运营方的智能合约中，获取该业务节点的权限数据，包括：

从区块链上与该业务节点对应的智能合约区块，获取该业务节点与区块链运营方的智能合约；

从该智能合约中，获取该业务节点的权限数据。

4.根据权利要求2或3的方法，其特征在于，生成业务节点与区块链运营方的智能合约，包括：

发布合约模板，所述合约模板中含有合约函数；

接收利用所述合约函数设置的该业务节点的权限数据；

将所述权限数据整合到所述合约模板中，形成该业务节点与区块链运营方的智能合约。

5.根据权利要求2或3的方法，其特征在于，生成业务节点与区块链运营方的智能合约，包括：

接收来自业务节点的智能合约生成请求，所述智能合约生成请求中含有业务节点运营属性数据；

根据所述业务节点运营属性数据，确定与所述业务节点运营属性数据对应的权限数据；

将所述权限数据整合到所述合约模板中，形成该业务节点与区块链运营方的智能合约。

6.根据权利要求5所述的方法，其特征在于，所述业务节点运营属性数据包括业务节点所属单位下属单位或管辖单位的业务节点，所述权限数据包括允许查询的交易信息所属的业务节点权限，

所述根据所述业务节点运营属性数据，确定与所述业务节点运营属性数据对应的权限数据，包括：

将所述业务节点、以及该业务节点所属单位下属单位或管辖单位的业务节点确定为允许查询的交易信息所属的业务节点权限。

7.根据权利要求5所述的方法，其特征在于，所述业务节点运营属性数据包括业务节点所属单位的每日工作时间段，所述权限数据包括允许查询交易信息的每日允许时间段，

所述根据所述业务节点运营属性数据，确定与所述业务节点运营属性数据对应的权限数据，包括：

将业务节点所属单位的每日工作时间段确定为允许查询交易信息的每日允许时间段。

8.根据权利要求5所述的方法，其特征在于，所述业务节点运营属性数据包括业务节点所属单位的交易类型，所述权限数据包括允许查询的交易信息对应的交易类型，

所述根据所述业务节点运营属性数据，确定与所述业务节点运营属性数据对应的权限数据，包括：

将业务节点所属单位的交易类型确定为允许查询的交易信息对应的交易类型。

9.根据权利要求2所述的方法，其特征在于，在将生成的智能合约同步到记账节点子网络中的各记账节点存储之后，所述方法还包括：

接收对业务节点与区块链运营方的智能合约的更新；

将所述更新同步到记账节点子网络中的各记账节点存储。

10.根据权利要求3所述的方法，其特征在于，在将生成的智能合约加入与该业务节点对应的智能合约区块，记录在区块链上之后，所述方法还包括：

接收对业务节点与区块链运营方的智能合约的更新；

将所述更新加入与该业务节点对应的智能合约更新区块，记录在区块链上。

11.根据权利要求9或10所述的方法，其特征在于，接收对业务节点与区块链运营方的智能合约的更新，包括：

接收来自业务节点的智能合约更新请求，所述智能合约更新请求中含有变化的业务节点运营属性数据；

根据所述变化的业务节点运营属性数据，确定与所述业务节点运营属性数据对应的权限数据的更新；

将所述权限数据的更新整合到所述合约模板中，形成更新后的该业务节点与区块链运营方的智能合约。

12.根据权利要求1所述的方法，其特征在于，所述从业务节点与区块链运营方的智能合约中，获取该业务节点的权限数据，包括：

从业务节点与区块链运营方的智能合约中，获取该业务节点是否是注册用户的信息；

如果所述信息指示该业务节点是注册用户，从业务节点与区块链运营方的智能合约中，获取该业务节点的权限数据。

13.一种在区块链网络中查询数据区块中的交易信息的记账节点，其特征在于，所述区块链网络包括记账节点子网络和业务节点子网络，所述记账节点子网络包括将数据区块记录到区块链上的记账节点，所述业务节点子网络包括对记账节点记录到区块链上的数据区块进行验证的业务节点，所述记账节点包括：

查询请求接收单元，用于接收业务节点对数据区块中的交易信息的查询请求；

权限数据获取单元，用于从业务节点与区块链运营方的智能合约中，获取该业务节点的权限数据；

交易信息返回单元，用于如果根据该业务节点的权限数据确定该业务节点对该交易信息有查询权限，向该业务节点返回该交易信息，反之，向该业务节点返回该交易信息的哈希值。

14.一种记账节点，其特征在于，包括：

存储器，存储有计算机可读指令；

处理器，读取存储器存储的计算机可读指令，以执行权利要求1-12中的任一个所述的方法。

15.一种计算机程序介质，其上存储有计算机可读指令，当所述计算机可读指令被计算机的处理器执行时，使计算机执行权利要求1-12中的任一个所述的方法。