ABSTRACT

THE PROCESS OF CASTING A VOTE IN THE TRADITIONAL PHYSICAL VOTING SYSTEM

IS TIME-CONSUMING, CENTRALIZED, HARD TO COORDINATE AND MANAGE, PRONE
TO MISCALCULATIONS, AND TAMPERING WITH THE VOTES AND CASTING GHOST
VOTES. TO COMBAT THE ABOVE LIMITATIONS AND INCREASE PUBLIC
PARTICIPATION IN VOTING PROCESS WHICH IS A FUNDAMENTAL RIGHT, A BLOCK
CHAIN-BASED E-VOTING SYSTEM HAS BEEN DEVELOPED SO FAR, WHICH PROVIDES
THE BENEFITS OF AN IMMUTABLE DECENTRALIZED LEDGER, TRANSPARENCY, AND
A TRUSTLESS SYSTEM. TRADITIONAL BLOCKCHAIN-BASED ELECTRONIC VOTING
SYSTEMS USE A SINGLE BLOCKCHAIN TO PROCESS AND RECORD VOTES FOR THE
ENTIRE VOTING PROCESS, INCLUDING ALL POLLING STATIONS, WHICH IS NOT
EFFICIENT AND SCALABLE DUE TO LOW THROUGHPUT RATES.

TO IMPROVE THE THROUGHPUT RATES, THE IDEA IS TO CONCURRENTLY

CALCULATE THE PARTIAL VOTING RESULTS FOR EACH POLLING STATION BY
MAINTAINING A SEPARATE INDEPENDENT BLOCKCHAIN, AND THEN COMBINE ALL
THE PARTIAL RESULTS BY CREATING A HIERARCHY OF BLOCKCHAINS THAT USES
BLOCKCHAIN INTEROPERABILITY CONCEPTS TO COMMUNICATE WITH EACH OTHER
AND PUBLISH OVERALL RESULTS IN A MAIN PUBLIC BLOCKCHAIN.

INCREASED THROUGHPUT OF PROCESSING TRANSACTIONS AND OVERALL VOTE

RESULT CALCULATION PROCESS BECOMES FASTER DUE TO PARALLEL PROCESSING
OF THE SHARDS. SEARCHING THE BLOCKS TAKE O (LOGN) TIME USING HYBRID
MERKLE HASH TREE AND COUNTING BLOOM FILTER BASED FAST AUTHENTICATION
DURING VOTER REGISTRATION PHASE WHICH WITH EARLIER REGULAR BLOCKCHAIN
TOOK O(N)TIME.

BUILDING A HIERARCHY OF BLOCKCHAIN THAT USES BLOCKCHAIN

INTEROPERABILITY CONCEPT TO COMMUNICATE AMONG EACH OTHER ENABLES
CONCURRENT PROCESSING OF VOTES WHICH INCREASES THE THROUGHPUT OF THE
BLOCK CHAIN BASED VOTING SYSTEM AND ENABLES IT TO BE USED FOR LARGE
SCALE VOTING PROCESS.
 CHAPTER 1
Introduction
1.1 State of the art developments
The right to vote is a fundamental right given to every citizen in a democratic country. However,
the participation rate of citizens, especially in urban areas, is declining due to the very difficult
and time-consuming process of casting a vote at physical polling stations. Besides, there is a lack
of trust between the voters as the process of collecting the ballots and counting the votes is done
by a very small group of staff appointed at the physical polling station, which leaves the scope of
casting false votes, errors in counting and result declaration, results getting influenced by third
parties, and no way of checking that the votes were cast as intended by the voter and counted as
they were cast. Managing the physical voting process requires a lot of human and other
resources, which is quite challenging. Hence, to overcome all these challenges, a web-based
electronic voting system was developed. Now, the voting process is easily accessible with a
single click, even in the most remote areas. But the following challenges were faced in the
centralized web-based electronic voting system: The voters still had to trust a central authority
that controlled the rules of how the votes were cast and how they were counted. If a person has
access to the physical server of the website, he can easily manipulate the voting process. There is
a fear of the e-voting system failing if the central server fails (a single point of failure). The
system is more susceptible to cyber attacks. Now, to overcome all these challenges, the
development of blockchain-based electronic voting systems has started. Blockchain technology
provides the benefits of transparency, tamper proof, a decentralized ledger, etc. that can be used
to increase the trust of the voters in the system, so there is no need to trust a central third-party
authority, which will motivate voters and increase their participation in the voting process, which
is their fundamental right.

1.2 Motivation
Our motivation for selecting this project is to increase the participation of the citizens in the
voting process, which is their fundamental right, as many of the citizens prefer not to vote as the
traditional physical voting system is difficult and chaotic, and they have a lack of trust in the
government staff at the polling station. Therefore, in order to make the voting process more
transparent, error-proof, safe, and tamper-proof, an electronic voting system is being developed
using blockchain technology But it has certain disadvantages. The traditional single blockchain
is not very efficient to use on a large scale as the number of transactions being processed per
second is very less 7 per second compared to VISA's 1700 per second and the total number of
unprocessed transactions waiting to be mined and validated by validators is huge compared to
the total population who is eligible to vote and has cast his vote. Hence, in order to scale up the
traditional blockchain-based e-voting system which would make it most time efficient by
dividing and assigning the whole process of counting and validation of votes into smaller
blockchains for each individual polling station and finding the local aggregate, and use a
hierarchical design of blockchains, which would communicate the local aggregate of each of the
local blockchains or shards to the main public blockchains to calculate the global voting results,
or use the divide and conquer strategy to calculate the overall voting results in the main public
blockchain.

1.3 Problem Statement

Our problem statement is to make traditional voting systems transparent, trustless, decentralized,
secure, failure-resistant, efficient, and effective, reduce the time and resources required to vote,
and make the vote calculation process fault-proof.

1.4 Objective
The following are the objectives we need to achieve through this major project. We need to
eliminate the possibility of vote tampering and the casting of ghost votes. We need to remove
central control of the voting process or achieve decentralization. We need to make the voting,
counting, and result declaration systems transparent, secure, tamper-proof, efficient, and
effective. We need to make the voting system resilient to single points of failure. We need to
reduce the time and resources required.

