Schiedermeier et al.

Applied Network Science (2024) 9:51 Applied Network Science

https://doi.org/10.1007/s41109-024-00650-2

RESEARCH Open Access

Anonymous voting using distributed

ledger‑assisted secure multi‑party computation
Maximilian Schiedermeier1,2, Omar Hasan2*, Tobias Mayer3, Lionel Brunie2 and Harald Kosch4*

*Correspondence:
[email protected];
Abstract
[email protected] High voter turnout in elections and referendums is desirable to ensure a robust
1
Present Address: Université du democracy. Secure electronic voting is a vision for the future of elections and refer-
Québec à Montréal, Montréal, endums. Such a system can counteract factors hindering strong voter turnout such
Canada
2
LIRIS, INSA Lyon, Villeurbanne, as the requirement of physical presence during limited hours at polling stations.
France However, this vision brings transparency and confidentiality requirements that render
3
ConnectedCare GmbH, Telgte, the design of such solutions challenging. Specifically, the counting implementa-
Germany
4
University of Passau, Passau, tion must support reproducibility, and the choice of individual voters must remain
Germany confidential. In this paper, we propose and evaluate a novel referendum protocol
that ensures transparency, confidentiality, and integrity, in trustless networks. The
protocol is built by combining secure multi-party computation and distributed ledger
technology, e.g., a Blockchain. The persistence and immutability of the protocol com-
munication allow verifiability of the referendum outcome by any participant. Voters
therefore do not need to trust third parties. We provide a formal description and con-
duct a thorough security evaluation of our proposal.
Keywords: E-voting, Anonymity, Transparency, Distributed ledger, Blockchain, SMPC,
Trustless networks

Introduction
Over the past years, we have witnessed a sharp decline in voter turnout in major elec-
tions (Mestre 2022). For example, in the 2022 French legislative elections, the turnout
was only 46.2% in the critical second round of the elections (Darame and Roger 2022).
The voter turnout for the 2018 US midterm election was at 53.4% (Bureau 2019). Though,
compared to previous elections this is a high value, almost half of the population at vot-
ing age did not make use of their right to vote. In the US midterm elections in 2014 and
2010, the turnout was as low as 36.7% and 41.8% respectively (Ballotpedia 2022).
It is a longstanding goal to render the voters’ active participation as effortless and
convenient as possible to mitigate low voter turnout. A secure voting system based on
remote clients could greatly improve the flexibility of potential voters. It would signifi-
cantly reduce the administrative overhead of postal voting and eliminate voters’ obliga-
tions to be physically present at a voting station during limited hours.
In this paper, we focus on referendums, which can be seen as a special instance of
elections, with only two voting options. Even though referendums are a simpler case

© The Author(s) 2024. Open Access This article is licensed under a Creative Commons Attribution 4.0 International License, which permits
use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original
author(s) and the source, provide a link to the Creative Commons licence, and indicate if changes were made. The images or other third
party material in this article are included in the article’s Creative Commons licence, unless indicated otherwise in a credit line to the mate-
rial. If material is not included in the article’s Creative Commons licence and your intended use is not permitted by statutory regulation or
exceeds the permitted use, you will need to obtain permission directly from the copyright holder. To view a copy of this licence, visit http://
creativecommons.org/licenses/by/4.0/.
Schiedermeier et al. Applied Network Science (2024) 9:51 Page 2 of 25

of elections, implementing them correctly is still very challenging (Clarkson et al.

2008; Springall et al. 2014). Many parties may have an interest in the manipulation
of the outcome. Furthermore, we consider the context of trustless networks, where
we assume that participants place little to no trust in one another and there does not
exist a central trusted authority, or such an entity is not desirable. A breach of the bal-
lot secrecy may result in harmful consequences for voters. Given this sensitive con-
text, voters naturally seek solutions they can trust.
The classic analog way of conducting a secret referendum is having voters cast their
ballots into boxes. This procedure ensures individual ballots are unlikable to the voter.
However, the logistic effort imposed by such an approach is tremendous. Ballot boxes
must be set up, ballots with voting options must be printed and afterwards, the count-
ing must be realized by fair participants. The complex chain of implicit actions makes
it hard for the individual to hold proof of compliance at every step. In this article, we
try to address this problem with an electronic referendum scheme that emphasizes
transparency, that is to say, full client-sided verification of correctness.

Contribution
We propose a transparent referendum protocol with immutable proceedings and ver-
ifiable outcome. We define this immutability as the impossibility of tampering with
the log of participant actions. Although there already exist protocols with similar
ambitions, they commonly provide little evidence to the end user that the designated
protocol was followed in practice. We suggest a protocol that is based on a creative
combination of existing cryptographic tools. To achieve transparency, we also assess
the viability of our proposal considering mobile clients and discuss to which extent
the protocol can withstand adversary attacks. Our evaluation concentrates on the
confidentiality of votes, transparency and immutability of proceedings and a verifi-
able outcome.
The key idea behind our contribution is to use a distributed ledger, to keep a complete
and publicly accessible log of all communication between participants. Blockchain tech-
nology fulfills this criterion but so does any distributed ledger technology with integ-
rity protection, e.g. a distributed database with logs and hashsums. While the secrecy of
individual votes is ensured by an SMPC scheme, the log allows anyone with access to the
ledger to autonomously compare the actual proceedings to the expected protocol. This
verification of the voting outcome can occur locally. In return, this means participants
gain proof of correctness by themselves (instead of having to trust a third party).
We note that this paper is an extended version of our prior conference paper (Schie-
dermeier et al. 2019) in the proceedings of the International Conference on Complex
Networks and Their Applications. This paper extends the conference paper by more
than 30% and provides a much more in-depth and updated discussion of the topic. An
earlier version (Schiedermeier et al. 2019) of this paper has also been made available
on the arXiv preprint server. The extensions in the present paper as compared to the
conference paper are summarized below.

• Several sections have been extended with new and updated information.
Schiedermeier et al. Applied Network Science (2024) 9:51 Page 3 of 25

• The “Introduction” section has been revised and updated. Two new subsections
on the “Contribution” and the “Outline” of the article have been added as well.
• The “Related work” section has been completely rewritten. It now spans two and a
half pages instead of previously half a page. It discusses the current state of the art
in further detail. The paper now cites 31 relevant references in total instead of 13
previously.
• The “Adversary model” section has been extended with two new subsections:
“Malicious communication” and “Assumptions”.
• The section on “The protocol” now presents a more detailed description of the
proposed protocol.
• The “Conclusion” now includes a new subsection on “Future work”.

• A number of new full sections have been added. These include:

• A new section on the “Building blocks” used for the construction of the protocol,
including four subsections describing “Secret sharing scheme”, “Distributed ledger
technology”, “Asymmetric encryption”, and “Anonymous credentials”.
• A new section that discusses the “Scalability” aspects of the protocol.
• A new section on “Enforcing honest behavior in real-world application”.

• The existing figures have been renewed for better clarity. Moreover, new figures have
been added for more thorough explanation, which include:

• “Illustration of Shamir’s Secret Sharing”.

• “Illustration of t − n threshold system robustness”.

Outline
In this article, we first give a quick overview of related articles that pursue similar objec-
tives. Some of them follow strategies that are very different from our approach. We
point out the issues that they pose and how we intend to address them. Next comes a
brief presentation of our model, followed by an enumeration of the cryptographic tools
we apply within our protocol. Afterwards, we delve into the exact phases and actions
that describe our protocol, followed by an evaluation in two parts. The first part dis-
cusses how well our initial objectives are met by the proposal. The second provides a
security analysis where we evaluate different adversary strategies and their potential
impact. Finally, we present our conclusions and delineate the potential topics of further
investigation.

Related work
In this section, we present articles that discuss how to design a protocol for elec-
tronic referendums. For each one, we outline the key idea and highlight the associated
disadvantages.
Benaloh et al. describe in Benaloh (1987) how secret-sharing schemes can be used as
SMPC for secret ballot elections. This work unarguably is the cryptographic founda-
tion of our proposal. However, Benaloh’s formal model by itself provides no practical
Schiedermeier et al. Applied Network Science (2024) 9:51 Page 4 of 25

