CN110471952B

CN110471952B - Method, proxy node and medium for determining accounting node in blockchain network

Info

Publication number: CN110471952B
Application number: CN201910678553.5A
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-05-26
Anticipated expiration: 2038-12-07
Also published as: CN109523385A; CN110471953B; CN110471952A; CN110471953A

Abstract

The present disclosure provides a method, agent node and medium for determining an accounting node in a blockchain network. The blockchain network comprises a billing node sub-network formed by billing nodes and a service node sub-network formed by service nodes, and the method is executed by proxy nodes between the billing node sub-network and the service node sub-network. The method comprises the following steps: acquiring the processing load of each accounting node in the accounting node sub-network; determining the distance between each accounting node in the accounting node sub-network and a service node sending a query request; based on the processing load and the distance, an accounting node is determined that services the query request. The embodiment of the disclosure can improve the rationality of determining the accounting node and improve the response efficiency to the service node query request.

Description

Method, proxy node and medium for determining accounting node in blockchain network

The application is a divisional application of application date 2018, 12-7, application number 201811495811.8, and application name "method for inquiring transaction information in blockchain network, accounting node and medium".

Technical Field

The present disclosure relates to the field of blockchain, and in particular to a method, proxy node, and medium for determining an accounting node in a blockchain network.

Background

Conventional blockchain networks fall into two categories. In the first type of blockchain network, each billing node is also the node where transactions occur and thus need to be uplinked with transaction information. In the second blockchain network, the accounting node is only responsible for accounting for the blockchain, i.e., the data is up-link, and the node where the transaction actually occurs and the transaction information is needed to be up-link is outside the accounting node. When the transaction information is required to be uplink, the node requiring the uplink of the transaction information sends the transaction information required to be uplink to the corresponding accounting node, and the accounting node links the transaction information.

In the first type of blockchain network, each node requiring transaction information to be uplink is an accounting node, which can see the detailed information of each data block uplink on the blockchain, and is unable to make some enterprises want to make their own transaction information inquired by unrelated enterprises. In the second type of blockchain network, the node that needs to query the data block information on the blockchain queries on the blockchain through the corresponding accounting node, and since all accounting nodes have authority to query the detailed information in all the data blocks on the blockchain, the node that needs to query the data block information on the blockchain can query the detailed information in all the data blocks on the blockchain, and the information confidentiality cannot be achieved for enterprises that need to have uplink information confidentiality.

The prior art lacks a scheme capable of privacy protection of uplink data based on consensus of shared information.

Disclosure of Invention

An object of the present disclosure is to propose a method, proxy node and medium for determining an accounting node in a blockchain network, which can improve the rationality of determining an accounting node and improve the response efficiency to a service node query request.

According to an aspect of an embodiment of the present disclosure, there is disclosed a method of determining an accounting node in a blockchain network, the blockchain network including an accounting node sub-network comprised of accounting nodes and a service node sub-network comprised of service nodes, the method being performed by a proxy node between the accounting node sub-network and the service node sub-network, the method comprising:

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

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

based on the processing load and the distance, an accounting node is determined that services the query request.

According to an aspect of the disclosed embodiments, there is disclosed a proxy node for determining an accounting node in a blockchain network, the blockchain network including an accounting node sub-network composed of accounting nodes and a service node sub-network composed of service nodes, the accounting node sub-network and the service node sub-network having the proxy node therebetween, the proxy node comprising:

A processing load obtaining unit, configured to obtain a processing load of each accounting node in the accounting node subnetwork;

a distance determining unit, configured to determine a distance between each accounting node in the accounting node sub-network and a service node that sends the query request;

and an accounting node determining unit for determining an accounting node serving the query request based on the processing load and the distance.

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

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

In an embodiment of the disclosure, not only the processing load of each billing node but also the distance of each billing node from the service node sending the query request is taken into account when determining the billing node performing the method. Although it is possible that the processing load of a certain accounting node is minimal, the accounting node may be very far away from the service node that sent the query request, and selecting it as the accounting node that performs the method increases the network transmission load and also reduces the query processing speed. The embodiment comprehensively considers the distance and the processing load, and compared with the scheme of determining the accounting node for executing the query according to the distance or the processing load, the method and the device can approximately balance the processing load of each accounting node, do not cause too much transmission load on the network, improve the rationality of determining the accounting node, and improve the response efficiency to the query request of the service node.

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

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

Drawings

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

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

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

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

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

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

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

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

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

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

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

Fig. 11 illustrates a flow chart of a billing node determining the method of querying transaction information in a data chunk in a blockchain network according to an embodiment of the disclosure.

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

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

Fig. 14 illustrates a flow chart of a billing node determining the method of querying transaction information in a data chunk in a blockchain network according to an embodiment of the disclosure.

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

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

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

Detailed Description

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

In case a digest of the transaction information is transmitted simultaneously (e.g. the digest and the signature are transmitted together in a block header, which digest may be a merck tree root calculated from the hash value of each piece of transaction information to be included in the data block), the service node 11 does not receive each transaction information. The service node 11 needs to request from the accounting node 21 when it is to view the transaction information. Each service node 11 has an intelligent contract with the blockchain operator, and the intelligent contract has authority data of the service node. And according to the authority data of the service node 11, the transaction information which is obtained by the service node in the data block is returned to the service node 11. For transaction information in the data block that the service node 11 is not authorized to acquire, only the hash value of the transaction information is returned to the service node 11. Therefore, the purpose that a plurality of units do not want own transaction information to be seen by irrelevant parties is achieved, and the privacy of the uplink transaction information is improved. Because the Merker tree root can be calculated only by the hash value of each transaction information, the purposes of hiding the information and not influencing the content verification in the data block are achieved. The service node 11 may calculate hash values for the obtained non-hidden transaction information, calculate the merck tree root according to the hash values and the hash values of the received hidden transaction information, compare with the merck tree root contained in the block header, and if they are consistent, indicate that the content of the data block has not been tampered, and pass the content verification. And the service node 11 may also verify from the non-hidden transaction information whether the transaction information corresponds to the transaction information sent to the accounting node 21 itself. If the service nodes are inconsistent, the service nodes 11 are wrongly indicated, and the purpose of supervision is achieved.

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

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

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

