CN110619520A

CN110619520A - Block chain system and routing method of routing node applied to block chain system

Info

Publication number: CN110619520A
Application number: CN201810636486.6A
Authority: CN
Inventors: 程强
Original assignee: Shenzhen Red Brick Square Technology Co Ltd
Current assignee: Shenzhen Red Brick Square Technology Co Ltd
Priority date: 2018-06-20
Filing date: 2018-06-20
Publication date: 2019-12-27
Anticipated expiration: 2038-06-20
Also published as: CN110619520B; WO2019242508A1

Abstract

The embodiment of the application discloses a blockchain system and a routing method applied to a routing node of the blockchain system. The system comprises at least one parallel chain, the parallel chain comprises routing nodes, at least one miner node and at least one simplified payment verification SPV node, each miner node of each parallel chain adopts a distributed data block chain to store data, the routing nodes of the at least one parallel chain are connected through a network, the parallel chain corresponding to the account address bound by the SPV node is the parallel chain where the SPV node is located, and a specific implementation mode of the system comprises the following steps: the routing node checks and forwards the received transaction request to the same-chain miner node or the different-link routing node, and synchronizes the block chain of the same-chain miner node of the routing node to the local block chain in real time; and the miner node verifies the signed transaction request received by the node from the same link and joins the local pending transaction request set. This embodiment increases the number of transactions per second for the blockchain system.

Description

Block chain system and routing method of routing node applied to block chain system

Technical Field

The embodiment of the application relates to the technical field of computers, in particular to a blockchain system and a routing method applied to a routing node of the blockchain system.

Background

The block chain is a Decentralized shared general ledger (Decentralized shared ledger) which combines data blocks into a specific data structure in a chain manner according to a time sequence and is cryptographically guaranteed to be non-falsifiable and non-falsifiable. The block chain can safely store simple data which have precedence relationship and can be verified in the system.

The blockchain system is a system that stores data using blockchains. Currently, most blockchain systems generally have the following characteristics: decentralized, non-falsifiable, verifiable, anonymous. However, the block chain system currently has the problems of long waiting time for one transaction to be confirmed (for example, one hour of waiting time Per transaction in bitcoin system) and low TPS (for example, 7 Transactions Per Second in bitcoin system) due to the limitation of block output speed and capacity Per block (for example, one block Per 10 minutes in bitcoin system on average, and 1 megabyte of capacity Per block).

Disclosure of Invention

The embodiment of the application provides a blockchain system and a routing method applied to a routing node of the blockchain system.

In a first aspect, an embodiment of the present application provides a blockchain system, where the system includes at least one parallel chain, where the parallel chain includes routing nodes, at least one miner node, and at least one simplified payment verification SPV node, where each miner node of each parallel chain stores data using a distributed data blockchain, the routing nodes of the at least one parallel chain are connected to each other via a network, and the parallel chain corresponding to an account address bound to the SPV node is the parallel chain where the SPV node is located, where: the SPV node is configured to: responding to the received transaction request, and sending the received transaction request to a routing node of a parallel chain where the SPV node is located; the routing node is configured to: responding to the received transaction request, checking the transaction request, adding the received transaction request into the transaction request set of the routing node, signing the received transaction request, and broadcasting the signed transaction request to the same-chain miner node of the routing node; synchronizing the block chain of the same-chain miner node of the routing node to the local block chain in real time; the miner node is configured to: in response to the verification of the signed transaction request received from the same link node passing, adding the intra-chain transaction request of the miner node in the signed transaction request to a pending transaction request set of the miner node; the routing node is configured to: determining an unsettled transaction request which is confirmed to be billed and unsettled in the transaction request set of the routing node; sending the determined unsettled transaction request to a routing node of a target parallel chain, wherein the target parallel chain is a parallel chain corresponding to an account number address in the determined unsettled transaction request; and in response to receiving the transaction request sent by the different-link routing node, the received transaction request is signed and then broadcast to the same-link miner nodes of the routing node.

In some embodiments, a trusted execution environment is disposed in the miner node, and a node identifier for uniquely identifying the miner node is stored in the trusted execution environment of the miner node.

In some embodiments, the mineworker node is bound with an account address; and the miner node is configured to: in response to competing the accounting right to the parallel chain where the miner node is located, performing the following accounting operation: selecting a transaction request to be processed from the transaction request set to be processed of the miner node; generating a new block by using the selected to-be-processed transaction request, the mining reward information and the accounting reward information of the miner node, wherein the mining reward information and the accounting reward information of the miner node are respectively used for representing that the mining reward and the accounting reward corresponding to each expenditure transaction request in the selected to-be-processed transaction request are counted into an account address bound by the miner node; connecting the generated new block in series to the local block chain of the miner node; and broadcasting the generated new block to other co-chained miner nodes of the miner node.

In some embodiments, the account address comprises a virtual parallel chain identification and an account address string; and the miner node is configured to: in response to detecting the account address generation request, performing the following account address binding operations in the trusted execution environment of the miner node: in response to determining that the miner node does not bind the account address, generating a new account address character string as the account address character string of the miner node; according to a preset calculation formula, calculating the virtual parallel chain identification of the miner node according to the node identification of the miner node, combining the account address character string and the virtual parallel chain identification of the miner node to obtain an account address, and determining the account address obtained by combination as the account address bound by the miner node.

In some embodiments, the blockchain system includes a number N of parallel chains that is a power of 2 to the power of m, where m is a natural number between 0 and 16.

In some embodiments, the virtual parallel chain is identified as a natural number between 0 and 65535.

In some embodiments, a first preset mask is stored in the trusted execution environment of each miner node, and the first preset mask is an integer between 0 and 65535; and according to a preset calculation formula, calculating the virtual parallel chain identifier of the miner node according to the node identifier of the miner node, wherein the method comprises the following steps: and determining the result of bitwise XOR operation of the binary representation of the node identifier of the miner node and the binary representation of the first preset mask as the virtual parallel chain identifier of the miner node.

In some embodiments, the parallel chain identification used to indicate the parallel chain is a natural number between 0 and (N-1).

In some embodiments, a second preset mask is stored in the trusted execution environment of each routing node and each miner node, and the second preset mask is an integer between 0 and 65535; and the miner node is configured to: in response to detecting the mineworker network entry request, performing the following parallel chain determination operations in the trusted execution environment of the mineworker node: bitwise AND operation is carried out on the binary representation of the virtual parallel chain identifier of the miner node and the binary representation of the difference of N minus 1 to obtain an account parallel chain identifier; determining a parallel chain indicated by the account number parallel chain identification as a parallel chain corresponding to the account number address bound by the miner node; performing exclusive-or operation on the binary representation of the virtual parallel chain identifier of the miner node and the binary representation of the second preset mask according to bits to obtain an exclusive-or operation result; performing bitwise AND operation on the obtained XOR operation result and the binary expression of the difference of N minus 1 to obtain a miner parallel chain identifier; and determining the parallel chain in which the miner node is positioned as the parallel chain indicated by the miner parallel chain identification.

In some embodiments, N and m are also stored in the trusted execution environment of each miner node and in each routing node; and the routing node is further configured to: encrypting the locally stored parallel chain configuration information to obtain encrypted parallel chain configuration information, and sending the encrypted parallel chain configuration information to a same-chain miner node of the routing node, wherein the parallel chain configuration information comprises N, m and a second preset mask; and the miner node is configured to: in response to receiving encrypted parallel chain configuration information sent by a node on the same link of the mineworker node, decrypting the received encrypted parallel chain configuration information in a trusted execution environment of the mineworker node; and in response to the decrypted parallel chain configuration information passing the verification, updating the N, m and a second preset mask stored in the trusted execution environment of the miner node by using the N, m and the second preset mask in the decrypted parallel chain configuration information.

In some embodiments, the block chain system further includes a management server, the management server is connected to each routing node through a network, a preset management private key and a preset management public key are stored in the management server, and a preset management public key is stored in each routing node and each mining node; and the management server is configured to: in response to receiving a routing node management instruction input by a user, signing the routing node management instruction by using a preset management private key and then sending the routing node management instruction to a first routing node, wherein the first routing node is a routing node related to the routing node management instruction; the routing node is configured to: in response to receiving a signed routing node management instruction sent by a management server, carrying out signature verification on the received signed routing node management instruction by using a preset management public key; and executing the routing node management instruction in the received signed routing node management instruction in response to the received signed routing node management instruction passing the signature verification.

In some embodiments, the management server is configured to: in response to receiving a transaction management instruction input by a user, signing the transaction management instruction by using a preset management private key and then sending the signed transaction management instruction to a second routing node, wherein the second routing node is a parallel link routing node corresponding to an account address related to the transaction management instruction; the routing node is configured to: in response to receiving a signed transaction management instruction sent by a management server, carrying out signature verification on the received signed transaction management instruction by using a preset management public key; responding to the received signed transaction management instruction and passing the signature verification, and sending the received signed transaction management instruction to the same-chain miner node of the routing node; the miner node is configured to: in response to receiving a signed transaction management instruction sent by a node in the same link of the miner node, carrying out signature verification on the received signed transaction management instruction by using a preset management public key; and in response to the verification of the received signed transaction management command signature, adding the transaction management command in the received signed transaction management command to the local pending transaction request set.

In some embodiments, the routing node is further configured to: and in response to the detection of the preset abnormality, encrypting the abnormality-related information of the detected abnormality by using the preset management public key, and sending the encrypted abnormality-related information to the management server.

In some embodiments, the routing node is further configured to: after the routing node is started, acquiring a public key and a private key of the routing node from locally stored starting configuration information, acquiring a signed public key for signing the public key of the routing node by using a preset management private key, broadcasting the acquired signed public key to the same-chain miner node of the routing node, signing data sent to the same-chain miner node of the routing node by using the private key of the routing node, sending the signed data, and decrypting the data received from the same-chain miner node of the routing node by using the private key of the routing node; and the miner node is further configured to: in response to receiving the signed public key sent by the same link node of the miner node, carrying out signature verification on the received signed public key by using a preset management public key; in response to the fact that the signed public key passes signature verification, determining a public key in the received signed public key as a public key of a same-link routing node of the miner node; and encrypting the data sent to the same-link routing node of the miner node by using the public key of the same-link routing node of the miner node and then sending the encrypted data, and performing signature verification on the data received from the same-link routing node of the miner node by using the public key of the same-link routing node of the miner node.

In some embodiments, the routing node is configured to: and responding to the received transaction request which is not verified, and sending first prompt information to the SPV node which sends the received transaction request, wherein the first prompt information is used for indicating that the transaction request is not verified.

In some embodiments, the routing node is configured to: sending an incineration instruction corresponding to the abnormal transaction request to each same-chain miner node of the routing node for the abnormal transaction request in the transaction request set of the routing node, wherein the abnormal transaction request is a transaction request for which the charge is not confirmed within a preset time length, and the incineration instruction corresponding to the abnormal transaction request is used for indicating the miner node to reduce the charge-out account number address in the abnormal transaction request by the transfer-out amount in the abnormal transaction request; and the miner node is configured to: and executing the received burning instruction in response to receiving the burning instruction.

In some embodiments, the routing node is configured to: and monitoring the execution process of each transaction request in the transaction request set of the routing node.

In some embodiments, the domain name of a routing node is associated with a parallel chain identification of the parallel chain in which the routing node resides.

In some embodiments, the management server is configured to: and in response to receiving the capacity expansion request, expanding the capacity of the N parallel chains in the block chain system into 2N parallel chains.

In some embodiments, the miner node is configured to: in a trusted execution environment of the miner node, encrypting data of the same-chain miner node sent to the miner node by using a first key and then sending the encrypted data, wherein the first key is generated according to a parallel chain identifier of a parallel chain where the miner node is located and m; in the trusted execution environment of the miner node, data received from a co-chained miner node of the miner node is decrypted using the first key.

In some embodiments, the routing node is configured to: in response to checking the received transaction request for a pass, adding the received transaction request to the transaction request set of the routing node, including: the routing node is configured to: in response to receiving a transaction request sent by a co-link SPV node of the routing node, verifying the validity of the received transaction request; responding to the failure of the validity check, and sending second prompt information for indicating that the validity check fails to pass to the SPV node sending the received transaction request; responding to the passing of the validity check, and determining whether the routing node can receive a new transaction request according to the number of unprocessed transaction requests in the transaction request set of the routing node; and in response to the fact that a new transaction request can be received, adding the received transaction request into the transaction request set of the routing node, generating a transaction number corresponding to the received transaction request, and correspondingly storing the received transaction request, a corresponding transaction identifier and an operation process state used for representing that the account is paid out into a preset distributed database, wherein the transaction identifier corresponding to the received transaction request comprises the generated transaction number and a parallel chain identifier of a parallel chain where the routing node is located.

