Byzantine Leader Election

We now introduce an eventual leader-detector abstraction with Byzantine processes.

As mentioned before in the context of failure detectors, one cannot rely on the time-liness of simple responses for detecting arbitrary faults. We must exploit another way to determine remotely whether a process is faulty or performs correctly as a leader. Our approach is best described as “trust, but verify.” Every newly chosen leader gets a chance to perform well. But the other processes monitor its actions, and should the leader not have achieved the desired goal after some time, they replace it with a new leader. Electing political leaders uses the same approach in many countries.

More specifically, we assume that the leader should perform some actions according to an algorithm, within some time bounds. If the leader performs wrongly or exceeds the allocated time before reaching this goal then other processes detect this and report it as a failure to the leader detector. In an eventually synchronous system, every process always behaves according the algorithm and eventually all remote processes also observe this; if such correct behavior cannot be observed from a process then the process must be faulty. To make this work in an eventually synchronous system, every elected leader is given progressively more time than its predecessors to achieve its goal.

It is important that this notion of good performance depends on the specific algo-rithm executed by the processes, which relies on the output from the leader-detection module. Therefore, eventual leader election with Byzantine process abstractions is not an isolated low-level abstraction, as with crash-stop processes, but requires some input from the higher-level algorithm. For expressing this input, we introduce a

⟨ Complain | p ⟩ event. Every process may complain against the current leader p by triggering this event. We assume that every correct process successively increases the time between issuing complaints.

The Byzantine leader-detector abstraction is obtained from Module2.9by aug-menting its interface with the ⟨ Complain | p ⟩ request. The eventual accuracy property, which required every process to trust a correct process eventually, is

Module 2.10: Interface and properties of the Byzantine eventual leader detector Module:

Name: ByzantineLeaderDetector, instance bld.

Events:

Indication: ⟨ bld, Trust | p ⟩: Indicates that process p is trusted to be leader.

Request: ⟨ bld, Complain | p ⟩: Receives a complaint about process p.

Properties:

BLD1: Eventual succession: If more than f correct processes that trust some pro-cess p complain about p, then every correct propro-cess eventually trusts a different process than p.

BLD2: Putsch resistance: A correct process does not trust a new leader unless at least one correct process has complained against the previous leader.

BLD3: Eventual agreement: There is a time after which no two correct processes trust different processes.

replaced by two new conditions. The eventual succession property ensures that the primitive eventually elects a new leader after more than f correct processes have complained against the current leader. Furthermore, the putsch resistance property ensures that no leader is removed from power, unless at least one correct process has complained against the leader. Taken together, these conditions imply that ev-ery correct process eventually trust some process that appears to perform its task in the higher-level algorithm. Module2.10summarizes the specification. In contrast to Module2.9, one cannot require that every correct process eventually trusts a correct process because a Byzantine process may behave just like a correct process.

Algorithm: Rotating Byzantine Leader Detection. Algorithm2.10, called “Rota-ting Byzantine Leader Detection,” implements a Byzantine eventual leader-detector abstraction, assuming that N > 3f. The algorithm maintains a continuously inc-reasing round number and deterministically derives the leader from it. Recall that N denotes the number of processes in the system (i.e., the size of Π). The leader of a round r is simply the process p whose rank is r mod N. Because there is no process with rank0, the leader is the process with rank N if r mod N = 0. This derivation is given by the function

leader(r) =

!p where p satisfies rank(p) = r mod N, if r mod N ̸= 0 q such thatrank(q) = N, otherwise.

A process broadcasts a COMPLAINT message when the higher-level algorithm triggers a ⟨ Complain | p ⟩ event and p is the current leader. Whenever a process receives more than2f COMPLAINTmessages against the current leader, it switches

Algorithm 2.10: Rotating Byzantine Leader Detection Implements:

ByzantineLeaderDetector, instance bld.

Uses:

AuthPerfectPointToPointLinks, instance al.

upon event_⟨bld,Init_⟩do round:=1;

complainlist:=_[⊥]^N; complained:= FALSE;

trigger_⟨bld,Trust _|leader(round)_⟩;

upon event_⟨bld,Complain_{| p ⟩}such thatp =leader(round)and complained=FALSEdo

complained:= TRUE; forallq∈ Πdo

trigger_⟨al,Send _{| q},[COMPLAINT, round]⟩;

upon event_⟨al,Deliver| p,[COMPLAINT,r]⟩such thatr =roundand complainlist[p] =⊥do

complainlist[p]:= COMPLAINT;

if#(complainlist) > f∧complained=FALSEthen complained:= TRUE;

forallq∈ Πdo

trigger_⟨al,Send _{| q},[COMPLAINT, round]⟩; else if#(complainlist) > 2f then

round:= round+ 1; complainlist:=_[⊥]^N; complained:= FALSE;

trigger_⟨bld,Trust_|leader(round)_⟩;

to the next round. Furthermore, when a process receives more than f C^OMPLAINT messages but has not sent a COMPLAINTmessage itself in the current round, it joins the complaining processes and also sends a COMPLAINTmessage. This mechanism serves two goals: first, it ensures that the Byzantine processes alone cannot provoke a leader change; second, it guarantees that once a correct process switches to the next round, every other correct process eventually also switches to that round.

In Algorithm 2.10, the function #(S) for a set S or for a list S denotes the number of elements in set S or the number of non-⊥ entries in list S, respectively.

It is used throughout this book to obtain the cardinality of a data structure.

In the pseudo code, the notation [x]^N for any symbol x denotes the N-vector [x, . . . , x]; vectors may be indexed by processes or by numbers.

Correctness. The eventual succession property follows directly from the algorithm because every complaining correct process broadcasts a COMPLAINT message.

These messages cause the remaining correct processes to chime in, so that every

correct process eventually receives N −f > 2f C^OMPLAINTmessages and replaces the current leader.

Because there are only f Byzantine processes, the putsch resistance property follows trivially. For the eventual agreement property, note that the correct pro-cesses eventually cease to complain against a correct leader because they wait long enough for the leader to achieve its goal. When all COMPLAINT messages have been received subsequently, every correct process is in the same round and trusts the same process.