CN109472572B - Contract system based on block chain main chain and parallel multiple sub-chains - Google Patents

Contract system based on block chain main chain and parallel multiple sub-chains Download PDF

Info

Publication number
CN109472572B
CN109472572B CN201811392134.7A CN201811392134A CN109472572B CN 109472572 B CN109472572 B CN 109472572B CN 201811392134 A CN201811392134 A CN 201811392134A CN 109472572 B CN109472572 B CN 109472572B
Authority
CN
China
Prior art keywords
chain
sub
node
user
main chain
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
CN201811392134.7A
Other languages
Chinese (zh)
Other versions
CN109472572A (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.)
Beijing Lanshi Huanqiu Block Chain Technology Co ltd
Original Assignee
Beijing Lanshi Huanqiu Block Chain 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 Beijing Lanshi Huanqiu Block Chain Technology Co ltd filed Critical Beijing Lanshi Huanqiu Block Chain Technology Co ltd
Priority to CN201811392134.7A priority Critical patent/CN109472572B/en
Publication of CN109472572A publication Critical patent/CN109472572A/en
Application granted granted Critical
Publication of CN109472572B publication Critical patent/CN109472572B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06QDATA PROCESSING SYSTEMS OR METHODS, SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/04Payment circuits
    • G06Q20/06Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • G06Q20/065Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06QDATA PROCESSING SYSTEMS OR METHODS, SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/10Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06QDATA PROCESSING SYSTEMS OR METHODS, SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06QDATA PROCESSING SYSTEMS OR METHODS, SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/382Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3825Use of electronic signatures
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06QDATA PROCESSING SYSTEMS OR METHODS, SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/382Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3827Use of message hashing
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06QDATA PROCESSING SYSTEMS OR METHODS, SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/42Confirmation, e.g. check or permission by the legal debtor of payment
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06QDATA PROCESSING SYSTEMS OR METHODS, SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/04Exchange, e.g. stocks, commodities, derivatives or currency exchange

Abstract

The invention relates to a block chain main chain and parallel multi-subchain-based contract system, which is characterized in that: the main chain and parallel multi-subchain framework comprises a main chain and N parallel subchains, each node stores main chain data, the main chain data does not store specific transactions, system global information is stored, a user logs in a user side wallet, the user side wallet sends a source address to a direct interaction node to inquire the subchain position of an account, a source subchain corresponding to the subchain and subchain node connection information corresponding to the source address are returned, contract dependency is analyzed, and whether the content depends on other subchain contracts is returned; if the user receives the content independent of other sub-chain contracts, the user confirms the signature, the contracts are deployed to the user sub-chain nodes, then the sub-chains are submitted to the main chain, the main chain is newly added with the contracts and the mapping relation between the contracts and the sub-chains, and the contracts are deployed to the main chain; and if the content dependent on other child chain contracts is received, the deployment fails, and the reason of the failure in deployment is returned.

Description

