CN110851496B

CN110851496B - Method, apparatus, accounting node and medium for querying transaction information in blockchain network

Info

Publication number: CN110851496B
Application number: CN201911031824.4A
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: 2023-03-14
Anticipated expiration: 2038-12-07
Also published as: CN109447811B; CN109447811A; CN110851496A

Abstract

The present disclosure provides a method, apparatus, accounting node and medium for querying transaction information in a blockchain network. The blockchain network includes a billing node sub-network and a service node sub-network. The method is performed by a billing node in a billing node sub-network, the method comprising: generating an intelligent contract between the service node and a block chain operator; synchronizing the generated intelligent contract to each accounting node in an accounting node sub-network for storage; receiving a query request of a service node for transaction information in a data block; acquiring target service node authority data corresponding to a service node from an intelligent contract of the service node and a block chain operator stored in an accounting node; and if the actor or the follower of the transaction information is one of the target service nodes indicated in the authority data of the target service node, returning the transaction information to the service node. The method and the system enable the user who inquires 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, apparatus, accounting node and medium for querying transaction information in blockchain network

The application is a divisional application with application number 201811495810.3 and invented name of 'method for inquiring transaction information in block chain network, accounting node and medium' which is submitted in 2018, 12 months, and 07 days.

Technical Field

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

Background

In a conventional blockchain network, the uplink transaction data is redundantly stored in full by each accounting node in the blockchain network. Each accounting node can view all transaction information on the blockchain. If a certain enterprise desires privacy of its uplink transaction information, it cannot be viewed by other enterprises.

Therefore, a blockchain network with good privacy is desired, so that a user who queries transaction information on a blockchain can only query the transaction information related to the user, thereby preventing the transaction information from being leaked.

Disclosure of Invention

One purpose of the present disclosure is to enable a user who queries transaction information on a blockchain to only query transaction information related to the user, thereby preventing the transaction information from leaking.

According to an aspect of the disclosed embodiments, a method for querying transaction information in data blocks in a blockchain network is disclosed, the blockchain network comprising a billing node sub-network and a service node sub-network, the billing node sub-network comprising a billing node that records the data blocks onto the blockchain, the service node sub-network comprising a service node that verifies the data blocks recorded onto the blockchain by the billing node, the method being performed by one billing node in the billing node sub-network, the method comprising: generating an intelligent contract between the service node and a block chain operator; synchronizing the generated intelligent contract to each accounting node in an accounting node sub-network for storage; 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 from an intelligent contract of the service node and a block chain operator, which is stored in the accounting node; and 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, returning the transaction information to the service node.

According to an aspect of the disclosed embodiments, a method for querying transaction information in data blocks in a blockchain network is disclosed, the blockchain network comprising a billing node sub-network and a service node sub-network, the billing node sub-network comprising a billing node that records the data blocks onto the blockchain, the service node sub-network comprising a service node that verifies the data blocks recorded onto the blockchain by the billing node, the method being performed by one billing node in the billing node sub-network, the method comprising: generating an intelligent contract of the service node and a block chain operator; adding the generated intelligent contract into an intelligent contract block corresponding to the service node, and recording the intelligent contract block on a block chain; receiving a query request of a service node for transaction information in a data block; acquiring an intelligent contract between the service node and a block chain operator from an intelligent contract block corresponding to the service node on the block chain; acquiring target service node authority data corresponding to the service node from the intelligent contract; and 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, returning the transaction information to the service node.

According to an aspect of the disclosed embodiments, an apparatus for querying transaction information in data blocks in a blockchain network is disclosed, the blockchain network comprising an accounting node sub-network and a service node sub-network, the accounting node sub-network comprising an accounting node that records the data blocks onto the blockchain, the service node sub-network comprising a service node that verifies the data blocks recorded by the accounting node onto the blockchain, the apparatus comprising: the first generation unit is used for generating an intelligent contract between the service node and the block chain operator; the synchronization unit is used for synchronizing the generated intelligent contract to each accounting node in the accounting node sub-network for storage; the query request receiving unit is used for receiving a query request of the business node for the transaction information in the data block; a target service node permission data obtaining unit, configured to obtain target service node permission data corresponding to the service node from an intelligent contract between the service node and a block chain operator, where the intelligent contract is stored in the accounting node; and the transaction information returning unit is used for returning the transaction information to the service node if the actor or the actor of the transaction information is one of the target service nodes indicated in the authority data of the target service node.

According to an aspect of the disclosed embodiments, an apparatus for querying transaction information in data blocks in a blockchain network is disclosed, the blockchain network comprising an accounting node sub-network and a service node sub-network, the accounting node sub-network comprising an accounting node that records the data blocks onto the blockchain, the service node sub-network comprising a service node that verifies the data blocks recorded by the accounting node onto the blockchain, the apparatus comprising: a second generating unit, configured to generate an intelligent contract between the service node and the block chain operator; the uplink unit is used for adding the generated intelligent contract into an intelligent contract block corresponding to the service node and recording the intelligent contract block on a block chain; the query request receiving unit is used for receiving a query request of the business node for the transaction information in the data block; a target service node permission data obtaining unit, configured to obtain an intelligent contract between the service node and a block chain operator from an intelligent contract block corresponding to the service node in the block chain, and obtain target service node permission data corresponding to the service node from the intelligent contract; and the transaction information returning unit is used for returning the transaction information to the service node if the actor or the actor of the transaction information is one of the target service nodes indicated in the authority data of the target service node.

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

According to an aspect of embodiments of the present disclosure, a computer program medium is disclosed, having computer readable instructions stored thereon, 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 sub-network is separate from the service node sub-network. Accounting nodes in the accounting node subnetwork may agree 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 for not divulging the transaction information. On the basis, the accounting node receives the query request of the service node for the 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 node-related transaction information the service node can query. If the acting party or the driven party of the transaction information is one of the target service nodes indicated in the authority data of the target service node, the transaction information is indicated to be in the authority range of the service node, and the service node has the authority to inquire the transaction information and return the transaction information to the service node. Therefore, the users who inquire the transaction information on the blockchain can only inquire the transaction information related to the users, and the transaction information is prevented from being leaked.

Additional features and advantages of the disclosure will be set forth in the detailed description which follows, or in part will be obvious from the description, or may be learned by 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.

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

Fig. 2A-2C are architecture diagrams illustrating a scenario in which the method for querying transaction information in data blocks in a blockchain network according to an embodiment of the present disclosure is applied to three different application scenarios of supply chain finance, electronic invoice, and legal digital currency.

Fig. 3A-3G illustrate a business node display interface diagram applied in a supply chain financial application scenario for a method of querying transaction information in a data block in a blockchain network according to an embodiment of the present disclosure, which represents a general process of linking transaction information to query transaction information and verifying the content of the data block in the supply chain financial application scenario.

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

Fig. 5A-5G illustrate service node display interface diagrams in a fiat digital currency application scenario for a method of querying transaction information in data blocks in a blockchain network according to one embodiment of the present disclosure, which show the general process of chaining transaction information to query transaction information and verifying the contents of data blocks in the fiat digital currency application scenario.

Fig. 6 shows a flow diagram of a method of querying transaction information in a data chunk in a blockchain network according to one embodiment of the present disclosure.

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

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

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

FIG. 10 shows a detailed flowchart of step 305 in FIG. 10 according to one embodiment of the present disclosure.

FIG. 11 shows another detailed flowchart of step 305 in FIG. 10 according to one embodiment of the present disclosure.

Fig. 12 shows a flowchart of a billing node determining to perform the method of querying for transaction information in data blocks in a blockchain network according to one embodiment of the present disclosure.

FIG. 13 shows a detailed flowchart of step 430 of FIG. 12 according to one embodiment of the present disclosure.

FIG. 14 shows a detailed flowchart of step 4303 in FIG. 13 according to one embodiment of the present disclosure.

Fig. 15 shows a flowchart of a billing node determining to perform the method of querying for transaction information in data blocks in a blockchain network according to one embodiment of the present disclosure.

FIG. 16 shows a detailed flowchart 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 according to a comparison of an actor or actor of transaction information and target service node authority data according to one embodiment of the present disclosure.

