Scenario one We have already formalised and verified instantiation of the machine with five different STV algorithms1. If the algorithmAalready exists in our frame- work then the desideratum is satisfied. No effort beyond following simple instruc- tions to execute on the command line is required for synthesising an executable verifier forA.
Scenario two Another possibility is thatAas a whole does not literally match with any of the already existing instantiations of the machine in the framework. However, clauses describing pre- and postconditions of transitions which are components of the semantics ofAdo exist in theAuxiliarymodule2. Then all one needs doing is to call the formal specifications of the clauses and their respective implementations into the specification and implementation of transitions, respectively, to formally obtain an instantiation of the algorithm. In this case, the proofs also succeed in satisfying the desideratum.
Scenario three Suppose there is a clause in the description of A whose specifica- tion, and therefore implementation, does not exist in the Auxiliary module. Then one trivially has to extend the Auxiliary module by specifying and implementing that clause and then verifying the implementation correct against the specification. If one was overconfident in their implementation, then they can take the implemen- tation as its specification in which case no verification is required. Note that as including the generic formal machine transitions in the semantics of each transition instantiation is mandatory there are few numbers of such clauses and consequently few lines of encoding needed to formalise them.
Once the proofs of equivalence between the specification and implementation of a machine instantiation either automatically or interactively succeed, the rest of verifier synthesis process for the instantiated machine completely automatically follows. We have fully automated the Verifier, Parser, DeepSpec, and Compilation modules. Also translation of assertions in theTranslationmodules happens automatically by calling the name of the translator tool of CakeML. Therefore, from this point onward, no user has to carry out any more task to obtain an executable version of a verifier for their desired STV algorithm. We shall discuss the details of how this automated process advances in the subsequent part of this sequel.
6.4
Verifier in HOL4: Specification, Implementation and Ver-
ification
In this section, we discuss the formalisation of the content of the Definition 5.7 which mathematically describes what a verifier is. As you see in the definition, the specifi- cation of a verifier of computation with some STV algorithmA, and consequently its
1See the Github repository at https://github.com/MiladKetabGhale 2See Figure 5.3 in Section 5.2 for more information on this module.
computational content as well, depends on an instantiation of the machine with A. Despite this dependence, the way in which the verifier inspects evidence produced upon executions ofAis universal. A verifier, regardless of which algorithm is instan- tiated into the machine, is a Boolean procedure whichchecks the correctness of input evidence by recursively validating two consecutive steps at a time. Also, there is more universality to the mechanism of verifying evidence, namely that the inspection of consecutive steps forvalidation happens by examiningthe correctness of thedisjunctions
ofthe semantics of instantiated transitions.
The above understanding of the behaviour of a verifier for processing information in evidence of instances of computation opens the possibility of automating several modules in the framework’s component. In particular, we formalise and implement the Definition 5.7, and then verify the correctness of the implementation once and for all in such a way that it automatically operates for any successful instantiation of the machine3.
To make the above happen, in light of the above discussion and the Remarks 6.2.1 and 6.2.2, we engineer the Verifier module in such a way that it calls in one in- stantiation module at a time. As a result, the specifications, implementations and proofs developed in the Verifiermodule are adapted to work for creating a verifier for the called instantiation module. This latter means that the verifier which we consequently obtain is a verifier for computation with the algorithm that has been successfully instantiated into the machine and called in theVerifiermodule. We ob- tain a verifier for various STV algorithms by varying the instantiation module which is called in theVerifiermodule.
So suppose ˆAspec = hS,T,(S0
t)t∈Ti is the specification of a machine instantia- tion with the formalised algorithm A as defined in Definition5.4 and discussed in Section 6.1. Also assume ˆAdec = hS,T,(S0
t)t∈Ti is the implementation of the algo- rithm A for which the Desideratum 6.1 either automatically or interactively have been proven correct.
Then the technical specification of a verifier consists of two steps. First, we need to validate whether the first machine state in the certificate is a valid initial state of the count. A valid initial judgement is one where
• every candidate’s tally is zero as no votes have been counted yet,
• everyone’s piles are empty because no votes have yet been allocated to anyone,
• the backlog of the elected and eliminated candidates are empty,
• the list of elected candidates is empty because no one has yet been elected, and
• the list of continuing candidates consists of every competing candidate in the election as it is the starting point of the competition.
Figure 6.8 shows the formal specification of a valid initial machine state. At this point, we can explain about one other difference between the formalisation of the
3By a "successful instantiation of the machine" we mean an instantiation of the machine for which
§6.4 Verifier in HOL4: Specification, Implementation and Verification 123
generic STV as a machine which we did in Coq with the one carried out in HOL4. In the framework component developed in Coq, the data structure of the machine has a constructor for specifying the initial states of the machine. As a result, the set of machine transitions in Coq have a transition called Start for moving from an initial state to an intermediate machine state. One notices that all the Starttransition does is to assure that the tallying happens only based on the formal (valid) votes of the election and that the initial values of the tally, pile, lists of elected and eliminated candidates and the backlogs are as we have specified them above.
Figure 6.8: Specification of a Valid Initial Machine State
We choose a different way of accommodating the notion of a valid initial state of computation in our HOL4 formalisation. For checking that the first line of a certificate of computation matches with a valid initial state, we simply perform the checks that Figure 6.8 illustrates them in the definition of initial_judgement. This choice of formalisation has two man advantages;
1. the data structure for constructing machine states becomes simpler than the one given for the Coq component of the framework. Also, the mechanism of the vote-counting used for checking the correctness of certificates produced becomes simpler as we have one less transition to deal with.
2. it is more cost-efficient in terms of time and memory. In the Coq component, the initial state holds information of the votes recorded in the system in order to filter the valid ones. This costs memory for keeping the data and also for during the parsing phase. Also, since we do have aStarttransition any more, it saves time in processing the information in a certificate for validation or rejection. The second step for specifying the certificate verifier is to define formally define what a valid transition from one machine state to another is. The following assertions declare that in order to legitimately move from one state to another, at least one transition should be legally applicable.
Using Valid_Step_Spec, we define a recursive procedure for validating a list of intermediate machine states given in a certificate.
Putting the specification of a valid initial machine state and a list of non-final machine states together, we obtain a formal declaration for a valid certificate.
For checking a formal certificate we therefore first verify that certificate starts at a permissible initial stage. We then iteratively check that transitions have happened correctly and that the terminating state is a final one where winners are declared.
Figure 6.9: Specification of a Valid Step From one State to Another
Figure 6.10: Specification of a Valid List of Non-final Machine States
Figure 6.11: Specification of a Valid Formal Certificate
We implement Boolean-valued decision procedures for each of the above spec- ifications. In particular, the specification of a valid certificate corresponds to the following computational formal certificate checker.
Figure 6.12: Implementation of the Formal Certificate Verifier
The correctness of the implementation of the formal certificate verifier above rests on the equivalences we have already established (Figure 6.13) between the specifica- tions and the computational counterparts of the Boolean sub-procedures, namelyIni-
tial_Judgement_decandvalid_judgements_decwhich theCheck_Parsed_Certificate
calls to validate a formal certificate. Drawing on the correctness proofs of the sub- procedures on whichCheck_Parsed_Certificaterelies, we establish (Figure 6.15) the fact that it process information in a formal certificate according to its specification in HOL4.