We next demonstrate how the framework modularly extends to instantiations with various STV algorithms. To this end, we present two cases. First, we discuss instan- tiation of the transfer-elect based on the Victoria STV. Then we explain the transfer- elected of the CADE STV and show how our system realises an instantiation with this algorithm.
6.2
Instantiations with the Victoria and CADE STV
We shall exemplify the modularity in the implementation of the framework compo- nent by discussing the case of transfer-elected transition. We shall elaborate on the textual descriptions of the Victoria STV and the variant algorithm by comparing them against the ACT STV’s. Then, we present the Boolean procedure which implements the informal semantics clauses of the transfer-elected of the two algorithms and show which informal clause(s) are implemented by which function(s).
We neither illustrate how to obtain a formal specification of the informal condi- tions above, nor we demonstrate how the implementation of the Boolean functions matches with their formal specifications. We nonetheless encourage the astute reader to construct such formal semantics from the informal clauses that we provide shortly afterwards, or refer to the GitHub repository for details of the formalisation.
The legislature of Victoria’s counting scheme does not strictly speak about the no- tion of the parcel. However, as explained under the subsection 3.2 it transfers votes of an eliminated candidate stepwise which therefore requires separating votes into different chunks (or parcels). Hence, the pile of every candidate has to be divided into parcels so that they can subsequently be distributed one by one. Consequently, the type of a pile object is a list of ballots list, instead of a list of ballots.
Having reminded a necessary remark on the legislature of the Victoria protocol, note that Victoria STV matches with ACT STV on every•i item under the Section 6.1 except fori∈ {5, 7}.
•50 transfer all of the surplus votes of an elected candidate at a reduced fraction. •70 the fractional transfer value is computed based on all of the surplus (not nec-
essarily depending on the last parcel).
The Clause•70 appears in the semantics of the Victoria’s elect transition. But the
clause •50 is the main difference between the Victoria’s and ACT’s informal seman-
tics of the transfer-elected. Figure 6.6 contains the implementation of the Victoria’s transfer-elected. As you see in line 33, the transition distributes all of the surplus votes of an already elected candidate (clause•50).
The modularity in implementation of the system clearly shows its strength in the formalisation of the Victoria’s transfer-elected. Breaking the formalisation into separate parts each of which encapsulates some part of the protocol, instead of a
Figure 6.6: Implementation of the Victoria’s Transfer-elected
gigantic formalisation, has the advantage of using the already existing infrastructure to accommodate STV cases which are close to the already formalised ones. Here, we do not need to re-do everything in order to realise Victoria’s transfer-elected. We only need to add the formal clauses for which the Victoria varies from the ACT.
The next STV example, makes the flexibility of our system stand out. The transfer- elected of this STV algorithm is considerably different from Victoria’s and ACT’s. Nonetheless, we shall see how easy it is to formalise the variations on top of the existing implementations.
6.2.1 Instantiation with the CADE STV
Despite the fact that STV algorithms have had stable characteristics, there have his- torically been changes to them as well [54]. Therefore, a framework such as ours for dealing with STV algorithms has to facilitate enough structure for being eas- ily adaptable to possibly emerging STV algorithms. Our framework accommodates formalisation and verification of the CADE STV which significantly varies from stan- dard STV algorithms. This case exemplifies the degree to which our system easily extends to a considerably varying vote counting application with STV algorithms.
We discussed in Subsection 4.4 that there is more than one way of formalising the CADE STV in the first component of the framework. We argued how one can merge the semantics of the transfer-elected with that of the elect transition to obtain a more efficient implementation for the CADE STV. The second component also allows specifying and verifying CADE STV in different ways. However, we illustrate how to formalise the transfer-elected semantics in HOL4 for constructing a verifier of the CADE STV without merging the semantics of the transfer-elected with the semantics of the elect transition. From this demonstration one simply understands how to proceed with the integration of the two semantics, if they choose this alternative. The following comprise the informal clauses of the CADE STV’s tranfer-elected.
?1 the backlog of elected candidates contains one element.
§6.2 Instantiations with the Victoria and CADE STV 119
?3 the election restarts after each round of transfer-elect.
The clause?3itself consists of the following sub-clauses. ?3a pile of all of the candidates is emptied in the post-state.
?3b all ballots in the piles of all candidates are placed back into the list of uncounted ballots with the name of already elected candidate removed from those ballots. ?3c the eliminated candidates are “resurrected” meaning they start to be continuing
candidates in the post-state.
Figure 6.7: Implementation of the CADE’s Transfer-elected
We explain in short how some of the clauses correspond with which lines in the Figure 6.7.
• Line 31 is a decision procedure stating that the list of uncounted ballots in the post-state of the transition consists of all of the votes recorded in the piles of candidates (clause?3b).
• Line 33 is another Boolean-valued procedure deciding if the pile every candi- date in the post-state is empty (clause?3a).
• Line 34 comprises a Boolean-valued function which decides if the list of contin- uing candidates in the post-state consists of every candidate competing in the election except those who are already elected (clause?3c).
Once an instantiation of the machine completes we next proceed to verify logical equivalences of the specification of each transition as a unity with its implementation. Based on our experience, proving such equivalences roughly requires 200 lines of HOL4 encoding. We desire to automate them in a way that they practically work for different instances of the machine instantiations with various STV schemes. We remark on two points which are important to notice in order to understand how we progress towards automating these equivalences.
Remark 6.2.1 In this section, when we instantiated transitions of the machine, particu- larly transfer-elect, we named instantiations uniformly. We represented an instantiation of transfer-elect with the ACT, Victoria, and CADE STV algorithms byTRANSFER_dec. Re- call from Subsection 5.2 that every machine instantiation happens in a separate module (see Figure 5.3) two of which we schematically show in the figure by calling themSTV1andSTV2.
Therefore, naming the implementation of the transitions of different STV algorithms similarly does not cause any clash when calling them in dependent modules. For example, theverifier
module in Figure 5.3 which comprises the formalisation and verification of the verifier no- tion given in Definition 5.7 calls each instantiation module separately one at a time. Hence, the theorem prover HOL4 identifies the right reference to TRASNFER_dec without any confusion.
Remark 6.2.2 The Core calculus of HOL4 uses term rewriting to manipulate assertions expressed in higher-order logic and ML programming style. Since HOL4 is a rewriting sys- tem, what appears as the name of an assertion on the left of ⇔ is therefore secondary to its definitional content on the right side. In light of the previous remark, we can uniformly re- fer tonames of instantiated transitions regardless of the algorithm used. Therefore we can formulate evidence verifier based on the names of the transitions but call in the desired instan- tiation module to embody the names with the semantics of the algorithm intended to obtain a verifier for. Consequently the Verifier, Translation, DeepSpecandCompilationmodules in Figure 5.3 which all depend on instantiation modules as their parents are developed once and for all.