Fig. 18A-B illustrate an interaction flow diagram for querying transaction information in a data chunk in a blockchain network, according to two embodiments of the present disclosure.

Fig. 19 shows a block diagram of a billing node querying a blockchain network for transaction information in data blocks according to one embodiment of the present disclosure.

Fig. 20 shows a hardware structure 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. Example embodiments may, however, be embodied in many different 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 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 their repetitive description 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 subject matter of the present disclosure can be practiced without one or more of the specific details, or with other methods, components, steps, and so forth. 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 the form of 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 for use in embodiments of the present disclosure will now be described with reference to fig. 1A-1C.

FIG. 1A illustrates an architecture of a blockchain network to which embodiments of the present disclosure are applied. The blockchain network comprises a sub-network 2 of accounting nodes and a sub-network 1 of service nodes. Accounting node subnetwork 2 includes an accounting node 21 that records data blocks onto a block chain. Service node subnetwork 1 includes service node 11 which validates the data blocks that the accounting node records onto the blockchain. Billing node sub-network 2 and service node sub-network 1 are connected by proxy node 12. The proxy node 12 is a service node of the service node subnetwork 1, but is a more specific one. It is responsible for passing information to the service node 11 that the accounting node 21 wants to pass to the service node 11. The service node 11 is a terminal of a transaction party that generates various transaction information to be linked. They generate transaction information but have no right to record directly onto the blockchain, which must be recorded onto the blockchain by an accounting node 21. The unified accounting by a few accounting nodes 21 is also beneficial to the unified processing and supervision of transactions, and the service node 11 can perform the supervision and witness of the uplink of transaction information through the information sent by the accounting node 21 through the proxy node 12. The method has great significance in certain scenes which need unified supervision but are afraid of collective cheating of supervised nodes and therefore need supervision of people. Billing node subnetwork 2, each billing node 21 generates a data block that is broadcast to other billing nodes 21 for consensus and then uplink. In fig. 1A, a service node subnetwork 1 adopts a P2P network mode. A P2P network is a distributed application architecture that distributes tasks and workloads among peers (peers), and is a form of networking or networking formed by Peer-to-Peer computing models at the application layer, i.e., a "Peer-to-Peer" or "Peer-to-Peer" network. It can be defined as: participants of the network share a portion of the hardware resources (processing power, storage power, network connectivity, printers, etc.) they own, which provide services and content over the network and which can be accessed directly by other peer nodes without going through intermediate entities. Participants in this network are both providers and acquirers of resources, services and content. Therefore, in the service node subnetwork 1, the proxy node 12 receives the message transmitted from the accounting node 21 and propagates the message to the surrounding service nodes 11. The surrounding service nodes 11 receive the message and then transmit the message to the surrounding service nodes 11, and the message is propagated layer by layer, so that the message is propagated at each service node 11 of the service node sub-network 1.

Fig. 1B illustrates another block chain network architecture to which embodiments of the present disclosure are applied. This architecture differs from the architecture of fig. 1A in that the service node subnetwork 1 does not adopt the P2P network mode, but adopts the broadcast network mode. The proxy node 12 receives the message passed from the accounting node 21 and broadcasts the message to the other service nodes 11 in the service node sub-network 1. In this way, the propagation of the message at each service node 11 of the service node sub-network 1 is also achieved.

Fig. 1C illustrates another block chain network architecture to which embodiments of the present disclosure are applied. The architecture differs from the architecture of fig. 1A in that its billing node sub-network 2 is divided into a plurality of branch billing node sub-networks. Each branch accounting node sub-network may be responsible for the recording of some type of transaction information. For example, a business may have a supply chain financial transaction and may need to record contract information, credit, etc. generated during supply and marketing to the blockchain, and the business may need to issue invoices and also record invoicing information, invoice reimbursement information, etc. to the blockchain. In this case, in order to facilitate the requirement that the accounting node is supervised by the same department, the accounting node for recording the supply chain financial service transaction and the accounting node for recording the transaction in the invoice circulation process may belong to different departments. For example, the accounting node for recording the supply chain financial service transaction is an accounting terminal set by a bank, and the accounting node for recording the transaction in the invoice circulation process is an accounting terminal set by a national tax bureau. And the supply chain financial business transaction and the transaction in the process of recording the invoice flow can also be finally recorded on different subarea block chains. In this case, the agent node 12 transmits the transaction information to the branch accounting node sub-network corresponding to the transaction type, based on the transaction type carried in the transaction information transmitted from the service node 11.

Fig. 2A shows a scene architecture diagram of the application of the method for querying transaction information in data blocks in a blockchain network in an application scenario of supply chain finance according to an embodiment of the present disclosure.

Supply chain finance is a business that: a manufacturing enterprise produces a device or product, often not necessarily all of the parts or components of the device or product that it own enterprise produces, wherein the production of some parts or components needs to be outsourced to other enterprises for production. Although the manufacturer has made a supply and sale contract with the supplier in advance, the money can be obtained only when the whole equipment or product is produced, and the money for purchasing the parts or components in the process needs to be paid by the manufacturer, so that the capital turnover of the manufacturer is difficult. Therefore, a need has arisen for a manufacturing enterprise to secure a part or component in a bank under a total purchase contract (in which a value and ordering party information) made for the entire device or product, and to transfer a part of the security for the purchase of the part or component from the value in the total purchase contract for the device or product secured by the bank based on the total purchase contract for the entire device or product secured by the bank when the purchase of the part or component is required. Thus, the company that produces the part or component can be assured of producing the part or component, and the bank can guarantee that the part or component will not be paid by the part of the money transferred. At the same time, the manufacturer does not actually take the money out at this time, but waits until the actual payment of the purchasing party of the entire device or product is obtained, and pays the corresponding part to the manufacturer of the part or component.

In the traditional block chain network, because all accounting nodes are set by a bank and the network is closed, enterprises with nodes on supply and marketing chains are nodes related to chain interests of data blocks of supply chain finance, but cannot supervise and witness, and only the accounting network consisting of the accounting nodes of the non-interest party can be completely trusted. For example, a manufacturing enterprise making a general purchase contract with an ordering party for an entire device or product, or making a branch purchase contract with a part or component generating party, all require that these contracts be transmitted to a chain of banking nodes. At this time, each accounting node arranged in the bank can supervise and witness each other, but each node enterprise on the supply chain cannot supervise and witness. In addition, in the conventional blockchain network, any other enterprise node which is not related to the current supply and marketing chain may also query any transaction information linked to the enterprise node on the current supply and marketing chain through the corresponding accounting node. Therefore, the hidden danger of transaction information leakage is greatly brought.

However, in fig. 2A, since accounting node sub-network 2 is separate from service node sub-network 1, accounting node sub-network 2 is dedicated to accounting, while service node sub-network 1 contains enterprise terminals for each node on the distribution chain, witnessing accounting for accounting node 21. Once accounting nodes 21 cheat collectively, each business node 11 witnessed retains evidence of the particular accounting node doing malicious work. Meanwhile, when the business node needs to inquire the transaction information, not all the transaction information can be returned to the business node, but whether the transaction data is returned to the business node is determined according to the authority data of the business node in the intelligent contract between the business node and the block chain operator. Therefore, any other enterprise node irrelevant to the current supply and distribution chain cannot inquire any transaction information linked on the enterprise node on the current supply and distribution chain, and the hidden danger of transaction information leakage is eliminated.

In an example of 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 component supplier terminal, a bank terminal, and the like. The automobile manufacturer and the automobile ordering party make a total purchase contract, and a part of the total purchase contract is allocated for tire purchase from the price of the total purchase contract, and then the corresponding part is allocated for vehicle part purchase. The tire manufacturer follows a contract with the automobile manufacturer, and draws out a part of the price of the contract for purchasing the rubber required by tire manufacturing. Thus, a layer-by-layer purchasing relationship is established.

