CN110460590B

CN110460590B - Data management method, device, medium and electronic equipment of block chain system

Info

Publication number: CN110460590B
Application number: CN201910678072.4A
Authority: CN
Inventors: 李茂材; 王宗友; 孔利; 周开班; 杨常青; 张劲松; 蓝虎; 时一防; 丁勇; 刘区城; 朱耿良; 陈秋平
Original assignee: Shenzhen Zhishuilian Technology Co ltd
Current assignee: Shenzhen Zhishuilian Technology Co ltd
Priority date: 2018-12-07
Filing date: 2018-12-07
Publication date: 2022-07-19
Anticipated expiration: 2038-12-07
Also published as: CN109379382A; CN109379382B; CN110460590A

Abstract

The embodiment of the application provides a data management method, a data management device, a data management medium and electronic equipment of a block chain system. The blockchain system comprises a sub-network of accounting nodes and a sub-network of service nodes, the sub-network of accounting nodes comprises accounting nodes for recording data blocks onto the blockchain, the sub-network of service nodes comprises service nodes for verifying the data blocks recorded onto the blockchain by the accounting nodes, the data management method is executed by the accounting nodes in the sub-network of accounting nodes, and the data management method comprises the following steps: after the data block is generated, the block head of the generated data block is sent to a designated service node in a service node sub-network; and issuing the block header to a service node sub-network through the designated service node so as to inform the service node sub-network of the information of the newly generated data block. According to the technical scheme of the embodiment of the application, the data in the accounting node sub-network can be conveniently sent to the service node sub-network on the premise of ensuring the data security.

Description

Data management method, device, medium and electronic equipment of block chain system

The present application is a divisional application entitled "data management method, apparatus, medium, and electronic device for a blockchain system" with application number 201811497483.5, filed on 07/12/2018.

Technical Field

The present application relates to the field of computer and communication technologies, and in particular, to a data management method, apparatus, medium, and electronic device for a block chain system.

Background

The block chain network is an end-to-end decentralized network formed by a plurality of nodes, each node is allowed to obtain a complete database copy, namely all information among the nodes is completely shared, and all the nodes jointly maintain the whole block chain based on a set of consensus mechanism.

In an application scenario of the blockchain system, data in the blockchain network may need to be sent to a service node outside the blockchain network, and in the application scenario, how to send the data in the blockchain network to the service node outside the blockchain network becomes an urgent technical problem to be solved.

Disclosure of Invention

Embodiments of the present application provide a data management method, an apparatus, a medium, and an electronic device for a block chain system, so that data in a billing node sub-network can be conveniently sent to a service node sub-network on the premise of ensuring data security at least to a certain extent.

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

According to an aspect of the embodiments of the present application, there is provided a data management method of a blockchain system, the blockchain system including an accounting node sub-network and a service node sub-network, the accounting node sub-network including an accounting node that records data blocks onto a blockchain, the service node sub-network including a service node that verifies the data blocks recorded onto the blockchain by the accounting node, the data management method being performed by the accounting node in the accounting node sub-network, the data management method including: after the data block is generated, sending a block head of the generated data block to a designated service node in the service node sub-network; and issuing the block header to the service node sub-network through the designated service node so as to inform the service node sub-network of the information of the newly generated data block.

According to an aspect of an embodiment of the present application, there is provided a data management apparatus of a blockchain system, the blockchain system comprising a billing node sub-network and a service node sub-network, the billing node sub-network comprising a billing node, the service node sub-network comprising a service node, the billing node comprising the data management apparatus, the data management apparatus comprising: a sending unit, configured to send a block header of a generated data block to a designated service node in the service node sub-network after the data block is generated; and the issuing unit is used for issuing the block header to the service node sub-network through the specified service node so as to inform the service node sub-network of the information of the newly generated data block.

In some embodiments of the present application, based on the foregoing solution, the issuing unit is configured to: broadcasting, by the designated service node, the blockhead to other service nodes in the service node subnetwork.

In some embodiments of the present application, based on the foregoing solution, the issuing unit is configured to: and taking the appointed service node as a sending node to send the block head to the service node closest to the sending node, and taking the service node receiving the block head as the sending node to continue sending until the service nodes in the service node sub-network all receive the block head.

In some embodiments of the present application, based on the foregoing solution, the issuing unit is configured to: determining distances between other service nodes in the service node sub-network except the sending node and the sending node; sending the block head to a service node closest to the sending node, wherein if the service node receiving the block head receives the block head before, a rejection message is fed back to the sending node; and if the rejection message is received, continuing to send the block head to other service nodes according to the sequence from near to far of the distance until an acceptance message is received.

In some embodiments of the present application, based on the foregoing solution, the issuing unit is configured to: receiving positioning information broadcast by other service nodes in the service node sub-network; and calculating the distance between each other service node and the sending node according to the positioning information broadcast by each other service node and the positioning information of the sending node.

In some embodiments of the present application, based on the foregoing solution, the issuing unit is configured to: periodically receiving positioning information broadcast by other service nodes in a service node sub-network; and calculating the distance between each other service node and the sending node according to the positioning information broadcast by each other service node which is received last time and the positioning information of the sending node.

In some embodiments of the present application, based on the foregoing solution, the data management apparatus of the blockchain system further includes: a determining unit, configured to send a request to a distribution progress recording server, so that the distribution progress recording server queries an identifier of a service node that does not receive the block header in a service node sub-network, where any service node sends a recording request to the distribution progress recording server after receiving the block header; receiving an identifier of a service node which is returned by the distribution progress recording server and does not receive the block header; and determining the service node closest to the sending node in the service nodes which do not receive the block head.

In some embodiments of the present application, based on the foregoing solution, the data management apparatus of the blockchain system further includes: the acquiring unit is used for acquiring the authority information of a target service node when receiving an acquiring request of the target service node in the service node sub-network for transaction data contained in a designated data block; and the processing unit is used for returning the transaction data which is contained in the specified data block and is authorized to be acquired by the target service node to the target service node according to the authority information of the target service node.

In some embodiments of the present application, based on the foregoing solution, the obtaining unit is configured to: acquiring authentication information of the target service node according to the identification information of the target service node contained in the acquisition request; and acquiring the authority information of the target service node based on the authentication information.

In some embodiments of the present application, based on the foregoing solution, the processing unit is further configured to: and returning the hash value of the transaction data which is contained in the appointed data block and is not acquired by the target service node to the target service node, so that the target service node calculates a Merck tree root according to the transaction data which is acquired by the target service node and the hash value of the transaction data which is not acquired by the target service node, and the acquired transaction data is verified.

In some embodiments of the present application, based on the foregoing scheme, the obtaining request includes address information of the target service node, where the address information includes identification information of the target service node, identification information of a higher node to which the target service node belongs, and signature information of the higher node; the processing unit is further to: determining a superior node to which the target service node belongs according to the address information contained in the acquisition request, and verifying the signature information contained in the acquisition request according to the superior node to which the target service node belongs; and if the signature information contained in the acquisition request passes the verification, inquiring and acquiring the transaction data which the target service node has the right to acquire from the data corresponding to the upper node to which the target service node belongs based on the authority information of the target service node.

In some embodiments of the present application, based on the foregoing scheme, the authority in the authority information includes one or more of the following: allowing the checked business nodes of the request uplink corresponding to the transaction data; the transaction type corresponding to the transaction data allowed to be viewed; and allowing the viewed uplink time corresponding to the transaction data.

According to an aspect of the embodiments of the present application, there is provided a computer readable medium, on which a computer program is stored, which when executed by a processor, implements the data management method of the blockchain system as described in the above embodiments.

