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.
1. A method for performing a flexible byzantine fault tolerant (BFT) protocol for a consensus by a replica device, the method comprising:
receiving, from a client device, a first proposed value;
determining to broadcast a blame message on the first proposed value based on a first quorum being reached and the safe;
broadcasting the blame message to the client device and other replica devices;
executing a view change by:
collecting at least one additional blame message from one or more of the other replica devices;
forwarding the collected blame messages to the other replica devices and the client device,
replacing the client device with a new client device, and
entering a new view based at least in part on the replacement of the client device with the new client device setting; and
transmitting a status to the client device regarding the executed view change.
2. The method of claim 1 , further comprising:
determining that the collected blame messages meet or exceed a second quorum threshold; and
based on the determination that the collected blame messages meet or exceed the second quorum threshold, replacing the client device with the new client device as a leader device.
3. The method of claim 2 , further comprising:
receiving, from the new client device, a second proposed value; and
determining to broadcast a safe vote on the second proposed value to the client device and other replica devices based on the first quorum being reached.
4. The method of claim 2 , further comprising:
reporting, to the leader device, a status of a locked block; and
transitioning to a steady state.
5. The method of claim 4 , wherein the locked block is a value that has been selected.
6. The method of claim 1 , further comprising:
responsive to transmitting the status to the client device, transitioning to a steady state;
receiving a safe block as a second proposed value; and
transmitting a safe vote on the second proposed value.
7. The method of claim 1 , wherein determining to broadcast the blame message on the first proposed value is further based on one or more of the replica device not observing progress in an original view, observing more than one height block in the original view, or detecting malicious leader behavior.
8. A system configured to perform a flexible byzantine fault tolerant (BFT) protocol for a consensus by a replica device, the system comprising:
a transceiver configured to receive, from a client device, a first proposed value; and
a processor configured to:
determine to broadcast a blame message on the first proposed value based on a first quorum being reached;
control the transceiver to broadcast the blame message to the client device and other replica devices;
execute a view change by:
collecting at least one additional blame message from one or more of the other replica devices,
forwarding the collected blame messages to the other replica devices and the client device,
replacing the client device with a new client device, and
entering a new view based at least in part on the replacement of the client device with the new client device; and
control the transceiver to transmit a status to the client device regarding the executed view change time.
9. The system of claim 8 , wherein the processor is further configured to:
determine that the collected blame messages meet or exceed a second quorum threshold; and
based on the determination that the collected blame messages meet or exceed the second quorum threshold, replace with a new client device as a leader device.
10. The system of claim 9 , wherein the processor is further configured to:
control the transceiver to receive, from the new client device, a second proposed value; and
determine to broadcast a safe vote on the second proposed value to the client device and other based on the first quorum being reached.
11. The system of claim 9 , wherein the processor is further configured to:
report, to the leader device, a status of a locked block; and
transition to a steady state.
12. The system of claim 11 , wherein the locked block is a value of that has been selected.
13. The system of claim 8 , wherein the processor is further configured to:
responsive to transmitting the status to the client device, transition to a steady state;
control the transceiver to receive a safe block as a second proposed value; and
control the transceiver to transmit a safe vote on the second proposed value.
14. The system of claim 8 , wherein the processor is further configured to:
determine to broadcast the blame message on the first proposed value is further based on one or more of the device not observing progress in an original view, observing more than one height block in the original view, or detecting malicious leader behavior.
15. A non-transitory computer storage medium storing instructions executable by a first computer system at a first site that, when executed by a processor of the first computer system, cause the processor to:
control a transceiver to receive, from a client device, a first proposed value;
determine to broadcast a blame message on the first proposed value based on a first quorum being reached;
control the transceiver to broadcast the blame message to the client device and each of the other replica devices;
execute a view change by:
collecting at least one additional blame message from one or more of the other replica devices,
forwarding the collected blame messages to the other replica devices and the client device,
replacing the client device with a new client device, and
entering a new view based at least in part on the replacement of the client device with the new client device; and
control the transceiver to transmit a status to the client device regarding the executed view change.
16. The non-transitory computer storage medium of claim 15 , wherein: the instructions further cause the processor to:
determine that the collected blame messages meet or exceed a second quorum threshold; and
based on the determination that the collected blame messages meet or exceed the second quorum threshold, replace the client device with the new client device as a leader device.
17. The non-transitory computer storage medium of claim 16 , wherein instructions further cause the processor to:
control the transceiver to receive, from the new client device, a second proposed value; and
determine to broadcast a safe vote on the second proposed value to the client device and other replica devices based on the first quorum being reached.
18. The non-transitory computer storage medium of claim 16 , wherein the instructions cause the processor to:
report, to the device, a status of a locked block; and
transition to a steady state.
19. The non-transitory computer storage medium of claim 15 , wherein the instructions further cause the processor to:
responsive to transmitting the status to the client device, transition to a steady state;
control the transceiver to receive a safe block as a second proposed value; and
control the transceiver to transmit a safe vote on the second proposed value.
20. The non-transitory computer storage medium of claim 15 , wherein the instructions further cause the processor to determine to broadcast the blame message on the first proposed value further based on one or more of the replica device not observing progress in an original view, observing more than one height block in the original view, or detecting malicious leader behavior.