Professional Documents
Culture Documents
Final Documentation
Final Documentation
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.
External Viva
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.
EC Election commission
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
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
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
References 59
Appendices 65
Appendix 1 65
Appendix 2 66
5.1 Structure chart for hierarchical blockchain design for e-voting system 42
CHAPTER-1
Introduction
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.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 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.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.
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.
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.
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.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
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.
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. 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
7. Vote once any authorized voter can only vote once in an election
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.
Windows 7 or higher
4 GB RAM or higher
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.
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
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.
Then following that deciding on what would the different stages in which the election would
be conducted as shown in the Figure 6.
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.
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.
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.
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
Fig 4.1. 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.
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
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.
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.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.
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.
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.
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.
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.
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
RAM - 4 Gb (min)
Monitor - SVGA
SOFTWARE REQUIREMENTS
Database : SQL
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.
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.
Unit testing by entering invalid 8 characters OTP received in e-mail which should not
authenticate the voter in table 7.5
The next unit testing is done on receiving the OTP on e-mail of valid voters given in table
7.6.
The next unit testing involves checking the private key received on email and entering for
casting vote given in table 7.7
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.
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.
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.
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.
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.
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.
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.
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.
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.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
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
[4] M. Malhotra, A. Kumar, S. Kumar, and V. Yadav, “Untangling e-voting platform for
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
Science and Engineering, vol. 1099, no. 1, p. 012038, Mar. 2021. doi:10.1088/1757-
899x/1099/1/012038
991013114548703412
[8] Y. Abuidris, R. Kumar, T. Yang, and J. Onginjo, “Secure large ‐scale e ‐voting system
Sharding,” ETRI Journal, vol. 43, no. 2, pp. 357–370, Nov. 2020.
doi:10.4218/etrij.2019-0362
[10] Ž. Turk, “Interoperability in construction - hype and Reality,” Blockchain BIM, Oct.
2022. doi:10.47330/cbc.2022.zixt1087
doi:10.36227/techrxiv.21532953.v2
doi:10.36227/techrxiv.21532953
doi:10.36227/techrxiv.21532953.v1
doi:10.36227/techrxiv.21532953.v1
doi:10.12783/dtcse/cst2017/12539
Appendices
Appendix 1: Screenshots
In Fig A.1, the admin i.e. election commissioner adds the voters in the voting list.
In Fig. A.3 and A.4, The second step voter authentication of the registered email id of the
valid voter via OTP.
Appendix -2
Department of Computer Science and Engineering 2022-23 Page 73
Hierarchical blockchain design for e-voting system