In some embodiments, the routing node is configured to: determining a confirmed posted transaction request in the transaction request set of the routing node; and updating the operation progress state of the confirmed posted transaction request in a preset distributed database into the posted transaction according to the confirmed transaction identifier of the posted transaction request.

In some embodiments, each parallel chain further includes an ledger node, and the ledger nodes of each parallel chain form a distributed ledger cluster; and the ledger node is configured to: synchronously storing the block chains stored in the adjacent same-chain miner nodes or the routing nodes of the account node into the local block chain of the account node in real time; responding to an account information query request sent by a received terminal, querying data in the distributed account book cluster according to the account information query request, and sending a query result to the terminal sending the account information query request.

In a second aspect, an embodiment of the present application provides a routing method applied to a routing node of a blockchain system, where the blockchain system includes at least one parallel chain, and the parallel chain includes a routing node, at least one miner node, and at least one reduced payment verification SPV node, each miner node of each parallel chain stores data using a distributed data blockchain, the routing nodes of the at least one parallel chain are connected via a network, and the parallel chain corresponding to an account address bound by the SPV node is the parallel chain where the SPV node is located, and the method includes: responding to the received transaction request, checking the transaction request, adding the received transaction request into a transaction request set of the routing node, signing the received transaction request, and broadcasting the signed transaction request to the same-chain miner node of the routing node; synchronizing the block chain of the same-chain miner node of the routing node to the local block chain in real time; determining an unsettled transaction request which is confirmed to be billed and unsettled in a transaction request set of the routing node; sending the determined unsettled transaction request to a routing node of a target parallel chain, wherein the target parallel chain is a parallel chain corresponding to an account number address in the determined unsettled transaction request; and in response to receiving the transaction request sent by the routing node of the different link, the received transaction request is signed and then is broadcasted to the same-link miner node of the routing node.

In some embodiments, a trusted execution environment is disposed in the miner node, and the blockchain system includes a number N of parallel chains that is a power m of 2, where m is a natural number between 0 and 16.

In some embodiments, N, m and a second preset mask are stored in the trusted execution environment of each miner node and each routing node, and the second preset mask is an integer between 0 and 65535; and the method further comprises: and encrypting the locally stored parallel chain configuration information to obtain encrypted parallel chain configuration information, and sending the encrypted parallel chain configuration information to the same-chain miner node of the routing node, wherein the parallel chain configuration information comprises N, m and a second preset mask.

In some embodiments, the blockchain system further includes a management server, the management server is connected to each routing node through a network, a preset management private key and a preset management public key are stored in the management server, and a preset management public key is stored in each routing node and each mining node; and the method further comprises: in response to receiving a signed routing node management instruction sent by a management server, carrying out signature verification on the received signed routing node management instruction by using a preset management public key; and executing the routing node management instruction in the received signed routing node management instruction in response to the received signed routing node management instruction passing the signature verification.

In some embodiments, the method further comprises: in response to receiving a signed transaction management instruction sent by a management server, carrying out signature verification on the received signed transaction management instruction by using a preset management public key; and responding to the verification of the received signed transaction management command signature, and sending the received signed transaction management command to the same-chain miner node of the routing node.

In some embodiments, the method further comprises: and in response to the detection of the preset abnormality, encrypting the abnormality-related information of the detected abnormality by using the preset management public key, and sending the encrypted abnormality-related information to the management server.

In some embodiments, the method further comprises: after the routing node is started, acquiring a public key and a private key of the routing node from locally stored starting configuration information, and acquiring a signed public key for signing the public key of the routing node by using a preset management private key; broadcasting the acquired signed public key to the same-chain miner node of the routing node; signing the data of the same-chain miner node sent to the routing node by using a private key of the routing node and then sending the data; and decrypting the data received from the co-chained miner node of the routing node using the private key of the routing node.

In some embodiments, the method further comprises: and responding to the received transaction request which is not verified, and sending first prompt information to the SPV node which sends the received transaction request, wherein the first prompt information is used for indicating that the transaction request is not verified.

In some embodiments, the method further comprises: and for the abnormal transaction request in the transaction request set of the routing node, sending an incineration instruction corresponding to the abnormal transaction request to each co-link miner node of the routing node, wherein the abnormal transaction request is a transaction request for which the charge is not confirmed within a preset time length, and the incineration instruction corresponding to the abnormal transaction request is used for indicating the miner node to reduce the charge account number address in the abnormal transaction request by the transfer amount in the abnormal transaction request.

In some embodiments, the method further comprises: the execution process of each transaction request in the transaction request set of the routing node is monitored.

In some embodiments, adding the received transaction request to the transaction request set of the routing node in response to checking the received transaction request for a pass, comprises: in response to receiving a transaction request sent by a co-link SPV node of a routing node, verifying the validity of the received transaction request; responding to the failure of the validity check, and sending second prompt information for indicating that the validity check fails to pass to the SPV node sending the received transaction request; responding to the passing of the validity check, and determining whether the routing node can receive a new transaction request according to the number of unprocessed transaction requests in the transaction request set of the routing node; in response to the fact that the new transaction request can be received, adding the received transaction request into a transaction request set of the routing node, generating a transaction number corresponding to the received transaction request, and correspondingly storing the received transaction request, a corresponding transaction identifier and an operation process state used for representing that the account is paid out into a preset distributed database, wherein the transaction identifier corresponding to the received transaction request comprises the generated transaction number and a parallel chain identifier of a parallel chain where the routing node is located.

In some embodiments, the method further comprises: determining a confirmed posted transaction request in a transaction request set of a routing node; and updating the operation progress state of the confirmed posted transaction request in a preset distributed database into the posted transaction according to the confirmed transaction identifier of the posted transaction request.

In a third aspect, an embodiment of the present application provides a routing node, including: one or more processors; a storage device, on which one or more programs are stored, which, when executed by the one or more processors, cause the one or more processors to implement the method as described in any implementation manner of the second aspect.

In a fourth aspect, the present application provides a computer-readable storage medium, on which a computer program is stored, where the computer program, when executed by one or more processors, implements the method as described in any implementation manner of the second aspect.

According to the block chain system provided by the embodiment of the application, the transaction processing process is improved from a single-chain serial mode to a multi-chain concurrent mode in a parallel chain mode, so that the transaction times per second are increased along with the increase of the number of parallel chains, and the TPS of the block chain system is further improved.

Drawings

Other features, objects and advantages of the present application will become more apparent upon reading of the following detailed description of non-limiting embodiments thereof, made with reference to the accompanying drawings in which:

FIG. 1 is an exemplary system architecture diagram in which one embodiment of the present application may be applied;

2A-2D are timing diagrams of one embodiment of a blockchain system according to the present application;

FIG. 3 is a flow diagram of one embodiment of a routing method applied to a routing node of a blockchain system according to the present application;

FIG. 4 is a block diagram of a computer system suitable for use in implementing a routing node of an embodiment of the present application.

Detailed Description

The present application will be described in further detail with reference to the following drawings and examples. It is to be understood that the specific embodiments described herein are merely illustrative of the relevant invention and not restrictive of the invention. It should be noted that, for convenience of description, only the portions related to the related invention are shown in the drawings.

It should be noted that the embodiments and features of the embodiments in the present application may be combined with each other without conflict. The present application will be described in detail below with reference to the embodiments with reference to the attached drawings.

Fig. 1 illustrates an exemplary system architecture 100 to which embodiments of the blockchain system and routing method applied to routing nodes of the blockchain system of the present application may be applied.

As shown in fig. 1, system architecture 100 may include parallel chains 101, 102, 103 and networks 104, 105.

Parallel chain 101 includes routing node 1011, miner nodes 1012, 1014, 1015, 1016, 1018, SPV (Simplified Payment Verification) nodes 1013, 1017, and network 1019. Network 1019 is a medium used to provide communication links between routing node 1011, miner nodes 1012, 1014, 1015, 1016, 1018, and SPV nodes 1013, 1017. The network 1019 may include various types of connections, such as wire, wireless communication links, or fiber optic cables, to name a few. The miner nodes 1012, 1014, 1015, 1016, 1018 of the parallel chain 101 store data using a distributed data blockchain. Account addresses are bound to the SPV nodes 1013 and 1017 of the parallel chain 101, and the parallel chain corresponding to the account addresses bound to the SPV nodes 1013 and 1017 is the parallel chain 101.

The parallel chain 102 includes a routing node 1021, mineworker nodes 1022, 1023, 1025, 1026, SPV node 1024, and a network 1027. The network 1027 serves to provide a medium for communication links between the routing node 1021, the mineworker nodes 1022, 1023, 1025, 1026 and the SPV node 1024. The network 1027 may include various connection types, such as wired, wireless communication links, or fiber optic cables, among others. The miner nodes 1022, 1023, 1025, 1026 of the parallel chain 102 store data using a distributed data block chain. An account address is bound to the SPV node 1024 of the parallel chain 102, and the parallel chain corresponding to the account address bound to the SPV node 1024 is the parallel chain 102.

The parallel chain 103 includes a routing node 1031, miner nodes 1032, 1033, 1035, 1036, SPV nodes 1034, 1037, and a network 1038. Network 1038 is used to provide a medium for communication links between routing nodes 1031, miner nodes 1032, 1033, 1035, 1036, and SPV nodes 1034, 1037. The network 1038 may include various connection types, such as wired, wireless communication links, or fiber optic cables, to name a few. The miner nodes 1032, 1033, 1035, 1036 of the parallel chain 103 store data using a distributed data block chain. Account addresses are bound to the SPV nodes 1034 and 1037 of the parallel chain 103, and the parallel chain corresponding to the account addresses bound to the SPV nodes 1034 and 1037 is the parallel chain 103.

A user may interact with routing node 1021 through network 1019 using SPV nodes 1013, 1017 to receive or send messages, etc. A user may also interact with routing node 1021 through network 1027 using SPV node 1024 to receive or send messages and the like. The user may also interact with routing node 1031 over network 1037 using SPV nodes 1034, 1037 to receive or send messages, etc.

SPV nodes 1013, 1017, 1024, 1034, 1037 may have installed thereon various messenger client applications such as a reduced payment verification application, a wallet application, a web browser application, a shopping-like application, a search-like application, an instant messenger, a mailbox client, social platform software, and the like. The user may use the simplified payment verification application installed on the SPV nodes 1013, 1017, 1024, 1034, 1037 to perform operations such as digital money management, money transfer, collection, balance viewing, transaction record viewing, and the like.

The SPV nodes 1013, 1017, 1024, 1034, 1037 may be hardware or software. When the SPV nodes 1013, 1017, 1024, 1034, 1037 are hardware, they may be various electronic devices having display screens, including but not limited to smart phones, tablet computers, laptop and desktop computers, and the like. When the SPV nodes 1013, 1017, 1024, 1034, 1037 are software, they may be installed in the electronic devices listed above. It may be implemented as multiple pieces of software or software modules (e.g., to provide a simplified payment verification service) or as a single piece of software or software module. And is not particularly limited herein.

It should be noted that the routing method applied to the routing nodes of the blockchain system provided in the embodiments of the present application is generally performed by the routing nodes 1011, 1021, and 1031, and accordingly, the routing devices applied to the routing nodes of the blockchain system are generally disposed in the routing nodes 1011, 1021, and 1031.

The routing nodes 1011, 1021, and 1031 may be hardware or software. When the routing nodes 1011, 1021, 1031 are hardware, they may be implemented as a distributed server cluster composed of a plurality of servers, or may be implemented as a single server. When the routing nodes 1011, 1021, 1031 are software, they may be implemented as multiple software or software modules (e.g., to provide routing services) or as a single software or software module. And is not particularly limited herein.

It should be noted that the miner nodes 1012, 1014, 1015, 1016, 1018, 1022, 1023, 1025, 1026, 1032, 1033, 1035, 1036 may be hardware or software. When the mineworker nodes 1012, 1014, 1015, 1016, 1018, 1022, 1023, 1025, 1026, 1032, 1033, 1035, 1036 are hardware, they can be implemented as a distributed server cluster consisting of a plurality of servers or as a single server. When the mineworker nodes 1012, 1014, 1015, 1016, 1018, 1022, 1023, 1025, 1026, 1032, 1033, 1035, 1036 are software, they may be implemented as multiple software or software modules (e.g., to provide mining and accounting services) or as a single software or software module. And is not particularly limited herein.

It should be understood that the number of parallel chains in fig. 1 is merely illustrative. There may be any number of parallel chains, as desired for implementation. The number of routing nodes, miners nodes, networks and SPV nodes in each parallel chain is also merely illustrative. There may be any number of routing nodes, mineworker nodes, networks, and SPV nodes, as desired for implementation.

With continued reference to fig. 2, a timing sequence 200 for one embodiment of a blockchain system according to the present application is shown.

The block chain system in the embodiment of the present application may include at least one parallel chain (e.g., the parallel chains 101, 102, 103 shown in fig. 1), where the parallel chain may include a routing node (e.g., the routing nodes 1011, 1021, 1031 shown in fig. 1), at least one mineworker node (e.g., the mineworker nodes 1012, 1014, 1015, 1016, 1018, 1022, 1023, 1025, 1026, 1032, 1033, 1035, 1036 shown in fig. 1), and at least one SPV node (e.g., the SPV nodes 1013, 1017, 1024, 1034, 1037 shown in fig. 1), where each mineworker node of each parallel chain stores data using a distributed data block chain, where the routing nodes of the at least one parallel chain are connected through a network, and the parallel chain corresponding to the account address bound by the SPV node is the parallel chain where the SPV node is located.

As shown in fig. 2, a timing sequence 200 according to one embodiment of the present application of the blockchain system includes the steps of:

step 201, in response to receiving the transaction request, the SPV node sends the received transaction request to a routing node of a parallel chain where the SPV node is located.

In this embodiment, the SPV nodes (e.g., SPV nodes 1013, 1017, 1024, 1034, 1037 shown in fig. 1) may have a simplified payment verification application installed therein. The user may submit a transaction request using a simplified payment verification application in the SPV node. Here, the transaction request is a transfer request. That is, the numbers in account address a bound by the SPV node are transferred to account address B, which is different from account address a. In this way, the SPV node may send the transaction request to the routing node of the parallel chain in which the SPV node is located in response to receiving the transaction request.

Here, each SPV node may be bound with an account address. In practice, the wallet application may be employed to generate and bind account addresses for SPV nodes.

Here, the account address bound by each SPV node is the parallel chain in which the SPV node is located. Therefore, the transaction request is sent to the routing node in the parallel chain where the SPV node is located, that is, the transaction request is sent to the routing node of the parallel chain corresponding to the account address bound to the SPV node.

In practice, various implementations may also be adopted to correspond the account address bound by the SPV node to one of the parallel chains included in the blockchain system. For example, one parallel chain may be randomly selected from parallel chains included in the blockchain system as a parallel chain corresponding to an account address bound by an SPV node.

Step 202, the routing node responds to the received transaction request and checks, adds the received transaction request to the transaction request set of the routing node, signs the received transaction request and broadcasts the signed transaction request to each same-chain miner node of the routing node.

In this embodiment, the routing node (e.g., the routing nodes 1011, 1021, 1031 shown in fig. 1) may check the received transaction request in response to receiving the transaction request sent by the SPV node in step 201. If the verification is passed, the received transaction request can be added to the transaction request set of the routing node, and the received transaction request is signed and then broadcasted to each same-chain miner node of the routing node.

Here, the verification of the received transaction request by the routing node may include, but is not limited to, performing a validity check on the transaction request. The validity check may include, but is not limited to, verifying whether a UTXO (un-spent Transaction Output) record exists in a transferred account address in the Transaction request, whether a balance of the transferred account address in the Transaction request supports the Transaction request of this time, whether the transferred account address in the Transaction request is an account address in a transferred account address blacklist stored in the routing node, whether a transferred account address in the Transaction request is an account address in a transferred account address blacklist stored in the routing node, and the like. In practice, the verification of the transaction request here may also include other verifications.

Here, the transaction request set of the routing node stores the transaction requests that the routing node passes the check.

Here, signing the received transaction request by the routing node may be signing the received transaction request with a private key of the routing node.

Here, the same-chain miner node of the routing node is a miner node belonging to the same parallel chain as the routing node. For example, as shown in FIG. 1, miner nodes 1012, 1014, 1015, 1016, 1018 are co-chained miner nodes of routing node 1011.

In practice, since each parallel chain is usually based on a Peer-to-Peer network (Peer-to-Peer, P2P), when the routing node signs the received transaction request and broadcasts it to the Peer miners of the routing node, the routing node may sign the received transaction request and broadcast it to the neighboring Peer miners of the routing node, and then the neighboring Peer miners of the routing node broadcast the signed transaction request to their respective neighboring miners.

It should be noted that, the routing node may add the received transaction request to the transaction request set of the routing node first and then broadcast the received transaction request signature to each of the same-chain miner nodes of the routing node when the transaction request received from the SPV node passes the verification, or the routing node may also sign the received transaction request and then broadcast the signed transaction request to each of the same-chain miner nodes of the routing node and then add the received transaction request to the transaction request set of the routing node when the transaction request received from the SPV node passes the verification.

In step 203, the routing node synchronizes the blockchain of the same-chain miner node of the routing node to the local blockchain in real time.

In this embodiment, a routing node (e.g., the routing nodes 1011, 1021, 1031 shown in fig. 1) also synchronizes the block chain of the same-chain miner node of the routing node to the local block chain in real time. That is, the routing node does not perform mining and accounting operations, but block chain data (ledger) of the parallel chain in which the routing node is located is synchronously stored in the routing node.

It should be noted that the routing node may execute step 203 at any time, and is not limited to execute step 203 after executing step 202.

In step 204, the miner node adds the intra-chain transaction request of the miner node in the signed transaction request to the pending transaction request set of the miner node in response to the verification of the signed transaction request received from the same link by the node passing.

In this embodiment, a mineworker node (e.g., the mineworker nodes 1012, 1014, 1015, 1016, 1018, 1022, 1023, 1025, 1026, 1032, 1033, 1035, 1036 shown in fig. 1) may, in response to receiving a signed transaction request from a same link of the mineworker node by the node, first verify the received signed transaction request. Second, if the verification passes, the miner node may add the in-chain transaction request for the miner node in the signed transaction request to the set of pending transaction requests for the miner node.

Here, the verifying the received signed transaction request by the miner node may specifically include: and carrying out signature verification on the received signed transaction request by using the public key of the same link routing node of the miner node, carrying out validity verification on the received signed transaction request if the signature verification is passed, and determining that the miner node passes the verification on the received signed transaction request if the validity verification is passed.

Here, the intra-chain transaction request of the miner node in the post-signature transaction request may specifically include the following two cases: (1) and the parallel chain corresponding to the transfer-out account address and the transfer-in account address in the signed transaction request is the parallel chain in which the miner node is positioned, and the charge-out request and the charge-in request in the signed transaction request are both in-chain transaction requests of the miner node. (2) The parallel chain corresponding to the transfer-out account number address in the signed transaction request is the parallel chain where the miner node is located, and the parallel chain corresponding to the transfer-in account number address in the signed transaction request is not the parallel chain where the miner node is located, so that the out-account request in the signed transaction request is the intra-chain transaction request of the miner node, and the in-account request in the signed transaction request is not the intra-chain transaction request of the miner node.

It should be noted that each miner node may have stored therein a set of pending transaction requests for that miner node. Each miner node belonging to the same parallel chain can compete for the accounting right of the parallel chain where the miner node is located according to a preset consensus mechanism. If a certain miner node competes for the accounting right (commonly called mining) of the parallel chain where the miner node is located, a new block can be formed by using the pending transaction requests in the pending transaction request set locally stored by the miner node, and the formed new block is quickly connected in series to the local block chain of the miner node. That is, the miner node needs to perform mining and accounting operations.

In step 205, the routing node determines an unsettled transaction request that confirms that the transaction request is billed and unsettled in the transaction request set of the routing node.

In this embodiment, the routing node may update and record, in real time, the current processing state corresponding to each transaction request in the local transaction request set, in addition to recording the transaction request in the local transaction request set.

In this embodiment, the transaction request may include an outbound request and an inbound request. For example, transaction request D is to transfer X digits from account address A to account address B. The transaction request D may include an out-of-account request D1 and an in-account request D2, where the out-of-account request D1 is to decrease the digital currency in account address a by X and the in-account request D2 is to increase the digital currency in account address B by X.

In this embodiment, since the routing nodes (e.g., the routing nodes 1011, 1021, 1031 shown in fig. 1) synchronously store the blockchain data of the parallel chain in which the routing node is located, the routing node may first query the local transaction request set for the non-billed transaction requests whose current processing states are not yet billed, and then determine whether each non-billed transaction request has confirmed the billing according to the locally and synchronously stored blockchain data. For example, the routing node may determine whether there are six or more than six blocks after the block corresponding to the posting request in the transaction request in the locally synchronously stored blockchain data, and if so, may confirm that the transaction request confirms that the posting has been posted. If the outstanding transaction request is determined to confirm outstanding, then the transaction request can be determined to be an outstanding transaction request that confirms outstanding and outstanding.

In step 206, the routing node sends the determined unsettled transaction request to the routing node of the target parallel chain.

In this embodiment, the routing node (e.g., the routing nodes 1011, 1021, 1031 shown in fig. 1) may send the outstanding transaction request determined in step 205 to the routing node of the target parallel chain. And the target parallel chain is a parallel chain corresponding to the account number address in the determined unsettled transaction request. For example, for an unsettled transaction request D: and transferring the X digital currencies in the account address A to an account address B, wherein the account address A corresponds to the parallel chain L1, and the account address B corresponds to the parallel chain L2, and here, corresponding to the step 206, the routing node of the parallel chain L1 may send the unsettled transaction request D to the routing node of the parallel chain L2.

Step 207, in response to receiving the transaction request sent by the different-link routing node, the routing node signs the received transaction request and broadcasts the signed transaction request to the same-link miner nodes of the routing node.

In this embodiment, a routing node (e.g., the routing nodes 1011, 1021, 1031 shown in fig. 1) may sign a transaction request sent by a different link routing node and broadcast the signed transaction request to a same link miner node of the routing node in response to receiving the transaction request.

Here, the different-link routing node of the routing node is a routing node in a parallel chain different from the parallel chain in which the routing node is located.

If the routing node receives the transaction request sent by the different link routing node, the routing node indicates that the different link routing node sends an unsettled transaction request which confirms that the transaction is billed and unsettled in the transaction request set of the different link routing node to the routing node. Then, the routing node may sign the received transaction request and broadcast the signed transaction request to the same-chain miner nodes of the routing node. Here, the routing node signing the transaction request may be the routing node signing using a private key of the routing node.

For example, for an unsettled transaction request D: and transferring the X digital currencies in the account address A to an account address B, wherein the account address A corresponds to the parallel chain L1, and the account address B corresponds to the parallel chain L2, and here, corresponding to the step 206, the routing node of the parallel chain L1 may send the unsettled transaction request D to the routing node of the parallel chain L2. Corresponding to step 207, the routing node, which may be the parallel chain L2, signs the outstanding transaction request D and broadcasts it to the mineworker nodes in the parallel chain L2. Thus, the mineworker node in the L2 chain may execute step 204, and if a signed transaction request D sent by the same-link routing node, i.e., the routing node in the parallel chain L2, is received, the received signed transaction request D is first verified, and if the verification is passed, the intra-chain transaction request of the mineworker node in the signed transaction request is added to the pending transaction request set of the mineworker node. In the transaction request D, the intra-chain transaction request of the miner node of the parallel chain L2 is to increase the account address B by X digital currencies.

It should be noted that the sequence 200 is only an exemplary sequence, and in practice, the execution sequence of the steps 201 to 207 may be rearranged and combined in various ways, which is not specifically limited in this application.

In some cases, the present embodiment may have the following optional implementations:

alternative implementation (one): a Trusted Execution Environment (TEE) may be set in the miner node, and a node identifier for uniquely identifying the miner node may be stored in the Trusted Execution Environment of the miner node.

Here, the TEE is a runtime environment coexisting with the Rich OS (typically, Android or the like) on the device, and provides a security service to the Rich OS. The TEE has its own execution space. The hardware and software resources that are accessible to the TEE are separate from the Rich OS. The TEE provides a secure execution environment for Trusted Applications (TAs), while also protecting the confidentiality, integrity, and access rights of the Trusted applications' resources and data. To guarantee the trusted root of the TEE itself, the TEE is authenticated and isolated from the Rich OS during secure boot. In TEE, each trusted application is independent of each other and cannot access each other without authorization.