If the user selects "yes" the service node 11 requests transaction information from the accounting node 21 via the proxy node 12. The accounting node 21 obtains the entitlement data for the service node from the service node's intelligent contracts with blockchain operators. For the transaction information that the service node 11 in the data block has the right to acquire, the transaction information is returned to the service node 11, such as the specific information of the transaction information ID 000083 and the specific information of the transaction information ID 000153 in fig. 3E; for transaction information in the data block that the service node 11 does not have the right to acquire, such as transaction information ID 000258, transaction information ID 000256, transaction information ID 078365, transaction information ID 018387, the hash value is returned only to the service node 11, as shown in fig. 3E.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

step 320, acquiring authority data of the service node from the intelligent contracts of the service node and the blockchain operator;

Step 330, if it is determined that the service node has the query authority to the transaction information according to the authority data of the service node, the transaction information is returned to the service node, otherwise, the hash value of the transaction information is returned to the service node.

In one embodiment, steps 310-330 may be performed as a separate process, i.e., it does not rely on the uplink of transaction information. That is, step 310 may be preceded by no other steps. Steps 310-330 are similarly performed even if transaction information queried by the service node is not at all uplinked, except that no transaction information is queried at step 330 and an empty message is returned to the service node.

In another embodiment, steps 310-330 are preceded by the step of linking transaction information. In this embodiment, after the transaction information is uploaded, the signature generated by the accounting node for the transaction information is sent to the service node, which verifies the signature. At the time of signature verification, the service node may not obtain the entire transaction information, and may only obtain the abstract of the transaction information. Signature verification may also be performed based on the digest. After the verification is passed, the service node may immediately request to query the detailed information of the transaction information, i.e. send a query request for the transaction information to the proxy node. After receiving the inquiry request, the proxy node forwards the inquiry request to the corresponding accounting node, and the accounting node determines whether to return transaction information to the service node based on the authority data of the service node according to the process.

The case where steps 310-330 are preceded by a step of transaction chaining is also divided into two cases. One is to request transaction information immediately after a transaction is uplink, and the other is that the service node does not issue a query request immediately after a transaction is uplink, but issues the query request in response to a user of the service node inputting a query instruction. In either case, in this embodiment, prior to step 310, the method includes:

generating a signature based on transaction information to be included in one data chunk to be added to the blockchain using a key specific to the accounting node;

adding the transaction information and the generated signature to the data block and adding the data block to a blockchain;

and transmitting the signature to service nodes in the service node sub-network, so that the service nodes verify the signature according to the secret key specific to the billing node.

The accounting node specific key is a key pre-assigned by the authentication center for each accounting node that is dedicated to its use in signing transaction information. In general, the process of signing is such that: and applying abstract operation to the message to be signed to obtain an abstract of the message to be signed, and encrypting the abstract by using a key used for signing to obtain the signature. When the signature is verified, the signature needs to be decrypted by utilizing a secret key used for signing, the abstract of the message to be signed is obtained, and then the same abstract operation is applied to the message to be signed again, so that the redetermined abstract is obtained. If the decrypted digest is consistent with the redetermined digest, the signature verification is successful. By means of signature verification, it can be verified whether the message to be signed is sent by the signer and whether the message is complete. If the message is not sent by the signer or if a part of the message is lost during transmission, signature verification is not passed.

The keys used for signing and signing may be identical, i.e. in the case of symmetric keys, or may be different, i.e. in the case of asymmetric keys. Whichever key is, in one embodiment, the particular key for each billing node may be requested by the billing node from the authentication center as it is set up, generated and stored for the billing node by the authentication center, and then sent to the billing node. And the service node also requests the key specific to the accounting node from the authentication center when signature verification is carried out, and the authentication center sends the key to the service node for signature verification of the service node.

In one embodiment, when the service node 11 sends transaction information to the accounting node 21 through the proxy node 12, the proxy node 12 may not be urgent to use the received transaction information as transaction information to be included in a data block to be added to the blockchain, apply a signature algorithm to the transaction information to generate a signature, and place the signature in a buffer, wait for enough transaction information to be buffered in the buffer, that is, reach a preset block packing requirement (for example, the total size of the transaction information to be uplink in the buffer reaches a predetermined size threshold, and the total number of the transaction information to be uplink in the buffer reaches a predetermined number threshold), and play the transaction information into a packet, generate the signature, and uplink. The benefit of this embodiment is that the utilization efficiency of the data blocks is improved. In one data block, multiple transaction information pieces may be provided, so that excessive scattering of the data blocks on the blockchain is avoided, and the workload of the blockchain uplink is reduced.

The signature algorithm that generates the signature is described above, including the digest algorithm and encryption of the digest. In one embodiment, the summary is the root of the merck tree. In this embodiment, the merck tree root is generated based on transaction information to be included in one data chunk to be added to the blockchain by:

determining a hash value of each transaction information in the data block;

ordering the transaction information in the data block according to the sequence entering the cache, wherein the transaction information sequentially ordered in the odd bit and the subsequent transaction information sequentially ordered in the even bit form a pair;

