A Parameterizable Research Framework for Electronic Voting Based on Cryptographic Protocols and Blockchain Audit

Abstract

Electronic voting requires the simultaneous admission of only legitimate participants, ballot uniqueness, vote confidentiality, storage integrity, and result verifiability. Blockchain alone does not solve these problems, since ledger immutability does not guarantee anonymity, ballot correctness, or reduced trust concentration. The purpose of this work is to develop a parameterizable research framework for electronic voting scenarios with enhanced cryptographic protection, allowing the security level to be varied according to the requirements of a voting scenario. The main contribution of the work is a parameterizable research architecture for composing and experimentally comparing electronic voting configurations with different security and computational profiles. The cryptographic and audit mechanisms integrated into this architecture include blind-signature-based anonymous authorization, encrypted ballot submission, blockchain-style audit, receipt verification, homomorphic tally publication, and threshold-supported tally artifacts. These mechanisms are not proposed as new cryptographic primitives; rather, they are integrated into a reproducible prototype to study how their combination affects verifiability, privacy support, auditability, and computational cost. Compared with basic blockchain-based voting prototypes, this architecture explicitly separates security, privacy, and verifiability profiles and makes their computational cost observable. The implemented prototype is used as an experimental platform for analyzing supported security properties, threat modeling, and computational cost estimation. The results show that authentication, anonymous token issuance, and receipt verification maintain an almost constant cost at the studied scale, while the main cryptographic burden is associated with encrypted ballot submission and threshold-supported tally publication. The scientific novelty of the work lies in constructing a parameterizable architecture that integrates several cryptographic mechanisms and a blockchain audit layer into one reproducible research prototype. At the same time, the proposed approach retains prototype-level limitations associated with the absence of a full zero-knowledge proof stack, independently deployed threshold authorities, and coercion-resistance mechanisms.

1. Introduction

Electronic voting is one of the key directions of digital transformation of public administration and corporate decision-making processes. Increasing the requirements for transparency, trust in voting results, and scalability of systems encourages the active development of methods that ensure the security, verifiability, and confidentiality of the electoral process.

Modern electronic voting systems must simultaneously meet a number of critical requirements, including voter anonymity, correct vote counting, protection against repeat voting, the ability to independently verify results, and resistance to internal and external attacks. It is difficult to ensure all these features exist within one system because it requires a large number of different types of cryptographic mechanisms to work together in order for this to occur [1]. Examples of very well-developed systems that have achieved this goal are those that use end-to-end verifiable voting systems as a method for allowing voters and observers to confirm (by themselves) that their vote was cast correctly without relying on centralised authorities [2]. End-to-end verifiable voting systems provide a high degree of transparency, but they are typically restricted to fixed architectures and do not have the ability to easily adapt to a variety of applicable scenarios.

At the same time, cryptographic methods are actively developing, including blind signatures, homomorphic encryption, and threshold schemes that allow for anonymous authorization, secure vote counting, and trust sharing among multiple participants. Despite the high level of theoretical study, these methods are often considered in isolation and are not integrated into complex systems with full testability and practical implementation.

With the advent of distributed ledger technology, considerable attention is being paid to the use of blockchain to ensure the immutability and auditability of voting results [3]. However, modern research shows that the use of blockchain does not fully solve the tasks of ensuring privacy, protection from coercion and scalability, and requires a combination with other cryptographic mechanisms.

In recent years, there has been a transition to modular electronic voting architectures, in which the system is considered as a set of interrelated components that implement various stages of the electoral process [4]. With this approach, having a flexible system configuration based on what different applications may need is possible. However, current solutions in this area are generally limited to describing abstract models with no systematic way to assess how different security configurations will affect performance and compute complexity. The research gap addressed in this paper is therefore not the absence of individual cryptographic primitives for electronic voting, but the lack of a reproducible and parameterizable research framework that integrates these primitives into one executable architecture and allows their security and computational trade-offs to be compared under controlled experimental conditions.

Systems with full verifiability, such as Helios and Belenios, provide a high level of transparency and cryptographic correctness, but they implement fixed protocols and do not provide for adapting the architecture to various voting scenarios. Classical cryptographic schemes based on the use of blind signatures, homomorphic encryption, and threshold methods provide strong supported security properties within the stated prototype threat model, but they are usually considered in isolation and are not integrated into fully functional systems. In turn, blockchain-based solutions improve the auditability and immutability of data, but they do not fully solve the tasks of ensuring privacy, protection from coercion and scalability. To date, modern investigations into modular voting architectures are mainly limited to theoretical approaches but lack a systematic way of determining/configuring the required security level and metrics for comparison by calculating the cost of computation required for each possible combination of components. Therefore, there remains an open area for developing an all-encompassing framework that can enable:

• The integration of multiple types of cryptographic mechanisms with a single voting architecture;
• Configuring a voting architecture security level based on the specific needs of these applications;
• Measuring the performance impact of any given mechanism chosen to implement.

This study proposes the use of “parameterized builders”, or templates, to construct modular electronic voting systems that use multiple techniques such as anonymous signing through blind signatures; generate electronically secured ballots for voters via encryption; auditable block chain recordkeeping; homomorphic tallying; proven time stamped submissions supported by threshold schemes. Unlike existing solutions, the proposed approach is not focused on the implementation of a fixed protocol, but on creating a research platform that allows you to systematically compare different security configurations and analyze their impact on computing costs and scalability.

The novelty of the proposed work should be understood at three levels. At the conceptual level, the work treats electronic voting not as a single fixed protocol, but as a configurable composition of authentication, anonymization, encrypted ballot submission, audit, tallying, and verification layers. At the methodological level, it introduces security profiles and experimental configurations as a way to compare trade-offs between supported security properties and computational cost. At the technical level, it implements these ideas in a reproducible prototype that combines blind-signature-based anonymous authorization, encrypted ballot submission, blockchain-style audit, receipt verification, homomorphic tally publication, threshold-supported tally artifacts, and automated integrity checks.

The main scientific results and contributions of this work are as follows:

• We formally define a parameterizable designer for electronic voting scenarios as a configurable design space that combines authorization, ballot protection, audit, tallying, verification, security profiles, and measurable performance/integrity metrics.
• We implement a reproducible research prototype that instantiates this design space through blind-signature-based anonymous authorization, encrypted ballot submission, blockchain-style audit, receipt verification, homomorphic tally publication, threshold-supported tally artifacts, and automated integrity checks.
• We empirically demonstrate, within the stated prototype threat model, that the implemented mechanisms support eligibility control, repeated-vote prevention, receipt-based inclusion checking, ledger-derived tally publication, and audit-state consistency.
• We measure the computational overhead of different security configurations and show that authentication, anonymous token issuance, and receipt verification remain relatively stable at the studied prototype scale, while encrypted ballot submission and threshold-supported tally publication dominate the cryptographic cost.
• We identify the limitations of the current prototype, including the absence of a full zero-knowledge proof layer, coercion resistance, independently deployed threshold authorities, real distributed consensus, and large-scale deployment evaluation.

These contributions are not limited to a descriptive architectural proposal. They are demonstrated through an implemented prototype, executable security-profile configurations, automated integrity and attack-scenario tests, and benchmark measurements that quantify the computational cost of selected mechanisms under controlled experimental conditions.

As mentioned above, this article is composed of the following sections. In Section 2, We will provide an overview of some related work and analyze previous electronic voting schemes and compare them to our proposed scheme. In Section 3, we will describe the architecture for a parameterizable constructor which includes overall system architecture, participants, cryptographically sound mechanisms, the auditing aspect offered by blockchains, and the security properties of the proposed system. Lastly, in Section 4 present a formal definition of the threat model and establish the security properties of the proposed system. Section 5 presents the implementation of the prototype and the experimental setup used to evaluate the proposed approach. Section 6 provides experimental results, including an analysis of computational cost and scalability. Section 7 discusses the limitations of the proposed solution and the directions of further research. The main conclusions of the work are formulated in Section 8.

2. Related Work

Electronic voting systems are being actively researched in terms of security, confidentiality, and verifiability of results. One of the first and most significant approaches is mixnet, proposed by D. Chaum [5], which ensures the anonymity of voters through cryptographic mixing of ballots. Later, this approach was developed and optimized for practical application [6].

Another widely used approach is homomorphic encryption, which allows for vote counting without disclosing individual elections. Modern voting systems also actively use Zero-Knowledge Proofs, which make it possible to confirm the correctness of ballots without disclosing their contents. A significant contribution to the development of this field was made by the work on short non-interactive proofs (SNARK) [7,8].

With the development of blockchain technology, the attention of researchers has been attracted by decentralized voting systems that ensure transparency and immutability of data. Modern works consider the advantages and limitations of using blockchain in voting [9,10]; however, the problems of scalability and confidentiality remain unresolved.

In addition to confidentiality, resistance to coercion is an important requirement. The classic work of Juels and co-authors [11] suggests mechanisms to protect against pressure on voters, which remain relevant in modern systems. Threshold cryptography schemes are also used to increase the reliability of systems, distributing trust between several participants [12].

2.1. End-to-End Verifiable Voting Systems

End-to-end (E2E) verifiable voting systems represent one of the most established directions in electronic voting research, aiming to provide voters and external observers with the ability to verify the correctness of the election process at all stages.

A classical example is Helios, which introduced an open-audit model where encrypted ballots are publicly available for verification. The independent validation of election results is possible through this methodology; however, it should be noted that it has a strong dependence on trusted authentication infrastructure and lacks complete resistance to coercion. At the same time, more sophisticated systems such as Belenios expand on this basic model by adding ballot validity, threshold decryption, and alternative methods of aggregation, such as homomorphic aggregation or mixnets, using zero-knowledge proofs (ZKP). These systems provide stronger cryptographic guarantees and improved verifiability.

Recent surveys confirm that E2E systems significantly improve transparency and trust but still face challenges related to usability, coercion resistance, and deployment in large-scale real-world scenarios [12,13,14].

2.2. Classical Cryptographic Voting Schemes

Another important direction is based on classical cryptographic primitives such as blind signatures, homomorphic encryption, and threshold cryptography.

Blind signature schemes enable anonymous voter authentication, ensuring that eligibility can be verified without linking voters to their ballots. With homomorphic encryption it is possible to add together encrypted votes without decrypting them, keeping voter privacy throughout the voting process. By using threshold cryptography, trust is spread across multiple entities making it less likely to be compromised by any one party.