As an example, a TEE set in a miner node may take two ways:

(1) and constructing a trusted execution environment by means of the safety protection capability provided by a specific CPU chip, such as Intel SGX, ARM Trust Zone and the like.

In order to ensure the security strength, Trusted hardware support may be added to the bottom layer of the Trusted execution environment, for example, a security chip conforming to a Trusted Platform Module (TPM) standard or a security chip conforming to a Trusted Cryptography Module (TCM) standard is used.

(2) And a trusted execution environment is realized by adopting an encryption lock (commonly called a dongle).

A typical dongle is often packaged as a compact USB (Universal Serial Bus) device that provides both file storage and supports the running of customized programs. By adopting the software dog, the equipment type of the mining machine node does not need to be limited, and the requirement on the equipment of the mining machine node is reduced as long as the mining machine node is provided with the USB interface.

Optional implementation (b): based on the above optional implementation manner (one), the ore node may further bind an account address, and the time sequence 200 may further include step 208:

and step 208, the miner node responds to the accounting right competing to the parallel chain where the miner node is positioned, and performs accounting operation.

Here, the miner node may perform a billing operation in response to competing for a billing right to the parallel chain in which the miner node is located, where the billing operation may include the following sub-steps 2081 to 2084 (not shown in fig. 2A):

substep 2081, selecting a pending transaction request from the pending transaction request set of the miner node.

Here, the miner node may employ various implementations to select a pending transaction request from a set of pending transaction requests for the miner node. For example, a first preset number (e.g., 10) of pending transaction requests may be selected in the pending transaction request set at the miner node in descending order of their billing award (also referred to as transaction fee, or transaction commission). For another example, a second preset number of pending transaction requests may also be selected from the pending transaction request set of the miner node in the order from front to back of the transaction submission time of the pending transaction requests.

Substep 2082, generating a new block using the selected pending transaction request, the mineworker node's mining incentive information, and the billing incentive information.

Here, the miner node may generate a new block using the selected pending transaction request, the mining incentive information of the miner node, and the accounting incentive information after selecting the pending transaction request. The mining reward information of the miner node is used for representing the account address bound by the miner node to which mining rewards are to be entered, and the bookkeeping reward information of the miner node is used for representing that the bookkeeping rewards corresponding to each charge-off transaction request in the selected to-be-processed transaction requests are included in the account address bound by the miner node.

Here, since the mineworker node competes for the billing right, that is, the mineworker node successfully excavates the mine, the mineworker node is rewarded with the mine excavation, that is, a specified amount of digital money is given to the account address bound by the mineworker node.

In addition, each transaction request may include an accounting reward (i.e., transaction fee) of Y coins to the mineworker node that entered the transaction request into the ledger (blockchain), in addition to the transfer of X digital currencies from account address a to account address B.

The blockchain system comprises at least one parallel chain, and the transaction requests comprise intra-chain transaction requests and cross-link transaction requests. The in-chain transaction request is a transaction request in which a parallel chain corresponding to an account number of the transaction request and a parallel chain corresponding to an account number of the transaction request are the same parallel chain, and the cross-linked transaction request is a transaction request in which the parallel chain corresponding to the account number of the transaction request and the parallel chain corresponding to the account number of the transaction request are different parallel chains. For example, for transaction request D: transferring X digital currencies in the account address A to an account address B, wherein the account address A corresponds to a parallel chain L1, the account address B corresponds to a parallel chain L2, if L1 is the same as L2, the transaction request D is an intra-chain transaction request, and if L1 is different from L2, the transaction request D is a cross-connection transaction request.

For intra-chain transaction requests: and transferring the X digital currency in the account address A of the L1 chain to the account address B of the L1 chain, wherein the corresponding accounting reward is Y digital currency. If the miner node M1 of the L1 chain competes for accounting rights to the block corresponding to the intra-chain transaction described above, the miner node M1 writes in its block: the method comprises the steps of reducing X digital currencies from an account address A, increasing X digital currencies from an account address B, increasing preset mine digging reward digital currencies from an account address bound by a miner node M1, and increasing Y digital currencies from an account address bound by a miner node M1.

For a cross-chain transaction request: and transferring the X digital currency in the account address A of the L1 chain to the account address B of the L2 chain, wherein the corresponding accounting reward is Y digital currency, and L1 is not equal to L2. Since the transaction involves bridging, the corresponding transaction is divided into an outbound transaction request: reducing X digital currencies in the account address A and the account entry transaction request: adding X digital currencies into the account address B. The out-bound transaction request is recorded in the miner node of the L1 chain and the in-bound transaction request is recorded in the miner node of the L2 chain. If the mineworker node M1 of the L1 chain competes for billing rights to the block corresponding to the above-described checkout transaction, then the mineworker node M1 writes in its block: the account address A is reduced by X digital currencies, the account address bound by the miner node M1 is increased by preset mine digging reward digital currencies, and the account address bound by the miner node M1 is increased by Y digital currencies. If the miner node M2 of the L2 chain competes for the accounting right to the block corresponding to the posting transaction, then the miner node M2 writes in its block: adding X digital currencies to the account address B, and adding a preset mine-digging reward digital currency to the account address bound by the miner node M1. Here, the miner node M2 may not receive the billing rewards for the cross-chain transaction described above. That is, the accounting rewards only give the mineworker nodes in the parallel chain corresponding to the account number address.

Substep 2083, concatenating the generated new block into the local block chain of the miner node.

Here, the miner node may generate a new block and then concatenate the generated new block into the local block chain of the miner node.

Substep 2084, broadcasting the generated new block to other co-chained miner nodes of the miner node.

Here, the miner node may broadcast the generated new block to other co-chained miner nodes of the miner node after the new block is generated.

It should be noted that, after performing sub-step 2082, the mineworker node may first perform sub-step 2083 and then perform sub-step 2084, and after performing sub-step 2082, the mineworker node may also first perform sub-step 2084 and then perform sub-step 2083, which is not limited in this application.

Alternative implementation (c): based on the above optional implementation manner (two), the account address bound by the miner node may include a virtual parallel chain identifier and an account address character string. And, the sequence 200 may further include step 209:

in step 209, the mineworker node, in response to detecting the account address generation request, performs an account address binding operation in the trusted execution environment of the mineworker node.

Here, in addition to the application for mining and accounting, in order to ensure that the mining reward and the accounting reward of the miner node can only be transferred to the unique account address bound by the miner node, an account address binding application may be installed in the trusted execution environment of the miner node. Here, the miner node may send an account address generation request each time the device is started, and the miner node may also detect an account address generation request input by the user. If the mineworker node detects the account address generation request, the mineworker node may perform an account address binding operation in a trusted execution environment of the mineworker node. Here, the account address binding operation may include sub-steps 2091 through 2094 (not shown in fig. 2A) as follows:

sub-step 2091, in response to determining that the miner node does not have an account posting address bound, generates a new account address string as the account address string for the miner node.

Here, it may first be determined at the trusted execution environment of the miner node whether the miner node binds the posting address. If it is determined that the miner node binds the posting address, no action is taken or a bound prompt may be presented indicating that the miner node binds the posting address. If the miner node is determined not to have the account address bound, various implementation manners can be adopted in the trusted execution environment of the miner node to generate a new account address character string as the account address character string of the miner node. For example, an existing wallet application may be employed to generate a 20 byte account address string.

Substep 2092, calculating the virtual parallel chain identifier of the miner node according to the node identifier of the miner node according to a preset calculation formula.

Based on the optional implementation mode (one), the trusted execution environment of the miner node stores a node identifier for uniquely identifying the miner node. Here, the virtual parallel chain identifier of the miner node may be calculated according to a preset calculation formula in the trusted execution environment of the miner node and according to the node identifier of the miner node. For example, the same virtual parallel chain identification key may be stored in the trusted execution environment of each miner node, and then the node identification of the miner node may be encrypted by using the virtual parallel chain identification key stored in the trusted execution environment of the miner node, and the encryption result is used as the virtual parallel chain identification of the miner node.

Here, what is used to indicate a parallel chain is a parallel chain identification. Each miner node belongs to a parallel chain, and therefore, the trusted execution environment of the miner node stores the parallel chain identification of the parallel chain in which the miner node is located. Here, except that the trusted execution environment of the miner node stores the parallel chain identifier of the parallel chain where the miner node is located, the trusted execution environment of the miner node may also store the virtual parallel chain identifier of the miner node, so that the virtual parallel chain identifier is required to be the virtual parallel chain identifier, so that when the number of parallel chains in the block chain system changes in the future, the identifier of the parallel chain correspondingly changes, in this process, the virtual parallel chain identifier of each miner node is not changed, but the parallel chain where each miner node is located may change, and the parallel chain identifier of the corresponding parallel chain where each miner node is located may also change. At this time, each miner node can determine the parallel chain identifier of the parallel chain where the miner node is located according to the virtual parallel chain identifier of the miner node.

Substep 2093, combining the account address character string of the miner node and the virtual parallel chain identifier to obtain an account address.

Here, after the virtual parallel chain identifier of the miner node is obtained in sub-step 2092, the account address character string and the virtual parallel chain identifier of the miner node are combined in the trusted execution environment of the miner node to obtain the account address. For example, the account address character string of the miner node may be concatenated after the virtual parallel chain identifier of the miner node to obtain the account address. For another example, the account address may be obtained by concatenating the virtual parallel link identifier of the miner node after the account address character string of the miner node.

Substep 2094, determining the account address obtained by the combination as the account address bound by the miner node.

Here, the account address obtained by combining in sub-step 2093 may be determined in the trusted execution environment of the miner node as the account address bound by the miner node.

Through sub-steps 2091 through 2094, the account address and the virtual parallel chain identification of the miner node that detected the account address generation request are determined and stored in the trusted execution environment of the miner node.

Alternative implementation (iv): the block chain system may include N, which is a natural number between 0 and 16, as the number of parallel chains to the power of m of 2. That is, 1, 2, 4, 8, 16, 32, 64, …, or 65536 parallel chains may be included in the blockchain system.

Optional implementation (v): based on the above-mentioned optional implementation (four), the virtual parallel chain identifier of the miner node may be a natural number between 0 and 65535.

Alternative implementation (iv): based on the above-mentioned optional implementation manner (five), the trusted execution environment of the miner node may store a first preset mask, where the first preset mask is an integer between 0 and 65535. Thus, in sub-step 2092, according to the preset calculation formula, calculating the virtual parallel chain identifier of the miner node according to the node identifier of the miner node, which may be performed as follows:

and determining the result of bitwise XOR operation of the binary representation of the node identifier of the miner node and the binary representation of the first preset mask as the virtual parallel chain identifier of the miner node.

Specifically, the following can be formulated:

VCN＝UID^UidMask (1)

wherein:

UID is a binary representation of the node identification of the mineworker node;

the UidMask is a first preset mask stored in a trusted execution environment of the miner node;

the VCN is the computed virtual parallel chain identification for that miner node.

In practice, the first preset mask stored in the trusted execution environment of each miner node may be the same.

Optionally, in the foregoing sub-step 2092, according to a preset calculation formula, calculating the virtual parallel chain identifier of the mineworker node according to the node identifier of the mineworker node, which may also be performed as follows:

VCN＝UID&0xFFFF (2)

wherein:

0xFFFF is a hexadecimal representation of 65535;

Alternative implementation (seven): based on the various optional implementations described above, the parallel chain identification used to indicate the parallel chain may be a natural number between 0 and (N-1), where N is the number of parallel chains in the blockchain system.

Alternative implementation (eight): based on the above optional mode (seventy), a second preset mask may be further stored in the trusted execution environment of each routing node and each miner node, where the second preset mask is an integer between 0 and 65535. And the sequence 200 may further include step 210:

in step 210, in response to detecting a mineworker networking request, the mineworker node performs a parallel chain determination operation in a trusted execution environment of the mineworker node.

Here, before mining and billing using the miner node, the user may send a miner network entry request using the miner node to determine the parallel chain in which the miner node is located. For example, the mineworker node may generate the mineworker network entry request when the user first opens an application interface that performs mining and accounting operations. In this way, the miner node may perform a parallel chain determination operation in the trusted execution environment of the miner node in response to detecting the miner's network entry request. Among other things, the parallel chain determination operation may include the following substeps 2101 to 2105 (not shown in fig. 2A):