1.5 Scope
The following are the scope of our project hierarchical blockchain design for scaling the voting
system on a large scale, Hybrid blockchain search algorithm using counting bloom filter and
merkle hash tree for fast authentication of voters, implement cross chain routing protocol
between main chain and shards, hybrid consensus that uses POS and POC for layer 2 blockchain
for enhanced security against 51% attack on the network.

1.6 Methodology
The system comprises blockchains at three different levels: levels 0, 1, and 2. Level two
comprise the shards, or independent private blockchains, for each individual polling station.
These shards are independent of each other and will concurrently process vote information, form
blocks in the local blockchain, and find the partial result for the polling station using
holomorphic encryption that intuitively allows doing an aggregate operation on the cipher text
underneath the encrypted ballots without the need to decrypt it first, and the result is also in an
encrypted format. Level 1 comprises a blockchain of router nodes or validator nodes that will be
randomly assigned to one of the shards using cryptographic sortition and will validate the blocks
from level 2 shards and publish them to the main public blockchain using the blockchain
interoperability or cross-chain routing protocol. Level 0 comprises the main public blockchain,
where the partial encrypted results of all the different polling stations are recorded for calculating
the overall aggregate voting results for the entire voting system on vote opening day using the
shared private key of at least t+1 validator nodes of layer 1, and the results can be audited and
verified publically by anyone, thereby increasing transparency and scalability.

1.7 Organization of the report

The report has been organised in the following way first an introduction to the problem statement
and insight into the existing physical voting system, introduction to the domain blockchain
fundamentals and working, SRS specification, High level design, detailed design,
implementation details, software testing, experimental results and analysis followed by
conclusion and future scope for this project.

1.8 Summary
The chaper 1 talks about an introduction to the overall work that is carried out throughout this
major project semester and an insight to the problem statement, research gaps in the existing
system and what can be a possible solution to scale the existing blockchain electronic voting
systems.

CHAPTER 2
Overview of Blockchain

2.1 Introduction
Blockchain is a peer to peer distributed ledger of history of transactions contained in blocks
which are linked to each other by cryptographic hash which is like a fingerprint of the previous
valid block hence making blockchain unchangeable. Changing data on blockchain is
computationally very expensive will be explained in the blockchain security section.

2.2 Cryptographic hash function

Inorder to secure the blockchain data we need a one way function which acts like a fingerprint
unique for every individual and based on the fingerprint we cannot trace back how the person
looks like.

Following are the five characteristics of a good cryptographic hash function:

One way which means we should not be able to reverse the hash value to get what the message
looked like

Deterministic which implies the hash of a file should be same every time we calculate the hash
for the file.
Fast computation which implies calculating the hash for a file or message or data should be fast
and easy to compute and verify.

Avalanche effect which refers to hash functions are designed in such a way that if you change
even a single bit of the data whose hash has to be calculated the entire hash value for the
message changes like a small snowball leads to a large avalanche by triggering more changes in
the later stages of hash calculation. So every time even if you make the slightest change in the
data to be hashed the whole hash changes and looks random every time.

Must withstand collisions: All hashes are of fixed size for example SHA-256 produces 256 bit
hashes. But the number of documents that can be input to hash function is unlimited and only 2n
are possible hashes where n is the number of bits used to hash there is a possibility of collision or
same hash value for two different documents. It is important for n to be sufficiently large so that
finding how to produce a collision deliberately for a slightly changed document is
computationally expensive. This type of attack where the intruder finds a way to modify the
originally signed document without changing the meaning of it which collides with the slightly
modified version of a fake document to be replaced with having the same hash value is called
birthday attack and finding the collision by brute force takes O(√ n) time and space so for 128
bit hashes the birthday attack would take O(264 ) time and space which is not very secure hence
256 bit is used for hash functions.

2.3 Immutable ledger

Immutable ledger is achieved by blockchain protocol using cryptographic hash and distributed
peer to peer network of the blockchain explained below.

2.3.1 Structure of a block in a blockchain

The blocks in a blockchain can be thought of as a page in a ledger containing the transanction
history in it. The block contains two parts the header which is hashed to produce hash of the
block and the body which contains the valid transactions.

The contents of a block head are:

1. The version number of the software

2. The hash of the previous block

3. The root hash of the Merkle tree

4. The time in seconds since 1970–01–01 T00: 00 UTC

5. The goal of the current difficulty

6. The nonce

Now for calculating the hash of the current block these six header data is used to obtain the hash
value if any of these changes the hash of the current block will change .

2.3.2 Most important fields of block header

The following are the most important fields of the blocks in a blockchain that will be used to
provide security to the individual nodes and provide blockchain ledger immutability.

2.3.2.1 Previous Hash

The hash value of the previous valid block from the current state of the blockchain after which
this block is mined.

2.3.2.2 Merkle tree root

Summarized hash all the transactions which are recorded in the present block body. Any changes
in any of the transactions would change the overall merkle root hash value and can be identified.

2.3.2.3. Nonce and goal of current difficulty

In order to mitigate the dispute of which block mined by which miner should be accepted by all
the nodes in the network as the next valid block in the blockchain so that the block chain ledger
looks exactly the same for all the nodes in the network all the miners have to solve a
mathematical problem or finding by brute force a number nonce which when added to the block
header makes the hash of the current block starting with a minimum number of leading zeros
which is accepted as valid block. So the difficulty of the consensus mechanism depends on how
many minimum leading zeros should be there in the hash value of the current block which is
dynamic and decided based on the throughput or how many blocks are being mined per second if
all miners are producing too many blocks per second then the goal of current difficulty is
increased and if throughput is too low than the goal of current difficulty is reduced.

2.3.2.4 Effect of changing the block data when block in middle

If an attacker tries to alter the content of a block upon which other blocks have already been
build what happens is like domino effect one by one all the other blocks after it becomes also
invalid as when altering any of the transaction content of block 1 for example the fingerprint or
hash of the block 1 changes as the merkle root value would change which is the combined hash
of all the transactions present in the block 1 but as the block 2 was mined or hash was calculated
using the old hash of block 1 as its previous hash in its head there is a mismatch and hence block
1 becomes invalid and block 2 also becomes invalid so the attacker would have to find a new
nonce value for validating block 2 but like a chain effect all the next blocks after block 2
becomes invalid and have to be remined again which is computationally very expensive.