New research has demonstrated that combining these two technologies together can provide robust privacy as well as security advantages over the traditional voting system [15,16]. However, such schemes are often studied in isolation and lack integration into fully operational and user-oriented voting platforms.

Moreover, these approaches typically introduce computational overhead and require complex key management infrastructures, which limits their practical deployment in large-scale systems.

2.3. Blockchain-Based Electronic Voting Systems

With the emergence of distributed ledger technologies, blockchain has been actively explored as a tool for improving transparency and auditability in electronic voting [17].

Blockchain-based voting systems use immutable ledgers to store election data, enabling public verification and tamper resistance. Modern approaches combine blockchain with cryptographic techniques such as zero-knowledge proofs, blind signatures, and threshold encryption [18].

As an illustration of recent progress, we have seen several proposals for a versatile voting system based on a blockchain with aggregated signatures and privacy preservation [19]. Smart contracts are also emphasized as having the potential to automate the process of conducting elections, leading to increased integrity [20].

Nevertheless, many researchers continue to note that blockchain by itself is insufficient to address many of the major issues surrounding voting, including voter privacy, coercion-resistance and secure authentication. Additionally, scalability and transaction throughput remain significant limitations, especially in large-scale elections [21,22].

Therefore, blockchain is increasingly viewed as an audit and integrity layer rather than a standalone solution for secure voting systems.

2.4. Modular and Configurable Voting Architectures

A more recent research direction focuses on modular and configurable architectures for electronic voting systems.

Such approaches decompose voting systems into independent components (authentication, ballot generation, tallying, auditing), allowing different cryptographic mechanisms to be combined depending on the application requirements.

Framework-based approaches have been developed for the purpose of providing enhanced flexibility, scalability, and adaptability for voting systems [23]. These architectures allow users to define security characteristics of the voting system based on their specific requirements and allow users to apply different trusts/assumption types and different performance requirements.

However, existing works are often limited to conceptual models or partial implementations and lack systematic evaluation of how different configurations impact both supported security properties within the stated prototype threat model and computational performance.

From the reviewed literature, three limitations are particularly relevant to the present work. First, open-audit systems such as Helios and Belenios provide strong verifiability, but they are usually designed as relatively fixed protocol families rather than as configurable research frameworks for comparing different security profiles. Second, blockchain-based voting prototypes improve auditability and tamper evidence, but often treat the ledger as the central innovation while leaving privacy, ballot validity, coercion resistance, and performance trade-offs only partially addressed. Third, classical cryptographic voting schemes provide strong primitives such as blind signatures, homomorphic tallying, threshold decryption, and zero-knowledge proofs, but they are often studied as separate protocol components and are not always accompanied by reproducible software prototypes and systematic cost evaluation.

The proposed work is positioned at the intersection of these limitations. It does not claim to replace formally verified voting systems or to introduce a new cryptographic primitive. Instead, it integrates selected mechanisms into a reproducible parameterizable prototype and evaluates how different configurations affect supported security properties and computational overhead. This critical positioning motivates the need for the proposed framework.

2.5. Comparison with the Closest Research Areas

From the point of view of comparison with existing approaches, the proposed method is closest to the three main research areas.

The first direction is represented by web-based electronic voting systems with open audit, such as Helios [24]. The proposed constructor combines with these systems a focus on verifiability, web accessibility, and practical reproducibility. At the same time, the proposed architecture expands this approach by integrating blockchain-based auditing, anonymous authorization mechanisms based on blind signatures, as well as publishing results with support for threshold schemes.

The second area includes modern electronic voting schemes based on the blockchain, which use blind signatures, threshold encryption and various cryptographic verification mechanisms. Unlike these solutions, the proposed constructor is not tied to a specific blockchain platform or smart contract environment and is considered as a research architecture. This allows you to parameterize security levels, vary experimental scenarios, and explicitly analyze the trade-off between security and computational cost.

The third direction is represented by classical cryptographic voting schemes based on multilateral trust and threshold counting organization [25,26,27]. These works form the theoretical basis of the mechanisms used in the prototype, including anonymous authorization, distributed decryption, and secure vote aggregation. However, they typically do not provide a reproducible research platform combining a web interface, applied auditing, experimental security profiles, and an observable integrity control loop.

Therefore, the main distinction among the proposed method and others that are similar is that a new cryptographic primitive is not developed but rather a parameterizable research constructor which can combine mechanisms for anonymous authorizing, ballot encrypting, an auditor for chains, homomorphically aggregating the data and thresholded supporting the publication of results and maintaining state consistency for all in one consistent, reproducible architecture. It is the composition of these mechanisms and the possibility of their experimental analysis that form the main comparative contribution of this work.

It should be noted that the comparison in this section is qualitative and feature-oriented. The present work does not perform a direct benchmark against existing implementations such as Helios, Belenios, or deployed blockchain voting systems. The purpose of the comparison is to position the proposed research prototype with respect to architectural components, supported mechanisms, and reproducibility, rather than to claim superior performance or stronger formally proven security over existing systems.

For a clearer comparison, the closest works are evaluated according to the following criteria: (1) support for anonymous authorization; (2) encrypted ballot submission; (3) append-only or blockchain-style audit; (4) homomorphic or cryptographic tally support; (5) threshold-supported tally publication; (6) explicit parameterization of security profiles; (7) reproducibility as an implemented research prototype; and (8) availability of experimental cost evaluation. These criteria correspond to the main layers of the proposed architecture and clarify the distinction between fixed voting protocols, blockchain-based prototypes, and configurable research frameworks.

Table 1. Comparison of the proposed constructor with existing approaches.

Approach	Anonymous Authorization	Ballot Encryption	Blockchain Audit	Homomorphic Aggregation	Threshold Support for the Publication of the Tally	Parameterization of Profiles	A Reproducible Research Prototype	Experimental Cost Evaluation
Centralized web systems	Usually missing	Possible, but not required	No	Usually missing	Usually missing	Limited	Usually limited	Usually limited
Basic voting systems based on blockchain	Usually missing	Often missing or simplified	Yes	Usually missing	Usually missing	Usually missing	Often a demo	Often limited
Open-audit web systems such as Helios	Limited	Yes	No	Possible	Usually missing	Limited	Yes	Present in some works
Classic cryptographic multi-authority schemes	Yes	Yes	No	Yes	Yes	It is usually not the central goal	Often low engineering reproducibility	Usually theoretical or scheme-specific
Modern Hybrid blockchain Cryptographic Schemes	Partially implemented	Yes	Yes	Yes	Partially implemented	Usually limited	Depends on the platform and implementation	Depends on the platform and implementation
The proposed parameterizable constructor	Yes	Yes	Yes	Yes	Yes, at the prototype level	Yes	Yes	Yes, prototype-level

summarizes the position of the proposed constructor among the closest classes of solutions.

Table 1 shows that the proposed approach does not claim advanced cryptographic completeness in all dimensions, but combines properties that are rarely present simultaneously in one research platform: anonymous authorization, encrypted ballot submission, blockchain audit, homomorphic aggregation, threshold-supported tally publication, parameterizability, and reproducibility. The comparison is based on architectural and functional properties reported in the literature and in the implemented prototype; it is not a direct experimental benchmark against the listed systems.

The comparative implication of Table 1 is that the proposed constructor occupies an intermediate position between fixed end-to-end verifiable voting protocols, blockchain-based voting prototypes, and classical cryptographic schemes. Compared with open-audit systems such as Helios, the proposed approach is less mature in terms of formal cryptographic completeness, but it provides a broader experimental environment for combining audit, anonymization, encrypted ballot submission, tallying, and profile-based configuration. Compared with basic blockchain-based voting systems, the main difference is that blockchain is not treated as the sole security mechanism, but as one audit layer combined with cryptographic protection and verification mechanisms. Compared with classical cryptographic schemes, the contribution is not a stronger primitive, but the integration of selected mechanisms into a reproducible prototype in which computational costs can be observed.

3. Architecture of the Proposed Constructor

3.1. The Overall Architecture of the System

The proposed system is a parameterizable electronic voting constructor that combines several independent but interacting components: a voter registration module, an anonymous authorization module, a ballot generation module, a storage and audit module, and a vote counting module.

The architecture is based on a modular principle, which allows you to configure the composition of the cryptographic mechanisms used, depending on the requirements of a specific voting scenario. The main feature of the system is the ability to combine different levels of security without changing the basic logic of component interaction.

The architectural composition of the designer is shown in Figure 1.

3.2. System Participants

The following participants are distinguished within the framework of the model:

• Voter—generates and sends an encrypted ballot;
• Registration Authority—confirms the right to participate in voting;
• Authorization Authority—performs a blind token signature;
• Voting Server—accepts encrypted ballots;
• Audit Module (Audit Layer/Blockchain)—ensures the immutability of records;
• A set of trusted nodes (Tally Authorities) performs threshold decryption of the results.

Separation of roles allows you to minimize trust in individual components of the system and increase resistance to compromise.

Figure 2 shows the interaction model of the system participants.

The separation of roles between registration, authorization, and the voting server eliminates single points of trust and increases the system’s resilience to compromise of individual components. The audit layer supports tamper-evident recording within the prototype.

3.3. Voting Protocol

The voting process in the proposed system is divided into several logical phases, each of which performs a separate function to ensure the security and correctness of the protocol.

Phase 1. Authentication and confirmation of voting rights. At this stage, the system verifies that the participant belongs to the register of voters and is eligible to participate in the current electoral process. The main purpose of this phase is to provide the eligibility property.

Phase 2. Anonymous token issuance. After successful authentication, the voter forms a blinded request, which is signed by the anonymous authorization authority. As a result, the voter receives a token confirming the right to vote, but not directly linked to the person at the stage of submitting the ballot. This phase is aimed at increasing privacy and breaking the direct link between identification and the ballot.

Phase 3. Formation of the ballot. In this phase, the selection is encoded as an encrypted ballot. Additionally, a receipt and a homomorphic representation of the ballot are generated, suitable for subsequent aggregation. This ensures the confidentiality of the choice and the prerequisites for verifiability.

Phase 4. Submission of the ballot. The voter submits an anonymous token, a token signature, an encrypted ballot, a receipt, and related cryptographic data. The system verifies the validity of the ballot structure, the uniqueness of the token, and the correctness of the connection between the receipt and the ciphertext. The main purpose of this phase is to ensure uniqueness and integrity properties.

Phase 5. Confirmation of the record in the blockchain. Once the ballot is put into the pending transaction pool, it is included in a block and then added to the chain as part of the permanent audit trail of all transactions. Therefore, during this stage, the integrity and traceability are improved.

