Final

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING
Hierarchical Block chain Design for E voting system

PROJECT REPORT
Submitted by,
AKANSHA BANERJEE 1RV19CS007
PRIYANSHU KUMARI 1RV19CS120
Under the guidance of
Dr. Ashok Kumar A R

Associate Professor
Dept of CSE
RV College of Engineering
In partial fulfillment for the award of degree

of
Bachelor of Engineering
in
Computer Science and Engineering
2022-2023
RV COLLEGE OF ENGINEERING ®, BENGALURU-59
(Autonomous Institution Affiliated to VTU, Belagavi)
CERTIFICATE
Certified that the major project work titled ‘Hierarchical blockchain design for e voting system’
is carried out by Akansha Banerjee (1RV19CS007), Priyanshu Kumari (1RV19CS120) who
are bonafide students of RV College of Engineering, Bengaluru, in partial fulfilment for the
award of degree of Bachelor of Engineering in Computer Science and Engineering of the
Visvesvaraya Technological University, Belagavi during the year 2022-2023. It is certified that
all corrections/suggestions indicated for the Internal Assessment have been incorporated in the
major project report deposited in the departmental library. The major project report has been
approved as it satisfies the academic requirements in respect of major project work prescribed by
the institution for the said degree.
Signature of Guide Signature of Head of the Department Signature of Principal

Dr. Ashok Kumar A R Dr. Ramakanth Kumar P Dr.K.N.Subramanya
External Viva
Name of Examiners Signature with Date
2
RV COLLEGE OF ENGINEERING ®, BENGALURU-59
(Autonomous Institution Affiliated to VTU, Belagavi)
DECLARATION
We, Akansha Banerjee , Priyanshu Kumari students of eighth semester B.E., department of
CSE, RV College of Engineering, Bengaluru, hereby declare that the major project titled
‘Hierarchical Block chain design for e-voting system’ has been carried out by us and
submitted in partial fulfilment for the award of degree of Bachelor of Engineering in Computer
Science and Engineering during the year 2022-23.
Further we declare that the content of the dissertation has not been submitted previously by
anybody for the award of any degree or diploma to any other university.
We also declare that any Intellectual Property Rights generated out of this project carried out at
RVCE will be the property of RV College of Engineering, Bengaluru and we will be one of the
authors of the same.
Place: Bengaluru
Date:
Name Signature
1. Akansha Banerjee (1RV19CS007)
2. Priyanshu Kumari (1RV19CS120)
ACKNOWLEDGEMENT
We are indebted to our guide, Dr. Ashok Kumar A R, Associate Professor, Dept of CSE for
his wholehearted support, suggestions and invaluable advice throughout our project work and
also helped in the preparation of this thesis.
We also express our gratitude to our panel members Dr. Nagaraja G S., Professor, and
Dr.Soumya A., Associate Professor, Department of Computer Science and Engineering for
their valuable comments and suggestions.
Our sincere thanks to Dr. Ramakanth Kumar P., Professor and Head, Department of Computer
Science and Engineering, RVCE for his support and encouragement.
We express sincere gratitude to our beloved Principal, Dr. K. N. Subramanya for his
appreciation towards this project work.
We thank all the teaching staff and technical staff of Computer Science and Engineering
department, RVCE for their help.
Lastly, we take this opportunity to thank our family members and friends who provided all the
backup support throughout the project work.
ABSTRACT
The process of casting a vote in the traditional physical voting system is time-consuming,
centralized, and 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 or no need to trust anyone in the system the protocol itself is such
full proof due to cryptographic techniques. 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.
Acronyms
POW Proof of work
POS Proof of stake
POC Proof of credibility
EC Election commission
SRS Software requirement specification
DFD Data flow diagram
OTP One time password

TABLE OF CONTENTS
Page No
Abstract
List of Tables
List of figures
Chapter 1
Introduction 1
1.1. State of Art Developments 2
1.2. Motivation 6
1.3. Problem Statement 7
1.4. Objective 7
1.5. Scope 8
1.6. Methodology 8
1.7. Organization of the Report 8
1.8. Summary 9
Chapter 2
Overview of Blockchain 10
2.1. Introduction 10
2.2. Relevant information 10
2.3 Summary 11
Chapter 3
Software Requirements Specification 15
3.1. Overall Description 15
3.1.1. Product Perspective 15
3.1.2. Product Functions 16
3.1.3. User Characteristics 16
3.1.4. Constraints and dependencies 16
3.2. Specific Requirements 17
3.2.1. Functional Requirements 17
3.2.2. Performance Requirements 17
3.2.3. Supportability 17
3.2.4. Software Requirements 18
3.2.5. Hardware Requirements 18
3.2.6. Design Constraints 18
3.2.7. Interfaces 19
3.2.7.1. User Interfaces of the system 19
3.2.7.2. Software Interfaces of the system 19
3.2.8. Non-Functional Requirements 19
3.3. Summary 20
Chapter 4
High Level Design of 21
4.1. Design Considerations 21