According to an aspect of an embodiment of the present application, there is provided an electronic device including: one or more processors; a storage device for storing one or more programs which, when executed by the one or more processors, cause the one or more processors to implement the data management method of the blockchain system as described in the above embodiments.

In the technical solutions provided by some embodiments of the present application, by dividing the block chain system into an accounting node sub-network and a service node sub-network, the accounting node sub-network includes an accounting node that records a data block onto the block chain, and the service node sub-network includes a service node that verifies the data block recorded onto the block chain by the accounting node, so that the accounting process of the block chain system can be separated from the service processing process, and thus, not only can a full amount of data blocks be maintained through the accounting node sub-network and the security of the data blocks be ensured, but also flexible data access, such as data access with different permissions in a hierarchical level, can be realized through the service node sub-network. By sending the block head of the generated data block to the designated service node in the service node sub-network and distributing the block head to the service node sub-network through the designated service node, the information of the newly generated data block is notified to the service node sub-network, so that the service node in the service node sub-network can acquire the newly generated data block in the common node sub-network, and the problem that transaction data in the data block is leaked due to the fact that the whole data block is sent to the service node sub-network can be avoided.

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 application.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the application and, together with the description, serve to explain the principles of the application. It is obvious that the drawings in the following description are only some embodiments of the application, and that for a person skilled in the art, other drawings can be derived from them without inventive effort. In the drawings:

fig. 1 to 3 are schematic architectural diagrams of a blockchain system applied in the embodiment of the present application;

FIG. 4 schematically illustrates a flow chart of a method of data management for a blockchain system according to one embodiment of the present application;

FIG. 5 illustrates a process diagram of data chunk consensus according to an embodiment of the present application;

figure 6 schematically shows a flow chart for distributing a tile head of data tiles into a service node sub-network according to an embodiment of the application;

figure 7 schematically shows a flow chart for distributing a block head of data blocks into a service node sub-network according to an embodiment of the application;

figure 8 schematically illustrates a flow diagram for sending a block header to a traffic node closest to a sending node according to one embodiment of the present application;

FIG. 9 schematically shows a flowchart for generating a Merck tree root according to an embodiment of the application;

figure 10 shows an address structure diagram of a service node according to an embodiment of the application;

FIG. 11 schematically illustrates a flow chart of a method of data management for a blockchain system according to one embodiment of the present application;

FIG. 12 schematically illustrates a flow chart of a method of data management for a blockchain system according to one embodiment of the present application;

FIG. 13 schematically shows a block diagram of a data management device of a blockchain system according to one embodiment of the present application;

FIG. 14 schematically illustrates a block diagram of a data management device of a blockchain system according to one embodiment of the present application;

FIG. 15 illustrates a schematic structural diagram of a computer system suitable for use in implementing the electronic device of an embodiment of the present application.

Detailed Description

Example embodiments will now be described more fully with reference to the accompanying drawings. Example embodiments may, however, be embodied in many different forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the concept of example embodiments to those skilled in the art.

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

The block diagrams shown in the figures are functional entities only and do not necessarily correspond to physically separate entities. I.e. these functional entities may be implemented in the form of software, or in one or more hardware modules or integrated circuits, or in different networks and/or processor means and/or microcontroller means.

The flow charts shown in the drawings are merely illustrative and do not necessarily include all of the contents and operations/steps, nor do they necessarily have to be performed in the order described. For example, some operations/steps may be decomposed, and some operations/steps may be combined or partially combined, so that the actual execution sequence may be changed according to the actual situation.

Fig. 1 shows an architecture of a blockchain system applied in the embodiments of the present application. The blockchain system comprises a sub-network 2 of accounting nodes and a sub-network 1 of service nodes. Accounting node subnetwork 2 includes an accounting node 21 that recognizes and records data blocks onto a blockchain. Service node subnetwork 1 includes service node 11, and service node 11 may validate data blocks recorded by the accounting node onto the blockchain, or may request corresponding transaction data from the accounting node.

Specifically, the step of the service node 11 verifying the data blocks recorded by the accounting node to the block chain may include the following steps: an accounting node 21 in the sub-network of accounting nodes generates a signature based on transaction information to be included in a data block to be added to the blockchain using a key specific to the accounting node; the accounting node 21 adds the transaction information and the generated signature into the data block and adds the data block to a block chain; the accounting node 21 sends the signature to the service nodes in the service node sub-network, and the service nodes verify the signature according to the key specific to the accounting node, so that the service node 11 verifies the data blocks recorded by the accounting node to the block chain. The accounting nodes in the accounting node sub-network are responsible for recording data blocks to the block chain, and the service nodes in the service node sub-network are responsible for witnessing the results recorded by the accounting nodes. Specifically, the accounting node generates a signature based on transaction information to be included in a data block to be added to a block chain, and then adds the transaction information and the generated signature to the data block for uplink. The signature is sent to a service node in the service node subnetwork so that the service node performs signature verification on the signature according to a key specific to the accounting node. The service nodes in the service node sub-network can witness the transaction data of the whole network by verifying the accounting node signature on the block. Billing networks, while having monopoly billing rights, are publicly traceable in all activities because the data blocks have digital signatures representing the identity of the billers. If the accounting nodes collectively make a malignancy, then all nodes in the witness network will retain evidence that the particular accounting node made a malignancy. Compared with the traditional centralized system and the private chain, the system runs more transparently in the scheme; compared with the traditional decentralized common-chain scheme, the scheme is more controllable and more convenient to supervise.

In one embodiment of the application, billing node sub-network 2 and service node sub-network 1 may be connected via a proxy node 12, and proxy node 12 may be a service node of service node sub-network 1, which is responsible for passing information to be passed by billing node 21 to service node 11. The service node 11 is a terminal of a transaction party that generates various transaction data to be linked, and may also be a terminal that queries transaction data from the sub-network 2 of the accounting node. The transaction data generated by the service node 11 is transmitted to the accounting node 21 through the proxy node 12, and then is recorded on the blockchain after being identified, which is beneficial to the uniform processing and supervision of the transaction data, and the service node 11 can also perform the uplink supervision and witness of the transaction data through the information sent by the accounting node 21 through the proxy node 12, which has very important significance in some scenes that need uniform supervision but also afraid collective cheating of the supervised nodes and therefore need supervision.

In the configuration shown in fig. 1, service node subnetwork 1 adopts the P2P network mode. The P2P network is a distributed application architecture that distributes tasks and workloads among peers (peers), and is a form of networking or networking that the Peer-to-Peer computing model forms at the application layer, i.e., a "Peer-to-Peer" or "Peer-to-Peer" network. It can be defined as: participants of the network share a portion of the hardware resources (processing power, storage power, network connectivity, printers, etc.) they own, which provide services and content over the network and which can be accessed directly by other peer nodes without going through intermediate entities. Participants in this network are both providers and acquirers of resources, services and content. Therefore, in the service node subnetwork 1, when the proxy node 12 receives the message transmitted from the accounting node 21, the message is transmitted to the surrounding service nodes 11, and the surrounding service nodes 11 receive the message and transmit the message to the surrounding service nodes 11, so that the message is transmitted between each service node 11 of the service node subnetwork 1.

Fig. 2 shows an architecture of another blockchain system applied in the embodiment of the present application. This architecture differs from the architecture shown in fig. 1 in that: the P2P network mode is not adopted in the service node subnetwork 1, but the mode of the broadcast network is adopted. In particular, proxy node 12, upon receiving the message passed from accounting node 21, broadcasts the message to other service nodes 11 in service node subnetwork 1. In this way, the propagation of the message between each service node 11 of the service node sub-network 1 is also achieved.