Phase 6. Checking the consistency of the state. After the record is confirmed, the derived application representation is compared with the data of the blockchain chain. If a discrepancy is detected, the confirmed slice can be automatically or manually reassembled from the registry. In this phase, the operational integrity control loop is enhanced.

Phase 7. Verification and publication of the result. The voter can check the receipt, and an external observer can analyze the public ballot board, the integrity of the chain, and the published aggregated total. At this stage, the properties of individual and partially public verifiability are implemented. All phases are shown in Figure 3.

Figure 3 shows the sequence of the main voting stages. First, the voter goes through the authentication procedure through the registration authority, after which the authorization authority issues an anonymous token using the blind signature mechanism. Next, the voter generates an encrypted ballot and sends it to the voting server. The server records the encrypted ballot in the audit layer. At the counting stage, trusted nodes perform threshold decryption, after which the results are published and can be verified by the voter. The presented sequence supports anonymity, verifiability, and integrity within the limitations of the implemented prototype of the system by separating roles and using cryptographic mechanisms.

3.4. Formalized Voting Protocol Flow

To improve reproducibility, the voting workflow is represented in

Table 2. Formalized prototype voting protocol and security interpretation.

Step	Protocol Action	Security Purpose	Prototype Limitation
1	Voter authenticates with the registration/authentication authority	Establishes eligibility	Depends on trusted registration data
2	Voter generates token message τ and blinded request β = Blind(τ)	Separates voter identity from the final token	Does not remove timing metadata
3	Token authority verifies eligibility and signs β once per voter and election	Prevents unauthorized token issuance and repeated eligibility use	Authority is trusted within the prototype
4	Voter unblinds the response and obtains σ = Unblind(σβ)	Produces an anonymous authorization token.	Not a complete coercion-resistant credential system.
5	Voter encodes the selected option as one-hot vector m and encrypts it as C = Ency(m)	Supports ballot confidentiality and homomorphic tallying	Client environment is assumed honest
6	Voter generates ballot-validity artifacts π and receipt hash p = H(C)	Supports prototype-level well-formedness checking and receipt inclusion	Not a complete independently verifiable ZKP layer
7	Voters submit (e, τ, σ, C, π, p) to the voting service	Links authorization, encrypted ballot, and receipt consistency	Server-side validation remains trusted
8	Voting service verifies σ, token uniqueness, election status, π, and p	Rejects invalid or repeated ballots before confirmation	Correct execution of service logic is assumed
9	Accepted ballot transaction is appended to the blockchain-style audit ledger	Provides chronological, tamper-evident recording	Not a BFT distributed consensus system
10	Voter or observer verifies receipt inclusion and audit consistency	Supports individual verification and audit transparency	Receipt mechanism is not receipt-free
11	Confirmed ciphertexts are homomorphically aggregated and tally artifacts are published	Supports prototype-level tally transparency	Threshold authorities are not independently deployed

as a structured protocol sequence. For each step, the table identifies the corresponding protocol action, its security purpose, and the remaining prototype-level limitation. This formalization is intended to clarify the implemented workflow and its security assumptions, rather than to serve as a complete formal proof of the voting protocol.

Table 2 formalizes the protocol roles and shows how each step contributes to the supported security properties. The table also makes explicit which assumptions remain in the prototype. Therefore, the protocol should be interpreted as a reproducible research workflow with selected security checks, rather than as a complete formally proven e-voting protocol.

In addition to the protocol sequence,

Table 3. Phase-level vulnerability analysis of the prototype workflow.

Phase	Possible Attacks	Security Condition/Mitigation	Residual Risk
Authentication	Credential misuse, unauthorized login, stolen PIN	Voter registry, PIN verification, role-based access control	Depends on registration authority and credential secrecy
Token issuance	Multiple token requests, linkability between voter and token	One-token-per-voter rule, blind signature, token issuance registry	Timing metadata and authority trust remain
Ballot construction	Malformed encrypted ballot, client-side malware, invalid option encoding	One-hot encoding, encrypted ballot, ballot-validity checks	Client compromise and full ZKP absence remain
Ballot submission	Replay, double voting, token reuse, receipt mismatch	Token signature verification, token-spending registry, receipt hash check	Correct server-side validation is assumed
Ledger confirmation	Transaction omission, record tampering, local database modification	Blockchain-style append-only ledger, receipt inclusion, chain validation	No BFT consensus or realistic distributed adversary
Receipt verification	Receipt misuse for coercion, false confidence from incomplete verification	Receipt lookup and inclusion check	Not receipt-free and not coercion-resistant
Tally publication	Incorrect aggregation, manipulated tally artifacts, compromised authorities	Homomorphic aggregation, threshold-supported artifacts, authority signatures	Authorities are not independently deployed; full independent verification is limited

summarizes the main vulnerability classes associated with each voting phase. Since the present prototype does not include empirical attack-probability estimation or a formal adversarial probability model, the risk level is reported qualitatively. The purpose of this analysis is to make the security assumptions and residual risks of each phase explicit.

Table 3 shows that the strongest protections in the current prototype concern eligibility control, repeated-vote prevention, receipt inclusion checking, and audit-state consistency. The main residual risks are concentrated in areas that require stronger real-world assumptions or additional cryptographic protocols: client-device compromise, coercion and vote buying, absence of a full independently verifiable ZKP layer, lack of BFT consensus, and non-independent deployment of tally authorities. Therefore, the phase-level analysis confirms that the prototype should be interpreted as a controlled research implementation with explicit residual risks, rather than as a complete operational e-voting security solution.

3.5. Cryptographic Mechanisms of the Constructor

The architectural differences in the proposed approach are determined not by a separate cryptographic primitive, but by their composition.

The proposed constructor uses the following key cryptographic mechanisms:

• Blind signature

The first basic mechanism is the blind signature, which is used to issue an anonymous token. This mechanism allows you to confirm the right to vote without disclosing the final identifier of the token to the authorization authority. Scientifically, this ensures a strict separation between the admission phase and the ballot phase.

2.

Ballot encryption

The second mechanism is ballot encryption. The contents of the ballot are not published in clear form in the blockchain record. Unlike models where there is direct recording in an immutable registry, selective choice records in this system are stored in the form of ciphertext, receipt and service cryptographic derivatives, instead providing greater confidentiality.

3.

Individual verifiability (receipt-based verification)

The third mechanism is receipt-based individual verifiability. After submitting the ballot, the voter receives a hash receipt, according to which he can check the availability of his entry in the system. This mechanism does not provide the full receipt-freedom property, but it enhances individual verifiability and trust in the ballot inclusion procedure. It is important to distinguish receipt-based individual verification from receipt-freeness. In the current prototype, a receipt hash allows a voter to check whether the submitted ballot has been included in the confirmed record. However, this mechanism should not be interpreted as a coercion-resistant or receipt-free protocol. If a receipt or related verification information can be shown to a third party together with contextual information, it may create risks in coercion or vote-buying scenarios. Therefore, receipt verification in the current framework is treated only as an individual inclusion-checking mechanism within the prototype threat model, not as evidence of coercion resistance.

4.

Homomorphic aggregation

The fourth mechanism is homomorphic aggregation of ballots. It allows the system to publish an aggregated result without disclosing individual votes. In the proposed architecture, this layer enhances the public verifiability of the final count.

The homomorphic tally construction in the prototype is specified as follows. In the implemented prototype, the homomorphic tally layer follows an ElGamal-style exponential encoding over a multiplicative group modulo a large prime p. Let g be the public generator, x the tally private key, and $y=g^{x}mod\ast p$ the tally public key. For each voting option, the ballot is encoded as a one-hot vector $m_i\in \left\{\mathrm{0,1}\right\}$. Each component is encrypted as $C_i=({c1}_i,{c2}_i)$, where ${c1}_i=g^{r}mod\ast p$ and ${c2}_i=y^r{g}^{\left\{m_i\right\}}mod\ast p$ for fresh randomness r. The ciphertext format stored by the prototype is a JSON object with hexadecimal fields c1 and c2.

For each ballot, the prototype verifies that each encrypted component represents a binary value and that the encrypted vector sums to one selected option. This is implemented through Chaum–Pedersen-style equality checks for the encrypted components and an aggregate sum proof over the product of the ciphertexts. These validity checks are used to reject malformed ballots in the implemented prototype before they enter the confirmed tally. Nevertheless, this layer is not equivalent to a complete zero-knowledge ballot-validity proof system. The prototype still relies on implementation-level verification logic and does not provide a formally specified, independently verifiable non-interactive zero-knowledge proof for every ballot. Therefore, the current system should be interpreted as having a limited ballot-validity checking layer rather than a complete ZKP-based verifiable voting construction.

Homomorphic aggregation is performed by component-wise multiplication of ciphertexts for the same option across all confirmed ballots. For option j, the aggregate ciphertext is $C_j=\prod C_{\{i,j\}}$. Decryption removes the shared secret ${C1}^x$ and then recovers the tally by bounded discrete-log search over the expected voter-count range. Tally verification in the prototype consists of checking the ballot validity artifacts, verifying that the aggregate is computed from confirmed ledger ballots, publishing the aggregate ciphertexts, and checking the threshold-supported tally artifacts and signatures.

5.

Threshold publication of the result

The fifth mechanism is the threshold-supported publication of the result. It is implemented through a model of logically separated tally authorities that form signed artifacts. At the prototype level, this approach demonstrates how dependence on a single decision-making center may be reduced when publishing results.

In the current prototype, threshold support should be interpreted as logical and artifact-level threshold support rather than as a fully independent operational deployment of tally authorities. The prototype generates threshold-supported tally artifacts and authority signatures, but the authorities are not deployed as independent organizations, machines, jurisdictions, or administrative domains. Therefore, the trust-reduction effect is limited to the implemented research model and should not be interpreted as equivalent to a production deployment with independently operated authorities.

The combination of these mechanisms is not fixed. Depending on the selected security profile, the system can use different subsets of these primitives, which ensures the adaptability of the architecture to various voting scenarios.

3.6. The Role of Blockchain Audit

In the proposed constructor, the blockchain is considered as a layer of auditing and immutable event recording, rather than as a universal replacement for cryptographic protocols. This positioning is essential for the correct separation of security functions in the system.