4.1.1. General Constraints 21
4.1.2. Development Methods 22
4.2. Architectural Strategies 22

4.2.1. Programming Language 22
4.2.2. User Interface Paradigm 22
4.2.3. Error Detection and Recovery 23
4.2.4. Data Storage Management 23
4.3. System Architecture 23
4.4. Data Flow Diagrams 24
4.4.1. Data Flow Diagram – Level 0 25
4.5. Summary 28
Chapter 5
Detailed Design 29
5.1. Structure Chart 29
5.2. Functional Description of the Modules 30
5.2.1. Order Assignment Module 30
5.2.2. Order Assignment Configuration Module 32
5.2.3. Master File Generation Module 33
5.3. Summary 34
Chapter 6
Implementation 35
6.1. Programming Language Selection 35
6.2. Platform Selection 36
6.3. Code Conventions 36
6.3.1. Naming Conventions 36
6.3.2. File Organization 37
6.3.3. Declarations 38
6.3.4. Comments 38
6.4. Difficulties Encountered and Strategies Used to Tackle Them 38

6.4.1. Concurrency Control 39
6.5. Summary 39
Chapter 7
Software Testing 40
7.1. Test Environment 40
7.2. Unit Testing 41
7.2.1. Unit Testing of Order Assignment Module 41
7.2.2. Unit Testing of Order Assignment Configuration Module 43
7.2.3. Unit Testing of Order Assignment 45
7.3. Integration Testing 46
7.3.1. Integration Testing for Order Assignment 47
7.3.2. Integration Testing for Order Assignment Configuration 47
7.3.3. Integration Testing of Master File Generation 48
7.3.4. Integration Testing of Order Assignment System 49
7.4. System Testing 50
7.5. Summary 51
Chapter 8
Experimental Results and Analysis 52
8.1. Evaluation Metrics 52
8.2. Experimental Dataset 52
8.3. Performance Analysis 53
8.3.1. Order Assignment 54
8.3.2. Master File Generation 55
8.4. Summary 56
Chapter 9
Conclusion and Future Enhancement 57

9.1. Limitations of the Project 57
9.2. Future Enhancements 58
9.3. Summary 58
References 59
Appendices 65
Appendix 1 65
Appendix 2 66
List of figures Page No
1. Structure of blockchain 17
2. User interface of the e-voting system 25
3. Software interface of the system 26
4. Agile software development strategy 30
5. Waterfall software development method 30
6. High level design of hierarchical block chain 30
7. The six stages in our e-voting system 31
8. Levels 0, 1, 2 of structure of the blockchain network 31
9. The high level working of the election process 32
10. Interface design spiral 33
11. Different levels of hierarchical blockchain design of e-voting system 35
12. Level 0 DFD 36
13. Level 1 dfd 37
14. Level 2 dfd 38
15. Structure chart for hierarchical blockchain design for e-voting system 41
16. Voter registration phase use case diagram 42
17. Sequence diagram of voter registration phase 43
18. Use case diagram ballot casting 44
19. Ballot casting sequence diagram 45
20. Use case diagram auditing voting process 46
21. Ballot tallying and opening sequence diagram 47
22. Election Initialization phase sequence diagram 48
23. Use case diagram of election intialization phase 48

Hierarchical blockchain design for e-voting system
CHAPTER-1
Introduction
Department of Computer Science and Engineering 2022-23 Page 12

CHAPTER 1
Introduction
1.1 State of the art developments
As mentioned by the authors of “A Framework to Make Voting System Transparent Using
Blockchain Technology”[2] 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[2].
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 [1]
as mentioned by the authors of the paper “Analysis of the possibilities for improvement of
blockchain technology” 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
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.
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 chapter 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

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.
1 structure of blockchain
2.2 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 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( ) time
and space so for 128 bit hashes the birthday attack would take O( ) 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

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.7 Interfaces
In software engineering, interfaces provide a contract or set of rules that specify how distinct
software components should interact with one another. They create a clear distinction
between components, allowing for modularity, reusability, and easy integration.