in substep 2101, the binary representation of the virtual parallel chain identifier of the mineworker node is bitwise anded with the binary representation of the difference between N minus 1 to obtain the account parallel chain identifier.

Substep 2101 may be represented by the following equation:

ACN＝VCN&(N-1) (3)

wherein:

the VCN is the virtual parallel chain identification of the miner node;

n is the number of parallel chains included in the blockchain system;

and the ACN is the account number parallel chain identification obtained by calculation.

And a substep 2102 of determining the parallel chain indicated by the account parallel chain identification as the parallel chain corresponding to the account address bound by the miner node.

Here, the parallel chain indicated by ACN calculated in the above formula (3) may be determined as the parallel chain corresponding to the account address bound by the miner node.

And a substep 2103, performing bitwise exclusive-or operation on the binary representation of the virtual parallel chain identifier of the miner node and the binary representation of the second preset mask to obtain an exclusive-or operation result.

And a substep 2104 of performing bitwise and operation on the obtained xor operation result and a binary representation of the difference between N and 1 to obtain a miner parallel chain identifier.

Here, sub-step 2103 and sub-step 2104 taken together can be represented by the following formula:

MCN＝(VCN^MiningMask)&(N-1) (4)

wherein:

the VCN is the virtual parallel chain identification of the miner node;

n is the number of parallel chains included in the blockchain system;

a second preset mask stored in the trusted execution environment of the MiningMask of the miner node;

the MCN is the calculated identity of the miner's parallel chain.

And a substep 2105 of determining the parallel chain in which the miner node is positioned as the parallel chain indicated by the miner parallel chain identifier.

That is, the parallel chain in which the miner node is located is determined as the parallel chain indicated by the MCN calculated in the above formula.

Through substeps 2101 to 2105, a parallel chain identifier (hereinafter referred to as ACN of the miner node) of a parallel chain corresponding to the account address bound by the miner node is determined and stored in the trusted execution environment of the miner node, and a parallel chain identifier (hereinafter referred to as MCN of the miner node) of a parallel chain where the miner node is located is also determined and recorded. It should be noted that the ACN of the miner node may be the same as or different from the MCN of the miner node. The ACN of the miner node is characterized in that the mining reward and the accounting reward of the miner node are recorded in the miner node of the parallel chain indicated by the ACN of the miner node, and the MCN of the miner node is characterized in that the parallel chain identification of the parallel chain corresponding to the account number address involved in the account-out transaction and the account-in transaction recorded by the miner node.

With continued reference to fig. 2B due to page display limitations, it should be noted that the flow of fig. 2B may include various steps shown in fig. 2A in addition to the flow shown in fig. 2B.

Alternative implementation (nine): based on the above optional implementation manner (eight), the trusted execution environment of each worker node and each routing node may further store the number N and m of parallel chains included in the blockchain system, and the timing sequence 200 may further include the following step 211:

and step 211, the routing node encrypts the locally stored parallel chain configuration information to obtain encrypted parallel chain configuration information, and sends the encrypted parallel chain configuration information to the same-chain miner node of the routing node.

Here, the parallel chain configuration information may include the number of parallel chains N, m included in the block chain and a second preset mask.

Here, there is an association between m and the capacity expansion sequence number of the blockchain system.

For example, the blockchain system may have 1 parallel chain at the beginning, where m is 0, and the sequence number of the expansion is 0 without expansion. And then expanding 1 parallel chain into 2 parallel chains through one expansion, wherein m is 1, namely the expansion serial number is 1 through one expansion. And expanding the capacity of 2 parallel chains into 4 chains once, wherein m is 2, namely, the capacity expansion serial number is 2 after the secondary capacity expansion. In this case, the capacity expansion sequence number of the blockchain system is equal to m.

For another example, the blockchain system may have 16 parallel chains at the beginning, where m is 4, and the sequence number of expansion is 0 without expansion. And then, after one expansion, expanding the 16 parallel chains into 32 parallel chains, wherein m is 5, namely, after one expansion, the expansion serial number is 1. In this case, the capacity expansion sequence number of the blockchain system is equal to (m-m)₀) Wherein m is₀Is log₂N₀，N₀The number of parallel chains included in the blockchain system initially without capacity expansion.

The routing node may perform step 211 when the mineworker node first accesses the blockchain system. The routing node may further perform step 211 when the blockchain system is expanded, that is, the number of parallel chains included in the blockchain system is increased.

In step 212, the mineworker node decrypts, in the trusted execution environment, the received encrypted parallel chain configuration information in response to receiving the encrypted parallel chain configuration information sent by the same link node of the mineworker node.

It should be noted that the encryption in step 211 may be symmetric encryption or asymmetric encryption. If the asymmetric encryption is used in step 211, the public key in the preset key pair may be used for encryption in step 211, and the private key in the preset key pair may be used for decryption in step 212. If the symmetric encryption is used in step 211, the preset configuration information key may be used for encryption in step 211, and the preset configuration information key may be used for decryption in step 212. The preset configuration information key may be a preset and secure (non-disclosure) key.

And step 213, the miner node responds to the decrypted parallel chain configuration information in the trusted execution environment to verify that the decrypted parallel chain configuration information passes, and updates the N, m and the second preset mask stored in the trusted execution environment by using the N, m and the second preset mask in the decrypted parallel chain configuration information.

Here, the verifying, by the miner node, the decrypted parallel chain configuration information in the trusted execution environment may include at least one of: n in the decrypted parallel chain configuration information is twice the N stored in the trusted execution environment of the miner node, and m in the decrypted parallel chain configuration information is equal to the sum of m and 1 stored in the trusted execution environment of the miner node. If the verification passes, that the parallel chain configuration information sent by the same link of the miner node from the node can be trusted is indicated, the N, m and the second preset mask stored in the trusted execution environment of the miner node can be updated by using the N, m and the second preset mask in the decrypted parallel chain configuration information.

Alternative implementation (ten): based on the embodiment shown in fig. 2, or any one of the optional implementation manners (one) to (nine), the blockchain system may further include a management server, where the management server is connected to each routing node in each parallel chain of the blockchain system through a network, a preset management private key and a preset management public key are stored in the management server, and a preset management public key is stored in each routing node and each mining node. And the sequence 200 may further include steps 214 through 216:

in step 214, in response to receiving the routing node management instruction input by the user, the management server signs the routing node management instruction with a preset management private key and sends the routing node management instruction to the first routing node.

Here, the routing node management instruction is a management instruction that is directed to the routing node and needs to be executed by the routing node. The routing node management instructions may include, but are not limited to, instructions to: initiating online capacity expansion, adding a specified account address into a transferred account address blacklist or adding a specified account address into a transferred account address blacklist, and the like.

The user can access the preset management website through a web browser installed on the terminal to input a route management instruction, and then the terminal sends the route management instruction input by the user to the management server, wherein the management server can be a server supported by the preset management website.

The user can also input a route management instruction through a management instruction input interface of a management application installed on the terminal, and then the terminal can send the route management instruction input by the user in the management instruction input interface to the management server, wherein the management server can be a server for providing support for the management application installed on the terminal.

It will be appreciated that the user may also enter route management instructions by accessing a pre-set management website directly in the management server or using a management application.

In this way, in response to receiving the routing management instruction input by the user, the management server may first sign the received routing node management instruction using a preset management private key stored in the management server, and then send the signed routing node management instruction to the first routing node, where the first routing node is a routing node to which the routing node management instruction relates.

Step 215, the routing node, in response to receiving the signed routing node management instruction sent by the management server, performs signature verification on the received signed routing node management instruction by using a preset management public key.

In step 216, the routing node executes the routing node management instruction in the received signed routing node management instruction in response to the received signed routing node management instruction passing the signature verification.

By performing steps 214 through 216, the user may effect management of the routing node by entering route management instructions for the routing node. And then the supervision department can realize the management of the routing node through the management server.

Alternative implementation (eleven): based on the above optional implementation manner (ten), the above time sequence 200 may further include steps 217 to 221:

step 217, the management server uses a preset management private key to sign the transaction management instruction and sends the signed transaction management instruction to the second routing node in response to receiving the transaction management instruction input by the user.

Here, the transaction management instructions may include increasing the specified account address by a specified number of digital currencies or decreasing the specified account address by a specified number of digital currencies.

Here, the user may input the transaction management command by using the implementation manner described in step 214, which is not described herein again.

In this way, the management server may, in response to receiving the transaction management instruction input by the user, sign the transaction management instruction using the preset management private key and send the signed transaction management instruction to the second routing node. And the second routing node is a parallel link routing node corresponding to the account address related to the transaction management instruction.

In step 218, in response to receiving the signed transaction management instruction sent by the management server, the routing node performs signature verification on the received signed transaction management instruction by using a preset management public key.

In step 219, the routing node sends the received signed transaction management instruction to the same-chain miner node of the routing node in response to the received signed transaction management instruction passing the signature verification.

In step 220, in response to receiving the signed transaction management instruction sent by the node in the same link of the miner node, the miner node performs signature verification on the received signed transaction management instruction by using a preset management public key.

Step 221, the miner node adds the transaction management instruction in the received signed transaction management instruction to the local pending transaction request set in response to the verification of the received signed transaction management instruction signature.

By performing steps 217 through 221, the transaction management instructions entered by the user may be added to the local set of pending transaction requests for the miner node. In this way, the miner nodes may continue to perform step 208 so that miner nodes competing for billing rights may post the transaction management instructions described above in the local blockchain. And then the supervision department can realize the management of the transaction request through the management server.

Alternative implementation (twelve): based on the above optional implementation (ten) or the optional implementation (eleven), the above time sequence 200 may further include the following step 222:

in step 222, in response to detecting the preset anomaly, the routing node encrypts anomaly-related information of the detected anomaly by using the preset management public key, and sends the encrypted anomaly-related information to the management server.

Here, the preset abnormality may include, but is not limited to, the following abnormality conditions:

(1) and the expenditure exception is that the transaction request which does not finish the expenditure confirmation within the first preset time length exists in the transaction request set locally stored by the routing node.

(2) And the posting is abnormal, namely the transaction request which does not finish posting confirmation within the second preset time length exists in the transaction request set locally stored by the routing node.

The cause of the abnormality may be various causes. For example, the cause of the exception may be a program code bug (bug), a network failure, a malicious attack on the blockchain system, and so on. The cause of the abnormality is different, and the abnormality-related information is also different. For example, if the exception is caused by a program code defect, the exception-related information of the exception may include a program file name where the program code defect is located, a line number of the program code defect in the program file, a defect type of the program code defect, and the like.

Here, the routing node may encrypt abnormality-related information of the detected abnormality with a preset management public key in response to detection of the preset abnormality, and transmit the encrypted abnormality-related information to the management server.

By executing step 222, the management server may decrypt the received encrypted abnormal relevant information by using a preset management private key after receiving the encrypted abnormal relevant information. Thus, the user of the management server can determine the problem by analyzing the abnormal relevant information, and improve the block chain system according to the determined problem.

With continued reference to fig. 2C due to page display limitations, it should be noted that the flow of fig. 2C may include various steps shown in fig. 2A and 2B in addition to the flow shown in fig. 2C.

Alternative implementation (thirteen): based on step 201 to step 208 shown in fig. 2, or any of the above alternative implementations, the above time sequence 200 may further include the following steps 223 to 230:

step 223, after the routing node is started, obtaining the public key and the private key of the routing node in the locally stored start configuration information, and obtaining the signed public key obtained by signing the public key of the routing node with the preset management private key.

Here, the routing node may locally store, in advance, start configuration information, where the start configuration information includes a public key and a private key of the routing node, and a signed public key obtained by signing the public key of the routing node with a preset management private key. In this way, after the device is started for the first time or restarted, the routing node may obtain the public key and the private key of the routing node from the locally stored startup configuration information, and obtain the signed public key obtained by signing the public key of the routing node with the preset management private key.

And 224, the routing node broadcasts the acquired signed public key to the same-chain miner node of the routing node.

Here, the routing node may broadcast the signed public key obtained in step 223 to the routing node's co-chained mineworker node.

And step 225, the routing node signs the data of the same-chain miner node sent to the routing node by using the private key of the routing node and then sends the data.

Here, when data needs to be sent to the same-chain miner node of the routing node, the routing node may first sign the data sent to the same-chain miner node of the routing node by using the private key of the routing node, and then send the signed data to the same-chain miner node of the routing node.

In step 226, the routing node decrypts the data received from the routing node's co-chained miner node using the routing node's private key.