The blockchain provides a chronologically ordered record of confirmed ballots, complicates the hidden modification of previously recorded data, and supports chain integrity verification. At the same time, privacy, anonymity and correctness of the ballot structure are provided not by the blockchain itself, but by external cryptographic mechanisms described in the previous section. The blockchain layer in this work should not be interpreted as an independent source of privacy, ballot correctness, or full decentralization. These properties depend primarily on the cryptographic mechanisms surrounding the ledger. In the current prototype, the blockchain is used as a blockchain-style append-only audit layer that provides chronological ordering, tamper-evident storage, receipt inclusion checking, and reconstruction of the confirmed ballot view. The present study does not claim or prove that this blockchain layer is more secure than a conventional append-only ballot board; rather, it evaluates one possible ledger-based audit implementation within a reproducible research prototype.

In this architecture, the blockchain audit performs three key functions:

(1)

recording of confirmed ballots;

(2)

support for subsequent verification of data immutability;

(3)

the formation of a publicly analyzed layer of events for audit and research.

Unlike traditional approaches, where the blockchain is considered as the main repository of votes, in the proposed system it is used as a specialized audit layer. By adopting this methodology, we can prevent the exposure of sensitive data and continue to maintain the flexibility of the architecture.

In the current instance this role has been further developed through the architectural transformation to an arrangement where the blockchain will function as an authoritative record of validated events; with the ballot board application table being a derived representation of that information from the blockchain. When using the validated results as the basis for creating a public ballot board and for producing a Homomorphically protected publication containing the results, that information will contain the same information being held in the chain, and the derived representation can automatically be validated against the information contained in the blockchain registry and be reconstructed from its record where necessary.

This approach reduces the risk of hidden falsification through modification of the local database and makes the audit layer not only descriptive, but also an operationally significant element of the system.

3.7. Parameterizability and Security Profiles

The key difference between the proposed approach and many existing prototypes is its parameterization at the level of security profiles. The system is not intended to represent a single fixed configuration; rather, it supports the analysis of several usage modes with different requirements for privacy, verifiability, transparency, and computational complexity. However, in the prototype, this parameterization is not implemented as a fully independent executable protocol pipeline for each security profile. Instead, parameterization operates at two levels: (1) implemented mechanisms that can be selectively enabled or combined, and (2) architectural and experimental profiles used for comparative analysis. Thus, the profiles should be interpreted as research-level configurations for studying trade-offs between security properties and computational cost, rather than as fully modular production-ready protocol variants.

In this work, a parameterizable designer is defined as a research framework that represents an electronic voting scenario as a configurable design space:

$$D=(A,B,L,T,V,P,M)$$

where A denotes the set of authorization mechanisms, B denotes the set of ballot-protection mechanisms, L denotes the set of audit ledger or bulletin-board layers, T denotes the set of tallying mechanisms, V denotes the set of verification mechanisms, P denotes the set of security profiles, and M denotes the set of measurable performance and integrity metrics.

A concrete voting configuration c generated from D is obtained by selecting specific elements from these sets:

$$c=\left(a,b,l,t,v,p,m\right)$$

where a ∈ A, b ∈ B, l ∈ L, t ∈ T, v ∈ V, p ∈ P, and m ⊆ M. In the prototype, this definition is implemented at the level of executable mechanisms, architectural profiles, and experimental configurations.

Thus, the proposed designer is treated as a system model rather than only as an architectural description: selected configurations can be instantiated in the prototype, executed, tested, and evaluated by means of performance measurements.

This research-level parameterization provides a constructor that can be used for different types of experimental scenarios, including low-risk elections emphasizing the integrity of the election and basic auditing; high-risk elections using anonymous authorizations, encrypted ballots, homomorphic aggregation, and threshold-supported publication of results. Thus, parameterizability becomes one of the central scientific elements of the proposed concept.

Several typical security profiles can be distinguished, corresponding to different architectural modes of the constructor:

• The basic level is the use of a minimal set of cryptographic mechanisms with an emphasis on integrity and ease of implementation;
• Standard level—adding anonymous authorization and ballot encryption;
• High level—the use of homomorphic aggregation and elements of threshold cryptography;
• Advanced level—the most complete set currently implemented in the prototype, including anonymous authorization, encryption, homomorphic counting, and threshold-supported publication of results.

Thus, the system can adapt to various voting scenarios without changing the underlying architecture, which distinguishes the proposed approach from most existing fixed protocol solutions.

For a more formal representation of parameterization,

Table 4. Security profiles of the parameterizable constructor.

Profile	Target Scenario	Active Mechanisms	Expected Properties	Main Limitations	Scientific Role in the Article
basic	Low-risk local voting	Authentication, role management, blockchain audit, basic integrity verification	Eligibility, basic uniqueness, auditability	There is no strong anonymization, no threshold layer, no developed public verifiability	It is used as a basic profile for comparison with enhanced modes.
standard	Institutional elections	Anonymous token, encrypted ballot, receipt verification, public ballot board	Enhanced privacy, individual verifiability, better unlikability compared to basic	There is no strong threshold decrease in confidence, there is no full stack of evidence	Shows the transition from simple secure voting to cryptographically enhanced
high_assurance	Highly significant research-level choices	Anonymous blind signature authorization, encrypted ballots, proof of the correctness of the ballot, homomorphic counting, threshold-supported publication of the tally	Stronger privacy, integrity, improved public verifiability, more pronounced decrease in trust concentration	Counting bodies are not operationally independent, there is no complete ZKP stack, there is no coherence resistance	This is the main profile of the article and the main carrier of scientific novelty.
advanced_protection	The upper experimental configuration of the research prototype	All advanced _assurance mechanisms plus a reinforced 3-of-5 threshold layer and more expensive publication of the result	The most powerful configuration in the current prototype privacy/verifiability/trust-reduction.	It does not implement a full-fledged independent organ infrastructure and a full ZKP stack	As an example for developing new products, this is the final comparative model for the designer (comparative production), not a general operational model.

describes security profiles as architectural modes of the constructor.

It should be noted that in this prototype, the security profiles are implemented in part as “security profiles” (executable mechanisms) and architecturally/experimentally. This does not reduce the research value of the designer, but it requires careful differentiation between what is already implemented in the code as a separate execution logic and what acts as a direction for further strengthening the architecture.

4. Threat Model and Security Properties

4.1. Threat Model

For the correct interpretation of the results, the proposed system is considered within the framework of a limited but clearly formulated threat model. The threat model of the current work is intentionally limited to the research-prototype setting. The prototype primarily considers threats related to eligibility violation, repeated voting, ballot tampering after submission, receipt-inclusion failure, inconsistency between the confirmed ledger state and the application state, and partial trust concentration in tally publication. Several important real-world electronic voting threats are not fully addressed in the current implementation. These include voter coercion and vote buying, malware or compromised voter devices, large-scale denial-of-service attacks, side-channel leakage, fully compromised authorities, and Byzantine behavior in a genuinely distributed network. These threats are acknowledged as essential for production electronic voting systems, but they remain outside the implemented threat model or are only partially discussed as limitations and future work. It is assumed that the adversary may try to influence certain stages of the electoral process, including authentication, issuing an anonymous token, submitting a ballot, storing the application status, publishing the result, and auditing. At the same time, in the context of a research prototype, the following classes of threats are considered the most realistic.

Table 5. Scope of the threat model in the current research prototype.

Threat Class	Status in the Current Work	Interpretation
Eligibility violation	Addressed at prototype level	Controlled through voter registry, authentication, and anonymous token issuance
Double voting/replay	Addressed at prototype level	Controlled through one-token issuance, token-spending checks, and repeated-submission rejection
Ballot tampering after submission	Addressed at prototype level	Detected through receipt hashes, chain validation, and audit consistency checks
Invalid encrypted ballots	Partially addressed	The prototype performs implementation-level ballot-validity checks, but it does not provide a complete independently verifiable ZKP layer.
Receipt-inclusion failure	Addressed at prototype level	Checked through receipt-based verification against the confirmed ballot record
Result-state inconsistency	Addressed at prototype level	Confirmed results are derived from the ledger and checked against the application state
Trust concentration in tallying	Partially addressed	Threshold-supported artifacts reduce trust concentration but do not fully eliminate it in the co-located prototype
Voter coercion and vote buying	Out of scope	No receipt-freeness or coercion-resistance protocol is implemented
Malware on voter devices	Out of scope	The prototype assumes an honest or controlled client environment.
Denial-of-service attacks	Out of scope	Availability and network-level resilience are not evaluated
Side-channel leakage	Out of scope	Timing and metadata leakage are acknowledged but not formally analyzed
Compromised authorities	Partially addressed	Authorities are logically separated, but they are not independently deployed in the current prototype
Byzantine distributed behavior	Out of scope	The prototype does not implement BFT consensus or a real adversarial multi-node network

summarizes the scope of the threat model by distinguishing threats addressed at the prototype level, threats partially addressed by the implemented mechanisms, and threats that remain outside the current implementation.

Coercion resistance and receipt-freeness are outside the implemented threat model. The prototype does not provide fake credentials, revoting with last-vote-counting, deniable receipts, untappable channels, or other mechanisms commonly required for coercion-resistant electronic voting.

First, an adversary is considered who tries to submit more than one ballot by reusing the token, resending the request, or circumventing application restrictions. The second factor identifies adversary attempts to alter application data after submission of a ballot, including changes to local storage, alteration of previously confirmed records, and inconsistencies between the blockchain and the representation of the state derived from the blockchain. The third factor identifies observers attempting to reconstruct the link between a voter and their ballot, using various means based on the voter’s metadata, time correlation, or features of the server environment. The fourth consideration is whether the adversary will distort or substitute artefacts of the published results, such as total published results, receipts, or aggregation of values or thresholds supporting the total published amount. However, the current threat model has intentionally not covered a number of additional and more serious cases of the threat to the current model.

These additional examples include total independence of multi-domain threat authorities in order to compromise the threshold authority; some advanced examples of the threat of voter coercion; complete takeover of the total computing infrastructure covering the entire distributed computing infrastructure with independent side channel analysis; and the absence of a resistance to Byzantium attack on a distributed consensus in a true multi-node network. The current limitations of the prototype correspond to the research status and must be accounted for when making claims.

In terms of prerequisites for trust, the current project assumes that the local execution environment will include the web contour, the service node, the database and the file keystore are all part of the same research stand. For this reason, the designed architecture is primarily focused upon reducing the naive and hidden modifiability of confirmed state, increase verifiability and reduce the direct link between ballot and identity, but not to completely eliminate all sources of trust.

4.2. Security Properties

Taking into account the specified threat model, the following security properties are analyzed in the work, which determine the scientific and applied value of the proposed designer.