carrying out hash operation on the hash values of the two transaction information of each pair to obtain the hash value of the pair;

and ordering the pairs according to the sequence entering the cache, wherein the pairs sequentially ordered at the odd number and the pairs sequentially ordered at the even number form a pair at a higher level, and carrying out hash operation on the hash values of the two pairs in each pair at the higher level to obtain the hash value of the pair at the higher level until the hash value of the pair at the uppermost level is obtained, namely the merck tree root.

In the above process, if the transaction information sequentially arranged in the odd-numbered bits is the last transaction information in the cache, the transaction information is taken as a pair; if the pair ordered in the odd bit is the last pair in the cache, the pair itself is taken as the pair at the higher level.

For example, 9 transaction messages are buffered, A1-A9 in the time sequence of entry into the buffer, to be placed in the data block for uplink. A1-A2 form a pair B1, and hash value operation is carried out on the hash value of A1 and the hash value of A2 to obtain the hash value of B1; A3-A4 form a pair B2, and hash value operation is carried out on the hash value of A3 and the hash value of A4 to obtain the hash value of B2; A5-A6 form a pair B3, and hash value operation is carried out on the hash value of A5 and the hash value of A6 to obtain the hash value of B3; A7-A8 form a pair B4, and the hash value of A7 and the hash value of A8 are subjected to hash value operation to obtain the hash value of B4; a9 itself is a hash value for B5, A9 being the hash value of B5.

Aiming at B1-B5 and B1-B2, forming a pair C1 at a higher layer, and carrying out hash value operation on the hash value of B1 and the hash value of B2 to obtain the hash value of C1; B3-B4 form a higher-layer pair C2, and the hash value of B3 and the hash value of B4 are subjected to hash value operation to obtain the hash value of C2; b5 is itself a hash value for C3, B5 is the hash value for C3.

Aiming at C1-C3 and C1-C2 to form a pair D1 at a higher layer, carrying out hash value operation on the hash value of C1 and the hash value of C2 to obtain the hash value of D1; c3 is itself a hash value for D2, C3 is the hash value for D2.

And aiming at D1-D2, carrying out hash value operation on the hash value of D1 and the hash value of D2 to obtain the merck tree root.

In one embodiment, a data block is divided into a block header and a block body. The block body is a main body of the data block, and contains transaction information stored in the data block. The block header is the header of the data block that contains no transaction information, but rather auxiliary information, including a digest (e.g., the merck root), signature, and digest of the previous data block calculated based on all transaction information in the current data block. The function of the digest of the preceding data block is that, since each data block includes information of the preceding data block, the digest of the data block itself is included in the following data blocks on the blockchain. In this way, each data block is associated with each other, and once a certain data block is tampered, the digest of the data block included in the subsequent data block will not correspond to the data block, so that tampering is identified, and the security of the information stored on the blockchain is ensured.

After the data block is uplink, the signature is sent to the service node in the service node sub-network, so that the service node performs signature verification on the signature according to the key specific to the accounting node.

Specifically, in the case where the data block includes a block header and a block body, the block header contains the digest and the signature described above. In one embodiment, a chunk header may be directed to a service node in the service node subnetwork, causing the service node to sign the signature in the chunk header based on a key specific to the accounting node, a digest in the received chunk header.

In one embodiment, the specific process of signature verification of the signature in the block header based on the accounting node specific key, the digest in the received block header, comprises:

acquiring a key specific to the accounting node;

decrypting said signature with a key specific to the accounting node to obtain a digest of transaction information in said data block;

if the received digest is consistent with the decrypted digest, the signature verification is successful.

The method of acquiring the accounting node-specific key may be used to send a key request to the authentication center and receive the accounting node-specific key corresponding to the identifier from the authentication center, which is not described in detail.

As shown in fig. 7, prior to step 310, the method further comprises:

Step 301, generating an intelligent contract between a service node and a blockchain operator;

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

In this embodiment, step 302 includes:

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

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

The intelligent contract is a contract which stores various authority data of the service node in the aspect of inquiring transaction information, and the intelligent contract is reserved by the service node and a blockchain operator. The permission data comprises the permission of the service node to which the transaction information which is allowed to be inquired belongs, the daily permission time period for allowing the transaction information to be inquired and the transaction type corresponding to the transaction information which is allowed to be inquired.

The service node authority to which the transaction information allowed to be queried belongs refers to that the transaction information related to which service nodes has query authority. The service node to which the transaction information belongs refers to the service node of both transaction parties in the transaction information. For example, in a transaction of electronic invoice invoicing, a terminal of an invoicing unit and a terminal of a ticket taker (reimburser) are service nodes to which the transaction information belongs, and the service nodes to which the transaction information of the invoicing relates are a terminal of an invoicing unit and a terminal of a ticket taker (reimburser). For example, in an intelligent contract that the a node and a blockchain operator have established, it is specified that the service node authority to which the transaction information allowed to be queried belongs is the a node, that is, the a node is only allowed to query the transaction information related to the a node, and as long as the a node is one of the terminal of the billing unit and the terminal of the ticket taker (reimburser), the transaction information is considered to have the query authority, and otherwise, the transaction information is not considered to have the query authority. For another example, in the intelligent contract that the a node and the blockchain operator make, the service node authority to which the transaction information allowed to be queried belongs is defined as the a node and the unit node subordinate thereto, namely, the A1 node, namely, the a node is only allowed to query the transaction information related to the a node and the A1, if the a node or the A1 node is one of the terminal of the billing unit and the terminal of the ticket taker (reimburser), the transaction information is considered to have the query authority, otherwise, the query authority is not provided.

