CN109447811B

CN109447811B - Method, accounting node and medium for inquiring transaction information in blockchain network

Info

Publication number: CN109447811B
Application number: CN201811495810.3A
Authority: CN
Inventors: 李茂材; 王宗友; 孔利; 杨常青; 周开班; 时一防; 蓝虎; 张劲松; 丁勇; 刘区城; 朱耿良; 陈秋平
Original assignee: Shenzhen Zhishuilian Technology Co ltd
Current assignee: Shenzhen Zhishuilian Technology Co ltd
Priority date: 2018-12-07
Filing date: 2018-12-07
Publication date: 2024-01-02
Anticipated expiration: 2038-12-07
Also published as: CN110851496A; CN110851496B; CN109447811A

Abstract

The present disclosure provides a method, billing node, and medium for querying transaction information in a blockchain network. The blockchain network includes a billing node subnetwork and a service node subnetwork. The method is performed by an accounting node in an accounting node sub-network, the method comprising: receiving a query request of a service node for transaction information in a data block; acquiring target service node authority data corresponding to the service node, wherein the service node is authorized to inquire transaction information of a target service node indicated in the target service node authority data; if the actor or the follower of the transaction information is one of the target service nodes indicated in the target service node authority data, the transaction information is returned to the service node. The embodiment of the disclosure enables a user inquiring the transaction information on the blockchain to only inquire the transaction information related to the user, thereby preventing the transaction information from being leaked.

Description

Method, accounting node and medium for inquiring transaction information in blockchain network

Technical Field

The present disclosure relates to the field of blockchains, and in particular to a method, billing node, and medium for querying transaction information in a data block in a blockchain network.

Background

In a conventional blockchain network, the transaction data for the uplink is stored in full redundancy by each billing node in the blockchain network. Each billing node may view all transaction information on the blockchain. If a certain enterprise wants its own uplink transaction information to have privacy, it cannot be done without being checked by other enterprises.

Therefore, it is desirable to have a blockchain network with good privacy so that users querying transaction information on the blockchain can only query the transaction information related to themselves, thereby preventing the transaction information from leaking.

Disclosure of Invention

It is an object of the present disclosure to enable a user querying transaction information on a blockchain to query only transaction information related to the user, thereby preventing the transaction information from being leaked.

According to an aspect of an embodiment of the present disclosure, there is disclosed a method of querying transaction information in a data block in a blockchain network, the blockchain network including a billing node subnetwork including billing nodes that record the data block onto the blockchain and a service node subnetwork including service nodes that verify the data block recorded onto the blockchain by the billing nodes, the method performed by one of the billing nodes in the billing node subnetwork, the method comprising: receiving a query request of a service node for transaction information in a data block; acquiring target service node authority data corresponding to the service node, wherein the service node is authorized to inquire transaction information of a target service node indicated in the target service node authority data; if the actor or the follower of the transaction information is one of the target service nodes indicated in the target service node authority data, the transaction information is returned to the service node.

According to an aspect of an embodiment of the present disclosure, there is disclosed an accounting node for querying transaction information in a data block in a blockchain network, the blockchain network including an accounting node sub-network and a service node sub-network, the accounting node sub-network including an accounting node for recording the data block onto a blockchain, the service node sub-network including a service node for validating the data block recorded onto the blockchain by the accounting node, the accounting node comprising: a query request receiving unit, configured to receive a query request of a service node for transaction information in a data block; a target service node authority data obtaining unit, configured to obtain target service node authority data corresponding to the service node, where the service node is authorized to query transaction information of a target service node indicated in the target service node authority data; and the transaction information return unit is used for returning the transaction information to the service node if the acting party or the driven party of the transaction information is one of the target service nodes indicated in the target service node authority data.

According to an aspect of an embodiment of the present disclosure, there is disclosed an accounting node comprising: a memory storing computer readable instructions; a processor reads the computer readable instructions stored by the memory to perform the method as described above.

According to an aspect of the disclosed embodiments, a computer program medium is disclosed, on which computer readable instructions are stored which, when executed by a processor of a computer, cause the computer to perform the method as described above.

In the disclosed embodiment, the billing node subnetwork is separate from the service node subnetwork. The accounting nodes in the accounting node subnetwork will have a consensus on the uplink transaction information. The service nodes in the service node sub-network do not have consensus on the uplink transaction information, which provides a preliminary possibility that the transaction information is not compromised. On the basis, the accounting node receives a query request of the service node for transaction information in the data block, and acquires the target service node authority data corresponding to the service node. This target service node entitlement data indicates which target service nodes the service node is able to query for transaction information related to. If the actor or the follower of the transaction information is one of the target service nodes indicated in the target service node authority data, the transaction information is indicated to be within the authority range of the service node, and the service node is authorized to inquire the transaction information and return the transaction information to the service node. Therefore, the user inquiring the transaction information on the blockchain can only inquire the transaction information related to the user, and the transaction information is prevented from being leaked.

Other features and advantages of the present disclosure will be apparent from the following detailed description, or may be learned in part by the practice of the disclosure.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the disclosure.

Drawings

The above and other objects, features and advantages of the present disclosure will become more apparent by describing in detail exemplary embodiments thereof with reference to the attached drawings.

1A-1C illustrate three architectural diagrams of a method of querying transaction information in a data chunk in a blockchain network according to an embodiment of the present disclosure.

Fig. 2A-2C illustrate a scene architecture diagram of a method of querying transaction information in a data block in a blockchain network applied in three different application scenarios of supply chain finance, electronic invoice, legal digital currency, according to one embodiment of the disclosure.

Fig. 3A-3G illustrate a business node display interface diagram for a method of querying transaction information in a data chunk in a blockchain network in a supply chain financial application scenario, representing the general process of uploading transaction information to querying transaction information and verifying the content of the data chunk in the supply chain financial application scenario, according to one embodiment of the present disclosure.

Fig. 4A-4G illustrate a business node display interface diagram for a method of querying transaction information in a data chunk in a blockchain network in an electronic invoice application scenario, the interface diagrams representing the general process of uploading transaction information to querying transaction information and verifying the content of the data chunk in the electronic invoice application scenario, according to one embodiment of the present disclosure.

5A-5G illustrate a method of querying transaction information in a data chunk in a blockchain network applied to service node display interface diagrams in a quorum money application scenario, which illustrate the general process of linking up from transaction information to querying transaction information and verifying the content of the data chunk in the quorum money application scenario, in accordance with one embodiment of the present disclosure.

Fig. 6 illustrates a flowchart of a method of querying transaction information in a data chunk in a blockchain network, according to an embodiment of the present disclosure.

Fig. 7 illustrates a flowchart of a method of querying transaction information in a data chunk in a blockchain network, according to an embodiment of the present disclosure.

Fig. 8 illustrates a flowchart of a method of querying transaction information in a data chunk in a blockchain network, according to an embodiment of the present disclosure.

Fig. 9 illustrates a flowchart of a method of querying transaction information in a data chunk in a blockchain network, according to an embodiment of the present disclosure.

Fig. 10 shows a specific flowchart of step 305 in fig. 10, according to one embodiment of the present disclosure.

Fig. 11 illustrates another specific flow diagram of step 305 in fig. 10 according to one embodiment of the present disclosure.

Fig. 12 illustrates a flowchart of determining an accounting node to perform the method of querying transaction information in a data chunk in a blockchain network according to an embodiment of the present disclosure.

Fig. 13 shows a detailed flow chart of step 430 of fig. 12 according to one embodiment of the present disclosure.

Fig. 14 shows a detailed flow chart of step 4303 of fig. 13 according to one embodiment of the present disclosure.

Fig. 15 illustrates a flowchart of determining an accounting node performing the method of querying transaction information in a data chunk in a blockchain network according to an embodiment of the present disclosure.

Fig. 16 shows a detailed flow chart of step 530 in fig. 15 according to one embodiment of the present disclosure.

Fig. 17 illustrates an example diagram of determining whether to return transaction information to a service node based on a comparison of the actor or the recipient of the transaction information and the target service node entitlement data, according to one embodiment of the present disclosure.

Fig. 18A-B illustrate an interactive flow diagram for querying transaction information in a data chunk in a blockchain network in accordance with two embodiments of the present disclosure.

Fig. 19 illustrates a block diagram of a billing node querying transaction information in a data block in a blockchain network in accordance with an embodiment of the present disclosure.

Fig. 20 illustrates a hardware block diagram of an accounting node according to one embodiment of the present disclosure.

Detailed Description

Example embodiments will now be described more fully with reference to the accompanying drawings. However, the exemplary embodiments may be embodied in many forms and should not be construed as limited to the examples set forth herein; rather, these example embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the concept of the example embodiments to those skilled in the art. The drawings are merely schematic illustrations of the present disclosure and are not necessarily drawn to scale. The same reference numerals in the drawings denote the same or similar parts, and thus a repetitive description thereof will be omitted.

Furthermore, the described features, structures, or characteristics may be combined in any suitable manner in one or more example embodiments. In the following description, numerous specific details are provided to give a thorough understanding of example embodiments of the disclosure. One skilled in the relevant art will recognize, however, that the aspects of the disclosure may be practiced without one or more of the specific details, or with other methods, components, steps, etc. In other instances, well-known structures, methods, implementations, or operations are not shown or described in detail to avoid obscuring aspects of the disclosure.

Some of the block diagrams shown in the figures are functional entities and do not necessarily correspond to physically or logically separate entities. These functional entities may be implemented in software or in one or more hardware modules or integrated circuits or in different networks and/or processor devices and/or microcontroller devices.

The architecture and overall flow of an application of embodiments of the present disclosure will now be described with reference to FIGS. 1A-1C.