3.2.7.1 User Interface of the system
Figure 2 User interface of the e-voting system

3.2.7.2 Software Interface of the system
Figure 3 software interface of the system
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 of the hierarchical design of e-voting
system

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 takeninto 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).

Figure 4 Agile development
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.

Figure 5 Waterfall software development method
Figure 6 High level design of hierarchical block chain

Figure 7 Levels 0, 1, 2 of structure of the blockchain network
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 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.
Figure 8 the six stages in our e-voting system
Then following that deciding on what would the different stages in which the election would
be conducted as shown in the Figure 6.

Figure 9 the high level working of the election process
After which defining the high level working and what data is stored at each level of the block
chain system as shown in figure 7.
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.
Figure 10 Interface design spiral
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 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( ) time
and space so for 128 bit hashes the birthday attack would take O( ) 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.
Figure 11 Different levels of hierarchical blockchain design of e-voting system

4.3. Data Flow Diagrams

A Data Flow Diagram (DFD) gives an overview of how information flows throughout any
system or process. It displays data inputs, outputs, storage locations, and routes between each
destination using predefined symbols such as rectangles, circles, and arrows as well as brief
text labels. Data flow diagrams can be as simple as hand-drawn process overviews or much
more complex, multi-level DFDs that progressively delve deeper into the data handling
process. They can be used to model a new system or analyse an existing one. A DFD, like the
best diagrams and charts, can frequently "say" things visually that are challenging to convey
verbally. They are appropriate for both technical and non-technical audiences, from
developers to CEOs. That explains why DFDs are still so widely used today. These days, they
are less useful for visualising interactive, real-time, or database-oriented software or systems,
even though they still function well for data flow software and systems.
4.4.1. Data Flow Diagram – Level 0
Figure 12 Level 0 DFD

Figure 13 level 1 DFD

Figure 14 level 2 DFD
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

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.

Figure 15 Structure chart for hierarchical blockchain design for e-voting system
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.

Figure 16 voter registration phase use case diagram

Figure 17 Sequence diagram of voter registration phase

Figure 18 use case diagram ballot casting

Figure 19 ballot casting sequence diagram

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.
Figure 20 use case diagram auditing voting process

Figure 21 ballot tallying and opening sequence diagram
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.

Figure 23 use case diagram of election intialization phase
Figure 22 Election Initialization phase sequence diagram

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

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

Code conventions are a set of guidelines and standards that dictate the formatting, style, and
organization of source code in a software project. These conventions ensure consistency and
readability across the codebase, making it easier for developers to understand, maintain, and
collaborate on the code. Code conventions cover aspects such as naming conventions for
variables, functions, classes, and files, indentation and spacing rules, commenting practices,
and code structure guidelines. They may also include recommendations for error handling,
exception handling, and code documentation. By adhering to code conventions, developers
can produce code that is more readable, maintainable, and less prone to errors. Consistent
code formatting and style enhance code readability and make it easier to identify and fix
issues. Code conventions also promote a sense of unity and standardization within a
development team, facilitating code reviews and codebase comprehension. Overall, code
conventions play a vital role in promoting code quality, improving collaboration, and
enhancing the long-term maintainability of software projects.
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
Software testing is a crucial stage in the development of software that seeks to find and
correct bugs. Its primary goals are to increase performance, dependability, and quality. To
evaluate the functionality of the software and guarantee compliance with requirements,
testers employ techniques like unit, system, and integration testing. To find discrepancies, test
cases are created, run, and then compared to expected results. The development team records
and handles defects. Testing cuts down on the time and money needed for eventual solutions
by identifying problems early. Additionally, it guarantees that the programme fulfils user
needs, works as intended, and offers a positive user experience. Delivering high-quality
software without significant faults, meeting end-user expectations, and achieving overall
success in software development all depend on effective 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.
Testing was done on a Windows 11 machine. The hardware and software specifications are
as follows:

