CN107301600B - Core construction method of block chain Internet model for cross-chain transaction - Google Patents
Core construction method of block chain Internet model for cross-chain transaction Download PDFInfo
- Publication number
- CN107301600B CN107301600B CN201710483789.4A CN201710483789A CN107301600B CN 107301600 B CN107301600 B CN 107301600B CN 201710483789 A CN201710483789 A CN 201710483789A CN 107301600 B CN107301600 B CN 107301600B
- Authority
- CN
- China
- Prior art keywords
- chain
- transaction
- participation
- participating
- information
- 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
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
-
- 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
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3297—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving time stamps, e.g. generation of time stamps
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
- H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash
Abstract
The invention develops a core algorithm of a block chain internet model (golden monkey model) of cross-chain transaction, and the model is a completely distributed and multi-chain network architecture and is easier to expand, extend and fault-tolerant than the traditional centralized architecture. Each chain maintains self consistency, the consistency between chains is maintained by a completely distributed mechanism, the limitation of a centralized model is broken, all chains can run in parallel, and the transaction efficiency and the network running speed are improved. The model is a new financial market architecture, can be expanded, and financial units can easily join or leave at any time, thereby supporting large-scale network and high transaction volume. The model comprises a participation chain and an intermediate chain, which can be one or a group of financial institutions and can realize cross-chain transaction. The invention is a core algorithm of chain-to-chain transaction, in particular a protocol algorithm of an intermediate chain assisting two or more participating chains to mutually transact, and the consistency of the whole network is maintained without a central mechanism.
Description
Technical Field
The invention relates to the technical field of block chain internet for a financial system, in particular to a distributed block chain internet structure.
Background
The block chain Internet (Internet of blocks) is a value network built based on the block chain, and has the characteristics of high performance, safety, privacy, expandability, interoperability, changeability, fault tolerance, manageability and completeness.
Most of the existing blockchain internet, such as the Cosmos (Cosmos), has a centralized structure, and the intermediate chain is a central mechanism, so that the calculation and communication links of the intermediate chain are easy to become the bottleneck of the blockchain internet. In addition, each chain needs to maintain the consistency of the chain, the middle chain also needs to dynamically maintain the consistency with each participating chain, and further, a cross-chain transaction needs to maintain a plurality of participating chains and the middle chain together, so that the running speed of the block chain is reduced.
Disclosure of Invention
In order to solve the problem that the existing chain network (such as Cosmos) applied to a financial system is low in efficiency, the invention provides a core algorithm of a block chain internet model of cross-chain transaction, which can realize parallel operation, improve the operation efficiency and the transaction speed of the system and ensure the consistency of the system.
The technical scheme adopted by the invention is a core algorithm of a block chain internet model of cross-chain transaction, which is characterized in that the model is shown in figure 1 and comprises the following components:
(1) a Participant chain (PPC) representing one or more financial institutions or financial units, which may include from one to a plurality of nodes;
(2) an Inter-chain (ICC) represents an intermediary, which is also a financial institution and can also function as a CCP (Central counter party), the intermediary and the participating chain have two or more public nodes, and the intermediary and the participating chain use the public nodes to perform transactions;
(3) one or more intermediate chains can be connected between every two participation chains, each intermediate chain can connect two to more participation chains, and the intermediate chains complete the transaction between the two or more participation chains, and the transaction comprises two transaction modes so as to be suitable for different requirements (instant transaction completion, or non-real-time but efficient transaction):
(3a) real-time transaction (real-time transaction): two or more participation chains can carry out real-time transaction through one intermediate chain, and the intermediate chain executes each transaction in real time;
(3b) multilateral net settlement (multilateral net): each intermediate chain performs multilateral net amount settlement at the end of each settlement period, processes a plurality of pending transactions (tentative transactions) together, plays a role of CCP, reduces transaction times and improves transaction efficiency;
(4) a plurality of financial institutions form a distributed network in the form of participating chains and intermediate chains, each chain maintains the consistency of the financial institutions, and the consistency between the chains is not managed by a central organization, so that the financial institutions can run in parallel, and the transaction efficiency and the network running speed are improved; new financial units can easily join or leave the network at any time, and the system has expandability and supports large-scale networks and high transaction volume.
Preferably, for the component (1), the chain network comprises a plurality of multi-participation chains, each participation chain represents one or more financial units, and the chain network comprises a plurality of multi-nodes, and each node stores all information of the financial unit; all or part of the nodes of the participating chains have voting rights (both the whole nodes and part of the nodes can participate in voting are applicable to the patent), and a Concurrent Byzantine Fault tolerant protocol (CBFT) or a Practical Byzantine Fault tolerant Protocol (PBFT) or other Byzantine (Byzantine) consensus protocol or an algorithm of database transaction consistency (for example, if the algorithm of database transaction consistency is used, the node which lies cannot be checked is a weakened consistency algorithm) is adopted among all the nodes to ensure the consistency and the difficult-to-flee modification of information among all the nodes and ensure the consistency of each participating chain.
Preferably, for the component (2), the chain network comprises a plurality of intermediate chains, each intermediate chain representing an intermediate institution, which is also a financial institution itself, and also functioning as a CCP (Central counter party), the intermediate chains and the participating chains having two or more common nodes, as shown schematically in fig. 2 and 3. The intermediate chain includes a plurality of nodes, all or some of which have voting authority (both of which are applicable to this patent). Byzantine fault-tolerant protocols (or weakened database transaction protocols) are adopted among all nodes to ensure the consistency and the difficult change of information among all nodes.
Preferably, the intermediate chain utilizes a common node to transact with the participating chain. If a node on the intermediate link is a common node of the n-th chain, as shown in fig. 5 and 7, the storage space of the node is divided into n +1 parts, a1, a2, …, An, which are responsible for storing information of the nth chain, and a C (connection) part, which is responsible for transferring information from the Ai part to the Aj part (i, j equals to 1,2, …, n), as shown in fig. 4, 6 and 8. The core algorithm of the model is illustrated below by taking a common node of two chains as an example, and as shown in fig. 4, the storage space of each common node is divided into three parts, i.e., L (left), R (right), and C (connection). The L part stores information of the left side chain of the common node, and the R part stores information of the right side chain of the common node. The contents of the L part and the R part can not be directly communicated, and information transmission from the L part to the R part or from the R part to the L part is required to be carried out through the C part.
Preferably, for the component (3), in the chain network, one to many intermediate chains may be connected between every two participating chains, and two to many participating chains may be connected between every two intermediate chains, and the intermediate chains complete the transaction between two or more participating chains, the chain network may implement two different transaction modes to meet two different requirements of instant transaction completion and non-real-time but efficient transaction:
(1) real-time transaction: two or more participation chains can carry out real-time transaction through one intermediate chain, and the intermediate chain executes each transaction in real time to realize real-time clearing and settlement;
(2) and (4) multilateral net settlement: each intermediate chain performs multilateral net settlement at the end of each settlement period (one hour or one day and the like), processes a plurality of pending transactions (tentative transactions) together, reduces the number of clearing settlement, and improves the transaction efficiency, because one clearing settlement can solve a large number of transactions, but the method cannot realize real-time clearing.
Preferably, for (1) real-time transactions, the core process of this transaction mode is shown in fig. 9 and fig. 13. The transaction pattern includes the following processes (the following is a high-level description of the steps, see the description of the algorithm and pseudo code in the detailed description of the embodiments in the description), the flow of which is shown in fig. 10 and 14.
(1) Participating chain 1(PPC1) initiates a transaction to intermediate chain 1(ICC 1);
the following process (2) is divided into two modes:
mode (I), see fig. 9:
(2) intermediate chain 1(ICC1) sends a transaction request to participating chain 2(PPC 2);
if the transaction initiation of the process (1) is successful, after the process (2) is executed, the transaction state is marked as pending;
mode (II), see fig. 13:
the following process (2a) is performed simultaneously with the process (2 b);
(2a) intermediate chain 1(ICC1) returns information to participating chain 1(PPC1) on the success or failure of the transaction request;
(2b) intermediate chain 1(ICC1) sends a transaction request to participating chain 2(PPC 2);
if the transaction initiation of the process (1) is successful, after the process (2a) and the process (2b) are executed, the transaction state is marked as pending;
after the execution (2a) in the mode (II) is completed, the participating chain 1(PPC1) can perform other operations, thereby implementing non-blocking operation.
(3) The participating chain 2(PPC2) sends a message to the intermediate chain 1(ICC1) whether the transaction request was successfully accepted by the participating chain 2(PPC2), and if so, sends to the intermediate chain 1(ICC1) a proof that the participating chain 2(PPC2) can accept the transaction;
the following process (4a) is executed simultaneously with the process (4 b);
(4a) intermediate chain 1(ICC1) informs participating chain 1(PPC1) that the transaction satisfies the execution condition and can be executed;
(4b) intermediate chain 1(ICC1) informs participating chain 2(PPC2) that the transaction satisfies the execution condition and can be executed;
after receiving the message of the intermediate chain 1(ICC1), the two participating chains immediately execute pending transactions of the intermediate chain 1(ICC1) and the participating chain 1(PPC1) and pending transactions of the intermediate chain 1(ICC1) and the participating chain 2(PPC2) until all the pending transactions are successfully executed, namely, the transaction (commit) is completed.
Preferably, for the (2) th transaction mode, the multi-edge net settlement, the core process of this transaction mode is shown in fig. 11 and fig. 15. The transaction pattern includes the following processes (the following is a high-level description of the steps, see the description of the algorithm and pseudo code in the detailed description of the embodiments in the description), the flow of which is shown in fig. 12 and 16.
(1) Participating chain 1(PPC1) initiates a transaction to intermediate chain 1(ICC 1);
the following process (2) is divided into two modes:
mode (I), see fig. 11:
(2) intermediate chain 1(ICC1) sends a transaction request to participating chain 2(PPC 2);
if the transaction initiation of the process (1) is successful, after the process (2) is executed, the transaction state is marked as pre-pending;
mode (II), see fig. 15:
the following process (2a) is performed simultaneously with the process (2 b);
(2a) intermediate chain 1(ICC1) returns information to participating chain 1(PPC1) on the success or failure of the transaction request;
(2b) intermediate chain 1(ICC1) sends a transaction request to participating chain 2(PPC 2);
if the transaction initiation of the process (1) is successful, after the processes (2a) and (2b) are executed, the transaction state is marked as pre-pending;
after the execution (2a) in the mode (II) is completed, the participating chain 1(PPC1) can perform other operations, thereby implementing non-blocking operation.
(3) The participating chain 2(PPC2) sends a message to the intermediate chain 1(ICC1) whether the transaction request was successfully accepted by the participating chain 2(PPC2), and if so, sends to the intermediate chain 1(ICC1) a proof that the participating chain 2(PPC2) can accept the transaction;
if the request is successfully accepted, marking the transaction status as pending;
the following process (4a) is executed simultaneously with the process (4 b);
(4a) intermediate chain 1(ICC1) informs participating chain 1(PPC1) that the transaction satisfies the execution condition and can be executed;
(4b) intermediate chain 1(ICC1) informs participating chain 2(PPC2) that the transaction satisfies the execution condition and can be executed;
when the transaction waits for the settlement period to end, executing the process (5);
(5) at this time, the settlement period is ended, all the transactions to be started or initialized and pending transactions are stopped, the transaction being executed is completed, and the intermediate chain 1(ICC1) performs multilateral net settlement on all the transactions marked as pending (tentative) in the settlement period, and then the transaction completion (commit) stage is entered.
Preferably, when one chain transfers information to another chain, the transfer mode is bulk transfer, as shown in fig. 17 and 18, each node of one chain transfers information to each node of another chain respectively, so as to prevent that one or some nodes cheat and influence the correctness of the whole transfer process. When the participating chain 1(PPC1) transmits a request to the intermediate chain 1(ICC1), if the participating chain 1(PPC1) shares m nodes, P1, P2, …, Pm, and TBC1 shares n nodes, T1, T2, …, and Tn, Pi (i ═ 1,2, …, n) transmits requests to T1, T2, …, and Tn, and all nodes transmit m × n requests in total. For example, as shown in fig. 17, when participating chain 1(PPC1) sends a request to intermediate chain 1(ICC1), node 1 and node 2 send request information to each node of intermediate chain 1(ICC1), respectively; for another example, when participating chain 2(PPC2) sends a request to intermediate chain 1(ICC1), node 3 and node 4 send request information to each node of intermediate chain 1(ICC1), respectively.
Preferably, following is a brief description of each step of processes (1) through (4) for two participating chains, participating chain 1(PPC1) and participating chain 2(PPC2), as detailed in the description of the algorithm and pseudo code in detailed description of specific embodiments in the description.
(1) The participating chain 1(PPC1) initiates a transaction to the intermediate chain 1(ICC 1):
(1.1) participating in chain 1(PPC1) (financial institution) initiating a transaction: the participating chain decides whether to initiate a transaction or not through internal voting (bazating fault-tolerant consensus protocol such as CBFT or PBFT or database transaction protocol), if yes, the participating chain 1(PPC1) performs encrypted authentication (using digital signature or the like) on the transaction information, and the participating chain 1(PPC1) obtains all information of the participating chain 1(PPC1) through the consensus with the common node (node 1 and node 2 in fig. 9) of the intermediate chain 1(ICC 1). Subsequently, the L part passes the content related to the present transaction and information for verification, such as digital signatures of all nodes participating in the chain 1(PPC1), to the R part through the C part. The R section broadcasts (broadcast) these encrypted and authenticated transaction information to each node of the intermediate chain 1(ICC1), as shown in fig. 17; if not, returning error information to the participation chain 1(PPC1) and marking the process as failure (failure);
(1.2) intermediate chain 1(ICC1) authentication information: after receiving the transaction information, the intermediate link (ICC1) verifies the transaction information (using digital signature, etc.), if the verification is successful, each node votes and blocks the transaction, and the transaction is in a pending (pending) state; if the verification fails, an error message is returned, and the previous steps are marked as failure.
The following process (2) is divided into two modes:
mode (I):
(2) intermediate chain 1(ICC1) sends a transaction request to participating chain 2(PPC 2):
(2.1) intermediate chain (ICC1) passing transactions: the intermediate chain (ICC1) decides whether to pass the transaction to the participating chain 2(PPC2) by internal voting (bayesian fault-tolerant consensus protocol such as CBFT or PBFT or database transaction protocol), if so, the intermediate chain (ICC1) cryptographically authenticates the transaction (using digital signature or the like), and the intermediate chain 1(ICC1) obtains all the information of the intermediate chain 1(ICC1) by consensus with the common nodes of the participating chain 2(PPC2) (in fig. 9, for the L portions of nodes 3 and 4). Subsequently, the L section passes the content related to the present transaction and information for verification such as digital signatures of all nodes of the intermediate chain 1(ICC1) to the R section through the C section. The R section further broadcasts (broadcasts) these encrypted authenticated transaction information to each node participating in the chain 2(ICC2), as shown in fig. 18; if not, returning error information, and marking the previous steps as failure;
(2.2) participating in chain 2(PPC2) authentication information: the participating chain 2(PPC2) verifies the transaction of the received request (using a digital signature, etc.), and if the verification is passed, the participating chain 2(PPC2) performs an internal voting to decide whether to accept the transaction; if the verification fails, failure information is returned, and the previous steps are marked as failure (failure).
Mode (II):
(2a) the intermediate chain 1(ICC1) returns information to the participating chain 1(PPC1) on the success or failure of the pending transaction:
when the participating chain 1(PPC1) receives the information that the verification of the intermediate chain 1(ICC1) was successful and the transaction is marked pending, the participating chain can proceed to other transactions without waiting further.
(2b) The process is the same as the process (2) of mode (I).
(3) Participating chain 2(PPC2) sends a message to intermediate chain 1(ICC1) whether the transaction request was successfully accepted by participating chain 2(PPC2), and if so, sends to intermediate chain 1(ICC1) a proof that the participating chain 2(PPC2) can accept the transaction:
(3.1) if the participation chain 2(PPC2) votes successfully and agrees to accept the transaction, returning success information to the intermediate chain 1(ICC1) and performing (3.2); otherwise, returning failure information to the intermediate chain 1(ICC1), and marking the previous steps as failure (failure);
(3.2) the participating chain 2(PPC2) sends a proof to the intermediate chain 1(ICC1) that the participating chain 2(PPC2) can accept the transaction, e.g., the participating chain 2(PPC2) has sufficient resources associated to complete the transaction, and the transactions of the intermediate chain 1(ICC1) and the participating chain 2(PPC2) are set to pending (pending) state.
(4) The middle chain verifies the information returned by the participation chain 2(PPC2) and determines whether the transaction meets the execution condition, if so, then (4a) and (4b) are carried out; if not, voting is carried out to determine whether to cancel the pending transaction, and the previous steps are marked as failure.
(4a) Intermediate chain 1(ICC1) informs participating chain 1(PPC1) that the transaction satisfies the execution condition and can be executed;
(4b) the intermediate chain 1(ICC1) informs the participating chain 2(PPC2) that the transaction satisfies the execution condition and can be executed.
In order to improve the existing problems that the chain network result designed aiming at the financial system can not be operated in parallel and the efficiency is slow, the distributed novel chain network structure model designed at present has the following advantages:
(1) support for parallel operation: because the model is a completely distributed architecture, all chains can run on the model in parallel, and the running speed of the whole financial system is improved: because different participation chains can trade with different intermediate chains, and the trades processed by different participation chains can be carried out simultaneously, each trade does not need to pass through a general central mechanism, the trading volume and the loading capacity of each intermediate mechanism are greatly reduced, and the parallel operation can be carried out, thereby improving the trading efficiency and speeding up the trading speed.
(2) And (4) multilateral net settlement: when two or more participating chains trade through one intermediate chain, the intermediate chain carries out mutual offset and offset on a plurality of trades, the settlement processing amount is reduced, the difficulty of large-scale trading is also reduced, the trading speed is improved, and the market efficiency is improved.
(3) And (3) expandability: any number of financial institutions and intermediate institutions can easily join the chain network structure at any time, and a new financial unit to be joined is connected with the existing intermediate institution through the TBC, which allows the chain network to expand and accommodate a large network and a high transaction amount.
(4) And (3) supporting supervision: the account book record which is difficult to be tampered records the real transaction process, and is convenient for government departments to supervise and check accounts.
(5) The basic principle of the chain net is ensured, which comprises the following steps: (a) the high-performance completely distributed structure supports each intermediate mechanism to run in parallel, and the transaction efficiency of the network is improved; (b) data reliability (difficult tamper property and safety), wherein each node adopts a Byzantine fault-tolerant protocol to ensure the consistency and difficult tamper property of each node; (c) privacy is protected, and information in each chain cannot be acquired from the outside; (f) the expandability is realized, any financial institution can easily join the chain network at any time, and due to parallel operation, the communication blockage can not be caused by adding a new financial institution; (e) completeness, each chain can track its completeness, which decreases once a node cheats and can be tracked and viewed.
The above and other objects, advantages and features of the present invention will become more apparent to those skilled in the art from the following detailed description of specific embodiments thereof taken in conjunction with the accompanying drawings.
Drawings
Some specific embodiments of the invention will be described in detail hereinafter, by way of illustration and not limitation, with reference to the accompanying drawings. The same reference numbers in the drawings identify the same or similar elements or components. Those skilled in the art will appreciate that the drawings are not necessarily drawn to scale. The objects and features of the present invention will become more apparent in view of the following description taken in conjunction with the accompanying drawings. In the drawings:
FIG. 1 is a general schematic diagram of a blockchain Internet model (golden monkey model) for cross-chain transactions according to a preferred embodiment of the present invention;
FIG. 2 is a diagram of an intermediate chain (ICC) and a participation chain (PPC) that may have two common nodes according to a preferred embodiment of the present invention;
FIG. 3 is a schematic diagram of three common nodes possible for an intermediate chain (ICC) and a participation chain (PPC) according to a preferred embodiment of the present invention;
FIG. 4 is a schematic diagram of a structure of a common node linking two chains according to a preferred embodiment of the present invention;
FIG. 5 is a schematic diagram of an intermediate chain (ICC) linking three participating chains (PPCs) via a common node according to a preferred embodiment of the present invention;
FIG. 6 is a schematic diagram of a structure of a common node linking three chains according to a preferred embodiment of the present invention;
FIG. 7 is a diagram of an intermediate chain (ICC) linking four participating chains (PPCs) via a common node according to a preferred embodiment of the present invention;
FIG. 8 is a schematic diagram of a structure of a common node linking four chains according to a preferred embodiment of the present invention;
FIG. 9 is a schematic diagram of the real-time transaction process of mode (I) (PPC as participation chain, ICC as intermediate chain) according to the preferred embodiment of the present invention;
FIG. 10 is a flowchart of the respective processes of the mode (I) real-time transaction according to the preferred embodiment of the present invention;
FIG. 11 is a schematic diagram of a transaction process employing multi-party net settlement according to mode (I) of the preferred embodiment of the present invention (PPC is a participation chain, and ICC is a middle chain);
FIG. 12 is a flowchart of a transaction process employing multi-party net settlement according to mode (I) of the preferred embodiment of the present invention;
FIG. 13 is a schematic diagram of the real-time transaction process of mode (II) according to the preferred embodiment of the present invention (PPC is the participation chain, and ICC is the intermediate chain);
FIG. 14 is a flowchart of the respective processes of the mode (II) real-time transaction according to the preferred embodiment of the present invention;
FIG. 15 is a schematic diagram of a transaction process employing multi-party net settlement according to mode (II) of the preferred embodiment of the present invention (PPC is a participation chain, and ICC is a middle chain);
FIG. 16 is a flowchart of a transaction process employing multi-party net settlement according to mode (II) of the preferred embodiment of the present invention;
fig. 17 is a schematic diagram of a process 1 in which a common node transmits information to an intermediate chain (ICC) (a participation chain is a PPC);
fig. 18 is a diagram illustrating that a common node transmits information to the transmission participation chain 2(PPC2) (PPC is a participation chain, and ICC is an intermediate chain) in the process 2 of the mode (I) (or the process 2b of the mode (II)) according to the preferred embodiment of the present invention.
Detailed description of the preferred embodiments
In order to better understand the technical solutions provided by the embodiments of the present invention and better compare with the technical solutions provided by the embodiments of the present invention, the present invention is further explained below by using algorithms and pseudo codes in combination with the accompanying drawings.
The specific implementation of the blockchain internet model (golden monkey model) of the wait-free cross-chain transaction mainly comprises the following three parts:
(1) the whole network is built from zero;
(2) trading: one participating chain transacts with the other participating chain through an intermediate chain;
(3) the new link joins the network.
For (1) the whole network is built from zero, the input of the network comprises a plurality of intermediate chains (Inter-chain Blockchain, represented by ICC in pseudo code), a plurality of participating chains (Participant Blockchain, represented by PPC in pseudo code), and the relation of whether each participating chain should be connected with the intermediate chains, and the specific process is as follows.
(1) For the chains to be added into the network, putting all the participating chains into a participating chain set, and putting all the intermediate chains into an intermediate chain set;
(2) for each intermediate chain in the intermediate chain set and each two participating chains in the participating chain set, judging by using the known relationship between the upcoming chain and the chain of the network: if the intermediate chain is to be connected with the two participating chains, the intermediate chain is respectively connected with the two participating chains; otherwise, the other chains continue to be considered.
The main algorithm of the process is shown in pseudo code form, denoted as algorithm 0, to establish the network.
"consensus protocol" in the pseudo-code below denotes "CBFT or PBFT or other Byzantine consensus protocol or database consistency".
For (2) transaction: one participating chain transacts with another participating chain through an intermediate chain, as shown schematically in fig. 2. Its inputs include intermediate chain 1(ICC1), participating chain 1(PPC1), and participating chain 2(PPC 2). The participating chain 1(PPC1) is responsible for initiating transactions and transactions are conducted by the intermediate chain 1 and received by the participating chain 2(PPC 2). For example, participating chain 1(PPC1) conducts a dollar gold exchange transaction to participating chain 2(PPC2), participating chain 1(PPC1) initiates a transaction that provides dollars and exchanges for gold, provides a certain amount of money, performs a transaction process by intermediate chain 1, and participating chain 2(PPC2) is responsible for receiving the dollars and providing gold.
For each transaction, two cases of real-time transaction and multilateral net settlement are included, and the specific transaction process is as follows.
(1) The participation chain 1(PPC1) decides whether to initiate the transaction by voting (using CBFT, or PBFT, or other byzantine consensus protocol, or database transaction protocol) on each node within it, and if the voting is successful, step (2) is entered; if the voting fails, returning error information;
(2) invoking algorithm 2, the participating chain 1(PPC1) sends a transaction request (using a common node of the participating chain 1(PPC1) and the intermediate chain 1(ICC 1)) to the intermediate chain 1(ICC1), which is process (1);
(3) calling algorithm 3, verifying the transaction request (using an electronic signature or the like) by the intermediate chain 1(ICC1), and entering section (4) if the verification is successful; if the verification fails, an error message is returned to the participating chain 1(PPC 1);
(4) the intermediate chain 1 votes (using CBFT, or PBFT, or other Byzantine consensus protocol, or database transaction protocol) for each node inside it to decide whether the transaction can be executed, and if the voting is successful, step (5) is entered; if the vote fails, information of the failure of the vote is returned to the participation chain 1(PPC1), and all the previous steps are marked as 'failure';
(5) setting the transaction status between the participating chain 1(PPC1) and the intermediate chain 1(ICC1) to "pending" (pending);
(6) if a real-time transaction is required, marking the transaction status as "pending" (tentative); if a multi-sided net settlement is required, then the transaction status is marked as "pre-pending" (pre-tentative);
(7) if mode (I), algorithm 4 is invoked, central chain 1(ICC1) begins to prepare to initiate a transaction request to participating chain 2(PPC2), i.e., process (2); if the process (2) returns that the transaction request of the central chain 1(ICC1) to the participation chain 2(PPC2) is successful, the step (8) is entered, otherwise, all the previous steps are marked as 'failure', and an algorithm 7 is invoked, the intermediate chain 1(ICC1) and the participation chain 1(PPC1) and the participation chain 2(PPC2) perform consensus, and whether to cancel the pending transaction of the intermediate chain 1(ICC1) and the participation chain 1(PPC1) is determined, and error information is returned; if the mode is the mode (II), the algorithm 2 is called, the middle chain 1(ICC1) informs the participating chain 1(PPC1) of the current transaction state, i.e., the process (2a), and simultaneously the process 2 in the mode (I) is performed;
(8) invoking algorithm 2, the participating chain 2(PPC2) informing the middle chain 1(ICC1) whether the current participating chain 2(PPC2) agrees with the transaction, and if so, sending information that the participating chain 2(PPC2) proves that the transaction can be performed to the middle chain 1(ICC1) for verification by the middle chain 1(ICC1), namely, process (3);
(9) the intermediate chain 1(ICC1) verifies the information, if the information passes the verification, the step (10) is entered, otherwise all the previous steps are marked as 'failure', an algorithm 7 is called, the intermediate chain 1(ICC1) agrees with the participating chain 1(PPC1) and the participating chain 2(PPC2), whether to cancel the pending transaction of the intermediate chain 1(ICC1) and the participating chain 1(PPC1) is determined, and error information is returned;
(10) marking the transaction state between the intermediate chain 1(ICC1) and the participating chain 2(PPC2) as pending (pending), and calling the algorithm 2, and informing the participating chain 1(PPC1), i.e. the participating chain 2(PPC2), that the transaction satisfies the transaction condition by the intermediate chain 1(ICC1), which can be executed, i.e. the process (4a) and the process (4 b);
(11) if the participation chain 1(PPC1) fails to receive the notification that the transaction can be executed within a certain Time (Time1), the intermediate chain (ICC1) agrees with the participation chain 1(PPC1) and the participation chain 2(PPC2) to determine whether to cancel the transaction, if so, the step (12) is entered, otherwise, the step (13) is entered;
(12) marking all the previous steps as 'failure', and canceling pending transactions of the intermediate chain (ICC1) and the participating chain 1(PPC1) and pending transactions of the intermediate chain (ICC1) and the participating chain 2(PPC2), and then the intermediate chain 1(ICC1) again agrees with the participating chain 1(PPC1) and the participating chain 2(PPC2) and returns failure information;
(13) if real-time transaction is required, invoking algorithm 5 to execute the real-time transaction; if a multi-sided net settlement is required, the transaction status is marked as "pending" and algorithm 6 is invoked to perform the multi-sided net settlement (in algorithm 6, it is first waited until the end of the settlement period).
For algorithm 2, called in algorithm 1, passing information from one chain to another, the input includes a chain that sends information and a chain that accepts information. The specific process is as follows.
(1) Placing the common nodes of the two chains into a set;
(2) for each node in the set, the node sends the required information to the chain of accepted information.
The main algorithm of this process is shown in pseudo code form as algorithm 2, passing information from one chain to another.
For algorithm 3 invoked in algorithm 1, the transaction information is verified with a digital signature, the inputs of which include the requestor, verifier, and requested transaction. The specific process is as follows.
(1) The verifier verifies the requester by using the digital signature, and if the verification is successful, the step (2) is carried out; if the verification fails, returning information of the verification failure to the requester;
(2) the verifier checks whether the requester has the relevant resources to perform the transaction requested by the requester, and if so, the step (3) is entered; otherwise, returning failure information without related resources to the requester;
(3) the verifier checks whether the requester has enough resources or balance to complete the requested transaction, and if so, returns the information of successful verification; otherwise, failure information of insufficient resources is returned to the requester.
The main algorithm of this process is shown below in pseudo code form, denoted as algorithm 3, and verifies the transaction information with a digital signature.
For algorithm 4 invoked in algorithm 1: hub chain 1(ICC1) begins to prepare to initiate a transaction request to participating chain 2(PPC2), whose inputs include intermediate chain 1(ICC1) and participating chain 2(PPC 2). The specific process is as follows.
(1) The intermediate chain 1 votes (using CBFT, or PBFT, or other byzantine consensus protocol, or database transaction protocol) on its various nodes to decide whether to perform its transaction with the participating chain 2(PPC2), and if the vote is successful, step (2) is entered; if the voting fails, returning failure information;
(2) calling algorithm 2, and the intermediate chain 1(ICC1) sends a transaction request to the participation chain 2(PPC2), namely process (2 b);
(3) calling an algorithm 3, verifying the transaction request (by using an electronic signature and the like) by the participation chain 2(PPC2), and entering the step (4) if the verification is successful; if the verification fails, returning error information and marking all previous steps as 'failure';
(4) the participation chain 2(PPC2) votes (using CBFT, or PBFT, or other byzantine consensus protocol, or database transaction protocol) on its internal nodes to decide whether to accept the transaction, and if the vote is successful, returns a success message; if the voting fails, the information of the voting failure is returned, and all the previous steps are marked as 'failure'.
The main algorithm of the process is shown below in pseudo code, denoted algorithm 4, with central chain 1 initiating a transaction request to participant chain 2.
For algorithm 5 called in algorithm 1, the intermediate chain executes real-time transaction, and after the participating chains 1(PPC1) and 2(PPC2) receive the information sent by the intermediate chain confirming that the transaction can occur, i.e. after processes (4a) and (4b) are completed, the transactions marked as pending (pending) of the intermediate chain and participating chain 1(PPC1) and the intermediate chain and participating chain 2(PPC2) are executed immediately in the process, and the transaction (commit) is completed. The specific process is as follows.
(1) The transactions marked pending (pending) of intermediate chain and participating chain 1(PPC1) and intermediate chain and participating chain 2(PPC2) are performed until the transaction of participating chain 2(PPC2) by the participating chain 1(PPC1) is successfully completed.
(2) Algorithm 2 is invoked and the middle chain informs participating chain 1(PPC1) that the transaction is complete with participating chain 2(PPC 2).
The main algorithm of the process is shown below in pseudo code, denoted as algorithm 5, with the middle chain performing real-time transactions.
For algorithm 6 invoked in algorithm 1, the intermediate chain performs a multi-edge net settlement, which proceeds when the intermediate chain completes the accounting of transactions for a certain amount of time (a settlement period: one hour, one day, one week, etc.) (transactions for each of the participating chains within that amount of time are accounted in the intermediate chain). The specific process is as follows.
When a settlement period is finished, the intermediate chain carries out the following operations;
(1) stop initializing or starting any new transactions and complete all ongoing or pending transactions;
(2) the intermediate chain finds all the participating chains which are trying to trade with the intermediate chain in the previous settlement period and puts the participating chains into a set;
(3) the intermediate chain finds out all transaction records in the previous settlement period;
(4) for each participating chain, the intermediate chain performs conflict rolling on the funds or resources due and receivable for all transactions in the previous settlement period, and performs delivery to the participating chain according to the net value obtained from the rolling.
(5) Verifying whether the multiparty equity settlement result is correct: judging whether the sum of the business in and out of all the participating chains which carry out the business through the intermediate chain in the settlement period is 0 after the offset is carried out, if so, judging the business to be correct, and if not, judging the business to be wrong;
(6) if the result is correct, the intermediate chain executes final transaction to each participating chain according to the settlement result; if not, then the multi-party net worth settlement is carried out again or the manual check is carried out.
The main algorithm of this process is shown below in pseudo code, denoted algorithm 6, with the intermediate chain performing multi-edge net settlement.
For the algorithm 7 called in the algorithm 1, to cancel the pending transaction between the intermediate chain (ICC) and the participating chain 1(PPC1), before each cancellation operation, the intermediate chain needs to be in consensus with all participating chains participating in the current transaction to decide whether to cancel the pending transaction. If the pending transaction is cancelled, the intermediate chain needs to agree again to inform all the participating chains participating in the transaction. The specific process is as follows.
(1) The intermediate chain (ICC) shares with the participating chain 1(PPC1) and the participating chain 2(PPC2) to decide whether to cancel the pending (pending) transaction between the participating chain 1(PPC1) and the intermediate chain (ICC);
(2) if so, the pending transaction is cancelled and the intermediate chain (ICC) agrees with the participating chain 1(PPC1) and the participating chain 2(PPC2) to inform that the pending transaction has been cancelled.
The main algorithm of this process is shown below in pseudo code, denoted as algorithm 7, to cancel pending transactions between the intermediate chain and the participating chain 1(PPC 1).
For (3) new links join the network, two cases are distinguished: (A) the new participating chain joins the network; (B) the new intermediate link joins the network. Two cases are discussed separately below.
For case (a), a new participating chain joins the network, whose inputs are the new participating chain to be joined to the network, and the network (including other participating chains and intermediate chains in the network). When a new participating chain is to join the network, the participating chain may itself generate one or more intermediate chains, and these newly generated intermediate chains may be linked to other participating chains already present in the network, while the participating chain may also be linked to other intermediate chains already present in the network; the participating chain may not generate an intermediate chain itself, and the participating chain must then link one or more existing intermediate chains. The specific process is as follows.
(1) In the case where the participating chain needs to generate a new intermediate chain by itself, the following procedure is performed until the participating chain no longer needs to generate a new intermediate chain by itself:
(a) the participating chain generates a new intermediate chain;
(b) this intermediate chain is linked to the participating chain by invoking the algorithm 10;
(c) finding out all other existing participating chains needing to be connected with the intermediate chain (each intermediate chain needs to be connected with two or more participating chains), and putting the participating chains into one other participating chain set;
(d) for each participating chain in the obtained other participating chain set, connecting the participating chain with the intermediate chain by calling the algorithm 10;
subsequently, execution is performed:
(2) judging whether the participating chain needs to be connected with an existing intermediate chain in the network, if so, entering the step (3);
(3) finding all other participation chains with which the participation chain needs to be traded, and finding all intermediate chains connected with the participation chains;
(4) under the condition that all the participating chains found in the previous step are ensured to be included, finding out an intermediate chain subset from all the intermediate chains found in the previous step, wherein each participating chain can be connected with a plurality of intermediate chains, so that one intermediate chain can be found out to ensure that all the required participating chains are connected with the intermediate chains;
(5) for each intermediate chain in the subset of intermediate chains, the participating chain is connected to the intermediate chain by invoking algorithm 10.
The main algorithm of this process is shown below in pseudo code, denoted algorithm 8, with the new participating chain joining the network.
For case (B), a new intermediate chain joins the network, whose inputs are the new intermediate chain to be joined to the network, and the network (including other participating and intermediate chains in the network). The specific process is as follows.
(1) Finding the existing participating chains in all networks that need to be connected to the new intermediate chain to be added;
(2) if no or only one participating chain is to be connected to the intermediate chain, returning an error message to the intermediate chain because each intermediate chain needs to be connected to two or more participating chains; if two or more participating chains are to be connected with the intermediate chain, the step (3) is carried out;
(3) the participating chains to be connected to the intermediate chain are placed in a set, and each participating chain in the set is connected to the intermediate chain by invoking the algorithm 10.
The main algorithm of this process is shown below in pseudo code, denoted as algorithm 9, with a new intermediate link joining the network.
For algorithm 10 invoked in algorithms 8 and 9: one participating chain is connected to one intermediate chain, and the inputs include one participating chain and one intermediate chain. The specific process is as follows.
(1) The participation chain decides whether to connect with the middle chain by voting (using CBFT, PBFT or other Byzantine consensus protocol or database transaction protocol) for each node inside the participation chain, and if the voting is successful, step (2) is entered; if the voting fails, returning error information;
(2) the participating chain sends verification information (such as a digital signature, etc.) to the intermediate chain;
(3) the intermediate chain verifies the received verification information (by using a digital signature and the like), if the verification is successful, the step (4) is carried out, otherwise, error information is returned;
(4) the intermediate chain decides whether to connect with the participation chain by voting (using CBFT, PBFT, other Byzantine consensus protocol or database transaction protocol) for each node inside the intermediate chain, if yes, the step (5) is entered, otherwise, error information is returned;
(5) determining the number of required common nodes, and selecting the number of common nodes from all nodes of the participating chain and the intermediate chain;
(6) among the selected nodes, putting the nodes belonging to the intermediate chain into an intermediate chain common node set, and putting the nodes belonging to the participating chain into another participating chain common node set;
(7) for each node in the intermediate chain common node set, connecting the node with each node participating in the chain; for each node in the set of nodes that participate in the common set of nodes of the chain, the node is connected to each node of the intermediate chain.
The main algorithm of this process is shown below in pseudo code, denoted as algorithm 10, with one participating chain connected to one intermediate chain.
While the present invention has been described with reference to the particular illustrative embodiments, it is not to be restricted by the embodiments but only by the appended claims. It will be understood by those skilled in the art that variations and modifications of the embodiments of the present invention can be made without departing from the scope and spirit of the invention.
Claims (9)
1. A method for constructing a block chain Internet model of cross-chain transaction is characterized in that the model comprises a participation chain and an intermediate chain, wherein the participation chain represents one or more financial institutions or financial units and comprises one or more nodes; the intermediate chain represents an intermediate institution which is a financial institution and plays the role of a central counterparty, the intermediate chain comprises a plurality of nodes, the intermediate chain and the participation chain have common nodes which are equal to or more than two, and the intermediate chain utilizes the common nodes to trade with the participation chain; one or more intermediate chains are connected between every two participation chains, each intermediate chain is connected with two or more than two participation chains, and the intermediate chains complete the transaction between the two or more than two participation chains, wherein the transaction comprises two transaction modes of instant transaction completion or non-real-time but efficient transaction so as to be suitable for different requirements; the instant transaction is a real-time transaction, two or more participation chains carry out the real-time transaction through one intermediate chain, and the intermediate chain executes each transaction in real time; the non-real-time but efficient transaction is multilateral net settlement, each intermediate chain performs multilateral net settlement at the end of each settlement period, and a plurality of pending transactions are processed together to play a role of a central counterparty; a plurality of financial units form a distributed network in the form of participating chains and intermediate chains, the participating chains and each chain in the intermediate chains maintain the consistency thereof, and the consistency between the participating chains and the intermediate chains can run in parallel without central organization management; new financial institutions may join or leave the network at any time.
2. The method for constructing the block chain internet model of the cross-chain transaction according to claim 1, wherein: each of said participating chains represents one or more financial units, each of said nodes storing all information of said financial units; all or part of the nodes of the participation chain have voting right, a concurrent Byzantine fault-tolerant protocol, a practical Byzantine fault-tolerant protocol or an algorithm of database transaction consistency is adopted among all the nodes, and the consistency of information among the nodes and the difficulty in tampering guarantee the consistency of each participation chain.
3. The method for constructing the block chain internet model of the cross-chain transaction according to claim 1, wherein: all or part of the nodes in the plurality of nodes in the intermediate link have voting right, and a Byzantine fault-tolerant protocol or a weakened database transaction protocol is adopted among the nodes to ensure the consistency and the tamper resistance of the information among the nodes.
4. The method for constructing the block chain internet model of the cross-chain transaction according to claim 3, wherein: the intermediate chain utilizes a common node to trade with the participating chain, if a certain node on the intermediate chain is a common node of the n chains, the storage space of the node is divided into n +1 parts for storing information of the n chain, respectively, A1, A2, … and An, and a connecting part for transmitting information from the Ai part to the Aj part, wherein i, j is 1,2, … and n.
5. The method for constructing the block chain internet model of the cross-chain transaction according to claim 4, wherein: the transaction mode of the real-time transaction comprises the following processes:
(1) the first participating chain initiates a transaction to the first intermediate chain;
(2) the first intermediate chain sends a transaction request to the second participating chain;
if the transaction initiation of the process (1) is successful, after the process (2) is executed, marking the transaction state as pending;
the following processes (2a) and (2b) are simultaneously performed:
(2a) the first intermediate chain returns the information whether the transaction request is successful or not to the first participation chain;
(2b) the first intermediate chain sends a transaction request to the second participating chain;
if the transaction initiation of the process (1) is successful, after the processes (2a) and (2b) are executed, marking the transaction state as pending;
after the execution (2a) is finished, the first participation chain can perform other operations to realize non-blocking operation;
(3) the second participation chain sends a message whether the transaction request is successfully accepted by the second participation chain to the first intermediate chain, and if the transaction request is successfully accepted by the second participation chain, the second participation chain sends a proof that the transaction can be accepted by the second participation chain to the first intermediate chain;
performing the process (4a) and the process (4b) simultaneously:
(4a) the first intermediate chain informs the first participation chain that the transaction meets the execution condition and can be executed;
(4b) the first intermediate chain informs the second participation chain that the transaction meets the execution condition and can be executed;
and immediately executing pending transactions of the first intermediate chain and the first participation chain and pending transactions of the first intermediate chain and the second participation chain after the first participation chain and the second participation chain receive the message of the first intermediate chain until all the pending transactions are executed successfully, namely completing the transactions.
6. The method for constructing the block chain internet model of the cross-chain transaction according to claim 4, wherein: the multi-sided net settlement transaction mode comprises the following steps:
(1) the first participating chain initiates a transaction to the first intermediate chain;
(2) the first intermediate chain sends a transaction request to the second participating chain;
if the transaction is successfully initiated, after the process (2) is executed, marking the transaction state as pre-pending;
performing the process (2a) and the process (2b) simultaneously:
(2a) the first intermediate chain returns the information whether the transaction request is successful or not to the first participation chain;
(2b) the first intermediate chain sends a transaction request to the second participating chain;
if the transaction is successfully initiated, after the process (2a) and the process (2b) are executed, the transaction state is marked as pre-pending;
after the execution (2a) is finished, the first participation chain can perform other operations to realize non-blocking operation;
(3) the second participation chain sends a message whether the transaction request is successfully accepted by the second participation chain to the first intermediate chain, and if so, sends a proof that the transaction can be accepted by the second participation chain to the first intermediate chain;
if the request is successfully accepted, marking the transaction status as pending;
performing the process (4a) and the process (4b) simultaneously:
(4a) the first intermediate chain informs the first participation chain that the transaction meets the execution condition and can be executed;
(4b) the first intermediate chain informs the second participation chain that the transaction meets the execution condition and can be executed; when the transaction waits for the settlement period to end, executing the process (5);
(5) at the moment, the settlement period is ended, all transactions to be started or initialized and pending transactions are stopped, the executing transactions are completed, the first intermediate chain performs multilateral net settlement on all the transactions marked as pending in the settlement period, and the transaction completion stage is entered.
7. The method for constructing the block chain internet model of the cross-chain transaction according to claim 4, wherein: the intermediate chain trading with the participation chain using the common node comprises: the middle chain firstly carries out consensus voting on each node to decide whether to initiate a transaction, the left part of each public node of the middle chain and the participation chain obtains the transaction information of other nodes of the middle chain, the node transmits the content related to the transaction to the right part through the connection part of the middle chain, and then the right part of each public node sends a transaction request related to the transaction to each node of the other chain, so as to prevent a certain node or nodes from cheating to cause system errors or failures.
8. The method for constructing the blockchain internet model of the cross-chain transaction according to claim 7, wherein: when one chain transmits information to the other chain, the transmission mode is bulk transmission, and each node of one chain transmits information to each node of the other chain respectively, so that the correctness of the whole transmission process is prevented from being influenced by cheating of one or more nodes; when the first participating chain transmits a request to the first intermediate chain, if the first participating chain has m nodes, P1, P2, …, Pm, and TBC1 has n nodes, T1, T2, …, and Tn, respectively, the first participating chain transmits a request to T1, T2, …, and Tn by Pi, i, 1,2, …, and n, respectively, and all the nodes transmit m × n requests in total.
9. The method for constructing the block chain internet model of the cross-chain transaction according to claim 5, wherein: for two participation chains, the first participation chain transacting with the second participation chain through an intermediate chain, comprising:
(1) the first participating chain initiates a transaction to the first intermediate chain:
(1.1) the first participating chain initiates a transaction: the first participation chain determines whether to initiate a transaction or not through internal voting based on a CBFT or PBFT Byzantine fault-tolerant consensus protocol or a database transaction protocol, if so, the first participation chain encrypts and authenticates transaction information by adopting a digital signature, and obtains all information of the first participation chain through the consensus and the left part of a first intermediate chain common node; then, the left part transmits the content related to the transaction and all the nodes in the first participation chain as digital signatures for verification information to the right part through the connection part, and the right part broadcasts the transaction information subjected to encryption authentication to each node of the first intermediate chain; if not, returning error information to the first participation chain, and marking the process as failure;
(1.2) first intermediate chain authentication information: after receiving the transaction information, the first intermediate link verifies the transaction information by using a digital signature, if the verification is successful, each node votes and builds a block for the transaction, and the transaction is in an undetermined state; if the verification fails, returning error information, and marking the previous steps as failure;
the process (2) is divided into two modes, mode (I) and mode (II), wherein:
mode (I):
(2) the first intermediate chain sends a transaction request to the second participating chain:
(2.1) first intermediate chain passing transaction: the first intermediate chain determines whether to transmit the transaction to the second participating chain or not through internal voting based on a CBFT or PBFT Byzantine fault-tolerant consensus protocol or a database transaction protocol, if so, the first intermediate chain uses a digital signature to encrypt and authenticate the transaction, and the first intermediate chain obtains all information of the first intermediate chain with the left part of a common node of the second participating chain through consensus; then, the left part transmits the content related to the transaction and all nodes in the first intermediate chain as the digital signature for verification information to the right part through the connection part, and the right part broadcasts the transaction information subjected to encryption authentication to each node of the second participation chain; if not, returning error information, and marking the previous steps as failure;
(2.2) second participation chain verification information: the second participation chain verifies the received transaction of the request by using the digital signature, and if the verification is passed, the second participation chain carries out internal voting to determine whether to accept the transaction; if the verification fails, returning failure information, and marking the previous steps as failure;
mode (II):
(2a) the first intermediate chain returns the information whether the pending transaction is successful or not to the first participating chain:
when the first participation chain receives the information that the verification of the first intermediate chain is successful and the transaction is marked as pending, the first participation chain can carry out other transactions without continuously waiting;
(2b) the process is the same as the process (2) of the mode (I);
(3) the second participation chain sends a message to the first intermediate chain whether the transaction request is successfully accepted by the second participation chain, and if so, sends a proof to the first intermediate chain that the second participation chain can accept the transaction:
(3.1) if the voting of the second participation chain is successful and the transaction is accepted, returning success information to the first intermediate chain, and performing (3.2); otherwise, returning failure information to the first intermediate chain, and marking the previous steps as failure;
(3.2) the second participation chain sending a proof to the first intermediate chain that the second participation chain can accept the transaction, and setting the transaction of the first intermediate chain and the second participation chain to a pending state;
(4) the first intermediate chain verifies the information returned by the second participating chain and determines whether the transaction meets the execution condition, if so, the steps (4a) and (4b) are carried out; if not, voting to determine whether to cancel the pending transaction, and marking the previous steps as failure;
(4a) the first intermediate chain informs the first participation chain that the transaction meets the execution condition and can be executed;
(4b) the first intermediate chain informs the second participating chain that the transaction satisfies the execution condition and can be executed.
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201710483789.4A CN107301600B (en) | 2017-06-23 | 2017-06-23 | Core construction method of block chain Internet model for cross-chain transaction |
| PCT/CA2018/000130 WO2018232494A1 (en) | 2017-06-23 | 2018-06-22 | A network of blockchains capable of cross-chain transactions |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201710483789.4A CN107301600B (en) | 2017-06-23 | 2017-06-23 | Core construction method of block chain Internet model for cross-chain transaction |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN107301600A CN107301600A (en) | 2017-10-27 |
| CN107301600B true CN107301600B (en) | 2021-07-20 |
Family
ID=60136512
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201710483789.4A Active CN107301600B (en) | 2017-06-23 | 2017-06-23 | Core construction method of block chain Internet model for cross-chain transaction |
Country Status (2)
| Country | Link |
|---|---|
| CN (1) | CN107301600B (en) |
| WO (1) | WO2018232494A1 (en) |
Families Citing this family (46)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107248076A (en) * | 2017-06-24 | 2017-10-13 | 北京天德科技有限公司 | A kind of core algorithm of the double-chain block chain the Internet model merchandised across chain |
| US10938567B2 (en) * | 2017-09-12 | 2021-03-02 | Kadena Llc | Parallel-chain architecture for blockchain systems |
| CN108600301B (en) * | 2018-03-08 | 2021-05-18 | 青岛墨一客区块链有限公司 | Cross-link method between block chains and main block chain |
| US10628454B2 (en) | 2018-03-13 | 2020-04-21 | Blockpoint Systems Inc. | Relational blockchain database |
| CN111901121B (en) | 2018-04-03 | 2023-09-29 | 创新先进技术有限公司 | Cross-blockchain authentication method and device and electronic equipment |
| US11030217B2 (en) | 2018-05-01 | 2021-06-08 | International Business Machines Corporation | Blockchain implementing cross-chain transactions |
| US11194837B2 (en) | 2018-05-01 | 2021-12-07 | International Business Machines Corporation | Blockchain implementing cross-chain transactions |
| JP7324222B2 (en) * | 2018-05-01 | 2023-08-09 | インターナショナル・ビジネス・マシーンズ・コーポレーション | Computing system, method and computer program for managing blockchain |
| CN108764875B (en) * | 2018-05-17 | 2021-07-06 | 深圳前海微众银行股份有限公司 | Block chain transfer method, device, system and computer readable storage medium |
| CN109035012B (en) * | 2018-06-11 | 2020-11-17 | 西安纸贵互联网科技有限公司 | Cross-chain processing method of block chain system and computer readable storage medium |
| CN109067832A (en) * | 2018-06-27 | 2018-12-21 | 南京百市通数字科技有限公司 | A kind of block chain transmission of transaction data method |
| CN109035016B (en) * | 2018-06-28 | 2020-10-23 | 杭州复杂美科技有限公司 | Multi-chain concurrent transaction method |
| CN109002527B (en) * | 2018-07-13 | 2020-12-01 | 江苏开放大学（江苏城市职业学院） | Block chain-based network examination system and method for managing network examination |
| CN108959621B (en) * | 2018-07-18 | 2020-06-05 | 百度在线网络技术（北京）有限公司 | Method, device, equipment and storage medium for realizing block chain network |
| CN110868441B (en) * | 2018-08-28 | 2021-03-16 | 傲为信息技术(江苏)有限公司 | Block chain public link maintenance method and device, node and block chain public link |
| WO2020042936A1 (en) * | 2018-08-28 | 2020-03-05 | 白杰 | Parallel chain-based cross-chain transaction method and apparatus, and block chain system |
| WO2020042931A1 (en) * | 2018-08-28 | 2020-03-05 | 白杰 | Public chain-based transaction method and blockchain system |
| WO2020042928A1 (en) * | 2018-08-28 | 2020-03-05 | 白杰 | Block chain network system |
| WO2020042934A1 (en) * | 2018-08-28 | 2020-03-05 | 白杰 | Non-repudiation cross-chain transaction method and blockchain system |
| CN109191298A (en) * | 2018-08-31 | 2019-01-11 | 深圳市有钱科技有限公司 | A kind of patent right transaction system |
| CN111183622B (en) * | 2018-08-31 | 2022-11-15 | 重庆小雨点小额贷款有限公司 | Block chain system, information sharing method and related equipment |
| CN109165945B (en) * | 2018-09-07 | 2021-04-16 | 腾讯科技（深圳）有限公司 | Representative node device election method and device, computer device and storage medium |
| CN109299338B (en) * | 2018-10-31 | 2019-08-06 | 山东云溪网络科技有限公司 | Transregional piece of chain data management system of one kind and method |
| ES2867423T3 (en) | 2018-11-07 | 2021-10-20 | Advanced New Technologies Co Ltd | Facilitate practical Byzantine fault tolerance blockchain consensus and node synchronization |
| CA3132083A1 (en) | 2019-03-01 | 2020-09-10 | Broadridge Fixed Income Liquidity Solutions, LLC | Computer platforms designed for improved electronic execution of electronic transactions and methods of use thereof |
| US20210182966A1 (en) | 2019-03-01 | 2021-06-17 | Broadridge Fixed Income Liquidity Solutions, LLC | Computer platforms configured to implement a specialized communication session protocol for electronic execution of electronic transactions and methods of use thereof |
| JP6880227B2 (en) | 2019-03-18 | 2021-06-02 | アドバンスド ニュー テクノロジーズ カンパニー リミテッド | Recovery of consensus system downtime |
| US10938750B2 (en) | 2019-03-18 | 2021-03-02 | Advanced New Technologies Co., Ltd. | Consensus system downtime recovery |
| AU2019203864B2 (en) | 2019-03-18 | 2021-01-21 | Advanced New Technologies Co., Ltd. | Consensus system downtime recovery |
| CN110033271B (en) * | 2019-03-22 | 2023-12-22 | 湖南天河国云科技有限公司 | Cross-chain transaction method, system and computer readable storage medium |
| US20200349564A1 (en) * | 2019-04-30 | 2020-11-05 | Salesforce.Com, Inc. | System and method of providing interoperable distributed and decentralized ledgers using consensus on consensus and delegated consensus |
| CN110288344A (en) * | 2019-06-25 | 2019-09-27 | 中国工商银行股份有限公司 | The assets transfer method and device of transregional piece of chain |
| EP3996028A4 (en) * | 2019-07-26 | 2022-08-31 | Huawei Technologies Co., Ltd. | Cross-chain transaction method and apparatus |
| US20220284011A1 (en) * | 2019-08-06 | 2022-09-08 | Zeu Technologies, Inc. | Distributed blockchain transaction system |
| CN110505091B (en) * | 2019-08-23 | 2021-09-10 | 昆明理工大学 | Improved consensus method based on PBFT |
| CN110727712B (en) * | 2019-10-15 | 2021-06-04 | 腾讯科技（深圳）有限公司 | Data processing method and device based on block chain network, electronic equipment and storage medium |
| CN113128998B (en) * | 2019-12-31 | 2024-04-12 | 航天信息股份有限公司 | Service processing method, device and system of block chain system |
| US11664973B2 (en) | 2020-04-21 | 2023-05-30 | International Business Machines Corporation | Trust-varied relationship between blockchain networks |
| CN111652617B (en) * | 2020-07-07 | 2023-09-22 | 中国银行股份有限公司 | Service processing system of cross-block chain platform |
| CN112202863B (en) * | 2020-09-24 | 2022-09-20 | 成都质数斯达克科技有限公司 | Data synchronization method and device, electronic equipment and readable storage medium |
| CN112491959B (en) * | 2020-10-28 | 2023-03-24 | 杭州趣链科技有限公司 | Cross-link resource exchange method, device and system based on relay link |
| CN112600874B (en) * | 2020-11-24 | 2023-03-31 | 成都质数斯达克科技有限公司 | Node joining method and device, electronic equipment and readable storage medium |
| US11943360B2 (en) * | 2021-06-22 | 2024-03-26 | International Business Machines Corporation | Generative cryptogram for blockchain data management |
| US11695573B2 (en) | 2021-07-23 | 2023-07-04 | International Business Machines Corporation | Blockchain controlled cross-domain data transfer |
| CN113987077B (en) * | 2021-12-23 | 2022-03-29 | 太极计算机股份有限公司 | Data sensing and cross-link scheduling method and device based on chain code mechanism |
| CN115632791B (en) * | 2022-10-12 | 2024-03-19 | 南京航空航天大学 | Dynamic cross-chain data consistency decentration verification method |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105488722A (en) * | 2015-11-30 | 2016-04-13 | 布比（北京）网络技术有限公司 | Asset data processing method and device based on derivation chain |
| CN106445711A (en) * | 2016-08-28 | 2017-02-22 | 杭州云象网络技术有限公司 | Byzantine-fault-tolerant consensus method applied to block chain |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US10475030B2 (en) * | 2016-02-22 | 2019-11-12 | Bank Of America Corporation | System for implementing a distributed ledger across multiple network nodes |
| US10157295B2 (en) * | 2016-10-07 | 2018-12-18 | Acronis International Gmbh | System and method for file authenticity certification using blockchain network |
| CN107248076A (en) * | 2017-06-24 | 2017-10-13 | 北京天德科技有限公司 | A kind of core algorithm of the double-chain block chain the Internet model merchandised across chain |
-
2017
- 2017-06-23 CN CN201710483789.4A patent/CN107301600B/en active Active
-
2018
- 2018-06-22 WO PCT/CA2018/000130 patent/WO2018232494A1/en active Application Filing
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105488722A (en) * | 2015-11-30 | 2016-04-13 | 布比（北京）网络技术有限公司 | Asset data processing method and device based on derivation chain |
| CN106445711A (en) * | 2016-08-28 | 2017-02-22 | 杭州云象网络技术有限公司 | Byzantine-fault-tolerant consensus method applied to block chain |
Non-Patent Citations (1)
| Title |
|---|
| 区块链技术的本质特征及在证券业的应用;孙国茂;《上海证券报》;20170208;第008版第1-6页 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN107301600A (en) | 2017-10-27 |
| WO2018232494A1 (en) | 2018-12-27 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN107301600B (en) | Core construction method of block chain Internet model for cross-chain transaction | |
| WO2018232493A1 (en) | A network of doubly-chained blockchains capable of cross-chain transactions | |
| CN111183445B (en) | Method and apparatus for digital asset auto-promise settlement | |
| Desai et al. | A hybrid blockchain architecture for privacy-enabled and accountable auctions | |
| US10832230B2 (en) | Scalable and distributed shared ledger transaction management | |
| US20190354518A1 (en) | Chain mesh network for decentralized transaction systems | |
| CN112541758A (en) | Multi-round voting type fault-tolerant sequencing consensus mechanism and method based on block chain | |
| US20220284011A1 (en) | Distributed blockchain transaction system | |
| CN110351133A (en) | Method and device for the host node hand-off process in block catenary system | |
| US11481771B2 (en) | One way functions in a resource transfer system | |
| CN111640017A (en) | Transaction correctness verification method and device applied to alliance chain cross-chain transfer | |
| US10607297B2 (en) | Scalable and distributed shared ledger transaction management | |
| CN110610421B (en) | Guarantee fund management method and device under fragment framework | |
| US11392944B2 (en) | Transfer costs in a resource transfer system | |
| CN110785782A (en) | Multi-round token distribution system and method using blockchain network | |
| GB2578168A (en) | Computer-implemented method and system for digital signing of transactions | |
| CA2999806A1 (en) | Temporary consensus networks in a resource transfer system | |
| JP2022544321A (en) | Method and system for decentralized transaction communication protocol | |
| CN114154969B (en) | Large-scale trading and settlement method based on block chain | |
| CN116415955A (en) | Cross-chain transaction method and system based on combination of hash locking and notary | |
| WO2022075046A1 (en) | Transaction system | |
| CN111598389B (en) | Transaction system for preventing bill market risk based on blockchain | |
| CN112235110B (en) | Cross-chain service processing method and device of block chain and electronic equipment | |
| CN112950180A (en) | Community certificate method and system based on alliance chain, electronic device and storage medium | |
| Ge et al. | Magma: Robust and flexible multi-party payment channel |
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 |