transparency for the participants. In his approach, security lies entirely in the applied
threshold system, i.e., participants have no dynamic feedback on the effectiveness of
the applied security mechanisms. Our proposal not only protects the privacy of vot-
ers, it also transparently monitors if ballots have been potentially compromised.
The work by Diaz et al. (2009) describes and evaluates an architecture for a pri-
vacy-aware electronic petition system. As petitions typically express only two opin-
ions (non-participation meaning approval, participation meaning disapproval of a
topic), it can be considered a referendum system. The core element of this approach
involves anonymous certificates to elegantly restrict the referendum to eligible par-
ticipants and eliminate double-spending in a privacy-aware manner. However, the
suggested protocol does not provide enough transparency for an anonymous voter’s
participation: The act of participation by signing is not publicly transparent, there-
fore a dishonest petition server could discard signatures. The outcome would be
indistinguishable from a case where the voter has never even contacted the server.
Notably, the voter has no way to prove the misbehavior of the signature server. While
our approach also involves anonymous credentials, we make sure that the semantics
of issued tokens are independent of effectuated voting decisions. This allows us to
ensure transparency, which ultimately renders dishonest server behavior detectable.
In Zyskind (2015a) and Zyskind et al. (2015b), Zyskind et al. provide a description of
the Ledger-enabled SMPC platform (ENIGMA). Our contribution differs in two aspects:

1. ENIGMA was not explicitly designed for referendums. Though the authors men-
tion a general compatibility for such scenarios, its applicability for this context is not
assessed in much detail.
2. In their platform, the ledger is neither an exclusive data store nor is it used as an
exclusive channel for inter-participant communication. Therefore participants do not
obtain the same level of communicative transparency as in our solution.

The work of Cortier et al. (2019) relies on a threshold system that can defend the
secrecy of ballots until a fixed number of colluding adversaries. However, their proto-
col provides no control mechanism to monitor whether such collusion was attempted
or has already occurred. As such voters can not obtain certainty that their votes have
remained undisclosed.
Bursuc et al. identified similar objectives (Bursuc et al. 2019): they introduce a met-
ric to measure voter privacy and examine how compromised systems perform under
that metric. In reaction to this evaluation, they then suggest a protocol that performs
well, given the metric. However, their protocol is very focused on that specific aspect
and provides no mechanisms for other important goals, such as the prevention of bal-
lot dropping.
Very related to our approach is a proposal by Li et al. (2019), where an IoT-enabled
protocol is discussed. The presented approach gains security by persisting encrypted
votes in a blockchain. However, there are two fundamental differences to our approach:

1. It does not include a client-side analysis of communication meta-data, excluding an

additional verification of protocol proceedings.
Schiedermeier et al. Applied Network Science (2024) 9:51 Page 5 of 25

2. In the described model, there is a clear and intentional separation between the block-
chain infrastructure and the voting devices. For registration and notably casting of
ballots, the voters access the blockchain via a gateway. This separation of blockchain
and clients also eliminates the possibility of performing integrity checks on the cli-
ent’s side. Clients thus have to rely on external entities for full integrity checks of the
blockchain.

In Lee et al. (2016), Lee et al. describe a blockchain-based voting protocol. In contrast
to our proposal, their solution involves a trusted third party for vote filtering. The work
proposed in Ayed (2017) also suggests a blockchain-based voting system. However, in
their system, the blockchain arranges persisted votes in an immutable order. Therefore,
voters can not update their vote, once it has been submitted. Our system does not rely
on such a mechanism and therefore does not come with this restriction. In Riemann and
Grumbach (2015), Riemann et al. introduce a taxonomy of further notions for distrib-
uted voting protocols.
Song et al. (2021) tackle the problem of scalability in anonymous voting implemen-
tations on the Ethereum platform. They identify several bottlenecks that impede the
scalability of prior solutions on Ethereum. One of the issues they resolve is the tallying
failure due to the “no vote” from registered voters. The scheme demonstrates a substan-
tial reduction in “gas” (the unit of resource consumption on Ethereum). For example,
with 60 voters, the scheme consumes 1/53 of the gas compared to another state-of-the-
art solution (Hao et al. 2010).
Zaghloul et al. (2021) introduce the d-BAME electronic voting scheme that empha-
sizes mobility in addition to anonymity. The scheme relies on the participation of two
opposing parties to ensure election integrity and accountability. The proposed scheme
preserves voter privacy by using secure multiparty computations, which must be per-
formed by parties that have conflicting allegiances. Their simulations show that the
scheme can be deployed on smartphones in large-scale elections. Similar to our work,
Zaghloul et al.’s scheme leverages blockchain as a public tamper-resistant bulletin board.
However, they use a blockchain platform that implements smart contracts, whereas
we do not impose this requirement in our work. Moreover, we note that in contrast to
Zaghloul et al.’s proposal, our scheme does not have the requirement of the participation
of opposing parties in the voting process.
Onur and Yurdakul (2022) propose ElectAnon, a ranked-choice election protocol
that focuses on anonymity, robustness, and scalability. ElectAnon uses zero-knowledge
proofs to enable voters to cast their votes anonymously. Experiment results show that
ElectAnon reduces “gas” consumption on Ethereum by up to 89% as compared to the
state-of-the-art. The work also discusses how to reduce the requirement of trust in the
election authorities.
Uribe et al. (2022) describe anonymous voting solutions specifically for Decentral-
ized Autonomous Organizations (DAOs). They observe that current DAOs use voting
schemes that are not anonymous. According to the authors, the lack of anonymity in
DAO voting results in numerous issues when it comes to confidentiality, voter influence,
and voter turnout. Uribe et al. present a voting scheme for DAOs that enables confiden-
tiality, in addition to maintaining ballot integrity.
Schiedermeier et al. Applied Network Science (2024) 9:51 Page 6 of 25

Our model
Participants
We distinguish between physical entities, identifiers and roles. Each physical entity pos-
sesses a unique and anonymous identifier. Furthermore, there are three roles that the
physical entities can personify. A single entity can personify multiple roles, but not all
combinations are allowed. The restrictions are explained in “Roles” section.

Roles
Our protocol considers several roles:

• Initiator: The initiator ensures all participants obtain the information required for
the protocol execution. This role I is represented by a single physical entity init. The
initiator provides a referendum context that comprises all information required by
other participants to follow the referendum procedure.
• Voters: Voters are the devices of natural persons eligible to provide their opinion on
the referendum context. We define the eligible set of k physical voter entities to a
given referendum as V = {v1 , ..., vk }.
• Workers: Workers contribute to the execution of the protocol’s underlying SMPC
and provide intermediate results required to compute the referendum outcome and
verification checksum. The set of n physical worker entities is a subset of the voter
entities: W = {w1 , ..., wn }, W ⊂ V . Workers are an example of physical entities per-
sonifying multiple roles. The physical entity behind each worker also, at some point
acts as a voter. One advantage of this decision is that the total amount of entities,
required to run our protocol decreases by | W |. In general, allowing a single entity to
act on behalf of multiple roles is critical, as this gathers additional information for an
entity. However, in this case, the applied security mechanisms ensure that knowledge
about a single ballot does not enable the worker to infer further information.