• Eligibility: the right to participate in voting should be granted only to registered and admitted participants;
• Uniqueness: a participant should not be able to submit more than one valid ballot within the same electoral process;
• Privacy: The ballot record and the relationship between the participant and their election should remain obscured to external observation by the protection model implemented in the system;
• Integrity: Confirmed records should not undergo changes in an unnoticeable way after being placed in the confirmed area of the system;
• Individual verifiability: The ballot should have a way to verify (prove) there is a record of your ballot being included in the official confirmed states and an external observer will be able to verify that record as well through the use of the public ballot board and the confirmed chain.
• Audit Trail: A record of transactions showing all the steps in the history of all events, the status has been confirmed, and the final outcome of a publication is available to be validated against a predefined list of potential outcomes.
• Reduced Trust: The architecture must minimize centralization of trust, even if this is only partial for current implementation and prototype.

This study proposes a new way of looking at the features of the architecture and implementation of a system, specifically, they will be analyzed together as a unit rather than in isolation. When comparing the architecture, implementation and experimental results with a single mechanism, they will look at how well each mechanism supports the characteristics of eligibility, uniqueness, privacy, integrity, verifiability, and auditability within the defined threat model.

5. Materials and Methods

5.1. Methodological Approach

The research was carried out in the logic of a project-oriented approach and evaluation based on a prototype. As part of this approach, a targeted secure electronic voting architecture is first formed, then a reproducible software prototype is implemented, after which its security properties, limitations, and computational characteristics are analyzed. Such a methodological choice is justified by the fact that the research task is not only theoretical, but also engineering and cryptographic in nature: it is necessary not only to describe the concept of secure voting, but also to verify its feasibility, connectivity of components and behavior in controlled experimental conditions.

The prototype is implemented as a research platform that combines a web interface, a ballot processing service loop, local storage, cryptographic procedures, and a blockchain audit layer. Within the framework of the article, it is considered not as a commercial product, but as a tool for testing the integration of anonymous authorization, ballot encryption, receipt verification, homomorphic tallying, and threshold-supported tally publication. As discussed in Section 3.6, the blockchain component is treated as an audit layer that is combined with cryptographic mechanisms, rather than as a standalone security solution.

5.2. Research Prototype

The implemented prototype includes two main logical circuits. The first circuit is responsible for user interaction: authentication, choosing a voting option, requesting an anonymous token, receiving a receipt, and launching verification procedures. The second circuit is responsible for receiving ballots, validating them, fixing them in the blockchain, publishing the results, and providing audit interfaces.

The system status is stored in a local database containing information about registered participants, elections, ballots, anonymous tokens, audit artifacts, and metadata for publishing results. Using this method provides the ability to repeat experiments and recreate any type of voting and attack situation.

The prototype provides a way to reduce the effect that the changing application state has on the confirmed results, by making the blockchain registry the source of truth and the application tables derived representations. The validated blockchain chain will serve as the source of truth for total (votes) calculations, public ballot board construction, homomorphic aggregate result creation while the ballot application table serves as a derived representation for verifying receipts, navigating through interfaces, and servicing scenarios. Before issuing key service data, an explicit consistency check of the derived representation with the chain is performed, and if a discrepancy is detected, the confirmed slice is automatically reassembled from the blockchain registry.

At the same time, this scheme operates within the same local trust zone of the research stand. The Web contour, the service API, the local database and the file storage of cryptographic keys operate in a common computing environment. This increases the reproducibility of experiments but does not eliminate the organizational concentration of trust. Therefore, the credibility of the blockchain registry in the article is interpreted as strengthening the integrity and auditability of the confirmed state within the prototype, rather than as a completely independent distributed trust model.

5.3. Security Profiles as an Object of Parameterization

An important part of the methodology is the use of security profiles. They allow the configuration of elections to be altered depending on the requirements for the level of protection and vary in the depth of anonymization, the degree of cryptographic verifiability, the complexity of publishing the results and the acceptable level of centralized trust. Thus, the constructor becomes a platform for comparative analysis of trade-offs between privacy, transparency, computational cost and operational complexity.

5.4. Experimental Methodology

The experimental part of the work is aimed at evaluating performance and investigating the costs incurred when using cryptographic mechanisms and blockchain auditing. The main metrics are considered:

• Authentication time;
• The time when the anonymous token was issued;
• The time of submission of the protected ballot;
• Receipt verification time;
• Block confirmation time;
• The e time of the basic publication of the result;
• The publication time of the threshold-supported result;
• Chain length increase;
• The number of published confirmation artifacts.

Measurements are performed in a local research environment, which reduces the impact of external network factors and focuses on comparing the internal computing costs of the various stages of the protocol.

We aimed to ensure reproducibility by conducting all trials using the same isolated votomony environment on the same software environment (Python 3.11, Python Software Foundation, Wilmington, DE, USA) and the same programmatic dependencies. We verified that the expected capabilities of the system were working correctly through automated testing prior to making computations. For the matrix benchmark run, a single scenario generator was used, which created a temporary isolated database for each configuration, reinitialized the state of the chain, formed a set of accounts and active selections with a set number of options. Thus, each scenario was measured under controlled reset conditions, and the impact of accumulated side effects between runs was minimized.

The experiments were conducted on a local MacBook Air (Apple Inc., Cupertino, CA, USA) workstation with an Apple M3 processor (Apple Inc., Cupertino, CA, USA), (8 cores: 4 performance cores and 4 efficiency cores), 8 GB of RAM, running macOS 26.2 (Apple Inc., Cupertino, CA, USA). The software part of the calculations was performed in an isolated conda environment (Anaconda Inc., Austin, TX, USA) with Python version 3.11.15 (Python Software Foundation, Wilmington, DE, USA).

It should be emphasized that the experimental setup is a local single-machine research environment. The web application, service node, local database, cryptographic key storage, and benchmark runner operate within the same test bed. Therefore, the reported measurements capture local prototype overhead and relative computational costs of the implemented mechanisms. They do not measure the performance of a distributed voting system with realistic network latency, concurrent voter traffic, independent tally authorities, real blockchain consensus, or adversarial network conditions.

The key reproducible set of results in the framework of the article is considered to be a fixed matrix run of 48 scenarios, including four security profiles, three values of the number of candidates (2, 3, 5) and four values of the number of voters. (3, 5, 10, 25). It is this set that is used as the main source for comparative conclusions on the profiles of the designer, whereas earlier small-scale measurements retain the role of an introductory estimate of the relative cost of individual protocol stages.

Automated Verification of the Correctness of the Prototype

Verification of the prototype implementation will perform automated verification versus manual with respect to its three levels.

The first level of verification is through service circuit testing where ballots are received, tokens are verified, transactions are recorded, results published and chains of evidence are examined. The second level of verification is through web testing whereby the various elements in the web/application interaction will be evaluated from a security and scenario perspective including authentication, user interaction and vote transmission. Therefore, by using both a standard benchmark testing tool along with SR&ED compliant methods for verification, the various services within this application should continue to remain consistent with the predefined properties of the technology employed in this application. Thirdly, tests of attack scenarios that replicate the typical types of violations (e.g., re-submissions, re-use of tokens, violations in votes collected, and any form of writing logic around the prototype) are executed.

Methodologically, this verification layer provides the ability to interpret experimental and/or comparative results as not being disjointed manual runs, but as results validated by the established functional integrity of the entire system. Therefore, automated tests are considered in the article as part of the evidence base along with benchmark artifacts, tables and visual reports.

6. Results

6.1. General Characteristics of the Results Obtained

In the course of the research, a reproducible prototype of a parameterizable designer of electronic voting scenarios with enhanced cryptographic protection was implemented and tested. It combines mechanisms for anonymous authorization, encrypted ballot submission, blockchain auditing, receipt verifiability, homomorphic publication of results, and threshold-supported artifacts of result publication. Both a software architecture to model secure voting scenarios and an experimental platform for evaluating computational costs were created.

The findings indicate that the proposed prototype architecture provided a greater diversity regarding security characteristics than typical voting schemes based upon basic blockchains at the research prototype stage, suggesting that while considering enhanced privacy and verifiability, there will be some reductions in computational burdens due to extra cryptography (most importantly during the creation of secure ballots and the publication of threshold-supported counts).

6.2. Results of Computational Experiments

The experiments reported in this section should be interpreted as prototype-scale micro-benchmarks rather than evidence of deployment readiness or large-scale scalability. The measured scenarios, including up to 25 voters and 5 voting options, are intended to evaluate functional behavior, relative computational overhead, and the cost of additional cryptographic mechanisms under controlled conditions. They do not provide sufficient evidence for national-scale or production-scale performance. The main measured values for the prototype under study on a small scale are shown in

Table 6. Average time values for performing basic operations on a prototype scale.

Number of Voters	Authentication, Seconds	Token Issuance, Seconds	Submission of the Ballot, Seconds	Checking the Receipt, Seconds	Block Confirmation, Seconds	Basic Publication of the Result, Seconds	Threshold-Supported Publication, Seconds
5	0.0211	0.0536	0.4343	0.0003	0.0109	0.0004	0.4643
10	0.0218	0.0550	0.4470	0.0003	0.0308	0.0008	0.4824
25	0.0218	0.0547	0.4419	0.0002	0.3117	0.0004	0.4759

.

The presented data allow us to highlight several important observations.

First, authentication, anonymous token issuance, and receipt verification operations maintain an almost constant cost within the range under study. This means that at the current scale, the computational complexity of these operations is determined mainly by the ongoing costs of application logic and cryptographic processing, rather than the number of ballots already cast.

Secondly, the submission of a secure ballot forms the main user cryptographic delay. The average time of this operation is approximately in the range of 0.43–0.45 s, which is significantly higher than the time of authentication and token issuance. This behavior is expected, since it is at this stage that ciphertext formation, homomorphic representation preparation, receipt calculation and server validation of the secure ballot structure are simultaneously performed.

Third, the block confirmation time increases with the number of ballots. Even on the moderate scale studied, there is a transition from an almost negligible cost on a small number of records to an already noticeable value with 25 voters. This confirms that the blockchain layer in the prototype does indeed carry the computational burden associated with packaging, confirming, and storing accumulated voting data.

Fourth, the threshold-supported publication of the result is the most expensive stage in terms of additional verifiability. Unlike the basic publication of the results, the time of which remains extremely short, the publication of the enhanced result is consistently in the range of about 0.46–0.48 s. This is because this stage includes not only the aggregation of the result, but also the generation, publication, and verification of additional artifacts involving logically separated counting bodies.

