CN111181715B - Multi-party cross-linking method based on consistent Hash consensus protocol - Google Patents
Multi-party cross-linking method based on consistent Hash consensus protocol Download PDFInfo
- Publication number
- CN111181715B CN111181715B CN201911395852.4A CN201911395852A CN111181715B CN 111181715 B CN111181715 B CN 111181715B CN 201911395852 A CN201911395852 A CN 201911395852A CN 111181715 B CN111181715 B CN 111181715B
- Authority
- CN
- China
- Prior art keywords
- node
- chain
- user
- nodes
- proposal
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
- H04L9/0643—Hash functions, e.g. MD5, SHA, HMAC or f9 MAC
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
- G06Q20/3827—Use of message hashing
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- 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
- H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
- H04L67/1004—Server selection for load balancing
- H04L67/1008—Server selection for load balancing based on parameters of servers, e.g. available memory or workload
-
- 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
- H04L67/1095—Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
- G06F2009/4557—Distribution of virtual machine instances; Migration and load balancing
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Abstract
The invention discloses a multi-party cross-linking method based on a consistent Hash consensus protocol, which comprises the following steps: (1) formulating a consensus protocol for the multi-party cross-chain system; (2) finding out the position of the corresponding virtual node according to a consistent hash algorithm; (3) the multi-party users perform interaction (4) and store user data to corresponding virtual nodes; (5) and requesting multi-party cross-chain verification interaction (6), triggering an intelligent contract to perform a cross-chain consensus process after receiving a verification interaction request, passing the interactive verification, and completing data cross-chain after consensus is achieved. The multi-party cross-chain method can realize the high-efficiency consensus among cross-chains, and improves the efficiency of the consensus through the consistent hash algorithm so as to realize the load balance of the system during the cross-chain interaction of multiple parties.
Description
Technical Field
The invention belongs to the technical field of block chains, and particularly relates to a multi-party cross-chain method based on a consistent Hash consensus protocol.
Background
The block chain is essentially a decentralized distributed chain system, the system can comprise mutual cooperation of a plurality of chains, the unique distributed chain structure realizes uplink data traceability, and functions of non-falsification, non-forgery and the like are realized on the basis of a cryptography technology and a consensus mechanism, so that safety and data sharing among the plurality of chains of the block chain are coordinated. However, the problems of interoperability and consistency between blockchain chains are gradually highlighted because of the strong specificity and the wide variety of each chain on the blockchain and the increase of the number of applied multi-chain channels of the blockchain.
The core technology of distributed systems is the consensus technology. In the P2P network of the distributed system of the blockchain, the process that nodes which are not trusted with each other finally reach data consistency by following a preset mechanism is called a consensus process, so that data of all nodes of the blockchain whole network are shared by a distributed consistency protocol. The cross-chain technology is more and more concerned by people, and designing an efficient consensus mechanism to improve the throughput of the block chain cross-chain process gradually becomes one of the key problems of the cross-chain. Currently, there are three more common types of cross-chain techniques that are generally defaulted:
(1) the notary mechanism (notary schemes) refers to that a notary is elected to supervise an event on a certain chain and automatically execute a corresponding event on another chain through an intelligent contract. And the notarization people perform consensus verification on the event through a preset consensus mechanism.
(2) Side chains or relays (sidechains/relays) refer to that based on a light client authentication technology, whether a certain specific transaction, event or state information of a certain chain occurs or not is verified by verifying a cryptographic hash tree (cryptographic hash tree) and a block header (block header) of the certain chain, and then the certain specific transaction, event or state information is automatically executed on another chain through an intelligent contract.
(3) Hash-locking (Hash-locking) refers to that a specific intelligent contract is operated on a chain where two parties performing transaction are located, so that cross-chain transaction and information interaction are achieved. The process of realizing cross-chain transaction through hash locking comprises the following steps: a) the user A generates a random number s, calculates the hash value of the random number and sends the hash value to the user B; b) a and B lock respective assets through smart contracts; c) if B receives correct s in a certain time, automatically executing the asset transfer of B to A through an intelligent contract, otherwise returning to B; d) if A receives correct random number s in a certain time period, the asset of A will be automatically transferred to B, otherwise returned to A.
The common consensus mechanisms include POW (workload certification), POS (rights and interests certification), DPOS (rights and interests certification), BFT (byzantine fault-tolerant algorithm), a new consensus mechanism formed by combining different consensus mechanisms, or a new consensus algorithm formed by improving various consensus algorithms, such as POW + POS, BFT + POS, etc., or DBFT, PBFT, etc., and various consensus methods based on a consistency algorithm, such as Paxos, Raft, etc., where the consistency hash algorithm allocates storage tasks based on a hash function, thereby realizing load balancing of servers when the system processes the tasks. In general, the state of the art for evaluating the consensus mechanisms requires the following conditions to be met: (1) safety: whether common attacks can be prevented and whether the fault tolerance is good. (2) Expansibility: the scalability mainly considers the changes of system load and network traffic caused by the increase of the number of system members and the number of transactions to be confirmed, which are usually measured by the network throughput. (3) Performance: the system can process the number of confirmed transactions per second, which can also be measured in terms of network throughput. (4) Resource consumption: the consensus mechanism on the blockchain achieves consensus by means of computational resources or network communication resources.
Aiming at a certain block chain application scene, cross-chain consensus is realized, which relates to the selection of the cross-chain mode, a consensus mechanism is correspondingly deployed on the basis of the selected cross-chain mode, the condition of reaching an ideal consensus state is met, and efficient cross-chain consensus is realized by matching with a certain scene of a block chain.
It can be said that cross-chain technology is key to implementing a blockchain, particularly a value network for a federation chain or a private chain. At present, in a federation chain, organizations realize service isolation and data access by building channels, a consensus mechanism is a core for realizing consistency among the organizations, and different organizations on the chain are allowed to own respective chains by the support of the federation chain and a private chain, and even multiple chains are allowed to run simultaneously in the same organization. At present, the number of global block chains is continuously increased, and networks of different block chains are mutually isolated, so that operations such as digital asset transfer, cross-chain communication and the like cannot be effectively executed among the chains. However, the main problems to be solved by the design and development of the mainstream cross-chain technology mainly include: asset transfer between different blockchains, implementation of settings to freeze asset lock and unlock conditions on a blockchain (and then associated with other chain-specific events or actions), reading and verifying status or events of other chains, enhancing blockchain transaction processing capabilities.
It can be seen that the current cross-chain technology cannot solve the growing demand of blockchain for cross-chain consensus, and various effective solutions are urgently needed to be proposed.
Disclosure of Invention
Based on the background and the problems in the prior art, the invention proposes a multi-party chain crossing method based on a consistent Hash consensus protocol, which can realize efficient consensus among chains. It is yet another object of the present invention to improve the efficiency of consensus through a consistent hashing algorithm to keep the load balance of the system in the process of cross-chaining of multiple parties. To achieve these objects and other advantages in accordance with the purpose of the invention, a multi-party cross-chaining method based on a consistent hash consensus protocol is provided, where a user U ═ { U ═ is1，U2，……，UnThe cross-chain interaction occurs between the two, and corresponding resources, U, need to be paid outiThe method generally refers to the ith user, and comprises the following implementation steps:
(1) formulating a consensus protocol for the multi-party cross-link system, and solving the user U according to the hash function of the consistent hash algorithmiWherein the user UiIn the chain XiThe above step (1);
(2) finding user U according to hash valueiWhen the corresponding virtual nodes are positioned on the Hash ring and cross-link interaction is prepared, a protocol of an interaction demand set A of each user is formulated;
(3) user U ═ { U ═ U1，U2，……，UnThe ith user is interacted with the ith user, and the interaction requirement matrix of the ith user is Ai＝(ai1，ai2，……，aij，……，aim) Wherein a isijE.g. Z, representing the requirement condition of the ith user for the jth interaction, wherein m represents m data objects, namely representing the requirement condition of m interactions;
(4) from user UiStarting from the position of (A), finding the first node along the direction d, and connecting UiWherein d is generally clockwise;
(5) according to user UiDistributing required resource e for the interaction requirement condition, solving the position of data related to the interaction on a hash ring according to a hash function of a consistent hash distribution algorithm, corresponding to the data related to the user and the interaction by searching a node position table, and in a chain XiUser U ofiForward the need to on-chain XxUser U ofxRequesting to verify the interactive content;
(6) and receiving a verification interaction request, triggering an intelligent contract, executing a cross-chain consensus protocol, passing the verification of the interaction content, and completing the cross-chain transfer of the resource after the consensus is achieved.
Preferably, the consistent Hash consensus protocol in step (1) further includes a user UiNodes forming various processing messages, including proposal nodes, for proposing interactive proposals (proposal number PID and proposal content V); the consensus node participates in the process of verifying consensus; the backup node acquires an approved proposal; (theoretically, all nodes in the blockchain may be a proposed node, a consensus node, and a backup node).
The specific implementation method comprises the following steps:
1.1 preparation (Prepare) phase: the proposal node generates a globally unique and incremental PID, and sends a request message (for carrying out consensus verification) for preparing a verification proposal, which only carries the PID, to all the consensus nodes, wherein the content of the message at the moment does not need to carry the proposal content V;
1.2 verification (verify) phase: proposing a proposal (including PID and V) by the proposing node, verifying the proposal by the consensus node, and showing that the whole network agrees with the proposal through verification and all the nodes are ready to receive the proposal;
1.3 receiving (Accept) phase: after receiving the messages that the verification of the majority of the consensus nodes passes, the proposal node sends a notice of preparing a backup proposal to the backup node, and the backup node uniformly distributes node processing for each proposal by adopting a consistent hash algorithm aiming at the data object type represented by the PID in each received message, thereby realizing the load balance of the data processed and proposed by the nodes;
1.4 backup (back-up) phase: the proposal node informs a backup node of preparing backup for the proposal which passes the verification, the proposal which passes the verification and reaches the consistency consensus is sent to the backup node, and the backup node carries out backup, wherein, m is more than 0.5n and less than or equal to n, and n is all nodes of the whole network;
1.5 recovery (reply) phase: and after each backup node finishes the backup, replying to the proposal node, and continuously finishing the cross-chain transfer of the corresponding interactive resources through the proposal node.
The object of the present invention can be further achieved by the consistent hash algorithm in step (1) or (2), in the process of achieving load balancing by using the consistent hash algorithm, the number of actual servers N is set to be N, service is provided for users, the number of virtual nodes is P, where P is much larger than N, and when there are fewer servers, virtual nodes need to be correspondingly added, the method includes:
2.1 equally dividing the Hash ring into P intervals;
2.2 each interval takes each virtual node as an end address, and each virtual node is responsible for mapping the key value of the corresponding interval;
2.3 after the key value is subjected to modulus extraction, carrying out one-time modulus extraction operation on the number of the intervals to find out a corresponding virtual node;
2.4 setting weight E of storage server according to storage capacity and performance, setting storage reference value N0Is set to E0Comparing the storage of each server with the storage reference value of the server to obtain
Then, the P virtual nodes are listed according to the weight { E1，E2，……，EnIs averagely allocated to the corresponding node U ═ U1，U2，……，UnStorage server of { N } {1，N2，……，Nn}；
2.5 when the storage server or the node changes (when a new server or a node is added or quitted), the virtual node is acquired or released according to the weight value E of the server or the resource E required by the node. If the distribution of the nodes is changed, a large influence is caused on the existing redistribution of the data, so when the storage server is changed, the virtual nodes need to be acquired or released according to the weight values of the storage server, that is, the corresponding relationship between the virtual nodes and the server influences the change of the consistent hash structure.
In this way, since the number of virtual nodes as a whole does not change much, when the storage server or the node (user) changes, the influence on the whole system is minimized. The newly added server or node (user) only needs to integrally migrate the load of other virtual nodes, so that repeated hash calculation on information during data migration can be avoided, and load balance of the system is ensured. Because the weight is added to each storage server, when the system senses that the system has a data imbalance condition (including data overload, underload and balance states), the task allocation state (including storage, processing, calculation and the like) of the virtual node can be dynamically adjusted according to the weight of the storage server.
Preferably, the process of implementing load balancing further comprises: setting a standard threshold value as s% and a virtual node load highest threshold value as LHThe minimum load threshold is LLWhen L is presentH-LL>And s%, when the data overload occurs when the data overload exceeds the threshold value, distributing the virtual nodes corresponding to the high-load storage nodes to the low-load nodes according to the weight, so that the overall load value is lower than s%, and realizing the dynamic adjustment of the load.
Further, the step (3) includes: in the process of interaction of the user U, the total amount of related resources meets the conditions: u may constitute the interactable matrix A if and only if the equation is satisfied
When the user is in use, the interaction can be smoothly carried out.
Preferably, the step (4) or the process of implementing load balancing further includes implementing virtual node data backup and live migration, where the step of implementing virtual node data backup includes: according to the storage and processing capacity of the server or each node, distributing the tasks matched with the capacity of the server or each node,the capacity is matched, namely the size of the stored data and the resource demand condition are considered, namely the task is distributed according to the weight E occupied by the server or the resource E required by the node. The step of dynamically adjusting the state of the virtual node in response to the data migration condition further includes: when L isH-LL<s%, when the data is in a low load state, recalculating the positions of the nodes, updating the node position table, and migrating corresponding data according to a consistent hash algorithm and a recalculation result (at the moment, the data is migrated according to a new node mapping rule, and the load of each node after migration is balanced); when L isH-LLWhen s%, it is in a load balancing state.
Preferably, the implementation method of step (5) is to implement a multi-party cross-chain consensus protocol by deploying an intelligent contract on a blockchain, and the implementation steps include:
3.1 user UiGenerating a random number r, calculating the hash value h of the random number h-hash (r), and sending the hash value h-hash (r) to an interactive object Ux；
3.2 UiAnd UxSequentially locking respective resources through an intelligent contract;
3.3 if UxReceiving the message that the interactive proposal passes the verification within the time T and receiving the correct r, the intelligent contract automatically executes to connect the UiAsset transfer to UxOtherwise, return to UiExecute U in the same wayiTo UxThe resource transfer of (2);
further, in step (1) or step (6), the master node is a node issuing a proposal, i.e. a proposed node, and the slave node is a node verifying the proposal, i.e. a consensus node, and the step of implementing cross-chain consensus includes:
4.1 Xichain master node UiBroadcasting interactive proposal to XxNode U on the chainx；
4.2 XiChain and XxThe main nodes on the chains broadcast respectively to prepare for interacting to the slave nodes of the respective chains;
4.3 Xichain and XxThe slave nodes on the chain respectively verify the interaction to be carried out, and broadcast the prepared interaction message to the slave nodes after the verification is passedXiChain and XxAll nodes on the chain;
4.4 Xichain and XxThe nodes of the chain receive X with the number of miNodes on the chain, and a number m of XxNode-on-chain-same prepare message post broadcast acknowledgement (Commit) message to XiChain and XxAll nodes on the chain;
4.5 Xichain and XxThe nodes of the chain receive X with the number of miNodes on the chain, and a number m of XxThe nodes on the same network agree on the same confirmation message.
Additional advantages, objects, and features of the invention will be set forth in part in the description which follows and in part will become apparent to those having ordinary skill in the art upon examination of the following or may be learned from practice of the invention. The beneficial effects of the invention at least comprise: the cross-chain consensus protocol generates hash values for all users (nodes) based on a hash function of a consistent hash algorithm, configures virtual nodes on a hash ring, stores data on the virtual nodes, correspondingly finds addresses of related data through a list of user stored data, and dynamically adjusts data migration conditions caused by changes of a storage server or the users (nodes) by setting a load threshold value, thereby realizing dynamic load balancing. The cross-chain consensus method can realize multi-party interaction based on the alliance chain, but is not limited to the cross-chain consensus method, by designing the multi-party cross-chain consensus method (which can be understood as a combination of a Paxos + PBFT consensus method), the interaction verification is realized, and on the basis of ensuring that consensus can be successfully achieved, basic conditions of safety, expansibility, high performance and low resource consumption to be met by consensus are met, namely the safety of cross-chain interaction is ensured, the throughput of cross-chain interaction is improved through a consistent hash algorithm, the interaction efficiency among different chains is improved, and the increasingly-growing cross-chain consensus requirement on a block chain is met. And supervision and inspection on the interactive proposal and the interactive process are realized.
Drawings
FIG. 1 is a schematic diagram of the overall architecture of the present invention;
FIG. 2 is a diagram of a consensus protocol process based on a consistent hashing algorithm according to the present invention;
FIG. 3 is a flow chart of cross-chain consensus according to the present invention.
Detailed Description
In order to clearly illustrate the present invention and make the objects, technical solutions and advantages of the embodiments of the present invention clearer, the technical solutions in the embodiments of the present invention are clearly and completely described below with reference to the drawings in the embodiments of the present invention, so that those skilled in the art can implement the technical solutions by referring to the description text, and the interactive processes of the specific implementations can be described by using the common asset transaction process as an example, so as to facilitate the understanding of those skilled in the art.
Specific example 1:
1. fig. 1 shows an overall architecture schematic diagram of a multi-party cross-link method based on a consistent hash consensus protocol according to an implementation form of the present invention, and the schematic diagram shows a model for carrying the method of the present invention, where a user U ═ { U ═ U { (U } { (U) } { (U } { (U } U { (U } U } U } @1，U2，……，UnCross-chain transactions occur between, assets need to be transferred, UiThe method is characterized by generally referring to the ith user and specifically comprising the following steps:
(1) formulating a consensus protocol for the multi-party cross-link system to realize smooth verification transaction, further ensuring the asset safety of the user, and solving the user U according to the hash function of the consistent hash algorithmiWherein the user UiIn the chain XiThe above step (1);
(2) finding user U according to hash valueiWhen the corresponding virtual nodes are positioned on the Hash ring and cross-link transaction is prepared, a protocol of a transaction requirement set A of each user is formulated;
(3) user U ═ { U ═ U1，U2，……，UnThe transaction is carried out, and the transaction requirement matrix of the ith user is Ai＝(ai1，ai2，……，aij，……，aim) Wherein a isijE.g. Z, representing the demand situation of the ith user for the jth transaction, wherein m represents m data objects, namely representing the demand situation of m transactions;
(4) from user UiStarting from the position of the virtual node, finding the first node along the direction d, and connecting the U with the first nodeiWherein d is generally clockwise;
(5) according to user UiDistributing required assets e according to the transaction requirement condition, solving the position of transaction data on a hash ring according to a hash function of a consistent hash distribution algorithm, matching users and the transaction data by searching a node position table, and performing X-ray linkiUser U ofiForward the need to on-chain XxUser U ofxRequesting a validation transaction;
(6) and receiving a verification transaction request, triggering an intelligent contract, executing a cross-chain consensus protocol, passing the transaction verification, and completing the cross-chain asset transfer after consensus is achieved.
Specific example 2:
2. in another example, the invention is used to implement a consensus protocol based on a consistent hashing algorithm, as shown in fig. 2. Using this approach has the advantage of achieving system load balancing. Also, this manner is merely an illustration of a preferred example, but not limited thereto. When the method and the device are implemented, the implementation mode of the application scene can be changed according to the requirements of a user. The consistent Hash consensus protocol in the step (1) further comprises a user UiNodes for composing various kinds of processing messages, including proposal nodes, for proposing transaction proposals (proposal number PID and proposal content V); and (3) consensus nodes: participating in the process of verifying consensus; backup node: an approved proposal is obtained. All nodes in the blockchain may be a proposal node, a consensus node, and a backup node. All notification messages contain only PIDs. The specific implementation method comprises the following steps:
1.1 preparation (Prepare) phase: the proposal node generates a unique and incremental PID, and sends a request message (for carrying out consensus verification) for preparing a verification proposal, which only carries the PID, to all the consensus nodes, wherein the content of the message at the moment does not need to carry the proposal content V; (ii) a
1.2 verification (verify) phase: proposing a proposal by the proposing node, verifying the proposing content by the consensus node, and showing that the whole network agrees on the proposal (transaction) through verification and all the nodes are ready to receive the transaction of the proposal;
1.3 receiving (Accept) phase: after receiving the messages passing the verification of the m consensus nodes, the proposal node sends a notice of preparing backup proposals to the backup node, and the backup node uniformly distributes node processing for each proposal by adopting a consistent hash algorithm aiming at the transaction data type represented by the PID in each received message, thereby realizing the load balance of the node processing proposals;
1.4 backup (back-up) phase: the proposal node informs the backup node to prepare for backing up the proposed data according to the proposal that the verification passes, sends the proposal that the verification passes, namely the proposal that the consistency is identified, to all the backup nodes, and the backup nodes back up, wherein m is more than 0.5n and less than or equal to n, and n is all the nodes of the whole network;
1.5 recovery (reply) phase: after each backup node finishes the backup, the proposal node is replied, and the proposal node which passes the verification continues to finish the transaction (the cross-chain transfer of the corresponding interactive resource).
The object of the present invention can be achieved by that in step (1) or (2), a consistent hash algorithm is used to implement load balancing, in the process of implementing load balancing, the number of actual servers N is set to be N, so as to provide services for users, the number of virtual nodes is P, where P is much larger than N, and when there are fewer servers, virtual nodes need to be correspondingly added, and the method includes:
2.1 equally dividing the Hash ring into P intervals;
2.2 each interval takes each virtual node as an end address, and each virtual node is responsible for mapping the key value of the corresponding interval;
2.3 after the key value is subjected to modulus extraction, carrying out one-time modulus extraction operation on the number of the intervals to find out a corresponding virtual node;
2.4 setting weight E of storage server according to storage capacity and performance, setting storage reference value N0And is set to E0Comparing the storage of each server with the storage reference value of the server to obtain
Then, the P virtual nodes are listed according to the weight { E1，E2，……，EnIs allocated to a corresponding node U ═ U1，U2，……，UnStorage server of { N })1，N2，……，Nn}；
2.5 when the storage server or node (user) changes (when a new server or node is added or quitted), the virtual node is acquired or released according to the weight value E of the server or the resource E required by the node. If the distribution of the nodes is changed, a large influence is caused on the redistribution of the existing data, so that when the storage server or the nodes (users) are changed, the virtual nodes need to be acquired or released according to the weight values of the nodes, that is, the corresponding relationship between the virtual nodes and the server influences the change of the consistent hash structure.
In this way, since the number of virtual nodes as a whole does not change much, when the storage server or the node (user) changes, the influence on the whole system is minimized. The newly added server or node (user) only needs to integrally migrate the load of other virtual nodes, so that repeated hash calculation on information during data migration can be avoided, and load balance of the system is ensured. Because the weight is added to each storage server, when the system senses that the system has a data imbalance condition (including data overload, underload and balance states), the task allocation state (including storage, processing, calculation and the like) of the virtual node can be dynamically adjusted according to the weight of the storage server.
For example, the system standard threshold is set to 15%, and when the maximum load threshold of the system virtual node is set to LHAnd a load minimum threshold LLWhen compared to the virtual nodes of, i.e. when LH-LL>15%, when the load exceeds the threshold value, the system judges that data overload occurs, and at the moment, the virtual nodes corresponding to the high-load storage nodes are distributed to the low-load nodes according to the weight, so that the overall load value is lower than 15%, and the dynamic adjustment of the load is realized.
Specific example 3:
3. FIG. 3 shows a cross-chain system for implementing the present inventionThe flow chart of recognition, which takes the transfer of asset transaction as an example, illustrates the specific implementation process of multi-party cross-chain recognition in the present invention. Wherein the step (3) comprises: in the process of carrying out transaction by the user U, the total amount of related assets meets the conditions: u may constitute a tradable matrix A if and only if the equation is satisfied
In time, the transaction can be smoothly performed.
The step (4), or the process of implementing load balancing, further includes implementing virtual node data backup and live migration, where the step of implementing virtual node data backup includes: and distributing tasks matched with the capacity of the server or each node according to the storage and processing capacity of the server or each node, wherein the capacity is matched, namely the size of the stored data and the requirement condition of assets are considered, namely the tasks are distributed according to the weight E occupied by the server or the assets E required by the nodes. The step of dynamically adjusting the state of the virtual node in response to the data migration condition further includes: when L isH-LL<15%, when the data is in a low load state, recalculating the positions of the nodes, updating the node position table, and migrating corresponding data according to the consistent hash algorithm and the recalculation result (at the moment, the data is migrated according to a new node mapping rule, and the load of each node after migration is balanced); when L isH-LLWhen 15%, the load is balanced.
The method realizes the consensus protocol of multi-party cross-chain by deploying intelligent contracts on the block chain, and comprises the following specific implementation steps:
3.1 user UiGenerating a random number r, calculating the hash value h of the random number to hash (r), and sending the hash value h to a transaction object Ux；
3.2 UiAnd UxLocking respective assets in sequence through an intelligent contract;
3.3 if UxReceiving the message that the transaction proposal is verified within the time T and receiving the correct r, the intelligent contract automatically executes to connect UiAsset transfer to UxOtherwise, return to UiExecute U in the same wayiTo UxThe asset transfer of (2);
further, in step (1) or step (6), the master node is a node issuing a proposal, i.e. a proposal node, and the slave node is a node verifying the proposal, i.e. a consensus node, and the steps of implementing multi-party cross-chain consensus are as follows:
4.1 Xichain master node UiBroadcasting a transaction proposal to XxNode U on the chainx；
4.2 XiChain and XxThe master nodes on the chains respectively broadcast the slave nodes ready to carry out transactions to the respective chains;
4.3 Xichain and XxThe slave nodes on the chain respectively verify the prepared transaction, and broadcast the prepared transaction message to X after the verification is passediChain and XxAll nodes on the chain;
4.4 Xichain and XxThe nodes of the chain receive X with the number of miNodes on the chain, and a number m of XxNode-on-chain-same prepare message post broadcast acknowledgement (Commit) message to XiChain and XxAll nodes on the chain;
4.5 Xichain and XxThe nodes of the chain receive X with the number of miNodes on the chain, and a number m of XxThe nodes on the same group agree upon the same acknowledgement message.
The embodiments described above are presented to enable a person having ordinary skill in the art to make and use the invention. It will be readily apparent to those skilled in the art that various modifications to the above-described embodiments may be made, and the generic principles defined herein may be applied to other embodiments without the use of inventive faculty. Therefore, the present invention is not limited to the above embodiments, and those skilled in the art should make improvements and modifications to the present invention based on the disclosure of the present invention within the protection scope of the present invention.
Claims (8)
1. A multi-party cross-linking method based on a consistent Hash consensus protocol is characterized in that a user U is { U ═ U-1，U2，……，UnThe cross-chain interaction occurs between the two, and resources are paid out, UiThe method generally refers to the ith user in a user U, n is the number of all nodes in the whole network, and the specific implementation steps comprise:
(1) formulating a consensus protocol for the multi-party cross-link system, and solving the user U according to the hash function of the consistent hash algorithmiWherein the user UiIn the chain XiThe above step (1);
(2) finding user U according to hash valueiWhen the position of the corresponding virtual node on the hash ring is ready for cross-link interaction, a protocol of an interaction demand set A of each user is formulated;
(3) user U interacts with the ith user UiThe interaction requirement matrix is Ai＝(ai1，ai2，……，aij，……，aim) Wherein a isijE.g. Z, representing the requirement condition of the ith user on the jth interaction, wherein m represents the number of m data objects;
(4) from user UiStarting from the position of the virtual node, finding the first adjacent virtual node along the direction d, and connecting the U with the virtual nodeiTo the first adjacent virtual node;
(5) according to user UiDistributing required resources e for the interaction requirement condition, solving the position of data related to the interaction on a hash ring according to a hash function of a consistent hash distribution algorithm, and matching a user U by searching a node position tableiAnd interaction data involved in the interaction, in chain XiUser U ofiForward the need to on-chain XxUser U ofxIs locked, UxGenerally refers to the xth user of users U, where x is 1, 2, … …, n, requesting authentication of the interactive content;
(6) and receiving a verification interaction request, triggering an intelligent contract, executing a cross-chain consensus protocol, passing the interactive verification, and completing the cross-chain transfer of resources after consensus is achieved.
2. The multiple-party cross-chaining method based on consistent Hash consensus protocol according to claim 1, wherein the consistent Hash consensus protocol in step (1)And also includes user UiThe nodes forming various types of processing messages comprise proposal nodes and are used for proposing interactive proposals, and the proposals comprise proposal numbers PID and proposal contents V; the consensus node participates in the process of verifying consensus; the backup node acquires the approved proposal, and all nodes in the block chain can be proposal nodes, consensus nodes and backup nodes; all notification messages contain only PIDs; the protocol consists of:
1.1 preparation phase: the proposal node generates a unique and incremental PID and sends a request message carrying only the PID for preparing verification proposal to all the consensus nodes;
1.2 verification phase: proposing a proposal by the proposing node, verifying the proposal by the consensus node, and informing all nodes to prepare for receiving the proposal after the proposal is verified;
1.3 receiving stage: after receiving the messages passing the verification of the m consensus nodes, the proposal node sends a notice of preparing backup proposals to the backup node, and the backup node adopts a consistent Hash algorithm to evenly distribute node processing for each proposal aiming at the data object type represented by the PID in each received message;
1.4 backup stage: the proposal node informs the backup node of preparing to backup the proposal aiming at the proposal passing the verification, the proposal passing the verification is sent to the backup node, and the backup node carries out backup, wherein, m is more than 0.5n and less than or equal to n, and n is the number of all nodes in the whole network;
1.5 recovery stage: and after each backup node finishes the backup, replying the proposal node, and continuously finishing the cross-chain transfer of the corresponding interactive resources through the proposal node which passes the verification.
3. The multi-party cross-linking method based on the consistent hash consensus protocol according to claim 1, wherein in step (1) or (2), a consistent hash algorithm is used to implement a load balancing process, the number of storage servers is set to n, n is the number of all nodes in the whole network, and provides services for users, the number of virtual nodes is P, where P is much larger than n, and when there are fewer servers, virtual nodes need to be correspondingly added, the method comprising:
2.1 equally dividing the Hash ring into P intervals;
2.2 each interval takes each virtual node as an end address, and each virtual node is responsible for mapping the key value of the corresponding interval;
2.3 after the key value is subjected to modulus extraction, carrying out one-time modulus extraction operation on the number of the intervals to find out a corresponding virtual node;
2.4 setting weight value E of storage server according to storage capacity and performance, setting initial value of weight value E as E0Setting a storage reference value N0Comparing the stored value N of each storage servernAnd a storage reference value N of the storage server0Obtaining the weight value of each storage server
Then, the P virtual nodes are listed according to the weight { E1，E2，……，En……，EPAnd averagely allocating the user U to the corresponding user U ═ U1，U2，……，UnThe storage server of (1);
2.5 when the storage server or the virtual node changes, the virtual node is obtained or released according to the weight value E of the storage server or the resource E required by the virtual node.
4. The method of claim 3, wherein the process of implementing load balancing further comprises: setting a standard threshold value as s% and a virtual node load highest threshold value as LHThe minimum load threshold is LLWhen L is presentH-LL>And s%, when the data overload occurs when the data overload exceeds the threshold value, distributing the virtual nodes corresponding to the high-load storage nodes to the low-load nodes according to the weight, so that the overall load value is lower than s%, and realizing the dynamic adjustment of the load.
5. The multiple-party cross-chaining method based on the consistent Hash consensus protocol according to claim 1, wherein the step (3) comprises: resources involved in the process of interaction of the user UThe total amount satisfies the condition: the user U may form the interactable requirement matrix A if and only if the equation is satisfied
When the user is in use, the interaction can be smoothly carried out.
6. The multiparty cross-chaining method based on the consistent hash consensus protocol according to claim 1, 3 or 4, wherein in the step (4), or a process of implementing load balancing, further comprising implementing virtual node data backup and live migration, wherein the step of implementing virtual node data backup comprises: distributing tasks matched with the capacity of the server or each virtual node according to the storage and processing capacity of the server or each virtual node, wherein the capacity matching comprises the step of distributing the tasks according to the weight value E occupied by the storage server or the resources E required by the user by considering the data size and the resource demand condition of the storage content; the step of dynamically adjusting the state of the virtual node in response to the data migration condition further includes: when L isH-LL<s%, when data is in low load, recalculating each virtual node position, updating the virtual node position table, migrating corresponding data according to the consistent Hash algorithm and the recalculation result, and when L% is in low load, recalculating each virtual node position, and transferring corresponding data according to the consistent Hash algorithm and the recalculation resultH-LLWhen the load is s%, the load is balanced.
7. The multi-party cross-linking method based on the consistent hashing consensus protocol according to claim 1, wherein the step (5) is implemented by deploying an intelligent contract on a blockchain to implement the multi-party cross-linking consensus protocol, and the implementation steps include:
3.1 user UiGenerating a random number r, calculating a hash value of the random number r, and sending the hash value to a user U of an interactive objectx；
3.2 user UiAnd user UxSequentially locking respective required resources through an intelligent contract;
3.3 if user UxReceiving the message that the interactive proposal passes the verification within the time T and receiving the correct random number r, the intelligent contract automatically executes the user UiRequired resources of to user UxOtherwise, returning to the user UiSimilarly execute user UiTo user UxThe resource transfer of (2);
8. the multiparty cross-chaining method based on the consistent hash consensus protocol according to claim 1, wherein in step (1) or step (6), the master node is a proposal node, the slave node is a consensus node, and the step of implementing multiparty cross-chaining consensus comprises:
4.1 Xithe main node on the chain broadcasts an offer of interactive content to XxA master node on a chain;
4.2 Xichain and XxThe main nodes on the chains respectively broadcast messages to be interacted to the slave nodes of the respective chains;
4.3 Xichain and XxThe slave nodes of the chain respectively verify the interaction to be carried out, and broadcast the interaction preparation message to X after the verification is passediChain and XxAll nodes on the chain;
4.4 Xichain and XxThe master node of the chain receives X with the number of miNodes on the chain, and a number m of XxBroadcast acknowledgement message to X after the same prepare message of the master node in the chainiChain and XxAll nodes on the chain;
4.5 Xichain and XxThe master node of the chain receives X with the number of miNodes on the chain, and a number m of XxThe master nodes on the same node agree upon the same acknowledgement message.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201911395852.4A CN111181715B (en) | 2019-12-30 | 2019-12-30 | Multi-party cross-linking method based on consistent Hash consensus protocol |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201911395852.4A CN111181715B (en) | 2019-12-30 | 2019-12-30 | Multi-party cross-linking method based on consistent Hash consensus protocol |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN111181715A CN111181715A (en) | 2020-05-19 |
| CN111181715B true CN111181715B (en) | 2022-07-12 |
Family
ID=70657585
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201911395852.4A Active CN111181715B (en) | 2019-12-30 | 2019-12-30 | Multi-party cross-linking method based on consistent Hash consensus protocol |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN111181715B (en) |
Families Citing this family (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111666345A (en) * | 2020-06-29 | 2020-09-15 | 深圳技术大学 | Financial derivative transaction information sharing method, distributed system and electronic terminal |
| WO2022000172A1 (en) * | 2020-06-29 | 2022-01-06 | 深圳技术大学 | Method for sharing transaction information of financial derivative, distributed system, and electronic terminal |
| CN111538792B (en) * | 2020-07-10 | 2020-11-03 | 卓尔智联(武汉)研究院有限公司 | Alliance link data processing method and device and electronic equipment |
| CN112463761A (en) * | 2020-11-05 | 2021-03-09 | 杭州云象网络技术有限公司 | Cross-chain cooperative platform construction method and system for dynamic unbalanced application environment |
| CN112632164B (en) * | 2020-12-21 | 2022-09-13 | 杭州云象网络技术有限公司 | Universal cross-chain programming interface method for realizing trusted authority access |
| CN112819628B (en) * | 2021-02-01 | 2024-02-02 | 网易（杭州）网络有限公司 | Transaction replay prevention detection method, device and system, electronic equipment and storage medium |
| CN112801665B (en) * | 2021-03-19 | 2021-08-24 | 北京万物智链科技有限公司 | Cross-chain transaction method and system based on server relay |
| CN112804262B (en) * | 2021-03-19 | 2021-07-27 | 北京万物智链科技有限公司 | Safety guarantee method and system in block chain cross-chain communication |
| CN113821340A (en) * | 2021-08-27 | 2021-12-21 | 济南浪潮数据技术有限公司 | Dynamic balancing method, system, terminal and storage medium of distributed system |
| CN113708937B (en) * | 2021-10-28 | 2022-03-01 | 湖南天河国云科技有限公司 | Processing method and system for block chain transaction |
| CN114884962B (en) * | 2022-04-29 | 2024-03-26 | 蚂蚁区块链科技(上海)有限公司 | Load balancing method and device and electronic equipment |
| CN115865943B (en) * | 2022-11-23 | 2024-03-08 | 南方电网数字电网研究院有限公司 | Adaptive dynamic cross-link consensus mechanism selection method |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108256864A (en) * | 2018-02-13 | 2018-07-06 | 中链科技有限公司 | Between a kind of block chain across the foundation of chain alliance and communication means, system |
| CN109919615A (en) * | 2019-03-01 | 2019-06-21 | 上海分布信息科技有限公司 | Across chain data interactive method and across chain data interaction system based on block chain |
| CN110288345A (en) * | 2019-06-26 | 2019-09-27 | 深圳市网心科技有限公司 | Across chain communication means, device, main chain node and storage medium |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US10812274B2 (en) * | 2015-05-07 | 2020-10-20 | Blockstream Corporation | Transferring ledger assets between blockchains via pegged sidechains |
| US20190172026A1 (en) * | 2017-12-02 | 2019-06-06 | Alchemy Limited LLC | Cross blockchain secure transactions |
-
2019
- 2019-12-30 CN CN201911395852.4A patent/CN111181715B/en active Active
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108256864A (en) * | 2018-02-13 | 2018-07-06 | 中链科技有限公司 | Between a kind of block chain across the foundation of chain alliance and communication means, system |
| CN109919615A (en) * | 2019-03-01 | 2019-06-21 | 上海分布信息科技有限公司 | Across chain data interactive method and across chain data interaction system based on block chain |
| CN110288345A (en) * | 2019-06-26 | 2019-09-27 | 深圳市网心科技有限公司 | Across chain communication means, device, main chain node and storage medium |
Non-Patent Citations (1)
| Title |
|---|
| 基于哈希锁定的多方跨链协议研究;张诗童 等;《网络空间安全》;20181130;全文 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN111181715A (en) | 2020-05-19 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN111181715B (en) | Multi-party cross-linking method based on consistent Hash consensus protocol | |
| US20200387503A1 (en) | Blockchain Maintenance Method and Apparatus, Server, and Computer-Readable Storage Medium | |
| CN111311414B (en) | Block chain multiparty consensus method based on consistent hash algorithm | |
| US11811910B2 (en) | Blockchain maintenance method and apparatus, server, and computer-readable storage medium | |
| US10887090B2 (en) | Scalable byzantine fault-tolerant protocol with partial tee support | |
| AU2019203861B2 (en) | System and method for ending view change protocol | |
| Marandi et al. | Multi-ring paxos | |
| US7543020B2 (en) | Distributed client services based on execution of service attributes and data attributes by multiple nodes in resource groups | |
| AU2019203862B2 (en) | System and method for ending view change protocol | |
| Quesnel et al. | Cooperative and reactive scheduling in large‐scale virtualized platforms with DVMS | |
| CN107886328A (en) | Transaction processing method, device, computer equipment and storage medium | |
| Buchnik et al. | Fireledger: A high throughput blockchain consensus protocol | |
| Ranjan et al. | Coordinated load management in peer-to-peer coupled federated grid systems | |
| Lim et al. | Scalable and leaderless Byzantine consensus in cloud computing environments | |
| Huang et al. | Blockchain based log system | |
| Bezerra et al. | Ridge: high-throughput, low-latency atomic multicast | |
| Li et al. | Jenga: Orchestrating smart contracts in sharding-based blockchain for efficient processing | |
| Kapoor et al. | Hierarchical chord-based resource discovery in intercloud environment | |
| CN110730241B (en) | Global scale oriented blockchain infrastructure | |
| Set et al. | Service-aware dynamic sharding approach for scalable blockchain | |
| Ghosh et al. | Towards a democratic federation for infrastructure service provisioning | |
| Flauzac et al. | CONFIIT: a middleware for peer-to-peer computing | |
| Chen | Scaling Byzantine Fault-Tolerant Consensus With Optimized Shading Scheme | |
| Sun et al. | RPCC: A Replica Placement Method to Alleviate the Replica Consistency under Dynamic Cloud | |
| Hanamakkanavar et al. | Load balancing in distributed systems: a survey |
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 |