INDUSTRIAL TRAINING REPORT ATTENDED

AT COMPANY/ORGANIZATION NAME

CSE-412 INDUSTRIAL TRAINING

(Duration of Training: 05-06-2023 TO 28-07-2023)
Submitted in partial fulfillment for the award of the degree of
BACHELOR OF TECHNOLOGY
(Computer Science and Engineering)

Submitted to
INDIAN INSTITUTE OF INFORMATION TECHNOLOGY
BHOPAL (M.P.)

Submitted by
Rahul Prasad (20U02030)

Under the supervision of

HARSH and LUJA SWAIN
Blockchain Developer and HR

NOVEMBER 2023
INCLUDE COPY OF THE CERTIFICATE
PROVIDED BY THE
COMPANY/ORGANIZATION
 INDIAN INSTITUTE OF
INFORMATION TECHNOLOGY
BHOPAL (M.P.)

DECLARATION

I hereby declare that the industrial training report presented herein is the culmination of my
industrial training at Compozent, conducted in accordance with our curriculum during the
time period 6 June 2023 to 28 July 2023. This report is being submitted in the partial
fulfillment of the requirements for the award of the degree of Bachelor of Technology in
Computer Science & Engineering from the Indian Institute of Information Technology
Bhopal MP India.

The work documented in this report is the result of our original efforts and has been
conducted under the able guidance and supervision of Harsh at Compozent. We affirm that
this report accurately reflects our work during the training period.

Furthermore, we confirm that this industrial training report has not been previously
submitted, in part or in whole, for the fulfillment of any other degree or professional diploma
at any other educational institution or organization.

It is my declaration that the information provided in this report is based on my knowledge

and experience. In the event of any discrepancies that may occur, it is my responsibility to
accept full responsibility.

Rahul Prasad (20U02030) Sign of student

 ACKNOWLEDGMENTS
This dissertation would not have been possible without the guidance and the help of several
individuals who in one way or another contributed and extended their valuable assistance in
the preparation and completion of this study. I am thankful to Mr. Harsh, my project guide
from Compozent and some of the colleagues for devoting time from their busy schedule and
explaining how work is being done and assigning me with various tasks during these
internship period. I would also like to thanks to the entire staff for their full co-operation,
guidance and support during my project period.
 TABLE OF CONTENT
S.no Title Page No.
Certificate
Declaration
Acknowledgments
1 Introduction 1
2 Company Profile 2
3 Training Objectives 3
4 Methodology 4
5 Technical Details 5
6 Results and Achievements 6
7 Challenges Faced 7
8 Learnings and Insights 8
9 Conclusion 9
10 References 10
 LIST OF FIGURES
Fig Description Page no.
1 Stream Processing Pipeline
2 Lambda Architecture
3 Kappa Architecture
4 HDFS Architecture
5 Streaming Data Pipeline
6 Kafka Producer & Consumer
7 Multiple Node Multiple Broker Cluster
8 Output of Clusters
9 Output of Clusters for Analysis
 LIST OF TABLES

Table No Description Page no.

1 Comparison of Data Ingestion Methods
2 Analysis of Clusters
 INTRODUCTION

1.1 Overview

Voting system is a very crucial activity of all democratic country. The traditional
voting system is leading to lot of expenditure and very un-convenient to the enduser.
A whole world is exploring a secure and reliable voting system which can take care of
user convenient. The advent of block chain technology has given a new hope towards
the development of secure and convenient voting system. Block chain is the public
distributed database, which holds the encrypted ledger. The reason behind encrypted,
is to keep the details of the user anonymous. Instead of a centralized database, all the
transaction data that is shared across the nodes in the blockchain is contained in
bundles of records called blocks, which are chained together to create the public
ledger. This public ledger represents all the data in the blockchain. All the data in the
public ledger is secured by cryptographic hashing, and validated by a consensus
algorithm. Nodes on the network participate to ensure that all copies of the data
distributed across the network are the same. That’s one very important reason why
we’re building our voting application on the blockchain, because we want to ensure
that our vote was counted, and that it did not change. Since, block chain technology
prevents the recorded vote from any short of tempering at the same time it offers to
changes the casted option to the legitimate user. Some of the evident work done to
reflect these benefits are as follows:

i. Very Vote System by Rui Joaquim, Carlos Ribeiro, and Paulo Ferreira in
which they provide the threshold encryption scheme which enable the vote
and the verification without compromising the voters privacy.

ii. Securing e-voting based on blockchain in P2P network by Haibo Yi in which

they provided the user credential system and compute the hash value which
are based upon SHA-256. It usually used to compare the hash value to
expected hash value for the Data Integrity.

iii. Secure Digital Voting System based on Blockchain Technology by Kashif

Mehboob Khan, Junaid Arshad, Muhammad Mubashir Khan NED University
of Engineering and Technology where they use the concept of Multichain to
protect the anonymity and integrity of a vote. Their System Generate the
Strong Cryptographic Hash for Each Vote Transaction based on specific user.

The user needs an account with a wallet address with some Ether, Ethereum's
cryptocurrency. Once they connect to the network, they cast their vote and pay a small
transaction fee to write this transaction to the blockchain. This transaction fee is called

1
 “gas”. Whenever the vote is cast, some of the nodes on the network, called miners,
compete to complete this transaction. The miner who completes this transaction is
awarded the Ether that we paid to vote. Smart contracts are where all the business
logic of our application lives. This is where we’ll actually code the decentralized
portion our app. Smart contracts are in charge of reading and writing data to the
blockchain, as well as executing business logic. Smart contacts are written in a
programming language called Solidity, The function of smart contracts on the Bock-
chain is very similar to a microservice on the web. If the public ledger represents the
database layer of the blockchain, then smart contracts are where all the business logic
that transacts with that data lives. We’ll have a traditional front-end client that is
written in HTML, CSS, and JavaScript. Instead of talking to a back-end server, this
client will connect to a local Ethereum blockchain that we’ll install. We’ll code all the
business logic about our dapp in an Election smart contract with the Solidity
programming language. We’ll deploy this smart contract to our local Ethereum
blockchain, and allow accounts to start voting. We'll build a client-side application
that will talk to our smart contract on the blockchain. This client-side application will
have a table of candidates that lists each candidate's id, name, and vote count. It will
have a form where we can cast a vote for our desired candidate. It also shows the
account we're connected to the blockchain with under "public address" which are
unique each user.

1.2 General Overview of the Problem

In a normal voting system, it usually done on paper or by electronic voting system
which can lead to frauds. The money and effort for managing the voting process can
be huge. The Data records can be lost and maintaining all the records can be difficult.
Without the Proper Mechanism, the system can be very complex and our main aim is
to provide a simple system. In a normal web application, whenever we want to access
the application, we require centralized data base which is not preferable in e-voting
system. By using centralized network number of votes and code for the application
can be changed by any time by unauthorized user which may lead to error.

Feasibility Study
Feasibility study is an analysis that takes all of a project’s relevant factor into an
account including economic, technical, legal and schedule considerations to ascertain
the likelihood of completing the project successfully. During the feasibility study of
this projects the relevant factors were found to be feasible which is described below:

1.2.1 Economic Feasibility

There is not excess amount of cost to be spent for the completion of this project.
For deployment the cost required is not much more and is affordable. therefore,
after the analysis of this project was found to be economically feasible.

2
1.2.2 Technical Feasibility
The project can be completed on the simple systems by using node JS, metamask
and Ethereum where it provides the free 10 addresses along with its private key.
Not much more complex system is required for the completion of the project.

1.2.3 Legal Feasibility

As the project that is purposed will be developed within our institution using the
resources available here, the legal feasibility is assured because all the software,
operating system and tools available are licensed. Therefore, neither the institution
nor the proposed project will face the legal threats.