Identities
When we talk of participants P, we implicitly mean the physical entities behind voters
and workers. Although with the definition P = V ∪ W , P is equal to V, we intentionally
introduce P for participants. Participants do not know each other directly, but only by
an anonymous pseudo-identifier p̄. Likewise, we introduce the set of all pseudo-identi-
fiers as P̄ . Only for illustration purposes, we denote a mapping function id : P → P̄ that
translates a specific entity p ∈ P to its associated identifier p̄ ∈ P̄ . It is important to state
that in practice no entity must ever possess such a function. Participant anonymity is
an essential element in our protocol. From this point on when we talk of identifiers, we
implicitly mean pseudo-identifiers. Each participant holds a key pair. The private key is
used for signatures and decryption. It never leaves the participant. The public key is used
for encryption and also serves as a participant’s identifier.
We assume that the initiator holds a complete list of all eligible voters’ identifiers
V̄ = {id(v) | v ∈ V }. We consider this to be a fair assumption since Diaz et al. (2009)
demonstrated how anonymous credentials (described in “Anonymous credentials”
Schiedermeier et al. Applied Network Science (2024) 9:51 Page 7 of 25

section) can be issued among eligible voters, using an external credential server. As
a proof-of-concept, Diaz et al. use the Belgian e-ID card as an authentication source.
Their use case is about issuing anonymous credentials that are used to anonymously sign
petitions. The system guarantees that the users’ anonymity is preserved for the step of
petition signing due to the use of anonymous credentials. Despite this anonymity, the
system ensures that the eligibility can be verified before the issuance of the credentials.
This approach unlinks a petition signer’s true identity from the pseudo-identity that they
would use for signing the petition. In the section on related work (“Related work” sec-
tion), we discuss the work by Diaz et al. in further detail as well as the differences from
our protocol for the referendum phase.
In the context of our protocol, we can assume that there exists a system similar to Diaz
et al. outside the protocol to verify the eligibility of the voters and subsequently issue
anonymous credentials. This system could be based on the approach of Diaz et al. or any
other one that allows eligibility verification yet ensures anonymity for the voting phase.
The eligibility verification entity would learn the identity of the user as well as personal
attributes such as age, nationality, etc., which are required for validating eligibility. How-
ever, it would not be able to link this information with the user’s vote. We also note here
that the eligibility verification system may be decentralized or indeed centralized. If
the initiator is a centralized entity, for example, the election authority of a geographical
region, then the eligibility verification system would naturally be centralized. However,
the architecture of the eligibility verification system does not impact the properties of
the proposed referendum protocol because the eligibility verification phase is assumed
to take place before the referendum and outside of the protocol.

Ledger
A key component of our model is an immutable and integrity-protected data store that
is directly accessible by all participants. This is the ledger L. Access to the ledger enables
the retrieval of persisted records and the submission of new records. Persisted records
however can be neither modified nor erased.

Ledger‑restricted communication
Every participant locally operates a ledger-access node that allows him to retrieve
records, submit new records and notably fully verify the ledger’s integrity locally. We use
the ledger as the exclusive communication medium among participants. As participants
only know one another by their identifiers, they exchange messages by adding and poll-
ing ledger records whenever they communicate.

Message notation
For every message m placed on the ledger, we indicate the sender and the recipient infor-
mation via the indexes α and β, i.e. the notation mαβ represents a message m, which has
been placed on the ledger by sender α, and is destined for recipient β. Some messages
are broadcast messages, destined for all participants. In this case, the notation shows no
recipient, β. The α and β variables are placeholders, throughout the paper we gradually
replace them with specific sender and recipient information.
Schiedermeier et al. Applied Network Science (2024) 9:51 Page 8 of 25

Throughout the protocol, we distinguish between four different message types:

• bα: Initial broadcast message, contains all referendum parameters. α = id(init)

• sαβ : A protected voting message (share), destined for a specific worker.
α = id(vi ), vi ∈ V , β = id(wj ), wj ∈ W
• rα: A worker’s broadcast message, contributing to the referendum outcome.
α = id(wj ), wj ∈ W
• cα: A worker’s broadcast message, contributing to the referendum validation.
α = id(wj ), wj ∈ W

The authenticity of message origins is ensured by the author’s signature. As the regis-
tration of voters’ public keys, described in section “Identities”, can be realized over the
ledger, it is fair to presume a trusted key exchange among participants, prior to the refer-
endum taking place.

Adversary model
We consider all voters and workers as potential adversaries. In section “Protocol outline”,
we outline the exact expected behavior of referendum participants. Our adversary model
covers that any Voter or Worker may deviate from this expected behavior at any time.

Malicious communication
In terms of message exchange, we consider:

• submission of syntactically incorrect messages, for instance, messages that lack man-
datory meta-information such as a cryptographic signature.
• submission of semantically incorrect messages. We notably consider the submission
of undefined values (e.g. out of valid numeric range) and incorrect result values (i.e.
values not corresponding to a delegated computation outcome). We consider insane
values may appear both, in the message payload and header information, such as the
sender field.
• submission of messages that by format or content do not correspond to the current
protocol phase.
• inactivity where interaction is requested, that is, deliberate non-communication.

Adversaries may deviate from the expected behavior individually or as a collusive group.

Assumptions
We assume that all openly verifiable information in bid(init), is considered correct by each
participant. If a user does not accept the parameters, then the user can decide not to par-
ticipate in the given instance of the referendum. The referendum is susceptible to having
low voter turnout, the proposed parameters of bid(init) are assumed unacceptable to the
general voting population. Moreover, since those parameters are public and immutable,
their validity can be debated in any public forum at any time after their publication.
Furthermore, we assume that it is infeasible for adversaries to fake RSA signatures or
break encrypted messages. Adversaries are not able to resolve the physical identity of
Schiedermeier et al. Applied Network Science (2024) 9:51 Page 9 of 25

other participants by inspecting network traffic. This is realistic if participants use TOR.
Finally, we assume that adversaries do not have the resources to break the ledger’s integ-
rity. Although our proposal does not explicitly require blockchain technology, one of the
characteristics of blockchains is strong integrity protection for persisted data (Gaetani
et al. 2015). It is considered practically infeasible for an adversary to overcome the
integrity protection, given the unattainable computation power such an attack would
require. We assume that the protocol either results in a provably correct result, or the
participants can detect anomalies. However, we do not expect the participants to correct
detected issues.

Objectives
We set the following four objectives for our proposed protocol:

1. Confidentiality: The referendum must be conducted in such a way that it is impos-

sible to infer the choices made by individual voters.
2. Transparency: The referendum must be transparent. This means that every partici-
pant must obtain a complete trace of the operations performed, by whom and when.
This notably covers the communication among participants throughout the referen-
dum.
3. Verifiability of the outcome: The referendum result must be verifiable to every par-
ticipant. That means he must be able to autonomously evaluate the correctness of the
result.
4. Immutability of proceedings: Proceedings are the logs of all actions performed by
participants from the moment of referendum initialization until the determination of
the result. Proceedings must arise directly upon execution of the described actions.
Once persisted, proceedings must be immutable. That is to say, it must be impossible
to secretly modify or erase stored proceedings.

Building blocks
Secret sharing scheme
Any secret sharing scheme supporting additive and multiplicative homomorphic opera-
tions will serve our protocol. We decided for the SEPIA (Many et al. 2012) specifica-
tion of Shamir’s Secret Sharing, due to its good documentation and ease of integration.
Shamir’s Secret Sharing is an instance of an SMPC scheme. As such, it allows to perform
computations without having to reveal the original inputs to individual parties.

t − n threshold systems
A t − n threshold system allows splitting a secret into n shares in such a way that any t
of them suffice to reconstruct the original secret. Subsets with less than t shares do not
reveal any information about the secret. If the shares are distributed to multiple parties,
we can thus create an effective mechanism against collusion. If shares of a secret are
distributed among n parties, t of them must cooperate, to reconstruct the secret. With
a greater value t, the protection against collusive reconstruction rises. However, in the
case of a desired reconstruction, increasing the offset between t and n leads to enhanced
robustness, as it makes the reconstruction robust against the unavailability of selected
Schiedermeier et al. Applied Network Science (2024) 9:51 Page 10 of 25

Fig. 1 Illustration of t − n threshold system characteristic and support for homomorphic operations in
Shamir’s Secret Sharing. The sum of two secrets (dashed circles) is computed by first concealing each secret
behind samples (turquoise and violet diamonds) of a random polynomial (grey). Adding sample points of the
same x-value (dashed upward arrows) produces a new set of result sample points (blue diamonds). The sum
of the original secrets (blue circle) is reconstructed by inferring the corresponding polynomial from the result
sample points

parties. The ratio of t to n can thus be adjusted, to meet a distributed protocol’s security
and robustness requirements.