The daily allowable period for allowing inquiry transaction information refers to what time of day is allowed to be up-linked to inquiry transaction information. For example, in the intelligent contract that the node A and the blockchain operator have an agreement, the daily allowed time period for allowing to query the transaction information is 9:00-17:00, and only if the query request of the node A for the transaction information in the data block is received at 9:00-17:00 every day, the query authority is considered to be provided for the transaction information, otherwise, the query authority is not provided.

The permission data comprises transaction types corresponding to the transaction information which is allowed to be inquired. For example, it is possible to simultaneously uplink transaction information of three transaction types, namely supply chain financial transaction information, electronic invoice transaction information, legal digital currency transaction information, on the same blockchain. For example, the intelligent contract defined by the node a and the blockchain operator specifies that the transaction type corresponding to the transaction information allowed to be queried is electronic invoice transaction information, and the node a has query authority only when the transaction type corresponding to the transaction information is electronic invoice transaction information, otherwise, the node a has no query authority.

In one embodiment, step 301 includes:

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

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

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

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

The specific conditions of the checked service node comprise service node operation attribute data and the like. The service node operation attribute data is data expressed in unit operation to which the service node belongs. In one embodiment, it includes service nodes of the subordinate or jurisdictional units of the units to which the service node operation attribute data service node belongs, daily working time periods of the units to which the service node belongs, transaction types of the units to which the service node belongs, and the like.

Each service node is a terminal in one unit. The unit to which the service node belongs is the unit to which the terminal belongs. For example, a computer of an invoice issuing company serves as a service node, and the unit is the invoice issuing company. The unit to which the service node belongs may be its branch. In addition, the entity to which the service node belongs may be a functional department, and its jurisdiction unit is all the entities that the functional department jurisdictions. For example, the jurisdictional of the XX municipality tax office may be all tax units of the XX municipality. The administrator may determine the service node, and the service node of the unit subordinate unit or jurisdictional unit to which the service node belongs, as the service node authority to which the transaction information that allows the query belongs. For example, company a is defined by two branch companies A1, A2, A, A, A2 can be determined as the service node authority to which the transaction information that allows the inquiry belongs, that is, when one of A, A, A2 appears in both parties of the transaction information, company a is considered to have the inquiry authority for the transaction information.

The daily operation time period of the unit to which the service node belongs refers to which time period the unit to which the service node belongs is operated daily. The administrator may determine the daily working period of the unit to which the service node belongs as a daily allowed period for allowing inquiry of transaction information. For example, company A works on a 9:00-17:00 day, if at 9:00-17:00 receives a query request from company a, which can be considered to have query rights to the transaction information.

The transaction type of the unit to which the service node belongs refers to what transaction the unit to which the service node belongs is engaged in. For example, the business node has a supply and sales chain financial business in its unit, and its transaction type includes a supply and sales chain financial transaction. For example, the business node's affiliated unit uses a digital money transaction, then its transaction type includes a legal digital money transaction. The administrator may determine the transaction type of the unit to which the service node belongs as the transaction type corresponding to the transaction information that allows the query. For example, company a engages in a supply and sales chain financial business, and if a query request for a piece of uplink supply and sales chain financial transaction information is received, company a may be considered to have query rights for the transaction information.

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

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

In one embodiment, step 301 includes:

receiving an intelligent contract generation request from a service node, wherein the intelligent contract generation request contains service node operation attribute data;

determining authority data corresponding to the service node operation attribute data according to the service node operation attribute data;

In this embodiment, when the service node is to generate an intelligent contract, an intelligent contract generation request is sent, where the intelligent contract generation request includes service node operation attribute data. After receiving the intelligent contract generation request, the billing node automatically determines authority data corresponding to the service node operation attribute data according to the service node operation attribute data, and integrates the automatically determined authority data into the contract template.

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

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

In one embodiment, the service node operation attribute data includes a service node of a unit subordinate unit or jurisdictional unit to which the service node belongs, and the authority data includes a service node authority to which the transaction information allowed to be queried belongs. The determining authority data corresponding to the service node operation attribute data according to the service node operation attribute data comprises the following steps: and determining the service node and the service node of the subordinate unit or the jurisdiction unit of the unit to which the service node belongs as the service node authority to which the transaction information which allows the inquiry belongs.

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

In one embodiment, the service node operation attribute data includes a daily working period of a unit to which the service node belongs, and the authority data includes a daily permission period for permitting inquiry of transaction information. The determining authority data corresponding to the service node operation attribute data according to the service node operation attribute data comprises the following steps: the daily working time period of the unit to which the service node belongs is determined as a daily allowed time period for allowing inquiry of transaction information.

This embodiment is similar to the method described above in which the administrator determines the daily allowance period for allowing inquiry of transaction information based on the daily work period of the unit to which the service node belongs, except that it is automatically performed by the machine, and automation of determination is achieved.

In one embodiment, the service node operation attribute data includes a transaction type of a unit to which the service node belongs, and the permission data includes a transaction type corresponding to transaction information that allows inquiry. The determining authority data corresponding to the service node operation attribute data according to the service node operation attribute data comprises the following steps: and determining the transaction type of the unit to which the service node belongs as the transaction type corresponding to the transaction information which is allowed to be inquired.

This embodiment is similar to the method described above in which the administrator determines the transaction type corresponding to the transaction information to be queried based on the transaction type of the unit to which the service node belongs, except that it is automatically performed by the machine, and automation of determination is achieved.

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

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

and 303, 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 intelligent contracts of the service node and a blockchain operator from intelligent contract blocks corresponding to the service node on the blockchain;

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