3
 COMPANY PROFILE

At Compozent, they have a mission to be an essential part of every student's educational

journey. They aim to empower students with valuable knowledge and the confidence to
confront real-world challenges in their chosen fields. Compozent is all about equipping
students with the tools they need to succeed in the real world.

Compozent is driven by a lofty vision: to ignite the flames of inspiration and furnish students
with the essential skills and knowledge they need to flourish in the dynamic realms of media
and technology. Our mission is simple but profound – we endeavor to offer students a
transformative platform, one that immerses them in hands-on experiences that mirror real-
world situations.
At Compozent, we don't just prepare students; we challenge and sculpt them. We believe that
true learning lies in the crucible of experience, where one's problem-solving abilities are
sharpened like a fine blade, communication skills polished to a brilliant sheen, and technical
prowess honed to a level of excellence.
But we don't stop there. We are staunch advocates of innovation and creativity, viewing them
as the twin pillars upon which the future stands. In our nurturing environment, we aim to
kindle the fires of passion for innovation, encouraging students to think beyond boundaries
and fostering a spirit of creativity that will be their guiding light as they journey towards their
future careers.
Compozent is not just an institution; it's a crucible for transformation, a forge where students
are not just educated but empowered, not merely trained but inspired. We believe in
equipping the leaders of tomorrow with the tools and the fire they need to shape the world of
media and technology in their own unique and innovative ways.

4
 TRAINING OBJECTIVES

PROBLEM DEFINITATION

In a normal voting system, it usually done on paper or by electronic voting system which can
lead to frauds the money and effort for managing the voting process can be huge if we build
normal web application, whenever we want to access the application, we required the
centralized data base which is not preferable for evoting system and there is server crash like
error 404. The current system will not show the result after voting, the voters privacy is not
secure it will show the voters details and the cost of ethereum gas fee is very high.

3.1. Analysis of the problem

As in the normal web application we usually use a web browser and perform a operation in a
centralized server through a network. All the codes and data are stored in a centralized
database and any time when we want to access or use the application, we required a
centralized server which is not preferable for the e-voting system.
The problem was analysed and the following points are considered.
• By ensuring that all the votes should only counted once and the correct candidate with
actual votes will be able to win the election.
• The data is decentralized in block chain in a peer-to-peer network.
• It provides the high level of security i.e. once the voter votes the candidate. Authorized and
un-authorized user will not be able to modify the vote count.

3.2. Objective
• The objective of this online voting system is to provide secure voting system.
• Voter can cast their vote in less gas fee.
• Voter’s privacy will be secured.
• No server crash(error 404).

5
 METHODOLOGY

4.1. ARCHITECTURE DIAGRAM

Fig-1: Architectural Diagram

6
4.2. SEQUENCE DIAGRAM

Sequence diagrams are interaction diagrams that detail how operations are carried out. They
capture the interaction between objects in the context of a collaboration. Sequence Diagrams
are time focus and they show the order of the interaction visually by using the vertical axis of
the diagram to represent time what messages are sent and when.

Fig-2. SEQUENCE DIAGRAM

7
4.3. Use case diagram
A use case diagram is a way to summarize details of a system and the users within that
system. It is generally shown as a graphic depiction of interactions among different elements
in a system. Use case diagrams will specify the events in a system and how those events flow,
however, use case diagram does not describe how those events are implemented.

Fig-3. use case diagram

8
 Software Development Life Cycle (SDLC)

The life cycle model used for this development of the software is Iterative Waterfall Model. It
allows to go back on the previous phase and change the requirements therefore some
modification can do if necessary. This model reduces the developer’s effort and time required
to detect and correct the errors.

Fig-4. Iterative waterfall model

9
 TECHNICAL DETAILS
Smart Contract Development

Smart Contract Language: Solidity

Solidity is a widely used programming language for developing smart contracts on the
Ethereum blockchain due to its security features and compatibility.