Fig. 3 shows an architecture of another block chain system applied in the embodiment of the present application. This architecture differs from that shown in fig. 1 in that: its billing node sub-network 2 is divided into a plurality of branch billing node sub-networks. Each branch accounting node sub-network may be responsible for the recording of some type of transaction information. For example, a business may have a supply chain financial transaction and may need to record contract information, credit, etc. generated during supply and marketing to the blockchain, and the business may need to issue invoices and also record invoicing information, invoice reimbursement information, etc. to the blockchain. In this case, in order to facilitate the requirement that the accounting node is supervised by the same department, the accounting node for recording the supply chain financial service transaction and the accounting node for recording the transaction in the invoice circulation process may belong to different departments. For example, the accounting node for recording the supply chain financial service transaction is an accounting terminal set by a bank, and the accounting node for recording the transaction in the invoice circulation process is an accounting terminal set by a national tax bureau. And supply chain financial transaction and recording of transactions in the invoicing process may also end up being recorded on a different branching sub-network of accounting nodes. In this case, the agent node 12 transmits the transaction information to the branch accounting node sub-network corresponding to the transaction type, based on the transaction type carried in the transaction information transmitted from the service node 11.

It should be noted that, in the architecture of the blockchain system shown in fig. 1 to 3, the proxy node 12 is located in the service node sub-network 1, and in other embodiments of the present application, the proxy node 12 may also be located in the common node sub-network 2, or may be independent of the service node sub-network 1 and the common node sub-network 2.

The architecture of the blockchain system shown in fig. 1 to 3 can be applied to the application scenario of electronic invoices, and is described in detail as follows:

in an embodiment of the application, the accounting nodes in the sub-network of accounting nodes may be individual tax administration terminals, e.g. the sub-network of accounting nodes is formed by tax administration terminals deployed in multiple areas as one accounting node each. Each service node in a service node sub-network may be a local tax office terminal, an invoicing agent facilitator terminal, an invoicing enterprise terminal, a personal user terminal, etc.

After the accounting node in the accounting node sub-network generates the data block (the data block may contain the invoice information issued, etc.), the block head of the generated data block may be distributed to the service node sub-network to notify the service node sub-network of the information of the newly generated data block, and meanwhile, the problem that the data in the data block is illegally stolen by a role without access authority (for example, an individual user cannot view the invoice information irrelevant to the individual user) due to directly sending the data block to the service node sub-network may be avoided. After receiving the block header of the data block, the service node in the service node sub-network may know the newly generated data block in the accounting node sub-network, and may further request the accounting node sub-network to obtain the transaction data included in the specified data block (for example, send a request for obtaining the transaction data to the accounting node sub-network through the proxy node). After receiving the acquisition request of the transaction data contained in the designated data block, the accounting node in the accounting node sub-network may acquire the authority information of the service node that sent the acquisition request, and then return the transaction data that the service node contained in the designated data block is authorized to acquire to the service node according to the authority information. For example, the provincial tax office can access the invoice information related to the province, the municipal tax office can only access the invoice information related to the city, the regional tax office can only access the invoice information related to the region, and the billing agent service provider can only access the invoice information related to the enterprise of the agent.

The details of the implementation of the data management scheme of the blockchain system according to the embodiment of the present application are described in detail as follows:

fig. 4 schematically shows a flow chart of a data management method of a blockchain system according to an embodiment of the present application, as shown in fig. 1 to 3, the blockchain system comprising a billing node sub-network 2 and a service node sub-network 1, the billing node sub-network 2 comprising a billing node 21 and the service node sub-network 1 comprising a service node 11. The data management method of the blockchain system shown in fig. 4 may be performed by accounting node 21 in accounting node sub-network 2 and the steps shown in fig. 4 may be performed entirely by any one of the accounting nodes in accounting node sub-network 2 or may be performed by a plurality of accounting nodes each performing only a part of the steps. Referring to fig. 4, the data management method of the blockchain system at least includes steps S410 to S430, which are described in detail as follows:

in step S410, after the data block is generated, the block head of the generated data block is distributed to the service node sub-network to notify the service node sub-network of information of the newly generated data block.

In one embodiment of the present application, the data block may be generated by packaging the data of the to-be-uplink transaction (such as billing data, invoice flow data, etc.) sent by the service node in the service node sub-network. For example, the transaction data may be buffered after being received, and the buffered transaction data may be packed to generate a data block when at least one of the following packing requirements is met:

the total size of the transaction data to be linked in the cache reaches a preset size threshold;

the total number of the transaction data to be linked in the cache reaches a preset number threshold;

the cache time of the earliest cached to-be-uplink transaction data in the cache reaches a preset time threshold from the current time.

In an embodiment of the present application, in a case that the block packing requirement is that the total size of the to-be-uplink transaction data in the cache exceeds a predetermined size threshold, for example, the predetermined size threshold is 4Mb, and there are 2 transaction data originally in the cache, which are 0.8Mb and 1.5Mb respectively, and if a to-be-uplink transaction data is received at this time, the size is 2Mb, so that 0.8Mb +1.5Mb +2Mb is 4.3Mb >4Mb, a data block can be generated for the 3 transaction data, thereby avoiding resource waste of generating a data block for each transaction data.

In an embodiment of the present application, in a case that the block packing requirement is that the total number of the to-be-uplink transaction data in the cache exceeds a predetermined number threshold, for example, the predetermined number threshold is 5, 4 transaction data originally exist in the cache, and if a to-be-uplink transaction data is received at this time, a data block can be generated for the 5 transaction data, so as to avoid resource waste of generating a data block for each transaction data.

In an embodiment of the present application, in a case that the block packing requirement is that a buffer time of an earliest buffered piece of to-be-uplink transaction data in the buffer reaches a predetermined time threshold, for example, the predetermined time threshold is 24 hours, if the to-be-uplink transaction data is placed in the buffer in 2018, 4, 25, 11, 27, 01, a data block can be generated for the to-be-uplink transaction data in 4, 26, 11, 27, 01, so as to avoid an excessive delay from requesting uplink to actually uplink.

In practice, one or more of the above may be used in combination. For example, if the total size of the to-be-uplink-transaction data in the cache reaches a predetermined size threshold, or the cache time of the earliest cached uplink-transaction data in the to-be-uplink-transaction data in the cache reaches a predetermined time threshold from the current time, a data block may be generated. Therefore, resource waste caused by generating a data block for transaction data is avoided, and unlimited waiting caused by insufficient transaction data received in a period of time is avoided.

In one embodiment of the application, after the data block is generated, the generated data block may be issued to a sub-network of accounting nodes for consensus by each accounting node, and after the consensus is successful, the data block is added to the block chain.

Specifically, in one embodiment of the present application, fig. 5 shows a process for the leader accounting node to broadcast the data block to other accounting nodes in the accounting node sub-network for consensus in the embodiment of the present application. Wherein, the client (which may be a billing node forming a data block to be recorded on the block chain) initiates a consensus request and sends the consensus request to a leader billing node a in a leader state; continuing to enter the entity adding stage, the leading accounting node A broadcasts the data block corresponding to the consensus request to other accounting nodes (accounting node B, C, D …) which are not in a leading state in the accounting node sub-network; and continuing to enter an additional response stage, broadcasting the received consensus content to other accounting nodes by other accounting nodes, and entering a confirmation stage when the consensus contents broadcast by the other accounting nodes with the preset number (2f +1) are consistent, wherein each accounting node feeds back a confirmation result to the leader accounting node A. And when the leader accounting node A receives that the feedback confirmation of the preset number (2f +1) of other block chain nodes passes, judging that the consensus is completed and feeding back the consensus completion result to the client. Where f is the largest integer less than (N-1)/3 and N is the number of accounting nodes in the accounting node subnetwork. f is the number of bad accounting nodes in the sub-network of accounting nodes that the algorithm can tolerate.