Homomorphic operations
We make use of a secret sharing scheme that supports additive and multiplicative homo-
morphic operations. This means the secret sharing scheme provides a way to perform
operations on the shares of different secrets so that the fusion of the resulting shares
provides values that are equivalent to calculations done on the original secrets. Shamir’s
secret sharing supports both additive and multiplicative homomorphic operations.
However, the multiplicative component has side effects that limit its practical applica-
tion. Specifically, it increases the amount of shares required for a later reconstruction of
the result value. This problem was first mentioned in Benaloh (1987). The practical con-
sequences of our protocol are discussed in section “Security analysis”.
Figure 1 illustrates how Shamir’s Secret Sharing is an SMPC that showcases both traits,
the t − n threshold system, and support for homomorphic operations. Diamonds repre-
sent the t − n threshold system. For a given polynomial, as many samples as desired can
be constructed (n). However, only t samples are required to reconstruct the polynomial,
with t equal the polynomial’s degree +1. Computing the sum (blue circle) of two secrets
(dashed circles) by passing into polynomial representation, creating samples, summing
up samples, and reconstructing the result polynomial is a homomorphism. The sum-
ming up of samples can be handled by separate parties, rendering the process an SMPC
system.
Schiedermeier et al. Applied Network Science (2024) 9:51 Page 11 of 25

Fig. 2 Illustration of referendum participants, if a blockchain is used as ledger. Every referendum participant
replicates the ledger. Although the nodes constantly synchronize, referendum-related messages are
exchanged exclusively via ledger records. Therefore all clients hold a transparent copy of the proceedings. As
pictured above, the protocol does not bind specific roles to particular hardware

Distributed ledger technology

Our protocol relies on a precise log of communication that cannot be tampered with.
We therefore use distributed ledger technology as the communication channel among
participants.
We note that the proposed referendum protocol is independent of the specific imple-
mentation of the underlying distributed ledger. However, it is required that certain
essential properties are guaranteed by the distributed ledger. These properties notably
include immutability and integrity. For example, the distributed ledger may be imple-
mented by a blockchain, such as Bitcoin that relies on the Proof-of-Work mechanism for
consensus, or the ledger may be implemented by Ethereum, that uses the Proof-of-Stake
mechanism. Either of these two implementations can ensure immutability and integrity.
In addition to immutability and integrity, other practical attributes such as scalability
and cost would need to be considered as well for the selection of the underlying distrib-
uted ledger. A dedicated distributed ledger may be deployed for the proposed protocol
as well as long as the desired properties are guaranteed.
As shown in Fig. 2, we consider mobile clients as potential nodes of the distributed
ledger as well. These nodes would replicate the distributed ledger, however, in the case of
the ledger being a blockchain, they may not have the computing capabilities to partici-
pate in the “mining” or “validating” processes of the blockchain. For this reason, a suf-
ficient proportion of “mining” or “validating” nodes must be present as well as required
by the underlying distributed ledger to guarantee its overall security. It is the responsi-
bility of the initiator node (described in “Roles” section) to verify the general security
of the underlying distributed ledger before initiating a referendum. For well-established
blockchains, such as Bitcoin and Ethereum, this would generally not be an issue. The fact
whether these blockchains are operating securely or not is closely monitored and pub-
licly known. Moreover, voters may also individually verify the security of the underlying
distributed ledger before participating and potentially decide to abstain if the security
appears to be compromised.
Schiedermeier et al. Applied Network Science (2024) 9:51 Page 12 of 25

Asymmetric encryption
Although our protocol requires a complete listing of communication meta-data, there
are good reasons to delimit the content of messages to the recipient. We therefore use
asymmetric encryption to generate public-private key pairs which allow encryption and
decryption of directed messages. Furthermore, these keys are used for message signing
and authorship validation.

Anonymous credentials
Anonymous credentials allow a restriction of services to specific users, without a need
to verify identities at the moment of access. The key idea is to introduce an external
entity that hands out cryptographic tokens to eligible users (Chaum 1985). Those users
can later use their credentials to gain admission to an access-controlled service. Though
modern implementations (Lysyanskaya and Camenish 2001) respond to advanced
requirements such as the detection of double spending or a privacy-aware verification of
user-specific attributes, we only make use of the key feature, as it allows the anonymous
registration of eligible voters.
Technically, the external entity could issue the cryptographic tokens as hardware
devices and to eligible users only. The issuing can include a validation of identity or per-
missions. Such validation is optional and depends on contextual criticality and the goals
of the deploying organization. The issued device could serve as multi-factor authoriza-
tion (MFA) where also double-usage can be prevented. The actual service use remains
anonymous. The entity has to operate honestly due to its critical role. In real-world sys-
tems, this is ensured by the legal frame (e.g. data processing contracts, GDPR) and secu-
rity certifications with regular audits, where violations can cause serious consequences.
See also section “Enforcing honest behavior in real-world application” for typical meas-
ures of real-world application. Note that the external entity is a common and proven
practice. An example is certificate authorities (CA) issuing certificates for use in web
servers.

The protocol
The key idea behind our contribution is to use the ledger as a complete log of all commu-
nication between participants. This allows anyone, with access to the ledger, to autono-
mously compare the actual proceedings to the expected protocol. This verification can
occur locally. Participants therefore gain proof of correctness by themselves and not via
third parties. Furthermore, the anonymity of individual participants effectively prevents
communications via side channels. This is discussed in more detail in section “Security
analysis”.
Since our protocol is based on a secret sharing system, it seems at first counter-intui-
tive that we also make use of a public ledger. Secret sharing systems protect secret infor-
mation by dividing information into separate shares. The protection lies in the fact that
the secret information can only be reconstructed when shares are reunited, i.e. one party
gets hold of enough shares. Yet, we suggest to store all shares in a single place, namely, in
a public ledger. This seems pointless, for anyone can access the public ledger, and hence
combine all shares, immediately breaking all protection. Therefore, we do not store the
Schiedermeier et al. Applied Network Science (2024) 9:51 Page 13 of 25

shares in plain but apply additional asymmetric encryption. The interest of this encryp-
tion is to maintain a clear trace of all shares while ensuring share confidentiality to a spe-
cific party. In more general terms: Only the intended target entity (party) has access to a
specific set of sensitive information (shares). At the same time, the ledger as an exclusive
communication channel allows us to monitor the message meta-data of all participants.
Participants only know one another by their anonymous identities, i.e. the ledger is the
only means of communication. In reverse, this allows clients to autonomously verify the
absence of adversary collusion, targeted on the underlying t − n threshold system. Secret
communication via side channels is not an issue, as participants only know each other by
their anonymous identities.
In case a blockchain is used for the ledger, and mining sets on proof-of-work, we can
infer the following restrictions for participant hardware: The verification of the ledger’s
integrity by itself does not require clients to actively mine, we consider it reasonable to
enable mobile clients as blockchain replicating nodes. This is a valid assumption, given
two conditions:

1. The used blockchain serves exclusively for the current referendum. By restricting the
ledger content to this specific payload, the blockchain’s data volume is significantly
reduced. This is an essential decision, since popular public chains can easily exceed
the storage capacity of a mobile client and therefore render a replication infeasible.
2. As shown in Fig. 2, a portion of the participants rely on non-mobile hardware, bear-
ing the resources for active mining. This is likewise an important condition, as the
blockchain only provides integrity protection when an honest majority of miners can
not be computationally outperformed by adversaries (Gaetani et al. 2015).

Protocol overview
Our referendum protocol is based on a secure multi-party computation scheme, with
the restriction added that all inter-participant communication occurs exclusively over
a public ledger. That is to say, parties can only communicate by placing public mes-
sages in the ledger. Messages clearly state the recipient and are furthermore signed by
the author. This provides a transparent and clear trace of all arising inter-participant
communication.
The SMPC by itself allows a privacy-aware computation of the referendum outcome.
The SMPC’s homomorphism ensures that computing entities do not learn about sensi-
tive input data, since they work on an encrypted transformation of the data.
Proof of conformity to the designated protocol is supported by the ledger’s immutabil-
ity. Voters can analyze the communication meta-data of the executed SMPC. This way
every participant can assess whether the actual communication followed the protocol.
As all information required to perform this validation is stored in the ledger, referendum
participants can implement all compliance checks locally, without the need to trust third
parties. This allows the protocol to function in a trustless network environment.
Schiedermeier et al. Applied Network Science (2024) 9:51 Page 14 of 25

