CN113381861B - Improved Ripple consensus method suitable for unlicensed chain - Google Patents
Improved Ripple consensus method suitable for unlicensed chain Download PDFInfo
- Publication number
- CN113381861B CN113381861B CN202110665513.4A CN202110665513A CN113381861B CN 113381861 B CN113381861 B CN 113381861B CN 202110665513 A CN202110665513 A CN 202110665513A CN 113381861 B CN113381861 B CN 113381861B
- Authority
- CN
- China
- Prior art keywords
- node
- nodes
- core
- consensus
- transaction
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
-
- 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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Hardware Redundancy (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
An improved Ripple consensus method suitable for an unlicensed chain relates to the technical field of block chains and is used for solving the problems that the existing Ripple consensus protocol is difficult to ensure the security and the activity of a network and is not suitable for a weak synchronous network environment due to the fact that the existing Ripple consensus protocol depends on synchronous time hypothesis. The technical points of the invention comprise: the Ripple consensus protocol is improved from three aspects: by adopting a specific trust model and corresponding UNL selection guidance, the method is easy to meet the safety and activity conditions during actual deployment; a main node and a view switching mechanism are added to solve the problem that the Ripple mentioned in the previous research may be inactivated in some extreme scenes; the strong synchronous clock and the time-out mechanism of the Ripple in the consensus process are removed, so that the method is suitable for the weak synchronous hypothesis network. Experimental results show that the method can realize the throughput of tens of thousands of transactions per second within the time delay of no more than half a minute, and the view switching mechanism hardly generates additional overhead. The invention is suitable as consensus support for unlicensed chains.
Description
Technical Field
The invention relates to the technical field of block chains, in particular to an improved Ripple consensus method suitable for an unlicensed chain.
Background
Ripple, one of the most well-known blockchain items, plays the role of a bridge between different currencies, an internet transaction protocol that allows people to pay in any currency. The Ripple network adopts the Ripple consensus protocol as the consensus support to ensure the network consistency. The Ripple consensus protocol is a Byzantine fault-tolerant consensus protocol with distributed trust characteristics, which means that each node in the network can select a subset of trust from all nodes (i.e., UNL) and agree only on the proposals of the nodes in the UNL, ignoring the proposals of the other nodes. Compared with Byzantine Fault Tolerance (BFT) consensus of other centralized trust models (such as PBFT and the like), the Ripple consensus protocol is more suitable for diversified trust networks. The design of UNL ensures that the Ripple consensus protocol is secure when nodes have a sufficiently large UNL intersection.
However, given that achieving consensus under a distributed trust model is a more complex matter, the security and activity of the Ripple consensus protocol has been at issue. The Ripple original white paper considers that under the assumption that the number of Byzantine nodes does not exceed 20% of the number of UNL nodes, when the UNL intersection between any two nodes exceeds 20% of the larger UNL of the two nodes, the safety can be guaranteed. In subsequent studies, this condition proved to be wrong, the correct conclusion being that the UNL intersection must exceed 60% of the average size of the two UNLs, and even in extremely network degrading environments, the threshold would be raised to 90%. This is difficult to meet in a real-world deployment, especially in the unlicensed chain without any UNL selection guidance. Although current Ripple networks require that nodes collectively trust a trusted community containing 5 nodes, this is still not flexible and scalable. The liveness of the Ripple consensus protocol is another issue, as in the Chase et al paper[1]Was analyzed for the first time. However, a subsequent study showed that in an extreme case, the system might be deactivated even if only one byzantine node sends conflicting transactions to different nodes. Therefore, the activity is difficult to be secured in the Ripple consensus.
Another disadvantage of Ripple consensus is that it relies on a synchronization time assumption, as it needs to rely on a global heartbeat timer to run and enter the next phase, which is reflected in Ripple's source code. This is in sharp contrast to BFT consensus protocols under other weak synchronous or asynchronous assumptions. Due to the randomness of the network delay, it is not practical to have all nodes have synchronized clocks, and to assume that enough messages can arrive within the timeout.
Disclosure of Invention
In view of the above problems, the present invention provides an improved Ripple consensus method applicable to an unlicensed chain, so as to solve the problems that the existing Ripple consensus protocol is difficult to ensure the security and activity of a network and is not suitable for a weakly synchronous network environment due to the dependence on the assumption of synchronous time.
An improved Ripple consensus method applicable to an unlicensed chain is characterized in that a core set consisting of a plurality of nodes is configured in a block chain consensus network in advance, the nodes in the core set are defined as core nodes, and a trusted node list of the core nodes is the core set; nodes in the blockchain consensus network, which do not belong to a core set, are defined as leaf nodes, and the trust node list of the leaf nodes is a subset of the core set and the leaf nodes are self; the implementation process of the improved Ripple consensus method comprises the following steps:
step one, a submission stage:
selecting a core node as a main node according to the current view number, wherein the main node firstly receives a plurality of transactions submitted by a client; then, verifying the received multiple transactions and packaging the transactions into a transaction set; then broadcasting the transaction set to other nodes in the block chain consensus network for consensus;
step two, an opening stage:
generating and broadcasting their respective initial offers when the other nodes receive the transaction set;
step three, establishing:
each node in other nodes iteratively proposes transactions in a plurality of rounds until a legal set in a trusted node list proposes an identical transaction set, submits the transaction set to a latest closed account book of the node, and broadcasts a verification message about the state of the latest closed account book updated by the node;
step four, an accepting stage:
and when one legal person set in the trust node list of each node in other nodes has the same latest closed account book, updating and applying the updated account book to the complete verification account book of the node to complete a consensus process.
Further, the specific process of each node generating and broadcasting its initial proposal in step two is as follows: after receiving the transaction set, the node initializes the current state of the node, wherein the state comprises the number of rounds and the proposed states of other nodes except the node; then, whether the current self works on the preferred account book is checked, and if not, the self is switched to the preferred account book; and then, checking whether the current self works on the preferred account book, and if not, switching to the preferred account book.
Further, the specific implementation process of each node in the third step in the establishing stage is as follows:
step three, in each round, the node continuously receives proposals from the nodes in the trust node list and updates the locally maintained proposal state;
step two, after the node receives the proposal of a legal person set from the trust node list in the current round, the node calculates the ticket number of all the affairs according to the latest proposal of the node in the trust node list, if the ticket number of the affairs exceeds the preset threshold value of the current round, the affairs can be proposed by the node in the next round;
step three, after the node broadcasts a new proposal, checking whether all nodes in the trust node list reach consensus or not, and if the consensus is confirmed, submitting the transaction list reaching the consensus to the recently closed account book;
and step three, broadcasting a verification message by the node, wherein the verification message comprises the state of the latest closed account book after the node is updated.
Further, the third step confirms that the principle of consensus is achieved: if there is a legal set proposed transaction list that is the same as the node and the legal sets all claim to be updated based on the same book, then it is confirmed that consensus has been reached for the transaction list.
Further, the specific implementation process of each node in the fourth step in the accepting stage is as follows: the method comprises the steps of locally maintaining the latest verification state of a trusted node list of an account according to received verification messages, and updating a fully verified account into the account when the account is supported by a legal set in the trusted node list.
Further, in the step one, when the master node does not receive a legal and uncommitted transaction requested to be submitted by the client, but other core nodes in the core set receive the transaction submission request, the core node receiving the transaction submission request starts a timer and forwards the transaction submission request to the master node, and when the legal transaction is submitted, the timer is halted; and restarting the timer when other legal and uncommitted transaction requests are received again, and executing the view switching operation if the timer is overtime, namely the legal transaction is not committed.
Further, the specific process of view switching operation is as follows: when a core node captures the overtime exception of the timer, the core node stops receiving messages of an open stage and a set-up stage, and then broadcasts a view switching message to all other core nodes, wherein the view switching message comprises the current latest closed account book state of the core node and all found but uncommitted transactions; when one core node receives the view switching message of more than 20% of the core nodes in the core set and does not broadcast the view switching message, the node stops receiving the message and broadcasts the view switching message;
when a master node corresponding to the next view in the core set receives a view switching message with the same view number from a legal set of a trusted node list of the master node, broadcasting a new view message to all nodes, wherein the new view message comprises: the view switching method comprises the steps that a preferred account book is obtained according to the account book in all view switching messages, all transactions which are contained in the view switching messages and are not submitted to the preferred account book, and all received view switching messages with signatures;
when other nodes receive and verify the new view message, adding all uncommitted transactions into respective candidate sets, updating the latest closed account book of the candidate sets into a preferred account book, and broadcasting a new view received message; and when a new view receiving message with the same view number is received from a legal person set of the trust node list, the view switching is completed.
Further, on the premise that the size of the legal set is 80% of the total number of the core nodes and the number of the byzantine nodes does not exceed 20% of the total number of the core nodes, the conditions for ensuring the network security are as follows:
wherein x represents the total number of core nodes; a represents the number of core nodes contained in a subset selected from a core set by a trust node list of a leaf node; x and a are both positive integers;
the conditions for ensuring the activity of the leaf nodes are as follows: a is more than or equal to 4.
Further, in case of extreme network degradation, the conditions for ensuring network security are:
x>9
further, the nodes communicate with each other through the Gossip protocol.
The beneficial technical effects of the invention are as follows:
the invention provides an improved Ripple consensus method applicable to an unlicensed chain, which improves Ripple from three aspects of deployability, activity and time hypothesis, firstly, nodes are divided into core nodes and leaf nodes, UNL selection guidance is provided to enable the nodes to be easily deployed in reality, and the scheme meets the requirements of safety and activity; the situation that the system is possibly inactivated is avoided by adding a main node and a view switching mechanism, and the scheme is proved to be effective by theory and experiments; in addition, the synchronous clock and the timeout of a Ripple open phase and a setup phase are removed, so that the method is more suitable for a weak synchronous network environment. Experiments show that the method can meet the performance requirements of the unlicensed chain on time delay and throughput, and is suitable for being used as consensus support of the unlicensed chain.
Drawings
The invention may be better understood by referring to the following description in conjunction with the accompanying drawings, in which like reference numerals are used throughout the figures to indicate like or similar parts. The accompanying drawings, which are incorporated in and form a part of this specification, illustrate preferred embodiments of the present invention and, together with the detailed description, serve to further explain the principles and advantages of the invention.
FIG. 1 is an exemplary diagram of a trust model in the present invention;
FIG. 2 is a flow chart of the present invention for performing a consensus process;
FIG. 3 is a diagram illustrating a view switch execution process according to the present invention;
FIG. 4 is a graph of average latency versus kernel set size in the experiment of the present invention;
FIG. 5 is a time delay comparison diagram of the open phase and the set-up phase in the experiment of the present invention;
FIG. 6 is a graph of throughput variation for different batch sizes and node sizes in the experiment of the present invention;
FIG. 7 is a diagram illustrating view switching overhead for different kernel set sizes in the experiment of the present invention.
Detailed Description
In order that those skilled in the art will better understand the disclosure, exemplary embodiments or examples of the disclosure are described below with reference to the accompanying drawings. It is obvious that the described embodiments or examples are only some, but not all embodiments or examples of the invention. All other embodiments or examples obtained by a person of ordinary skill in the art based on the embodiments or examples of the present invention without any creative effort shall fall within the protection scope of the present invention.
The invention provides an improved scheme Ripple + based on a Ripple consensus protocol, which improves the Ripple consensus protocol from three aspects: ripple + makes it easy to meet the security and activity conditions at the time of actual deployment by adopting a specific trust model and corresponding UNL selection guidance; 2. a main node and a view switching mechanism are added to solve the problem that the Ripple mentioned in the previous research may be inactivated in some extreme scenes; 3. the strong synchronous clock and the time-out mechanism of the Ripple in the consensus process are removed, so that the method is suitable for the weak synchronous hypothesis network. The method specifically comprises the following steps:
deployability: the new scheme adopts a core set to ensure the security of consensus, nodes in the set trust each other, and the core set is selected as the UNL. The core set is of indeterminate size and needs to be preconfigured before consensus begins. The core set reflects the current network state and the core nodes are more reliable, but still follows the assumption that there are at most 20% byzantine nodes in the UNL, i.e. there may also be byzantine nodes in the core set. Other nodes that do not belong to the core set are called leaf nodes, which select a subset of the core set plus themselves as the UNL set. Leaf nodes can freely join or leave the network without affecting consensus process. In this way, the problem that the Ripple is difficult to deploy in reality to meet the safety is solved. While the Ripple project has a similar idea as the present invention when actually deployed, the Ripple + of the present invention is more flexible and extensible because leaf nodes have the right to choose which core nodes to trust, rather than having to trust the entire core set.
Activity: previous studies have demonstrated that the core set itself may be inactivated even if only one byzantine node broadcasts conflicting transactions in the open phase. The solution of the invention is to select a node from the core set as master node at any time. In the open phase, the main node is responsible for receiving the transaction from the client, packaging and broadcasting the transaction to all nodes through the Gossip network, and other nodes have no right to broadcast the transaction in the open phase. When legal transactions are not written into the account book after a period of time, the timeout is triggered, a view switching mechanism is executed, and the main node becomes the next node in the core set. The system may resume operation after a period of time based on the assumption that no more than 20% of the byzantine nodes in the core set.
The time assumption is that: the synchronous time assumption in the original Ripple consensus protocol makes it difficult to adapt to the asynchronous application environment of the internet. In Ripple, the synchronous clock and timeout are mainly used in the open phase and the setup phase. In Ripple +, because the master node is responsible for packaging all transactions from the client and broadcasting the transactions to all nodes in the open phase, when other nodes receive the broadcast message from the master node, the master node can enter the setup phase without a timeout mechanism; in the setup phase, the end condition of each iteration is changed, i.e. when the node receives more than 80% of the node messages in the UNL set, it updates its proposal and enters the next iteration.
Most of the assumptions of the present invention are based on native ripples. In particular, Ripple + operates in an open system with byzantine nodes, each maintaining a list of trusted nodes (UNL). The node makes a decision only based on the proposal of the node in its UNL. There is a subset of nodes in the network, where all nodes choose the subset itself as their UNL, called the core set, and the nodes in the core set are called core nodes. All core nodes trust each other, and the core set is the basis for ensuring security and activity. At any time, a node in the core set is selected as the master node, which is responsible for receiving transactions submitted by clients and broadcasting the transactions over the gossip network. When a timeout occurs, the master node will switch to the next node in the core set, which helps ensure system activity in the possible deactivation scenario described above. Nodes in the network that do not belong to the core set are called leaf nodes, which select themselves and a subset of the core set as their UNL. Leaf nodes are free to join and leave the network. Following the assumption of Ripple, the legal set (i.e., quorum) is set to be 80% of the UNL of nodes, and the byzantine node percentage does not exceed 20%. The set of legal persons is a set for helping the node to make a decision, and if the node has one set of legal persons, all nodes in the set of legal persons agree to one thing, the node agrees to the thing.
In the system, a node needs to maintain two types of accounts: the Last Closed Ledger (LCL) is the latest ledger that records all transactions that reach consensus in the consensus period, and the Full Validated Ledger (FVL) is the result of the validation of the last closed ledger. The fully validated ledger represents the state of the current network. Under normal circumstances, two correct nodes will submit the same ordered transaction set based on the same book, thus generating a completely consistent new book. However, the Ledger may still diverge due to failure or network delay, and at this time, the node checks whether it works on the Preferred Ledger (Preferred Ledger) according to the respective Ledger status of the node in its UNL, and if not, switches to the Preferred Ledger (Preferred Ledger).
Assuming that all core nodes and their addresses are public to the entire network, this means that there is a reliable authorized point-to-point channel between each correct pair of core nodes to ensure that messages can be transmitted correctly. In contrast, leaf nodes are unknown to the entire network, with core nodes and leaf nodes communicating through the Gossip network. A leaf node may join the Gossip network by informing several core nodes of its address.
Compared to the strongly synchronous clock in the Ripple consensus protocol, Ripple + relies only on the weak synchronization assumption, which means that the delay is time-varying, but does not grow infinitely faster than the polynomial function with respect to time. This is a time assumption that is more suitable for a real network environment. However, since FLP impossibility cannot be violated, Ripple + employs a timeout mechanism when performing view switching. View switching does not occur frequently in Ripple + and the required extra cost is small and therefore acceptable.
The trust model established in the improved Ripple consensus method applicable to the unlicensed chain is shown in fig. 1, and the consensus system comprises a plurality of core nodes and leaf nodes, wherein arrows represent the trust relationship of the core nodes and point to trusted parties from the trusted parties. One of the core nodes is also the master node (node N in fig. 1)0). Each node needs to pre-configure its UNL, initial view number, keys, and neighbors in the Gossip network before consensus, and then initialize the recently closed account book and fully validate the account book. The new node may join the consensus by adding its address to the neighbor list of other nodes and selecting its UNL.
As shown in fig. 2, a consensus process begins with a client committing a transaction and ends when the transaction is committed to a fully validated book. Normally, a consensus process comprises four phases:
a submission stage: the client submits the transaction to the master node, and the master node verifies and packages the transaction and broadcasts the transaction through the Gossip network.
And (3) an opening stage: when a node receives a transaction from the master node, it generates and broadcasts its initial proposal accordingly.
A building stage: the node iteratively proposes the transaction in a plurality of rounds until a legal set in its UNL proposes the identical transaction set; the transaction set is then committed into the recently closed ledger and a validation message is broadcast regarding the updated recently closed ledger status.
And (3) an accepting stage: when one legal set in the node UNL has the exact same recently closed account book, the update is applied to the fully validated account book.
When the legal transaction is not submitted after a period of time, namely timeout occurs, view switching operation is carried out, and the main node is changed into the next node in the core set. Since at most 20% of the core nodes are assumed to be byzantine nodes, the system must recover to normal operation after a period of time.
Each stage of the consensus process of Ripple + is set forth in detail below.
1) Commit phase
In the Ripple consensus protocol, a client sends transactions to nodes through the Gossip network, so that as many nodes as possible receive the transactions. The client cannot know exactly who will offer these transactions, nor does the node know how many transactions were submitted by the client. After a period of time, the node proceeds to the next stage, and the duration of the period of time is related to the duration of the last consensus process. Ripple + introduces a master node responsible for receiving transactions committed by clients and from it decides when to enter the next phase. And sequentially selecting a main node from the core set according to the current view number, wherein the identity of the main node is disclosed to all nodes and the client side so as to be convenient for other nodes to verify. In the commit phase, the client commits the transaction only to the master node, redirecting it to the master node if other nodes receive a commit from the client. When the master node thinks it has received enough messages, it packages all transactions and broadcasts them out through the Gossip network.
2) Open phase
When a node receives a message from the Gossip network containing several transactions signed by the master node, it will start a new consensus process. First, the node initializes its current state, including the number of rounds and the proposed states of the other nodes. Then, the method checks whether the current work is on the preferred account book or not according to the latest verification message received from the UNL node of the account book, if not, the preferred account book is switched to, and the generation method of the preferred account book is the same as that of Ripple. It then generates and broadcasts its initial offer based on the transaction set broadcast by the master node and the current recently closed ledger state.
3) Establishing phase
The setup phase is divided into several rounds. In each round, the node continuously receives offers from its UNL and updates the offer status maintained locally. When a node receives a proposal from some legal set of its UNL on its turn, it will calculate the votes for all transactions based on the latest proposals for nodes in its UNL. If the transaction's ticket number exceeds the threshold for the current round, the transaction will be proposed by the node in the next round. This is in contrast to the original Ripple, which only performs the counting process after a predetermined time interval, which means that the phases are synchronized. When a node broadcasts a new proposal, it will check whether the nodes in its UNL have agreed. If there is a legal set of proposed transactions that are the same as the node and they are all declared to be updated based on the same book, the node considers that agreement has been reached for the list of transactions and commits the transactions to the recently closed book. The node then broadcasts a validation message containing the updated status of the last closed ledger and enters the accept phase.
4) Accepting stage
The node maintains locally the latest authentication status of its UNL according to the received authentication message. When there is an account book supported by a legal set in its UNL, the fully verified account book will be updated to the account book. Even if no account book meeting the condition exists, the consensus is not inactivated because the accepting stage and the opening stage are parallel, when the first-choice account book check is carried out in the opening stage of the next consensus process, all correct nodes are switched to the same branch according to the latest verification state maintained locally, and the agreement is achieved in the next consensus process.
The pseudo code to implement the consensus process described above is as follows:
ripple + addresses some of the previously mentioned scenarios that may lead to deactivation by introducing a master node. However, failure of the master node may present additional problems to the system. For example, the master node may participate in the consensus negatively, i.e., it deliberately packs only a small number of transactions in each consensus process to reduce throughput. The master node may also selectively mask certain transactions, causing them to be unable to agree for a long time, thereby losing "fairness". The present invention further addresses these issues through a view switching mechanism.
View switching is dominated by all core nodes, but the new view will be applied across all nodes. The decision on when to start a view switch is made by setting a timer and capturing the timeout exceptions with the help of the client. Under normal circumstances, only the master node can receive requests from clients. When other core nodes receive the client request and contain some legal but uncommitted transactions, the core node starts a timer and forwards the request to the master node. When these legitimate transactions are committed, the node will pause the timer, but restart the timer when other legitimate and uncommitted transactions are received again. If the timer times out, a view switching operation is performed.
View switch operation as shown in fig. 3, when a core node catches the timeout exception, it will stop receiving the messages of the open phase and the setup phase, and then broadcast a view change message to all core nodes, which contains the current recently closed account book status of the node and all discovered but uncommitted transactions. When a core node receives a ViewChange message for more than 20% of the core nodes and does not itself broadcast the ViewChange message, then the node also stops receiving messages and broadcasts a view change message.
When the master node corresponding to the next view in the kernel set receives a view change message with the same view number from a legal set of its UNL, it broadcasts a new view message to all nodes via the Gossip network, which contains three parts: 1. obtaining a preferred account book according to the account books in all the ViewChange messages; all transactions contained in the ViewChange message and not committed to the preferred ledger; 3. all received ViewChange messages with signatures for other nodes to verify. When a node receives and validates a NewView message, it adds all uncommitted transactions to its candidate set, updates the recently closed account book to the preferred account book, and then broadcasts a NewView ack message over the Gossip network. When the node receives a NewViewAck message with the same view number from a legal person set of the UNL, the view switching is completed, and the node is ready to enter a new consensus process.
The pseudo code implementing the view switching process is as follows:
the technical effects that the present invention can produce are explained as follows:
1. theoretical proof
Supposing that a system core set comprises x core nodes, selecting a core nodes from the core set by any leaf node, adding the core nodes to form UNL, wherein x and a are positive integers; the number of leaf nodes in the system is uncertain. The size of the legal set is set to be 80% of the number of nodes in the UNL set, and the number of byzantine nodes does not exceed 20%. The following analyses how the inventive Ripple + satisfies the safety and activity under this assumption. The proof is based mainly on the conclusion of Chase et al.
1) Safety feature
From analysis by Chase et al, the system can ensure security if and only if any two nodes NiAnd NjSatisfies the following conditions:
Oi,j>(ni-qi)+(nj-qj)+ti,j (1)
wherein n isi、nj、qi、qjRespectively representing the respective UNL set size and the legal set size; o isi,jRepresents NiAnd NjNumber of nodes in the UNL intersection, ti,jRepresenting the maximum number of byzantine nodes in the intersection. Obviously, the kernel set itself satisfies condition (1) because any pair of kernel nodes has 100% UNL intersection. Thus only the security of leaf nodes is discussed. For any leaf node Ni、niAnd q isiHas the following values:
ni＝a+1 (2)
qi＝0.8ni＝0.8(a+1) (3)
because all leaf nodes select a core nodes from the core set as the trust nodes, any two leaf nodes can generate UNL intersection, and the size of the intersection has the minimum value, namely:
Oi,j≥2a-x (4)
obviously, ti,jMust not exceed UNLiOr UNLjThe number of byzantine nodes in (1), namely:
ti,j≤min(ti,tj)≤0.2(a+1) (5)
as a trust nodes need to be selected from x core nodes, an additional condition is:
a≤x (6)
based on (1) - (6), ranges for a and x are obtained:
in addition, Chase et al also suggests a case of extreme network degradation, where nodes may exit in the midst of consensus, resulting in network inconsistencies. In this case, the conditions under which the system ensures security become:
Oi,j>(ni-qi)+nj/2+ti,j (9)
also, according to the above analysis, the ranges of a and x in this case are:
x>9 (11)
2) activity of
Chase et al have demonstrated that the activity of leaf nodes is dependent on the activity of the core set. However, subsequent studies indicate that the core set itself may also be subject to inactivation. The Ripple + of the invention solves the problem that the core set may face inactivation by introducing a main node and a view switching mechanism. Specifically, when a Byzantine core node broadcasts inconsistent transactions during the open phase, resulting in no transactions reaching consensus, a timeout may occur because the transaction has not been committed for a period of time. Then, a view switch mechanism is performed and the master node will become the node in the next position in the core set. Based on the assumption that the number of Byzantine nodes in the core set does not exceed 20%, at most
After each view, the master node will become the correct node.
According to the analysis of Chase et al, a leaf node is not inactivated when the number of core nodes in its UNL set is not less than the size of its UNL's legal set. Namely when
a≥0.8(a+1) (12)
The system may guarantee the liveness of the leaf nodes. Namely, it is
a≥4 (13)
2. The experimental results prove that
A Ripple + prototype is realized by using the Go language, and a plurality of nodes are simulated on a single machine to carry out experiments, wherein each node runs in a single coroutine. The nodes communicate with each other in an HTTP POST mode, and the communication delay can be ignored. Using SHA256 as a hash algorithm and ECDSA as a digital signature algorithm for message authentication, the key for each node has been generated in advance before the experiment starts. All global parameters, such as kernel set membership, legal set size, and thresholds for each iteration are preconfigured. In addition, the client is also simulated to repeatedly submit transactions to the master node, and the performance of the Ripple + under different conditions is analyzed by controlling the batch size and the number of submissions.
The state of the whole network is represented by the state of the account book of the core set, and when one legal set in the core set completes the update of the account book, the consensus process is finished, and the leaf nodes are not considered, because the messages of the leaf nodes are ignored by all the core nodes in the trust model. In the experiment, the number of byzantine nodes is set to be not more than 20% of the UNL.
The performance of Ripple + in ideal and actual conditions was analyzed separately. Ideally, all nodes will have all transactions received from the client as initial proposals for the setup phase, so that the consensus condition is reached only once iteration on the premise that the master node broadcasts consistent transactions to all nodes. However, in practice, the initial proposal contains only a random subset of all transactions received from the master node, which results in different initial proposals for each node. Thus, the setup phase may last for multiple rounds. This is similar to the situation in native Ripple, because in native Ripple, multiple clients commit transactions over the Gossip network, which is more likely to cause inconsistent transactions to be received by different nodes. Performance of Ripple + in both cases was compared separately.
Two performance indicators were used to evaluate the performance of Ripple +: (1) latency, i.e. the time interval that elapses from the time the client commits a transaction until the accounting book is fully verified to be updated. The average time delay of the setup phase and the verification phase were also measured separately in the experiment for further analysis. The delay of the commit phase and the open phase is almost negligible in the total delay and is thus omitted; (2) throughput, i.e., the number of transactions submitted to the fully validated account book per unit time. Peak throughput of Ripple + was measured and analyzed at different node sizes and batch sizes.
The batch size was set to 100 and the average delay for a single consensus period was measured. Fig. 4 shows the average latency versus kernel set size. Due to many-to-many communication between core nodes, the delay grows exponentially with the size of the core set. The delay in the ideal case is advantageous over the delay in the actual case because the latter requires more rounds in the setup phase to achieve consensus. As can be seen from fig. 4, under the same conditions, the actual delay is about twice the ideal delay.
Fig. 5 further analyzes the setup phase and verification phase mean time delays. The setup phase occupies most of the time of a consensus period, and as the kernel set size increases, the latency of the setup phase increases more significantly than the verification phase. Under the same node scale, the time delay of the establishing stage is larger than that of the actual condition in the ideal condition, but the time delay of the verifying stage is approximately the same.
Fig. 6 shows the variation of throughput for different batch sizes and node sizes. When the node size is small, the throughput increases rapidly with the batch size, but the throughput increase speed gradually slows down with the increase of the batch size, and finally reaches a peak. Ideally, the throughput is higher than in practice, because the number of iterations in the set-up phase is smaller. In addition, the size of the kernel set also has a large impact on throughput. Specifically, under 10 core nodes, the throughput of the ideal case is close to 13000tx/s, but only 11000tx/s in the actual case; whereas with 20 core nodes the throughput is ideally close to 3100tx/s, but in practice the throughput is about 2500 tx/s.
FIG. 7 is a view switching overhead for different kernel set sizes, with maximum, minimum, and average overhead labeled after multiple measurements. Similar to consensus latency, view switching overhead grows exponentially with the kernel set size. However, the consensus latency is hundreds of times the view switching overhead for the same kernel set size, which means that the view switching mechanism generates little overhead. In addition, the view switching overhead results are stable under multiple measurements. Therefore, the view switching mechanism effectively improves the activity of Ripple.
While the invention has been described with respect to a limited number of embodiments, those skilled in the art, having benefit of this description, will appreciate that other embodiments can be devised which do not depart from the scope of the invention as described herein. The present invention has been disclosed in an illustrative rather than a restrictive sense, and the scope of the present invention is defined by the appended claims.
The documents cited in the present invention are:
[1]Chase B,MacBrough E.Analysis of the XRP ledger consensus protocol[J].arXiv preprint arXiv:1802.07242,2018。
Claims (8)
1. an improved Ripple consensus method applicable to an unlicensed chain is characterized in that a core set consisting of a plurality of nodes is configured in advance in a blockchain consensus network, the nodes in the core set are defined as core nodes, and a trusted node list of the core nodes is the core set; nodes in the blockchain consensus network, which do not belong to a core set, are defined as leaf nodes, and the trust node list of the leaf nodes is a subset of the core set and the leaf nodes are self; the implementation process of the improved Ripple consensus method comprises the following steps:
step one, a submission stage:
selecting a core node as a main node according to the current view number, wherein the main node firstly receives a plurality of transactions submitted by a client; then, verifying the received multiple transactions and packaging the transactions into a transaction set; then broadcasting the transaction set to other nodes in the block chain consensus network for consensus;
step two, an opening stage:
generating and broadcasting their respective initial offers when the other nodes receive the transaction set; the specific process of each node generating and broadcasting its initial proposal is as follows: after receiving the transaction set, the node initializes the current state of the node, wherein the state comprises the number of rounds and the proposed states of other nodes except the node; then, whether the current self works on the preferred account book is checked, and if not, the self is switched to the preferred account book; then, generating an initial proposal according to the transaction set broadcasted by the main node and the current latest account book closing state and broadcasting the initial proposal;
step three, establishing:
each node in other nodes iteratively proposes transactions in a plurality of rounds until a legal set in a trusted node list proposes an identical transaction set, submits the transaction set to a latest closed account book of the node, and broadcasts a verification message about the state of the latest closed account book updated by the node; the specific implementation process of each node in the establishing stage is as follows:
step three, in each round, the node continuously receives proposals from the nodes in the trust node list and updates the locally maintained proposal state;
step two, after the node receives the proposal of a legal person set from the trust node list in the current round, the node calculates the ticket number of all the affairs according to the latest proposal of the node in the trust node list, if the ticket number of the affairs exceeds the preset threshold value of the current round, the affairs can be proposed by the node in the next round;
step three, after the node broadcasts a new proposal, checking whether all nodes in the trust node list reach consensus or not, and if the consensus is confirmed, submitting the transaction list reaching the consensus to the recently closed account book;
step three, broadcasting a verification message by the node, wherein the verification message comprises the state of the latest closed account book after the node is updated;
step four, an accepting stage:
and when one legal person set in the trust node list of each node in other nodes has the same latest closed account book, updating and applying the updated account book to the complete verification account book of the node to complete a consensus process.
2. The improved Ripple consensus method for unlicensed chains as claimed in claim 1, wherein the principle of confirming the consensus in step three is: if there is a legal set proposed transaction list that is the same as the node and the legal sets all claim to be updated based on the same book, then it is confirmed that consensus has been reached for the transaction list.
3. The improved Ripple consensus method for unlicensed chains according to claim 2, wherein each node in step four is implemented in the accepting phase by: the method comprises the steps of locally maintaining the latest verification state of a trusted node list of an account according to received verification messages, and updating a fully verified account into the account when the account is supported by a legal set in the trusted node list.
4. The method of claim 3, wherein in step one, when the master node does not receive a legal and uncommitted transaction requested to be submitted by the client, but receives the transaction submission request from other core nodes in the kernel set, the core node that receives the transaction submission request starts a timer and forwards the transaction submission request to the master node, and when the legal transaction is submitted, the timer is halted; and restarting the timer when other legal and uncommitted transaction requests are received again, and executing the view switching operation if the timer is overtime, namely the legal transaction is not committed.
5. The method of claim 4, wherein the specific process of the view switching operation is as follows: when a core node captures the overtime exception of the timer, the core node stops receiving messages of an open stage and a set-up stage, and then broadcasts a view switching message to all other core nodes, wherein the view switching message comprises the current latest closed account book state of the core node and all found but uncommitted transactions; when one core node receives the view switching message of more than 20% of the core nodes in the core set and does not broadcast the view switching message, the node stops receiving the message and broadcasts the view switching message;
when a master node corresponding to the next view in the core set receives a view switching message with the same view number from a legal set of a trusted node list of the master node, broadcasting a new view message to all nodes, wherein the new view message comprises: the view switching method comprises the steps that a preferred account book is obtained according to the account book in all view switching messages, all transactions which are contained in the view switching messages and are not submitted to the preferred account book, and all received view switching messages with signatures;
when other nodes receive and verify the new view message, adding all uncommitted transactions into respective candidate sets, updating the latest closed account book of the candidate sets into a preferred account book, and broadcasting a new view received message; and when a new view receiving message with the same view number is received from a legal person set of the trust node list, the view switching is completed.
6. The improved Ripple consensus method applicable to the unlicensed chain as claimed in claim 5, wherein the conditions for ensuring the network security under the premise that the size of the legal set is 80% of the total number of core nodes and the number of byzantine nodes does not exceed 20% of the total number of core nodes are:
wherein x represents the total number of core nodes; a represents the number of core nodes contained in a subset selected from a core set by a trust node list of a leaf node; x and a are both positive integers;
the conditions for ensuring the activity of the leaf nodes are as follows: a is more than or equal to 4.
7. The improved Ripple consensus method for unlicensed chains according to claim 5, wherein in case of extreme network degradation, the conditions for ensuring network security are:
x>9 。
8. the method of claim 5, wherein the nodes communicate with each other via the Gossip protocol.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110665513.4A CN113381861B (en) | 2021-06-16 | 2021-06-16 | Improved Ripple consensus method suitable for unlicensed chain |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110665513.4A CN113381861B (en) | 2021-06-16 | 2021-06-16 | Improved Ripple consensus method suitable for unlicensed chain |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN113381861A CN113381861A (en) | 2021-09-10 |
| CN113381861B true CN113381861B (en) | 2022-03-15 |
Family
ID=77574646
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110665513.4A Active CN113381861B (en) | 2021-06-16 | 2021-06-16 | Improved Ripple consensus method suitable for unlicensed chain |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113381861B (en) |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106060036A (en) * | 2016-05-26 | 2016-10-26 | 布比（北京）网络技术有限公司 | Decentralized consenting method and apparatus |
| CN108848125A (en) * | 2018-05-22 | 2018-11-20 | 北京京东尚科信息技术有限公司 | The method and apparatus and storage medium of common recognition service are provided in block chain |
Family Cites Families (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2017139688A1 (en) * | 2016-02-12 | 2017-08-17 | D+H Usa Corporation | Peer-to-peer financial transactions using a private distributed ledger |
| CN106228446B (en) * | 2016-05-12 | 2019-09-13 | 北京众享比特科技有限公司 | Transaction in assets plateform system and method based on privately owned block chain |
| CN113204532A (en) * | 2017-10-04 | 2021-08-03 | 邓白氏公司 | System and method for identity resolution across disparate immutable distributed ledger networks |
| CN109784916A (en) * | 2018-12-12 | 2019-05-21 | 广东工业大学 | A method of ether mill common recognition mechanism that improving PBFT is applied to alliance's chain |
| CN110535836B (en) * | 2019-08-12 | 2021-10-29 | 安徽师范大学 | Trust block chain consensus method based on role classification |
| CN111030993B (en) * | 2019-11-11 | 2022-05-03 | 重庆邮电大学 | Rayleigh consensus method based on extended credible authentication in alliance block chain |
| CN111275438B (en) * | 2020-01-14 | 2023-04-28 | 北京众享比特科技有限公司 | Consensus method, device, equipment and storage medium of block chain network |
| CN112398640B (en) * | 2020-11-13 | 2024-02-13 | 华南农业大学 | Optimized block chain consensus algorithm |
-
2021
- 2021-06-16 CN CN202110665513.4A patent/CN113381861B/en active Active
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106060036A (en) * | 2016-05-26 | 2016-10-26 | 布比（北京）网络技术有限公司 | Decentralized consenting method and apparatus |
| CN108848125A (en) * | 2018-05-22 | 2018-11-20 | 北京京东尚科信息技术有限公司 | The method and apparatus and storage medium of common recognition service are provided in block chain |
Also Published As
| Publication number | Publication date |
|---|---|
| CN113381861A (en) | 2021-09-10 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Chase et al. | Analysis of the XRP ledger consensus protocol | |
| EP3836512B1 (en) | Facilitating practical byzantine fault tolerance blockchain consensus and node synchronization | |
| Cachin et al. | Non-determinism in byzantine fault-tolerant replication | |
| Hanke et al. | Dfinity technology overview series, consensus system | |
| US11675677B2 (en) | Byzantine agreement using communications having linear complexity | |
| Buchman et al. | The latest gossip on BFT consensus | |
| WO2020258831A1 (en) | Method and device for master node handover processing in blockchain system | |
| Jalalzai et al. | Proteus: A scalable BFT consensus protocol for blockchains | |
| Culnane et al. | A peered bulletin board for robust use in verifiable voting systems | |
| JP2020512708A (en) | Distributed system, message processing method, node, client and storage medium | |
| US20200134578A1 (en) | Blockchain consensus systems and methods involving a time parameter | |
| Momose et al. | Constant latency in sleepy consensus | |
| CN111682942A (en) | Binary weighted Byzantine fault-tolerant consensus method applied to permit chain | |
| CN111582843A (en) | Block chain privacy transaction method based on aggregated signature | |
| Charapko et al. | Bridging paxos and blockchain consensus | |
| CN109919760A (en) | Byzantine failure tolerance common recognition algorithm based on voting mechanism | |
| Santiago et al. | Concordia: a streamlined consensus protocol for blockchain networks | |
| Bentov et al. | The Sleepy Model of Consensus. | |
| CN114491656A (en) | Method and apparatus in a blockchain network | |
| CN113381861B (en) | Improved Ripple consensus method suitable for unlicensed chain | |
| Blum et al. | Network-agnostic state machine replication | |
| Bazzi et al. | Clairvoyant state machine replication | |
| Jalalzai et al. | The hermes BFT for blockchains | |
| WO2017059737A1 (en) | Method and device for verifying validity of identity of entity | |
| Kuo et al. | Fair byzantine agreements for blockchains |
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 |