2.3.2.5 Distributed peer to peer network

The current state of the blockchain is stored on all the nodes or peers of the blockchain network
can be thought of as all the participating peers in the blockchain have a separate copy of the
current accepted blockchain ledger.

Each of the peers in the blockchain network are constantly checking their copy of blockchain
ledger state looks same as the blockchain ledger state of the majority of the neighbour peers
connected directly to it. If the peer I say finds that its copy of the blockchain ledger differs from
majority of its neighbour peers then it discards those blocks and copy the majority accepted
blockchain ledger state.

As a result of this if the attacker changes the data of only one peer on the network its attack will
go in vain as the peer would find it out by comparing its ledger copy with its neighbours and
discard the manipulated invalid copy.

So for a successful attack the attacker would have to simultaneously attack 51% of the peers of
the network so that his changed version of the blockchain ledger copy is accepted as valid by all
the peers participating in the network which is computationally very expensive and almost
impossible to achieve.

2.3.2.6 Consensus protocol

The consensus is the protocol used by blockchains which serves the following two functions first
as a separate copy of the current state of blockchain ledger is maintained by each peer in the
blockchain network but how do they agree on the next state of the blockchain local ledger which
will be consistent with the majority of the peers in the blockchain network in the case of two
miners mine a valid next block using the previous hash of the last state of the blockchain they
use consensus protocol to come to a majority agreement on what should the next state of the
blockchain look like. The second function of consensus protocol is to prevent double spending
attacks on the blockchain network where an attacker tries to concurrently generate two
transactions of the same coins and the longest chain at a particular time is accepted as a valid
blockchain state and the shorter branch blocks are termed invalid thus reversing the transactions
contained in them. A double spending attack is successful when the attacker has access to 51%
of the computational power in the network and can mine the blocks faster than any honest node
and the honest branch of the blockchain will become shorter and thus accepted invalid by all the
nodes in the blockchain network.
2.4 Summary
In chapter two we have discussed about the domain of the project that is the fundamentals of
blockchain and some of the most important concepts that build the foundation of any blockchain
based system how the blockchain distributed ledger is immutable and how blockchain ensures
security from double spend attacks.

CHAPTER 3
Software Requirements Specification

3.1 Overall description

The requirement specification process is a critical step in the software development process. The
Software Requirements Specifications (SRS) document contains these requirement
specifications. When every need has been gathered and evaluated, this report becomes the basis
for the work of the software engineers. SRS is a formal report that represents software and
enables clients to determine whether it satisfies their needs. It also provides comprehensive
system requirement specifications and the needs of system users. The SRS is a list of
specifications for a certain piece of software, program, or group of apps that carry out specific
activities in a particular setting. This chapter describes the project's functional and non-
functional hardware and software needs; it provides a comprehensive overview of the product
and various constraints and dependencies.

3.1.1 Product perspective

The software has three main users who interact with it in different ways: voters, electoral
commissions, and auditors selected from the electoral commissions. The local shards are a
permissioned blockchain in which one of the selected election commission officials, selected by
cryptographic sortition, uploads the public key certificate of voters to the main blockchain,
which registers the valid users eligible to vote. There are different functions for the three
different stakeholders. The election commission is a part of the level 1 blockchain and validates
all the transactions and signs them to put in the final main blockchain, and the‘t’ auditors are
selected from the election commission members who are responsible for putting their distributed
keys for ballot opening at the end of the election process on vote opening day.

3.1.2 Product functions

There will be different functions provided for each of the different stakeholders the voters ,
election commission , the auditor and the smart contract. The election holder has the following
functions upload election commission public keys, get distributed key, verify smart contract ,
upload candidate ,upload voter list ,verify ballot, blind sign,upload ballot, upload private key and
open result. The voter can invoke the following functions generate ballot, blind ballot, sign
message, vote, view results.
3.1.3 User characteristics
The three major categories of the end users are

The election commission: they are responsible for monitoring the election process checking and
validating the incoming blocks from the local shards and uploading the validated blocks into the
main public blockchain. They have permission to author blocks and validate the blocks.

The voter: they are responsible to cast votes, view results these users have the permission to only
send transactions to the level 2 blockchains.

The auditors: these are the ‘t’ selected users from the election commission who have the
distributed private key that can be jointly used to open the election results on the vote opening
day.

3.1.4 Constraints and dependencies

GUI only exists in English. One server is supported by this system. Only supports
HTTP/HTTPS. User should be familiar with computers.

3.2 Specific Requirements

The following are the specific requirements of the hierarchical blockchain design for electronic
voting system.

3.2.1 Functional Requirements

1. Authorize User it will authorize every user before letting him vote

2. Add Auditor it will allow to add auditor

3. Vote Virtually Voter can vote from any part of the world through webapp

4. Vote anonymously Voter will be able to vote anonymously using public key

5. Add Election can add many Elections

6. Multiple Elections Multiple Elections can be carried out

7. Vote once any authorized voter can only vote once in an election

8. History will provide history of Elections

3.2.2 Performance Requirements

The software is anticipated to respond fairly quickly. It should be able to log in and provide new
pages to the voter upon request with a response time of a few seconds or less.
3.2.3 Supportability
Professionals favour Linux because to its stability, whereas average computer users choose
Windows due to its usability. Because of this, the main platforms on which our application will
run are Android (android app), Windows, and Ubuntu14.0 or higher (web app). Any core 2 quad
or newer machine can use it.

3.2.4 Software Requirements

Visual Studio 2019

SQL Server Management Studio latest

3.2.5 Hardware Requirements

Laptop or PC

Windows 7 or higher

I3 processor system or higher

4 GB RAM or higher

100 GB ROM or higher

3.2.6 Design Constraints

The customer's organisation that is in charge of maintaining the project must be knowledgeable
about blockchain technology because the application was created for widespread public use, so it
was necessary to keep implementation and design constraints to a minimum. Since the app was
created using the Solidity programming language, it is difficult to deliver future upgrades. The
budget may be a significant design limitation, for instance if the customer wants more options
yet has a limited budget. Any design changes that the customer requests during the later stages of
programme development may cause significant implementation issues.GUI only exists in
English. User should be familiar with computers.

3.2.8 Non functional Requirements

Performance Requirements the software is anticipated to respond fairly quickly. It should be able
to log in and provide new pages to the voter upon request with a response time of a few seconds
or less.
Safety Requirements the results of the votes cast up to that point must be preserved in the
database in order for the system to keep counting votes after a reboot, preventing data loss in the
event of a system failure. If the EC discovers any security flaw in the system, he should be able
to promptly shut down the server and stop all connections while maintaining the polled votes.
The EC should set up his system time appropriately so that the election process can begin at the
proper moment. The voting process should be able to continue gracefully after earlier crashes on
the system.

Security requirements Basic security features like encrypted transactions and password
authentication should be offered by the system. To avoid unauthorised usage, all passwords
created and distributed to users should only be saved on the server in encrypted form for login
management. By establishing a minimal time interval between repeated unsuccessful log-in
attempts, serial attacks should be prevented.

3.3 Summary
In chapter 3 we have discussed and specified the software requirements specification which is
extremely helpful to unambiguously record all the functional and non functional requirements
and helps the developer team understand what are the needs of the stakeholders without making
any assumptions and will be helpful while validating the software.

CHAPTER 4
High Level Design

4.1. Design Considerations

The design considerations are critical to the success of a project. To begin, it is necessary to
understand the project's objectives, requirements, and constraints. Communication with
stakeholders and team members is essential for acquiring information about their needs and
expectations. Analyzing the target audience is also necessary for creating a user-centric design
that caters to their unique likes and behaviors. Scalability and flexibility should be considered for
future growth and change. A design that balances beauty and utility is both engaging and useful.
Additionally, technical feasibility, cost-effectiveness, and environmental impact must all be
taken into account. Ensuring that the design can be implemented within the available resources,
successfully controlling expenses, and considering sustainability all contribute to project success.
By addressing these design considerations holistically, projects can achieve their goals, provide a
wonderful user experience, and contribute to long-term success.
4.1.1. General Constraints
Voting must be done online with a working connection.

Only laptops and computers can use it.

The website is available in English language only.

4.1.2. Development Methods

Following are the different software development methods

Agile development process when implementing new features, teams employ the agile
development technique to reduce risk (such as errors, budget overruns, and changing needs).
Teams create software in iterations that include tiny increments of new functionality according to
all agile development methodologies. The agile development methodology comes in a variety of
forms, such as scrum, crystal, extreme programming (XP), and feature-driven development
(FDD).

The waterfall method is frequently regarded as the oldest approach to software development. The
requirements, design, implementation, verification, and maintenance phases of the waterfall
technique each focus on a different objective. Before moving on to the following phase, each
phase must be finished completely. In most cases, there is no procedure for going back and
changing the project or direction.

The system was developed by first studying how the blockchain network is arranged into
different levels of blockchains in the hierarchical design of the system Figure 4 shows the
different nodes that are present in the level 2 and level 1 of the blockchain which submit the
transactions to the relay main chain or level 0 of the blockchain network.

Then following that deciding on what would the different stages in which the election would be
conducted.

After which defining the high level working and what data is stored at each level of the block
chain system.

4.2. Architectural Strategies

The Architectural strategies direct project design and implementation. Establishing a clear
architectural vision, choosing an appropriate architectural style, ensuring modularity and
separation of responsibilities, addressing scalability and performance, and including security,
dependability, and fault tolerance techniques are all critical problems. A clear vision defines
project goals, while architectural styles improve scalability and maintainability. Performance
considerations allow for more efficient system handling, while modularity improves flexibility.
Security measures guard against threats, while fault tolerance and reliability strategies improve
system robustness. Using these architectural ideas, projects may be created to meet objectives,
give exceptional performance, and ensure long-term success.

4.2.1. Programming Language

C# is a programming language that offers a plethora of benefits to both inexperienced and
seasoned programmers. It is statically typed, simple to read, and places a strong emphasis on
effectiveness. It is a wonderful entry point into the area because it is very simple to learn and
maintain. It is easier to modify and maintain than other languages since it is scalable and simple
to manage. A big community and object-oriented programming are two features of the computer
language C#. Although it is a unique quality for a programming language, there are several
benefits, including efficiency and versatility. The StackOverflow and Meetup.com communities
are largely made up of C# developers, and object-oriented programming has several benefits,
including efficiency and flexibility.

4.2.2 User interface paradigm

A spiral model can be used to illustrate the iterative analysis and design process of a user
interface. Four framework activities make up the user interface analysis and design process.

1. User profiles, needs, tasks, the physical work environment, and unique human factors
issues are the subject of user, task, and environmental analysis and modelling. User
profiles, requirements, tasks, the physical work environment, and unique human factors
concerns are the main areas of analysis.

2. The purpose of interface design is to establish user scenarios, define interface objects and
actions, and take into account design factors including response time, command and
action structure, error handling, and assistance features.

3. The design of a prototype to test various usage situations is the first step in the
implementation process. Next, windows, menus, device interaction, error messages, and
instructions are created using a User Interface toolkit.

4. The practise of verifying an interface to make sure it satisfies user needs and is simple to
use and understand is known as interface validation. It needs to be able to manage a range
of jobs and carry them out correctly.

4.2.3. Error Detection and Recovery

The following are used for error detection and recovery in the hierarchical blockchain design for
e-voting system
Cryptographic hash function In order to secure the blockchain data we need a one way function
which acts like a fingerprint unique for every individual and based on the fingerprint we cannot
trace back how the person looks like.

Following are the five characteristics of a good cryptographic hash function:

One way which means we should not be able to reverse the hash value to get what the message
looked like

Deterministic which implies the hash of a file should be same every time we calculate the hash
for the file.

Fast computation which implies calculating the hash for a file or message or data should be fast
and easy to compute and verify.

Avalanche effect which refers to hash functions are designed in such a way that if you change
even a single bit of the data whose hash has to be calculated the entire hash value for the
message changes like a small snowball leads to a large avalanche by triggering more changes in
the later stages of hash calculation. So every time even if you make the slightest change in the
data to be hashed the whole hash changes and looks random every time.