Fig. 1A illustrates an architecture of a blockchain network to which embodiments of the present disclosure are applied. The blockchain network includes a billing node subnetwork 2 and a service node subnetwork 1. The accounting node subnetwork 2 comprises accounting nodes 21 that record data blocks onto the blockchain. The service node subnetwork 1 comprises a service node 11 which validates the data blocks recorded by the accounting node onto the blockchain. The accounting node subnetwork 2 and the service node subnetwork 1 are connected by means of a proxy node 12. The proxy node 12 is a service node of the service node subnetwork 1, but is a more specific service node. It is responsible for delivering the information to be delivered by the accounting node 21 to the service node 11. The service node 11 is a terminal of a transaction party that generates various transaction information that needs to be linked up. They generate transaction information but have no rights to record directly to the blockchain, which must be recorded to the blockchain by an accounting node 21. Unified accounting by a few accounting nodes 21 also facilitates unified handling and policing of transactions, while business node 11 is able to conduct policing and witnessing of the linking of transaction information through information sent by accounting node 21 via agent node 12. This is of great importance in certain scenarios where there is a need for unified supervision but where there is a need for collective cheating of the supervising nodes and thus for supervision by the people. In the accounting node subnetwork 2, each accounting node 21 generates a data block, which is broadcast to other accounting nodes 21 for consensus and then uplink. In fig. 1A, the service node subnetwork 1 adopts a P2P network mode. P2P networks are a distributed application architecture that distributes tasks and workloads among peers (peers), a form of networking or network that Peer-to-Peer computing models form at the application layer, i.e., a "point-to-point" or "end-to-end" network. It can be defined as: participants in the network share a portion of the hardware resources (processing power, storage power, network connectivity, printers, etc.) they own, which provide services and content through the network that can be accessed directly by other peer nodes without going through intermediate entities. The participants in this network are both providers of resources, services and content and acquisitors of resources, services and content. Thus, in the service node subnetwork 1, the current proxy node 12 receives the message transmitted from the accounting node 21 and propagates it towards the surrounding service nodes 11. The surrounding service nodes 11 receive the message and transmit the message to the surrounding service nodes 11, and the message propagates layer by layer, so that the message propagates in each service node 11 of the service node sub-network 1.

Fig. 1B illustrates an architecture of another blockchain network to which embodiments of the present disclosure are applied. The architecture differs from the architecture of fig. 1A in that in the service node subnetwork 1 no P2P network mode is adopted, a broadcast network mode is adopted. The proxy node 12 receives the message delivered from the accounting node 21 and broadcasts the message to the other service nodes 11 in the service node subnetwork 1. In this way, the propagation of the message at each service node 11 of the service node subnetwork 1 is also achieved.

Fig. 1C illustrates an architecture of another blockchain network to which embodiments of the present disclosure are applied. The architecture differs from the architecture of fig. 1A in that its accounting node subnetwork 2 is divided into a plurality of branched accounting node subnetworks. Each branch accounting node subnetwork may be responsible for recording of certain types of transaction information. For example, an enterprise may have a supply chain financial business, and may need to record information such as contract information, credit, etc. generated during the supply and distribution process to the blockchain, and also issue an invoice, and record information such as issue invoice, reimbursement invoice, etc. to the blockchain. At this time, in order to facilitate the need for the accounting node to be administered by the same department, the accounting node that records the supply chain financial business transaction and the accounting node that records the transaction during the invoice flow may be separate departments. For example, the accounting node that records supply chain financial transactions is a bank-set accounting terminal, and the accounting node that records transactions during invoice flows is a national tax office-set accounting terminal. And the supply chain financial business transactions and transactions during the recording invoice flow may also eventually be recorded on different sub-block chains. At this time, the proxy node 12 transmits the transaction information to the branch accounting node sub-network corresponding to the transaction type according to the transaction type carried in the transaction information transmitted from the service node 11.

Fig. 2A illustrates a scene skeleton diagram of an application scenario in which a method of querying transaction information in a data block in a blockchain network is applied in supply chain finance according to one embodiment of the present disclosure.

Supply chain finance is one such business: often, a manufacturing enterprise produces a device or product, not necessarily all parts or components of the device or product, by its own enterprise, wherein the production of some parts or components requires outsourcing to other enterprises for production. The manufacturer makes a supply and sales contract with the ordering party in advance, but the manufacturer can only take the money when producing the whole equipment or product, and the money of purchasing parts or components in the process needs to be paid by the manufacturer, so that the capital turnover of the manufacturer is difficult. Accordingly, there is a need for a manufacturing company to secure a whole equipment or product by a total purchase contract (in which valuable and ordering party information) to a bank, and when a purchase of a part or component is required, a part of the secure for the purchase of the part or component is transferred from the total purchase contract of the equipment or product based on the total purchase contract of the whole equipment or product secured by the bank. In this way, the enterprise who generates the part or component can be relieved to produce the part or component, and the bank is guaranteed, so that the part of the transferred goods can not be received. Meanwhile, the manufacturer does not actually pay out the money at this time, but waits until the actual payment of the purchasing side of the whole equipment or product is obtained, and pays a corresponding part to the manufacturer of the parts or components.

In a traditional blockchain network, since all accounting nodes are set by banks and the network is closed, each node enterprise on the supply and sales chain is a node related to the uplink benefit of the data block of the supply chain finance, but cannot supervise and witness, and only can fully trust the accounting network consisting of the accounting nodes of the benefit independent party. For example, a manufacturing enterprise may have made a total purchase contract with a subscriber to an entire device or product, or a separate purchase contract with a part or component producer, all of which may require that these contracts be passed on to a billing node at the bank's facility. At this time, the accounting nodes set up by the bank can supervise and witness each other, but the node enterprises on the supply and sales chain cannot supervise and witness each other. In addition, in a conventional blockchain network, any other enterprise node that is not related to the current supply and distribution chain may query any transaction information that is uplink to the enterprise node on the current supply and distribution chain through the corresponding billing node. Therefore, the potential risk of leakage of transaction information is greatly brought.

However, in fig. 2A, since the accounting node subnetwork 2 is separate from the service node subnetwork 1, the accounting node subnetwork 2 is dedicated to accounting, and the service node subnetwork 1 contains node enterprise terminals in the supply and distribution chain, witnessing accounting for the accounting node 21. Once the accounting nodes 21 collectively cheat, each witness service node 11 retains evidence of the particular accounting node's disuse. Meanwhile, when the service node needs to inquire the transaction information, not all the transaction information can be returned to the service node, but whether the transaction data is returned to the service node is determined according to the authority data of the service node in the intelligent contract with the blockchain operator. Thus, any other enterprise node irrelevant to the current supply and sales chain cannot inquire any transaction information of the enterprise node uplink on the current supply and sales chain, and the hidden danger of transaction information leakage is eliminated.

In one example of an automotive supply chain finance, as shown in fig. 2A, each service node 11 includes an automotive manufacturer terminal, a tire manufacturer terminal, a rubber manufacturer terminal, a vehicle parts supplier terminal, a banking terminal, and the like. The automobile manufacturer makes a total purchase contract with an automobile ordering party, dials a part of the total purchase contract price for purchasing the tire, and dials a corresponding part of the total purchase contract price for purchasing the automobile parts. The tire manufacturer bases on the contract with the automobile manufacturer and dials a portion of the purchase of the rubber needed to manufacture the tire from the price of the contract. Thus, a layer-by-layer purchasing relationship is established.

When the vehicle manufacturer makes a total purchase contract with the vehicle ordering party, or the vehicle manufacturer makes a separate purchase contract with the tire manufacturer, the vehicle parts supplier, or the tire manufacturer makes a separate purchase contract with the rubber manufacturer, corresponding transaction information is transferred to the agent node 12, and one accounting node 21 is selected by the agent node 12. The proxy node 12 sends the corresponding transaction information to the selected accounting node 21 for caching. The accounting node 21 typically does not package a piece of transaction information individually into a data chunk uplink, but rather packages into a data chunk according to the chunk packing requirements (e.g., to stitch a sufficient number or size). Each billing node is assigned a signing key in advance, which is specific to that billing node. The accounting node 21 generates a signature based on transaction information to be included in one data chunk to be added to the blockchain using a key specific to the accounting node. The signature is generated by first generating a digest of the transaction information in the data block and then signing the digest with a signature algorithm using a key specific to the accounting node. Accounting nodes 21 add the transaction information and the generated signature to the data block, which is uplink after consensus among all accounting nodes 21, while sending the signature through proxy nodes 12 to each service node 11 in the service node subnetwork.

There may also be transaction information in the data blocks, or digests of transaction information, sent to each service node 11 simultaneously with the signature.

In case of simultaneous transmission of transaction information, the service node 11 obtains a billing node specific key. In the case of an asymmetric public private key pair, the key employed by the accounting node 21 in the accounting process is the private key assigned to the accounting node 21 by the authentication Center (CA). At the same time as the private key is assigned, a public key is also assigned to the accounting node 21. The public key is stored at the authentication center. The service node 11 may request from the authentication center to the public key assigned to the accounting node 21. This public key is the accounting node specific key acquired by the service node 11. The service node 11 decrypts the signature with the key to obtain a digest of the transaction information in the data block. The service node 11 calculates a digest of the transaction information in the data block received simultaneously. If the calculated digest is consistent with the decrypted digest, the signature verification is successful.

In case a digest of the transaction information is sent simultaneously (e.g. the digest and the signature are sent together in a block header), the service node 11 obtains a key specific to the accounting node, e.g. from an authentication center request to a public key assigned for the accounting node 21. The service node 11 decrypts the signature with a key specific to the accounting node resulting in a digest of the transaction information in the data block. If the digest received simultaneously with the signature is consistent with the digest obtained by decryption, the signature verification is successful.