To enhance the experimental part, comparative runs were additionally performed for configurations that differ not only in the number of voters, but also in the number of choices, as well as the parameters of the threshold layer. The results are presented in

Table 7. Comparison of the computational cost of different constructor configurations.

Configuration	Auth Mean, Seconds	Token Mean, Seconds	Cast Mean, Seconds	Verify Mean, Seconds	Mine Mean, Seconds	Homomorphic Results, Seconds	Proof Artifacts
5 voters, 3 options, threshold 2-of-3	0.0324	0.1188	0.7138	0.00049	0.0151	0.7661	6
5 voters, 5 options, threshold 3-of-5	0.0412	0.1085	1.0436	0.00039	0.0403	1.4254	15

.

A comparison of Table 7 shows that the computational cost is determined not only by the number of voters, but also by the complexity of the voting configuration itself. When switching from three choices and a 2-of-3 scheme to five choices and a 3-of-5 scheme, the average time for submitting a ballot increases from about 0.71 to 1.04 s, and the time for publishing a homomorphic result with threshold support increases from about 0.77 to 1.43 s. Simultaneously, as the load on printed evidentiary artifacts rises from 6 to 15, they become increasingly difficult to manage. This growing complexity (in terms of ballot structures) indicates that managers will need to put forth substantial effort in order to reach a higher “confirmation” level for their work product (evidentiary artifacts).

The Experimental Data (from this designer) confirms that the computational cost associated with a work product created by the designer is not determined by one single parameter alone, it is determined by at least three interdependent variables, being: 1. The number of ‘voters’ 2. The number of ‘choices’ 3. The combination of the two parameters involved with determining the parameters for the ‘threshold’ Overall, this finding is quite significant. This observation is fundamentally important for the article, because it transfers the benchmark part from the level of a simple demonstration of delays to the level of an analysis of the configuration price of security.

Any larger-scale values discussed in this section should be interpreted as projections or exploratory stress indicators, not as direct experimental proof of scalability. A full scalability evaluation would require substantially larger voter populations, distributed deployment, realistic network conditions, adversarial load, and independent infrastructure components.

6.2.1. Visual Benchmark of the Constructor Profiles

To systematically compare the basic, standard, high_assurance, and advanced_protection profiles, a separate visual benchmark runner was prepared, which performs a complete voting scenario for each configuration of the number of candidates and the number of voters. Unlike static tabular measurements, this tool is designed not only for accumulating aggregated values, but also for step-by-step monitoring of the experiment and automatic detection of bottlenecks.

The startup logic is designed so that for each scenario, the total times of authentication, token issuance, ballot submission, receipt verification, block confirmation, basic result publication, homomorphic result publication, chain verification, and reading of the public ballot board are recorded. After each scenario is completed, the stage with the highest computational cost is automatically determined, which is interpreted as the current configuration bottleneck.

In practice, this has two important research effects. First, the designer’s profiles become comparable not only at the level of the conceptual description, but also at the level of the complete executable script. Secondly, it becomes possible to visually observe how the computational load profile changes with an increasing number of candidates and voters: for simple modes, the basic logic of authentication or vote recording may remain critical, while for enhanced modes, cryptographic ballot submission or publication of a result with threshold support becomes dominant.

An important feature of such a scenario tool is its interpretability. It generates not only tabular artifacts, but also a visual HTML report containing profile summary cards, comparative band diagrams, a heat map of bottlenecks, and scenario matrices based on the number of candidates and voters. Thus, the experimental part of the article is enhanced by the transition from separate delay tables to visual analysis of the configuration security price.

From a scientific point of view, this tool is also important because it makes the parameterizability of the constructor empirically observable. While in the theoretical part, security profiles are described as different modes of building a secure electoral process, in the visual benchmark run, these differences become measurable and visual. This is especially valuable for the article, as it allows us to link the architectural model of profiles with actual experimental artifacts and with the interpretation of system bottlenecks.

A complete run of the profile matrix was performed for 48 scenarios formed by a combination of four profiles, three values of the number of candidates (2, 3, 5) and four values of the number of voters (3, 5, 10, 25). The summary results of this run are presented in

Table 8. Summary results of the full matrix benchmark run of the constructor profiles.

Profile	Number of Scenarios	Average Total Script Time, Seconds	Advanced Total Time, Seconds	Average Time for Submitting a Ballot, Seconds	Average Publication Time of the Result, Seconds	The Dominant Bottleneck
basic	12	0.452	1.093	0.050	0.001	auth_total
standard	12	21.390	62.944	8.491	0.001	cast_total
high_assurance	12	21.501	63.358	8.239	0.805	cast_total
advanced_protection	12	22.277	66.407	8.471	1.034	cast_total

.

Several meaningful conclusions follow from Table 8. First, the basic profile is qualitatively different from the other modes: the computing load remains low in it, and the authentication phase is the main bottleneck in all 12 scenarios. Secondly, the transition to the standard profile has already radically changed the nature of the workload: the main bottleneck in all scenarios is the submission of the ballots, and the average total time of one scenario increases by more than an order of magnitude. Thirdly, the high_assurance and advanced_protection profiles demonstrate a further increase in the total cost compared to the standard; however, this increase is explained not only by the submission of the ballot, but also by the increase in the cost of publishing the result, which on average reaches approximately 0.805 and 1.034 s, respectively.

It is especially significant that the configuration of 5 candidates/25 voters turns out to be the most difficult scenario for all non-base profiles. For her, the total time reaches 62.944 s in standard mode, 63.358 s in high_assurance mode and 66.407 s in advanced_protection mode. Thus, the visual matrix benchmark confirms that an increase in the level of protection in the constructor leads to a systematic increase in the computational cost, with the main bottleneck remaining precisely the secure submission of the ballot, while the complication of the threshold layer is manifested primarily in the additional cost of publishing the result.

Detailed Scenario Matrices

As part of the evaluation of the proposed e-voting model, an analysis of computational costs for various scenarios and levels of protection was carried out. Four system profiles were considered: basic, standard, high_assurance, and advanced_protection, differing in the cryptographic mechanisms used.

A matrix was built for each profile, reflecting the time required to complete key voting stages depending on the number of candidates and the number of voters. The results allow us to identify the bottlenecks of the prototype and evaluate scalability trends within the limited experimental setting. The results for the basic profile are presented in

Table 9. Scenario matrix (basic profile).

Candidates\Voting Members	3	5	10	25
2	0.116 s Auth	0.225 s Auth	0.412 s Auth	1.022 s Auth
3	0.111 s Auth	0.230 s Auth	0.401 s Auth	1.087 s Auth
5	0.111 s Auth	0.222 s Auth	0.398 s Auth	1.093 s Auth

.

In the basic profile, the system demonstrates high performance, while most of the time is spent on the authentication stage. An increase in the number of voters leads to a linear increase in the execution time. The results for the standard profile are presented in

Table 10. Scenario matrix (standard profile).

Candidates\Voting Members	3	5	10	25
2	4.465 s Auth	7.486 s Auth	15.568 s Auth	38.482 s Auth
3	5.917 s Auth	9.279 s Auth	18.513 s Auth	48.323 s Auth
5	7.729 s Auth	12.652 s Auth	25.323 s Auth	62.944 s Auth

.

The standard profile shows a significant increase in transaction execution time due to the use of cryptographic ballot encryption mechanisms. The main load falls on the Cast stage. The results for the high_assurance profile are presented in

Table 11. Scenario matrix (high_assurance profile).

Candidates\Voting Members	3	5	10	25
2	4.881 s Auth	7.924 s Auth	15.163 s Auth	37.262 s Auth
3	6.185 s Auth	9.771 s Auth	18.889 s Auth	45.883 s Auth
5	8.485 s Auth	13.767 s Auth	26.444 s Auth	63.358 s Auth

.

The high_assurance profile provides an increased level of security through the use of blind signatures and homomorphic encryption, which leads to additional computational costs. The results for the advanced_protection profile are presented in

Table 12. Scenario matrix (advanced_protection profile).

Candidates\Voting Members	3	5	10	25
2	5.199 s Auth	8.072 s Auth	15.269 s Auth	37.070 s Auth
3	6.495 s Auth	10.190 s Auth	19.621 s Auth	47.711 s Auth
5	9.196 s Auth	14.778 s Auth	27.313 s Auth	66.407 s Auth

.

The advanced level of protection demonstrates the highest computational costs due to the use of threshold cryptography and additional verification mechanisms.

The experimental results show that an increase in the security level of the system leads to an increase in computing costs, especially at the stage of ballot formation. At the same time, the basic profile demonstrates high performance, but is inferior in terms of security. Thus, the choice of system configuration must take into account the balance between security and scalability.

6.2.2. Automated Verification Results

A separate result of the study is the confirmation of the functional integrity of the prototype by means of automated testing. On the current version of the system, a combined set of unit and integration tests was performed for the service layer, the web contour, and scenarios of attacking behavior. In total, this set includes 49 tests, all of which were completed successfully (OK) with a total execution time of about 29 s on the described research bench.

The scientific significance of this result lies not in the fact that tests exist as an engineering practice, but in the fact that they form a formalized verification layer of a reproducible research prototype. Service loop tests confirm the correctness of accepting transactions, publishing results, verifying the chain, and processing anonymous tokens. Web contour tests confirm the correctness of user authentication and vote sending scenarios. Tests of attacking scenarios demonstrate that the prototype in the supported threat model responds correctly to repeated submissions, incorrect requests, and attempts to violate voting restrictions.

In the context of the article, this allows us to interpret computational measurements and comparative results not as isolated experimental observations, but as data obtained against the background of confirmed functional stability of the prototype. Therefore, automated verification enhances the reproducibility of the study and reduces the risk that quantitative results are caused by hidden regressions of the software implementation.

An additional practically significant result was the implementation of an operational circuit for monitoring the integrity of the confirmed state. In the current version of the prototype, the audit interface shows a separate consistency status between the results obtained from the chain and the derived application representation of the ballots and also allows you to initiate manual reassembly of the confirmed representation from the blockchain registry. This means that integrity control in the prototype is presented not only as a theoretical property, but also as an observable and reproducible maintenance workflow.

6.3. Interpretation of the Results from the Point of View of the Security Architecture

The results obtained confirm the central hypothesis of the study: the integration of several cryptographic mechanisms and a layer of blockchain audit in a single designer makes it possible to enhance the security properties of electronic voting, but it is accompanied by measurable computational costs. These costs are not accidental, but structurally explicable.