Must withstand collisions: All hashes are of fixed size for example SHA-256 produces 256 bit
hashes. But the number of documents that can be input to hash function is unlimited and only 2n
are possible hashes where n is the number of bits used to hash there is a possibility of collision or
same hash value for two different documents. It is important for n to be sufficiently large so that
finding how to produce a collision deliberately for a slightly changed document is
computationally expensive. This type of attack where the intruder finds a way to modify the
originally signed document without changing the meaning of it which collides with the slightly
modified version of a fake document to be replaced with having the same hash value is called
birthday attack and finding the collision by brute force takes O(√ n) time and space so for 128
bit hashes the birthday attack would take O(264 ) time and space which is not very secure hence
256 bit is used for hash functions.

Digital signature that takes in the message and the private key of the sender to produce a unique
digital signature that can be used as zero knowledge proof for the receiver that you have the
private key for the public key which has been used to sign the message and the message is
authentic.

A checksum functions as a code or file's digital fingerprint. It is a computed value made up of

numbers and letters that is used to confirm a file's integrity. Checksums are frequently used to
determine whether downloaded files are damaged or have undergone modifications since they
were first created.
4.2.4 Data storage management
In this project data is stored in different levels of the blockchain hierarchy. The level 2 or the
shards store the local voting information and aggregate, the level 1 or the router blockchain
stores the routing information and are responsible for validating and routing information to the
main chain. The main chain or level 0 contains the public information or the total aggregate of
the entire voting results in the encrypted form and also the public key information, election
certificate, candidate list etc.

4.3 System Architecture

The following are the different levels of the hierarchical blockchain design of the e-voting
system the system comprises blockchains at three different levels: levels 0, 1, and 2. Level two
comprises the shards, or independent private blockchains, for each individual polling station.
These shards are independent of each other and will concurrently process vote information, form
blocks in the local blockchain, and find the partial result for the polling station using
homomorphic encryption that intuitively allows doing an aggregate operation on the cipher text
underneath the encrypted ballots without the need to decrypt it first, and the result is also in an
encrypted format. Level 1 comprises a blockchain of router nodes or validator nodes that will be
randomly assigned to one of the shards using cryptographic sortition and will validate the blocks
from level 2 shards and publish them to the main public blockchain using the blockchain
interoperability or cross-chain routing protocol. Level 0 comprises the main public blockchain,
where the partial encrypted results of all the different polling stations are recorded for calculating
the overall aggregate voting results for the entire voting system on vote opening day using the
shared private key of at least t+1 validator nodes of layer 1, and the results can be audited and
verified publically by anyone, thereby increasing transparency and scalability.

4.5 Summary
In chapter 4 we have discussed the high level design of the major project discussing the design
considerations, architectural strategies, system architecture and level 0,1,2 data flow diagrams.
 CHAPTER 5
Detailed design

5.1 Structure chart

A structure chart is a visual representation or diagram that illustrates the hierarchical structure
and organization of modules or components in a software system. It depicts the relationships and
interactions between these modules, showing how they collaborate to achieve the system's
functionalities. The structure chart typically uses boxes or rectangles to represent individual
modules, with lines or arrows indicating the connections between them. It provides a clear and
concise overview of the system's architecture, allowing developers to understand the system's
composition and organization. A structure chart aids in modular design, encapsulation, and
information hiding, enabling the system to be divided into manageable and reusable components.
It serves as a communication and documentation tool, facilitating discussions among team
members and supporting system understanding, maintenance, and troubleshooting.

5.2 Functional Description of the Modules

A functional description of modules in a software system provides a detailed explanation of their
specific functionalities and purposes. It describes the tasks and operations that each module
performs to contribute to the overall system's functionality. The functional description outlines
the inputs, outputs, and processing logic of each module, specifying how it interacts with other
modules or components. It clarifies the responsibilities and behavior of the module, including
any business rules or algorithms it employs. Additionally, the functional description may
highlight any dependencies or interfaces with external systems or modules. It defines the
module's role in the overall system architecture and its contribution to achieving the system's
objectives. A comprehensive functional description of modules aids in understanding the
system's flow, supports design decisions, and enables efficient development, maintenance, and
testing. It serves as a crucial reference for developers, testers, and stakeholders, ensuring a clear
understanding of each module's purpose and functionality.

5.2.1 Order Assignment Module

The distribution of orders inside the e-voting system is managed by the Order Assignment
Module. Its primary functions include accepting and processing voting orders from qualified
voters, providing each order with a special identification number, and guaranteeing that the

distribution of orders among the various participants in the voting process is done correctly. The
integrity and effectiveness of the entire system are crucially dependent on this module. The order
assignment module in hierarchical blockchain design for e-voting system is voter registration
module and ballot casting module.
5.2.2. Order Assignment Configuration Module
The tools and interfaces required to configure the parameters and settings of the Order
Assignment Configuration Module are provided by this module. The rules and criteria used for
assigning orders can be defined and changed by authorised staff or system administrators using
this module. It has features that let you design order allocation algorithms, specify order priority
requirements, and set constraints for distributing orders in accordance with predetermined
criteria. The validate ballot and validate voting process modules provide order assignment
configuration module.

5.2.3. Master File Generation Module

The generation and management of the master files used by the e-voting system are the
responsibility of the Master File Generation Module. This module compiles data from a variety
of sources, including voter registration databases and order assignment data, to produce a
thorough and current master file. The master file is an essential resource for confirming voter
IDs, confirming polling place assignments, and guaranteeing the precision and consistency of the
entire voting process. The modules upload voter list, upload candidate list, upload EC public
keys are the master file generation module.

5.3 Summary
In chapter 5 we have discussed the detailed design of the hierarchical blockchain design for e-

voting system with the structure chart, use case diagram, sequence diagram for the modules to
understand in a better way the modules which are order assignment, order assignment
configuration module, master file generation module in our project work.

CHAPTER 6
 Implementation