In case a digest of the transaction information is transmitted simultaneously (e.g. the digest and the signature are transmitted together in a block header, which digest may be a merck tree root calculated from the hash value of each piece of transaction information to be included in the data block), the service node 11 does not receive each transaction information. The service node 11 needs to request from the accounting node 21 when it is to view the transaction information. At this point, the accounting node 21 obtains target service node entitlement data (typically derived from the service node implementing an intelligent contract with the blockchain operator) corresponding to the service node, the target service node entitlement data indicating which target service nodes the service node is permitted to access related transaction information. If the actor or the follower of the transaction information is one of the target service nodes indicated in the target service node authority data, the transaction information is returned to the service node. Therefore, the purpose that a plurality of units do not want own transaction information to be seen by irrelevant parties is achieved, and the privacy of the uplink transaction information is improved.

If transaction information is not returned to the service node (the service node has no authority), a hash value of the transaction information may be returned thereto. Because the Merker tree root can be calculated only by the hash value of each transaction information, the purposes of hiding the information and not influencing the content verification in the data block are achieved. The service node 11 may calculate hash values for the obtained non-hidden transaction information, calculate the merck tree root according to the hash values and the hash values of the received hidden transaction information, compare with the merck tree root contained in the block header, and if they are consistent, indicate that the content of the data block has not been tampered, and pass the content verification. And the service node 11 may also verify from the non-hidden transaction information whether the transaction information corresponds to the transaction information sent to the accounting node 21 itself. If the service nodes are inconsistent, the service nodes 11 are wrongly indicated, and the purpose of supervision is achieved.

The embodiment of the disclosure mainly aims at the process of acquiring the target service node authority data corresponding to the service node after receiving the inquiry request of the service node for the transaction information in the data block, and comparing the target service node authority data with an acting party or a driven party of the transaction information so as to determine whether to return the transaction information to the service node.

The general process of linking transaction information to queries and verification in a supply chain financial application scenario is described below in connection with fig. 3A-3G. Fig. 3A-3G are diagrams of a business node display interface in a supply chain financial application scenario for a method of querying transaction information in a data block in a blockchain network according to one embodiment of the present disclosure.

As shown in fig. 3A, B automobile factories are based on 1000 ten thousand purchase orders from a seller purchasing B automobile factories, with 200 ten thousand of 1000 ten thousand being guaranteed, and C tire factories are entrusted with producing tires with a selling price of 200 ten thousand. After the business person of the B-car factory enters the above transaction information at the business node 11 of the B-car factory, clicks the "submit to billing node" option, and the transaction information is sent to the billing node 21 through the proxy node 12. Accounting node 21 places transaction information to be included in a block of data to be added to the blockchain in a block body. The accounting node 21 also generates a summary of these transaction information, such as the merck tree root of fig. 3B. Accounting node 21 also generates a signature based on the transaction information in the data chunk using a key specific to the accounting node. The root of the merck tree, the signature, and the digest of the previous data block on the blockchain are placed in the block header together. The block header and the block body constitute a data block of the uplink, which is commonly known by all accounting nodes 21.

The accounting node 21 also transmits the block header to each service node 11. The merck root, signature, and digest of the previous data chunk on the blockchain are displayed on the screen of the service node 11 as shown in fig. 3B. At this point, the accounting node 21 obtains a key specific to the accounting node (e.g., by requesting an authentication center), and decrypts the signature with the accounting node-specific key to obtain a digest of the transaction information in the data chunk, i.e., the mercker root. If the received merck tree root in the block header is inconsistent with the decrypted merck tree root, signature verification fails and an interface as shown in fig. 3C is displayed. If the merck tree root in the received block header is consistent with the decrypted merck tree root, the signature verification is successful, and an interface shown in fig. 3D is displayed. Since in the above procedure the service node 11 only obtains the block header of the data block, the transaction information in the block header has not yet been obtained. At this time, the user is asked in the interface of fig. 3D whether to request transaction information in the data block.

If the user selects "yes" the service node 11 requests transaction information from the accounting node 21 via the proxy node 12. The accounting node 21 obtains target service node entitlement data for the service node 11 indicating which target service nodes the service node 11 is entitled to query for transaction information. If the actor or the follower of the transaction information is just one of the target service nodes indicated in the target service node authority data, the service node is indicated to have such query authority, and the transaction information is returned to the service node, such as the specific information of the transaction information ID 000083 and the specific information of the transaction information ID 000153 in fig. 3E. For transaction information in the data block that the service node 11 does not have the right to acquire, such as transaction information ID 000258, transaction information ID 000256, transaction information ID 078365, transaction information ID 018387, the hash value is returned only to the service node 11, as shown in fig. 3E.

After the user selects "perform content verification" on the interface of fig. 3E, for the specific information of the transaction information ID 000083 and the specific information of the transaction information ID 000153 in fig. 3E, the service node 11 calculates a hash value thereof, and then calculates a merck tree root together with the received hash value of the transaction information ID 000258, the hash value of the transaction information ID 000256, the hash value of the transaction information ID 078365, and the hash value of the transaction information ID 018387, and compares the merck tree root with the merck tree root contained in the block header, thereby performing content verification. If the accounting node 21 tampers with the contents of the data block, the calculated merck root is not consistent with the merck root contained in the block header, displaying an interface of "content verification failed" as shown in fig. 3F. If the calculated merck root is consistent with the merck root contained in the block header, an interface of "content verification successful" as shown in fig. 3G is displayed.

Fig. 2B illustrates a scene skeleton diagram of a method of querying transaction information in a data block in a blockchain network applied in an application scene of an electronic invoice according to an embodiment of the present disclosure.

In the traditional block chain application scenario of electronic invoices, the tax office issues invoices to the issuing enterprises, the issuing enterprises issue invoices to the ticket taker, and the ticket taker reimburses the invoices to the reimbursement unit where the ticket taker is located. All of these transactions require a chaining, i.e., recording onto the blockchain. However, these nodes are not billing nodes 21 for the tax office, billing enterprise, and reimbursement unit. They commit the corresponding accounting node or supernode to record these transactions on the blockchain. All the accounting nodes or super nodes are uniformly arranged by national tax departments. They can supervise and witness each other, but the nodes of the tax office, the billing enterprise and the reimbursement unit are direct relatives of the invoice, but cannot supervise and witness, but can only trust the billing node 21 completely. In addition, any enterprise can query any transaction information on the blockchain through its corresponding billing node. In some cases, however, the invoice-related information of the business may not be desired to be known by other businesses. In the disclosed embodiment, since the accounting node subnetwork 2 is separate from the service node subnetwork 1, the accounting node subnetwork 2 is dedicated to accounting, and the service node subnetwork 1 contains nodes that are related to the benefit of these invoices, accounting for accounting of the accounting node 21 is witnessed. Once the accounting nodes 21 collectively cheat, each witness service node 11 retains evidence of the particular accounting node's disuse. When any service node 1 needs to query the transaction information in the data block, the accounting node obtains the target service node authority data corresponding to the service node, where the target service node authority data indicates that the service node has authority to query the transaction information related to which target service nodes. If the actor or the passive of the transaction information is one of the target service nodes indicated in the target service node authority data, the transaction information is returned to the service node, otherwise, the transaction information is not returned. By the method, the privacy of the uplink transaction information is ensured. Under the condition that the service node has no authority, transaction information is not returned to the service node, but a hash value of the transaction information is returned, so that the service node can verify the Merker tree root in the block head by using the hash value, and the purpose of content verification is achieved.

In one example of an electronic invoice, as shown in fig. 2B, each service node 11 includes an issuing authority terminal, a sales person's mobile phone, a reimbursement authority terminal, a tax office terminal, and the like.

When the local tax office issues an invoice for an issuing unit, or the issuing unit issues an invoice, or a reimburser reimburses for reimbursement at a reimbursement unit, corresponding transaction information (transfer of ownership of the invoice) is transferred to the agent node 12, and one of the accounting nodes 21 is selected by the agent node 12. The proxy node 12 sends the corresponding transaction information to the selected accounting node 21 for caching. The accounting node 21 then packs into blocks of data according to the block packing requirements. The accounting node 21 generates a signature based on the transaction information in the data block, adds the signature to the block header back-up of the data block and sends the signature to the service node 11, similar to the process shown in connection with fig. 2A.

There may also be transaction information in the data blocks, or digests of transaction information, sent to each service node 11 simultaneously with the signature. In the case where transaction information is transmitted simultaneously and in the case where the digest is transmitted simultaneously, the signature verification method at the service node 11 is different, but the signature verification can be performed at the service node 11. This is similar to the process described above in connection with fig. 2A, and reference may be made to the associated description described above in connection with fig. 2A. In addition, in the case of simultaneously transmitting the digest of the transaction information, the service node 11 may perform content verification of the data block, and the verification process is similar to the process described above in connection with fig. 2A, so that a detailed description is omitted.

Fig. 4A-4G illustrate a business node display interface diagram of a method for querying transaction information in a data block in a blockchain network in an electronic invoice application scenario, which illustrates the general process of transaction information linking, querying and verifying in the electronic invoice application scenario, according to one embodiment of the present disclosure.

As shown in fig. 4A, at 22 days of 10 in 2018, liu Shan to rainbow computer company purchased a computer for the unit metaplasia company, spending 3000 yuan. Rainbow computer company invoices Liu Shan with a transaction ID of 000083. After the staff of the rainbow computer company has entered the above information, click on the "submit to billing node" option and the transaction information is sent to billing node 21 through agent node 12. Accounting node 21 places transaction information to be included in a block of data to be added to the blockchain in a block body. Billing node 21 also generates a merck root and signature, which are placed in the block header along with the digest of the previous data block on the blockchain. Accounting node 21 uplinks the data blocks and sends the block header to each service node 11. The merck root, signature, and digest of the previous data chunk on the blockchain are displayed on the screen of the service node 11 as shown in fig. 4B.

Then, the accounting node 21 performs signature verification, displays the interface of fig. 4C or fig. 4D according to the verification result, and requests transaction information from the accounting node 21, displays the interface of the acquired transaction information or the hash value of the transaction information shown in fig. 4E, and then displays the interfaces of fig. 4F to 4G respectively according to the verification result of content verification. These processes are similar to those shown in fig. 3C-3G and are not described in detail.