Here, the routing node may decrypt the data received from the routing node's co-chained miner node using the routing node's private key when the data is received from the routing node's co-chained miner node.

And 227, in response to receiving the signed public key sent by the node in the same link of the miner node, the miner node performs signature verification on the received signed public key by using a preset management public key.

Here, since the post-signature public key sent by the routing node to the peer-link miner node is signed by using the preset management private key, the miner node may perform signature verification on the received post-signature public key by using the preset management public key in response to receiving the post-signature public key sent by the peer-link miner node of the miner node.

In step 228, the miner node determines the public key in the received signed public key as the public key of the same link routing node of the miner node in response to the signature verification passing of the signed public key.

At step 229, the mineworker node encrypts the data sent to the same-link routing node of the mineworker node using the public key of the same-link routing node of the mineworker node.

Here, when the mineworker node needs to send data to the peer-to-peer node of the mineworker node, the mineworker node may first encrypt the data sent to the peer-to-peer node of the mineworker node by using the public key of the peer-to-peer node of the mineworker node determined in step 228, and then send the encrypted data to the peer-to-peer node of the mineworker node.

In step 230, the mineworker node performs signature verification on the data received from the same-link routing node of the mineworker node by using the public key of the same-link routing node of the mineworker node.

Here, since the data sent by the routing node to the peer-link miner node is signed by using the private key of the routing node, the miner node can use the public key of the peer-link router node of the miner node to sign and verify the received data of the peer-link miner node of the miner node when the data is received from the peer-link router node of the miner node.

By performing steps 223 through 230, encrypted communication between the routing node and the same-chain miner node of the routing node may be achieved.

With continued reference to fig. 2D below due to page display limitations, it should be noted that the flow of fig. 2D may include various steps shown in fig. 2A, 2B, and 2C in addition to the flow shown in fig. 2D.

Alternative implementation (fourteen): based on the steps 201 to 208 shown in fig. 2, or any of the above alternative implementations, the above time sequence 200 may further include the following step 231:

in step 231, the routing node sends the first hint information to the SPV node that sent the received transaction request in response to failing to verify the received transaction request.

In step 202, the routing node adds the received transaction request to the routing node's transaction request set in response to checking the received transaction request for a pass. Here, the routing node may also send the first hint information to the SPV node that sent the received transaction request in response to failing to verify the received transaction request. Wherein, the first prompt message is used for indicating that the transaction request is not verified.

By performing step 231, the user of the SPV node issuing the transaction request can know that the verification of the transaction request submitted by the user fails, so that the user of the SPV node can take corresponding measures, such as resending the transaction request, or amending the transaction request after checking what problem the transaction request has been about, and then resubmitting the transaction request.

Alternative implementation (fifteen): based on the steps 201 to 208 shown in fig. 2, or any of the above alternative implementations, the above time sequence 200 may further include the following steps 232 and 233:

in step 232, the routing node sends an incineration instruction corresponding to the abnormal transaction request to each co-chain miner node of the routing node for the abnormal transaction request in the transaction request set of the routing node.

Here, the abnormal transaction request in the transaction request set of the routing node refers to a transaction request for which the charge is not confirmed within a preset time length. The transaction requests in the transaction request set of the routing node are transaction requests which pass the verification of the routing node. Although the transaction requests in the transaction request set of the routing node are verified, in reality, various exceptions occur, so that the transaction requests cannot be confirmed to be paid out within a preset time length, for the SPV node issuing the transaction request, if the transaction request is verified to be passed and the corresponding digital currency of the transfer amount is not confirmed to be paid out, the transfer transaction in the transaction request needs to be executed forcibly.

Specifically, the routing node may send, to each co-chain miner node of the routing node, an incineration instruction corresponding to the abnormal transaction request for the abnormal transaction request in the transaction request set of the routing node. And the burning instruction corresponding to the abnormal transaction request is used for indicating the miner node to reduce the charge account number address in the abnormal transaction request by the roll-out amount in the abnormal transaction request.

Here, the transaction request confirmation charge-out may refer to that the transaction request has been verified by the routing node and stored in a transaction request set of the routing node, and the charge-out request of the transaction request confirms the charge-out. For example, the routing node may determine whether there is an operation record in the recently confirmed block that the accounting request has performed in the locally synchronously stored blockchain data. And if the operation record executed by the charge-out request exists, indicating that the charge-out request confirms the charge-out. Otherwise, if the transaction request does not exist, the routing node may wait for a preset time period (for example, 1.2 hours), and if the operation record executed by the accounting request does not exist in the last confirmed block within the preset time period, it may be confirmed that the transaction request does not confirm the accounting. The last confirmed block refers to a plurality of blocks except the last six blocks at the tail of the locally synchronously stored blockchain data, and the six blocks at the tail are removed because the blockchain system generally confirms the last confirmed block with six times of block discharge.

Here, the roll-out amount in the transaction request may include the following two parts: the amount transferred from the transfer account address to the transfer account address in the transaction request and the amount of the account award amount.

In step 233, the miner node executes the received burn-up instruction in response to receiving the burn-up instruction.

Here, the executing of the burning instruction by the miner node may include: firstly, analyzing the received burning instruction to obtain an account-out transaction request in which the account-out account number address in the abnormal transaction request is reduced by the transfer-out amount in the abnormal transaction request. The resulting posted transaction request is then added to the set of pending transaction requests for that mineworker node. Finally, the miners who compete for the accounting right in the parallel chain of the miners write the accounting transaction request into the local block chain.

By performing steps 232 and 233, the time waiting for transaction confirmation may be reduced. That is, as long as the transaction request sent by the user at the SPV node is verified by the routing node, the roll-out transaction is not reversible for the SPV node user, and the roll-out amount will be rolled out regardless of whether an abnormality occurs. For example, a user of account address a submits a transaction request for transferring X digits of account address a to account address B for purchasing a cup of coffee using a simplified payment verification application, the transaction request being submitted to and verified by a routing node. Subsequently, the user of account address a can leave with a cup of coffee in advance without waiting for the final charge-out confirmation and charge-in confirmation of the transaction request, and X digital currencies of account address a can be transferred out regardless of whether account address B confirms that X digital currencies transferred from account address a are received or not. Thereby reducing the time that the user of account address a waits for confirmation of the transaction.

Alternative implementation (sixteen): based on steps 201 to 208 shown in fig. 2, or any of the above alternative implementations, the above time sequence 200 may further include the following step 234:

in step 234, the routing node monitors the execution process of each transaction request in the transaction request set of the routing node.

Here, since the routing node synchronously stores the blockchain data of the mineworker node in the parallel chain where the routing node is located, the routing node can determine and record the current state of each transaction request in the transaction request set of the routing node by analyzing the locally synchronized blockchain data, thereby monitoring the execution process of each transaction request.

Alternative implementation (sixteen): based on steps 201 to 208 shown in fig. 2, or any of the above alternative implementations, the domain name of the routing node may be associated with the parallel chain identifier of the parallel chain in which the routing node is located.

For example, "routenodeb 0.xxx.com" is the domain name of the routing node of the parallel chain indicated by the parallel chain identification "0", "routenodeb 1.xxx.com" is the domain name of the routing node of the parallel chain indicated by the parallel chain identification "1", and "routenodeb 65535. xxx.com" is the domain name of the routing node of the parallel chain indicated by the parallel chain identification "65535"

And by adopting the optional implementation mode (sixteen), the process of determining the parallel chain where the routing node is located by the routing node can be simplified.

Alternative implementation (seventeen): based on the steps 201 to 208 shown in fig. 2, or any of the above alternative implementations, the above time sequence 200 may further include the following step 235:

in step 235, the management server expands the N parallel chains in the blockchain system into 2N parallel chains in response to receiving the expansion request.

In practice, the blockchain system will have performance as the number of SPV nodes and miners nodes increases, and for this reason, the blockchain system can be expanded, i.e. the number of parallel chains increases. Here, the capacity expansion request may be initiated on the management server by the user. In this way, the management server may expand the N parallel chains in the blockchain system to 2N parallel chains in response to receiving the expansion request. Specifically, the management server may send a routing management instruction to the routing nodes of the N parallel links of the blockchain system, so as to copy the blockchain data synchronized in the original routing nodes of the blockchain system to the newly started routing nodes, and determine the parallel links where the routing nodes are located again for each routing node.

Alternative implementation (eighteen): based on the steps 201 to 208 shown in fig. 2, or any of the above alternative implementations, the above time sequence 200 may further include the following steps 236 and 237:

and step 236, the miner node encrypts the data of the same-chain miner node sent to the miner node by using the first key and sends the encrypted data in the trusted execution environment of the miner node.

Here, when the miner node needs to send data to the co-chain miner node of the miner node, first, in the trusted execution environment of the miner node, the data sent to the co-chain miner node of the miner node is encrypted by using the first key, and then, the encrypted data is sent to the co-chain miner node of the miner node. It should be noted that, here, the calculation process of the first key is also performed in the trusted execution environment of the miner node, and the calculated first key is also stored in the trusted execution environment of the miner node, and an application outside the trusted execution environment of the miner node may not access the first key.

Here, the first key is generated according to the parallel chain identifier of the parallel chain in which the miner node is located and m. As an example, the first key may be obtained by combining the parallel chain identifier of the parallel chain in which the miner node is located, the m, and a third preset mask, where the third preset mask is stored in the trusted execution environment of each miner node.

In step 237, the miner node decrypts the data received from the co-chained miner node of the miner node in the trusted execution environment of the miner node using the first key.

Here, since the first key is generated according to the parallel chain identifier of the parallel chain in which the miner node is located and m, and the parallel chain identifier is the same for each miner node in the same parallel chain, and m is also the same, for each different miner node in the same parallel chain, the first key generated according to the parallel chain identifier of the parallel chain in which the miner node is located and m is also the same. That is, different miner nodes of the same parallel chain have the same first key. Furthermore, it should be noted that the first key is stored in the trusted execution environment of each miner node.

For the above reasons, if the mineworker node receives the data sent by the same-chain mineworker node of the mineworker node, the mineworker node may first obtain the first key in the trusted execution environment of the mineworker node, and then decrypt the data received from the same-chain mineworker node of the mineworker node by using the first key, so as to obtain the corresponding data.

Alternative implementations (nineteen): based on the steps 201 to 208 shown in fig. 2, or any of the above alternative implementations, the step 202 may include the following sub-steps 2021 to 2029:

substep 2021, in response to receiving the transaction request sent by the co-chained SPV node of the routing node, checks the validity of the received transaction request.

Here, the routing node may first check the validity of the received transaction request when receiving the transaction request sent by the co-chained SPV node of the routing node. If the validity check passes, go to substep 2022. If the validity check does not pass, go to substep 2023.

Substep 2022, sending a second prompt to the SPV node sending the received transaction request indicating that the validity check does not pass.

Here, the routing node may send second hint information indicating that the validity check is not passed to the SPV node that sent the received transaction request in case the validity check of the received transaction request in sub-step 2021 is not passed. In this way, the SPV node sending the transaction request can learn that the validity check fails, and further wait for the next operation of the user. Here, the second hint information may be the same as or different from the first hint information sent in step 231 in the alternative implementation (fourteenth).

Sub-step 2023, determining whether the routing node can receive new transaction requests based on the number of unprocessed transaction requests in the transaction request set of the routing node.

Here, the routing node may determine whether the routing node can receive a new transaction request according to the number of unprocessed transaction requests in the transaction request set of the routing node in case the legitimacy check of the received transaction request in sub-step 2021 passes. If it is determined that a new transaction request may be received, then it may proceed to substep 2024.

For example, the routing node may first determine whether the number of outstanding transaction requests in the transaction request set of the routing node is greater than a preset number of outstanding transactions. If so, determining that the routing node is not capable of receiving the new transaction request, and if not, determining that the routing node is capable of receiving the new transaction request.

Substep 2024, adding the received transaction request to the transaction request set of the routing node, generating a transaction number corresponding to the received transaction request, and storing the received transaction request, the corresponding transaction identifier and the operation process state for representing the debt into a preset distributed database.

Here, the routing node may add the received transaction request to the transaction request set of the routing node and generate a transaction number corresponding to the received transaction request, and correspondingly store the received transaction request, the corresponding transaction identifier and the operation process state for representing the billed operation process in the preset distributed database, in the sub-step 2023, if it is determined that the routing node can receive a new transaction request. And the transaction identifier corresponding to the received transaction request comprises the generated transaction number and the parallel chain identifier of the parallel chain in which the routing node is positioned.

