Evidence Auditing with Terminal API

[JanisErdmanis]

The PeaceFounder system is universally verifiable, a feature ensuring that every vote is cryptographically proven to come from a registered member, even if all involved parties are corrupt. To mitigate the influence of coercion or bribery, the authority can strategically delay the publication of votes, which weakens the link between coercers and their subjects before the voters lose receipt freeness. After the votes are published, every aspect of the voting process is transparent: all proofs of votes are made publicly available. This transparency allows any interested party to audit the election results and, at their convenience, independently reproduce the announced tally.

Evidence auditing in the PeaceFounder system begins immediately after the authority publishes the election tally, accompanied by a tree hash of the votes. Each voter's client software maintains a 'consistency proof chain.' This chain validates that their vote has been recorded accurately. Subsequently, voters can update their proof chains to verify that their vote remains included in the final announced tally. This verification is done by comparing the tree hash displayed on their device with the one in the official tally.

In cases where a voter discovers a discrepancy in the tree hash or their devices show inconsistencies with the newly received ballot box commitment, they have the option to generate a blame proof. This proof can be published anonymously, proving the corruption of the authority. However, the effectiveness of this system relies on a critical assumption: the public environment must be open to these blame proofs and hold the authority accountable. If this receptiveness is lacking, the published tree hash cannot be regarded as a consensus. Therefore, auditors must consider potential corruption within the authority and be vigilant about the channels through which they receive a ballotbox tree hash.

The best source for the ballotbox tree hash comes from the member's client devices, which can display the current tree hash and forward ballotbox commitment to the auditor. Even if the devices are infected with the malware, they would be unable to affect the ballotbox commitment. PeaceFounder's security is fundamentally based on the premise that at least one device remains uncompromised, and the voter would compare the tree hash shown on the device with that of an officially announced tally, and a corrupt ballot box collector cannot discern which device is. Therefore, that compels them to maintain a consistent view of the ballot box ledger for everyone, as failing to do so would generate blame proof.

When the auditor secures the authoritative source of the ballot box tree hash, they can initiate a comprehensive audit. The process begins with the retrieval of both the ballotbox and braidchain ledgers. This retrieval may involve collecting records through individual HTTP requests, accessing published records on a GitHub repository, or utilising other hosting providers and synchronisation solutions. Once all necessary data has been gathered, the auditor conducts an initial verification to ensure the completeness of the data using the following command:

peacefounder-audit root ballotbox ⌘371:sha256:BFDODDC-6FSEFOCF-B852883-2F1F1581-B33EDS3-73CESAD5-DAEFD8DA-39414A7

where ballotbox is the location of records.

In the event of an invalid ballot box commit, the command will trigger an error. Conversely, if there are more records in the ballot box than indicated by the commit tree hash, a warning prompts the auditor to verify whether a new tree hash has been officially announced with the tally or if member devices have retrieved a newer version. Should neither be the case, the auditor will have the option to isolate the uncommitted records for separate inspection.

The next step involves auditing all published evidence, which can be executed using the following command:

peacefounder-audit eligibility braidchain ballotbox

In this context, braidchain refers to the retrieved records. It's important to note that the braidchain itself does not require separate verification. This is because each vote in the ballotbox includes a hash of the corresponding proposal, which in turn contains a tree hash within its anchor section. If the braidchain does not contain a proposal with a given hash, or if the braidchain tree hash is inconsistent with that of one listed in the proposal, the audit will terminate with an error. In such cases, the auditor must seek an alternative source to retrieve the braidchain.

After the tree hash of the braidchain is verified, it follows through checking its integrity. Records are issued by authorised entities listed in the DemeSpec roster; checks that all signatures are valid and that added records are compatible with the braid chain state and verify zero-knowledge proofs of the braid receipts. Finally, the pseudonym set with which votes are collected in the ballot box is compared by the generator encoded in the with the one ge proposal anchor.

When the audit successfully verifies that only eligible pseudonyms have cast the vote, the process can advance to a tallying stage, executed with the following command:

peacefounder-audit tally ballotbox ⌘371:sha256:BFDODDC-6FSEFOCF-B852883-2F1F1581-B33EDS3-73CESAD5-DAEFD8DA-39414A7

This command checks first that every signature for the vote is valid. Then, it proceeds in selecting valid votes, which are then finally being counted. This command works without braidchain as ballotbox contains proposal, demespec and inclusion proof for the demespec with respect to the proposal anchor tree root under ballotbox/meta directory (the votes themselves are stored under ballotbox/votes and receipts under ballotbox/receipts). Note that this works because the hash function is passed with the tree hash. Upon a successful audit, the command outputs the final tally along with the ballot box tree hash.

The last part of auditing is verifying the authenticity of the members who could have participated in the vote, which is important to establish the legitimacy of the vote. In situations where all membership supporting documents are given to the auditor, the auditing stops there. However, in a situation where supporting documents are sampled as proposed previously, the way the sample is formed must be verified to be verifiably random. This could be audited as follows:

peacefounder-audit cohort braidchain electoral-roll-sample

where electoral-roll-sample contains a meta folder that includes a proposal record and a pulse issued by Legue of Entropy. This is, however, just an API and will need to be implemented with electoral roll sampling feature implementation.

With the implementation of evidence auditing, the Model part of the PeaceFounder codebase could be refactored into Core, which could contain only the types and methods necessary to implement auditing and is something which could be investigated. In such a situation, audit terminal API could be implemented under the Audit module, which would depend only on Parser and Core, making it easier to reason about it.

The necessary steps thus to support this API are:

• [x] implement serialisation/deserialization for a braid receipt record;
• [x] store the evidence on the disk;
• [x] implement a method to retrieve all records over HTTP;
• [x] implement record submission to a GitHub repo, which can be configured from admin panel;
• [x] collect the auditing pieces under Audit module and implement terminal API;
• [x] refactor the Model module and create a Core module;
• [x] make an integration test where braidchain and ballotbox are serialised into the disk and then verified with the Audit module.

[JanisErdmanis]

The current storage implementation is a bit messy. It will improve in the future when ledger storage is done within an abstract vector implementation with which the ledger is initialised.

[JanisErdmanis]

During the implementation of audit methods for the ballotbox ledger and thinking a bit further on the issue #20 it became clear that a ballotbox ledger needs to store the voters which are eligiable for the vote. Currently the eligiability of each vote is checked within Model.isbinding(::BraidChainLedger, ::BallotBoxLedger) making this method complex even more so when the feature #20 will be implemented.

In the alternative scenario the voters would be stored within the ballotbox ledger thus every vote eligiability and alias resolution auditing could be done isolated with ::BallotBoxLedger alone wheras Model.isbinding(::BraidChainLedger, ::BallotBoxLedger) would only need to check that proposal, demespec and voters are part of the chain.

It also seems beneficial if a hash of the voters would be included within the proposal. This would enable a collector of the votes not needing another security mechanism in place to ensure integrity if the collector server is relocated on a different server.

[JanisErdmanis]

The final endavour for synchronizing a public buletin board with a remote git repository is finally finished: Uppon initialization a README.md and audit_workflow.yml is and with the button "Push to Remote" ballotbox and braidchain is synchronized to remote. To keep matters seperated locally a dublicate is kept to avoid accidental contamination from the remote to the local state. The impact of disk storage is minimized as hardlinks are used for files.

An example repo generated with the interface is https://github.com/PeaceFounder/PeaceFounderDemo