When the automobile manufacturer makes a total purchase contract with an automobile ordering party, or the automobile manufacturer makes a separate purchase contract with a tire manufacturer and a vehicle part supplier, or the tire manufacturer makes a separate purchase contract with a rubber manufacturer, corresponding transaction information is transmitted to the proxy node 12, and the proxy node 12 selects one accounting node 21. The agent node 12 sends the corresponding transaction information to the selected accounting node 21 for caching. The accounting node 21 typically does not pack a transaction alone into a data block uplink, but rather into a data block according to block packing requirements (e.g., sufficient number or size). Each accounting node is assigned in advance a key for signing, which key is specific to the accounting node. The accounting node 21 generates a signature based on transaction information to be included in a data block to be added to the block chain 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. The accounting node 21 adds the transaction information and the generated signature to the data block, performs uplink after common identification among all the accounting nodes 21, and simultaneously sends the signature to each service node 11 in the service node subnetwork through the proxy node 12.

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

In case of simultaneous transmission of transaction information, the service node 11 acquires a key specific to the accounting node. In the case of an asymmetric public-private key pair, the key employed by the accounting node 21 in the accounting process is a private key assigned to the accounting node 21 by a Certificate Authority (CA). At the same time as the private key is assigned, a public key is also assigned to accounting node 21. The public key is stored at the certificate authority. The service node 11 can request the public key allocated for the accounting node 21 from the certificate authority. This public key is the accounting node specific key that the service node 11 has acquired. The service node 11 decrypts the signature by using the key, and obtains the digest of the transaction information in the data block. The service node 11 computes a summary of the transaction information in the data blocks received simultaneously. And if the calculated digest is consistent with the decrypted digest, the signature verification is successful.

In the case where 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, for example, a public key assigned from the certificate authority to the accounting node 21. The service node 11 decrypts the signature with a key specific to the accounting node to obtain the digest of the transaction information in the data block. If the digest received simultaneously with the signature is identical to the digest obtained by decryption, the signature verification is successful.

In the case where a digest of the transaction information (e.g., a digest, which may be a root of a mercker tree calculated from a hash value of each piece of transaction information to be included in the data block, is sent together with a signature in the block header) is sent at the same time, the service node 11 does not receive each piece of transaction information. When the service node 11 wants to view the transaction information, it needs to request from the accounting node 21. At this time, the accounting node 21 obtains target service node authority data (generally obtained from an intelligent contract made by the service node with the block chain operator) corresponding to the service node, where the target service node authority data indicates which target service nodes the service node is allowed to access related transaction information. And if the actor or the actor of the transaction information is one of the target service nodes indicated in the authority data of the target service node, returning the transaction information to the service node. Therefore, the aim that some units do not want the transaction information of the units to be seen by the irrelevant parties is achieved, and the privacy of the uplink transaction information is improved.

If no transaction information is returned to the service node (the service node has no authority), a hash value of the transaction information may be returned thereto. Since the Mercker tree root can be calculated only by the hash value of each piece of transaction information, the purpose of hiding the information and not influencing the content verification in the data block is achieved. The service node 11 may calculate hash values for the obtained non-hidden transaction information, calculate a mercker tree root according to the hash values and the hash values of the received hidden transaction information, compare the mercker tree root with the mercker tree root included in the block header, and if the hash values are consistent with the mercker tree root, indicate that the content of the data block is not tampered, and the content passes verification. The service node 11 may also receive transaction information from the non-hidden transaction information to verify whether the transaction information is consistent with the transaction information sent to the accounting node 21 by itself. If the inconsistency is not consistent, the service node 11 is declared bad, and the purpose of supervision is achieved.

The method and the device mainly aim at the process that after the business node receives the query request of the business node for the transaction information in the data block, the authority data of the target business node corresponding to the business node is obtained and is compared with an actor or a follower of the transaction information, and therefore whether the transaction information is returned to the business node or not is determined.

The general process of chaining transaction information to queries and verifications in a supply chain financial application scenario is described below in conjunction with FIGS. 3A-3G. Fig. 3A-3G are service node display interface diagrams applied in a supply chain financial application scenario for a method for querying transaction information in a data block in a blockchain network according to an embodiment of the disclosure.

As shown in FIG. 3A, the automobile factory B is based on the seller A purchasing 1000 ten thousand purchase orders from the automobile factory B, and entrusts the tire factory C to produce tires of 200 ten thousand sale prices with 200 ten thousand of 1000 ten thousand of the lots. After the operator of the bus plant B enters the transaction information into the service node 11 of the bus plant B, the operator clicks the option "submit to accounting node", and the transaction information is sent to the accounting node 21 through the agent node 12. The accounting node 21 places transaction information to be included in a data block to be added to the block chain in a block body. Accounting node 21 also generates summaries of these transaction information, such as the Merckel tree root of FIG. 3B. The accounting node 21 also generates a signature based on the transaction information in the data block using a key specific to the accounting node. The merkel root, the signature, and the digest of the previous data block on the block chain are placed together in the block header. The block header and block body constitute the data block of the uplink, and the uplink is identified by all the accounting nodes 21.

The accounting node 21 also sends the block header to each service node 11. The mercker tree root, signature and summary of the previous data block on the block chain 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 key specific to the accounting node to obtain a digest of the transaction information in the data block, i.e., the mercker tree root. If the Mercker tree root in the received block header is not consistent with the decrypted Mercker tree root, the signature verification fails, and the interface shown in FIG. 3C is displayed. If the Mercker tree root in the received block header is consistent with the Mercker tree root obtained through decryption, the signature verification is successful, and an interface as shown in FIG. 3D is displayed. Since in the above process, the service node 11 only obtains the block header of the data block, the transaction information in the block header has not been obtained yet. At this time, the user is asked in the interface of fig. 3D whether to request the 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 permission data for the service node 11 indicating which target service nodes the service node 11 has the right to query for transaction information. If the actor or the victim of the transaction information happens to be one of the target service nodes indicated in the target service node permission data, it indicates that the service node has such inquiry permission, and returns the transaction information 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 the transaction information that the service node 11 in the data block is not authorized to obtain, such as the transaction information of the transaction information ID 000258, the transaction information of the transaction information ID 000256, the transaction information of the transaction information ID 078365, and the transaction information of the transaction information ID 018387, only the hash value is returned to the service node 11, as shown in fig. 3E.

After the user selects "perform content verification" on the interface of fig. 3E, the service node 11 calculates the hash value of the specific information of the transaction information ID 000083 and the specific information of the transaction information ID 000153 in fig. 3E, then calculates the merck 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 root with the merck root included in the chunk header to perform content verification. If accounting node 21 has tampered with the contents of the data block, the computed Mercker tree root is inconsistent with the Mercker tree root contained in the block header, and a "content verification failed" interface is displayed as shown in FIG. 3F. If the computed Mercker tree root is consistent with the Mercker tree root contained in the chunk header, an interface of "content verification successful" is displayed as shown in FIG. 3G.

Fig. 2B shows a scene architecture diagram applied in an application scenario of an electronic invoice according to an embodiment of the present disclosure, in which the method for querying transaction information in a data block in a blockchain network is applied.

In a traditional block chain application scene of electronic invoices, a local tax bureau issues invoices to invoicing enterprises, the invoicing enterprises issue invoices to ticket retrievers, and the ticket retrievers submit invoices to reimbursement units where the ticket retrievers are located. All these transactions require uplink, i.e. recording onto the blockchain. However, the nodes of the local tax office, billing enterprise, and reimbursement entity are not accounting nodes 21. They order the corresponding accounting node or super node to record these transactions on the blockchain. All the accounting nodes or super nodes are uniformly set by the national tax department. They can supervise and witness each other, but the nodes of the local tax bureau, the invoicing enterprise and the reimbursement unit are direct relatives of the invoice, but can not supervise and witness and only trust the accounting node 21 completely. In addition, any enterprise can inquire any transaction information on the blockchain through the corresponding accounting node. But in some cases, the invoice-related information for a business is not desired to be known to other businesses. In the disclosed embodiment, accounting node sub-network 2 is dedicated to accounting, since accounting node sub-network 2 is separate from service node sub-network 1, and service node sub-network 1 contains the nodes that are relevant to the benefits of these invoices, the accounting of accounting node 21 is witnessed. Once accounting nodes 21 cheat collectively, each business node 11 witnessed retains evidence of the particular accounting node doing malicious work. When any service node 1 needs to query the transaction information in the data block, the accounting node needs to acquire the target service node authority data corresponding to the service node, and the target service node authority data indicates that the service node has the right to query the transaction information related to which target service nodes. If the actor or the follower of the transaction information is one of the target service nodes indicated in the authority data of the target service node, 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, the transaction information is not returned to the service node, but the hash value of the transaction information is returned, so that the service node can verify the Merck tree root in the block header by using the hash value, and the purpose of content verification is achieved.

