This application relates to the field of blockchain technologies, and in particular, to a data processing method and apparatus, a computer device, and a storage medium.
A blockchain network corresponding to an existing blockchain node system may include a blockchain, and transactions corresponding to all transaction services generated by a service node in the blockchain network need to be recorded on the blockchain. When receiving the transactions sent by the service node, a consensus node in the blockchain network needs to store all the received transactions to a node transaction pool of the consensus node, such that all the transactions are queued in the node transaction pool to obtain a queuing result. Further, the consensus node may write each transaction to the blockchain according to the queuing result.
It may be understood that since all the transactions generated by the service node need to be written to the same blockchain, the blockchain may store transactions corresponding to different transaction services, and further, different transaction services on the blockchain cannot be effectively distinguished.
According to various embodiments provided in this application, a data processing method and apparatus, a computer device, and a storage medium are provided.
An aspect of the embodiments of this application provides a data processing method, performed by a target consensus node in a core consensus network and including:
An aspect of the embodiments of this application provides a computer device, including one or more processors and a memory.
The one or more processors are connected to the memory. The memory is configured to store computer-readable instructions. When the computer-readable instructions are executed by the one or more processors, the computer device is enabled to perform the method provided in the embodiments of this application.
An aspect of the embodiments of this application provides one or more non-transitory computer-readable storage media. The computer-readable storage medium stores computer-readable instructions. The computer-readable instructions are suitable for one or more processors to load and execute, such that a computer device with the processor performs the method provided in the embodiments of this application.
An aspect of the embodiments of this application provides a computer program product. The computer program product includes computer-readable instructions. The computer-readable instructions are stored in a computer-readable storage medium. One or more processors of a computer device read the computer-readable instructions from the computer-readable storage medium. The one or more processors execute the computer-readable instructions, such that the computer device performs the method provided in the embodiments of this application.
Details of one or more embodiments of this application will be provided in the following drawings and descriptions. Other features, objectives, and advantages of this application will become apparent in the specification, the drawings, and the claims.
In order to describe the technical solutions in the embodiments of this application more clearly, the drawings required to be used in descriptions about the embodiments will be simply described below. Apparently, the drawings in the descriptions below are merely some embodiments of this application. A person of ordinary skill in the art may further obtain other drawings according to these drawings without creative work.
The technical solutions in the embodiments of this application will be described clearly and completely below with reference to the drawings in the embodiments of this application. Clearly, the described embodiments are not all but only some embodiments of this application. All other embodiments obtained by a person of ordinary skill in the art based on the embodiments of this application without creative work shall fall within the protection scope of this application.
Refer to
It is to be understood that a quantity of agent nodes in the routing agent network may be one or more, and this is not limited herein. In this embodiment of this application, an agent node 10D is used as an example. The agent node 10D may be configured to perform network isolation on the service network and the core consensus network. The agent node 10D may be an independent physical server, or a server cluster or distributed system including a plurality of physical servers, or a cloud server providing a basic cloud computing service. This is not limited herein. The agent node 10D may perform network layering on a peer to peer (P2P for short) network to form a layered structure of “service network-core consensus network”, thereby improving confidentiality and security of data on a blockchain.
A blockchain node system (that is, a first blockchain node system) corresponding to the service network (that is, a witness network) shown in
A blockchain node system (that is, a second blockchain node system) corresponding to the core consensus network shown in
It is to be understood that, in this embodiment of this application, the agent node, the service node, and the consensus node may be collectively referred to as blockchain nodes in the blockchain network 1W. The blockchain node may be a server accessing the blockchain network 1W, or a user terminal accessing the blockchain network 1W. A specific form of the blockchain node is not limited herein. It may be understood that the service network and the core consensus network shown in
For ease of understanding, in this embodiment of this application, one node (for example, the node 120a) may be selected from the core consensus network shown in
As shown in
The service configuration information of the transaction service (for example, the bill service) herein may include basic information of the transaction service (that is, a description about the bill service) and node configuration information (including service node configuration information and consensus node configuration information). The service node configuration information may include a configured node identifier configured by the consensus node with the supervision permission (for example, the node 120a with the supervision permission) for the corresponding service branch chain (for example, a service branch chain corresponding to the bill service). A service node corresponding to the configured node identifier may be configured to perform the bill service. The consensus node configuration information herein may include an independent consensus node configured by the consensus node with the supervision permission for the service branch chain to participate in consensus of the service branch chain.
The derivation condition corresponding to each service branch chain herein may be used for determining, on the basic main chain 10Q, a genesis block of the corresponding service branch chain. Each service branch chain shown in
It is to be understood that if an information change occurs on configuration information of the blockchain node system (for example, the taxation blockchain system) corresponding to the entire blockchain network, another consensus node in the core consensus network needs to stop running. In this embodiment of this application, the configuration information on which the information change occurs may be referred to as configuration change information. For example, the configuration change information may be a change of a supervision rule and a calculation regulation in the field of taxation, a change of an important blockchain node, or alternation of a certificate authorizing node of a chain. The consensus node with the supervision permission in the core consensus network may generate a configuration change block based on the configuration change information, further upload the configuration change block to the basic main chain in the core consensus network, and synchronize the configuration change block to all the service branch chains. In this case, the other consensus node in the core consensus network may resume running. As shown in
The core consensus network shown in
In the core consensus network, the target consensus node may further be configured to receive a service request transmitted by the service node in the service network. For example, the service request herein may include a transaction uploading request and a block synchronization request. The target consensus node may be a first consensus node with a first consensus permission. The first consensus permission herein is used for indicating that the first consensus node may participate in consensus of the basic main chain in the core consensus network and the N service branch chains derived from the basic main chain. Alternatively, the target consensus node may be a second consensus node with a second consensus permission. The second consensus permission herein is used for indicating that the second consensus node may participate in consensus of the basic main chain in the core consensus network and a service branch chain corresponding to a target chain identifier. That is, the second consensus node may be an independent consensus node configured to participate in consensus of the service branch chain corresponding to the target chain identifier.
For ease of understanding, further, Refer to
The core consensus network may include N branch chain independent consensus networks. A consensus node in each branch chain independent consensus network has a second consensus permission. That is, the consensus node in each branch chain independent consensus network may perform independent consensus on a same service branch chain, and synchronize data on the basic main chain 10Q. As shown in
A consensus node in the branch chain independent consensus network W1 may be configured by a consensus node with the supervision permission (for example, the target consensus node) in the core consensus network for a service branch chain 11Q, and a blockchain in the branch chain independent consensus network W1 may include the basic main chain (for example, the basic main chain 10Q shown in
A consensus node in the branch chain independent consensus network W2 may be configured by the consensus node with the supervision permission in the core consensus network for a service branch chain 12Q, and a blockchain in the branch chain independent consensus network W2 may include the basic main chain 10Q in the core consensus network and the service branch chain 12Q. This means that the consensus node in the branch chain independent consensus network W2 needs to not only participate in consensus of the service branch chain 12Q but also synchronize the data in the basic main chain 10Q in the core consensus network.
By analogy, a consensus node in the branch chain independent consensus network W3 may be configured by the consensus node with the supervision permission in the core consensus network for a service branch chain 13Q, and a blockchain in the branch chain independent consensus network W3 may include the basic main chain 10Q in the core consensus network and the service branch chain 13Q. This means that the consensus node in the branch chain independent consensus network W3 needs to not only participate in consensus of the service branch chain 13Q but also synchronize the data in the basic main chain 10Q in the core consensus network.
The embodiments of this application may provide a data processing method of deriving a plurality of service branch chains from a basic main chain in a core consensus network. In this way, it can be effectively ensured that the basic main chain is a trust root of all the service branch chains. Global information such as a service configuration of each service branch chain is collected, so that convenience is brought to subsequent supervision and review. In addition, simultaneous running of the plurality of service branch chains can improve concurrency of different transaction services and reduce waiting time of the transaction services during uploading, thereby improving resource utilization and further improving system efficiency.
For ease of understanding, further, refer to
Since the consensus node 200C has the first consensus permission, a blockchain run by the consensus node 200C may include a basic main chain (for example, a basic main chain 20Q) in the core consensus network and N service branch chains derived from the basic main chain 20Q. Here, N is a positive integer. As shown in
As shown in
A chain identifier (for example, a chain identifier 220s) of the service branch chain 22Q may be determined by the consensus node with the supervision permission when creating another transaction service (that is, a second transaction service, for example, a credit information service) in the blockchain node system corresponding to the blockchain network. The service branch chain 22Q may be a service subchain derived by the consensus node with the supervision permission from a block A3 on the basic main chain 20Q based on a derivation condition corresponding to the chain identifier 220s on the basic main chain 20Q. The derivation condition corresponding to the chain identifier 220s may be used for determining, on the basic main chain 20Q, a genesis block (for example, the block A3) of the service branch chain 22Q. The service branch chain 22Q may further include a block C4, a block C5, a block C6, and a block C7. The block C7 may include a transaction (a transaction 2X shown in
Similarly, a chain identifier (for example, a chain identifier 230s) of the service branch chain 23Q may be determined by the consensus node with the supervision permission when creating another transaction service (that is, a third transaction service, for example, a tax refund service) in the blockchain node system corresponding to the blockchain network. The service branch chain 23Q is a service subchain derived by the consensus node with the supervision permission from a block A4 on the basic main chain 20Q based on a derivation condition corresponding to the chain identifier 230s on the basic main chain 20Q. The derivation condition corresponding to the chain identifier 230s may be used for determining, on the basic main chain 20Q, a genesis block (for example, the block A4) of the service branch chain 23Q. The service branch chain 23Q may further include a block D5.
It is to be understood that the consensus node with the supervision permission in the core consensus network may also dynamically configure M chain identifiers for the service node 200A shown in
It may be understood that when receiving the transaction 2X and the chain identifier 220s, the agent node 200B may perform permission verification on the service node 200A (for example, verify transaction signature information of the service node 200A for the transaction 2X, a transaction format of the transaction 2X, and whether the service node 200A is a node in an invalid node list stored in the agent node 200B), and when determining that the service node 200A is valid, may further forward both the transaction 2X and the chain identifier 220s to the core consensus network, such that the consensus node in the core consensus network writes the transaction 2X to the service branch chain (that is, the service branch chain 22Q) corresponding to the chain identifier 220s.
When the consensus node 200C in the core consensus network receives the transaction 2X and the chain identifier 220s, the consensus node 200C may obtain the derivation condition corresponding to the chain identifier 220s from the basic main chain 20Q based on the chain identifier 220s, and further perform packing processing on the transaction based on the derivation condition corresponding to the chain identifier 220s, to obtain a to-be-verified block for broadcasting to the core consensus network. Further, the consensus node 200C may transmit the to-be-verified block to the consensus node (for example, another consensus node capable of participating in consensus of the service branch chain 22Q in the core consensus network in which the consensus node 200C is) in the core consensus network based on the chain identifier 220s, such that the consensus node performs block consensus on the to-be-verified block.
It may be understood that the consensus node 200C may receive a block consensus result (that is, a first block consensus result) returned by the consensus node for the to-be-verified block, and further perform result analysis on the first block consensus result. If the first block consensus result indicates that consensus succeeds, the consensus node 200C may write the to-be-verified block to the service branch chain 22Q corresponding to the chain identifier 220s based on the genesis block (the block A3) of the service branch chain 22Q. In other words, the consensus node 200C determines the to-be-verified block a next block of the block C6 (for example, a block C7 shown in
Thus, it can be seen that service branch chains respectively corresponding to a plurality of transaction services may be derived from the basic main chain 20Q in the core consensus network shown in
An embodiment of this application provides a bifurcated service tree-based blockchain structure in a blockchain node system. A plurality of service branch chains derived from a basic main chain may simultaneously run in a core consensus network of a blockchain network corresponding to the blockchain node system. A specific implementation in which a consensus node (for example, a target consensus node) in the core consensus network uploads, when receiving a transaction transmitted by a service node in a service network, the transaction to a corresponding service branch chain based on a target chain identifier corresponding to the transaction may refer to the following embodiments corresponding to
Further, refer to
Step S101: Receive a transaction and a target chain identifier corresponding to the transaction, which are transmitted by a service node in a service network.
Specifically, the target consensus node in the core consensus network may obtain a transaction uploading request forwarded by an agent node in a routing agent network. The routing agent network may be a subnetwork in a blockchain network in which the core consensus network is. The routing agent network is configured to perform network isolation on the service network and the core consensus network in the blockchain network. The transaction uploading request herein may be generated by the service node in the service network. The transaction uploading request may include the transaction, the target chain identifier corresponding to the transaction, transaction signature information corresponding to the transaction, and a node identifier of the service node. The transaction signature information may be obtained by the service node by signing the transaction based on a node private key of the service node. Further, the target consensus node may obtain a node public key of the service node, and further perform signature verification on the transaction signature information based on the node public key of the service node to obtain a signature verification result. It may be understood that when the signature verification result indicates that signature verification succeeds, the target consensus node may perform transaction verification on the transaction based on the target chain identifier and the node identifier of the service node to obtain a transaction verification result. If the transaction verification result indicates that transaction verification succeeds, the target consensus node may determine that the transaction uploading request is a valid request, and obtain the transaction and the target chain identifier from the transaction uploading request.
It is to be understood that when performing a target transaction service, the service node in the service network may generate a service transaction corresponding to the target transaction service, further determine the generated service transaction as the transaction, and determine a chain identifier corresponding to the target transaction service as the target chain identifier. The target transaction service herein is a transaction service corresponding to a specific chain identifier in M chain identifiers configured by the core consensus network for the service node. The M chain identifiers belong to chain identifiers of the N service branch chains registered in the core consensus network. Here, M is a positive integer less than or equal to N. It is to be understood that one service branch chain corresponds to one transaction service, and one service branch chain corresponds to one chain identifier. Each of the N service branch chains is obtained according to a derivation condition on a basic main chain in the core consensus network.
In order to effectively improve authenticity and security of the transaction during data transmission, the service node may perform signature processing on the transaction based on the node private key of the service node to obtain the transaction signature information corresponding to the transaction. Further, the service node may generate, based on the transaction, the target chain identifier corresponding to the transaction, the transaction signature information corresponding to the transaction, and the node identifier of the service node, a service request for uploading the transaction. In this embodiment of this application, the service request for uploading the transaction may be referred to as the transaction uploading request.
In this embodiment of this application, the blockchain network may include two subnetworks: the service network and the core consensus network. The service node in the service network may directly perform network interaction with the target consensus node in the core consensus network to implement data transmission between the two subnetworks. Based on this, when generating the transaction uploading request, the service node may directly transmit, based on the target chain identifier in the transaction uploading request, the transaction uploading request to the target consensus node capable of participating in consensus of a service branch chain corresponding to the target chain identifier in the core consensus network, such that the target consensus node successfully writes the transaction in the transaction uploading request to the service branch chain corresponding to the target chain identifier.
Alternatively, in this embodiment of this application, the blockchain network may include not only the service network and the core consensus network but also the routing agent network configured to perform network isolation on the service network and the core consensus network. The agent node in the routing agent network may realize a routing forwarding function between the service network and the core consensus network. Based on this, when generating the transaction uploading request, the service node (for example, the node 110a in the service network shown in
Permission verification herein may include verifying whether the node identifier of the service node is a node identifier in the invalid node list, verifying whether the transaction format of the transaction is wrong, verifying whether the transaction signature information of the transaction is wrong, and the like. The invalid node list herein may be a blacklist stored in the agent node. An invalid node corresponding to an invalid node identifier in the invalid node list may include a detected malicious node, a node reported by another person, a node transmitting transactions at an exceptional frequency in a specific time period, or the like.
When receiving the transaction uploading request forwarded by the agent node, the target consensus node in the core consensus network may obtain the node public key of the service node, and further perform signature verification on the transaction signature information in the transaction uploading request based on the node public key of the service node to obtain the signature verification result. When the signature verification result indicates that signature verification succeeds, the target consensus node may perform transaction verification on the transaction based on the target chain identifier and the node identifier of the service node, thereby obtaining the transaction verification result.
For example, when the signature verification result indicates that signature verification succeeds, the target consensus node may obtain registration information associated with the service branch chain corresponding to the target chain identifier from the basic main chain in the core consensus network, and further determine the obtained registration information as check registration information. Then, the target consensus node may obtain service node configuration information in the check registration information, and search in the service node configuration information for a configured node identifier matched with the node identifier of the service node. A service node corresponding to the configured node identifier is configured by the core consensus network (for example, a consensus node with a supervision permission in the core consensus network) for the service branch chain corresponding to the target chain identifier. The service node corresponding to the configured node identifier is configured to perform the target transaction service corresponding to the target chain identifier.
If the service node configuration information does not include the configured node identifier matched with the node identifier of the service node, the target consensus node may obtain a transaction verification result for indicating that transaction verification fails. Alternatively, if the service node configuration information includes the configured node identifier matched with the node identifier of the service node, the target consensus node may obtain a transaction verification result for indicating that transaction verification succeeds. It may be understood that if the transaction verification result indicates that transaction verification succeeds, the target consensus node may determine that the transaction uploading request is a valid request, and further obtain the transaction and the target chain identifier corresponding to the transaction from the transaction uploading request.
For ease of understanding, further, refer to
A transaction 4X (that is, the transaction) shown in
In order to effectively improve authenticity and security of the transaction 4X during data transmission, the service node 400A may perform signature processing on the transaction 4X based on a node private key of the service node 400A to obtain transaction signature information corresponding to the transaction 4X. It may be understood that the service node 400A may obtain a hash calculation rule for the transaction (that is, the transaction 4X). The hash calculation rule may be a digest algorithm predetermined by the service node 400A and another blockchain node (for example, the consensus node 400C) in a blockchain network. Therefore, the service node 400A may perform hash calculation on the transaction 4X based on the hash calculation rule to obtain digest information (for example, digest information h) of the transaction 4X. In this embodiment of this application, the digest information, determined by the service node 400A, of the transaction 4X may be referred to as first digest information. Further, the service node 400A may sign the first digest information based on the node private key of the service node 400A, thereby obtaining the transaction signature information shown in
The service node 400A may generate, based on the transaction 4X, the chain identifier 430s corresponding to the transaction 4X, the transaction signature information corresponding to the transaction 4X, and a node identifier 4J of the service node 400A, a transaction uploading request for uploading the transaction 4X. Then, the service node 400A may transmit the transaction uploading request to the agent node 400B shown in
The agent node 400B stores an invalid node list. An invalid node corresponding to an invalid node identifier in the invalid node list may include a detected malicious node, a node reported by another person, a node transmitting transactions at an exceptional frequency in a specific time period, or the like. For example, when receiving the transaction uploading request transmitted by the service node 400A, the agent node 400B may obtain the node identifier 4J of the service node 400A from the transaction uploading request, and further search in the invalid node list for the node identifier 4J of the service node 400A, thereby obtaining the permission verification result. If the permission verification result indicates that the invalid node list includes an invalid node identifier the same as the node identifier 4J of the service node 400A, the agent node 400B may determine that the permission verification result indicates that the service node is invalid. In this case, the agent node 400B may determine that the service node 400A is an invalid node, and does not need to broadcast the transaction uploading request to the core consensus network.
Alternatively, if the permission verification result indicates that the invalid node list does not include an invalid node identifier the same as the node identifier 4J of the service node 400A, the agent node 400B may determine that the permission verification result indicates that the service node is valid. In this case, the agent node 400B may determine that the service node 400A is a valid node, and further broadcast the transaction uploading request to a consensus node (for example, the consensus node 400C shown in
The consensus node 400C may obtain a node public key of the service node 400A, and further perform signature verification on the transaction signature information in the transaction uploading request based on the node public key of the service node 400A to obtain a signature verification result. It may be understood that the consensus node 400C may obtain the node public key of the service node 400A, and further perform signature verification on the transaction signature information based on the node public key of the service node 400A to obtain the first digest information of the transaction 4X. Meanwhile, the consensus node 400C may further obtain the same hash calculation rule as the service node 400A, and perform hash calculation on the transaction 4X, thereby obtaining digest information (for example, digest information H) of the transaction 4X. In this embodiment of this application, the digest information, determined by the consensus node 400C, of the transaction 4X may be referred to as second digest information.
Then, the consensus node 400C may compare the first digest information with the second digest information to obtain the signature verification result, thereby determining whether the transaction 4X is tampered. It may be understood that if the first digest information is different from the second digest information, the consensus node 400C may determine that the signature verification result indicates that signature verification fails. Alternatively, if the first digest information is the same as the second digest information, the consensus node 400C may determine that the signature verification result indicates that signature verification succeeds, and this means that the transaction 4X is not tampered and is actually transmitted by the service node 400A.
Further, when the signature verification result indicates that signature verification succeeds, the consensus node 400C may perform transaction verification on the transaction 4X based on the target chain identifier 430s and the node identifier 4J of the service node 400A, thereby obtaining a transaction verification result. For example, when the signature verification result indicates that signature verification succeeds, the consensus node 400C may obtain registration information associated with a service branch chain corresponding to the chain identifier 430s from the basic main chain in the core consensus network, and further determine the obtained registration information as check registration information. Then, the consensus node 400C may obtain service node configuration information in the check registration information, and search in the service node configuration information for a configured node identifier matched with the node identifier 4J of the service node 400A. A service node corresponding to the configured node identifier may be configured by the core consensus network for the service branch chain corresponding to the chain identifier 430s. The service node corresponding to the configured node identifier may be configured to perform the target transaction service.
For ease of understanding, refer to Table 1. Table 1 is a configured node identifier list provided in this embodiment of this application. The configured node identifier list may be used for representing the service node configuration information obtained by the consensus node 400C from the basic main chain in the core consensus network. As shown in Table 1:
As shown in table 1, the configured node identifier list may include service nodes corresponding to a plurality of (for example, four) configured node identifiers, specifically including a service node 100A, a service node 200A, a service node 300A, and the service node 400A. The service node corresponding to each configured node identifier is configured by a consensus node with a supervision permission in the core consensus network for a specific service branch chain (for example, the service branch chain corresponding to the target chain identifier). This means that all the service nodes in Table 1 are qualified to perform the target transaction service corresponding to the target chain identifier. The node identifier in the configured node identifier list may be an Internet protocol (IP) address and any other information capable of identifying the node. Table 1 uses only the IP address as an example for description.
It may be understood that if the configured node identifier list (for example, the above Table 1) does not include the configured node identifier matched with the node identifier 4J (for example, 156.115.726.324) of the service node 400A, the consensus node 400C may obtain a transaction verification result for indicating that transaction verification fails. This means that the service node 400A is unqualified to perform the target transaction service corresponding to the chain identifier 430s. In this case, the consensus node 400C may determine that the transaction uploading request is an invalid request, and further generate an uploading failure notification for notifying the service node 400A for the agent node 400B to forward to the service node 400A. The uploading failure notification may be “You do not have the permission to perform this transaction service, so you cannot upload the transaction 4X. If necessary, you can go to the xx tax bureau to modify your permission”.
Alternatively, if the configured node identifier list includes the configured node identifier 4J matched with the node identifier 4J (for example, 119.123.789.258) of the service node 400A, the consensus node 400C may obtain a transaction verification result for indicating that transaction verification succeeds. This means that the service node 400A is qualified to perform the target transaction service corresponding to the chain identifier 430s. In this case, the consensus node 400C may determine that the transaction uploading request is a valid request, and further obtain the transaction 4X and the chain identifier 430s corresponding to the transaction 4X from the transaction uploading request.
Since the target consensus node in the core consensus network is the first consensus node with the first consensus permission, that is, the first consensus node may be configured to participate in consensus of the basic main chain in the core consensus network and the N service branch chains derived from the basic main chain, a node transaction pool of the first consensus node may include N transaction sets. One transaction set is used for storing a service transaction with a same chain identifier. If the transaction verification result indicates that transaction verification succeeds, the first consensus node may determine a transaction set corresponding to the target chain identifier from the N transaction sets, and store the transaction to the target transaction set corresponding to the target chain identifier.
As shown in
If the transaction verification result determined by the consensus node 400C indicates that transaction verification succeeds, the consensus node 400C may determine a transaction set (for example, the transaction set 3g shown in
Step S102: Perform packing processing on the transaction based on a derivation condition corresponding to the target chain identifier to obtain a to-be-verified block for broadcasting to the core consensus network, and transmit the to-be-verified block to at least a part of consensus nodes in the core consensus network except the target consensus node based on the target chain identifier, such that the consensus node performs block consensus on the to-be-verified block.
Specifically, the target consensus node may obtain a service transaction with a same chain identifier as the target chain identifier from a node transaction pool of the core consensus network, and further determine the obtained service transaction as a to-be-processed transaction. The to-be-processed transaction may include the transaction. Further, the target consensus node may perform packing processing on the to-be-processed transaction based on the derivation condition corresponding to the target chain identifier to obtain the to-be-verified block for broadcasting to the core consensus network. Then, the target consensus node may transmit the to-be-verified block to the consensus node in the core consensus network based on the target chain identifier. The consensus node receiving the to-be-verified block may be another consensus node with a consensus permission for the service branch chain corresponding to the target chain identifier in the core consensus network in which the target consensus node is.
As shown in
It is to be understood that the target consensus node may determine the service branch chain corresponding to the target chain identifier as a target service branch chain, and further recognize a block type of the to-be-verified block to be generated on the target service branch chain. The block type of the to-be-verified block on the target service branch chain may include a first block type and a second block type. The first block type herein is used for indicating that a parent block of the to-be-verified block is a block on the basic main chain, that is, the to-be-verified block is a next block of a genesis block of the target service branch chain. This means that the target service branch chain derived from the current basic main chain includes only the genesis block (that is, a specific block, determined based on the derivation condition, on the basic main chain) of the target service branch chain, and the next block of the genesis block is yet not written after the genesis block. The second block type herein is used for indicating that a parent block of the to-be-verified block is not a block on the basic main chain, that is, the to-be-verified block is a next block of a non-genesis block of the target service branch chain. This means that the target service branch chain derived from the current basic main chain includes not only the genesis block of the target service branch chain but also another block that is written after and in a block index relationship with the genesis block.
Further, the target consensus node may determine the parent block of the to-be-verified block based on the block type and the derivation condition corresponding to the target chain identifier, and further determine a block hash value of the parent block of the to-be-verified block as a parent block hash value. It may be understood that if the block type is the first block type, the target consensus node may obtain target registration information associated with the target service branch chain from the basic main chain, and obtain the derivation condition corresponding to the target chain identifier from the target registration information. Further, the target consensus node may determine the genesis block of the target service branch chain based on the derivation condition corresponding to the target chain identifier, and further determine the determined genesis block as the parent block of the to-be-verified block. Then, the target consensus node may obtain the block hash value of the parent block of the to-be-verified block, and determine the obtained block hash value as the parent block hash value of the to-be-verified block.
Alternatively, if the block type is the second block type, the target consensus node may obtain a block with a maximum generation timestamp from the target service branch chain indicated by the derivation condition corresponding to the target chain identifier, and further determine the block with the maximum generation timestamp as the parent block of the to-be-verified block. Further, the target consensus node may obtain the block hash value of the parent block of the to-be-verified block, and determine the obtained block hash value as the parent block hash value of the to-be-verified block.
Then, the target consensus node may perform transaction hash transformation on the to-be-processed transaction to obtain a transaction hash value corresponding to the to-be-processed transaction, and determine a block hash value of the to-be-verified block based on the transaction hash value. Further, the target consensus node may perform packing processing on the to-be-processed transaction, the block hash value, and the parent block hash value to obtain the to-be-verified block to be written to the target service branch chain. A generation timestamp of the to-be-verified block is used for updating the maximum generation timestamp on the target service branch chain.
For ease of understanding, further, refer to
As shown in
If a target chain identifier corresponding to a transaction (for example, a transaction 4X) received by the consensus node 500C is the chain identifier 530s, when performing packing processing on the transaction, the consensus node 500C may obtain a service transaction with a same chain identifier as the chain identifier 530s from a node transaction pool 5000m shown in
Further, the consensus node 500C may recognize a block type of a to-be-verified block to be generated on the service branch chain 53Q (that is, a target service branch chain). Since the next block of the genesis block of the service branch chain 53Q is yet not written after the genesis block, the consensus node 500C may determine that the block type of the to-be-verified block is a first block type. In this case, the consensus node 500C may obtain registration information (that is, target registration information, for example, registration information stored in the block A3 shown in
For example, the derivation condition 53P may be determining a next block of a block in which the derivation condition 53P is as the genesis block of the service branch chain 53Q. Alternatively, the derivation condition 53P may be determining a block in which the target registration information associated with the service branch chain 53Q is as the genesis block of the service branch chain 53Q. Alternatively, the derivation condition 53P may be determining a block with a maximum generation timestamp on the basic main chain 53Q as the genesis block of the service branch chain 53Q when a service transaction with the chain identifier 530s needs to be uploaded. A specific manner of the derivation condition is not limited herein.
It may be understood that the genesis block of the service branch chain 53Q determined by the consensus node 500C based on the derivation condition 53P may be the block A4 on the basic main chain 50Q shown in
Meanwhile, the consensus node 500C may perform transaction hash transformation on the four to-be-processed transactions, that is, the transaction 1X, the transaction 2X, the transaction 3X, and the transaction 4X, to obtain transaction hash values corresponding to the to-be-processed transactions, and further determine a block hash value of the to-be-verified block based on the transaction hash values. Further, the consensus node 500C may perform packing processing on the to-be-processed transaction, the block hash value, and the parent block hash value, thereby obtaining the to-be-verified block to be written to the service branch chain 53Q. A generation timestamp of the to-be-verified block is used for updating a maximum generation timestamp on a target service branch chain. It may be understood that the to-be-verified block may be determined as a next block of the block A4 (for example, a block D5) when written to the service branch chain 53Q.
Alternatively, as shown in
Further, the consensus node 200C may recognize a block type of a to-be-verified block to be generated on a target service branch chain (for example, a service branch chain 22Q) corresponding to the chain identifier 220s. The service branch chain 22Q includes not only a genesis block (for example, a block A3 on the basic main chain 20Q) of the service branch chain 22Q but also another block (for example, a block C4, a block C5, and a block C6) that is written after and in a block index relationship with the genesis block. Therefore, the consensus node 200C may determine that the block type of the to-be-verified block shown in
In this case, the consensus node 200C may obtain a block with a maximum generation timestamp from the service branch chain 22Q indicated by the derivation condition corresponding to the chain identifier 220s, and further determine the block with the maximum generation timestamp as a parent block (for example, the block C6) of the to-be-verified block. Further, the consensus node 200C may determine a block hash value of the block C6 as a parent block hash value of the to-be-verified block.
Meanwhile, the consensus node 200C may perform transaction hash transformation on the to-be-processed transaction, that is, the transaction 2X shown in
Further, after generating the to-be-verified block, the target consensus node may transmit the to-be-verified block to the consensus node in the core consensus network based on the target chain identifier. The consensus node herein may be configured to participate in consensus of the service branch chain (that is, the target service branch chain) corresponding to the target chain identifier. As shown in
Step S103: Receive a first block consensus result returned by the consensus node for the to-be-verified block, and write, based on the derivation condition when the first block consensus result indicates that consensus succeeds, the to-be-verified block to the service branch chain corresponding to the target chain identifier.
Specifically, the target consensus node may receive a first block consensus result returned by another consensus node in the core consensus network for the to-be-verified block, and further perform result analysis on the first block consensus result. If consensus results of a quantity exceeding a consensus threshold (for example, ½ or ⅔) in the first block consensus result indicate that consensus succeeds, the target consensus node may determine that the consensus nodes in the core consensus network reach a consensus, and further write, based on the derivation condition, the to-be-verified block to the service branch chain corresponding to the target chain identifier.
Further, refer to
It is to be understood that the consensus node 500C may perform result analysis on the block consensus result after receiving the block consensus result (that is, the first block consensus result) returned by the consensus node 500D for the to-be-verified block. If consensus results of a quantity exceeding a consensus threshold (for example, ½ or ⅔) in the first block consensus result indicate that consensus succeeds, the consensus node 500C may determine that consensus nodes in the core consensus network reach a consensus, and further write, based on the derivation condition 53P, the to-be-verified block to the service branch chain 53Q corresponding to the chain identifier 530s, that is, determine the to-be-verified block as the next block, that is, the block D5, of the block A4 in the basic main chain 50Q.
In this embodiment of this application, all the M chain identifiers configured by the core consensus network for the service node in the service network belong to chain identifiers of the N service branch chains registered in the core consensus network. M is a positive integer less than or equal to N. This means that a service node may be qualified to perform M transaction services, but cannot perform a transaction service corresponding to another chain identifier not configured for the service node. This can not only ensure lightweight of the service node but only implement effective security control on the service node. It may be understood that each of the N service branch chains is obtained according to the derivation condition on the basic main chain in the core consensus network. This means that in this embodiment of this application, the basic main chain may be determined as a trust root of all transaction services. Global information (that is, registration information respectively corresponding to all the service branch chains) such as subchain configurations respectively corresponding to all the service branch chains is collected, thereby bringing convenience to supervision and review and further effectively solving the problem of inconsistency of each service branch chain caused by non-uniformity of data. In addition, in the core consensus network, one service branch chain corresponds to one transaction service, and one service branch chain corresponds to one chain identifier, instead of storing all transactions generated for the N transaction services on a single blockchain indistinguishably. In this way, different transaction services can be effectively distinguished to ensure uniformity of transaction storage on each service branch chain. It may be understood that running processes of the N service branch chains in the core consensus network may all refer to a process in which the target consensus node runs the service branch chain corresponding to the target chain identifier. In this way, when the N service branch chains run simultaneously, concurrency of different transaction services can be improved, and uploading waiting time of the transaction services can further be reduced, thereby improving resource utilization and further improving system efficiency.
Further, refer to
Step S201: The service node in the service network transmits a generated transaction uploading request to the agent node in the routing agent network.
Specifically, when performing the target transaction service, the service node in the service network may generate a service transaction corresponding to the target transaction service, further determine the generated service transaction as a transaction, and determine a chain identifier corresponding to the target transaction service as the target chain identifier. The target transaction service herein is a transaction service corresponding to a specific chain identifier in the M chain identifiers configured by the core consensus network for the service node. The M chain identifiers belong to chain identifiers of N service branch chains registered in the core consensus network. Here, M is a positive integer less than or equal to N. It is to be understood that one service branch chain corresponds to one transaction service, and one service branch chain corresponds to one chain identifier. Each of the N service branch chains is obtained according to a derivation condition on a basic main chain in the core consensus network. Further, the service node may perform signature processing on the transaction based on a node private key of the service node to obtain transaction signature information corresponding to the transaction. Further, the service node may generate, based on the transaction, the target chain identifier corresponding to the transaction, the transaction signature information corresponding to the transaction, and a node identifier of the service node, the transaction uploading request for uploading the transaction, and further transmit the transaction uploading request to the agent node in the routing agent network.
Step S202: The agent node performs permission verification on the service node, and forwards the transaction uploading request to the second consensus node in the corresponding target independent consensus network based on the target chain identifier in the transaction uploading request when a permission verification result indicates that the service node is valid.
The agent node may be configured to record independent consensus node information of an independent consensus node in the core consensus network, and further realize a routing forwarding function between the service network and the core consensus network based on the recorded independent consensus node information. Specifically, when receiving the transaction uploading request, the agent node may perform permission verification on the service node (for example, verify whether the node identifier of the service node is a node identifier in an invalid node list, verify whether a transaction format of the transaction is wrong, or verify whether the transaction signature information of the transaction is wrong) to obtain the permission verification result. When the permission verification result indicates that the service node is valid, the agent node may determine the target independent consensus network corresponding to the target chain identifier from N branch chain independent consensus networks in the core consensus network based on the target chain identifier and the independent consensus node information, and further transmit the transaction uploading request to the second consensus node in the target independent consensus network.
For ease of understanding, further, refer to Table 2. Table 2 is an independent consensus node information table provided in this embodiment of this application. The independent consensus node information table may be used for representing the independent consensus node information recorded by the agent node based on the basic main chain (for example, the basic main chain 10Q shown in
It is to be understood that the basic main chain in the core consensus network may include registration information of a service branch chain corresponding to each transaction service. The registration information of the service branch chain corresponding to each transaction service may include a chain identifier of the service branch chain, service configuration information (including consensus node configuration information) of the transaction service, and a derivation condition corresponding to the chain identifier. The consensus node configuration information may be an independent consensus node configured by a consensus node with a supervision permission in the core consensus network for the service branch chain to participate in consensus of the service branch chain. Therefore, the agent node may obtain the registration information of each service branch chain from the basic main chain in the core consensus network, and further determine a mapping relationship between the chain identifier of each service branch chain, the consensus node configuration information, and a branch chain independent consensus network formed by the consensus node configuration information based on the obtained registration information, to generate the independent consensus node information shown in Table 2. In addition, after the core consensus network creates a new transaction service, the agent node may obtain new registration information associated with the new transaction service, and further dynamically update Table 2 based on the new registration information.
It may be understood that when the permission verification result indicates that the service node is valid, the agent node may determine the target independent consensus network (for example, the branch chain independent consensus network W1) corresponding to the target chain identifier from the N branch chain independent consensus networks in the core consensus network based on the target chain identifier (for example, a chain identifier 2s) and the independent consensus node information shown in Table 2, and further transmit the transaction uploading request to the second consensus node (for example, a node 120d) in the target independent consensus network.
Step S203: The second consensus node obtains the transaction and the target chain identifier corresponding to the transaction from the transaction uploading request.
The transaction uploading request herein may include the transaction, the target chain identifier corresponding to the transaction, the transaction signature information corresponding to the transaction, and the node identifier of the service node. The transaction signature information may be obtained by the service node by signing the transaction based on the node private key of the service node. Further, the second consensus node may obtain a node public key of the service node, and further perform signature verification on the transaction signature information based on the node public key of the service node to obtain a signature verification result. It may be understood that when the signature verification result indicates that signature verification succeeds, the second consensus node may perform transaction verification on the transaction based on the target chain identifier and the node identifier of the service node to obtain a transaction verification result. If the transaction verification result indicates that transaction verification succeeds, the second consensus node may determine that the transaction uploading request is a valid request, and obtain the transaction and the target chain identifier from the transaction uploading request.
Step S204: The second consensus node performs packing processing on the transaction based on a derivation condition corresponding to the target chain identifier to obtain a to-be-verified block for broadcasting to the core consensus network.
Specifically, the second consensus node may directly obtain a service transaction with a same chain identifier as the target chain identifier from a node transaction pool of the second consensus node, and further determine the obtained service transaction as a to-be-processed transaction. Since the second consensus node is an independent consensus node, the node transaction pool of the second consensus node may store the service transaction with the same chain identifier as the target chain identifier, and does not need to store a service transaction with another chain identifier. The to-be-processed transaction may include the transaction. Further, the second consensus node may perform packing processing on the to-be-processed transaction based on the derivation condition corresponding to the target chain identifier to obtain the to-be-verified block for broadcasting to the target independent consensus network.
Step S205: The second consensus node transmits the to-be-verified block to the third consensus node in the target independent consensus node based on the target chain identifier, such that the third consensus node in the target independent consensus network performs block consensus on the to-be-verified block.
The third consensus node receiving the to-be-verified block may be any consensus node in a branch chain independent consensus network in which a first consensus node is, for example, a node 120f in the branch chain independent consensus network W1 shown in Table 2.
Step S206: The second consensus node receives a first block consensus result returned by the third consensus node for the to-be-verified block.
Specifically, the second consensus node may receive the first block consensus result returned by the third consensus node for the to-be-verified block, and further perform result analysis on the first block consensus result.
Step S207: The second consensus node writes, based on a genesis block when the first block consensus result indicates that consensus succeeds, the to-be-verified block to the service branch chain corresponding to the target chain identifier.
Specifically, if consensus results of a quantity exceeding a consensus threshold (for example, ½ or ⅔) in the first block consensus result indicate that consensus succeeds, the second consensus node may determine that consensus nodes in the core consensus network reach a consensus, and further write, based on the derivation condition, the to-be-verified block to the service branch chain corresponding to the target chain identifier.
Specific implementations of step S201 to step S207 may refer to the descriptions about step S101 to step S103 in the embodiment corresponding to
It is to be understood that in the embodiments of this application, when the target consensus node (for example, the first consensus node with the first consensus permission or the second consensus node with the second consensus permission) in the core consensus network successfully writes the to-be-verified block to the service branch chain corresponding to the target chain identifier, the target consensus node may obtain the target registration information associated with the service branch chain corresponding to the target chain identifier from the basic main chain, and obtain the service node configuration information corresponding to the target chain identifier from the target registration information. Further, the target consensus node may transmit the service node configuration information and a target block height of the to-be-verified block to the agent node in the routing agent network, such that the agent node forwards the target block height to the service node (that is, a target service node) corresponding to the configured node identifier in the service node configuration information. The target block height may be used for instructing the target service node to generate a block synchronization request based on an initial block height on a local blockchain and a chain identifier corresponding to the initial block height.
In this case, when receiving the target block height forwarded by the agent node, the target service node may determine the initial block height on the local blockchain, generate the block synchronization request based on the initial block height and the chain identifier corresponding to the initial block height, and further transmit the block synchronization request to the agent node, such that the agent node forwards the block synchronization request to the target consensus node in the core consensus network. Further, when receiving the block synchronization request, the target consensus node may determine, based on the initial block height and the chain identifier corresponding to the initial block height in the block synchronization request, a to-be-synchronized block for synchronization to the target service node. Further, the target consensus node may transmit the to-be-synchronized block to the target service node through the agent node, such that the target service node writes the to-be-synchronized block to a corresponding service branch chain in the local blockchain when the to-be-synchronized block is successfully verified.
For ease of understanding, further, refer to
As shown in
When successfully writing a to-be-verified block (for example, a block C7) to the service branch chain 72Q corresponding to the target chain identifier (that is, the chain identifier 720s), the consensus node 700C may obtain target registration information (for example, registration information 72Z shown in
The agent node 700B may transmit the block height of the block C7 to a service node (for example, the service node 700A) corresponding to the configured node identifier based on the configured node identifier in the service node configuration information. In order to improve data transmission security, the agent node 700B may further obtain a system public key of the service network, perform encryption processing on the block height of the block C7 to obtain system encrypted data information, and further forward the system encrypted data information to the service node 700A. When receiving the system encrypted data information, the service node 700A may perform decryption processing on the system encrypted data information based on a system private key corresponding to the system public key to obtain the block height of the block C7.
Further, the service node 700A may obtain an initial block height (that is, a maximum block height) of each service branch chain on the local blockchain, and further generate, based on the initial block height of each service branch chain and a chain identifier corresponding to the initial block height, a block synchronization request for transmission to the agent node 700B.
For example, a maximum block height obtained by the service node 700A on the service branch chain 71q is a block height of the block header b4, and the block height of the block header b4 may further be referred to as an initial block height on the service branch chain 71q. For another example, a maximum block height obtained by the service node 700A on the service branch chain 72q is a block height of the block header c5, and the block height of the block header c5 may further be referred to as an initial block height on the service branch chain 72q. In this case, the service node 700A may generate, based on the initial block height on the service branch chain 71q, the chain identifier 710s corresponding to the initial block height on the service branch chain 71q, the initial block height on the service branch chain 72q, and the chain identifier 720s corresponding to the initial block height on the service branch chain 72q, the block synchronization request for transmission to the agent node 700B, such that the agent node 700B may forward the block synchronization request to the consensus node 700C.
Further, the consensus node 700C may determine, based on the initial block height and the chain identifier corresponding to the initial block height in the block synchronization request, a to-be-synchronized block for synchronization to the service node corresponding to the configured node identifier. For example, the consensus node 700C may determine a maximum block height on the service branch chain 71Q based on the chain identifier 710s corresponding to the initial block height on the service branch chain 71q, and further determine, based on the initial block height on the service branch chain 71q and the maximum block height on the service branch chain 71Q, a to-be-synchronized block (for example, a block B5) for synchronization to the service branch chain 71q. Meanwhile, the consensus node 700C may determine a maximum block height on the service branch chain 72Q based on the chain identifier 720s corresponding to the initial block height on the service branch chain 72q, and further determine, based on the initial block height on the service branch chain 72q and the maximum block height on the service branch chain 72Q, a to-be-synchronized block (for example, a block C6 and a block C7) for synchronization to the service branch chain 72q.
Further, the consensus node 700C may transmit the to-be-synchronized block (that is, the block B5, the block C6, and the block C7) on each service branch chain to the service node 700A through the agent node 700B. When receiving the to-be-synchronized block, the service node 700A may verify the to-be-synchronized block. Since the partial block data on the basic main chain 70Q in the core consensus network is synchronized in the service node 700A, when receiving the to-be-synchronized block, the service node 700A needs to perform verification till a genesis block of the corresponding service branch chain. For example, when verifying the to-be-synchronized block (for example, the block B5) on the service branch chain 71q, the service node 700A needs to successfully find a genesis block (that is, the block header a2) of the service branch chain 71q on the basic main chain 70Q from the block B5, that is, needs to find the block header b4 based on a parent block hash value of the block B5 and then find the block b3 based on a parent block hash value of the block header b4. When the block header a2 is successfully found based on a parent block hash value of the block header b3, verification succeeds.
Certainly, if the partial block data on the basic main chain 70Q in the core consensus network is not synchronized in the service node 700A, when verifying the to-be-synchronized block on the service branch chain 71Q, the service node 700A needs not only to successfully find a genesis block (that is, the block header a2) of the service branch chain 71q on the basic main chain 70Q from the block B5 but also to find a genesis block of the basic main chain 70Q. That is, the service node 700A needs to find the block header b4 based on a parent block hash value of the block B5, then find the block b3 based on a parent block hash value of the block header b4, then successfully find the block header a2 based on a parent block hash value of the block header b3, and further successfully find the block header a1 based on a parent block hash value of the block header a2. When a block header of the genesis block is successfully found based on a parent block hash value of the block header a1, verification succeeds.
Further, when successfully verifying the to-be-synchronized block on each service branch chain, the service node 700A may write partial block data of the to-be-synchronized block (that is, block header data of the to-be-synchronized block and an associated service transaction) on each service branch chain to the corresponding service branch chain in the local blockchain.
It is to be understood that when having a supervision permission, the target consensus node in the core consensus network may obtain configuration change information (for example, a changed supervision rule) associated with the blockchain network, and further generate, based on the configuration change information, a configuration change block for writing to the basic main chain. Further, the target consensus node may broadcast the configuration change block to the core consensus network, such that the consensus node in the core consensus network performs consensus on the configuration change block. The configuration change block is used for instructing all the consensus nodes in the core consensus network to stop running. This means that when receiving the configuration change block, all the consensus nodes in the core consensus network need not only to perform consensus on the configuration change block but also to stop operations such as consensus and blocking on all the service branch chains.
The target consensus node may receive a second block consensus result returned by the consensus node in the core consensus network for the configuration change block, and further perform result analysis on the second block consensus result. If the second block consensus result indicates that consensus fails, the target consensus node may determine that configuration information is temporarily not changed in a blockchain node system corresponding to the current blockchain network, further generate resume notification information for broadcasting to the core consensus network, and broadcast the resume notification information to all the consensus nodes, such that all the consensus nodes in the core consensus network resume running. Alternatively, if the second block consensus result indicates that consensus succeeds, the target consensus node may write the configuration change block to the basic main chain. Meanwhile, the target consensus node may further perform block synchronization on all the service branch chains in the core consensus network based on the configuration change block that has been written to the basic main chain. When the configuration change block is successfully synchronized on all the service branch chains in the core consensus network, the resume notification information for broadcasting to the core consensus network is generated, and the resume notification information is further broadcast to all the consensus nodes, such that all the consensus nodes in the core consensus network resume running.
As shown in
Based on this, when having the supervision permission, the target consensus node (for example, the node 120a shown in
Meanwhile, the node 120a may further perform block synchronization respectively on all the service branch chains in the core consensus network based on the block A4. For example, after writing the configuration change block (for example, the block A4) to the basic main chain 10Q, the node 120a may perform block synchronization on the service branch chain 11Q. The node 120a may obtain a block (for example, the block B4) corresponding to a maximum generation timestamp on the service branch chain 11Q, replace the block hash value of the block A3 with a block hash value of the block B4 as the parent block hash value in the configuration change block, and further write a configuration change block after replacement to the service branch chain 11Q, that is, determine the configuration change block after replacement as a next block of the block B4 (for example, the block B5), so as to complete block synchronization on the service branch chain 11Q.
In addition, after writing the configuration change block (for example, the block A4) to the basic main chain 10Q, the node 120a further needs to perform block synchronization on the service branch chain 12Q. The node 120a may obtain a block (for example, the block C4) corresponding to a maximum generation timestamp on the service branch chain 12Q, replace the block hash value of the block A3 with a block hash value of the block C4 as the parent block hash value in the configuration change block, and further write a configuration change block after replacement to the service branch chain 12Q, that is, determine the configuration change block after replacement as a next block of the block C4 (for example, the block C5), so as to complete block synchronization on the service branch chain 12Q.
When the configuration change block is successfully synchronized on all the service branch chains (that is, the service branch chain 11Q and the service branch chain 12Q) in the core consensus network, the node 120a may generate resume notification information for broadcasting to the core consensus network, and further broadcast the resume notification information to all the consensus nodes in the core consensus network, such that all the consensus nodes in the core consensus network resume running.
Further, when the target consensus node in the core consensus network has the supervision permission, the target consensus node may further create a new transaction service on the basic main chain in the core consensus network. For example, the target consensus node may determine a next transaction service of N transaction services as a to-be-created service, and obtain service registration information associated with the to-be-created service. The service registration information may include a to-be-derived chain identifier of a to-be-derived service branch chain corresponding to the to-be-created service, service configuration information of the to-be-created service, and a derivation condition corresponding to the to-be-derived chain identifier. The to-be-derived chain identifier is different from a chain identifier corresponding to each of the N service branch chains in the core consensus network.
It may be understood that the target consensus node may obtain, from the basic main chain, a smart contract for performing branch registration on the to-be-derived service branch chain, and further invoke the smart contract to perform packing processing on the service registration information to generate a branch chain registration block for broadcasting to the core consensus network. When the branch chain registration block is successfully written to the basic main chain, the target consensus node may determine the to-be-derived service branch chain as an (N+1)th service branch chain derived from the basic main chain. Thus, it can be seen that in the embodiments of this application, when the blockchain node system corresponding to the blockchain network stably runs, different transaction services may be gradually added to the blockchain node system. In this way, a transaction service corresponding to each service branch chain may be created when an adequate preparation is made, thereby effectively solving a problem of the entire system caused by desynchronization.
Further, refer to
It may be understood that when the blockchain is used for some scenarios of a government (for example, a taxation system) or a commercial organization, a layered blockchain structure of “service network-core consensus network” in this embodiment of this application may be used if the blockchain system involves related data of personal privacies, national security, or the like, so as to improve confidentiality and security of the data. The diagram of the system architecture may be applied to various sub-services (transaction services) associated with a taxation service, for example, a bill service, a blocking service, a legal person service, a credit information service, and a tax refund service. One transaction service may correspond to one service branch chain. One service branch chain may correspond to one chain identifier. In this way, different transaction services can be effectively distinguished to ensure uniformity of transaction storage on a single service branch chain.
As the entire taxation service may involve a supervision organization, a drawer, a reimbursement party, a tax declaration party, and the like, service nodes in the service network shown in
The agent node in the routing agent network may be configured to perform network isolation on the service network and the core consensus network. The agent node may have a P2P service (that is, a P2P service), a routing service, a certificate cache, and an authentication service. It may be understood that the P2P service is a service in a P2P network. Based on a specific type of network protocol, no center node is needed to maintain a network status between network nodes in the P2P network, and instead, each node performs broadcasting interaction with an adjacent node to maintain a node status of the entire network or a connection status of the adjacent node. The routing service is a basic function of the node, and may be used for communication between nodes, so as to perform network isolation on the service network and the core consensus network. The certificate cache is used for caching an identity certificate of each node. The certificate herein may be a public key infrastructure (PM). In the PM, the certificate is a proof of an identity of a public key owner, and is authorized by a certificate authority (CA). Asymmetric encryption and a digital signature of information may be implemented based on the PM. The PM herein may include public and private key passwords, an x509 certificate, a CA certificate signing center, and the like. The authentication service may be used for performing identity verification and the like on the service node in the service network. It may be understood that in this embodiment of this application, the agent node may be configured to record independent consensus node information of an independent consensus node in the core consensus network. The independent consensus node information may be used for instructing the agent node to determine, from the N branch chain independent consensus networks in the core consensus network when receiving a service request (including a transaction uploading request and a block synchronization request) transmitted by the service node in the service network, a target independent consensus network corresponding to a chain identifier carried in the service request, and further forward the service request to the target consensus node in the target independent consensus network, such that the target consensus node performs independent processing according to the chain identifier in the service request. In this case, the target consensus node is the second consensus node with the second consensus permission. Since data of the service branch chain is of a small size, and may not be fused with another service branch chain, the target consensus node may independently process the service request more conveniently.
A consensus node (that is, an accounting node) in the core consensus network may be a trusted node in a taxation private network, and may invoke a permission contract (for example, a smart contract) to determine its own consensus responsibility. The permission contract herein further stores a circulation logic about an entire life cycle of an electronic bill, for example, a bill status of the electronic bill, a circulation process, a data access permission, an application condition for the electronic bill, or an issuing condition of the electronic bill. For example, the target consensus node in the core consensus network may receive the transaction and the target chain identifier corresponding to the transaction, which are forwarded by the agent node, store, based on the target chain identifier when the transaction is successfully verified, the transaction to a cache (that is, a node transaction pool in the core consensus network) shown in
Further, refer to
The receiving module 11 is configured to receive a transaction and a target chain identifier corresponding to the transaction, which are transmitted by a service node in a service network. The target chain identifier belongs to M chain identifiers configured by the core consensus network for the service node. The M chain identifiers belong to chain identifiers of N service branch chains registered in the core consensus network. M is a positive integer less than or equal to N. One service branch chain corresponds to one transaction service. One service branch chain corresponds to one chain identifier. Each of the N service branch chains is derived according to a derivation condition on a basic main chain in the core consensus network. Both the service network and the core consensus network are subnetworks in a blockchain network.
The receiving module 11 includes a transaction uploading request obtaining unit 111, a signature verification unit 112, a transaction verification unit 113, and a target chain identifier obtaining unit 114.
The transaction uploading request obtaining unit 111 is configured to obtain a transaction uploading request forwarded by an agent node in a routing agent network. The routing agent network is a subnetwork in the blockchain network. The routing agent network is configured to perform network isolation on the service network and the core consensus network in the blockchain network. The transaction uploading request is generated by the service node in the service network. The transaction uploading request includes the transaction, the target chain identifier corresponding to the transaction, transaction signature information corresponding to the transaction, and a node identifier of the service node. The transaction signature information is obtained by the service node by signing the transaction based on a node private key of the service node.
The signature verification unit 112 is configured to obtain a node public key of the service node, and perform signature verification on the transaction signature information based on the node public key of the service node to obtain a signature verification result.
The transaction verification unit 113 is configured to perform, when the signature verification result indicates that signature verification succeeds, transaction verification on the transaction based on the target chain identifier and the node identifier of the service node to obtain a transaction verification result.
The transaction verification unit 113 includes a check registration information obtaining subunit 1131, an identifier searching subunit 1132, and a transaction verification result determining subunit 1133.
The check registration information obtaining subunit 1131 is configured to obtain, in the case that the signature verification result indicates that signature verification succeeds, registration information associated with the service branch chain corresponding to the target chain identifier from the basic main chain, and determine the obtained registration information as check registration information.
The identifier searching subunit 1132 is configured to obtain service node configuration information in the check registration information, and search in the service node configuration information for a configured node identifier matched with the node identifier of the service node. A service node corresponding to the configured node identifier is configured by the core consensus network for the service branch chain corresponding to the target chain identifier. The service node corresponding to the configured node identifier is configured to perform a transaction service corresponding to the target chain identifier.
The transaction verification result determining subunit 1133 is configured to obtain, when the service node configuration information includes the configured node identifier matched with the node identifier of the service node, a transaction verification result for indicating that transaction verification succeeds.
Specific implementations of the check registration information obtaining subunit 1131, the identifier searching subunit 1132, and the transaction verification result determining subunit 1133 may refer to the descriptions about transaction verification on the transaction in the embodiment corresponding to
The target chain identifier obtaining unit 114 is configured to determine, when the transaction verification result indicates that transaction verification succeeds, that the transaction uploading request is a valid request, and obtain the transaction and the target chain identifier from the transaction uploading request.
Specific implementations of the transaction uploading request obtaining unit 111, the signature verification unit 112, the transaction verification unit 113, and the target chain identifier obtaining unit 114 may refer to the descriptions about step S101 in the embodiment corresponding to
The to-be-verified block packing module 12 is configured to perform packing processing on the transaction based on a derivation condition corresponding to the target chain identifier to obtain a to-be-verified block for broadcasting to the core consensus network, and transmit the to-be-verified block to a consensus node in the core consensus network based on the target chain identifier, such that the consensus node performs block consensus on the to-be-verified block. The derivation condition corresponding to the target chain identifier is used for determining, in the basic main chain, a genesis block of a service branch chain corresponding to the target chain identifier.
The to-be-verified block packing module 12 includes a to-be-processed transaction obtaining unit 121, a to-be-verified block packing unit 122, and a to-be-verified block transmission unit 123.
The to-be-processed transaction obtaining unit 121 is configured to obtain a service transaction with a same chain identifier as the target chain identifier from a node transaction pool of the core consensus network, and determine the obtained service transaction as a to-be-processed transaction. The to-be-processed transaction includes the transaction.
The to-be-verified block packing unit 122 is configured to perform packing processing on the to-be-processed transaction based on the derivation condition corresponding to the target chain identifier to obtain the to-be-verified block for broadcasting to the core consensus network.
The to-be-verified block packing unit 122 includes a block type recognition subunit 1221, a parent block hash value determining subunit 1222, a block hash value determining subunit 1223, and a block packing subunit 1224.
The block type recognition subunit 1221 is configured to determine the service branch chain corresponding to the target chain identifier as a target service branch chain, and recognize a block type of the to-be-verified block to be generated on the target service branch chain.
The parent block hash value determining subunit 1222 is configured to determine a parent block of the to-be-verified block based on the block type and the derivation condition corresponding to the target chain identifier, and determine a block hash value of the parent block of the to-be-verified block as a parent block hash value of the to-be-verified block.
The block type includes a first block type. The first block type is used for indicating that the parent block of the to-be-verified block is a block on the basic main chain.
The parent block hash value determining subunit 1222 is further configured to: obtain, when the block type is the first block type, target registration information associated with the target service branch chain from the basic main chain, and obtain the derivation condition corresponding to the target chain identifier from the target registration information;
The block type includes a second block type. The second block type is used for indicating that the parent block of the to-be-verified block is not a block on the basic main chain.
The parent block hash value determining subunit 1222 is further configured to: obtain, when the block type is the second block type, a block with a maximum generation timestamp from the target service branch chain indicated by the derivation condition corresponding to the target chain identifier, and determine the block with the maximum generation timestamp as the parent block of the to-be-verified block; and obtain the block hash value of the parent block of the to-be-verified block, and determine the obtained block hash value as the parent block hash value of the to-be-verified block.
The block hash value determining subunit 1223 is configured to perform transaction hash transformation on the to-be-processed transaction to obtain a transaction hash value corresponding to the to-be-processed transaction, and determine a block hash value of the to-be-verified block based on the transaction hash value.
The block packing subunit 1224 is configured to perform packing processing on the to-be-processed transaction, the block hash value, and the parent block hash value to obtain the to-be-verified block to be written to the target service branch chain.
Specific implementations of the block type recognition subunit 1221, the parent block hash value determining subunit 1222, the block hash value determining subunit 1223, and the block packing subunit 1224 may refer to the descriptions about the to-be-verified block in the embodiment corresponding to
The to-be-verified block transmission unit 123 is configured to transmit the to-be-verified block to a part consensus node in the core consensus network based on the target chain identifier. The consensus node is configured to perform consensus on a transaction service corresponding to the target chain identifier.
Specific implementations of the to-be-processed transaction obtaining unit 121, the to-be-verified block packing unit 122, and the to-be-verified block transmission unit 123 may refer to the descriptions about step S102 in the embodiment corresponding to
The to-be-verified block writing module 13 is configured to receive a first block consensus result returned by the consensus node for the to-be-verified block, and write, based on the genesis block when the first block consensus result indicates that consensus succeeds, the to-be-verified block to the service branch chain corresponding to the target chain identifier.
The service registration information obtaining module 14 is configured to determine a next transaction service of N transaction services as a to-be-created service, and obtain service registration information associated with the to-be-created service. The service registration information includes a to-be-derived chain identifier of a to-be-derived service branch chain corresponding to the to-be-created service, service configuration information of the to-be-created service, and a derivation condition corresponding to the to-be-derived chain identifier. The to-be-derived chain identifier is different from a chain identifier corresponding to each of the N service branch chains.
The registration block packing module 15 is configured to obtain, from the basic main chain, a smart contract for performing branch registration on the to-be-derived service branch chain, and invoke the smart contract to perform packing processing on the service registration information to generate a branch chain registration block for broadcasting to the core consensus network.
The registration block writing module 16 is configured to determine, when the branch chain registration block is successfully written to the basic main chain, the to-be-derived service branch chain as an (N+1)th service branch chain derived from the basic main chain.
The target consensus node has a first consensus permission. A node transaction pool of the target consensus node includes N transaction sets. One transaction set is used for storing a service transaction with a same chain identifier.
The transaction storage module 17 is configured to determine, in the case that the transaction verification result indicates that transaction verification succeeds, a target transaction set corresponding to the target chain identifier from the N transaction sets, and store the transaction to the target transaction set.
The target registration information obtaining module 18 is configured to obtain, when the to-be-verified block is successfully written to the service branch chain corresponding to the target chain identifier, target registration information associated with the service branch chain corresponding to the target chain identifier from the basic main chain, and obtain service node configuration information corresponding to the target chain identifier from the target registration information.
The target block height transmission module 19 is configured to transmit the service node configuration information and a target block height of the to-be-verified block to an agent node in a routing agent network, such that the agent node forwards the target block height to a service node corresponding to a configured node identifier in the service node configuration information. The target block height is used for instructing the service node corresponding to the configured node identifier to generate a block synchronization request based on an initial block height on a local blockchain and a chain identifier corresponding to the initial block height. The routing agent network is a subnetwork in the blockchain network. The routing agent network is configured to perform network isolation on the service network and the core consensus network.
The block synchronization request receiving module 20 is configured to receive the block synchronization request through the agent node, and determine, based on the initial block height and the chain identifier corresponding to the initial block height in the block synchronization request, a to-be-synchronized block for synchronization to the service node corresponding to the configured node identifier.
The to-be-synchronized block transmission module 21 is configured to transmit the to-be-synchronized block to the service node corresponding to the configured node identifier through the agent node, such that the service node corresponding to the configured node identifier writes the to-be-synchronized block to a corresponding service branch chain in the local blockchain when the to-be-synchronized block is successfully verified.
The configuration change block generation module 22 is configured to obtain, when there is a supervision permission, configuration change information associated with the blockchain network, generate, based on the configuration change information, a configuration change block for writing to the basic main chain, and broadcast the configuration change block to the core consensus network, such that the consensus node in the core consensus network performs consensus on the configuration change block. The configuration change block is used for instructing all consensus nodes in the core consensus network to stop running.
The configuration change block writing module 23 is configured to receive a second block consensus result returned by the consensus node for the configuration change block, and write, when the second block consensus result indicates that consensus succeeds, the configuration change block to the basic main chain.
The configuration change block synchronization module 24 is configured to perform block synchronization respectively on all service branch chains in the core consensus network based on the configuration change block, generate, when the configuration change block is successfully synchronized on all the service branch chains, resume notification information for broadcasting to the core consensus network, and broadcast the resume notification information to all the consensus nodes, such that all the consensus nodes resume running.
The blockchain network includes a routing agent network. An agent node in the routing agent network is configured to record independent consensus node information of an independent consensus node in the core consensus network. The independent consensus node information is used for instructing the agent node to determine, from N branch chain independent consensus networks in the core consensus network in response to receiving a service request transmitted by the service node, a target independent consensus network corresponding to a chain identifier carried in the service request, and forward the service request to the target consensus node with a second consensus permission in the target independent consensus network. The service request includes a transaction uploading request. The transaction uploading request carries the transaction and the target chain identifier corresponding to the transaction.
Specific implementations of the receiving module 11, the to-be-verified block packing module 12, the to-be-verified block writing module 13, the service registration information obtaining module 14, the registration block packing module 15, the registration block writing module 16, the transaction storage module 17, the target registration information obtaining module 18, the target block height transmission module 19, the block synchronization request receiving module 20, the to-be-synchronized block transmission module 21, the configuration change block generation module 22, the configuration change block writing module 23, and the configuration change block synchronization module 24 may refer to the descriptions about step S201 to step S207 in the embodiment corresponding to
Further, refer to
In the computer device 1000 shown in
It is to be understood that the computer device 1000 described in this embodiment of this application may execute the descriptions about the data processing methods in the embodiments corresponding to
An embodiment of this application also provides one or more non-transitory computer-readable storage media. The computer-readable storage medium stores computer-readable instructions. The computer-readable instructions include program instructions. The program instructions are executed by a processor to implement the data processing methods including each step in
The computer-readable storage medium may be an internal storage unit of the data processing apparatus or the computer device provided in any one of the foregoing embodiments, such as a hard disk or an internal memory of the computer device. The computer-readable storage medium may alternatively be an external storage device of the computer device, such as a plug-in hard disk, a smart media card (SMC), a secure digital (SD) card, or a flash card on the computer device. Further, the computer-readable storage medium may alternatively include both an internal storage unit and an external storage device of the computer device. The computer-readable storage medium is configured to store the computer-readable instructions and another program and data that are needed by the computer device. The computer-readable storage medium may further be configured to temporarily store data that has been outputted or is to be output.
An aspect of this application provides a computer program product. The computer program product includes computer-readable instructions. The computer-readable instructions are stored in a computer-readable storage medium. One or more processors of a computer device read the computer-readable instructions from the computer-readable storage medium. The one or more processors execute the computer-readable instructions, such that the computer device execute the descriptions about the data processing method in the embodiment corresponding to
It may be understood by a person of ordinary skill in the art that all or some processes in the method of the foregoing embodiments may be completed by computer-readable instructions by instructing related hardware. The program may be stored in a computer-readable storage medium. When the program is executed, the processes of each method embodiment may be included. The storage medium may be a magnetic disk, an optical disk, a read-only memory (ROM), a RAM, or the like.
The above is only the preferred embodiment of this application and certainly not intended to limit the scope of this application. Therefore, equivalent variations made according to the claims of this application also fall within the scope of this application.
In this application, the term “unit” or “module” in this application refers to a computer program or part of the computer program that has a predefined function and works together with other related parts to achieve a predefined goal and may be all or partially implemented by using software, hardware (e.g., processing circuitry and/or memory configured to perform the predefined functions), or a combination thereof. Each unit or module can be implemented using one or more processors (or processors and memory). Likewise, a processor (or processors and memory) can be used to implement one or more modules or units. Moreover, each module or unit can be part of an overall module that includes the functionalities of the module or unit.
Number | Date | Country | Kind |
---|---|---|---|
202110965200.0 | Aug 2021 | CN | national |
This application is a continuation application of PCT Patent Application No. PCT/CN2022/105391, entitled “DATA PROCESSING METHOD AND APPARATUS, COMPUTER DEVICE, AND STORAGE MEDIUM” filed on Jul. 13, 2022, which claims priority to Chinese Patent Application No. 202110965200.0, entitled “DATA PROCESSING METHOD AND APPARATUS, COMPUTER DEVICE, AND STORAGE MEDIUM” filed with the China National Intellectual Property Administration on Aug. 23, 2021, all of which is incorporated herein by reference in its entirety.
Number | Date | Country | |
---|---|---|---|
Parent | PCT/CN2022/105391 | Jul 2022 | US |
Child | 18206028 | US |