Here, the transaction number corresponding to the transaction request may be a transaction number generated by the routing node that is not repeated and continuously incremented within the routing node. However, there may be duplication between transaction numbers in each routing node, but parallel chain identifiers of parallel chains in which each routing node is located are different, so that the transaction numbers and the parallel chain identifiers of the parallel chains in which the routing node is located can be combined to serve as transaction identifiers, and thus the transaction identifiers can uniquely identify transaction requests in the blockchain system, and the preset distributed database stores not only transaction request information and transaction identifiers of each transaction in the blockchain system, but also implements updating and stores an operation progress state of each transaction. Here, the operational process state of the transaction may include, but is not limited to: a validity check is passed, a validity check is not passed, a transaction request set has been joined to a routing node and not billed, a billed confirmed but not billed, a billed confirmed, and the like.

Alternative implementation (twenty): based on step 201 to step 208 shown in fig. 2, or any optional implementation manner described above, each parallel chain may further include an ledger node, and the ledger nodes of each parallel chain form a distributed ledger cluster. Thus, the sequence 200 may further include the following steps 238 and 239:

in step 238, the account node synchronously stores the block chains stored in the neighboring same-chain miner nodes or routing nodes of the account node into the local block chain of the account node in real time.

Here, the account node may store the blockchain stored in the neighboring co-link miner node or the routing node of the account node into the local blockchain of the account node in real time. In this way, the ledger node stores the blockchain data in each parallel chain in real time.

In step 239, in response to receiving the account information query request sent by the terminal, the ledger node queries data in the distributed ledger cluster according to the account information query request, and sends the query result to the terminal sending the account information query request.

Here, since each parallel chain of the block chain system includes the ledger node, and each ledger node stores block chain data of the corresponding parallel chain, the distributed ledger cluster can be formed by combining the ledger nodes of the respective parallel chains. Therefore, the ledger node can respond to the account information query request sent by the terminal, query data in the distributed ledger cluster according to the account information query request, and send the query result to the terminal sending the account information query request. Therefore, the block chain data of each parallel chain in the block chain system can be summarized, analyzed and inquired.

The blockchain system provided by the above embodiment of the application improves the transaction processing process from a single-chain serial mode to a multi-chain concurrent mode by adopting at least one parallel chain mode, so that the transaction frequency per second increases along with the increase of the number of parallel chains, and further improves the TPS of the blockchain system.

With further reference to fig. 3, a flow 300 of one embodiment of a routing method applied to a routing node of a blockchain system is shown. The block chain system comprises at least one parallel chain, the parallel chain comprises routing nodes, at least one miner node and at least one SPV node, each miner node of each parallel chain stores data by adopting a distributed data block chain, the routing nodes of the at least one parallel chain are connected with one another through a network, the parallel chain corresponding to the account address bound by the SPV node is the parallel chain where the SPV node is located, and the flow 300 of the routing method comprises the following steps:

step 301, in response to the received transaction request passing the verification, adding the received transaction request to the transaction request set of the routing node, and signing and broadcasting the received transaction request to the same-chain miner node of the routing node.

In this embodiment, an execution subject (e.g., the routing node shown in fig. 1) on which the routing method operates may verify a received transaction request in response to receiving the transaction request sent by an SPV node in the blockchain system. If the verification is passed, the received transaction request can be added to the transaction request set of the execution main body, and the received transaction request is signed and then broadcasted to each same-chain miner node of the execution main body.

The specific operation of step 301 in this embodiment is substantially the same as the operation of step 202 in the embodiment shown in fig. 2, and is not repeated here.

Step 302, synchronizing the blockchain of the same-chain miner nodes to the local blockchain in real time.

In this embodiment, the execution subject may synchronize the blockchain of the same-chain miner node to the local blockchain. That is, the execution main body does not perform mining and accounting operations, but block chain data (ledger) of the parallel chain in which the execution main body is located is synchronously stored in the execution main body.

It should be noted that the executing agent may execute step 302 at any time, and is not limited to execute step 302 after executing step 301.

Step 303, determining the outstanding transaction requests confirmed to be billed and not billed in the transaction request set.

In this embodiment, the execution subject may determine an unsettled transaction request that confirms that the transaction request is unsettled and billed in the transaction request set stored locally.

In this embodiment, the specific operation of step 303 is substantially the same as the operation of step 205 in the embodiment shown in fig. 2, and is not described herein again.

Step 304, sending the determined unsettled transaction request to a routing node of the target parallel chain.

In this embodiment, the execution subject may, but does not need to, send the determined unsettled transaction request to the routing node of the target parallel chain in step 303. And the target parallel chain is a parallel chain corresponding to the account number address in the determined unsettled transaction request.

In this embodiment, the specific operation of step 304 is substantially the same as the operation of step 206 in the embodiment shown in fig. 2, and is not repeated herein.

Step 305, in response to receiving the transaction request sent by the node in the different link, the received transaction request is signed and then broadcast to the same-link miner node.

In this embodiment, the executing entity may, in response to receiving the transaction request sent by the node in the different link, sign the received transaction request and broadcast the signed transaction request to the peer miner node of the executing entity.

In this embodiment, the specific operation of step 305 is substantially the same as the operation of step 207 in the embodiment shown in fig. 2, and is not repeated herein.

The routing method applied to the routing node of the blockchain system provided by the above embodiments of the present application can improve the TPS of the blockchain system by checking, signing, and forwarding a transaction request sent by an SPV node in a chain of the routing node, and synchronizing blockchain data of a same-chain mineworker node in real time.

Referring now to FIG. 4, a block diagram of a computer system 400 suitable for use in implementing a routing node of an embodiment of the present application is shown. The routing node shown in fig. 4 is only an example, and should not bring any limitation to the function and the scope of use of the embodiments of the present application.

As shown in fig. 4, the computer system 400 includes a Central Processing Unit (CPU)401 that can perform various appropriate actions and processes according to a program stored in a Read Only Memory (ROM) 402 or a program loaded from a storage section 408 into a Random Access Memory (RAM) 403. In the RAM 403, various programs and data necessary for the operation of the system 400 are also stored. The CPU 401, ROM402, and RAM 403 are connected to each other via a bus 404. An Input/Output (I/O) interface 405 is also connected to the bus 404.

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

In particular, according to an embodiment of the present disclosure, the processes described above with reference to the flowcharts may be implemented as computer software programs. For example, embodiments of the present disclosure include a computer program product comprising a computer program embodied on a computer readable medium, the computer program comprising program code for performing the method illustrated in the flow chart. In such an embodiment, the computer program may be downloaded and installed from a network through the communication section 409, and/or installed from the removable medium 411. The computer program performs the above-described functions defined in the method of the present application when executed by a Central Processing Unit (CPU) 401. It should be noted that the computer readable medium described herein can be a computer readable signal medium or a computer readable storage medium or any combination of the two. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the foregoing. More specific examples of the computer readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the present application, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. In this application, however, a computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated data signal may take many forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wire, fiber optic cable, RF, etc., or any suitable combination of the foregoing.

Computer program code for carrying out operations for aspects of the present application may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C + +, Python, and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet service provider).

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

As another aspect, the present application also provides a computer-readable medium, which may be contained in the apparatus described in the above embodiments; or may be present separately and not assembled into the device. The computer readable medium carries one or more programs which, when executed by the apparatus, cause the apparatus to: responding to the received transaction request, checking the transaction request, adding the received transaction request into a transaction request set of the routing node, signing the received transaction request, and broadcasting the signed transaction request to the same-chain miner node of the routing node; synchronizing the block chain of the same-chain miner node of the routing node to the local block chain in real time; determining an unsettled transaction request which is confirmed to be billed and unsettled in a transaction request set of the routing node; sending the determined unsettled transaction request to a routing node of a target parallel chain, wherein the target parallel chain is a parallel chain corresponding to an account number address in the determined unsettled transaction request; and in response to receiving the transaction request sent by the routing node of the different link, the received transaction request is signed and then is broadcasted to the same-link miner node of the routing node.

The above description is only a preferred embodiment of the application and is illustrative of the principles of the technology employed. It will be appreciated by those skilled in the art that the scope of the invention herein disclosed is not limited to the particular combination of features described above, but also encompasses other arrangements formed by any combination of the above features or their equivalents without departing from the spirit of the invention. For example, the above features may be replaced with (but not limited to) features having similar functions disclosed in the present application.

Claims

1. A block chain system comprises at least one parallel chain, wherein the parallel chain comprises routing nodes, at least one miner node and at least one Simplified Payment Verification (SPV) node, each miner node of each parallel chain adopts a distributed data block chain to store data, the routing nodes of the at least one parallel chain are connected through a network, and the parallel chain corresponding to an account address bound by the SPV node is the parallel chain where the SPV node is located, wherein:

the SPV node is configured to: responding to the received transaction request, and sending the received transaction request to a routing node of a parallel chain where the SPV node is located;

the routing node is configured to: responding to the received transaction request, checking the transaction request, adding the received transaction request into the transaction request set of the routing node, signing the received transaction request, and broadcasting the signed transaction request to the same-chain miner node of the routing node; synchronizing the block chain of the same-chain miner node of the routing node to the local block chain in real time;

the miner node is configured to: in response to the verification of the signed transaction request received from the same link node passing, adding the intra-chain transaction request of the miner node in the signed transaction request to a pending transaction request set of the miner node;

the routing node is configured to: determining an unsettled transaction request which is confirmed to be billed and unsettled in the transaction request set of the routing node; sending the determined unsettled transaction request to a routing node of a target parallel chain, wherein the target parallel chain is a parallel chain corresponding to an account number address in the determined unsettled transaction request; and in response to receiving the transaction request sent by the different-link routing node, the received transaction request is signed and then broadcast to the same-link miner nodes of the routing node.

2. The system according to claim 1, wherein a trusted execution environment is provided in the miner node, and a node identifier for uniquely identifying the miner node is stored in the trusted execution environment of the miner node.

3. The system of claim 2, wherein the mineworker node is bound with an account address; and

the miner node is configured to: in response to competing the accounting right to the parallel chain where the miner node is located, performing the following accounting operation: selecting a transaction request to be processed from the transaction request set to be processed of the miner node; generating a new block by using the selected to-be-processed transaction request, the mining reward information and the accounting reward information of the miner node, wherein the mining reward information and the accounting reward information of the miner node are respectively used for representing that the mining reward and the accounting reward corresponding to each expenditure transaction request in the selected to-be-processed transaction request are counted into an account address bound by the miner node; connecting the generated new block in series to the local block chain of the miner node; and broadcasting the generated new block to other co-chained miner nodes of the miner node.

4. The system of claim 3, wherein an account address comprises a virtual parallel chain identification and an account address string; and

the miner node is configured to: in response to detecting the account address generation request, performing the following account address binding operations in the trusted execution environment of the miner node: in response to determining that the miner node does not bind the account address, generating a new account address character string as the account address character string of the miner node; according to a preset calculation formula, calculating the virtual parallel chain identification of the miner node according to the node identification of the miner node, combining the account address character string and the virtual parallel chain identification of the miner node to obtain an account address, and determining the account address obtained by combination as the account address bound by the miner node.

5. The system of claim 4, wherein the blockchain system comprises a number N of parallel chains that is a power of m of 2, where m is a natural number between 0 and 16.

6. The system of claim 5, wherein a virtual parallel chain is identified as a natural number between 0 and 65535.

7. The system of claim 6, wherein a first preset mask is stored in the trusted execution environment of each of the miner nodes, the first preset mask being an integer between 0 and 65535; and

the step of calculating the virtual parallel chain identifier of the miner node according to the node identifier of the miner node according to a preset calculation formula comprises the following steps:

and determining the result of performing bitwise XOR operation on the binary representation of the node identifier of the miner node and the binary representation of the first preset mask as the virtual parallel chain identifier of the miner node.

8. The system of claim 7, wherein a parallel chain identification for indicating a parallel chain is a natural number between 0 and (N-1).

9. The system of claim 8, wherein each of the routing nodes and each of the miner nodes has a second predetermined mask stored in its trusted execution environment, the second predetermined mask being an integer between 0 and 65535; and