When the consensus is successful, each accounting node in the accounting node sub-network can add the data block to the block chain, i.e. the uplink is completed.

In one embodiment of the present application, the block header of the data block does not contain specific transaction data, so that after the block header of the data block is distributed to the sub-network of service nodes, the service nodes in the sub-network of service nodes only know that the data block is newly generated in the sub-network of accounting nodes, and do not obtain the specific transaction data in the data block.

In an embodiment of the present application, as shown in fig. 6, the process of distributing the block head of the generated data block into the service node sub-network in step S410 includes:

step S610, sending the block header to a designated service node in the service node sub-network.

Step S620, broadcasting the block header to other service nodes in the service node sub-network through the designated service node.

This embodiment is directed to the architecture of the block chain system shown in fig. 2. In the architecture, one service node in the service node sub-network can be used as a proxy node, and then the block header of the data block is sent to all the service nodes in the service node sub-network in a broadcasting manner. A benefit of this embodiment is that the block header can be quickly communicated to all service nodes in the service node sub-network.

The service node sub-network may use a communication method of broadcast message shown in fig. 2, and may also use a network communication method of P2P shown in fig. 1 and fig. 3. In the service node sub-network of P2P, the proxy node may send the chunk header to its surrounding service nodes, and the service node that receives the chunk header sends the chunk header to other service nodes surrounding the service node until all service nodes of the service node sub-network receive the chunk header.

In an embodiment of P2P networking, as shown in fig. 7, the process of distributing the block header to a service node sub-network includes:

step S710, sending the block header to a designated service node in the service node sub-network.

Step S720, the appointed service node is taken as a sending node to send the block head to the service node nearest to the sending node, and the service node receiving the block head is taken as the sending node to continue sending until the service nodes in the service node sub-network all receive the block head.

In step S720, since it does not make sense that the service node having received the block header repeatedly receives the same block header, when each service node determines the next service node to transmit the block header, it is considered to be transmitted to the service node that has not received the block header, in addition to the service node that is preferentially transmitted to the service node that is close thereto (to reduce the transmission latency). Thus, each service node only needs to send the block header to one service node, which is the nearest service node among other service nodes that do not receive the block header. Therefore, the safe issuing of the block head node by node is completed, the issuing burden is prevented from being concentrated on one service node, and the load balance is realized.

In an embodiment of the present application, as shown in fig. 8, the sending the block header to the service node closest to the sending node in step S720 may include the following steps:

step S810, determining distances between other service nodes in the service node sub-network except the sending node and the sending node.

Step S820, sending the block header to the service node closest to the sending node, wherein if the service node receiving the block header has received the block header before, a rejection message is fed back to the sending node.

Step S830, if the rejection message is received, the block header is continuously sent to other service nodes according to the sequence from near to far of the distance until an acceptance message is received.

In one embodiment of the present application, in step S810, determining distances between service nodes other than the sending node in the service node subnetwork and the sending node may include: the positioning information broadcast from other service nodes in the service node sub-network is received periodically (e.g., every 5 seconds), and the distance between each other service node and the sending node is calculated according to the most recently received positioning information broadcast by each other service node and the positioning information of the sending node.

In one embodiment of the present application, the positioning information is location information of the service node obtained by each service node from its own positioning system (e.g., GPS system installed on the node). The service node obtains its own location information from its installed location system and then broadcasts periodically (e.g., every 5 seconds) to other service nodes in the service node subnetwork. The sending node may also obtain its own positioning information from its own positioning system. Because the broadcasting and updating of the positioning information are periodic and the period is short, the positioning information broadcast by each other service node which is received by the sending node for the last time can be regarded as the current positioning information of each other service node, and thus, the distance between each other service node and the sending node can be calculated according to the positioning information broadcast by each other service node which is received for the last time and the positioning information of the sending node.

From the above calculated distances, the other service node with the smallest distance to the sending node among all other service nodes can be found, but the other service node may have received the block header. Thus, embodiments of the present application avoid re-transmitting a block header to a service node by having other service nodes that receive the block header send an accept message or a reject message. Wherein, the acceptance message or the rejection message is distinguished by that a certain specific identification field is set to different characters or character strings to represent the acceptance message or the rejection message. Thus, it is possible to identify whether a received message is an accept message or a reject message by identifying the particular identification field in the received message. If the message is an accept message, it indicates that the service node that received the block header has not previously received the block header and thus accepted the block header. If the reject message is the one, it indicates that the service node that received the block header has previously received the block header, and thus rejects the block header. If the reject message is received, other service nodes which are the second smallest away from the sending node are found, the block head is sent to the service nodes to judge whether the other service nodes feed back the reject message or the accept message, if the other service nodes still feed back the reject message, other service nodes which are the third smallest away from the sending node are found, the block head is sent to the service nodes, and the other service nodes feed back the reject message or the accept message are judged. That is, if a reject message is received, the block header continues to be transmitted to other service nodes in order of close to far distance from the transmitting node until an accept message is received.

Another embodiment of finding the service node closest to the sending node among the other service nodes that have not received the block header is to maintain a distribution progress record server. And each time when another service node receives the block head, sending a recording request to a distribution progress recording server, wherein the recording request contains the identification of the service node and the identification of the block head (such as the root of the Mercker tree), and the distribution progress recording server correspondingly stores the identification of the service node and the identification of the block head. When the sending node needs to determine that the service node closest to the sending node in other service nodes of the block header is not received, a request is sent to the distribution progress recording server, the distribution progress recording server inquires the identification of the service node which does not receive the block header in the service node sub-network (the service node identification which is stored corresponding to the identification of the block header is removed from the identification list of all the service nodes), and the service node is sent to the sending node. The sending node determines the service node with the minimum distance from the sending node among the service nodes which do not receive the block head. In contrast, by sending the block header to the other service nodes closest to the service node, the other service nodes receiving the block header are allowed to send the acceptance message or the rejection message according to whether the other service nodes receive the block header before, and one server is omitted, so that network resources are saved, and network congestion is avoided.

Continuing to refer to fig. 4, in step S420, if an acquisition request of a target service node in the service node sub-network for transaction data included in a designated data block is received, authority information of the target service node is acquired.

In the embodiment of the present application, the authority information of the service node refers to information indicating which transaction data in the data block the service node has the right to obtain and which transaction data the service node does not have the right to obtain. In one embodiment of the present application, the rights in the rights information include one or more of the following:

allowing the checked business nodes of the request uplink corresponding to the transaction data;

the transaction type corresponding to the transaction data allowed to be viewed;

and allowing the viewed uplink time corresponding to the transaction data.

The business node requesting uplink corresponding to the business data allowed to be checked refers to permission of checking which business nodes requesting uplink business data. In one embodiment of the present application, it may be specified that a service node can only view transaction data requested to be linked up by itself. If there is a service node a, it may be that the requested uplink service node corresponding to the transaction data allowed to be viewed in the permission message is the service node a itself, so that only the data block requested to be uplink by the service node a itself can be viewed by the service node a. In another embodiment, it may be provided that a service node may view the transaction data requested to be uplink by its own and all its subordinate service nodes. For example, there is a service node a, and the service nodes of its subordinate units have a1-a7, so that the service nodes requesting uplink corresponding to the transaction information that the service node a allows to view are the service node a and the service nodes a1-a7, and further the data blocks requested uplink by any one of the service node a and the service nodes a1-a7 can be viewed by the service node a.