Step 301 of fig. 8 is the same as step 301 of fig. 7, and thus is not repeated.

In one embodiment, step 303 comprises:

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

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

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

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

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

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

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

Accordingly, step 3202 may include:

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

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

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

In step 330, in the case that the permission data includes the permission of the service node to which the transaction information allowed to be queried belongs, the determining that the service node has the query permission for the transaction information according to the permission data of the service node includes:

and if at least one of the transaction parties in the transaction information is matched with the authority of the service node to which the transaction information which is allowed to be inquired belongs, determining that the service node has the inquiry authority for the transaction information.

At least one party of the transaction information is matched with the authority of the service node to which the transaction information which allows inquiry belongs, namely at least one party of the transaction information is one of the service nodes to which the transaction information which allows inquiry belongs.

For example, the service node authority to which the transaction information to be queried is allowed includes the service nodes A, A1, A2. The transaction information is electronic invoice issuing transaction information, and two issuing parties, namely an issuing unit terminal and a reimbursement person terminal. If one of the billing unit terminal and the reimburser terminal is A, or A1, or A2, the service node is determined to have query authority for the transaction information.

In step 330, in the case that the permission data includes a daily permission period for permitting querying of transaction information, the determining that the service node has querying permission for the transaction information according to the permission data of the service node includes:

and if the receiving time of the query request is within the daily allowable time period for allowing the query of the transaction information, determining that the service node has query authority on the transaction information.

For example, the daily allowable time period for allowing the A node to query the transaction information is 9:00-17:00 a day, and the time for receiving the query request of the A node is 15:03, so that the A node is considered to have query authority on the transaction information.

In step 330, in the case that the permission data includes a transaction type corresponding to the transaction information that is allowed to be queried, the determining, according to the permission data of the service node, that the service node has a query permission for the transaction information includes:

And if the transaction type contained in the inquiry request is the transaction type corresponding to the transaction information which is allowed to be inquired, determining that the service node has inquiry authority for the transaction information.

For example, the transaction types corresponding to the transaction information that allows the node A to query are transacted by supply chain financial and legal digital money. And if the transaction type contained in the query request sent by the A node is the supply chain financial transaction type, the A node is considered to have query authority on the transaction information.

Due to the query request to the service node in step 330, either transaction information or a hash value of the transaction information is returned. As can be seen from the above-mentioned calculation method of the merck tree root, if some transaction information in the data block is not known, but the hash value of the transaction information is specified, the merck tree root can be calculated finally. The merck tree root calculated by the service node is compared with the merck tree root of the block head of the data block returned by the accounting node, so that the content verification can be performed. If the two merck tree roots are identical, it is stated that the billing node has not tampered with each transaction information. If the two merck tree roots are not identical, there is a possibility that the billing node tampers with some of the transaction messages, resulting in the final service node recalculated merck tree root not being identical to the merck tree root in the block header.

As shown in fig. 9, in one embodiment, after step 302, the method further comprises:

step 304, receiving update of intelligent contracts of the service node and the blockchain operator;

step 305, synchronizing the update to each accounting node storage in the accounting node sub-network.

In step 302, after the generated intelligent contracts are synchronized to each accounting node in the accounting node sub-network for storage, if the operation attribute of the service node changes, for example, only one branch company exists in the company to which the service node a belongs before, the corresponding service node is A1, the two branch companies exist now, and the corresponding service nodes are A1 and A2, the intelligent contracts need to be updated. At this point, it is necessary to receive updates to the smart contracts and then synchronize the updates to the storage of the accounting nodes in the accounting node subnetwork. In this way, each billing node in the billing node subnetwork maintains up-to-date intelligent contracts for service nodes and blockchain parties.

A benefit of this embodiment is that in case each billing node in the billing node sub-network maintains an intelligent contract for each service node separately, the intelligent contracts for each service node maintained by each billing node can be updated quickly.

In one embodiment, step 304 includes:

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

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

The manner of issuing the contract template is the same as that described above when the smart contract is generated.

The manner of receiving the update of the authority data of the service node set by the contract function is basically the same as the manner of receiving the authority data of the service node set by the contract function when the intelligent contract is generated, but only the authority data are changed, and only the changed authority data set by the contract function can be received.

Similarly, the integration of the update of the rights data into the contract template is also similar to the integration of the rights data into the contract template when generating the smart contract, and is not repeated.

The embodiment has the advantages that the update of the authority data can be manually input, an administrator can flexibly set the authority data for the service node according to the specific situation of the service node, and the flexibility of intelligent contract update is improved.

In one embodiment, step 304 includes:

receiving an intelligent contract updating request from a service node, wherein the intelligent contract updating request contains changed service node operation attribute data;

determining updating of authority data corresponding to the service node operation attribute data according to the changed service node operation attribute data;

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

The intelligent contract update request may only contain changed operation attribute data of the service node, and may not contain unchanged operation attribute data.

And determining the update of the authority data corresponding to the operation attribute data of the service node according to the changed operation attribute data of the service node, wherein the update is automatically performed by an accounting node. The rule of automatic update is similar to the way of automatically determining the authority data when generating the intelligent contract, except that only the changed operation attribute data is considered, the authority data corresponding to the changed operation attribute data is determined, and the previous authority data is replaced. For example, only one subordinate company of the service node a originally corresponds to the service node A1 and is now changed into two companies A1 and A2, and at this time, the authority data corresponding to the changed operation attribute data is: the service nodes to which the inquiry transaction information is allowed to belong are A, A and A2. The authority data replaces the authority data which only allows the service node to which the inquiry transaction information belongs to be A and A1 before.

Integrating the update of the rights data into the contract template is also similar to integrating the rights data into the contract template when generating the smart contract, and is not repeated.