IDE (Integrated Development Environment):

Remix Remix is a popular online IDE for writing, testing, and deploying Solidity smart
contracts. It offers a user-friendly interface and real-time feedback on contract behavior.

Blockchain Platform: Ethereum

Ethereum is chosen as the blockchain platform for its robustness and wide adoption, making
it suitable for decentralized applications, including voting systems.

Contract Structure

Contract Architecture:

A single contract is used to manage the entire voting process.

The contract comprises several key functionalities, including candidate registration, voter
registration, vote casting, vote tallying, and result declaration.

Candidate Registration:

Candidates are registered by the contract owner or an authorized entity.

Candidate details, including their name and party affiliation, are stored in an array within the
contract.

Voter Registration:

Eligible voters register by providing their Ethereum addresses.

Voter addresses are recorded in a mapping to ensure that only registered voters can
participate.

Voting Mechanism:

Registered voters can cast their votes through the contract's user interface.

10
The contract ensures that a voter can only vote once.

Vote Tallying:

Vote counts are maintained for each candidate using a mapping.

As votes are cast, the contract updates the counts in real-time.

Election Management:
The contract owner or an authorized entity has the authority to start and end the election.
After the election ends, the contract calculates the final vote counts and determines the
winner.

Security and Transparency

Access Control:
Access control mechanisms are implemented to prevent unauthorized parties from modifying
the contract.
Only the contract owner or authorized entities have the ability to perform specific actions,
such as candidate registration and election management.

Blockchain Security:

The blockchain's inherent security features, including decentralization, immutability, and

transparency, ensure the integrity of the voting process.
All actions, including voter registration and vote casting, are recorded on the blockchain.

User Interface
Decentralized Application (DApp):

Users interact with the voting system through a user-friendly DApp.

The DApp communicates with the smart contract, allowing voters to participate, candidates
to monitor their progress, and observers to check the results.

Verification:
Election results are stored on the blockchain and can be independently verified by interested
parties, ensuring transparency and integrity.

11
12
 RESULTS AND ACHIVEMENTS

CONTRACT
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

