[0041] Example 1
[0042] This embodiment provides a cross-chain transaction system and method for alliance blockchain. The research object of this embodiment is two consortium blockchains: the first consortium chain (CB 1 ), the second consortium chain (CB 2 ). This example will give CB 1 ,CB 2 Active cross-chain transaction method between. Cross-chain transactions refer to users making transactions between two blockchains, that is, assets in CB 1 ,CB 2 The process of transferring back and forth between. At present, most cross-chain transaction implementation methods are to destroy the corresponding assets on the first blockchain, and create/release the corresponding assets on the second blockchain, and this can be regarded as a special amount on the blockchain. transaction.
[0043] Such as figure 1 As shown, the main technical idea provided by this embodiment is: when a transaction Tx occurs on the first alliance chain 1 At the time, the first consortium chain needs to provide evidence that the transaction has occurred to the second consortium chain, and the second consortium chain needs to Tx this transaction 1 Verification is performed to keep the information of the two chains synchronized, which is the cross-chain interaction process of the alliance chain.
[0044] Then, in the cross-chain process, any blockchain must have the ability to provide evidence to other chains and have the ability to verify transactions on other blockchains. If in actual application, each blockchain stores evidence from other chains and sets up verification of other chains, the complexity is extremely high. Therefore, in this embodiment, we provide a cross-chain transaction system and method for the alliance blockchain by designing the cross-chain medium and the alliance chain cross-chain processor.
[0045] The following is a detailed description of cross-chain media, alliance chain cross-chain processors, specific method principles and implementation examples.
[0046] 1. Cross-chain media
[0047] This embodiment proposes a cross-chain medium alternative pool. The cross-chain medium is similar to the role of a miner in a Bitcoin mining pool, but the cross-chain medium is used to assist users on two consortium chains to conduct cross-chain transactions. The cross-chain media is randomly elected by nodes that are willing to act as cross-chain intermediaries and have accounts on both chains and enter a candidate pool after paying a certain deposit. Cross-chain media can initiate a transaction on any party's blockchain. In order to encourage nodes to elect cross-chain media and promote the completion of cross-chain transactions, cross-chain media has a special reward and punishment mechanism: for each successful completion of a cross-chain order, the cross-chain media can earn a service fee of 5% of the order amount; at the same time, once found The cross-chain media violates regulations and disrupts the normal conduct of cross-chain transactions. All deposits paid by the node will be immediately deducted and the election ability will be permanently cancelled.
[0048] 2. Consortium chain cross-chain processor
[0049] Cross-Consortium-Blockchain-Processor (Cross-Consortium-Blockchain-Processor) hereinafter referred to as CCBP, can read the content on the blockchain through the specific smart contract interface of the alliance chain, and has the ability to verify the transaction data on the chain.
[0050] Such as figure 2 As shown, the principle of CCBP is that when the first consortium chain and the second consortium chain establish a cross-chain channel, the first consortium chain only needs to open the smart contract interface to input evidence of on-chain transactions to CCBP, and CCBP conducts self-checking through the verification module. Verification: After judging the validity of the transaction, the proof is output to the second consortium chain through the forwarding module, and the second consortium chain receives and judges it through the smart contract interface. In this way, the validity proof of the cross-chain transaction can be completed.
[0051] The alliance chain cross-chain processor includes a transaction input module, a transaction verification module and a result output module, which are described in detail below.
[0052] 2.1. Transaction input module
[0053] The alliance chain provides CCBP with an existing transaction and other related evidence through the open smart contract interface, and enters the transaction verification module through the transaction input module.
[0054] 2.2, transaction verification module
[0055] CCBP performs transaction existence verification. The principle is to perform Merkel tree proof based on the data on the transaction source blockchain. When the verification result is passed, the signature function Sign(TX x , SK CCP ) Generate the signature σ, and use the proof function Prove(TX x ,Σ) Generate evidence π; when the verification result is not passed, the cross-chain transaction request is rejected and the verification failed result is returned.
[0056] 2.3. Result output module
[0057] The result output module of CCBP forwards the processing result of the transaction verification module to the smart contract interface of the opponent alliance chain, and the smart contract on the opponent alliance chain performs further processing according to the returned result.
[0058] Three, the specific method principle
[0059] The following is a detailed description of the specific terms and symbols, the cross-chain transaction system, assumptions and instructions, and the specific steps of the cross-chain transaction method.
[0060] 3.1. Explanation of proper nouns and symbols
[0061] The following is an explanation and explanation of the proper nouns and symbols used below.
[0062] 1.1) The sending chain of cross-consortium chain transactions is called the first consortium chain, denoted as (CB 1 ), the digital asset-points on it are recorded as (credit 1 ); unit c 1; The receiving chain of cross-consortium chain transactions is called the second consortium chain, denoted as (CB 2 ), the digital asset-points on it are recorded as (credit 2 ), unit c 2;
[0063] 1.2) The third-party nodes that have accounts on the first consortium chain and the second consortium chain are called cross-chain media, denoted as (M);
[0064] 1.3) The address (public key) of the cross-chain medium on the first consortium chain is The address (public key) of the cross-chain medium on the second consortium chain is
[0065] 1.4) In this embodiment, a consortium chain cross-chain processor is designed for the exclusive development of consortium chain cross-chain, denoted as (CCBP); the public key (address) of CCBP is denoted as PK CCP , CCBP’s private key is marked as SK CCP;
[0066] 1.5) In the cross-chain transaction example described in this embodiment, the transaction initiator participating in a cross-chain transaction is called the user (A), and the transaction receiver is called the merchant (B);
[0067] 1.6) User A's address (public key) on the first consortium chain is Merchant B's address (public key) on the second consortium chain is
[0068] 1.7) In this embodiment, transactions that occur on the first alliance chain are recorded as TX CB1; Transactions that occur on the second consortium chain are recorded as TX CB2; Transactions that occur between the first alliance chain and the second alliance chain are recorded as cross-chain transactions, and when the funds flow from the first alliance chain to the second alliance chain, it is recorded as TX CB1→CB2;
[0069] 1.8) In this embodiment, a certain block on the first blockchain is marked as B CB1; A certain block on the second blockchain is marked as B CB2;
[0070] 1.9) In this embodiment, the points locked by user A on the first alliance chain are recorded as credit CB1; The points accepted by merchant B on the second alliance chain are recorded as credit CB2.
[0071] 3.2, cross-chain transaction system
[0072] The cross-chain transaction system for the alliance blockchain proposed in this embodiment includes a cross-chain medium candidate pool and a alliance chain cross-chain processor, and the cross-chain medium candidate pool includes multiple candidate nodes;
[0073] The cross-chain media candidate pool is configured to receive cross-chain transaction requests and select a candidate node as the cross-chain media node M;
[0074] The cross-chain media node M is configured to conduct buyer alliance chain transactions and seller alliance chain transactions respectively. Seller alliance chain transactions occur before buyer alliance chain transactions, and both buyer alliance chain transactions and seller alliance chain transactions are generated based on cross-chain transaction requests;
[0075] The alliance chain cross-chain processor is configured to receive and verify the buyer's alliance chain transaction information; receive and verify the seller's alliance chain transaction information, and then generate signatures and evidence. The alliance chain cross-chain processor uses the Merkel proof principle to generate evidence.
[0076] The cross-chain intermediary node M is also configured to, after receiving the cross-chain transaction request, also announce the intermediary signature to the entire network. The intermediary signature is generated by digitally signing the cross-chain transaction request by the private key of the inter-chain intermediary node M.
[0077] The cross-chain transaction system also includes buyer alliance chain nodes and seller alliance chain nodes,
[0078] The buyer consortium chain node is configured to generate a cross-chain transaction request, and publicize the cross-chain transaction request in the entire network; receive and verify the signature and evidence, and when the verification is successful, conduct a buyer consortium chain transaction with the cross-chain media node M;
[0079] The seller alliance chain node is configured to conduct seller alliance chain transactions with the cross-chain media node M;
[0080] Both the buyer's alliance chain node and the seller's alliance chain node are based on smart contract alliance chain nodes. In this embodiment, the buyer consortium chain node connects to user A and generates a first consortium chain CB1, and the seller consortium chain node connects to merchant B and generates a second consortium chain CB2.
[0081] The cross-chain transaction system also includes a supervision structure node, which is used to perform behavior inspection on the cross-chain media node in the cross-chain media candidate pool.
[0082] 3.2. Assumptions and explanations
[0083] In order to better illustrate the subsequent cross-chain examples of alliance chains, this embodiment provides the following descriptions and assumptions:
[0084] 2.1) Based on the characteristics of automatic execution of smart contracts, it is assumed that once a user initiates a transaction, it is irrevocable;
[0085] 2.2) The exchange ratio of credit1 on the first consortium chain CB1 and credit2 on the second consortium chain CB2 is 2:1;
[0086] 2.3) The order information contained in a cross-chain transaction request (Request) is: Buyer address Addr 1 , The seller's address Addr 2 , Point transaction amount Amount (converted by points on the alliance chain where the buyer is located), Order tip Order_tips; expressed as: Request = {Addr, Addr 2 , Amount, Order_tips};
[0087] 2.4) After accepting a cross-chain order, the cross-chain media should announce it to the entire network and use its own private key S k Digitally sign the cross-chain transaction request body Request; expressed as: Sig={S k (Request)};
[0088] 2.5) A cross-chain transaction CCTX 1→2 The information included is: Buyer Address Addr 1 , The seller's address Addr 2 , The cross-chain media address Addr 3 , The buyer pays points credit 1 , The seller receives credit 2 , Order tip Order_tips; expressed as: CCTX 1→2 = {Addr, Addr 2 , Addr 3 , Credit 1 , Credit 2 , Order_tips}, where credit 1 ={n*credit 2 +Order_tips};
[0089] 3.3, the specific steps of the cross-chain transaction method
[0090] Such as image 3 As shown, the specific steps of a cross-chain transaction method between alliance chains proposed in this embodiment are designed as follows:
[0091] 3.1) User A on the first alliance chain wants to use his credit1 on the first alliance chain to purchase the value credit2 data service sold by merchant B on the second alliance chain. User A is the buyer and merchant B is the seller;
[0092] 3.2) A initiates a cross-chain transaction request and sends an order to the entire network, To publicize to nodes in the cross-chain media candidate pool;
[0093] 3.3) The cross-chain media candidate pool randomly assigns a node among the candidate nodes as the cross-chain media node M to receive the cross-chain order request, and publicize it to the entire network, Sig={S k (Request)};
[0094] 3.4) At this time, the cross-chain transaction participated by user A, merchant B, and cross-chain media node M can be expressed as: Where credit 1 ={n*credit 2 +Order_tips};
[0095] 3.5) Insert TX CB1→CB2 Split into two parts, one is the in-chain transaction TX between user A on the first alliance chain and cross-chain media node M A→M (Buyer alliance chain transaction), the second part is the in-chain transaction TX between cross-chain media node M and merchant B on the second alliance chain M→B (Seller alliance chain transaction);
[0096] 3.6) It is worth emphasizing here that the point cross-chain transaction strategy of this embodiment is the transaction TX on the second alliance chain M→B Happens first, that is, cross-chain media node M transfers credit2 to merchant B on the second consortium chain first,
[0097] 3.7) Wait for TX M→B Is packaged into block B CB2;
[0098] 3.8) The contract interface on the second alliance chain will trade TX M→B Submit to CCBP, CCBP performs verification and gives the signature σ=Signature(TX M→B , SK CCP ) And evidence π = Prove(TX M→B ,Σ); output to the first alliance chain CB 1;
[0099] 3.9) On the first consortium chain, the transaction of user A transferring credit1 to the cross-chain media node M is recorded as Before this transaction occurs, the pre-set trigger conditions of the smart contract are: verify the evidence π and signature σ provided by CCBP regarding the transaction on the second consortium chain, and only when the smart contract is verified will it trigger the execution of TX A→M;
[0100] 3.10) Wait for TX A→M Is packaged into block B CB1;
[0101] 3.11) The contract interface on the first alliance chain will trade TX A→M Submit to CCBP, CCBP will perform transaction verification. When verification is successful, the signature σ=Signature(TX M→B , SK CCP ) Return to the first consortium chain and the second consortium chain, otherwise the transaction fails;
[0102] 3.12) The point cross-chain transaction ends.
[0103] Step 3.6) is further analyzed below:
[0104] In the system where two alliance chains interact, a possible fraud object involved in a cross-chain transaction. First, a cross-chain transaction involves three parties: user A, cross-chain media node M, and merchant B. User A is the transaction initiator. Based on our assumption that is based on the characteristics of smart contracts, once the user initiates the transaction, it cannot be undone, and user A cannot make fraudulent actions; Merchant B is the transaction recipient and is in a passive position, and fraud can also be eliminated The possibility of fraud; then the cross-chain media node M we introduced is the most likely to be fraudulent, because he is both the recipient of the transaction on the first consortium chain and the initiator of the transaction on the second consortium chain.
[0105] Under the cross-chain transaction strategy proposed in this embodiment, M has no chance to commit fraud, which can be proved by the model:
[0106] According to the transaction process described above, the processing strategy of this embodiment is simply to allow the transfer of funds from M to B on the second alliance chain to occur first, and generate corresponding transaction existence evidence π through CCBP and return it to the first alliance Chain; Then only when the smart contract on the first alliance chain verifies π, the action of transferring A to M is executed.
[0107] The main advantage of this is to prevent the fraudulent behavior of the cross-chain media node M. For example, if M first receives the transfer of points from A and obtains the reward, it does not perform the transfer to B according to the regulations, which will cause A to lose points. This situation is obviously impossible to occur in the cross-chain transaction strategy designed in this embodiment, because this embodiment protects A’s interests by executing the transaction on the second blockchain first by M, and at the same time, as long as M performs according to regulations Operation, he will also get the remuneration he received from this cross-chain order as scheduled.
[0108] Of course, in addition to anti-fraud M through the execution order of the transaction strategy, a special inspection agency node is also set up in this embodiment to periodically check the behavior of candidate nodes in the cross-chain media candidate pool. Once a violation is found, the candidate node The deposit paid will be deducted in full and will be removed from the network. This guarantees the positive incentives and rules of the network.
[0109] Four, implementation example
[0110] User A on the first consortium chain wants to use 100credit1 to buy data services worth 50credit2 sold by merchant B on the second consortium chain, with an additional service fee of 5credit1.
[0111] The implementation example is as follows:
[0112] 4.1) User A's account on the first alliance chain is User B’s account on the second consortium chain is
[0113] 4.2) A initiates a cross-chain transaction request and sends an order to the entire network, To publicize to nodes in the cross-chain media candidate pool;
[0114] 4.3) The cross-chain media candidate pool randomly assigns a node among the candidate nodes as the cross-chain media node M to receive the cross-chain order request and announce it to the whole network, Sig={S k (Request)};
[0115] 4.4) At this time, the cross-chain transaction participated by user A and cross-chain media node M can be expressed as: Of which 110credit 1 ={2*50credit 2 +5credit1};
[0116] 4.5) We will TX CB1→CB2 Split into two parts, one part is the in-chain transaction TX between user A and cross-chain media node M on the first alliance chain A→M , The second part is the in-chain transaction TX between user B and cross-chain media node M on the second consortium chain M→B;
[0117] 4.6) Similarly, in order to protect the interests of user A, our point cross-chain transaction strategy is the transaction TX on the second consortium chain M→B Happens first, that is, the cross-chain media node M must first transfer money to user B on the second consortium chain,
[0118] 4.7) Wait for TX M→B Is packaged into block B CB2;
[0119] 4.8) Cross-chain media node M will trade TX M→B Submitted to the alliance chain cross-chain processor CCBP, CCBP performs transaction existence verification and uses the signature function Signature (TX M→B , SK CCP ) Generate the signature σ and the proof function Prove(TX M→A′ ,Σ) Generate evidence π; return to the first alliance chain CB 1 , For smart contract verification;
[0120] 4.9) On the first consortium chain, the transaction of user A transferring credit1 to the cross-chain media node M is recorded as Before this transaction occurs, the pre-set trigger condition of the smart contract is: verify the evidence π and signature σ provided by CCBP regarding the transaction on the second consortium chain, that is, the function Verify(π, σ), only when the smart contract is verified TX will only be triggered when passed A→M;
[0121] 4.10) Wait for TX A→M Is packaged into block B CB1;
[0122] 4.11) User A will trade TX A→M Submitted to the alliance chain cross-chain processor CCBP, CCBP performs transaction existence verification, when the verification is successful, the signature function Signature (TX A→M , SK CCP ) Return the signature message of successful point cross-chain transaction to the first consortium chain and the second consortium chain;
[0123] At this time, the user's account on the first alliance chain and the second alliance chain has completed the transfer of cross-chain points, and the cross-chain transaction ends.
[0124] The cross-chain transaction method for the alliance blockchain provided in this embodiment is also applicable to the application scenario of cross-chain asset transfer (exchange). When the merchant B in this embodiment is user A, that is, when user A wants to transfer points to his own account on the second alliance chain through his account on the first alliance chain, in this embodiment, it is used in the alliance area The cross-chain transaction method of the block chain is still valid.
[0125] The embodiment of the present invention also provides a computer-readable storage medium, which may be a hard disk, a multimedia card, an SD card, a flash memory card, an SMC, a read-only memory (ROM), an erasable programmable read-only memory (EPROM), portable compact disk read-only memory (CD-ROM), USB memory, etc. any one or any combination of several. The computer-readable storage medium includes a processing system. For the functions that the processing system implements when executed by the processor, please refer to the above-mentioned introduction on the transaction method of the cross-chain transaction system used in the alliance blockchain, which will not be repeated here. .