The embodiment has the advantage that the update of the intelligent contracts of the service nodes is automated without manual intervention.

As shown in fig. 10, in one embodiment, after step 303, the method further comprises:

step 306, receiving update of intelligent contracts of the service node and the blockchain operator;

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

The content of step 306 is the same as that of step 304, and thus will not be described in detail.

Since the data blocks on the blockchain are not modifiable, if there is a change in the blockdata on the blockchain, only one data block can be remembered, requiring an update. In one embodiment, in step 307, the updated smart contract may be added to the smart contract update block corresponding to the service node and recorded on the blockchain. Thus, when the accounting node searches the intelligent contracts of the service node and the blockchain operator on the blockchain for searching the authority data of the service node, the intelligent contracts of the service node and the blockchain operator can be found in a plurality of data blocks, and the intelligent contracts in the latest data block are used as updated intelligent contracts, so that whether transaction information is returned to the service node is determined.

This embodiment enables the update of the smart contract on the blockchain in a faster way in the case of a post-smart contract generation uplink record.

In one embodiment, the intelligent contracts between the service node and the blockchain operator include not only authority data of the service node, but also information about whether the service node is a registered user. Before the permission data is required to be acquired to judge whether the transaction information is returned for the service node, the information of whether the service node is a registered user is acquired from the intelligent contract. If it is not a registered user, the service node has no authority to query any transaction data that is up-link and no transaction data is returned for it. And if the service node is a registered user, acquiring the authority data and judging whether transaction information is returned for the service node.

The embodiment has the advantages that only the registered user is judged to return transaction information or hash value of the transaction information, no data is returned to the non-registered user, the non-registered user is prevented from inquiring the uplink transaction information through the method of the embodiment of the disclosure, and the security of the uplink data inquiry is improved.

In this embodiment, step 320 includes:

acquiring information of whether the service node is a registered user or not from intelligent contracts of the service node and a blockchain operator;

And if the information indicates that the service node is a registered user, acquiring authority data of the service node from an intelligent contract between the service node and a blockchain operator.

In one embodiment, a field may be set at a particular location in the smart contract. A 1 in this field indicates that the service node is a registered user. This field is 0, indicating that the service node is a non-registered user. Information of whether the service node is a registered user or not is acquired through the field. If the field is 1, acquiring the authority data of the service node from the other field storing the authority data in the intelligent contracts of the service node and the blockchain operator. If the field is 0, no transaction data is returned to the service node. This may include returning no data to the service node or returning null data to the service node. Null data is a structure in which only data is stored, but there is no data of any content in the structure.

In the case where the intelligent contracts between the service node and the blockchain operator also contain information whether the service node is a registered user, in one embodiment, step 301 includes:

Receiving authority data of the service node set by using the contract function and information of whether the service node is a registered user or not;

and integrating the authority data and the information of whether the service node is a registered user into the contract template to form an intelligent contract between the service node and a blockchain operator.

This embodiment differs from the specific procedure of step 301 in the case where the information whether the service node is a registered user is not contained in the intelligent contracts of the service node and the blockchain operator as described above in that:

first, the administrator uses the contract function to set up the authority data of the service node, and also uses the contract function to set up the information of whether the service node is a registered user or not, and inputs both into the accounting node. The contract function may set both types of information. Before an administrator sets information about whether the service node is a registered user, the administrator inquires of a node responsible for registration of the service node with the blockchain network whether the service node is a registered user. The method of querying may be to send a query request to a node responsible for service node registration with the blockchain network and receive information about whether the service node sent by the node responsible for service node registration with the blockchain network is a registered user. When the service node registers, a registration request is sent to a node responsible for registering the service node to the blockchain network, and registration information is filled in. The node responsible for registration of the service node with the blockchain network stores the identity of the service node in correspondence with the registration information. When a query request is received, the query request is provided with an identifier of a service node, and a node responsible for registering the service node with the blockchain network can judge whether the service node is a registered node by querying whether the stored registration information corresponding to the identifier of the service node exists. The node responsible for registration of the service node with the blockchain network may be a designated accounting node in the accounting node subnetwork or may be a dedicated node outside the accounting node subnetwork.

Second, after receiving the two information, the billing node integrates both information into the contract template to form an intelligent contract for the service node and the blockchain operator, rather than integrating only rights data.

In the case that the intelligent contracts between the service node and the blockchain operator also contain information whether the service node is a registered user, in another embodiment, step 301 includes:

sending a query request to a node which is responsible for registering the service node to the blockchain network;

receiving information about whether a service node is a registered user or not sent by a node responsible for registering the service node to a blockchain network;

The above-described procedure differs from the detailed procedure of step 301 in the case where the intelligent contracts of the service node and the blockchain operator do not contain information about whether the service node is a registered user, in that, since the intelligent contracts need to include information about whether the service node is a registered user in addition to the authority data, in order to acquire the information, a query request needs to be sent to the node responsible for registration of the service node with the blockchain network, and information about whether the service node sent by the node responsible for registration of the service node with the blockchain network is a registered user is received. The process of issuing the query request and receiving the information whether the service node is a registered user is the same as that of the foregoing embodiment in which the administrator sets the rights data through the contract function and the information whether the service node is a registered user, except that it is not done by the administrator here, but is done automatically by the machine.

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

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

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

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

step 430, determining an accounting node receiving the transaction information to be uplink based on the processing load and the distance.

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

In one embodiment, step 410 includes:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

TABLE 1 correspondence table of processing load and first score

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

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

TABLE 2 correspondence table of distance and second score

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