contract Voting {
struct Candidate {
string name;
uint256 voteCount;
}

Candidate[] public candidates;

address owner;
mapping(address => bool) public voters;

uint256 public votingStart;

uint256 public votingEnd;

constructor(string[] memory _candidateNames, uint256 _durationInMinutes) {

for (uint256 i = 0; i < _candidateNames.length; i++) {
candidates.push(Candidate({
name: _candidateNames[i],
voteCount: 0
}));
}
owner = msg.sender;
votingStart = block.timestamp;
votingEnd = block.timestamp + (_durationInMinutes * 1 minutes);
}

modifier onlyOwner {
require(msg.sender == owner);
_;
}

function addCandidate(string memory _name) public onlyOwner {

candidates.push(Candidate({
name: _name,
voteCount: 0
}));
}

function vote(uint256 _candidateIndex) public {

13
 require(!voters[msg.sender], "You have already voted.");
require(_candidateIndex < candidates.length, "Invalid candidate
index.");

candidates[_candidateIndex].voteCount++;
voters[msg.sender] = true;
}

function getAllVotesOfCandiates() public view returns (Candidate[] memory)

{
return candidates;
}

function getVotingStatus() public view returns (bool) {

return (block.timestamp >= votingStart && block.timestamp <
votingEnd);
}

function getRemainingTime() public view returns (uint256) {

require(block.timestamp >= votingStart, "Voting has not started
yet.");
if (block.timestamp >= votingEnd) {
return 0;
}
return votingEnd - block.timestamp;
}
}

Fig. 5

14
 Fig. 6

Deploy.JS
async function main() {
const Voting = await ethers.getContractFactory("Voting");

// Start deployment, returning a promise that resolves to a contract object

const Voting_ = await Voting.deploy(["Manish", "Bhuvnesh", "Utkarsh",
"Sarkar"], 90);
console.log("Contract address:", Voting_.address);

main()
.then(() => process.exit(0))
.catch(error => {
console.error(error);
process.exit(1);
});

15
 Fig. 7

Fig. 8

16
Lock
const {
time,
loadFixture,
} = require("@nomicfoundation/hardhat-toolbox/network-helpers");
const { anyValue } =
require("@nomicfoundation/hardhat-chai-matchers/withArgs");
const { expect } = require("chai");

describe("Lock", function () {
// We define a fixture to reuse the same setup in every test.
// We use loadFixture to run this setup once, snapshot that state,
// and reset Hardhat Network to that snapshot in every test.
async function deployOneYearLockFixture() {
const ONE_YEAR_IN_SECS = 365 * 24 * 60 * 60;
const ONE_GWEI = 1_000_000_000;

const lockedAmount = ONE_GWEI;

const unlockTime = (await time.latest()) + ONE_YEAR_IN_SECS;

// Contracts are deployed using the first signer/account by default

const [owner, otherAccount] = await ethers.getSigners();

const Lock = await ethers.getContractFactory("Lock");

const lock = await Lock.deploy(unlockTime, { value: lockedAmount });

return { lock, unlockTime, lockedAmount, owner, otherAccount };

}

describe("Deployment", function () {
it("Should set the right unlockTime", async function () {
const { lock, unlockTime } = await
loadFixture(deployOneYearLockFixture);

expect(await lock.unlockTime()).to.equal(unlockTime);
});

it("Should set the right owner", async function () {

const { lock, owner } = await loadFixture(deployOneYearLockFixture);

expect(await lock.owner()).to.equal(owner.address);
});

it("Should receive and store the funds to lock", async function () {

const { lock, lockedAmount } = await loadFixture(
deployOneYearLockFixture
);

17
 expect(await ethers.provider.getBalance(lock.target)).to.equal(
lockedAmount
);
});

it("Should fail if the unlockTime is not in the future", async function ()

{
// We don't use the fixture here because we want a different deployment
const latestTime = await time.latest();
const Lock = await ethers.getContractFactory("Lock");
await expect(Lock.deploy(latestTime, { value: 1 })).to.be.revertedWith(
"Unlock time should be in the future"
);
});
});

describe("Withdrawals", function () {
describe("Validations", function () {
it("Should revert with the right error if called too soon", async
function () {
const { lock } = await loadFixture(deployOneYearLockFixture);

await expect(lock.withdraw()).to.be.revertedWith(
"You can't withdraw yet"
);
});

it("Should revert with the right error if called from another account",
async function () {
const { lock, unlockTime, otherAccount } = await loadFixture(
deployOneYearLockFixture
);

// We can increase the time in Hardhat Network

await time.increaseTo(unlockTime);

// We use lock.connect() to send a transaction from another account

await
expect(lock.connect(otherAccount).withdraw()).to.be.revertedWith(
"You aren't the owner"
);
});

it("Shouldn't fail if the unlockTime has arrived and the owner calls
it", async function () {
const { lock, unlockTime } = await loadFixture(
deployOneYearLockFixture
);

18
 // Transactions are sent using the first signer by default
await time.increaseTo(unlockTime);

await expect(lock.withdraw()).not.to.be.reverted;
});
});

describe("Events", function () {
it("Should emit an event on withdrawals", async function () {
const { lock, unlockTime, lockedAmount } = await loadFixture(
deployOneYearLockFixture
);

await time.increaseTo(unlockTime);

await expect(lock.withdraw())
.to.emit(lock, "Withdrawal")
.withArgs(lockedAmount, anyValue); // We accept any value as `when`
arg
});
});

describe("Transfers", function () {
it("Should transfer the funds to the owner", async function () {
const { lock, unlockTime, lockedAmount, owner } = await loadFixture(
deployOneYearLockFixture
);

await time.increaseTo(unlockTime);

await expect(lock.withdraw()).to.changeEtherBalances(
[owner, lock],
[lockedAmount, -lockedAmount]
);
});
});
});
});

19
Fig. 9

Fig. 10

20
Env

API_URl = "https://rpc.sepolia.org"
PRIVATE_KEY =
"ed538cbac95b60932674bed06b0a8fe7859221e0083481535ee792cf836cb745"
CONTRACT_ADDRESS = "0xE9c226AA8C68aC7cf85CEC6707B23FCBE1551D54"

Fig. 11

21
Fig. 12

Fig. 13

22
 CHALLENGES FACED

Blockchain Integration

Challenge 1: Integration Complexity

 Integrating the voting application with the Ethereum blockchain presented a

significant challenge. Ensuring seamless communication between the user interface
and the smart contract, handling transactions, and managing gas costs required careful
consideration.

Security and Privacy

Challenge 2: Voter Privacy

 Maintaining voter privacy while ensuring transparency on the blockchain was a

delicate balance. Implementing cryptographic techniques to protect voter identities
without compromising the integrity of the election process required specialized
expertise.

Challenge 3: Smart Contract Security

 Developing a secure smart contract to prevent vulnerabilities such as reentrancy

attacks, denial of service, and unauthorized access was a continuous challenge.
Extensive testing and auditing were necessary to identify and mitigate potential risks.

Challenge 4: Gas Costs

Managing gas costs associated with executing transactions on the blockchain was a financial
challenge. Optimizing the smart contract and DApp to minimize gas fees while maintaining
functionality was crucial.

23
Testing and Audit

Challenge 5: Rigorous Testing

 Rigorously testing the entire system, from the smart contract to the DApp, was time-
consuming. Identifying and addressing bugs and vulnerabilities to guarantee the
system's reliability and security was an ongoing challenge.

Project Management

Challenge 6: Time Constraints

Meeting project deadlines while addressing the complexities and challenges faced throughout
the development process was a significant project management challenge. Effective time and
resource management were critical.

24
 LEARNINGS AND INSIGHTS
Blockchain Technology
Insight 1: Decentralization

 The project emphasized the power of decentralization in maintaining trust and

transparency. Using blockchain technology, we were able to eliminate the need for a
central authority, reducing the risk of manipulation in the voting process.

Insight 2: Immutability

 The immutability of the blockchain was a valuable feature. Once data is recorded on
the blockchain, it cannot be altered, which is essential for maintaining the integrity of
an election.

Security and Privacy

Insight 3: Security Best Practices

 We learned the importance of implementing security best practices throughout the

development process. This included secure coding, access control, and third-party
auditing to identify and address vulnerabilities.

Insight 4: Privacy-Preserving Techniques

 Protecting voter privacy while maintaining transparency was a delicate balance. We

gained insights into privacy-preserving techniques, such as zero-knowledge proofs,
which can be used to anonymize votes.

User Experience
Insight 5: User-Centric Design

 A user-friendly design was crucial for adoption. We discovered that a user-centric

approach, with a focus on accessibility and intuitive interfaces, greatly improved the
overall user experience.

Insight 6: Gas Optimization

 Managing gas costs was an ongoing challenge, but it also provided insights into
optimizing smart contracts for efficiency. We learned to balance functionality with
cost-effectiveness.

25
Compliance and Legal Considerations
Insight 7: Legal Expertise

 Navigating the legal and regulatory landscape of blockchain-based voting systems

taught us the significance of legal expertise. Collaboration with legal professionals
was essential for compliance.

Insight 8: Customization

 Understanding the need for customization based on the legal requirements of different
jurisdictions was a key insight. A flexible system architecture allowed for compliance
with varying legal frameworks.

Project Management
Insight 9: Thorough Testing

 The project reinforced the importance of thorough testing, including unit testing,
integration testing, and security testing. It highlighted the need for continuous quality
assurance.

Insight 10: Collaboration

 Collaborating with experts in blockchain development, security, and legal matters was
pivotal. Effective teamwork and communication played a significant role in
overcoming challenges.

Future Development
Insight 11: Continuous Improvement

 We recognized that the development of a blockchain-based voting application is an

ongoing process. Continuous improvement, updates, and adaptations to address
emerging challenges and advancements in technology are essential.

Insight 12: Public Awareness

 Creating awareness and educating the public about the benefits and security of
blockchain-based voting systems is a crucial aspect of future development.

26
 CONCLUSION
6.1 Summary of Achievement
By accomplishing this project, I gained a lot of knowledge about the solidity programming
language and basic concept of decentralized network (Block-chain). Not only I acquire a
knowledge of technical aspect but also the importance of planning and scheduling of the
project. I have created simple frontend of election results where I successfully implemented
and tested the contract of migration and election. It can Test the various condition at Truffle
CLI where it ensure that contract code is bug free. If the contract contains any bugs, it might
disable the contract and deploy the new copy. It minimizes the cost of ether during the
transaction. Setup the web3 and inject the meta-mask to the local server. Each account
(voters) by linking the private key at the Ethereum we can vote only one time. We can view
the unique address of the account(voter) after migrating into the blockchain. Successfully
incremented vote count of the candidate which lead to change in the state of the block chain.

6.4 Future scope of the project

Security and privacy are two pivotal aspects that bear the load of public expectation for
evoting system using blockchain. Longer the node-chain gets it is harder for attacker to
decrypt. It offers the transparency in terms of validating the accuracy of the trail of votes.
Since the nodes are distributed randomly, the dependency on a centralized authority to secure
the cyberspace is automatically mitigated in a Blockchain e-voting system.

6.5 Conclusion
The Block-chain technology have lot of potential to improve the traditional voting system. It
is having a potential to produce a voter verifiable voting system where the voting system can
be designed in a minimal cost. It can eliminate lot of effort and investment made in the
traditional voting system. Therefore, the development of block chain-based voting system can
be considered as very relevant in the current scenario.

27
 REFERENCES
[1]. Joaquim R., Ribeiro C., Ferreira P. “Very Vote: A Voter Verifiable Code Voting
System.” In: Ryan P.Y.A., Schoen makers B. (eds) E-Voting and Identity. Vote-ID 2009.
Lecture Notes in Computer Science, vol 5767.

DOI: https://doi.org/10.1007/978-3-642-04135-8_

[2]. Yi H., “Securing e-voting based on blockchain in P2P network”. J Wireless Com
Network 2019, 137 (2019).

DOI: https://doi.org/10.1186/s13638-019-1473-6

[3]. Kashif Mehboob Khan, J. Arshad, Muhammad Mubashir Khan, “Secure Digital Voting
System based on Blockchain”. NED University of Engineering and Technology, Ptisan, West
London, UK (2018)

DOI: https://doi.org/10.1186/d4532243-019-1473-6 .

[4]. Rivest, R.L.: Electronic voting. In: Syverson, P.F. (ed.) FC 2001. LNCS,vol. 2339, pp.
243–268. Springer, Heidelberg (2001)

[5]. UK’s National Technical Authority for Information Assurance: e-voting security study
(2002)

DOI: http://www.ictparliament.org/CDTunisi/ict_compendium/paesi/uk/uk54.pdf.

[6]. UK’s Electoral Commission: Technical report on the may 2003 pilots (2003)

DOI: http://www.electoralcommission.org.uk/about-us/03pilotscheme.cfm.

[7]. Estonian National Electoral Commitee: Internet voting in estonia (2007),

DOI: http://www.vvk.ee/engindex.html.

[8]. Neff, A.: Practical high certainty intent verification for encrypted votes (2004),

DOI: http://www.votehere.com/old/vhti/documentation/vsv-2.0.3638.pdf.

28