Keywords

1 Introduction

Blockchain is quickly becoming one of the most useful technologies for e-Voting due to its traceability, transparency, high-trustability, immutability, and distributed performance characteristics. While designing a blockchain-based e-Voting system (BES), design of a wide variety of layers is involved. These layers include, but are not limited to, storage layer, auditing layer, aggregation layer, administration layer, election management layer, etc. Figure 1 shows a typical BES model that allows for the visualization of these elements and their internal data flow.

Fig. 1
A schematic illustration of several units linked to a cloud-shaped icon.

Typical blockchain-based e-voting model

Full size image

The model initiates with election preparation services, wherein voter list, party list, election rules, etc. are decided. This information is given to an administration module, where details about file server, database, administrator, application server, etc. are stored. These layers are synchronized using Governmental authorities, and election-specific rules are enforced. Based on these rules, the e-voting process is started, and voters are requested to cast their votes using smart phones, and other e-Platforms. Each set of votes is added to a smart contract, and these contracts are stored on multiple blockchain nodes [1]. The following actions are carried out while adding a block to the blockchain: The block is encrypted using high-efficiency encryption techniques like elliptic curve cryptography (ECC) Each block is hashed using a secure hashing algorithm (SHA) Before adding a block, it is checked for uniqueness, wherein the block hash is compared with hashes of already stored blocks. Based on these components, the following delay equation is modeled,

$$ {\text{New}}_{{\text{delay}}} = N*\left( {{\text{Read}}_{{\text{delay}}} + {\text{Hash}}_{{\text{delay}}} + {\text{Check}}_{{\text{delay}}} } \right) + {\text{Write}}_{{\text{delay}}} $$
(1)

where N represents a number of blocks already present in the chain, while New, Read, Hash, Check, and Write represents delay for adding a new block, delay for reading old blocks, hashing delay, delay for comparing current block with other blocks, and delay for writing the block to the blockchain. It can be shown from Eq. 1 that as the number of blocks grows, so does the time required to add a new block to the blockchain. It has been noted that the delay for adding blocks using distributed blockchain (DB) [2], consortium blockchain [3], or smart contracts [4] follows a roughly exponential curve in relation to the number of blocks. Thus, various techniques are proposed for reducing this delay, which includes side chain creation, increasing block length, etc. The next section reviews these techniques and discusses their intricacies, benefits, drawbacks, and potential applications in further research. The design of the suggested firefly-based side chain creation and management paradigm, which aids in enhancing the functionality of E-Voting systems, is then presented. In Sect. 4, the suggested model is tested, validated, and contrasted with several state-of-the-art methods across a range of applications. This essay concludes with some thought-provoking remarks on the suggested model and offers a number of suggestions for improvements to increase its capacity for real-time performance.

2 Literature Review

For e-Voting with side chains, a wide range of system models are put out, and each of these models is used for a specific user scale. For instance, to increase the scalability of e-Voting systems, the work in [5, 6] suggests trust-enhanced blockchain and access control-based blockchain. Similar to this, the work in [7] suggests many uses for an Oracle-based open-source decentralized blockchain that can be utilized to boost performance. This performance is measured in terms of quality of service (QoS) parameters including transaction delay, memory requirement, and throughput. Blockchain are further used for flying ad-hoc networks [8], corporate security systems [9], and industrial IoT [10] for solving multiple security and performance issues. All these models are equally applicable for e-Voting and are used while designing and optimizing block structures. Methods like delegated proof of stake (DPoS) [11], privacy preservation using smart contracts [12], Proof-of-Quality-Factor (PoQF) [13], and dynamic topology-aware blockchains [14] are further proposed by researchers for multiple application security. These models also find their usage in e-Voting via the reduction in delay and improvement in node-level scalability. In [15,16,17], a use case for these models is presented, in which a Blockchain-Assisted Certificateless Key Agreement Protocol is suggested for Internet of Vehicle (IoV) based voting scenarios, Secure Software-Defined Industrial Network voting scenarios, and Consensus Managed Reputation and Contract Theory-based IoV voting scenarios. By eliminating topological dependence, these protocols help to increase QoS and scalability performance.