The low and stable cost of authentication and anonymous token issuance shows that the separation between the admission phase and the ballot phase can be implemented without a critical deterioration in user interaction. This is important because one of the typical criticisms of complex cryptographic voting schemes is the possible excessive increase in overhead costs already at the login stage.

On the other hand, the measured cost of submitting a ballot shows that it is the cryptographic protection of the ballot and the associated validation that are the main center of computational load in the architecture under study. This is natural, since this phase focuses on the main mechanisms that ensure privacy, the correctness of the ballot structure and the possibility of subsequent verifiability. Additional configuration runs show that this burden increases as the number of choices increases, as the one-hot presentation of the ballot and the associated evidentiary verification layer become more complex.

Of particular importance is the interpretation of the costs of threshold-supported publication of the tally. The observed difference between the almost instantaneous basic publication of the result and the significantly more expensive enhanced publication should not be interpreted as a sign of a failed architecture. Rather, it reflects a trade-off between the simplicity of basic tally publication and additional verifiability support. Additional comparative runs show that this compromise also depends on the parameters of the configuration itself: increasing the number of tally authorities and the participation threshold increases the cost of verifiability, while also increasing the number of supporting artifacts available for tally publication.

The computational-cost analysis should be interpreted critically. The measured overheads demonstrate where the implemented prototype spends time under controlled local conditions, but they do not establish that the proposed approach is more efficient than existing systems. In particular, the present study does not include an external benchmark against systems such as Helios, Belenios, or deployed blockchain-based voting implementations. Therefore, the performance results should be understood as internal configuration-level measurements of the proposed prototype, not as comparative performance evidence.

Separately, it should be noted that in the current version of the prototype, the computational and architectural interpretation of the results is complemented by a layer of audit consistency control. The service compares the confirmed state obtained from the chain with the derived application representation, and the audit interface visualizes both the match status of the results and the results of the service reassembly of the confirmed state. Thus, the results of the article are based not only on benchmarks and unit tests, but also on a reproducible integrity control workflow.

6.4. The Results of the Analysis of Security Properties

A comparison of the implemented mechanisms with the formal security properties allows us to formulate the following conclusions.

The eligibility property is supported through the voter registry, authentication, and verification of the right to receive an anonymous token. Within the research prototype, this property is implemented at a strong application level, but it remains dependent on trust in the registration circuit.

The uniqueness property is implemented more convincingly. It uses restrictions on the issuance of one token per participant within the framework of one election, a register of the use of tokens, and a logic for preventing the re-submission of ballots. Within the framework of the prototype, this property is strongly supported.

The privacy feature is enhanced by separating authentication and ballot submission, applying blind signature, and storing encrypted ballot content instead of an open selection record. However, privacy is not complete yet, and the connection between the admission phase and the ballot submission phase is not completely eliminated, as risks of time correlation remain, local server metadata and part of the ballot verification logic remains concentrated in the server environment.

The integrity property is supported through receipt, chain immutability, and block confirmation. In the current architecture, this property is implemented convincingly enough for the level of a research prototype.

An additional enhancement of the integrity property in the current version of the prototype is achieved by transferring the confirmed results to the authoritative registry model. This means that the confirmed results, the public ballot board, and the homomorphic publication of the results no longer directly trust the mutable application representation of the ballots, but are derived from the confirmed chain and accompanied by a consistency check of the derived state.

From the point of view of the information security architecture, this enhancement is complemented by an explicit separation of the confirmed and unconfirmed state. Unconfirmed records are used as an intermediate operational layer, whereas a confirmed slice is interpreted as a derived representation from the chain and is subject to automatic or manual resemblance from the blockchain registry if a mismatch is detected. This separation reduces the risk of hidden distortion of the application tables, although it does not negate the trust prerequisites of the local stand.

The verifiability property is implemented on two levels. Individual verifiability is provided by the receipt mechanism and verification of recording activation. Public verifiability is supported through a public ballot board, verification of the status of the chain, publication of the aggregated result and artifacts of its confirmation. Despite this, the level of public verifiability should be assessed as enhanced but not completely trust independent.

The results obtained confirm that the scientific contribution of the work consists not in the development of a new separate cryptographic primitive, but in the proposal of a parameterizable constructor that combines several protocol and classroom mechanisms in a single architecture. It is the reproducibility, compositionality and the possibility of experimental research of various protection profiles that distinguish the proposed approach from many private demonstration solutions.

Consequently, the results of the work confirm the claimed scientific novelty in three aspects:

• In the architectural aspect, since an integrated secure voting model is proposed that surpasses a simple voting scheme based on the blockchain;
• In the protocol aspect, since anonymous authorization, ballot encryption, receipt verification, homomorphic aggregation and threshold-supported publication of the tally are combined;
• In the methodological aspect, since a reproducible research constructor has been created to analyze the trade-offs between security and computational cost.

7. Discussion

7.1. Scientific Significance of the Proposed Approach

The proposed constructor is of interest primarily as a research architecture that allows balancing engineering feasibility and cryptographic content. In many works on electronic voting, there is a gap between theoretically strong but difficult-to-reproduce schemes and simple demonstration blockchain prototypes that do not provide sufficient privacy and verifiability. The developed constructor occupies an intermediate, but scientifically productive position between these two classes of solutions.

Its value lies in the fact that it allows you to analyze electronic voting not as a single technology, but as a composition of complementary layers of trust. As discussed earlier, the architecture separates the roles of the main mechanisms: blind signatures support separation between identity and ballot submission, encryption hides the choice, receipts support individual verification, and homomorphic/threshold-supported tallying supports result transparency. This decomposition makes the system more suitable for scientific analysis and further increasing cryptographic rigor.

7.2. Comparison with Basic Blockchain Voting Models

Compared to basic blockchain-based voting systems, the proposed approach provides a stronger separation between the voting admission phase and the ballot submission phase. In the simplest blockchain models, voter registration and vote recording often turn out to be too closely related, which makes privacy conditional or even vulnerable. In the proposed constructor, such a connection is weakened by an anonymous token and encrypted ballot submission, although in the current prototype it is not completely eliminated at the level of all metadata and the server environment.

In addition, in simple blockchain-based voting schemes, the blockchain often acts both as an event log and as a carrier of the voting content. This creates a risk of excessive transparency. In the proposed architecture, the blockchain is used more correctly: as an audit and verification layer, rather than as a storage space for an open expression of will.

A significant difference between the current version of the prototype and simpler local schemes is that the blockchain chain is used not only as an external event log, but also as an authoritative source of confirmed status. This allows you to calculate confirmed results and restore a derived application representation from the registry when discrepancies are detected, which significantly increases the prototype’s resistance to direct modification of the local database.

7.3. A Compromise Between Security and Performance

One of the key conclusions of the study is that increased verifiability and a decrease in the concentration of trust are inevitably accompanied by additional computational costs. This is especially noticeable at the stage of publishing a threshold-supported result. However, such a computational surcharge has a meaningful interpretation: the system does not just take longer to perform operations, but exchanges additional time for the appearance of verifiable artifacts and for reducing the role of the only opaque subject of the publication of the results.

In the context of a scientific article, it is important to emphasize this very carefully. The measured delay should not be presented as a sign of production readiness or optimality. It should be interpreted as a quantitative expression of the architectural price for enhanced security and verifiability within the prototype.

Validation of Basic Statements

To increase the rigor of interpretation,

Table 13. Compliance of statements, confirmations and restrictions.

Statement	Confirmation in the Project	Limitation
The system separates the authentication of the voter and the submission of the ballot	The logic of login and anonymous token issuance is implemented separately from the submission of the ballot; blind-signature tokens are used	Token authority and other components have not yet been distributed across independent trusted domains
Voting rights can be anonymized through blind signature	Message blinding, blinded token signing, deblinding, and signature verification are implemented	Anonymity is limited by time metadata and a shared server environment.
The ballot is stored in encrypted form, not as an open choice on the blockchain	Ballot encryption, ciphertext storage, receipt hash and token fingerprint are implemented instead of the voter ID	The server is still able to decrypt the ballot in the current prototype trust model
The system supports individual verifiability	Implemented a receipt and a mechanism for verifying the inclusion of the ballot	This is individual verifiability, but not receipt-freedom
The system supports enhanced public verifiability	A public ballot board, chain verification, homomorphic publication of totals, and counting confirmation artifacts are implemented	Public verifiability is enhanced, but it is not completely trust-independent
The system verifies the correctness of the one-hot structure of the homomorphic ballot	Bit proofs and unit sum proof are implemented	This is the evidentiary verification layer of the ballot, but not the full stack of zero-knowledge proof
The system reduces the risk of repeated voting	Implemented one-token-per-vote, token spend registry and re-submission restrictions	Protection depends on the integrity of the server-side state and the protection of authority keys
The system supports threshold-supported tally evidence	Rating promotions, signed partial artifacts, and threshold session reconstruction	Authorities are co-located; this is a prototype threshold support, not a fully independent distributed authority architecture
The system has a blockchain audit and chain integrity control	Blocks, chain verification, ballot board and peer sync are implemented	The consensus is simplified and is not Byzantine-grade
The architecture is suitable as a research platform	The experimental measurement contour, attack tests, audit panel and documentation are implemented	The experiments are limited to a prototype scale and are not rich enough for a strong comparative study

links the key statements of the article with factual confirmation in the code and experimental artifacts, as well as with the limitations of correct scientific claims.

7.4. Limitations of the Current Prototype

Although the obtained results are encouraging, the present work has several important limitations. Not all security profiles are currently implemented as fully independent execution pipelines; some profiles remain architectural or experimental configurations used for comparative analysis. Therefore, the parameterizability claim should be understood as research-level configurability rather than as a complete implementation of separate executable protocols for each security level.

The most serious limitation has to do with not yet providing complete zero-knowledge proof stacks that authenticate ballot correctness and ensure the reliability of the published results without having to rely on trusting the server’s internal logic. Additionally, although third-party escrow accounts serve as proxies for greater trust, the contours of these escrows remain logically separate but have little in terms of their physical geographic locations or the jurisdictions in which they are maintained. Therefore, while trust has been diminished through both architectural and protocol-related changes, there still exists much room for organizationally overcoming differences in geographic and/or jurisdictional locations.

The homomorphic tally layer is specified and implemented at the research-prototype level. Although the prototype includes ElGamal-style encrypted tallying, ballot-validity checks, aggregate ciphertext publication, and threshold-supported tally artifacts, it does not provide a complete formally verified cryptographic protocol specification or a production-grade non-interactive zero-knowledge proof system. A more rigorous specification of the proof system, decryption protocol, and independent tally verification procedure remains future work. Consequently, the prototype assumes that the implemented server-side validity checks are correctly executed before ballots are confirmed. It does not eliminate the need for a full independently verifiable ZKP layer in a production voting system.