the miner node is configured to: in response to detecting the mineworker network entry request, performing the following parallel chain determination operations in the trusted execution environment of the mineworker node: performing bitwise AND operation on the binary representation of the virtual parallel chain identifier of the miner node and the binary representation of the difference between N and 1 to obtain an account parallel chain identifier; determining the parallel chain indicated by the account number parallel chain identification as the parallel chain corresponding to the account number address bound by the miner node; performing exclusive-or operation on the binary representation of the virtual parallel chain identifier of the miner node and the binary representation of the second preset mask according to bits to obtain an exclusive-or operation result; performing bitwise AND operation on the obtained XOR operation result and the binary expression of the difference of N minus 1 to obtain a miner parallel chain identifier; and determining the parallel chain where the miner node is positioned as the parallel chain indicated by the miner parallel chain identification.

10. The system of claim 9, wherein said N and said m are further stored in a trusted execution environment of each of said miner nodes and in each of said routing nodes; and

the routing node is further configured to: encrypting the locally stored parallel chain configuration information to obtain encrypted parallel chain configuration information, and sending the encrypted parallel chain configuration information to a same-chain miner node of the routing node, wherein the parallel chain configuration information comprises the N, the m and the second preset mask; and

the miner node is configured to: in response to receiving encrypted parallel chain configuration information sent by a node on the same link of the mineworker node, decrypting the received encrypted parallel chain configuration information in a trusted execution environment of the mineworker node; and in response to the decrypted parallel chain configuration information passing the verification, updating the N, m and a second preset mask stored in the trusted execution environment of the miner node by using the N, m and the second preset mask in the decrypted parallel chain configuration information.

11. The system of claim 10, wherein the blockchain system further comprises a management server, the management server is connected to each routing node through a network, a preset management private key and a preset management public key are stored in the management server, and each routing node and each miner node store the preset management public key; and

the management server is configured to: responding to a received routing node management instruction input by a user, signing the routing node management instruction by using the preset management private key, and then sending the routing node management instruction to a first routing node, wherein the first routing node is a routing node related to the routing node management instruction;

the routing node is configured to: in response to receiving a post-signature routing node management instruction sent by the management server, performing signature verification on the received post-signature routing node management instruction by using the preset management public key; and executing the routing node management instruction in the received signed routing node management instruction in response to the received signed routing node management instruction passing the signature verification.

12. The system of claim 11, wherein:

the management server is configured to: in response to receiving a transaction management instruction input by a user, signing the transaction management instruction by using the preset management private key and then sending the signed transaction management instruction to a second routing node, wherein the second routing node is a parallel-link routing node corresponding to an account address related to the transaction management instruction;

the routing node is configured to: in response to receiving the signed transaction management instruction sent by the management server, carrying out signature verification on the received signed transaction management instruction by using the preset management public key; responding to the received signed transaction management instruction and passing the signature verification, and sending the received signed transaction management instruction to the same-chain miner node of the routing node;

the miner node is configured to: in response to receiving a signed transaction management instruction sent by a node in the same link of the miner node, carrying out signature verification on the received signed transaction management instruction by using the preset management public key; and in response to the verification of the received signed transaction management command signature, adding the transaction management command in the received signed transaction management command to the local pending transaction request set.

13. The system of claim 12, wherein the routing node is further configured to:

and in response to the detection of the preset abnormality, encrypting the abnormal related information of the detected abnormality by using the preset management public key, and sending the encrypted abnormal related information to the management server.

14. The system of claim 13, wherein:

the routing node is further configured to: after the routing node is started, acquiring a public key and a private key of the routing node from locally stored starting configuration information, acquiring a signed public key for signing the public key of the routing node by using the preset management private key, broadcasting the acquired signed public key to the same-chain miner node of the routing node, signing data sent to the same-chain miner node of the routing node by using the private key of the routing node, sending the signed data, and decrypting the data received from the same-chain miner node of the routing node by using the private key of the routing node; and

the miner node is further configured to: in response to receiving the signed public key sent by the same link node of the miner node, carrying out signature verification on the received signed public key by using the preset management public key; in response to the fact that the signed public key passes signature verification, determining a public key in the received signed public key as a public key of a same-link routing node of the miner node; and encrypting the data sent to the same-link routing node of the miner node by using the public key of the same-link routing node of the miner node and then sending the encrypted data, and performing signature verification on the data received from the same-link routing node of the miner node by using the public key of the same-link routing node of the miner node.

15. The system of claim 14, wherein the routing node is configured to:

and responding to the received transaction request which is not verified, and sending first prompt information to the SPV node which sends the received transaction request, wherein the first prompt information is used for indicating that the transaction request is not verified.

16. The system of claim 15, wherein the routing node is configured to:

sending an incineration instruction corresponding to the abnormal transaction request to each same-chain miner node of the routing node for the abnormal transaction request in the transaction request set of the routing node, wherein the abnormal transaction request is a transaction request for which the charge is not confirmed within a preset time length, and the incineration instruction corresponding to the abnormal transaction request is used for indicating the miner node to reduce the charge-out account number address in the abnormal transaction request by the transfer-out amount in the abnormal transaction request; and

the miner node is configured to: and executing the received burning instruction in response to receiving the burning instruction.

17. The system of claim 16, wherein the routing node is configured to:

and monitoring the execution process of each transaction request in the transaction request set of the routing node.

18. The system of claim 17, wherein the domain name of a routing node is associated with a parallel chain identification of the parallel chain in which the routing node resides.

19. The system of claim 18, wherein the management server is configured to:

and in response to receiving a capacity expansion request, expanding the capacity of the N parallel chains in the block chain system into 2N parallel chains.

20. The system of claim 19, wherein the miner node is configured to:

in a trusted execution environment of the miner node, encrypting data of the same-chain miner node sent to the miner node by using a first key and then sending the encrypted data, wherein the first key is generated according to a parallel chain identifier of a parallel chain where the miner node is located and the m;

and in the trusted execution environment of the miner node, decrypting the data received from the co-chained miner node of the miner node by using the first key.

21. The system of claim 20, wherein the routing node is configured to: in response to checking the received transaction request for a pass, adding the received transaction request to the transaction request set of the routing node, including:

the routing node is configured to: in response to receiving a transaction request sent by a co-link SPV node of the routing node, verifying the validity of the received transaction request; responding to the failure of the validity check, and sending second prompt information for indicating that the validity check fails to pass to the SPV node sending the received transaction request; responding to the passing of the validity check, and determining whether the routing node can receive a new transaction request according to the number of unprocessed transaction requests in the transaction request set of the routing node; and in response to the fact that a new transaction request can be received, adding the received transaction request into the transaction request set of the routing node, generating a transaction number corresponding to the received transaction request, and correspondingly storing the received transaction request, a corresponding transaction identifier and an operation process state used for representing that the account is paid out into a preset distributed database, wherein the transaction identifier corresponding to the received transaction request comprises the generated transaction number and a parallel chain identifier of a parallel chain where the routing node is located.

22. The system of claim 21, wherein the routing node is configured to:

determining a confirmed posted transaction request in the transaction request set of the routing node;

and updating the operation process state of the confirmed posted transaction request in the preset distributed database into the posted transaction according to the confirmed transaction identifier of the posted transaction request.

23. The system of any of claims 1-22, wherein each of the parallel chains further comprises ledger nodes, the ledger nodes of each of the parallel chains comprising a distributed ledger cluster; and

the ledger node is configured to:

synchronously storing the block chains stored in the adjacent same-chain miner nodes or the routing nodes of the account node into the local block chain of the account node in real time;

responding to an account information query request sent by a terminal, querying data in the distributed account book cluster according to the account information query request, and sending a query result to the terminal sending the account information query request.

24. A routing method applied to routing nodes of a block chain system, wherein the block chain system comprises at least one parallel chain, the parallel chain comprises routing nodes, at least one miner node and at least one Simplified Payment Verification (SPV) node, each miner node of each parallel chain stores data by adopting a distributed data block chain, the routing nodes of the at least one parallel chain are connected with each other through a network, and the parallel chain corresponding to an account address bound by the SPV node is the parallel chain in which the SPV node is located, the method comprises the following steps:

responding to the received transaction request, checking the received transaction request, adding the received transaction request into the transaction request set of the routing node, signing the received transaction request, and broadcasting the signed transaction request to the same-chain miner nodes of the routing node;

synchronizing block chains of the same-chain miner nodes of the routing nodes to a local block chain in real time;

determining an unsettled transaction request which is confirmed to be billed and unsettled in the transaction request set of the routing node;

sending the determined unsettled transaction request to a routing node of a target parallel chain, wherein the target parallel chain is a parallel chain corresponding to an account number address in the determined unsettled transaction request; and

and in response to receiving the transaction request sent by the routing node of the different link, signing the received transaction request and then broadcasting the signed transaction request to the same-link miner node of the routing node.

25. The method of claim 24, wherein a trusted execution environment is provided in the mineworker node, and the blockchain system comprises a number N of parallel chains that is a power m of 2, where m is a natural number between 0 and 16.

26. The method of claim 25, wherein said N, said m and a second predetermined mask are stored in a trusted execution environment of each of said miner nodes and each of said routing nodes, said second predetermined mask being an integer between 0 and 65535; and

the method further comprises the following steps: encrypting the locally stored parallel chain configuration information to obtain encrypted parallel chain configuration information, and sending the encrypted parallel chain configuration information to the same-chain miner node of the routing node, wherein the parallel chain configuration information includes the N, the m, and the second preset mask.

27. The method of claim 26, wherein the blockchain system further comprises a management server, the management server is connected to each routing node through a network, a preset management private key and a preset management public key are stored in the management server, and each routing node and each miner node store the preset management public key; and

the method further comprises the following steps:

in response to receiving a post-signature routing node management instruction sent by the management server, performing signature verification on the received post-signature routing node management instruction by using the preset management public key;

and executing the routing node management instruction in the received signed routing node management instruction in response to the received signed routing node management instruction passing the signature verification.

28. The method of claim 27, wherein the method further comprises:

in response to receiving the signed transaction management instruction sent by the management server, carrying out signature verification on the received signed transaction management instruction by using the preset management public key;

and responding to the verification of the received signed transaction management command signature, and sending the received signed transaction management command to the same-chain miner node of the routing node.

29. The method of claim 28, wherein the method further comprises:

30. The method of claim 29, wherein the method further comprises:

after the routing node is started, acquiring a public key and a private key of the routing node from locally stored starting configuration information, and acquiring a signed public key for signing the public key of the routing node by using the preset management private key;

broadcasting the acquired signed public key to the same-chain miner node of the routing node;

signing the data of the same-chain miner node sent to the routing node by using the private key of the routing node and then sending the signed data; and

and decrypting the data received from the same-chain miner node of the routing node by using the private key of the routing node.

31. The method of claim 30, wherein the method further comprises:

32. The method of claim 31, wherein the method further comprises:

and for an abnormal transaction request in the transaction request set of the routing node, sending an incineration instruction corresponding to the abnormal transaction request to each co-chain miner node of the routing node, wherein the abnormal transaction request is a transaction request for which the charge is not confirmed within a preset time length, and the incineration instruction corresponding to the abnormal transaction request is used for indicating the miner node to reduce the charge-out account number address in the abnormal transaction request by the transfer-out amount in the abnormal transaction request.

33. The method of claim 32, wherein the method further comprises:

34. The method of claim 33, wherein the domain name of the routing node is associated with a parallel chain identification of the parallel chain in which the routing node resides.

35. The method of claim 34, wherein said adding the received transaction request to the transaction request set of the routing node in response to checking the received transaction request for a pass comprises:

in response to receiving a transaction request sent by a co-chained SPV node of the routing node, verifying the validity of the received transaction request;

responding to the failure of the validity check, and sending second prompt information for indicating that the validity check fails to pass to the SPV node sending the received transaction request;

responding to the passing of the validity check, and determining whether the routing node can receive a new transaction request according to the number of unprocessed transaction requests in the transaction request set of the routing node;

and in response to the fact that a new transaction request can be received, adding the received transaction request into the transaction request set of the routing node, generating a transaction number corresponding to the received transaction request, and correspondingly storing the received transaction request, a corresponding transaction identifier and an operation process state used for representing that the account is paid out into a preset distributed database, wherein the transaction identifier corresponding to the received transaction request comprises the generated transaction number and a parallel chain identifier of a parallel chain where the routing node is located.

36. The method of claim 35, wherein the method further comprises:

determining a confirmed posted transaction request in a transaction request set of the routing node;

37. A routing node, comprising:

one or more processors;

a storage device having one or more programs stored thereon,

the one or more programs, when executed by the one or more processors, cause the one or more processors to implement the method of any of claims 24-36.

38. A computer readable storage medium having a computer program stored thereon, wherein the computer program, when executed by one or more processors, implements the method of any of claims 24-36.