5.3 The Generic Machine in HOL4
5.3.3 Verifying a Sample Concrete Certificate
One can perform experiments with the Boolean-valued implementation of the generic verifier on concrete certificates inside the environment of HOL4. We give two exam- ples to illustrate how the generic verifier processes information on concrete certifi- cates.
Figure 5.18 consists of the preferences recorded in an election which uses the ACT STV as its vote-counting mechanism. The election parameters consisting of the quota, number of vacancies, the candidates competing in the election and preferences cast in the election match with the ones in Figures 4.8 and 4.9. Therefore, the reader can refer to the Subsection 4.2.3 to see how the winners of this election are computed.
Figure 5.14: A Function for Deciding if Everyone is Below the Quota
Figure 5.15: less_than_quotaComputationally Realises Its Specification
Figure 5.16: Implementation of the Generic Transfer-Elected’s Semantics
Figure 5.17: Implementation and Specification of Generic Transfer-Elected’s Seman- tics Match
Here, we demonstrate how the generic verifier validates the certificate produced for that instance of election. In particular, we focus on validating the transfer-elected transition.
Figure 5.19 shows the concrete certificate produced for the instance of computa- tion with the ACT STV in this election. In Figure 5.19, there are two coloured lines. One line is in blue and the other is in orange color3. We discuss how the transition
from the machine state in orange to the one in blue occurs by a correct application of
theTRANSFER_Auxiliary_decinside the environment of HOL4.
Recall that the Definition 5.7 specifies it as a Boolean-valued procedure where one valid step has to occur in order to move from one machine state to the next. The valid step in Definition 5.6 declares that such a move from one state to another is legitimate only if it happens according to the semantics of a transition label. To this
3In case the reader is reading a back and white hard-copy of the chapter, the blue line is the 7th line
§5.3 The Generic Machine in HOL4 111
Ballot Preference Ballot Preference
b1 [A,B] b5 [C,B,A]
b2 [A,B,C] b6 [B]
b3 [B,C,A] b7 [B,C]
b4 [B,A] b8 []
Figure 5.18: Ballots’ Preferences of a Sample Election with ACT STV
10/3 2 [A,B,C] [B,A] [(b5, 1/1),(b3, 2/3),(b7, 2/3)];A{8/3}B{4/1}C{7/3};A[[(b1, 1/1),(b2, 1/1)],[(b4, 2/3)]]B[]C[]; ([],[]); [B]; [A] [];A{8/3}B{4/1}C{7/3};A[[(b1, 1/1),(b2, 1/1)],[(b4, 2/3)]]B[]C[[(b5, 1/1)],[(b3, 2/3),(b7, 2/3)]]; ([],[]); [B]; [A,C] [(b3, 2/3),(b4, 2/3),(b6, 2/3)];A{5/2}B{4/1}C{1/1};A[[(b1, 1/1),(b2, 1/1)]]B[]C[[(b5, 1/1)]]; ([],[]); [B]; [A,C] [];A{2/1}B{4/1}C{1/1};A[[(b1, 1/1),(b2, 1/1)]]B[[(b3, 2/3),(b4, 2/3),(b6, 2/3),(b7, 2/3)]]C[[(b5, 1/1)]]; ([B],[]); [B]; [A,C] [];A{2/1}B{4/1}C{1/1};A[[(b1, 1/1),(b2, 1/1)]]B[[(b3, 1/1),(b4, 1/1),(b6, 1/1),(b7, 1/1)]]C[[(b5, 1/1)]]; ([],[]); []; [A,B,C] [(b1, 1/1),(b2, 1/1),(b3, 1/1) (b4, 1/1),(b5, 1/1),(b6, 1/1),(b7, 1/1),(b8, 1/1)];A{0/1}B{0/1}C{0/1};A{}B{}C{}; ([],[]); []; [A,B,C]
Figure 5.19: A Concrete Certificate of an Election
end, the verifier which recursively calls the ValidStepfunction checks to see which one of the transitions may have happened to make the move.
Assume the generic verifier validates all the steps happening before the orange line as correct. It is time now to check if the transition from the orange line to the blue one is also correct. For this, the verifier tries the Boolean-valued decision pro- cedure TRANSFER_Auxiliary_dec. Every conjunction in the definition ofTRANS-
FER_Auxiliary_dec given in Figure 5.16 has to return the Boolean-value true in
order to certify that the transition taken from the orange line to the blue one is cor- rect.
For example, the Boolean sub-procedureValid_PileTally_dec1andValid_PileTally_dec2 check if the tally lists appearing in the orange and blue lines allocate only one tally to
each competing candidate. As another example, the functionlist_MEM_dec called on the appended list of the elected and continuing candidates in the pre-state (here the orange line) checks if every element in these two lists is indeed a member of the competing candidates.
Every Boolean sub-procedure of TRANSFER_Auxiliary_dec returns the value trueexcept one of them. The sub-procedure in the definition ofTRANSFER_Auxiliary_dec which inspects if the tally list has remained the same detects an anomaly, namely that the candidate Ahas received 1/2 votes illegally. As a result, the returned value of this sub-procedure and consequently of TRANSFER_Auxiliary_dec is false. The generic verifier however does not flag invalidity of the transition from the orange line to the blue one yet. It first tries to see if some other transition can acceptably apply. Only when there is no transition left to examine, the generic verifier sends an error message back rejecting the certificate as invalid.
The second example is also about the same concrete certificate in Figure 5.19. There is another problem with this certificate that the generic verifier does not and can not recognise. In the pile of the candidateB in the orange line, there is vote the
(b7, 2/3)that is maliciously not included in the list of uncounted ballots appearing in
the blue line. But the instructions of the ACT STV dictate that this vote should also be in the list of uncounted ballots in the blue line. There is no decision sub-procedure in any of the generic transitions’ semantics, including transfer-elected, that performs a check on whether or not all or some of the surplus votes of an elected candidate is correctly staged for being counted next. Therefore, as far as the generic verifier is concerned, this mistake does not exist.
One should not be surprised that the generic verifier fails in finding the error dis- cussed in the preceding paragraph. The generic verifier only encapsulates the com- monalities of the STV family and checks if the commonalities are preserved in a certificate. If one desires to examine the correctness of a certificate based on the par- ticular STV algorithm used for producing it, then they have to add more Boolean sub-procedures for performing more detailed checks as per instructions of the algo- rithm.
Nonetheless, one can already proceed to synthesise from the machine a verifier that is executable in an operating system’s environment. Such a generic verifier can correctly decide if given evidenceωclaimed to have been produced by an algorithm
whose counting scheme is STV, instead of e.g. First-Past-The-Post [53] where voters choose whom they prefer most and the candidate with the most amount of votes is elected. However, we wish to generate verifiers that can recognise and validate according to which specific STV algorithm the evidence ω has been output. Hence
we need to enrich the computational content of the machine semantics with more pre- and postconditions which are particular to individual STV schemes. We refer to this enrichment process as an instantiation of the machine and discuss it further in the subsequent chapter.
Chapter6
Instantiating the Generic Machine
for Automated Synthesis of Specific
Verifiers
We divide this chapter into two parts. The second part demonstrates how we auto- mate the synthesis of an executable certificate verifier for a successful instantiation of the generic machine with an STV algorithm. It discusses the content of the modules
Verifier,Translation,Parser,DeepSpec, andCompilationmodules which we briefly explained in the Section 5.2.
In the first part of the chapter, we discuss how to instantiate the generic STV machine presented in the previous chapter in order to obtain verifiers of specific STV algorithms. We shall progress through the same cycle comprised of a specification of the algorithm, implementation of Boolean decision procedures for the specifications, and then verifying the correctness of the implementations against their specification. We shall only focus on the instantiations of the transfer-elected transition. There are two reasons for our choice. First of all, the process is modular and uniform for every transition. The same development cycle comes into practice to finalise the formalisation and verification of a transition label. Therefore, explaining more than one transition introduces unnecessary duplication. Second, it completes our discussion on the generic transfer-elected in the preceding chapter. As a result, the reader comes to see a finished picture of how the development cycle advances for a single transition. In light of the first point, it also lays down a view of how the procedure happens for every other transition.
To demonstrate the flexibility of our system in producing verifiers of various STV algorithms, we provide three STV instances. The first one elaborates on the instan- tiation of the machine with the ACT STV. The second example describes how the instantiation process proceeds with the Victoria STV. The last instantiation example details how the same process happens for the CADE STV.
The purpose of including the ACT and Victoria STV schemes is to illustrate the extent to which our framework addresses the current needs of verifying computation with STV algorithms. On the other hand, the case of CADE STV exemplifies the extent to which our system can be extended and easily adapted to accommodate
generating verifiers for radically different STV schemes. The ease of extensibility and adaptability of our framework with different STV algorithms witnesses usability of the system for addressing any possibly emerging future needs for proving the correctness of computation with an STV algorithm.
6.1
Instantiation with the ACT STV
The ACT STV’s protocol explains under the section ’Step 3’ and ’transfer surplus from elected candidates’ under what conditions and how to transfer surplus votes of an elected candidate. We have already identified and formalised some of the clauses appearing in these sections that happen to be common among all STV algorithms. There nonetheless exists some other clauses that are specific to transferring surplus votes under the ACT STV’s terms. We summarise and rephrase the clauses appearing in sections as follows.
•1 the parcel of an elected with surplus is not empty.
•2 distribution of the surplus of an elected candidate proceeds in one single step. •3 surplus of elected candidates is distributed one at a time beginning with those
who are elected earlier.
•4 pile of the candidate whose surplus is transferred is emptied in the post-state. •5 only the last parcel of votes received (which resulted in a surplus) is transferred.
It may be that the last parcel is the only parcel in a candidate’s pile (if only one application of the count action has occurred previously), or more parcels exist (if the count transition has been applied several times earlier)
•6 pile of any candidate other than the one whose surplus is transferred at this stage remains the same.
•7 the fractional transfer value is then computed depending on whether or not the
last parcel is the only parcel of ballots in the pile of the elected candidate. We define declarations in HOL4 that formally specify the above clauses. Con- junctions of these formal specifications with the assertion TRANSFER_Auxiliary comprise the formal declaration of the ACT STV’s transfer-elected semantics as Fig- ure 6.1 illustrate it. We continue by explaining the formal assertions appearing in the figure and pointing at the informal clause(s) with which they match.
• Lines 54, 55, 65. the pre-state and post-states on which TRANSFERoperates are both non-final machine states. The components of these states have to satisfy the requirements of the generic transfer-elected formalised inTRANS- FER_Auxiliary.
§6.1 Instantiation with the ACT STV 115
Figure 6.1: Specification of the ACT STV’s Transfer-elected Semantics
• Lines 57, 59. the backlog of the elected candidate is not empty as the candidate c is in the head position of the list. Also, there are surplus votes in the pile of the candidatecto transfer upon this application ofTRANSFER(item•1).
• Line 59, 61. this application ofTRANSFERdistributes candidatec’s surplus in one step (item •2). Also, once the application of TRASNFERis over, name of the candidate c is removed from the backlog of the elected candidates in the post-statenbl(item•3). Moreover, only the last parcel of votes received bycare staged for distribution among the continuing candidates (item•5).
• Lines 62, 63, 64. The pile of the candidatecwhose surplus distribution is done is emptied in the post-state (item•4). Also, every candidate’s pile in the post-state other thanc’s remains the same as in the pre-state (item•6).
Note that we take care of formalising item•7in the semantics of the elect transition. We shall next exemplify how to implement the formal specification given in lines 63 and 64 which correspond to the item •6. We then proceed to formally establish the
correspondence between the implementation and the specification of this component. Figure 6.2 contains the Boolean decision procedures called subpile1andsubpile2 which implement lines 63 and 64.
Figure 6.3: Logical Specifications ofsubpile1andsubpile2Force their Computational Contents
Figure 6.3 illustrates the proof thatsubpile1andsubpile2computationally realise their specification.
Conversely, if the computational content ofsubpile1andsubpile2are correct, then their logical declarations are also correct as proofs in Figure 6.4 demonstrate.
Figure 6.4: The Computational Content ofsubpile1andsubpile2Forces their Logical Specifications
In a similar manner, we implement other decision procedures each of which cor-
Figure 6.5: Implementation of the Semantics of the ACT STV’s Transfer-elected responds with some specification(s) in the definition of TRASNFER. Conjunctions of these Boolean-valued functions comprise a function (Figure 6.5) that is the imple- mentation of the transfer-elected semantics.