Contract system based on block chain main chain and parallel multiple sub-chains
Technical Field
The invention relates to an expansibility scheme of a block chain, in particular to contract deployment and transaction based on a block chain main chain and a plurality of parallel sub-chains.
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 expansion through fragmentation and multi-chain is a basic solution, but the key problem is how to perform fragmentation, how to make the multi-chain externally appear as a chain, and how to keep a low cross-chain overhead and implement linear expansion on the premise of ensuring security, which is also a problem to be researched and solved by the present invention.
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 block chain main chain and parallel multi-subchain based contract system, wherein the main chain and parallel multi-subchain architecture comprises a main chain and N parallel subchains, wherein N =1 … X, each node stores main chain data, the main chain data does not store specific transactions, and system global information is stored and at least comprises cross-chain request/response notification information; each node is initially allocated by the system to store all data of a sub-chain, and each node further comprises a sub-chain cross-chain message queue; the cross-chain request/response notification information is a notification corresponding to a cross-chain request/response queue, and contains no details; a user interacts with a certain node through user side wallet software, and the node is called a direct interaction node; one user belongs to one sub-chain only, one node has data of one sub-chain only, and the request of one user can be processed only by the node having the data, and the node is called as a user sub-chain node; a user logs in a user side wallet, the user side wallet is connected to a direct interaction node, the user side wallet sends a source address to the direct interaction node to inquire the position of a sub-chain of an account of the direct interaction node, the direct interaction node returns a source sub-chain corresponding to the direct interaction node and sub-chain node connection information corresponding to the source address, the contract dependency relationship is analyzed, and whether the contract depends on other sub-chains or not is returned; if the user receives the content independent of other sub-chain contracts, the user confirms the signature, the contracts are deployed to the user sub-chain nodes, then the sub-chains are submitted to the main chain, the main chain is newly added with the contracts and the mapping relation between the contracts and the sub-chains, and the contracts are deployed to the main chain; and if the content dependent on other child chain contracts is received, the deployment fails, and the reason of the failure in deployment is returned.
The invention also provides a scheme for submitting transactions: the user submits the transaction request to user-side wallet software, and the user-side wallet software sends a request for inquiring a source address and receiving a subchain position of the address and a request for receiving a subchain position of a contract to a direct interaction node of the user-side wallet software; the direct interaction node returns corresponding source subchain, subchain node connection information corresponding to the source address, a received subchain and whether other subchain contracts are relied on; if the user belongs to a certain sub-chain and the contract also belongs to a certain sub-chain, if the two sub-chains are the same, the user sub-chain node can directly process contract transaction; if the contracts belong to different sub-chains, the wallet modifies the contract transaction into a cross-chain transaction, and the cross-chain system contract is finally processed by the user sub-chain node.
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 process of transferring accounts based on the framework of the main chain and the parallel sub-chains of the present invention for the user and the user side.
FIG. 9 is an internal logic diagram of a transfer transaction.
FIG. 10 is a cross-chain request and response flow.
FIG. 11 is a cross-chain transfer transaction flow.
FIG. 12 is a flow diagram of a deployment contract in the present invention.
FIG. 13 is a flow diagram of a commit contract transaction in the present invention.
FIG. 14 is a diagram illustrating the storage of nodes and child chains.
Fig. 15 is a flowchart of node registration.
FIG. 16 is a schematic illustration of main chain and daughter chain storage.
FIG. 17 is a flow chart of account assignment and migration.
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 =1 … X, each node stores main chain data and is initially allocated by a system to store all data of a certain sub-chain, and each node further comprises a sub-chain cross-chain message queue. 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.
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, verification nodes of the sub-chains are randomly selected, 1% of total amount can be avoided, and the safety performance is greatly improved.
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.
The user interacts with a node through the user-side wallet software, the node is called a direct interaction node, but the node may not have the information of the user and cannot process the request of the user. In the system, one user belongs to and only belongs to a certain sub-chain, one node owns and only owns data of one sub-chain, and the request of one user can be processed only by the node owning the data of the user, and the node is called as a user sub-chain node. The user side wallet software, the direct interaction node and the user sub-chain node are matched with each other, and a simple experience is provided for the user.
Based on a framework of a main chain and a plurality of parallel sub-chains, the framework presents a single chain to an external user, and realizes transparent routing to the user. 1) Transferring accounts; 2) Deploying a contract; 3) submitting a contract transaction; 4) transaction/block query.
Please refer to fig. 8, which shows a process of transferring accounts between a user and a client based on the architecture of the main chain and the parallel sub-chains of the present invention. FIG. 9 is an internal logic diagram of a transfer transaction. FIG. 10 is a cross-chain request and response flow. FIG. 11 is a cross-chain transfer transaction flow.
Referring to fig. 8, the flow of the transfer includes:
s1: the user opens the user-side wallet, the user-side wallet is connected to the direct interaction node, and the user inputs the receiving address destAddr and the transfer amount bill in the user-side wallet.
S2: the user side wallet inquires subchain information of a source address srcAddr of a current user, node connection information of the subchain and subchain information of a receiving address destAddr to a direct interaction node directly connected with the user side wallet. Wherein the sub-chain information is a sub-chain id.
S3: the direct interaction node inquires local main chain information, obtains a sub chain id of a source sub chain srcChain corresponding to a source address srcAddr of a current user, node connection information of the source sub chain srcChain and a sub chain id of a receiving sub chain destChain corresponding to a receiving address destAddr and returns to the wallet.
S4: the wallet checks whether the source sub-chain srcChain and the receiving sub-chain destChain are the same chain, if so, a direct transfer transaction is constructed, otherwise, a cross-chain transfer transaction is constructed, and a user signature is requested.
The user confirms the transaction information and signs, and the wallet sends the transaction to the user sub-chain node for processing.
And S5, the user sub-chain node processes the request.
Turning now to FIG. 9, an internal logic diagram for a user sub-chain node processing a transfer transaction is shown. The user sub-chain node processes the specific request.
S5-1: and the user subchain node receives the source address srcAddr, the receiving address destAddr and the transfer amount bill of the transfer and judges whether the source address srcAddr is in charge of the current subchain. If not, the transaction processing is failed, failure information is returned, if the current subchain is responsible for the failure, whether the receiver address destAddr exists or not is continuously judged, and if the receiver address destAddr does not exist, a new account needs to be created.
S5-1-1 account adding process:
judging whether the target receiving address destAddr exists in the main chain data, if not, allocating a destChain, adding a main chain transaction set (destChain) by a user, and storing the mapping relation between the account and the sub chain in the main chain data.
S5-2: and judging whether the source address srcAddr and the receiving address destADdr are in charge of the current child chain, if so, directly performing transfer transaction, and if not, performing cross-chain transfer transaction through a cross-chain system contract.
Wherein, direct transfer transactions: is the prior art.
The cross-chain transfer transaction is completed through a cross-chain system contract, which is shown in fig. 10, which is a flow of cross-chain request/response. The external interface of the cross-chain system contract is a send method, and the parameters of the send method are a source address srcAddr, a target sub-chain 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 gets out of the block, the source sub-chain a node submits the source chain a block header information to the main chain through the main chain P2P network, and the submitted information also contains 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 does 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.
Please refer to fig. 11, which shows a process of payment for a user, the user first pays a cross-link system contract of a chain a, the process of executing the cross-link system contract is the flow illustrated in fig. 8, a receiving chain a node submits a block header information and a cross-link request notification information included in the block header information to a main chain, when the main chain is synchronized, a chain B finds the cross-link request notification information of a, the chain B connects the chain a, the request acquisition request details, and the requested Merkle Proof data. After verifying that the user really pays by using the Merkle Proof, the chain node B pays the target receiving address, generates cross-chain response notification information, sends out a block by the chain B, and submits block header information and the cross-chain response notification information to the main chain, when the main chain is synchronous, the chain node A is connected with the chain B, acquires response details and requests Merkle Proof data, after the chain A receives the response details, the chain node A also verifies the response of the chain B by using the Merkle Proof, and if the chain B fails in payment, the user is refunded.
In the above-described flow of money transfers, some security issues appear to be introduced. Without the introduction of multi-chain technology, the user can construct transactions and sign off-line without querying any information, without trusting wallet software and any nodes. While in the above flow it seems that the wallet and the direct interaction node need to be trusted, in fact, this is not necessary, and the following analyzes the possibility that the direct interaction node and the wallet do bad, respectively.
If the direct interaction node is malicious, the information it returns to the wallet is incorrect, such as srcAddr and destAddr actually reside in the same child chain but return different child chains, or srcAddr and destAddr actually reside in different child chains but return the same child chain, in both cases, the node handling the transfer verifies the child chain information and rejects the transaction, and even if individual nodes agree to the transaction, most consensus will not be obtained. If the sub-chain node connection information corresponding to the returned srcAddr is wrong, the wallet may not be connected, the signed transaction may also be sent to the wrong node, the node will reject the transaction, and even if the node agrees, most common knowledge will not be obtained. To summarize, as when no multi-chain technique is introduced, the user does not need to trust the direct interaction node, if the node is malicious, the transfer may fail, but the user's assets are secure.
In a high-security scene, wallet software does not have a private key, and is only responsible for constructing a transaction to be signed, the transaction to be signed is sent to a user in an off-line mode, the user signs in a high-security environment, the signed transaction is sent to the wallet software in an off-line mode, and the wallet software is sent to a network. In this process, the user does not need to trust the wallet software, it simply verifies that the transaction's recipient address and amount are correct.
In the case of multiple chains, it is necessary to distinguish between direct transfers and cross-chain transfers. For direct transfers, the user only needs to verify the recipient address and amount, as with the single chain. For cross-chain transfers, the destination address is not the recipient address, but rather the address of the cross-chain transfer system contract, how the user ensures the correctness of the address. The answer is that the address is a fixed value without a private key, the address is fixed in the code, public, and as long as the address is correct, the receiving address and amount are also correct, and the transfer across the chain is secure. In summary, after introducing the multi-chain technology, the user does not need to trust wallet software, but needs to know the address of the cross-chain transfer system contract, which sacrifices certain transparency, but in most daily scenarios, the private key of the user is generally managed by the wallet and trusts the wallet, and then the multi-chain technology is transparent to the user.
Please refer to fig. 12, which illustrates a flow of deploying contracts. The contract is deployed to the child chain where the creator is located, and the main chain records the mapping relationship between the contract and the child chain (contract a exists on the child chain x). When the contracts are deployed, the contracts which depend on the contracts are analyzed, and if the contracts of other sub-chains are depended on, the deployment fails.
The specific process is as follows: the user logs in a user side wallet, the user side wallet is connected to the direct interaction node, the user side wallet sends the source address srcAddr to the direct interaction node to inquire the position of the sub-chain of the account of the direct interaction node, the direct interaction node returns the source sub-chain srcChain corresponding to the direct interaction node and sub-chain node connection information corresponding to the source address srcAddr, contract dependency is analyzed, and whether the content of other sub-chain contracts is depended or not is returned. If the user receives the content independent of other sub-chain contracts, the user confirms the signature, the deployment of the sub-chains is completed, then the sub-chains are submitted to the main chain, the main chain is newly added with the contracts and the mapping relation between the contracts and the sub-chains, and the contracts are deployed to the main chain. And if the content dependent on other child chain contracts is received, the deployment fails, and the reason of the failure in deployment is returned.
FIG. 13 is a flow diagram of a process for submitting a contract transaction. The user submits a transaction request [ destAddr, req ] to the user-side wallet, and the user-side wallet sends a request for inquiring the position of the subchain where the source address scrAddr and the receiving address destAddr are located and a request for inquiring the position of the subchain where the contract is located to the direct interaction node of the user-side wallet. And the direct interaction node returns corresponding sub-chain node connection information corresponding to the source sub-chain srcChain and the source address scrAddr, receives the sub-chain destChain and judges whether other sub-chain contracts are relied on. If the user belongs to a sub-chain and the contract also belongs to a sub-chain, if the two sub-chains are the same, the user sub-chain node can directly process contract transaction. If the contracts belong to different sub-chains, the wallet modifies the contract transaction into a cross-chain transaction, and the cross-chain system contract is finally processed by the user sub-chain node
In the present system, please refer to fig. 14, which shows the storage of the Nodes and the sub-chains, two system configuration parameters are further set in the main chain data, one is the minimum node number-min Nodes and the other is the maximum node number-max Nodes, the node number corresponding to the sub-chain is not less than the minimum node number-min Nodes, and the sub-chain node number is not more than the maximum node number-maxNodes.
Referring to fig. 15, when registering a node, a main chain system contract is submitted with a registration request, and the system determines whether a child chain with a node number less than maxNodes exists, and if so, allocates the node to the child chain with the minimum node number, otherwise, a new child chain is expanded, but the child chain is not valid. And if the node number of the corresponding sub-chain is not less than the minNodes for the first time after the nodes are registered, enabling the new sub-chain to take effect. In the scheme, the number of sub-chains and the system capacity are dynamically expanded, the more nodes are involved, the more sub-chains are involved, and the stronger the system capacity is.
Referring to fig. 16 and 17, the main chain stores the mapping relationship between the account and the child chain, and stores the load of each child chain, where the load of the child chain is obtained by comprehensive calculation according to the user, contract, transaction, and storage. And the block outlet node analyzes the account transaction in a fixed period, analyzes the transaction number of each account in the chain and other transaction numbers of each sub-chain, and obtains the transaction frequency of each sub-chain.
The account allocation and migration process comprises the following steps:
s1: the account is initially assigned to the least loaded child chain.
S2: the block outlet node analyzes the account transaction in a fixed period and dynamically migrates the account transaction to the subchain with the most frequent interaction, and the specific process is as follows:
s2-1: for each account, analyzing the transaction number of the transaction in the chain and the transaction number of each sub-chain to obtain the transaction frequency of each sub-chain;
s2-2: judging whether to migrate or not and to which sub-chain to migrate;
s2-3: and if the migration is needed, submitting an account migration transaction, wherein the transaction comprises two parts, namely, modifying the mapping relation between the account on the main chain and the sub chain, and transferring the cross-chain to the same-name account of the target sub chain, and because the cross-chain is the same-name account, no account signature is needed.
Notably, accounts that have created contracts cannot be migrated, requiring no analysis, because if account A deploys contract C1 to chain X, after A migrates to chain Y, deployment will fail if C2 is redeployed, and C2 relies on C1.
And verifying the migration transaction by using the nodes of other same sub-chains according to the same algorithm, submitting the verified blocks to the main chain, synchronizing the main chain to all the nodes after the blocks are generated, modifying the mapping relation on the main chain, creating an account by using the target sub-chain node, and finishing the transfer.