Fig. 3 Illustration of protocol phases. Downward arrows indicate the persistence of messages types into the
ledger, upward arrows indicate the lookup of messages (indicated by type). Time advances from left to right

Ultimately, after a successful validation of the proceedings, each voter holds the cer-
tainty that the outcome was determined correctly and no vote has been compromised.

Protocol outline
Figure 3 illustrates how individual roles chronologically submit and retrieve messages to
the ledger. For each action, it also indicates the corresponding protocol phase.

1. Initiation: In this step, the referendum conditions are written to the ledger: Referen-
dum context, voting options, identities of registered voters, etc...
2. Vote submission: Voters look up the referendum conditions and deposit their ballots,
secured by the secret sharing scheme and asymmetric encryption.
3. Intermediate result computation: Workers perform homomorphic operations on the
secured ballots, then write intermediate results and checksums back to the ledger.
4. Determination and validation of the outcome: Voters pick up the intermediate results
and checksums to determine the outcome and run verifications.

The next section provides more details regarding the individual phases.

Initiation
The goal of the first phase is to ensure all participants operate on identical referen-
dum parameters. The referendum initiator init communicates these parameters with
a single broadcast message:

1. init places an initial broadcast message bid(init) in the ledger. The content of this mes-
sage, b̃id(init) accumulates all static referendum parameters. It includes:

• The identities (public keys) of all eligible voters: V̄ = {id(vi ) | vi ∈ V }.

• A subset of identities that names the designated workers:
W̄ = {id(wj ) | wj ∈ W } as well as the individual share affiliation. The latter is
required by the voters in the next phase, so they know which share belongs to
which worker.
• The referendum context and semantics of numeric voting options. The two
options are always encoded by numeric values ∈ {−1, +1}. The initial broad-
Schiedermeier et al. Applied Network Science (2024) 9:51 Page 15 of 25

Fig. 4 Illustration of vote submission by a voter vi and intermediate result computation by a worker wj . Note
that all messages arising throughout these steps are persisted in the ledger

cast message’s payload b̃id(init) only defines the semantics for each voting
option value, for instance: Are cats cooler than dogs? Yes = +1, No = −1.
• A set of time-stamps that define the transitions between subsequent phases
Q = {q1−2 , q2−3 , q3−4 }. The fixed time stamps are required to ensure that at
the start of each phase, all required input data is present in the ledger. As q1−2
marks the transition to phase 2, this timestamp matches the moment of plac-
ing bid(init) in the ledger.

By communicating these conditions through a ledger, we ensure a unanimous partic-

ipant understanding of the upcoming referendum proceedings, i.e. the initial message
contains all the information required to outline subsequent participant communications.

Vote submission
In the second phase, voters cast their votes. Start and end of the Vote Submission phase
are defined through the referendum init message bid(init), as q1−2, respectively q2−3.
Throughout the Vote Submission phase, each voter vi ∈ V does the following:

1. vi retrieves the initiator’s broadcast message from the ledger.

2. vi secretly chooses his personally preferred voting option and determines the cor-
responding numeric value ψi ∈ {−1, +1}. The mapping is specified in bid(init), e.g. if
vi were to believe that cats are indeed cooler than dogs, he would proceed using the
numeric value corresponding to Yes: “+1”.
3. Based on ψi , voter vi then generates a set of n shares {σi1 , ..., σin }. He does so follow-
ing a t − n threshold secret sharing scheme. The exact parameters for this step are
provided in bid(init).
Schiedermeier et al. Applied Network Science (2024) 9:51 Page 16 of 25

4. Each generated share is intended for a specific worker wj . Voter vi encrypts each gen-
erated share σij with the corresponding worker wj ’s public key w̃j . The exact mapping
of shares to workers is once more described in bid(init). The target worker’s id is also
the public key to use for encryption.
5. vi packs all n cypher-shares s̃ij = pubj (σij ), j ∈ {1, ..., n} individually into n messages
sij and initiates their persistence in the ledger. The horizontal arrows in Fig. 4 illus-
trate this step.

Voters can submit votes until a timestamp q2−3. During the valid time window, voters
can submit multiple votes. Only the last vote is taken into account and messages sij sub-
mitted after timestamp q2−3 are considered non-compliant with the protocol and are
ignored.
Note that vote changes during the valid time windows are explicitly wanted as a prac-
tical feature to allow voters to change their minds and demonstrate protocol flexibility.
The exact mechanism for “Double Voting” is described in detail in section “Security anal-
ysis”. It can be easily changed to traditional voting by considering only the first vote and
ignoring subsequent ones even within the valid time window. Note also that the times-
tamp is computed using a block number or storage id on the ledger as timestamps in
distributed systems cannot guaranteed to be reliable due to consensus protocols.

Intermediate result computation

In the third phase, each worker wj performs the following actions to contribute interme-
diate result values for the referendum outcome and checksum computations:

1. wj retrieves the set of k encrypted share-messages destined to him: {s1j , ..., skj }.
2. wj retrieves the payload of received messages and this way holds k shares s̃1j , ..., s̃kj ,
each encrypted with his public key w̃j.
3. wj decrypts every single share using his private key ŵj and obtains a set of k unen-
crypted shares: {σ1j , ..., σkj }. These are the k shares, the voters V = {v1 , ..., vk } securely
communicated to him via ledger.
4. Based on {σ1j , ..., σkj }, wj participates in the homomorphic calculation of intermediate
result shares:

• He contributes to obtaining the sum of all votes, with an intermediate result share
r̃j.
• He contributes to obtaining the sum of all squared votes, with an intermediate
result share c̃j.

The sum of squared votes will later serve to detect illegal inputs. Note that inter-
mediate result shares r̃j , j ∈ W̄ , respectively c̃j , j ∈ W̄ must be combined to obtain
the actual results.

5. wj converts r̃j and c̃j to broadcast messages rj , cj and persists those in the ledger.
Schiedermeier et al. Applied Network Science (2024) 9:51 Page 17 of 25

The execution of the above steps by a worker wj , leading to the persistence of rj and cj ,
is illustrated in Fig. 4 by a downward arrow. q3−4 marks the moment by which workers
must have their intermediate results persisted.

Determination and validation of the outcome

In the final phase, voters individually reconstruct the referendum outcome and evaluate
the proceedings for conformity with the protocol. To do so, every voter vi performs the
following actions:

1. vi picks up all result- and checksum messages, deposited in the ledger by the workers:
{rj | j ∈ W̄ } and {cj | j ∈ W̄ }.
2. vi extracts the message payloads. This produces two separate sets. One containing
the election result shares and one for the election checksum shares: {r̃j | j ∈ W̄ } and
{c̃j | j ∈ W̄ }
3. vi uses each set to reconstruct the corresponding secret, i.e. vi combines the shares of
each set, to remove the protection of the threshold system. That is, vi combines the
intermediate result shares {r̃j | j ∈ W̄ }, respectively {c̃j | j ∈ W̄ }. These sets of shares
express the homomorphic equivalent of:

• The referendum outcome, r = i∈V ψi

• A referendum checksum, c = i∈V ψi2

Consequently, by combining the corresponding shares, vi obtains r and c. The check-

sum c allows the detection of illegal votes. As all votes are expected to be either of ±1,
it must hold that c = k . If that is not given, the participant directly knows that at least
one illegal input value was submitted. Still, it is possible to generate a valid checksum
with cleverly arranged illegal input values. We discuss this threat in section “Security
analysis”.

Analysis of objective fulfillment

In this section, we evaluate how well the individual objectives are met by the suggested
protocol.

Immutability of the referendum proceedings

Proceedings are immutable whenever they are preserved in a way that renders retroac-
tive tampering infeasible. Given the presented protocol, proceedings can be expressed
by a complete log of participant-exchanged messages. As those messages are exchanged
publicly through the ledger, the ledger content itself serves as a complete transcript of
referendum proceedings. We ensure the ledger’s exclusive status as a targeted communi-
cation medium by concealing the physical identity of participants behind pseudonyms.
Since the ledger ensures the immutability of persisted records, we obtain an immutable
log of the referendum proceedings.
Schiedermeier et al. Applied Network Science (2024) 9:51 Page 18 of 25