In an example of an electronic invoice, as shown in fig. 2B, each service node 11 includes a billing unit terminal, a reimburser mobile phone, a reimbursement unit terminal, a local tax office terminal, and the like.

When the local tax authority issues an invoice for a billing unit, or the billing unit issues the invoice, or a reimburser reimburses the invoice to a reimbursement unit, corresponding transaction information (transfer of ownership of the invoice) is transmitted to the agent node 12, and the agent node 12 selects one accounting node 21. The agent node 12 sends the corresponding transaction information to the selected accounting node 21 for caching. The accounting node 21 then packs into data blocks 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 of the data block and sends the signature to the service node 11, similar to the process described in connection with fig. 2A.

There may also be transaction information in the data block, or a digest of the transaction information, sent to each service node 11 simultaneously with the signature. In the case of transmitting transaction information at the same time and in the case of transmitting the digest at the same time, although the signature verification method is different in the service node 11, the signature verification can be performed in both the service node 11 and 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 sending the summary of the transaction information at the same time, the service node 11 may perform content verification of the data block, and the verification process is also similar to the process shown in fig. 2A, and thus is not described again.

Fig. 4A-4G illustrate service node display interface diagrams applied in an electronic invoice application scenario for a method for querying transaction information in a data block in a blockchain network according to an embodiment of the present disclosure, which illustrate the general processes of chaining, querying and verifying transaction information in an electronic invoice application scenario.

As shown in FIG. 4A, in 2018, day 22 of 10 months, liu Shan to Rainbow computer company purchased a computer for the unit Hongsheng company, which took 3000 yuan. Rainbow computer corporation has produced an invoice for Liu Shan with a transaction ID of 000083. After the staff of the rainbow computer company inputs the information, the staff clicks the option of 'submitting to the accounting node', and the transaction information is sent to the accounting node 21 through the agent node 12. Accounting node 21 places transaction information to be included in a data block to be added to the block chain in a block body. The accounting node 21 also generates a mercker tree root and a signature, which are placed in the chunk header together with the digest of the previous data chunk on the chunk chain. The accounting node 21 chains up the data blocks and sends the block number to each service node 11. The mercker tree root, signature and summary of the previous data block on the block chain 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, requests the accounting node 21 for transaction information, 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 the content verification. These processes are similar to those shown in FIGS. 3C-3G and are not described in detail.

Fig. 2C is a diagram illustrating a scenario architecture of applying the method for querying transaction information in data blocks in a blockchain network in an application scenario of legal digital currency according to an embodiment of the present disclosure.

In the scenario of legal digital currency, the digital currency is issued by an official and must be supervised by the official, and the public needs to trust the digital currency to prevent the collective cheating of the official accounting nodes, so that the problem of the balance of government supervision and public trust in the existing network system is caused. In addition, in the existing block chain 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 block chain, while some units of transaction information are not expected to be exposed to all persons, and the problem of privacy protection is also generated.

In this case, the solution of the embodiment of the present disclosure in which the billing node sub-network and the service node sub-network are separated completely avoids this problem. First, each accounting node of the accounting node sub-network belongs to the authority. When the transaction of the legal digital currency occurs at any service node, the transaction of the legal digital currency is recorded on the blockchain through the corresponding accounting node. However, each service node in the service node subnetwork may witness the accounting of accounting node 21. Once the accounting nodes 21 cheat collectively, each service node 11 witnessed retains evidence that a specific accounting node cheats, and gives consideration to government supervision and public trust. Meanwhile, the service node wants to inquire the transaction information, and acquires target service node authority data corresponding to the service node, wherein the target service node authority data indicates that the service node is authorized to inquire the transaction information related to the target service nodes. And if the actor or the actor of the transaction information is one of the target service nodes indicated in the authority data of the target service node, returning the transaction information to the service node. When the service node has no authority, the transaction information is not returned to the service node, but the hash value of the transaction information is returned, and the Mercker tree root in the block header can be verified through the hash value, so that the content verification is realized.

In one example of legal digital currency, as shown in FIG. 2C, each service node 11 includes a respective transaction terminal involved in the circulation of the legal digital currency. When transmitting transaction information of the legal digital currency, the transaction terminal transfers the corresponding transaction information (transfer of ownership of the legal digital currency) to the agent node 12, and one accounting node 21 is selected by the agent node 12. The agent node 12 sends the corresponding transaction information to the selected accounting node 21 for caching. The accounting node 21 then packs into data blocks 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 of the data block and sends the signature to the service node 11, similar to the process described in connection with fig. 2A.

Fig. 5A-5G show service node display interface diagrams in a fiat digital currency application scenario illustrating the general process of accounting and witnessing in a fiat digital currency application scenario applied to a method of querying transaction information in data blocks in a blockchain network according to one embodiment of the present disclosure.

As shown in fig. 5A, on 29/8/2018, since X bought a piece of furniture of the legal digital currency sold at a price of 3000 units from Y, Y paid the legal digital currency of 3000 units of the renminbi. After the information is input by the company X, the option of 'submitting to the accounting node' is clicked, and the transaction information is sent to the accounting node 21 through the agent node 12. Accounting node 21 places transaction information to be included in a data block to be added to the block chain in a block body. The accounting node 21 also generates a merkel root and a signature, placing the merkel root, the signature and a digest of the previous data block on the blockchain together in the blockheader. The accounting node 21 chains up the data blocks and sends the block number to each service node 11. The mercker tree root, signature, and summary of the previous data block on the block chain 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 fig. 5D according to the verification result, requests the accounting node 21 for transaction information, displays the interface of the acquired transaction information or the 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 FIGS. 3C-3G and are therefore not described in detail.

As shown in fig. 6, according to one embodiment of the present disclosure, a method for querying transaction information in a data block in a blockchain network is provided. As shown in fig. 1A-1C, the blockchain network includes a billing node sub-network 2 and a service node sub-network 1. The accounting node sub-network 2 comprises an accounting node 21 that records data blocks onto a block chain. The service node subnetwork 1 comprises a service node 11 that validates data blocks recorded by accounting nodes onto the blockchain. The method is performed by one accounting node 21 in 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, acquiring target service node authority data corresponding to the service node, wherein the service node has the right 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 actor of the transaction information is one of the target service nodes indicated in the authority data of the target service node, returning the transaction information to the service node.

Steps 310-330 are described in detail below.

There are various ways for the billing node to receive a query request from the service node for the transaction information in the data block in step 310. In one embodiment, the accounting node may receive a request for a transaction message in the data block from the service node via a proxy node, which is a special node in the service node sub-network and is used to transfer the message 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 one of the accounting nodes in the accounting node sub-network, so as to select an accounting node, which will be described in detail below. In another embodiment, the service node may send the query request directly to the accounting node. The method for selecting the accounting node by the service node may be the same as the method for selecting the accounting node by the agent node.

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

In one embodiment, a corresponding relation table of the service node and the authority data of the target service node is maintained in advance at each accounting 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 an intelligent contract with the blockchain operator in advance. Target service node permission data corresponding to the service node can be acquired from an intelligent contract between the service node and a block chain operator. How to generate the intelligent contract is described in the following embodiments.

In step 330, if the actor or the actor 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.

As is well known, a transaction is an action by which one party invokes another party. The party that causes the action is the actor and the party that is caused the action is the actor. For example, in a transaction for issuing an electronic invoice, a terminal of a billing unit is an actor and a terminal of a ticket taker is an actor. In the transfer transaction of the legal digital money, the terminal of the transferring party of the legal digital money is the actor, and the terminal of the transferring party of the legal digital money is the acceptor.