a rights data acquiring unit 620, configured to acquire rights data of a service node from an intelligent contract between the service node and a blockchain operator;

and the transaction information returning unit 630 is configured to return the transaction information to the service node if it is determined that the service node has the query authority for the transaction information according to the authority data of the service node, and otherwise, return the hash value of the transaction information to the service node.

In one embodiment, the billing node further comprises:

an intelligent contract generating unit (not shown) for generating intelligent contracts between the service node and the blockchain operator;

a synchronizing unit (not shown) for synchronizing the generated intelligent contracts to the storage of the accounting nodes in the accounting node subnetwork.

The rights data acquisition unit is further configured to: and acquiring authority data of the service node from the intelligent contracts of the service node and the blockchain operator stored in the accounting node.

In one embodiment, the billing node further comprises:

A smart contract block uplink unit (not shown) for adding the generated smart contract to a smart contract block corresponding to the service node, recording on a blockchain,

the rights data acquisition unit is further configured to:

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

and acquiring authority data of the service node from the intelligent contract.

In one embodiment, the smart contract generation unit is further to:

In one embodiment, in the case that the permission data includes a service node permission to which the transaction information allowed to be queried belongs, the determining that the service node has the query permission to the transaction information according to the permission data of the service node includes: and if at least one of the transaction parties in the transaction information is matched with the authority of the service node to which the transaction information which is allowed to be inquired belongs, determining that the service node has the inquiry authority for the transaction information.

In one embodiment, in the case that the permission data includes a daily permission period for permitting querying of transaction information, the determining that the service node has querying permission for the transaction information according to the permission data of the service node includes: and if the receiving time of the query request is within the daily allowable time period for allowing the query of the transaction information, determining that the service node has query authority on the transaction information.

In one embodiment, in a case that the permission data includes a transaction type corresponding to transaction information that allows to be queried, the determining that the service node has query permission for the transaction information according to the permission data of the service node includes: and if the transaction type contained in the inquiry request is the transaction type corresponding to the transaction information which is allowed to be inquired, determining that the service node has inquiry authority for the transaction information.

In one embodiment, the billing node further comprises:

an intelligent contract update receiving unit (not shown) for receiving updates of intelligent contracts for the service node and the blockchain operator;

an update synchronization unit (not shown) for synchronizing the updates to the storage of the accounting nodes in the accounting node sub-network.

In one embodiment, the billing node further comprises:

an update uplink unit (not shown) for adding the update to the intelligent contract update block corresponding to the service node, and recording the update on the block chain.

In one embodiment, the smart contract update receiving unit is further to:

In one embodiment, receiving an update to a business node's intelligence contract with a blockchain operator includes:

In one embodiment, the billing node further comprises:

a signature generation unit (not shown) for generating a signature based on transaction information to be included in one data block to be added to the blockchain using the key specific to the accounting node;

a transaction information and signature uplink unit (not shown) for adding the transaction information and generated signature to the data block, adding to a blockchain;

a signature transmitting unit (not shown) for transmitting the signature to a service node in the service node sub-network, causing the service node to verify the signature based on a key specific to the accounting node.

In one embodiment, the accounting node in the blockchain network that queries for transaction information in the data block is selected from the accounting node subnetwork as follows:

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

based on the processing load and the distance, an accounting node is determined that queries the blockchain network for transaction information in the data block.

In one embodiment, the determining, based on the processing load and the distance, an accounting node in a blockchain network that queries for transaction information in a data block includes:

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

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

based on the first score and the second score of each billing node, a billing node in the blockchain network querying transaction information in the data block is determined.

In one embodiment, the determining the accounting node in the blockchain network that queries for transaction information in the data block based on the first score and the second score of each accounting node includes:

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

Based on the weighted sum, an accounting node in the blockchain network is determined that queries for transaction information in the data block.

In one embodiment, the determining, based on the weighted sum, an accounting node in the blockchain network that queries for transaction information in the data block includes:

and determining the accounting node with the largest weighted sum as the accounting node for inquiring the transaction information in the data block in the blockchain network.

In one embodiment, the query request carries the queried transaction information type, the billing nodes in the billing node sub-network are pre-classified according to the processed transaction information type, and the billing node identification and the processed transaction information type are correspondingly recorded in a corresponding relationship table of the billing node identification and the transaction information type. The accounting node in the blockchain network that queries for transaction information in the data block is selected from the accounting node subnetwork as follows:

acquiring the transaction information type in the query request;

searching an accounting node identifier corresponding to the acquired transaction information type from an accounting node identifier and transaction information type corresponding relation table;

from the accounting nodes identified by the found accounting nodes, the accounting nodes in the blockchain network that query for transaction information in the data blocks are determined.

In one embodiment, the determining, from among the accounting nodes identified by the found accounting nodes, the accounting node that queries the blockchain network for transaction information in the data block includes:

acquiring the processing load of each accounting node identified by each found accounting node;

determining the distance from each billing node identified by the found billing node to the service node that sent the query request;

In one embodiment, the rights data acquisition unit 620 is further configured to:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Claims

1. A method of determining accounting nodes in a blockchain network, the blockchain network comprising an accounting node subnetwork comprised of a plurality of accounting nodes for recording data blocks onto a blockchain and a service node subnetwork comprised of a plurality of service nodes for validating the data blocks recorded onto the blockchain by the accounting nodes, the method performed by a proxy node between the accounting node subnetwork and the service node subnetwork, the method comprising:

sending a positioning information request to each accounting node in the accounting node sub-network and a service node sending a query request; receiving from each billing node and the service node sending the query request, location information of each billing node and the service node sending the query request; determining the distance between each billing node and the service node sending the query request by using the billing nodes and the positioning information of the service node sending the query request;