Fig. 5 Illustration of t − n threshold system robustness. If the amount t of samples needed to reconstruct
(t = 4 for a third-degree polynomial) is lower than the total number n of total shares (n = 10, all diamonds),
the system gains in redundancy, i.e. the secret (green circle) can be reconstructed even if shares are missing
(grey diamond) or a manipulated value has been provided (red diamond)

Confidentiality of votes
A ballot is secret if no entity other than the voter himself knows the submitted value.
Our protocol applies a strong protection of votes, by first splitting every vote according
to a secret sharing scheme and then encrypting each resulting share asymmetrically. As
a reminder: the shares of all votes reside together in the ledger. While the ledger content
is public, the shares cannot be readily combined, because each share is encrypted with a
specific worker key. Unless an adversary manages to overcome the asymmetric encryp-
tion for at least t shares of the same vote (allowing subsequent vote reconstruction), con-
fidentiality of the vote remains ensured. Though asymmetric encryption mechanisms are
in theory breakable, such attack is assumed computationally infeasible in practice. That
is to say with current or near-future hardware it is extremely unlikely for an adversary to
reconstruct even a single secret share, without the required key material. Furthermore,
by analyzing the ledger, voters can reconstruct the message flow among participants and
exclude even the possibility that workers colluded to reunite shares. As workers only
know one another by their pseudo-identifiers, they can not secretly establish a commu-
nication side channel for collusion.

Referendum validation
To verify the correctness of the referendum outcome, each participant must be able to
validate that two conditions are met:

1. The inputs that the outcome evaluation occurred on, are valid. This means all votes
must be valid numeric options. As we will see in section “Security analysis”, this con-
dition restricts the range of valid parameters for the t − n threshold system.
2. The evaluation itself was conducted correctly. This means that the intermediate
results computed by the workers must be correct for the provided inputs.
Schiedermeier et al. Applied Network Science (2024) 9:51 Page 19 of 25

The second condition can be ensured by redundancy. The polynomial-based secret shar-
ing scheme allows to detect and ignore outliers. Figure 5 illustrates the principle on an
example. Let’s assume 10 sampling points are provided to reconstruct a 3rd-degree pol-
ynomial, e.g. f (x) = 13 x3 − 12 x2 + 2. Ideally, any four sampling points suffice to recon-
struct the polynomial. However, additional sampling points provide robustness against
incorrect, or in the worst case, intentionally manipulated sampling points. The greater
the offset between t and n, the more robust the protection against incoherent samples.
In turn, the identification of outliers allows the exclusion of dishonest parties. Figure 5
illustrates this principle, where we assume all but one sampling point is correct. If all
samples are correct, any subset of t sampling points will be reconstructed to the same
polynomial. In return, if some subsets of size t produce a deviating result, these subsets
contain an incorrect sampling point, suggesting one or several dishonest workers.

Transparency
A referendum is considered transparent if all participants possess a correct and complete
log of all actions performed throughout the entire referendum. In our model, all actions
eventually result in communication. As we force all communication to run through the
ledger, the trace of deposited messages provides a transparent and verifiable log of actions.

Scalability
In addition to the four initial objectives discussed above, we also discuss the scalability aspect
of the proposed referendum protocol in this section. Elections and referendums need to take
place for democratic decision-making in a variety of institutions and constituencies. These
entities could comprise of hundreds, thousands, or even millions of eligible voters.
Scaling the proposed protocol to a few hundred or even a few thousand voters appears
feasible. Let’s take the init phase of the protocol as an example. It requires placing k iden-
tities or public keys of the eligible voters on the ledger. The German Federal Office for
Information Security (Deutschland Digital Sicher BSI) recommends using a key size of
256 Bits for encryption with an Elliptic Curve based cryptosystem (ECC) (xxx 2024).
The size of the set of all keys for 10 thousand eligible voters would be 10,000 × 256 Bits
= 2,560,000 Bits = 320 Kilobytes. The feasibility of storing this amount of informa-
tion on a distributed ledger would depend on its specific implementation. For example,
recording 320 KB of information on a blockchain such as Bitcoin or Ethereum could be
expensive, however, it would be technically feasible.
Now let’s take the example of the country of Germany, which may be considered a
medium to large-sized country in terms of population given its ranking of 19 in the list
of over 200 countries in the year 2023 (United-Nations 2024). The population of Ger-
many that is eligible to vote is comprised of 60.4 million people according to the German
election demographics for the year 2021 (Bateson and Thurau 2021). Given the above
statistics and considering a single ECC public key of 256 Bits for each voter, we can deter-
mine the size of the set of keys of the entire eligible voting population. The size of the set
would be 60,400,000 × 256 Bits = 15,462,400,000 Bits = 1.80006 Gigabytes. Consider-
ing the storage capacities of modern computing devices, a couple of Gigabytes is a fairly
Schiedermeier et al. Applied Network Science (2024) 9:51 Page 20 of 25

manageable storage requirement. However, recording such a large amount of information

on a blockchain such as Bitcoin or Ethereum can be expensive or even prohibitive.
Some alternative solutions could be used to resolve this limitation of scalability. One
example would be storing the complete set of keys on a decentralized storage platform
such as IPFS instead and only the hash of the set on the blockchain. Other solutions
could involve employing better-scaling blockchain technology, such as Layer 2 scaling
solutions. Moreover, we note that elections rarely take place on the scale of an entire
country. Rather, elections generally take place in smaller constituencies and their indi-
vidual results are eventually aggregated into a country-wide result.

Security analysis
In this section, we evaluate whether adversary strategies are detrimental to the suggested
protocol:

• Intentional inactivity: Any participant can violate the protocol by intentional inactiv-
ity where interaction is expected. That is, eligible voters can choose not to distribute
shares or only send them to a subset of workers. Furthermore, a worker can ignore
the expected submission of intermediate result shares. Although the payload of vote
messages is encrypted, all participants can inspect the ledger content and detect if
eligible voters are inactive or do not communicate with all designated workers. The
default strategy is to systematically ignore all vote shares of voters that do not comply
with the expected behavior. This way the disadvantage of inactivity lies entirely with
the adversary. Likewise, intentionally inactive workers cannot be prevented, however,
the nature of the t − n threshold system provides robustness against that scenario.
Precisely, for reconstructing the voting outcome only t samples are required, that is
the protocol is robust until up to n − t inactive workers. Concerning the referendum
outcome’s checksum, the redundancy is weaker. The reason is that the checksum
computation relies on an internal polynomial multiplication (see section “Determi-
nation and validation of the outcome”), the effect of which is a doubled degree of the
checksum result polynomial. Since reconstruction of a twice-as-high-degree poly-
nomial requires approximately twice as many sampling points, the protocol is less
robust against inactive workers, concerning the checksum. The exact tolerance for
inactive workers is at n − t 2 missing checksum samples. Benaloh (1987)
• Syntactically incorrect messages: Participants can violate the protocol by sending
syntactically incorrect messages. Syntactic errors can be easily detected with syntax
schemes, e.g. if messages are exchanged in JSON format, their syntax can be vali-
dated with a corresponding JSON schema instance, defining valid the message meta-
structure, and property constraints (Pezoa et al. 2016). The default strategy is to
ignore any syntactically incorrect message. This way, messages that are in no relation
to the protocol also have no impact. If ignoring the message results in an interpreted
participant inactivity, the above inactivity analysis is applicable here, too.
• Impersonation: Participants may try to illegally send messages in the name of another
participant. Impersonated messages are easy to detect since their signature does not
match the expected author. Messages with invalid signatures are systematically ignored.
Schiedermeier et al. Applied Network Science (2024) 9:51 Page 21 of 25

• Invalid voting options: Voters are expected to vote for either ±1. However, as their
shares are submitted in encrypted form, they might try to boost their influence
with higher (or lower) numeric values. For colluding participants, it is possible to
arrange invalid votes in a way that the input validation checksum is still fulfilled.1
However, this attack is not in the interest of the adversaries, since it can only dimin-
ish the overall influence of the outcome. If parties collusively submit illegal inputs
that pass the validation, the impact of those inputs is lower than the impact they
would have achieved with legal input values. This is a consequence of the Cauchy-
n n p 1/p (n q 1/q ,
Hölder inequality: k=1 | xk yk |≤ ( k=1 | xk | ) k=1 | yk | ) with
2
n ∈ N, {x1 , ..., xn }, {y1 , ..., yn } ∈ R, p, q ∈ [1, ∞). Furthermore, it is not a severe threat
to the protocol as it requires collusion (which, as previously argued, is difficult to
establish, given the concealed identities of protocol participants).
• Incorrect intermediate results: Workers might submit incorrect intermediate results
on purpose. In the case of an extreme threshold system configuration with t = n,
the existence of incorrect result shares is neither detectable nor correctable. How-
ever, with rising share redundancy, an honest majority of workers can push incor-
rect shares into a detectable outlier position (see section “Analysis of objective fulfill-
ment”). However, massively colluding adversaries could also push an honest minority
into an outlier position. Another inconvenience for worker adversaries is that they
can not predict the effects of their manipulation. Given the SMPC, an altered value
can influence the result in either direction. As discussed previously, we furthermore
hinder collusive attacks by concealing the participants’ natural identities.
• Double voting: Double voting is an explicit protocol feature, i.e. voters are allowed to
cast multiple votes. However, this does not increase voting power for individuals. If
multiple votes are cast by the same voter, the workers only consider the shares, cor-
responding to the most recent vote. That is, voters can repeat the generation, encryp-
tion and distribution of vote-corresponding shares. The double voting is thereupon
detectable (each share message sα,β contains an unencrypted, signed header). If
workers are confronted with multiple shares from the same voter, they interpret the
situation as “The voter changed their mind” and therefore only consume the share
with the most recent timestamp, i.e. the outcome of the SMPC only reflects the latest
vote. Throughout the Vote Submission phase q1−2 (see 5.2.2), a voter can change their
mind as many times as they want.
• De-anonymization: Participants might be interested in identifying the physical entity
that operates behind a participant pseudonym. This would enable outside-ledger

1
√
2
√
Example: Imagine two votes ψ1 = 1.5, ψ2 = 2 0.5 are submitted, their checksum is ψ12 + ψ22 = 2, while the resulting
vote impact is ψ1 + ψ2 � = 2.
2
  √
If we chose p = 2, q = 2, yk = 1, the inequality
n is reduced to nk=1 | xk |≤ 2 nk=1 | xk |2 2 n .However, the client
side checksum verification ensures that k=1 xk2 = n, which further reduces the inequality to nk=1 | xk | ≤ n. This
maximum value is obtained with valid inputs xk ∈ {−1, +1}, rendering a collusive construction of illegal inputs point-
less, since such inputs cannot surpass the impact of valid values, on the referendum.
Schiedermeier et al. Applied Network Science (2024) 9:51 Page 22 of 25

undetected communication. As all network traffic runs over TOR connections, de-
anonymization is not feasible.
• Communication side channel creation: Adversaries may try to secretly establish an
alternate platform for direct communication, parallel to the ledger. Though secret
inter-participant communication is a severe threat to the protocol’s transparency and
opens a gate for further attacks, it is not trivial to establish. A resilient system can
counter this by setting the threshold value reasonably high. Specifically, this means
that the probability of random workers falling into societal cliques must be mini-
mized. If adversaries do not already know their physical identities, they have to com-
municate publicly, as they do not know who to address. Adversaries publicly declar-
ing their will to collude can be easily detected.
• Voter exclusion: In Section “Related work”, we criticized the usage of an anonymous
credential server, because such a server can, if dishonest, omit correctly submitted
ballots and thereby exclude votes at will. However, in our case, anonymous creden-
tials are only used for voter registration, not for the voting procedure itself. In Diaz
et al. (2009), a voter cannot provably expose a dishonest petition server. If the server
never hands out a confirmation of receipt, a voter cannot prove their previous inter-
action with the server. In the worst-case scenario blaming a dishonest server may
even jeopardize the confidentiality of the vote: If a malicious server reports a unani-
mous vote outcome, blaming the server is equivalent to disclosing the own vote not
being that option. The described risk is eliminated in our case. The voter registration
itself can be logged in the ledger, i.e. the public init message bid(init) can be inspected
preemptively. If a legit voter were intentionally or accidentally excluded, they can
point out the mistake, before the voting phase, that is without any risk. Consequently,
in our protocol, a legitimate voter can prove their exclusion by a malicious server,
without risks.

Enforcing honest behavior in real‑world application

In classical analogue voting, a person receives a ballot paper after physical authentica-
tion of the identity card by specially authorized voting staff. This records that a specific
person has received a ballot paper and submitted a vote but keeps this information con-
fidential. The ballot paper and the vote itself are anonymous. The correct behavior of
both the voting staff and voters is regulated by a legal framework and supervised by the
voting staff.
The presented approach of this paper follows the same principle. An external entity
issues the tokens to voters for vote submission and records which voter has received a
token (but not which one) and keeps this information confidential. The token and vote
submission remains fully anonymous. Compared to classical analogue voting, even the
token issuing of our proposal can be fully anonymous without any form of identity vali-
dation. It is easy to imagine that the external entity could be an independent trusted
organization that uses a secured channel (e.g. encrypted emails) to provide unique IDs
for authorizing token issuing.
Enforcing honest behavior of the external entity (but also the technical infrastructure
provider) of our approach in real-world application would still rely on laws and legal
agreements as cornerstones. The honest behavior of voters in classical analogue voting
Schiedermeier et al. Applied Network Science (2024) 9:51 Page 23 of 25

is enforced by physical presence and supervision, whereas the technical system ensures
correct behavior of the voting procedure. To this end, real-world deployments are hard-
ened by various technical, organizational and operational measures to ensure honest
behavior. The following list outlines the most important measures.

• Legal framework: Legal contracts specify data processing activities and potential fines
for the commercial sector. Also, the data processing has to follow the legal frame-
work of the countries of the residing servers. In Europe, the GDPR defines serious
data protection requirements, where violations cause significant consequences.
Examples are Meta, which was fined 1.2 billion Euros in May 2023, and Whatsapp
which was fined 225 million Euros in 2021 for data processing-related violations.
• Certified data security: Organizations typically prove their level of secure data pro-
cessing with security certifications that imply also regular audits by independent
third parties. For example, Amazon Web Services (AWS) owns a multitude of certi-
fications such as ISO 27001, ISO 9001, ISO 22301, ISO 27017, ISO 27701, ISO 27019
as well as SOC 1 / 2 / 3. or PCI DSS and has their infrastructure certified according
the Cloud Computing Compliance Controls Catalogue (C5). A full list of certifica-
tions and engagements can be found online.3.
• Architectural design patterns: Software development should follow development
paradigms such as security-by-design, privacy-by-design, privacy-by-default or shift-
left-security. Also, data processing should be minimized and server locations should
be used according to the legal framework.
• Cloud security services: Modern cloud infrastructure providers offer powerful secu-
rity services. For example, the aforementioned AWS offers DDoS prevention, intru-
sion detection, security scanners (e.g. operation systems, containers, infrastructure
configurations), monitoring and logging, root cause analysis support and compliance
validation scanners (e.g. regarding controls of CIS or NIST 800-53 rev 5).
• Monitoring and logging: All relevant actions are monitored and administrators are
informed about anonymous behavior. Extensive logging is taking place and also
stored on a secured dedicated system for possible audits by external parties and thus
only accessible by a few trusted persons.
• Specific measures: Many specific measures are applied to harden real-world deploy-
ments. This includes notably data encryption in transit and at rest, following official
recommendations (e.g. BSI TR-2102 for cryptographic algorithms and key lengths),
network separation, access control/permissions or firewalls. Dedicated security
teams should enforce such measures and be in contact with relevant actors (engi-
neering teams, management, data protection officer etc.)
• Processes: Several processes such as vulnerability management, incident manage-
ment and risk management are crucial for data security. Thus, they are at the core of
information security management systems (ISMS) and related certifications (e.g. ISO
27001). Also, some processes become legal requirements in Europe through regula-
tions such as NIS-2 or the Cyber Resilience Act.

3
https://​aws.​amazon.​com/​de/​compl​iance/​progr​ams/.
Schiedermeier et al. Applied Network Science (2024) 9:51 Page 24 of 25