As shown in fig. 17, each piece of transaction information includes actor information and victim information. The actor information includes actor-related information and the follower information includes follower-related information. For example, in the event of issuing an electronic invoice, the actor information includes the name of the billing unit, the taxpayer identification number of the billing unit, the name of the billing person, the billing time, the billing amount, and the like, and the actor information includes the name of the ticket taker, the contact address of the ticket taker, the reimbursement unit in which the ticket taker is located, and the like. The actors in the transaction information have two expression modes, one is directly expressed by the name of the actor (such as the name of the invoicing unit, the name of the legal digital currency transfer unit, etc.) (for example, the actor of the transaction information TX3 is a, and the actor of the transaction information TX3 is a unit terminal named as a in fig. 17), and the other is expressed by other transaction information, and the actor of the transaction information is the follower of the other transaction information (for example, the actors of the transaction information TX1 and TX2 are TX0, and the actors of the transaction information TX1 and TX2 are the followers of the transaction information TX0, and the actor of TX4 is TX1+ TX2, and the actor of the transaction information TX4 is the followers 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 invoicing transaction information, i.e. the actor becomes the actor when the ticket taker who received the electronic invoice in the invoicing event reimburses the unit. When multiple ticket extractors jointly reimburse in the same unit, the actor in the reimbursement transaction information may come from the actor in multiple invoicing transaction information.

The target service node permission data indicates a target service node to which the service node is entitled to query. If the actor or the victim of the transaction message is one of the target service nodes indicated in the target service node permission data, the transaction message can be returned to either the actor or the victim within the permitted permission.

In one embodiment, after step 320, the method further comprises: if the actor of the transaction information is the actor of another transaction information and the actor of the another 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.

As described above, the actor in the transaction information has two ways of representing, one is directly represented by the actor name, the other is represented by the other transaction information, and the actor representing the transaction information is the passive actor of the other transaction information. In this way, if the actor of the transaction information is the latter expression, that is, the actor of the transaction information is the actor of another transaction information, and the actor of the another transaction information is one of the target service nodes indicated in the authority data of the target service node, in this case, it also becomes equivalent to that the actor of the transaction information is one of the target service nodes indicated in the authority data of the target service node, and the service node should also have the right to query the transaction information of the target service node.

As shown in fig. 17, the actor of the transaction message TX4 is denoted by TX1+ TX2, i.e., the actor of the transaction message TX4 is the passive actor of the transaction message TX1 and the passive actor of the transaction message TX 2. For example, the transaction information TX4 is transaction information for electronic invoice reimbursement, and the transaction information TX1 and TX2 are transaction information for two electronic invoice invoices respectively. In the transaction information TX1, A1 is a ticket taker. In the transaction information TX2, B is the ticket taker. The actor TX1+ TX2 of TX4 represents that the actor of TX1 (i.e., ticket seeker A1) and the actor of TX2 (i.e., ticket seeker B) are reimbursed together. Thus, ostensibly the actor of transaction TX4 is denoted TX1+ TX2, and in fact its actor is A1+ B. Thus, if the target service node authority data indicates that the service node a has authority to query the transaction information of the service nodes a and A1 (A1 is a subsidiary of a), A1 in A1+ B is for which the service node a has authority to query the transaction information. Thus, transaction information may be returned to the service node.

This embodiment overcomes the problem that when it is the actor of the transaction information that is represented by other transaction information (i.e. the actor of the transaction information is the actor of the other transaction information), it is possible to determine whether it is an incorrect one of the target service nodes indicated in the target service node entitlement data from the actor or the actor of the transaction information alone, because in this case, the actor of the transaction information is essentially one of the target service nodes indicated in the target service node entitlement data, but not in form, thus causing a false determination. 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: and 330, if the actor or the actor of the transaction information is not one of the target service nodes indicated in the authority data of the target service nodes, or is not the actor of another transaction information, and the actor of the another transaction information is one of the target service nodes indicated in the authority data of the target service nodes, returning the hash value of the transaction information to the service node.

That is, in both cases described above (the first case is that the actor or the actor of a transaction message is itself one of the target service nodes indicated in the target service node permission data, the second case is that the actor of the transaction message is the actor of another transaction message, and the actor of the other transaction message is one of the target service nodes indicated in the target service node permission data), the service node should be considered as having the right to query the transaction message. If the two situations do not exist, namely the actor or the actor of the transaction information is neither one of the target service nodes indicated in the authority data of the target service nodes nor the actor of the other transaction information, and the actor of the other transaction information is one of the target service nodes indicated in the authority data of the target service nodes, the service node is considered to have no authority to inquire the transaction information, and the transaction information is not returned to the service node at the moment, and only the hash value of the transaction information can be returned for content verification.

Since the mercker tree root can be calculated only by the hash value of each piece of transaction information, the service node 11 can calculate the hash value of the acquired non-hidden transaction information, calculate the mercker tree root according to the hash values and the received hash value of the hidden transaction information, compare the mercker tree root with the mercker tree root contained in the block header, if the hash values and the received hash value of the hidden transaction information are consistent, the content of the data block is not tampered, the content is verified to pass, and therefore the purpose of preventing the accounting node from tampering the content of the transaction information is achieved.

In one embodiment, as shown in FIG. 7, step 310 comprises: 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. Additionally, prior to step 320, the method further comprises: and step 312, verifying the signature by using a public key specific to the service node, wherein only if the verification is successful, the target service node permission data corresponding to the service node is obtained.

Compared to the embodiment of fig. 6, the embodiment of fig. 7 adds a process of verifying the identity of the service node, which is rejected before the actor and the victim are checked against the authority data if the identity of the service node is not qualified, i.e. not a node registered in the blockchain network (including the service node sub-network and the accounting node sub-network), which is not authorized to query any uplink transaction information. By the method, the safety of inquiring the uplink transaction information on the block chain network is further ensured.

Whether the identity of the service node is qualified, namely whether the service node is a node registered on the blockchain network, can be verified through the signature. The authentication center issues a private key specific to the service node while storing a public key specific to the service node at the authentication center, or to the agent node, or to each accounting node in the accounting node sub-network. In this way, the service node, because of its possession of the 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 signature method includes first calculating the digest of the query request using a predetermined digest algorithm, and then encrypting the digest using a private key specific to the service node. And when the accounting node or the proxy node obtains the signature, verifying the signature.

In one embodiment, step 312 includes:

obtaining a public key specific to the service node;

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

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

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

It can be seen that the process of verification 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 process of generating the signature. Therefore, the query request is summarized again by using the summarization algorithm when the summary is generated, and if the obtained summary is the same as the decrypted summary, the verification is successful. If not, the authentication fails and the query request is rejected.

In one embodiment, the authentication center issuing the service node specific private key to the service node may occur immediately after the service node registers with the blockchain network. In this embodiment, after the service node sends the registration request to the node in the blockchain network responsible for the blockchain network registration, the node in the blockchain network registration reads and stores the service node registration information in the registration request, and notifies the authentication center to issue the 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 before the service node sends a query request for transaction information. In this embodiment, after the service node sends the registration request to the node in the blockchain network responsible for blockchain network registration, the node in the blockchain network registration reads and stores the service node registration information in the registration request, and simultaneously notifies the authentication center that the service node is registered, but does not urgently issue a private key specific to the service node, but the service node sends a private key request to the authentication center before the service node sends the query request. After inquiring that the service node is registered, the authentication center distributes a private key specific 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 broker node may be performed immediately after the issuing of the private key specific to the service node by the authentication center, that is, the issuing of the public key specific to the service node to the accounting node or the broker node by the authentication center immediately after the issuing of the private key specific to the service node. In another embodiment, however, the certificate authority issues the public key specific to the service node to the accounting node or the proxy node when the accounting node or the proxy node needs to decrypt the signature sent from 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 requested from the authentication center, and then the public key specific to the service node is issued to the accounting node or the proxy node by the authentication center.

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

In the embodiment of fig. 18A, the process of signature verification may be performed at the proxy node. The service node creates the query request and signs it with a private key specific to the service node. The service node sends the query request and the signature to the proxy node. And the proxy node acquires a public key specific to the service node and verifies the signature. If the verification is successful, the proxy node continuously sends the query request to the accounting node, the accounting node verifies the actor or the follower of the transaction information according to the target service node authority data of 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, or if the actor of the transaction information is the follower of another transaction information and the follower of the another 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 hash value of the transaction information is returned.

In the embodiment of FIG. 18B, the process of signature verification may be performed at the accounting node. The service node creates the query request and signs it with a private key specific to the service node. The service node sends the query request and the signature to the proxy node, which forwards the query request and the signature to the accounting node. And the accounting node acquires a public key specific to the service node and verifies the signature. If the verification is successful, the accounting node verifies the actor or the follower of the transaction information according to the target service node authority data of 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, or if the actor or the follower of the transaction information is the follower of another transaction information and the follower of the another 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 hash value of the transaction information is returned.

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

305, generating an intelligent contract between the service node and a block chain operator;

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

In this embodiment, step 320 includes:

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

In this embodiment, the intelligent contracts of each service node with the blockchain operator are stored in accounting nodes in the accounting node sub-network. The embodiment has the advantage that the intelligent contracts are locally stored in each accounting node, so that the processing speed of returning the transaction information or the hash value to the service node is greatly increased.

The intelligent contract is a contract for storing authority data (including target service node authority data) of the service node in the aspect of inquiring transaction information, and is formed by the service node and a block chain operator in advance.

The target service node authority data is data indicating which target service nodes the service node has authority to query for transaction information, and indicates: at least one of which target service nodes the actor or the actor of the transaction information must carry to allow the query; alternatively, the actor of the transaction message is the actor of another transaction message, and the actor of the other transaction message must carry at least one of the target service nodes to which the service node allows the query. 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 nodes that can be queried by the service node a include A, A, A2. Once the actor or the follower of the transaction information contains at least one of A, A1 and A2, or the actor of the transaction information is the follower of another transaction information, and the follower of the another 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 comprises:

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

step 3052, receiving target service node authority data of the service node set by 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 block chain operator.

The contract template is the contract style that applies to the intelligent contracts of all service nodes and blockchain operators. Each smart contract may apply the style, but with different specific rights data. It is a format section in the intelligent contract after removing the authority data which is different with different service nodes. The contract function is a function set in the contract, and the user can set the target service node authority data by calling the function. Publishing the contract template may include publishing the contract template to the billing node or may include publishing the contract template to all billing nodes in the billing node subnetwork. In the former case, an administrator operating the accounting node may determine the authority data for the service node and enter the accounting node after reviewing the details of the service node. In the latter case, the administrator of any accounting node may determine and enter the authority data for the service node after reviewing the details of the service node.

The specific condition of the audited service node comprises the service node of the subordinate unit or the administration 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 is used as a business node, and the unit is the invoice issuing company. The unit to which the service node belongs may be its affiliate. In addition, the unit to which the service node belongs may be a functional department, and the administration unit of the service node is all the units administered by the functional department. For example, the jurisdiction of the prefecture of the city XX may be all taxation units in the city XX. The administrator may determine the service node and the service node of the unit subordinate to the service node or the administration unit as the target service node indicated in the target service node authority data. For example, company a has two branches A1, A2, and may determine A, A, A2 as the target service node indicated in the target service node authority data, that is, when one of A, A, A2 appears in the transaction information actor or the follower, or when the actor of the transaction information is the follower of another transaction information and the follower of the another transaction information is one of A, A, A2, company a is considered to have the authority to query the transaction information.

After the administrator determines the authority data, the authority data of the service node is set by the accounting node by using the contract function, so that the accounting node receives the target service node authority data of the service node set by using the contract function, and the target service node authority data is integrated into the contract template, thereby forming an intelligent contract between the service node and a block chain operator.

The embodiment has the advantages that the contract template provides a contract function, so that an administrator can flexibly set 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 comprises:

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

step 3055, determining target service node authority data according to service nodes of subordinate units or administration units of the service nodes;

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

In this embodiment, when a 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 unit subordinate to the service node or a service node of a jurisdiction unit. After receiving the intelligent contract generation request, the accounting node automatically determines target service node authority data according to the service node of the subordinate unit or the administration 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 intelligent contract generation is achieved.

The above-described method of automatically determining the authority data is as follows.

In one embodiment, step 3055 comprises: and determining the service node, the service node of the unit subordinate to the service node or the service node of the administration unit as the target service node indicated in the authority data of the target service node. For example, company a has two branches A1 and A2, and may determine A, A and A2 as the target service node indicated in the target service node authority data.

The embodiment is similar to the method for determining the target service node permission data according to the service node of the subordinate unit or the administration unit of the unit to which the service node belongs by the administrator, except that the machine directly determines the service node of the subordinate unit or the administration unit of the unit to which the service node belongs in the received intelligent contract generation request and the service node as the target service node permission data, thereby realizing the determined automation.

In another embodiment, the intelligent contract is not implemented to be stored in each accounting node of the sub-network of accounting nodes, but rather the ul records. Therefore, when each accounting node needs to acquire the authority data from the intelligent contract, uplink searching can be carried out. The embodiment has the advantage that the occupation of the internal storage space of the node is saved compared with the situation that a database is maintained inside each accounting node to store the intelligent contract of each service node.

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

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

Accordingly, step 320 includes:

step 3202, obtaining an intelligent contract between the service node and a block chain operator from an intelligent contract block corresponding to the service node on the block chain;

step 3203, obtain 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 therefore is not repeated.

In one embodiment, step 307 comprises:

correspondingly storing the generated intelligent contract and the service node identification in the block body of the intelligent contract block;

applying abstract operation and signature operation to the block of the generation area to obtain an abstract and a signature;

adding the abstract, the signature and the abstract of the previous block on the block chain into a block head of the intelligent contract block;

and recording the intelligent contract block on a block chain after the intelligent contract block is identified among all the accounting nodes of the accounting node sub-network.

The service node identification is used to facilitate obtaining an intelligent contract corresponding to the service node in step 3202.

The functions of the digest and the signature, and the digest of the previous block in the block chain are as described above with reference to fig. 2A to 2C, fig. 3A to 3G, fig. 4A to 4G, and fig. 5A to 5G, and thus are not described again.

There are many consensus algorithms for the intelligent contract block to perform consensus among all the accounting nodes in the accounting node sub-network, and therefore details are not given.

Accordingly, step 3202 may include:

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

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

In one embodiment, a specific identifier may be added to the chunk header of the intelligent contract chunk, by means of which the intelligent contract chunk may be located from all data chunks on the blockchain. The embodiment has the advantage that the efficiency of searching the intelligent contracts of the service nodes is greatly improved compared with the method of searching the identifications of the service nodes in all the data blocks one by one.

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

In one embodiment, as shown in fig. 12, the accounting node performing the method is selected from the accounting node sub-network in the following way. In one embodiment, the query request of the service node is sent to the proxy node, and the proxy node selects the accounting node according to the following steps:

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

step 420, determining the distance from each accounting node in the accounting node sub-network to the service node sending the query request;

step 430, determining a billing 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 accounting node. In one embodiment, the processing load may be measured by the number of tasks not processed by the accounting node. The tasks include transaction information chaining tasks and inquiry tasks. These unprocessed tasks can represent the processing load of the accounting node.

In one embodiment, step 410 comprises:

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

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

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

In this embodiment, the proxy node passively receives the processing load periodically transmitted 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:

sending a processing load query request to each accounting node in the accounting node sub-network;

and receiving the processing load of each accounting node transmitted by the accounting node.

In one embodiment, determining the distance of each accounting node in the accounting node sub-network to the service node sending the query request in step 420 comprises:

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

receiving the positioning information of each accounting node and the service node sending the query request from each accounting node and the service node sending the query request;

and determining the distance from each accounting node to the service node sending the query request by utilizing the positioning information of each accounting node and 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. And when receiving a positioning information request sent by the proxy node, sending the self positioning information obtained from the GPS system to the proxy node. After the agent node obtains the positioning information of each accounting node and the service node sending the query request, the agent node can determine the distance from each accounting node to the service node sending the query request by using the positioning information.

In the above embodiment, the positioning information is obtained by using a mode of being actively requested by the proxy node, and as with the processing load, the positioning information may also be sent to the proxy node by using each accounting node and the service node sending the query request periodically, which is not described herein again.

This embodiment has the advantage that not only the processing load of each accounting node but also the distance of each accounting node from the service node sending the query request is taken into account when determining the accounting node performing the method. Although, the processing load of a billing node may be minimal, the billing node may be very far from the service node sending the query request, and is selected as the billing node for executing the method, which increases the network transmission load and also reduces the query processing speed. The embodiment comprehensively considers the distance and the processing load, and compared with a scheme of determining the accounting nodes for executing the query according to the distance or the processing load, the embodiment can roughly balance the processing load of each accounting node and does not cause too much transmission load to the network.

In one embodiment, as shown in FIG. 13, step 430 may comprise:

step 4301, determining a first score of each accounting node based on the processing load of each accounting node in the accounting node sub-network;

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

4303, determining accounting nodes for executing the method based on the first score and the second score of each accounting node.

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

processing load (number of unprocessed tasks)	First fraction
		0－1	5
2－4	4
		5－9	3
10－19	2
		20－49	1
More than 50	0

TABLE 1 processing load and first score correspondence table

In step 4302, determining the second score of each accounting node based on the distance of each accounting node in the accounting node sub-network may take the form of looking up a preset distance-to-second score correspondence table. The corresponding relation 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 between two adjacent plates	Second fraction
		Within 50 m	5
50-200 m	4
		200-1000 m	3
1000-5000 m	2
		5000-20000 rice	1
Over 20000 meters	0

TABLE 2 distance and second score correspondence Table

With the first score and the second score of each billing node, the billing node performing the method can be determined from the first score and the second score. This embodiment has the advantage that the accuracy of selecting accounting nodes for performing said method is improved by fractionalizing the impact of said processing load of each accounting node in the sub-network of accounting nodes and said distance of each accounting node in the sub-network of accounting nodes on the selection of accounting nodes for performing said 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, based on the weighted sum, determines a billing node to perform the method.

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

In step 43032, the accounting node with the largest weighted sum may be determined as the accounting node receiving the to-be-uplink transaction information, or any one of the accounting nodes with the weighted sum larger than a predetermined weighted sum threshold may be used as the accounting node receiving the to-be-uplink transaction information. It can be considered that it is the same as the one selected as the accounting node for performing the method, as long as the weighted sum is larger than the predetermined weighted sum threshold, which is not too much loaded and not too far away from the service node transmitting the pending uplink transaction information. In the latter way, load balancing is also facilitated, preventing the weighted and largest accounting node from being selected at the same time, which in turn causes the weighted and largest accounting node to be obviously overloaded.

This embodiment has the advantage that the determination of the accounting node receiving the to-be-uplink transaction information based on the weighted sum of the first score and the second score of each accounting node takes into account the difference in contribution of the first score and the second score to the determination of the accounting node performing the method substantially, compared to a solution in which the accounting node receiving the to-be-uplink transaction information is determined based on the sum or average of the first score and the second score, which improves the rationality of determining the accounting node performing the method.

The above embodiments of determining the accounting node receiving the information of pending uplink transactions are mainly directed to the case of fig. 1A-1B where there is no branch accounting node sub-network at the accounting node sub-network side. But in the embodiment shown in fig. 1C where the billing node sub-network terminals are divided into branched billing node sub-networks this is the other case.

In this embodiment, the query request includes a 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-networks are classified in advance according to the types of the transaction information processed, and the accounting nodes of each class are respectively formed into a corresponding branch accounting node sub-network, such as a supply chain financial transaction branch accounting node sub-network, an electronic invoice transaction branch accounting node sub-network or a legal digital currency transaction branch accounting node sub-network, wherein each branch accounting node sub-network specially processes the transaction type corresponding to one transaction type. Therefore, the agent node sends the query request to an accounting node in the corresponding type of branch accounting node sub-network according to the transaction information type carried in the query request. In order to achieve the purpose, a corresponding relation table of the accounting node identification and the transaction information type is stored in the agent node, and the accounting node identification and the processed transaction information type are correspondingly recorded in the corresponding relation table of the accounting 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 sub-network in the following way:

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

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

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

A benefit of this embodiment is that for the architecture shown in fig. 1C, where the sub-network terminals of the accounting node are divided into sub-networks of branched accounting nodes, a way of rationally selecting accounting nodes to perform the method is proposed that is suitable for the architecture.

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

Since the agent node is provided with the corresponding relation table of the accounting node identifier and the transaction information type, in one embodiment, in step 520, the accounting node identifier corresponding to the transaction information type in the query request can be found from the table.

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

step 5301, determining the processing load of the accounting node of each found accounting node identifier;

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 a billing node for executing the method based on the processing load and the distance.

The specific implementation process of steps 5301-5303 is similar to that of steps 410-430, except that the range of the accounting node that determines the processing load and the distance to the service node that sends the query request in the embodiment of fig. 16 is limited to the accounting node that is found in step 520 and is identified by the accounting node corresponding to the transaction information type in the query request, and is not all accounting nodes in the accounting node sub-network, which is not described herein again.

According to an embodiment of the present disclosure, as shown in fig. 19, there is also provided an accounting node for querying transaction information in a data block in a blockchain network. The blockchain network includes a billing node sub-network and a service node sub-network. The accounting node sub-network comprises an accounting node that records the data blocks onto the blockchain, and the service node sub-network comprises a service node that verifies the data blocks that the accounting node records 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 permission data obtaining unit 620, configured to obtain target service node permission data corresponding to the service node, where the service node has the right to query the transaction information of the target service node indicated in the target service node permission data;

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

Optionally, the accounting node further comprises:

a second transaction information returning unit (not shown) for returning the transaction information to the service node if the actor of the transaction information is the actor of another transaction information and the actor of the another transaction information is one of the target service nodes indicated in the target service node authority data.

Optionally, the accounting node further comprises:

a hash value returning 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 authority data of the target service node nor the follower of another transaction information, and the follower of the another transaction information is one of the target service nodes indicated in the authority data of the target service node.

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 by the query request by a private key specific to the service node;

the device further comprises:

and a signature verification unit (not shown) configured to verify the signature with a public key specific to the service node, where only if the verification is successful, the target service node permission data corresponding to the service node is obtained.

Optionally, the signature verification unit is configured to:

obtaining a public key specific to the service node;

Optionally, the accounting node further comprises:

the intelligent contract generating unit is used for generating an intelligent contract between the service node and the block chain operator;

and the synchronization unit is used for synchronizing the generated intelligent contract to each accounting node in the accounting node sub-network for storage.

The target service node permission data obtaining unit is further configured to:

and acquiring target service node authority data corresponding to the service node from the intelligent contract of the service node and the block chain operator, which is stored in the accounting node.

Optionally, the apparatus further comprises:

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

acquiring an intelligent contract between the service node and a block chain operator from an intelligent contract block corresponding to the service node on the block chain;

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

Optionally, the intelligent contract generating 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 the contract function;

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

Optionally, the intelligent contract generating 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 domination unit of the unit to which the service node belongs;

determining target service node authority data according to service nodes of subordinate units or administration units of the service nodes;

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

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

and determining the service node, the service node of the unit subordinate to the service node or the service node of the administration unit as the target service node indicated in the target service node authority data.

Optionally, the accounting node performing the method is selected from a sub-network of accounting nodes as follows:

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

determining the distance from each accounting node in the accounting node sub-network to the service node sending the query request;

based on the processing load and the distance, a billing node is determined that executes the method.

Optionally, said determining a billing node to perform said method based on said processing load and said distance comprises:

determining a first score for each accounting node in a sub-network of accounting nodes based on the processing load of each accounting node;

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

based on the first score and the second score of each billing node, a billing node to perform the method is determined.

The method of querying transaction information in data blocks in a blockchain network according to an embodiment of the present disclosure may be implemented by the accounting node 21 of fig. 20 that queries transaction information in data blocks in a blockchain network. An accounting node 21 querying transaction information in data blocks in a blockchain network according to an embodiment of the present disclosure is described below with reference to fig. 20. The accounting node 21 shown in fig. 20 for querying transaction information in data blocks in a blockchain network is only an example, and should not bring any limitation to the function and the scope of use of the embodiments of the present disclosure.

As shown in fig. 20, an accounting node 21 in a blockchain network that queries for transaction information in data blocks is in the form of a general purpose computing device. The components of the accounting node 21 that query the transaction information in the data blocks in the blockchain network 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 that couples the various system components including the memory unit 820 and the processing unit 810.

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

The memory unit 820 may include readable media in the form of volatile memory units, such as a random access memory unit (RAM) 8201 and/or a cache memory unit 8202, and may further include a read only memory unit (ROM) 8203.

The 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 of which, or some combination thereof, may comprise an implementation of a network environment.

Bus 830 may be any 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 data block for transaction information in the blockchain network 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 data block for transaction information in the blockchain network, and/or any device (e.g., router, modem, etc.) that enables the accounting node 21 querying the data block for transaction information in the blockchain network to communicate with one or more other computing devices. Such communication may occur via input/output (I/O) interface 650. Also, accounting nodes 21 that query 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) via network adapter 860. As shown, the network adapter 860 communicates over a bus 830 with other modules of the accounting node 21 that query transaction information in data blocks in a blockchain network. It should be appreciated that although not shown in the figures, other hardware and/or software modules may be used in conjunction with accounting node 21 querying the transaction information in the data blocks in the blockchain network, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems, among others.

