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

本公开涉及区块链领域，具体涉及一种在区块链网络中查询数据区块中的交易信息的方法、记账节点和介质。
背景技术：
：传统的区块链网络分为两种。第一种区块链网络中，每个记账节点负责记账，即将数据区块上链，但同时它又是产生数据区块中的交易信息的节点。第二种区块链网络中，记账节点只负责向区块链上记账，即数据上链，实际发生交易、需要交易信息上链的节点在记账节点之外。当需要交易信息上链时，需要交易信息上链的节点将需要上链的交易信息发给对应的记账节点，由记账节点将交易信息上链。在实际中，有隐藏数据区块中交易笔数的需求。有些情况下，产生交易信息的单位可能不希望别人看到自己产生了多少笔交易。在第一种区块链网络中，每个需要交易信息上链的节点就是记账节点，任何一个节点都能够看到数据区块中有多少笔交易，或者某单位发生了多少笔交易。在第二种区块链网络中，需要查询区块链上的数据区块信息的节点通过对应的记账节点在区块链上进行查询，由于所有记账节点都有权限查询区块链上的所有数据区块中的详细信息，当然也包括交易笔数，因此，无法因此交易笔数。现有技术缺少一种能够在不影响区块链网络记账安全性的同时隐藏交易笔数的方案。技术实现要素：本公开的一个目的在于提出一种能够在不影响区块链网络记账安全性的同时隐藏交易笔数的方法、记账节点和介质。根据本公开实施例的一方面，公开了一种在区块链网络中查询数据区块中的交易信息的方法，所述区块链网络包括记账节点子网络和业务节点子网络，所述记账节点子网络包括将数据区块记录到区块链上的记账节点，所述业务节点子网络包括对记账节点记录到区块链上的数据区块进行验证的业务节点，所述方法由记账节点子网络中的一个记账节点执行，所述方法包括：接收业务节点对数据区块中的交易信息的查询请求；获取该数据区块的默克尔树，所述默克尔树通过以下方式形成：按照数据区块中每个交易信息的顺序，排在第奇数位的交易信息和之后相邻的排在第偶数位的交易信息的哈希值组成一个对，对该对的两个哈希值进行哈希运算，得到该对的哈希值，再按照每个对在数据区块中的顺序，排在第奇数位的对和之后相邻的排在第偶数位的对组成一个更上一层的对，将每个更上一层的对中的两个对的哈希值进行哈希运算，得到该更上一层的对的哈希值，直到得到最上一层的对的哈希值，即为默克尔树根，上述每个层的哈希值为默克尔树的一个树节点；如果根据该业务节点的权限数据，该默克尔树中的一个树节点的哈希值完全由该业务节点没有查询权限的交易信息层层哈希运算得出，向该业务节点返回该树节点的哈希值，代替该哈希值所出自的、所述业务节点没有查询权限的交易信息。根据本公开实施例的一方面，公开了一种在区块链网络中查询数据区块中的交易信息的记账节点，所述区块链网络包括记账节点子网络和业务节点子网络，所述记账节点子网络包括将数据区块记录到区块链上的记账节点，所述业务节点子网络包括对记账节点记录到区块链上的数据区块进行验证的业务节点，所述在区块链网络中查询数据区块中的交易信息的记账节点包括：查询请求接收单元，用于接收业务节点对数据区块中的交易信息的查询请求；默克尔树获取单元，用于获取该数据区块的默克尔树，所述默克尔树通过以下方式形成：按照数据区块中每个交易信息的顺序，排在第奇数位的交易信息和之后相邻的排在第偶数位的交易信息的哈希值组成一个对，对该对的两个哈希值进行哈希运算，得到该对的哈希值，再按照每个对在数据区块中的顺序，排在第奇数位的对和之后相邻的排在第偶数位的对组成一个更上一层的对，将每个更上一层的对中的两个对的哈希值进行哈希运算，得到该更上一层的对的哈希值，直到得到最上一层的对的哈希值，即为默克尔树根，上述每个层的哈希值为默克尔树的一个树节点；返回单元，用于如果根据该业务节点的权限数据，该默克尔树中的一个树节点的哈希值完全由该业务节点没有查询权限的交易信息层层哈希运算得出，向该业务节点返回该树节点的哈希值，代替该哈希值所出自的、所述业务节点没有查询权限的交易信息。根据本公开实施例的一方面，公开了一种记账节点，包括：存储器，存储有计算机可读指令；处理器，读取存储器存储的计算机可读指令，以执行如上所述的方法。根据本公开实施例的一方面，公开了一种计算机程序介质，其上存储有计算机可读指令，当所述计算机可读指令被计算机的处理器执行时，使计算机执行如上所述的方法。本公开实施例中，记账节点子网络与业务节点子网络是分开的。数据区块在上链之前在记账节点之间进行共识，并记录在区块链上，但实际有交易发生需要交易信息上链的业务节点是在记账节点子网络外的，其通过记账节点进行交易信息上链。因而，在业务节点间不会发生共识，因而直接看不到交易笔数。其向记账节点查询交易信息时，获取数据区块的默克尔树。如果该默克尔树中的一个树节点的哈希值完全由该业务节点没有查询权限的交易信息层层哈希运算得出，向该业务节点返回该树节点的哈希值，代替该哈希值所出自的、所述业务节点没有查询权限的交易信息。这样，相当于返回时用一个哈希值替代了数据区块中的多个其无权查询的交易信息，到底替代了多少个这种交易信息，是业务节点无法知道的。通过这种方式，向业务节点隐藏了交易笔数。但是，虽然隐藏了交易笔数，由于返回的该哈希值是隐藏的这些业务节点没有权限的交易信息层层哈希运算出的，业务节点无需知道隐藏的这些交易信息是什么，或者其哈希值是什么，只需要利用该返回的哈希值向默克尔树的更上一层进行哈希运算，就能得到默克尔树根，从而与记账节点返回的区块头的默克尔树根进行比较，进行数据区块的内容验证，保证了记账安全性，即在不影响区块链网络记账安全性的同时隐藏了交易笔数。本公开的其他特性和优点将通过下面的详细描述变得显然，或部分地通过本公开的实践而习得。应当理解的是，以上的一般描述和后文的细节描述仅是示例性的，并不能限制本公开。附图说明通过参照附图详细描述其示例实施例，本公开的上述和其它目标、特征及优点将变得更加显而易见。图1a-1c示出了根据本公开一个实施例的在区块链网络中查询数据区块中的交易信息的方法的三种体系构架图。图2a-2c示出了根据本公开一个实施例的在区块链网络中查询数据区块中的交易信息的方法应用在供应链金融、电子发票、法定数字货币三种不同的应用场景下的场景构架图。图3a-3g示出了根据本公开一个实施例的在区块链网络中查询数据区块中的交易信息的方法应用在供应链金融应用场景下的业务节点显示界面图，这些界面图表示了供应链金融应用场景下从交易信息上链到查询交易信息并验证数据区块内容的大体过程。图4a-4g示出了根据本公开一个实施例的在区块链网络中查询数据区块中的交易信息的方法应用在电子发票应用场景下的业务节点显示界面图，这些界面图表示了电子发票应用场景下从交易信息上链到查询交易信息并验证数据区块内容的大体过程。图5a-5g示出了根据本公开一个实施例的在区块链网络中查询数据区块中的交易信息的方法应用在法定数字货币应用场景下的业务节点显示界面图，这些界面图表示了法定数字货币应用场景下从交易信息上链到查询交易信息并验证数据区块内容的大体过程。图6a示出了根据本公开一个实施例的默克尔树。图6b示出了根据本公开另一个实施例的默克尔树。图7示出了根据本公开一个实施例的在区块链网络中查询数据区块中的交易信息的方法的流程图。图8示出了根据本公开一个实施例的确定数据区块中每个交易信息的顺序的流程图。图9示出了根据本公开另一个实施例的确定数据区块中每个交易信息的顺序的流程图。图10示出了根据本公开一个实施例的在区块链网络中查询数据区块中的交易信息的方法的流程图。图11示出了根据本公开一个实施例的在区块链网络中查询数据区块中的交易信息的方法的流程图。图12示出了根据本公开一个实施例的确定所述在区块链网络中查询数据区块中的交易信息的方法的记账节点的流程图。图13示出了根据本公开一个实施例的图12中步骤430的详细流程图。图14示出了根据本公开一个实施例的图13中步骤4303的详细流程图。图15示出了根据本公开一个实施例的确定所述在区块链网络中查询数据区块中的交易信息的方法的记账节点的流程图。图16示出了根据本公开一个实施例的图15中步骤530的详细流程图。图17示出了根据本公开一个实施例的在区块链网络中查询数据区块中的交易信息的记账节点的模块框图。图18示出了根据本公开一个实施例的记账节点的硬件结构图。具体实施方式现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些示例实施方式使得本公开的描述将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。附图仅为本公开的示意性图解，并非一定是按比例绘制。图中相同的附图标记表示相同或类似的部分，因而将省略对它们的重复描述。此外，所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多示例实施方式中。在下面的描述中，提供许多具体细节从而给出对本公开的示例实施方式的充分理解。然而，本领域技术人员将意识到，可以实践本公开的技术方案而省略所述特定细节中的一个或更多，或者可以采用其它的方法、组元、步骤等。在其它情况下，不详细示出或描述公知结构、方法、实现或者操作以避免喧宾夺主而使得本公开的各方面变得模糊。附图中所示的一些方框图是功能实体，不一定必须与物理或逻辑上独立的实体相对应。可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。下面先参照图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，而区块头中含有默克尔树根和签名。在同时发送交易信息的默克尔树根(例如，默克尔树根和签名放在区块头中发送)的情况下，业务节点11获取特定于该记账节点的密钥，例如从认证中心请求到为该记账节点21分配的公钥。业务节点11用特定于该记账节点的密钥对所述签名进行解密，得到所述数据区块中的交易信息的默克尔树根。如果与签名同时接收到的默克尔树根与解密得到的默克尔树根一致，则签名验证成功。在同时发送交易信息的默克尔树根的情况下，业务节点11是接收不到每个交易信息的。业务节点11要查看交易信息时，需要向记账节点21请求。记账节点21获取该数据区块的默克尔树。默克尔树是计算上述的默克尔树根时形成的哈希值树形结构。默克尔树通过以下方式形成：按照数据区块中每个交易信息的顺序，排在第奇数位的交易信息和之后相邻的排在第偶数位的交易信息的哈希值组成一个对，对该对的两个哈希值进行哈希运算，得到该对的哈希值，再按照每个对在数据区块中的顺序，排在第奇数位的对和之后相邻的排在第偶数位的对组成一个更上一层的对，将每个更上一层的对中的两个对的哈希值进行哈希运算，得到该更上一层的对的哈希值，直到得到最上一层的对的哈希值，即为默克尔树根，上述每个层的哈希值为默克尔树的一个树节点。如图6a所示，一个示例性的数据区块包括8个交易信息，即交易信息1-8。交易信息1和2组成第一对，交易信息1的哈希值h1和交易信息2的哈希值h2进行哈希运算，得到第一对的哈希值h9。交易信息3和4组成第二对，交易信息3的哈希值h3和交易信息4的哈希值h4进行哈希运算，得到第二对的哈希值h10。交易信息5和6组成第三对，交易信息5的哈希值h5和交易信息6的哈希值h6进行哈希运算，得到第三对的哈希值h11。交易信息7和8组成第四对，交易信息7的哈希值h7和交易信息8的哈希值h8进行哈希运算，得到第四对的哈希值h12。将第一对的哈希值h9与第二对的哈希值h10组成一个更上一层的对，h9和h10进行哈希运算，得到更上一层的对的哈希值h13。将第三对的哈希值h11与第二对的哈希值h12组成一个更上一层的对，h11和h12进行哈希运算，得到更上一层的对的哈希值h14。然后，将两个哈希值h13和h14进行最后的哈希运算，得到最上一层的哈希值m1，即默克尔树根。h1-h14的每个哈希值为默克尔树的一个树节点。如果根据该业务节点的权限数据，该默克尔树中的一个树节点的哈希值完全由该业务节点没有查询权限的交易信息层层哈希运算得出，向该业务节点返回该树节点的哈希值，代替该哈希值所出自的、所述业务节点没有查询权限的交易信息。这样，就用一个哈希值掩盖了其出自的多个所述业务节点没有查询权限的交易信息，隐藏了交易笔数。如图6a所示，假设发出查询请求的业务节点为业务节点a。根据业务节点a的权限数据，其对交易信息1、3、5具有查询权限。这时，对于交易信息1、3、5来说，是可以为业务节点a返回交易信息的内容的。对于交易信息2、4、6来说，可以为业务节点a返回交易信息的哈希值h2、h4、h6。但是，对于交易信息7、8，其都是业务节点a没有查询权限的交易信息，为业务节点a分别返回其哈希值h7和h8，与返回h7和h8的哈希值h12，对业务节点a来说是同样的，都不影响业务节点a根据哈希值来计算默克尔树根，从而与区块头中的默克尔树根进行比较，进行数据区块的内容验证。而为业务节点a返回哈希值h12，掩盖了该哈希值h12出自的交易信息的笔数，实现了交易笔数的保密。因此，只会向业务节点a返回哈希值h12，不会向业务节点a返回下面具体的交易信息或哈希值h7和h8。业务节点11得到记账节点21返回的交易信息和哈希值后，按照图6a的方法再次计算该数据区块的默克尔树根。如果计算出的默克尔树根与一开始向业务节点11返回的区块头中的默克尔树根一致，则说明数据区块的内容没有被篡改，内容验证通过。如不一致，说明记账节点21篡改了数据区块的内容，达到了监督的目的。下面结合图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返回该交易信息。对于无权获取的交易信息，根据如上结合图6a所示的方法，如果该数据区块的默克尔树中的一个树节点的哈希值完全由该业务节点没有查询权限的交易信息层层哈希运算得出，向该业务节点返回该树节点的哈希值，代替该哈希值所出自的、所述业务节点没有查询权限的交易信息。如图6a中，用哈希值h12代替交易信息7和8，或者哈希值h7和h8，向业务节点返回。这样，如图3e所示，在业务节点11的界面上显示的有业务节点11有权查询的交易信息1、3、5，还有业务节点11无权查询的交易信息的哈希值h2、h4、h6、以及哈希值h12。由于哈希值12是由默克尔树中其下面的业务节点11没有查询权限的交易信息层层哈希运算得出的，不知道其代表的交易信息的数量，达到了隐藏交易笔数的目的。当用户在图3e的界面上选择“进行内容验证”后，业务节点11根据图3e显示的各交易信息和各哈希值进行重新的默克尔树根的计算，并将重新计算的默克尔树根与区块头中的默克尔树根比较，从而进行内容验证。如果重新计算出的默克尔树根与区块头中包含的默克尔树根不一致，显示如图3f所示的“内容验证失败”的界面。如果重新计算出的默克尔树根与区块头中包含的默克尔树根一致，显示如图3g所示的“内容验证成功”的界面。图2b示出了根据本公开一个实施例的在区块链网络中查询数据区块中的交易信息的方法应用在电子发票的应用场景下的场景构架图。在传统的电子发票的区块链应用场景中，地税局向开票企业发放发票，开票企业向领票人开出发票，领票人向领票人所在的报销单位报销发票。所有这些交易都需要上链，即记录到区块链上。但是，地税局、开票企业、报销单位这些节点不是记账节点21。它们要委托对应的记账节点或超级节点将这些交易记录在区块链上。所有这些记账节点或超级节点都是国税部门统一设置的。它们之间可以互相监督和见证，但地税局、开票企业、报销单位这些节点是发票的直接关系人，却不能监督和见证，只能完全信任记账节点21。另外，任何企业都可以通过其对应的记账节点查询区块链上任何交易信息。但在某些情况下，企业的发票相关信息并不希望被其它企业获知。在本公开实施例中，由于记账节点子网络2与业务节点子网络1分开，记账节点子网络2专用于记账，而业务节点子网络1包含了这些发票利益相关的节点，对记账节点21的记账进行见证。一旦记账节点21集体作弊，见证的各业务节点11会保留有具体记账节点作恶的证据。在一个电子发票的例子中，如图2b所示，各业务节点11包括开票单位终端、报销人手机、报销单位终端、地税局终端等。当地税局为开票单位发放发票，或者开票单位开出发票，或者报销人到报销单位报销时，将相应的交易信息(发票所有权的转移)传递给代理节点12，由代理节点12选择一个记账节点21。代理节点12将相应的交易信息发送给选择的记账节点21缓存。然后，记账节点21按照区块打包要求打包成数据区块。记账节点21基于数据区块中的交易信息，生成签名，将签名加入数据区块的区块头后上链并将签名发送给业务节点11，这些过程与结合图2a所示的过程类似。与签名同时发送到各业务节点11的还可以有交易信息的默克尔树根。业务节点11处签名验证的方式与上面结合图2a所述的过程类似，可以参照以上结合图2a所示的相关描述。另外，在同时发送交易信息的默克尔树根的情况下，业务节点11可以向记账节点21发送查询请求，用于查询交易信息。记账节点21根据业务节点11的权限数据，对于该业务节点有权限的交易信息，向业务节点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得到默克尔树根和签名后，能进行签名验证。这与上面结合图2a所示的过程类似，故不赘述。另外，如果业务节点需要查询数据区块中的具体交易信息，可以向记账节点21发送查询请求。记账节点21如果根据该业务节点的权限数据，判断该数据区块的默克尔树中的一个树节点的哈希值完全由该业务节点没有查询权限的交易信息层层哈希运算得出，向该业务节点返回该树节点的哈希值，代替该哈希值所出自的、所述业务节点没有查询权限的交易信息。这样，达到了隐藏交易笔数的目的。该过程与上面结合图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所示的过程类似，故不赘述。如图7所示，根据本公开的一个实施例，提供了一种在区块链网络中查询数据区块中的交易信息的方法。如图1a-1c所示，所述区块链网络包括记账节点子网络2和业务节点子网络1。所述记账节点子网络2包括将数据区块记录到区块链上的记账节点21。所述业务节点子网络1包括对记账节点记录到区块链上的数据区块进行验证的业务节点11。所述方法由记账节点子网络2中的一个记账节点21执行。所述方法包括：步骤310、接收业务节点对数据区块中的交易信息的查询请求；步骤320、获取该数据区块的默克尔树，所述默克尔树通过以下方式形成：按照数据区块中每个交易信息的顺序，排在第奇数位的交易信息和之后相邻的排在第偶数位的交易信息的哈希值组成一个对，对该对的两个哈希值进行哈希运算，得到该对的哈希值，再按照每个对在数据区块中的顺序，排在第奇数位的对和之后相邻的排在第偶数位的对组成一个更上一层的对，将每个更上一层的对中的两个对的哈希值进行哈希运算，得到该更上一层的对的哈希值，直到得到最上一层的对的哈希值，即为默克尔树根，上述每个层的哈希值为默克尔树的一个树节点；步骤330、如果根据该业务节点的权限数据，该默克尔树中的一个树节点的哈希值完全由该业务节点没有查询权限的交易信息层层哈希运算得出，向该业务节点返回该树节点的哈希值，代替该哈希值所出自的、所述业务节点没有查询权限的交易信息。在详细描述步骤310-330之前，先对步骤310前面可能会有的步骤进行描述。在一个实施例中，步骤310-330之前是有交易信息上链的步骤的。在该实施例中，步骤310之前，所述方法包括：基于要添加到区块链上的一个数据区块中所要包括的交易信息，生成该数据区块的默克尔树根；利用特定于该记账节点的密钥，基于该默克尔树根，生成签名；将所述交易信息添加到所述数据区块的区块体，将默克尔树根、签名添加到所述数据区块的区块头，将该数据区块添加到区块链上；将所述区块头发往所述业务节点子网络中的业务节点，使业务节点根据特定于该记账节点的密钥和区块头中的默克尔树根，对所述区块头中的签名进行签名验证。基于要添加到区块链上的一个数据区块中所要包括的交易信息，生成该数据区块的默克尔树根的方式与步骤320中默克尔树形成的方式是基本一致的。即，按照数据区块中每个交易信息的顺序，排在第奇数位的交易信息和之后相邻的排在第偶数位的交易信息的哈希值组成一个对，对该对的两个哈希值进行哈希运算，得到该对的哈希值，再按照每个对在数据区块中的顺序，排在第奇数位的对和之后相邻的排在第偶数位的对组成一个更上一层的对，将每个更上一层的对中的两个对的哈希值进行哈希运算，得到该更上一层的对的哈希值，直到得到最上一层的对的哈希值，即为默克尔树根，上述每个层的哈希值为默克尔树的一个树节点。由于前面已经结合图2a详细描述了如何从交易信息1-8的哈希值两两组对，层层向上确定更上一层的哈希值，直到得到默克尔树根的过程，因此，此部分内容在这里不再赘述。需要说明的是，数据区块中每个交易信息的顺序是指每个交易信息在数据区块中的序号的顺序。如图6a所示，该数据区块中8个交易信息的序号分别是1-8，这些交易信息表示为交易信息1-交易信息8。排在第奇数位的交易信息为序号为奇数的交易信息，如图6a中的交易信息1、3、5、7。排在第偶数位的交易信息为序号为偶数的交易信息，如图6a中的交易信息2、4、6、8。每个对在数据区块中的顺序是指，将每个对按照其含有的交易信息序号的大小从小到大排序后得到的序号。例如，第一对包括交易信息1和2，第二对包括交易信息3和4，那么第一对包括的交易信息序号小于第二对包括的交易信息序号。这样，第一对、第二对、第三对、第四对按照其含有的交易信息序号的大小从小到大排序后得到的序列就是：第一对、第二对、第三对、第四对。第一对、第二对、第三对、第四对的序号分别是1-4。排在第奇数位的对即序号为奇数的对。排在第偶数位的对即序号为偶数的对。还需要说明的是，在上述过程中，如果顺序排在第奇数位的交易信息是缓存中最后一个交易信息，可以将该交易信息本身作为一个对；如果顺序排在第奇数位的对是缓存中最后一个对，可以将该对本身作为更上一层的对。在一个实施例中，数据区块中每个交易信息的顺序为记账节点接收到每个交易信息的顺序。在该实施例中，当业务节点11通过代理节点12向记账节点21发送交易信息时，代理节点12可以不急于将接收到的该交易信息作为要添加到区块链上的一个数据区块中所要包括的交易信息，对该交易信息施加签名算法，生成签名，而是将其放在缓存中，等待缓存中缓存了足够的交易信息，即达到了预设的区块打包要求(例如，缓存中的待上链交易信息的总大小达到预定大小阈值，缓存中的待上链交易信息的总条数达到预定条数阈值)时，才将其打在一个包中，生成签名，并上链。该实施例的好处是，提高数据区块的利用效率，避免区块链上的数据区块过多过于分散。这样，在打包时，每个交易信息放进缓存的顺序(或被记账节点接收到的顺序)，就变成了打包时数据区块中每个交易信息的顺序。特定于记账节点的密钥是预先由认证中心为每个记账节点分配的、专用于其对交易信息进行签名所使用的密钥。一般来说，签名的过程是这样的：将待签名的消息施加摘要运算，得到待签名的消息的摘要(如默克尔树根)，然后用签名使用的密钥对摘要加密，得到了签名。对签名进行验证时，需要利用解签名使用的密钥对签名解密，得到了待签名的消息的摘要，然后对待签名的消息重新施加同样的摘要运算，得到重新确定的摘要。如果解密后的摘要与重新确定的摘要一致，则签名验证成功。通过签名验证，能够验证出待签名的消息是否是签名者所发出的、以及消息是否完整。如果该消息不是签名者所发，或者消息在传输过程中丢失了一部分，签名验证均不通过。由上述签名算法的过程可知，可以利用特定于该记账节点的密钥，基于该默克尔树根，生成签名。在一个实施例中，可以在每个记账节点设立时，由记账节点向认证中心请求该特定于该记账节点的密钥，由认证中心为记账节点生成该密钥并存储，然后发送到该记账节点。而业务节点在签名验证时，也向认证中心请求该特定于该记账节点的密钥，认证中心将该密钥发送给业务节点，供业务节点签名验证使用。在一个实施例中，数据区块分为区块头和区块体。区块体是数据区块的主体，其中包含有数据区块存储的交易信息。区块头是数据区块的头部，其不含有交易信息，而是含有辅助性信息，包括基于本数据区块中的所有交易信息计算出的摘要(例如默克尔树根)、签名以及前一数据区块的摘要。前一数据区块的摘要的作用是，由于每个数据区块中包括前一数据区块的信息，而该数据区块本身的摘要又包含在区块链上其后的数据区块中。这样，每个数据区块相互关联，一旦某一数据区块被篡改，其后一数据区块中包含的该数据区块的摘要就会与其不对应，从而识别出篡改，保证了区块链上存储信息的安全性。数据区块上链后，将所述区块头发往所述业务节点子网络中的业务节点，使业务节点根据特定于该记账节点的密钥和区块头中的默克尔树根，对所述区块头中的签名进行签名验证。在一个实施例中，根据特定于该记账节点的密钥和区块头中的默克尔树根，对所述区块头中的签名进行签名验证的具体过程包括：获取特定于该记账节点的密钥；用特定于该记账节点的密钥对所述签名进行解密，得到所述数据区块中的交易信息的摘要；如果接收到的摘要与解密得到的摘要一致，则签名验证成功。获取特定于该记账节点的密钥可以采用以上所述的向认证中心发送密钥请求，从认证中心接收与该标识对应的特定于记账节点的密钥的方式，故不赘述。下面来详细描述步骤310-330的具体实现过程。在步骤310中，接收业务节点对数据区块中的交易信息的查询请求。在上述签名验证的过程中，业务节点得到的仅仅是数据区块的区块头。如果业务节点需要得到具体的交易信息，可以向记账节点发送对数据区块中的交易信息的查询请求。该查询请求中可以带有该数据区块的默克尔树根。由于不同数据区块的默克尔树根是不同的，因此，记账节点通过查询区块链上每个数据区块的数据头中的默克尔树根，就能在区块链上找到该数据区块。在步骤320中，获取该数据区块的默克尔树。在一个实施例中，在前面记账节点生成区块头中的默克尔树根的步骤中，记账节点将生成的默克尔树同步到记账节点子网络中的所有记账节点存储。这样，步骤320中，记账节点根据所述查询请求中的默克尔树根，从该记账节点存储的默克尔树中查找默克尔树根与查询请求中的默克尔树根一致的默克尔树，作为获取到的默克尔树。在一个实施例中，步骤320可以包括：根据所述查询请求中的默克尔树根，在区块链上查找区块头中含有所述默克尔树根的数据区块；根据找到的数据区块中的交易信息生成默克尔树。生成默克尔树的方法与前面记账节点生成区块头中的默克尔树根的步骤中用的方法一致，故不赘述。也就是说，之前生成区块头中的默克尔树根后，生成默克尔树根用的默克尔树不存储，而是重新根据数据区块中的交易信息计算。该实施例的好处是，可以减少对记账节点存储空间的占用。在步骤330中，如果根据该业务节点的权限数据，该默克尔树中的一个树节点的哈希值完全由该业务节点没有查询权限的交易信息层层哈希运算得出，向该业务节点返回该树节点的哈希值，代替该哈希值所出自的、所述业务节点没有查询权限的交易信息。业务节点的权限数据是指示业务节点能查询哪些交易信息、不能查询哪些交易信息的数据。在一个实施例中，该业务节点的权限数据从业务节点与区块链运营方的智能合约中获取。根据智能合约存放的不同地点，有不同获取权限数据的实施例。为了避免模糊步骤330中的重点，这些不同的获取权限数据的实施例将在后文描述。默克尔树中的一个树节点的哈希值完全由该业务节点没有查询权限的交易信息层层哈希运算得出是指，该业务节点对默克尔树中该树节点出自的所有交易信息都没有查询权限。树节点出自的所有交易信息这样定义：默克尔树中一个树节点的哈希值由其下面一层的两个树节点的哈希值经哈希运算得到，其下面一层的树节点的哈希值由更下面一层的两个树节点的哈希值经哈希运算得到，直到追溯到默克尔树最下面一层的树节点的哈希值。这样，默克尔树中一个树节点的哈希值按照上述方式所追溯到的最下面一层的树节点所对应的所有交易信息就是该树节点出自的所有交易信息。如图6a所示，业务节点a仅对交易信息1、3、5有查询权限。对于h12这个树节点，其哈希值由下面一层的树节点哈希值h7和h8哈希运算得到，h7、h8已经是最下面一层树节点哈希值，其对应的交易信息7、8就是树节点h12出自的所有交易信息。根据业务节点a的权限数据，其对交易信息7、8确实是没有权限的。因此，向该业务节点a返回该树节点的哈希值h12，代替该哈希值所出自的、所述业务节点没有查询权限的交易信息7、8。在一个实施例中，根据该业务节点的权限数据，确定该默克尔树中的一个树节点的哈希值完全由该业务节点没有查询权限的交易信息层层哈希运算得出，具体包括：确定该树节点出自的所有交易信息；如果针对该树节点出自的每个交易信息，确定该交易信息的施动方或受动方都不是所述权限数据中指示的目标业务节点之一，则确定该默克尔树中的一个树节点的哈希值完全由该业务节点没有查询权限的交易信息层层哈希运算得出。树节点出自的所有交易信息上面已经定义过，故不赘述。众所周知，交易是一方引起另一方的行为。引起行为的一方就是施动方，被引起行为的一方就是受动方。例如，在开出电子发票的交易中，开票单位终端就是施动方，领票人终端就是受动方。在法定数字货币的转移交易中，法定数字货币的转出方终端就是施动方，法定数字货币的转入方终端就是受动方。权限数据指示着该业务节点有权查询的目标业务节点。这些目标业务节点之一作为施动方或受动方的交易信息，该业务节点都有权查询。即如果交易信息的施动方或受动方是所述权限数据中指示的目标业务节点之一，都是可以向其返回交易信息的。例如，业务节点a的权限数据指示，目标业务节点是a、a1、a2。因此，只要a、a1、a2之一作为交易信息的施动方或受动方，就认为业务节点a有权查询这个交易信息。上述步骤330中，确定该默克尔树中的一个树节点的哈希值完全由该业务节点没有查询权限的交易信息层层哈希运算得出，只是一个概括性的表述。在具体实施时，可以从默克尔树的默克尔树根开始自上而下进行确定。因此，在一个实施例中，步骤330包括：如果该默克尔树的默克尔树根所出自的两个下一层树节点的哈希值中有完全由该业务节点没有查询权限的交易信息层层哈希运算得出的哈希值，向该业务节点返回该树节点的哈希值，代替该哈希值所出自的、所述业务节点没有查询权限的交易信息；对于默克尔树根所出自的两个下一层树节点的哈希值中不完全由该业务节点没有查询权限的交易信息层层哈希运算得出的哈希值，确定该哈希值所出自的两个更下一层树节点的哈希值中是否有完全由该业务节点没有查询权限的交易信息层层哈希运算得出的哈希值；如果更下一层树节点的哈希值中有完全由该业务节点没有查询权限的交易信息层层哈希运算得出的哈希值，向该业务节点返回该哈希值，代替该哈希值所出自的、所述业务节点没有查询权限的交易信息；对于两个更下一层树节点的哈希值中不完全由该业务节点没有查询权限的交易信息层层哈希运算得出的哈希值，确定该哈希值所出自的两个再更下一层树节点的哈希值中是否有完全由该业务节点没有查询权限的交易信息层层哈希运算得出的哈希值，直到没有更下一层树节点；在没有更下一层树节点时，如果该树节点的哈希值是该业务节点有查询权限的交易信息的哈希值，则向业务节点返回该交易信息；反之，则向业务节点返回该交易信息的哈希值。也就是说，在该实施例中，先从默克尔树根开始判断。由于默克尔树根是由其下一层的两个树节点的哈希值哈希运算得到的，因此可以先判断这两个下一层的树节点的哈希值中的每一个是不是完全由该业务节点没有查询权限的交易信息层层哈希运算得出的哈希值，即判断这两个下一层的树节点出自的每一个交易信息是否都是根据该权限数据确定该业务节点没有查询权限的交易信息。如果这两个下一层的树节点出自的每一个交易信息都是根据该权限数据确定该业务节点没有查询权限的交易信息，就可以向该业务节点返回该树节点的哈希值，代替该树节点出自的所有交易信息了。如图6a所示，默克尔树根m1是由下一层的两个树节点哈希值h13、h14经哈希运算得到的，h13出自的交易信息有交易信息1-4，h14出自的交易信息有交易信息5-8，都含有业务节点a有查询权限的交易信息。交易信息1-4中，业务节点a对交易信息1和3具有查询权限。交易信息5-8中，业务节点a对交易信息5具有查询权限。因此，不向业务节点a返回任何哈希值。进行下一层的判断。对于默克尔树根所出自的两个下一层树节点的哈希值中不完全由该业务节点没有查询权限的交易信息层层哈希运算得出的哈希值，即对于默克尔树根所出自的两个下一层树节点的哈希值中的、所出自的交易信息不全是业务节点没有查询权限的交易信息的哈希值，确定该哈希值所出自的两个更下一层树节点的哈希值中是否有完全由该业务节点没有查询权限的交易信息层层哈希运算得出的哈希值。也就是说，对所出自的交易信息不全是业务节点没有查询权限的交易信息的哈希值进行下一层的判断，确定其更下一层树节点的哈希值中是否有完全由该业务节点没有查询权限的交易信息层层哈希运算得出的哈希值，即是否有所出自的交易信息不全是业务节点没有查询权限的交易信息的哈希值。如图6a所示，对于哈希值h13，其由下一层的两个哈希值h9和h10经哈希运算得到，而h9出自交易信息1-2，h10出自交易信息3-4，其中都含有业务节点a有查询权限的交易信息(交易信息1和3)。对于哈希值h14，其由下一层的两个哈希值h11和h12经哈希运算得到，而h11出自交易信息5-6，其中含有业务节点a有查询权限的交易信息(交易信息5),h12出自交易信息7和8，其中不含有业务节点a有查询权限的交易信息。h12是完全由该业务节点没有查询权限的交易信息层层哈希运算得出的哈希值。然后，如果更下一层树节点的哈希值中有完全由该业务节点没有查询权限的交易信息层层哈希运算得出的哈希值，向该业务节点返回该哈希值，代替该哈希值所出自的、所述业务节点没有查询权限的交易信息。如图6a所示，由于h12是完全由该业务节点没有查询权限的交易信息层层哈希运算得出的哈希值，向业务节点a返回h12，代替其出自的交易信息7和8，从而达到掩盖交易笔数的目的。对于两个更下一层树节点的哈希值中不完全由该业务节点没有查询权限的交易信息层层哈希运算得出的哈希值，确定该哈希值所出自的两个再更下一层树节点的哈希值中是否有完全由该业务节点没有查询权限的交易信息层层哈希运算得出的哈希值，直到没有更下一层树节点；在没有更下一层树节点时，如果该树节点的哈希值是该业务节点有查询权限的交易信息的哈希值，则向业务节点返回该交易信息；反之，则向业务节点返回该交易信息的哈希值。如图6a所示，对于哈希值h9，确定其分别出自的两个更下一层哈希值h1和h2分别是否是完全由该业务节点a没有查询权限的交易信息层层哈希运算得出的哈希值。答案为否定。由于此时没有更下一层树节点的哈希值，对于业务节点a有查询权限的交易信息1，向业务节点a返回交易信息1。对于业务节点a没有查询权限的交易信息2，向业务节点a返回交易信息2的哈希值。对于哈希值h10和h12，也有类似的过程，故不赘述。该实施例的优点是，从默克尔树的树根开始自上而下进行判断，能够高效地找到代替交易信息数目最多的哈希值，提高掩盖交易笔数的效果。这一点在图6b上体现得更为明显。如果只是查找一个树节点，其哈希值完全由该业务节点没有查询权限的交易信息层层哈希运算得出，则很可能在图5b中找到树节点h17和h18，但显然h17和h18并不是能替代交易信息最多的哈希值。能替代交易信息最多的哈希值是h20，可以掩盖最多的交易笔数。如图8所示，在一个实施例中，所述数据区块中每个交易信息的顺序是通过以下方式确定的：步骤610、针对数据区块中的每个交易信息，根据每个业务节点的权限数据，确定有权查询该交易信息的业务节点数量；步骤620、按照有权查询各交易信息的业务节点数量的降序，将数据区块中的各交易信息排序。也就是说，在数据区块上链阶段，基于要添加到区块链上的一个数据区块中所要包括的交易信息，生成该数据区块的默克尔树根时，所述数据区块中每个交易信息的顺序是按照步骤610-620进行确定的。该实施例中，数据区块的交易信息中，有权限查询的业务节点多的交易信息排在前面。有权限查询的业务节点多，代表其在步骤330中与其它相邻交易信息一起被某一个哈希值集体代替返回给业务节点的几率小。让有权限查询的业务节点少的交易信息集中排在后面的位置，业务节点很可能对这些后面的交易信息都没有查询权限，从而为在步骤330中用一个哈希值集体代替更多的交易信息向业务节点返回提供了方便，有利于掩盖交易笔数。该排序在生成默克尔树根并生成数据区块上链的阶段就需要形成。由于默克尔树根是不可更改的，因此上链之后调整数据区块中交易信息的排序已经不可能。步骤610可以通过设置计数器来实现。在一个实施例中，步骤610包括：将计数器置0；针对数据区块中的每个交易信息，根据每个业务节点的权限数据，确定该业务节点是否有权查询该交易信息，如果是，将计数器加1；根据所有业务节点的权限数据，确定完该业务节点是否有权查询该交易信息，计数器的值即为确定有权查询该交易信息的业务节点数量。针对数据区块中的每个交易信息，根据每个业务节点的权限数据，确定该业务节点是否有权查询该交易信息，可以如前文提到的，根据该交易信息的施动方或受动方是否是所述权限数据中指示的目标业务节点之一来实现。如果该交易信息的施动方或受动方是业务节点的权限数据中指示的目标业务节点之一，则确定该业务节点有权查询该交易信息。通过上述实施方式，有效率地实现了针对数据区块中的每个交易信息，确定有权查询该交易信息的业务节点数量。如图9所示，在另一实施例中，所述数据区块中每个交易信息的顺序是通过以下方式确定的：步骤710、针对数据区块中的每个交易信息，根据每个业务节点的权限数据，确定有权查询该交易信息的所有业务节点；步骤720、获取有权查询该交易信息的每个业务节点的活跃度分数；步骤730、将针对数据区块中的每个交易信息获得的各业务节点的活跃度分数相加，得到该交易信息的活跃度总分；步骤740、按照数据区块中各交易信息的活跃度总分，将数据区块中的各交易信息排序。在步骤710中，针对数据区块中的每个交易信息，根据每个业务节点的权限数据，确定有权查询该交易信息的所有业务节点，可以如前文描述的，通过根据该交易信息的施动方或受动方是否是业务节点的权限数据中指示的目标业务节点之一来实现。如果该交易信息的施动方或受动方是业务节点的权限数据中指示的目标业务节点之一，则确定该业务节点有权查询该交易信息。为每个业务节点逐一执行上述确定过程，从而确定有权查询该交易信息的所有业务节点。在步骤720中，每个业务节点的活跃度分数是通过查询业务节点与活跃度分数对应关系表获得的。活跃度分数可以预先由平台根据该业务节点历史上进行区块链信息查询的次数来确定，例如可以设置成与该业务节点历史上进行区块链信息查询的次数成正比。该业务节点历史上进行区块链信息查询的次数，是指对在当前数据区块上链前对区块链上上链的所有数据区块的交易信息的查询的次数。在当前数据区块上链前，如果该业务节点对区块链上上链的数据区块的交易信息的查询的次数多，说明该业务节点比较活跃，喜欢查询一些交易信息，因此要为其设置比较大的活跃度分数。该业务节点历史上进行区块链信息查询的次数可以通过由记账节点向记账节点子网络中所有其它记账节点进行查询实现。在记账节点每接收到业务节点对交易信息的一次查询时，都进行记录。这样，通过由记账节点向记账节点子网络中所有其它记账节点进行查询，就可以获得所有其它记账节点接收到该业务节点的查询的数量，加上该记账节点本身记录的接收到该业务节点的查询的数量，即该业务节点历史上进行区块链信息查询的次数。然后，在步骤730中，将针对数据区块中的每个交易信息获得的各业务节点的活跃度分数相加，得到该交易信息的活跃度总分。该活跃度总分综合反映了有权查询该交易信息的业务节点的数目、以及这些业务节点的活跃程度。如果虽然有权查询某个交易信息的业务节点非常多，但都是平时不怎么查询的业务节点，当接收到一个业务节点的交易信息查询请求时，这个交易信息是该业务节点有权查询的交易信息的概率也是很低的，因为有权查询它的那些业务节点一般都不会发出查询请求。在步骤740中，按照数据区块中各交易信息的活跃度总分，将数据区块中的各交易信息排序。该实施例的优点在于，综合考虑了有权查询交易信息的业务节点的数目、以及这些业务节点的活跃程度对当接收到一个业务节点的交易信息查询请求时这个交易信息是该业务节点有权查询的交易信息的概率的影响，使得交易信息的排序更合理，更容易用一个哈希值掩盖更多的交易笔数。如图10所示，在一个实施例中，在步骤310之前，所述方法还包括：步骤301、生成业务节点与区块链运营方的智能合约；步骤302、将生成的智能合约同步到记账节点子网络中的各记账节点存储。该实施例中，该业务节点的权限数据从该记账节点存储的该业务节点与区块链运营方的智能合约中获取。该实施例中，每个业务节点与区块链运营方的智能合约都会存储在记账节点子网络中的各记账节点中。该实施例的好处是，由于智能合约都在各个记账节点本地存储，大大提高了向业务节点返回交易信息或哈希值的处理速度。智能合约是业务节点与区块链运营方事先订立的合约，其中存储着业务节点的各种权限数据(包括目标业务节点权限数据)。目标业务节点权限数据是指示该业务节点有权查询哪些目标业务节点的交易信息的数据，它表明：交易信息的施动方或受动方必须带有哪些目标业务节点中的至少一个，该业务节点才允许查询；或者，该交易信息的施动方是另一交易信息的受动方，而该另一交易信息的受动方必须带有哪些目标业务节点中的至少一个，该业务节点才允许查询。例如，a公司有两个分公司a1和a2，该业务节点a对应的目标业务节点权限数据可能就会指示，该业务节点a能够查询的目标业务节点包括a、a1、a2。一旦交易信息的施动方或受动方中含有a、a1、a2中的至少一个，或者，该交易信息的施动方是另一交易信息的受动方，而该另一交易信息的受动方中含有a、a1、a2中的至少一个，则业务节点a有权查询该交易信息，可以向其返回交易信息，否则只能返回交易信息的哈希值。在一个实施例中，步骤301包括：发布合约模板，所述合约模板中含有合约函数；接收利用所述合约函数设置的该业务节点的目标业务节点权限数据；将所述目标业务节点权限数据整合到所述合约模板中，形成该业务节点与区块链运营方的智能合约。合约模板是对于所有业务节点与区块链运营方的智能合约都适用于的合约样式。每个智能合约都可以套用该样式，只不过其中具体的权限数据不同而已。它是智能合约中除掉随着不同业务节点而不同的权限数据之后的格式段。合约函数是合约中设置的函数，用户通过调用该函数，可以设置目标业务节点权限数据。发布合约模板可以包括向该记账节点发布合约模板，也可以包括向记账节点子网络中所有记账节点发布合约模板。在前者的情况下，操作该记账节点的管理员可以在审核业务节点的具体情况后，为该业务节点确定权限数据并输入该记账节点。在后者的情况下，任一个记账节点的管理员都可以在审核业务节点的具体情况后，为该业务节点确定权限数据并输入该记账节点。审核的业务节点的具体情况包括业务节点所属单位下属单位或管辖单位的业务节点。每个业务节点是一个单位中的终端。业务节点所属单位就是该终端归属的单位。例如，发票开票企业的一台电脑作为业务节点，其所述单位就是该发票开票企业。该业务节点所属单位可能是它的分公司。另外，该业务节点所属单位可能是一个职能部门，其管辖单位就是该职能部门管辖的所有单位。例如，xx市地税局的管辖单位可以是xx市所有纳税单位。管理员可以将所述业务节点、以及该业务节点所属单位下属单位或管辖单位的业务节点确定为目标业务节点权限数据中指示的目标业务节点。例如，a公司有两个分公司a1、a2，可以将a、a1、a2确定为目标业务节点权限数据中指示的目标业务节点，即当交易信息施动方或受动方中出现a、a1、a2中的一个时，或者当该交易信息的施动方是另一交易信息的受动方，而该另一交易信息的受动方是a、a1、a2中的一个时，认为a公司具有对该交易信息的查询权限。管理员确定权限数据后，就在记账节点利用所述合约函数设置该业务节点的权限数据，这样，该记账节点就接收到利用所述合约函数设置的该业务节点的目标业务节点权限数据，将所述目标业务节点权限数据整合到所述合约模板中，就形成了该业务节点与区块链运营方的智能合约。该实施例的优点是，合约模板提供合约函数，让管理员根据业务节点的情况灵活设置目标业务节点权限数据，提高了目标业务节点权限数据设置的灵活性。在一个实施例中，步骤301包括：接收来自业务节点的智能合约生成请求，所述智能合约生成请求中指示业务节点所属单位下属单位或管辖单位的业务节点；根据业务节点所属单位下属单位或管辖单位的业务节点，确定目标业务节点权限数据；将所述目标业务节点权限数据整合到所述合约模板中，形成该业务节点与区块链运营方的智能合约。该实施例中，业务节点要生成智能合约时，发送一个智能合约生成请求，所述智能合约生成请求中指示业务节点所属单位下属单位或管辖单位的业务节点。记账节点接收该该智能合约生成请求后，根据业务节点所属单位下属单位或管辖单位的业务节点，自动确定目标业务节点权限数据，并将自动确定的所述目标业务节点权限数据整合到所述合约模板中。该实施例的优点是，实现了智能合约生成的自动化。上述的自动确定权限数据的方法如下。在一个实施例中，所述根据业务节点所属单位下属单位或管辖单位的业务节点，确定目标业务节点权限数据，包括：将所述业务节点、所述业务节点所属单位下属单位或管辖单位的业务节点，确定为目标业务节点权限数据中指示的目标业务节点。例如，a公司有两个分公司a1、a2，可以将a、a1、a2确定为目标业务节点权限数据中指示的目标业务节点。该实施例与如上所述的管理员根据该业务节点所属单位下属单位或管辖单位的业务节点确定目标业务节点权限数据的方法类似，只不过它是由机器直接将接收到的智能合约生成请求中的该业务节点所属单位下属单位或管辖单位的业务节点、以及所述业务节点本身，确定为目标业务节点权限数据，实现了确定的自动化。在另一个实施例中，智能合约不是实现存储在记账节点子网络的每个记账节点中，而是上链记录。这样，每个记账节点需要从智能合约中获取权限数据时，可以上链查找。该实施例的优点是，相比于每个记账节点内部维护一个数据库存储每个业务节点的智能合约，节省了节点内部存储空间的占用。如图11所示，在该实施例中，在步骤310之前，所述方法包括：步骤301、生成业务节点与区块链运营方的智能合约；步骤303、将生成的智能合约加入与该业务节点对应的智能合约区块，记录在区块链上。相应地，该业务节点的权限数据从区块链上与该业务节点对应的智能合约区块中的该业务节点与区块链运营方的智能合约中获取。图11的步骤301与图10的步骤301相同，故不赘述。在一个实施例中，步骤303包括：将生成的智能合约与该业务节点标识对应存储在该智能合约区块的区块体；对生成区块体施加摘要运算和签名运算，得到摘要和签名；将所述摘要、签名以及区块链上前一区块的摘要，加入智能合约区块的区块头；将该智能合约区块在记账节点子网络的所有记账节点间进行共识后，记录在区块链上。业务节点标识的作用是便于在步骤330中获取与业务节点对应的智能合约，从而获取权限数据。摘要和签名、以及区块链上前一区块的摘要的作用如前结合图2a-2c、图3a-3g、图4a-4g、图5a-5g所述，故不赘述。关于智能合约区块在记账节点子网络的所有记账节点间进行共识，目前有很多共识算法，故不赘述。如上所述，根据本公开一个实施例的在区块链网络中查询数据区块中的交易信息的方法由记账节点子网络中的一个记账节点执行。下面详细描述该记账节点的选出过程。在一个实施例中，如图12所示，执行所述方法的记账节点从记账节点子网络中按照以下方式选出。在一个实施例中，业务节点的查询请求先发送给代理节点，由代理节点按照以下步骤选出记账节点：步骤410、获取记账节点子网络中每个记账节点的处理负荷；步骤420、确定记账节点子网络中每个记账节点到发送所述查询请求的业务节点的距离；步骤430、基于所述处理负荷和所述距离，确定执行所述方法的记账节点。处理负荷是表示记账节点正在处理的任务的负担的参数。在一个实施例中，处理负荷可以用记账节点未处理完的任务数来衡量。这里的任务包括交易信息上链任务和查询任务。这些未处理完的任务数就能够代表记账节点的处理负荷。在一个实施例中，步骤410包括：获取每个记账节点定期发送的处理负荷并存储；将记账节点最近一次存储的记账节点的处理负荷作为获取的该记账节点的处理负荷。也就是说，在该实施例中，处理负荷可以由各记账节点定期(例如，每隔5秒)发送给代理节点。代理节点维护一张处理负荷表，该处理负荷表中记录接收到的各记账节点定期广播的处理负荷。这样，代理节点就可以将记账节点最近一次存储的记账节点的处理负荷作为获取的该记账节点的处理负荷。在该实施例中，代理节点被动接收记账节点定期发送的处理负荷。在另一个实施例中，代理节点主动查询记账节点的处理负荷。在该实施例中，步骤410包括：向记账节点子网络中每个记账节点发送处理负荷查询请求；接收每个记账节点发送来的该记账节点的处理负荷。在一个实施例中，步骤420中，确定记账节点子网络中每个记账节点到发送所述查询请求的业务节点的距离，包括：向记账节点子网络中每个记账节点、以及发送所述查询请求的业务节点发出定位信息请求；从各记账节点、以及发送所述查询请求的业务节点接收各记账节点、以及发送所述查询请求的业务节点的定位信息；利用各记账节点、以及发送所述查询请求的业务节点的定位信息，确定各记账节点到发送所述查询请求的业务节点的距离。每个业务节点和记账节点都可以具有gps等定位系统，因此，它们从自身具有的gps定位系统中就能够获得自身的定位信息。当接收到代理节点发来的定位信息请求时，将从gps系统中获得的自身的定位信息发送给代理节点。当代理节点获得了各记账节点、以及发送所述查询请求的业务节点的定位信息后，利用这些定位信息，就能够确定出各记账节点到发送所述查询请求的业务节点的距离。在上述实施例中，获得定位信息采用的是由代理节点主动请求的方式，与处理负荷一样，该定位信息也可以采用由各记账节点、以及发送所述查询请求的业务节点定期向代理节点发送的方式，故不赘述。该实施例的优点是，在确定执行所述方法的记账节点时，不仅考虑到每个记账节点的处理负荷，还考虑到每个记账节点离发送所述查询请求的业务节点的距离。虽然，可能某一记账节点的处理负荷最小，但是该记账节点离发送所述查询请求的业务节点可能非常远，将其选为执行所述方法的记账节点，增加了网络传输负担，也降低了查询处理速度。该实施例综合考虑了距离和处理负荷，比单纯根据距离或处理负荷来确定执行查询的记账节点的方案，既能大致均衡每个记账节点的处理负荷，又不给网络造成太大传输负担。在一个实施例中，如图13所示，步骤430可以包括：步骤4301、基于记账节点子网络中每个记账节点的所述处理负荷，确定每个记账节点的第一分数；步骤4302、基于记账节点子网络中每个记账节点的所述距离，确定每个记账节点的第二分数；步骤4303、基于每个记账节点的第一分数和第二分数，确定执行所述方法的记账节点。在步骤4301中，基于记账节点子网络中每个记账节点的所述处理负荷，确定每个记账节点的第一分数可以采取查找预先设置的处理负荷与第一分数对应关系表的形式。该处理负荷与第一分数对应关系表预先设置，其中处理负荷越大，第一分数越低。例如：处理负荷(未处理完的任务数)第一分数0-152-445-9310-19220-49150以上0表1处理负荷与第一分数对应关系表步骤4302中，基于记账节点子网络中每个记账节点的所述距离，确定每个记账节点的第二分数可以采取查找预先设置的距离与第二分数对应关系表的形式。该距离与第二分数对应关系表预先设置，其中距离越大，第二分数越低。例如：距离第二分数50米之内550-200米4200-1000米31000-5000米25000-20000米120000米以上0表2距离与第二分数对应关系表有了每个记账节点的第一分数和第二分数，就可以根据第一分数和第二分数确定执行所述方法的记账节点。该实施例的优点在于，将记账节点子网络中每个记账节点的所述处理负荷、和记账节点子网络中每个记账节点的所述距离这两个因素对选择执行所述方法的记账节点的影响分数化，提高了选择执行所述方法的记账节点的精确性。在一个实施例中，如图14所示，步骤4303包括：步骤43031、确定每个记账节点的第一分数和第二分数的加权和；步骤43032、基于所述加权和，确定执行所述方法的记账节点。在步骤43031中，确定加权和时，为第一分数和第二分数分配的权重可以是根据经验预设的。在步骤43032中，可以将所述加权和最大的记账节点，确定为接收所述待上链交易信息的记账节点，也可以将加权和大于预定加权和阈值的记账节点中任选一个，作为接收所述待上链交易信息的记账节点。可以认为，只要加权和大于预定加权和阈值，其都是负荷不算太大且距离发送待上链交易信息的业务节点不算太远的，选取哪一个作为执行所述方法的记账节点都是一样的。按照后一种方式，还有利于负载的均衡，防止在相同时间都选择加权和最大的记账节点，又造成该加权和最大的记账节点显然超负荷状态。该实施例的优点是，基于每个记账节点的第一分数和第二分数的加权和，确定接收所述待上链交易信息的记账节点，相比于基于第一分数和第二分数的和或平均值确定接收所述待上链交易信息的记账节点的方案，充分考虑到了第一分数和第二分数对于确定执行所述方法的记账节点的贡献的差异性，提高了确定执行所述方法的记账节点的合理性。上述确定接收所述待上链交易信息的记账节点的实施例主要针对图1a-1b的在记账节点子网络端没有分支记账节点子网络的情况。但在图1c所示的记账节点子网络端分为分支记账节点子网络的实施例中，则是另外一种情况。在该实施例中，查询请求中带有交易信息类型，例如是供应链金融交易，或电子发票交易，或法定数字货币交易。记账节点子网络中的记账节点预先按照处理的交易信息类型分类，分成的每一类的记账节点分别组成相应的一个分支记账节点子网络，例如，供应链金融交易分支记账节点子网络，或电子发票交易分支记账节点子网络，或法定数字货币交易分支记账节点子网络，每个分支记账节点子网络专门处理与一种交易类型对应的交易类型。因此，代理节点要根据查询请求中携带的交易信息类型，将该查询请求发到相应类型的分支记账节点子网络中的一个记账节点中。为了达到这一点，在代理节点中存储记账节点标识和交易信息类型对应关系表，记账节点标识和处理的交易信息类型对应记录在记账节点标识和交易信息类型对应关系表中。在该实施例中，如图15所示，执行所述方法的记账节点从记账节点子网络中按照以下方式选出：步骤510、获取查询请求中的交易信息类型；步骤520、从记账节点标识和交易信息类型对应关系表中，查找与查询请求中的交易信息类型对应的记账节点标识；步骤530、从找到的记账节点标识的记账节点中，确定接收所述待上链交易信息的记账节点。该实施例的好处是，对于图1c所示的记账节点子网络端分为分支记账节点子网络的体系构架，提出了一种适合该体系构架的合理选择执行所述方法的记账节点的方式。在一个实施例中，查询请求中的交易信息类型字段中包含交易信息类型。步骤510中，可以直接从该交易信息类型字段读出交易信息类型。由于代理节点上设置有记账节点标识和交易信息类型对应关系表，在一个实施例中，步骤520中，从该表中，可以查找到与查询请求中的交易信息类型对应的记账节点标识。如图16所示，在一个实施例中，步骤530包括：步骤5301、确定每个找到的记账节点标识的记账节点的处理负荷；步骤5302、确定每个找到的记账节点标识的记账节点到发送所述查询请求的业务节点的距离；步骤5303、基于所述处理负荷和所述距离，确定执行所述方法的记账节点。步骤5301-5303的具体实现过程与步骤410-430的具体实现过程类似，区别仅在于图16的实施例中确定处理负荷和到发送所述查询请求的业务节点的距离的记账节点的范围仅限于步骤520中找到的与查询请求中的交易信息类型对应的记账节点标识的记账节点，不是记账节点子网络中的所有记账节点，故不赘述。根据本公开的一个实施例，如图17所示，还提供了一种在区块链网络中查询数据区块中的交易信息的记账节点。所述区块链网络包括记账节点子网络和业务节点子网络。所述记账节点子网络包括将数据区块记录到区块链上的记账节点，所述业务节点子网络包括对记账节点记录到区块链上的数据区块进行验证的业务节点。所述在区块链网络中查询数据区块中的交易信息的记账节点包括：查询请求接收单元910，用于接收业务节点对数据区块中的交易信息的查询请求；默克尔树获取单元920，用于获取该数据区块的默克尔树，所述默克尔树通过以下方式形成：按照数据区块中每个交易信息的顺序，排在第奇数位的交易信息和之后相邻的排在第偶数位的交易信息的哈希值组成一个对，对该对的两个哈希值进行哈希运算，得到该对的哈希值，再按照每个对在数据区块中的顺序，排在第奇数位的对和之后相邻的排在第偶数位的对组成一个更上一层的对，将每个更上一层的对中的两个对的哈希值进行哈希运算，得到该更上一层的对的哈希值，直到得到最上一层的对的哈希值，即为默克尔树根，上述每个层的哈希值为默克尔树的一个树节点；返回单元930，用于如果根据该业务节点的权限数据，确定该默克尔树中的一个树节点的哈希值完全由该业务节点没有查询权限的交易信息层层哈希运算得出，则向该业务节点返回该树节点的哈希值，代替该哈希值所出自的、所述业务节点没有查询权限的交易信息。在一个实施例中，返回单元930进一步用于：如果该默克尔树的默克尔树根所出自的两个下一层树节点的哈希值中有完全由该业务节点没有查询权限的交易信息层层哈希运算得出的哈希值，向该业务节点返回该树节点的哈希值，代替该哈希值所出自的、所述业务节点没有查询权限的交易信息；对于默克尔树根所出自的两个下一层树节点的哈希值中不完全由该业务节点没有查询权限的交易信息层层哈希运算得出的哈希值，确定该哈希值所出自的两个更下一层树节点的哈希值中是否有完全由该业务节点没有查询权限的交易信息层层哈希运算得出的哈希值；如果更下一层树节点的哈希值中有完全由该业务节点没有查询权限的交易信息层层哈希运算得出的哈希值，向该业务节点返回该哈希值，代替该哈希值所出自的、所述业务节点没有查询权限的交易信息；对于两个更下一层树节点的哈希值中不完全由该业务节点没有查询权限的交易信息层层哈希运算得出的哈希值，确定该哈希值所出自的两个再更下一层树节点的哈希值中是否有完全由该业务节点没有查询权限的交易信息层层哈希运算得出的哈希值，直到没有更下一层树节点；在没有更下一层树节点时，如果该树节点的哈希值是该业务节点有查询权限的交易信息的哈希值，则向业务节点返回该交易信息；反之，则向业务节点返回该交易信息的哈希值。在一个实施例中，所述数据区块中每个交易信息的顺序是通过以下方式确定的：针对数据区块中的每个交易信息，根据每个业务节点的权限数据，确定有权查询该交易信息的业务节点数量；按照有权查询各交易信息的业务节点数量的降序，将数据区块中的各交易信息排序。在一个实施例中，所述数据区块中每个交易信息的顺序是通过以下方式确定的：针对数据区块中的每个交易信息，根据每个业务节点的权限数据，确定有权查询该交易信息的所有业务节点；获取有权查询该交易信息的每个业务节点的活跃度分数；将针对数据区块中的每个交易信息获得的各业务节点的活跃度分数相加，得到该交易信息的活跃度总分；按照数据区块中各交易信息的活跃度总分，将数据区块中的各交易信息排序。在一个实施例中，该业务节点的权限数据从业务节点与区块链运营方的智能合约中获取。在一个实施例中，所述记账节点还包括：智能合约生成单元(未示)，用于生成业务节点与区块链运营方的智能合约；同步单元(未示)，用于将生成的智能合约同步到记账节点子网络中的各记账节点存储。该业务节点的权限数据从该记账节点存储的该业务节点与区块链运营方的智能合约中获取。在一个实施例中，所述记账节点还包括：智能合约生成单元(未示)，用于生成业务节点与区块链运营方的智能合约；智能合约上链单元(未示)，用于将生成的智能合约加入与该业务节点对应的智能合约区块，记录在区块链上。该业务节点的权限数据从区块链上与该业务节点对应的智能合约区块中的该业务节点与区块链运营方的智能合约中获取。在一个实施例中，所述智能合约生成单元进一步用于：接收来自业务节点的智能合约生成请求，所述智能合约生成请求中指示业务节点所属单位下属单位或管辖单位的业务节点，根据业务节点所属单位下属单位或管辖单位的业务节点，确定目标业务节点权限数据；将所述目标业务节点权限数据整合到所述合约模板中，形成该业务节点与区块链运营方的智能合约。在一个实施例中，所述根据业务节点所属单位下属单位或管辖单位的业务节点，确定目标业务节点权限数据，包括：将所述业务节点、所述业务节点所属单位下属单位或管辖单位的业务节点，确定为目标业务节点权限数据中指示的目标业务节点。在一个实施例中，所述执行所述方法的记账节点从记账节点子网络中按照以下方式选出：获取记账节点子网络中每个记账节点的处理负荷；确定记账节点子网络中每个记账节点到发送所述查询请求的业务节点的距离；基于所述处理负荷和所述距离，确定执行所述方法的记账节点。在一个实施例中，所述基于所述处理负荷和所述距离，确定执行所述方法的记账节点，包括：基于记账节点子网络中每个记账节点的所述处理负荷，确定每个记账节点的第一分数；基于记账节点子网络中每个记账节点的所述距离，确定每个记账节点的第二分数；基于每个记账节点的第一分数和第二分数，确定执行所述方法的记账节点。在一个实施例中，所述基于每个记账节点的第一分数和第二分数，确定执行所述方法的记账节点，包括：确定每个记账节点的第一分数和第二分数的加权和；基于所述加权和，确定执行所述方法的记账节点。根据本公开实施例的在区块链网络中查询数据区块中的交易信息的方法可以由图18的在区块链网络中查询数据区块中的交易信息的记账节点21实现。下面参照图18来描述根据本公开实施例的在区块链网络中查询数据区块中的交易信息的记账节点21。图18显示的在区块链网络中查询数据区块中的交易信息的记账节点21仅仅是一个示例，不应对本公开实施例的功能和使用范围带来任何限制。如图18所示，在区块链网络中查询数据区块中的交易信息的记账节点21以通用计算设备的形式表现。在区块链网络中查询数据区块中的交易信息的记账节点21的组件可以包括但不限于：上述至少一个处理单元810、上述至少一个存储单元820、连接不同系统组件(包括存储单元820和处理单元810)的总线830。其中，所述存储单元存储有程序代码，所述程序代码可以被所述处理单元810执行，使得所述处理单元810执行本说明书上述示例性方法的描述部分中描述的根据本发明各种示例性实施方式的步骤。例如，所述处理单元810可以执行如图7中所示的各个步骤。存储单元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盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、移动终端、或者网络设备等)执行根据本公开实施方式的方法。本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其它实施方案。本申请旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本
技术领域：
中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由所附的权利要求指出。当前第1页12