Due to an increase in blockchain length, existing models adapt to side chaining, wherein the main blockchain is divided into multiple subparts, and each subpart is managed independently for secure communications. The work in [18,19,20,21] proposes such models, wherein researchers have discussed usage of Reputation-Based Coalition Formation, Streamlined Consensus models, Traffic Classification Services, and Trust Model for Malicious Node classification using side chains. These models assist in selecting side chaining as an alternative to single chained blockchains, which improves transaction speed while reducing dependency on singular chains. Based on this observation, the work in [22] proposes an Ethereum Smart Contracts-based E-Voting model, which reduces voting delay, and improves the efficiency of vote counting by storing multiple votes on a single block structure. A high trust model that uses Adjusted Blockchain Technology for trust (ABTT)-based voting is proposed in [23], wherein miner nodes are selected depending upon their location and computational efficiency. Similar models are put out in [24,25,26], where researchers talk about using IoT-based E-Voting systems, the privacy-preserving automatic voting tally mechanism (PriScore or PS), and Anti-Quantum E-Voting with an integrated Audit Function. These models are highly scalable, and reduce E-Voting complexity via truly distributed computing models. Based on these observations, a novel dual Genetic Algorithm (GA)-based model for the next section of this paper proposes side chain-based E-Voting. As seen in Sect. 4 of this text, where performance evaluation in terms of transaction delay, throughput, and storage capacity is exhibited for various scaling situations, this model is assessed on a wide variety of applications and compared with various state-of-the-art methodologies.

3 Proposed Novel Side Chaining Model for Improving Performance of Security-Aware E-Voting Applications

According to the literature review, the majority of current blockchain solutions for electronic voting are either not scalable or perform worse in terms of quality of service (QoS) when compared to non-blockchain alternatives. Some side chain implementations are proposed for this purpose, but their complexity increases with respect to increase in E-Voting data. In order to design a highly scalable E-Voting system with lower complexity, this section discusses a novel side chaining model that is able to create and manage side chains depending upon the number of cast votes. Figure 2 shows the suggested model and specifics of how it operates internally, as well as how side chains are created and managed. The current blockchain is observed to be reviewed for each new request, and either new sidechains are created or old ones are updated.

Fig. 2
A schematic diagram presents three units with a human figure linked to the unit in the middle.

Overall structure of the suggested model

Full size image

Thus, two different Genetic Algorithm models are required for managing the blockchains. The Genetic Algorithm (GA) is designed for new sidechain creation, in order to optimize sidechain length, and the number of votes stored per chain uses the original blockchain and divides it into multiple parts. The proposed GA model employs the following steps to function:

Initialize GA parameters

  • Number of iterations (Ni)

  • Number of solutions (Ns)

  • Learning rate (Lr)

  • Voting time limit (max DV)

  • The blockchain’s maximum length (max BL)

Mark each answer as “to be modified.”

For each of the 1 to Ns solutions, from 1 through Ni iterations.

Go to the next solution if the first one is marked as “not to be modified.”

Otherwise, create a new answer using the procedures below.

Using Eq. 2, divide the current blockchain into n random, unequal-sized chunks (Fig. 2).

$$ n = {\text{random}}\left( {\max_{{\text{BL}}} *L_{\text{r}} ,\max_{{\text{BL}}} } \right) $$
(2)

Number of blocks (NB) in each part is estimated using Eq. 3,

$$ {\text{NB}} = {\text{random}}\left( {\frac{{\max_{{\text{BL}}} }}{n},B_{{\text{REM}}} } \right) $$
(3)

where BREM represents number of blocks remaining to be allocated in sidechains. Select a random chain r out of these sidechains, and cast a dummy vote into this chain.

While adding a vote, estimate its voting delay using Eq. 4,

$$ {\text{DV}} = \left( {D_{{\text{read}}_r } + D_{{\text{check}}_r } + D_{{\text{hash}}_r } } \right)*{\text{NB}}_r + D_{{\text{write}}_r } $$
(4)