HARDWARE REQUIREMENTS
Processor - I3 Above
Speed - 2.4 Ghz
RAM - 4 Gb (min)
Hard Disk - 500 Gb
Key Board - Standard Windows Keyboard
Mouse - Two or Three Button Mouse
Monitor - SVGA
SOFTWARE REQUIREMENTS
Operating System : Windows
Front End : Anaconda Navigator
Database : SQL
Language : Python, HTML
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.
Table 7.1 Testing login validation
Once the voter has casted his vote he should not be allowed to cast his vote again shown in
table 7.3 Testing invalid alphanumeric aadhar id should not let invalid aadhar id caste vote as
shown in table 7.2.

Table 7.2 Testing invalid aadhar
Table 7.3 Testing single vote
Unit testing test case 4 involves electronic mail validation which is used for two way voter
authentication as in Table 7.4.

Table 7.4 Testing email validation
Unit testing by entering invalid 8 characters OTP received in e-mail which should not
authenticate the voter in table 7.5
Table 7.5 Testing invalid OTP
The next unit testing is done on receiving the OTP on e-mail of valid voters given in table
7.6.

Table 7.6 Testing receiving OTP on email
The next unit testing involves checking the private key received on email and entering for
casting vote given in table 7.7
Table 7.7 Testing receiving and entering valid private key

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:
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: 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
In order to validate the project's goals, evaluate its performance, and make wise judgements
about its optimisation or continued development, experimental data and analysis are essential.
The analysis could involve contrasting various methods, measuring the project against
standards or benchmarks, or examining the correlation between various factors.
The conclusions drawn from experimental data analysis and results aid in improving project
understanding, pinpointing areas for development, and aid in making decisions for upcoming
iterations or improvements. The analysis contributes to the validation of the project's
efficacy, dependability, scalability, security, or any other pertinent feature, offering insightful
information to stakeholders and assisting in the decision-making process.
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.

References
[1] D. Mechkaroska, V. Dimitrova, and A. Popovska-Mitrovikj, “Analysis of the
Possibilities for improvement of Blockchain technology,” 2018 26th
Telecommunications Forum (TELFOR), Nov. 2018. doi:10.1109/telfor.2018.8612034
[2] M. S. Farooq, U. Iftikhar, and A. Khelifi, “A framework to make voting system
transparent using blockchain technology,” IEEE Access, vol. 10, pp. 59959–59969, 2022.
doi:10.1109/access.2022.3180168
[3] “Security considerations for remote electronic voting over the internet,” Communications
Policy and Information Technology, 2002. doi:10.7551/mitpress/1953.003.0008
[4] M. Malhotra, A. Kumar, S. Kumar, and V. Yadav, “Untangling e-voting platform for
secure and enhanced voting using blockchain technology,” Transforming
Management with AI, Big-Data, and IoT, pp. 51–72, 2022. doi:10.1007/978-3-030-
86749-2_3
[5] A. P. Marańda, M. Pawlak, and J. Guziur, “Auditable blockchain voting system - the
blockchain technology toward the electronic voting process,” International Journal of
Web and Grid Services, vol. 16, no. 1, p. 1, 2020. doi:10.1504/ijwgs.2020.106102
[6] T. Sharma, C. Rama Krishna, and A. Bahga, “A cost-efficient proof-of-stake-voting
based auditable blockchain e-voting system,” IOP Conference Series: Materials
Science and Engineering, vol. 1099, no. 1, p. 012038, Mar. 2021. doi:10.1088/1757-
899x/1099/1/012038
[7] M. Li, Towards efficient and secure sharding-based blockchain. doi:10.14711/thesis-
991013114548703412

[8] Y. Abuidris, R. Kumar, T. Yang, and J. Onginjo, “Secure large‐scale e‐voting system
based on blockchain contract using a hybrid consensus model combined with
Sharding,” ETRI Journal, vol. 43, no. 2, pp. 357–370, Nov. 2020.
doi:10.4218/etrij.2019-0362
[9] M. Helal, A. R. Alsoud, and H. Alshareef, Cross-chain interoperability - validating
smart contracts to interoperate over diverse blockchain networks using interoperable
Blockchain Framework Design (IBFD), Nov. 2022. doi:10.21203/rs.3.rs-2217138/v1
[10] Ž. Turk, “Interoperability in construction - hype and Reality,” Blockchain BIM, Oct.
2022. doi:10.47330/cbc.2022.zixt1087
[11] Blockchain-based supply chain systems, interoperability model in a pharmaceutical
case study. doi:10.37473/fic/10.3390/s23041962
[12] IEEE standard for Blockchain Interoperability Data Authentication and
Communication Protocol. doi:10.1109/ieeestd.2023.10108929
[13] G. Wang and M. Nixon, “Intertrust: Towards an efficient blockchain interoperability
architecture with trusted services,” 2021 IEEE International Conference on
Blockchain (Blockchain), Dec. 2021. doi:10.1109/blockchain53845.2021.00029
[14] D. L. Dinesha and B. Patil, Achieving interoperability in heterogeneous blockchain users
through Inter-Blockchain Communication Protocol, Nov. 2022.
doi:10.36227/techrxiv.21532953.v2
doi:10.36227/techrxiv.21532953
[16] M. Sober, G. Scaffino, C. Spanring, and S. Schulte, “A voting-based Blockchain
Interoperability Oracle,” 2021 IEEE International Conference on Blockchain
(Blockchain), Dec. 2021. doi:10.1109/blockchain53845.2021.00030