Finally, the current system does not address issues of coercion resistance as well as does not provide any significant degree of receipt-free elections; thus, it cannot be considered a viable solution for even the most risky and difficult to administer socio-political elections.

A separate limitation concerns receipt-based verification. Although receipts improve individual confidence by allowing voters to check inclusion of their ballots, the current receipt mechanism is not receipt-free. It does not prevent a voter from using receipt-related information as evidence in a coercion or vote-buying scenario. Consequently, the current prototype should not be presented as coercion-resistant; adding receipt-freeness or coercion-resistance mechanisms remains future work.

The threat model also excludes several important real-world adversarial conditions. In particular, the prototype does not address coercion and vote buying, malware on voter devices, denial-of-service attacks, side-channel leakage, fully compromised authorities, or Byzantine behavior in a real distributed deployment. These exclusions mean that the prototype should not be interpreted as a complete operational e-voting security solution. Instead, it should be viewed as a controlled research platform for studying selected cryptographic and audit mechanisms.

The experimental scale is another important limitation. The measured benchmark scenarios are limited to prototype-scale settings, including up to 25 voters and 5 voting options. These results are useful for identifying relative computational costs and bottlenecks, but they do not support claims of production scalability or deployment readiness. Larger-scale experiments under realistic distributed and adversarial conditions remain future work.

The performance evaluation is also limited by the local execution environment. All experiments were conducted on a single research machine without distributed network interaction, realistic concurrent voting, real blockchain consensus, or independently deployed authorities. Consequently, the reported results should be interpreted as measurements of local prototype overhead, not as evidence of real distributed system performance.

The comparison with existing systems is also limited. The manuscript provides a qualitative and feature-oriented comparison with representative systems and research directions, but it does not include direct benchmarking or formal security comparison against existing implementations such as Helios or Belenios. Such comparative experiments would require harmonized deployment conditions, equivalent election configurations, and access to comparable implementations, and remain future work. For this reason, the computational-cost discussion is limited to internal prototype configurations and should not be interpreted as an external performance comparison.

The blockchain verification mechanism is still too simple when compared to Byzantine fault tolerant distributed consensus mechanisms and many other blockchain based voting systems have been criticized for this in the current literature search. Therefore, vague references to a high degree of decentralization can only be made with limited accuracy.

Node service circuits are not currently separated from general administrative services so that they can be protected adequately. In addition, mining operations, revalidation of confirmed status representations and neighbor node registrations are being performed as research test bed functions and need to be enhanced by separate authentication and authorisation to the service APIs.

Cryptographic keys and threshold shares are currently being stored locally to the research test bed file system and database. This simplifies the reproducibility and automation of experiments, however this means that if an attacker compromises a node, they will obtain more powerful capabilities than if they were in a hardware or organisationally separated location for the storage of secret information.

These limitations significantly restrict the practical applicability of the current prototype. In its present form, the framework should not be considered suitable for high-stakes public or national elections. Its practical use is limited to research, education, laboratory experimentation, and controlled institutional or low-risk voting scenarios where the assumptions of the prototype threat model are acceptable. For use in high-stakes political elections, the framework would require substantial extensions, including coercion resistance, receipt-freeness, independently deployed threshold authorities, Byzantine fault-tolerant consensus, hardened client environments, and large-scale distributed evaluation.

Correct Statement Boundaries

In order to preserve scientific integrity, the results of the article should be interpreted within the framework of a clearly limited research position. The presented system is a research prototype, not a complete national-scale system and not a full-scale operational electronic voting platform.

This leads to several fundamental restrictions on permissible statements.

Firstly, the results of the article should not be formulated as evidence of the system’s readiness for state or national implementation. The correct formulation is that the proposed architecture demonstrates a reproducible and experimentally researched way to enhance the security of electronic voting at the prototype level.

Secondly, public verifiability in the current version of the work should be characterized as enhanced, but not as completely trust-independent or cryptographically complete. Despite the presence of a receipt check, a public ballot board, homomorphic publication, and confirmation artifacts, the system does not yet implement a full stack of zero-knowledge proof for all stages of the protocol, and some of the checks rely on server-side supported data.

The location of the contour of the threshold for publication of results will be seen as an indication of a prototype model with the threshold-supported infrastructure being distributed to the threshold authority’s separate location and with no linkage to other locations. The logical separation and the presence of signed artifacts provide confidence in the model, however the model does not remove all trust from organisations and in the current implementation the publication of results will rely on local initations of the organs and secret reconstruction in the research setting.

Architecture should not be treated as the solution for people who find it difficult to resist coercion, as is evident from the overall unevenness and lack of receipt free existence, indicated in point about this thesis, item B. Because of this reason, authors should confine themselves to using their designs in contexts related to research, education, institutions or prototypes rather than the most vital social and political elections of our time.

Fifth, when you describe the blockchain part of the system, think of it as acting only as an auditing and fixing layer rather than as a stable decentralized consensus model (with respect to Byzintine stability/decentralization). This formulation matches how the system actually works and makes claims that decentralization is overstated.

Sixth, when thinking about the credibility of the blockchain registry, view the trust model used in this project as being the research bench trust model. In this project, that means giving priority to validated chains vs. application-derived representations in calculating totals and conducting audits while still maintaining the existence of your local trust zone (Web container, Service node, Local DB and Cryptographic Key Storage) working together for one end.

It is this kind of honest frame that makes the article stronger, not weaker. It shows that the author does not confuse prototypical verification of an architectural hypothesis with a statement about the complete completeness of a cryptographic or organizational model of electronic voting.

7.5. Limitations of Interpretation of Results

There are several limits to the accuracy of interpreting these results.

The first limitation is that all of the computations were conducted in a local research environment. Although this reduces the amount of time that measurements could be replicated, it limits the portability of the conclusions to distributed infrastructures that have higher latencies in their networks and independent services to service failures to a more complicated degree than would be expected from any one service.

Secondly, while the experiments are exploratory and prototype in nature, the nature of the results is only representative of the research environment; therefore, these results can not be used to support assertions about either industrially available productivity or productivity at a national level.

Third, the threshold circuit in the current version of the architecture remains logically separated, but not completely operationally independent. Therefore, conclusions about a decrease in trust concentration should be interpreted as a prototypical decrease in trust concentration, and not as a definitively achieved distributed trust model.

To clarify, while an evidentiary verification layer does improve the ability to verify a document’s structure, it does not provide a complete mechanism to create “zero disclosure” evidentiary proof. Thus, public verifiability should only be assessed based on the extent to which a ballots structure has been improved beyond what would otherwise be allowed for independent verification.

The blockchain layer utilized in this prototype is aimed at providing auditable and immutable records and not a Byzantinely stable decentralized consensus system, so it should be regarded as a cryptography-enriched research prototype as opposed to a fully decentralised election network.

In addition, the current work does not provide a formal comparative proof that the blockchain audit layer improves security over a conventional append-only ballot board. The blockchain-style ledger is used as one possible implementation of an append-only audit mechanism within the prototype. A systematic comparison between blockchain-based audit layers and conventional append-only ballot-board constructions remains an important direction for future work.

Sixth, the local storage of keys, threshold shares, and the availability of node management service operations without a separate production administration loop mean that the results of the article should not be interpreted as confirmation of the operational maturity of the secure infrastructure. They confirm the research applicability of the architecture and the usefulness of the implemented mechanisms within the framework of a controlled stand.

7.6. Prospects for Further Development

The most natural course of development is to strengthen the current prototype towards a more rigorous distributed trust model. In particular, the following steps are promising:

• Placing the publication threshold authorities in independent processes or services;
• Introduction of separate authentication and authorization for administrative operations of the service node;
• Bringing cryptographic keys and threshold shares into a more isolated secret storage loop;
• Development of the evidentiary verification layer towards more formalized mechanisms with zero disclosure;
• Expansion of the experimental base in terms of the number of voters, the number of choices and the number of publication bodies of the results;
• Deeper comparative analysis with mix-net and full-format homomorphic voting schemes;
• Formalization of confidence assumptions and constraints in a mathematically more rigorous form.

It is these areas that can transfer the current constructor from the status of a strong research prototype to the status of a more mature doctoral cryptographic platform.

8. Conclusions

This paper presents a parameterised constructor for electronic voting scenarios with enhanced cryptographic protection through the use of cryptographic protocols, and blockchain audits. Unlike simple blockchain-based voting systems, where each of the before mentioned components would be separate processes, this model incorporates anonymous credential authorisation, encryption of ballot submissions, provision of individual receipt verifiability, homomorphic distribution of vote counts, and provision of threshold based final count confirmations as part of a single reproducible research architecture.

The research demonstrated the feasibility of this type of architectural design as a research prototype and provided a mechanism for greater levels of both the privacy, integrity and verifiability of transactions than would normally be found with less advanced types of blockchains. The study demonstrates the feasibility of the proposed architecture as a research prototype and identifies the main sources of computational overhead. The highest costs are associated with encrypted ballot construction and threshold-supported tally publication, while authentication, anonymous token issuance, and receipt verification remain comparatively lightweight at the studied prototype scale.

The scientific significance of the work lies in the system integration and parameterization of several cryptographic mechanisms within a single research platform. The practical significance lies in the creation of a tool for demonstrating, analyzing, and further developing cryptography-supported electronic voting scenarios. The presented result should be considered a research prototype, not a complete national electronic voting system. Parameterization should be interpreted as a research-level mechanism for exploring configuration trade-offs rather than as a fully modular production-ready system. Further development should focus on strengthening the zero-knowledge component, independently deploying threshold authorities, and expanding the formal trust and security model.

Summarizing the results of this research study, we have:

• Proposed A parameterized constructor for electronic voting scenarios with enhanced cryptographic protection by considering the admission, anonymization, ballot submission, auditing and result publishing as a combination of agreed-upon security mechanisms.
• Implemented an experimental working prototype that utilizes blind signed anonymous ballots, encrypted ballot submissions, a blockchain audit, verifiable receipts, homomorphic aggregation, and threshold-based result publishing.
• Compared our implemented architecture against formally established security properties and the defined limitations of our defined threat model.
• A multidimensional experimental evaluation of computational costs for security was performed and includes comparisons of security profiles, numbers of voters, numbers of choice options, and threshold boundary parameters.
• Confirmed the functional stability of the prototype using a fully automated software verification process.