where \({\text{DV}},\;D_{{\text{read}}_r } ,\;D_{{\text{check}}_r } ,\;D_{{\text{hash}}_r } ,\;{\text{NB}}_r ,\;{\text{and}}\;D_{{\text{write}}_r }\) represents voting delay, delay to read one block from current chain, delay to compare hashes of one block from current chain, delay to hash the current block, number of blocks in current chain, and delay to write a block to the current chain, respectively.

Accept this solution, only if \({\text{DV}} < \max_{{\text{DV}}}\).

Else, again split the blockchain into multiple parts, and regenerate a new solution.

If, \(N_{\text{s}} *N_{\text{i}}\) combinations have been evaluated, and solution is not found, then create a new sidechain and cast all votes into this sidechain.

Evaluate fitness for this solution using Eq. 5,

$$ f = {\text{DV}}*\frac{n}{{{\text{BL}}^2 }}*\frac{{\sum_{i = 1}^r {\text{NB}}_i }}{r} $$
(5)

where r represents number of sidechains created by this solution.

Repeat this method for each solution, and then use Eq. 6 to estimate fitness threshold.

$$ f_{{\text{th}}} = \frac{{\sum_{i = 1}^{N_{\text{s}} } f_i *L_{\text{r}} }}{{N_{\text{s}} }} $$
(6)

where fitness exceeds the threshold, mark all solutions as “to be mutated,” and “not to be altered.” Choose the solution with the lowest fitness value after all iterations, and estimate the following parameters: (\(N_{{\text{SC}}}\)) Number of sidechains produced Each sidechain’s total number of votes (\(N_{V_{{\text{SC}}} }\))

Selected sidechain for casting the vote (\({\text{Sel}}_{{\text{SC}}}\))

Cast current vote into this sidechain, and use the given configuration for casting future votes. While casting these votes, check DV levels, and if \({\text{DV}} > \max_{{\text{DV}}}\), then a new sidechain must be selected or created. The following Iterative Genetic Algorithm (IGA) model is triggered to carry out this task: establishing IGA parameters.

  • Number of iterations (Ni)

  • Number of solutions (Ns)

  • Learning rate (Lr)

  • Voting time limit (Max DV)

Mark each answer as “to be modified.”

From 1 through Ni iterations, for each of the 1 to Ns solutions go to the next solution if the first one is marked “not to be modified.” Otherwise, create a new solution using the procedures below.

Select a random chain r out of the current sidechains, and cast a dummy vote into this chain.

  • While adding a vote, estimate its voting delay using Eq. 4,

  • Accept this solution, only if \({\text{DV}} < \max_{{\text{DV}}}\)

  • Else, select a new sidechain for casting the vote.

  • If, Ns combinations have been evaluated, and solution is not found, then create a new sidechain and cast all votes into this sidechain.

  • Evaluate fitness for this solution using Eq. 5.

  • Carry out this procedure for each solution, and then use Eq. 6 to get the fitness threshold.

  • Mark all solutions where fitness exceeds threshold as “to be mutated,” and mark other solutions as “not to be mutated.”

  • Select the sidchain with the lowest fitness value after all iterations, and estimate the following parameters:

  • Sidechain number (\({\text{Num}}_{{\text{SC}}}\))

  • Number of votes in current sidechain (\(N_{V_{{\text{CSC}}} }\))

Cast current vote into selected sidechain, and use the given configuration for casting future votes. Repeat the process if \({\text{DV}} > \max_{{\text{DV}}}\), which assists in formation of newer sidechains. Based on this process, a wide variety of sidechains with different sizes, and different votes per chain can be created. These sidechains are tested on numerous e-Voting applications, and the results are tallied in terms of transaction delay, throughput, and storage expense. In the following section of this article, it is described how the proposed model stacks up against alternative techniques based on these parameters.

4 Results Analysis and Comparison

Different optimization methods are used for sidechain creation and maintenance in the proposed dual GA architecture. The proposed sidechain concept was put to the test in a variety of e-Voting scenarios to gauge its effectiveness, including

  • Small-scale e-Voting, which is used to form consensus for less than 5 parties.

  • Moderate-scale e-Voting, which is used to form consensus for less than 10 parties.

  • Large-scale e-Voting, which is used to form consensus for more than 10 parties (Fig. 3).

    Fig. 3
    A workflow diagram elucidates the process involved in a model.

    Flow of the designed sidechain creation and management genetic algorithm (GA) model

    Full size image

Based on these scenarios, smart contracts were deployed using Ethereum blockchain in Solidity. Each scenario was evaluated terms of transaction delay (TD), throughput (Th), and storage cost (S). These values were estimated for the proposed model by varying number of votes casted by users, and were compared with DB [2], ABTT [23], and PS [25] for validating its performance. For small-scale voting application, number of votes casted were varied between 200 and 2000, and 5 participating candidates were considered during evaluation. Based on these parameters, transaction delay was estimated (Fig. 4).

Fig. 4
A graph titled transaction delay with four trends plots the units across the number of votes.

Transaction delay performance for different algorithms on small-scale voting applications

Full size image

The suggested model was found to be 15% quicker than DB [2], 8% faster than ABTT [23], and 26% faster than PS [25] for small-scale voting applications due to the usage of numerous GA models that are customized to reduce transaction delay. Similarly, the throughput (measured in Megabits per second, or Mbps), which represents the number of blocks mined in a unit of time, was seen for each of these models in Fig. 5.

Fig. 5
A graph titled throughput with four trends plots the through in Megabits per second across the number of votes.

Throughput performance for different algorithms on small-scale voting applications

Full size image

The suggested model was found to be 61% quicker than DB [2], 9% faster than ABTT [23], and 28% faster than PS [25] for small-scale voting applications due to the usage of numerous GA models that are tweaked to optimize sidechain length. The storage cost (in Megabits or Mb), which represents the average number of blocks stored per chain, was similarly displayed for each of these models in Fig. 6.

Fig. 6
A graph titled storage cost with four trends plots the storage cost in Megabytes across the number of votes.

Storage cost for different algorithms on small-scale voting applications

Full size image

The proposed model was observed to be 80% better than DB [2], 15% better than ABTT [23], and 40% better than PS [25] for small-scale voting applications in terms of storage cost due to the use of multiple GA models that are tuned to optimize sidechain length and number of blocks per sidechain. These benefits enable the suggested methodology to be implemented in small-scale e-Voting systems.

Similarly, for the moderate-scale voting application scenario, number of votes casted were varied between 8000 and 100 k, and 10 participating candidates were considered during evaluation. Based on these parameters, transaction delay was shown in Fig. 7.

Fig. 7
A graph titled transaction delay with four trends plots the transaction delay in milliseconds across the number of votes in thousands.

Transaction delay performance for different algorithms on moderate-scale voting applications

Full size image

The suggested model was found to be 25% faster than PS [25], 26% faster than ABTT [23], and 18% faster than DB [2] for intermediate scale voting applications due to the usage of numerous GA models that are optimized to reduce transaction delay. Similar to this, Fig. 8's throughput (in Megabits per second or Mbps), which represents the number of blocks mined per unit time, was displayed for each of these models.

Fig. 8
A graph titled throughput with four trends plots the through in Megabits per second across the number of votes in thousands.

Throughput performance for different algorithms on moderate-scale voting applications

Full size image

The suggested model was found to be 20% faster than DB [2], 6% faster than ABTT [23], and 19% faster than PS [25] for moderate-scale voting applications due to the usage of numerous GA models that are tweaked to optimize sidechain length. For each of these models, the storage cost (in Megabits or Mb), which reflects the average number of blocks stored per chain, is presented in Fig. 9.

Fig. 9
A graph titled storage cost with four trends plots the storage cost in Megabytes across the number of votes in thousands.

Storage cost for different algorithms on moderate-scale voting applications

Full size image

