CN110619520B - Block chain system and routing method applied to routing nodes of block chain system - Google Patents

Block chain system and routing method applied to routing nodes of block chain system Download PDF

Info

Publication number
CN110619520B
CN110619520B CN201810636486.6A CN201810636486A CN110619520B CN 110619520 B CN110619520 B CN 110619520B CN 201810636486 A CN201810636486 A CN 201810636486A CN 110619520 B CN110619520 B CN 110619520B
Authority
CN
China
Prior art keywords
node
transaction request
miner
routing
routing node
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201810636486.6A
Other languages
Chinese (zh)
Other versions
CN110619520A (en
Inventor
程强
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Shenzhen Hongzhuanfang Technology Co ltd
Original Assignee
Shenzhen Hongzhuanfang Technology Co ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Shenzhen Hongzhuanfang Technology Co ltd filed Critical Shenzhen Hongzhuanfang Technology Co ltd
Priority to CN201810636486.6A priority Critical patent/CN110619520B/en
Priority to PCT/CN2019/090355 priority patent/WO2019242508A1/en
Publication of CN110619520A publication Critical patent/CN110619520A/en
Application granted granted Critical
Publication of CN110619520B publication Critical patent/CN110619520B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange

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, 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 stores data by adopting a distributed data block chain, the routing nodes of the at least one parallel chain are connected through a network, the parallel chain corresponding to an account address bound by the SPV node is the parallel chain where the SPV node is located, and one specific implementation mode of the system comprises: the routing node checks and forwards the received transaction request to the same-chain miner node or the different-chain router node, and synchronizes the blockchain of the same-chain miner node of the routing node to the local blockchain in real time; the mineworker node verifies the signed transaction request received from the co-link by node and joins the local set of pending transaction requests. This embodiment increases the number of transactions per second for the blockchain system.

Description

Block chain system and routing method applied to routing nodes of 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 routing nodes of the blockchain system.
Background
Blockchain is a kind of decentralised shared ledger (Decentralized Shared Ledger) that combines blocks of data in a time-sequential manner into a specific data structure in a chain and cryptographically guarantees that it is not tamperable, not counterfeitable. The blockchain can safely store simple, orderly and validated data in the system.
A blockchain system, i.e., a system that stores data using blockchains. Currently, most blockchain systems commonly have the following features: decentralizing, non-tamperable, non-counterfeitable, verifiable, anonymous. However, current blockchain systems generally suffer from longer time to wait for a transaction to be confirmed (e.g., one hour per transaction in a bitcoin system), and lower TPS (Transactions Per Second, number of transactions per second) due to limitations on block speed and capacity per block (e.g., an average of one block per 10 minutes in a bitcoin system, each block defining a capacity of 1 megabyte), such as an average of 7 transactions per second in a bitcoin system.
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, the system including at least one parallel chain, the parallel chain including a routing node, at least one miner node and at least one simplified payment verification SPV node, each miner node of each parallel chain storing data using a distributed data blockchain, the routing nodes of the at least one parallel chain being connected by a network, the parallel chain corresponding to an account address bound by the SPV node being the parallel chain in which the SPV node is located, wherein: the SPV node is configured to: in response to receiving a transaction request, sending the received transaction request to a routing node of a parallel chain in which the SPV node is located; the routing node is configured to: in response to passing the received transaction request verification, adding the received transaction request to a transaction request set of the routing node, and signing the received transaction request and broadcasting the signed transaction request to a co-link miner node of the routing node; synchronizing the blockchain of the same-chain miner node of the routing node to a local blockchain in real time; the mineworker node is configured to: in response to passing verification of the signed transaction request received from the co-link slave node, adding an intra-link transaction request of the mineworker node in the signed transaction request to a set of pending transaction requests of the mineworker node; the routing node is configured to: determining a non-posted transaction request which is confirmed to be posted and not posted in a transaction request set of the routing node; transmitting the determined non-posted transaction request to a routing node of a target parallel chain, wherein the target parallel chain is a parallel chain corresponding to a posted account number address in the determined non-posted transaction request; and in response to receiving the transaction request sent by the node of the different link, broadcasting the received transaction request to the peer miner nodes of the routing node after signing.
In some embodiments, a trusted execution environment is provided in the miner node, and a node identification for uniquely identifying the miner node is stored in the trusted execution environment of the miner node.
In some embodiments, the mineworker node has an account address bound thereto; and the mineworker node is configured to: in response to competing for billing rights to the parallel chain in which the mineworker node resides, performing the following billing operations: selecting a transaction request to be processed from a set of transaction requests to be processed of the miner node; generating a new block by using the selected to-be-processed transaction request, the mining rewarding information and the billing rewarding information of the miner node, wherein the mining rewarding information and the billing rewarding information of the miner node are respectively used for representing the mining rewards and account addresses bound by the miner node and corresponding to each account-out transaction request in the selected to-be-processed transaction request; the generated new block is connected in series to the local block chain of the miner node; and broadcasting the generated new block to other in-chain miner nodes of the miner node.
In some embodiments, the account address includes a virtual parallel chain identification and an account address string; and the mineworker node is configured to: in response to detecting the account address generation request, performing the following account address binding operations in a trusted execution environment of the mineworker node: generating a new account address character string as the account address character string of the miner node in response to determining that the miner node is not bound with the account address; according to a preset calculation formula, calculating a virtual parallel chain identification of the miner node according to the node identification of the miner node, combining an account address character string of the miner node and the virtual parallel chain identification to obtain an account address, and determining the combined account address as the account address bound by the miner node.
In some embodiments, the blockchain system includes a number N of parallel chains to the power of 2 m, where m is a natural number between 0 and 16.
In some embodiments, the virtual parallel chain identification is a natural number between 0 and 65535.
In some embodiments, the trusted execution environment of each mineworker node has stored therein a first preset mask, the first preset mask being an integer between 0 and 65535; and calculating a virtual parallel chain identification of the miner node according to a preset calculation formula and the node identification of the miner node, wherein the virtual parallel chain identification comprises: and determining the result of the exclusive OR operation of the binary representation of the node identifier of the miner node and the binary representation of the first preset mask according to the bits as a 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 mineworker node, the second preset mask being an integer between 0 and 65535; and the mineworker node is configured to: in response to detecting a mineworker network entry request, performing the following parallel chain determination operations in a trusted execution environment of the mineworker node: performing bit-wise AND operation 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 parallel chain identification as a parallel chain corresponding to the account 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 the bits to obtain an exclusive-or operation result; performing AND operation on the binary representation of the difference between the obtained exclusive OR operation result and N minus 1 according to the bit to obtain a miner parallel chain identifier; the parallel chain where the miner node is located is determined to be 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 mineworker 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 mineworker node is configured to: in response to receiving encrypted parallel chain configuration information sent by a node in the same link of the miner node, decrypting the received encrypted parallel chain configuration information in a trusted execution environment of the miner node; and in response to the verification passing of the decrypted parallel chain configuration information, updating the N, m and the second preset mask stored in the trusted execution environment of the mineworker node with the N, m and the second preset mask in the decrypted parallel chain configuration information.
In some embodiments, the blockchain system further includes a management server, the management server is connected with 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 miner node; and the management server is configured to: responding to 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: responding to the received signed routing node management instruction sent by the management server, and performing signature verification on the received signed routing node management instruction by using a preset management public key; and in response to the received signed routing node management instruction signature verification passing, executing the routing node management instruction in the received signed routing node management instruction.
In some embodiments, the management server is configured to: responding to a transaction management instruction input by a user, signing the transaction management instruction by using a preset management private key, and then sending the transaction management instruction to a second routing node, wherein the second routing node is a routing node of a parallel chain corresponding to an account address related to the transaction management instruction; the routing node is configured to: in response to receiving the post-signature transaction management instruction sent by the management server, performing signature verification on the received post-signature transaction management instruction by using a preset management public key; in response to the received signed transaction management instruction signature verification passing, sending the received signed transaction management instruction to a co-chain miner node of the routing node; the mineworker node is configured to: responding to the received signed transaction management instruction sent by the node in the same link of the miner node, and performing signature verification on the received signed transaction management instruction by using a preset management public key; in response to the received signed transaction management instruction signature verification passing, adding the transaction management instruction of the received signed transaction management instruction to the local set of pending transaction requests.
In some embodiments, the routing node is further configured to: in response to detecting the preset anomaly, encrypting anomaly related information of the detected anomaly by using a preset management public key, and transmitting the encrypted anomaly related information to a management server.
In some embodiments, the routing node is further configured to: after the routing node is started, a public key and a private key of the routing node are obtained from locally stored starting configuration information, a signed public key for signing the public key of the routing node by utilizing a preset management private key is obtained, the obtained signed public key is broadcasted to the same-chain miner node of the routing node, the private key of the routing node is utilized to sign and then send data sent to the same-chain miner node of the routing node, and the private key of the routing node is utilized to decrypt the data received from the same-chain miner node of the routing node; and the mineworker node is further configured to: responding to the received signed public key sent by the node in the same link of the miner node, and carrying out signature verification on the received signed public key by utilizing a preset management public key; in response to signature verification passing of the signed public key, determining a public key of the received signed public key as a public key of the co-link slave node of the miner node; and encrypting the data sent to the co-link slave node of the miner node by using the public key of the co-link slave node of the miner node, and then sending the data, and signature verification is carried out on the received data from the co-link slave node of the miner node by using the public key of the co-link slave node of the miner node.
In some embodiments, the routing node is configured to: and in response to the failure of the verification of the received transaction request, sending first prompt information to the SPV node sending the received transaction request, wherein the first prompt information is used for indicating that the verification of the transaction request fails.
In some embodiments, the routing node is configured to: for an abnormal transaction request in a 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 account is not confirmed within a preset time period, and the incineration instruction corresponding to the abnormal transaction request is used for indicating the miner node to reduce the account number address in the abnormal transaction request by the transfer amount in the abnormal transaction request; and the mineworker node is configured to: in response to receiving the burn instruction, executing the received burn instruction.
In some embodiments, the routing node is configured to: the execution of each transaction request in the set of transaction requests of the routing node is monitored.
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 is located.
In some embodiments, the management server is configured to: in response to receiving the expansion request, expanding N parallel chains in the blockchain system to 2N parallel chains.
In some embodiments, the mineworker 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 and m of a parallel chain where the miner node is positioned; in a trusted execution environment of the mineworker node, data received from an in-chain mineworker node of the mineworker node is decrypted using a first key.
In some embodiments, the routing node is configured to: in response to passing the received transaction request verification, adding the received transaction request to the set of transaction requests for the routing node, including: the routing node is configured to: in response to receiving a transaction request sent by a same-chain 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 the failure of the validity check to an SPV node sending the received transaction request; determining whether the routing node can receive new transaction requests according to the number of unprocessed transaction requests in the transaction request set of the routing node in response to the passing of the validity check; in response to determining that a new transaction request can be received, adding the received transaction request to 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 progress state for representing an issued transaction 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 in which the routing node is located.
In some embodiments, the routing node is configured to: determining an credited transaction request of credited confirmation in the transaction request set of the routing node; and updating the operation progress state of the checked-in transaction request determined in the preset distributed database into the checked-in transaction according to the determined transaction identification of the checked-in transaction request.
In some embodiments, each parallel chain further includes ledger nodes, the ledger nodes of each parallel chain forming a distributed ledger cluster; and the ledger node is configured to: synchronously storing blockchains stored in adjacent same-chain miner nodes or routing nodes of the account node into local blockchains of the account node in real time; and responding to the received account information inquiry request sent by the terminal, inquiring data in the distributed account book cluster according to the account information inquiry request, and sending an inquiry result to the terminal sending the account information inquiry 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, the parallel chain includes a routing node, at least one miner node and at least one simplified payment verification SPV node, each miner node of each parallel chain stores data using a distributed data blockchain, the routing nodes of at least one parallel chain are connected by a network, and a parallel chain corresponding to an account address bound by the SPV node is a parallel chain where the SPV node is located, and the method includes: in response to the received transaction request being verified, adding the received transaction request to a transaction request set of the routing node, and signing the received transaction request and broadcasting the signed transaction request to a co-chain miner node of the routing node; synchronizing the blockchain of the same-chain miner node of the routing node to a local blockchain in real time; determining a non-posted transaction request which is checked out and not posted in a transaction request set of a routing node; transmitting the determined non-posted transaction request to a routing node of a target parallel chain, wherein the target parallel chain is a parallel chain corresponding to a posted account number address in the determined non-posted transaction request; and in response to receiving the transaction request sent by the node for the different link, broadcasting the received transaction request to the on-link miner nodes of the routing node after signing.
In some embodiments, a trusted execution environment is provided in the mineworker node, and the blockchain system includes a number N of parallel chains to the power of 2 m, 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 mineworker node and each routing node, the second preset mask being an integer between 0 and 65535; the method further comprises the following steps: 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 a 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 miner node; the method further comprises: responding to the received signed routing node management instruction sent by the management server, and performing signature verification on the received signed routing node management instruction by using a preset management public key; and in response to the received signed routing node management instruction signature verification passing, executing the routing node management instruction in the received signed routing node management instruction.
In some embodiments, the method further comprises: in response to receiving the post-signature transaction management instruction sent by the management server, performing signature verification on the received post-signature transaction management instruction by using a preset management public key; and in response to the received signed transaction management instruction signature verification passing, sending the received signed transaction management instruction to the in-chain miner node of the routing node.
In some embodiments, the method further comprises: in response to detecting the preset anomaly, encrypting anomaly related information of the detected anomaly by using a preset management public key, and transmitting the encrypted anomaly related information to a management server.
In some embodiments, the method further comprises: after the routing node is started, a public key and a private key of the routing node are obtained from locally stored starting configuration information, and a signed public key for signing the public key of the routing node by utilizing a preset management private key is obtained; broadcasting the obtained public key after signing to the same-chain miner nodes of the routing nodes; signing and transmitting the data of the same-chain miner node transmitted to the routing node by using the private key of the routing node; and decrypting data received from the in-chain miner nodes of the routing node using the private key of the routing node.
In some embodiments, the method further comprises: and in response to the failure of the verification of the received transaction request, sending first prompt information to the SPV node sending the received transaction request, wherein the first prompt information is used for indicating that the verification of the transaction request fails.
In some embodiments, the method further comprises: for an abnormal transaction request in a transaction request set of a 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 account 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 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, the domain name of the routing node is associated with a parallel chain identification of the parallel chain in which the routing node is located.
In some embodiments, adding the received transaction request to the transaction request set of routing nodes in response to the received transaction request being verified, includes: in response to receiving a transaction request sent by a same-chain 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 the failure of the validity check to an SPV node sending the received transaction request; determining whether the routing node can receive new transaction requests according to the number of unprocessed transaction requests in the transaction request set of the routing node in response to the passing of the validity check; in response to determining that a new transaction request can be received, adding the received transaction request to a transaction request set of the routing node, generating a transaction number corresponding to the received transaction request, and storing the received transaction request, a corresponding transaction identifier and an operation progress state for characterizing the posted in a preset distributed database in correspondence, wherein the transaction identifier corresponding to the received transaction request comprises the generated transaction number and a parallel chain identifier of a parallel chain in which the routing node is located.
In some embodiments, the method further comprises: determining an credited transaction request of credited confirmation in a transaction request set of the routing node; and updating the operation progress state of the checked-in transaction request determined in the preset distributed database into the checked-in transaction according to the determined transaction identification of the checked-in transaction request.
In a third aspect, an embodiment of the present application provides a routing node, including: one or more processors; and a storage device having one or more programs stored thereon, which when executed by the one or more processors, cause the one or more processors to implement a method as described in any implementation of the second aspect.
In a fourth aspect, embodiments of the present application provide a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by one or more processors, implements a method as described in any of the implementations of the second aspect.
According to the blockchain system, the transaction processing process is improved from a single-chain serial mode to a multi-chain concurrent mode by adopting at least one parallel chain mode, so that the number of transactions per second is increased along with the increase of the number of parallel chains, and TPS of the blockchain system is further improved.
Drawings
Other features, objects and advantages of the present application will become more apparent upon reading of the detailed description of non-limiting embodiments, made with reference to the following drawings, in which:
FIG. 1 is an exemplary system architecture diagram in which an embodiment of the present application may be applied;
2A-2D are timing diagrams of one embodiment of a blockchain system in accordance with the present application;
FIG. 3 is a flow chart of one embodiment of a routing method applied to a routing node of a blockchain system in accordance with the present application;
fig. 4 is a schematic diagram of a computer system suitable for use in implementing routing nodes of embodiments of the present application.
Detailed Description
The present application is described in further detail below with reference to the drawings and examples. It is to be understood that the specific embodiments described herein are merely illustrative of the invention and are not limiting of the invention. It should be noted that, for convenience of description, only the portions related to the present invention are shown in the drawings.
It should be noted that, in the case of no conflict, the embodiments and features in the embodiments may be combined with each other. The present application will be described in detail below with reference to the accompanying drawings in conjunction with embodiments.
Fig. 1 illustrates an exemplary system architecture 100 to which embodiments of a blockchain system and routing methods for routing nodes of the blockchain system may be applied.
As shown in fig. 1, a system architecture 100 may include parallel chains 101, 102, 103 and networks 104, 105.
The parallel chain 101 includes routing nodes 1011, mineworker nodes 1012, 1014, 1015, 1016, 1018, spv (Simplified Payment Verification ) nodes 1013, 1017, and a network 1019. The network 1019 is used to provide a medium for communication links between the routing nodes 1011, mineworker nodes 1012, 1014, 1015, 1016, 1018 and SPV nodes 1013, 1017. The network 1019 may include various connection types, such as wired, wireless communication links, or fiber optic cables, among others. The mineworker nodes 1012, 1014, 1015, 1016, 1018 of the parallel chain 101 store data using a distributed data blockchain. The SPV nodes 1013, 1017 of the parallel chain 101 are bound with account addresses, and the parallel chain corresponding to the account addresses bound by the SPV nodes 1013, 1017 is the parallel chain 101.
The parallel chain 102 includes routing nodes 1021, mineworker nodes 1022, 1023, 1025, 1026, spv node 1024, and network 1027. The network 1027 is used as a medium to provide communication links between the routing nodes 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 blockchain. The SPV node 1024 of the parallel chain 102 is bound with an account address, and the parallel chain corresponding to the account address bound by the SPV node 1024 is the parallel chain 102.
The parallel chain 103 includes routing nodes 1031, mineworker nodes 1032, 1033, 1035, 1036, spv nodes 1034, 1037, and a network 1038. The network 1038 is used as a medium to provide communication links between the routing nodes 1031, mineworker nodes 1032, 1033, 1035, 1036, and SPV nodes 1034, 1037. Network 1038 may include various connection types, such as wired, wireless communication links, or fiber optic cables, among others. The miner nodes 1032, 1033, 1035, 1036 of the parallel chain 103 store data using distributed data blockchains. The SPV nodes 1034 and 1037 of the parallel chain 103 are bound with account addresses, and the parallel chain corresponding to the account addresses bound by the SPV nodes 1034 and 1037 is the parallel chain 103.
A user may interact with the routing node 1021 over the network 1019 using the SPV nodes 1013, 1017 to receive or send messages, etc. A user may also interact with the routing node 1021 over the network 1027 using the SPV node 1024 to receive or send messages, etc. Users may also interact with routing node 1031 through network 1037 using SPV nodes 1034, 1037 to receive or send messages, etc.
Various communication client applications may be installed on SPV nodes 1013, 1017, 1024, 1034, 1037, such as a simplified payment verification application, wallet application, web browser application, shopping class application, search class application, instant messaging tool, mailbox client, social platform software, and the like. A user may perform digital money management, transfer, collection, balance viewing, transaction record viewing, etc. operations using the simplified payment verification application installed on SPV nodes 1013, 1017, 1024, 1034, 1037.
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 can be a variety of electronic devices with display screens including, but not limited to, smartphones, tablets, laptop and desktop computers, and the like. When the SPV nodes 1013, 1017, 1024, 1034, 1037 are software, they can be installed in the above-listed electronic devices. Which may be implemented as multiple software or software modules (e.g., to provide a simplified payment verification service), or as a single software or software module. The present invention is not particularly limited herein.
It should be noted that, the routing method applied to the routing node of the blockchain system provided in the embodiments of the present application is generally executed by the routing nodes 1011, 1021, 1031, and accordingly, the routing device applied to the routing node of the blockchain system is generally disposed in the routing nodes 1011, 1021, 1031.
The routing nodes 1011, 1021, 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 as a single server. When 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. The present invention is not particularly limited herein.
The miner nodes 1012, 1014, 1015, 1016, 1018, 1022, 1023, 1025, 1026, 1032, 1033, 1035, 1036 may be hardware or software. When the miner nodes 1012, 1014, 1015, 1016, 1018, 1022, 1023, 1025, 1026, 1032, 1033, 1035, 1036 are hardware, they may be implemented as a distributed server cluster formed by a plurality of servers, or may be implemented 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 billing services), or as a single software or software module. The present invention 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 the implementation. The number of routing nodes, miner nodes, networks, and SPV nodes in each parallel chain is also merely illustrative. There may be any number of routing nodes, miner nodes, networks, and SPV nodes, as desired for implementation.
With continued reference to FIG. 2, a timing 200 in accordance with one embodiment of the blockchain system of the present application is shown.
The blockchain system in the embodiments of the present application may include at least one parallel chain (such as the parallel chains 101, 102, 103 shown in fig. 1), where each of the parallel chains stores data using a distributed data blockchain, a network connection is provided between the routing nodes of the at least one parallel chain (such as the routing nodes 1011, 1021, 1031 shown in fig. 1), at least one miner node (such as the miner nodes 1012, 1014, 1015, 1016, 1018, 1022, 1023, 1025, 1026, 1032, 1033, 1035, 1036 shown in fig. 1), and at least one SPV node (such as the SPV nodes 1013, 1017, 1024, 1034, 1037 shown in fig. 1), where the parallel chains corresponding to the account addresses bound by the SPV nodes are the parallel chains where the SPV nodes are located.
As shown in fig. 2, a timing sequence 200 according to one embodiment of the blockchain system of the present application includes the steps of:
in 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, a simplified payment verification application may be installed in an SPV node (e.g., SPV nodes 1013, 1017, 1024, 1034, 1037 shown in fig. 1). The user may submit the transaction request using a reduced payment verification application in the SPV node. Here, the transaction request is a transfer request. That is, the digital currency in the account address a bound by the SPV node is transferred to an account address B different from the 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 resides in response to receiving the transaction request.
Here, each SPV node may be bound with an account address. In practice, wallet applications 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 where 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 routing node of the parallel chain corresponding to the account address bound by the SPV node.
In practice, various implementations may also be employed 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 the SPV node.
In response to the received transaction request being checked by the routing node, the routing node adds the received transaction request to the collection of transaction requests for the routing node and signs the received transaction request and broadcasts the signed transaction request to each of the in-chain miner nodes of the routing node, step 202.
In this embodiment, a routing node (e.g., routing nodes 1011, 1021, 1031 shown in fig. 1) may verify 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 may be added to the transaction request set of the routing node and signed and broadcast to the individual in-chain miner nodes of the routing node.
Here, the verification of the received transaction request by the routing node may include, but is not limited to, verifying the validity of the transaction request. The validity check may include, but is not limited to, verifying whether a UTXO (Unspent Transaction Output, not spending transaction output) record exists at the outgoing account address in the transaction request, whether the balance of the outgoing account address in the transaction request supports the transaction request, whether the outgoing account address in the transaction request is an account address in a blacklist of outgoing account addresses stored in the routing node, whether the outgoing account address in the transaction request is an account address in a blacklist of incoming account addresses stored in the routing node, and so on. In practice, the verification of the transaction request herein may also include other verification.
Here, each transaction request that the routing node checks through is stored in the transaction request set of the routing node.
Here, the routing node signing the received transaction request 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, the miner nodes 1012, 1014, 1015, 1016, 1018 are co-chain miner nodes of the routing node 1011.
In practice, since each parallel chain is generally based on a Peer-to-Peer (P2P), when a routing node signs a received transaction request and broadcasts the received transaction request to a Peer miner node of the routing node, the routing node may sign the received transaction request and broadcast the received transaction request to neighboring Peer miner nodes of the routing node, and then the neighboring Peer miner nodes of the routing node broadcast the signed transaction request to respective neighboring miner nodes.
It should be noted that, when the transaction request received from the SPV node is checked and passed, the routing node may first add the received transaction request to the transaction request set of the routing node, and then broadcast the received transaction request to each of the same-chain miner nodes of the routing node after signing the received transaction request, or when the transaction request received from the SPV node is checked and passed, the routing node may first broadcast the received transaction request to each of the same-chain miner nodes of the routing node after signing the received transaction request, and then add the received transaction request to the transaction request set of the routing node, which is not limited in this application.
In step 203, the routing node synchronizes the blockchain of the peer miner node of the routing node to the local blockchain in real time.
In this embodiment, a routing node (e.g., routing nodes 1011, 1021, 1031 of FIG. 1) also synchronizes the blockchain of the co-chain miner nodes of the routing node to the local blockchain in real-time. That is, the routing node does not perform mining and billing operations, but the blockchain 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 perform step 203 at any time, and is not limited to performing step 203 after performing step 202.
In step 204, the mineworker node adds an in-chain transaction request of the mineworker node to a set of pending transaction requests of the mineworker node in response to the verification of the signed transaction request received from the co-link slave 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 respond to receiving a signed transaction request from the mineworker node's co-link by the node by first verifying the received signed transaction request. Second, if the verification passes, the miner node may add the intra-chain transaction request of the miner node in the signed transaction request to the set of pending transaction requests of the miner node.
Here, the miner node verifying the received signed transaction request may specifically include: and carrying out signature verification on the received signed transaction request by using the public key of the node of the same link of the miner node, if the signature verification is passed, carrying out validity verification on the received signed transaction request, and if the validity verification is passed, determining that the received signed transaction request is verified to be passed by the miner node.
Here, the intra-chain transaction request of the miner node in the signed transaction request may specifically include the following two cases: (1) The outgoing account address and the parallel chain corresponding to the incoming account address in the signed transaction request are both parallel chains where the miner node is located, and then the outgoing account request and the incoming account request in the signed transaction request are both intra-chain transaction requests of the miner node. (2) The parallel chain corresponding to the address of the turning-out account in the signed transaction request is the parallel chain where the miner node is located, and the parallel chain corresponding to the address of the turning-in account in the signed transaction request is not the parallel chain where the miner node is located, so that the accounting request in the signed transaction request is an intra-chain transaction request of the miner node, and the accounting 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 store a set of pending transaction requests for that miner node. Each miner node belonging to the same parallel chain can compete for the accounting rights of the parallel chain in which the miner node is located according to a preset consensus mechanism. If a miner node competes for the account rights (commonly known as mining) of the parallel chain in which the miner node is located, a new block can be formed by using the transaction requests to be processed in the transaction request set to be processed stored locally by the miner node, and the formed new block is quickly connected in series to the local blockchain of the miner node. That is, the mineworker node needs to perform mining and billing operations.
In step 205, the routing node determines a non-posted transaction request that is confirmed to be posted and not posted in the set of transaction requests for 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 digital currencies from account address a to account address B. The transaction request D may include an outbound request D1 to reduce the digital currency in account address a by X and an inbound request D2 to increase the digital currency in account address B by X.
In this embodiment, since the routing node (for example, the routing nodes 1011, 1021, 1031 shown in fig. 1) synchronously stores the blockchain data of the parallel chain where the routing node is located, the routing node may first query the local transaction request set for the corresponding outstanding transaction request whose current processing state is not yet outstanding, and then determine whether each outstanding transaction request has confirmed to be outstanding according to the locally synchronously stored blockchain data. For example, the routing node may determine whether six or more blocks exist after the block corresponding to the posting request in the transaction request in the locally stored blockchain data, and if so, may confirm that the transaction request is confirmed to have been posted. If it is determined that the outstanding transaction request confirms that the outstanding transaction request has been posted, it may be determined that the transaction request is a outstanding transaction request that confirms that the outstanding transaction request has been posted and that the outstanding transaction request has not been posted.
In step 206, the routing node sends the determined unsettled transaction request to the routing node of the target parallel chain.
In this embodiment, a routing node (e.g., routing nodes 1011, 1021, 1031 shown in FIG. 1) may send the unsettled transaction request determined in step 205 to the routing node of the target parallel chain. The target parallel chain is a parallel chain corresponding to the account number address of the confirmed non-account transaction request. For example, for a unsettled transaction request D: the X digital currencies in the account address a are transferred to the account address B, where the account address a corresponds to the parallel chain L1 and the account address B corresponds to the parallel chain L2, where the step 206 corresponds to the routing node of the parallel chain L1 sending the uninhabited transaction request D to the routing node of the parallel chain L2.
In step 207, the routing node, in response to receiving the transaction request sent by the node for the different link, signs the received transaction request and broadcasts the signed transaction request to the on-link miner nodes of the routing node.
In this embodiment, a routing node (e.g., routing nodes 1011, 1021, 1031 of fig. 1) may, in response to receiving a transaction request sent by a node on an inter-link, sign the received transaction request and broadcast it to the peer mineworker nodes of the routing node.
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 a transaction request sent by the other link node, the other link node sends a non-accounting transaction request which confirms that the transaction request is checked out and is not checked in to the routing node from the transaction request set of the other link node. The routing node may sign the received transaction request and broadcast the transaction request to the peer 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 a unsettled transaction request D: the X digital currencies in the account address a are transferred to the account address B, where the account address a corresponds to the parallel chain L1 and the account address B corresponds to the parallel chain L2, where the step 206 corresponds to the routing node of the parallel chain L1 sending the uninhabited transaction request D to the routing node of the parallel chain L2. Corresponding to step 207, it may be that the routing node of the parallel chain L2 signs the unsettled transaction request D and broadcasts it to the mineworker nodes in the parallel chain L2. Thus, the miner node of the L2 chain may execute step 204, if a signed transaction request D sent by a node of the same link, i.e. a routing node of 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 miner node in the signed transaction request is added to the set of pending transaction requests of the miner node. Wherein, the intra-chain transaction request of the miner node of the parallel chain L2 in the transaction request D is to increase the account address B by X digital currencies.
It should be noted that the timing sequence 200 is merely illustrative, 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, this embodiment may have the following optional implementation:
alternative implementation (one): a trusted execution environment (TEE, trusted Execution Environment) may be provided in the mineworker node, and a node identification for uniquely identifying the mineworker node may be stored in the trusted execution environment of the mineworker node.
Here, the TEE is an operating environment that coexist with a Rich OS (typically Android or the like) on the device, and provides security services to the Rich OS. The TEE has its own execution space. The software and hardware resources accessible by the TEE are separate from the Rich OS. The TEE provides a secure execution environment for trusted applications (Trusted Application, TA) while also protecting the confidentiality, integrity and access rights of the resources and data of the trusted applications. To guarantee a trusted root of the TEE itself, the TEE is to be 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, the TEE set in the mineworker node may take two ways:
(1) A trusted execution environment is constructed with the security protection capabilities provided by a particular CPU chip, such as Intel SGX, ARM Trust Zone, etc.
In order to ensure the security strength, trusted hardware support can be added at the bottom layer of the trusted execution environment, for example, a security chip conforming to the standard of a trusted platform module (TPM, trusted Platform Module) or a security chip conforming to the standard of a trusted cryptography module (TCM, trusted Cryptography Module) can be adopted.
(2) A trusted execution environment is realized by adopting an encryption lock (commonly known as a dongle).
Common dongles are often packaged as a compact USB (Universal Serial Bus ) device, which provides both file storage and support running custom programs within the dongle. The dongle is adopted, the equipment type of the mine machine node is not limited, and the equipment requirement on the mine machine node is reduced as long as the mine machine node is provided with the USB interface.
Alternative implementation (ii): based on the optional implementation (one), the mining machine node may further be bound with an account address, and the timing sequence 200 may further include step 208:
at step 208, the mineworker node performs a billing operation in response to competing for billing rights to the parallel chain in which the mineworker node is located.
Here, the miner node may perform a billing operation in response to competing for billing rights to the parallel chain in which the miner node is located, wherein the billing operation may include the following substeps 2081 through 2084 (not shown in fig. 2A):
sub-step 2081, selecting a pending transaction request from the set of pending transaction requests for the miner node.
Here, the miner node may select the pending transaction request from the set of pending transaction requests for the miner node in various implementations. For example, a first predetermined number (e.g., 10) of pending transaction requests may be selected from the set of pending transaction requests for the miner node in order of top to bottom of the billing rewards (also referred to as transaction fees, or transaction commissions) for the pending transaction requests. For another example, a second preset number of pending transaction requests may also be selected from the set of pending transaction requests of the miner node in order of front-to-back transaction commit times of the pending transaction requests.
In a substep 2082, a new block is generated using the selected pending transaction request, the mineworker node's mining rewards information, and the billing rewards information.
Here, the miner node may generate a new block using the selected pending transaction request, the mining rewards information and the billing rewards information of the miner node after selecting the pending transaction request. The mining rewards information of the miner nodes is used for representing account addresses binding the mining rewards into the miner nodes, and the billing rewards information of the miner nodes is used for representing account addresses binding the miner nodes with billing rewards corresponding to each billing transaction request in the selected transaction requests to be processed.
Here, since the miner nodes compete for the right to pay, i.e., the miner nodes mine successfully, the miner nodes are rewarded with mine mining, i.e., a specified amount of digital currency is given to the account address to which the miner nodes are bound.
In addition, each transaction request may include, in addition to the transfer of X digital currencies from account address A to account address B, a Y-coin billing incentive (i.e., transaction fee) to the mineworker node posting the transaction request to the ledger (blockchain).
The blockchain system comprises at least one parallel chain, and the transaction request comprises an intra-chain transaction request and a cross-link transaction request. The in-chain transaction request is a transaction request of which the parallel chain corresponding to the account outgoing account number and the parallel chain corresponding to the account incoming account number of the transaction request are the same parallel chain, and the cross-link transaction request is a transaction request of which the parallel chain corresponding to the account outgoing account number and the parallel chain corresponding to the account incoming account number of the transaction request are different parallel chains. For example, for transaction request D: and transferring X digital currencies in the account address A to the 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-link transaction request.
For in-chain transaction requests: and transferring the X digital currencies in the account address A of the L1 chain to the account address B of the L1 chain, wherein the corresponding billing rewards are Y digital currencies. If the mineworker node M1 of the L1 chain competes for billing rights for the block corresponding to the intra-chain transaction, then the mineworker node M1 writes in its own block: x digital currencies are reduced in the account address A, X digital currencies are increased in the account address B, the account address bound by the miner node M1 is increased by a preset mining rewards digital currencies, and Y digital currencies are increased again for the account address bound by the miner node M1.
For a cross-chain transaction request: x digital currencies in the account address A of the L1 chain are transferred to the account address B of the L2 chain, the corresponding billing rewards are Y digital currencies, and L1 is not equal to L2. Since the transaction involves a cross-link, the corresponding transaction is divided into outbound transaction requests: reducing X digital currencies and account entry transaction requests in account address A: and adding two parts of X digital currencies into the account address B. The outbound transaction request is recorded in the mineworker node of the L1 chain and the inbound transaction request is recorded in the mineworker node of the L2 chain. If the mineworker node M1 of the L1 chain competes for the right to credit for the block corresponding to the above-described outbound transaction, the mineworker node M1 writes in its own block: and reducing X digital currencies in the account address A, increasing the account address bound by the miner node M1 by a preset mining rewards number of digital currencies, and increasing the account address bound by the miner node M1 by Y digital currencies. If the miner node M2 of the L2 chain competes for the accounting rights of the block corresponding to the above-mentioned accounting transaction, the miner node M2 writes in its own block: and adding X digital currencies to the account address B, and adding a preset mining rewarding digital currency to the account address bound by the miner node M1. Here, the mineworker node M2 cannot obtain the billing rewards for the above-described cross-chain transactions. That is, the billing reward only gives the mineworker node in the parallel chain to which the account number address corresponds.
Sub-step 2083 strings the generated new block into the local blockchain of the miner node.
Here, the miner node may, after generating the new block, string the generated new block into the local blockchain of the miner node.
Sub-step 2084 broadcasts the generated new block to other on-link mineworker nodes of the mineworker node.
Here, the miner node may broadcast the generated new block to other in-chain miner nodes of the miner node after the new block is generated.
It should be noted that, the miner node may execute the sub-step 2083 and then execute the sub-step 2084 after executing the sub-step 2082, or the miner node may execute the sub-step 2084 and then execute the sub-step 2083 after executing the sub-step 2082, which is not limited in this application.
Alternative implementation (III): based on the above alternative implementation (two), the account address bound by the miner node may include a virtual parallel chain identifier and an account address string. And, the above-mentioned timing sequence 200 may further include step 209:
in step 209, the miner node performs an account address binding operation in a trusted execution environment of the miner node in response to detecting the account address generation request.
Here, in addition to the application for mining and accounting, in order to ensure that the mining rewards and accounting rewards of the miner node can only be transferred into the unique account addresses bound by the miner node, the account address binding application can also be installed in the trusted execution environment of the miner node. Here, the miner node may issue an account address generation request every time the device is started, and the miner node may also detect the account address generation request input by the user. If the miner node detects an account address generation request, the miner node may perform an account address binding operation in a trusted execution environment of the miner node. Here, the account address binding operation may include the following sub-steps 2091 to 2094 (not shown in fig. 2A):
in response to determining that the miner node is not bound to the account address, a new account address string is generated as the miner node's account address string, substep 2091.
Here, it may first be determined in the trusted execution environment of the mineworker node whether the mineworker node is bound to the account address. If the miner node is determined to be bound to the account address, no operation is performed or bound prompt information for indicating that the miner node is bound to the account address can be presented. If it is determined that the miner node is not bound with the account address, a new account address string may be generated as the account address string of the miner node in a trusted execution environment of the miner node using various implementations. For example, an existing wallet application may be employed to generate a 20 byte account address string.
Sub-step 2092, calculating the virtual parallel chain identification of the mineworker node from the node identification of the mineworker node according to a preset calculation formula.
Based on the alternative implementation (one), the trusted execution environment of the miner node has stored therein 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 a trusted execution environment of the miner node according to the node identifier of the miner node. For example, the same virtual parallel chain identification key can be stored in the trusted execution environment of each miner node, then the node identification of the miner node can be encrypted by using the virtual parallel chain identification key stored in the trusted execution environment of the miner node, and the encryption result can be used as the virtual parallel chain identification of the miner node.
Here, the parallel chain identification is used to indicate the parallel chain. Each miner node belongs to a parallel chain, and therefore, the parallel chain identification of the parallel chain where the miner node is located is stored in the trusted execution environment of the miner node. Here, in addition to the parallel chain identifier of the parallel chain where the miner node is located, the trusted execution environment of the miner node may 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 future blockchain system changes, the identifier of the parallel chain correspondingly changes, and in this process, the virtual parallel chain identifier of each miner node is unchanged, 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.
Sub-step 2093, combining the account address string of the mineworker node and the virtual parallel chain identification to obtain an account address.
Here, after the virtual parallel chain identification of the mineworker node is obtained in sub-step 2092, the account address may be obtained by combining the account address string of the mineworker node and the virtual parallel chain identification in the trusted execution environment of the mineworker node. For example, the account address string of the miner node may be concatenated after the virtual parallel chain identification of the miner node to obtain the account address. For another example, the virtual parallel chain identifier of the miner node may be serially connected to the account address string of the miner node to obtain the account address.
Sub-step 2094, determining the combined account address as the mineworker node bound account address.
Here, the combined account address of sub-step 2093 may be determined in the trusted execution environment of the mineworker node as the account address to which the mineworker node is bound.
Through sub-steps 2091 through 2094, the account address and virtual parallel chain identification of the mineworker node have been determined and stored in the trusted execution environment of the mineworker node where the account address generation request was detected.
Alternative implementation (four): the blockchain system described above may include a number N of parallel chains that is to the power of 2 m, where m is a natural number between 0 and 16. That is, 1,2,4,8, 16, 32, 64, …, or 65536 parallel chains may be included in a blockchain system.
Alternative implementation (fifth): based on the above alternative implementation (four), the virtual parallel chain identification of the mineworker node may be a natural number between 0 and 65535 for the virtual parallel chain identification.
Alternative implementation (six): based on the optional implementation (fifth), a first preset mask may be stored in the trusted execution environment of the miner node, where the first preset mask is an integer between 0 and 65535. Thus, sub-step 2092, according to a predetermined calculation formula, calculates a virtual parallel chain identification of the mineworker node from the node identification of the mineworker node, which may be performed as follows:
and determining the result of the exclusive OR operation of the binary representation of the node identifier of the miner node and the binary representation of the first preset mask according to the bits as a virtual parallel chain identifier of the miner node.
The formula can be expressed as follows:
VCN＝UID^UidMask (1)
wherein:
UIDs are binary representations of node identifications of the mineworker nodes;
The UidMask is a first preset mask stored in a trusted execution environment of the mineworker node;
the VCN is the calculated virtual parallel chain identification of the mineworker node.
In practice, the first preset mask stored in the trusted execution environment of each mineworker node may be the same.
Optionally, in the above sub-step 2092, according to a preset calculation formula, the virtual parallel chain identifier of the miner node is calculated according to the node identifier of the miner node, which may also be performed as follows:
VCN＝UID&0xFFFF (2)
wherein:
UIDs are binary representations of node identifications of the mineworker nodes;
0xFFFF is a hexadecimal representation of 65535;
the VCN is the calculated virtual parallel chain identification of the mineworker node.
Alternative implementation (seventh): based on the various alternative implementations described above, the parallel chain identification used to indicate the parallel chains 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 alternative (seventh), a second preset mask may be 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 above-described sequence 200 may further include step 210:
In response to detecting a mineworker network entry request, the mineworker node performs a parallel chain determination operation in its trusted execution environment, step 210.
Here, the user may first make a mineworker access request with a mineworker node to determine the parallel chain in which the mineworker node is located before using the mineworker node for mining and billing. For example, the mineworker node may generate a mineworker networking request when a user first opens an application interface that performs mining and billing operations. In this way, a mineworker node may perform parallel chain determination operations in its trusted execution environment in response to detecting a mineworker network entry request. Wherein the parallel chain determination operation may include the following sub-steps 2101 through 2105 (not shown in fig. 2A):
sub-step 2101, performing a bitwise AND operation on the binary representation of the virtual parallel chain identification of the miner node and the binary representation of the difference of N minus 1 to obtain the account parallel chain identification.
Sub-step 2101 may be expressed by the following formula:
ACN＝VCN&(N-1) (3)
wherein:
VCN is virtual parallel chain identification of the miner node;
n is the number of parallel chains included in the blockchain system;
ACN is the account parallel chain identification calculated.
Sub-step 2102, determining the parallel chain indicated by the account parallel chain identifier as the parallel chain corresponding to the account address bound by the miner node.
Here, the parallel chain indicated by the ACN calculated in the above formula (3) may be determined as the parallel chain corresponding to the account address bound by the miner node.
Sub-step 2103 performs a bitwise exclusive-or operation on the binary representation of the virtual parallel chain identification of the mineworker node and the binary representation of the second preset mask to obtain an exclusive-or operation result.
Sub-step 2104, performing an AND operation on the obtained exclusive OR operation result and the binary representation of the difference of N minus 1 according to bits to obtain the mineworker parallel chain identification.
Here, sub-step 2103 and sub-step 2104 together may be expressed by the following formula:
MCN＝(VCN^MiningMask)&(N-1) (4)
wherein:
VCN is virtual parallel chain identification of the miner node;
n is the number of parallel chains included in the blockchain system;
miningmask a second preset mask stored in the trusted execution environment of the mineworker node;
MCN is the calculated mineworker parallel chain identity.
Sub-step 2105 determines the parallel chain in which the mineworker node is located as the parallel chain indicated by the mineworker parallel chain identity.
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 sub-steps 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 a trusted execution environment of the miner node, and a parallel chain identifier (hereinafter referred to as MCN of the miner node) of the parallel chain where the miner node is located is also determined and recorded. 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 represented by the mining rewards and the billing rewards of the miner node being 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 represented by the parallel chain identification of the parallel chain corresponding to the account addresses involved in the outbound transaction and the inbound transaction recorded by the miner node.
Due to the limitation of page display, it should be noted that, with continued reference to fig. 2B, the flow of fig. 2B may include, in addition to the flow shown in fig. 2B, the steps shown in fig. 2A.
Alternative implementation (nine): based on the optional implementation (eight), the number of parallel chains N and m included in the blockchain system may also be stored in the trusted execution environment of each mineworker node and in each routing node, and the above-described timing sequence 200 may further include the following step 211:
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 above-described parallel chain configuration information may include the number of parallel chains N, m included in the blockchain and a second preset mask.
Here, there is an association between m and the expansion sequence number of the blockchain system.
For example, a blockchain system may initially have 1 parallel chain where m is 0, and is not expanded, with an expansion sequence number of 0. Then through one expansion, 1 parallel chain is expanded into 2 parallel chains, at this time m is 1, namely through one expansion, the expansion serial number is 1. And expanding the capacity of the 2 parallel chains into 4 after the primary capacity expansion, wherein m is 2 at the moment, namely the capacity expansion sequence 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 expansion sequence number is 0. Then through one expansion, the 16 parallel chains are expanded into 32 parallel chains, at this time m is 5, namely through 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 0 ) Wherein m is 0 Is log of 2 N 0 ，N 0 Is the number of parallel chains that the blockchain system initially includes without being expanded.
The routing node may perform step 211 when the mineworker node first accesses the blockchain system. The routing node may also perform step 211 when the blockchain system expands, i.e., increases the number of parallel chains included in the blockchain system.
In step 212, the miner node decrypts the received encrypted parallel chain configuration information in the trusted execution environment in response to receiving the encrypted parallel chain configuration information sent by the node on the same link as the miner node.
It should be noted that the encryption in step 211 may be either symmetric encryption or asymmetric encryption. If asymmetric encryption is used in step 211, the encryption in step 211 may be performed using the public key in the preset key pair, and the decryption in step 212 may be performed using the private key in the preset key pair. If symmetric encryption is used in step 211, the encryption may be performed using the preset configuration information key in step 211, and the decryption may be performed using the preset configuration information key in step 212 accordingly. The preset configuration information key may be a key that is preset and has a security guarantee (does not leak).
In step 213, the miner node responds to the verification of the decrypted parallel link configuration information in the trusted execution environment and updates the N, m and the second preset mask stored in the trusted execution environment with the N, m and the second preset mask in the decrypted parallel link configuration information.
Here, the miner node checking the decrypted parallel link configuration information in the trusted execution environment may include at least one of: n in the decrypted parallel chain configuration information is twice as much as 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 is passed, the parallel chain configuration information sent by the node in the same link of the miner node can be trusted, and N, m and a second preset mask in the decrypted parallel chain configuration information can be used for updating N, m and the second preset mask stored in the trusted execution environment of the miner node.
Alternative implementation (ten): based on the embodiment shown in fig. 2, or any one of the above alternative implementations (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, and a preset management private key and a preset management public key are stored in the management server, and each routing node and each mineworker node store a preset management public key. And the above described sequence 200 may further include steps 214 through 216:
In step 214, the management server, in response to receiving the routing node management instruction input by the user, signs the routing node management instruction by using the preset management private key and then sends the routing node management instruction to the first routing node.
Here, the routing node management instruction is a management instruction for a 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: and starting online capacity expansion, adding the specified account address into a blacklist of the account address to be transferred, or adding the specified account address into the blacklist of the account address to be transferred out, and the like.
The user may access a preset management website through a web browser installed on the terminal to input a route management instruction, and then the terminal transmits the route management instruction input by the user to the management server, where the management server may be a server supported by the preset management website.
The user may also input a route management instruction through a management instruction input interface of a management application installed on the terminal, and then the terminal may transmit the route management instruction input by the user in the management instruction input interface to the management server, where the management server may be a server providing support for the management application installed on the terminal.
It will be appreciated that the user may also enter routing management instructions by accessing a preset management website directly in the management server or using a management application.
In this way, the management server may respond to receiving the routing management instruction input by the user, first sign the received routing node management instruction by using the 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 the routing node related to the routing node management instruction.
In step 215, the routing node responds to the received signed routing node management instruction sent by the management server, and performs signature verification on the received signed routing node management instruction by using the 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 signature verification passing.
By executing steps 214 to 216, the user can implement management of the routing node by inputting a routing management instruction for the routing node. And then the supervision department can realize the management of the routing nodes through the management server.
Alternative implementation (eleven): based on the optional implementation (ten), the above-described timing sequence 200 may further include steps 217 to 221:
in step 217, the management server signs the transaction management instruction by using the preset management private key and sends the 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 incrementing the specified account address by a specified number of digital currencies or decrementing the specified account address by a specified number of digital currencies.
Here, the user may input the transaction management instruction by using the implementation manner described in step 214, which is not described herein.
In this way, the management server may send the transaction management instruction to the second routing node after signing the transaction management instruction by using the preset management private key in response to receiving the transaction management instruction input by the user. The second routing node is a parallel link routing node corresponding to the account address related to the transaction management instruction.
In step 218, the routing node performs signature verification on the received signed transaction management instruction by using the preset management public key in response to receiving the signed transaction management instruction sent by the management server.
In response to the received signed transaction management instruction signature verification passing, the routing node sends the received signed transaction management instruction to the in-chain miner node of the routing node, step 219.
In step 220, the miner node responds to the received signed transaction management instruction sent by the node in the same link of the miner node, and performs signature verification on the received signed transaction management instruction by using a preset management public key.
In step 221, the miner node adds the transaction management instructions in the received signed transaction management instructions to the local set of pending transaction requests in response to the received signed transaction management instructions signature verification passing.
By performing steps 217 to 221, user entered transaction management instructions may be added to the local set of pending transaction requests at the mineworker node. In this way, the mineworker node may proceed to step 208, so that mineworker nodes competing for billing rights may record the transaction management instructions in the local blockchain. The supervision department can then realize the management of the transaction request through the management server.
Alternative implementation (twelve): based on the optional implementation (ten) or the optional implementation (eleven), the above-described timing sequence 200 may further include the following step 222:
in step 222, the routing node encrypts the abnormality related information of the detected abnormality by using the preset management public key in response to detecting the preset abnormality, and sends the encrypted abnormality related information to the management server.
Here, the preset anomalies may include, but are not limited to, the following anomalies:
(1) And the transaction request which is not confirmed by the account is in the transaction request set stored locally by the routing node within the first preset time.
(2) And the account entering is abnormal, namely transaction requests which do not finish account entering confirmation within a second preset duration exist 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 abnormality related information of the abnormality is also different. For example, if it is an exception 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, the number of lines 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 the abnormality related information of the detected abnormality using a preset management public key in response to detecting 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 anomaly related information using a preset management private key after receiving the encrypted anomaly related information. In this way, a user of the management server can determine that a problem is present by analyzing the abnormality related information described above, and improve the blockchain system according to the determined problem.
Due to the limitation of page display, it should be noted that, with continued reference to fig. 2C, the flow of fig. 2C may include, in addition to the flow shown in fig. 2C, the steps shown in fig. 2A and 2B.
Alternative implementation (thirteen): based on steps 201 through 208 shown in fig. 2, or any of the above alternative implementations, the above described sequence 200 may further include the following steps 223 through 230:
step 223, after the routing node is started, the public key and the private key of the routing node are obtained from the locally stored starting configuration information, and the signed public key for signing the public key of the routing node by using the preset management private key is obtained.
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 obtain a signed public key that signs the public key of the routing node with a preset management private key. Thus, after the device is started or restarted for the first time, the routing node can acquire the public key and the private key of the routing node from the locally stored starting configuration information, and acquire the signed public key for signing the public key of the routing node by using the preset management private key.
In step 224, the routing node broadcasts the obtained signed public key to the in-chain miner nodes of the routing node.
Here, the routing node may broadcast the signed public key obtained in step 223 to the in-chain miner nodes of the routing node.
And 225, the routing node signs the data sent to the same-chain miner node of the routing node by using the private key of the routing node and sends the data.
When the routing node needs to send data to the same-chain miner node of the routing node, the private key of the routing node is used for signing the data sent to the same-chain miner node of the routing node, and then the signed data is sent to the same-chain miner node of the routing node.
In step 226, the routing node decrypts the data received from the in-chain miner node of the routing node using the private key of the routing node.
Here, the routing node may decrypt the data received from the co-miner node of the routing node using the private key of the routing node when the data is received from the co-miner node of the routing node.
In step 227, the miner node performs signature verification on the received signed public key by using the preset management public key in response to receiving the signed public key sent by the node on the same link of the miner node.
Here, since the routing node sends the signed public key of the co-link miner node to sign with the preset management private key, the miner node may perform signature verification on the received signed public key with the preset management public key in response to receiving the signed public key sent by the node for the co-link of the miner node.
In response to the signed public key passing the signature verification, the miner node determines the public key of the received signed public key as the public key of the co-link slave node of the miner node, step 228.
In step 229, the miner node encrypts the data sent to the miner node's co-link slave node using the miner node's co-link slave node's public key.
Here, when the miner node needs to send data to the co-link slave node of the miner node, the miner node may first encrypt the data sent to the co-link slave node of the miner node using the public key of the co-link slave node determined in step 228, and then send the encrypted data to the co-link slave node of the miner node.
At step 230, the mineworker node uses the mineworker node's co-link slave node's public key to signature-verify the received data from the mineworker node's co-link slave node.
Here, since the data sent by the routing node to the co-link miner node is signed with the private key of the routing node, the miner node may verify the signature of the received data from the co-link router node of the miner node using the public key of the co-link router node when the data is received from the co-link router node of the miner node.
By performing steps 223 to 230, encrypted communication between the routing node and the in-chain miner nodes of the routing node may be achieved.
Due to the limitation of page display, it should be noted that, with continued reference to fig. 2D, the flow of fig. 2D may include, in addition to the flow shown in fig. 2D, the steps shown in fig. 2A, 2B, and 2C.
Alternative implementation (fourteen): based on steps 201 through 208 shown in fig. 2, or any of the above alternative implementations, the above described sequence 200 may further include the following step 231:
in step 231, the routing node sends a first hint information to the SPV node that sent the received transaction request in response to not verifying the received transaction request.
In step 202, the routing node adds the received transaction request to the set of transaction requests for the routing node in response to the received transaction request being verified. Here, the routing node may also send a first hint information to the SPV node that sent the received transaction request in response to not verifying the received transaction request. The first prompt message is used for indicating that the transaction request is not checked.
By executing step 231, the user of the SPV node that issued the transaction request may know that the transaction request submitted by the user has not passed the verification, so that the user of the SPV node may take corresponding measures, such as resending the transaction request, or resending the transaction request after modifying the transaction request after checking what problems the transaction request has been.
Alternative implementation (fifteen): based on steps 201 through 208 shown in fig. 2, or any of the above alternative implementations, the above described sequence 200 may further include the following steps 232 and 233:
step 232, for an abnormal transaction request in the transaction request set of the routing node, the routing node sends a burn instruction corresponding to the abnormal transaction request to each peer miner node 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 posting is not confirmed within the preset time period. The transaction requests in the transaction request set of the routing node are transaction requests that pass the routing node verification. Although the transaction requests in the transaction request set of the routing node are verified, various anomalies may actually occur, so that the transaction requests cannot be confirmed for a preset duration, and if the transaction requests are verified, the SPV node that sends the transaction requests does not confirm the corresponding digital currency of the transfer-out amount, and the transfer-out transaction in the transaction requests needs to be forced.
Specifically, for an abnormal transaction request in the transaction request set of the routing node, the routing node may send a burn instruction corresponding to the abnormal transaction request to each of the peer miners of the routing node. The burning instruction corresponding to the abnormal transaction request is used for indicating the mineworker node to reduce the account number address in the abnormal transaction request by the transfer amount in the abnormal transaction request.
Here, the transaction request confirmation ledger may refer to a transaction request that has been verified by the routing node and stored into the transaction request set of the routing node, and the ledger request of the transaction request confirms ledger. For example, the routing node may determine whether there is a record of operations performed by the outbound request in the recently validated chunk in the locally synchronously stored blockchain data. If there is a record of the operations that the posting request has performed, it is indicated that the posting request confirms the posting. Otherwise, if the operation record executed by the transaction request does not exist in the most recently confirmed block within a preset time period (for example, 1.2 hours), the routing node may wait for a preset time period, and if the operation record executed by the transaction request does not exist in the most recently confirmed block within the preset time period, the transaction request may be confirmed to be not confirmed to be posted. The last confirmed block refers to a plurality of blocks except the last six blocks at the tail in the locally stored synchronized block chain data, and the six blocks at the tail are removed because the block chain system generally uses six out-of-block acknowledgements as the condition of final confirmation.
Here, the transfer-out amount in the transaction request may include the following two parts: the amount transferred from the transfer account address in the transaction request to the transfer account address and the billing reward amount.
In response to receiving the burn instruction, the mineworker node executes the received burn instruction, step 233.
Here the miner node executing the burn instruction may include: first, the received burning instruction is analyzed to obtain an account-out transaction request with the account-out account address in the abnormal transaction request reduced by the transfer amount in the abnormal transaction request. The resulting outbound transaction request is then added to the set of pending transaction requests for the mineworker node. Finally, the miner node competing for the billing rights in the parallel chain in which the miner node is located writes the outbound transaction request to the local blockchain.
By performing steps 232 and 233, the time to wait for confirmation of a transaction may be reduced. That is, as long as the transaction request issued by the user at the SPV node is verified by the routing node, the transfer-out transaction is irreversible for the SPV node user, and the transfer-out amount is transferred out regardless of whether an anomaly occurs. For example, the user of account address a submits a transaction request using the reduced payment verification application for transferring X digital currencies of account address a to account address B to purchase a cup of coffee, the transaction request being submitted to and verified by the routing node. Then, the user of the account address A does not need to wait until the final account-out confirmation and the account-in confirmation of the transaction request, and can leave with a cup of coffee in advance, and the X digital currencies of the account address A can be transferred out no matter whether the account address B confirms that the X digital currencies transferred by the account address A are received or not. So that the time for the user of account address a to wait for confirmation of the transaction can be reduced.
Alternative implementation (sixteen): based on steps 201 through 208 of fig. 2, or any of the above alternative implementations, the above described sequence 200 may further include the following step 234:
in step 234, the routing node monitors the execution of each transaction request in the set of transaction requests for the routing node.
Here, since the blockchain data of the miner node in the parallel chain where the routing node is located is synchronously stored in the routing node, 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 synchronous blockchain data, so that the execution process of each transaction request is monitored.
Alternative implementation (sixteen): based on steps 201 through 208 shown in fig. 2, or any of the alternative implementations described above, the domain name of the routing node may be associated with a parallel chain identification of the parallel chain in which the routing node is located.
For example, "routenode0.Xxx.com" is a domain name of a routing node of a parallel chain indicated by a parallel chain identification "0", routenode1.Xxx.com "is a domain name of a routing node of a parallel chain indicated by a parallel chain identification" 1", and" routenode65535.Xxx.com "is a domain name of a routing node of a parallel chain indicated by a parallel chain identification" 65535
With an alternative implementation (sixteen), the process of the routing node determining its own parallel chain can be simplified.
Alternative implementation (seventeen): based on steps 201 through 208 shown in fig. 2, or any of the above alternative implementations, the above described sequence 200 may further include the following step 235:
in step 235, the management server expands the N parallel chains in the blockchain system to 2N parallel chains in response to receiving the expansion request.
In practice, the blockchain system will perform as the number of SPV nodes and miners nodes increases, and for this purpose, the blockchain system may be expanded, i.e., the number of parallel chains is increased. Here, the capacity expansion request may be initiated by the user on the management server. 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 route 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 respective routing nodes are located again.
Alternative implementation (eighteen): based on steps 201 through 208 shown in fig. 2, or any of the above alternative implementations, the above described sequence 200 may further include the following steps 236 and 237:
in step 236, the miner node encrypts the data sent to the same-chain miner node of the miner node using the first key and sends the encrypted data in a trusted execution environment of the miner node.
Here, when the miner node needs to send data to the same-chain miner node of the miner node, first, in a trusted execution environment of the miner node, the data sent to the same-chain miner node of the miner node is encrypted by using a first key, and then the encrypted data is sent to the same-chain miner node of the miner node. It should be noted that, the calculation process of the first key is also completed in the trusted execution environment of the miner node, the first key obtained by the calculation is also stored in the trusted execution environment of the miner node, and the first key is not accessible to applications outside the trusted execution environment of the miner node.
Here, the first key is generated based on the parallel chain identity of the parallel chain in which the mineworker node is located and m described above. As an example, the first key may be obtained by combining the parallel chain identity 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 in-chain miner node of the miner node using the first key in a trusted execution environment of the miner node.
Here, since the first key is generated based on the parallel chain identifier of the parallel chain in which the miner node is located and the m, the parallel chain identifier is the same for each miner node in which the parallel chain is located, and the m is the same for each different miner node in the same parallel chain, the first key generated based on the parallel chain identifier of the parallel chain in which the miner node is located and the m is the same. That is, different mineworker 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 mineworker node.
For the above reasons, if the miner node receives the data sent by the same-chain miner node of the miner node, the miner node may first obtain the first key in the trusted execution environment of the miner node, and then decrypt the data received from the same-chain miner node of the miner node using the first key, thereby obtaining the corresponding data.
Alternative implementation (nineteen): based on steps 201 to 208 shown in fig. 2, or any of the above alternative implementations, the above step 202 may include the following sub-steps 2021 to 2029:
sub-step 2021, in response to receiving a transaction request sent by the in-chain SPV node of the routing node, verifies the validity of the received transaction request.
Here, the routing node may first check the validity of the received transaction request in case of receiving the transaction request sent by the in-chain SPV node of the routing node. If the validity check passes, go to sub-step 2022. If the validity check does not pass, go to sub-step 2023.
Sub-step 2022, sends a second hint information to the SPV node sending the received transaction request to indicate that the validity check does not pass.
Here, the routing node may send a second hint information to the SPV node sending the received transaction request indicating that the validity check is not passed in case the validity check of the received transaction request is not passed in sub-step 2021. In this way, the SPV node sending the transaction request can learn that the validity check is not passed and wait for the next operation by the user. Here, the second hint information may be the same as or different from the first hint information transmitted in step 231 in the alternative implementation (fourteen).
Sub-step 2023 determines whether the routing node may receive a new transaction request based on the number of outstanding transaction requests in the set of transaction requests for the routing node.
Here, the routing node may determine whether the routing node may receive a new transaction request based on the number of outstanding transaction requests in the set of transaction requests of the routing node in case the validity check of the received transaction request in sub-step 2021 passes. If it is determined that a new transaction request can be received, sub-step 2024 may be passed.
For example, the routing node may first determine whether the number of outstanding transaction requests in the routing node's set of transaction requests is greater than a preset number of outstanding transactions. If so, it is determined that the routing node is not available to receive new transaction requests, and if not, it is determined that the routing node is available to receive new transaction requests.
Sub-step 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 operational process state for characterizing the posted in 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, storing the received transaction request, the corresponding transaction identification and the operational progress state for characterizing the posted correspondence to a preset distributed database, in case it is determined in sub-step 2023 that the routing node may receive a new transaction request. 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.
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, because there may be duplication between transaction numbers in each routing node, but the parallel chain identifiers of the parallel chains where each routing node is located are different, the transaction numbers and the parallel chain identifiers of the parallel chains where the routing node is located may be combined as transaction identifiers, so that the transaction identifiers may 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 update and store operation progress states of each transaction. Here, the operational progress status of the transaction may include, but is not limited to: validity check passed, validity check failed, transaction request set joined to routing node and unset, unset but unset for posting, etc.
Alternative implementation (twenty): based on steps 201 through 208 of fig. 2, or any of the alternative implementations described above, each parallel chain may also include ledger nodes, the ledger nodes of each parallel chain forming a distributed ledger cluster. Thus, the above described sequence 200 may further include the following steps 238 and 239:
in step 238, the ledger node synchronously stores the blockchains stored in the neighboring peer mineworker nodes or routing nodes of the ledger node into the local blockchain of the ledger node in real time.
Here, the ledger node may store the blockchains stored in the neighboring co-link mineworker nodes or routing nodes of the ledger node in real time into the local blockchain of the ledger node. In this way, blockchain data in each parallel chain is stored in the ledger node in real time.
In step 239, the ledger wall node responds to the received account information inquiry request sent by the terminal, inquires data in the distributed ledger cluster according to the account information inquiry request, and sends the inquiry result to the terminal sending the account information inquiry request.
Here, since each parallel chain of the blockchain system includes ledger nodes, and each ledger node stores blockchain data of the parallel chain where it is located, ledger nodes combining the respective parallel chains may constitute a distributed ledger cluster. Therefore, the account node can respond to the received account information query request sent by the terminal, query data in the distributed account cluster according to the account information query request, and send the query result to the terminal sending the account information query request. Thus, the block chain data of each parallel chain in the block chain system can be summarized, analyzed and queried.
According to the blockchain 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 by adopting at least one parallel chain mode, so that the number of transactions per second is increased along with the increase of the number of parallel chains, and TPS of the blockchain system is further improved.
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 blockchain system comprises at least one parallel chain, the parallel chain comprises a routing node, 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 blockchain, the routing nodes of the at least one parallel chain are connected through a network, 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 flow 300 of the routing method comprises the following steps:
in response to the received transaction request being checked, the received transaction request is added to the transaction request set of the routing node and signed and broadcast to the on-link miner nodes of the routing node, step 301.
In this embodiment, an executing entity (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 may be added to the transaction request set of the executing body, and the received transaction request may be signed and broadcasted to each of the in-chain miner nodes of the executing body.
The specific operation of step 301 in this embodiment is substantially the same as that of step 202 in the embodiment shown in fig. 2, and will not be described here again.
Step 302, synchronizing the blockchain of the co-chain miner nodes to the local blockchain in real-time.
In this embodiment, the executive may synchronize the blockchain of the on-chain miner nodes to the local blockchain. That is, the execution subject does not perform mining and billing operations, but the execution subject synchronously saves blockchain data (ledger) of a parallel chain in which the execution subject is located.
It should be noted that the execution subject may execute step 302 at any time, and is not limited to executing step 302 after executing step 301.
Step 303, determining a non-posted transaction request in the collection of transaction requests that is validated as posted and not posted.
In this embodiment, the executing entity may determine a non-posted transaction request that is confirmed to be posted and not posted in the locally stored transaction request set.
In this embodiment, the specific operation of step 303 is substantially the same as that of step 205 in the embodiment shown in fig. 2, and will not be described herein.
Step 304, the determined unsettled transaction request is sent to the routing node of the target parallel chain.
In this embodiment, the executing entity may send the determined outstanding transaction request to the routing node of the target parallel chain in step 303. The target parallel chain is a parallel chain corresponding to the account number address of the confirmed non-account transaction request.
In this embodiment, the specific operation of step 304 is substantially the same as that of step 206 in the embodiment shown in fig. 2, and will not be described here again.
In step 305, in response to receiving the transaction request sent by the node for the different link, the received transaction request is signed and then broadcast to the nodes of the same-chain miners.
In this embodiment, the executing entity may respond to the transaction request sent by the node in the different link, and broadcast the received transaction request after signing to the on-link miner node of the executing entity.
In this embodiment, the specific operation of step 305 is substantially the same as that of step 207 in the embodiment shown in fig. 2, and will not be described herein.
According to the routing method applied to the routing node of the blockchain system, provided by the embodiment of the application, the transaction request sent by the intra-chain SPV node of the routing node is checked, signed and forwarded, and the blockchain data of the same-chain miner node are synchronized in real time, so that the TPS of the blockchain system can be improved.
Referring now to FIG. 4, there is illustrated a schematic diagram of a computer system 400 suitable for use in implementing routing nodes of embodiments of the present application. The routing node shown in fig. 4 is only an example and should not impose any limitation on the functionality and scope of use of embodiments of the present application.
As shown in fig. 4, the computer system 400 includes a central processing unit (CPU, central Processing Unit) 401, which 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, random Access Memory) 403. In RAM 403, various programs and data required for the operation of system 400 are also stored. The CPU 401, ROM 402, and RAM 403 are connected to each other by a bus 404. An Input/Output (I/O) interface 405 is also connected to 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 portion 407 including a Cathode Ray Tube (CRT), a liquid crystal display (LCD, liquid Crystal Display), and the like, a speaker, and the like; a storage section 408 including a hard disk or 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. The drive 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 installed on the drive 410 as needed, so that a computer program read therefrom is installed into the storage section 408 as needed.
In particular, according to embodiments of the present disclosure, the processes described above with reference to 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 shown in the flowcharts. In such an embodiment, the computer program may be downloaded and installed from a network via the communication portion 409 and/or installed from the removable medium 411. The above-described functions defined in the method of the present application are performed when the computer program is executed by a Central Processing Unit (CPU) 401. It should be noted that, the computer readable medium described in the present application may be a computer readable signal medium or a computer readable storage medium, or any combination of the two. The computer readable storage medium can be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or a combination of any of the foregoing. More specific examples 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 context of this document, 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 the present application, however, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, with computer-readable program code embodied therein. Such a propagated data signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination of the foregoing. A 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 of the present application may be written in 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 kind of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or may be connected to an external computer (for example, through the Internet using an Internet service provider).
The flowcharts 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 that may be contained in the apparatus described in the above embodiments; or may be present alone without being fitted into the device. The computer readable medium carries one or more programs which, when executed by the apparatus, cause the apparatus to: in response to the received transaction request being verified, adding the received transaction request to a transaction request set of the routing node, and signing the received transaction request and broadcasting the signed transaction request to a co-chain miner node of the routing node; synchronizing the blockchain of the same-chain miner node of the routing node to a local blockchain in real time; determining a non-posted transaction request which is checked out and not posted in a transaction request set of a routing node; transmitting the determined non-posted transaction request to a routing node of a target parallel chain, wherein the target parallel chain is a parallel chain corresponding to a posted account number address in the determined non-posted transaction request; and in response to receiving the transaction request sent by the node for the different link, broadcasting the received transaction request to the on-link miner nodes of the routing node after signing.
The foregoing description is only of the preferred embodiments of the present application and is presented as a description of the principles of the technology being utilized. It will be appreciated by persons skilled in the art that the scope of the invention referred to in this application is not limited to the specific combinations of features described above, but it is intended to cover other embodiments in which any combination of features described above or equivalents thereof is possible without departing from the spirit of the invention. Such as the above-described features and technical features having similar functions (but not limited to) disclosed in the present application are replaced with each other.

Claims (38)

1. The utility model provides a blockchain system, includes at least one parallel chain, and the parallel chain includes routing node, at least one miner node and at least one simplified payment verification SPV node, and each miner node of every parallel chain adopts distributed data blockchain to store data, network connection between the routing node of at least one parallel chain, and the parallel chain that the account address that SPV node binds corresponds is the parallel chain that SPV node is located, wherein:
the SPV node is configured to: in response to receiving a transaction request, sending the received transaction request to a routing node of a parallel chain in which the SPV node is located;
The routing node is configured to: in response to passing the received transaction request verification, adding the received transaction request to a transaction request set of the routing node, and signing the received transaction request and broadcasting the signed transaction request to a co-link miner node of the routing node; synchronizing the blockchain of the same-chain miner node of the routing node to a local blockchain in real time;
the mineworker node is configured to: in response to passing verification of the signed transaction request received from the co-link slave node, adding an intra-link transaction request of the mineworker node in the signed transaction request to a set of pending transaction requests of the mineworker node;
the routing node is configured to: determining a non-posted transaction request which is confirmed to be posted and not posted in a transaction request set of the routing node; transmitting the determined non-posting transaction request to a routing node of a target parallel chain, wherein the target parallel chain is a parallel chain corresponding to a posting account address in the determined non-posting transaction request; and in response to receiving the transaction request sent by the node of the different link, broadcasting the received transaction request to the peer miner nodes of the routing node after signing.
2. The system of claim 1, wherein the miner node has a trusted execution environment disposed therein, and wherein the trusted execution environment of the miner node has stored therein a node identification for uniquely identifying the miner node.
3. The system of claim 2, wherein the mineworker node has an account address bound thereto; and
the mineworker node is configured to: in response to competing for billing rights to the parallel chain in which the mineworker node resides, performing the following billing operations: selecting a transaction request to be processed from a set of transaction requests to be processed of the miner node; generating a new block by using the selected to-be-processed transaction request, the mining rewarding information and the billing rewarding information of the miner node, wherein the mining rewarding information and the billing rewarding information of the miner node are respectively used for representing the mining rewards and account addresses bound by the miner node and corresponding to each account-out transaction request in the selected to-be-processed transaction request; the generated new block is connected in series to the local block chain of the miner node; and broadcasting the generated new block to other in-chain miner nodes of the miner node.
4. A system according to claim 3, wherein the account address comprises a virtual parallel chain identification and an account address string; and
The mineworker node is configured to: in response to detecting the account address generation request, performing the following account address binding operations in a trusted execution environment of the mineworker node: generating a new account address character string as the account address character string of the miner node in response to determining that the miner node is not bound with the account address; according to a preset calculation formula, calculating a virtual parallel chain identification of the miner node according to the node identification of the miner node, combining an account address character string of the miner node and the virtual parallel chain identification to obtain an account address, and determining the combined account address as the account address bound by the miner node.
5. The system of claim 4, wherein the blockchain system includes a number N of parallel chains to the power of 2 m, wherein m is a natural number between 0 and 16.
6. The system of claim 5, wherein the 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 a trusted execution environment of each of the mineworker nodes, the first preset mask being an integer between 0 and 65535; and
according to a preset calculation formula, calculating a virtual parallel chain identification of the miner node according to the node identification of the miner node, including:
And determining the result of performing exclusive OR operation on the binary representation of the node identifier of the miner node and the binary representation of the first preset mask by bits as a virtual parallel chain identifier of the miner node.
8. The system of claim 7, wherein the parallel chain identification for indicating the parallel chain is a natural number between 0 and (N-1).
9. The system of claim 8, wherein a second preset mask is stored in the trusted execution environment of each of the routing nodes and each of the mineworker nodes, the second preset mask being an integer between 0 and 65535; and
the mineworker node is configured to: in response to detecting a mineworker network entry request, performing the following parallel chain determination operations in a trusted execution environment of the mineworker node: performing bit-wise AND operation 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 the parallel chain indicated by the account parallel chain identification as a parallel chain corresponding to the account 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 the bits to obtain an exclusive-or operation result; performing AND operation on the binary representation of the difference between the obtained exclusive OR operation result and the N minus 1 according to the bit to obtain a miner parallel chain identifier; and determining the parallel chain where the miner node is located as the parallel chain indicated by the miner parallel chain identification.
10. The system of claim 9, wherein the N and the 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 the N, the m and the second preset mask; and
the mineworker node is configured to: in response to receiving encrypted parallel chain configuration information sent by a node in the same link of the miner node, decrypting the received encrypted parallel chain configuration information in a trusted execution environment of the miner node; and in response to the verification passing of the decrypted parallel chain configuration information, updating the N, m and the second preset mask stored in the trusted execution environment of the mineworker node with 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 in network connection with each of the routing nodes, the management server having stored therein a preset management private key and a preset management public key, each of the routing nodes and each of the miner nodes having stored therein the preset management public key; and
The management server is configured to: responding to a 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: responding to the received signed routing node management instruction sent by the management server, and performing signature verification on the received signed routing node management instruction by utilizing the preset management public key; and in response to the received signed routing node management instruction signature verification passing, executing the routing node management instruction in the received signed routing node management instruction.
12. The system of claim 11, wherein:
the management server is configured to: responding to a transaction management instruction input by a user, signing the transaction management instruction by utilizing the preset management private key, and then sending the transaction management instruction to a second routing node, wherein the second routing node is a routing node of a parallel chain corresponding to an account address related to the transaction management instruction;
The routing node is configured to: responding to the received signed transaction management instruction sent by the management server, and performing signature verification on the received signed transaction management instruction by utilizing the preset management public key; in response to the received signed transaction management instruction signature verification passing, sending the received signed transaction management instruction to a co-chain miner node of the routing node;
the mineworker node is configured to: responding to the received signed transaction management instruction sent by the node in the same link of the miner node, and performing signature verification on the received signed transaction management instruction by utilizing the preset management public key; in response to the received signed transaction management instruction signature verification passing, adding the transaction management instruction of the received signed transaction management instruction to the local set of pending transaction requests.
13. The system of claim 12, wherein the routing node is further configured to:
in response to detecting a preset abnormality, encrypting abnormality related information of the detected abnormality by using the preset management public key, and transmitting the encrypted abnormality 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, a public key and a private key of the routing node are obtained from locally stored starting configuration information, a signed public key for signing the public key of the routing node by utilizing the preset management private key is obtained, the obtained signed public key is broadcasted to the same-chain miner node of the routing node, the private key of the routing node is utilized to sign and then send the data sent to the same-chain miner node of the routing node, and the private key of the routing node is utilized to decrypt the data received from the same-chain miner node of the routing node; and
the mineworker node is further configured to: responding to the received signed public key sent by the node in the same link of the miner node, and carrying out signature verification on the received signed public key by utilizing the preset management public key; in response to signature verification passing of the signed public key, determining a public key of the received signed public key as a public key of the co-link slave node of the miner node; and encrypting the data sent to the co-link slave node of the miner node by using the public key of the co-link slave node of the miner node, and then sending the data, and signature verification is carried out on the received data from the co-link slave node of the miner node by using the public key of the co-link slave node of the miner node.
15. The system of claim 14, wherein the routing node is configured to:
and responding to the failure of the verification of the received transaction request, and sending first prompt information to an SPV node sending the received transaction request, wherein the first prompt information is used for indicating that the failure of the verification of the transaction request is indicated.
16. The system of claim 15, wherein the routing node is configured to:
for an abnormal transaction request in a 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 account is not confirmed within a preset time period, and the incineration instruction corresponding to the abnormal transaction request is used for indicating the miner node to reduce the account number address in the abnormal transaction request by the transfer amount in the abnormal transaction request; and
the mineworker node is configured to: in response to receiving the burn instruction, executing the received burn instruction.
17. The system of claim 16, wherein the routing node is configured to:
the execution of each transaction request in the set of transaction requests of the routing node is monitored.
18. The system of claim 17, wherein the domain name of a routing node is associated with a parallel chain identification of a parallel chain in which the routing node is located.
19. The system of claim 18, wherein the management server is configured to:
in response to receiving the expansion request, expanding N parallel chains in the blockchain system to 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;
in a trusted execution environment of the mineworker node, data received from the in-chain mineworker node of the mineworker node is decrypted using the first key.
21. The system of claim 20, wherein the routing node is configured to: in response to passing the received transaction request verification, adding the received transaction request to the set of transaction requests for the routing node, including:
the routing node is configured to: in response to receiving a transaction request sent by a same-chain 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 the failure of the validity check to an SPV node sending the received transaction request; determining whether the routing node can receive new transaction requests according to the number of unprocessed transaction requests in the transaction request set of the routing node in response to the passing of the validity check; in response to determining that a new transaction request can be received, adding the received transaction request to 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 progress state for representing an issued transaction 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 in which the routing node is located.
22. The system of claim 21, wherein the routing node is configured to:
determining an credited transaction request of credited confirmation in the transaction request set of the routing node;
and updating the operation progress state of the checked-in transaction request determined in the preset distributed database into the checked-in transaction according to the determined transaction identification of the checked-in transaction request.
23. The system of any of claims 1-22, wherein each of the parallel chains further includes 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 blockchains stored in adjacent same-chain miner nodes or routing nodes of the account node into local blockchains of the account node in real time;
responding to an account information inquiry request sent by a receiving terminal, inquiring data in the distributed account book cluster according to the account information inquiry request, and sending an inquiry result to the terminal sending the account information inquiry request.
24. A routing method applied to routing nodes of a blockchain system, wherein the blockchain 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 blockchain, the routing nodes of the at least one parallel chain are connected through a network, and a 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 comprising:
In response to passing the received transaction request verification, adding the received transaction request to a transaction request set of the routing node, and signing the received transaction request and broadcasting the signed transaction request to a peer miner node of the routing node;
synchronizing the blockchain of the co-link miner node of the routing node to a local blockchain in real time, wherein the miner node responds to the verification of the post-signature transaction request received from the co-link miner node and adds an intra-link transaction request of the miner node in the post-signature transaction request to a set of pending transaction requests of the miner node;
determining a non-posted transaction request which is confirmed to be posted and not posted in a transaction request set of the routing node;
transmitting the determined non-posting transaction request to a routing node of a target parallel chain, wherein the target parallel chain is a parallel chain corresponding to a posting account address in the determined non-posting transaction request; and
in response to receiving a transaction request sent by a node of the different link, the received transaction request is signed and then broadcast to the on-link miner nodes of the routing node.
25. The method of claim 24, wherein a trusted execution environment is provided in the mineworker node, the blockchain system comprising a number N of parallel chains to the power of 2 to m, wherein m is a natural number between 0 and 16.
26. The method of claim 25, wherein the N, the m, and a second preset mask are stored in a trusted execution environment of each miner node and each routing node, the second preset mask being an integer between 0 and 65535; and
the method further comprises the steps of: and encrypting the locally stored parallel chain configuration information to obtain encrypted parallel chain configuration information, and transmitting 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.
27. The method of claim 26, wherein the blockchain system further comprises a management server in network connection with each of the routing nodes, the management server having stored therein a preset management private key and a preset management public key, each of the routing nodes and each of the miner nodes having stored therein the preset management public key; and
the method further comprises the steps of:
responding to the received signed routing node management instruction sent by the management server, and performing signature verification on the received signed routing node management instruction by utilizing the preset management public key;
And in response to the received signed routing node management instruction signature verification passing, executing the routing node management instruction in the received signed routing node management instruction.
28. The method of claim 27, wherein the method further comprises:
responding to the received signed transaction management instruction sent by the management server, and performing signature verification on the received signed transaction management instruction by utilizing the preset management public key;
and in response to the received signed transaction management instruction signature verification passing, transmitting the received signed transaction management instruction to a co-link miner node of the routing node.
29. The method of claim 28, wherein the method further comprises:
in response to detecting a preset abnormality, encrypting abnormality related information of the detected abnormality by using the preset management public key, and transmitting the encrypted abnormality related information to the management server.
30. The method of claim 29, wherein the method further comprises:
after the routing node is started, a public key and a private key of the routing node are obtained from locally stored starting configuration information, and a signed public key for signing the public key of the routing node by utilizing the preset management private key is obtained;
Broadcasting the obtained public key after signing to the same-chain miner nodes of the routing nodes;
signing and transmitting data of the same-chain miner node transmitted to the routing node by using the private key of the routing node; 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:
and responding to the failure of the verification of the received transaction request, and sending first prompt information to an SPV node sending the received transaction request, wherein the first prompt information is used for indicating that the failure of the verification of the transaction request is indicated.
32. The method of claim 31, wherein the method further comprises:
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-link miner node of the routing node, wherein the abnormal transaction request is a transaction request for which the account is not confirmed within a preset time period, and the incineration instruction corresponding to the abnormal transaction request is used for indicating the miner node to reduce the account number address in the abnormal transaction request by the transfer amount in the abnormal transaction request.
33. The method of claim 32, wherein the method further comprises:
the execution process of each transaction request in the transaction request set of the routing node is monitored.
34. The method of claim 33, wherein the domain name of the routing node is associated with a parallel chain identification of a parallel chain in which the routing node is located.
35. The method of claim 34, wherein the adding the received transaction request to the set of transaction requests of the routing node in response to the received transaction request being verified, comprises:
in response to receiving a transaction request sent by a same-chain 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 the failure of the validity check to an SPV node sending the received transaction request;
determining whether the routing node can receive new transaction requests according to the number of unprocessed transaction requests in the transaction request set of the routing node in response to the passing of the validity check;
in response to determining that a new transaction request can be received, adding the received transaction request to 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 progress state for representing an issued transaction 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 in which the routing node is located.
36. The method of claim 35, wherein the method further comprises:
determining an credited transaction request of credited confirmation in a transaction request set of the routing node;
and updating the operation progress state of the checked-in transaction request determined in the preset distributed database into the checked-in transaction according to the determined transaction identification of the checked-in transaction request.
37. An electronic device for a routing node of a blockchain system, 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 stored thereon a computer program, wherein the computer program when executed by one or more processors implements the method of any of claims 24-36.
CN201810636486.6A 2018-06-20 2018-06-20 Block chain system and routing method applied to routing nodes of block chain system Active CN110619520B (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN201810636486.6A CN110619520B (en) 2018-06-20 2018-06-20 Block chain system and routing method applied to routing nodes of block chain system
PCT/CN2019/090355 WO2019242508A1 (en) 2018-06-20 2019-06-06 Blockchain system and routing method of routing node applied to blockchain system

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201810636486.6A CN110619520B (en) 2018-06-20 2018-06-20 Block chain system and routing method applied to routing nodes of block chain system

Publications (2)

Publication Number Publication Date
CN110619520A CN110619520A (en) 2019-12-27
CN110619520B true CN110619520B (en) 2023-05-02

Family

ID=68920761

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201810636486.6A Active CN110619520B (en) 2018-06-20 2018-06-20 Block chain system and routing method applied to routing nodes of block chain system

Country Status (2)

Country Link
CN (1) CN110619520B (en)
WO (1) WO2019242508A1 (en)

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111275437B (en) * 2020-01-12 2023-05-30 杭州复杂美科技有限公司 Parallel chain consensus method, apparatus and storage medium
CN111401868B (en) * 2020-03-19 2022-07-01 南开大学 Minimum-cost block chain down-link transaction routing algorithm
CN112231105B (en) * 2020-10-26 2023-10-27 中国工商银行股份有限公司 Block writing method and system based on block chain
CN112104517B (en) * 2020-11-23 2021-02-05 腾讯科技（深圳）有限公司 Data processing method based on block chain network and related device
CN112446050B (en) * 2021-02-01 2021-05-18 腾讯科技（深圳）有限公司 Business data processing method and device applied to block chain system
CN113691508B (en) * 2021-08-06 2023-04-18 上海浦东发展银行股份有限公司 Data transmission method, system, device, computer equipment and storage medium
CN114500030B (en) * 2022-01-21 2023-06-20 黎鸿 Elastic chain method based on digital address
CN115811498A (en) * 2023-02-06 2023-03-17 北京微芯区块链与边缘计算研究院 Node routing method, device, equipment and storage medium of alliance chain
CN117240605B (en) * 2023-11-10 2024-02-02 北京中科江南信息技术股份有限公司 Data transaction method, device, equipment and storage medium

Citations (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106385319A (en) * 2016-09-29 2017-02-08 江苏通付盾科技有限公司 Verification method for information in block chain network and verification system thereof
CN106452785A (en) * 2016-09-29 2017-02-22 财付通支付科技有限公司 Block chain network, branch node and block chain network application method
CN106936589A (en) * 2017-04-21 2017-07-07 杭州秘猿科技有限公司 A kind of acentric the license parallel sharding method of chain and method of commerce
CN107294729A (en) * 2017-07-25 2017-10-24 中国联合网络通信集团有限公司 Communication means and device in block chain between different nodes
CN107291862A (en) * 2017-06-12 2017-10-24 腾讯科技（深圳）有限公司 Business datum storage method, device, storage medium and electronic equipment
CN107395353A (en) * 2017-04-24 2017-11-24 阿里巴巴集团控股有限公司 A kind of block chain common recognition method and device
CN107678865A (en) * 2017-09-20 2018-02-09 中国银行股份有限公司 The verification method and system of block chain based on transaction packet
CN107688999A (en) * 2017-08-11 2018-02-13 杭州秘猿科技有限公司 A kind of parallel transaction based on block chain performs method
CN107742210A (en) * 2017-10-13 2018-02-27 布比（北京）网络技术有限公司 Across the chain fund transfer system and method for a kind of different blocks interchain
CN107862216A (en) * 2017-10-13 2018-03-30 布比（北京）网络技术有限公司 Method for secret protection, device and the storage medium merchandised for anonymity across chain
CN107909369A (en) * 2017-10-13 2018-04-13 布比（北京）网络技术有限公司 Based on the common recognition method, apparatus merchandised across chain and storage medium

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10812274B2 (en) * 2015-05-07 2020-10-20 Blockstream Corporation Transferring ledger assets between blockchains via pegged sidechains
CN107277781B (en) * 2017-05-03 2019-03-22 上海点融信息科技有限责任公司 Block chain multicast network, block chain equipment and its communication means under mobile broadband network

Patent Citations (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106385319A (en) * 2016-09-29 2017-02-08 江苏通付盾科技有限公司 Verification method for information in block chain network and verification system thereof
CN106452785A (en) * 2016-09-29 2017-02-22 财付通支付科技有限公司 Block chain network, branch node and block chain network application method
CN106936589A (en) * 2017-04-21 2017-07-07 杭州秘猿科技有限公司 A kind of acentric the license parallel sharding method of chain and method of commerce
CN107395353A (en) * 2017-04-24 2017-11-24 阿里巴巴集团控股有限公司 A kind of block chain common recognition method and device
CN107291862A (en) * 2017-06-12 2017-10-24 腾讯科技（深圳）有限公司 Business datum storage method, device, storage medium and electronic equipment
CN107294729A (en) * 2017-07-25 2017-10-24 中国联合网络通信集团有限公司 Communication means and device in block chain between different nodes
CN107688999A (en) * 2017-08-11 2018-02-13 杭州秘猿科技有限公司 A kind of parallel transaction based on block chain performs method
CN107678865A (en) * 2017-09-20 2018-02-09 中国银行股份有限公司 The verification method and system of block chain based on transaction packet
CN107742210A (en) * 2017-10-13 2018-02-27 布比（北京）网络技术有限公司 Across the chain fund transfer system and method for a kind of different blocks interchain
CN107862216A (en) * 2017-10-13 2018-03-30 布比（北京）网络技术有限公司 Method for secret protection, device and the storage medium merchandised for anonymity across chain
CN107909369A (en) * 2017-10-13 2018-04-13 布比（北京）网络技术有限公司 Based on the common recognition method, apparatus merchandised across chain and storage medium

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
区块链技术:应用及问题;翟社平等;《西安邮电大学学报》;20180110(第01期);5-17 *

Also Published As

Publication number Publication date
CN110619520A (en) 2019-12-27
WO2019242508A1 (en) 2019-12-26

Similar Documents

Publication Publication Date Title
CN110619520B (en) Block chain system and routing method applied to routing nodes of block chain system
CN112214780B (en) Data processing method and device, intelligent equipment and storage medium
CN109462588B (en) Decentralized data transaction method and system based on block chain
CN110535648B (en) Electronic certificate generation and verification and key control method, device, system and medium
CN110766406B (en) Resource transfer method, resource transfer device, storage medium and electronic equipment
CN110855791B (en) Block link point deployment method and related equipment
US11588643B2 (en) Blockchain management system
CN111740966B (en) Data processing method based on block chain network and related equipment
US20090138699A1 (en) Software module management device and program
CN111597567B (en) Data processing method, data processing device, node equipment and storage medium
CN110096894B (en) Data anonymous sharing system and method based on block chain
CN110149323B (en) Processing device with ten-million-level TPS (platform secure protocol) contract processing capacity
CN108923925B (en) Data storage method and device applied to block chain
CN112001713B (en) Block chain system and request processing method and device
CN103281187A (en) Security authentication method, equipment and system
CN114567643B (en) Cross-blockchain data transfer method, device and related equipment
Leiba et al. IoTPatchPool: Incentivized delivery network of IoT software updates based on proofs-of-distribution
CN115705601A (en) Data processing method and device, computer equipment and storage medium
CN105051769A (en) A method and system for transferring data
CN114143312A (en) Block chain-based edge computing terminal authentication method, system and equipment
CN115409511B (en) Personal information protection system based on block chain
JP6939313B2 (en) Distributed authentication system
US20220216999A1 (en) Blockchain system for supporting change of plain text data included in transaction
CN113014556B (en) Bank-enterprise communication system, communication method and electronic terminal
KR101581663B1 (en) Authentication and non-repudiation method and system using trusted third party

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant