Conference PaperPDF Available

Provotum: A Blockchain-based and End-to-end Verifiable Remote Electronic Voting System

Conference Paper

Provotum: A Blockchain-based and End-to-end Verifiable Remote Electronic Voting System

Abstract and Figures

While the existence of Public Bulletin Boards (PBB) is often formulated as an assumption in related work on Remote Electronic Voting (REV) systems, this work here on Provotum focuses on the practical design and architecture of such a PBB, including its distributed execution. Further, Provotum leverages a public permissioned Blockchain (BC) as a PBB, where only authorized entities can sign blocks, while the general public can verify all BC data. Therefore, Provotum defines a new and fully decentralized BC-based REV system, which deploys a permissioned BC as a PBB and allows for the explicit distribution of trust across different permissioned BC nodes. Provotum is operated in a fully distributed fashion by using Smart Contracts (SC), Distributed Key Generation (DKG), Homomorphic Encryption (HE), and Cooperative Decryption (CD), as well as employing client-side encryption, which enables ballot secrecy, while the BC forms an audit trail, enabling public and End-to-end Verifiability (E2E-V).
Content may be subject to copyright.
Provotum: A Blockchain-based and End-to-end
Verifiable Remote Electronic Voting System
Christian Killer, Bruno Rodrigues, Eder John Scheid,
Muriel Franco, Moritz Eck, Nik Zaugg, Alex Scheitlin, Burkhard Stiller
Communication Systems Group CSG, Department of Informatics IfI, University of Zurich UZH
Binzm¨
uhlestrasse 14, CH-8050 Z¨
urich, Switzerland
[killer|rodrigues|scheid|franco|stiller]@ifi.uzh.ch, [moritz.eck|nik.zaugg|alex.scheitlin]@uzh.ch
Abstract—While the existence of Public Bulletin Boards (PBB)
is often formulated as an assumption in related work on Remote
Electronic Voting (REV) systems, this work here on Provotum
focuses on the practical design and architecture of such a PBB,
including its distributed execution. Further, Provotum leverages
a public permissioned Blockchain (BC) as a PBB, where only
authorized entities can sign blocks, while the general public can
verify all BC data.
Therefore, Provotum defines a new and fully decentralized
BC-based REV system, which deploys a permissioned BC as
a PBB and allows for the explicit distribution of trust across
different permissioned BC nodes. Provotum is operated in a fully
distributed fashion by using Smart Contracts (SC), Distributed
Key Generation (DKG), Homomorphic Encryption (HE), and
Cooperative Decryption (CD), as well as employing client-side
encryption, which enables ballot secrecy, while the BC forms an
audit trail, enabling public and End-to-end Verifiability (E2E-V).
I. INTRODUCTION
The digitization of governmental processes also includes
a modernization of voting processes to diminish or replace
traditional paper-based voting through Electronic Voting (EV)
systems [33]. In general, the advantages of EV over paper-
based systems are widely recognized [23], providing increased
efficiency and transparency for the electoral process. However,
there are plenty of non-technical aspects of each country’s
culture that impact how EV systems are implemented. Hence,
EV systems can be broadly classified as those (i) including
vote casting in a Remote EV (REV) setting, such as the ones
implemented in countries like Switzerland and Estonia, or (ii)
requiring in-person voting, for instance by visiting a ballot
booth, as in EV systems in Brazil and India.
While EV and REV systems expose trade-offs between
election verifiability and privacy, REV systems involve higher
complexity, since they run outside a controlled environment,
i.e., outside of a prepared voting booth where eligible voters
cast their votes. In general, REV introduces risks concerning
voter coercion, forced abstention, technical risks regarding
threats to the personal voting device (e.g., browser vulner-
abilities), and the security of the network link to the REV
environment. Increasing verifiability means introducing trans-
parency into the electoral process, which means that there is a
higher risk to voter’s privacy. In this sense, both EV and REV
systems must seek to strike a balance between these properties
that is accepted by each country’s culture.
Voting systems always require verifiable evidence of a
correctly executed voting process. An essential building block
of any EV system is the Public Bulletin Board (PBB). PBBs
need to serve as a publicly shared, append-only audit trail,
offering a consistent view for verifiers [30]. Generally, EV
schemes assume the existence of a secure PBB, often treating
this assumption too casually for real-world scenarios, and
hence practical deployment remains a challenge [25]. EV
systems need to minimize the requirement for trust, too, i.e.,
accomplishing weaker trust assumptions. Arguably, trust in
authorities may always remain necessary, e.g., for identity
management (authenticating voters, checking eligibility) [10].
However, the execution of the voting protocol itself has to
be fully transparent and verifiable. Remaining trust has be
distributed among a set of trustees in EV systems, e.g., by
distributing private key shares among multiple authorities [12].
The emergence of public Blockchains (BC) highlighted
novel ways to distribute trust across nodes [5]. Instead of rely-
ing on existing public permissionless BCs, the deployment of
a public permissioned BC is an efficient way to distribute trust
across permissioned nodes in a network [30]. Only authorities
are authorized to sign blocks, while anyone can verify BC data
and read from the BC, enabling public verifiability. Further, a
BC-based architecture persists a global state in an immutable
way, thus, allowing the PBB to achieve a fully distributed
voting protocol with End-to-end Verifiability (E2E-V).
Distribution of trust is straightforward in paper-based voting
systems, e.g., the tallying of paper ballots can be easily split
up across different locations. On the contrary, EV deployments
generally lead to centralized architectures within a “single
location”, and thus, introduce a Single Point-of-Failure (SPoF),
which is prone to attacks (e.g., Distributed Denial-of-Service).
Most EV systems based on Homomorphic Encryption (HE)
distribute trust by using Threshold Cryptography to distribute
private key shares among trustees. However, the distributed
key generation is not done transparently, but among trusted
servers, and without a publicly readable PBB [49].
Provotum’s key goal is to distribute trust via the voting
protocol and allow public verifiability through the deployment
of a PBB as a public permissioned BC. Preliminary work
on Provotum used a public permissioned Proof-of-Authority
(PoA) Ethereum BC as a PBB [35]. Although this showcases
end-to-end voting, the initial version relied on a centralized
server for encryption and proof verification, defeating the
purpose of using a BC as a PBB. This deficit had been tackled
with a new approach to Provotum here, still based on a public
permissioned PoA of Ethereum, but the new addition is the
voting protocol, which now offers fully distributed E2E-V.
Provotum offers (i) Distributed Key Generation (DKG),
where keys for the election are generated in a distributed
fashion [12], allowing for the distribution of trust and mit-
igating the risk of a SPoF. Furthermore, (ii) Cooperative
Decryption (CD) is deployed: At the end of the voting process,
the decrypted key shares need to be combined to decrypt
the homomorphically tallied result, thus distributing trust in
the decryption process. Additionally, (iii) E2E-V is provided,
including a Cast-as-Intended, a Recorded-as-Cast, and Tallied-
as-Recorded verifiability, mainly by using the public permis-
sioned BC as a PBB [8]. Finally, (iv) Client-Side Encryption
is used, which is a crucial part of any REV system since the
encryption on the client-side requires careful considerations
of the security of the browser [30]. This newly designed and
prototypically evaluated E2E-V protocol does not yet offer any
Coercion-Resistance or Receipt-Freeness.
The remainder of this paper is organized as follows. While
relevant background and related work is presented in Sec-
tion II, Section III outlines cryptographic primitives. Based on
Section’s IV details on Provotum’s design, assumptions, and
stakeholders, Section V defines Provotum’s voting protocol.
Built on Section’s VI description of the prototype, Sections VII
and VIII render the evaluation and discussion. Finally, Sec-
tion IX draws conclusions and outlines future work.
II. BAC KG ROUND AND REL ATED WO RK
Research on REV systems spans 40 years, refining theoret-
ical properties to define private and verifiable REV systems
[26], from which background and related work is reviewed.
A. Blockchains and Distributed Ledgers
A Blockchain (BC) is an immutable backward linked-list
formed by blocks of transactions. The BC is maintained by
a distributed network of peers following a consensus mecha-
nism [5]. Permissionless BCs represent the majority of current
BCs, such as Bitcoin [38] and Ethereum [57]. Permissionless
BCs allow anyone to join and leave the BC network at any
time, as there is no central authority managing participants of
the network. Thus, the BC is open to be written to and read by
anyone as long the protocol is followed. In a permissioned BC,
referred to as a Distributed Ledger (DL), a central authority or
a consortium grants access rights to authorized parties. Further
distinctions depend on whether a BC is public permissioned
(i.e., reading is possible for everyone) or private permissioned
(i.e., reading is restricted to selected entities).
BCs and DLs rely on consensus mechanisms to agree on the
next state of the network and to maintain its consistency across
all nodes. Traditional consensus mechanisms (e.g., Byzantine
Agreement Protocols [45]) are not suitable for BCs, as they
are susceptible to Sybil Attacks [41]. Hence, a myriad of
mechanisms, including Proof-of-Work (PoW) and Proof-of-
Authority (PoA), were proposed to address specific BC and
DL types [56]. PoW is mostly used by permissionless BCs,
where miners solve a difficult mathematical problem, which
determines whether they can append blocks or not. Such diffi-
culty is adjusted depending on the network’s computational
power to ensure that blocks are produced in a fixed time
interval. For a permissioned BC, PoA is suitable, since it
does not depend on nodes solving mathematical problems, but
instead uses a set of authorities,i.e., nodes that are explicitly
allowed to create new blocks. These authorities are usually
referred to as Sealers or Validators of the BC. The new state
of the BC has to be signed off on by the majority of authorities,
in which case it becomes a part of the permanent DL in the
form of an additional block. This setup has the advantage
that it is less computationally intensive compared to the PoW
mechanism and blocks can be created more predictably (i.e.,
in more steady time intervals).
B. Related Work
Informally, privacy is defined by Ballot Secrecy (BS),
Receipt-freeness (RF), and Coercion-resistance (CR) [11].
BS and privacy are synonymous in REV literature, but the
term BS is favored to avoid confusion with other notions of
privacy [54]. Thus, BS is concerned with the privacy of the
ballot, whereas RF ensures that a voter cannot gain a receipt of
how she voted to avoid vote selling and buying [4]. A scheme
offers CR if it is infeasible for the coercer to determine if a
coerced voter complies with the demands [28]. And perfect
BS ensures that knowledge about the partial tally of the ballots
of any set of voters is only computable by the coalition of
all the remaining voters (this property captures strong voter
privacy as understood in real-world elections) [29].
1) Properties: Three properties define verifiability in the
context of EV [11]: (i) Individual Verifiability ensures that a
voter can verify that the PBB includes the vote cast [28]. (ii)
Universal Verifiability means that anyone can check that a PBB
contains all votes of the final tally. (iii) Eligibility verifiability
means that anyone can check that each ballot on the PBB
was cast by a registered, eligible voter. At most, one ballot is
tallied per voter [32]. Refinements of Eligibility Verifiability to
Unforgeability ensure that only eligible voters can construct
authorized ballots [54]. Furthermore, E2E-V consists of (i)
Cast-as-Intended, (ii)Recorded-as-Cast, and (iii)Tallied-as-
Recorded Verifiability [3]. However, “If voters and election
observers do not have complete freedom regarding which
software to trust to do the verification, or if only a privileged
few can verify at all, the system is not truly E2E-V” [3].
Additional properties include the notion of Software In-
dependence (SWI). The problem that SWI addresses is the
difficulties in verifying correct casting, recording, and tallying
done by sophisticated software in EV systems. Convincing
anyone of the fact that the voting software is correct is
arguably impossible, especially in a complex and full EV
system. Furthermore, it is argued that the growing complexity
and contradictory requirements lead to even more complex and
hard-to-test EV systems. Hence, the maxim followed by SWI
is Verify the election results, not the voting system. [48].
2) REV Systems: BCs and DLs offer desirable properties
for REV systems and are used as PBB’s. BC-based REV
often relies on a public permissionless BC as a PBB to store
encrypted ballots and to provide verifiability of the final tally.
E.g., [34] relies on trust between a voter, a central organizer,
and an inspector. The voter encrypts the vote with the central
organizer’s public key before the inspector signs it to cast a
ballot. This system assumes that both actors can be trusted.
Hardwick et al. [24] proposes a system with a private
Ethereum instance relying on a central certificate authority
to authenticate voters; violating the ballot secrecy should
the authority become byzantine. A variant of the Open Vote
Network (OVN) [36] offers self-tallying of votes. All votes
are publicly available once cast and the final tally can be
verified by anyone. This leads to the drawback of fairness,
since the last voter can tally the final result before anyone
else can. OVN is based on the Ethereum BC and is practical
for 40 voters. Seifelnasr et al. [52] proposes improvements
to OVN, introducing an off-chain untrusted administrator to
perform the bulk of the computations.
Similarly, Caforio et al. [7] proposes a decentralized voting
system based on a mechanism that resembles a BC [40].
The entire voting system is based on a state machine that
maps different stages of an election. For each stage, different
protocols are used with the main premise of maintaining
the privacy of votes, including their verification. The system
relies on the ElGamal cryptosystem in combination with Neff
Shuffles [39] to achieve privacy, and Non-Interactive Zero-
Knowledge Proofs [50] for verifiability.
III. CRYP TOGR AP HI C INSTRUMENTS IN USE
Cryptographic instruments are the key to building secure
REV systems. Table I shows these instruments used with
a concise mapping to Provotum’s voting protocol phases
and steps. Thus, a feasible approach to build REV sys-
tems is to employ Public Key Cryptography (PKC) based
on Finite Fields or Elliptic Curve Cryptography (ECC). In
combination with threshold cryptography, Homomorphic En-
cryption (HE) [50], Distributed Key Generation (DKG) and
Cooperative Decryption (CD), private keying material can be
distributed among trustees. Non-Interactive Zero-Knowledge
Proofs (NIZKP) are used to prove the validity of ciphertexts.
A. Homomorphic Encryption (HE)
HE allows operations on encrypted data. Therefore, con-
fidential data remains private, even when an operation is
performed in an untrusted environment, e.g., a public cloud
provider [1]. This property can be used to tally votes in a
REV system. Thus, every eligible voter can encrypt his or her
vote using the election public key, resulting in an encrypted
vote. No individual votes need to be decrypted because these
votes can be added together homomorphically [26].
TABLE I: Cryptographic Instruments Applied in Provotum
Phases Steps Approach References
Pre
Voting
Registration PKC Ethereum Wallet [6]
Pairing ECC ECDSA [57]
Key-generation DKG, NIZKP
Robust Threshold
ElGamal
Cryptosystem [12],
Schnorr-Proofs [51]
Voting Voting PKC, NIZKP
ElGamal
Cryptosystem [17],
Disjunctive Chaum-
Pedersen Proof [2]
Post
Voting
Tallying CD, NIZKP
Robust Threshold
ElGamal Crypto-
system [12], Chaum-
Pedersen Proof [9]
Result ECC ECDSA [57]
1) ElGamal Cryptosystem: The ElGamal scheme is a PKC
system defined over cyclic groups Gand is based on the
difficulty of solving the discrete logarithm problem in G[17].
ElGamal provides indistinguishability under chosen-plaintext
attack and is provably secure under the Decisional Diffie-
Hellman (DDH) assumption [14]. Also, ElGamal is homo-
morphic with respect to multiplication. Therefore, component-
wise multiplication of two ciphertexts results in encryption
of the product of respective plaintexts, which allows for the
homomorphic tallying of encrypted votes without decrypting
individual ballots [21]. ElGamal uses a cyclic group Z
p, a
multiplicative group Gdefined over a finite field of integers
Zp(i.e., multiplications of integers are always modulo p). For
security reasons, the finite field with generator gand order
of the group qare required to be a prime field, pand qare
co-prime, and pshould be at least 2,048 bits long.
a) Key Generation: The private key sk is a secure
random value in the range [1, q 1]. The public key pk is
the generator gof the cyclic group chosen, Z
pto the power
of the private key modulo p:
(sk, pk)=(r, h)=(r, gr(mod p)) (1)
b) Encryption: To encrypt a plaintext m(i.e., a no vote
of value 0or a yes vote of value 1) producing a ciphertext
(c1, c2), a secure random value rin [1, q 1] needs to be
computed. The first component of the ciphertext c1is equal
to the group’s generator gto the power of the random value
rmodulo p. The second component c2is the product of the
public key hto the power of the random value rand the
plaintext (i.e., vote) m∈ {0,1}modulo p:
(c1, c2)=(gr(mod p), hrm(mod p)),m∈ {0,1}(2)
c) Decryption: To decrypt a ciphertext (c1, c2), the mul-
tiplicative inverse of the first component c1to the power
of the private key sk is multiplied with the cipher’s second
component c2modulo p(3).
m= (csk
1)1c2(mod p)(3)
B. Distributed Key Generation
DKG and CD distribute trust and mitigate the risk of one
party decrypting individual ballots. A threshold cryptosystem
is used, where nout of nparties need to be present to
decrypt a ciphertext [12]. This can be used in conjunction
with the ElGamal public-key cryptosystem. The encryption
algorithm for voters remains the same. However, the DKG
and decryption steps need to be adjusted as follows.
The keypair is generated similarly to the standard ElGamal
Key Generation. Each party i[1, n]creates a key pair
(ski, pki)(cf. Equation 4) resulting in nkeypairs. While
private keys skiare kept secret, public keys pkiare collected
and combined to form the system’s public key pk =h(cf.
Equation 5), which will be used to encrypt these votes.
(ski, pki) = (ri, hi)=(ri, gr
i(mod p)) (4)
pk =h=
n
Y
i=1
pki(mod p)(5)
C. Cooperative Decryption
CD is performed in two steps. First, each party decrypts the
ciphertext (c1, c2)by using their private key ski, producing
a decrypted share di(cf. Equation 6). These shares do not
reveal anything about the plaintext. Then, decrypted shares are
collected and combined to reveal the plaintext (cf. Equation 7).
di=cski
1(mod p)(6)
(7)
input ciphertext = (c1, c2)
dec. shares = [d1, ..., di, ..., dn]
decryption m=c2
Qn
i=1 di
(mod p)
=c2×(
n
Y
i=1
di)1(mod p)
D. Zero-Knowledge Proof
A Zero-Knowledge Proof (ZKP) is a cryptographic method
by which a prover Pcan prove to a verifier Vthat it knows
about a secret s(e.g., the content of a vote) without revealing
anything about sapart from the fact that it knows s. The
proof is called zero-knowledge because Vlearns nothing about
sapart from the fact that Pknows about s[26], [53]. In
REV systems, ZKPs can be used to generate proofs for valid
ballots, without revealing anything about the voter’s choice.
This ensures that only valid votes are considered in the final
tally [26], [53]. Moreover, ZKPs can also be used to prove
that the decryption was done using the private key associated
with the public key previously used for encryption.
The issue with interactive ZKPs is that the communication
between the Pand Vis time-consuming, costly, and often not
feasible in practice. A popular alternative is non-interactive
ZKPs (NIZKP), which do not require any interaction between
Pand V. The interaction (i.e., the challenge chosen by the
verifier) is replaced by a cryptographic hash function serving
as a random oracle. This is also known as applying the Fiat-
Shamir heuristic [20] to an interactive ZKP. The following
proofs are ZKPs transformed to NIZKP using the Fiat-Shamir
heuristic. Thus, they can be used in REV systems without the
need for interaction to generate and validate the proofs.
E. Schnorr Proofs
To prove knowledge of an ElGamal private key r, belonging
to a public key h(i.e., h=gr), the Schnorr Proof [51] is
suitable. It is a proof of knowledge of a discrete logarithm of
r=logg(gr)[22].
1) Schnorr Proof Generation: The proof can be created
as shown in Equation 8. The private/public key pair (r, h)
is needed as input. Additionally, a secure random value of
ain the range [1, q 1] is needed. q=p1
2is the additive
modulus of the cyclic group Z+
qover the field Fq(i.e., the
cyclic group in which all additive operations take place) and
gis the group’s generator. The id is the unique identifier of
the prover. To generate the proof, first, the commitment b, the
generator gto the power of a, is hashed together with the
unique id and the public key h. This forms the challenge c
that is the first part of the proof. The second part of the proof
is the response, which is the sum of the random value aand
the product of the challenge cand the private key r.
(8)
input keypair = (sk, pk)=(r, h)
commitment b=ga(mod p)
challenge c=hash(id, h, b) (mod q)
response d=a+c×r(mod q)
output proof = (c, d)
2) Schnorr Proof Verification: To verify the Schnorr proof
(c, d), first, the commitment b0and challenge c0need to be
recomputed, as shown in Equation 9. Then, the recomputed
challenge c0needs to match the original challenge c. And the
generator gto the power of the response dneeds to be equal to
the recomputed commitment b0multiplied by the public key h
to the power of the original challenge c. If both checks are
successful, the proof verification concludes successfully.
(9)
input proof = (c, d)
rec. commitment b0=gd/hc(mod p)
rec. challenge c0=hash(id, h, b0) (mod q)
compare hashes c!
=c0
verify proof gd(mod p)!
=b0×hc(mod p)
F. Chaum-Pedersen Proof
The Chaum-Pedersen proof [9] can be used to affirm the
correct decryption of a cipher (c1, c2)using the private key
r. It is a proof of discrete logarithm equality of logg(gr) =
logh(hr)and is similar to the Schnorr Proof [12].
1) Chaum-Pedersen Proof Generation: To generate the
proof for a ciphertext (c1, c2)(cf. Equation 10), a secure
random value xin the range [1, q 1] is needed. The
commitment consists of two parts, aand b,ais equal to the
cipher’s first component c1to the power of the random value
x, and bis equal to the generator gto the power of x. The
challenge cis computed by hashing the unique prover id, the
cipher’s components c1and c2, and commitments components
aand busing a cryptographic hash function. The final response
consists of fand d.fis computed by adding the random value
xto the product of the challenge cand the private key r, and
dis the cipher’s first component c1to the power of the private
key r. The proof itself consists of the commitment (a,b) and
the response (f,d).
(10)
input ciphertext = (c1, c2)
commitment a=cx
1(mod p)
b=gx(mod p)
challenge c=hash(id, c1, c2, a, b) (mod q)
response f=x+c×r(mod q)
d=cr
1(mod p)
output proof = (a, b, f, d)
2) Chaum-Pedersen Proof Verification: The respective ver-
ification consists of the commitment (a,b) and the response
(f,d) for a ciphertext (c1,c2) (cf. Equation 11). The challenge
c0is recomputed by hashing the prover’s unique id together
with the cipher (c1,c2) and the response (a,b) extracted
from the proof. To verify the proof’s validity, two checks are
performed: (i) the cipher’s first component c1to the power
of the response’s fist component fneeds to be equal to the
commitment’s first component amultiplied with the response’s
second component dto the power of the recomputed challenge
c0and (ii) Whether the generator gto the power of the
response’s fist component fis equal to the commitment’s
second component bmultiplied with the public key hto the
power of the recomputed challenge c0is checked.
(11)
input proof = (a, b, f, d)
ciphertext = (c1, c2)
rec. challenge c0=hash(id, c1, c2, a, b) (mod q)
verify proof cf
1(mod p)!
=a×dc0(mod p)
gf(mod p)!
=b×hc0(mod p)
3) Disjunctive Chaum-Pedersen Proof: The disjunctive
Chaum-Pedersen proof is a modification of the Chaum-
Pedersen proof introduced in [2]. It is used for the encryption
and is also called OR-proof or membership proof since the
vote contained in the ballot is proven to be either a no-
vote (value 0, subsequently represented as v0) or a yes-vote
(value 1, subsequently represented as v1) and guaranteed to be
nothing else. The proof does this without revealing the vote’s
actual content; thus, it is used during vote encryption.
4) Disjunctive Chaum-Pedersen Proof Generation: The
proof generation is composed of two parts. The yes-part and
the no-part for which only one part ever exists, i.e., the
knowledge of the actual encrypted choice and, in both cases,
the contrary part needs to be simulated as well. E.g., if the
ballot contains a yes-vote v1, the no-vote v0part of the proof
needs to be simulated. The proof is generated with Equation
12, which is an example for a yes-vote proof, whereas c0, f0, x
are secure random values in the range [1, q 1] and ris the
random value used in the encryption of the vote.
(12)
input ciphertext = (a, b)
sim.(v0) (a0, b0)=(gf0/ac0(mod p), hf0/bc0(mod p))
proof(v1) (a1, b1)=(gx(mod p), hx(mod p))
challenge c=hash(id, a, b, a0, b0, a1, b1) (mod q)
c1=cc0(mod q)
response f1=x+c1×r(mod q)
output v1proof = (a0, b0, a1, b1, c0, c1, f0, f1)
In the case of the no-vote proof (cf. Equation 13), instead
of simulating c0, f0, the values c1, f1(secure random values
in the range [1, q 1]) are simulated Another slight change is
that instead of using bin the simulation, b/g is used. Actually,
in the v1proof, b/g0is taken, which equals b. In the v0proof,
where the yes-vote (of value 1) is simulated, b/g1is taken [2].
(13)
input ciphertext = (a, b)
sim.(v1) (a1, b1)=(gf1/ac1(mod p),
hf1/(b/g)c1(mod p))
proof(v0) (a0, b0)=(gx(mod p), hx(mod p))
challenge c=hash(id, a, b, a0, b0, a1, b1) (mod q)
c0=cc1(mod q)
response f0=x+c0×r(mod q)
output v0proof = (a0, b0, a1, b1, c0, c1, f0, f1)
5) Disjunctive Chaum-Pedersen Proof Verification: Both v1
and v0proofs are validated using the algorithm described in
Equation 14. The ciphertext serves as input (i), while the
recomputed challenge (ii) is followed by a comparison of
hashes (iii) and concludes with various checks executed to
validate the proof (iv).
(14)
(i) ciphertext = (a, b)
proof = (a0, b0, a1, b1, c0, c1, f0, f1)
(ii) c0=hash(id, a, b, a0, b0, a1, b1) (mod q)
(iii) c0+c1(mod q)!
=c0
(iv) gf0(mod p)!
=a0×ac0(mod p)
gf1(mod p)!
=a1×ac1(mod p)
hf0(mod p)!
=b0×bc0(mod p)
hf1(mod p)!
=b1×(b/g)c1(mod p)
IV. PROVOTUM DESIGN
Provotum is designed as a REV system based on a public
permissioned BC, which serves as a PBB but also enforces
the correct execution of the voting protocol. The use of a BC
achieves public verifiability through an immutable, redundant
data store that is persisted across a distributed network of
BC nodes. Further, the full state of the application and the
application logic (i.e., the voting protocol) is immutably stored
and executed on by all BC nodes in the distributed BC net-
work, achieving redundant operation. While the first version of
Provotum [35] stored all votes on-chain, it relied on a central
server to handle encryption and proof generation, which is
obviously infeasible in a real-world scenario. Therefore, this
section focuses on the new Provotum design [47], [46], which
still leverages a public permissioned BC as PBB. However, the
voting protocol is now fully executed on-chain in the ballot’s
Smart Contract (SC).
Sealers
Public Perm is si oned BC
Votin g
Aut hor it y Voters
Acc ess
Prov id er
Ident ity
Prov id er
sign blocks deploy ballot SC vote, verify
authenticate
authorize
Fig. 1: Provotum System Design
A. Assumptions
The assumptions made for Provotum are congruent with
[30] since the use-case of deployment is similar: deploying
a REV system that takes the requirements of Switzerland, a
federalistic state, into account. However, while [30] shows
similarities in these assumptions, the voting protocol offers
different properties, since DKG and CD are not implemented
in the CaIV case.
TABLE II: Provotum’s Design Assumptions as of [30]
ID Description
A1Every voter is only allowed to cast a single vote once.
A2Every eligible voter is uniquely identifiable.
A3The voting authority nodes are fixed and known a priori.
A4The connection between the voter’s voting device and the voting
network is confidential.
A5Submitted votes contain either 1 or 0, thus, votes are binary.
B. Public Bulletin Board
Key properties of a PBB are (i) readability by anyone,
(ii) immutability of the information on the PBB, and (iii)
the consistent state of the PBB for anyone viewing it [27].
Therefore, such a PBB is fundamental for any REV system,
since auditable information is published during the execution
of the voting protocol. Due to the Swiss federalistic structure, a
public permissioned BC serves as an appropriate PBB without
a central node, since this allows for the distributed execution
of the voting protocol among trusted authorities [30]. Since
all writers to the PBB are trusted authorities and known
beforehand, there is no need to employ a PoW-based consensus
mechanism to secure the network. Thus, a PoA consensus
mechanism is a perfect fit given assumption A3 of Table II.
C. Stakeholders
1) Sealers: are authorities allowed to sign blocks and
participate in the consensus algorithm. The advantage of using
a BC over an always-online Trusted Third Party (TTP) is
that weaker trust assumptions necessary because voters can
publicly verify the BC’s data without requiring access through
any intermediaries. By doing so, there is no longer a SPoF.
Furthermore, additional validators can participate in the PoA
consensus (e.g., non-governmental organizations or any other
partially trusted organization) to further increase trust in the
network [58]. Sealers participate in the DKG and also in the
Cooperative Decryption during tallying, once the voting has
ended. In the Swiss scenario, each canton can act as a trusted
Sealer and operate such a service.
2) Voting Authority (VA): The VA is the voting adminis-
trator and acts mainly as a coordinator of the voting phase
in Provotum. The VA is responsible (i) for coordinating the
initial start-up phase of the BC with Sealers, (ii) deploying the
voting SC on the BC and (iii) formally opening and closing
the vote. In general, the definition of the VA depends on the
vote at hand and could be handled by different organizations in
collaboration (e.g., the municipality, the canton, or the national
government).
3) Voters: Voters are eligible citizens willing to participate
in the voting process. The first voter’s responsibility is to
authenticate with the Identity Provider (IdP). The Access
Provider (AP) will authorize the voter to cast his or her vote.
Then, the voter can cast his / her vote and, if required, verify
the E2E-V of the process by inspecting the PBB.
4) Identity and Access Provider: The IdP is a TTP responsi-
ble for the verification of voter eligibility. The IdP provides an
authentication service that validates and verifies the Electronic
Identity (E-Identity) of users trying to receive authorization
for the REV system. After verifying the E-Identity, the IdP
provides a one-time token that will be used by the voter
to authorize with the AP. The AP is a service provided by
the VA or another TTP. The AP provides an authorization
service that only grants access to eligible voters by validating
the voter’s one-time token. If successful, the AP funds the
voter’s BC account with voting tokens (e.g., in the case of
a ballot SC requiring specific tokens), which allows the user
to participate in the vote. Together, this provides secure and
privacy-preserving authentication and authorization.
V. PROVOTU MSVOTI NG PROTO CO L
The Provotum voting protocol is divided into three phases:
(1) the Pre-Voting Phase, (2) the Voting Phase, and (3) the
Post-Voting Phase (cf. Figure 2). The voting protocol is fully
Pre-Voti ng Phase
Regis tratio n Pai ring Key Gener ation
Votin g Phase
Voting
Post-Voti ng Phase
Tallyi ng Resul t
on c hain
Ident ity Pro visio ning
off chain off chain on c hain on c hain on chain on ch ain
Fig. 2: Provotum Voting Protocol Phases, Sub-phases, and Overview
executed on the BC as soon as the ballot SC has been deployed
during pairing, enforcing the distribution of trust among VAs.
A. Identity Provisioning
Identity Management (IdM) is dependent on the legal
regulation and often formulated as an assumption in REV
systems. However, to achieve an end-to-end voting process,
Provotum includes a simplified IdM in order to evaluate
the prototype. Before the voting protocol starts, an Electoral
Register is created, containing eligible voters for the vote. The
IdP generates a randomized one-time token for each eligible
voter and sends a shuffled list of all tokens to the AP. The
IdP verifies the identity of the voter (i.e., a digital certificate
issued by the government containing the unique ID of the
voter) and checks if the voter is eligible for this vote. The
voter (1) authenticates him-/herself with the IdP using his/her
E-ID. If the eligibility verification is successful, (2) the IdP
issues a one-time tokenvto the voter, then (3) the voter
generates a new Ethereum account and submits it along with
the tokenvto register with the AP. The AP verifies the one-
time tokenv, and (4) ensures that the voter’s Ethereum account
has sufficient funds to send a vote transaction. This step is only
required because the prototype uses a permissioned BC based
on Ethereum.
B. Pre-Voting Phase
The Pre-Voting phase sets up the Voting Phase in three steps.
1) Registration: During the registration, all Sealers gener-
ate public/private keys for the BC account and register the
public key with the VA. Each cantonal Swiss Election Office
(EO) can participate, allowing them to seal blocks in the BC.
2) Pairing: From the VA, all Sealers retrieve the BC
genesis block, which defines a configuration file with addresses
authorized to sign blocks (the Sealers). The VA acts as a
bootstrapping node for the BC, helping all other Sealers to
interconnect. Once all Sealers are sealing, the VA deploys
the ballot SC to the BC. The ballot SC handles all vote-
specific information (e.g., the vote’s system parameters, ev-
ery encrypted vote, and proofs thereof). Now all subsequent
actions are executed on all Sealers, distributing trust among
them.
3) Key Generation: After the successful deployment of the
ballot SCs, the DKG is initiated. Thus, all Sealers generate (a)
an ElGamal public/private key pair and (b)a non-interactive
Schnorr proof of knowledge, which are both sent to the ballot
SC. This step ensures the distribution of trust among all
participating Sealers, omitting any centralized SPOFs. Once
every Sealer submits their public key and their proof has been
verified, the VA initiates the generation of the public key
for voting in the ballot SC, which will create the system’s
public key pkvoting by combining all the Sealer’s public keys
pkvai, i n, where nis the total number of Sealers. The
voting public key is used by all voters for vote encryption.
Once the pkvoting has been generated, the VA can open the
vote, which in most cases is a pre-defined and announced point
in time.
C. Voting Phase
The Voting Phase includes three steps performed by the
voter on his/her voting client: (i) the voter can proceed by
making a voting decision and encrypting the vote. This is
done automatically by the local voting client software, once the
voter has selected his choice. In addition to the encrypted vote,
the system will generate a NIZKP, proving that the encrypted
vote contains one of the two possible answers (i.e., yes or
no) and nothing else without revealing the actual content of
the vote; (ii) the encrypted vote and NIZKP are sent to the
ballot SC, and vote casting is concluded as soon as the ballot
SC first successfully verifies the proof and stores the encrypted
vote; (iii) the voter will receive a vote confirmation transaction
that can be used to check whether the vote had been Cast-as-
Intended. Since all votes and proofs are stored on the BC, each
voter can verify the inclusion in the ballot SC.
D. Post-Voting Phase
Once the voting period ends, which is a previously defined
and publicly communicated point in time, the VA closes the
vote by calling a function of the ballot SC and the Sealers can
decrypt and tally the final result.
1) Tallying: The Sealers (i)retrieve all encrypted votes
from the BC, (ii)add them homomorphically, perform partial
decryption on a share of the final tally, and (iii)also generate
a ZKP proving the correct decryption using the private key
skvaiassociated with the Sealer’s public key pkvaistored in
the ballot SC. The decrypted share and the proof are both
submitted to the ballot SC, which verifies the validity of the
proof, rejecting any invalid submissions. As a final step of
tallying, any Sealer can trigger the final tallying simply by
calling the tally function in the ballot SC, since all decrypted
shares from the VAs are already persisted in the SC.
2) Result: All decrypted shares dvaicombined allow for
the generation of the decrypted result i.e., the number of
yes-votes submitted (result =Pn
i=0 dvai). The ballot SC
automatically subtracts the number of yes-votes from the total
number of submitted votes in order to obtain the number of
no-votes: |votesno|=|votestotal| − |votesyes |. The result is
stored in the ballot SC and everyone can verify the proof of
correct decryption or perform the decryption as well since all
decrypted shares are stored in the ballot SC.
VI. PROTOT YP IC AL IMPLEMENTATION
Major technical details for the prototype are provided in
detail in [47]. All cryptographic instruments are provided in
a separate repository [46], allowing for modular re-use of
the code. Provotum provides front-ends for all stakeholders.
Thus, interacting with the REV system (and thus, the BC and
PBB) does not require any additional software installation or
low-level interactions because the system is fully controlled
through browser-based dashboards. TypeScript [37] was used
for all front and back-ends.
The back-end components (e.g., the VA back-end, relaying
interactions with the BC and the VA front-end) are also im-
plemented in TypeScript and use Node.js [42]. Since the PBB
is implemented as a public permissioned BC, Ethereum [19]
was selected, since it offers Turing-complete SCs to distribute
trust on-chain. For the Ethereum protocol implementation, the
Parity Ethereum client (now called OpenEthereum) [43] client
was used. All components are containerized using Docker [15]
and can be started via a single script provided in [47].
A. Ballot Smart Contract (SC)
The ballot SC is the key, since it enforces the correct exe-
cution of the voting protocol. It contains the main application
logic of Provotum and enables the distribution of trust by using
SCs implemented in Solidity [18].
As indicated in Listing 1, the ballot SC enforces the voting
protocol by using voting states, which are persisted and
verified on-chain at the beginning of the function call (cf.
Listing 4). By following a state-machine based approach, it
is possible to ensure the correct execution order of the ballot
SC and prevent actions, for example, performing the ”tallying”
before the ”voting” actually happens.
1enum VotingState{KEY_GENERATION, VOTING, TALLYING, RESULT}
Listing 1: Ballot.sol enum Voting States
The constructor of the ballot SC (cf. Listing 2) requires
a voting question to be defined. Instead of directly storing a
string, it could contain the cryptographic hash of a comprehen-
sive official document, cryptographically signed and hashed
by the authority (e.g., an official voting document published
by authorities on different online channels). The constructor
requires the number of authority nodes to be defined, which
is a numerical value for the authorities allowed to participate
in the DKG. Thus, the distribution of trust is enforced from
the beginning of the SC deployment.
1constructor(string memory votingQuestion, uint256
numberOfAuthNodes, address[] memory addresses) public
{
2voteVerifier = new VoteProofVerifier();
3sumVerifier = new SumProofVerifier();
4keyGenProofVerifier = new KeyGenProofVerifier();
5election.votingQuestion = votingQuestion;
6priviledgedAddresses = addresses;
7NR_OF_AUTHORITY_NODES = numberOfAuthNodes;
8}
Listing 2: Ballot.sol Constructor
The constructor instantiates verifiers (i) to verify NIZKPs
accompanied by public key shares submitted by Sealers during
the DKG, (ii) to verify NIZKPs, proving the validity of
ballots submitted and encrypted by voters, and (iii) to verify
NIZKPs submitted with decrypted shares during final tallying.
Privileged addresses define an array of addresses that belong
to entities not allowed to vote (VA, Sealers, and AP).
Listing 3 shows an excerpt of the Election struct, which
contains most of the variables relevant for the ballot SC, such
as the voting question, the number of voters, and an array
containing all voters, which, in turn, is a struct containing the
triple of the voter’s account address, the ciphertext encrypted
with the election public key, and the NIZKP proving the
validity of the encrypted ballot. The hasVoted mapping stores
information on every address, including whether it had already
cast a ballot, ensuring that no voter can vote multiple times.
1struct Election {
2string votingQuestion;
3uint256 nrOfVoters;
4Voter[] voters;
5mapping(address => bool) hasVoted;
6mapping(address => PublicKeyShare) pubKeyShareMapping;
7address[] publicKeyShareWallet;
8mapping(address => DecryptedShare)
decryptedShareMapping;
9address[] decryptedShareWallet;
10 Cipher sumCipher;
11 uint256 yesVotes;
12 }
Listing 3: Ballot.sol Election Struct
Once the ballot SC is deployed, the DKG initiates the voting
protocol on the BC. Each authorized entity is required to send
a public key-share for the DKG. In Listing 4, each Sealer cre-
ates a transaction with a call to his/her submitPublicKeyShare
function. This function requires (i) the voting state to be in
KEY GENERATION, (ii) the election public key to have not
yet been set, (iii) the proof Schnorr NIZKP, which is verified in
the KeyGenProofVerifier, and (iv) checking whether the Sealer
has already submitted a key share. If all checks are successful,
the key-share is persisted.
1function submitPublicKeyShare(uint256 key,uint256 proof_c,
uint256 proof_d) external
2returns (bool,string memory) {
3require(votingState == VotingState.KEY_GENERATION,
'Need state KEY_GENERATION.');
4require(!IS_PUBKEY_SET,'Public key already set.');
5require(keyGenProofVerifier.verifyProof(proof_c,
proof_d, key, msg.sender), 'Proof verification
failed.');
6// check if this address submitted a share
7bool sealerAlreadySubmitted = false;
8for (uint256 i; i < election.publicKeyShareWallet.
length; i++) {
9if (election.publicKeyShareWallet[i]==msg.sender){
10 sealerAlreadySubmitted = true;
11 }}
12 PublicKeyShare memory publicKeyShare = PublicKeyShare(
key, KeyShareProof(proof_c, proof_d));
13 if (!sealerAlreadySubmitted) {
14 // add sealer address to array
15 election.publicKeyShareWallet.push(msg.sender); }
16 // add or replace the share
17 election.pubKeyShareMapping[msg.sender] =
publicKeyShare;
18 return (true,'Proof verification succeeded.'); }
Listing 4: Ballot.sol Submitting Public Key Share for DKG
VII. PHA SE -BASE D SYS TE M EVALUATION
Provotum’s prototype has reached the stage of a fully
working end-to-end voting process, which is evaluated in a
Docker deployment. Following all steps provided in the voting
protocol as above, including all stakeholders, the working
prototype’s evaluation follows the use-case of a complete end-
to-end voting process for which videos are provided at [31].
The relevant stakeholders include the (i) Voting Authority
(VA) in charge of the vote, (ii) Sealers authorized to sign
blocks and participate in DKG and CD, and (iii) eligible
Voters. It is assumed that voters have been authorized and
identity provisioning was done a-priori (cf. Subsection V-A).
1) Registration Phase: This phase starts with each Sealer
generating an Ethereum account. Each Sealer starts its back-
end and front-end service, which will be served as depicted in
Figure 3a. The front-end triggers the transmission of the public
account address from the Sealer’s back-end to the VA’s back-
end. The registration stage is concluded once all Sealers have
sent their account address to the VA. The number of required
Sealers can be pre-defined, or a time-limited registration could
be opened beforehand. Once all Sealers have registered with
the VA, the next stage is started by the VA.
2) Pairing Phase: During the pairing stage, the VA gen-
erates an initial configuration file (i.e., genesis block) that
all Sealers retrieve from the VA and then start their BC
client, connecting to the bootnode, and bootstrapping the BC
network to participate in the consensus. Even though this BC
is permissioned, every transaction requires transaction fees.
Hence, the configuration is used to ensure that all wallets of
the VA, AP, and all Sealers show sufficient funds. The pairing
phase concludes with the deployment of the ballot SC (which
includes the definition of the voting question). The respective
VA fron-tend is depicted in Figure 3b.
3) Key Generation Phase: During this phase, all Sealers
generate an ElGamal public/private key pair (cf. Equation 1).
Each Sealer generates a NIZKP, proving knowledge of the El-
Gamal private key belonging to the public key (cf. Equation 8).
Once the keypair and the proof have been generated, the Sealer
will send both the public key and the NIZKP directly to the
ballot SC. The ballot SC first verifies the proof as shown in
Equation 9 and only stores the Sealer’s public key if the proof
verification has been successful. Once every Sealer submits
his/her public key and the respective proofs have been verified,
the VA initiates the generation of the system’s public key by
triggering a function in the ballot SC. It will generate the
system’s public key pksystem by combining all Sealer’s public
keys pksealeri, i n, where nis the total number of Sealers.
Once pksystem is generated, the VA can open the vote. By
opening the vote, the process advances to the voting phase.
4) Voting Phase: The voter front-end generates an
Ethereum account and uses it together with the one-time token
(provided by the Identity Provider) to authenticate with the AP.
The AP verifies the one-time token and, if successful, funds
the voter’s account. The voter can now proceed by making
a voting decision on the front-end, as depicted in Figure 3c.
Once selected, the front-end encrypts the vote (cf. Equation 2).
This is done automatically by the system once the voter has
selected his choice. In addition to the encrypted vote, the
system will generate the respective NIZKP (cf. Equation 12),
proving the validity of the encrypted ballot. Once the vote has
been encrypted and the proof has been generated, the voting
client submits both directly to the ballot SC to avoid trusting
any intermediary. The ballot SC first verifies the proof (cf.
Equation 14) and, if successful, stores the encrypted vote. The
respective voter’s view is shown in Figure 3d, which allows for
the verification on the BC with an integrated block explorer.
Here, the dashboard shows a visualization of the BC’s activity.
Once the voting period has ended, which has to be previously
defined and publicly communicated at some point in time, the
voting authority will close the vote by calling a function from
the ballot SC, concluding the voting stage.
5) Tallying Phase: During this phase, every Sealer fetches
encrypted votes from the BC and homomorphically adds these
encrypted votes to calculate the final sum. Afterward, each
Sealer decrypts a share of the vote’s final result and publishes it
to the ballot SC. A NIZKP proof is generated as well (cf. Equa-
tion 10) to ensure the integrity of the decryption performed by
the Sealer. The proof proves that the homomorphic sum has
been decrypted using the private key sksealeriassociated with
the Sealer’s public key pksealeristored in the ballot SC. This
ensures that only authentic decrypted shares are persisted, and
someone apart from the owner of the private key sksealeri
(i.e., the sealer) can submit a decrypted share for the respective
public key pksealeri. Once both the decrypted share and the
proof have been generated, the Sealer will send both directly
to the ballot SC. The ballot SC verifies the decryption proof
as shown in Equation 11 and stores the decrypted share only
if the proof verification was successful.
6) Results Phase: Once all Sealers have submitted the
decrypted shares, and the ballot SC persists them, the VA
triggers the final decryption step. The ballot SC combines the
decrypted shares dsealeriand generates the decrypted result
of all votes. The result is stored in the ballot SC, and anyone
can verify the result by combining the decrypted shares.
VIII. PROVOT UM SANA LYSI S AND DISCUSSION
REV systems need to be analyzed, especially with respect
to their privacy and verifiability, while considering additional
properties, such as Software Independence (SWI).
A. Privacy
Privacy is crucial for REV systems, especially as a property
of the voting protocol. Ballot Secrecy (BS) (also referred to
as Ballot Privacy (BP)) requires that the content of a cast
vote cannot be revealed under any circumstances and linked
to a voter. Provotum guarantees Ballot Secrecy, since voters
encrypt their votes using the system’s public key (pkvoting ),
which was generated using each VA’s public key share. How-
ever, no RF is provided yet, unless assuming a safe execution
environment, running unchanged voting system code and not
recording any of the cryptographic functions performed during
(a) (b)
(c) (d)
Fig. 3: Screenshots of Provotum’s Frontend Prototype: (a) Sealer front-end during Registration Phase, (b) VA front-end during
Pairing Phase, (c) Voter front-end during Vote Casting (Voting Phase), (d) Voter front-end after Vote Casting (Voting Phase)
execution. Therefore, RF (i.e., the inability to prove to a third-
party that a voter has cast a particular vote) is not yet given.
Although BS is obtained perfectly, CR cannot yet be guar-
anteed, which is a common problem in REV systems [26]. If
a voter and coercer are at the same physical location, the voter
can be forced to abstain or to give up his/her credentials. Since
the voting process is observable in person, the voter can be
observed making his/her voting choice. Also, Swiss law does
not permit multiple vote submissions, i.e., eligible voters are
only allowed to cast their vote once [13]. In other countries,
such as Estonia, voters are allowed to cast their votes multiple
times, where only the last vote is counted toward the final
tally [16]. Finally, long-term privacy (e.g., everlasting privacy)
cannot be guaranteed, since the Provotum protocol is based on
the security of the ElGamal public-key cryptosystem, which
is based on the DDH assumption.
B. Verifiability
Provotum provides E2E-V, since the voter can (a)check if
his/her vote had been Cast-as-Intended (CAI), (b)if the BC
included the vote Recorded-as-Cast (RAC), and (c)whether
the votes had been Counted-as-Recorded (CAR). Since the
voter encrypts a plaintext vote, generates a proof for its
validity, and directly submits it to the ballot SC where the
proof is verified and stored together with the encrypted ballot,
the voter can check its inclusion into the ballot SC and thus,
CAI verifiability is ensured once the ballot SC has verified the
correctness of the proof. The voter will obtain a reference to
his/her vote, i.e., the transaction hash of the block, including
his encrypted vote. The voter can retrieve the proof pand the
encrypted vote vat any given time thanks to the reference (i.e.,
the transaction hash of the block) obtained after submitting
both to the BC. RAC verifiability is provided by comparing the
locally-generated proof and the vote encrypted with the proof
obtained from the BC. By recomputing the final decryption
published by VAs, a voter can verify that CAR is provided.
C. Additional Considerations
The prototype1shows an implementation with easy-to-
use characteristics and consistent dashboards. The current
system does not yet scale to larger electorates. The main
limitation is not due to Provotum, but due to the choice of
the underlying BC as PBB. Thus, by replacing Ethereum as
the implementation choice, the Provotum design with a public
1Provotum’s source-code: http://provotum.ch
permissioned BC and its voting protocol is suitable to be
implemented on top of another BC (e.g., Substrate [44] or
Hyperledger Fabric [55]). Furthermore, Weak SWI [48] is
achieved in Provotum because anyone can fetch BC data and
implement a verifier to check the proofs provided within the
specification of the cryptographic instruments. A possible error
could be detected since all BC data is immutably stored and
distributed. However, if necessary, a recovery or roll-back will
require additional mechanisms to be integrated.
IX. SUMMARY, CONCLUSIONS,AN D FUTURE WORK
In summary, Provotum combines mathematically proven
cryptographic primitives in a practical approach, prototyping
all achievable properties, which can be analyzed within the
BC-based REV system. Since BCs are distributed, immutable,
and append-only, they are suitable for Public Bulletin Boards
(PBB) in REV systems and Provotum contributes a working
and fully documented proof-of-concept implementation. While
previous work on Provotum employed a central server archi-
tecture [35], the new Provotum delivers a fully distributed
system using a private permissioned BC as the PBB. This
system practically enables the following major characteristics:
(i) vote encryption and proof generation is handled on the
voter’s device, ensuring Ballot Secrecy; (ii) all cryptographic
proofs are verified on-chain by the ballot SC instead of a
central server; and (iii) the application of DKG and CD adds to
the robustness of the system by distributing the trust any single
node has to the entire network. The end-to-end voting process
is available for demonstration purposes in videos at [31].
Concluding, the Provotum REV system is the first one in
prototypical operation, offering full auditability of the entire
end-to-end voting process deployed locally with pre-built
Docker images [47], which are end-to-end verifiable, reach-
ing Ballot Secrecy. While full code transparency is reached,
Coersion-Resistance is not, since i.e., re-submission of votes
is not possible due to legal requirements in Switzerland.
The BC-based REV prototype still shows a few shortcom-
ings. Provotum’s properties hold for integers only up to a
length of 256 bit, determined by the limit of the Ethereum
Virtual Machine used. Furthermore, a full identity provisioning
and management scheme would be used in practice to support
the prototype. The scalability of cryptographic instruments
deployed requires further performance evaluations. The lack
of secure communication channels can be solved by deploying
Onion routing or similar schemes. And Provotum does not
yet support multi-way elections with a limited votes’ support.
Thus, future research will include additional protocol changes
achieving RF, the employment of secure communication chan-
nels between the voter and the BC network, and dedicated
encoding schemes for multi-way elections.
ACK NOWLED GE ME NT S
This paper was supported partially by (a) the University
of Z¨
urich UZH, Switzerland, and (b) the European Union’s
Horizon 2020 Research and Innovation Program under Grant
Agreement No. 830927, the CONCORDIA project.
REFERENCES
[1] F. Armknecht, C. Boyd, C. Carr, K. Gjosteen, A. Jaschke,
C. A. Reuter, and M. Strand, “A Guide to Fully Homomorphic
Encryption,” Cryptology ePrint Archive, pp. 1–35, 2015. [Online]:
https://eprint.iacr.org/2015/1192
[2] M. J. Atallah and M. Blanton, Algorithms and Theory of Computation
Handbook, Volume 1, 2nd Edt. Chapman and Hall/CRC, 11 2009.
[Online]: https://www.taylorfrancis.com/books/9781584888239
[3] J. Benaloh, R. Rivest, P. Y. A. Ryan, P. Stark, V. Teague, and P. Vora,
“End-to-end Verifiability,” CoRR, Vol. abs/1504.0, 4 2015. [Online]:
http://arxiv.org/abs/1504.03778
[4] J. Benaloh and D. Tuinstra, “Receipt-free Secret-ballot Elections,” in
26th Annual ACM Symposium on Theory of Computing (STOC ’94).
New York, New York, USA: ACM Press, 1994, pp. 544–553.
[5] T. Bocek and B. Stiller, “Smart Contracts – Blockchains in the Wings,
in Digital Marketplaces Unleashed. Springer, 2018, pp. 169–184.
[6] V. Buterin, “A Next-Generation Smart Contract and Decentralized Ap-
plication Platform,” 2013. [Online]: https://ethereum.org/en/whitepaper/
[7] A. Caforio, L. Gasser, and P. Jovanovic, “A Decentralized and
Distributed E-voting Scheme Based on Verifiable Cryptographic
Shuffles,” 2017. [Online]: https://www.epfl.ch/labs/dedis/wp-content/
uploads/2020/01/report-2017- 2-andrea caforio- evoting.pdf
[8] D. Chaum, “Secret-Ballot Receipts: True Voter-Verifiable Elections,
IEEE Security & Privacy Magazine, Vol. 2, No. 1, pp. 38–47, 1 2004.
[Online]: http://ieeexplore.ieee.org/document/1264852/
[9] D. Chaum and T. P. Pedersen, “Wallet Databases with Observers,” in
12th Annual Cryptology Conference (CRYPTO ’92), Vol. 740 LNCS.
Santa Barbara, California, USA: Springer, 1992, pp. 89–105.
[10] V. Cortier, D. Galindo, S. Glondu, and M. Izabach`
ene, “Election
Verifiability for Helios under Weaker Trust Assumptions,” Lecture Notes
in Computer Science, Vol. 8713 LNCS, No. PART 2, pp. 327–344, 2014.
[11] V. Cortier and B. Smyth, “Attacking and Fixing Helios: An Analysis
of Ballot Secrecy,” in 24th IEEE Computer Security Foundations Sym-
posium (CSF ’11), Abbaye des Vaux de Cernay, France, 6 2011, pp.
297–311.
[12] R. Cramer, R. Gennaro, and B. Schoenmakers, “A Secure and Opti-
mally Efficient Multi-authority Election Scheme,” in 17th International
Conference on the Theory and Application of Cryptographic Techniques
(EUROCRYPT ’97), Vol. 1233, Konstanz, Germany, 1997, pp. 103–118.
[13] Der Schweizerische Bundesrat, “Verordnung ¨
uber die politischen Rechte
(VPR) (vom 24. Mai 1978 (Stand 1. Juli 2019)),” 1978. [Online]: https:
//www.admin.ch/opc/de/classified-compilation/19780105/index.html
[14] W. Diffie and M. E. Hellman, “New Directions in Cryptography,” IEEE
Transactions on Information Theory, 1976.
[15] Docker Inc., “Docker.” [Online]: https://docker.com
[16] E. Dubuis, “E-Demokratie: E-Voting,” in Handbuch E-Government.
Wiesbaden: Springer Fachmedien Wiesbaden, 2019, pp. 1–14. [Online]:
http://link.springer.com/10.1007/978-3-658- 21596-5 39- 1
[17] T. Elgamal, “A Public Key Cryptosystem and a Signature Scheme based
on Discrete Logarithms,” IEEE Transactions on Information Theory,
Vol. 31, No. 4, pp. 469–472, 7 1985.
[18] Ethereum, “Solidity,” 2020. [Online]: https://solidity.readthedocs.io/
[19] Ethereum Foundation, “Ethereum.” [Online]: https://ethereum.org/
[20] A. Fiat and A. Shamir, “How to Prove Yourself: Practical Solutions to
Identification and Signature Problems,” in 4th Advances in Cryptology
Conference (CRYPTO ’86), Vol. 263 LNCS. Santa Barbara, California,
USA: Springer, 1987, pp. 186–194.
[21] R. Haenni, R. E. Koenig, P. Locher, and E. Dubuis, “CHVote System
Specification,” Cryptology ePrint Archive, Report 2017/325, 2017.
[22] F. Hao, “Schnorr Non-interactive Zero-Knowledge Proof,” RFC Editor,
Tech. Rep., 2017. [Online]: https://www.rfc- editor.org/rfc/rfc8235
[23] F. Hao and P. Y. A. Ryan, “Real-World Electronic Voting: Design, Anal-
ysis and Deployment,” Real-World Electronic Voting: Design, Analysis
and Deployment, pp. 1–461, 2016.
[24] F. S. Hardwick, A. Gioulis, R. N. Akram, and K. Markantonakis, “E-
Voting With Blockchain: An E-Voting Protocol with Decentralisation
and Voter Privacy,” in IEEE International Conference on iThings,
GreenCom, CPSCom and SmartData. Los Alamitos, CA, USA: IEEE,
2018, pp. 1561–1567.
[25] L. Hirschi, L. Schmid, and D. Basin, “Fixing the Achilles Heel of
E-Voting: The Bulletin Board,” IACR Cryptology ePrint Archive, Vol.
2020, p. 109, 2020. [Online]: https://eprint.iacr.org/2020/109
[26] H. Jonker, S. Mauw, and J. Pang, “Privacy and Verifiability in Voting
Systems: Methods, Developments and Trends,Computer Science Re-
view, 2013.
[27] H. Jonker and J. Pang, “Bulletin Boards in Voting Systems: Modelling
and Measuring Privacy,” in 6th International Conference on Availability,
Reliability and Security, (ARES ’11), 2011, pp. 294–300.
[28] A. Juels, D. Catalano, and M. Jakobsson, “Coercion-Resistant Electronic
Elections,” in ACM Workshop on Privacy in the Electronic Society
(WPES ’05). Alexandria, VA, USA: ACM, 2005, p. 61–70. [Online]:
https://doi.org/10.1145/1102199.1102213
[29] A. Kiayias and M. Yung, “Self-tallying Elections and Perfect Ballot
Secrecy,” in 6th International Workshop on Theory and Practice in
Public Key Cryptography (PKC ’02), D. Naccache and P. Paillier, Eds.
Miami, FL, USA: Springer Berlin Heidelberg, 2002, pp. 141–158.
[30] C. Killer, B. Rodrigues, R. Matile, E. Scheid, and B. Stiller,
“Design and Implementation of Cast-as-Intended Verifiability for a
Blockchain-based Voting System,” in 35th Annual ACM Symposium on
Applied Computing (SAC ’20). Brno, Czech Republic: ACM, 3 2020,
pp. 286–293. [Online]: https://dl.acm.org/doi/10.1145/3341105.3373884
[31] C. Killer, B. Rodrigues, E. Scheid, M. Franco, and B. Stiller, “Practical
Introduction to Blockchain-based Remote Electronic Voting,” 2020.
[Online]: https://github.com/christiankiller/icbc20-bcbev-tutorial/
[32] S. Kremer, M. Ryan, and B. Smyth, “Election Verifiability in Elec-
tronic Voting Protocols,” in 15th European Symposium on Research in
Computer Security (ESORICS ’10), Vol. 6345 LNCS. Athens, Greece:
Springer, Berlin, Heidelberg, 2010, pp. 389–404.
[33] R. Krimmer, “A Structure for New Voting Technologies: What
They Are, How They Are Used and Why,” in The Art of
Structuring: Bridging the Gap Between Information Systems Research
and Practice, K. Bergener, M. R¨
ackers, and A. Stein, Eds. Cham:
Springer International Publishing, 2019, pp. 421–426. [Online]:
https://doi.org/10.1007/978-3-030-06234- 7 39
[34] Y. Liu and Q. Wang, “An E-voting Protocol Based on Blockchain,”
IACR Cryptology ePrint Archive, p. 1043, 2017. [Online]: https:
//eprint.iacr.org/2017/1043.pdf
[35] R. Matile and C. Killer, “Privacy, Verifiability, and Auditability
in Blockchain-based E-Voting,” 2018. [Online]: https://files.ifi.uzh.ch/
CSG/staff/rodrigues/extern/theses/mp-raphael-christian.pdf
[36] P. McCorry, S. F. Shahandashti, and F. Hao, “A Smart Contract for
Boardroom Voting with Maximum Voter Privacy,” in Lecture Notes in
Computer Science, Vol. 10322 LNCS. Berlin, Heidelberg: Springer,
2017, pp. 357–375.
[37] Microsoft, “TypeScript.” [Online]: https://www.typescriptlang.org/
[38] S. Nakamoto, “Bitcoin: A Peer-to-Peer Electronic Cash System,” 2008.
[Online]: https://bitcoin.org/bitcoin.pdf
[39] C. A. Neff, “A Verifiable Secret Shuffle and Its Application to
E-Voting,” in Proceedings of the 8th ACM Conference on Computer
and Communications Security, Ser. CCS ’01. New York, NY, USA:
Association for Computing Machinery, 2001, p. 116–125. [Online]:
https://doi.org/10.1145/501983.502000
[40] K. Nikitin, E. Kokoris-Kogias, P. Jovanovic, N. Gailly, L. Gasser,
I. Khoffi, J. Cappos, and B. Ford, “CHAINIAC: Proactive Software-
Update Transparency via Collectively Signed Skipchains and Verified
Builds,” in 26th USENIX Security Symposium (USENIX Security 17),
2017, pp. 1271–1287.
[41] D. Ongaro and J. K. Ousterhout, “In Search of an Understandable
Consensus Algorithm,” USENIX Annual Technical Conference, pp. 305–
319, 2014.
[42] OpenJS Foundation, “Node.js.” [Online]: https://nodejs.org/en/
[43] Parity Technologies, “Open Ethereum.” [Online]: https://github.com/
openethereum/openethereum
[44] ——, “Substrate.” [Online]: https://github.com/paritytech/substrate
[45] M. Pease, R. Shostak, and L. Lamport, “Reaching Agreement in the
Presence of Faults,” Journal of the ACM (JACM), Vol. 27, No. 2, pp.
228–234, 1980.
[46] Provotum, “Provotum 2.0 Crypto Library.” [Online]: https://github.com/
provotum/evote-crypto
[47] ——, “Provotum 2.0,” 2020. [Online]: https://github.com/provotum/
provotum-v2
[48] R. L. Rivest and M. Virza, “Software Independence Revisited,” in Real-
World Electronic Voting: Design, Analysis and Deployment, 2016.
[49] R&S Scytl, “Swiss Online Voting System Cryptographic proof of
Individual Verifiability,” 2017.
[50] K. Sako and J. Kilian, “Receipt-Free Mix-Type Voting Scheme,” 1995,
pp. 393–403.
[51] C.-P. Schnorr, “Efficient Signature Generation by Smart Cards,Journal
of Cryptology, Vol. 4, No. 3, pp. 161–174, 1991.
[52] M. Seifelnasr, H. S. Galal, and A. M. Youssef, “Scalable Open-Vote
Network on Ethereum,” IACR Cryptology ePrint Archive, Vol. 2020, No.
November 2019, p. 33, 2020. [Online]: https://eprint.iacr.org/2020/033
[53] W. D. Smith, “Cryptography Meets Voting,” Compute, Vol. 10, p. 64,
2005.
[54] B. Smyth, “A Foundation for Secret, Verifiable Elections,” IACR
Cryptology ePrint Archive, p. 225, 2018. [Online]: http://eprint.iacr.org/
2018/225
[55] The Linux Foundation, “Hyperledger Fabric.” [Online]: https://github.
com/hyperledger/fabric
[56] W. Wang, D. T. Hoang, P. Hu, Z. Xiong, D. Niyato, P. Wang, Y. Wen, and
D. I. Kim, “A Survey on Consensus Mechanisms and Mining Strategy
Management in Blockchain Networks,” in IEEE Access, Vol. 7, 1 2019,
pp. 22 328–22 370.
[57] G. Wood, “Ethereum: A Secure Decentralised Generalised Transaction
Ledger.” Ethereum Project Yellow Paper, 2014.
[58] K. W¨
ust and A. Gervais, “Do you Need a Blockchain?” in IEEE Crypto
Valley Conference on Blockchain Technology (CVCBT ’18). Zug,
Switzerland: IEEE, 2018, pp. 45–54.
All links provided above were last accessed on October 15, 2020.
... Remote Electronic Voting (REV) is an essential topic, considering the further digitalization of society, which demands an increasingly efficient, transparent, and verifiable voting processes. REV allows for casting votes over the internet, applying cryptographic protocols to achieve End-to-End (E2E) verifiable schemes [30]. Furthermore, immutable Public Bulletin Boards (PBB) offer a transparent audit trail of the voting process. ...
... Distributed Ledgers (DL) offer a suitable approach to deploy a Decentralized PBB (DPBB) to achieve such a distribution of trust among authorities [29]. DLs are tamper-proof and immutable, replicate data securely, making them ideal for storing ballots that should not be manipulated by anyone [30]. This paper proposes AEternum, the first DL-based REV system combining a voting scheme with UP and a public permissioned DL, which serves as a DPBB. ...
... Although the prototype implementation uses Tendermint's consensus mechanism (requiring at least 2 /3 of all consensus nodes to behave honestly), a suitable alternative is Proof-of-Authority [29], [30]. For instance, in Switzerland, cantons, down to municipalities can participate in the consensus, only requiring at least 1 /2 nodes to behave honestly. ...
Conference Paper
Full-text available
Remote Electronic Voting (REV) systems allow voters to cast their votes in an uncontrolled, distributed environment. At the same time, the REV system must provide ballot privacy and verifiability of the final tally. Research has proposed REV schemes offering ballot privacy based on computational intractability assumptions, but only a few provide Unconditional Privacy (UP). Therefore, this work proposes Æternum, a REV system with a voting scheme providing UP. Æternum does not require trust in a central authority, nor does it assume computational intractability of an underlying mathematical problem to provide UP. To satisfy UP's minimal trust assumptions, AEternum uses a permissioned Distributed Ledger (DL), that forms a decentralized network of permissioned nodes, which serve as a transparent, tamper-proof Decentralized Public Bulletin Board (DPBB).
... Nevertheless, the major problem remains the logistics that this requires on a large scale: each voter would have to have a device that allows the transmission of his biometric data, which seems difficult to achieve now. [19], [23], [24], [63], [65] [19]- [21], [25], [68], [69] [20], [41], [43], [45], [52], [70]- [73] [20], [33] [38], [41], [43], [45], [49], [56], [58], [62], [70], [74] [26], [75] [28], [76] [25], [44], [49], [52], [57], [67], [73], [77]- [80] [22], [26], [26], [27], [33]- [35], [64] If the security of voter authentication seems complicated to ensure for the moment, the European initiative through the eIDAS regulation seems to be an interesting perspective to secure the identification of the voter during an e-vote [83]. The eIDAS regulation applies to electronic identification, trust services and electronic documents. ...
... Nevertheless, the major problem remains the logistics that this requires on a large scale: each voter would have to have a device that allows the transmission of his biometric data, which seems difficult to achieve now. [19], [23], [24], [63], [65] [19]- [21], [25], [68], [69] [20], [41], [43], [45], [52], [70]- [73] [20], [33] [38], [41], [43], [45], [49], [56], [58], [62], [70], [74] [26], [75] [28], [76] [25], [44], [49], [52], [57], [67], [73], [77]- [80] [22], [26], [26], [27], [33]- [35], [64] If the security of voter authentication seems complicated to ensure for the moment, the European initiative through the eIDAS regulation seems to be an interesting perspective to secure the identification of the voter during an e-vote [83]. The eIDAS regulation applies to electronic identification, trust services and electronic documents. ...
... The Zero Knowledge Proof is often used in a voting system [20], [33] [38], [41], [43], [45], [49], [56], [58], [62], [70], [74] to prove that the statement is indeed what it claims without revealing any additional information about the statement itself. In a voting system, the voter must convince the authority that his ballot is valid by proving that the ballot includes only one legitimate candidate without revealing his vote. ...
Article
Full-text available
To this day, abstention rates continue to rise, largely due to the need to travel to vote. This is why remote e-voting will increase the turnout by allowing everyone to vote without the need to travel. It will also minimize the risks and obtain results in a faster way compared to a traditional vote with paper ballots. In fact, given the high stakes of an election, a remote e-voting solution must meet the highest standards of security, reliability, and transparency to gain the trust of citizens. In literature, several remote e-voting solutions based on blockchain technology have been proposed. Indeed, the blockchain technology is proposed today as a new technical infrastructure for several types of IT applications because it allows to remove the TTP and decentralize transactions while offering a transparent and fully protected data storage. In addition, it allows to implement in its environment the smart-contracts technology which is used to automate and execute agreements between users. In this paper, we are interested in reviewing the most revealing e-voting solutions based on blockchain technology.
... Seifelnasr et al. [26] improved the scalability of [21] by reducing the storage requirements and delegating the tally computation to an off-chain entity. Besides the implementations of the self-tallying approach, other blockchainbased voting systems have been proposed, such as Zhang et al. [35], Alvi et al. [2], Dagher et al. [12] (BroncoVote), Killer et al. [19] (Provotum) or Zhang et al. [34] (Chaintegrity). Blockchain-based voting was also criticized by Park et al. [22] for bringing additional security issues rather than improvements. ...
Preprint
Decentralized electronic voting solutions represent a promising advancement in electronic voting. One of the e-voting paradigms, the self-tallying scheme, offers strong protection of the voters' privacy while making the whole voting process verifiable. Decentralized smart contract platforms became interesting practical instantiation of the immutable bulletin board that this scheme requires to preserve its properties. Existing smart contract-based approaches employing the self-tallying scheme (such as OVN or BBB-Voting) are only suitable for a boardroom voting scenario due to their scalability limitation. The goal of our work is to build on existing solutions to achieve scalability without losing privacy guarantees and verifiability. We present SBvote, a blockchain-based self-tallying voting protocol that is scalable in the number of voters and therefore suitable for large-scale elections. The evaluation of our proof-of-concept implementation shows that the protocol's scalability is limited only by the underlying blockchain platform. We evaluated the scalability of SBvote on two public smart contract platforms -- Gnosis and Harmony. Despite the limitations imposed by the throughput of the blockchain platform, SBvote can accommodate elections with millions of voters.
... Since the BCs proposal in late 2008 as an underlying infrastructure for a cryptocurrency [48] and their later application in several application domains and use cases [26,39,13], the BC concept shows measurably a strong decentralization, transparency, and immutability features. However, for selected use cases concerns raised, whether they require a BC [76,31]. ...
... Since the BCs proposal in late 2008 as an underlying infrastructure for a cryptocurrency [48] and their later application in several application domains and use cases [26,39,13], the BC concept shows measurably a strong decentralization, transparency, and immutability features. However, for selected use cases concerns raised, whether they require a BC [76,31]. ...
Chapter
Full-text available
Although the first Blockchain (BC) was proposed about a decade ago, BC achievements from a technical and functional perspective are measurable, but still face open issues. Since IFIP’s Working Group 6.6 on the “Management of Networks and Distributed System” investigated BCs in various aspects, this contribution here summarizes and clarifies key characteristics of BCs and their related approach of Distributed Ledgers (DL). While many properties are under discussion, the two approaches differ measurably. In turn, the value of BCs and DLs is outlined in combination with selected and exemplified application domains. However, a set of open issues has been observed, which possibly hinders a practical operation, e.g., due to excessive expectations, missing interoperability, wrong scalability promises, or out-of-scope trust assumptions. Thus, the state-of-the-art in BCs and DLs is clarified and current as well necessary research steps to follow complement this state.
Chapter
Highly-heterogeneous and fast-arriving large amounts of data, otherwise said Big Data, induced the development of novel Data Management technologies. In this paper, the members of the IFIP Working Group 2.6 share their expertise in some of these technologies, focusing on: recent advancements in data integration, metadata management, data quality, graph management, as well as data stream and fog computing are discussed.
Article
Electronic voting systems face many challenges, including authentication, privacy, data integrity, transparency and verifiability. However, the developed over 10 years ago blockchain technology provides an out-of-the-box solution for many of those challenges. Despite that, some issues are still to be solved, like remote authentication, anonymity and end-to-end verifiability. For this reason, research on new and better blockchain-based systems is still ongoing. The main goal of this study is to highlight the current trends in this research and its eventual shortcomings. This was accomplished by conducting a Systematic Literature Review (SLR) (Kitchenham and Charters, 2007), which resulted in selecting 35 publications. The performed SLR allowed to define trends in utilized blockchain technologies, intended scenarios, testing methods, main benefits and challenges faced by various systems and the most used cryptographic solutions.
Chapter
Full-text available
McCorry et al. (Financial Cryptography 2017) presented the first implementation of a decentralized self-tallying voting protocol on Ethereum. However, their implementation did not scale beyond 40 voters since all the computations were performed on the smart contract. In this paper, we tackle this problem by delegating the bulk computations to an off-chain untrusted administrator in a verifiable manner. Specifically, the administrator tallies the votes off-chain and publishes a Merkle tree that encodes the tallying computation trace. Then, the administrator submits the Merkle tree root and the tally result to the smart contract. Subsequently, the smart contract transits to an intermediate phase where at least a single honest voter can contend the administrator’s claimed result if it was not computed correctly. Then, in the worst case, the smart contract verifies the dispute at the cost of an elliptic curve point addition and scalar multiplication, and two Merkle proofs of membership which are logarithmic in the number of voters. This allows our protocol to achieve higher scalability without sacrificing the public verifiability or voters’ privacy. To assess our protocol, we implemented an open-source prototype on Ethereum and carried out multiple experiments for different numbers of voters. The results of our implementation confirm the scalability and efficiency of our proposed solution which does not exceed the current block gas limit for any practical number of voters.
Conference Paper
Full-text available
Digitization of electoral processes depends on confident systems that produce verifiable evidence. The design and implementation of voting systems has been widely studied in prior research, bringing together expertise in many fields. Switzerland is organized in a federal, decentralized structure of independent governmental entities. Thus, its decentralized structure is a real-world example for implementing an electronic voting system, where trust is distributed among multiple authorities. This work outlines the design and implementation of a blockchain-based electronic voting system providing cast-as-intended verifiability. The generation of non-interactive zero-knowledge proofs of knowledge enables every voter to verify the encrypted vote, while maintaining the secrecy of the ballot. The Public Bulletin Board (PBB) is a crucial component of every electronic voting system, serving as a publicly verifiable log of communication and ballots - here a blockchain is used as the PBB. Also, the required cryptographic operations are in linear relation to the number of voters, making the outlined system fit for large-scale elections.
Article
Full-text available
The past decade has witnessed the rapid evolution in blockchain technologies, which has attracted tremendous interests from both the research communities and industries. The blockchain network was originated from the Internet financial sector as a decentralized, immutable ledger system for transactional data ordering. Nowadays, it is envisioned as a powerful backbone/framework for decentralized data processing and data-driven self-organization in flat, open-access networks. In particular, the plausible characteristics of decentralization, immutability, and self-organization are primarily owing to the unique decentralized consensus mechanisms introduced by blockchain networks. This survey is motivated by the lack of a comprehensive literature review on the development of decentralized consensus mechanisms in blockchain networks. In this paper, we provide a systematic vision of the organization of blockchain networks. By emphasizing the unique characteristics of decentralized consensus in blockchain networks, our in-depth review of the state-of-the-art consensus protocols is focused on both the perspective of distributed consensus system design and the perspective of incentive mechanism design. From a game-theoretic point of view, we also provide a thorough review of the strategy adopted for self-organization by the individual nodes in the blockchain backbone networks. Consequently, we provide a comprehensive survey of the emerging applications of blockchain networks in a broad area of telecommunication. We highlight our special interest in how the consensus mechanisms impact these applications. Finally, we discuss several open issues in the protocol design for blockchain consensus and the related potential research directions.
Article
Full-text available
One of the most challenging aspects in computer-supported voting is to combine the apparently conflicting requirements of privacy and verifiability. On the one hand, privacy requires that a vote cannot be traced back from the result to a voter, while on the other hand, verifiability states that a voter can trace the effect of her vote on the result. This can be addressed using various privacy-enabling cryptographic primitives which also offer verifiability. As more and more refined voting systems were proposed, understanding of first privacy and later verifiability in voting increased, and notions of privacy as well as notions of verifiability in voting became increasingly more refined. This has culminated in a variety of verifiable systems that use cryptographic primitives to ensure specific kinds of privacy. However, the corresponding privacy and verifiability claims are not often verified independently. When they are investigated, claims have been invalidated sufficiently often to warrant a cautious approach to them. The multitude of notions, primitives and proposed solutions that claim to achieve both privacy and verifiability form an interesting but complex landscape. The purpose of this paper is to survey this landscape by providing an overview of the methods, developments and current trends regarding privacy and verifiability in voting systems.
Chapter
Der Einsatz elektronischer Wahlsysteme oder E-Voting-Systeme bei politischen Abstimmungen oder Wahlen wird sowohl unter Fachleuten wie auch unter Bürgerinnen und Bürger kontrovers diskutiert. Die einen sehen E-Voting-Systeme als eine natürliche Weiterentwicklung verbreiterter Dienste wie E-Shopping oder E-Banking, während bei den anderen die möglichen Gefahren oder gar die Gefährdung der Demokratie im Vordergrund stehen. Aufbauend auf allgemeinen Anforderungen und entsprechenden Herausforderungen bei der Umsetzung werden im Folgenden generelle vertrauensbildende Massnahmen für den Einsatz von E-Voting-Systemen dargestellt. Kryptografische Verfahren und Bausteine für E-Voting-Systeme werden beschrieben. Sie ermöglichen gewisse widersprüchliche Anforderungen aufzulösen, wie zum Beispiel die Wahrung des Stimm- und Wahlgeheimisses in Verbindung mit der individuellen und universellen Verifikation. Zwei Synthesen dieser Bausteine bilden den Schluss dieses Beitrags: Ein E-Voting-System mit postalischer Zustellung des Stimmrechtsausweises sowie ein medienbruchfreies E-Voting-System, welches vollständig über das Internet funktioniert.
Chapter
In this contribution we structure the use of new voting technologies in elections in the Northern hemisphere in three areas—first which and how technology can be used, and second which motivational factors can be accounted for their use.