Claims (4)

1. A block chain main chain and parallel multi-subchain based contract system is characterized in that: the main chain plus parallel multi-subchain architecture comprises a main chain and N parallel subchains, wherein N =1 … X, wherein each node stores main chain data, the main chain data does not store specific transactions, but stores system global information, at least comprising cross-chain request/response notification information; each node is initially allocated by the system to store all data of a sub-chain, and each node further comprises a sub-chain cross-chain message queue; the cross-chain request/response notification information is a notification corresponding to a cross-chain request/response queue, and contains no details; a user interacts with a certain node through user side wallet software, and the node is called a direct interaction node; one user belongs to one sub-chain only, one node has data of one sub-chain only, and the request of one user can be processed only by the node having the data, and the node is called as a user sub-chain node;
a user logs in a user side wallet, the user side wallet is connected to a direct interaction node, the user side wallet sends a source address to the direct interaction node to inquire the position of a sub-chain of an account of the direct interaction node, the direct interaction node returns a source sub-chain corresponding to the direct interaction node and sub-chain node connection information corresponding to the source address, the contract dependency relationship is analyzed, and whether the contract depends on other sub-chains or not is returned;
if the user receives the content independent of other sub-chain contracts, the user confirms the signature, the contracts are deployed to the user sub-chain nodes, then the sub-chains are submitted to the main chain, the main chain is newly added with the contracts and the mapping relation between the contracts and the sub-chains, and the contracts are deployed to the main chain;
and if the content dependent on other child chain contracts is received, the deployment fails, and the reason of the failure in deployment is returned.
2. The block chain backbone plus parallel multi-subchain based contract system of claim 1, wherein: the user submits the transaction request to user-side wallet software, and the user-side wallet software sends a request for inquiring a source address and receiving a subchain position of the address and a request for receiving a subchain position of a contract to a direct interaction node of the user-side wallet software;
the direct interaction node returns corresponding source subchain, subchain node connection information corresponding to the source address, a received subchain and whether other subchain contracts are relied on;
if the user belongs to a certain sub-chain and the contract also belongs to a certain sub-chain, if the two sub-chains are the same, the user sub-chain node can directly process contract transaction;
if the contracts belong to different sub-chains, the wallet modifies the contract transaction into a cross-chain transaction, and the cross-chain system contract is finally processed by the user sub-chain node.
3. The blockchain-backbone-plus-parallel-multi-subchain-based contract system of claim 2, wherein: the workflow of the cross-chain system contract is as follows:
the cross-chain transaction is completed through a cross-chain system contract, the external interface of the cross-chain system contract is a send method, the parameters of the send method are a source address, a target sub-chain, a receiving address, a payment amount and/or a request message, the cross-chain system contract has 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 a 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 a request message and then puts the request message 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 block head information of the source sub-link 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 a request message and requested merkel certification data; receiving a request message of a sub-chain target node for verifying a user sub-chain node according to a source sub-chain block head and Mercker certification data contained in local main chain information, processing the request after verifying that a user really pays, paying to a 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.
4. The blockchain-backbone-plus-parallel-multi-subchain-based contract system of claim 3, 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.
CN201811392134.7A 2018-11-21 2018-11-21 Contract system based on block chain main chain and parallel multiple sub-chains Active CN109472572B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201811392134.7A CN109472572B (en) 2018-11-21 2018-11-21 Contract system based on block chain main chain and parallel multiple sub-chains

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201811392134.7A CN109472572B (en) 2018-11-21 2018-11-21 Contract system based on block chain main chain and parallel multiple sub-chains