The transaction type corresponding to the transaction data which is allowed to be viewed refers to the permission of the transaction data of which transaction types are allowed to be viewed. The transaction data in the data block carries the transaction type. The transaction type can be, for example, an invoice transaction, a supply chain financial transaction, a fiat digital currency transaction, and the like. In an invoice transaction, a business node of a local tax authority is allowed to view all of the transaction data about the invoice within its jurisdiction, and thus may return all of the transaction data about the invoice in the data block to it, with only hash values being returned for other types of transaction data in the data block. In supply chain financial transactions, a business node of a possible bank is allowed to view all transaction data about supply chain finance within its jurisdiction, so that transaction data about supply chain finance in a data block can be returned to it all the way, and only hash values are returned to it for other types of transaction data in the data block. In a fiat digital currency transaction, a service node of an issuing authority of a possible fiat digital currency is allowed to view all transaction data related to the flow of the fiat digital currency within its jurisdiction, and thus can return transaction data related to the fiat digital currency in a data block to all of it, and only return a hash value to it for other types of transaction data in the data block.

The uplink time corresponding to the transaction data allowed to be viewed refers to the permission of viewing the transaction data uplink in which time period. For example, it may be provided that the service node a can only view the transaction data that was uplink within the last year.

Several of the above rights may also be used in combination. For example, the requested uplink service node corresponding to the transaction data allowed to be viewed and the corresponding uplink time allowed to be viewed can be used in combination. Assuming that there is a service node A, the service nodes of its subordinate units have A1-A7, the authority data of which may specify: service node a may obtain transaction data for service node a, service node a1-a7, that was uplinked within the last year.

In an embodiment of the present application, the authentication information of the target service node may be obtained according to the identification information of the target service node included in the acquisition request sent by the target service node, and then the authority information of the target service node may be obtained based on the authentication information. The authentication information of the service node may be information obtained by the service node through registration in advance, for example, the service node may send a registration request to the sub-network of the accounting node, and then the sub-network of the accounting node may obtain a network access contract corresponding to the service node, where the network access contract includes the authentication information and the permission information of the service node, and further add the network access contract to the data block and to the block chain. Because all contents in the data block on the block chain are completely visible to the accounting node, after receiving a request of the service node for the transaction data in the data block, the accounting node can find the network access contract stored corresponding to the identification information of the service node in the block chain according to the identification information of the requested service node, and further read the authority information from the network access contract.

With reference to fig. 4, in step S430, according to the authority information of the target service node, the transaction data that the target service node contained in the specified data block is authorized to obtain is returned to the target service node.

In the embodiment of the application, after the data block is generated, the accounting node only sends the block head to each service node of the service node sub-network, and each service node cannot acquire each transaction data in the block body in the data block, so that the transaction data is hidden. When the service node wants to acquire the transaction data in the data block, an acquisition request for the transaction data in the data block needs to be sent to the accounting node, the accounting node only sends the transaction data (such as the transaction data related to the service node or the transaction data related to subordinate units) which the service node has the right to view to the accounting node, and the transaction data (such as the transaction data related to other service nodes) which is not allowed to view is prohibited from being viewed, so that the service node can know the transaction data related to the service node, and the problem that the transaction data related to other service nodes are leaked can be avoided.

In an embodiment of the present application, a hash value of the transaction data that the target service node is not authorized to obtain, which is included in the specified data block, may also be returned to the target service node, so that the target service node calculates a root of the merck tree according to the hash values of the transaction data that the target service node is authorized to obtain and the transaction data that the target service node is not authorized to obtain, so as to verify the obtained transaction data.

In an embodiment of the present application, as shown in fig. 9, the process of generating the root of the merck tree according to the transaction data contained in one data block may specifically include the following steps:

step S910, calculating a hash value of each transaction data in the data block;

step S920, sorting the transaction data in the data block (for example, sorting the transaction data according to the sequence of entering the buffer memory), wherein the transaction data sequentially arranged in the odd-numbered position and the transaction data sequentially arranged in the even-numbered position form a pair;

step S930, performing hash operation on the hash values of the two transaction data of each pair to obtain a hash value of the pair;

step S940, the pairs are sorted (for example, sorted according to the sequence of entering the pairs into the cache), the pair sequentially arranged at the odd-numbered position and the pair sequentially arranged at the even-numbered position form a pair at the upper level, and hash values of two pairs in each pair at the upper level are subjected to hash operation to obtain hash values of the pair at the upper level until a hash value of the pair at the upper level is obtained, that is, the root of the merck tree.

It should be noted that, in another embodiment of the present application, if the transaction information sequentially arranged in the odd-numbered position is the last transaction information in the cache, the transaction information is copied, and the last transaction information and the copied transaction information form a pair; if the pair sequentially arranged in the odd number is the last pair in the cache, the pair is copied, the last pair and the copied pair form a pair at a higher level, and the Merck tree obtained in this way is a binary tree. For example, there are 9 transaction data in the data block, which are A1-A9 in the time order of entering the buffer. A1-A2 form a pair B1, and hash operation is carried out on the hash value of A1 and the hash value of A2 to obtain a hash value of B1; A3-A4 form a pair B2, and hash operation is carried out on the hash value of A3 and the hash value of A4 to obtain a hash value of B2; A5-A6 form a pair B3, and hash operation is carried out on the hash value of A5 and the hash value of A6 to obtain a hash value of B3; A7-A8 form a pair B4, and hash operation is carried out on the hash value of A7 and the hash value of A8 to obtain a hash value of B4; copy a copy of a9 to obtain a10, and perform hash operation on the hash value of a9 and the hash value of a10 to obtain a hash value of B5.

For B1-B5, B1-B2 form a pair C1 at the upper layer, and hash operation is carried out on the hash value of B1 and the hash value of B2 to obtain a hash value of C1; B3-B4 form a pair C2 at the upper layer, and hash operation is carried out on the hash value of B3 and the hash value of B4 to obtain a hash value of C2; copy B5 to obtain B6, and perform hash operation on the hash value of B5 and the hash value of B6 to obtain a hash value of C3.

For C1-C3, C1-C2 form a pair D1 at the upper layer, and hash operation is carried out on the hash value of C1 and the hash value of C2 to obtain the hash value of D1; copy C3 to get C4, and perform hash operation on the hash value of C3 and the hash value of C4 to get the hash value of D2.

For D1-D2, the hash value of D1 and the hash value of D2 are subjected to hash operation to obtain the root of the Merck tree.

As can be seen from the above calculation of the mercker tree root, if some transaction data in the data block is not known, but the hash value of the transaction data is specified, the mercker tree root can also be calculated. After the Merck tree root calculated by the service node, the Merck tree root can be compared with the Merck tree root contained in the block header of the data block returned by the accounting node, and content verification can be further performed. If the two Mercker tree roots are consistent, the fact that the transaction data returned by the accounting node are not tampered is shown; if the two Mercker tree roots are not consistent, the fact that a part of transaction data returned by the accounting node is possibly tampered is shown, the service node can verify the acquired transaction data through the method, and the service node is ensured to acquire accurate and legal transaction data.

