CN117911032A - Cross-chain transaction method for multi-chain parallel block chain system - Google Patents
Cross-chain transaction method for multi-chain parallel block chain system Download PDFInfo
- Publication number
- CN117911032A CN117911032A CN202410083742.9A CN202410083742A CN117911032A CN 117911032 A CN117911032 A CN 117911032A CN 202410083742 A CN202410083742 A CN 202410083742A CN 117911032 A CN117911032 A CN 117911032A
- Authority
- CN
- China
- Prior art keywords
- transaction
- block
- chain
- blockchain
- partition
- 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.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 25
- 238000005192 partition Methods 0.000 claims abstract description 82
- 238000012795 verification Methods 0.000 claims description 54
- 239000003999 initiator Substances 0.000 claims description 35
- 239000002243 precursor Substances 0.000 description 6
- 238000009792 diffusion process Methods 0.000 description 3
- 238000012545 processing Methods 0.000 description 3
- 238000003672 processing method Methods 0.000 description 3
- 238000012790 confirmation Methods 0.000 description 2
- LPLLVINFLBSFRP-UHFFFAOYSA-N 2-methylamino-1-phenylpropan-1-one Chemical compound CNC(C)C(=O)C1=CC=CC=C1 LPLLVINFLBSFRP-UHFFFAOYSA-N 0.000 description 1
- 241000132539 Cosmos Species 0.000 description 1
- 235000005956 Cosmos caudatus Nutrition 0.000 description 1
- 241000280258 Dyschoriste linearis Species 0.000 description 1
- 230000004075 alteration Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 230000001627 detrimental effect Effects 0.000 description 1
- 238000010586 diagram Methods 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 238000002955 isolation Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000000644 propagated effect Effects 0.000 description 1
- 238000004088 simulation Methods 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
Landscapes
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
The invention relates to the technical field of blockchains, in particular to a cross-chain transaction method for a multi-chain parallel blockchain system, which comprises the steps that in the multi-chain parallel blockchain system, each partition randomly and unbiasedly selects a main node, the main node and a chain link point in the partition jointly maintain a blockchain, each blockchain adopts different consensus algorithms to carry out cross-chain transaction, and when the chain link point in one partition encapsulates transaction information into a block, and the block is forwarded to other partitions for transaction through the main node; aiming at the problem of interconnection and intercommunication among different block chains, the method solves the problem of interoperability faced by the block chain technology, and uses the master node to coordinate inter-chain transactions, thereby ensuring the consistency and the safety of inter-chain transactions of different block chains.
Description
Technical Field
The invention relates to the technical field of blockchains, in particular to a cross-chain transaction method for a multi-chain parallel blockchain system.
Background
The lack of interoperability between the various blockchains currently prevents blockchain-based applications from efficiently exchanging data and value, resulting in isolation from each other, defeating the purpose of sharing. Aiming at the problem of interconnection and interworking among different blockchains, a blockchain interoperation scheme is proposed, and a series of interconnection and interworking schemes are covered, and the scheme can be mainly divided into three types, namely a centralized or multistage notary scheme, hash locking (HTLC) and side chain technology. However, they still have some limitations.
As shown in table 1, the notary scheme relies on trusted intermediaries, destroying the blockchain decentralization and untrusted nature. HTLCs rely on functional support of smart contracts with poor compatibility and applicability. Cosmos and Polkadot require trust of the special blockchain as side chains, which would be detrimental to the decentralized nature of blockchains, and in addition, these interoperability-based blockchains ignore cross-chain transaction inconsistencies resulting from double-flower attacks, posing a threat to the security of cross-chain transactions.
Table 1 interoperability-based blockchain overview
Disclosure of Invention
In order to ensure consistency and safety of cross-chain transactions of different blockchains, the invention provides a cross-chain transaction method for a multi-chain parallel blockchain system, in the multi-chain parallel blockchain system, each partition randomly and unbiasedly selects a main node, the main node and a chain link point in the partition jointly maintain a blockchain, each blockchain adopts different consensus algorithms, and the cross-chain transaction of the chain link point in the partition comprises the following procedures:
The nth link point In the z-th blockchain wants to initiate a cross-chain transaction to the nth link point In the y-th blockchain, then the nth link point In the z-th partition initiates a transaction tr= { In, out i, out.r };
Transaction tr= { In, out.i, out r } is encapsulated into one block B zi and broadcast In the z-th blockchain;
after the chain node and the block chain master node receive the block, verifying the validity of the newly generated block, and then performing block verification of the chain node;
After the verification of the chain node block is passed, the block is diffused to the main node of the z-th partition, the main node in the z-th partition performs main node block verification on the block, and after the verification is passed, the block is diffused to other main nodes;
After other master nodes receive the block B zi issued to the block chain, carrying out chain link point block verification and master node block verification on the block B zi, and after the block B and the master node block verification pass the verification, executing In and out.i In the transaction by the master node and the chain link point;
the main node transmits the cross-link transaction information to other main nodes, and when the main nodes with set threshold number pass verification, the y-th partition generates a block B yh according to the transaction;
Verifying the block B yh by the chain link point of the y-th partition, and executing out r by the main node and the chain link point of the y-th partition after verification and after the block B yh is confirmed as the block of the main chain in the y-th partition;
the main node of the y-th partition updates the account book according to the result of executing out.
Wherein tr initiates a transaction for the nth chain node in the z-th partition; in is an unexpanded transaction output of the transaction initiator; out.i is the remaining amount of the transaction initiator after an unexpired transaction is paid to the transaction recipient; out.r is the amount that the transaction initiator needs to pay to the transaction receiver; in particular, the concepts of "In" and "Out" are ubiquitous, whether using an account model or a UTXO model, taking the UTXO model as an example, in is a reference to a previously unexpired transaction output of a transaction initiator, out representing the output portion of a transaction, which is considered "spent" when a transaction output is referenced by another transaction's input and a spending condition is satisfied.
Further, verifying the validity of the newly generated block, i.e. verifying the validity of the transaction tr= { In, out.i, out.r }, if the transaction tr= { In, out.i, out.r } is encapsulated into a block B ij, the verification of the validity specifically includes the following steps:
judging whether the blockchain where the out.i is located is from the same partition as HASHINTRA of the block B ij, if so, verifying that the block B ij can execute In and out.i In the transaction;
it is determined if the blockchain in which out.r is located is from the same partition as HASHINTRA of block B ij, if so, then by verification, block B ij can execute out r in the transaction.
Further, the link point block verification and the master node block verification, namely verifying whether HASHINTRA of a block in a partition is consistent with the hash of the linked previous block in the partition where the link node and the master node are located, if so, the verification is passed.
Further, the process of determining that the master node and the link point are capable of executing the transaction includes:
Judging whether the blockchain maintained by the partition where the current node is located is the same blockchain as the blockchain of the out.i In the transaction, if so, executing the In and the out.i In the transaction;
and judging whether the blockchain maintained by the partition where the current node is located is the same blockchain as the blockchain of Out.r in the transaction, and if so, executing Out.r in the transaction.
Further, if a link point In one partition trades with a link point In the same partition, transaction tr= { In, out.i, out r } of the trade is encapsulated into one block, and the transactions In the block can be executed at the same time.
Further, the executing process of the transaction comprises the following steps:
executing In a transaction, i.e., the system references an unexpired transaction of the transaction initiator, an output of a transaction is considered "spent" when it is referenced by the input of another transaction and the cost condition is met;
Out.i in executing transaction, namely the system transmits the rest amount after deducting the amount required to be paid to the transaction receiver from one un-spent transaction amount of the transaction initiator to the transaction initiator;
Out.r in the execution transaction, i.e. the system sends to the transaction recipient the amount that the transaction initiator needs to pay to the transaction recipient.
Further, when the transaction tr= { In, out.i, out.r } is encapsulated into one block B zi, the block B zi selects one block from the partitions where the transaction initiator is located as a link, and randomly selects the head block from other partitions as a link.
The invention provides a multi-chain collaborative cross-chain transaction processing method, which aims at the problem of interconnection and intercommunication among different blockchains, solves the problem of interoperability, avoids the problem of data island, ensures that data among blockchains are interacted, and ensures the consistency and the safety of cross-chain transactions.
Drawings
FIG. 1 is a schematic diagram of a cross-chain transaction method model for a multi-chain parallel blockchain system in accordance with the present invention;
FIG. 2 is a flow chart of a cross-chain transaction method for a multi-chain parallel blockchain system in accordance with the present invention.
Detailed Description
The following description of the embodiments of the present invention will be made clearly and completely with reference to the accompanying drawings, in which it is apparent that the embodiments described are only some embodiments of the present invention, but not all embodiments. All other embodiments, which can be made by those skilled in the art based on the embodiments of the invention without making any inventive effort, are intended to be within the scope of the invention.
The invention provides a cross-chain transaction method for a multi-chain parallel blockchain system, in the multi-chain parallel blockchain system, each partition randomly and unbiasedly selects a main node, the main node and a chain link point in the partition jointly maintain a blockchain, each blockchain adopts different consensus algorithms, and the chain link point in one partition performs the cross-chain transaction, which comprises the following processes:
The nth link point In the z-th blockchain wants to initiate a cross-chain transaction to the nth link point In the y-th blockchain, then the nth link point In the z-th partition initiates a transaction tr= { In, out i, out.r };
Transaction tr= { In, out.i, out r } is encapsulated into one block B zi and broadcast In the z-th blockchain;
after the chain node and the block chain master node receive the block, verifying the validity of the newly generated block, and then performing block verification of the chain node;
After the verification of the chain node block is passed, the block is diffused to the main node of the z-th partition, the main node in the z-th partition performs main node block verification on the block, and after the verification is passed, the block is diffused to other main nodes;
After other master nodes receive the block B zi issued to the block chain, carrying out chain link point block verification and master node block verification on the block B zi, and after the block B and the master node block verification pass the verification, executing In and out.i In the transaction by the master node and the chain link point;
the main node transmits the cross-link transaction information to other main nodes, and when the main nodes with set threshold number pass verification, the y-th partition generates a block B yh according to the transaction;
Verifying the block B yh by the chain link point of the y-th partition, and executing out r by the main node and the chain link point of the y-th partition after verification and after the block B yh is confirmed as the block of the main chain in the y-th partition;
the main node of the y-th partition updates the account book according to the result of executing out.
Wherein tr initiates a transaction for the nth chain node in the z-th partition; in is an unexpanded transaction output of the transaction initiator; out.i is the remaining amount of the transaction initiator after an unexpired transaction is paid to the transaction recipient; out.r is the amount that the transaction initiator needs to pay to the transaction recipient.
Aiming at the problem of interoperability of the blockchain technology, the invention provides a multi-chain collaborative cross-chain transaction processing method, which aims to solve the problem of interconnection and interworking among different blockchains in the blockchain technology application and ensure the safety of cross-chain interaction while improving the operability. The invention is based on the block chain technology, and realizes the following purposes:
1. An innovative multi-chain collaborative cross-chain transaction processing method is provided, single-chain consensus logic is modified, and the problem of interoperability faced by a block chain technology is solved aiming at the problem of interconnection and interworking among different block chains;
2. And the coordination of the inter-chain transactions is carried out by using the master node, so that the consistency and the safety of the inter-chain transactions of different blockchains are ensured.
Distributed Ledgers (DL) typically achieve balance in two ways: one is an account-based model in which funds are directly associated with a user account, such as an ethernet; and the other is an unexpired transaction export (UTXO) model in which UTXOs correspond to inputs and the user has an export key, using the account model including IOTA coins. Based on the nature of the UTXO model, it is not necessary for many scenarios to fully order transactions, as most of them are processable in parallel.
In the present invention, link points CM i＝{CMij∣1≤j≤Zi represents the set of chain nodes that are part of blockchain #i, where Z i is the size of CM i, where i ε N, CM ij represents the jth link point in blockchain #i, N is the number of link points in blockchain #i, which maintain their single chain blockchain ledger.
In this embodiment, after the user initiates the transaction, the link points receive the message, and in the system there are in-chain transactions (txIntra) and inter-chain transactions (txInter). Each transaction can be summarized as having two types of operations, input (In for transaction representing payment amount) and Output (Out for transaction representing charge amount), whatever transaction model is employed, transaction processing can be interpreted from the logical dependencies of Input and Output, out.i being the Output of the transaction initiator, and out.r being the Output of the transaction recipient. The input-output dependencies of txIntra and txInter are different due to the different blockchains to which the transaction initiator and recipient belong, resulting in different transaction processing for the system.
For txIntra, ledger status updates for the transaction initiator and recipient are recorded in the same ledger because they belong to the same blockchain. In fig. 1, the In, out.i, out r operations of txIntra In the block encapsulated by the transaction may be performed simultaneously when the initiator CM zn (link point #n In blockchain #z) and the receiver M zm (link point #m In blockchain #z) of the transaction are In the same blockchain.
For txInter, cross-chain transactions, its transaction initiator is in blockchain #z and the recipient of the transaction is in blockchain #y. In order to ensure the consistency of transactions in different blockchains, each partition randomly and unbiasedly selects a master node as a leader, and is responsible for coordinating the execution sequence of cross-chain transactions and HASHINTER and HASHINTRA selected during block generation, the master nodes in each blockchain can communicate with each other, and a blockchain ledger is commonly maintained. The cross-chain transaction processing flow comprises the following steps:
① After the link point initiates the transaction and the new block of the package is determined to be a single-chain block, updating the account book of all the chain nodes, namely executing the effective transaction.
The initiator of the transaction, M zn (chain link point #n In blockchain #z), issues the inter-blockchain transaction tr= { In, out.i, out r } In the current blockchain #z, and the transaction is first encapsulated In block B zi and then generated In the current blockchain #z.
In addition to verifying the authenticity and validity of the transaction by verifying the digital signature of the transaction, the generated block needs to be subjected to block verification of the chain node, so as to ensure that the block meets the requirements of updating the ledger, for example, verifying whether the information in the block B zi, such as the verification block B zi, such as zoneIntra, meets the requirements of the current blockchain #z, and if the verification is passed, the block B zi is determined to be the block of the blockchain #z main chain.
The link node can obtain the Tip recommended by the master node through the master node, update the blockchain #z according to the Tip, if the latest generated block B zi and the recommended Tip are in a link, the new Tip is determined by a consensus algorithm of the blockchain #z, the Tip refers to a precursor block of the generated block link, the hash value of the precursor block linked with the precursor block is compared with the value of HASHINTRA stored in the current block, the block is verified, if the comparison result is consistent, the verification is passed, otherwise, the verification cannot be passed.
The ledger state of the nth node CM zn of the z-th partition is effectively transacted, updated in all local ledgers of the master node DM z of the z-th partition, where zone_number () is an operation performed to obtain the partition to which the block link point belongs.
② After verification, block B zi performs the execution of the valid transaction.
Block B zi is diffused to other master nodes in other blockchains through the master node of the blockchain #z, the master node of the blockchain #z needs to perform block verification of the chain node and block verification of the master node, the block verification of the master node needs to ensure that no block in the block and the ancestor block thereof have different forking conditions in HASHINTER selection, after verification, the master node of the blockchain #z needs to determine the main chain and the Tip of the main chain according to the main chain weight of the block, perform effective transaction execution, execute Out.i in tr and update the account book of the chain node.
In this embodiment, in the process of generating a block containing the transaction tr= { In, out.i, out.r }, one precursor node In the blockchain where the node capable of executing the transaction out.i is located is required to be linked with one precursor node In the blockchain where the node capable of executing the transaction out.i is located, and one precursor node In the blockchain where the node capable of executing the transaction out.r is located
③ The inter-blockchain transaction is forwarded to the blockchain #y by the master node of the blockchain #z where the link point of the transaction receiver is located, then is packaged into the block B yh in the blockchain #y, and is updated after being determined as the partition main chain, namely the execution of the effective transaction.
After the cross-chain transaction is forwarded to the blockchain #y by the master node of the blockchain #z where the link point of the transaction receiver is located, the cross-chain transaction information is encapsulated in the block B yh, when the block B yh is determined to be the block of the main chain of the blockchain #y, the block of the main chain of the block chain #y is confirmed to be the block of the main chain of the block chain #y, the link point in the partition #y needs to be verified, then all the master nodes are verified, and after two times of verification, the out. R in the transaction is executed in the block chain #y.
④ After block B yh is identified as the block of the backbone, execution of the valid transaction is performed.
When block B yh is diffused through the master node to other master nodes, the out.r of tr is not performed at the master node until block B yh is determined to be a block on the backbone; as with block B zi, block B yh also requires transaction verification and block verification to determine the block as the blockchain #y backbone, and out.r of tr will be performed at the master node of blockchain #y, in which step tr is not completed until now, although it is allowed to perform part of tr first.
The present embodiment also provides a specific process of cross-chain transactions in one specific embodiment, as in fig. 1, comprising:
① The inter-blockchain transaction initiated by the chain node CM 11 is encapsulated in block B 12, generated at blockchain # 1.
With node CM 21 as the transaction receiver, the transaction tr= { In, out.i, out.r } initiated by node CM 12 propagates In blockchain #1, where the recipients of out.i, out.r In the transaction are node CM 12 and node CM 21, respectively; transaction tr is then encapsulated in block B 12. After block B 12 is propagated and determined to be a block of the blockchain #1 backbone, the ledger state of node CM 12 is updated in all local ledgers of master node DM 1 according to the active transaction execution algorithm.
② Block B 12 forwards the diffusion to other blockchain master nodes through the master node DM 1 of blockchain # 1.
Once block B 12 propagates to the blockchain #1 master node and other master nodes, after block B 12 is determined to be a block on the master node's backbone, operating according to a valid transaction execution algorithm; since the blockchain to which out.i belongs is blockchain #1, in and out.i In tr will be executed In the master node and update the ledger maintained by the master node, since the ledger states of node CM 12 and node CM 21 are recorded In the respective ledgers.
③ The inter-blockchain transaction (txInter) is forwarded by the blockchain #1 master node to blockchain #2 and then encapsulated into blockb 21 generated by blockchain # 2.
Transaction information will be encapsulated in block B 21, block B 21 is generated in blockchain #2, and after block B 21 is determined to be a block of the blockchain #2 ledger backbone, out r of tr will be performed at DM 2.
④ Block B 21 forwards the diffusion to other blockchain master nodes through the master node of blockchain # 1.
When block B 21 forwards the diffusion to other blockchain master nodes through the master node of blockchain #1, the out.r of tr will not be executed at the master node until the master node determines that block B 21 is the master, and the execution of out r of tr and the master node ledger update will not be performed until the master node confirms that block B 21 is a block on the master, nor will it complete the execution of this transaction.
In this embodiment, the process of determining whether a transaction is valid, the valid transaction execution algorithm includes:
Judging whether the blockchain maintained by the partition where the current node is located is the same blockchain as the blockchain of the out.i In the transaction, if so, executing the In and the out.i In the transaction;
and judging whether the blockchain maintained by the partition where the current node is located is the same blockchain as the blockchain of Out.r in the transaction, and if so, executing Out.r in the transaction.
After judging that the transaction is valid, executing the valid transaction, wherein the executing part comprises:
executing In a transaction, i.e., the system references an unexpired transaction of the transaction initiator, an output of a transaction is considered "spent" when it is referenced by the input of another transaction and the cost condition is met;
Out.i in executing transaction, namely the system transmits the rest amount after deducting the amount required to be paid to the transaction receiver from one un-spent transaction amount of the transaction initiator to the transaction initiator;
Out.r in the execution transaction, i.e. the system sends to the transaction recipient the amount that the transaction initiator needs to pay to the transaction recipient.
Fig. 2 shows a transaction flow based on the present invention, in which all computing nodes form a two-layer framework, the first layer is formed by nodes of each partition, each partition can adopt different consensus algorithms, a node is randomly selected from each partition as a main node of the current partition, the second layer is formed by the main nodes of each partition, and the transaction process includes the following steps:
The transaction initiator initiates a transaction, and the initiated transaction is divided into txIntra and txInter according to whether the transaction initiator and the transaction receiver are in the same partition;
If the transaction initiator and the transaction receiver are In the same partition, the transaction is divided into txIntra, and In, out.i and out.r In the transaction are executed simultaneously;
If the transaction initiator and the transaction receiver are not in the same partition, the transaction is divided into txInter, after the partition where the initiator is located is packaged into a block, the block performs verification of a chain node in the current partition, and after the block is confirmed to be the block of the block chain main chain of the current partition, the block is spread to a second layer through a main node;
the second layer is composed of all partitioned master nodes, the master nodes verify, and after the block passes the verification and is confirmed as the block of the current block chain main chain, corresponding In and out.i are executed In the chain link points and the master nodes;
Each master node encapsulates the transaction authenticated by the master node into a block and then distributes the block into the corresponding partition block chain, each partition authenticates the block and confirms the main chain (namely, confirms whether the block is the block on the main chain of the current block chain), when the block of the transaction receiver is encapsulated into the block, the transaction receiver performs authentication and main chain confirmation again, after confirmation, the block is spread to a second layer, after master node authentication, if the block is confirmed to be the main chain block, the out. R is executed at the chain link point and the master node.
In order to verify the design of the invention, an actual system is realized by using c++, malicious nodes are simulated in an actual environment to evaluate the consistency of different blockchain transactions, the safety of the invention is demonstrated based on the angle of simulation experiments, and the consistency of transaction execution can be ensured by the invention when the cross-chain transactions are carried out among different blockchains, which comprises the following steps:
setting n independent single chains in a block chain system, adding malicious nodes into the block chain#, and firstly synchronizing the malicious nodes with the whole block chain network to acquire data;
The malicious node starts to construct a private bifurcation to try to tamper with the main chain content, and closes the normal node to simulate 51% attack, when the computing power of the malicious node exceeds that of the normal node, the private bifurcation is continuously increased;
when the malicious node builds the bifurcation with the length exceeding the original blockchain, the normal node is started, and when the malicious node joins the partition to try to tamper with the main chain of the partition #1, the block generated by the malicious node can be judged to be an illegal block through block verification, and the malicious node synchronizes the account book of the normal node through account book synchronization, so that the malicious node attack failure can be realized, and the consistency of transactions of different blockchains is ensured.
Although embodiments of the present invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made therein without departing from the principles and spirit of the invention, the scope of which is defined in the appended claims and their equivalents.
Claims (7)
1. A cross-chain transaction method for a multi-chain parallel blockchain system is characterized in that in the multi-chain parallel blockchain system, each partition randomly and unbiased selects a main node, the main node and a chain link point in the partition jointly maintain a blockchain, each blockchain adopts different consensus algorithms, and the chain link point in one partition performs cross-chain transaction, which comprises the following procedures:
The nth link point In the z-th blockchain wants to initiate a cross-chain transaction to the nth link point In the y-th blockchain, then the nth link point In the z-th partition initiates a transaction tr= { In, out i, out.r };
Transaction tr= { In, out.i, out r } is encapsulated into one block B zi and broadcast In the z-th blockchain;
after the chain node and the block chain master node receive the block, verifying the validity of the newly generated block, and then performing block verification of the chain node;
After the verification of the chain node block is passed, the block is diffused to the main node of the z-th partition, the main node in the z-th partition performs main node block verification on the block, and after the verification is passed, the block is diffused to other main nodes;
After other master nodes receive the block B zi issued to the block chain, carrying out chain link point block verification and master node block verification on the block B zi, and after the block B and the master node block verification pass the verification, executing In and out.i In the transaction by the master node and the chain link point;
the main node forwards the cross-chain transaction information to the y-th partition, and generates a block B yh according to the transaction, wherein the block passes verification;
After block B yh is identified as the block of the main chain in the y-th partition, the main node of the y-th partition executes Out r;
the main node of the y-th partition updates the account book according to the result of executing out.
Wherein tr initiates a transaction for the nth chain node in the z-th partition; in is a reference to the transaction output of the transaction initiator that was not previously spent; out.i is the remaining amount of the transaction initiator after an unexpired transaction is paid to the transaction recipient; out.r is the amount that the transaction initiator needs to pay to the transaction recipient.
2. The method according to claim 1, wherein verifying the validity of the newly generated block, i.e. verifying the validity of the transaction tr= { In, out.i, out.r }, if the transaction tr= { In, out.i, out.r } is encapsulated In a block B ij, the verification of the validity specifically comprises the following steps:
judging whether the blockchain where the out.i is located is from the same partition as HASHINTRA of the block B ij, if so, verifying that the block B ij can execute In and out.i In the transaction;
it is determined if the blockchain in which out.r is located is from the same partition as HASHINTRA of block B ij, if so, then by verification, block B ij can execute out r in the transaction.
3. The method of claim 1, wherein the link point block verification and master node block verification are performed by verifying whether HASHINTRA of a block in a partition matches a hash of a linked previous block in the partition where the link node and master node are located, and if so, by verifying.
4. The method of claim 1, wherein determining that the master node and the link point are capable of performing transactions comprises:
Judging whether the blockchain maintained by the partition where the current node is located is the same blockchain as the blockchain of the out.i In the transaction, if so, executing the In and the out.i In the transaction;
and judging whether the blockchain maintained by the partition where the current node is located is the same blockchain as the blockchain of Out.r in the transaction, and if so, executing Out.r in the transaction.
5. The method of claim 1, wherein if a link point In a partition trades with a link point In the same partition, the traded transaction tr= { In, out.i, out.r } is encapsulated into a block, and the transactions In the block can be executed simultaneously.
6. The method of claim 1, wherein the performing of the transaction comprises:
executing In the transaction, namely deducting an unexpired transaction amount of the transaction initiator by the system;
Out.i in executing transaction, namely the system transmits the rest amount after deducting the amount required to be paid to the transaction receiver from one un-spent transaction amount of the transaction initiator to the transaction initiator;
Out.r in the execution transaction, i.e. the system sends to the transaction recipient the amount that the transaction initiator needs to pay to the transaction recipient.
7. The method of claim 1, wherein when the transaction tr= { In, out.i, out.r } is encapsulated into a block B zi, the block B zi selects one block from the partitions where the transaction initiator is located as a link, and randomly selects the head blocks of other partitions as links.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202410083742.9A CN117911032A (en) | 2024-01-19 | 2024-01-19 | Cross-chain transaction method for multi-chain parallel block chain system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202410083742.9A CN117911032A (en) | 2024-01-19 | 2024-01-19 | Cross-chain transaction method for multi-chain parallel block chain system |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN117911032A true CN117911032A (en) | 2024-04-19 |
Family
ID=90681719
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202410083742.9A Pending CN117911032A (en) | 2024-01-19 | 2024-01-19 | Cross-chain transaction method for multi-chain parallel block chain system |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN117911032A (en) |
-
2024
- 2024-01-19 CN CN202410083742.9A patent/CN117911032A/en active Pending
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN107038639B (en) | Alliance chain construction method compatible with multi-asset type rapid transaction | |
| CN109493050B (en) | Transfer method based on block chain main chain and parallel multiple sub-chains | |
| CN111629039B (en) | Block chain consensus method, client, endorsement node and sequencing node | |
| CN110580653B (en) | Block chain consensus mechanism based on transaction | |
| CN108830602B (en) | Permission chain construction and management and control method based on chameleon hash function | |
| CN109840767B (en) | Multi-party fair contract evidence storing method and system based on block chain technology | |
| CN112583917B (en) | CSCP-based hybrid chain construction method | |
| WO2019109003A1 (en) | Blockchain system for confidential and anonymous smart contracts | |
| JP2021507564A (en) | Computer-implemented systems and methods for allowing blockchain transactions with low entropy passwords | |
| CN112615915B (en) | Method for constructing alliance chain between private chains | |
| CN112507393B (en) | Method for guaranteeing consistency of block chain cross-chain transaction | |
| CN109347651B (en) | MSVL (modeling, simulation and verification language) -based block chain system modeling and security verification method and system | |
| CN110084596B (en) | Method and device for processing block chain mixed consensus | |
| Asfia et al. | Energy trading of electric vehicles using blockchain and smart contracts | |
| CN112163950A (en) | Block chain network construction method and system convenient for expansion and node resource reuse and terminal equipment | |
| CN110785782A (en) | Multi-round token distribution system and method using blockchain network | |
| CN109743182B (en) | Intelligent contract approval method and system based on block chain | |
| CN113407977B (en) | Cross-chain extension method and system based on aggregated signature | |
| CN109447602A (en) | A kind of mixed coin method of the collaborative distributed digital cash of multicenter that protecting privacy | |
| CN111464310B (en) | Method for realizing mixed chain of alliance chain and Polkadat chain | |
| Sliwinski et al. | Abc: Proof-of-stake without consensus | |
| CN111046439A (en) | Intelligent contract task verifiable method and system based on block chain | |
| CN112488683A (en) | Method and device for offline transaction of block chain | |
| CN112583598A (en) | Complex Internet of things alliance chain system communication mechanism | |
| CN111815329A (en) | Method for realizing high-performance block chain network based on cross-chain technology |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination |