A UC-Secure Protocol for Privacy-Preserving Preferential Voting with Verifiable Encrypted Ballots

Abstract

Preferential voting allows participants to rank multiple alternatives according to their preferences rather than being restricted to selecting a single option. Such mechanisms are used in national and local elections and, in decentralized governance, can be applied to committee selection, the prioritization of protocol upgrades or funding applications, and the choice of an electricity supplier or energy source. Of particular practical interest are systems in which participants have different stakes and their voting weights are proportional to those stakes. In the model considered in this work, each voter submits a complete ranking of the alternatives. The key technical challenge is to verify that an encrypted ballot encodes a valid ranking, that is, that exactly one rank is assigned to each alternative and each rank is used exactly once, without revealing the voter’s preferences. We propose a UC-secure protocol for privacy-preserving preferential voting with verifiable encrypted ballots. A ranking is represented as a permutation matrix whose entries are encrypted using an additively homomorphic cryptosystem. To verify ballot validity, each encrypted row of the matrix is accompanied by a non-interactive zero-knowledge proof that it is a unit vector. The encrypted rows are then homomorphically summed, and the resulting vector is checked against the all-ones vector. Together, these checks ensure that the encrypted matrix is a permutation matrix without revealing the ranking itself. Using an $O(logm)$-size unit-vector proof for each of the m rows yields $O(mlogm)$ ballot-validity proof data, while the overall ballot size remains $O\left(m^2\right)$ because the encrypted matrix contains $m^2$ ciphertexts. The protocol supports stake-weighted tallying and threshold decryption, so that only the final aggregate result is revealed. The UC security of the protocol is established in the random-oracle model under the Decisional Diffie–Hellman (DDH) assumption. The theoretical analysis shows that the computational complexity of generating and verifying a single ballot is $O\left(m^2\right)$ and that the ballot size is also $O\left(m^2\right)$, where m is the number of alternatives. The experimental results are consistent with this quadratic scaling: for 32 alternatives, the mean ballot-generation time is 87 ms, the mean verification time is 36 ms, and the reported cryptographic ballot payload is 106 KiB. These measurements indicate practical ballot-construction and verification costs for elections with a moderate number of alternatives.

1. Introduction

Decentralized decision-making is an important mechanism in distributed governance settings, where participants collectively influence the selection of proposals, policies, representatives, or development priorities. Such mechanisms are widely used in blockchain ecosystems, including platforms such as MakerDAO, Cardano, Aragon, and Gitcoin, but are also relevant to other organizational and electronic voting environments. While many existing voting protocols support simple “yes/no” or single-choice decisions, they often fail to capture the nuanced preferences of participants when several competing alternatives must be compared.

Preferential voting systems, in which voters rank candidates or options in order of preference, offer a more expressive and sophisticated method for collective decision-making. One practical limitation of such systems is their inconvenience when the number of candidates is large, and each voter has clear preferences for only a few of them (or, conversely, strong aversions), while remaining indifferent to the rest. In this case, the voter may assign arbitrary middle-range ranks to all indifferent candidates; such an arbitrary completion may reduce the interpretability of the submitted ranking. Therefore, preferential voting is most appropriate when, first, the number of candidates (alternatives) is relatively small, and second, voters have a well defined understanding of their preferences.

Preferential voting systems are widely used in national and local elections (e.g., in Australia, Ireland, and various municipal elections in the US), as they can produce outcomes that better reflect the collective will of the electorate [1,2], for example by electing a Condorcet winner [3]. A Condorcet winner is an alternative that defeats every other alternative in a pairwise majority comparison.

However, the experimental evaluation in this work is focused on scenarios with a moderate number of alternatives and is not intended to demonstrate scalability to a nationwide election process.

In blockchain governance, preferential voting can be applied to committee selection, prioritization of protocol upgrades, or choosing among multiple grant applicants.

A further application domain is decentralized electricity markets and energy communities. In addition to executing energy trades, their participants may need to rank potential suppliers, local generation or storage projects, demand-response programs, or proposals concerning market rules. Individual rankings may reveal commercially sensitive interests and strategies. If voting weights are determined by publicly verifiable participation shares then the proposed protocol can compute a stake-weighted aggregate ranking without disclosing individual preferences.

Implementing complete preferential voting in a distributed and publicly auditable environment creates a specific cryptographic challenge. Each voter’s ranking must remain confidential, while any observer must be able to verify that the encrypted ballot assigns exactly one rank to every alternative and uses every rank exactly once. When voters have different publicly verifiable stakes, the tally must also incorporate the corresponding weights without opening individual ballots and must reveal only the aggregate result.

Existing protocols address only parts of this problem. Some preferential-voting systems reveal anonymous individual rankings during tallying, while others verify a different ballot-validity relation, such as an arbitrary allocation of a fixed point budget. AranVoting represents a ranking by an encrypted permutation matrix and uses cell-level validity proofs, but it does not provide a Universal Composability (UC) formalization. Conversely, existing UC-secure voting protocols do not support publicly verifiable encrypted complete rankings together with stake-weighted tallying and threshold opening of only the aggregate result.

This leads to the main research question of this work: How can a privacy-preserving protocol for complete preferential ballots publicly verify that an encrypted ballot is a permutation, support stake-weighted aggregation and threshold opening of only the final tally, and provide a security proof in the universal composability framework?

1.1. Our Contributions

This paper presents a UC-secure protocol for privacy-preserving preferential voting in a decentralized ledger setting. It requires a public append-only bulletin board for publishing election parameters, encrypted ballots, validity proofs, and the final tally. Such a bulletin board can be implemented using a blockchain or another publicly auditable append-only system. However, the security analysis of the protocol does not rely on the details of a specific chain, consensus mechanism, or smart-contract platform.

Our construction combines additively homomorphic encryption with non-interactive zero-knowledge (NIZK)-based ballot validation: encrypted ranked ballots remain private, while their correctness can be publicly verified. The main contributions are summarized below:

–

Contribution 1. We construct a privacy-preserving preferential-voting protocol in which a complete ranking is represented by an encrypted permutation matrix. To validate the ballot without revealing the ranking, the $O(logm)$-size NIZK unit-vector proof of Zhang et al. [4] is applied to each row, while the uniqueness of the ranks is verified by a joint homomorphic check of the column sums. For an $m\times m$ matrix, the total size of the ballot-validity proofs in our protocol is $O(mlogm)$, whereas AranVoting uses $O\left(m^2\right)$ validity proofs for individual entries of the encrypted matrix. The overall ballot size remains $O\left(m^2\right)$ because the encrypted matrix contains $m^2$ ciphertexts.

–

Contribution 2. The validation mechanism is integrated with stake-weighted tallying, in which each ballot is weighted proportionally to the voter’s stake. The resulting ordering of the alternatives is equivalent to that produced by the Borda rule up to an additive constant common to all alternatives. A threshold trustee committee decrypts only the homomorphically computed aggregate result; individual rankings remain encrypted after tallying.

–

Contribution 3. We formalize the protocol through the ideal functionality ${\mathcal{F}}_{\mathrm{Vote}}^{t,u,m,n}$ and prove its security in the universal composability framework in the random-oracle model under the Decisional Diffie–Hellman assumption. The theorem considers a static probabilistic polynomial-time adversary that may corrupt any number of voters and at most $u-t$ trustees, where $u/2<t\le u$. Following successful distributed key generation, at least t honest and active trustees can complete threshold decryption and publish the result without the participation of corrupted trustees.

–

Contribution 4. We evaluated the core encrypted-ballot processing algorithms using a Rust prototype. The benchmark results reported in Section 5 show that the measured ballot-generation time, complete ballot-verification time, and cryptographic ballot payload were consistent with the theoretical $O\left(m^2\right)$ scaling as the number of alternatives grew. The evaluation indicates practical per-ballot processing costs for elections with a moderate number of alternatives.

1.2. Related Work

Existing preferential-voting protocols that use cryptographic mechanisms differ in how they represent a complete ranking, verify the validity of an encrypted ballot, tally the votes, and disclose the result. We therefore focus on the works that are closest to our protocol with respect to ballot representation, privacy, public verifiability, stake-dependent voting weights, and UC security.

One of the earliest works to consider the use of cryptographic mechanisms in a preferential-voting protocol is the study by Aditya et al. [5]. The authors considered two approaches to preserving the confidentiality of preferential ballots: one based on homomorphic encryption and one based on a mix-net. The former requires all possible complete rankings to be taken into account; because their number is factorial in the number of candidates, this approach is suitable only for elections with a small candidate set. In the mix-net approach, the link between a voter and the corresponding ballot is hidden, but the content of every ballot is nevertheless decrypted after mixing. Thus, all ballots become visible, although it is not possible to determine which voter submitted which ballot. Ballot secrecy in this approach therefore relies on anonymization, whereas the individual rankings themselves are disclosed during tallying. In our protocol, individual rankings remain encrypted and only the aggregate result is decrypted. Moreover, in their proposed form, the schemes of Aditya et al. do not provide public zero-knowledge verification that an encrypted ballot encodes a valid ranking, do not support different voting weights proportional to the voters’ stakes, and are not analyzed in the universal composability framework.

Yang et al. [6] proposed an online voting system based on lifted ElGamal encryption. Although the title uses the term ranked-choice voting, a ballot specifies an allocation of a predetermined number of points among the candidates and permits equal scores for different candidates as well as the allocation of all points to a single candidate. The ballot is represented as a binary matrix whose entries are encrypted separately. Zero-knowledge proofs are used to show that every ciphertext encrypts a bit and that the sum of the points allocated by a voter equals a value P fixed by the election organizers and common to all voters. Individual stake weights are not considered, although public stake weights could be incorporated at the homomorphic tallying stage. The principal difference from our protocol lies in the ballot-validity predicate: the scheme of Yang et al. permits an arbitrary allocation of the fixed point budget, whereas our protocol requires the ballot to encode a complete permutation of the ranks, in which each alternative receives exactly one rank and every rank is used exactly once. The system of Yang et al. also has no UC formalization.

In ElectAnon [7], each possible complete ranking is mapped to a single integer, and a ballot contains only the index of the selected permutation. The number of possible indices is factorial in the number of candidates, but a particular ballot stores only one integer. The protocol follows a commit-reveal scheme: in the first stage, a voter publishes a commitment to the encoded ranking; in the second stage, the voter reveals the numerical ranking code and the secret value from which the smart contract verifies the commitment. Ballot validity is checked by testing whether the numerical code belongs to the admissible interval. Semaphore, together with a zk-SNARK proof, is used for anonymous eligibility verification and prevention of double voting rather than for verifying a hidden permutation. ElectAnon supports, among others, the Borda and Tideman rules. However, after the reveal stage all individual ballots become publicly available in plaintext, although they remain anonymous. By contrast, our protocol keeps individual rankings encrypted, homomorphically computes a stake-weighted tally, and reveals only the aggregate result.

Xia et al. [8] proposed AranVoting, a blockchain-based preferential-voting protocol under the Borda rule in which a ranking is represented as a permutation matrix. Ballot privacy is provided by homomorphic encryption, while zero-knowledge proofs are used to establish the bitness of the encrypted entries and the row and column conditions required for a permutation matrix. The authors also address tally availability and transparency by means of a smart contract, a committee-formation algorithm, and an incentive mechanism.

Let m denote the number of candidates. An AranVoting ballot contains $m^2$ matrix entries that are encrypted separately. The construction establishes the bitness condition for each encrypted entry, while the row and column sums are additionally checked. Consequently, the number of ciphertexts and the number of cell-level validity-proof components in AranVoting are both $O\left(m^2\right)$; accordingly, the construction and validation of a single AranVoting ballot have quadratic complexity $O\left(m^2\right)$ with respect to the number of candidates. In our protocol, the $O(logm)$-size NIZK unit-vector proof introduced by Zhang et al. [4] is applied to each of the m rows. The column condition is verified homomorphically after publication of a length-m vector containing the sums of the encryption randomnesses, without separate zero-knowledge proofs for the columns. Hence, the total size of the ballot-validity proof data in our protocol is $O(mlogm)$, which is asymptotically smaller than the $O\left(m^2\right)$ cell-by-cell proof component in AranVoting. This reduction does not make the overall ballot size subquadratic: in both protocols, the encrypted permutation matrix contains $m^2$ ciphertexts, so the total ballot size remains $O\left(m^2\right)$.

Compared with AranVoting [8], the proposed protocol has three principal differences. First, to verify the correctness of the encrypted permutation matrix, our protocol uses m NIZK unit-vector proofs with total size $O(mlogm)$, whereas AranVoting uses $O\left(m^2\right)$ validity proofs for individual entries of the matrix. This reduces the amount of data associated with validity proofs, but it does not reduce the asymptotic size of the whole ballot: both protocols transmit $m^2$ ciphertexts, so the total ballot size, as well as the complexity of ballot generation and verification, remains $O\left(m^2\right)$. Second, we provide a formal UC model for the proposed protocol: we define the ideal functionality and adversarial model and prove UC security of the protocol; no such UC formalization is provided for AranVoting. Third, our protocol supports voting in which a voter’s weight is proportional to the voter’s publicly known stake. In addition, individual voter rankings remain confidential even after the final voting result has been computed .

Zhang et al. [4] proposed a UC-secure voting protocol for collective decisions on funding project proposals from a common fund of a cryptocurrency system. A voter’s weight is determined by the voter’s stake, and the voter may choose yes, no, or abstain, or delegate the vote to an expert. The work introduced a NIZK unit-vector proof showing that an encrypted vector is binary and contains exactly one entry equal to 1. For a vector of length m, the proof size is $O(logm)$. The protocol of Zhang et al. does not implement preferential voting and does not rank candidates. In our protocol, their unit-vector proof is applied to every row of the encrypted permutation matrix and is combined with a homomorphic check that every rank is used exactly once.

A complementary line of our previous work concerns stake-dependent quadratic voting. Kovalchuk et al. [9] analyzed several models of quadratic voting and its generalizations, including models in which a voter’s stake is split among selected alternatives. Kovalchuk et al. [10] subsequently proposed a UC-secure on-chain quadratic-voting protocol with liquid democracy, in which voting power defined as the square root of the stake can be distributed among selected proposals or delegated to representatives. That protocol formalizes stake-dependent voting and delegation in the UC framework, but its ballot specifies an allocation of voting power rather than a complete ordering of all alternatives. The present work addresses a different validity relation: every ballot must encode a full ranking as a permutation, and its contribution to the aggregate result is weighted proportionally to the voter’s stake.

E-cclesia [11] is a UC-secure self-tallying voting protocol in which voters anonymously publish ballots encrypted using time-lock encryption. After the voting phase, every ballot is decrypted, and the resulting value is tested for membership in a predefined set O of admissible options; values outside O are discarded. The result can then be computed from the published data without a separate tallying committee. E-cclesia therefore does not need to verify the hidden structure of a ballot: admissibility is checked after its content has been revealed. For complete preferential voting, the set O would have to contain all admissible permutations. If O is represented by an explicit list, its size is $m!$, whereas representing it by a polynomial-time validity predicate is not formalized in that work. In our protocol, individual rankings are not revealed even after tallying. Ballot validity is verified without decrypting the ballot, and a trustee committee decrypts only the stake-weighted aggregate result.

Privacy-preserving protocols for peer-to-peer electricity trading and energy auctions address a related but different class of problems. These protocols primarily protect numerical bids, prices, and quantities while computing matching, allocation, or clearing results [12,13,14]. In decentralized electricity markets and energy communities, however, participants may also need to rank suppliers, local generation or storage projects, demand-response programs, or proposals concerning market rules. Such rankings may reveal commercially sensitive preferences and strategies. When voting rights are determined by a publicly verifiable participation share, our protocol can be used at this governance layer to compute a stake-weighted aggregate ranking without disclosing individual preferences. It does not replace an auction protocol or implement bid matching and market clearing.

The choice of protocol depends on the requirements of the application. If disclosure of individual ballots after the voting phase is acceptable, then mix-net or commit–reveal approaches such as those of Aditya et al. [5] or ElectAnon [7] may be suitable. If the task is to allocate a fixed number of points rather than to submit a complete ranking then the approach of Yang et al. [6] is more natural. If self-tallying without a separate trustee committee is required and disclosure of ballots after voting is acceptable then E-cclesia [11] is an appropriate approach. The protocol of Zhang et al. [4] is designed for stake-weighted collective decisions with yes/no/abstain choices or delegation, rather than for a complete preferential ranking of alternatives. The protocol proposed in this work is intended for applications that simultaneously require a complete ranking of alternatives, public verification of the correctness of an encrypted ballot, voting weights proportional to public stakes, confidentiality of individual ballots even after the final result has been computed, and formal UC security guarantees.

Taken together, the existing preferential-voting protocols either disclose anonymous individual rankings during tallying or do not formalize the combined privacy and verifiability guarantees in the UC framework. Conversely, the existing UC-secure voting protocols do not simultaneously address a complete encrypted ranking, public verification of its permutation structure, voting weights proportional to stakes, threshold opening of only the aggregate result, and the corresponding adversarial model. To the best of our knowledge, this combination of properties has not been considered in previous work. Our protocol closes this gap through the ideal functionality ${\mathcal{F}}_{\mathrm{Vote}}^{t,u,m,n}$, a publicly verifiable encrypted-permutation ballot, $O(mlogm)$ ballot-validity proof data, stake-weighted tallying, and threshold decryption of only the aggregate result.

2. Preliminaries

This section introduces the notation, cryptographic building blocks, and the Universal Composability framework used in the construction and security analysis of the proposed protocol.

2.1. Notation and Terminology

Table 1 summarizes the main abbreviations and notation used throughout the paper.

Table 1. Main abbreviations and notation.

Abbreviation/Notation	Meaning
BB	Balloting Board; public append-only bulletin board.
NIZK	Non-Interactive Zero-Knowledge proof/argument.
UC	Universal Composability framework.
DDH	Decisional Diffie–Hellman assumption.
DKG	Distributed Key Generation.
PPT	Probabilistic Polynomial Time.
CRS	Common Reference String; for the unit-vector NIZK, the commitment key $\mathsf{ck}$ serves as the CRS.
RO	Random Oracle/random-oracle model.
n	Number of voters.
m	Number of alternatives.
u	Total number of trustees.
t	Threshold number of trustees sufficient for threshold decryption; $u/2<t\le u$.
$V^{\left(i\right)}$	The i-th voter.
$T^{\left(j\right)}$	The j-th trustee.
$s^{\left(i\right)}$	Publicly registered stake (voting weight) of voter $V^{\left(i\right)}$.
$S_{max}$	Public upper bound on the total stake included in the tally.
$M=m{S}_{max}$	Upper bound on a plaintext tally component used for bounded-DLP recovery.
$\mathsf{pk}$	Public encryption key used for the election.
${\mathsf{sk}}_j$	Secret-key share of trustee $T^{\left(j\right)}$.
$\mathsf{ck}$	Commitment key; used as the CRS for the unit-vector NIZK.
$B_{\mathrm{final}}$	Final set of valid ballots included in the tally.
${\mathcal{F}}_{\mathrm{Vote}}^{t,u,m,n}$	Ideal voting functionality.
${\mathcal{F}}_{\mathrm{BLOCKCHAIN}}$	Ideal functionality providing the public append-only bulletin board.
${\mathcal{F}}_{\mathrm{DKG}}^{t,u}$	Ideal threshold distributed-key-generation functionality.
$\tau$	Aggregate tally vector.

The security level is parameterized by $\lambda \in \mathbb{N}$. Given $1^{\lambda }$, the algorithm ${\mathsf{Gen}}^{\mathsf{G}}$ produces a description $\mathsf{param}$ of the algebraic setting used by the protocol. In particular, $\mathsf{param}$ specifies a prime-order cyclic multiplicative group $\mathbb{G}$, its order q, and a generator g, with $\left|q\right|=\lambda$. Unless stated otherwise, all group operations were performed in $\mathbb{G}$. The security analysis relied on the hardness of the Decisional Diffie–Hellman (DDH) problem for this group [15]. Informally, the DDH assumption states that, in an appropriate cyclic group, no efficient algorithm can distinguish a Diffie–Hellman tuple from a random tuple with non-negligible advantage. We use PPT as an abbreviation for probabilistic polynomial time.

We use the notation $[a,b]$ to represent the set $\{a,a+1,\dots ,b\}$, and write $\left[b\right]$ as a shorthand for $[1,b]$. For a finite set S, the expression $s\leftarrow S$ denotes uniform random sampling of s from S. A vector $(a_1,\dots ,a_{\mathsf{\ell }})$ is denoted by $\mathit{a}$, where the dimension is specified explicitly whenever it is not clear from the context. A negligible function is written as $\mathsf{negl}(·)$, while $poly(·)$ denotes a function bounded by a polynomial.

2.2. Additively Homomorphic Encryption

A homomorphic encryption scheme allows specified operations to be performed on ciphertexts so that, after decryption, the result corresponds to applying the associated operations to the plaintexts.

We rely on the Lifted ElGamal scheme [16] as the encryption layer of the protocol. This scheme is a variant of ElGamal encryption in which messages are embedded in the exponent, allowing ciphertexts to be combined so that the underlying plaintexts are added. Let $\mathsf{param}\leftarrow {\mathsf{Gen}}^{\mathsf{G}}\left(1^{\lambda }\right)$ denote the group parameters used throughout the construction. The encryption scheme is defined as follows:

–

${\mathsf{Gen}}^{\mathsf{E}}\left(\mathsf{param}\right)$: sample $\mathsf{sk}\leftarrow {\mathbb{Z}}_q^{*}$, then compute $\mathsf{pk}:=g^{\mathsf{sk}}$, and return $(\mathsf{pk},\mathsf{sk})$.

–

${\mathsf{Enc}}_{\mathsf{pk}}(m,r)$: compute and return $c:=(c_1,c_2)=(g^r,g^m·{\mathsf{pk}}^r)$.

–

$\mathsf{Mul}(c^{\left(1\right)},\dots ,c^{(\mathsf{\ell })})$: compute and return $c:=({\prod }_{i=1}^{\mathsf{\ell }}{c}_1^{\left(i\right)},{\prod }_{i=1}^{\mathsf{\ell }}{c}_2^{\left(i\right)})$.

–

$\mathsf{Exp}(c,n)$: compute and return $c^n:=(c_1^n,c_2^n)$.

–

${\mathsf{Dec}}_{\mathsf{sk}}\left(c\right)$: compute and return $\mathsf{Dlog}(c_2·c_1^{-\mathsf{sk}})$, where $\mathsf{Dlog}\left(x\right)$ denotes the discrete logarithm of x in the chosen group.

Stake amounts are encoded as non-negative integers using an application-defined unit. Let $S={\sum }_i{s}^{\left(i\right)}$ denote the total stake of the voters whose ballots are included in the tally, and let $S_{max}$ be a public upper bound on this value. Because each rank belongs to $[1,m]$, the final weighted score of every alternative is at most $mS\le m{S}_{max}$. The group parameters are chosen so that $m{S}_{max}<q$. Hence, although Lifted ElGamal decryption requires computing a discrete logarithm in a group of order q, the exponent to be recovered is known a priori to lie in the bounded interval $[0,m{S}_{max}]$ .

• Illustrative parameter estimate (Cardano). To illustrate the practical size of this interval for a real-world deployment, consider Cardano as an example and use ADA as the stake unit for this estimate. Recent Cardano epoch data report an active stake of approximately $21.42\times {10}^9$ ADA [17]. We therefore take $S_{max}=22\times {10}^9$ ADA as a conservative upper bound. This gives $M=m{S}_{max}=3.52\times {10}^{11}$ for $m=16$ and $M=7.04\times {10}^{11}$ for $m=32$. In our implementation, bounded-DLP recovery used the baby-step giant-step algorithm with a pre-computed baby-step table. For these two bounds, the one-time pre-computation took 5.85 s and 8.80 s, respectively, while the mean worst-case recovery time for a single plaintext value was 1.47 s and 2.11 s. For $M=7.04\times {10}^{11}$, recovery of the complete 32-component tally vector took 9.63 s on average after pre-computation using eight Rayon worker threads; the peak resident memory of the benchmark process was approximately 148 MiB. These measurements show that decryption remains feasible for the considered plaintext ranges.

Whenever the algorithms $\{{\mathsf{Enc}}_{\mathsf{pk}}(·),{\mathsf{Dec}}_{\mathsf{sk}}(·),\mathsf{Mul}(·),\mathsf{Exp}(·)\}$ are applied to vector-valued inputs, the operations are understood to be performed in a component-wise manner. Specifically, for vectors $\mathit{m}=(m_1,\dots ,m_{\mathsf{\ell }})$ and $\mathit{r}=(r_1,\dots ,r_{\mathsf{\ell }})$, we define:

$${\mathsf{Enc}}_{\mathsf{pk}}(\mathbf{m},\mathbf{r}):=\left({\mathsf{Enc}}_{\mathsf{pk}}(m_1,r_1),\dots ,{\mathsf{Enc}}_{\mathsf{pk}}(m_{\mathsf{\ell }},r_{\mathsf{\ell }})\right).$$

The Lifted ElGamal cryptosystem supports threshold encryption and achieves IND-CPA security under the DDH assumption [18]. Its additive homomorphic property is expressed as

$${\mathsf{Enc}}_{\mathsf{pk}}(m_1,r_1)·{\mathsf{Enc}}_{\mathsf{pk}}(m_2,r_2)={\mathsf{Enc}}_{\mathsf{pk}}(m_1+m_2,r_1+r_2).$$

The proposed protocol specifically requires additively homomorphic encryption, because tally aggregation performs two operations on encrypted data: addition of values and multiplication by known public coefficients. Unlike standard ElGamal, which is multiplicatively homomorphic with respect to plaintext group elements, a Lifted ElGamal ciphertext contains the group element $g^m$, where m is the plaintext. As a result, ciphertext multiplication corresponds to addition of plaintexts. Moreover, the $\Sigma$-protocols/NIZKs used in our protocol are constructed directly for Lifted ElGamal ciphertexts; this cryptosystem also supports joint decryption. Other additively homomorphic cryptosystems, such as Paillier, could also be used in a similar construction, but the validity-proof and joint-decryption mechanisms used in the present protocol would have to be replaced by mechanisms compatible with the selected cryptosystem.

2.3. Zero Knowledge Proofs/Arguments

In our construction, we use the non-interactive unit vector argument of knowledge ${\mathsf{NIZK}}_{UV}^{RO}$ from [4], obtained in the random oracle model [19]. For brevity, we omit the superscript $RO$ when the context is clear. The formal definitions of the zero-knowledge proof/argument notions used in the protocol are provided in Supplementary Materials, Section S1.

2.4. Universal Composability

We use the Universal Composability (UC) framework [20] to state the security goal for the proposed protocol. In the UC setting, security is formulated by comparing two experiments. In the real experiment, the parties executed the protocol $\Pi$ in the presence of an adversary $\mathcal{A}$. In the ideal experiment, the same task was carried out by an ideal functionality $\mathcal{F}$, while a simulator $\mathcal{S}$ emulated the adversarial behavior visible to the environment $\mathcal{Z}$. A protocol is considered secure if every efficient real-world attack can be reproduced in the ideal world without allowing $\mathcal{Z}$ to tell which experiment it is observing.

The ideal functionality serves as a formal specification of the intended behavior of the protocol. It defines which inputs are accepted, which outputs are produced, which events are exposed to the adversary, and under which corruption conditions private information may be leaked. Thus, instead of reasoning directly about informal security properties, we prove that the real protocol execution is indistinguishable from an execution of this idealized specification.

Let ${\mathrm{EXEC}}_{\Pi ,\mathcal{A},\mathcal{Z}}$ denote the output of the environment in the real execution of protocol $\Pi$ with adversary $\mathcal{A}$. Let ${\mathrm{EXEC}}_{\mathcal{F},\mathcal{S},\mathcal{Z}}$ denote the corresponding output in the ideal execution with functionality $\mathcal{F}$ and simulator $\mathcal{S}$. In our model, protocol parties, the adversary, the simulator, and the environment are represented by interactive probabilistic polynomial-time machines. Each machine instance is indexed by a session identifier $sid$ and a party identifier $pid$. We consider a synchronous communication setting, static corruptions, and access to a random oracle.

To prove UC security, we construct a PPT simulator $\mathcal{S}$ such that for every PPT adversary $\mathcal{A}$ and every PPT environment $\mathcal{Z}$, the two executions are computationally indistinguishable:

$${\mathrm{EXEC}}_{\Pi ,\mathcal{A},\mathcal{Z}}\approx {\mathrm{EXEC}}_{\mathcal{F},\mathcal{S},\mathcal{Z}}.$$

3. System and Threat Model

This section describes the participants in the voting system, their roles, the threshold assumption, and the adversarial model.

3.1. Participants, External Environment, and Threshold Assumption

The proposed voting protocol involves two types of protocol parties: a voting committee of u trustees, denoted by $\mathrm{T}=\{T^{\left(1\right)},\dots ,T^{\left(u\right)}\}$, and a set of n voters $\mathrm{V}=\{V^{\left(1\right)},\dots ,V^{\left(n\right)}\}$. In addition, we consider a set of m available alternatives $\mathrm{A}=\{A^{\left(1\right)},\dots ,A^{\left(m\right)}\}$ over which the election is conducted.

Each voter forms a complete ranking of the alternatives, encrypts the corresponding ballot, generates the proofs required to verify its validity, and publishes the encrypted ballot together with these proofs on the balloting board, denoted by BB. In the formal UC model, BB is represented by the ideal functionality ${\mathcal{F}}_{\mathrm{BLOCKCHAIN}}$, which is used only through its public append-only bulletin-board interface; see Section 4.2. The trustees jointly generate the public encryption key; after the voting phase has ended, they homomorphically aggregate the valid encrypted ballots and participate in the threshold decryption of the final aggregate tally. The published ballots and their validity proofs are publicly verifiable.

Before voting begins, a public association is established for each voter $V^{\left(i\right)}$ between the voter’s public key ${\mathsf{pk}}_V^{\left(i\right)}$ and stake $s^{\left(i\right)}$. When a ballot is published, BB records the public key of the party that submitted it, so each ballot is unambiguously associated with the corresponding stake. Until the voting phase ends, a voter may publish a new ballot. In this case, the previous ballot remains in the history of BB but ceases to be active. For each registered public key, $B_{\mathrm{final}}$ contains only the most recent ballot published before the end of the voting phase that passes $\mathsf{VerifyBallot}$. Registration of the public keys and assignment of the corresponding stakes belong to the application layer and are not part of the cryptographic voting protocol.

The voting weight is not specified by the voter in the ballot. The stake value $s^{\left(i\right)}$ of voter $V^{\left(i\right)}$ is a public parameter that is associated in advance with that voter’s registered public key. During tallying, the components of the encrypted ballot are raised to the power $s^{\left(i\right)}$, which homomorphically multiplies the corresponding entries of the encrypted permutation matrix by $s^{\left(i\right)}$; consequently, when the scores are computed, rank j is counted with multiplier $s^{\left(i\right)}$, that is, as $j{s}^{\left(i\right)}$. Therefore, a voter cannot change the weight of its vote by specifying a different value of $s^{\left(i\right)}$. The correctness of the ballot itself is established by cryptographic mechanisms, including the zero-knowledge proofs applied to the encrypted ballot, whereas the correctness of the association between the voting weight and the corresponding public key is provided by the public registration association between the voter’s key and stake.

Voters may submit their ballots until the formally defined end of the voting phase. This point is determined by a public condition specified in the election parameters; for example, it may be a block number, a predetermined time, or another condition whose satisfaction can be readily verified by all participants in the election. The specific form of this condition belongs to the application layer and is not part of the cryptographic protocol.

In the formal model, satisfaction of this condition is represented by a message (CloseVoting, sid), which the environment $\mathcal{Z}$, whose role in the definition of UC security is described in Section 2.3, sends to the trustees. Upon receiving this message, each trustee $T^{\left(i\right)}$ is required to publish the record (CloseVoting, sid, $T^{\left(i\right)})$ on BB. Once such records have been published by at least t distinct trustees, the Voting phase is considered completed and the protocol transitions to the Tally phase. For each registered voter public key, only the most recent ballot published before the appearance on BB of the t-th CloseVoting record submitted by a distinct trustee and passing $\mathsf{VerifyBallot}$ is aggregated.

The environment $\mathcal{Z}$ is neither a voting participant nor a trusted party of the protocol. It provides external inputs and activates the corresponding protocol parties. In particular, $\mathcal{Z}$ sends (Init, sid) to the trustees and (Cast, sid, $v^{\left(i\right)},s^{\left(i\right)})$ to the voters. After the protocol has transitioned to the Tally phase, the environment may activate the trustees by sending (Tally, sid) and may send (ReadTally, sid) to any party to obtain the published result. The environment does not form or verify encrypted ballots, hold secret-key shares, or participate in computing the voting result.

The public key used to encrypt the ballots is generated by the committee through the distributed key generation functionality ${\mathcal{F}}_{\mathrm{DKG}}^{t,u}$. Distributed Key Generation (DKG) is a procedure in which several trustees jointly establish a public key and secret-key shares without requiring any single trustee to learn the complete secret key. The corresponding secret key is not held by any individual trustee; instead, it is distributed among the u trustees according to a $(t,u)$-threshold scheme. Decryption requires the participation of at least t trustees, where

$$u/2<t\le u.$$

Let ${\mathrm{T}}_{\mathrm{honest}}$ and ${\mathrm{T}}_{\mathrm{corr}}$ denote the sets of honest and corrupted trustees, respectively. We assume that, following the successful completion of distributed key generation, at least t trustees remain honest and active:

$$|{\mathrm{T}}_{\mathrm{honest}}|\ge t.$$

Since

$$|{\mathrm{T}}_{\mathrm{honest}}|+|{\mathrm{T}}_{\mathrm{corr}}|=u\mathrm{and}t>u/2,$$

it follows that

$$|{\mathrm{T}}_{\mathrm{corr}}|\le u-t<t.$$

Consequently, the corrupted trustees cannot decrypt individual ballots or the aggregate tally on their own. At the same time, the number of honest trustees is sufficient to decrypt the final tally without the participation of corrupted committee members.

The claim that the tally can be completed is conditional on the successful completion of distributed key generation. Honest trustees begin generating decryption shares only after CloseVoting records have been published on BB by at least t distinct trustees and the protocol has transitioned to the Tally phase. We also assume that messages sent by honest trustees during the tally phase eventually become available to all parties.

3.2. Adversarial Model

We make the following assumptions about the adversary and its capabilities:

–

the adversary observes all messages and data published on the public bulletin board;

–

the adversary is static and probabilistic polynomial-time;

–

the adversary may corrupt an arbitrary number of voters and at most $u-t$ trustees;

–

the sets of corrupted parties are determined before the protocol execution begins and do not change during the execution;

–

the adversary fully controls the actions of corrupted parties and may coordinate their behavior.

Corrupted trustees may perform the following actions:

–

disclose their secret-key shares to the adversary;

–

deviate from the protocol, including refusing to generate and/or publish their decryption shares.

Corrupted voters may choose their own rankings arbitrarily, coordinate their votes, disclose their rankings, randomness, and other internal data to the adversary, abstain from voting, replace a previously submitted ballot before the voting phase ends, or attempt to submit malformed ballots. Only ballots that pass $\mathsf{VerifyBallot}$ are included in the tally. Thus, a corrupted voter may influence the result by submitting any valid ranking with its assigned voting weight, but cannot cause an invalid ballot to be included in the tally.

The privacy guarantee applies only to honest voters. Disclosure by a corrupted voter of its own ranking or the randomness used to generate its ballot is not considered a violation of ballot privacy. The model does not address vote buying, coercion, or a voter’s ability to prove to a third party how it voted. Accordingly, the protocol does not claim coercion resistance or receipt-freeness.

The adversary does not obtain direct access to the plaintext ballots of honest voters and cannot modify or delete records that have already been published on the bulletin board.

3.3. Security Properties and Scope of Fairness

Under our assumptions,

$$|{\mathrm{T}}_{\mathrm{corr}}|\le u-t<t,$$

and therefore the adversary does not possess enough secret-key shares to decrypt the ballots of honest voters or the aggregate tally before the tally phase begins. Hence, the proposed voting protocol provides a limited fairness property in the following sense: any intermediate aggregate tally—that is, a tally computed from an incomplete set of ballots—remains hidden until the Voting phase has ended and the protocol has transitioned to the Tally phase. This property prevents early information about an intermediate tally from influencing voters who have not yet cast their ballots.

After the Voting phase has ended and the protocol has transitioned to the Tally phase, however, an adversary controlling

$$c=|{\mathrm{T}}_{\mathrm{corr}}|$$

trustees may combine its own shares with the first $t-c$ shares produced by honest trustees and obtain the final tally before t honest decryption shares have been published and the tally has become publicly available. Therefore, the protocol does not provide strong fairness—that is, it does not guarantee that all parties obtain the aggregate tally simultaneously.

The absence of strong fairness means that, after the Voting phase has ended, some parties may obtain the final tally before it becomes publicly available, but only after voting has already closed. Therefore, this information cannot affect the submitted ballots, because ballots can no longer be changed after the end of the Voting phase. However, this property may be undesirable in applications in which even short-lived early access to the result can provide an economic or strategic advantage. Such applications require an additional simultaneous-release mechanism, which is outside the scope of this work.

The adversary also cannot prevent computation or publication of the aggregate tally by withholding the shares of corrupted trustees. Indeed, under our assumption,

$$|{\mathrm{T}}_{\mathrm{honest}}|\ge t,$$

and therefore t honest trustees can generate all decryption shares required for the threshold decryption of the aggregate tally without the participation of corrupted trustees.

The privacy guarantee for honest voters means that the protocol does not reveal information about their rankings beyond what can be inferred from the final aggregate tally and other public data. It does not prevent inferences that logically follow from the published tally together with votes voluntarily disclosed by corrupted voters.

4. The Proposed Voting Protocol

4.1. The Voting Scheme

The sets of voters, trustees, and alternatives are defined in Section 3.1.

For the purpose of formal description, we further introduce the following notation:

–

$s^{\left(i\right)}$ – the stake assigned to the i-th voter, where $i\in \left[n\right]$;

–

$\mathsf{pk}\in \mathbb{G}$ – the public encryption key used for ballot encryption, generated by the functionality ${\mathcal{F}}_{\mathrm{DKG}}^{t,u}$;

In our scheme for each voter $V^{\left(k\right)}$, their vote $v^{\left(k\right)}$ is represented by a permutation ${\sigma }^{\left(k\right)}:\left[m\right]\to \left[m\right]$—that is, a bijective mapping that encodes the alternatives ranking. The value ${\sigma }^{\left(k\right)}\left(j\right)$ corresponds to the rank assigned to alternative $A^{\left(j\right)}$: ${\sigma }^{\left(k\right)}\left(j\right)=m$ means that $A^{\left(j\right)}$ is the most preferred, while ${\sigma }^{\left(k\right)}\left(j\right)=1$ means that $A^{\left(j\right)}$ is the least preferred. Here, m denotes both the number of alternatives and, since we consider complete rankings, the number of available rank values. The rank domain is $\left[m\right]=\{1,\dots ,m\}$, with larger values representing stronger preference. Thus, rank m is assigned to the most preferred alternative, rank $m-1$ to the next one, and so forth, while rank 1 is assigned to the least preferred alternative. Since ${\sigma }^{\left(k\right)}$ is a permutation, every rank in $\left[m\right]$ is assigned exactly once. Equivalently, the vote of $V^{\left(k\right)}$ is:

$$v^{\left(k\right)}=(v_1^{\left(k\right)},\dots ,v_m^{\left(k\right)})=({\sigma }^{\left(k\right)}\left(1\right),\dots ,{\sigma }^{\left(k\right)}\left(m\right)).$$

To represent $v^{\left(k\right)}$ we use the corresponding permutation matrix $P^{\left(k\right)}$ of size $m\times m$ with entries in $\{0,1\}$, where each row and each column contains exactly one “1”:

$$P^{\left(k\right)}={\left(p_{ij}^{\left(k\right)}\right)}_{i,j=1}^m,p_{ij}^{\left(k\right)}\in \{0,1\}.$$

In this representation, the i-th row corresponds to the alternative $A^{\left(i\right)}$, and $p_{ij}^{\left(k\right)}=1$ indicates that the voter $V^{\left(k\right)}$ has assigned the rank j to the alternative $A^{\left(i\right)}$.

For example, let $m=4$ and suppose that a voter orders the alternatives as:

$$A^{\left(3\right)}\succ A^{\left(1\right)}\succ A^{\left(4\right)}\succ A^{\left(2\right)}.$$

According to the rank convention above, the corresponding vote vector is:

$$v=(3,1,4,2),$$

meaning that $A^{\left(1\right)}$ receives rank 3, $A^{\left(2\right)}$ rank 1, $A^{\left(3\right)}$ rank 4, and $A^{\left(4\right)}$ rank 2. The corresponding permutation matrix is:

$$P=\left(\begin{array}{cccc}0& 0& 1& 0\\ 1& 0& 0& 0\\ 0& 0& 0& 1\\ 0& 1& 0& 0\end{array}\right).$$

Each row contains exactly one nonzero entry because every alternative receives one rank, while each column contains exactly one nonzero entry because every rank is used once. In particular, the component-wise sum of the rows is:

$$(1,1,1,1).$$

The Borda count is a positional voting rule in which each rank is assigned a numerical score and the scores obtained by each alternative are summed over all ballots.

The same rank values are used as positional scores during tallying. Namely, we use the linear scoring rule: $score\left(j\right)=j$ for $j\in \left[m\right]$. Hence, for a voter with stake $s^{\left(k\right)}$, an alternative assigned rank j contributes $j·s^{\left(k\right)}$ to its aggregate score. The most preferred alternative therefore contributes $m·s^{\left(k\right)}$, whereas the least preferred one contributes $s^{\left(k\right)}$. This scoring convention differs from the standard Borda vector $(m-1,m-2,\dots ,0)$ only by an additive constant and therefore induces the same ordering of the alternatives.

The corresponding vote-encoding algorithm $\mathsf{Encode}$, shown in Figure 1, converts the voter’s rank assignment into the binary permutation-matrix representation described above. The resulting matrix serves as the plaintext representation of the ballot.

Figure 1. The encoding algorithm $\mathsf{Encode}$.

To preserve voter privacy, the permutation matrix is not published in plaintext. Instead, each of its rows is encrypted component-wise using Lifted ElGamal. Since the entries of the matrix are hidden, ballot validity must be established without revealing the underlying ranking. We achieve this using two complementary checks.

First, for every encrypted row ${\mathbf{w}}_i$, the voter provides a NIZK unit-vector proof ${\mathsf{NIZK}}_{UV}$. Successful verification proves, in zero knowledge, that the plaintext underlying this row is a vector in ${\{0,1\}}^m$ containing exactly one 1. Consequently, every alternative is assigned exactly one rank. This condition alone, however, does not prevent two different alternatives from receiving the same rank, because the unique 1 in two different rows could occur in the same column.

Second, we exploit the additive homomorphism of Lifted ElGamal to check the columns jointly. The encrypted rows are multiplied component-wise, producing an encryption of their component-wise plaintext sum. The voter provides the aggregate randomness ${\mathbf{r}}_{\mathrm{sum}}$ used in this encryption, so that the verifier can check that the resulting ciphertext vector equals ${\mathsf{Enc}}_{\mathsf{pk}}(\mathbf{1},{\mathbf{r}}_{\mathrm{sum}})$, where $\mathbf{1}=(1,\dots ,1)$. Since every row has already been proven to be a unit vector, this all-ones condition implies that every column contains exactly one 1. Thus, every alternative receives exactly one rank and every rank is used exactly once, which is precisely the definition of a permutation matrix.

The complete ballot-encryption procedure is given in Figure 2, while encrypted-ballot verification is described in Figure 3.

Figure 2. Ballot encryption algorithm.

Figure 3. Ballot verification algorithm.

The full description of the voting protocol ${\Pi }_{Vote}^{t,u,m,n}$ is presented in Figure 4. The protocol operates in the $\{{\mathcal{F}}_{\mathrm{BLOCKCHAIN}},{\mathcal{F}}_{\mathrm{DKG}}^{t,u}\}$-hybrid setting. The corresponding auxiliary functionalities are defined and discussed in the next subsection.

Figure 4. The voting protocol ${\Pi }_{Vote}^{t,u,m,n}$.

4.2. Security Modeling

We now formalize the security properties of the protocol described above within the UC framework. We first define the corresponding ideal voting functionality and then specify the auxiliary functionalities used in the real/hybrid execution.

Ideal world. In the ideal world execution, the election is carried out by the ideal functionality ${\mathcal{F}}_{\mathrm{Vote}}^{t,u,m,n}$. Trustees T and voters V submit their commands directly to this functionality, where $(t,u)$ defines the trustee threshold. Throughout the protocol execution, all commands issued by $\mathrm{T}$ and $\mathrm{V}$ are processed by ${\mathcal{F}}_{\mathrm{Vote}}^{t,u,m,n}$. External inputs are provided by the environment $\mathcal{Z}$ to the corresponding voters and trustees; in the ideal execution, their dummy parties forward these commands to ${\mathcal{F}}_{\mathrm{Vote}}^{t,u,m,n}$. The functionality also notifies the adversary about selected protocol events and may be influenced by the simulator $\mathcal{S}$ to trigger specific actions. The full description of ${\mathcal{F}}_{\mathrm{Vote}}^{t,u,m,n}$ is given in Figure 5. The functionality proceeds through three consecutive phases: Preparation, Voting, and Tally; the condition for the transition from Voting to Tally is specified below.

Figure 5. Ideal functionality ${\mathcal{F}}_{\mathrm{Vote}}^{t,u,m,n}$.

Preparation phase. During this phase, every trustee $T^{\left(i\right)}\in T$ registers with the ideal functionality ${\mathcal{F}}_{\mathrm{Vote}}^{t,u,m,n}$ by submitting (Init, sid). The functionality proceeds to the voting phase only after all trustees have completed this initialization step.

Voting phase. During the voting phase, each voter $V^{\left(i\right)}\in \mathrm{V}$ submits their choice $v^{\left(i\right)}$ to the ideal functionality by sending the message (Cast, sid, $v^{\left(i\right)},s^{\left(i\right)})$ to ${\mathcal{F}}_{\mathrm{Vote}}^{t,u,m,n}$. The individual voting choice $v^{\left(i\right)}$ remains hidden and is revealed only in the case where at least t trustees are corrupted.

Transition from Voting to Tally. In the formal UC model, satisfaction of the public condition for closing the voting phase is represented by (CloseVoting, sid) messages from the trustees. After receiving such messages from t distinct trustees, the functionality stops accepting Cast messages, treats the current ballot set $\varphi$ as final, and transitions to the Tally phase.

Tally phase. After the functionality has transitioned to the Tally phase, the trustees $T^{\left(i\right)}\in \mathrm{T}$ request the opening of the voting result by submitting (Tally, sid) to ${\mathcal{F}}_{\mathrm{Vote}}^{t,u,m,n}$. Once at least t such requests have been received, any party may obtain the final outcome by querying the functionality with (ReadTally, sid). The possibility that the adversary may obtain the tally before it becomes publicly available, and the resulting limitation on fairness, are discussed in Section 3.3. The vote-validity checking algorithm $\mathsf{validateAlg}$ and the tally computation algorithm $\mathsf{TallyAlg}$ are specified in Figure 6 and Figure 7, respectively.

Figure 6. The vote validity checking algorithm $\mathsf{validateAlg}$.

Figure 7. The tally algorithm $\mathsf{TallyAlg}$.

• Real/hybrid-world. In the real/hybrid execution setting, the proposed voting protocol is supported by two auxiliary ideal functionalities: the bulletin board functionality ${\mathcal{F}}_{\mathrm{BLOCKCHAIN}}$ and the threshold key generation functionality ${\mathcal{F}}_{\mathrm{DKG}}^{t,u}$. Their roles are outlined below.
• Blockchain-based bulletin-board ideal functionality. We use the ideal functionality ${\mathcal{F}}_{\mathrm{BLOCKCHAIN}}$ introduced in [21] and shown in Figure 8. In the original construction, this functionality models a blockchain-based public ledger. In the context of electronic voting, a blockchain can be viewed as one possible realization of a public append-only bulletin board, providing a common public view of published data together with append-only and auditability properties [22,23]. Our protocol does not rely on the full infrastructure of a particular blockchain platform; instead, it uses ${\mathcal{F}}_{\mathrm{BLOCKCHAIN}}$ only through the bulletin-board properties required for publishing election parameters, encrypted ballots, validity proofs, and final tally data.
  

  Figure 8. Ideal functionality ${\mathcal{F}}_{\mathrm{BLOCKCHAIN}}\left[\mathtt{succ}\right]$.

Because ${\mathcal{F}}_{\mathrm{BLOCKCHAIN}}$ records each submitted item together with the identity of the submitting party, a ballot submitted by voter $V^{\left(i\right)}$ is associated with the registered public key ${\mathsf{pk}}_V^{\left(i\right)}$ and hence with stake $s^{\left(i\right)}$. Multiple ballot records under the same registered public key may remain in the append-only history. For tallying, however, only the most recent record under that key that precedes the end of the voting phase and passes $\mathsf{VerifyBallot}$ is included in $B_{\mathrm{final}}$.

The functionality is parameterized by a predicate succ, which determines whether a newly submitted record is consistent with the current ledger state and can therefore be appended.

For each voting session, the bulletin board preserves the order of published records and identifies the party that submitted each record. Therefore, the t-th CloseVoting record submitted by a distinct trustee uniquely determines the end of the Voting phase and fixes a common cutoff in the record sequence. For each registered voter public key, only its most recent ballot preceding this cutoff and passing $\mathsf{VerifyBallot}$ is included in the set aggregated to compute the voting result.

Ledger entries are addressed by an identifier $id$. Besides the usual Read and Write commands, ${\mathcal{F}}_{\mathrm{BLOCKCHAIN}}$ provides a membership query “∈”, allowing a party to check whether a particular value has already been recorded.

• Distributed key generation ideal functionality. The public encryption key used for ballot encryption is generated by the threshold key-generation functionality ${\mathcal{F}}_{\mathrm{DKG}}^{t,u}$ [24], shown in Figure 9. The functionality is invoked by the trustee set $T:=\{T_1,\dots ,T_u\}$ and outputs a public key $\mathsf{pk}$ for the Lifted ElGamal encryption scheme. The associated secret key $\mathsf{sk}$ is not given to any single trustee; instead, it is distributed among the trustees according to a $(t,u)$ threshold access structure. As a result, decryption of the final encrypted tally requires cooperation of at least t trustees.
  

  Figure 9. Ideal functionality ${\mathcal{F}}_{\mathrm{DKG}}^{t,u}$.

For the purposes of the threshold-decryption correctness proofs used in this work, we extended the interface of ${\mathcal{F}}_{\mathrm{DKG}}^{t,u}$ only with public access to the verification values $v{k}_i=g^{{\mathsf{sk}}_i}$ corresponding to the generated secret-key shares. These values were used solely to verify trustees’ partial decryption contributions and did not change the underlying key-generation or share-distribution procedure of [24].

Definition 1

(UC-realization). Let ${\mathsf{EXEC}}_{\Pi ,\mathcal{A},\mathcal{Z}}$ represent the output observed by the environment $\mathcal{Z}$ when it interacts with the parties running the real-world protocol Π in the presence of an adversary $\mathcal{A}$. Similarly, let ${\mathsf{EXEC}}_{\mathcal{F},\mathcal{S},\mathcal{Z}}$ denote the output produced by $\mathcal{Z}$ when it interacts with the ideal functionality $\mathcal{F}$, a simulator $\mathcal{S}$ modeling the ideal-world adversary, and a set of dummy parties. We say that the protocol Π UC-realizes the functionality $\mathcal{F}$ if, for every PPT adversary $\mathcal{A}$, there exists a PPT simulator $\mathcal{S}$ such that, for all PPT environments $\mathcal{Z}$, the following indistinguishability condition holds:

$${\mathsf{EXEC}}_{\Pi ,\mathcal{A},\mathcal{Z}}\approx {\mathsf{EXEC}}_{\mathcal{F},\mathcal{S},\mathcal{Z}}.$$

4.3. Security

We now state the UC security guarantee achieved by the proposed protocol; the formal statement appears in Theorem 1.

Theorem 1.

Let $t,u,m,n=poly\left(\lambda \right)$ with $u/2<t\le u$. Let $\mathcal{A}$ be a static PPT adversary that may corrupt an arbitrary number of voters and at most $u-t$ trustees. The protocol ${\Pi }_{\mathrm{Vote}}^{t,u,m,n}$ presented in Figure 4 UC-realizes the ideal functionality ${\mathcal{F}}_{\mathrm{Vote}}^{t,u,m,n}$ in the $\{{\mathcal{F}}_{\mathrm{BLOCKCHAIN}},{\mathcal{F}}_{\mathrm{DKG}}^{t,u}\}$-hybrid model and in the random-oracle model, under the DDH assumption.

Proof. 

The proof follows the standard UC simulation approach and proceeds through a sequence of hybrid experiments ${\mathcal{H}}_0,{\mathcal{H}}_1,{\mathcal{H}}_2,{\mathcal{H}}_3$; the full proof is given in Supplementary Materials, Section S2. Hybrid ${\mathcal{H}}_0$ is the real execution.

In hybrid ${\mathcal{H}}_1$, the correctness proofs attached to the honest trustees’ partial decryptions are replaced by simulated proofs. The zero-knowledge property of the partial-decryption correctness proof makes the transition from ${\mathcal{H}}_0$ to ${\mathcal{H}}_1$ computationally indistinguishable.

In hybrid ${\mathcal{H}}_2$, the honest trustees’ partial-decryption contributions are replaced by a consistent threshold-decryption transcript generated from the tally value $\tau$ supplied by the ideal functionality and conditioned on the shares held by the corrupted trustees. Under the DDH assumption, the resulting public transcript is computationally indistinguishable from an honestly generated threshold-decryption transcript. Hence, ${\mathcal{H}}_1$ and ${\mathcal{H}}_2$ are computationally indistinguishable.

In hybrid ${\mathcal{H}}_3$, the ballots of the honest voters are replaced by simulated ballots. In a real ballot, each column contains exactly one plaintext component equal to one, whose position is determined by the voter’s ranking, while all the other components are zero. In a simulated ballot, this unique one is placed in the first position of every column, and all the remaining components are set to zero. Thus, every plaintext column still sums to one. The disclosed aggregate encryption randomness has the same distribution in both cases, and the resulting public homomorphic relation is therefore unchanged. Under the DDH assumption, and consequently the IND-CPA security of Lifted ElGamal, the ciphertexts hide the position of the nonzero component within each column. Together with the simulation property of the unit-vector NIZK, this makes the transition from ${\mathcal{H}}_2$ to ${\mathcal{H}}_3$ computationally indistinguishable.

In ${\mathcal{H}}_3$, the threshold-decryption transcript is generated in the same manner as in ${\mathcal{H}}_2$, but for the aggregate ciphertext resulting from the simulated ballots. The resulting adversarial view coincides with the simulated ideal-world view. Therefore, by transitivity of computational indistinguishability, the real and ideal executions are computationally indistinguishable.

The NIZK proofs are obtained from the corresponding $\Sigma$-protocols by applying the Fiat–Shamir heuristic in the random-oracle model. In the UC security proof, the simulator can determine the random-oracle responses to selected queries so as to generate simulated NIZK proofs that are accepted by the verifier without knowledge of the corresponding witnesses. For the unit-vector NIZK, the public commitment key $\mathsf{ck}$ is used as the common reference string (CRS); it is chosen so that no party knows the discrete-logarithm relation between g and $\mathsf{ck}$.    □

5. Performance

For the performance evaluation, we implemented the core encrypted-ballot processing algorithms in the Rust programming language. The  main benchmark series focuses on encrypted-ballot construction and complete ballot verification. To complement these per-ballot measurements, we also report simulation results for homomorphic aggregation, scaling with the number of voters, and the implemented committee-based tally-decryption path.

The implementation used the Ristretto255 group, which is based on curve25519-dalek version 4. The benchmark executable was compiled and run in release mode. All measurements were performed on a workstation equipped with an Intel Core i7-1165G7 processor clocked at 2.80 GHz, 32 GB of RAM, and running Ubuntu 20.04.4 LTS. For each $m\in \{2,4,8,16,32,64,128\}$, 1000 complete ballots were generated and verified sequentially. Each individual ballot-generation and verification operation was timed using Rust’s std::time::Instant, and Table 2 reports the arithmetic mean per ballot over these 1000 operations. No explicit application-level parallelization was used in the measured routines.

Table 2. Performance of encrypted-ballot construction and verification for different numbers of alternatives. Times are arithmetic means per ballot over 1000 sequential ballots; payload values include the cryptographic components specified in the text.

Alternatives	Ballot Generation, ms	Ballot Verification, ms	Cryptographic Ballot Payload, KiB
2	0.66	0.44	0.875
4	4	1.4	3.25
8	8.3	3.7	10.5
16	26	11	33
32	87	36	106
64	313	123	356
128	1170	400	1256

Ballot-generation time included construction and encryption of the $m\times m$ permutation matrix, generation of the m NIZK unit-vector proofs, and computation of the length-m aggregate-randomness vector. Complete ballot verification included verification of all m unit-vector proofs, component-wise homomorphic aggregation of the encrypted rows, and verification that the aggregate encrypted the all-ones vector under the disclosed aggregate randomness. Thus, the timings in Table 2 correspond to the complete ballot-generation and ballot-verification procedures implemented by the prototype.

The reported size corresponds to the cryptographic payload of a ballot, rather than to end-to-end network traffic. In the implementation, both a compressed Ristretto255 group element and a scalar occupied 32 bytes. Consequently, a Lifted ElGamal ciphertext, which consists of two group elements, occupies 64 bytes.

Let $\mathsf{\ell }=\lceil {log}_{2}m\rceil$. The unit-vector proof operated on a vector whose length was padded to the next power of two and therefore consisted of ℓ proof levels. At each level, the proof contained an announcement composed of three group elements (96 bytes), one Lifted ElGamal ciphertext (64 bytes), and a response composed of three scalars (96 bytes). In addition, the proof contained one final scalar of 32 bytes. Hence, the size of a single unit-vector proof was

$$S_{\mathrm{UV}}\left(m\right)=(96+64+96)\mathsf{\ell }+32=256\lceil {log}_{2}m\rceil +32\mathrm{bytes}.$$

A complete encrypted ballot contained an $m\times m$ matrix of Lifted ElGamal ciphertexts, m unit-vector proofs—one for each encrypted row—and a length-m vector of aggregate encryption randomness. Its cryptographic payload was therefore

$$\begin{array}{cc}\hfill S_{\mathrm{ballot}}\left(m\right)& =\underset{\mathrm{encrypted}\mathrm{permutation}\mathrm{matrix}}{\underbrace{64m^2}}+\underset{\mathrm{unit}\text{-}\mathrm{vector}\mathrm{proofs}}{\underbrace{m\left(256\lceil {log}_{2}m\rceil +32\right)}}+\underset{\mathrm{aggregate}\text{-}\mathrm{randomness}\mathrm{vector}}{\underbrace{32m}}\hfill \\ & =64m^2+256m\lceil {log}_{2}m\rceil +64m\mathrm{bytes}.\hfill \end{array}$$

Thus, the encrypted-matrix data had size $O\left(m^2\right)$, the ballot-validity proof data had size $O(mlogm)$, and the aggregate-randomness data had size $O\left(m\right)$. The total cryptographic ballot payload therefore remained $O\left(m^2\right)$.

This calculation included the cryptographic data required for ballot verification but excluded implementation- and transport-specific overheads, such as transaction and signature data, bulletin-board metadata, and container-serialization overhead. Sizes are reported in KiB, where $1\mathrm{KiB}=1024$ bytes.

The theoretical $O\left(m^2\right)$ ballot-generation complexity followed from the need to encrypt $m^2$ matrix entries, together with the lower-order contribution of m logarithmic-size unit-vector proofs. The measurements in Table 2 and Figure 10a are consistent with this quadratic scaling. Ballot verification likewise processed all m unit-vector proofs and performed component-wise operations over the $m\times m$ encrypted matrix; the measured verification times in Figure 10b are also consistent with $O\left(m^2\right)$ growth. Verification remained faster than generation throughout the tested range.

Figure 10. (a) Mean ballot-generation time. (b) Mean complete ballot-verification time.

Figure 11 shows the reported cryptographic ballot payload. Its growth was dominated by the $m^2$ Lifted ElGamal ciphertexts, whereas the aggregate unit-vector proof data grew as $O(mlogm)$. For $m=32$, the reported payload was 106 KiB; at $m=64$ and $m=128$, it increased to 356 KiB and 1256 KiB, respectively. These values describe the cryptographic ballot components defined above and should not be interpreted as complete network or bulletin-board traffic.

Figure 11. Cryptographic ballot payload as a function of the number of alternatives. Values are reported in KiB and exclude application-layer and serialization overheads.

Let n denote the number of valid ballots included in the tally. The homomorphic tally computation had time complexity $O\left(n{m}^2\right)$, because $m^2$ ciphertexts were processed for each ballot. In the formal threshold protocol, decryption of the m aggregate ciphertexts from t valid decryption contributions requires $O\left(tm\right)$ share-processing operations, followed by m bounded discrete-logarithm recoveries. The current prototype simulation used all u committee-member shares, so its measured committee-decryption cost scaled with u rather than with the minimum threshold t.

For $m=32$, additional simulation runs gave homomorphic-aggregation times of 4.46 ms, 43.38 ms, and 444.57 ms for $n=10$, 100, and 1000 voters, respectively. The corresponding total sequential ballot-validation times were 0.362 s, 3.552 s, and 39.565 s, while the validation time per ballot remained approximately 35–40 ms. Thus, at fixed m, both the total validation work and homomorphic aggregation scaled approximately linearly with n.

The corresponding scaling measurements are summarized in Table 3.

Table 3. Additional scaling measurements for $m=32$. Each row corresponds to one simulation run.

Voters n	Total Ballot Validation	Homomorphic Aggregation
10	362.18 ms	4.46 ms
100	3.552 s	43.38 ms
1000	39.565 s	444.57 ms

The additional committee-based decryption measurements used $n=10$ and plaintext bound $M=10$, so that bounded-DLP recovery did not dominate the timing. The measured wall-clock time includes generation of partial decryptions by all simulated committee members, verification of DLEQ correctness proofs, combination of the validated shares, and final plaintext recovery. The results are shown in Table 4. Each aggregation/decryption configuration in these additional simulation tables was measured in one simulation run; the large-bound DLP benchmark reported in Section 2.2 used repeated measurements and is reported separately.

Table 4. Committee-based decryption measurements for $n=10$ and plaintext bound $M=10$.

Alternatives m	$(\mathit{t},\mathit{u})$	Committee-Based Decryption
32	$(1,1)$	228.79 ms
32	$(2,3)$	643.53 ms
32	$(3,5)$	1.053 s
64	$(1,1)$	879.06 ms
64	$(2,3)$	2.642 s
64	$(3,5)$	4.358 s

These measurements characterize the implemented committee-based decryption path, not a complete deployed t-of-u threshold system, because the current simulation required shares from all u committee members. They also do not include full DKG, bulletin-board/network latency, or other application-layer overheads.

For an indicative comparison, Table 5 reports performance values published for other protocols. This is not a normalized direct benchmark comparison: the protocols use different cryptographic mechanisms, ballot models, software platforms, and hardware, and they provide different privacy properties. The values should therefore be treated only as practical reference points and not as evidence that one protocol is “faster” than another.

Table 5. Indicative performance figures reported for related protocols and the present implementation.

Protocol	Experimental Setting	Metric	Reported Value
Yang et al. (2018) [6]	20 candidates	Ballot casting computation, per ballot	≈0.1 s
Yang et al. (2018) [6]	20 candidates	One submission (encrypted values + proofs + digital signature)	<150 KB
Yang et al. (2018) [6]	10 candidates; 10,000 voters	Verification of all ballots	≈6 min
ElectAnon (2023) [7]	Semaphore circuit	genProof	8.446 s
ElectAnon (2023) [7]	10 candidates; 250 voters	Tideman/electionResult	≈21.1 M gas; >250 voters reaches the 30 M gas limit
Our protocol	$m=32$	Mean ballot generation, per ballot	87 ms
Our protocol	$m=32$	Mean complete ballot verification, per ballot	36 ms
Our protocol	$m=32$	Cryptographic ballot payload	106 KiB

The practical applicability of the protocol is governed by two different scale parameters. The cost of generating, verifying, and transmitting an individual ballot grows quadratically with the number of alternatives m, because each vote is represented by an $m\times m$ permutation matrix. At fixed $m=32$, the additional simulation runs for $n=10$, 100, and 1000 show approximately linear growth of total ballot-validation work and homomorphic aggregation with the number of voters. These measurements characterize local cryptographic processing in the prototype; they do not include bulletin-board/network latency, distributed DKG, or a deployed threshold-decryption workflow and therefore do not establish scalability to nationwide elections with very large electorates. The present results are most directly informative for applications with a moderate number of alternatives and moderate voting scale, such as ranking projects, grant applications, committee members, or proposals in decentralized governance systems.

The main limitation of the protocol is the quadratic dependence of ballot size and ballot-processing time on m. Accordingly, the proposed construction is intended primarily for voting scenarios with a moderate number of alternatives.

Overall, the combined measurements support the theoretical complexity analysis: per-ballot construction and verification grow approximately quadratically with m, while homomorphic aggregation and total ballot-validation work grow approximately linearly with n for fixed m. The reported simulation results also characterize the implemented committee-based decryption path. They do not, however, constitute an end-to-end benchmark of a deployed voting system, because full DKG, bulletin-board/network latency, application-layer processing, and a deployed t-of-u threshold workflow remain outside the measured scope.

6. Conclusions

This work presents a UC-secure protocol for privacy-preserving preferential voting with verifiable encrypted ballots. Complete rankings are represented as encrypted permutation matrices. Ballot validity is established by applying the NIZK unit-vector proof of Zhang et al. [4] to each row and by verifying the column condition through a joint homomorphic check. This reduces the aggregate size of the ballot-validity proofs to $O(mlogm)$, although the total ballot size remains $O\left(m^2\right)$ because the matrix contains $m^2$ ciphertexts. The protocol further supports stake-weighted tallying and threshold decryption, so that individual rankings remain encrypted and only the aggregate result is revealed. These guarantees are formalized through ${\mathcal{F}}_{\mathrm{Vote}}^{t,u,m,n}$ and proved in the universal composability framework under the stated adversarial and threshold assumptions.

The experimental evaluation included the main per-ballot construction and complete ballot-verification benchmarks together with additional simulation measurements for homomorphic aggregation, scaling with the number of voters, and the implemented committee-based decryption path. The measured generation and verification times and the reported cryptographic ballot payload were consistent with the theoretical $O\left(m^2\right)$ scaling induced by the $m\times m$ permutation-matrix representation, while the aggregate ballot-validity proof data had size $O(mlogm)$. For 32 alternatives, the mean generation time was 87 ms, the mean verification time was 36 ms, and the reported cryptographic ballot payload was 106 KiB. At fixed $m=32$, the additional simulation runs for $n=10$, 100, and 1000 were consistent with approximately linear scaling of total validation work and homomorphic aggregation in the number of voters. These measurements indicate practical cryptographic processing costs for moderate problem sizes, while the increasing computational and payload costs limit scalability for larger alternative sets. The additional simulation measurements characterize homomorphic aggregation and the implemented committee-based decryption path; however, they do not constitute an end-to-end protocol benchmark and do not include full DKG, bulletin-board/network latency, or a deployed t-of-u threshold workflow.

Future work includes reducing the size of the encrypted ballot and the associated computational and communication costs, extending the protocol to other preferential-voting rules, and studying its use in governance mechanisms for decentralized electricity markets and energy communities. In the latter setting, the protocol may support confidential collective ranking of suppliers, energy projects, demand-response programs, or market-rule proposals; the design of privacy-preserving auction clearing remains a separate problem.