Publications (2)

Publication Number Publication Date
CN109472572A CN109472572A (en) 2019-03-15
CN109472572B true CN109472572B (en) 2021-08-03

Family

ID=65674247

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201811392134.7A Active CN109472572B (en) 2018-11-21 2018-11-21 Contract system based on block chain main chain and parallel multiple sub-chains

Country Status (1)

Country Link
CN (1) CN109472572B (en)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110223178A (en) * 2019-06-06 2019-09-10 杭州趣链科技有限公司 It is a kind of for alliance's chain across catenary system and across chain method
CN110428332A (en) * 2019-07-29 2019-11-08 杭州复杂美科技有限公司 A kind of across the chain method of commerce of parallel chain, equipment and storage medium
CN112633868A (en) * 2019-10-08 2021-04-09 橙载(上海)信息技术有限公司 Cross-chain asset transfer method based on intelligent contract implementation
CN111046437A (en) * 2019-10-31 2020-04-21 中国科学院计算技术研究所 Block chain parallel transaction processing method and system based on isomorphic multi-chain and terminal
CN112054928B (en) * 2020-09-02 2022-06-24 杭州复杂美科技有限公司 Parallel chain node configuration method, equipment and storage medium
CN111769957B (en) * 2020-09-02 2020-12-15 百度在线网络技术(北京)有限公司 Block chain cross-chain query method, device, equipment and storage medium
CN113393313B (en) * 2021-08-17 2021-11-09 环球数科集团有限公司 Writing mechanism for carrying out trusted deposit certificate on accounting tool for telecommunication value-added service
CN113822656B (en) * 2021-11-23 2022-02-11 江苏荣泽信息科技股份有限公司 Cross-chain cooperation method based on block chain technology

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107742210A (en) * 2017-10-13 2018-02-27 布比(北京)网络技术有限公司 Across the chain fund transfer system and method for a kind of different blocks interchain
CN108288158A (en) * 2018-01-29 2018-07-17 张天 A kind of storage method based on block chain technology, computer readable storage medium

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11321681B2 (en) * 2017-02-06 2022-05-03 Northern Trust Corporation Systems and methods for issuing and tracking digital tokens within distributed network nodes

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107742210A (en) * 2017-10-13 2018-02-27 布比(北京)网络技术有限公司 Across the chain fund transfer system and method for a kind of different blocks interchain
CN108288158A (en) * 2018-01-29 2018-07-17 张天 A kind of storage method based on block chain technology, computer readable storage medium