In terms of storage cost, the suggested model was found to be 20% better than DB [2], roughly the same as ABTT [23], and 10% better than PS [25] due to the usage of various GA models that are modified to optimize sidechain length & number of blocks per sidechain. These benefits make the suggested model suitable for deployment in any intermediate scale e-Voting application.

Similarly, for the large-scale voting application scenario, number of votes casted were varied between 500 k and 20 M, and 45 participating candidates were considered during evaluation. Based on these parameters, transaction delay is shown in Fig. 10.

Fig. 10
A graph titled transaction delay with four trends plots the transaction delay in milliseconds across the number of votes in thousands and millions.

Transaction delay performance for different algorithms on large-scale voting applications

Full size image

The suggested model was found to be 18% quicker than DB [2], 16% faster than ABTT [23], and 10% faster than PS [25] for large-scale voting applications due to the usage of numerous GA models that are customized to reduce transaction delay. For each of these models, the throughput (measured in Megabits per second, or Mbps), which represents the number of blocks mined per unit time, is displayed in Fig. 11.

Fig. 11
A graph titled throughput with four trends plots the through in Megabits per second across the number of votes in thousands and millions. Four lines are in an increasing trend.

Throughput performance for different algorithms on large-scale voting applications

Full size image

Due to use of multiple GA models, which are tuned to optimize sidechain length, the proposed model was observed to have16% better throughput than DB [2], 25% better throughput than ABTT [23], and 26% better throughput than PS [25] for large-scale voting applications. Similarly, the storage cost (in Megabits or Mb), which indicates average number of blocks stored per chain, for each of these models is shown in Fig. 12.

Fig. 12
A graph titled storage cost with four trends plots the storage cost in Megabytes across the number of votes in thousands and millions. Four lines are in a slightly increasing trend.

Storage cost for different algorithms on large-scale voting applications

Full size image

The proposed model was observed to be 25% better than DB [2], 10% better than ABTT [23], and 8% better than PS [25] for large-scale voting applications in terms of storage cost due to the use of multiple GA models that are tuned to optimize sidechain length and number of blocks per sidechain. These benefits make the suggested approach suitable for use in any form of extensive e-Voting application. The usage of multiple GA models for sidechain construction and maintenance causes the suggested model to be seen as being superior than a number of state-of-the-art techniques. These models enable the sidechain management technique to be presented to choose configurations that decrease transaction time and increase e-Voting throughput. As a result, the suggested model can be used for small, medium, and large-scale e-Voting systems.

5 Conclusion and Future Scope

The suggested concept combines two separate types of gas to create and manage sidechains. The sidechain creation GA is capable of selecting optimum sidechain lengths, and main blockchain divisions, which are optimized for improving transaction speed. The created sidechains are managed using another GA method, which assists in optimal creation and usage of existing sidechain configuration model. Both the GA models utilize transaction delay, and sidechain lengths in order to improve e-Voting performance for small, medium, and large-scale deployments. As a result, it was found that the proposed model was 15% faster than DB [2], 8% faster than ABTT [23], and 26% faster than PS [25] for small-scale voting applications, 18% faster than DB [2], 26% faster than ABTT [23], and 25% faster than PS [25] for medium-scale voting applications, and 18% faster than DB [2], 16% faster than ABTT [23], and 10% faster than PS [25] for large-scale. For small-scale voting applications, the suggested model was found to be 61% faster than DB [2], 9% faster than ABTT [23], and 28% faster than PS [25], while for moderate-scale voting, it was shown to be 20% faster than DB [2], 6% faster than ABTT [23], and 19% faster than PS [25]. For large-scale voting applications, the throughput was 26% higher than PS [25], 25% higher than ABTT [23], and 16% higher than DB [2]. Similar findings were reached regarding the cost of storage, which makes the suggested approach highly scalable and applicable to a variety of e-Voting systems. Future evaluations of the suggested methodology for more blockchain applications will help determine its versatility. The performance of the proposed model can be further enhanced by applying deep learning techniques like reinforcement learning and Q-learning, which will help in optimizing sidechain parameters through reward-based learning mechanisms, accelerating transaction performance, and further improving throughput for a variety of side chain applications.