Conclusion
Objectives fulfillment
Our work demonstrates how the challenges of electronic referendums can be answered
with a creative combination of existing approaches. By bringing together the potential
of ledger technology and secure multiparty computation, we constructed a highly trans-
parent referendum protocol that allows participants to autonomously verify proceed-
ings and referendum outcome. Traditional t − n threshold-based systems gain security
exclusively by selection of parameters that render successful collusive attacks unlikely.
To the best of our knowledge, there is no other system that further enforces security, by
considering proofs that inspect communication meta-data, protected by ledger technol-
ogy. This concept generates trust on the client side, because except for the anonymous
credential issuer the need for trusted third parties is eliminated. We provided a realistic
adversary model and analyzed how our protocol withstands corresponding attacks.

Future work
In future research, we would like to further investigate a meaningful selection of ref-
erendum parameters. We could also imagine experimenting with machine learning
approaches, to reach an optimal trade-off between security and scaling. Machine learn-
ing approaches could also be used to identify outliers and filter outliers in provided sam-
pling points. Also, we would like to explore other input validation methods that have
less impact on the voter-worker ratio. Another open question is how to best select the
worker subset. Given the focus of our current work on the security aspects of the pro-
tocol, we are interested in performance evaluations of a practical implementation of the
protocol, particularly in a mobile scenario.

Author contributions
Maximilian Schiedermeier is the primary contributor. Omar Hasan and Tobias Mayer contributed to all aspects. Lionel
Brunie and Harald Kosch contributed to the conceptualization and analysis.

Funding
Open Access funding enabled and organized by Projekt DEAL. We acknowledge support by the Open Access Publication
Fund of University Library Passau.
Availability of data and materials
Not applicable.

Declarations
Informed consent
Not applicable.

Competing Interests
The authors declare no Conflict of interest.

Received: 2 October 2023 Accepted: 17 July 2024

References
Ayed AB (2017) A conceptual secure blockchain-based electronic voting system. Int J Netw Secur Appl 9.3 (2017):1-9
Ballotpedia (2022) Voter turnout in United States elections. https://​ballo​tpedia.​org/​Voter_​turno​ut_​in_​United_​States_​
elect​ions
Bateson I, Thurau J (2021) German election demographics. https://​www.​dw.​com/​en/​german-​elect​ion-​demog​raphi​cs-​
facts-​and-​figur​es/a-​59143​207
Schiedermeier et al. Applied Network Science (2024) 9:51 Page 25 of 25

Benaloh JC (1987) Secret sharing homomorphisms: keeping shares of a secret secret (Extended Abstract). Lecture Notes
in Computer Science (including subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformat-
ics), vol 263 LNCS, pp 251–260
BSI: BSI TR-02102 cryptographic mechanisms. https://​www.​bsi.​bund.​de/​EN/​Themen/​Unter​nehmen-​und-​Organ​isati​onen/​
Stand​ards-​und-​Zerti​fizie​rung/​Techn​ische-​Richt​linien/​TR-​nach-​Thema-​sorti​ert/​tr021​02/​tr021​02_​node.​html (2024)
Bureau USC (2019) US elections voter turnout statistics. https://​www.​census.​gov/​libra​r y/​stori​es/​2019/​04/​behind-​2018-​
united-​states-​midte​rm-​elect​ion-​turno​ut.​html
Bursuc S, Dragan C-c, Kremer S, Bursuc S, Dragan C-c, Kremer S, Bursuc S, Est IN-g, Kremer S, Est IN-g (2019) HAL Id : hal-
02099434 Private votes on untrusted platforms: models , attacks and provable scheme
Chaum D (1985) Security without identification: transaction systems to make big brother obsolete 28(70)
Clarkson MR, Myers AC, Clarkson MR, Myers AC (2008) Civitas: toward a secure voting system civitas: toward a secure
voting system, vol 7875
Cortier V, Gaudry P, Glondu S, Cortier V, Gaudry P, Glondu S (2019) Belenios: a simple private and verifiable electronic vot-
ing system To cite this version: HAL Id : hal-02066930
Darame M, Roger P (2022) French legislative elections: Abstention remains the largest ’party’ in France. https://​www.​
lemon​de.​fr/​en/​polit​ics/​artic​le/​2022/​06/​21/​french-​legis​lative-​elect​ions-​abste​ntion-​remai​ns-​the-​first-​party-​in-​france_​
59875​01_5.​html
Diaz C, Kosta E, Dekeyser H, Kohlweiss M, Nigusse G (2009) Privacy preserving electronic petitions (2008), pp 203–219
Gaetani E, Aniello L, Baldoni R, Lombardi F, Margheri A, Sassone V (2015) Blockchain-based database to ensure data
integrity in cloud computing environments
Hao F, Ryan PY, Zieliński P (2010) Anonymous voting by two-round public discussion. IET Inf Secur 4(2):62–67
Lee K, James JI, Kim HJ, James JI (2016) Electronic voting service using block-chain. J Digit Forens Secur Law 11(2):8
Li Y, Susilo W, Yang G, Yu Y, Liu D, Guizani M (2019) A blockchain-based self-tallying voting scheme in decentralized IoT.
arXiv:​arXiv:​1902.​03710​v1
Lysyanskaya A, Camenish J (2001) An efficient system for non-transferable anonymous credentials with optional ano-
nymity revocation. In: EUROCRYPT 2001
Many D, Burkhart M, Dimitropoulos X (2012) Fast private set operations with SEPIA. Technical report, Department of
Computer Science, ETH Zurich
Mestre A (2022) French legislative elections: Sharp decline in voter turnout highlights a worrying trend. https://​www.​
lemon​de.​fr/​en/​polit​ics/​artic​le/​2022/​06/​19/​french-​legis​lative-​elect​ions-​sharp-​decli​ne-​in-​voter-​turno​ut-​highl​ights-a-​
worry​ing-​trend_​59872​91_5.​html
Onur C, Yurdakul A (2022) Electanon: A blockchain-based, anonymous, robust and scalable ranked-choice voting proto-
col. arXiv preprint arXiv:​2204.​00057
Pezoa F, Reutter JL, Suarez F, Ugarte M, Vrgoč D (2016) Foundations of JSON schema. In: Proceedings of the 25th interna-
tional conference on world wide web, pp 263–273
Riemann R, Grumbach S (2015) Distributed protocols at the rescue for trustworthy online voting. arXiv:​1705.​04480​v1
Schiedermeier M, Hasan O, Brunie L, Mayer T, Kosch H (2019) A transparent referendum protocol with immutable pro-
ceedings and verifiable outcome for trustless networks. In: International conference on complex networks and their
applications. Springer, pp 647–658
Schiedermeier M, Hasan O, Mayer T, Brunie L, Kosch H (2019) A transparent referendum protocol with immutable pro-
ceedings and verifiable outcome for trustless networks. arXiv preprint arXiv:​1909.​06462
Springall D, Finkenauer T, Durumeric Z, Kitcat J, Hursti H, Macalpine M, Halderman JA (2014) Security analysis of the
Estonian internet voting system (May), pp 703–715
Song J-G, Moon S-J, Jang J-W (2021) A scalable implementation of anonymous voting over Ethereum blockchain. Sen-
sors 21(12):3958
United-Nations (2024) United nations data portal population division. https://​popul​ation.​un.​org
Uribe F, Hernandez I, Jung L, Amenewolde P (2022) Anonymous voting in dao’s
Zaghloul E, Li T, Ren J (2021) d-BAME: distributed blockchain-based anonymous mobile electronic voting. IEEE Internet
Things J 8(22):16585–16597
Zyskind G (2015) Enigma : Decentralized Computation Platform with Guaranteed Privacy, pp 1–14 arXiv:​arXiv:​1506.​03471​
v1
Zyskind G, Nathan O, Pentland AS (2015) Decentralizing privacy: using blockchain to protect personal data. In: Proceed-
ings—2015 IEEE security and privacy workshops, SPW 2015, pp. 180–184

Publisher’s Note
Springer Nature remains neutral with regard to jurisdictional claims in published maps and institutional affiliations.