Patent Application
20200192770
Various embodiments disclosed herein relate generally to hierarchical weighted consensus for permissioned blockchains.
The Blockchain paradigm provides a popular mechanism for establishing trust and consensus in distributed environments. While Blockchain technology is currently primarily deployed in crypto-currency systems like Bitcoin and Ethereum, different kinds of information records or transactions can be managed and stored in a Blockchain, and the concept is expected to emerge as a key component of the Internet-of-Things (IoT), enabling novel applications especially in digital health.
The use of blockchain technology in digital health is motivated by some of the inherent limitations of existing health systems which include the fragmented nature of the healthcare ecosystem and the lack of interoperability between the different entities forming this ecosystem, i.e., hospitals, regulators, insurers, patients. Moreover, patients leave their data scattered across several organizations as they move from one provider to another. All of this creates what is known as “silo effect”, as patients' data are siloed with lack of medical information and records of patient flowing between these entities. There is also no redundancy mechanism to replicate the medical records of the patients making them vulnerable to loss or attacks like ransomware. Another issue is that the mechanisms being used do not provide immutable storage of these records, which means that these records are not tamper resistant, creating the need for non-repudiation and audit mechanisms to guarantee the immutability of the data. Blockchain technology seems to be a perfect solution to the above-mentioned inherent limitations of existing health systems. It noted that the data storage and data integrity issues present are found in other areas as well such as financial systems, production facilities, supply chains, etc.
A summary of various exemplary embodiments is presented below. Some simplifications and omissions may be made in the following summary, which is intended to highlight and introduce some aspects of the various exemplary embodiments, but not to limit the scope of the invention. Detailed descriptions of an exemplary embodiment adequate to allow those of ordinary skill in the art to make and use the inventive concepts will follow in later sections.
Various embodiments relate to a method of reaching consensus in a blockchain network including a plurality of nodes, including: clustering the nodes into a plurality of sites; randomly selecting a node at each site as a representative; initializing a weight for each node; receiving, by a first representative of a first site, a plurality of transactions received by nodes in the first site; constructing, by the first representative, a first block including the plurality of transactions received by the first representative; performing a weighted consensus mechanism to verify the first block, wherein each of nodes in the first site participates in a weighted Byzantine Fault Tolerant (BFT) consensus mechanism and wherein the consensus is based upon each node's weight; performing a BFT consensus mechanism by the plurality of representatives on the first block; updating each nodes weight; and updating the representative for each site by selecting the node at each site with the highest weight.
Various embodiments are described, wherein the weighted BFT consensus mechanism further includes: selecting a set of honest nodes such that the set of honest nodes is the minimum number of nodes whose sum of weights exceeds the sum of the weights of the faulty nodes; performing a first phase that produces a preliminary vote for each node at the site based upon the weighted votes of other nodes at the site; performing a second phase that produces an intermediate vote for each node at the site based upon the weighted preliminary votes of the other nodes at the site; and performing a third phase that produces a final vote for the site based upon the preliminary votes of the honest nodes.
Various embodiments are described, further including producing a digital signature for the final vote using a decentralized witness cosigning protocol.
Various embodiments are described, further including adding nodes to a faulty set when no message or a message with an incorrect format is received from the nodes.
Various embodiments are described, wherein updating each nodes weight further including: performing a first phase where all of the nodes in the site exchange a list of faulty nodes and then each node updates its list of faulty nodes based upon a suspect weight that is a sum of the weights all nodes that lists a node as faulty; performing a second phase wherein the nodes at the site reach an agreement of the set of faulty nodes using the weighted consensus mechanism; and performing a third phase that reduces the weights of the nodes in the set of faulty nodes and normalizes the weights of the other nodes.
Various embodiments are described, wherein reducing the weights of the nodes in the set of faulty nodes includes setting the weights to zero.
Various embodiments are described, further including: receiving, by a second representative of a second site, a plurality of transactions received by nodes in the second site; constructing, by the second representative, a second block including the plurality of transactions received by the second representative; performing a weighted consensus mechanism to verify the second block, wherein each of nodes in the second site participates in a weighted Byzantine Fault Tolerant (BFT) consensus mechanism and wherein the consensus is based upon each node's weight; performing a BFT consensus mechanism by the plurality of representatives on the second block; updating each nodes weight; and updating the representative for each site by selecting the node at each site with the highest weight.
Various embodiments are described, wherein the weights on each node allow for more than ⅓ of the nodes in the network to be faulty.
Further various embodiments relate to a non-transitory machine-readable storage medium encoded with instructions for reaching consensus in a blockchain network including a plurality of nodes, including: instructions for clustering the nodes into a plurality of sites; instructions for randomly selecting a node at each site as a representative; instructions for initializing a weight for each node; instructions for receiving, by a first representative of a first site, a plurality of transactions received by nodes in the first site; instructions for constructing, by the first representative, a first block including the plurality of transactions received by the first representative; instructions for performing a weighted consensus mechanism to verify the first block, wherein each of nodes in the first site participates in a weighted Byzantine Fault Tolerant (BFT) consensus mechanism and wherein the consensus is based upon each node's weight; instructions for performing a BFT consensus mechanism by the plurality of representatives on the first block; instructions for updating each nodes weight; and instructions for updating the representative for each site by selecting the node at each site with the highest weight.
Various embodiments are described, wherein the weighted BFT consensus mechanism further includes: instructions for selecting a set of honest nodes such that the set of honest nodes is the minimum number of nodes whose sum of weights exceeds the sum of the weights of the faulty nodes; instructions for performing a first phase that produces a preliminary vote for each node at the site based upon the weighted votes of other nodes at the site; instructions for performing a second phase that produces an intermediate vote for each node at the site based upon the weighted preliminary votes of the other nodes at the site; and instructions for performing a third phase that produces a final vote for the site based upon the preliminary votes of the honest nodes.
Various embodiments are described, further including instructions for producing a digital signature for the final vote using a decentralized witness cosigning protocol.
Various embodiments are described, further including instructions for adding nodes to a faulty set when no message or a message with an incorrect format is received from the nodes.
Various embodiments are described, wherein instructions for updating each nodes weight further includes: instructions for performing a first phase where all of the nodes in the site exchange a list of faulty nodes and then each node updates its list of faulty nodes based upon a suspect weight that is a sum of the weights all nodes that lists a node as faulty; instructions for performing a second phase wherein the nodes at the site reach an agreement of the set of faulty nodes using the weighted consensus mechanism; and instructions for performing a third phase that reduces the weights of the nodes in the set of faulty nodes and normalizes the weights of the other nodes.
Various embodiments are described, wherein reducing the weights of the nodes in the set of faulty nodes includes setting the weights to zero.
Various embodiments are described, further including: instructions for receiving, by a second representative of a second site, a plurality of transactions received by nodes in the second site; instructions for constructing, by the second representative, a second block including the plurality of transactions received by the second representative; instructions for performing a weighted consensus mechanism to verify the second block, wherein each of nodes in the second site participates in a weighted Byzantine Fault Tolerant (BFT) consensus mechanism and wherein the consensus is based upon each node's weight; instructions for performing a BFT consensus mechanism by the plurality of representatives on the second block; instructions for updating each nodes weight; and instructions for updating the representative for each site by selecting the node at each site with the highest weight.
Various embodiments are described, wherein the weights on each node allow for more than ⅓ of the nodes in the network to be faulty.
Further various embodiments relate to a system for reaching consensus in a blockchain network including a plurality of nodes, including: means for clustering the nodes into a plurality of sites; means for randomly selecting a node at each site as a representative; means for initializing a weight for each node; means for receiving, by a first representative of a first site, a plurality of transactions received by nodes in the first site; means for constructing, by the first representative, a first block including the plurality of transactions received by the first representative; means for performing a weighted consensus mechanism to verify the first block, wherein each of nodes in the first site participates in a weighted Byzantine Fault Tolerant (BFT) consensus mechanism and wherein the consensus is based upon each node's weight; means for performing a BFT consensus mechanism by the plurality of representatives on the first block; means for updating each nodes weight; and means for updating the representative for each site by selecting the node at each site with the highest weight.
Various embodiments are described, further including wherein the weighted BFT consensus mechanism further includes: means for selecting a set of honest nodes such that the set of honest nodes is the minimum number of nodes whose sum of weights exceeds the sum of the weights of the faulty nodes; means for performing a first phase that produces a preliminary vote for each node at the site based upon the weighted votes of other nodes at the site; means for performing a second phase that produces an intermediate vote for each node at the site based upon the weighted preliminary votes of the other nodes at the site; and means for performing a third phase that produces a final vote for the site based upon the preliminary votes of the honest nodes.
Various embodiments are described, further including means for producing a digital signature for the final vote using a decentralized witness cosigning protocol.
Various embodiments are described, further including means for adding nodes to a faulty set when no message or a message with an incorrect format is received from the nodes.
Various embodiments are described, wherein means for updating each nodes weight further includes: means for performing a first phase where all of the nodes in the site exchange a list of faulty nodes and then each node updates its list of faulty nodes based upon a suspect weight that is a sum of the weights all nodes that lists a node as faulty; means for performing a second phase wherein the nodes at the site reach an agreement of the set of faulty nodes using the weighted consensus mechanism; and means for performing a third phase that reduces the weights of the nodes in the set of faulty nodes and normalizes the weights of the other nodes.
Various embodiments are described, wherein means for reducing the weights of the nodes in the set of faulty nodes includes means for setting the weights to zero.
Various embodiments are described, further including: means for receiving, by a second representative of a second site, a plurality of transactions received by nodes in the second site; means for constructing, by the second representative, a second block including the plurality of transactions received by the second representative; means for performing a weighted consensus mechanism to verify the second block, wherein each of nodes in the second site participates in a weighted Byzantine Fault Tolerant (BFT) consensus mechanism and wherein the consensus is based upon each node's weight; means for performing a BFT consensus mechanism by the plurality of representatives on the second block; means for updating each nodes weight; and means for updating the representative for each site by selecting the node at each site with the highest weight.
Various embodiments are described, wherein the weights on each node allow for more than ⅓ of the nodes in the network to be faulty.
In order to better understand various exemplary embodiments, reference is made to the accompanying drawings, wherein:
To facilitate understanding, identical reference numerals have been used to designate elements having substantially the same or similar structure and/or substantially the same or similar function.
The description and drawings illustrate the principles of the invention. It will thus be appreciated that those skilled in the art will be able to devise various arrangements that, although not explicitly described or shown herein, embody the principles of the invention and are included within its scope. Furthermore, all examples recited herein are principally intended expressly to be for pedagogical purposes to aid the reader in understanding the principles of the invention and the concepts contributed by the inventor(s) to furthering the art and are to be construed as being without limitation to such specifically recited examples and conditions. Additionally, the term, “or,” as used herein, refers to a non-exclusive or (i e , and/or), unless otherwise indicated (e.g., “or else” or “or in the alternative”). Also, the various embodiments described herein are not necessarily mutually exclusive, as some embodiments can be combined with one or more other embodiments to form new embodiments.
An important component of any blockchain system is its consensus mechanism, which orchestrates how the different nodes of the blockchain network reaches an agreement about transactions and blocks that are to be added to the shared ledger in a disturbed manner. The most popular mechanism for consensus is proof-of-work, which is usually used in permissionless blockchains, such as cryptocurrencies where access is publicly open, and identities are hidden, to eliminate the need for established trust between the nodes as this concept limits the ability of the nodes to misbehave. Through the proof-of-work consensus mechanism each node needs to prove that it spent a large amount of computational resources and solve a mathematical cryptographic puzzle to gain the right to add its block.
However, access in healthcare and certain other applications must be authenticated, which means that all the nodes need to be aware of the identities of the other entities in the system. Therefore, it is unnecessary for nodes to spend tremendous computational resources to prove their eligibility to write into the blockchain as it would be a waste of energy resources. In addition, PoW is a slow consensus mechanism with a low transaction rate. The PoW consensus mechanism is also probabilistic, which means that even if a node solves the puzzle, the node is not guaranteed that its block will be added to the blockchain, which also causes the node to suffer from a very low transaction rate. These limitations make the PoW consensus mechanism unsuitable for healthcare and other similar systems. Therefore, there remains a need to design a consensus mechanism that enables health, and other similar systems as well, to leverage the potential and properties of blockchain technology while addressing the above-identified issues.
Due to the authenticated access requirement in health systems and due to the fact that nodes in a healthcare system are more likely to be altruistic than is the case in crypto-currency like systems, it makes more sense to rely on node's votes and a permissioned type of consensus, more specifically Byzantine Fault Tolerance (BFT) protocols, to implement a consensus mechanism for healthcare and other similar systems. BFT protocols enable distributed systems, like blockchain networks, to tolerate byzantine failure, which is the most difficult class of failures, among the nodes. BFT protocols present several advantages compared to their PoW consensus counterpart. First, the BFT protocol's permissioned nature makes them more suitable to healthcare systems and waives the requirement of using large amounts of computational power to establish trust as in the PoW consensus mechanism. Second, unlike PoW, BFT consensus is deterministic, meaning that once consensus about a certain block is reached, then that block is permanently added to the blockchain. Finally, blockchain systems relying on BFT protocols as their consensus mechanism enjoy much higher transactions rates compared to their PoW counterparts, which would be very beneficial in healthcare and other similar systems where data may need to propagate rapidly, especially in emergency situations.
As mentioned above, the several benefits that BFT protocols present make them very attractive to be used in healthcare and other similar blockchains. However, these benefits come at the cost of an exorbitant communication overhead as every node needs to communicate with every other node in the system over multiple rounds. This limits the BFT's scalability and high transaction rates to only small systems. Also, BFT protocols can tolerate only up to ⅓ of the nodes turning byzantine. Therefore, applying BFT protocols off the shelf to healthcare and other similar systems is not possible as the number of nodes pertaining to healthcare and other similar systems is much larger than what BFT protocols support. Also, healthcare and other similar systems are some of the most targeted systems by attackers, which increases the chances of the nodes being compromised and turning byzantine—thus the need to improve the systems fault tolerance to these byzantine faults.
The embodiments described herein address these two issues to create a BFT protocol that not only scales better to large systems such as healthcare systems, but also has better fault tolerance than the theoretical limit of ⅓ of the total number of nodes.
An embodiment of a consensus mechanism will not be described. The consensus mechanism is a BFT-based consensus mechanism for permissioned blockchains, that is suitable for healthcare and other systems, for example, wherein entities pertaining to the health ecosystem, i.e., hospitals, patients, care providers, insurance companies, could be involved in this consensus. This consensus mechanism achieves better scalability and better fault tolerance than the standard BFT consensus mechanism.
The consensus mechanism represents the main control component in any blockchain system. In fact, the consensus mechanism enables entities belonging to the system to reach an agreement on what block, and thus what transactions, will be validated and added to the blockchain. In healthcare applications all parties must have permissions to be part of the system and their identities are known to each other. Therefore, it is natural to choose a permissioned blockchain and to use a BFT-based protocol as the consensus engine. This is different from permissionless blockchains where membership is open to the public as in cryptocurrencies such as Bitcoin, where consensus is established via mechanisms like the computationally costly proof-of-work.
For illustration purposes the nodes in the system described herein are referred to as hospitals, but they can also include other entities from the health ecosystem. As previously stated, a healthcare based blockchain system is described, but the consensus mechanism embodiments described herein may be used in other systems that are similar to healthcare systems. Patients may also join the consensus with appropriate weights and incentives and be part of the protocol. The proposed BFT-based consensus mechanism makes use of two key concepts to achieve high transaction rates and increased fault tolerance: hierarchy and weights. BFT protocols in general are known for their poor scalability which is mainly due to their large communication overhead. This challenge is addressed by proposing a hierarchical BFT, where instead of making all the nodes participate simultaneously in the consensus, the nodes are organized into smaller groups and run parallel consensus instances. Once consensus is reached within each group, a global consensus is run between representatives of the different groups. This helps to reduce the large number of messages that are exchanged in common BFT protocols, which in turn reduces delays and increases the transaction rates of the system. In fact, if no hierarchy is in place, a regular BFT mechanism would incur an O(n2) communication overhead, as every node would communicate with every other node in the system over multiple rounds to reach consensus.
The consensus mechanism is executed in a hierarchical manner such that communication overhead will drop dramatically from O(n2) to approximately O(s2). This reduction in message exchange overhead will be especially important in wide area applications, where the clusters are located far apart leading to a reduction in consensus delay and improved transaction rate.
The weights are dynamically assigned to the different entities, i.e., each node will have a weight of wi where i indicates a specific node of the system. The weights wi serve two purposes. First, for each group a leader and representative is elected which is the hospital that has the highest weight in each. The group leaders and representatives then participate together in the global and final round of consensus. Second, the weights serve as a mechanism to penalize malicious nodes whose votes do not match the global vote, and the weights eventually eliminate these malicious nodes from the system. Incorporating weights in the BFT consensus has another important benefit as it improves resiliency to faults in terms of the number of nodes in the system that can turn byzantine. In fact, regular BFT protocols can tolerate up to ⅓ of the nodes to be malicious, while the weighted consensus protocol can tolerate a greater number of malicious nodes as long as their combined weight is not more than ⅓ of the total weight. Incorporation of weights in the consensus protocol is based on the King BFT algorithm proposed in: Vijay K Garg and John Bridgman, The weighted byzantine agreement problem, In Parallel & Distributed Processing Symposium (IPDPS), 2011 IEEE International, pages 524-531, IEEE, 2011, which is hereby incorporated by reference for all purposes as if fully set forth herein.
The consensus mechanism has two phases: an initialization phase that is executed only once; and the hierarchical BFT phase that is executed every consensus iteration. Algorithm 1 Hierarchical Weighted BFT is illustrated below using pseudo-code. The Hierarchical Weighted BFT is shown as having 22 lines of pseudo code. In the initialization phase (lines 1-5), the health system is composed of n hospitals hj that are clustered into s sites 1, . . .
s based on their geographical locations as depicted. It is assumed that each cluster or site HCi contains ni=3fi+1 hospitals, where fi represents the byzantine fault tolerance level of site
i (line 2). A representative hr(i) from each site
i is picked at random to coordinate consensus locally and with the other sites in the system (line 4). This set of representatives forms a set
t at iteration t. Initially, all hospitals in each site are assigned equal weights wi (line 5). At each iteration t of the protocol, the weights wi of the different set of representatives of all sites may be updated to eliminate misbehaving nodes and elect the hospital with the highest weight at each site (line 22) to be the representative/leader of its corresponding site. If two or might sites have equal weights, then representative may be selected in a round robin manner among those sites.
In the hierarchical BFT phase (lines 6-22), which represents the core of the consensus mechanism, a leader site L is selected in a round robin fashion from among representatives hr(i) from each site
i. This is done to allow each site to push the transactions that were received from entities belonging to the site to be included in the shared ledger. A client c(i), that could be a patient or a doctor for instance, located at site
i sends a transaction T(i) to one of the hospitals in the same site (line 6), which in turn forwards it to the representative hr(i) of the site
i (line 7). The representative hr(i) forwards the transaction T(i) to the representative hr(L) of the leading site HL, which collects all transactions that were sent to it from all representatives of other sites (line 7). The representative hr(L) constructs a block Bt(L) with these transactions (line 9). The representative hr(L) then proposes block Bt(L) to the hospitals in its site to reach consensus on it locally within
L using the King subroutine of Algorithm 2, which will be described below. The nodes in the site will collectively run the King algorithm which returns the final vote vt(L) of those nodes along with a digital signature σv
L, reach consensus locally on block Bt(L), then another round of consensus is run globally using a benign BFT protocol (line 16) between site representatives to reach final consensus on the block. If the block is also validated by the final benign consensus mechanism (line 17), then the block gets added to the blockchain (line 18), and the weights wi of all the hospitals in the system are updated via the UpdateWeights subroutine illustrated in Algorithm 3. Based on these updated weights wi, the set of representatives is also updated via the UpdateRepresentatives subroutine of Algorithm 4, which returns a new set of representatives
t+1 that will be used in the next round of the hierarchical consensus protocol.
Further, the client c(i) should receive a confirmation from the system that their transaction was successfully added to the blockchain. After a specific duration, if no confirmation is received, the client will resubmit the transaction to another hospital in i, and will report the hospital that did not forward its transaction to the system (lines 19 and 20).
= h1, . . . , hn is clustered into s sites
1, . . . ,
s.
i has ni = 3fi + 1 hospitals, where fi is the fault tolerance level of cluster
i, ∀ i = 1, . . . , s
i has a representative h
(i) picked at random to coordinate consensus with other sites.
t = {hr(
) , . . . , hr(s)} be the set of representatives at consensus iteration t
s.t initially the weights are equal, and ∀j, wi[j] ≥
All hj(i)s are aware of the weights of all other hj(i)s in
i
is selected in a round robin fashion
(i) located at
i sends a transaction T(i) to a hospital in
i
i's representative hr(i)
L's representative hr(L)
) ← King(hr(L) ,
L, Bt, 1)
i=1, i≠L
i ϵ
\
L do
) ← King(hr(i) ,
i, Bt(L), 1)
t, Bt(L))
)
t+1 ← UpdateRepresentatives (
,
t)
indicates data missing or illegible when filed
Next, the weighted King algorithm (see Algorithm 2 below) that represents the underlying BFT algorithm of Hierarchical BFT approach described herein and that is executed within each site.
The representative of the site, hr(i), which is also the leader of that site, starts broadcasting the block Bt being voted on at consensus iteration t to all of the hospitals in the site (line 1). A minimum number, αρ(i), of honest nodes in i, including the site representative hr(i), that have their total weight exceeding the weight ρi of faulty hospitals from previous iterations, are picked to play the role of “kings” in the algorithm (lines 2 and 3). The algorithm goes through three phases phase 1 (lines 7-15), phase 2 (lines 16-26), and phase 3 (lines 27-35), and the final vote outcome over a block may be one of two possible values: 0 means the block is not approved, and 1 means the block is valid. Only hospitals with positive weight will be able to participate in the protocol which keeps record of the weight vector wi of all nodes in
i (lines 7 and 17). The King subroutine loops through each hospital hj(i) and then loops through each of the “kings.”
In phase 1, each hospital with positive weight shares its initial vote, which could be 0 or 1, with all the hospitals in the site (line 7). Then each hospital hj(i) will check the votes that it received, including its own, which are also digitally signed (line 8). If a hospital hj(i) notices that one or more hospitals did not send their votes, or if other hospitals sent a message with a wrong format, then hospital hj(i) will add those hospitals to its preliminary set of faulty nodes faultySetj(i) (lines 9 and 10). Based on the different votes that the hospital h(i)j collected and using the weights of the corresponding hospitals, the total weight of each possible vote is calculated for the hospital hj(i) (lines 11 and 12). If one of the two possible outcomes has a total weight greater than ⅔ (since the fault tolerance threshold is ⅓) then the the node will change its vote to that value and will use it for the second phase of the algorithm (lines 13 and 14). Otherwise, the node will use undecided as its vote for the next phase (line 15).
In phase 2, the same process is repeated but with the new votes to take into consideration the decisions of the other nodes in the site. In this phase, as opposed to phase 1, a node can propose undecided as its vote (line 26), which means that the node is undecided about whether to validate or reject this block and will wait until it sees the decision of the leader to make its own decision. At the end of this phase, each hospital hj(i) will check if one of the three possible votes has a larger total weight than the others and will pick it as its final vote and use it in the third and final phase (lines 24-26).
In phase 3, only the king of the current iteration broadcasts its vote, denoted as kingvalue(i), to the remaining nodes in the site i (line 27). Each hospital receives kingvalue and makes a decision (lines 27-35). If the hospital is undecided or the weight stored in myweight from phase 2 is less than ⅔, then the hospital sets its final decision v to kingvalue only if kingvalue is not undecided, and sets it to 1 if kingvalue is undecided (lines 29-31). However, if the hospitals weight is greater than ⅔ and its vote is not undecided, then it will consider its vote as the final vote (lines 32 and 35). If this hospital notices that the king's value is different from its preference, it will add the king to its list of faulty nodes for the next round of the protocol (lines 33 and 34).
The algorithm will keep going through αρ(i) rounds executing the three phases that we explained above, but each time with a different king from set ind(i). Doing this will guarantee that there is at least one round in which one king is correct.
i, Bt, v): initiated by hr(i) with a vote v : {0, 1} over
i to reach consensus on block Bt
wi[j]) + wi[r] > ρi}where ρi is the sum of weights of all failed hj(i)s
ρi < 1/3
= 0, S1 = 0, Sv = 0
s.t. wi[
] > 0 do
(i) then
}
(i) then S1 ← S1 + wi[
]
(i) then S0 ← S0 + wi[
]
s.t. wi[
] > 0 do
(i) then
}
(i) then S1 ← S1 + wi[
]
(i) then S0 ← S0 + wi[
]
]
indicates data missing or illegible when filed
As the consensus mechanism needs to be run multiple times, it becomes natural to keep track of how each of the nodes behaves for each execution of the BFT protocol. This is done via the UpdateWeights subroutine which is illustrated in Algorithm 3 (see below). The algorithm includes three phases phase 1 (lines 4-11), phase 2 (lines 12-15), and phase 3 (lines 16-21). The UpdateWeights subroutine initializes to the empty set a variable consensuFaulty which is the set of all agreed to faulty nodes (line 1). The algorithm then loops through each hospital hj(i) (line 2). The algorithm then initializes suspectWeight hashmap for each iteration of the loop (line 3). The first phase, which is a learning phase, all hospitals with positive weights broadcast their faultySets to all remaining hospitals in the site (lines 4 and 5), so that they can all learn about faulty nodes from other hospitals (lines 6 and 7). Each hospital keeps updating the suspectWeight hashmap, which is indexed by the IDs of the hospitals, by assigning a weight for each suspect node that was included in the faulty set of one or more hospitals (lines 8 and 9). This weight corresponds to the total weight of the nodes that agreed that a specific hospital is faulty. If a hospital hj(i) notices that a suspect hospital hk(i) was voted to be faulty by some other hospitals with total weight of at least ⅓, it then it adds that hospital to its f aultySet (lines 10 and 11). This will guarantee that hk(i) is included in the faultySet of at least one honest hospital.
The second phase (lines 12-15), enables all the hospitals to reach an agreement on the set of faulty hospitals denoted as consensusFaulty, which is the same at all correct nodes.
Finally, in phase 3, the weight of the faulty nodes belonging to consensusFaulty is set to zero to punish them for their behavior and eliminate their contributions to future rounds of consensus (lines 17 and 18). The weight of the other nodes is then normalized after the faulty nodes are eliminated (lines 19 and 20). A less aggressive policy can also be adopted where instead of eliminating these nodes right away, their weight may be decreased gradually as they misbehave.
i, {faultySetj(i)}j=1ni) algorithm: updates weights of nodes in
i
s.t. wi[
] > 0 do
(i) sends faultySet
(i) to all {h
(i)}ni
=1
s.t. wi[
] > 0 do
(i) from h
(i)
(i) do
]
s.t. wi[
] > 0 do
] ≥ 1/3 then faultySetj(i) faultySetj(i) ← faultySetj(i) ∪ {
}
s.t. wi[
] > 0 do
ϵ faultySetj(i) then value ← King(hj(i),
i, ∅, 1)
i, ∅, 1)
}
ϵ consensusFaulty do
]
] ← 0
= 1, . . . , ni do
] ← wi[
]/totalWeight
indicates data missing or illegible when filed
The UpdateRepresentative routine is a simple subroutine, illustrated in Algorithm 4. The UpdateRepresentative routine aims at guaranteeing that the node with the maximum weight is always picked as a leader or representative of its corresponding site. This subroutine will always be executed after the weights are updated.
,
t) algorithm: updates the
t+1for the next consensus iteration
i ϵ
do
[i] ← maxWeight
i
The embodiments described herein solve the technological problem of providing a weighted hierarchical consensus mechanism among trusted nodes that decreases the communication overhead versus a traditional BFT consensus mechanism and that allows for more than ⅓ of the node to be faulty due to the weights applied to each node. The grouping of nodes into sites where a weighted BFT consensus mechanism is performed followed by a benign BFT consensus mechanism being performed among the site representatives greatly reduces the communication required in the network. Further, the use of weights allows for more than ⅓ of the nodes to become faulty, thus removing this as a limitation.
The embodiments described herein may be implemented as software running on a processor with an associated memory and storage. The processor may be any hardware device capable of executing instructions stored in memory or storage or otherwise processing data. As such, the processor may include a microprocessor, field programmable gate array (FPGA), application-specific integrated circuit (ASIC), graphics processing units (GPU), specialized neural network processors, cloud computing systems, or other similar devices.
The memory may include various memories such as, for example L1, L2, or L3 cache or system memory. As such, the memory may include static random-access memory (SRAM), dynamic RAM (DRAM), flash memory, read only memory (ROM), or other similar memory devices.
The storage may include one or more machine-readable storage media such as read-only memory (ROM), random-access memory (RAM), magnetic disk storage media, optical storage media, flash-memory devices, or similar storage media. In various embodiments, the storage may store instructions for execution by the processor or data upon with the processor may operate. This software may implement the various embodiments described above.
Further such embodiments may be implemented on multiprocessor computer systems, distributed computer systems, and cloud computing systems. For example, the embodiments may be implemented as software on a server, a specific computer, on a cloud computing, or other computing platform.
Any combination of specific software running on a processor to implement the embodiments of the invention, constitute a specific dedicated machine.
As used herein, the term “non-transitory machine-readable storage medium” will be understood to exclude a transitory propagation signal but to include all forms of volatile and non-volatile memory.
Although the various exemplary embodiments have been described in detail with particular reference to certain exemplary aspects thereof, it should be understood that the invention is capable of other embodiments and its details are capable of modifications in various obvious respects. As is readily apparent to those skilled in the art, variations and modifications can be affected while remaining within the spirit and scope of the invention. Accordingly, the foregoing disclosure, description, and figures are for illustrative purposes only and do not in any way limit the invention, which is defined only by the claims.