FIG. 2C illustrates a scene skeleton diagram of a method of querying transaction information in a data block in a blockchain network applied in an application scene of quorum currency in accordance with an embodiment of the present disclosure.

In the scenario of legal digital currency, the digital currency is issued by an official, must be regulated by the official, and the public needs to trust the digital currency, so that the collective cheating of the official accounting nodes is prevented, and the problem that the existing network system faces the balance of government regulation and public trust is generated. In addition, in the existing blockchain network, each node is used as an accounting node and a witness node, so that a user of each node can see all transaction information recorded on the blockchain, and certain units of transaction information are not hopefully exposed to all people, and privacy protection is also generated.

In this case, the separate solutions of the billing node subnetwork and the service node subnetwork of the embodiments of the present disclosure completely avoid this problem. First, each accounting node of the accounting node subnetwork is of an official nature. A transaction of the quorum currency occurs at any one of the service nodes, which is recorded onto the blockchain by the corresponding accounting node. However, each service node in the service node subnetwork may witnessed the accounting of the accounting node 21. Once the accounting nodes 21 are collectively cheated, each witness service node 11 retains evidence of the particular accounting node's disuse, taking into account government regulations and public trust. Meanwhile, the service node needs to inquire the transaction information, and obtains the target service node authority data corresponding to the service node, wherein the target service node authority data indicates that the service node has the authority to inquire the transaction information related to the target service node. If the actor or the follower of the transaction information is one of the target service nodes indicated in the target service node authority data, the transaction information is returned to the service node. When the service node does not have the right, the transaction information is not returned to the service node, but the hash value of the transaction information is returned, and the merck tree root in the block head can be verified through the hash value, so that the content verification is realized.

In one example of a quorum, as shown in FIG. 2C, each service node 11 includes a respective transaction terminal involved in the circulation of the quorum. When sending the transaction information of the legal digital currency, the transaction terminal delivers the corresponding transaction information (transfer of ownership of the legal digital currency) to the proxy node 12, and one of the accounting nodes 21 is selected by the proxy node 12. The proxy node 12 sends the corresponding transaction information to the selected accounting node 21 for caching. The accounting node 21 then packs into blocks of data according to the block packing requirements. The accounting node 21 generates a signature based on the transaction information in the data block, adds the signature to the block header back-up of the data block and sends the signature to the service node 11, similar to the process shown in connection with fig. 2A.

5A-5G illustrate a business node display interface diagram for a business node in a quorum money application scenario, where a method of querying transaction information in a data chunk in a blockchain network, in accordance with an embodiment of the present disclosure, shows the general process of accounting and witness in the quorum money application scenario.

As shown in FIG. 5A, at 29 of 2018, since X company buys a piece of furniture with a legal digital money of 3000 units of selling price from Y company, it pays out a legal digital money of 3000 units of RMB to Y company. After the X company's sponsor enters the above information, click on the "submit to billing node" option, and the transaction information is sent to billing node 21 through agent node 12. Accounting node 21 places transaction information to be included in a block of data to be added to the blockchain in a block body. Billing node 21 also generates a merck root and signature, which are placed in the block header along with the digest of the previous data block on the blockchain. Accounting node 21 uplinks the data blocks and sends the block header to each service node 11. The merck root, signature, and digest of the previous data chunk on the blockchain are displayed on the screen of the service node 11 as shown in fig. 5B.

Then, the accounting node 21 performs signature verification, displays the interface of fig. 5C or 5D according to the verification result, and requests transaction information from the accounting node 21, displays the interface of the acquired transaction information or hash value of the transaction information shown in fig. 5E, and then displays the interfaces of fig. 5F to 5G respectively according to the verification result of content verification. These processes are similar to those shown in fig. 3C-3G and are not described in detail.

As shown in fig. 6, according to one embodiment of the present disclosure, a method of querying transaction information in a data chunk in a blockchain network is provided. As shown in fig. 1A-1C, the blockchain network includes a billing node subnetwork 2 and a service node subnetwork 1. The accounting node subnetwork 2 comprises accounting nodes 21 that record blocks of data onto a blockchain. The service node subnetwork 1 comprises service nodes 11 for verifying data blocks recorded by accounting nodes onto the blockchain. The method is performed by one of the accounting nodes 21 in the accounting node sub-network 2. The method comprises the following steps:

step 310, receiving a query request of a service node for transaction information in a data block;

step 320, obtaining the target service node authority data corresponding to the service node, wherein the service node is authorized to inquire the transaction information of the target service node indicated in the target service node authority data;

Step 330, if the actor or the follower of the transaction information is one of the target service nodes indicated in the target service node authority data, the transaction information is returned to the service node.

Steps 310-330 are described in detail below.

In step 310, there are a number of ways in which the billing node may receive a query request from a service node for transaction information in a data block. In one embodiment, the accounting node may receive a query request for transaction information in the data block by a proxy node, which is a special node in the service node subnetwork for communicating information between the service node and the accounting node. The service node sends the query request to the proxy node, and the proxy node sends the query request to a corresponding billing node in the billing node subnetwork to select the billing node. In another embodiment, the service node may send the query request directly to the accounting node. The method by which the service node selects the accounting node may be the same as the method by which the proxy node selects the accounting node.

In step 320, the accounting node obtains the target service node authority data corresponding to the service node. The target service node entitlement data indicates which target service nodes the service node is entitled to query for transaction information. The service node is authorized to inquire the transaction information of the target service node indicated in the permission data of the target service node.

In one embodiment, a table of correspondence between service node and target service node entitlement data is maintained in advance at each billing node. The accounting node can acquire the target service node authority data corresponding to the service node by inquiring the corresponding relation table.

In another embodiment, each service node has a smart contract with the blockchain operator in advance. The target service node authority data corresponding to the service node can be acquired from the intelligent contracts of the service node and the blockchain operator. How the smart contract is generated is described in the later embodiments.

In step 330, if the actor or the recipient of the transaction information is one of the target service nodes indicated in the target service node entitlement data, the transaction information is returned to that service node.

It is well known that a transaction is the action that one party causes another party. The party that causes the behavior is the actor and the party that is caused the behavior is the victim. For example, in a transaction for issuing an electronic invoice, the issuing entity terminal is the actor and the ticket collector terminal is the recipient. In a transfer transaction of a quorum, the transfer-out terminal of the quorum is the actor and the transfer-in terminal of the quorum is the recipient.

As shown in fig. 17, each piece of transaction information includes actor information and recipient information. The actor information includes actor-related information, and the receiver information includes receiver-related information. For example, in the event of issuing an electronic invoice, the actor information includes the name of the issuing unit, the tax identifier of the issuing unit, the name of the issuing unit, the time of issuing, the amount of issuing, etc., and the receiver information includes the name of the ticket collector, the contact information of the ticket collector, the reimbursement unit where the ticket collector is located, etc. There are two expression methods of the actor in the transaction information, one is directly expressed by the actor name (for example, the name of the billing unit, the name of the legal digital money transfer unit, etc.) (for example, the actor of the transaction information TX3 is a in fig. 17, the actor of the transaction information TX3 is the unit terminal with the name a), the other is expressed by the other transaction information, the actor of the present transaction information is the actor of the other transaction information (for example, the actors of the transaction information TX1 and TX2 are TX0 in fig. 17, the actors of the transaction information TX1 and TX2 are the actors of the transaction information TX 0; the actor of TX4 is TX1+tx2, and the actor of the transaction information TX4 is the actors of the transaction information TX1 and TX 2).

For example, the actor in the electronic invoice reimbursement transaction information may be the passive actor in the electronic invoice reimbursement transaction information, i.e., the actor becomes the actor when the ticket taker who has acquired the electronic invoice in the invoicing event returns to the unit in which it is located. When multiple ticket collectors jointly reimburse in the same unit, the actor in reimbursement transaction information may come from the passive party in multiple invoicing transaction information.

The target service node entitlement data indicates a target service node to which the service node is entitled to query. If the actor or the victim of the transaction information is one of the target service nodes indicated in the target service node entitlement data, then the transaction information is returned to either that actor or the victim falls within the allowed entitlements.

In one embodiment, after step 320, the method further comprises: if the actor of the transaction information is the follower of the further transaction information and the follower of the further transaction information is one of the target service nodes indicated in the target service node entitlement data, the transaction information is returned to the service node.

As described above, there are two types of representations of the actors in the transaction information, one is represented by the actor name directly, and the other is represented by other transaction information, and the actor representing the present transaction information is the slave of the other transaction information. Thus, if the party acting on the transaction information is the latter representation, i.e. the party acting on the transaction information is the party acting on the other transaction information, the party acting on the other transaction information is one of the target service nodes indicated in the target service node entitlement data, in this case it also becomes equivalent that the actor of the transaction information is in fact also one of the target service nodes indicated in the target service node entitlement data, which service node should also have the right to query the target service node for transaction information.

As shown in fig. 17, the actor of the transaction information TX4 is denoted by TX1+tx2, that is, the actor of the transaction information TX4 is the slave of the transaction information TX1 and the slave of the transaction information TX 2. For example, transaction information TX4 is transaction information for electronic invoice reimbursement, and transaction information TX1 and TX2 are transaction information for two electronic invoice invoices, respectively. In the transaction information TX1, A1 is a ticket collector. In the transaction information TX2, B is the ticket collector. The actor TX1+ TX2 of TX4 represents that the follower of TX1 (i.e., ticketing person A1) and the follower of TX2 (i.e., ticketing person B) cancel together. Thus, the actor of the transaction information TX4 on the surface is denoted by TX1+ TX2, and in practice, its actor is a1+b. Thus, if the target service node entitlement data indicates that the service node a is entitled to query the transaction information for service nodes a and A1 (A1 is a subsidiary of a), A1 of a1+b is for which service node a is entitled to query the transaction information. Thus, transaction information may be returned to the service node.

This embodiment overcomes the problem that when the party being the transaction information is represented by other transaction information (i.e. the party being the recipient of this transaction information) it is possible to determine from the party being the transaction information alone whether it is one of the target service nodes indicated in the target service node entitlement data that is incorrect, since in this case the party being the transaction information is essentially one of the target service nodes indicated in the target service node entitlement data, but is not formally, thus causing a false positive. This embodiment improves the accuracy of determining whether transaction information should be returned to the service node.

In one embodiment, after step 320, the method further comprises: step 330, if the actor or the follower of the transaction information is neither one of the target service nodes indicated in the target service node authority data nor the follower of the other transaction information, which is one of the target service nodes indicated in the target service node authority data, the hash value of the transaction information is returned to the service node.

That is, in both cases (the first case is that the actor or the follower of the transaction information is itself one of the target service nodes indicated in the target service node authority data, the second case is that the actor of the transaction information is the follower of the other transaction information, and the follower of the other transaction information is one of the target service nodes indicated in the target service node authority data), the service node should be considered to have authority to query the transaction information. If it does not belong to the two cases, i.e. that the actor or the follower of the transaction information is neither one of the target service nodes indicated in the target service node entitlement data nor the follower of the further transaction information, which is one of the target service nodes indicated in the target service node entitlement data, it is considered that the service node has no authority to query the transaction information, and that no transaction information should be returned to the service node, only the hash value of the transaction information may be returned for content verification.

Since the merck tree root can be calculated only by the hash value of each transaction information, the service node 11 can calculate the hash value of the obtained non-hidden transaction information, calculate the merck tree root according to the hash values and the hash value of the received hidden transaction information, compare with the merck tree root contained in the block header, if the result is consistent, the content of the data block is not tampered, and the content verification is passed, thereby achieving the purpose of preventing the accounting node from tampering with the transaction information content.

In one embodiment, as shown in FIG. 7, step 310 includes: a query request by a service node for transaction information in a data block and a signature generated for the query request with a private key specific to the service node are received. In addition, prior to step 320, the method further comprises: step 312, the signature is verified by using the public key specific to the service node, wherein the target service node authority data corresponding to the service node is obtained only if the verification is successful.

The embodiment of fig. 7 adds a process of verifying the identity of the service node compared to the embodiment of fig. 6, and if the identity of the service node is not acceptable, i.e. not a node registered in the blockchain network (including the service node sub-network and the accounting node sub-network), it is not authorized to query any uplink transaction information, it is rejected before the actor and the victim check against the entitlement data. In this way, the security of querying the uplink transaction information on the blockchain network is further ensured.

And judging whether the identity of the service node is qualified, namely whether the service node is a node registered on the blockchain network, and verifying through signature. The authentication center issues a private key specific to the service node, while storing the service node-specific public key at the authentication center, or to the proxy node, or broadcast to each billing node in the billing node subnetwork. In this way, the service node, because it has a private key specific to the service node, can generate a signature for the query request with the private key specific to the service node. The signing method includes that a preset digest algorithm is used for solving a digest of the query request, and then the digest is encrypted by a private key specific to the service node. After the accounting node or proxy node obtains the signature, the signature is verified.

In one embodiment, step 312 includes:

acquiring a public key specific to the service node;

decrypting the signature by using the public key specific to the service node to obtain a summary of the query request;

calculating a digest of the query request using a predetermined digest algorithm;

if the calculated digest is consistent with the decrypted digest, the verification is successful.

It can be seen that this verification process corresponds exactly to the process of generating the signature. And decrypting the signature by using the public key specific to the service node to obtain the abstract of the query request. This digest should be consistent with the digest generated during the generation of the signature. Therefore, the digest is calculated again for the query request by using a digest algorithm when the digest is generated, and if the obtained digest is the same as the decrypted digest, the verification is successful. If not, the authentication fails and the query request is rejected.

In one embodiment, the issuing of the private key specific to the service node by the authentication center to the service node may occur immediately after the registration of the service node with the blockchain network. In this embodiment, after the service node sends a registration request to a node responsible for blockchain network registration in the blockchain network, the node responsible for blockchain network registration reads and stores the service node registration information in the registration request, and simultaneously notifies the authentication center to issue a private key specific to the service node.

In one embodiment, the issuing of the private key specific to the service node by the authentication center to the service node may be performed only after the service node sends a query request for transaction information. In this embodiment, after the service node sends a registration request to a node responsible for blockchain network registration in the blockchain network, the node responsible for blockchain network registration reads and stores the service node registration information in the registration request, and notifies the authentication center that the service node is registered, but does not need to issue a private key specific to the service node, but waits until the service node needs to send a query request, and the service node sends a private key request to the authentication center. After the authentication center inquires that the service node is registered, a private key specific to the service node is allocated to the service node.

In one embodiment, the issuing of the public key specific to the service node by the authentication center to the accounting node or the proxy node may be performed immediately after the issuing of the private key specific to the service node by the authentication center, i.e. the authentication center issues the public key specific to the service node to the accounting node or the proxy node immediately after the issuing of the private key specific to the service node. In another embodiment, however, the issuing of the public key specific to the service node by the authentication center to the accounting node or proxy node may occur when the accounting node or proxy node needs to decrypt the signature sent by the service node. After the accounting node or the proxy node receives the query request and the signature of the query request, the public key specific to the service node is first requested from the authentication center, and then the authentication center issues the public key specific to the service node to the accounting node or the proxy node.

As shown in fig. 18A and 18B, the process of signature verification may be performed at the proxy node or at the billing node.

In the embodiment of fig. 18A, the process of signature verification may be performed at the proxy node. The service node creates a query request and signs with a private key specific to the service node. The service node sends the query request and the signature to the proxy node. The proxy node obtains a public key specific to the service node and verifies the signature. If the verification is successful, the proxy node continues to send the query request to the accounting node, the accounting node verifies the acting party or the driven party of the transaction information according to the target service node authority data of the service node, if the acting party or the driven party of the transaction information is one of the target service nodes indicated in the target service node authority data, or if the acting party of the transaction information is the driven party of another transaction information which is one of the target service nodes indicated in the target service node authority data, the transaction information is returned to the service node, otherwise, the hash value of the transaction information is returned.

In the embodiment of fig. 18B, the process of signature verification may be performed at the billing node. The service node creates a query request and signs with a private key specific to the service node. The service node sends the query request and signature to the proxy node, which forwards the query request to the accounting node. The accounting node obtains a public key specific to the service node and verifies the signature. If the verification is successful, the accounting node verifies the mobile party or the passive party of the transaction information according to the target service node authority data of the service node, if the mobile party or the passive party of the transaction information is one of the target service nodes indicated in the target service node authority data, or if the mobile party of the transaction information is the passive party of another transaction information which is one of the target service nodes indicated in the target service node authority data, the transaction information is returned to the service node, otherwise, the hash value of the transaction information is returned.

As shown in fig. 8, in one embodiment, prior to step 310, the method further comprises:

step 305, generating an intelligent contract between the service node and the blockchain operator;

step 306, synchronizing the generated intelligent contracts to each accounting node in the accounting node sub-network for storage.

In this embodiment, step 320 includes:

step 3201, obtaining the target service node authority data corresponding to the service node from the intelligent contracts of the service node and the blockchain operator stored in the accounting node.

In this embodiment, each business node's smart contracts with the blockchain operator are stored in accounting nodes in the accounting node subnetwork. The benefit of this embodiment is that the processing speed of returning transaction information or hash values to the service node is greatly improved, since the intelligent contracts are stored locally at each accounting node.

The intelligent contract is a contract which stores authority data (including target service node authority data) of the service node in inquiring transaction information, and is prepared in advance by the service node and a blockchain operator.

The target service node authority data is data indicating which target service nodes the service node has authority to inquire about transaction information, and indicates: the actor or the victim of the transaction information must carry at least one of which target service nodes that only allow the inquiry; alternatively, the actor of the transaction information is the victim of the further transaction information, which must carry at least one of the target service nodes which only allow the inquiry. For example, company a has two branches A1 and A2, and the target service node authority data corresponding to the service node a may indicate that the target service node that the service node a can query includes A, A, A2. Once the party or the party to be moved of the transaction information contains at least one of A, A1 and A2, or the party to be moved of the transaction information is the party to be moved of the other transaction information, and the party to be moved of the other transaction information contains at least one of A, A and A2, the service node A has the right to inquire the transaction information and can return the transaction information to the service node A, otherwise, only the hash value of the transaction information can be returned.

In one embodiment, as shown in FIG. 10, step 305 includes:

step 3051, issuing a contract template, wherein the contract template contains a contract function;

step 3052, receiving the target service node authority data of the service node set by using the contract function;

step 3053, integrating the target service node authority data into the contract template to form an intelligent contract between the service node and the blockchain operator.

The contract template is a contract style that applies to all business nodes and intelligent contracts of blockchain operators. Each smart contract can apply the style except that specific rights data is different. It is a format segment in the smart contract after removing rights data that varies with different service nodes. The contract function is a function set in the contract, and the user can set the authority data of the target service node by calling the function. Issuing the contract template may include issuing the contract template to the billing node or may include issuing the contract template to all billing nodes in the billing node subnetwork. In the former case, an administrator operating the billing node may determine rights data for the service node and enter the billing node after auditing specific conditions of the service node. In the latter case, an administrator of any one of the accounting nodes may determine rights data for the service node and enter the accounting node after auditing the service node's specific conditions.