determining an accounting node serving the query request based on the processing load and the distance;

The billing node receives an intelligent contract generation request from a service node, wherein the intelligent contract generation request contains service node operation attribute data, and the service node operation attribute data comprises at least one of a service node of a subordinate unit or a jurisdiction unit of the service node, a daily working time period of the unit of the service node and a transaction type of the unit of the service node;

if the service node operation attribute data comprises the service node of the unit subordinate unit or the jurisdiction unit to which the service node belongs, determining the service node and the service node of the unit subordinate unit or the jurisdiction unit to which the service node belongs as the service node authority to which the transaction information allowed to be inquired belongs;

if the service node operation attribute data comprises a daily working time period of a unit to which the service node belongs, determining the daily working time period of the unit to which the service node belongs as a daily allowed time period for allowing inquiry of transaction information;

if the service node operation attribute data comprises the transaction type of the unit to which the service node belongs, determining the transaction type of the unit to which the service node belongs as the transaction type corresponding to the transaction information which allows inquiry;

The accounting node integrates the business node authority to which the transaction information allowed to be inquired belongs, the daily allowed time period of the transaction information allowed to be inquired and the transaction type corresponding to the transaction information allowed to be inquired into a contract template as authority data to form an intelligent contract of the business node and a blockchain operator;

the accounting node receives a query request of a service node for transaction information in a data block;

acquiring authority data of a service node from intelligent contracts of the service node and a blockchain operator;

if the service node has query authority to the transaction information according to the authority data of the service node, the transaction information is returned to the service node, otherwise, the hash value of the transaction information is returned to the service node.

2. The method of claim 1, wherein said obtaining the processing load of each of the billing nodes in the billing node subnetwork comprises:

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

3. The method of claim 1, wherein said obtaining the processing load of each of the billing nodes in the billing node subnetwork comprises:

Sending a processing load query request to each billing node;

and receiving the processing load sent by each accounting node.

4. The method of claim 1, wherein the determining an accounting node that services the query request based on the processing load and the distance comprises:

an accounting node is determined that services the query request based on the first score and the second score for each accounting node.

5. The method of claim 4, wherein the determining a first score for each billing node based on the processing load of each billing node in a billing node subnetwork comprises:

and searching a preset corresponding relation table of the processing load and the first score based on the processing load of each accounting node, and determining the first score of each accounting node.

6. The method of claim 4, wherein the determining a second score for each billing node based on the distance for each billing node in the billing node subnetwork comprises:

And searching a preset corresponding relation table of the distance and the second score based on the distance of each accounting node, and determining the second score of each accounting node.

7. The method of claim 4, wherein the determining the billing node that served the query request based on the first score and the second score for each billing node comprises:

based on the weighted sum, an accounting node is determined that services the query request.

8. The method of claim 7, wherein the determining an accounting node serving the query request based on the weighted sum comprises: and determining the accounting node with the largest weighted sum as the accounting node for serving the query request.

9. The method of claim 7, wherein the determining an accounting node serving the query request based on the weighted sum comprises: and optionally one of the billing nodes with a weighted sum greater than a predetermined weighted sum threshold is used as the billing node for servicing the query request.

10. A proxy node for determining an accounting node in a blockchain network, the blockchain network comprising an accounting node subnetwork comprised of a plurality of accounting nodes and a service node subnetwork comprised of a plurality of service nodes, the accounting nodes operable to record data blocks onto a blockchain, the service nodes operable to validate the data blocks recorded onto the blockchain by the accounting nodes, the accounting node subnetwork and the service node subnetwork having the proxy node therebetween, the proxy node comprising:

a distance determining unit, configured to send a positioning information request to each accounting node in the accounting node sub-network and a service node that sends a query request; receiving from each billing node and the service node sending the query request, location information of each billing node and the service node sending the query request; determining the distance between each billing node and the service node sending the query request by using the billing nodes and the positioning information of the service node sending the query request;

an accounting node determining unit, configured to determine an accounting node serving the query request based on the processing load and the distance, where the accounting node receives an intelligent contract generation request from a service node, where the intelligent contract generation request contains service node operation attribute data, where the service node operation attribute data includes at least one of a service node of a unit subordinate or jurisdiction to which the service node belongs, a daily operation period of a unit to which the service node belongs, and a transaction type of a unit to which the service node belongs; if the service node operation attribute data comprises the service node of the unit subordinate unit or the jurisdiction unit to which the service node belongs, determining the service node and the service node of the unit subordinate unit or the jurisdiction unit to which the service node belongs as the service node authority to which the transaction information allowed to be inquired belongs; if the service node operation attribute data comprises a daily working time period of a unit to which the service node belongs, determining the daily working time period of the unit to which the service node belongs as a daily allowed time period for allowing inquiry of transaction information; if the service node operation attribute data comprises the transaction type of the unit to which the service node belongs, determining the transaction type of the unit to which the service node belongs as the transaction type corresponding to the transaction information which allows inquiry; the accounting node integrates the business node authority to which the transaction information allowed to be inquired belongs, the daily allowed time period of the transaction information allowed to be inquired and the transaction type corresponding to the transaction information allowed to be inquired into a contract template as authority data to form an intelligent contract of the business node and a blockchain operator; the accounting node receives a query request of a service node for transaction information in a data block; acquiring authority data of a service node from intelligent contracts of the service node and a blockchain operator; if the service node has query authority to the transaction information according to the authority data of the service node, the transaction information is returned to the service node, otherwise, the hash value of the transaction information is returned to the service node.

11. A proxy node, comprising:

a memory storing computer readable instructions;

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

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