Through the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein may be implemented by software, or by software in combination with necessary hardware. Therefore, 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 (which may be a CD-ROM, a usb disk, a removable hard disk, etc.) or on a network, and includes several instructions to enable a computing device (which may be a personal computer, a server, a terminal device, or a network device, etc.) to execute 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 above method embodiment section.

According to an embodiment of the present disclosure, there is also provided a program product for implementing the method in the above method embodiment, which may employ a portable compact disc read only memory (CD-ROM) and include 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 in this respect, 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. A readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the foregoing. More specific examples (a non-exhaustive list) of the readable storage medium include: an electrical connection having one or more wires, a portable disk, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

A computer readable signal medium may include a propagated data signal with readable program code embodied therein, for example, in baseband or as part of a carrier wave. 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 thereof. 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 for aspects 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 and partly on a remote computing device, or entirely on the remote computing device or server. In the case of a remote computing device, 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., through the internet using an internet service provider).

It should be noted that although in the above detailed description several modules or units of the 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, according to embodiments of the present disclosure. Conversely, the features and functions of one module or unit described above may be further divided into embodiments by a plurality of modules or units.

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

Through the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein may be implemented by software, and may also be implemented by software in combination with necessary hardware. Therefore, 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 (which may be a CD-ROM, a usb disk, a removable hard disk, etc.) or on a network, and includes several instructions to enable a computing device (which may be a personal computer, a server, a mobile terminal, or a network device, etc.) to execute 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 invention disclosed herein. This application is intended to cover any variations, 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 data blocks, the blockchain network comprising a sub-network of accounting nodes and a sub-network of service nodes, the sub-network of accounting nodes comprising an accounting node that records data blocks onto a blockchain, the sub-network of service nodes comprising a service node that verifies data blocks recorded onto the blockchain by the accounting node to determine whether content of the data blocks recorded onto the blockchain was tampered with by the accounting node, the method performed by an accounting node in the sub-network of accounting nodes, the method comprising:

