Patent classifications
G06F11/187
FLEXIBLE BYZANTINE FAULT TOLERANCE
A method and system for performing a flexible Byzantine fault tolerant (BFT) protocol. The method includes sending, from a client device, a proposed value to a plurality of replica devices and receiving, from at least one of the plurality of replica devices, a safe vote on the proposed value. The replica device sends the safe vote, based on a first quorum being reached, to the client device and each of the other replica devices of the plurality of replica devices. The method further includes determining that a number of received safe votes for the proposed value meets or exceeds a second quorum threshold, selecting the proposed value based on the determination, and setting a period of time within which to receive additional votes. The method further includes, based on the period of time elapsing without receiving the additional votes, committing the selected value for the single view.
Efficient, time-based leader node election in a distributed computing system
A same voting time, a same vote counting time, and a same leader node tenure is configured by a host for all nodes. Time configuration information including the same configured voting time, the same vote counting time, and the same leader node tenure, is sent to all the nodes. The nodes are operable to vote during the same voting time, count the number of votes during the same vote counting time, and elect a leader node according to a vote counting result. The nodes are enabled to perform periodic node election according to the same leader node tenure.
FACILITATING PRACTICAL BYZANTINE FAULT TOLERANCE BLOCKCHAIN CONSENSUS AND NODE SYNCHRONIZATION
Implementations of the present disclosure include setting, by a first consensus node, a timer that runs out before a timeout of a view change; sending, to a second consensus node, a request for one or more consensus messages missing by the first consensus node in response to the timer running out; receiving, from the second consensus node, the one or more consensus messages each digitally signed by a private key of a corresponding consensus node that generates the respective one or more consensus messages; and determining that a block of transactions is valid, if a quantity of commit messages included in the received one or more consensus messages is greater than or equal to 2f+1, where f is a maximum number of faulty nodes that is tolerable by the blockchain based on practical Byzantine fault tolerance.
Methods, devices and systems for real-time checking of data consistency in a distributed heterogenous storage system
First and second pluralities of replicated state machines may execute a sequence of ordered agreements to make mutations to data stored in first and second data storage services of first and second types, respectively. First and second metadata of the mutated data stored in the first and second data storage services may then be received and stored. The first and second data storage services may then be synchronized using the received first and second metadata to determine when the data stored in the first and second data storage services have both settled after having mutated according to a predetermined agreement of the sequence of ordered agreements. A comparison of the stored first and second metadata may then be carried out when the data stored in the first data storage service and the data stored in the second data storage service have settled according to the predetermined agreement.
Facilitating practical byzantine fault tolerance blockchain consensus and node synchronization
Implementations of the present disclosure include setting, by a first consensus node, a timer that runs out before a timeout of a view change; sending, to a second consensus node, a request for one or more consensus messages missing by the first consensus node in response to the timer running out; receiving, from the second consensus node, the one or more consensus messages each digitally signed by a private key of a corresponding consensus node that generates the respective one or more consensus messages; and determining that a block of transactions is valid, if a quantity of commit messages included in the received one or more consensus messages is greater than or equal to 2f+1, where f is a maximum number of faulty nodes that is tolerable by the blockchain based on practical Byzantine fault tolerance.
Hierarchical weighted consensus for permissioned blockchains
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.
Distributed processing method and distributed processing system providing continuation of normal processing if byzantine failure occurs
A distributed processing method to receive data by a plurality of servers each including a processor and a memory, and process the data by replicating, the method includes a first determination step in which the servers each receive the replicated data, and a first determination unit determines a degree of consistency of the received data and an output step in which the servers each receive a determination result of the degree of consistency of the data from the first determination unit, and if the determination result includes data that guarantees consistency, the server outputs the data that guarantees consistency. A first number of servers that are to receive the data is set in advance based on a prescribed allowable number of failures that defines the number of servers that can have failures, and an allowable number of byzantine failures that defines the number of servers that can have byzantine failures.
VOTING OF TRIPLE REDUNDANT CIRCULAR DATA
The voter circuit and method determines a voted output among plural inputs each carrying circular data. To supply the voted output, a statistical average (e.g., mean or median) is computed by grouping the plural inputs into pairs, and for each pair generating a minimum angular difference by selecting the minimum of (a) the absolute difference between the pairs of inputs, and (b) the conjugate of the absolute difference between the pairs of inputs. The voted output is a statistical average generated from the minimum angular difference.
HIGH-RELIABILITY NON-VOLATILE MEMORY USING A VOTING MECHANISM
A memory system includes a processing device (e.g., a controller implemented using a CPU, FPGA, and/or logic circuitry) and memory regions (e.g., in a flash memory or other non-volatile memory) storing data. The processing device receives an access request from a host system that is requesting to read the stored data. In one approach, the memory system is configured to: receive, from the host system over a bus, a read command to access data associated with an address in a non-volatile memory; in response to receiving the read command, access, by the processing device, multiple copies of data stored in at least one memory region of the non-volatile memory; match, by the processing device, data from the copies with each other; select, based on matching data from the copies with each other, first data from a first copy of the copies; and provide, to the host system over the bus, the first data as output data.
Consensus system downtime recovery
Methods, systems, and apparatus, including computer programs encoded on computer storage media, for consensus system downtime recovery. One of the methods includes: multicasting a pre-prepare message to at least some of the backup nodes; obtaining (Q−1) or more prepare messages respectively from (Q−1) or more of the backup nodes, wherein the prepare messages each indicate an acceptance of the pre-prepare message by the corresponding backup node; storing the pre-prepare message and the (Q−1) or more prepare messages; multicasting a commit message to at least some of the backup nodes, the commit message indicating that the primary node agrees to the (Q−1) or more prepare messages; and obtaining, respectively from Q or more nodes among the primary node and the backup nodes, Q or more commit messages each indicating that the corresponding node agrees to (Q−1) or more prepare messages received by the corresponding node.