Also Published As

Publication number Publication date
CN109472572A (en) 2019-03-15

Similar Documents

Publication Publication Date Title
CN109472572B (en) Contract system based on block chain main chain and parallel multiple sub-chains
CN109493050B (en) Transfer method based on block chain main chain and parallel multiple sub-chains
CN109471744B (en) Main chain and parallel multi-sub-chain system architecture based on block chain
CN109493052B (en) Cross-chain contract system based on main chain and parallel multiple sub-chains
WO2020258848A1 (en) Method and apparatus for cross-chain transmission of resources
CN103227719B (en) Generate the system and method without key digital multi-signature
JP2020518888A (en) System and method for providing representational state transfer proxy services for blockchain cloud services
CN109492380B (en) Equipment authentication method and device and block link point
CN109493051B (en) Main chain and parallel multi-subchain system architecture capable of dynamically allocating and migrating accounts
CN110912707B (en) Block chain-based digital certificate processing method, device, equipment and storage medium
CN112602076A (en) DAG-based transaction processing method and system in distributed ledger
TW201946016A (en) Partitioning a blockchain network
WO2019021107A1 (en) Computer-implemented system and method for managing a large distributed memory pool in a blockchain network
CN111294379B (en) Block chain network service platform, authority hosting method thereof and storage medium
WO2018229633A1 (en) Method and system of mining blockchain transactions provided by a validator node
CN112235420B (en) Data synchronization method, system and related equipment based on block chain
Kaur et al. Scalability in blockchain: Challenges and solutions
KR20220006623A (en) Blockchain consensus method, device and system
CN110910110A (en) Data processing method and device and computer storage medium
CN112231415B (en) Data synchronization method and system of block chain network, electronic device and readable medium
CN112232822B (en) Transaction processing method, node, device and storage medium of block chain network
Sohrabi et al. On the scalability of blockchain systems
US20210182837A1 (en) High performance distributed system of record with delegated transaction signing
Amiri et al. Saguaro: Efficient processing of transactions in wide area networks using a hierarchical permissioned blockchain
CN113395363B (en) Data processing method, device and equipment based on block chain and storage medium

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