The specific conditions of the checked service node comprise the service node of the subordinate unit or the jurisdiction unit of the unit to which the service node belongs. Each service node is a terminal in one unit. The unit to which the service node belongs is the unit to which the terminal belongs. For example, a computer of an invoice issuing company serves as a service node, and the unit is the invoice issuing company. The unit to which the service node belongs may be its branch. In addition, the entity to which the service node belongs may be a functional department, and its jurisdiction unit is all the entities that the functional department jurisdictions. For example, the jurisdictional of the XX municipality tax office may be all tax units of the XX municipality. The administrator may determine the service node and a service node of a unit subordinate to the unit to which the service node belongs or a jurisdiction unit as a target service node indicated in the target service node authority data. For example, company a has two branch offices A1, A2, and A, A, A2 can be determined as the target service node indicated in the target service node authority data, i.e., when one of A, A, A2 appears in the transaction information actor or the victim, or when the actor of the transaction information is the victim of another transaction information, and the victim of the other transaction information is one of A, A1, A2, company a is considered to have the query authority for the transaction information.

After determining the authority data, the manager sets the authority data of the service node by using the contract function at the accounting node, so that the accounting node receives the authority data of the target service node of the service node set by using the contract function, and integrates the authority data of the target service node into the contract template to form an intelligent contract of the service node and a blockchain operator.

The embodiment has the advantages that the contract template provides a contract function, so that an administrator flexibly sets the authority data of the target service node according to the condition of the service node, and the flexibility of setting the authority data of the target service node is improved.

In one embodiment, as shown in FIG. 11, step 305 includes:

step 3054, receiving an intelligent contract generation request from a service node, wherein the intelligent contract generation request indicates a service node of a subordinate unit or a jurisdiction unit of a unit to which the service node belongs;

step 3055, determining the authority data of the target service node according to the service node of the subordinate unit or the jurisdiction unit of the unit to which the service node belongs;

step 3056, integrating the authority data into the contract template to form an intelligent contract between the service node and the blockchain operator.

In this embodiment, when the service node is to generate an intelligent contract, an intelligent contract generation request is sent, where the intelligent contract generation request indicates a service node of a subordinate unit or a jurisdiction unit of the unit to which the service node belongs. After receiving the intelligent contract generation request, the billing node automatically determines the target service node authority data according to the service node of the subordinate unit or the jurisdiction unit of the unit to which the service node belongs, and integrates the automatically determined target service node authority data into the contract template.

An advantage of this embodiment is that automation of smart contract generation is achieved.

The method for automatically determining the rights data is as follows.

In one embodiment, step 3055 includes: and determining the service node and the service node of the subordinate unit or the jurisdiction unit of the unit to which the service node belongs as the target service node indicated in the target service node permission data. For example, company a has two branches A1, A2, and A, A, A2 can be determined as the target service node indicated in the target service node authority data.

This embodiment is similar to the method in which the administrator determines the target service node authority data from the service node of the unit subordinate unit or jurisdiction unit to which the service node belongs, as described above, except that the machine directly determines the service node of the unit subordinate unit or jurisdiction unit to which the service node belongs in the received intelligent contract generation request, and the service node itself, as the target service node authority data, thereby realizing automation of determination.

In another embodiment, the intelligent contract is not implemented for storage in each accounting node of the accounting node subnetwork, but rather is a record of the uplink. In this way, each billing node can be able to perform a chaining lookup when it needs to obtain rights data from the smart contract. The advantage of this embodiment is that the occupation of storage space inside the node is saved compared to maintaining a database inside each billing node storing the intelligent contracts of each service node.

As shown in fig. 9, in this embodiment, prior to step 310, the method includes:

step 307, adding the generated intelligent contract into the intelligent contract block corresponding to the service node, and recording the intelligent contract block on the blockchain.

Accordingly, step 320 includes:

step 3202, obtaining intelligent contracts of the service node and a blockchain operator from intelligent contract blocks corresponding to the service node on the blockchain;

step 3203, obtaining the target service node authority data of the service node from the intelligent contract.

Step 305 of fig. 9 is the same as step 305 of fig. 8, and thus is not repeated.

In one embodiment, step 307 comprises:

Storing the generated intelligent contract and the service node identifier in a zone block of the intelligent contract block correspondingly;

applying abstract operation and signature operation to the generated block body to obtain an abstract and a signature;

adding the digest, signature and digest of the previous block on the blockchain to the block header of the intelligent contract block;

the intelligent contract block is recorded on the blockchain after being commonly recognized among all accounting nodes of the accounting node sub-network.

The service node identification is used to facilitate the retrieval of the intelligent contracts corresponding to the service nodes in step 3202.

The roles of the digest and signature, and the digest of the previous block on the blockchain, are as described above in connection with fig. 2A-2C, fig. 3A-3G, fig. 4A-4G, fig. 5A-5G, and are therefore not repeated.

Regarding the intelligent contract block, the intelligent contract block performs consensus among all the accounting nodes of the accounting node sub-network, and a plurality of consensus algorithms exist at present, so that the description is omitted.

Accordingly, step 3202 may include:

searching the identification of the service node from the area block of the intelligent contract block recorded on the block chain;

and acquiring the intelligent contract corresponding to the identifier in the block body as the intelligent contract of the service node and the block chain operator.

In one embodiment, a specific identification may be added on the block header of the smart contract block, by means of which the smart contract block may be located from all data blocks on the blockchain. The embodiment has the advantage that the efficiency of searching for intelligent contracts of service nodes is greatly improved compared with the way that identifiers of service nodes are searched one by one in all data blocks.

As described above, a method of querying transaction information in a data block in a blockchain network according to one embodiment of the present disclosure is performed by one of the billing nodes in the billing node subnetwork. The process of selecting the accounting node is described in detail below.

In one embodiment, as shown in fig. 12, the billing node performing the method is selected from the billing node subnetwork in the following manner. In one embodiment, a query request of a service node is sent to a proxy node, and the proxy node selects an accounting node according to the following steps:

step 410, obtaining a processing load of each accounting node in the accounting node sub-network;

step 420, determining a distance between each accounting node in the accounting node sub-network and a service node sending the query request;

step 430, determining an accounting node for performing the method based on the processing load and the distance.

The processing load is a parameter representing the burden of the task being processed by the billing node. In one embodiment, the processing load may be measured in terms of the number of tasks that the billing node has not processed. The tasks here include transaction information uplink tasks and query tasks. These number of outstanding tasks can represent the processing load of the accounting node.

In one embodiment, step 410 includes:

acquiring and storing the processing load sent by each accounting node periodically;

and taking the processing load of the accounting node stored by the accounting node last time as the acquired processing load of the accounting node.

That is, in this embodiment, the processing load may be sent to the proxy node periodically (e.g., every 5 seconds) by each billing node. The proxy node maintains a processing load table that records the received processing load periodically broadcast by each billing node. In this way, the proxy node may take the processing load of the accounting node that was last stored by the accounting node as the acquired processing load of the accounting node.

In this embodiment, the proxy node passively receives the processing load periodically sent by the accounting node. In another embodiment, the proxy node actively queries the processing load of the billing node. In this embodiment, step 410 includes:

Transmitting a processing load query request to each billing node in the billing node subnetwork;

and receiving the processing load of each billing node sent by the billing node.

In one embodiment, in step 420, determining the distance of each billing node in the billing node subnetwork to the service node sending the query request includes:

sending a positioning information request to each accounting node in the accounting node sub-network and a service node sending the query request;

receiving from each billing node and the service node sending the query request, location information of each billing node and the service node sending the query request;

and determining the distance between each billing node and the service node sending the query request by using the billing nodes and the positioning information of the service node sending the query request.

Each of the service node and the accounting node may have a positioning system such as GPS, so that they can obtain their own positioning information from their own GPS positioning system. When receiving a positioning information request sent by the proxy node, the proxy node sends the self positioning information obtained from the GPS system. After the proxy node obtains the positioning information of each accounting node and the service node sending the query request, the distance from each accounting node to the service node sending the query request can be determined by utilizing the positioning information.

In the above embodiment, the method of actively requesting by the proxy node is adopted for obtaining the positioning information, and as with the processing load, the positioning information may also be sent to the proxy node periodically by each accounting node and the service node sending the query request, so that details are not repeated.

An advantage of this embodiment is that not only the processing load of each accounting node but also the distance of each accounting node from the service node that sent the query request is taken into account when determining the accounting node that performs the method. Although it is possible that the processing load of a certain accounting node is minimal, the accounting node may be very far away from the service node that sent the query request, and selecting it as the accounting node that performs the method increases the network transmission load and also reduces the query processing speed. This embodiment takes into account both distance and processing load, and not only approximately equalizes the processing load of each billing node, but also does not place too much transmission burden on the network, as compared to a scenario where the billing node executing the query is determined solely based on distance or processing load.

In one embodiment, as shown in fig. 13, step 430 may include:

Step 4301, determining a first score for each accounting node based on the processing load of each accounting node in the accounting node subnetwork;

step 4302, determining a second score for each accounting node based on the distance of each accounting node in the accounting node subnetwork;

step 4303, determining an accounting node performing the method based on the first score and the second score for each accounting node.

In step 4301, determining a first score for each accounting node based on the processing load of each accounting node in the accounting node subnetwork may take the form of looking up a pre-set processing load to first score correspondence table. The corresponding relation table of the processing load and the first score is preset, wherein the larger the processing load is, the lower the first score is. For example:

processing load (number of unprocessed tasks)	First score
		0-1	5
2-4	4
		5-9	3
10-19	2
		20-49	1
50 or more	0

TABLE 1 correspondence table of processing load and first score

In step 4302, determining a second score for each accounting node based on the distance for each accounting node in the accounting node subnetwork may take the form of looking up a table of pre-set distance versus second score. The correspondence table of the distance and the second score is preset, wherein the larger the distance is, the lower the second score is. For example:

Distance of	Second fraction
		Within 50 meters	5
50-200 m	4
		200-1000 m	3
1000-5000 meters	2
		5000-20000 m	1
20000 m or more	0

TABLE 2 correspondence table of distance and second score

With the first score and the second score of each billing node, the billing node performing the method may be determined based on the first score and the second score. An advantage of this embodiment is that the influence of the two factors of the processing load of each accounting node in the accounting node sub-network and the distance of each accounting node in the accounting node sub-network on the selection of an accounting node performing the method is scored, improving the accuracy of the selection of an accounting node performing the method.

In one embodiment, as shown in FIG. 14, step 4303 comprises:

step 43031, determining a weighted sum of the first score and the second score for each billing node;

step 43032, determining an accounting node performing the method based on the weighted sum.

In step 43031, the weights assigned to the first score and the second score may be empirically preset when determining the weighted sum.

In step 43032, the accounting node with the largest weighted sum may be determined as the accounting node that receives the transaction information to be uplink, or one of the accounting nodes with the weighted sum greater than the predetermined weighted sum threshold may be optionally used as the accounting node that receives the transaction information to be uplink. It is considered that as long as the weighted sum is larger than the predetermined weighted sum threshold, which is not too heavy and not too far from the service node sending the transaction information to be uplinked, it is the same which is chosen as the accounting node performing the method. In this latter way, load balancing is also facilitated, preventing the selection of the accounting node with the greatest sum of weights at the same time, which in turn causes an apparent overload condition of the accounting node with the greatest sum of weights.

An advantage of this embodiment is that determining the accounting node receiving the transaction information to be uplinked based on a weighted sum of the first score and the second score of each accounting node, substantially takes into account the difference in the contribution of the first score and the second score to determining the accounting node performing the method, improving the rationality of determining the accounting node performing the method compared to a scheme in which the accounting node receiving the transaction information to be uplinked is determined based on a sum or average of the first score and the second score.

The above-described embodiments of determining the accounting node that receives the transaction information to be uplinked are mainly directed to the case of fig. 1A-1B where there is no branch accounting node subnetwork at the accounting node subnetwork side. But in the embodiment shown in fig. 1C in which the accounting node subnetwork end is divided into branch accounting node subnetworks, the other case is the case.

In this embodiment, the query request carries the transaction information type, such as a supply chain financial transaction, or an electronic invoice transaction, or a legal digital currency transaction. The accounting nodes in the accounting node sub-network are pre-classified according to the type of transaction information processed, and each type of accounting node is divided into a corresponding branch accounting node sub-network, for example, a supply chain financial transaction branch accounting node sub-network, or an electronic invoice transaction branch accounting node sub-network, or a legal digital currency transaction branch accounting node sub-network, each branch accounting node sub-network is specially used for processing the transaction type corresponding to one transaction type. The proxy node is thus to send the query request to one of the accounting nodes in the corresponding type of branch accounting node sub-network, depending on the type of transaction information carried in the query request. To achieve this, a table of the correspondence between the billing node identification and the transaction information type is stored in the proxy node, and the billing node identification and the processed transaction information type correspondence are recorded in the table of the correspondence between the billing node identification and the transaction information type.

In this embodiment, as shown in fig. 15, the accounting node performing the method is selected from the accounting node subnetworks as follows:

step 510, obtaining the transaction information type in the query request;

step 520, searching for an accounting node identifier corresponding to the transaction information type in the query request from the corresponding relation table of the accounting node identifier and the transaction information type;

step 530, determining the accounting node receiving the transaction information to be uplink from the accounting nodes identified by the found accounting nodes.

The benefit of this embodiment is that for an architecture in which the accounting node subnetwork side shown in fig. 1C is divided into branched accounting node subnetworks, a way is proposed to adapt the architecture to a reasonable choice of accounting nodes performing the method.

In one embodiment, the transaction information type field in the query request contains the transaction information type. In step 510, the transaction information type may be read directly from the transaction information type field.

Because the proxy node is provided with a table of correspondence between billing node identifiers and transaction information types, in one embodiment, in step 520, the billing node identifiers corresponding to the transaction information types in the query request may be found from the table.

As shown in fig. 16, in one embodiment, step 530 includes:

step 5301, determining the processing load of each billing node identified by the found billing node;

step 5302, determining the distance from the accounting node identified by each found accounting node to the service node sending the query request;

step 5303, determining an accounting node performing said method based on said processing load and said distance.

The implementation of steps 5301-5303 is similar to the implementation of steps 410-430 except that the scope of the accounting nodes determining the processing load and the distance to the service node sending the query request in the embodiment of fig. 16 is limited to the accounting nodes identified by the accounting node corresponding to the transaction information type in the query request found in step 520, not all accounting nodes in the accounting node subnetwork, and is not repeated.

There is also provided, in accordance with an embodiment of the present disclosure, as shown in fig. 19, an accounting node for querying transaction information in a data block in a blockchain network. The blockchain network includes a billing node subnetwork and a service node subnetwork. The accounting node subnetwork includes accounting nodes that record data blocks onto the blockchain, and the service node subnetwork includes service nodes that verify data blocks recorded by the accounting nodes onto the blockchain. The accounting node comprises:

A query request receiving unit 610, configured to receive a query request of a service node for transaction information in a data block;

a target service node authority data obtaining unit 620, configured to obtain target service node authority data corresponding to the service node, where the service node is authorized to query transaction information of a target service node indicated in the target service node authority data;

a first transaction information return unit 630, configured to return the transaction information to the service node if the actor or the follower of the transaction information is one of the target service nodes indicated in the target service node authority data.

Optionally, the billing node further comprises:

a second transaction information return unit (not shown) for returning the transaction information to the service node if the party acting on the transaction information is the party acting on the other transaction information, and the party acting on the other transaction information is one of the target service nodes indicated in the target service node authority data.

Optionally, the billing node further comprises:

a hash value return unit (not shown) for returning the hash value of the transaction information to the service node if the actor or the follower of the transaction information is neither one of the target service nodes indicated in the target service node authority data nor the follower of the further transaction information, which is one of the target service nodes indicated in the target service node authority data.

Optionally, the query request receiving unit 610 is configured to:

receiving a query request of a service node for transaction information in a data block and a signature generated on the query request by a private key specific to the service node;

the apparatus further comprises:

and a signature verification unit (not shown) for verifying the signature by using a public key specific to the service node, wherein the target service node authority data corresponding to the service node is obtained only if verification is successful.

Optionally, the signature verification unit is configured to:

acquiring a public key specific to the service node;

Optionally, the billing node further comprises:

the intelligent contract generating unit is used for generating intelligent contracts between the service node and the blockchain operator;

and the synchronization unit is used for synchronizing the generated intelligent contracts to all accounting nodes in the accounting node sub-network for storage.

The target service node authority data acquisition unit is further configured to:

And acquiring the target service node authority data corresponding to the service node from the intelligent contracts of the service node and the blockchain operator stored in the accounting node.

Optionally, the apparatus further comprises:

and the uplink unit is used for adding the generated intelligent contract into the intelligent contract block corresponding to the service node and recording the intelligent contract block on the block chain.

acquiring intelligent contracts of the service node and a blockchain operator from an intelligent contract block corresponding to the service node on a blockchain;

and acquiring the target service node authority data corresponding to the service node from the intelligent contract.

Optionally, the smart contract generation unit is further configured to:

issuing a contract template, wherein the contract template contains a contract function;

receiving target service node authority data of the service node set by utilizing the contract function;

and integrating the authority data of the target service node into the contract template to form an intelligent contract between the service node and a blockchain operator.

Optionally, the smart contract generation unit is further configured to:

receiving an intelligent contract generation request from a service node, wherein the intelligent contract generation request indicates the service node of a subordinate unit or a jurisdiction unit of a unit to which the service node belongs;

determining authority data of a target service node according to the service node of a subordinate unit or a jurisdiction unit of the unit to which the service node belongs;

and integrating the authority data into the contract template to form an intelligent contract between the service node and the blockchain operator.

Optionally, the determining the authority data of the target service node according to the service node of the subordinate unit or the jurisdiction unit of the unit to which the service node belongs includes:

and determining the service node and the service node of the subordinate unit or the jurisdiction unit of the unit to which the service node belongs as the target service node indicated in the target service node permission data.

Optionally, the accounting node performing the method is selected from an accounting node subnetwork in the following way:

acquiring the processing load of each accounting node in the accounting node sub-network;

determining the distance between each accounting node in the accounting node sub-network and the service node sending the query request;

Based on the processing load and the distance, an accounting node is determined that performs the method.

Optionally, the determining, based on the processing load and the distance, an accounting node performing the method includes:

determining a first score for each accounting node based on the processing load of each accounting node in the accounting node subnetwork;

determining a second score for each accounting node based on the distance of each accounting node in the accounting node sub-network;

an accounting node performing the method is determined based on the first score and the second score of each accounting node.

The method of querying transaction information in a data chunk in a blockchain network according to embodiments of the present disclosure may be implemented by the accounting node 21 of fig. 20 querying transaction information in a data chunk in a blockchain network. The following describes an accounting node 21 querying transaction information in data blocks in a blockchain network in accordance with embodiments of the present disclosure with reference to fig. 20. The accounting node 21 shown in fig. 20 that queries the blockchain network for transaction information in the data blocks is merely an example and should not be taken as limiting the functionality and scope of use of embodiments of the present disclosure.

As shown in fig. 20, the accounting node 21, which queries the blockchain network for transaction information in the data blocks, is in the form of a general purpose computing device. The components of the accounting node 21 that query the blockchain network for transaction information in the data blocks may include, but are not limited to: the at least one processing unit 810, the at least one memory unit 820, and a bus 830 connecting the various system components, including the memory unit 820 and the processing unit 810.

Wherein the storage unit stores program code that is executable by the processing unit 810 such that the processing unit 810 performs steps according to various exemplary embodiments of the present invention described in the description of the exemplary methods described above in this specification. For example, the processing unit 810 may perform the various steps as shown in fig. 6.

The storage unit 820 may include readable media in the form of volatile storage units, such as Random Access Memory (RAM) 8201 and/or cache memory 8202, and may further include Read Only Memory (ROM) 8203.

