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 computerized method for performing a flexible byzantine fault tolerant (BFT) protocol by a replica device, the method comprising:
receiving, from a client device, a first proposed value;
collecting, from other replica devices, one or more votes on the first proposed value in a first view;
observing an equivocating vote indicating an equivocating value;
broadcasting a blame message and the equivocating value to the client device and the other replica devices;
collecting one or more blame messages from one or more of the other replica devices,
forwarding the collected one or more blame messages to the other replica devices and the client device; and
entering a second view.
2. The computerized method of claim 1 , wherein each of the one or more votes comprises one of a safe vote or a non-safe vote on the first proposed value.
3. The computerized method of claim 1 , wherein the replica device executes a first protocol with a first delay bound and a second replica device of the other replica devices executes a second protocol with a second delay bound.
4. The computerized method of claim 3 , wherein only the client device knows both the first delay bound and the second delay bound.
5. The computerized method of claim 1 , further comprising:
locking on the first proposed value in the first view; and
until the first proposed value is locked, voting only on the first proposed value in the second view.
6. The computerized method of claim 1 , wherein the client device commits the first proposed value upon collecting unique votes on the first proposed value meeting or exceeding a commit threshold.
7. The computerized method of claim 6 , wherein the commit threshold chosen by the client device is larger when an adversary is likely to break safety than the commit threshold chosen by the client device when the adversary is likely to attack liveness.
8. A system configured to perform a flexible byzantine fault tolerant (BFT) protocol 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:
collect, from other replica devices, one or more votes on the first proposed value in a first view;
observe an equivocating vote indicating an equivocating value;
broadcast a blame message and the equivocating value to the client device and the other replica devices;
collect one or more blame messages from one or more of the other replica devices,
forward the collected one or more blame messages to the other replica devices and the client device; and
enter a second view.
9. The system of claim 8 , wherein each of the one or more votes comprises one of a safe vote or a non-safe vote on the first proposed value.
10. The system of claim 8 , wherein the replica device executes a first protocol with a first delay bound and a second replica device of the other replica devices executes a second protocol with a second delay bound.
11. The system of claim 10 , wherein only the client device knows both the first delay bound and the second delay bound.
12. The system of claim 8 , wherein the processor is further configured to:
lock on the first proposed value in the first view; and
until the first proposed value is locked, vote only on the first proposed value in the second view.
13. The system of claim 8 , wherein the client device commits the first proposed value upon collecting unique votes on the first proposed value meeting or exceeding a commit threshold.
14. The system of claim 13 , wherein the commit threshold chosen by the client device is larger when an adversary is likely to break safety than the commit threshold chosen by the client device when the adversary is likely to attack liveness.
15. A non-transitory computer storage medium storing instructions executable by a computer system of a replica device, the instructions when executed by a processor of the computer system, cause the processor to:
receive, from a client device, a first proposed value;
collect, from other replica devices, one or more votes on the first proposed value in a first view;
observe an equivocating vote indicating an equivocating value;
broadcast a blame message and the equivocating value to the client device and the other replica devices;
collect one or more blame messages from one or more of the other replica devices,
forward the collected one or more blame messages to the other replica devices and the client device; and
enter a second view.
16. The non-transitory computer storage medium of claim 15 , wherein each of the one or more votes comprises one of a safe vote or a non-safe vote on the first proposed value.
17. The non-transitory computer storage medium of claim 15 , wherein the replica device executes a first protocol with a first delay bound and a second replica device of the other replica devices executes a second protocol with a second delay bound.
18. The non-transitory computer storage medium of claim 17 , wherein only the client device knows both the first delay bound and the second delay bound.
19. The non-transitory computer storage medium of claim 15 , wherein the client device commits the first proposed value upon collecting unique votes on the first proposed value meeting or exceeding a commit threshold.
20. The non-transitory computer storage medium of claim 19 , wherein the commit threshold chosen by the client device is larger when an adversary is likely to break safety than the commit threshold chosen by the client device when the adversary is likely to attack liveness.