6.1 Programming language selection
C# is a programming language that offers a plethora of benefits to both inexperienced and
seasoned programmers. It is statically typed, simple to read, and places a strong emphasis on
effectiveness. It is a wonderful entry point into the area because it is very simple to learn and
maintain. It is easier to modify and maintain than other languages since it is scalable and simple
to manage. A big community and object-oriented programming are two features of the computer
language C#. Although it is a unique quality for a programming language, there are several
benefits, including efficiency and versatility. The StackOverflow and Meetup.com communities
are largely made up of C# developers, and object-oriented programming has several benefits,
including efficiency and flexibility.

6.2 Platform selection

The.NET Framework is a new computer platform created to make application development
easier. A new computer platform called The.NET Framework was created to make it easier to
construct applications for the Internet's widely distributed environment. The.NET Framework
class library and the common language runtime are its two main parts. The runtime controls how
code is handled when it is being executed, offering essential services like memory management,
thread management, and remote, as well as strictly enforcing type safety and other types of code
accuracy. Unmanaged code is defined as code that does not target the runtime, whereas managed
code targets the runtime. Applications can be created using The.NET Framework, a rich, object-
oriented collection of reusable types.

Unmanaged components with the ability to load the CLR into their processes and start the
execution of managed code can host it. To offer managed code a scalable, server-side
environment, ASP.NET hosts the runtime. The runtime to embed managed components or
Windows Forms controls in HTML documents is hosted by Internet Explorer.

Memory, threading, code execution, code safety checking, compilation, and other system
services are all managed by the Common Language Runtime. The common type system (CTS) is
used to enforce code access security and code resilience. This guarantees type fidelity and type
safety while ensuring that any managed code is self-describing and can consume other managed
types and instances. By enabling developers to use their preferred language to create applications
while fully using the runtime, class library, and components created in other languages, the
runtime increases developer productivity. With improved performance and interoperability
between managed and unmanaged code, it also supports applications from today and yesterday.
High-performance server-side apps may host it.

Server application development is the process of developing Web sites and Internet-distributed
objects using managed code. ASP.NET is the hosting environment that enables developers to use
the.NET Framework to target Web-based applications, while XML Web services are distributed,
server-side application components similar to common Web sites. ASP.NET pages are faster,
more functional, and easier to develop than unmanaged ASP pages because they interact with the
runtime like any managed application. XML Web services technology is rapidly moving
application development and deployment into the highly distributed environment of the Internet.
XML Web services are built on standards such as SOAP, XML, and WSDL.

The.NET Framework is built on these standards to promote interoperability with non-Microsoft

solutions. Active Server Pages.NET is a programming framework built on the common language
runtime that can be used on a server to build powerful Web applications. It offers several
advantages over previous Web development models, such as enhanced performance, world-class
tool support, power and flexibility, and simplicity. It is also language-independent, so developers
can choose the language that best applies to their application or partition their application across
many languages.

6.3. Code Conventions

6.3.1. Naming Conventions

In the development of the blockchain-based e-voting system, the project team implemented a set
of code conventions to ensure consistency, readability, and maintainability of the codebase.
Adhering to these conventions enhances collaboration among developers, simplifies debugging,
and promotes software quality.

To improve code clarity, the team followed a naming convention that emphasizes descriptive and
meaningful names for variables, functions, and classes. This helps developers understand the
purpose and functionality of different code elements. For example, variables representing votes
could be named "voterChoice" or "candidateVotes," while functions validating the blockchain
could be named "validateBlockchain()".

6.3.2. File Organization

The project codebase was organized in a structured manner to facilitate efficient navigation and
ease of maintenance. Files were grouped into directories based on their functionality, such as
source code, tests, and documentation. Each class had its own file with a name reflecting its
purpose, ensuring modularity and clarity.

6.3.3. Declarations
Consistent declaration practices were followed to enhance code readability. Variables were
declared close to their usage, and access modifiers were used appropriately to control
accessibility. Constants were declared using the "final" keyword to denote their immutability.
Class declarations followed standard conventions, specifying access modifiers and implementing
necessary interfaces or extending relevant classes.
6.3.4. Comments
Comments were used strategically to provide explanations and document code functionality.
Method comments described the purpose, parameters, return values, and exceptions of each
method. In-line comments were employed to clarify complex logic or draw attention to important
details. The comments were written in a clear and concise manner, following the project's chosen
natural language style.

By adhering to these code conventions, the project team aimed to foster code consistency,
improve code readability, and facilitate future enhancements or bug fixes. These conventions
contribute to the overall quality of the blockchain-based e-voting system, making it more
maintainable and understandable for developers and stakeholders alike.

6.4 Difficulties encountered and strategies used to tackle them

Our blockchain-based electronic voting system's development and installation weren't without
difficulties. We will go over the challenges we had while working on the project in this section,
along with the methods we used to solve them.

6.4.1. Concurrency Control

Our electronic voting system's crucial component of concurrency management ensures that
several users can interact with it concurrently without affecting the integrity of the data.
However, implementing concurrency management effectively in a distributed blockchain context
presented unique difficulties. Here, we'll discuss the challenges we encountered and the solutions
we came up with.

1. Vote Duplication:The prevention of vote duplication was one of the main issues we ran
into. To protect the credibility of the election, it was essential to make sure that each
voter could only cast one ballot. We created a transaction locking-based concurrency
control approach to solve this problem. Voters were prevented from simultaneously
altering the same data when a transaction matching to their vote locked the pertinent data
connected with that vote. By using this strategy, the possibility of double voting was
ensured to be eliminated.

2. Vote Synchronization: The synchronisation of votes among a number of nodes in the

blockchain network presented another difficulty for us. It was essential to make sure that
the vote counts remained constant across all nodes because votes were cast using a
variety of devices and places. We used a consensus approach to address this problem. In
order to validate and add new blocks to the blockchain, we used the Proof-of-Work
(PoW) consensus mechanism, which required participants (miners) to solve challenging
mathematical puzzles. By ensuring that the majority of the network concurred on the
sequence and legitimacy of transactions, we were able to synchronise votes thanks to this
 consensus process. With this strategy, the voting process across all nodes was kept
uniform and honest.

