The STV machine has no dead state so that it can always move from a non-final state to another state. We achieve this property by proving the applicability lemma (Fig- ure 3.22) that guarantees one of the transitions always applies as long as the machine is in a non-final state, and no transition is applicable once the machine reaches to a terminal state.
As discussed in Section 2.3, the sanity checks impose a universally appearing order of application on the machine transitions. We formally realise this order of ex- ecution of transitions in the content of the applicability proof. Figure 3.23 schemat- ically represents the overall structure of the proof. The proof begins by using the tacticaldestructto distinguish between three cases, namely when the given state jis an initial state, an intermediate state, or a final one. In the first case, the transition
initStep applies and the last case there is nothing to do because we have evidence
that jis not a final state.
The interesting case happens when j is state(ba,t,p,(bl1,bl2),e,h) for some un-
counted ballots ba, tally t, pile p, bl1 list of elected candidates whose votes await
transfer, bl2 list of eliminated candidates whose votes awaits transfer, and the list
of electede and continuing candidates h. Then the proof proceeds according to the following.
1. Are all seats filled or no continuing candidate left i.e. length(e) =stor h= []? •if yes then applyewinand declare winners
•if not then
2. Islength (e)+ length(h) less than or equal tost? •if yes then applyhwinand declare winners •if not then,
3. Is there uncounted ballots, i.e. ba6= []? •if yes then applycounttransition •if not then,
j initStep Do Nothing length(e+ +h)≤ st length(e)≤st hwin ba = [] ewin ∀c.t(c) < quota count bl2 = c::bl20 bl1 = [] elect transfer-elected transfer-removed concat(pile (c)) = [] elim initial state final state intermediate intermediate No Yes No Yes Yes No Yes No No No Yes Yes No Yes
Figure 3.23: Structure of Applicability Proof
•if yes then elect them byelecttransition •if not then,
5. Is the backlog of the eliminated candidates empty?, i.e. bl2= []?
•if no then,
6. Is any votes from an eliminated candidate at the head position ofbl2left to trans-
fer? i.e. concat(pile(c)) = []?
•if yes then applytransfer-removed
•if not, then
7. Is there any elected candidate whose surplus awaits transfer, i.ebl1 = []?
•if yes then applytransfer-elected
•if no then applyelim
To correctly establish the above structure for the proof we invoke the tactical destruct to visit every possible situation that can occur for the data structure of the machine. Now remember that the applicability sanity checks for each transition ascertain whenever the conditions are satisfied, that transition applies and a post-
§3.4 Verification of the Machine Properties 59
stateconcexists to which the machine moves using the transition. At each stage of the proof, we instantiate the existential j2 in the Rule_Applicationlemma with the concobtained using the sanity check of the transition applied.
Termination The last general property of the STV machine is termination (Fig- ure 3.24). Given a machine states, the content of the applicability proof is repeated so that starting from s some sequence of transitions apply where each reduces the complexity measure while moving from its pre-state to the post-state. Eventually, the machine reaches a terminal state where winners of the election are announced and a certificate of this instance of computation is output as well.
Figure 3.24: Termination Theorem
Put in the context of programming semantics, each execution of the machine has meaning. The sequence of transitions applied along with the machine states visited to reach the final state is the meaning of this execution. The final state resulted from this execution is the value of the execution. Moreover, each value is accompanied by a certificate which carries the meaning of the execution. The certificate in and by itself is meaningful so that it can be investigated for examining the correctness of the value of the execution (with respect to the input of this run) without reference to where and how the certificate is produced.
Chapter4
Instantiation of the Model
In the preceding chapter, we demonstrated how the generic machine formally re- alises the commonalities in the STV family. In the current chapter, we elaborate on how our framework accommodates formalisation and verification of each individual STV scheme through instantiation of the machine. Recall that the STV machine is a record consisting of generic transition labels and evidence that each generic transi- tion satisfies its sanity checks (see Figure 3.19). Each machine instantiation with an STV algorithmArequires three steps.
• specification of transitions. We want to remove as many trusted layers as possible to minimise the trusted computing base. On the one hand, we must, therefore, verify the correctness of the implementations below against the instructions in A. On the other hand, typically STV algorithms are described in informal en- vironments and languages such as textual documents, which are not suitable for formal reasoning. We hence need a formal counterpart of A’s instructions in order to reason about the implementation’s correctness in Coq. We con- sequently specify declarations in Coq that are the formal specifications of the informal description ofA’s transition labels.
• implementation of transitions. The machine transitions are merely generic types which do not carry computational content. On the other hand, sanity checks only give a semantics that is common among all STV family members without specifying any meaning particular to individual STV algorithms. In contrast, for computation based onA, we need to implement computational entities that (a) indeed compute an output for a given input and (b) perform the computa- tion as per instructions inA.
• discharging sanity checks. Having implemented and formally specified the al- gorithmA, we proceed to establish proofs that (a) the implementation indeed satisfies the specification so that computational behaviour of the implementa- tion matches with instruction in A, and (b) the specification/implementation successfully discharge the sanity checks so that our specification/implementa- tion is guaranteed to be an authentic STV algorithm. By successful discharge of the semantics requirements, we automatically obtain the guarantee that each instantiated algorithm inherits the machine properties such as termination.
We demonstrate in some detail how the above cycle of specifying, implementing, and discharging the sanity checks develops for elect transition of the ACT STV [? ]. To this end, we begin by a thorough analysis of the textual description of the ACT STV given in the Subsection 2.1.1 with a focus on the elect transition in order to identify the semantic requirements of the elect that are specific to this scheme. Then, we define a formal specification and an implementation for the informal semantics of the transitions elect, obtained through the analysis. We next discuss how to discharge the elect’s sanity checks to complete instantiation of the generic elect transition of the machine with ACT’s elect.
To illustrate how instantiated transitions with ACT STV collectively realise the ACT scheme, we briefly discuss formalisation of the ACT’s transfer-elect transition as well. We then proceed with a discussion on alternative ways of formalisation of one same STV algorithm by drawing on our detailed analysis and formalisation of the ACT.
We subsequently explain how to extract a Haskell compilable program for each formalised scheme. Each extracted program produces a certificate for each instance of computation performed on an input value. We elaborate on what the certificates are and how they establish transparency and verifiability of the tallying process. Finally, we illustrate some experimental results obtained by executing the extracted Haskell program for the ACT STV on real historical data of elections in the ACT state.
4.1
Analysis of the ACT STV
To pinpoint semantics of ACT STV’s transitions, we refer to the textual description of the algorithm given in Subsection 2.1.1 which can also be found at the official webpage of the ACT’s government [2]. Our initial effort is to only depend on this document for the algorithm analysis. Nonetheless, we shall see shortly afterwards that the document is occasionally vague on the description of some part of the proce- dure, or entirely lacks any specification about the subject matter. Therefore, we need to refer to other related resource as well. We shall reference other documents only if more evidence is needed to justify our interpretation, and the text or the ACT’s government webpage suggest referring to them for further information.
Recall that the elect transition which corresponds to the action of electing candi- dates only applies (under circumstances discussed below) to intermediate states of computation. Given an intermediate state state(ba,t,p,(bl1,bl2),e,h), the semantics
of the elect transition specifies the post-state state(ba0,t0,p0,(bl10,bl20),e0,h0)to which the computation proceeds by applying this transition. The semantics comprises the pre- and postconditions which impose constraints on when the elect transition can legitimately apply and how to update each piece of information in the post-state.
From a careful examination of the textual description of the ACT STV the follow- ing clauses result which comprise an informal semantics for electing a candidate.
§4.1 Analysis of the ACT STV 63
• list of uncounted ballots.
– clause 1. the list of uncounted ballots in the pre-state of the elect transition