doi:10.36227/techrxiv.21532953.v1
[18] Decentralized blockchain interoperability. doi:10.12681/eadd/49388
doi:10.36227/techrxiv.21532953.v1
[20] Z. CHEN, Z. YU, Z. DUAN, and K. HU, “Inter-blockchain communication,” DEStech
Transactions on Computer Science and Engineering, no. cst, Jul. 2017.
doi:10.12783/dtcse/cst2017/12539
[21] E. Akbari, Q. Wu, W. Zhao, H. R. Arabnia, and M. Q. Yang, “From blockchain to
internet-based voting,” 2017 International Conference on Computational Science and
Computational Intelligence (CSCI), Dec. 2017. doi:10.1109/csci.2017.34

Appendices
Appendix 1: Screenshots
In Fig A.1, the admin i.e. election commissioner adds the voters in the voting list.
Figure A.1 Add voters to voting list
In Fig A.2, the voters in the voting list are authenticated based on their unique Aadhar id.
Figure A.2 Authentication of voters based on Aadhar id

In Fig. A.3 and A.4, The second step voter authentication of the registered email id of the
valid voter via OTP.
Figure A.3 email authentication for voter
Figure A.4 OTP based voter e-mail authentication

Appendix -2




Final

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Final

Uploaded by

Copyright:

Available Formats

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING

Hierarchical Block chain Design for E voting system

AKANSHA BANERJEE 1RV19CS007

PRIYANSHU KUMARI 1RV19CS120

Under the guidance of

Dr. Ashok Kumar A R

In partial fulfillment for the award of degree

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING

Signature of Guide Signature of Head of the Department Signature of Principal

Name of Examiners Signature with Date

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING

Building a hierarchy of blockchain that uses blockchain interoperability concept to communicate

POW Proof of work

POS Proof of stake

POC Proof of credibility

SRS Software requirement specification

DFD Data flow diagram

OTP One time password

4.1. Design Considerations 21

4.2. Architectural Strategies 22

6.4. Difficulties Encountered and Strategies Used to Tackle Them 38

Conclusion and Future Enhancement 57

2. User interface of the e-voting system 25

3. Software interface of the system 26

4. Agile software development strategy 30

5. Waterfall software development method 30

6. High level design of hierarchical block chain 30

7. The six stages in our e-voting system 31

8. Levels 0, 1, 2 of structure of the blockchain network 31

9. The high level working of the election process 32

10. Interface design spiral 33

11. Different levels of hierarchical blockchain design of e-voting system 35

12. Level 0 DFD 36

13. Level 1 dfd 37

14. Level 2 dfd 38

16. Voter registration phase use case diagram 42

17. Sequence diagram of voter registration phase 43

18. Use case diagram ballot casting 44

19. Ballot casting sequence diagram 45

20. Use case diagram auditing voting process 46

21. Ballot tallying and opening sequence diagram 47

22. Election Initialization phase sequence diagram 48

23. Use case diagram of election intialization phase 48

Department of Computer Science and Engineering 2022-23 Page 12

Department of Computer Science and Engineering 2022-23 Page 13

1.3 Problem Statement

 We need to remove central control of the voting process or achieve decentralization.

Department of Computer Science and Engineering 2022-23 Page 14

1.7 Organization of the report

Department of Computer Science and Engineering 2022-23 Page 15

Department of Computer Science and Engineering 2022-23 Page 16

2.2 Cryptographic hash function

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

Department of Computer Science and Engineering 2022-23 Page 17

2.3 Immutable ledger

2.3.1 Structure of a block in a blockchain

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

2.3.2 Most important fields of block header