3. Scalability: Our concurrency control method was heavily influenced by our concern
about scalability. We needed to make sure the system could effectively handle the rising
workload as there were more voters and transactions. We used sharding strategies to deal
with this issue. We achieved parallel transaction processing by separating the blockchain
network into smaller, independent portions known as shards. Each shard worked
independently, handling a percentage of the total burden. By spreading out the transaction
processing load across several shards, this method increased system scalability by easing
the burden on individual nodes and enabling a greater volume of concurrent transactions.

4. Transaction Prioritization: In situations where multiple voters simultaneously initiated

transactions, it was essential to prioritize their execution. We needed to ensure that
critical votes or time-sensitive transactions were processed promptly. To tackle this
challenge, we implemented a priority queue system. Transactions were assigned priority
based on predefined criteria such as the urgency of the vote or the importance of the
voter. This prioritization mechanism ensured that critical transactions received
precedence in execution, maintaining fairness and timely processing of votes.

6.5 Summary
Conclusion, Our blockchain-based e-voting system's concurrency control faced particular
difficulties, such as preventing vote duplication, guaranteeing vote synchronisation, scalability,
and transaction prioritisation. We effectively overcame these difficulties by implementing
transaction locking, the PoW consensus algorithm, sharding approaches, and a priority queue
architecture. These techniques worked together to provide an electronic voting system that was
safe, synchronised, scalable, and fair in a concurrent setting.

6.4. Difficulties Encountered and Strategies Used to Tackle Them

 CHAPTER-7
Software Testing
 CHAPTER 7
Software Testing
7.1. Test Environment:
A thorough testing environment is necessary for the blockchain-based electronic voting system
to assure its dependability and correctness. While providing for controlled testing scenarios, the
test environment should be created to closely resemble the production environment. The test
environment should take into account the following factors:

Hardware: To accurately evaluate system performance, the test environment's hardware specs
should be comparable to those of the production environment.

Software: The test environment should be set up with all relevant software components, such as
the blockchain platform, smart contract code, and any additional modules or libraries.

Network: To provide realistic network latency and bandwidth limits, the test environment's
network configuration should be similar to that of the production environment.

Data: To imitate real-world scenarios, a realistic set of data should be developed or imported into
the test environment. This provides test scenarios with various inputs, election data, and sample
voter profiles.
Security: To protect sensitive data and stop unwanted access or alteration, adequate security
measures should be put in place in the test environment.

Monitoring and logging: To watch system activity, find problems, and examine performance
metrics, the test environment should be furnished with monitoring tools and recording systems.

7.2. Unit Testing:

Individual software pieces or components are tested individually to ensure that they work
properly and as intended. Unit testing should be done for particular modules relevant to order
assignment in the context of the blockchain-based electronic voting system. The unit testing
process is described in detail in the following sections.

7.2.1. Unit Testing of Order Assignment Module:

The Order Assignment module is in charge of allocating orders or jobs within the e-voting
system to qualified participants. The following unit testing tasks can be carried out to make sure
it is correct:

The purpose of test cases should be to cover a variety of scenarios, including validating the
assignment process, resolving edge circumstances, and assigning orders to diverse participants.

To ensure that each procedure or method in the Order Assignment module behaves as intended
and produces the desired outcomes, each function or method should be tested separately.

To make sure that invalid inputs are processed correctly and the right error messages or
exceptions are created, input validation should be thoroughly tested.

To separate the module being tested from other dependencies and enable focused testing and
quicker issue discovery, stubs or mock objects can be employed.

7.2.2. Unit Testing of Order Assignment Configuration Module:

The setup parameters and settings for order assignment are handled by the Order Assignment
setup module. The following can be included in unit testing for this module:
Explanation:

Different configuration possibilities should be covered by test cases, such as changing thresholds
and weights and assessing the effect on the assignment process.

To ensure proper handling and interaction with other system components, each configuration
setting should be evaluated.

Boundary testing can be used to confirm how the configuration module behaves when unusual or
extreme values are supplied.
7.2.3. Unit Testing of Order Assignment:
The integration and interaction of various modules and components used in the assignment
algorithm are tested as part of unit testing the overall Order Assignment process. The following
factors can direct the Order Assignment process's unit testing:

The order assignment process should be covered end-to-end in the test cases, including input
data, algorithm execution, and output validation.

In order to evaluate the reliability and correctness of the assignment process, several input and
data set combinations should be examined.

To guarantee proper data flow and interaction, integration testing with pertinent dependencies,
such as the blockchain platform or database, should be taken into account.

7.3. Integration Testing:

Integration testing is used to examine how various modules or parts of the blockchain-based
electronic voting system interact with one another. The process of integration testing is described
in detail in the following sections.

7.3.1. Integration Testing for Order Assignment:

The Order Assignment component's relationship with other modules or services is tested during
integration testing. Consider the following actions:

Different integration situations should be covered by test cases, such as communication with a
blockchain platform, database, or external APIs for voter identification or verification.

During the assignment process, data flow and integrity should be checked to make sure that the
assigned orders are appropriately saved and linked to the appropriate participants.

It is important to test boundary cases and extraordinary circumstances, such as network outages
or inconsistent data, to make sure the system can manage them gracefully.

7.3.2. Integration Testing for Order Assignment Configuration:

Verifying how the Order Assignment Configuration module interacts with other elements and
how this affects the assignment process is part of integration testing for this module. You can
carry out the following actions:

Test cases ought to include situations when the configuration module is used by other
components, such the Order Assignment module or user interfaces.
Check to see if configuration setting changes are implemented properly and reflected in the
assignment process.

In order to retrieve or save configuration data, check the integration of the configuration module
with any external systems or databases that may be used.

7.3.3. Integration Testing of Master File Generation:

The task of creating the master file, which includes the assigned orders and pertinent data, falls
under the purview of the master file generation component. The following actions can be part of
this module's integration testing:
Explanation:

To ensure accurate data and information transmission, test the integration between the Order
Assignment and Master File Generation modules.

Examine the resulting master file to make sure it is formatted as required and contains proper
data about the allocated orders.

Test the master file generation or exportation process' integration with any external systems or
APIs.

7.3.4. Integration Testing of Order Assignment System:

The interaction and coordination between various modules and components are tested as part of
the integration testing process for the overall Order Assignment system. Consider the following
actions:

Test the Order Assignment system's whole process, including data input, assignment algorithm
execution, storage of assigned orders, and master file production.