In one embodiment of the present application, there may be a hierarchical relationship between the various service nodes in the service node sub-network. For example, the lower level of the tax administration includes each provincial tax administration; the lower level of the provincial tax bureau comprises various city tax bureaus; the lower level of the municipal tax bureau comprises various district tax bureaus; the lower level of the district tax bureau comprises enterprises, individuals, billing agent service providers and the like; the lower level of the billing agent service provider includes the business or individual, etc. of its agent. Due to the hierarchical relationship, the accessible information of the service nodes of different levels is different, for example, the tax administration can inquire the whole electronic invoice information, the province tax administration can check the electronic invoice information of the province, the city tax administration can check the electronic invoice information of the city, an individual or an enterprise can only check the electronic invoice information related to the individual or the enterprise, and the invoicing agent service provider can check the electronic invoice information of the enterprise or the individual, which the enterprise or the enterprise acts as the agent.

In the related art, due to the existence of the above hierarchical relationship, the upper level service node needs to maintain a relationship with the lower level service node. For example, the billing agent service provider needs to maintain information about businesses or individuals that the billing agent service provider is acting on, and assuming that the number of billing agent service providers is n and the number of businesses or individuals that each billing agent service provider maintains is m, a relation table of m × n size is generated, and the data size of the relation table is doubled as n and m increase. In order to solve the problem, the embodiment of the present application proposes a technical solution of improving an address structure of a service node, that is, adding identification information of an upper node to which the service node belongs and signature information of the upper node to address information of the service node, specifically as shown in fig. 10, where the address information of the service node includes a parent number, a public key hash of the service node, and a parent signature. Wherein, the parent number represents the identification information of the superior node to which the service node belongs; the hash of the public key of the self public key represents the identification information of the service node; the parent signature represents signature information of a superior node to which the service node belongs, and the signature information is used for verifying the identity of the service node.

Based on the above address structure, in an embodiment of the present application, the target service node may add address information to an acquisition request for transaction data included in a specified data block, and then after receiving the acquisition request, the accounting node may determine, according to the address information included in the acquisition request, an upper node to which the target service node belongs, and verify, according to the upper node to which the target service node belongs, signature information included in the acquisition request, and if the signature information included in the acquisition request is verified, query and acquire, based on authority information of the target service node, transaction data that the target service node has the right to acquire, from data corresponding to the upper node to which the target service node belongs. Therefore, in the embodiment of the application, by improving the address structure of the service node, the relationship table between the superior node and the subordinate node does not need to be maintained, and the storage cost of the relationship table can be reduced.

Fig. 11 schematically shows a flow chart of a data management method of a blockchain system according to an embodiment of the present application, as shown in fig. 1 to 3, the blockchain system comprising a billing node sub-network 2 and a service node sub-network 1, the billing node sub-network 2 comprising a billing node 21 and the service node sub-network 1 comprising a service node 11. The data management method of the blockchain system shown in fig. 11 may be performed by the service node 11 in the service node sub-network 1. Referring to fig. 11, the data management method of the blockchain system at least includes steps S1110 to S1130, which are described in detail as follows:

in step S1110, the acquiring accounting node sub-network issues to the block header in the service node sub-network.

The process of generating the data blocks by the sub-network of the accounting node and the process of distributing the data blocks to the sub-network of the service node are already described in detail in the above embodiments, and are not described again.

In step S1120, a request for acquisition of transaction data contained in the specified data block is sent to a target accounting node in the accounting node sub-network according to the block header issued by the accounting node sub-network.

In one embodiment of the application, after receiving the block header issued by the billing node sub-network, the service node may determine from the block header that a new data block was generated in the billing node sub-network, and may send a request to the target billing node for acquisition of the transaction data contained in the specified data block. The target accounting node may be any accounting node in the accounting node sub-network, or may be an accounting node closest to the service node sending the acquisition request in the accounting node sub-network, or may be an accounting node corresponding to the service node sending the acquisition request.

In step S1130, the transaction data that the target service node has the right to acquire in the designated data block returned by the target accounting node according to the acquisition request is received.

After receiving the acquisition request sent by the service node, the accounting node may acquire the authority information of the service node, and further acquire the transaction data that the service node is authorized to acquire according to the authority information, which has been explained in the above embodiments, and thus, the process is not described again.

In an embodiment of the application, after receiving the transaction data which is contained in the designated data block and authorized to be acquired by the service node, the service node may further receive a hash value of the transaction data which is contained in the designated data block and unauthorized to be acquired, which is returned by the target accounting node, then calculate the mercker tree root according to the hash values of the transaction data which is authorized to be acquired and the transaction data which is unauthorized to be acquired, and further compare the calculated mercker tree root with the mercker tree root contained in the block header of the designated data block to verify the received transaction data. The process of generating the root of the mercker tree has been described in the above embodiments, and is not described herein again.

In an embodiment of the present application, since there may be a hierarchical relationship between service nodes, an upper service node may also respond to a transaction data acquisition request sent by a lower service node, specifically as shown in fig. 12, including the following steps:

step S1210, if an acquisition request for the transaction data in the target data block, which is sent by another service node that has a hierarchical relationship with the target service node and is located at a next hierarchy of the target service node, is received, it is determined that the other service node has the right to acquire the transaction data.

In an embodiment of the present application, a process of determining, by a target service node, that a service node has the right to acquire transaction data is similar to a process of determining, by an accounting node, that a service node has the right to acquire transaction data in the foregoing embodiment, that is, the target service node may determine, according to an acquisition request sent by another service node, authority information of the other service node, and further determine, according to the authority information, that the other service node has the right to acquire transaction data. In addition, other service nodes may also adopt the address structure proposed in the above embodiment of the present application, so that the target service node may query the transaction data that the other service node is authorized to acquire.

Step S1220, sending the transaction data that the other service node included in the target data block is authorized to obtain to the other service node.

In an embodiment of the present application, after the transaction data that is contained in the target data block and that is authorized to be acquired by another service node is sent to another service node, the hash value of the transaction data that is contained in the target data block and that is not authorized to be acquired by another service node may also be returned to the another service node, so that the another service node calculates the root of the merck tree according to the transaction data that is authorized to be acquired by the another service node and the hash value of the transaction data that is not authorized to be acquired by the another service node, so as to verify the acquired transaction data. Specifically, the calculated mercker tree root may be compared with the mercker tree root included in the block header of the target data block to verify the received transaction data. The process of generating the root of the mercker tree has been described in the above embodiments, and is not described herein again.

The technical solutions of the embodiments of the present application have been described in detail from the perspective of an accounting node in an accounting node sub-network and the perspective of a service node in a service node sub-network, respectively, and the technical solutions of the embodiments of the present application enable the accounting process and the service processing process of a block chain system to be separated by dividing the block chain system into the accounting node sub-network and the service node sub-network, so that not only can a full amount of data blocks be maintained through the accounting node sub-network, and the security of the data blocks be ensured, but also flexible data access, such as hierarchical data access with different rights, can be realized through the service node sub-network. The block head of the generated data block is distributed to the service node sub-network by the accounting node to inform the service node sub-network of the information of the newly generated data block, so that the service node in the service node sub-network can know the newly generated data block in the common node sub-network, and the problem that transaction data in the data block is leaked due to the fact that the whole data block is completely transmitted to the service node sub-network can be avoided. In addition, when receiving a request for acquiring the transaction data contained in the designated data block from the target service node, the accounting node returns the transaction data which is contained in the designated data block and is authorized to be acquired by the target service node to the target service node according to the authority information of the target service node, so that the authority of each service node can be controlled, and a more flexible data access mode is realized. The service nodes in the service node sub-network may directly send transaction data acquisition requests to the accounting nodes in the accounting node sub-network, or may send transaction data acquisition requests to the upper nodes (including direct upper nodes and indirect upper nodes) in the service node sub-network.

