CN109471744B - Main chain and parallel multi-sub-chain system architecture based on block chain - Google Patents
Main chain and parallel multi-sub-chain system architecture based on block chain Download PDFInfo
- Publication number
- CN109471744B CN109471744B CN201811392135.1A CN201811392135A CN109471744B CN 109471744 B CN109471744 B CN 109471744B CN 201811392135 A CN201811392135 A CN 201811392135A CN 109471744 B CN109471744 B CN 109471744B
- Authority
- CN
- China
- Prior art keywords
- chain
- sub
- node
- main chain
- cross
- 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
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/542—Event management; Broadcasting; Multicasting; Notifications
-
- 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/3825—Use of electronic 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/3827—Use of message hashing
-
- 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/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G06Q20/401—Transaction verification
-
- 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 invention comprises 1 main chain and n parallel sub-chains, wherein n is 1 … X, each node stores main chain data and is initially distributed by a system to store all data of a certain sub-chain, and each node further comprises a sub-chain cross-chain message queue. The main chain data does not store specific transactions, but stores system global information, and after a sub-chain exits a block, a sub-chain block head is submitted to the main chain through main chain P2P network broadcasting, the sub-chain modifies the main chain information, and cross-chain request/response notification information; the submissions of all the child chains form a main chain block which is broadcast to all the nodes; after each node receives the main chain block, the local main chain is updated so as to keep the main chain data of all the nodes consistent; and the current node directly connects with other sub-chain nodes to acquire the details of the request or the response information and processes the details according to the cross-chain request/response notification information acquisition request in the main chain data or response to other sub-chain information of the current sub-chain.
Description
Technical Field
The invention relates to a block chain technology, in particular to a system architecture with a main chain and a plurality of parallel sub-chains, which improves the expandability and the performance of a block chain.
Background
Now each common node in the blockchain needs to: 1. storing all the states; 2. executing all transactions in series; 3. to be in common with all other machines.
The basic idea of the expansion of the existing block chain is as follows: 1. a single node stores only a partial state; 2. a single node only processes a portion of the transactions; 3. only part of the nodes are allowed to participate in consensus.
Please refer to fig. 1, which is a schematic diagram illustrating slicing by user. If the users are fragmented, the transfer among different fragmented users is difficult to process, the contracts are also difficult to deploy, if the contracts are deployed on all the fragments, the contract states cannot be consistent, and if the contracts are deployed on one fragment, the requests of other fragmented users cannot be processed.
Fig. 2 is a schematic diagram of slicing according to a contract. If the contracts are divided into segments according to the contracts, each contract needs to be capable of processing the transactions of all users, the account state of each user can be checked/modified (for example, for an Ethern, all transactions need to modify the account balance due to gas consumption, for an EOS, the CPU/bandwidth/storage quota of the account needs to be modified), the contracts are executed in parallel, the consistency of the user states cannot be ensured, in addition, the contracts are frequently mutually called, and if the contracts are distributed on different segments, the contracts cannot be called.
In the third extended concept, part of the nodes participate in consensus and 1% of attacks are triggered, that is, assuming that there are 100 segments, an attacker only needs to control 1% of the nodes, and thus can completely control one segment.
The existing expansion schemes mainly comprise Ether workshop sharing, Ether workshop plasma, Cosmos Network, Polkadot, Lisk, Ashi chain, Zilliqa, VBFT, DPOS, Algorand, Dfinity and the like.
Ether house sharing: the problem of ether house expansion is solved for a long time. At present, 1% of attacks are mainly considered, a fragment chain cannot execute transactions, and the fragment chain is far away from practical application.
Ether house plasma: according to application, namely contract slicing, part of the contract is stored and executed on the side chain, the token can be transferred to the side chain, subsequent transactions are carried out on the side chain, and even if the side chain is not credible, the token can be safely transferred back to the main chain, which represents a game chain with a Low network. The limitation is that the side chain must adopt UTXO model, the practical application range is too narrow, the time for returning the token is too long, and at least 7 days are needed.
Cosmos Network, Polkadot: according to application fragmentation, a main chain is provided, each application uses a side chain of the application to define a main chain/side chain interaction protocol, and meanwhile, a bottom platform and a tool are provided to facilitate a third party to develop a self-defined side chain. The limitation is that the sub-chain is not transparent to users, the sub-chain has 1% attack problem, and both items are in development and lack detailed introduction.
Lisk, asig chain: fragmentation by application, emphasis is placed on the ease of creating side chains. The limitation is that the daughter strand is not transparent to the user, and 1% of the daughter strand attacks, and side chain customization is weaker than that of Cosmos/Polkadot.
Zilliqa: according to the user slicing, intra-chain transactions of different sub-chains (namely, the user and the contract are in the same slicing) can be executed in parallel. The limitations are that they cannot be completely parallel, there is no state fragmentation, there is no cross-chain communication, and there is no detailed introduction in the development.
VBFT, DPOS, Algorand, Dfine: part of nodes participate in consensus and simultaneously avoid 1% of attacks, DPOS is a voting node, and VBFT/Algorand/Ddefinition adopts verifiable random selection consensus nodes. The limitation is still limited to stand-alone storage/processing/network capabilities.
In summary, the scalability is still a difficult point at present, and the scalability through fragmentation and multi-chain is a basic solution, but how to perform fragmentation is a key problem? How do multiple chains appear externally as one chain? How to achieve linear extension while keeping the cross-link overhead low under the premise of ensuring security? It is also the problem that the present invention is to study and solve.
Disclosure of Invention
The invention aims to solve the problem of expansibility of a current block chain on the premise of not sacrificing security and distribution.
The invention firstly provides a system architecture based on a block chain main chain and parallel multiple sub-chains, which comprises a main chain and N parallel sub-chains, wherein N is 1.. X, each node stores main chain data, each node is initially allocated and stored with all data of one sub-chain by a system, and each node further comprises a sub-chain cross-chain message queue; all data of the sub-chains initially allocated and stored by the system of each node comprise accounts, contracts and transactions of the corresponding sub-chains; wherein the main chain data does not store specific transactions but system global information; the sub-chain cross-chain message queue comprises two types, one type is a cross-chain request queue, and the other type is a cross-chain response queue; each node network layer comprises a main chain P2P network, a sub-chain data P2P network and a sub-chain verification P2P network; the main chain P2P network is used for the sub-chain submitting data to the main chain, propagating main chain data and coordinating cross-chain communication; each node storing all data of a certain sub-chain synchronizes sub-chain transactions and blocks through a sub-chain data P2P network; wherein, each node responsible for verifying the same sub-chain transaction verifies and signs the transaction and the block through the sub-chain verification P2P network; the submitted data of all the child chains form a main chain block and are broadcast to all the nodes, and after each node receives the main chain block, the local main chain is updated so as to keep the main chains of all the nodes consistent.
Wherein the backbone data comprises at least: the number of the sub chains, the sub chain block head, the mapping relation between the account and the sub chain, the mapping relation between the contract and the sub chain, the mapping relation between the data node and the sub chain, the mapping relation between the verification node and the sub chain, cross-chain request/response notification information and all contract codes; in the cross-link request queue, each target sub-chain is established and used for storing request message details sent to the target sub-chain, and different target sub-chains are divided into different queues; in the cross-chain response queue, each source chain is established and used for storing the details of the response message sent to the source chain, and different source chains are divided into different queues; the cross-chain request/response notification information is a notification corresponding to a cross-chain request/response queue, without details.
The technical scheme of the invention comprises the following interaction processes of the sub-chain and the main chain: after the sub-chain exits the block, a sub-chain block head is submitted to a main chain through main chain P2P network broadcasting, the sub-chain modifies the main chain information, and cross-chain request/response notification information; the submissions of all the child chains form a main chain block which is broadcast to all the nodes; after each node receives the main chain block, the local main chain is updated so as to keep the main chain data of all the nodes consistent; and the current node directly connects with other sub-chain nodes to acquire the details of the request or the response information and processes the details according to the cross-chain request/response notification information acquisition request in the main chain data or response to other sub-chain information of the current sub-chain.
When the current node acquires the cross-chain request or the details of the response information, the current node requests the Mercker certification data together, the target node verifies the request information of the current node according to the current sub-chain block head and the Mercker certification data contained in the local main chain information, and after the verification is passed, the request is processed.
The invention also provides a cross-chain system contract, the external interface of the contract is a send method, the parameters of the contract comprise a source address, a target sub-chain, a receiving address, a payment amount and a request message, the cross-chain system contract comprises an address of the cross-chain system contract, the address is a fixed value without a private key, and the address is fixed and open in the code; the workflow of the cross-chain system contract is as follows:
a user firstly pays a cross-link system contract of a source sub-link, a user sub-link node of the source sub-link at the user sub-link receives request message details, the user sub-link node is placed into a local cross-link request queue aiming at a receiving sub-link, after the source sub-link exits a block, the source sub-link node submits source link block head information to a main chain through a main chain P2P network, and the submitted information also contains cross-link request notification information of all transactions in the converged block; the transaction submitted by each sub-chain to the main chain forms a main chain block, and cross-chain notification information contained in the main chain block is broadcasted to all nodes through the main chain P2P network;
when a receiving sub-chain target node receives a main chain block, discovering a cross-chain request notification of an active sub-chain to the receiving sub-chain, directly connecting the source sub-chain node, and acquiring request information details and requested merkel certification data; receiving request information of a sub-chain target node of a user according to a source sub-chain block head and Mercker certification data contained in local main chain information, processing the request after the user is verified to pay really, paying the target address, generating cross-chain response detail information, and storing and updating a cross-chain response queue state; when a receiving sub-chain target node submits block header information to a main chain through a main chain P2P network, cross-chain response notification information is submitted;
when the submission of the receiving sub-chain is contained in the main chain block and synchronized to the user sub-chain node, the user sub-chain node is directly connected with the receiving sub-chain target node, and response details including the Mercker evidence data of the response are acquired; and verifying the response of the target node of the link by the user sub-link node according to the received sub-link block head and the Mercker certification data contained in the local main chain information, updating the request queue after the verification is passed, processing possible failure rollback, refunding the user if the payment of the received sub-link fails, and finally calling a callback function provided by the user.
In all the above schemes, when a node returns any transaction or block hash, a child chain id value is embedded in the hash, the query is to analyze a source child chain id and/or a received child chain id from the transaction hash and the block hash, and query the child chain node connection information according to the child chain id, and the child chain node connection information is stored in the mapping relationship between the data node of the main chain data and the child chain.
The system architecture of the invention has the following characteristics:
1. universality: not only can cross-chain transfer be realized, but also any cross-chain message transmission can be realized.
2. Reliability: similar to the TCP protocol, the communication is reliable, the request must be responded to, and not a one-way transmission.
3. Safety: any node has main chain information, namely sub-chain block heads of all sub-chains, can be used as SPV clients of all sub-chains, and can verify the request/response of any sub-chain through Merkle Proof without trusting the sub-chain node directly connected.
Cross-chain communication is also efficient and scalable, as embodied in:
1. the cross-link communication details of the child chains are not sent to the main chain, nor are they propagated across the main chain P2P network, with only new request/response notification information being propagated on the main chain.
2. The cross-chain communication notification message of the sub-chain is the summary of all transactions in the sub-chain block, and is submitted to the main chain along with the sub-chain block head, and no additional communication overhead exists.
3. The main chain has no specific transaction, the transaction number in one main chain block is only related to the number of the sub-chains, in one consensus period, only one node of each sub-chain submits the transaction to the main chain, and the transaction content is only the main chain modification, the sub-chain block head and the gathered cross-chain notification information, so that the transaction, network communication, storage and the like of the main chain are not bottlenecks.
4. The sub-chain nodes independently apply the main chain block and are directly connected with other adjacent sub-chain nodes to obtain the request/response details, the process is parallel and distributed, and no node is a bottleneck.
In summary, although the cross-chain communication is via the main chain, the load of the main chain is very low and is not a bottleneck, the number of sub-chains that can be accommodated is related to the transaction number that can be contained in the main chain block, calculated by the block size of 1MB and 1KB of single transaction, 1024 sub-chains can be accommodated, and the processing capacity of the whole system can be linearly expanded as the number of sub-chains increases before the number of sub-chains reaches the value.
Drawings
Fig. 1 is a schematic diagram illustrating a block chain expansion manner according to user fragmentation in the prior art.
Fig. 2 is a schematic diagram of a block chain expansion manner partitioned according to a contract in the prior art.
FIG. 3 is a logic diagram of a system using a main chain plus multiple subchains in parallel according to the present invention.
FIG. 4 is an architecture diagram of a single node based on the main chain plus parallel multi-subchain logic in the present invention.
Fig. 5 is a multi-point architecture scheme deployed based on the single point in fig. 4 in the present invention.
FIG. 6 is a flow diagram of the interaction of a main chain and a child chain.
Fig. 7 is a flowchart for obtaining node connection information and transaction and block details according to the transaction hash txhash and the block hash blockhash.
FIG. 8 is a flow chart of data verification between a node initiating a transaction and a target node via merkel proof (MerkleProof).
Detailed Description
Please refer to fig. 3, which is a logic diagram of a system with a main chain and multiple parallel subchains according to the present invention. The invention comprises 1 main chain and n parallel sub-chains, wherein n is 1. Wherein, the main chain data does not store specific transaction, but stores the global information of the system, and at least comprises: the number of the sub chains, the sub chain block header, the mapping relationship between the account and the sub chain, the mapping relationship between the contract and the sub chain, the mapping relationship between the data node and the sub chain, the mapping relationship between the verification node and the sub chain, cross-chain request/response notification information, all contract codes, sub chain load, whether the sub chain is effective or not, and the like. Wherein the cross-chain notification message is a notification message corresponding to the message details in the sub-chain cross-chain message queue. Each sub-chain has a sub-chain id, each node has a node id, the sub-chain information refers to the sub-chain id, the sub-chain position includes the sub-chain id and sub-chain node connection information corresponding to the source sub-chain, the sub-chain node connection information is stored in a data node < - > sub-chain mapping table, and the sub-chain node connection information mainly includes sub-chains located on the nodes, and the IP addresses and ports of the nodes.
All data of the sub-chains initially allocated by the system by each node comprise accounts, contracts and transactions of the corresponding sub-chains. The contracts in all the data of the child chain include complete information such as the state of the contracts in addition to the contract codes. The sub-chain cross-chain message queue comprises two types, one type is a cross-chain request queue, one type is created for each target sub-chain, request message details sent to the target sub-chain are stored, and different target sub-chains are divided into different queues; the other is a cross-chain response queue, one created per source chain, storing response message details sent to the source chain, with different source chains divided into different queues.
The nodes realize point-to-point access through a P2P network, and the above architecture scheme is realized, wherein the network layer further comprises a sub-chain P2P in addition to a main chain P2P, and the main chain P2P network is used for submitting data (sub-chain block heads, modification information of the sub-chains to the main chain, and cross-chain notification information) to the main chain by the sub-chain, propagating main chain data, and coordinating cross-chain communication (communication of the cross-chain notification information among the nodes). The daughter chain P2P is further divided into two categories: the child chain data P2P and the child chain validation P2P. Each node storing all data of a certain child chain synchronizes child chain transactions and blocks through the child chain data P2P network. Each node responsible for verifying the same child chain transaction verifies and signs the transaction and the block through the child chain verification P2P. For a certain node, it may be a storage of a certain child chain data, and participate in the child chain data P2P network, and at the same time, may be a verifier of the same child chain or other child chains, and participate in the child chain verification P2P network. The subchain roles of the nodes are initially allocated by the system, the roles of the memory stores are relatively unchanged, the verification of which subchain is responsible for is dynamically and randomly adjusted, and each block-out period is different, so that the method can realize expandability, ensure safety and avoid 1% of attacks.
Please refer to fig. 4, which is a diagram illustrating an architecture of a single node according to the present invention. Each node stores main chain data, assigned sub-chain data, and a cross-chain message queue for the sub-chain. Please refer to fig. 5, which is a multi-node deployment scheme based on the node architecture in fig. 4. An example in this scenario lists 6 nodes A, B, C, D, E, F. Each node stores main chain data, where nodes A, B and C are initially allocated by the system to store data for child chain x, making up the data P2P network for child chain x. Nodes D, E and F are initially allocated by the system to store data for child chain y, making up the data P2P network for child chain y. The scheme shown in this figure comprises a main chain and 2 x, y daughter chains in parallel. At this point in the figure, nodes A, D and E are responsible for the verification of child chain x data, and nodes B, C and F are responsible for the verification of child chain y data.
Please refer to fig. 6, which illustrates the interaction between the main chain and the sub-chains under the structure of the main chain and the parallel multi-sub-chain system. After a child chain exits a block, a child chain block header, a modification of the child chain to the main chain, and a child chain set of cross-chain request/response notification information are broadcasted through the main chain P2P network. The submissions of all child chains form a master chain block, which is broadcast to all nodes. After each node receives the main chain block, the local main chain is updated to keep the main chains of all the nodes consistent, the acquisition request is notified or other sub-chain information of the current sub-chain is responded according to the cross-chain request/response notification message in the head of the main chain block, and other sub-chain nodes are directly connected to acquire request/response details and process the request/response details.
Under this architecture, other child chain transactions may be verified using the master chain block header. Under the framework, each node is initially allocated by the system to store all data of a certain sub-chain, and is a full node of the corresponding sub-chain, and each node stores main chain data, is a light node of all other sub-chains, and is a full node of the main chain. Mercker proof: a light node initiates a certification request to a whole node to inquire whether a specified data or transaction exists in the complete Mercker tree of the whole node; and returning a mulck proving path to the light node by the full node, and calculating by the light node to verify the existence.
In this scenario, the merkel proof may be used to verify request/response details.
Fig. 7 is a flowchart for obtaining node connection information and transaction and block details according to a transaction hash txhash and a block hash blockhash. Embedding a subchain id value in hash, wherein query is to analyze a source subchain id and/or a received subchain id from transaction hash and block hash, and query subchain node connection information according to the subchain id, wherein the subchain node connection information is stored in a mapping relation between data nodes of main chain data and the subchain, and the subchain node connection information mainly comprises a subchain located on the nodes, and IP addresses and ports of the nodes.
The system is internally composed of a main chain and a plurality of sub-chains, and each node has main chain information but only has information of one sub-chain. However, from the user's perspective, the notion of child chains does not exist, each node has only one chain, with complete information about that chain, and all its interactions can be done through that node. The transaction function of the traditional main chain is converted into a coordination function, each specific transaction is processed by the parallel sub-chains, and as each node stores main chain data, each user can realize final transaction through system global information recorded in the main chain data when interacting with a certain node.
Please refer to fig. 8, which is a flow chart of cross-chain request/response, which is a flow chart of data verification between a node initiating a transaction and a target node through Merkle Proof (Merkle Proof). The invention provides a cross-chain system contract based on the main chain and parallel multi-subchain framework, wherein an external interface of the cross-chain system contract is a send method, and a parameter of the cross-chain system contract is an active address srcAddr, a target subchain destChain, a receiving address destAddr, a payment amount bill and a request message reqMsg. The cross-chain system contract has an address of the cross-chain system contract, the address is a fixed value without a private key, the address is fixed and public in the code, and the cross-chain transfer is safe as long as the address is correct and the receiving address and the amount are also correct.
In the figure, a chain A is a source sub-chain, a node A is a user sub-chain node, a chain B is a receiving sub-chain, a node B is a target receiving node, the transaction of each node is performed through the sub-chain where the node is located to submit, verify, block out, synchronize and the like, the concept that the node is included in the chain A also includes the concept that the chain is located, the consensus process is simplified in the text and the figure, and one node is taken as a representative.
The user first pays the cross-link system contract of the chain A, and after the source sub-chain A node where the user is located receives the request message detail reqMsg, the source sub-chain A node can be placed in a local cross-link request queue aiming at the receiver sub-chain destChain. After the source sub-chain a leaves the block, the source sub-chain a node will provide the source cross-chain a block header information to the main chain through the main chain P2P network, and also provide cross-chain request notification information of all transactions in the aggregated block, such as a request [ req, a- > B ] of chain a to chain B, but not contain the request details. Transactions submitted by the various sub-chains to the main chain form main chain blocks, and cross-chain notification information contained therein is broadcast to all nodes over the main chain P2P network.
When receiving the main chain block, the receiving sub-chain node B finds that there is a request notification from the chain A to the chain B, and directly connects the chain node A, and obtains the request details and the requested Merkle Proof (Merkle Proof) data. And the chain B node verifies the request information of the chain A node according to the chain A block head and the Merkle Proof (Merkle Proof) data contained in the local main chain information, processes the request after verifying that the user really pays, pays the target address, generates cross-chain response detail information, and stores and updates the cross-chain response queue state. When a chain B node submits the block header information to the backbone over the backbone P2P network, it submits cross-chain response notification information, such as the response of chain B to chain a, but without the response details.
When the submission of chain B is contained in the master chain block and synchronized to chain A node, the chain A node directly connects to the chain B node, obtaining the response details, including the Merckle Proof (Merkle Proof) data of the response. And verifying the response of the chain node B by the chain node A according to a chain block head and Merkle Proof (Merkle Proof) data contained in the local main chain information, updating the request queue after the verification is passed, processing possible failure rollback, refunding the user if the chain B fails in payment, and finally calling a callback function provided by the user.
According to the scheme, actual transaction is not completed through the main chain, the main chain only records the summary information of the sub-chains, the performance of the block chain is greatly improved, the verification nodes of the sub-chains are randomly selected, 1% of attacks can be avoided, and the safety performance is greatly improved.
Claims (6)
1. A system architecture based on a block chain main chain and a plurality of parallel sub-chains is characterized in that: the system comprises a main chain and N parallel sub-chains, wherein N =1.. X, each node stores main chain data, each node is initially allocated by the system to store all data of one sub-chain, and each node further comprises a sub-chain cross-chain message queue;
wherein, all data of the sub-chain initially allocated and stored by the system of each node comprises the account, contract and transaction of the corresponding sub-chain;
wherein the main chain data does not store specific transactions but system global information;
the sub-chain cross-chain message queue comprises two types, one type is a cross-chain request queue, and the other type is a cross-chain response queue;
each node network layer comprises a main chain P2P network, a sub-chain data P2P network and a sub-chain verification P2P network;
the main chain P2P network is used for the sub-chain submitting data to the main chain, propagating main chain data and coordinating cross-chain communication;
each node storing all data of a certain sub-chain synchronizes sub-chain transactions and blocks through a sub-chain data P2P network;
wherein, each node responsible for verifying the same sub-chain transaction verifies and signs the transaction and the block through the sub-chain verification P2P network;
the submitted data of all the child chains form a main chain block and are broadcast to all the nodes, and after each node receives the main chain block, the local main chain is updated so as to keep the main chains of all the nodes consistent.
2. The system architecture of claim 1, wherein:
the backbone data at least comprises: the number of the sub chains, the sub chain block head, the mapping relation between the account and the sub chain, the mapping relation between the contract and the sub chain, the mapping relation between the data node and the sub chain, the mapping relation between the verification node and the sub chain, cross-chain request/response notification information and all contract codes;
in the cross-link request queue, each target sub-chain is established and used for storing request message details sent to the target sub-chain, and different target sub-chains are divided into different queues; in the cross-chain response queue, each source chain is established and used for storing the details of the response message sent to the source chain, and different source chains are divided into different queues;
the cross-chain request/response notification information is a notification corresponding to a cross-chain request/response queue, without details.
3. The system architecture of claim 2, wherein:
after the sub-chain exits the block, a sub-chain block head is submitted to a main chain through main chain P2P network broadcasting, the sub-chain modifies the main chain information, and cross-chain request/response notification information;
the submissions of all the child chains form a main chain block which is broadcast to all the nodes;
after each node receives the main chain block, the local main chain is updated so as to keep the main chain data of all the nodes consistent;
and the current node directly connects with other sub-chain nodes to acquire the details of the request or the response information and processes the details according to the cross-chain request/response notification information acquisition request in the main chain data or response to other sub-chain information of the current sub-chain.
4. The system architecture of claim 3, wherein:
when the current node acquires the cross-chain request or the details of the response information, the current node requests the Mercker certification data together, the target node verifies the request information of the current node according to the current sub-chain block head and the Mercker certification data contained in the local main chain information, and after the verification is passed, the request is processed.
5. The system architecture of claim 4, wherein: the contract also comprises a cross-chain system contract, wherein the external interface of the contract is a send method, the parameters of the contract are a source address, a target sub-chain, a receiving address, a payment amount and/or a request message, the cross-chain system contract comprises an address of the cross-chain system contract, the address is a fixed value without a private key, and the address is fixed and public in the code;
the workflow of the cross-chain system contract is as follows:
a user firstly pays a cross-link system contract of a source sub-link, a user sub-link node of the source sub-link at the user sub-link receives request message details, the user sub-link node is placed into a local cross-link request queue aiming at a receiving sub-link, after the source sub-link exits a block, the source sub-link node submits source link block head information to a main chain through a main chain P2P network, and the submitted information also contains cross-link request notification information of all transactions in the converged block; the transaction submitted by each sub-chain to the main chain forms a main chain block, and cross-chain notification information contained in the main chain block is broadcasted to all nodes through the main chain P2P network;
when a receiving sub-chain target node receives a main chain block, discovering a cross-chain request notification of an active sub-chain to the receiving sub-chain, directly connecting the source sub-chain node, and acquiring request information details and requested merkel certification data; receiving request information of a sub-chain target node of a user according to a source sub-chain block head and Mercker certification data contained in local main chain information, processing the request after the user is verified to pay really, paying the target address, generating cross-chain response detail information, and storing and updating a cross-chain response queue state; when a receiving sub-chain target node submits block header information to a main chain through a main chain P2P network, cross-chain response notification information is submitted;
when the submission of the receiving sub-chain is contained in the main chain block and synchronized to the user sub-chain node, the user sub-chain node is directly connected with the receiving sub-chain target node, and response details including the Mercker evidence data of the response are acquired; and verifying the response of the target link node by the user sub-link node according to the received sub-link block head and the Mercker certification data contained in the local main chain information, updating the request queue after the verification is passed, processing possible failure rollback, refunding the user if the payment of the received sub-link fails, and finally calling a callback function provided by the user.
6. The system architecture of claim 5, wherein: when the node returns any transaction or block hash, a sub-chain id value is embedded into the hash, the query is to analyze a source sub-chain id and/or a received sub-chain id from the transaction hash and the block hash, and query sub-chain node connection information according to the sub-chain id, wherein the sub-chain node connection information is stored in a mapping relation between a data node of the main chain data and the sub-chain.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201811392135.1A CN109471744B (en) | 2018-11-21 | 2018-11-21 | Main chain and parallel multi-sub-chain system architecture based on block chain |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201811392135.1A CN109471744B (en) | 2018-11-21 | 2018-11-21 | Main chain and parallel multi-sub-chain system architecture based on block chain |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN109471744A CN109471744A (en) | 2019-03-15 |
| CN109471744B true CN109471744B (en) | 2021-08-17 |
Family
ID=65674245
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201811392135.1A Active CN109471744B (en) | 2018-11-21 | 2018-11-21 | Main chain and parallel multi-sub-chain system architecture based on block chain |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN109471744B (en) |
Families Citing this family (20)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110163609B (en) * | 2019-05-28 | 2024-02-27 | 深圳前海微众银行股份有限公司 | Method and device for processing data in block chain |
| CN110210845B (en) * | 2019-06-11 | 2021-06-18 | 网易（杭州）网络有限公司 | Method, apparatus, medium, and computing device for blockchain data migration |
| CN110490562A (en) * | 2019-07-10 | 2019-11-22 | 布比（北京）网络技术有限公司 | A kind of across the chain data processing method and system of multi-tiling chain |
| CN111213135B (en) * | 2019-08-27 | 2023-11-21 | 创新先进技术有限公司 | System and method for blockchain-based notification |
| CN110727712B (en) * | 2019-10-15 | 2021-06-04 | 腾讯科技（深圳）有限公司 | Data processing method and device based on block chain network, electronic equipment and storage medium |
| CN110766410B (en) * | 2019-10-24 | 2023-09-22 | 杭州趣链科技有限公司 | Trusted cross-chain event construction and verification method and device based on Merker tree |
| CN110874798A (en) * | 2019-10-30 | 2020-03-10 | 链农(深圳)信息科技有限公司 | Network platform based on regional chain and safe communication method thereof |
| CN111026511B (en) * | 2019-11-20 | 2023-08-08 | 中国科学院计算技术研究所 | Block chain parallel system and method based on transaction data partition-chain fusion |
| CN112907367A (en) * | 2019-12-03 | 2021-06-04 | 微观(天津)科技发展有限公司 | Cross-border trade data management method and device based on block chain and storage medium |
| CN111342972B (en) * | 2020-02-24 | 2023-09-15 | 百度在线网络技术（北京）有限公司 | Transaction realization method, device, equipment and medium of block chain |
| CN111339114B (en) * | 2020-02-28 | 2023-05-09 | 百度在线网络技术（北京）有限公司 | Data access method, device, equipment and storage medium |
| CN113381863A (en) * | 2020-03-10 | 2021-09-10 | 本无链科技(深圳)有限公司 | Call-type broadcasting system and method for block chain |
| CN111428275B (en) * | 2020-03-13 | 2021-03-26 | 华东师范大学 | Alliance chain-oriented service non-stop fragment increasing method |
| CN111192146B (en) * | 2020-04-10 | 2020-07-17 | 支付宝(杭州)信息技术有限公司 | Correction method and device for block chain data |
| CN111769957B (en) * | 2020-09-02 | 2020-12-15 | 百度在线网络技术（北京）有限公司 | Block chain cross-chain query method, device, equipment and storage medium |
| CN113300851B (en) * | 2021-05-18 | 2022-06-21 | 中国信息通信研究院 | DHT-based block chain message broadcasting method, electronic equipment and storage medium |
| CN113259119B (en) * | 2021-06-02 | 2021-10-29 | 支付宝(杭州)信息技术有限公司 | Block chain message distribution method and device |
| CN113420169B (en) * | 2021-06-22 | 2023-03-21 | 重庆紫光华山智安科技有限公司 | File storage and query method, system, electronic equipment and medium |
| CN113760651B (en) * | 2021-08-12 | 2024-04-02 | 熵链科技(福建)有限公司 | Main sub-chain running state collection method, system and storage medium of block chain |
| CN114499872A (en) * | 2021-12-24 | 2022-05-13 | 山东浪潮工业互联网产业股份有限公司 | Industrial internet-based star fire chain cross-linking method and equipment |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106411506A (en) * | 2016-08-31 | 2017-02-15 | 飞天诚信科技股份有限公司 | Key derivation method and device applicable to digital currency |
| CN107104850A (en) * | 2017-03-24 | 2017-08-29 | 钱德君 | A kind of Quantum Chain method of testing |
| CN107844976A (en) * | 2017-10-25 | 2018-03-27 | 武汉天喻信息产业股份有限公司 | A kind of card of depositing based on block chain applies transaction system and method |
| CN108712491A (en) * | 2018-05-17 | 2018-10-26 | 易链科技（深圳）有限公司 | Block chain node, exchange information processing method, terminal device and medium |
| CN108734578A (en) * | 2018-05-02 | 2018-11-02 | 东莞市波动赢机器人科技有限公司 | Data processing method and system based on transaction robot |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US10075298B2 (en) * | 2015-06-02 | 2018-09-11 | ALTR Solutions, Inc. | Generation of hash values within a blockchain |
| US20170331896A1 (en) * | 2016-05-13 | 2017-11-16 | De La Rue International Limited | Methods and systems for processing assets |
-
2018
- 2018-11-21 CN CN201811392135.1A patent/CN109471744B/en active Active
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106411506A (en) * | 2016-08-31 | 2017-02-15 | 飞天诚信科技股份有限公司 | Key derivation method and device applicable to digital currency |
| CN107104850A (en) * | 2017-03-24 | 2017-08-29 | 钱德君 | A kind of Quantum Chain method of testing |
| CN107844976A (en) * | 2017-10-25 | 2018-03-27 | 武汉天喻信息产业股份有限公司 | A kind of card of depositing based on block chain applies transaction system and method |
| CN108734578A (en) * | 2018-05-02 | 2018-11-02 | 东莞市波动赢机器人科技有限公司 | Data processing method and system based on transaction robot |
| CN108712491A (en) * | 2018-05-17 | 2018-10-26 | 易链科技（深圳）有限公司 | Block chain node, exchange information processing method, terminal device and medium |
Also Published As
| Publication number | Publication date |
|---|---|
| CN109471744A (en) | 2019-03-15 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN109471744B (en) | Main chain and parallel multi-sub-chain system architecture based on block chain | |
| CN109493050B (en) | Transfer method based on block chain main chain and parallel multiple sub-chains | |
| CN109472572B (en) | Contract system based on block chain main chain and parallel multiple sub-chains | |
| CN109493051B (en) | Main chain and parallel multi-subchain system architecture capable of dynamically allocating and migrating accounts | |
| CN109246211B (en) | Resource uploading and resource requesting method in block chain | |
| TWI690184B (en) | Cross-blockchain authentication method and device, and electronic equipment | |
| CN109493052B (en) | Cross-chain contract system based on main chain and parallel multiple sub-chains | |
| CN110399338B (en) | Distributed file index system and method based on block chain and cloud storage server | |
| US10581613B2 (en) | Cryptographically verifiable data structure having multi-hop forward and backwards links and associated systems and methods | |
| EP4318362A1 (en) | Blockchain-based data processing method, apparatus and device, and storage medium | |
| CN110321074B (en) | Consensus method for safety storage certification based on block chain and distributed storage system | |
| TW202101440A (en) | Cross-blockchain resource transmission | |
| CN112235420B (en) | Data synchronization method, system and related equipment based on block chain | |
| CN110945548A (en) | Computer-implemented system and method for managing large distributed storage pools in a blockchain network | |
| CN108650182A (en) | Network communication method, system, device, equipment and storage medium | |
| CN111934996B (en) | Message transmission method and device | |
| CN105827410A (en) | Block chain transmission method and system with trusted node/satellite node construction | |
| KR20200081533A (en) | Blockchain Consensus Method based Improved Dynamic Blind Voting for Internet of Things Environment | |
| CN116150260A (en) | Data processing method, device, medium and electronic equipment of block chain system | |
| CN110910110A (en) | Data processing method and device and computer storage medium | |
| CN116055052A (en) | Block chain-based data processing method, device, equipment and readable storage medium | |
| CN116827957B (en) | Information processing method, device, equipment and medium based on multi-block chain | |
| CN113157450A (en) | Method and apparatus for performing blocks in a blockchain system | |
| CN117201031A (en) | File distributed storage sharing method based on homomorphic hash tree | |
| KR102176128B1 (en) | Method for providing encryption communication in a distributed computing resource shring system based on block chain |
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 |