generating an intelligent contract between each service node and a block chain operator;

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

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 from an intelligent contract of the service node and a block chain operator, which is stored in the accounting node; the target service node permission data indicates that the service node has the permission to inquire the transaction information of the target service node;

and 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, returning the transaction information to the service node.

2. The method of claim 1, wherein generating an intelligent contract for each service node with a blockchain operator comprises:

3. The method of claim 1, wherein generating an intelligent contract for each service node with a blockchain operator comprises:

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 domination unit of a unit to which the service node belongs;

determining target service node authority data according to service nodes of subordinate units or administration units of the service node subordinate units;

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

4. The method of claim 3, wherein determining the target service node authority data according to the service node of the subordinate unit or the administration unit of the unit to which the service node belongs comprises:

and determining the service node, the service node of the subordinate unit or the administration unit of the unit to which the service node belongs as the target service node indicated in the target service node authority data.

5. A method of querying a blockchain network for transaction information in data blocks, the blockchain network comprising a sub-network of accounting nodes and a sub-network of service nodes, the sub-network of accounting nodes comprising an accounting node that records data blocks onto a blockchain, the sub-network of service nodes comprising a service node that verifies data blocks recorded onto the blockchain by the accounting node to determine whether content of the data blocks recorded onto the blockchain was tampered with by the accounting node, the method performed by an accounting node in the sub-network of accounting nodes, the method comprising:

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

acquiring target service node authority data corresponding to the service node from the intelligent contract; the target service node permission data indicates that the service node has the permission to inquire the transaction information of the target service node;

6. The method of claim 5, wherein generating an intelligent contract for each service node with a blockchain operator comprises:

7. The method of claim 5, wherein generating an intelligent contract for each service node with a blockchain operator comprises:

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

9. The method of claim 5, wherein adding the generated intelligent contract into an intelligent contract block corresponding to the service node, recorded on a block chain, comprises:

correspondingly storing the generated intelligent contract and the identification of the service node in the block body of the intelligent contract block;

performing digest operation and signature operation on the generated block to obtain a digest and a signature;

10. The method of claim 9, wherein obtaining an intelligent contract between the service node and a blockchain operator from an intelligent contract block corresponding to the service node on the blockchain comprises:

11. An apparatus for querying transaction information in data blocks in a blockchain network, the blockchain network comprising a sub-network of accounting nodes and a sub-network of service nodes, the sub-network of accounting nodes comprising an accounting node that records data blocks onto a blockchain, the sub-network of service nodes comprising a service node that verifies data blocks recorded onto the blockchain by the accounting node to determine whether contents of the data blocks recorded onto the blockchain were tampered with by the accounting node, the apparatus comprising:

the first generating unit is used for generating an intelligent contract between each service node and a block chain operator;

a synchronization unit, configured to synchronize the generated intelligent contract to each accounting node in the accounting node sub-network for storage;

the query request receiving unit is used for receiving a query request of the business node for the transaction information in the data block;

a target service node permission data obtaining unit, configured to obtain target service node permission data corresponding to the service node from an intelligent contract between the service node and a block chain operator, where the intelligent contract is stored in the accounting node; the target service node permission data indicates that the service node has the permission to inquire the transaction information of the target service node;

and the transaction information returning unit is used for returning the transaction information to the service node if the actor or the actor of the transaction information is one of the target service nodes indicated in the authority data of the target service node.

12. An apparatus for querying transaction information in data blocks in a blockchain network, the blockchain network comprising a sub-network of accounting nodes and a sub-network of service nodes, the sub-network of accounting nodes comprising an accounting node that records data blocks onto a blockchain, the sub-network of service nodes comprising a service node that verifies data blocks recorded onto the blockchain by the accounting node to determine whether contents of the data blocks recorded onto the blockchain were tampered with by the accounting node, the apparatus comprising:

a second generating unit, configured to generate an intelligent contract between each service node and a block chain operator;

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

a target service node permission data obtaining unit, configured to obtain an intelligent contract between the service node and a block chain operator from an intelligent contract block corresponding to the service node in the block chain, and obtain target service node permission data corresponding to the service node from the intelligent contract; the target service node permission data indicates that the service node has the permission to inquire the transaction information of the target service node;

13. An accounting node, comprising:

a memory storing computer readable instructions;

a processor reading computer readable instructions stored by the memory to perform the method of any of claims 1-4 or to perform the method of any of claims 5-10.

14. A computer program medium having computer readable instructions stored thereon which, when executed by a processor of a computer, cause the computer to perform the method of any one of claims 1-4 or perform the method of any one of claims 5-10.