Storage unit 820 may also include a program/utility 8204 having a set (at least one) of program modules 8205, such program modules 8205 including, but not limited to: an operating system, one or more application programs, other program modules, and program data, each or some combination of which may include an implementation of a network environment.

Bus 830 may be one or more of several types of bus structures including a memory unit bus or memory unit controller, a peripheral bus, an accelerated graphics port, a processing unit, or a local bus using any of a variety of bus architectures.

The accounting node 21 querying the blockchain network for transaction information in the data block may also be in communication with one or more external devices 700 (e.g., keyboard, pointing device, bluetooth device, etc.), one or more devices that enable a user to interact with the accounting node 21 querying the blockchain network for transaction information in the data block, and/or any device (e.g., router, modem, etc.) that enables the accounting node 21 querying the blockchain network for transaction information in the data block to communicate with one or more other computing devices. Such communication may occur through an input/output (I/O) interface 650. Also, the accounting node 21 that queries the blockchain network for transaction information in the data blocks may also communicate with one or more networks (e.g., a Local Area Network (LAN), a Wide Area Network (WAN), and/or a public network, such as the internet) through network adapter 860. As shown, network adapter 860 communicates with other modules of accounting node 21 that query the blockchain network for transaction information in data blocks via bus 830. It should be appreciated that although not shown, other hardware and/or software modules may be used in connection with accounting node 21 querying transaction information in data blocks in a blockchain network, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, data backup storage systems, and the like.

From the above description of embodiments, those skilled in the art will readily appreciate that the example embodiments described herein may be implemented in software, or may be implemented in software in combination with the necessary hardware. Thus, the technical solution according to the embodiments of the present disclosure may be embodied in the form of a software product, which may be stored in a non-volatile storage medium (may be a CD-ROM, a U-disk, a mobile hard disk, etc.) or on a network, including several instructions to cause a computing device (may be a personal computer, a server, a terminal device, or a network device, etc.) to perform the method according to the embodiments of the present disclosure.

In an exemplary embodiment of the present disclosure, there is also provided a computer program medium having stored thereon computer readable instructions, which when executed by a processor of a computer, cause the computer to perform the method described in the method embodiment section above.

According to an embodiment of the present disclosure, there is also provided a program product for implementing the method in the above method embodiments, which may employ a portable compact disc read only memory (CD-ROM) and comprise program code, and may be run on a terminal device, such as a personal computer. However, the program product of the present invention is not limited thereto, and in this document, a readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.

The program product may employ any combination of one or more readable media. The readable medium may be a readable signal medium or a readable storage medium. The readable storage medium can be, for example, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or a combination of any of the foregoing. More specific examples (a non-exhaustive list) of the readable storage medium would include the following: an electrical connection having one or more wires, a portable disk, a hard disk, random Access Memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

The computer readable signal medium may include a data signal propagated in baseband or as part of a carrier wave with readable program code embodied therein. Such a propagated data signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination of the foregoing. A readable signal medium may also be any readable medium that is not a readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.

Program code embodied on a readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

Program code for carrying out operations of the present invention may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, C++ or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code may execute entirely on the user's computing device, partly on the user's device, as a stand-alone software package, partly on the user's computing device, partly on a remote computing device, or entirely on the remote computing device or server. In the case of remote computing devices, the remote computing device may be connected to the user computing device through any kind of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or may be connected to an external computing device (e.g., connected via the Internet using an Internet service provider).

It should be noted that although in the above detailed description several modules or units of a device for action execution are mentioned, such a division is not mandatory. Indeed, the features and functionality of two or more modules or units described above may be embodied in one module or unit in accordance with embodiments of the present disclosure. Conversely, the features and functions of one module or unit described above may be further divided into a plurality of modules or units to be embodied.

Furthermore, although the steps of the methods in the present disclosure are depicted in a particular order in the drawings, this does not require or imply that the steps must be performed in that particular order or that all illustrated steps be performed in order to achieve desirable results. Additionally or alternatively, certain steps may be omitted, multiple steps combined into one step to perform, and/or one step decomposed into multiple steps to perform, etc.

From the above description of embodiments, those skilled in the art will readily appreciate that the example embodiments described herein may be implemented in software, or may be implemented in software in combination with the necessary hardware. Thus, the technical solution according to the embodiments of the present disclosure may be embodied in the form of a software product, which may be stored in a non-volatile storage medium (may be a CD-ROM, a U-disk, a mobile hard disk, etc.) or on a network, including several instructions to cause a computing device (may be a personal computer, a server, a mobile terminal, or a network device, etc.) to perform the method according to the embodiments of the present disclosure.

Other embodiments of the disclosure will be apparent to those skilled in the art from consideration of the specification and practice of the disclosure disclosed herein. This application is intended to cover any adaptations, uses, or adaptations of the disclosure following, in general, the principles of the disclosure and including such departures from the present disclosure as come within known or customary practice within the art to which the disclosure pertains. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the disclosure being indicated by the following claims.

Claims

1. A method of querying a blockchain network for transaction information in a data block, the blockchain network comprising a billing node sub-network and a service node sub-network, the billing node sub-network comprising billing nodes that record data blocks onto a blockchain, the billing nodes in the billing node sub-network being consensus nodes, the service node sub-network comprising service nodes that verify data blocks recorded by a billing node onto a blockchain, the method performed by one of the billing node sub-networks, the method comprising:

generating intelligent contracts of the service node and the blockchain operator;

synchronizing the generated intelligent contracts to each accounting node in the accounting node sub-network for storage;

receiving a query request of a service node for transaction information in a data block;

obtaining the target service node authority data corresponding to the service node comprises the following steps: acquiring target service node authority data corresponding to the service node from the intelligent contracts of the service node and a blockchain operator stored by the accounting node; the service node is authorized to inquire the transaction information of the target service node indicated in the authority data of the target service node;

If the actor or the victim of the transaction information is one of the target service nodes indicated in the target service node entitlement data, or if the actor of the transaction information is the victim of another transaction information, and the passive party of the other transaction information is one of the target service nodes indicated in the target service node authority data, and the transaction information is returned to the service node;

if the actor or the follower of the transaction information is neither one of the target service nodes indicated in the target service node authority data nor the follower of the other transaction information, and the follower of the other transaction information is one of the target service nodes indicated in the target service node authority data, returning a hash value of the transaction information to the service node, wherein the hash value is used for verifying whether the transaction information in the data block is tampered or not by the service node;

wherein the accounting node performing the method is selected from an accounting node subnetwork in the following manner: acquiring the processing load of each accounting node in the accounting node sub-network; determining the distance between each accounting node in the accounting node sub-network and the service node sending the query request; based on the processing load and the distance, an accounting node is determined that performs the method.

2. The method of claim 1, wherein receiving the query request of the service node for transaction information in the data block comprises:

before obtaining the target service node authority data corresponding to the service node, the method further comprises the following steps:

and verifying the signature by using a public key specific to the service node, wherein the target service node authority data corresponding to the service node is acquired only if verification is successful.

3. The method according to claim 2, wherein said verifying said signature with a public key specific to said service node comprises:

obtaining a public key specific to the service node;

calculating a digest of the query request by using a predetermined digest algorithm;

4. The method of claim 1, wherein prior to receiving the query request by the service node for transaction information in the data block, the method further comprises:

adding the generated intelligent contract into an intelligent contract block corresponding to the service node, recording on a block chain,

the obtaining the target service node authority data corresponding to the service node includes:

5. The method of claim 1 or 4, wherein generating the intelligent contract of the service node with the blockchain operator comprises:

and integrating the target service node authority data into the contract template to form an intelligent contract between the service node and a blockchain operator.

6. The method of claim 1 or 4, wherein generating the intelligent contract of the service node with the blockchain operator comprises:

and integrating the authority data into the contract template to form an intelligent contract between the service node and a blockchain operator.

7. The method of claim 6, wherein the determining the target service node authority data according to the service node of the subordinate unit or the jurisdictional unit of the unit to which the service node belongs comprises:

8. The method of claim 1, wherein the determining an accounting node to perform the method based on the processing load and the distance comprises:

9. A billing node for querying a blockchain network for transaction information in data blocks, the blockchain network comprising a billing node sub-network and a service node sub-network, the billing node sub-network comprising billing nodes that record data blocks onto a blockchain, the billing nodes in the billing node sub-network being consensus nodes, the service node sub-network comprising service nodes that verify data blocks recorded onto a blockchain by a billing node, the billing node comprising:

a query request receiving unit, configured to receive a query request of a service node for transaction information in a data block;

the target service node authority data obtaining unit is configured to obtain target service node authority data corresponding to the service node, and includes: acquiring target service node authority data corresponding to the service node from the intelligent contracts of the service node and a blockchain operator stored by the accounting node; the service node is authorized to inquire the transaction information of the target service node indicated in the authority data of the target service node;

a first transaction information return unit configured to return the transaction information to the service node if an actor or a follower of the transaction information is one of the target service nodes indicated in the target service node authority data, or if the actor of the transaction information is a follower of another transaction information, and the follower of the other transaction information is one of the target service nodes indicated in the target service node authority data;

A hash value returning unit configured to return, to the service node, a hash value of the transaction information if the actor or the follower of the transaction information is neither one of the target service nodes indicated in the target service node authority data nor a follower of another transaction information, which is one of the target service nodes indicated in the target service node authority data, the hash value being used for the service node to verify whether the transaction information in the data block is tampered;

the synchronization unit is used for synchronizing the generated intelligent contracts to each accounting node in the accounting node sub-network for storage;

10. A billing node comprising:

a memory storing computer readable instructions;

a processor reading computer readable instructions stored in a memory to perform the method of any one of claims 1-8.

11. A computer program medium having stored thereon computer readable instructions which, when executed by a processor of a computer, cause the computer to perform the method of any of claims 1-8.