Patent classifications
G06F11/182
Resource-governed protocol and runtime for distributed databases with consistency models
- Karthik Raman ,
- Arsalan Ahmad ,
- Momin Mahmoud Al-Ghosien ,
- Padma Priya Aradhyula Bhavani ,
- Rajeev Sudhakar Bhopi ,
- Junyan Guo ,
- Ji Huang ,
- Atul Katiyar ,
- Hemant Kumar ,
- Sujit Vattathil Kuruvilla ,
- Ovidiu Constantin Platon ,
- Venkata Sivaramakrishna Ramadugu ,
- Ankur Savailal Shah ,
- Pankaj Sharma ,
- Dharma Shukla ,
- Shreshth Singhal ,
- Shireesh Kumar Thota
Distributed transactions are performed over a collection of servers operating as replicas of a data set, where a successful transaction involves meeting a quorum count of replicas that locally commit the transaction. However, performance constraints of data sets and consuming applications may vary (e.g., sensitivity to latency, scalability, and/or consistency), and the performance characteristics of the server set may be partly determined by the transactional commitment and quorum selection. The distributed transaction may be applied by designating the replicas as a set of followers and a leader that initiates the transaction and receives acknowledgments of local commits by each follower. On condition of the acknowledgments meeting a quorum count for the data set according to the performance characteristics of the application, the leader locally commits the transaction and delivers a result. The transaction may also be applied over collections of replica sets using a second-level quorum to achieve nested consensus.
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.
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.
PRIORITIZING SHARED BLOCKCHAIN DATA STORAGE
Disclosed herein are methods, systems, and apparatus, including computer programs encoded on computer storage media, for storing blockchain data. One of the methods includes receiving a plurality of blocks from a blockchain node in the blockchain network; for each of the plurality of blocks: determining a first number of blockchain nodes that store a dataset divided from an error correction coding (ECC) encoded version of the block and a second number of blockchain nodes that store a dataset comprised of redundant bits divided from the ECC encoded version of the block; calculating a priority value of the block based on the first number and the second number; and encoding at least a portion of the plurality of blocks using ECC to generate a plurality of encoded blocks based on the priority value.
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.
REDUNDANCY CONTROL DEVICE FOR AIRCRAFT
The redundancy control device includes three controllers that output status signals, a majority voting circuit to which a first voltage or a second voltage is supplied as an output signal through an output line of each controller, a switch provided in each output line, a voltage supply unit provided for each output line to supply the second voltage to the output line when the first voltage is lost, a latch circuit provided for each output line to latch the second voltage when the second voltage is supplied thereto and continue to output the second voltage, a comparison circuit provided for each controller to output a comparison signal based on a comparison of the status signals, and a switch control unit provided for each switch to outputs a switch signal to the switch in response to the comparison signal from the comparison circuit.
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.
Dynamic blockchain data storage based on error correction code
Disclosed herein are methods, systems, and apparatus, including computer programs encoded on computer storage media, for storing blockchain data. One of the methods includes receiving a request for performing error correction coding (ECC) to one or more blocks of a blockchain, obtaining the one or more blocks based on blockchain data received from at least one blockchain node of the blockchain network, and performing ECC of the one or more blocks to generate one or more encoded blocks, wherein a code rate of the one or more encoded blocks equals a minimum number of honest blockchain nodes required by the blockchain network and a total number of blockchain nodes of the blockchain network.
Prioritizing shared blockchain data storage
Disclosed herein are methods, systems, and apparatus, including computer programs encoded on computer storage media, for storing blockchain data. One of the methods includes receiving a plurality of blocks from a blockchain node in the blockchain network; for each of the plurality of blocks: determining a first number of blockchain nodes that store a dataset divided from an error correction coding (ECC) encoded version of the block and a second number of blockchain nodes that store a dataset comprised of redundant bits divided from the ECC encoded version of the block; calculating a priority value of the block based on the first number and the second number; and encoding at least a portion of the plurality of blocks using ECC to generate a plurality of encoded blocks based on the priority value.