CN108009811B - Inter-cloud computing environment value exchange-oriented cross-chain communication method - Google Patents
Inter-cloud computing environment value exchange-oriented cross-chain communication method Download PDFInfo
- Publication number
- CN108009811B CN108009811B CN201711237256.4A CN201711237256A CN108009811B CN 108009811 B CN108009811 B CN 108009811B CN 201711237256 A CN201711237256 A CN 201711237256A CN 108009811 B CN108009811 B CN 108009811B
- Authority
- CN
- China
- Prior art keywords
- transaction
- sender
- chain
- block
- receiver
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/085—Payment architectures involving remote charge determination or related payment systems
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/22—Payment schemes or models
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/22—Payment schemes or models
- G06Q20/29—Payment schemes or models characterised by micropayments
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G06Q20/401—Transaction verification
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G06Q20/405—Establishing or using transaction specific rules
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
Landscapes
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Strategic Management (AREA)
- Theoretical Computer Science (AREA)
- Finance (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Development Economics (AREA)
- Economics (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
本发明公开了一种面向云际计算环境价值交换的跨链通信方法，目的是保证价值交换过程的安全可靠和高效。技术方案是在各区块链上的每个用户节点中安装由跨链通信模块、节点管理模块、验证模块、记账模块组成的跨链通信系统，建立中间链，从中间链上选择路由节点，由路由节点完成链与链之间的价值转移和沟通交流；发送方的跨链通信模块为发送方、接收方、路由节点构造资金池，根据资金转移方案进行资金转移，接收方的验证模块采用智能合约的方式对发送方资金的有效性和可用性进行验证；接收方的记账模块广播交易结果，发送方、接收方、MidChain生成新区块以存储交易数据。采用本发明可保证价值交换过程的安全可靠和高效，实现链与链之间的无缝跨链通信。
The invention discloses a cross-chain communication method for inter-cloud computing environment value exchange, which aims to ensure the safety, reliability and efficiency of the value exchange process. The technical solution is to install a cross-chain communication system consisting of a cross-chain communication module, a node management module, a verification module, and an accounting module in each user node on each blockchain, establish an intermediate chain, and select routing nodes from the intermediate chain. The routing node completes the value transfer and communication between chains; the sender's cross-chain communication module constructs a fund pool for the sender, receiver, and routing node, and transfers funds according to the fund transfer scheme. The verification module of the receiver adopts The validity and availability of the sender's funds are verified by means of smart contracts; the accounting module of the receiver broadcasts the transaction results, and the sender, receiver, and MidChain generate new blocks to store transaction data. The invention can ensure the safety, reliability and efficiency of the value exchange process, and realize seamless cross-chain communication between chains.
Description
Technical Field
The invention relates to the field of block chains and distributed cloud computing, in particular to a communication method for performing value exchange in a cross-chain mode by using a block chain as a basic technical support.
Background
The concept of block chain was proposed as the underlying technology of bit currency in the Smart Bitcoin: A Peer-to-Peer Electronic Cash System (i.e., bit currency: a point-to-point Electronic Cash System) in 08. In order to realize a point-to-point decentralized trusted accounting system, the intelligent agent puts each transaction information of the bitcoin into a block (namely a block structure for storing transaction data hash values and timestamps), and each block is connected into a chain according to the sequence of the timestamps, which is called a block chain. A user node on a certain blockchain (also referred to as a user node belonging to a certain blockchain) refers to a user terminal that synchronizes all blocks on the certain blockchain to a local server, and in an inter-cloud computing environment, refers to a cloud service consumer and a cloud service provider in particular. A block chain is provided with a plurality of user nodes, and all the user nodes have the functions of broadcasting, verifying, allocating funds in a fund pool and transferring funds. In addition, since the blockchain itself can be regarded as a distributed book, the whole blockchain that synchronizes each user node to the local server is called a local book, and the local book is updated synchronously with the generation of a new block. Therefore, the traditional Chinese intelligent terminal perfectly realizes a decentralized and trusted accounting system under the peer-to-peer network through the form of the block chain. As shown in fig. 2, the block chain is formed by a plurality of blocks (the first block is defined as a creation block) in the order of time stamps for creating the transaction. Each block consists of a block header and three other data fields. The block header contains 6 data fields, which are: chunk ID, random number, last chunk hash value, timestamp of the generated chunk, Merkle root hash value, difficulty value. The block ID is the number of each block and is used for checking the transaction information after the verification module and the transaction are completed; the random number is a number which is subjected to hash operation with transaction information (the hash operation is an operation of mapping data with any length into data with fixed length, SHA-256 hash algorithm is used in a bitcoin, and the hash algorithm is from the safety hash standard issued by the national institute of standards and technology, and is used for a user node to compete for the billing right according to a PoW consensus mechanism; the last block hash value is a value obtained by merging and carrying out hash operation on the data field information of the last block connected with the block to which the last block hash value is 0; generating a time stamp of the block refers to a string of character sequences representing the block generation time; the Merkle root Hash value is formed by combining all transaction information in the transaction information through a Merkle Proof method (Nakamoto S. Bitcin: Apeer-to-peer electronic cash system [ J ].2008, namely Biteh currency: a point-to-point electronic cash system page 4, lines 22-31); the difficulty value is a difficulty coefficient for calculating the hash value when the user contends for the billing right. The other three data fields in the block are: block size, transaction counter, transaction information. The block size is the size of the block in bytes; the transaction counter is the transaction number recorded in the block; the transaction information is information for each transaction record, which is recorded by the user node according to the specific transaction. Later, based on the inspiration of bitcoin, more and more enterprises dedicated to the development of the blockchain infrastructure are launched into the industrial market, and the enterprises include Blockstream, Ripple, Ethereum and the like.
By taking the idea of bitcoin as a reference, Etheng attempts to build an intelligent contract platform on top of bitcoin protocol that does not require a trust base at all. It is an innovative programmable blockchain platform that allows anyone to build and use decentralized applications running through blockchain technology in the platform. In contrast to bitcoin blockchains, which are purely a list of transaction information, etherhouse blockchains are account-based units that track the status of each account, and state transitions across all etherhouse blockchains are transfers of value and information between accounts. The account is divided into an external account and a contract account, wherein the external account is controlled by a user through a private key, and the contract account is controlled by contract code, namely intelligent contract.
As for smart contracts, as early as 1994, the cryptologist nissabo (Nick Szabo) put forward the concept of smart contracts in its own website, but has not been applicable to reality. The development is not continued until the clever bitcoin is proposed. An intelligent CONTRACT is an automatically executable computer program (e.g., "Ethernet White Paper: ANEXT GENERATION SMART CONTACT & DECENTRALIZED APPLICATION PLATFORM", i.e., "ETHERS: Next Generation Intelligent CONTRACTs and DECENTRALIZED APPLICATION PLATFORMs", page 13, line 16-page 17, line 24, which describe the concept of intelligent CONTRACTs in ETHERS, how to write and how to use it. The method is deployed on a block chain, so that automatic control over transaction processes and transaction data can be realized, and interaction with real assets can be realized by executing the program.
If the blockchain is said to solve the problem that the transaction channel is not trusted, the consensus mechanism is to solve the problem of how the blockchain is consistent under the distributed scenario. Representative consensus algorithms include PBFT (Practical Byzantine factory Tolerance), PoW (Proof of Work) consensus algorithm (Nakamoto S. Bitcin: Apeer-to-peer electronic cash system [ J ] 2008, bit currency: a Point-to-Point electronic Cash System, pages 4, lines 1-22), PoS (Proof of rights) consensus algorithm, and the like. PBFT is a message-passing based consensus algorithm generated in the context of the problem of the general of byzantine. The maximum allowable fault tolerance number of the PBFT algorithm in an asynchronous network environment is (n-1)/3(n is the total node number). The PBFT algorithm is consistent through three stages of preparation, preparation and execution, and the three stages are all repeated possibly due to failure. The PoW consensus algorithm based on workload certification is mainly used in accounting right contention for blocks. The hash value of a block (i.e. the result of the hash encryption operation on the transaction record in the block, the transaction record being represented by a string of numbers) is composed of N leading zeros, and the number of zeros depends on the difficulty level of the network. To obtain a reasonable hash value, a large number of trial and error calculations are required, and the calculation time depends on the hash operation speed of the machine. Users on the blockchain compete for billing based on computing power to obtain bitcoin revenue, an operation also known as mine excavation. Since finding the correct hash value is a probabilistic event, when a node has m% of the total network computing power, the node has m% of the probability of finding the hash value of a block, and m is a real number. However, PoW resources are extremely wasteful, and the final operation is not practical. PoS is a rights-based attestation algorithm that considers records and attestations on a blockchain to be maintained and guaranteed by those with economic benefit on the chain. PoS fundamentally breaks away from the waste of computing power of PoW by requiring a prover to provide ownership of a certain amount of cryptocurrency rather than performing a difficult workload proof.
Existing Multi-Cloud service providers, such as Inter-Cloud, SuperCloud, Multi-Cloud, fedeastedcloud, etc., focus primarily on the integration of resources to meet the needs of Cloud service consumers, but lack platform and mechanism support for participant shared collaboration and a service model for cooperative win-win among Cloud service providers.
inter-Cloud Computing (Joint Cloud Computing) is a support technology which is provided for meeting the requirements of future Cloud Computing and adapting to the future development of Cloud Computing and can solve the existing research dilemma, and the Joint Cloud Computing is a new generation Cloud Computing mode which is based on open collaboration among Cloud service providers, integrates multiple Cloud resources deeply, supports self-service collaboration and benefit exchange among Cloud providers, and is convenient for developers to customize Cloud services and create Cloud value in a software definition mode. In an interpyury computing scenario, an interpyury chain coexists with other types of blockchains (user chains and business chains), and a requirement for value exchange exists in a single blockchain.
Under the global development trend of the internet, it is increasingly difficult for a single block link structure to meet the requirements of various transaction services. To address the complex and varied cloud computing transaction service challenges, some companies have proposed the concept of conducting transactions across chains. Representative examples include side chain technology (Sidechain) proposed by Blockstream corporation, and inter-chain protocol proposed by Ripple corporation. The side chain proposed by Blockstream is a chain for realizing the transfer of bitcoin among a plurality of block chains. When transferring funds, a confirmation period and a competition period need to be waited for. The validation period is the time that the funds need to be locked in the chain on which the sender of the funds is located before transferring to the sidechain in order to generate enough work to resist the attack. And the competition period is used for preventing the double-flower attack during the recombination. Both periods require waiting for 1-2 days to lock the funds, respectively. The side chain technique is inefficient due to the excessive time spent for processing the fund verification and cannot meet the requirements of normal transactions.
The Interridge protocol, proposed by Ripple corporation, is a protocol for payments across payment systems. If the two parties of the transaction are in different payment systems, no direct transaction channel is available between the two parties to complete the transaction. Aiming at the situation, the Interridge protocol proposes that middleware (Connectors) is added between a Sender (Sender) and a Receiver (Receiver) of transaction funds to connect, in such a way, a channel capable of direct transaction is established between different payment systems, meanwhile, Escrow and control of the funds during transaction preparation are realized through a third-party funds Escrow platform (Escorow), but the security of the Interridge protocol is doubted by the huge open risk of the Escorow.
Therefore, to implement cross-chain transaction or communication, the following technical problems also exist:
1. the safety problem. The inter-chain communication based on the digital currency needs to guarantee the rights and interests of both communication parties, namely, the effective availability of the transaction currency is ensured; the transaction record is real and traceable; the likelihood of a malicious attack is low. Therefore, a perfect mechanism is needed to maintain traceability and stable operation of the transaction, in the prior art, the transaction is often supervised and maintained by a third party (such as Escrow in the interleaver), and since the third party has a certain potential safety hazard (possibly existing fraud behaviors), the safety of the whole value exchange process cannot be ensured.
2. The efficiency is problematic. To ensure security, it takes a lot of time for currency validation (including verifying whether the source of the currency is valid and whether the currency is available) and accounting (confirming the transaction and recording). Most of the prior art costs a lot of time for verifying the validity of the funds (for example, the side chain spends 2-4 days for locking the funds in one value transfer), and the efficiency of the value exchange is greatly reduced.
Disclosure of Invention
The technical problem to be solved by the invention is to provide a cross-chain communication method for inter-cloud computing environment value exchange, which ensures the safety, reliability and high efficiency of the value exchange process, promotes the transaction and communication between any two chains, and realizes the seamless cross-chain communication between the chains.
The technical scheme of the invention is to facilitate inter-chain value exchange, and particularly provides a cross-chain communication scheme aiming at certain chains without direct connection channels. In an inter-cloud computing environment, there is a blockchain, referred to as inter-cloud chain, that has a need for cross-chain communication with other types of blockchains, including business chains that provide cloud computing services, and user chains that use cloud computing services. According to the idea that middleware is established to connect different payment systems according to an Interridge protocol (APROTOCOL for Interridge Payments, namely Interridge white paper) provided by Ripple company, the invention establishes an intermediate chain for connecting a cloud chain and any chain (as shown in figure 4, taking a service chain A as an example), and performs cross-chain communication through the intermediate chain to further realize value exchange; meanwhile, the fund validity in the value exchange process is verified in an intelligent contract mode, and the safety of the transaction process is guaranteed. The blockchain used in the present invention is the same as the data structure shown in fig. 2, and the contents of the transaction information field in the block are defined. Each transaction message includes the following contents: the transaction record index number, sender address, receiver address, transaction resource content, transaction transfer amount, and transaction generation timestamp. The transaction record index number is a serial number of each transaction record recorded in the ith block in the block chain according to a time sequence and is used for checking transaction information after fund verification and transaction are completed, wherein i is a positive integer; the sender address refers to the IP address of the user node that initiated the transaction; the receiver address refers to the IP address of the user node receiving the transaction; the transaction resource content refers to cloud service resources provided by a cloud service provider to a cloud service consumer in a cloud service transaction; the transaction transfer amount refers to an amount required by a cloud service consumer to purchase a resource provided by a cloud service provider in a cloud service transaction; the time stamp of the generated transaction refers to a string of characters representing the time of generation of the transaction.
The invention comprises the following steps:
firstly, installing a cross-chain communication system in each user node on each blockchain of the inter-cloud computing environment, wherein the system comprises a cross-chain communication module, a node management module, a verification module and an accounting module.
The cross-chain communication module is connected with a sender (namely a transaction sender, the default transaction sender is a party purchasing resources and paying money), a receiver (namely a transaction receiver, the default transaction receiver is a party providing resources and receiving money), a node management module, a verification module and an accounting module, is responsible for building a middle chain and constructing a routing node fund pool, and is also responsible for communication among the sender, the receiver and the routing node and fund transfer. The method comprises the steps of determining a sender address and a receiver address according to a request sent by a sender, constructing an intermediate chain connecting the sender and the receiver according to the two addresses, and sending IP addresses of all user nodes on the intermediate chain to a node management module; the cross-link communication module receives the IP address of the routing node from the node management module, performs communication connection and cloud service transaction according to the routing node result, and simultaneously sends funds related to the transaction to the verification module; the cross-link communication module receives a transaction acceptance result from the verification module, and continues to execute the transaction or terminate according to the transaction acceptance result; and after the cross-chain communication module finishes the transaction, the transaction information is sent to the accounting module.
The node management module is connected with the cross-chain communication module, receives the IP address of the user node on the intermediate chain from the cross-chain communication module, selects a routing node participating in cross-chain communication from the user node on the intermediate chain, and sends the IP address of the routing node to the cross-chain communication module;
the verification module is connected with the cross-chain communication module, receives the transaction fund from the cross-chain communication module, is responsible for verifying the validity and the availability of the transaction fund and returns the transaction verification result to the cross-chain communication module;
the accounting module is connected with the cross-chain communication module, the sender and the receiver, receives transaction information from the cross-chain communication module, and is responsible for generating an account book for the transaction and synchronizing the account book to all user nodes in a chain where the sender and the receiver are located.
And secondly, a cross-chain communication module of the sender builds an intermediate chain between the sender and the receiver. The method comprises the following steps:
2.1 the cross-chain communication module of the sender constructs an intermediate chain according to the sender address-StartAddr and the receiver address EndAddr, and the constructed intermediate chain is represented by MidChain. The method comprises the following steps:
2.1.1 determine the intermediate chain data structure as a blockchain.
2.1.2 initialize the first block of the intermediate chain:
2.1.2.1 determining the block size to be the byte size occupied by the entire block;
2.1.2.2 initializes the transaction counter to 0;
2.1.2.3 initialize the chunk header of the first chunk of the middle chain:
2.1.2.3.1 initializes the tile ID to 001;
2.1.2.3.2 initializes the random number to 0;
2.1.2.3.3 initializing the last chunk hash value to 0;
2.1.2.3.4 initialize a difficulty value to 0;
2.1.2.3.5 determining the time stamp of the generated block as the time of the block generation time;
2.1.2.3.6 initializing the Merkle root hash value to 0;
2.1.2.4 initializing transaction information in tiles:
2.1.2.4.1 initializing transaction record index number to Mid-1-1 (and growing sequentially in the form of Mid-1-2, Mid-1-3, Mid-1-4);
2.1.2.4.2 initializing transaction resource content to null;
2.1.2.4.3 initializes the transaction transfer amount to 0;
2.1.2.4.4 determining the sender address to be StartAddr;
2.1.2.4.5 determining the receiver address as EndAddr;
2.1.2.4.6 initializes the timestamp of the generated transaction to 0;
2.1.3 creating a user node belonging to MidChain, wherein the method comprises the following steps: and at least 5 different user node servers are randomly selected from the block chain where the sender is located and the block chain where the receiver is located respectively to synchronize the block information on the MidChain, and the synchronized server addresses are recorded as the IP addresses of the user nodes.
2.1.4 the cross-chain communication module of the sender sends all the user node IP addresses on the middle chain to the node management module of the sender.
Thirdly, the node management module of the sender receives the user node IP addresses belonging to MidChain from the cross-link communication module, and 1 user node is selected as a routing node, wherein the method comprises the following steps:
3.1 determining the candidate node range by adopting a PoW consensus algorithm, wherein the method comprises the following steps: performing power competition by adopting a PoW consensus algorithm, and selecting the first five user nodes with the strongest computing power as candidate nodes, wherein the strongest computing power means that the user nodes obtain a random number through operation at the fastest speed, so that the number obtained after the random number and 6 data in a block header are combined together by using a Merkle Proof method meets the set difficulty value, wherein the difficulty value is a maximum target value divided by a current target value (the maximum target value is a fixed hash value and is generally set to be 0x0000 FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF; and the current target value is the block header hash value of the current block (namely the newly generated block).
3.2 because the routing node is used for connecting communication and requires handling fee (the routing node is used as an intermediate connecting node of cross-link communication, the cost is charged for connecting communication between a sender and a receiver, and the specific handling fee amount is self-determined by the routing node), the handling fee required by the communication between the sender and the receiver is sorted from five candidate nodes selected by adopting a PoW consensus algorithm, and the candidate node with the lowest handling fee is selected as the routing node on the MidChain, which is called the routing node for short.
3.3 the node management module of the sender sends the IP address of the routing node to the cross-link communication module of the sender.
Fourthly, the cross-link communication module of the sender constructs a fund pool for the sender, the receiver and the selected routing node participating in the cross-link communication according to the IP address of the sender and the IP address of the receiver and the IP address of the routing node received from the node management module, and fund transfer is carried out according to a fund transfer scheme negotiated by the sender and the receiver participating in the cross-link communication (the scheme comprises purchased resource content and fund amount required to be transferred, and the fund amount comprises the amount required for purchasing the resource and procedure cost required for connecting and communicating with the routing node). The method comprises the following specific steps:
4.1 establishing independent fund pools for a sender, a receiver and a routing node participating in cross-link communication, namely representing the nodes and the corresponding pre-stored fund amount thereof by key value pairs in the form of (node IP addresses and pre-stored fund amounts);
4.2 the three parties of the sender, the receiver and the routing node pre-store a part of funds in the fund pool, namely, the IP addresses of the three parties (the IP address of the node and the pre-stored fund amount) and corresponding pre-stored fund values are respectively given to the three parties.
4.3 the sender broadcasts the fund transfer scheme to the routing node and the receiver, the routing node and the receiver receive the widely broadcast fund transfer scheme, check whether the fund transfer scheme content (fund transfer amount and routing node commission) is correct, if so, the receiver sends a confirmation result (that is, the scheme content is correct) to the routing node, the routing node collects the confirmation result (including the confirmation result of the routing node) and then signs, and returns the fund transfer scheme with the signature to the sender, and meanwhile, the routing node and the receiver send the fund involved in the transaction to the verification module of the routing node and the receiver, and the fifth step is carried out; if not, the receiver sends the error information to the routing node, the routing node collects the error information (including the error information found by the routing node) and attaches the signature of the routing node, the error information is sent to the sender, and the sender broadcasts again after checking and modifying the fund transfer scheme, and then the 4.3 steps are carried out.
And fifthly, the verification module of the receiver verifies the validity and the availability of the funds of the sender in an intelligent contract mode. The specific method for verification is as follows:
5.1 determination conditions for entering funds in a smart contract (i.e. a piece of program automatically performing the determination action deployed in the verification module): it is determined whether the source of funds is available, i.e., whether the sender has sufficient funds to transfer.
5.2 traversing each block of the block chain to which the sender belongs, inquiring transaction information (namely transaction transfer amount and transaction resource content) of the sender, judging whether the sender has enough funds for the transaction (namely whether the total amount of transferred funds minus the total amount of transferred funds of the sender is larger than the amount of funds required to be transferred for the transaction), if not, indicating that the verification fails, the fund transfer scheme is invalidated, the two parties of the transaction coordinate the next operation, and regenerating the fund transfer scheme and broadcasting again by the sender according to the coordination result or 4.3 steps; or turning to the seventh step to terminate the transaction; if sufficient funds exist, the verification is successful, and the result of the successful verification is returned to the cross-link communication module of the sender, and the step is changed to 5.3;
and 5.3, the cross-link communication module of the sender reallocates funds in the fund pool according to the transaction transfer amount related in the fund transfer scheme, namely (the node IP address and the pre-stored fund amount) of the sender is changed into (the node IP address and the existing fund amount) to complete fund transfer, (the existing fund amount is the pre-stored fund amount-the transaction transfer amount), and the transaction information is sent to the accounting module.
Sixthly, the accounting module of the receiver receives the transaction information sent by the cross-chain communication module in the step 5.3, and user nodes which acquire accounting rights by each block chain (including the block chain where the sender is located, the block chain where the receiver is located, and the MidChain) generate new blocks which are respectively put into the respective block chains to store the transaction information, wherein the method comprises the following steps:
6.1 the accounting module performs hash operation on the transaction information (including transaction record index number, transaction resource content, transaction transfer amount, sender address, receiver address and timestamp for generating transaction) (an algorithm for converting target text into hash character strings with the same length, and adopts SHA-256 hash algorithm in safety hash standard issued by national institute of standards and technology), and broadcasts the hash character strings to the block chain where the sender and the receiver are located and each user node on the intermediate chain.
6.2 each user node (including the chain where the sender is located, the chain where the receiver is located and all user nodes on the intermediate chain) contends for the accounting right by adopting a PoW consensus algorithm to perform calculation competition and selecting 1 user node with the strongest calculation. And finally, one user node of each block chain obtains the accounting right, a new block is generated on the block chain to which the user node belongs, and the block size, the transaction counter, the block header and the transaction information are put into the newly generated block. The values of the contents in the block are as follows:
6.2.1 Block size is determined as the byte size occupied by the entire block;
6.2.2 transaction counter is determined as the transaction times contained in the block;
6.2.3 the 6 data contained in the block header are assigned respectively:
6.2.3.1 the block ID is 00i (i is the block serial number, as the blocks increase, the value of i increases progressively according to the rule of n +1, n +2, n +3, …, n is the original number of blocks of the block chain to which the user node obtaining the accounting right belongs, and n is a positive integer);
6.2.3.2 the random number is a random number value obtained by the operation of the user node obtaining the accounting right when competing for the accounting right;
6.2.3.3 the last chunk hash value is the last chunk hash value;
6.2.3.4, the difficulty value is determined by the formula difficulty value is maximum target value ÷ current target value;
6.2.3.5 determining the time stamp of the generated block as the time of the block generation time;
6.2.3.6Merkle root hash is a hash value obtained by combining the transaction information by a Merkle Proof method;
6.2.4 the transaction information contains 6 data assigned values:
6.2.4.1 assigns the transaction record index number Mid- (i-1);
6.2.4.2 determining the transaction resource content as resource content (in the form of a string) for a particular transaction;
6.2.4.3 determining the transaction transfer amount as the amount to be transferred for the particular transaction;
6.2.4.4 determining the sender address to be StartAddr;
6.2.4.5 determining the receiver address as EndAddr;
6.2.4.6 determining the time stamp of the generated transaction as the time of the transaction generation time;
and 6.3, synchronously downloading the newly generated blocks to respective local accounts by each user node on the block chain where the sender and the receiver are located and the intermediate chain.
And step seven, ending the cloud service transaction communication.
The invention can achieve the following technical effects:
1. the accounting module records the transaction information in the local account book of each user node, so that the problem of poor traceability of the transaction information caused by accounting of both transaction parties is avoided, and the problem of high risk of fund exposure of a third-party escrow system is also avoided.
2. And because the fifth step adopts an intelligent contract mode, the efficiency is improved compared with the existing fund verification mode. For example, the side chain technique accomplishes the verification through fund locking of two waiting periods, which take 2-4 days in total, thus seriously affecting the transaction process. And the intelligent contract mode is adopted, rules are preset according to whether the fund is valid (namely whether the transaction record of the previous fund exists) and available (namely whether the fund is used), the fund verification is automatically completed, the unnecessary waiting time is reduced, the account confirming speed is accelerated, and the high efficiency and the order of the transaction are ensured.
3. And in the fourth step, a mode of establishing a fund pool is adopted, and the fund amount in the fund pools of the two parties is redistributed according to the transfer object and the amount described by the fund distribution scheme, so that the safety is improved compared with the mode of directly transferring the specific currency. Meanwhile, the method is also suitable for multiple small-scale transactions, the fund amount is directly modified, unnecessary time delay is reduced, and the efficiency is higher.
Drawings
FIG. 1 is a diagram of a scenario of inter-chain communication between chains in an inter-cloud computing environment.
Fig. 2 is a data structure diagram of the block chain of the present invention.
FIG. 3 is a logic structure diagram of a cross-chain communication system facing the inter-cloud computing environment, which is constructed in the first step of the invention;
fig. 4 is a scenario diagram of a middle chain constructed by the present invention to connect a sender and a receiver to communicate.
Fig. 5 is an overall flow chart of the present invention.
Detailed Description
FIG. 1 is a diagram of a background art scenario for inter-chain communication between chains in an inter-cloud computing environment. In the inter-cloud computing environment, there are various kinds of block chains (the data structure of the block chain is shown in fig. 2), including inter-cloud chains for connecting and cooperating various chains, business chains a and B for providing cloud computing services, and user chains C and D for purchasing and using the cloud computing services. There is a need for transactions for user nodes that are on different chains, including CSPs (cloud service providers), and CSCs (cloud service consumers). For such a cross-chain situation, an intermediate chain needs to be established between two chains of communication to connect.
Fig. 2 is a data structure diagram of the block chain of the present invention. The invention provides for the contents of the transaction information field in the tile. Each transaction message includes the following contents: the transaction record index number, sender address, receiver address, transaction resource content, transaction transfer amount, and transaction generation timestamp. The other information in the block is exactly the same as the existing block chain described in the background.
FIG. 3 is a logic structure diagram of a cross-chain communication system facing the cloud computing environment, which is constructed in the first step of the invention. The cross-chain communication module is connected with a sender (namely a transaction sender, the default transaction sender is a party purchasing resources and paying money), a receiver (namely a transaction receiver, the default transaction receiver is a party providing resources and receiving money), a node management module, a verification module and an accounting module, is responsible for building a middle chain and constructing a routing node fund pool, and is also responsible for communication among the sender, the receiver and the routing node and fund transfer. The method comprises the steps of determining a sender address and a receiver address according to a request sent by a sender, constructing an intermediate chain connecting the sender and the receiver according to the two addresses, and sending IP addresses of all user nodes on the intermediate chain to a node management module; the cross-link communication module receives the IP address of the routing node from the node management module, performs communication connection and cloud service transaction according to the routing node result, and simultaneously sends funds related to the transaction to the verification module; the cross-link communication module receives a transaction acceptance result from the verification module, and continues to execute the transaction or terminate according to the transaction acceptance result; and after the cross-chain communication module finishes the transaction, the transaction information is sent to the accounting module.
The node management module is connected with the cross-chain communication module, receives the IP address of the user node on the intermediate chain from the cross-chain communication module, selects a routing node participating in cross-chain communication from the user node on the intermediate chain, and sends the IP address of the routing node to the cross-chain communication module;
the verification module is connected with the cross-chain communication module, receives the transaction fund from the cross-chain communication module, is responsible for verifying the validity and the availability of the transaction fund and returns the transaction verification result to the cross-chain communication module;
the accounting module is connected with the cross-chain communication module, the sender and the receiver, receives transaction information from the cross-chain communication module, and is responsible for generating an account book for the transaction and synchronizing the account book to all user nodes in a chain where the sender and the receiver are located.
Fig. 4 is a scene diagram of a middle chain constructed by the present invention connecting a sender and a receiver and performing communication. Assuming that there is a communication requirement between the inter-cloud chain and the service chain a, but there is no direct connection channel, an intermediate chain is built between the two chains, Node2 is a routing Node of the intermediate chain, and the routing nodes of the sender, the receiver and the intermediate chain are all provided with a fund pool.
Fig. 5 is an overall flow chart of the present invention. The method comprises the following specific steps:
in the first step, a cross-chain communication system is installed in each user node on each blockchain of the inter-cloud computing environment, and the system is composed of a cross-chain communication module, a node management module, a verification module and an accounting module as shown in fig. 3.
And secondly, a cross-chain communication module of the sender builds an intermediate chain between the sender and the receiver. The method comprises the following steps:
2.1 the cross-chain communication module of the sender constructs an intermediate chain according to the sender address-StartAddr and the receiver address EndAddr, and the constructed intermediate chain is represented by MidChain. The method comprises the following steps:
2.1.1 determine the intermediate chain data structure as a blockchain.
2.1.2 initialize the first block of the intermediate chain:
2.1.2.1 determining the block size to be the byte size occupied by the entire block;
2.1.2.2 initializes the transaction counter to 0;
2.1.2.3 initialize the chunk header of the first chunk of the middle chain:
2.1.2.3.1 initializes the tile ID to 001;
2.1.2.3.2 initializes the random number to 0;
2.1.2.3.3 initializing the last chunk hash value to 0;
2.1.2.3.4 initialize a difficulty value to 0;
2.1.2.3.5 determining the time stamp of the generated block as the time of the block generation time;
2.1.2.3.6 initializing the Merkle root hash value to 0;
2.1.2.4 initializing transaction information in tiles:
2.1.2.4.1 initializing transaction record index number to Mid-1-1 (and growing sequentially in the form of Mid-1-2, Mid-1-3, Mid-1-4);
2.1.2.4.2 initializing transaction resource content to null;
2.1.2.4.3 initializes the transaction transfer amount to 0;
2.1.2.4.4 determining the sender address to be StartAddr;
2.1.2.4.5 determining the receiver address as EndAddr;
2.1.2.4.6 initializes the timestamp of the generated transaction to 0;
2.1.3 creating a user node belonging to MidChain, wherein the method comprises the following steps: and at least 5 different user node servers are randomly selected from the block chain where the sender is located and the block chain where the receiver is located respectively to synchronize the block information on the MidChain, and the synchronized server addresses are recorded as the IP addresses of the user nodes.
2.1.4 the cross-chain communication module of the sender sends all the user node IP addresses on the middle chain to the node management module of the sender.
Thirdly, the node management module of the sender receives the user node IP addresses belonging to MidChain from the cross-link communication module, and 1 user node is selected as a routing node, wherein the method comprises the following steps:
3.1 determining the candidate node range by adopting a PoW consensus algorithm, wherein the method comprises the following steps: performing power competition by adopting a PoW consensus algorithm, and selecting the first five user nodes with the strongest computing power as candidate nodes, wherein the strongest computing power means that the user nodes obtain a random number through operation at the fastest speed, so that the number obtained after the random number and 6 data in a block header are combined together by using a Merkle Proof method meets the set difficulty value, wherein the difficulty value is a maximum target value divided by a current target value (the maximum target value is a fixed hash value and is generally set to be 0x0000 FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF; and the current target value is the block header hash value of the current block (namely the newly generated block).
3.2 because the routing node is used for connecting communication and requires handling fee (the routing node is used as an intermediate connecting node of cross-link communication, the cost is charged for connecting communication between a sender and a receiver, and the specific handling fee amount is self-determined by the routing node), the handling fee required by the communication between the sender and the receiver is sorted from five candidate nodes selected by adopting a PoW consensus algorithm, and the candidate node with the lowest handling fee is selected as the routing node on the MidChain, which is called the routing node for short.
3.3 the node management module of the sender sends the IP address of the routing node to the cross-link communication module of the sender.
And fourthly, constructing a fund pool for the sender, the receiver and the selected routing node participating in the cross-chain communication by the cross-chain communication module of the sender according to the IP addresses of the sender and the receiver and the IP address of the routing node received from the node management module, and transferring funds according to a negotiated fund transfer scheme of the sender and the receiver participating in the cross-chain communication. The method comprises the following specific steps:
4.1 establishing independent fund pools for a sender, a receiver and a routing node participating in cross-link communication, namely representing the nodes and the corresponding pre-stored fund amount thereof by key value pairs in the form of (node IP addresses and pre-stored fund amounts);
4.2 the three parties of the sender, the receiver and the routing node pre-store a part of funds in the fund pool, namely, the IP addresses of the three parties (the IP address of the node and the pre-stored fund amount) and corresponding pre-stored fund values are respectively given to the three parties.
4.3 the sender broadcasts the fund transfer scheme to the routing node and the receiver, the routing node and the receiver receive the widely broadcast fund transfer scheme, check whether the fund transfer scheme is correct, if so, the receiver sends a confirmation result (i.e. the scheme content is correct) to the routing node, the routing node collects the confirmation result (including the confirmation result of the routing node) and then signs, the fund transfer scheme with the signature is returned to the sender, and meanwhile, the routing node and the receiver send the fund involved in the transaction to the verification module of the routing node and the receiver, and the fifth step is carried out; if not, the receiver sends the error information to the routing node, the routing node collects the error information (including the error information found by the routing node) and attaches the signature of the routing node, the error information is sent to the sender, and the sender broadcasts again after checking and modifying the fund transfer scheme, and then the 4.3 steps are carried out.
And fifthly, the verification module of the receiver verifies the validity and the availability of the funds of the sender in an intelligent contract mode. The specific method for verification is as follows:
5.1 judging conditions for inputting funds in the intelligent contract: it is determined whether the source of funds is available, i.e., whether the sender has sufficient funds to transfer.
5.2 traversing each block of the block chain to which the sender belongs, inquiring transaction information (namely transaction transfer amount and transaction resource content) of the sender, judging whether the sender has enough funds for the transaction (namely whether the total amount of transferred funds minus the total amount of transferred funds of the sender is larger than the amount of funds required to be transferred for the transaction), if not, indicating that the verification fails, the fund transfer scheme is invalidated, the two parties of the transaction coordinate the next operation, and regenerating the fund transfer scheme and broadcasting again by the sender according to the coordination result or 4.3 steps; or turning to the seventh step to terminate the transaction; if sufficient funds exist, the verification is successful, and the result of the successful verification is returned to the cross-link communication module of the sender, and the step is changed to 5.3;
and 5.3, the cross-link communication module of the sender reallocates funds in the fund pool according to the transaction transfer amount related in the fund transfer scheme, namely (the node IP address and the pre-stored fund amount) of the sender is changed into (the node IP address and the existing fund amount) to complete fund transfer, and the existing fund amount is the pre-stored fund amount-the transaction transfer amount and the transaction information is sent to the accounting module.
Sixthly, the accounting module of the receiver receives the transaction information sent by the cross-chain communication module in the step 5.3, and user nodes which acquire accounting rights by each block chain (including the block chain where the sender is located, the block chain where the receiver is located, and the MidChain) generate new blocks which are respectively put into the respective block chains to store the transaction information, wherein the method comprises the following steps:
6.1 the accounting module performs hash operation on the transaction information (an algorithm for converting a target text into a hash character string with the same length, and adopts SHA-256 hash algorithm in safety hash standard released by American national standards and technical research institute), and broadcasts the hash operation to the blockchain where the sender and the receiver are located and each user node on the intermediate chain.
6.2 each user node (including the chain where the sender is located, the chain where the receiver is located and all user nodes on the intermediate chain) contends for the accounting right by adopting a PoW consensus algorithm to perform calculation competition and selecting 1 user node with the strongest calculation. And finally, one user node of each block chain obtains the accounting right, a new block is generated on the block chain to which the user node belongs, and the block size, the transaction counter, the block header and the transaction information are put into the newly generated block. The values of the contents in the block are as follows:
6.2.1 Block size is determined as the byte size occupied by the entire block;
6.2.2 transaction counter is determined as the transaction times contained in the block;
6.2.3 the 6 data contained in the block header are assigned respectively:
6.2.3.1 the block ID is 00i (i is the block serial number, as the blocks increase, the value of i increases progressively according to the rule of n +1, n +2, n +3, …, n is the original number of blocks of the block chain to which the user node obtaining the accounting right belongs, and n is a positive integer);
6.2.3.2 the random number is a random number value obtained by the operation of the user node obtaining the accounting right when competing for the accounting right;
6.2.3.3 the last chunk hash value is the last chunk hash value;
6.2.3.4, the difficulty value is determined by the formula difficulty value is maximum target value ÷ current target value;
6.2.3.5 determining the time stamp of the generated block as the time of the block generation time;
6.2.3.6Merkle root hash is a hash value obtained by combining the transaction information by a Merkle Proof method;
6.2.4 the transaction information contains 6 data assigned values:
6.2.4.1 assigns the transaction record index number Mid- (i-1);
6.2.4.2 determining transaction resource content as resource content for a particular transaction;
6.2.4.3 determining the transaction transfer amount as the amount to be transferred for the particular transaction;
6.2.4.4 determining the sender address to be StartAddr;
6.2.4.5 determining the receiver address as EndAddr;
6.2.4.6 determining the time stamp of the generated transaction as the time of the transaction generation time;
and 6.3, synchronously downloading the newly generated blocks to respective local accounts by each user node on the block chain where the sender and the receiver are located and the intermediate chain.
And step seven, ending the cloud service transaction communication.
Claims (7)
1. A inter-cloud computing environment value exchange-oriented cross-chain communication method is characterized by comprising the following steps:
firstly, installing a cross-chain communication system in each user node on each block chain of the interplant computing environment, wherein the system consists of a cross-chain communication module, a node management module, a verification module and an accounting module; the user node on the block chain or the user node belonging to a certain block chain refers to a user terminal which synchronizes all blocks on the block chain to a local server and comprises a cloud service consumer and a cloud service provider;
the cross-link communication module is connected with a sender, namely a transaction sender, a receiver, namely a transaction receiver, a node management module, a verification module and an accounting module, is responsible for building an intermediate link and constructing a routing node fund pool, and is also responsible for communication among the sender, the receiver and the routing node and fund transfer; the method comprises the steps of determining a sender address and a receiver address according to a request sent by a sender, constructing an intermediate chain connecting the sender and the receiver according to the two addresses, and sending IP addresses of all user nodes on the intermediate chain to a node management module; the cross-link communication module receives the IP address of the routing node from the node management module, performs communication connection and cloud service transaction according to the routing node result, and simultaneously sends funds related to the transaction to the verification module; the cross-link communication module receives a transaction acceptance result from the verification module, and continues to execute the transaction or terminate according to the transaction acceptance result; after the cross-link communication module completes the transaction, the transaction information is sent to the accounting module;
the node management module is connected with the cross-chain communication module, receives the IP address of the user node on the intermediate chain from the cross-chain communication module, selects a routing node participating in cross-chain communication from the user node on the intermediate chain, and sends the IP address of the routing node to the cross-chain communication module;
the verification module is connected with the cross-chain communication module, receives the transaction fund from the cross-chain communication module, is responsible for verifying the validity and the availability of the transaction fund and returns the transaction verification result to the cross-chain communication module;
the accounting module is connected with the cross-chain communication module, the sender and the receiver, receives transaction information from the cross-chain communication module, and is responsible for generating an account book for the transaction and synchronizing the account book to all user nodes in a chain where the sender and the receiver are located;
secondly, a cross-chain communication module of the sender builds an intermediate chain between the sender and the receiver, and the method comprises the following steps:
2.1 the cross-chain communication module of the sender constructs a middle chain MidChain according to the sender address StartAddr and the receiver address EndAddr, and the method is as follows:
2.1.1 determining the intermediate chain data structure as a block chain, wherein the transaction information in the block comprises the following contents: transaction record index number, sender address, receiver address, transaction resource content, transaction transfer amount, and transaction timestamp generation; the transaction record index number is a serial number of each transaction record recorded in the ith block in the block chain according to a time sequence and is used for checking transaction information after fund verification and transaction are completed; the sender address refers to the IP address of the user node that initiated the transaction; the receiver address refers to the IP address of the user node receiving the transaction; the transaction resource content refers to cloud service resources provided by a cloud service provider to a cloud service consumer in a cloud service transaction; the transaction transfer amount refers to an amount required by a cloud service consumer to purchase a resource provided by a cloud service provider in a cloud service transaction; generating a time stamp of the transaction refers to a string of character sequences representing the transaction generation time; i is a positive integer;
2.1.2 initializing the first block of the intermediate chain;
2.1.3 creating a user node belonging to MidChain, wherein the method comprises the following steps: at least 5 different user node servers are selected from a block chain where a sender is located and a block chain where a receiver is located respectively to synchronize block information on MidChain, and the synchronized server addresses are recorded as IP addresses of the user nodes;
2.1.4 the cross-chain communication module of the sender sends all user node IP addresses on the middle chain to the node management module of the sender;
thirdly, the node management module of the sender receives the user node IP addresses belonging to MidChain from the cross-link communication module, and 1 user node is selected as a routing node, wherein the method comprises the following steps:
3.1 determining a candidate node range by adopting a PoW consensus algorithm;
3.2 from the candidate nodes selected by the PoW consensus algorithm, sequencing the commission charge required by the communication between the two parties of the connection transaction, and selecting the candidate node with the lowest commission charge as a routing node on MidChain, which is called the routing node for short;
3.3 the node management module of the sender sends the IP address of the routing node to the cross-link communication module of the sender;
fourthly, the cross-link communication module of the sender constructs a fund pool for the sender, the receiver and the selected routing node participating in the cross-link communication according to the IP addresses of the sender and the receiver and the IP address of the routing node received from the node management module, and fund transfer is carried out according to a fund transfer scheme negotiated by the sender and the receiver participating in the cross-link communication, and the method specifically comprises the following steps:
4.1 establishing independent fund pools for a sender, a receiver and a routing node participating in cross-link communication, namely representing the nodes and the corresponding pre-stored fund amount thereof by key value pairs in the form of 'node IP addresses and pre-stored fund amounts';
4.2 the three parties of the sender, the receiver and the routing node pre-store a part of funds in a fund pool, namely, the IP addresses of the three parties and the corresponding pre-stored fund values are respectively assigned to the 'node IP address and the pre-stored fund amount';
4.3 the sender broadcasts the fund transfer scheme to the routing node and the receiver, the routing node and the receiver receive the broadcast fund transfer scheme, check whether the fund transfer scheme is correct, if so, the receiver sends the confirmation result to the routing node, the routing node collects the confirmation result and signs, the fund transfer scheme with the signature is returned to the sender, meanwhile, the routing node and the receiver send the fund involved in the transaction to the verification module of the routing node and the receiver, and the fifth step is carried out; if not, the receiver sends the error information to the routing node, the routing node collects the error information and attaches the signature thereof, the error information is sent to the sender, the sender broadcasts again after checking and modifying the fund transfer scheme, and 4.3 steps are carried out; the fund transfer scheme content comprises fund transfer amount and routing node commission charge, the confirmation result is a result that the scheme content is considered to be correct, the confirmation result comprises a confirmation result of the routing node, and the error information comprises error information discovered by the routing node;
fifthly, the verification module of the receiver verifies the validity and the availability of the funds of the sender in an intelligent contract mode, and the verification method specifically comprises the following steps:
5.1 the judgment condition of inputting funds in the intelligent contract, namely a section of program which automatically executes the judgment action and is deployed in the verification module: judging whether the fund source is valid, namely whether the sender has enough funds to transfer;
5.2 traversing each block of the block chain to which the sender belongs, inquiring transaction information of the sender, namely transaction transfer amount and transaction resource content, judging whether the sender has enough funds for the transaction, namely whether the total amount of transferred funds minus the total amount of transferred funds of the sender is larger than the amount of funds required to be transferred for the transaction, if not, indicating that the verification fails, the fund transfer scheme is invalidated, coordinating two parties of the transaction to operate next step, and according to the coordination result, or turning to 4.3 steps, or turning to the seventh step to terminate the transaction; if sufficient funds exist, the verification is successful, and the result of the successful verification is returned to the cross-link communication module of the sender, and the step is changed to 5.3;
5.3 the cross-link communication module of the sender reallocates funds in the fund pool according to the transaction transfer amount related in the fund transfer scheme, namely changing 'node IP address, prestored fund amount' of the sender into 'node IP address, finishing fund transfer of the existing fund amount', and sending the transaction information to the accounting module, wherein the existing fund amount is the prestored fund amount-the transaction transfer amount;
sixthly, the accounting module of the receiver receives the transaction information sent by the cross-chain communication module, and new blocks are generated by the block chain where the sender is located, the block chain where the receiver is located and the user node which obtains the accounting right by the MidChain and are respectively put into the respective block chains, wherein the method comprises the following steps:
6.1 the accounting module broadcasts the transaction information to the block chain where the sender and the receiver are located and each user node on the intermediate chain after carrying out hash operation on the transaction information;
6.2 the chain of the sender, the chain of the receiver and all the user nodes on the intermediate chain compete for the accounting right, the method adopts a PoW consensus algorithm to carry out calculation competition, and 1 user node with the strongest calculation is selected; each block chain is provided with a user node finally to obtain the accounting right, a new block is generated on the block chain to which the user node belongs, and the block size, the transaction counter, the block head and the transaction information are put into the newly generated block;
6.3 the block chains where the sender and the receiver are located and each user node on the intermediate chain synchronously download the newly generated blocks to respective local accounts;
and step seven, ending the cloud service transaction communication.
2. The inter-cloud computing environment value exchange-oriented cross-chain communication method of claim 1, wherein the method for initializing the first block of the middle chain in step 2.1.2 is as follows:
2.1.2.1 determining the block size to be the byte size occupied by the entire block;
2.1.2.2 initializes the transaction counter to 0;
2.1.2.3 initialize the chunk header of the first chunk of the middle chain:
2.1.2.3.1 initializes the tile ID to 001;
2.1.2.3.2 initializes the random number to 0;
2.1.2.3.3 initializing the last chunk hash value to 0;
2.1.2.3.4 initialize a difficulty value to 0;
2.1.2.3.5 determining the time stamp of the generated block as the time of the block generation time;
2.1.2.3.6 initializing the Merkle root hash value to 0;
2.1.2.4 initializing transaction information in tiles:
2.1.2.4.1 initializes the transaction record index number to Mid-1-1;
2.1.2.4.2 initializing transaction resource content to null;
2.1.2.4.3 initializes the transaction transfer amount to 0;
2.1.2.4.4 determining the sender address to be StartAddr;
2.1.2.4.5 determining the receiver address as EndAddr;
2.1.2.4.6 initializes the timestamp of the generated transaction to 0.
3. The inter-cloud computing environment value exchange-oriented cross-chain communication method of claim 1, wherein the method for determining the candidate node range by adopting the PoW consensus algorithm in step 3.1 is as follows: performing power competition by adopting a PoW consensus algorithm, and selecting the first five user nodes with the strongest power as candidate nodes, wherein the strongest power means that the user nodes obtain a random number through operation fastest, so that the number obtained after the random number and 6 data in a block header are combined together by using a Merkle Proof method meets the set difficulty value, the difficulty value is the maximum target value divided by the current target value, the maximum target value is a fixed hash value, and the current target value is the current block, namely the newly generated block header hash value of the block.
4. The inter-cloud computing environment value exchange-oriented cross-chain communication method of claim 3, wherein the maximum target value is 0x00000000 FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF.
5. The inter-cloud computing environment value exchange-oriented cross-chain communication method of claim 1, wherein the method for putting the block size, the transaction counter, the block header and the transaction information into the newly generated block in step 6.2 is as follows:
6.2.1 Block size is determined as the byte size occupied by the entire block;
6.2.2 transaction counter is determined as the transaction times contained in the block;
6.2.3 the 6 data contained in the block header are assigned respectively:
6.2.3.1, the block ID is 00i, i is the block serial number, the value of i increases progressively according to the rule of n +1, n +2, n +3 and … as the blocks increase, n is the original number of blocks of the block chain to which the user node obtaining the accounting right belongs, and n is a positive integer;
6.2.3.2 the random number is a random number value obtained by the operation of the user node obtaining the accounting right when competing for the accounting right;
6.2.3.3 the last chunk hash value is the last chunk hash value;
6.2.3.4, the difficulty value is determined by the formula difficulty value is maximum target value ÷ current target value;
6.2.3.5 determining the time stamp of the generated block as the time of the block generation time;
6.2.3.6Merkle root hash is a hash value obtained by combining the transaction information by a Merkle Proof method;
6.2.4 the transaction information contains 6 data assigned values:
6.2.4.1 assigns the transaction record index number Mid- (i-1);
6.2.4.2 determining transaction resource content as resource content for a particular transaction;
6.2.4.3 determining the transaction transfer amount as the amount to be transferred for the particular transaction;
6.2.4.4 determining the sender address to be StartAddr;
6.2.4.5 determining the receiver address as EndAddr;
6.2.4.6 determines the timestamp of the generated transaction as the time of the transaction generation time.
6. The inter-cloud computing environment value exchange-oriented method for communication across links as recited in claim 1, wherein the hash operation in step 6.1 is an algorithm for converting a target text into a hash string having the same length, and employs SHA-256 hash algorithm.
7. The inter-cloud computing environment value exchange-oriented cross-chain communication method as claimed in claim 1, wherein the sender is a party who purchases the resource and pays an amount, and the receiver is a party who provides the resource and accepts the amount.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201711237256.4A CN108009811B (en) | 2017-11-30 | 2017-11-30 | Inter-cloud computing environment value exchange-oriented cross-chain communication method |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201711237256.4A CN108009811B (en) | 2017-11-30 | 2017-11-30 | Inter-cloud computing environment value exchange-oriented cross-chain communication method |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN108009811A CN108009811A (en) | 2018-05-08 |
| CN108009811B true CN108009811B (en) | 2021-06-04 |
Family
ID=62055455
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201711237256.4A Active CN108009811B (en) | 2017-11-30 | 2017-11-30 | Inter-cloud computing environment value exchange-oriented cross-chain communication method |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN108009811B (en) |
Families Citing this family (69)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108805704A (en) * | 2018-05-16 | 2018-11-13 | 深圳市网心科技有限公司 | Block chain service implementation method, audiomonitor, storage medium and system |
| CN108717634A (en) * | 2018-05-16 | 2018-10-30 | 横琴密达科技有限责任公司 | A kind of limitation block chain method of commerce and system |
| CN113283988B (en) * | 2018-05-29 | 2024-12-03 | 蚂蚁链技术有限公司 | Asset transfer method and device, electronic equipment |
| CN108964935A (en) * | 2018-05-29 | 2018-12-07 | 张迅 | Message accounting and charging method |
| CN108876572A (en) | 2018-05-29 | 2018-11-23 | 阿里巴巴集团控股有限公司 | The account checking method and device, electronic equipment of block chain transaction |
| CN108876606B (en) * | 2018-05-29 | 2021-02-09 | 创新先进技术有限公司 | Asset transfer method and device and electronic equipment |
| CN108805712B (en) | 2018-05-29 | 2021-03-23 | 创新先进技术有限公司 | Fallback processing method and device for asset transfer, and electronic equipment |
| CN110557334B (en) * | 2018-06-01 | 2021-12-28 | 本无链科技(深圳)有限公司 | Cross-link network interconnection method and system |
| CN110428237B (en) * | 2018-06-07 | 2021-05-14 | 腾讯科技（深圳）有限公司 | Resource processing method and device, storage medium and electronic device |
| CN109035012B (en) * | 2018-06-11 | 2020-11-17 | 西安纸贵互联网科技有限公司 | Cross-chain processing method of block chain system and computer readable storage medium |
| US11646879B2 (en) * | 2018-06-12 | 2023-05-09 | Electronics And Telecommunications Research Institute | Method and apparatus for selecting distributed consensus node based on proof of nonce |
| CN108876370B (en) * | 2018-06-12 | 2021-12-17 | 北京航空航天大学 | System architecture for sharing open data by crossing block chains under heterogeneous multi-chain architecture |
| CN108876618A (en) * | 2018-06-15 | 2018-11-23 | 浙江华信区块链科技服务有限公司 | A kind of exchange block catenary system and corresponding universal block chain mutual operation method and network |
| CN109035016B (en) * | 2018-06-28 | 2020-10-23 | 杭州复杂美科技有限公司 | Multi-chain concurrent transaction method |
| CN110705973B (en) * | 2018-07-10 | 2023-05-16 | 深圳市红砖坊技术有限公司 | Consensus method and blockchain system applied to miner nodes in blockchain system |
| CN109087131A (en) * | 2018-07-18 | 2018-12-25 | 青岛陶知电子科技有限公司 | A kind of garbage classification and reward on total mark system based on block chain framework |
| CN108985742B (en) * | 2018-07-19 | 2022-04-05 | 深圳市迅雷网络技术有限公司 | Transaction processing method, device and blockchain system |
| CN109241490B (en) * | 2018-07-26 | 2023-05-09 | 南京思利华信息科技有限公司 | Block chain-oriented X11 dynamic hash method and device |
| CN109102261A (en) * | 2018-08-02 | 2018-12-28 | 刘卓 | Based on the encryption currency for matching the decentralization for winning banknote, safety, power saving |
| CN109255056B (en) * | 2018-08-16 | 2021-05-25 | 北京京东尚科信息技术有限公司 | Data reference processing method, device, equipment and storage medium of block chain |
| CN110866823B (en) * | 2018-08-28 | 2022-09-23 | 傲为有限公司 | Public link-based transaction method and block chain system |
| CN109345714A (en) * | 2018-08-31 | 2019-02-15 | 华北电力大学（保定） | A charging pile and a charging network operation method for an electric vehicle |
| CN109272311A (en) * | 2018-09-29 | 2019-01-25 | 亚洲数字科技有限公司 | A kind of across chain flogic system based on digital wallet |
| CN109523380A (en) * | 2018-10-29 | 2019-03-26 | 中链科技有限公司 | Across chain method of commerce and device |
| EP3651112B1 (en) * | 2018-11-06 | 2025-04-09 | Electricité de France | Method for processing data and apparatuses for implementing the same |
| CN109462505B (en) * | 2018-11-12 | 2021-07-30 | 上海点融信息科技有限责任公司 | Method and apparatus for implementing cross-link communication between multiple blockchain networks |
| CN111199398B (en) * | 2018-11-16 | 2024-06-21 | 上海派链信息科技有限公司 | Methods, apparatus, computer readable storage media, and computer program products for cross-blockchain asset management |
| CN109493050B (en) * | 2018-11-21 | 2021-08-03 | 北京蓝石环球区块链科技有限公司 | Transfer method based on block chain main chain and parallel multiple sub-chains |
| CN111222876B (en) * | 2018-11-26 | 2022-11-11 | 本无链科技(深圳)有限公司 | Method and system for solving cross-chain coupling |
| CN109583896A (en) * | 2018-11-30 | 2019-04-05 | 元灵通智能科技（深圳）有限公司 | Transaction verification method, block chain node and storage medium |
| CN109639656B (en) * | 2018-12-03 | 2020-12-25 | 北京瑞卓喜投科技发展有限公司 | Block chain private data transmission method and private data transmission system |
| CN109615515B (en) * | 2018-12-05 | 2021-08-24 | 腾讯科技（深圳）有限公司 | Credit right certificate transfer method, device, electronic equipment and storage medium |
| CN111382119B (en) * | 2018-12-29 | 2023-08-22 | 华为技术有限公司 | Block data archiving method and related equipment |
| CN109784881A (en) * | 2018-12-29 | 2019-05-21 | 广州蓝石信息技术有限公司 | General across chain payment scheme based on decentralization gateway |
| CN109886661A (en) * | 2019-01-16 | 2019-06-14 | 深圳壹账通智能科技有限公司 | Across chain digital cash exchanging method, device, computer system and storage medium |
| KR102185191B1 (en) * | 2019-01-22 | 2020-12-01 | (주)에스투더블유랩 | Method and system for analyzing transaction of cryptocurrency |
| CN109978539B (en) * | 2019-03-01 | 2022-04-22 | 海南新软软件有限公司 | Progress prompting method, device and system for digital asset address transfer |
| CN110245517A (en) * | 2019-05-29 | 2019-09-17 | 杭州秘猿科技有限公司 | A kind of across chain method, apparatus, system and the electronic equipment of block chain |
| CN110264204B (en) * | 2019-06-06 | 2022-04-19 | 杭州趣链科技有限公司 | A blockchain cross-chain transaction method based on smart contract sequencing |
| CN110278264B (en) * | 2019-06-20 | 2023-02-21 | 深圳前海微众银行股份有限公司 | Block chain-based cross-link communication method and device and transaction system |
| US11251966B2 (en) | 2019-06-28 | 2022-02-15 | Advanced New Technologies Co., Ltd. | Sending cross-chain authenticatable messages |
| CN110443704B (en) * | 2019-06-28 | 2021-02-19 | 创新先进技术有限公司 | Method and device for sending resources in cross-link mode |
| CN110311790B (en) | 2019-06-28 | 2020-07-28 | 阿里巴巴集团控股有限公司 | A method and apparatus for sending certifiable messages across chains |
| CN110430235B (en) * | 2019-06-28 | 2020-11-03 | 创新先进技术有限公司 | Method, apparatus, storage medium and computing device for sending certifiable messages across chains |
| US11356282B2 (en) | 2019-06-28 | 2022-06-07 | Advanced New Technologies Co., Ltd. | Sending cross-chain authenticatable messages |
| US11336451B2 (en) | 2019-06-28 | 2022-05-17 | Advanced New Technologies Co., Ltd. | Cross-blockchain resource transmission |
| CN110689435B (en) * | 2019-08-02 | 2022-05-27 | 上海分布信息科技有限公司 | Data processing method and data processing system based on block chain |
| CN116886601A (en) | 2019-09-12 | 2023-10-13 | 华为技术有限公司 | Computing power routing method and device |
| CN110706104B (en) * | 2019-09-12 | 2022-07-15 | 杭州秘猿科技有限公司 | Proprietary chain construction method and system |
| CN112633868B (en) * | 2019-10-08 | 2023-04-14 | 橙载(上海)信息技术有限公司 | Cross-chain asset transfer method based on intelligent contract implementation |
| CN110993044B (en) * | 2019-11-28 | 2023-03-28 | 周口师范学院 | Lightweight dynamic autonomous cross-link interaction method for medical alliance link |
| CN111107075A (en) * | 2019-12-13 | 2020-05-05 | 中国工商银行股份有限公司 | Request response method and device, electronic equipment and computer-readable storage medium |
| CN111010441B (en) * | 2019-12-18 | 2022-12-13 | 深圳市迅雷网络技术有限公司 | A blockchain cross-chain method, system and electronic equipment |
| CN112837048B (en) * | 2020-02-03 | 2022-08-19 | 腾讯科技（深圳）有限公司 | Cross-block-chain data processing method, device, equipment and computer storage medium |
| CN111401868B (en) * | 2020-03-19 | 2022-07-01 | 南开大学 | Minimum-cost block chain down-link transaction routing algorithm |
| CN111582845A (en) * | 2020-04-30 | 2020-08-25 | 北京金山云网络技术有限公司 | Cross-chain transaction method and device of block chain and electronic equipment |
| CN111538791B (en) * | 2020-05-07 | 2023-09-22 | 深圳创客区块链技术有限公司 | Block chain multiple-cross-chain mutual protection method, device and storage medium |
| CN111597228B (en) * | 2020-05-13 | 2023-06-20 | 山大地纬软件股份有限公司 | Multi-chain system and method for improving expansibility of block chain |
| CN111598553A (en) * | 2020-05-29 | 2020-08-28 | 北京俩撇科技有限公司 | Method and device for creating block chain, data cross-chain and sales block chain and personal block chain |
| CN112016923A (en) * | 2020-08-28 | 2020-12-01 | 北京大学深圳研究生院 | Intra-network cross-domain identity management method and system based on block chain and computational power network |
| CN112287029B (en) * | 2020-11-17 | 2023-05-16 | 北京物资学院 | A blockchain multi-chain cross-chain system and its implementation mechanism |
| CN112637127B (en) * | 2020-11-23 | 2022-05-13 | 北京邮电大学 | A method and device for cross-blockchain communication |
| WO2022141059A1 (en) * | 2020-12-29 | 2022-07-07 | 合肥达朴汇联科技有限公司 | Method and system for cross-chain exchange of blockchain information, electronic device, and storage medium |
| CN112598523A (en) * | 2020-12-30 | 2021-04-02 | 广东微聚科技有限公司 | Aggregation block chain system |
| CN113709037B (en) * | 2021-08-17 | 2022-06-14 | 电子科技大学 | A method and device for selecting routing nodes for cross-chain transactions |
| CN116095074B (en) * | 2021-11-01 | 2025-11-04 | 中移（杭州）信息技术有限公司 | Resource allocation methods, devices, related equipment and storage media |
| CN115563214B (en) * | 2022-09-27 | 2025-12-02 | 东软集团股份有限公司 | Blockchain networking system and blockchain networking method |
| CN117834642B (en) * | 2024-03-04 | 2024-05-17 | 中国人民解放军国防科技大学 | A method, system and storage medium for distributed generation of massive QR codes |
| CN119515376A (en) * | 2024-10-30 | 2025-02-25 | 杭州高新区(滨江)区块链与数据安全研究院 | Path determination method, device, server and computer program product |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106503589A (en) * | 2016-10-26 | 2017-03-15 | 北京瑞卓喜投科技发展有限公司 | The method of calibration of block chain Transaction Information correctness, apparatus and system |
| CN106790145A (en) * | 2016-12-28 | 2017-05-31 | 上海优刻得信息科技有限公司 | A kind of high in the clouds Data Hosting system and high in the clouds Data Hosting method |
| CN107077674A (en) * | 2016-12-29 | 2017-08-18 | 深圳前海达闼云端智能科技有限公司 | Transaction verification processing method and device and node equipment |
-
2017
- 2017-11-30 CN CN201711237256.4A patent/CN108009811B/en active Active
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106503589A (en) * | 2016-10-26 | 2017-03-15 | 北京瑞卓喜投科技发展有限公司 | The method of calibration of block chain Transaction Information correctness, apparatus and system |
| CN106790145A (en) * | 2016-12-28 | 2017-05-31 | 上海优刻得信息科技有限公司 | A kind of high in the clouds Data Hosting system and high in the clouds Data Hosting method |
| CN107077674A (en) * | 2016-12-29 | 2017-08-18 | 深圳前海达闼云端智能科技有限公司 | Transaction verification processing method and device and node equipment |
Non-Patent Citations (1)
| Title |
|---|
| 云服务传递网络资源动态分配模型;史佩昌等;《计算机学报》;20111231;第34卷(第12期);第2305页-第2317页 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN108009811A (en) | 2018-05-08 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN108009811B (en) | Inter-cloud computing environment value exchange-oriented cross-chain communication method | |
| JP7771259B2 (en) | METHOD AND SYSTEM FOR MINING BLOCKCHAIN TRANSACTIONS PROVIDED BY VALIDATOR NODES | |
| US20230113492A1 (en) | Computer-implemented system and method for managing transactions over a blockchain network | |
| EP3754578B1 (en) | Blockchain-based settlement method, blockchain node and client | |
| CN110659906B (en) | Bill information processing method, related device and medium | |
| WO2020059865A1 (en) | Settlement system, settlement method, user device, and settlement program | |
| WO2020173499A1 (en) | Public chain-based sub-blockchain construction method and system | |
| US20210233068A1 (en) | Settlement system, settlement method, user device, and settlement program | |
| CN107995003A (en) | The charging and settlement method of international roaming communication, relevant apparatus and distributed system | |
| CN115801288B (en) | Verification method, system and equipment based on block chain and zero knowledge proof | |
| CN108711056A (en) | A kind of retrospective block catenary system and method for centralization | |
| CN112231741B (en) | Data processing method, device, medium and electronic equipment based on block chain system | |
| CN111311211A (en) | A blockchain-based data processing method and device | |
| CN114629735B (en) | State interaction method, device, equipment and medium based on multiparty state channel | |
| Nguyen et al. | A blockchain-based iterative double auction protocol using multiparty state channels | |
| CN116029825A (en) | Block chain transaction method, device and system, electronic equipment and storage medium | |
| CN110602252A (en) | Block chain enhanced open Internet of things access architecture | |
| CN112788555A (en) | Cross-operator telephone charge transfer settlement method, device and computing equipment | |
| Yamamoto et al. | Examination on interoperability of blockchains by using ZK-rollups | |
| US12314937B2 (en) | Implementing blockchain-based token attribution with reduced computational complexity | |
| WO2024164550A1 (en) | Blockchain data processing method and apparatus, device, and storage medium | |
| WO2024244318A9 (en) | Blockchain-based data processing method and apparatus, device, and storage medium | |
| CN113435949B (en) | Decentralized federal machine learning method, system and storage medium based on intelligent contracts | |
| CN117291595A (en) | Block chain-based data processing method, device, equipment and readable storage medium | |
| WO2022216205A1 (en) | Method and apparatus for secure communication using two different blockchain protocols |
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 |