The following describes embodiments of an apparatus of the present application, which can be used to implement the data management method of the blockchain system in the above embodiments of the present application. For details that are not disclosed in the embodiments of the apparatus of the present application, please refer to the embodiments of the data management method of the blockchain system described above in the present application.

Fig. 13 schematically shows a block diagram of a data management device of a blockchain system according to an embodiment of the present application. As shown in fig. 1 to 3, the blockchain system comprises a billing node sub-network 2 and a service node sub-network 1, the billing node sub-network 2 comprising a billing node 21 and the service node sub-network 1 comprising a service node 11. Wherein accounting node 21 in accounting node subnetwork 2 may comprise data management apparatus 1300 of the blockchain system shown in fig. 13.

Referring to fig. 13, a data management apparatus 1300 of a blockchain system according to an embodiment of the present application includes: an issuing unit 1302, an obtaining unit 1304 and a processing unit 1306.

The publishing unit 1302 is configured to, after generating a data block, publish the block head of the generated data block to the service node sub-network to notify the service node sub-network of information of the newly generated data block; the obtaining unit 1304 is configured to obtain permission information of a target service node when receiving a request for obtaining transaction data included in a designated data block from the target service node in the service node sub-network; the processing unit 1306 is configured to return, to the target service node, the transaction data that is included in the specified data block and that the target service node is authorized to obtain, according to the authority information of the target service node.

In one embodiment of the present application, the publishing unit 1302 is configured to: sending the block header to a designated service node in the service node sub-network; broadcasting, by the designated service node, the block header to other service nodes in the service node subnetwork.

In one embodiment of the present application, the publishing unit 1302 is configured to: sending the block header to a designated service node in the service node sub-network; and taking the appointed service node as a sending node to send the block head to the service node closest to the sending node, and taking the service node receiving the block head as the sending node to continue sending until the service nodes in the service node sub-network all receive the block head.

In one embodiment of the present application, the publishing unit 1302 is configured to: determining distances between other service nodes in the service node sub-network except the sending node and the sending node; sending the block head to a service node closest to the sending node, wherein if the service node receiving the block head has received the block head before, a rejection message is fed back to the sending node; and if the rejection message is received, continuing to send the block head to other service nodes according to the sequence from near to far of the distance until an acceptance message is received.

In an embodiment of the present application, the obtaining unit 1304 is configured to: acquiring the authentication information of the target service node according to the identification information of the target service node contained in the acquisition request; and acquiring the authority information of the target service node based on the authentication information.

In one embodiment of the present application, the processing unit 1306 is further configured to: and returning the hash value of the transaction data which is contained in the appointed data block and is not acquired by the target service node to the target service node, so that the target service node calculates a Merck tree root according to the transaction data which is acquired by the target service node and the hash value of the transaction data which is not acquired by the target service node, and the acquired transaction data is verified.

In an embodiment of the present application, the acquisition request includes address information of the target service node, where the address information includes identification information of the target service node, identification information of a higher node to which the target service node belongs, and signature information of the higher node; the processing unit 1306 is further configured to: determining a superior node to which the target service node belongs according to the address information contained in the acquisition request, and verifying the signature information contained in the acquisition request according to the superior node to which the target service node belongs; and if the signature information contained in the acquisition request passes the verification, inquiring and acquiring the transaction data which the target service node has the right to acquire from the data corresponding to the upper node to which the target service node belongs based on the authority information of the target service node.

Fig. 14 schematically shows a block diagram of a data management device of a blockchain system according to an embodiment of the present application. As shown in fig. 1 to 3, the blockchain system comprises a billing node sub-network 2 and a service node sub-network 1, the billing node sub-network 2 comprising a billing node 21 and the service node sub-network 1 comprising a service node 11. The service node 11 in the service node sub-network 1 may include the data management apparatus 1400 of the blockchain system shown in fig. 14.

Referring to fig. 14, a data management apparatus 1400 of a blockchain system according to an embodiment of the present application includes: an acquisition unit 1402, a transmission unit 1404, and a reception unit 1406.

The obtaining unit 1402 is configured to obtain a block header issued by the sub-network of accounting nodes to the sub-network of service nodes; the sending unit 1404 is configured to send, to a target accounting node in the accounting node sub-network, an acquisition request for transaction data included in a specified data block according to the block header issued by the accounting node sub-network; the receiving unit 1406 is configured to receive the transaction data that the target service node has the right to acquire in the designated data block returned by the target accounting node according to the acquisition request.

In an embodiment of the present application, the data management apparatus 1400 of the blockchain system further includes: a processing unit; the receiving unit is further configured to receive a hash value of transaction data returned by the target accounting node and not authorized to be obtained by the target service node in the designated data block; the processing unit is configured to: and calculating a Merck root according to the hash values of the transaction data which are acquired with the right and the transaction data which are not acquired with the right, and comparing the calculated Merck root with the Merck root contained in the block head of the specified data block so as to verify the received transaction data.

In an embodiment of the present application, the data management apparatus 1400 of the blockchain system further includes: the determining unit is used for determining transaction data which other service nodes have right to acquire when receiving an acquisition request of the transaction data in a target data block, wherein the acquisition request is sent by other service nodes which have a hierarchical relationship with the target service node and are positioned at the next hierarchy of the target service node; the sending unit 1404 is further configured to send the transaction data that the other service node included in the target data block has the right to obtain to the other service node.

In one embodiment of the present application, the sending unit 1404 is further configured to: and returning the hash value of the transaction data which is contained in the target data block and is not acquired by the other service nodes to the other service nodes so that the other service nodes calculate the root of the Merck tree according to the transaction data which is acquired by the other service nodes and the hash value of the transaction data which is not acquired by the other service nodes, and the acquired transaction data is verified.

It should be noted that the computer system 1500 of the electronic device shown in fig. 15 is only an example, and should not bring any limitation to the functions and the application scope of the embodiments of the present application.

As shown in fig. 15, the computer system 1500 includes a Central Processing Unit (CPU)1501 which can perform various appropriate actions and processes in accordance with a program stored in a Read-Only Memory (ROM) 1502 or a program loaded from a storage section 1508 into a Random Access Memory (RAM) 1503. In the RAM 1503, various programs and data necessary for system operation are also stored. The CPU 1501, the ROM 1502, and the RAM 1503 are connected to each other by a bus 1504. An Input/Output (I/O) interface 1505 is also connected to bus 1504.

The following components are connected to the I/O interface 1505: an input portion 1506 including a keyboard, a mouse, and the like; an output section 1507 including a Display such as a Cathode Ray Tube (CRT), a Liquid Crystal Display (LCD), and a speaker; a storage section 1508 including a hard disk and the like; and a communication section 1509 including a Network interface card such as a LAN (Local Area Network) card, a modem, or the like. The communication section 1509 performs communication processing via a network such as the internet. A drive 1510 is also connected to the I/O interface 1505 as needed. A removable medium 1511 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, or the like is mounted on the drive 1510 as necessary, so that a computer program read out therefrom is mounted into the storage section 1508 as necessary.

In particular, according to embodiments of the application, the processes described above with reference to the flow diagrams may be implemented as computer software programs. For example, embodiments of the present application include a computer program product comprising a computer program embodied on a computer readable medium, the computer program comprising program code for performing the method illustrated by the flow chart. In such an embodiment, the computer program may be downloaded and installed from a network through the communication section 1509, and/or installed from the removable medium 1511. When the computer program is executed by a Central Processing Unit (CPU)1501, various functions defined in the system of the present application are executed.

It should be noted that the computer readable medium shown in the embodiments of the present application may be a computer readable signal medium or a computer readable storage medium or any combination of the two. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the foregoing. More specific examples of the computer readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a Read-Only Memory (ROM), an Erasable Programmable Read-Only Memory (EPROM), a flash Memory, an optical fiber, a portable Compact Disc Read-Only Memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the present application, a computer 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. In this application, however, a computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated data signal may take many forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may be any computer readable medium that is not a computer 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 computer readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wired, etc., or any suitable combination of the foregoing.

The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present application. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams or flowchart illustration, and combinations of blocks in the block diagrams or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

The units described in the embodiments of the present application may be implemented by software, or may be implemented by hardware, and the described units may also be disposed in a processor. Wherein the names of the elements do not in some way constitute a limitation on the elements themselves.

As another aspect, the present application also provides a computer-readable medium, which may be contained in the electronic device described in the above embodiments; or may exist separately without being assembled into the electronic device. The computer readable medium carries one or more programs, which when executed by one of the electronic devices, cause the electronic device to implement the method described in the above embodiments.

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

Through the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein may be implemented by software, and may also be implemented by software in combination with necessary hardware. Therefore, the technical solution according to the embodiments of the present application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (which can be a CD-ROM, a usb disk, a removable hard disk, etc.) or on a network, and includes several instructions to enable a computing device (which can be a personal computer, a server, a touch terminal, or a network device, etc.) to execute the method according to the embodiments of the present application.

Other embodiments of the present application will be apparent to those skilled in the art from consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of the invention following, in general, the principles of the application and including such departures from the present disclosure as come within known or customary practice within the art to which the invention pertains.

It will be understood that the present application is not limited to the precise arrangements described above and shown in the drawings and that various modifications and changes may be made without departing from the scope thereof. The scope of the application is limited only by the appended claims.

Claims

1. A data management method for a blockchain system, the blockchain system comprising a billing node sub-network and a service node sub-network, the billing node sub-network comprising billing nodes and the service node sub-network comprising service nodes, the data management method being performed by a billing node in the billing node sub-network, the data management method comprising:

after the data block is generated, sending the block head of the generated data block to a designated service node in the service node sub-network;

issuing the block header to the service node sub-network through the designated service node to notify the service node sub-network of information of the newly generated data block;

if an acquisition request of a target service node in the service node sub-network for transaction data contained in a designated data block is received, acquiring authority information of the target service node, wherein the acquisition request contains address information of the target service node, and the address information contains public key hash of the target service node, identification information of a superior node to which the target service node belongs and signature information of the superior node;

determining a superior node to which the target service node belongs according to the address information contained in the acquisition request, and verifying the signature information contained in the acquisition request according to the superior node to which the target service node belongs;

and if the signature information contained in the acquisition request passes the verification, inquiring and acquiring transaction data which the target service node has the right to acquire from the data corresponding to the upper node to which the target service node belongs according to the authority information of the target service node, and returning the inquired transaction data to the target service node.

2. The method for data management in a blockchain system according to claim 1, wherein the distributing the block header into the service node sub-network through the designated service node includes:

broadcasting, by the designated service node, the block header to other service nodes in the service node subnetwork.

3. The method of data management in a blockchain system of claim 1, wherein the issuing of the block header into the service node sub-network by the designated service node comprises:

and taking the appointed service node as a sending node to send the block head to the service node closest to the sending node, and taking the service node receiving the block head as the sending node to continue sending until the service nodes in the service node sub-network all receive the block head.

4. The method of data management in a blockchain system according to claim 3, wherein sending the block header to a service node nearest to the sending node comprises:

determining distances between other service nodes in the service node sub-network except the sending node and the sending node;

sending the block head to a service node closest to the sending node, wherein if the service node receiving the block head has received the block head before, a rejection message is fed back to the sending node;

and if the rejection message is received, continuing to send the block head to other service nodes according to the sequence from near to far of the distance until an acceptance message is received.

5. The method of data management for a blockchain system of claim 4, wherein determining distances between other service nodes in the service node sub-network except the sending node and the sending node comprises:

receiving positioning information broadcast by other service nodes in the service node sub-network;

and calculating the distance between each other service node and the sending node according to the positioning information broadcast by each other service node and the positioning information of the sending node.

6. The method of data management in a blockchain system of claim 5 wherein receiving the positioning information broadcast by other service nodes in the service node subnetwork comprises: periodically receiving positioning information broadcast by other service nodes in the service node sub-network;

calculating the distance between each other service node and the sending node according to the positioning information broadcast by each other service node and the positioning information of the sending node, wherein the distance comprises the following steps: and calculating the distance between each other service node and the sending node according to the positioning information broadcast by each other service node which is received last time and the positioning information of the sending node.

7. The method of data management in a blockchain system according to claim 3, further comprising, before sending the block header to a service node nearest to the sending node:

sending a request to a distribution progress recording server so that the distribution progress recording server queries the identification of the service node which does not receive the block header in a service node sub-network, wherein any service node sends a recording request to the distribution progress recording server after receiving the block header;

receiving an identifier of a service node which is returned by the distribution progress recording server and does not receive the block header;

and determining the service node closest to the sending node in the service nodes which do not receive the block head.

8. The method of claim 1, wherein obtaining the authority information of the target service node comprises:

acquiring authentication information of the target service node according to the identification information of the target service node contained in the acquisition request;

and acquiring authority information of the target service node based on the authentication information.

9. The method of data management for a blockchain system according to claim 1, wherein after obtaining the authority information of the target service node, the method further comprises:

and returning the hash value of the transaction data which is contained in the appointed data block and is not acquired by the target service node to the target service node, so that the target service node calculates a Merck tree root according to the transaction data which is acquired by the target service node and the hash value of the transaction data which is not acquired by the target service node, and the acquired transaction data is verified.

10. The method for managing data in a blockchain system according to claim 1, wherein the rights in the rights information include one or more of the following:

and allowing the uplink time corresponding to the viewed transaction data.

11. A data management device of a blockchain system, the blockchain system comprising a billing node sub-network and a service node sub-network, the billing node sub-network comprising a billing node, the service node sub-network comprising a service node, the billing node comprising the data management device, the data management device comprising:

a sending unit, configured to send a block header of a generated data block to a designated service node in the service node subnetwork after the data block is generated;

a distribution unit configured to distribute the block header to the service node sub-network through the designated service node to notify the service node sub-network of information of a newly generated data block;

an obtaining unit, configured to obtain permission information of a target service node when an obtaining request of the target service node in the service node sub-network for transaction data included in an assigned data block is received, where the obtaining request includes address information of the target service node, and the address information includes a public key hash of the target service node, identification information of a higher node to which the target service node belongs, and signature information of the higher node;

a processing unit, configured to determine, according to address information included in the acquisition request, a superior node to which the target service node belongs, and verify, according to the superior node to which the target service node belongs, signature information included in the acquisition request; and if the signature information contained in the acquisition request passes the verification, inquiring and acquiring transaction data which the target service node has the right to acquire from data corresponding to a superior node to which the target service node belongs according to the authority information of the target service node, and returning the inquired transaction data to the target service node.

12. A computer-readable medium, on which a computer program is stored which, when being executed by a processor, carries out a data management method of a blockchain system according to any one of claims 1 to 10.

13. An electronic device, comprising:

one or more processors;

storage means for storing one or more programs which, when executed by the one or more processors, cause the one or more processors to implement a data management method of a blockchain system according to any one of claims 1 to 10.