Verify the Order Assignment module's connection with the configuration module and other
pertinent parts.

To evaluate performance and scalability, test the system behavior under heavy load or concurrent
access.

7.4. System Testing:

The main goal of system testing is to assess the entire blockchain-based electronic voting system
as a whole. It strives to guarantee that all modules, elements, and interfaces function properly
together. For system testing, the following elements can be taken into account:
Test the system in accordance with the specified functional criteria, paying particular attention to
user interactions, order assignment precision, and master file production.

Test the e-voting procedure from beginning to end, taking into account all possible
circumstances, from voter registration through vote submission and order assignment.

To assess performance and robustness, test the behavior of the system under various stresses,
such as heavy user traffic or network congestion.

To find weaknesses, maintain data privacy, and stop tampering or illegal access, do security
testing.

Verify the system's operation and compliance with any applicable rules or standards for e-voting
systems.

7.5. Summary
The blockchain-based e-voting system can be comprehensively assessed for functionality,
performance, and security by adhering to a complete testing approach that includes unit testing,
integration testing, and system testing.
 CHAPTER-8
Experimental Results and analysis

CHAPTER 8
Experimental Results and analysis
8.1. Evaluation Metrics
In order to assess the performance and effectiveness of our blockchain-based e-voting system,
we have defined a set of evaluation metrics. These metrics serve as quantitative measures to
evaluate various aspects of the system's performance. The evaluation metrics considered are:

Accuracy: This metric measures the correctness of the voting results generated by the system. It
compares the number of correctly recorded votes with the total number of votes cast to determine
the accuracy rate. A high accuracy rate indicates the system's ability to record votes correctly and
generate accurate results.
Security: This metric evaluates the level of security provided by the blockchain-based e-voting
system. It assesses the system's resistance against tampering, manipulation, and unauthorized
access. We employed cryptographic mechanisms, such as digital signatures and encryption, to
ensure the integrity and confidentiality of the voting process.

Efficiency: This metric quantifies the efficiency of the system in terms of processing time and
resource utilization. It measures the speed at which the system handles various operations, such
as vote recording, order assignment, and master file generation. We considered the
computational complexity of the algorithms used and implemented optimization techniques to
improve efficiency.

Scalability: This metric assesses the system's ability to handle a large number of voters and
maintain performance under increased load. It measures how well the system can scale with an
increasing number of participants without compromising its performance. We analyzed the
system's performance and resource utilization as the number of voters increased, identifying any
potential bottlenecks and scalability limitations.

Usability: This metric evaluates the user-friendliness of the e-voting system. It assesses factors
such as ease of use, intuitiveness of the interface, and user satisfaction. We conducted user
feedback surveys and usability testing to gather insights on the system's usability and made
improvements based on the feedback received.

8.2. Experimental Dataset

To conduct our experiments and evaluate the performance of the blockchain-based e-voting
system, we utilized a representative dataset. The dataset was designed to simulate a realistic
voting scenario with a diverse set of voters. It included synthetic voter profiles with various
attributes, including voter IDs, demographic information, and voting preferences.

The dataset aimed to capture the diversity of potential voters in a real-world election. It included
different age groups, geographical locations, and political affiliations. Additionally, variations in
the number of voters allowed us to assess the system's scalability and performance under
different voter loads. The dataset was carefully anonymized to ensure privacy and data
protection.

8.3 Performance Analysis:

In this section, we present a detailed analysis of the performance of the blockchain-based e-
voting system. We evaluated the system's performance based on the defined evaluation metrics
and gained insights into its efficiency, security, scalability, and usability.
8.3.1 Order Assignment:
The order assignment phase of the e-voting system involves allocating a unique order to each
voter to ensure fairness and prevent manipulation. We analyzed the performance of the order
assignment algorithm based on its execution time and the fairness of the assigned orders.

The execution time of the order assignment algorithm was measured to assess its efficiency. We
employed optimization techniques to improve the algorithm's performance and reduce processing
time.

To evaluate the fairness of the order assignment, we calculated the variance in the assigned
orders across different demographic groups. A lower variance indicated a more equitable
distribution of orders, ensuring that no specific group was favored or disadvantaged.

8.3.2 Master File Generation:

The master file generation process involved aggregating and encrypting the cast votes into a
single file for verification and tallying. We analyzed the performance of the master file
generation algorithm based on its execution time and the integrity of the generated file.

The execution time of the master file generation algorithm was measured to assess its efficiency.
We implemented optimizations to reduce the time required to aggregate and encrypt the cast
votes.

To verify the integrity of the master file, we compared it with the individual cast votes. This
verification ensured that all votes were accurately included in the master file. We also verified
the encryption and decryption process to confirm that the votes remained secure and confidential
during the generation phase.

8.4. Summary
In chapter 8 by evaluating the performance of the order assignment and master file generation,
we gained insights into the efficiency, reliability, and fairness of these crucial components of the
blockchain-based e-voting system.
 CHAPTER-9
Conclusion and future enhancement

CHAPTER 9
Conclusion and future enhancement
9.1. Limitations of the Project
The trilemma of the blockchain i.e. achieving the three scalability, decentralization, and security
concurrently is not possible we can achieve any of the two with a compromise on the third one.
Here in this project true sense of decentralization cannot be achieved as the level 1 of blockchain
has more authority than the voter nodes at level 2 and the system is not fully automatic the
election commission is responsible for uploading the encrypted candidate list and eligible voter
list though it is made random using cryptographic sortition but the system is not fully automatic
and decentralized in the true sense there is some compromise over here to achieve scalability.

9.2. Future Enhancements

The future enhancements can be using biometric fingerprint and monitoring the eye blinking of
the voters while casting votes to ensure the voter is alive during the voting process and no one is
impersonating and casting vote for a dead person. The other future enhancement is making a
scalable transparent voting system for other types of electoral systems like quadratic voting and
statement voting whereas this project and other projects deal with only plurality electoral system
voting. The other enhancement could be making the system truly decentralized and yet achieving
same degree of security and scalability.

9.3 Summary
In the chapter 9 we have discussed the limitations of the hierarchical blockchain design of e-
voting system and the possible future enhancements in detail.