A DECENTERLIZED MILITARY

GRADE ENCRYPTED CHAT

APPLICATION USING
BLOCKCHAIN TECHNOLOGY

A thesis submitted by

SAMEER AKHTARI (GL) (18SW107)

MUHAMMAD HASSAN (18SW43)

Supervisor
Engr. Mariam Memon

In the Partial Fulfillment of the Requirements for the Degree of

Bachelor of Engineering in Software Engineering

DEPARTMENT OF SOFTWARE ENGINEERING

MEHRAN UNIVERSITY OF ENGINEERING &
TECHNOLOGY, JAMSHORO

October, 2022

i
 DEDICATION

This humble effort is

DEDICATED
to our PARENTS and
TEACHERS with
GRATITUDE and RESPECT

ii
 DEPARTMENT OF SOFTWARE ENGINEERING

CERTIFICATE OF APPROVAL

This is to certify that Project/Thesis report on “A Decen-

terlized Military Grade Encrypted Chat Application Using
Blockchain Technology” is submitted in partial fulfillment of the
requirements for a Bachelor’s degree in Software Engineering by the
following students:

SAMEER AKHTARI (GL) (18SW107)

MUHAMMAD HASSAN (18SW43)

Project/Thesis Supervisor Chairman

Engr. Mariam Memon Dr. Naeem Mahoto

Dated:

iii
 ACKNOWLEDGEMENT

First and foremost praise and gratitude to the Almighty ”Allah,”

the most Merciful and most Gracious., who blessed mankind with

knowledge and wisdom, and who gave us the intellectual capability

and ability to advance this project to the fascinating level of knowl-

edge. Secondly, We are sincerely grateful, to our Supervisor Engr.

Mariam Memon for her valuable help in providing constructive

suggestions and comments throughout the project and thesis, There

have numerous obstacles along the path in completing this final year

project, but hes guidance, support and confidence have taught us

how to work professionally as a team, to get up quickly and to go

forward. Thank you for your inspiration and patience. We would

also like to express our gratitude and special thanks to our chairman

Dr Naeem A.Mahoto for providing the maximum number of fa-

cilities in our department which help us a lot in our project work.

 TABLE OF CONTENTS

List of Abbreviations xi

List of Tables xii

List of Figures xv

Abstract xvi

1 INTRODUCTION 1

1.1 APPLICATION OVERVIEW . . . . . . . . . . . . . 1

1.2 BACKGROUND . . . . . . . . . . . . . . . . . . . . 1

1.3 PROBLEM STATEMENT . . . . . . . . . . . . . . . 2

1.4 PROPOSED SOLUTION . . . . . . . . . . . . . . . 3

1.5 AIMS AND OBJECTIVES . . . . . . . . . . . . . . 4

1.6 ADVANTAGE . . . . . . . . . . . . . . . . . . . . . . 4

1.7 THESIS ORGANIZATION . . . . . . . . . . . . . . 5

1.7.1 Chapter 1: Introdcution . . . . . . . . . . . . 5

1.7.2 Chapter 2: Literature Review . . . . . . . . . 5

1.7.3 CHAPTER 3: Blockchain Technology and En-

cryption . . . . . . . . . . . . . . . . . . . . . 5

1.7.4 CHAPTER 4: Tools and Technologies . . . . 5

v
 1.7.5 CHAPTER 5: Design, Developments and Im-

plementation . . . . . . . . . . . . . . . . . . 6

1.7.6 CHAPTER 6: Conclusion and Future work . . 6

2 LITERATURE REVIEW 7

2.1 OVERVIEW . . . . . . . . . . . . . . . . . . . . . . . 7

2.2 RELATED WORK . . . . . . . . . . . . . . . . . . . 7

2.2.1 TrueConf . . . . . . . . . . . . . . . . . . . . 10

2.2.2 Matrix . . . . . . . . . . . . . . . . . . . . . . 10

2.2.3 Wickr . . . . . . . . . . . . . . . . . . . . . . 11

2.2.4 Signal . . . . . . . . . . . . . . . . . . . . . . 11

2.2.5 Baariar . . . . . . . . . . . . . . . . . . . . . 12

2.2.6 Blackberry Messenger . . . . . . . . . . . . . 12

2.2.7 Tox Chat . . . . . . . . . . . . . . . . . . . . 12

3 BLOCKCHAIN TECHNOLOGY AND ENCRYPTION 14

3.1 BLOCKCHAIN . . . . . . . . . . . . . . . . . . . . . 14

3.2 SMART CONTRACTS . . . . . . . . . . . . . . . . . 17

3.3 TECHNICAL STRUCTURE . . . . . . . . . . . . . 18

3.3.1 Cryptography . . . . . . . . . . . . . . . . . . 18

3.3.2 Public And Private Keys . . . . . . . . . . . . 18

3.3.3 Blocks . . . . . . . . . . . . . . . . . . . . . . 19

3.3.4 Blocks Structure . . . . . . . . . . . . . . . . 20

vi
 3.3.5 Forming A Sequence . . . . . . . . . . . . . . 20

3.3.6 Transaction . . . . . . . . . . . . . . . . . . . 21

3.3.7 Timestamp Sequence . . . . . . . . . . . . . . 21

3.3.8 Blockchain Agreement Protocol . . . . . . . . 22

3.3.9 Proof of Labor . . . . . . . . . . . . . . . . . 22

3.3.10 Proof of Stake . . . . . . . . . . . . . . . . . . 24

3.3.11 Proof of Capability . . . . . . . . . . . . . . . 25

3.3.12 Network . . . . . . . . . . . . . . . . . . . . . 26

3.3.13 Distributed Ledger . . . . . . . . . . . . . . . 27

3.4 ETHERUEM BLOCKCHAIN NETWORK . . . . . . 28

3.4.1 Ethereum Philosphy . . . . . . . . . . . . . . 29

3.4.2 Gas And Payment . . . . . . . . . . . . . . . 30

3.4.3 Ethereum Virtual Machine . . . . . . . . . . . 31

3.4.4 Ethereum Smart Contract . . . . . . . . . . . 32

3.4.5 Interacting With Etherum Network . . . . . . 36

3.5 CONNECTING FRONT END WITH SMART CON-

TRACT ON ETHEREUM . . . . . . . . . . . . . . . 37

3.6 STORING DATA ON BLOCKCHAIN . . . . . . . . 41

3.7 MILITARY GRADE ENCRYPTION . . . . . . . . . 43

3.7.1 Encryption . . . . . . . . . . . . . . . . . . . 43

3.7.2 What Exactly Is Military Grade Encryption? 44

3.7.3 Installation Of Military Grade Encryption . . 45

vii
 3.7.4 What Exactly Is The Advance Encryption Stan-

dard (AES)? . . . . . . . . . . . . . . . . . . . 46

4 TOOLS AND TECHNOLOGIES 48

4.1 TOOLS . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.1.1 Visual Studio Code . . . . . . . . . . . . . . . 48

4.2 FRONT END TECHNOLOGIES . . . . . . . . . . . 49

4.2.1 React Native . . . . . . . . . . . . . . . . . . 49

4.2.2 React . . . . . . . . . . . . . . . . . . . . . . 49

4.2.3 JavaScript . . . . . . . . . . . . . . . . . . . . 50

4.2.4 Web3 . . . . . . . . . . . . . . . . . . . . . . . 50

4.2.5 Application Binary Interface . . . . . . . . . . 51

4.3 BACKEND TECHNOLOGIES . . . . . . . . . . . . 51

4.3.1 Solidity . . . . . . . . . . . . . . . . . . . . . 51

4.3.2 Python . . . . . . . . . . . . . . . . . . . . . . 52

4.3.3 Blockchain . . . . . . . . . . . . . . . . . . . . 52

4.3.4 Metamask . . . . . . . . . . . . . . . . . . . . 53

5 DESIGN, DEVELOPMENT AND IMPLEMENTA-

TION 57

5.1 DESIGN . . . . . . . . . . . . . . . . . . . . . . . . . 57

5.1.1 Connect With Metamask . . . . . . . . . . . . 57

5.1.2 Set Username For Yourself . . . . . . . . . . . 57

viii
 5.1.3 Successfully Logged In As Username . . . . . 58

5.1.4 Preview Of The Friend List . . . . . . . . . . 58

5.1.5 Add New Friends . . . . . . . . . . . . . . . . 59

5.1.6 Messages Between User And Friend . . . . . . 60

5.2 SYSTEM ARCHITECTURE . . . . . . . . . . . . . 61

5.2.1 Application Flow Diagram . . . . . . . . . . . 61

5.2.2 User Flow Diagram . . . . . . . . . . . . . . . 62

5.2.3 Backend Flow Diagram . . . . . . . . . . . . . 63

5.2.4 Encryption Diagram . . . . . . . . . . . . . . 64

5.2.5 Decryption Diagram . . . . . . . . . . . . . . 64

5.3 DEPLOYMENT . . . . . . . . . . . . . . . . . . . . 65

5.3.1 JSON File . . . . . . . . . . . . . . . . . . . . 67

5.3.2 The Smart Contract . . . . . . . . . . . . . . 68

5.3.3 Account Creation . . . . . . . . . . . . . . . . 69

5.3.4 Adding Friend . . . . . . . . . . . . . . . . . . 70

5.3.5 Messaging . . . . . . . . . . . . . . . . . . . . 71

5.3.6 Collection of User Data . . . . . . . . . . . . . 72

5.3.7 Functionalities . . . . . . . . . . . . . . . . . 73

5.3.8 The Testing Architecture . . . . . . . . . . . . 76

5.4 IMPLEMENTATION . . . . . . . . . . . . . . . . . . 77

5.4.1 Compile, Deploy And Build . . . . . . . . . . 77

6 CONCLUSION AND FUTURE WORK 87

ix
 6.1 CONCLUSION . . . . . . . . . . . . . . . . . . . . . 87

6.2 FUTURE WORK . . . . . . . . . . . . . . . . . . . . 88

References 90

x
 LIST OF ABBREVIATIONS

EVM : Ethereum Virtual Machine

ABI : Application Binary Interface

AES : Advanced Encryption Standard

xi
 LIST OF TABLES

3.1 Gas Fees/unit in ether . . . . . . . . . . . . . . . . . 30

xii
 LIST OF FIGURES

2.1 Literature Review (Comparison with different appli-

cation) . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.1 Centralized vs Decentralized . . . . . . . . . . . . . . 15

3.2 Hashing a Block victimization SHA-256 . . . . . . . . 20

3.3 Timestamp server . . . . . . . . . . . . . . . . . . . . 22

3.4 Ethereum Smart Contract Information . . . . . . . . 34

3.5 Interacting with Ethereum Network [19] . . . . . . . 37

3.6 System Architecture on Web Server [18] . . . . . . . 39

3.7 System Architecture on IPFS [18] . . . . . . . . . . . 43

3.8 Encryption Algorithm . . . . . . . . . . . . . . . . . 45

3.9 Decryption Algorithm . . . . . . . . . . . . . . . . . 46

4.1 MetaMask Extension on Chrome . . . . . . . . . . . 53

4.2 Create Custom RPC . . . . . . . . . . . . . . . . . . 54

4.3 Mumbai Testnet . . . . . . . . . . . . . . . . . . . . . 55

5.1 Connect to MetaMask . . . . . . . . . . . . . . . . . 57

5.2 Set username . . . . . . . . . . . . . . . . . . . . . . 58

5.3 Signed in Successfully . . . . . . . . . . . . . . . . . . 58

5.4 Friend List Section . . . . . . . . . . . . . . . . . . . 59

5.5 Adding a new Friend . . . . . . . . . . . . . . . . . . 60

xiii
5.6 Message Section . . . . . . . . . . . . . . . . . . . . . 61

5.7 Application Flow Diagram . . . . . . . . . . . . . . . 62

5.8 User Flow Diagram . . . . . . . . . . . . . . . . . . . 62

5.9 Backend Diagram . . . . . . . . . . . . . . . . . . . . 63

5.10 Encryption Diagram . . . . . . . . . . . . . . . . . . 64

5.11 Decryption Diagram . . . . . . . . . . . . . . . . . . 65

5.12 JSON Script . . . . . . . . . . . . . . . . . . . . . . . 67

5.13 Create App . . . . . . . . . . . . . . . . . . . . . . . 68

5.14 Check User Function . . . . . . . . . . . . . . . . . . 69

5.15 Create Account Function . . . . . . . . . . . . . . . . 69

5.16 Get User Function . . . . . . . . . . . . . . . . . . . 70

5.17 Function of CheckAlreadyFriend . . . . . . . . . . . . 70

5.18 Function of Adding Friend . . . . . . . . . . . . . . . 71

5.19 Function of Friend List . . . . . . . . . . . . . . . . . 71

5.20 Send Message Function . . . . . . . . . . . . . . . . . 72

5.21 Read Message Function . . . . . . . . . . . . . . . . . 72

5.22 User Already Exits Function . . . . . . . . . . . . . . 73

5.23 Solidity Compiler Architecture . . . . . . . . . . . . . 77

5.24 Solidity Function . . . . . . . . . . . . . . . . . . . . 77

5.25 Solidity Compiler on Remix . . . . . . . . . . . . . . 78

5.26 Remix IDE . . . . . . . . . . . . . . . . . . . . . . . 79

5.27 Building Process . . . . . . . . . . . . . . . . . . . . 81

xiv
5.28 MUMBAI TEST NETWORK FAUCET . . . . . . . 82

5.29 Mumbai Test Network on MetaMask . . . . . . . . . 84

5.30 Contract Development . . . . . . . . . . . . . . . . . 85

5.31 Signature Request from MetaMask . . . . . . . . . . 86

xv
 ABSTRACT

People are increasingly relying on texting and messaging to commu-

nicate rather than speaking in person. Individuals and groups with

different identities and goals must therefore have a secure and sim-

ple way to connect. However, there are growing privacy concerns,

such as hacks and data being sold on the internet, denial of service

to individuals, groups, or organisations as a form of censorship, or

data being mined for financial gain by advisors. Blockchain technol-

ogy, which originated with crypto-currencies, has been introduced

to provide users with access to a variety of applications without re-

lying on a third party. The implementation of messaging DApps

has the potential to benefit society and the way user information or

various services are handled. The primary motivation for creating

the HushMessnger project was to improve message privacy. Many

popular chat applications claim that they are end-to-end encrypted.

This claim, however, has not been verified. This thesis created a new

chatting application called HushMessnger. HushMessenger is 100%

open source and employs Military grade encryption. HushMessenger

does not require a centralised server because it runs on the Ethereum

blockchain and on thousands of nodes.

xvi
 CHAPTER 1

INTRODUCTION

1.1 APPLICATION OVERVIEW

HushMessenger is a military grade encrypted decentralized messen-

ger, which permits users to chat while not limitations on censorship

or privacy concerns. HushMessenger lets users connect on to a de-

sired contact without the third party interference of different mes-

sengers. Send and receive messages among the DApp and chat with

others directly with none centralized authority to own access to the

conversations. Hush Messenger is a decentralized chat application.

• Highly secured Military Grade Encryption

• Allow to secure your personal data

• Protect your privacy.

• Make your data safe and secure.

Hush Messenger is very reliable and easy to use.

1.2 BACKGROUND

Blockchain is one in all the foremost promising rising technologies.

on the far side cryptocurrency, it’ redefining however we have a ten-

1
 2

dency to store, update, and transfer information across networks.

Blockchain and sensible contracts are a very new thanks to write and

deploy applications. Blockchain has the potential and capability to

enhance on-line security and user’s trust. World info transmission

has become progressively accessible. Using the ability fromthe de-

fault, accord mechanism and voluntary respect of the accord that

it’s attainable to use the web to create a decentralized value-transfer

system, Provide accross the globe and just about liberal to use.

Ethereum may be a project, that makes an attempt to make the

generalized technology, a technology on which all interaction-based

state machine ideas could also be built. what is more it aims to sup-

ply to the end-developer a tightly integrated end-to-end system for

building code on a yet un- explored calculate paradigm within the

mainstream: a confiding object electronic communication compute

framework.

1.3 PROBLEM STATEMENT

Messaging Applications like Whatsapp, Wechat, IMO and many

more are using centralized network to store their data due to central-

ized approach they are server dependent which means if application

servers goes down or collapse you cannot access your data or maybe

you will lose your data. Also problems like Data Leaking and Data
 3

Altering may occur due to Level of Encryption which can be consid-

ered as Moderate Level. Data Leaking cause huge problem if data of

an organization is very important such as Military or Government

Authorities data. Some Problems that we are facing in our regular

messaging application

• Centralized Platforms Approach

• Low level encryption

• Server dependency

• e.g. server getting down or collapse

• Data Alteration

• Data Leaking

1.4 PROPOSED SOLUTION

To overcome the problem of centralization and data leaking, Plat-

forms are transferring from centralized to decentralized approach.

By getting inspiration from this, We decided to build up messaging

a platform that will be secure efficient enough with high level of se-

curity to be used by each and every user.

 4

1.5 AIMS AND OBJECTIVES

The general aim is to provide the information about our project

and share the information about Decentralization and a high level

security using Encryption Techniques with Blockchain Technology to

develop a secure enough messaging platform. The main Objectives

of our applications are

• Providing the use of Blockchain

• Providing security by using High Level Military Grade Encryp-

tion

• Providing Decentralized Approach

• Providing Full Secure and Safe Platform

1.6 ADVANTAGE

HushMessenger is a secure Real time end to end encryption using

blockchain technology to store data Secure from hacker or unknown

attacks. Also we use Peer to peer approach to make data decen-

tralized and decentralized server save data from temporary collapse.

Decentralized Server makes data nearly impossible to Hack or altered

by dividing data into different block as well as unable to manipulate

the whole data at same time.

 5

1.7 THESIS ORGANIZATION

1.7.1 Chapter 1: Introdcution

This chapter is dedicated to the preliminary introduction. It includes

the portion of Application Overview, Background, Problem State-

ment, Proposed Solution, Aims and Objective and Advantages.

1.7.2 Chapter 2: Literature Review

This chapter describes the comprehensive literature study to achiev-

ing the primary goals of the thesis. It includes the review of similar

related work and similar application.

1.7.3 CHAPTER 3: Blockchain Technology and Encryption

This chapter describes the BLOCKCHAIN TECHNOLOGY AND

ENCRYPTION followed by this thesis. This chapter shares the

information about the knowledge on Blockchain, Interaction with

Ethereum, Working of our Application, Smart Contract and En-

cryption.

1.7.4 CHAPTER 4: Tools and Technologies

This chapter provides the information about the section of tools and

technologies that are used to develop the application.

 6

1.7.5 CHAPTER 5: Design, Developments and Implementation

This chapter describes the phases of design and development of the

application. It covers the portion of Application UI/UX, Smart Con-

tract for the Application, Deployment on the smart Contract on

Main/Test Network and The Build Process

1.7.6 CHAPTER 6: Conclusion and Future work

This chapter comprises of the concluding remarks and future research

avenues on this project.

 CHAPTER 2

LITERATURE REVIEW

2.1 OVERVIEW

The ongoing chapter describes the general idea of the related work

and research paper on the similar application. It shows the compar-

ison of our application with different similar applications.

2.2 RELATED WORK

Over the last decade, WhatsApp, WeChat, etc, these ancient ap-

plications have taken everywhere the internet. there’s a centralized

server that stores all the knowledge together with identity to chats.

Generally, these chat applications supported the following:

• Centralized Management: during this management system, en-

tire correspondence goes through the company’s server which

may govern its rules. Messages will be blocked on an exact sub-

ject or restrictions can be applied on the certain files.

• Centralized Architecture: during this architecture, there is solely

single server which is maintaining all the services. it’s permit-

ting North American country to block access to an exact service

for the complete country whereas, the issues on the management

7
 8

servers might result in inadequacy of the service for all or a big

a part of North American countries.

• Confidentiality: Confidentiality of a user will be compromised

on the request of government.

• Single purpose of Failure (SPF): If one node fails then whole

application can be compromised.

The on top of inspired us to create an application where, we will

have all the options like: decentralised storage, Censorship resis-

tance, knowledge security and knowledge immutability.

In the Figure 2.1, we are comparing different features of our chat

application with others decentralized chat application that are cur-

rently available on the internet.

 9

Figure 2.1: Literature Review (Comparison with different application)

In the Figure 2.1, Hush Messenger is compared with different

decentralized chat application. Hush Messenger has some extra fea-

tures like Native Platform and Availability and also it provides the

highest level of security by using Military Grade Encryption. Few

 10

chat applications are discussed below.

2.2.1 TrueConf

TrueConf could be a self-hosted enterprise video conferencing and

team messaging solution. TrueConf works in closed networks with-

out a network connection, simply scaling the platform to your needs

and or designing your own unified communications network through

federation. TrueConf, in addition to team messaging, provides video

conferencing for up to 1,000 participants, company chat, integration

with meeting room systems, and much more. TrueConf is not open-

source because it operates on its own proprietary protocol, which

brings both pros and cons.

2.2.2 Matrix

Matrix is a free and open protocol for decentralised, real-time com-

munication. It’s used for texting, group chats, audio/video calls,

and larva creation. Matrix.org Foundation has been developed by

enthusiasts since 2014. The protocol specifications, as well as the

consumer-server half, are in the public domain, in contrast to Tele-

gram, which currently only keeps its client public, raising numerous

concerns about the security of using the MTProto protocol.

 11

2.2.3 Wickr

Wickr ME, like many popular electronic communication apps, uses

end-to-end coding to protect your conversations and calls. Wickr

Secure electronic commu-nication Protocol is used by the service.

Wickr ME also includes a self-delete timer for messages that ranges

from one mi-nute to six days. It is not possible to repeat or forward

messages to third parties within the traveller, nor can screenshots be

created. Another feature of Wickr ME is that registration requires

no personal information other than a username and password.

2.2.4 Signal

Signal, which was founded in 2013 and is closely held by a non-

commercial foun-dation of the same name, is open source. Personal

donations are used to fund the app’s development. Previously, this

application was used by people who had a strong desire for priva-cy,

such as activists, members of various countries’ opposition, politi-

cians, jour-nalists, and so on. The traveller uses end-to-end coding

(E2EE), which means that no one except the participants of the

speech has access to the information—the knowledge—the knowl-

edge - even the developers can’t browse your correspond-ence. Trav-

eller does not collect user data and does not display advertisements.
 12

2.2.5 Baariar

Briar could be a digital communication app created for journalists,

activists, and eve-ryone else looking for a secure, simple, and robust

way to communicate. Briar, contra-ry to conventional messaging

methods like email, Twitter, or Telegram, doesn’t depend on a single

server - messages are sent synchronously between users’ devices. If

the In-ternet goes down, Briar will connect via Bluetooth or Wi-Fi

to keep the information flowing in an emergency. Briar can sync via

the Tor network if the Internet is availa-ble, shielding users and their

relationships from surveillance.

2.2.6 Blackberry Messenger

With BBMe, you can get all of your messaging needs met in one

place, on your preferred device. It enables safe communication on

any device, including smartphones and desktop computers. With

end-to-end encryption on multiple endpoints, robust privacy policies,

and enterprise-grade features, BBMe is the ideal communications

platform for work-ing professionals.

2.2.7 Tox Chat

Tox began a few years ago, following Edward Snowden’s leaks about

NSA spying activity. The goal was to develop an instant messaging

application that did not re-ly on central servers. The system would
 13

be distributed, peer-to-peer, and end-to-end encrypted, without a

method to turn off any of the encryption features, while still being

user-friendly for people who have no practical knowledge of cryptog-

raphy or distributed systems. During the summer of 2013, a small

group of de-velopers from all over the world got together and started

working on a library that implemented the Tox protocol.

 CHAPTER 3

BLOCKCHAIN TECHNOLOGY AND ENCRYPTION

3.1 BLOCKCHAIN

Blockchain or distributed ledger technology, DLT, may be a new

technology to store and manage knowledge across the web and alter-

native computing networks. it had been created as a results of the

introduction of the Bitcoin cryptocurrency. Today, the applying of

blockchain and its potential way exceed its genesis in Bitcoin. It sup-

ports not simply digital cash and trusty data movement and storage,

however the exchange of value, a web of value. The word blockchain

reflects the logic of the mechanism. New transactions in an exceed-

ingly network are bundled into blocks, that are further to existing

blocks - forming a sequence with cryptanalytic signatures. These

signatures security link the blocks to every alternative . Since the

cryptanalytic signature depends on the chain of all previous blocks,

dynamical AN existing block within the chain would invalidate all

the subsequent blocks in the eyes of the remainder of the network. As

a result, once a replacement group action is planned no participant

would settle for transactions returning from a changed version of this

chain: this constitutes blockchains groundbreaking fraud-detection

14
 15

system. Blockchain is peer-to-peer network architecture. If one peer

breaks down, the information is accessible through other peers (Fig-

ure 3.1).

Figure 3.1: Centralized vs Decentralized

take time to process, price money, are liable to hacking, offer

restricted participation from those involved, require special skills

and may be error prone. Up yet we’ve usually been okay with

this. Blockchain is that the answer all the issues mentioned above.

Blockchain database is put in on each laptop that’s utilized by the

folks that use the database. we have a tendency to decision them

nodes. A copy of identical information is put in on every node. this

fashion the database is unfolded among many nodes. There aren’t

any database servers. once a group action happens within the dis-

tributed database. The transaction happens in one amongst the

nodes then the transaction is transmitted to each identical database

on the distributed network. All the nodes agree that this alteration

will be done and therefore the transaction is completed. All the dis-
 16

tributed databases recognize the principles and when a change can

be done. this is often equivalent of consensus-based permission since

all the nodes on the network need to agree on a amendment before

it will happen. Blockchain has chain of blocks, that have identi-

cal data on all of the informations. The blockchain database won’t

enable hacks because every block within the database depends on

the previous block. Blocks are solely further and ne’er get deleted.

each change in the database simply creates a replacement block

not take away or edit, the previous block. Since blockchain is an

immutable database, it’s referred to as characteristic immutability.

Blockchain keeps tracks of changes and since of that typically it is

called distributed ledger. In order for a hacker to with success hack

the blockchain information, it has to change the information on all

the nodes on the blockchain, which may be as high as thousands.

A hacker would want to faux all the process and power of the min-

ers to fraudulently add a block to the blockchain. this is often the

sole thanks to get the authority to vary the database. Blockchain

database is put in on each node. each single node must verify every

group action within the database. The system is secure as long as

honest nodes conjointly management a lot of mainframe power than

any cooperating cluster of offender nodes. The blockchain can not

only transfer and store money, but it can also replace all processes
 17

and business models that accept charging a small fee for a group

action or another transaction between two parties. Even newcomers

such as Uber and AirBnB are vulnerable to blockchain technology.

All that is required is to code the transactional data for a car ride or

a long stay, and you have a superbly secure approach that disrupts

the business model of companies that have only recently begun to

challenge the traditional economy. We don’t just appear to be elimi-

nating the fee-processing middleman; we also appear to be eliminat-

ing the requirement for the matchmaking platform. Some examples

of blockchain applications include good contracts, the sharing econ-

omy, crowd funding, governance, supply chain auditing, file storage,

prediction markets, intellectual property protection, the internet of

things, neighbourhood small grids, identity management, combating

cash laundering, recognising your customer, knowledge management,

land title registration, and stock mercantilism.

3.2 SMART CONTRACTS

A wise contract may be a code or an automatic method that han-

dles the group action in between 2 parties while not a 3rd party.

Contracts are pretty much like categories in object- orientating lan-

guages. Contracts could have state variables, functions, events, and

struct types. within the contract we have a tendency to may have

 18

modifiers. Once the good contract governing the organization is

deployed on the blockchain network, it become freelance of its de-

velopers and can’t be influenced by any outside entity. Its rules,

money, records and transactions are controlled and maintained by

the blockchain and so eliminate the requirement of a middleman.

3.3 TECHNICAL STRUCTURE

3.3.1 Cryptography

Cryptography may be a Greek word, and it means that secret writ-

ing. victimisation this method we are able to send messages in cryp-

tic way, and no-one are going to be able to edit it. This method is

termed encryption. The message will be decrypted at the ultimate

destination. Cryptography involves the utilization of code and pro-

tocols to ascertain secure communications.

3.3.2 Public And Private Keys

Public Key Infrastructure or PKI is one sort of cryptography. It

needs 2 keys, a public and a personal key. Public key’s visible to ev-

eryone. non-public key is solely visible by the licensed user. In order

to create a distributed, irreversible ledger of information, blockchain

technology is used. it’s qualities thought of extremely appropriate

purer the storage ANd management of public keys. Non-public key’s

a random mixture of numbers and letters a radical f. once a personal

 19

key is generated its try is additionally created that is that the public

key at identical time. making public key from private key is easy,

but the other is very difficult. It’s nearly not possible to work out

the private key from public key. once an email correspondence is

distributed out, it’s public key is sent out with it, and it is signed

with a private key. The recipient has the general public key. The

authentication of the message will be verified by checking that the

sender created the signature with the non-public key pair. The recip-

ient opens the message with the private key. Unlocking the message

while not the private key’s impossible.

3.3.3 Blocks

Blocks are files that for good record and hold transaction data.

Blocks are linear sequences. Miners perpetually method new blocks.

These blocks are additional to finish of the chain of the blockchain.

As more blocks are added to the blockchain, it gets more durable to

change, edit or take away the blocks that were added earlier and are

deeper within the chain. this is often however the dealingss become

irreversible. every block in blockchain contains ledgers and trans-

action knowledge. The block data is hashed by cryptological hash

functions.
 20

3.3.4 Blocks Structure

Blocks are files that for good record and hold transaction data.

Blocks are linear sequences. Miners perpetually method new blocks.

These blocks are additional to finish of the chain of the blockchain.

As more blocks are added to the blockchain, it gets more durable to

change, edit or take away the blocks that were added earlier and are

deeper within the chain. this is often however the dealingss become

irreversible. every block in blockchain contains ledgers and trans-

action knowledge. The block data is hashed by cryptological hash

functions. Describe in the Figure 3.2.

Figure 3.2: Hashing a Block victimization SHA-256

3.3.5 Forming A Sequence

A Genesis Block is the first block in a blockchain. When the gen-

esis block is validated, every subsequent block will be added to the

blockchain. Each block contains a reference to the previous hash. A

 21

hash pointer is similar to a pointer. The hash pointer contains the

address of the previous block and thus the hash of the information

contained in the previous block. The block chain contains the ledger

of all the systems.

3.3.6 Transaction

An old blockchain application, such as Bitcoin, includes transactions

that represent a cash exchange between two entities (or users). For

efficiency, every valid transaction is recorded during a block, which

may contain multiple transactions. Unchangeability can be achieved

by utilising strong cryptological properties such as hashing. A chain

of digital signatures makes up an electronic coin. Every owner trans-

fers the coin to the succeeding owner by digitally signing a hash of

the previous transactions and thus the succeeding owner’s public key

and adding these to the tip of the coin.

3.3.7 Timestamp Sequence

The hash of a block of things is time stamped by the Timestamp

server. The hash will be widely distributed. The timestamp could

be used to prove that the information existed at the time. Every

timestamp hash includes the previous timestamp. This can create

a chain. Figure 3.3 shows how the next timestamp reinforces those

before it.
 22

Figure 3.3: Timestamp server

3.3.8 Blockchain Agreement Protocol

So as for the blockchains to operate globally, a practical, economical

and secure consensus algorithmic rule is needed for a shared public

ledger. All blockchain-based applications use distributed consensus

algorithm. analysis on consensus mechanisms has planned an out-

sized vary of systems, from proof-of-work to proof-of-stake systems

to the hybrid systems in between.

3.3.9 Proof of Labor

The mining proof-of-work (PoW) exists as a cryptographically se-

cure proof that a specific amount of computation has been used up

in calculating the value of a given token. By giving the concept of

an issue meaning and credibility, it is utilised to ensure blockchain

security (and, by extension, total difficulty). However, because there

is a financial incentive for mining new blocks, proof-of-work doubles

as a system for distributing wealth in addition to assuring that the

blockchain will stay valid in the future. Proof of labor is accessi-

 23

ble to as several nodes as possible. there’s minimum would like for

specialised or uncommon hardware. The goal is to form the mining

from electricity at a similar rate for any node within the globe. a

symbol of work is employed to implement a distributed timestamp

server on a peer-to-peer basis. The proof-of-work involves scanning

for a worth that once hashed, comparable to with SHA-256, the hash

begins with variety of zero bits. the common work needed is expo-

nential in the number of zero bits required and might be verified by

corporal punishment one hash. The proof-of-work is established by

incrementing a present within the block. This method is sustained

until a worth that offers the hash of the block the specified zero bit.

A pc goes to unravel the mathematical problems. The process capa-

bility is applied so as to solve it. The more durable it gets to solve

the problem, the additional computing power, is consumed. Once

the proof-of-work is established, the block can not be modified while

not redoing the work. The act of mining and making a winning hash

with success can implement the proof of labor. It conjointly solves

the large downside of double spending. Mining Bitcoin takes con-

cerning ten minutes. this is often the time needed to unravel a given

hash and generate proof of work, no block are accepted as authentic,

till the mining is complete. The laborers give the proof of work by

finishing the maths problem and thus give permission for block to
 24

be additional to the blockchain. Miners vie to solve the issues for

every block dealings. The winning miner is supplied with a selected

quantity of coin and therefore the transaction fee. The protocol is

truthful within the sense that a laborer with p fraction of the entire

process power can win the reward and build a block with the chance

p. Associate in Nursing assaulter is needed to unravel a similar tasks

because the remainder of the network; i.e., an attack on the network

will solely achieve success if the attacker can wake up bear vital com-

putational resources . Proof of labor needs monumental quantity of

computational energy, which is able to create quantifiability issues.

conjointly most of the mining are often centralized in the areas with

low-cost electricity, which is why different different consensuses have

been developed since Bitcoin.

3.3.10 Proof of Stake

Proof of stake is that the most typical different to proof of work. The

validators (stakeholders) invest within the coins rather than finance

in process instrumentality and energy. All the coins of the system

exist on day one and no mining is required. the prospect of the val-

idators to be picked for next block depends on the fraction of the

coins they own in the system. The decentralised agreement mech-

anism has advanced security measures by eliminating the necessity

for a trusty third party in any interaction. Proof of stake algorithms

 25

are one practical decentralised ledger solution that does not rely on

expensive computations for security. The idea behind proof of stake

is straightforward: rather than mining power, a user’s ownership

stake within the system determines how likely they are to create a

block and get the related reward. A replacement block is made with

a probability of p by a personal neutral who owns p portion of the

total number of currencies in circulation. The network nodes with

the greatest number of stakes have the greatest incentive to main-

tain network security. If the network has successfully attacked the

worth of the cryptocurrency would drop thanks to the attacks. The

attackers ought to acquire most of the network (currency) so as to

implement a victorious attack. Doing so is incredibly overpriced and

discourages the attackers.

3.3.11 Proof of Capability

Proof of capacity is additionally called proof of space. The nodes

on the network prove that they need enough storage to unravel a

process problem. Proof of capacity algorithmic rule targets com-

putational issues comparable to hard-to-pebble graphs that require

great amount of memory storage to solve the problem.

 26

3.3.12 Network

During a network, the new transactions are broadcasted to any or

all the nodes. The new transactions are collected into a block by

the nodes. each node will work extremely laborious to unravel the

problem, so give the proof-of-work for its block. the primary node

that finds the proof-of-work will broadcast it to all the nodes. All the

opposite nodes will solely approve the new block provided that all the

transactions in it are valid, conjointly not already spent. Once the

nodes settle for the new block, it’ll be additional to the chain. The

longest chain is that the correct chain, and accepted by the nodes.

this is often the chain that other nodes can add blocks to it. There

are times that the 2 nodes broadcast succeeding block at a similar

time. because the result the blocks won’t be the same. a number of

the taking part nodes will receive one or another first. The nodes

will work on the primary block they received. the opposite branch

are saved just in case it becomes long. If one amongst the branches

become longer and longer, all the nodes will move to the longer

node, and abandon the shorter one. The tie are broken. The new

dealingss don’t essentially be broadcast to any or all modes. Block

broadcasts are happy with born messages. The node that did not

receive a block can request it once the succeeding block is received.

That is when the node realises it has misplaced it. When the most
 27

recent transaction in a coin is buried beneath enough blocks, the

spent transactions preceding it are frequently discarded to save disc

space. The Merkle tree used to hash transactions only has the root

enclosed within the block’s hash, to facilitate this while not breaking

the block’ hash. Previous blocks will then be compacted by stubbing

off tree branches. Inside hashes do not need to be compelled to be

saved.

3.3.13 Distributed Ledger

A distributed ledger is an plus database, and a variety of decen-

tralised database. an enormous network of taking part nodes hold

distributed ledger. These nodes have a full copy of the ledger. The

nodes are often virtual or real. The distributed ledger runs on the

blockchain technology. New transactions during a network are bun-

dled into blocks, that are additional to the existing blocks, so forming

a sequence with cryptological signatures. These signatures firmly

link the blocks to every other. Since the cryptographic signature

depends on the chain of all previous blocks, dynamic Associate in

Nursing existing block within the chain would invalidate all the sub-

sequent blocks in the eyes of the remainder of the network. As a

result, once a replacement dealings is planned no participant would

settle for transactions returning from a changed version of this chain:

this constitutes blockchains groundbreaking fraud-detection system.

 28

3.4 ETHERUEM BLOCKCHAIN NETWORK

Ethereum could be a blockchain that anyone will transfer and run

the process software. it’s an online service platform that may of-

fer a secured setting for computation. Ethereum is a programmable

blockchain and is a peer-to-peer network. It provides a group of help-

ful integral options for the developers. Ethereum is a decentralised

Heroku.

Ethereum features:

• User authentication, via seamless integration of scientific disci-

pline signatures

• Absolutely customizable payment logic with none reliance on

third parties

• Proof against distributed denial of service (ddos) resistant up-

time

• Unlimited storage

• Ultimate interoperability, everything within the Ethereum scheme

will trivially act with everything else, from name to custom cur-

rencies

• Server free zone, the entire application will be deployed on the

blockchain which means no would like for putting in or main-

 29

taining servers; users acquire the value of victimisation the ser-

vice.

3.4.1 Ethereum Philosphy

Simplicity is one in all the key style philosophies in the Ethereum

protocol. a median engineer ought to be ready to learn and pro-

gram in the Ethereum environment. alternative core philosophy is

generality and this suggests that Ethereum isn’t attending to have

features, it’ going to be a Alan Turing complete scripting language,

that anyone will use to develop anything, however it’ not attending

to have specific apps engineered into it, that’ up to the programmer.

in so far as possible, they’re going to build it in order that anyone can

use this to try and do anything, but they’re not going to specialize in

developing domain specific application. Ethereum is standard and

thus capable of victimisation completely different parts of Ethereum

network as necessary. the thought is that the Ethereum develop-

ment setting ought to invariably be maximized to develop the entire

ecosystem. Ethereum is meant to be agile thus as time evolves the

platform evolves as well. Ethereum contains a sturdy policy of non-

discrimination and non-censorship. Ethereum is receptive anyone.

 30

Table 3.1: Gas Fees/unit in ether

Unit Wei Value Wei

Wei 1 Wei 1
kwei (babbage) 1e3 wei 1000
Mwei (lovelace) 1e6 wei 1000000
Gwei (shannon) 1e9 wei 1000000000
microether (szabo) 1e12 wei 1000000000000
milliether (9FNNEY) 1e15 wei 1000000000000000
Ether 1e18 wei 1000000000000000000

3.4.2 Gas And Payment

One of the important thing variations among Ethereum and different

programming environments is that calling write operations price fu-

eloline, that’s Ethereum. All programmable computing in Ethereum

is subject to charges in order to prevent difficulties with commu-

nity abuse and to avoid the questions that will inevitably arise from

Turing completeness. The price schedule is laid out in gasoline de-

vices. As a result, any given fragment of programmable computation

(which includes developing contracts, making message calls, utilising

and having access to account storage, and executing operations on

the digital machine) has a universally agreed-upon price in terms of

gasoline. Gas is withinside the shape of ether, and it is typically

damaged right all the way down to the smallest decimal. In Table-

3.1 the denominations of unit in ether has been shown.

Typically, Ether used to purchase gasoline that isn’t reimbursed

 31

is sent to the beneficiary address, which is the address of an account

that is typically within the miner’s control. Transactors are free to

set any fuel price they choose, but miners are free to ignore any

transactions they don’t like. A better gasoline rate on a transaction

will cost the sender more in terms of Ether, provide a higher fee to

the miner, and as a result, be more likely to be chosen for inclusion

by more miners. Transactors are free to look at these expenses in de-

termining what fueloil rate to give, although miners typically choose

to list the lowest fueloil rate for which they can complete trans-

actions. Transactors will always have to choose between lowering

the fuel price and maximising the risk that their transaction will be

mined in a timely manner because there may be a (weighted) distri-

bution of the lowest appropriate fueloline costs.Computing charges

had been delivered to deter additives requiring excessive computing

power, along with clever contracts with limitless loops, which can be

a heavy burden for the community

3.4.3 Ethereum Virtual Machine

in contrast to Bitcoin that has one specific use, Ethereum could

be a programmable blockchain. Due to the peer-to-peer network

that Ethereum provides, transactions are secure and tested across

the network. The essential component of this strategy is the EVM,

or Ethereum Virtual Machine, which is where all the sensible con-

 32

tracts are carried out. EVM is completely cut off from CPUs and

file systems. It contains the consensus across the network because

every node in the system runs the Ethereum virtual machine. Appli-

cations that alter peer-to-peer direct interaction or provide coordi-

nated group action through a network are best suited for Ethereum.

Ethereum virtual machine executes the transactions. every node

within the chain runs EVM. EVM is that the app server that’ aim-

ing to handle process sensible contracts thus the—and also the pro-

gramming functionality. There are alternative services that may be

on the market through these nodes together with Swarm for hosting

files and Whisper for electronic communication and DApps. Each

Ethereum node runs the EVM, therefore information is synced and

agreement of the blockchain is maintained and because the result:

• Changeless

• No censorship

• Zero time period because of the amount of nodes concerned

• High fault tolerance

3.4.4 Ethereum Smart Contract

Smart Contracts are the strongest utility of Ethereum. Smart con-

tracts are categories during which functions are often referred to as

 33

on externally. information will be hold on within the blockchain.

Smart contracts are programs, which management the behavior of

accounts within the Ethereum state. once associate degree Ethereum

contract is compiled, it’s compiled into bytecode. The bytecode

is stored in the Ethereum network on the blockchain. Since the

blockchain is immutable, when it is additional to the blockchain no

more changes can be done to it. Whenever an address is formed and

also the sensible contract is compiled, by recompiling, it’ aiming to

then need to have a brand new address. each contract has it’s own

address. The initial plan for Ethereum was to try to write some

committal that allows the user to place money in a holding bin, and

this holding bin would require bound parameters to be met. Once

those conditions are met, the money may be released to someone

else or a variety of different people, or it may be returned to the

original sender. Smart contracts, on the other hand, have evolved

significantly. They’ve evolved to include any type of code that’s no

longer running on a blockchain node. This suggests that they are

behaving similarly to a traditional programming category or a po-

tential service. Thus, each Smart contract is essentially a collection

of functions and state variables that reside on the blockchain and

can also store data and move thereupon blockchain gap unlimited

possibilities.
 34

Figure 3.4: Ethereum Smart Contract Information

All participants are equal in their roles on the network. Blockchain

features a flat topology and every one participants are the same.

Blockchain doesn’t have hierarchy. Decentralization, transparency

and changelessness are the most 3 characteristics of blockchain. Blockchain

may be a new and innovative variety of information. it’s not like al-

ternative kind of databases that are put in on one central server. In-

dividual computers have the blockchain database installed on them.

Individual computers have the blockchain database installed on them.

The participants who used the database use these computers. Same

identical database is installed on individual computers who used the

database; which is why it is referred to as distributed database.

These participants are referred to as nodes. All the nodes should

agree whenever a replacement entry is made on the information and

accord must be reached. For example, if we use the image of pay-

ment, The blockchain participants will not let a transaction if a user

wants to pay another user but does not have enough money in their
 35

account. In addition, there are network participants known as min-

ers who contribute process power to the network in exchange for a

reward in order to solve mathematical issues. That is done to en-

sure that only valid new transactions can be processed. Blockchain

also enables new computing platforms such as Ethereum, Tezos, and

Rootstock. The opposite negative purpose of ancient information is

that the central authority. In several cases that’s specifically what’s

expected from a system; an e-commerce web site is an example of

that. Having this central power has the flaw of single point of fail-

ure. If the central authority is compromised, the database will be

compromised as well. In most cases, any organization that makes a

database has the proper to it database as a result of a central author-

ity holds the control. That organization is answerable of deciding

who has access and what variety of access they have, what’s keep in

them, what and once knowledge gets deleted, and what is backed and

archived. In most cases, folks stay the ultimate arbiter of the valid-

ity of transactions. we have a tendency to see this in contract work.

A contract between 2 entities completed over the web still needs

one or a lot of central authorities to validate data. For example,

with a mortgage, banks should validate savings and approve loans.

Title corporations must validate properties and legal professionals

should validate signatures and alternative written agreement need-

 36

ments. every one of those central authorities has distinctive power

that levies goodish overhead in an exceedingly mortgage transaction.

The transactions within the varied informations all Smart contracts

are one in all the key reasons that blockchain and distributed ledger

technology is advancing on the far side the utilization case of storing

price or handling monetary transactions.

3.4.5 Interacting With Etherum Network

Developers will create programmes that run on EVM. These pro-

grammes are written in Solidity, a brand-new JavaScript artificial

language. Solidity programmes are compiled to EVM bytecode.

The EVM serves as the runtime environment for these programmes.

These programmes are completely isolated and have no access to

the file system, network, or other processes running on the same

machine. The approach a web site talks to Ethereum blockchain

with web3 has shown. a web site talks to web3 with JASON-RPC.

JSON-RPC may be a remote procedure decision protocol encoded in

JSON. JSON-RPC is employed to form a special request to a node

on the network.
 37

Figure 3.5: Interacting with Ethereum Network [19]

3.5 CONNECTING FRONT END WITH SMART CONTRACT ON

ETHEREUM

We are going to connecting application front-end with Although

Ethereum is a decentralised network, smart contracts are necessary

for them to be able to invoke functions. Each specific node on the

Ethereum network maintains a copy of every state that is currently

in the Ethereum state machine, including all of the code and infor-

mation related to each smart contract. On a blockchain network,

we engage with one of these nodes whenever we work with data or

code. This is so that each node can send an instruction to the EVM

to complete a transaction. The transaction is carried out by a miner,

who then propagates the resulting state change to the rest of the net-

work.
 38

There are two ways to broadcast a new Transaction Request.

• By setting up the node that runs Ethereum software

• By using the nodes that are provided by third party services

such as Infura, Alchemy and Quicknode.

The next step is ”Providers”. Providers are the noders that are

connect with blockchain network( we can set up or use one from

third party service).

 39

Figure 3.6: System Architecture on Web Server [18]

 40

Every Ethereum client (as well as provider) complies to the JSON-

RPC specification. By doing this, it is made possible for frontend

applications to interface with the blockchain using a set of uniform

techniques. A stateless, compact remote procedure call (RPC) pro-

tocol called JSON-RPC defines a number of data formats as well as

the procedures for processing them. The principles can be utilised

within the same process, via sockets, over HTTP, or in a number of

message-passing settings because it is transport-agnostic. As a data

format, it employs JSON (RFC 4627).

You can read the state stored on the blockchain after connecting to

it via a provider. However, if you want to write to the state, there

is one more step you must take before submitting the transaction

to the blockchain: ”sign” the transaction with your private key. As-

sume we have a DApp that allows users to read or publish blog posts

to the blockchain. You could include a button on the frontend that

allows anyone to search for blog posts written by a specific user.

(Remember that reading from the blockchain does not necessitate a

user signing a transaction.)

However, if a user wants to publish a new post to the chain, our

DApp will ask the user to ”sign” the transaction with their private

key before relaying the transaction to the blockchain. Otherwise, the

transaction would be rejected by the nodes. Metamask is typically

 41

used to aid in the ”signing” of transactions.

Metamask is a tool that simplifies key management and transaction

signing for applications. Every time the frontend requires the user

to sign a transaction, Metamask is called. Metamask is a browser

extension that keeps a user’s private keys.

Because it needs the blockchain to sign transactions and already has

a link to the nodes offered by Infura, Metamask also offers a connec-

tion to the blockchain (as a ”provider”). Thus, Metamask serves as

both a signer and a supplier.

3.6 STORING DATA ON BLOCKCHAIN

Asking users to pay extra to utilise our DApp each time their trans-

action needs to add a new state is not the best user experience. We

use decentralised off-chain storage solutions like Swarm or IPFS be-

cause of this.

A distributed file system called IPFS is used to access and store data.

The IPFS system distributes and stores data through a peer-to-peer

network rather than in a centralised database. This makes finding it

when you need it straightforward. We are going with decentralised

storage solution, such as IPFS to host our frontend.

Astute readers may have also noticed that the frontend code is not

stored on the blockchain. We could host this code on AWS, as we

 42

would normally do in Web 2.0, but this creates a centralised choke-

point for your DApp. What if AWS fails? What if it censors your

application? As a result, To create a truly decentralised app, we

consider hosting our frontend on a decentralised storage solution,

such as IPFS.

So our application architecture now looks something like this:

 43

Figure 3.7: System Architecture on IPFS [18]

3.7 MILITARY GRADE ENCRYPTION

3.7.1 Encryption

Let’s start with the fundamentals. Encryption is essentially a method

of requiring information and scrambling it, resulting in gibberish.

 44

You will then be able to rewrite that encrypted data—but only if

you know how. The method of encrypting and decrypting is known

as a ”cypher,” and it is always dependent on a piece of data known

as a ”key.”

For example, if you visit an HTTPS-encrypted website and sign in

with an arcanum or provide a mastercard number, your personal

data is sent over the internet in an unorganised (encrypted) format.

Only your laptop and the website you’re interacting with will un-

derstand it, preventing others from snooping on your arcanum or

mastercard number.

After the initial connection, your browser and the website perform

a ”handshake” and exchange secrets used for data encryption and

decryption.

There are numerous encryption algorithms to choose from. Some are

more resistant to cracking than others.

3.7.2 What Exactly Is Military Grade Encryption?

Military-grade encryption is AES (Advanced Encryption Standard)

with 256-bit keys. In 2001, the National Institute of Standards and

Technology (NIST), a branch of the US Department of Commerce,

designated AES to be the new benchmark for data security.

Military-grade encryption typically uses keys that are at least 128

bits in size. According to the US, top secret (classified) information

 45

is encrypted using AES-256, whereas secret (unclassified) material is

encrypted using AES-128. Anyone who isn’t highly tech-savvy won’t

understand these letters and figures. Protection companies started

looking for a name that described the highest level of security with

the least amount of verbiage in order to popularise encoding. The

name ”military-grade” felt fitting because AES is used by the US to

encrypt classified data and by the US intelligence agency to safeguard

national security material.

3.7.3 Installation Of Military Grade Encryption

We are going to use military grade encryption in our application.

First we need to install it using npm

npm install –save react-native-aes-crypto

After installing dependencies, We use Encryption method to encrypt

the message such that when a user send a message it will be en-

crypted in AES 256 encryption.

Figure 3.8: Encryption Algorithm

 46

When a messege is recieved in encrypted form the AESDecrypt

method will work to decrypt the message in normal sentence and

user received the message in normal state.

Figure 3.9: Decryption Algorithm

3.7.4 What Exactly Is The Advance Encryption Standard (AES)?

The cruciform block cypher algorithm used in AES encryption, some-

times referred to as the Rijndael algorithm, has a block/chunk size of

128 bits. These distinct blocks are converted utilising 128, 192, and

256 bit keys. It then connects these blocks to create the ciphertext

after encrypting them.

It supports an SP network, also referred to as a substitution-permutation

network. It consists of a number of connected bit-shuffle operations,

such as the substitution of inputs with predetermined outputs (per-

mutations).

Throughout this tutorial, you will be exposed to several of the stand-

 47

out options that AES provides as a globally standardised encryption

formula.
 CHAPTER 4

TOOLS AND TECHNOLOGIES

4.1 TOOLS

4.1.1 Visual Studio Code

Visual Studio Code is a code editor, to put it simply. The free edi-

tor Visual Studio Code ”assists programmers in writing, debugging,

and correcting code using the intelli-sense method.” It simplifies the

process of users writing code, to put it simply. The choice is en-

tirely up to the coders, despite the common misconception that it

functions as both an IDE and an editor. Any programme or piece of

software that we see or use is built using background code. Coding

was previously done in conventional editors or even straightforward

editors like notepad. Coders used to receive fundamental support

from these editors. It was really challenging to write simple English

level programmes in some of them since they were so simplistic. Over

time, certain programming languages called for a certain framework

and support for more coding and development, which these editors

did not offer. VI Editor, commonly referred to as Sublime Text Ed-

itor, is one of the various kinds of editors that have arisen. The

most widely used, which supports almost all coding languages, is

48
 49

VISUAL STUDIO CODE. With its features, users can tailor the ed-

itor to their specific requirements. For example, they can download

libraries from the internet and add them to the code as necessary.

4.2 FRONT END TECHNOLOGIES

4.2.1 React Native

React Native is a JavaScript framework for building genuine mobile

content as well as native iOS and Android apps. It is based on React,

a JavaScript user interface creation library developed by Facebook,

although it targets mobile platforms as opposed to browsers. In other

words, by utilising the well-known and adored JavaScript library,

web developers can now produce mobile apps that really ”native”

in appearance and functionality. React Native makes it simple to

simultaneously create for both Android and iOS platforms.

4.2.2 React

React is a popular JavaScript library for creating user interfaces

that is essential for many front-end and full-stack developers. React

generates reusable components that display data that changes over

time. React makes it simple to build interactive user interfaces.

When the data changes, it will efficiently update and render the

correct components.
 50

4.2.3 JavaScript

JavaScript is a simple, interpreted programming language. The cre-

ation of network-centric applications is its intended use.

It cooperates with Java and completes it. JavaScript is extremely

easy to use because it is already included in HTML. It is cross-

platform and available for free.

4.2.4 Web3

The Web3 class is a container for all Ethereum-related modules.

Web3 is a JavaScript library that allows the frontend application to

interact with DApps and communicate with the blockchain. Web3 is

an open-source project that defines the protocol used by client-side

applications to interact with the Ethereum network. Finding a way

to effectively connect the front-end application to the blockchain is

one of the challenges in client-side development of decentralised ap-

plications. web3 is assisting us with this task.

Web3.eth is an important package that allows users to interact

with the blockchain directly. Web3.eth gives the user the tools they

need to access a specific block’s Coinbase, view transactions, view

different accounts and check their balances, and much more. Web3

is employed for:
 51

• Perform transactions

• Manage user accounts

• Smart contract interaction

To integrate web3.js into the project

4.2.5 Application Binary Interface

ABI is a JSON encoding of a smart contract. A copy of the ABI

is available on the Etherscan website. The web3-eth-abi package

allows decoding and encoding of parameters from an application’s

binary interface used to invoke functions of an implemented smart

contract.

4.3 BACKEND TECHNOLOGIES

In this section, we have presented our system in the form of diagrams.

The data flow diagram we have presented and discussed.

4.3.1 Solidity

Smart contracts can be implemented using the high-level object-

oriented language Solidity. Programs known as smart contracts con-

trol how accounts behave within the Ethereum state. A crucial lan-

guage for the Ethereum Virtual Machine is called Solidity (EVM). It

is influenced by JavaScript, Python, and C++. For additional infor-

 52

mation on the languages that influenced Solidity, see the Language

Influences section..

4.3.2 Python

Python is a well-known and widely used high-level, general-purpose,

object-oriented, interactive programming language. Python source

code, like Perl, is available under the GNU General Public License

(GPL). Python supports a wide range of programming paradigms,

including procedural, object-oriented, and functional languages.

Python’s design philosophy prioritises code readability through the

use of clear indentation. This tutorial covers all aspects of the

Python programming language, from the fundamentals to advanced

concepts. While learning the Python programming language, this

tutorial will walk you through simple and practical approaches.

4.3.3 Blockchain

A distributed database or ledger known as a blockchain is shared by

computer network nodes. Similar to a database, a blockchain also

saves data electronically in digital form. In cryptocurrency systems

like Bitcoin, where they keep a secure and decentralised record of

transactions, blockchains are well known for their crucial role. The

originality of blockchain is that it fosters confidence without the

necessity for a reliable third party by guaranteeing the fidelity and

 53

security of a record.

A regular database and a blockchain have significantly different data

structures. In a blockchain, data is gathered in units called blocks,

each of which contains a set of data. Blocks have predetermined

amounts of storage and close when they are full. a data chain known

as a blockchain is created by connecting each finished block to the

one before it. After this new block is added, any additional data is

compiled into a new block and added to the chain.

4.3.4 Metamask

The next dependency is the Metamask extension for Google Chrome.

Metamask is used to connect to the blockchain. MetaMask is used

to verify the owner of a blockchain address that can send and receive

messages. Metamask is used to connect the personal account to the

local Ethereum blockchain and interact with the smart contract.

Figure 4.1: MetaMask Extension on Chrome

Allows the user to have a browser integrated wallet so Ethereum

can be sent and signed anytime Ethereum needs to be sent to the

network. It is possible to test the applications without having to log

on locally, but once the developer is running in the test environment,

 54

the contracts have to be signed. Brave Browser is an alternative to

Chrome that has Metamask integrated.

• Setting Up Mumbai Test Network on MetaMask

Log in to MetaMask -¿ Click the Network drop down -¿ Select

Custom RPC

Figure 4.2: Create Custom RPC

1. Mumbai Testnet Settings:

• Network Name: Mumbai Test Net

• New RPC URL https://rpc-mumbai.maticvigil.com/

 55

• ChainID: 80001

• Symbol: MATIC

Figure 4.3: Mumbai Testnet

• Mumbai/Rinkeby Test Network

The Mumbai polygon network’s testnet is called testnet. that

replicates the main polygon network. It allows developers to de-

ploy, test and run their dApps risk-free and free on the blockchain

environment. Mumbai employs the Proof-of-Stake (PoS) con-

sensus technique to decide on the state of the blockchain, just

like Polygon, which debuted in 2017. May 20, 2022 over 2 bil-

lion total accounts have been created in Mumbai, with over 26

million blocks containing over 85 million transactions. Specif-

ically, for token transfers, Mumbai has more than 52 million

 56

ERC20 transfer transactions (the standard Ethereum-based to-

ken), more than 21 million ERC721 transfer transactions (com-

monly known as NFT), and more than 8 million ERC1155 trans-

fers (multi-token ) listed , which may or may not be tenable)

transfer transactions.

As more platforms and dApps are actively developed and tested

on its testnet, this reflects the Polygon network’s growing promi-

nence in the blockchain ecosystem. Not to mention that the

Polygon mainnet saw over 1.6 billion transactions. Per se!

Mumbai offers incredibly high yields and extremely low trans-

action fees while utilising the security of Ethereum while pre-

serving the features of Polygon. Because testing is greatly ac-

celerated, this makes Mumbai (and development at Polygon in

general) very enticing to developers

 CHAPTER 5

DESIGN, DEVELOPMENT AND IMPLEMENTATION

5.1 DESIGN

In this chapter, we discuss the implementation of our project and

how we have implemented our idea to show every implemented func-

tionality.

5.1.1 Connect With Metamask

In the first step, user need to connect with the metamask by clicking

on the Connect to MetaMask Button.

Figure 5.1: Connect to MetaMask

5.1.2 Set Username For Yourself

During connecting with metamask a new user is asked to set a user-

name for itself. After adding username, MetaMask authorize the the

user to use the application.

57
 58

Figure 5.2: Set username

5.1.3 Successfully Logged In As Username

After succesfully signed in, Connection button is replaced with the

username of User.

Figure 5.3: Signed in Successfully

5.1.4 Preview Of The Friend List

In the Chat section, user can see the added friend when user click

on a freind name the message section will apear for the particular

friend. Also we can add new friend by using +NewChat Button.

 59

Figure 5.4: Friend List Section

5.1.5 Add New Friends

When you are addding a new friend using +NewChat Button, you

need to enter the name for your friend and also you have to paste

the public key of the friend obtain from metamask application in

friend’s device.
 60

Figure 5.5: Adding a new Friend

5.1.6 Messages Between User And Friend

Here we can see the chat between user and friend. It will apear when

we select the particular friend to start the chat. Also the Refresh

button helps to refresh the chat section if a delay occur.

 61

Figure 5.6: Message Section

5.2 SYSTEM ARCHITECTURE

System Architecture of the Application shows the flow, structure

and behavior of the application. It shows the formal representation

of the application.

5.2.1 Application Flow Diagram

Application Flow Diagram describes the overall flow of the applica-

tion from starting to ending.

 62

Figure 5.7: Application Flow Diagram

5.2.2 User Flow Diagram

User Flow Diagram describes the user journey within the application.

How user interact with the application. It allow user to understand

the connection between each attributes.

Figure 5.8: User Flow Diagram

 63

5.2.3 Backend Flow Diagram

Backend Flow Diagram shows the flow of the data in the backend.

It describes the flow mechanism of message data from within the

ethereum virtual machine. It shows how message flows in the back-

end when a user sends a message by interacting with frontend.

Figure 5.9: Backend Diagram

 64

5.2.4 Encryption Diagram

It shows the decryption process of the message. When a message it

will be encrypted and if double encryption is on it will be encrypted

again, vice versa

Figure 5.10: Encryption Diagram

5.2.5 Decryption Diagram

It shows the encryption process of the message. When a message is

received, it will be decrypted and if the message is double encrypted

on it will be decrypted again.

 65

Figure 5.11: Decryption Diagram

5.3 DEPLOYMENT

The HushMessenger was developed based on the dependencies from

the next chapter. The HushMessenger has a smart contract and a

web interface. The smart contract provides access to the blockchain.

The smart contract is where the data is stored. Encrypted messages

are sent from one address to another.

Only the sender and recipient of the message can decrypt the mes-

sage, but encrypted messages remain on the Ethereum blockchain

forever. HushMessenger does not require a central server and only

relies on the Ethereum network. To contact other people, the user

shares his public key with other users while keeping his private key
 66

secret. Messages are encrypted with an encryption key that is also

used to decrypt the message.

Only the sender and recipient can generate the same encryption key.

The sender generates the key from the sender’s private key and the

recipient’s public key. The receiver calculates the key from your pri-

vate key and the sender’s public key. The contract generates events

that are stored on the network.

Does not save messages or contacts. All encryption and decryption

is done through the web appli-cation and not through the contract.

Messages and friends list are added based on the history of events

generated by the contract. The HushMessenger members and the

relationship between the members are the only information stored

in the contract store.

The basic structures of HushMessenger are

• Join by signing private key (transaction fee)

• Accept friend requests (transaction fee)

• Add friends with your public key (transaction fee)

• Send messages to and receive messages from friends (transaction

fee)

• Receive messages from friends (free)

 67

5.3.1 JSON File

All project dependencies are specified in the package.json file. A

package.json file is a manifest that contains information about the

application. It easily distributes the App code without having to

worry about distributing all dependencies. npm also offers us a way

to automate the running, testing and debugging of our applications,

or really run any Unix or DOS command. The Scripts property

is part of the package.json. ”npm start” is used to start the web

application. The scripts create dummy data on the blockchain to

manually test the application.

Figure 5.12: JSON Script

With the addition of these scripts, the file system is now the main

API. Each .js file is converted into a route that is automatically pro-

cessed and rendered, causing the server to render and index ./pages.

React creates components and uses the React library. React-Dom

takes these components and places them in the dom to render them

on the page. Package.json keeps track of all dependen-cies. The save

flag adds the dependency to the package.

 68

$ npm install react –save

Figure 5.13: Create App

json. The dependencies used for HushMessenger are: sol, web3,

react, react-native, react-dom, create-react-app, ethereumjs-tx, ethereumjs-

wallet, metamask, test network.

5.3.2 The Smart Contract

Communication between contracts requires more energy than calling

methods within a single con-tract. Also, each contract implemented

separately in the system increases the overall attack surface. When

contracts are created, only that final contract needs to be imple-

mented on the blockchain. Its bytecode contains the entire inheri-

tance chain, structures, state variables, methods, and assign-ments.

Power contracts support multiple inheritance. Address: is the ad-

dress in the Ethereum network. There is an address for the sender

and an address for the recipient. The message is a special object

that is contained in the called message and the message contains

some data including the sender which is the address of the person
 69

sending the money and also the value which is the value of what is

sent. The message.

The sender variable is always present when executing a contract’s

public methods (including the constructor) and could represent the

wallet address or the address of another smart contract.

5.3.3 Account Creation

par We will define 3 functions:

• The checkUserExists(pubkey) function is used to check whether

a user is regis-tered in our application or not. It helps ensure

that duplicate users are not created and is also called by other

functions to verify their existence.

Figure 5.14: Check User Function

• The create Account(username) function registers a new user on

the platform with the specified username.

Figure 5.15: Create Account Function

 70

• The getUsername(pubkey) function returns the username of the

specified user, if any.

Figure 5.16: Get User Function

5.3.4 Adding Friend

Again, we define 3 functions:

• The checkAlreadyFriends(pubkey1, pubkey2) function checks

whether two users are already friends with each other or not.

.This is necessary to prevent duplicate channels between the

same parties and is also used to prevent a user from sending

messages to other users unless they are friends.

Figure 5.17: Function of CheckAlreadyFriend

• The addFriend(pubkey, name) function marks the two users as

 71

friends if they are both registered on the platform and are no

longer friends.

Figure 5.18: Function of Adding Friend

• The getMyFriendList() function returns an array of friends for

the specified user.

Figure 5.19: Function of Friend List

5.3.5 Messaging

The final part of the Solidity contract will allow for the exchange

of messages between us-ers. We split the task into two functions

sendMessage() and readMessage().

• The sendMessage() function allows a user to send messages to

another registered user (friend). This is done with checkUserEx-

 72

ists(pubkey) and checkAlready-Friends(pubkey1, pubkey2).

Figure 5.20: Send Message Function

• The readMessage() function returns the previous chat history

between the two us-ers.

Figure 5.21: Read Message Function

5.3.6 Collection of User Data

We have three custom data types:

• user will have the property name that will store the username

and the friends list which is an array of other users.

• The friend has the properties public key, which is the friends

public address, and the name the user wants to refer to them

by.

• the name the user wants to refer to them by. The message has
 73

three properties: sender, timestamp, and msg, which is short

for ”message”.

Figure 5.22: User Already Exits Function

Why would keep 2 collections in our database:

• User List, where all platform users are associated with their

public address

• allMessages stores the messages. Since Solidity doesn’t allow

custom keys in a mapping, we can encrypt the two users’ public

keys instead. This value can be saved in the mapping.

5.3.7 Functionalities

Sending Transaction:

Method eth sendTransaction, creates a new message call transaction

or creates a contract if the data field contains the code.

The parameters are:

Object:
 74

The object of the transaction to data, 20 bytes - (optional when

creating a new contract) The address to which the transaction is

directed. The To field in ChatApp is the contract address. There

is no from, because when the transaction is signed with the private

key, it is clear who is sending you

Gas:

Quantity - (optional, default: 90000) Integer of the gas provided to

execute the transaction. It will return the unused gas.

GasPrice:

Quantity - (optional, default: to be determined) Integer of the gasPrice

used for each gas paid for. It’s the reward sent to the miner and it’s

the cost of each unit of gas when we send the transaction. Gas has

to be paid for every time Ethereum is built on the blockchain.

GasLimit:

is a guarantee of the maximum allowed money to send.

Value:

Amount - (optional) integer of value sent with this transaction.For

ChatApp, this value is zero because Ether is not transmitted to data:

Data:

the compiled code of a contract or the hash of the called method’s

signature and encoded parameters. We send once data representing

the smart contract bytecode:

 75

Amount(optional)

integer of a nonce. Nonce is the transaction count of the account.It

must be hexadecimal.

It is a security measure that avoids the double-spending problem.

For a new account, the nonce value is zero.

Returns:

Data, 32 bytes: The hash of the transaction, or the null hash if the

transaction is not yet available.

Method eth estimateGas method generates and returns an estimate

of the amount of gas needed for the transaction to complete.

The transaction is not added to the blockchain. Note that the es-

timate may be significantly higher than the actual amount of gas

consumed by the transaction for various reasons including EVM me-

chanics and node performance. This method returns the amount

of gas consumed. Updating the balance of the logged-in account is

done through the getbalance property of web3: Ethereum web3.

The eth package allows the application to interact with an Ethereum

blockchain and implement smart contracts. The web3.eth.Contract

creates a web3 contract object that represents the Ethereum smart

contract. The last updated block number is reached by ”web3.

eth.getBlockNumber()”.

Transaction counting is done by:

 76

The ”web3.eth.sendSignedTransaction sends an already signed trans-

action. ”web3.eth.getGasPrice” returns the current gas price oracle.

The gas price is determined by the average gas price of the last

blocks. GasPrice is the Wei per gas unit.

5.3.8 The Testing Architecture

The Testing Architecture It is very important to test the smart con-

tract before deploying it on the network as the blockchain is im-

mutable and transactions on the blockchain also cost gas. The only

way to fix a bug is to implement a new version of the contract; the

old version always remains on the blockchain. Testing the smart con-

tract before deploying it will help ensure features behave as expected.

When compiling the contract, we get the ABI and the bytecode as

output.

We provide the bytecode on the local testnet. The test calls various

functions within the contract. We generate a local network solely

to implement and test the smart contract. This includes a custom

script.

On the device, creates the local area network. The JavaScript inter-

face (ABI) is fed to web3. A number of tests have been written to

ensure that the application works as expected. without errors before

deploying it to the mainnet.

 77

5.4 IMPLEMENTATION

5.4.1 Compile, Deploy And Build

5.4.1.1 Solidity Compiler

The Solidity compiler compiles the smart contract into bytecode and

ABI. The build and deployment structure is shown in Figure 5.23.

The Solidity compiler was installed as part of the npm package.

requires our HushMessenger.

Figure 5.23: Solidity Compiler Architecture

sol is because Node tries to run files as JavaScript and fails on a

.sol file. The compile.js file looks in the contracts folder and compiles

the Solidity files. The contents of the file are read from disk.

Figure 5.24: Solidity Function

 78

Figure 5.25: Solidity Compiler on Remix

Therefore we use two separate built-in modules. The path module

 79

creates a directory path from the currently compiled js file to the con-

tract file. Cross-platform compatibility is ensured by using the route

module. generates a route that points directly to the Database.sol

file.

To read the raw source of the contract, let’s create the constant

source. Now we can write the compiled statement, this is where the

solc comes in.

5.4.1.2 Deploy using Remix

Figure 5.26: Remix IDE

In the Remix file explorer, create a Database.sol file and write the

database code. To compile the database, go to the Solidity Compiler

tab in the left navigation bar and click the blue button. contract for

the sol Make a note of the ABI because it will be required in the

following section. Go to the Deploy tab and select ”ENVIRON-

 80

MENT.” Select ”Web3 injected” and click the Deploy button (make

sure Metamask is loaded).

In the metamask popup interface, approve the transaction. Make

a note of the contract address once our contract has been success-

fully implemented. % style=”info” % hint An Application Binary

Interface (ABI) is a JSON object that contains metadata about the

methods of a contract, such as: B. The data type of the input pa-

rameters, the return data type and the property of the method, such

as B. payable, view, pure etc.

5.4.1.3 The Build Process

To build the application for production, use the npm run build com-

mand. A build folder is created containing the deployable build and

only this folder needs to be deployed. The URL from the address

is compiled and placed in the package.json file. Properly integrate

React into production mode and optimally optimize the build Per-

formance. The compilation is minimized and the filenames contain

the hashes. Running this command allows HushMessenger to be de-

ployed. The best approach is to compile once and write the result

to a file in the build folder that can be read later. The compiled

script runs once and then runs the application as many times as you

like, without waiting for Solidity to recompile. If we run the com-

piler again, it means that the smart contract has changed. In this
 81

case, the entire build folder should be deleted if it exists. reads the

content of the smart contract (.sol).

Next, compile the contract using the Solidity compiler. The output

is written to the build directory as a JSON file. The API can be

read from the build directory without having to recompile the con-

tract. The output variable contains the object that is the output of

compiling the HushMessenger contract. The build folder needs to be

recreated as it has been deleted.

Figure 5.27: Building Process

The build folder and the JSON file it contains will be generated

after the build.

5.4.1.4 Smart Contract Deployment To Main/Test Network

Gas is required to write procedures on the Ethereum network. The

Rinkeby testnet was used in this project. The Ethereum Rinkeby

faucet delivers free gas to the specified address. The web3 library

is the only means to interact with the Ethereum network. It is the

portal to everything related to Ethereum.The constructor function

 82

allows us to interact with existing contracts on the blockchain or

to create and implement new contracts. The first argument for the

contract creator is the ABI. Here we get a conversion between the

world of JavaScript and the world of Solidity. The interface property

is passed to JSON.parse.

Figure 5.28: MUMBAI TEST NETWORK FAUCET

The Solidity compiler provides the interface in JSON. A JavaScript

object needs to be provided to the contract and here it is fixed. It

 83

tells web3 that a contract exists and gives it the expected interface.

There is no deployment or creation information.

The implementation of the contract is asynchronous, so await is used.

Deploy tells web3 that there is a contract that needs to be deployed

to the network. It creates a transaction object and has the data

property. The bytecode is specified in data. The send function takes

the contract and displays it on the network.

Invoking deployment creates an object that can then be deployed to

the network. The send method triggers web3 to communicate with

the network. It is taken from the property whose value is the ac-

count used to create the contract. The process of migrating to a local

development network or the Mumbai test network or even the main

network is similar. The Ethereum Virtual Machine does not compile;

is simply parses the bytecode. There are some differences between

deploying on a local network on the main/test network. Accounts

are unlocked and have free ether. Deployment on the main/test net-

work account with ether is required.

This is how web3 communicates with a specific network. The provider

tells web3 which network it needs to communicate with. For the im-

plementation, the provider needs an account that is used as a source

for Ether. ) is used to unlock the account and use the ether in it

to implement the contract. The account mnemonic is passed to the

 84

account being created.

Figure 5.29: Mumbai Test Network on MetaMask

For core network deployment, the developer must do the config-

uration. Deploying on the Mumbai Test network requires a node

that we can connect to. The solution is to run a local node on our

machine.

It would be a real Ethereum node that can connect to the network

and then we can use this node running on our computer to connect

to the Ethereum network.

 85

5.4.1.5 Connecting And Integrating With Blockchain

The web3.eth.Contract object facilitates interaction with the smart

contract on the Ethereum blockchain. When a new contract object is

created, the respective smart contract’s JSON interface is provided

and web3 automatically converts all calls to low-level ABI calls over

RPC for the developer.

This allows the developer to interact with the smart contract as if

they were JavaScript objects.

Figure 5.30: Contract Development

5.4.1.6 Application of MetaMask

Since interaction with MetaMask is used in this project, MetaMask

will inject its own web3, hence web3 is define. This way, when Meta-

Mask runs, the Web3 version of MetaMask will be used. Web3 will

allow the contract to interact directly with the Ethereum blockchain.

 86

Figure 5.31: Signature Request from MetaMask

 CHAPTER 6

CONCLUSION AND FUTURE WORK

6.1 CONCLUSION

Blockchain has shown its potential to transform traditional indus-

try. By removing the centralized approach, we can also ensure data

security and availability and communication. Decentralized appli-

cations tend to make interactions between two people more efficient

and easier. The chat process nowadays has a Switch node, while

our software does not have a switch device/node i. each person is

connected through a peer-to-peer network.

This project is to analyze the inefficiencies of traditional central

based messaging applications and fix them by using Ethereum Smart

Contracts in a trusted and secure decentralized application. This

was achieved by developing a decentralized application that can be

run by any user and also to send and receive encrypted messages.

Centralized Platform cause many problems and because of this issue

many application decided to transfer to decentralized platform. Not

only messaging application but blockchain provides security for all

the systems that are present on blockchain.

With the help of Blockchain Technology our application is secure

87
 88

and with the help of Military grade encryption the level of security

becomes high level. Also it provides availability to the user. Cen-

tralized network manage on a single server if any problem occur in

the server application will become unavailable for the user while de-

centralized application are present on different nodes which means

if one is down application is still available for user.

Now the world is transferring from centralized to decentralize just

because of security. Everyone wants to keep their data private and

the blockchain fulfill that need it restrict the third party to access

your data. People are connecting peer to peer with each other. Our

HushMessnger also restrict any third party to access your data only

receiver has the permission to access the data.

6.2 FUTURE WORK

We can improve our application in future by adding features like

image and video sharing, custom chat groups, and exploring a new

blockchain technology called Whisper for sending messages are some

of the future directions. Whisper technology allows you to make

your messaging application more social for user.

Currently, we are using one of the best encryption techniques in the

world but we will try to make our application more secure for the
 89

user by adding more salting techniques. Also our application design

and UI better is very simple, we will try to make a better UI design

for our application to attract more users.

 REFERENCES

[1] Sourabh, D. Rawat, K. Kapkoti, S. Aggarwal, A. Khanna. Present

on IRJET. ”bChat: A Decentralized Chat Application”.May

2020

[2] C.A. Rabano, D.C. Baz,I.G. Pitna, C. Crepso. ”DeChat - De-

centralized Chat Es - 6A - II”. Jan 2017

[3] A. Gamoneda, P. Fernández, N.San Emeterio, J. Garcı́a. ”deChat

- Decentralized Chat 0”. May 2019

[4] A.P. Takale, C V. Vaidya, S S. Kolekar. ”Decentralized Chat

Application using Blockchain Technology”. 2018 IJREAM

[5] C.A. Rabano, D.C. Baz,I.G. Pitna, C. Crepso. ”deChat - De-

centralized Chat 6b”. Jan 2017

[6] Morlis.io Blog .”Build a Decentralized Messaging App in 5 Steps”

. Dec 2021

[7] V. Bhardwaj, R. Ram Sharma, A. Kumar. ”Chat Application

using Blockchain Technology”. Apr 2021 : International Jour-

nal of Science Technology and Management

[8] Maistrenko, Yuliia. ”The establishment of effective communi-

cations in personnel management in the age of digitalization.”

90
 91

(2021).

[9] Heiler, Q., von Seck, R. and Jelten, J., 2019. Peer-to-Peer Ma-

trix. Network, 39.

[10] Kim, G., Kim, S., Park, M., Park, Y., Lee, I. and Kim, J., 2021.

Forensic analysis of instant messaging apps: Decrypting Wickr

and private text messaging data. Forensic Science International:

Digital Investigation, 37, p.301138.

[11] Boschini, C., The Secure Messaging App Conundrum: Signal

vs. Telegram.

[12] Ballinger, C., ChatSecure. https://chatsecure.org/blog/

chatsecure-v4-released (visited on 01/2017).

[13] Riadi, I., 2017. Forensic investigation technique on android’s

blackberry messenger using nist framework. International Jour-

nal of Cyber-Security and Digital Forensics, 6(4), pp.198-206.

[14] Blöchinger, S. and von Seck, R., 2021. Survey of Mesh Net-

working Messengers. Network, 1.

[15] Balchasan, D., Ozaniak, M., Schwartz, Y., Steffensen, N.S.,

Khajuria, S. and Sørensen, L., 2019, January. ATHiCC: An

Anonymous, Asynchronous, Serverless Instant Messaging Pro-

tocol. In Proceedings of the 52nd Hawaii International Confer-

 92

ence on System Sciences.

[16] iyoshi, K., Tauseef, M., Gebremedhin, R., Gokhale, V. and Eid,

M., 2019, October. Towards standardization of haptic hand-

shake for tactile Internet: A WebRTC-based implementation.

In 2019 IEEE International Symposium on Haptic, Audio and

Visual Environments and Games (HAVE)(pp. 1-6). IEEE.

[17] Building Blockchain Decentralized App. https://www.lynda.

com/JavaScript-tutorials/Server-[Accessed18-Feb-2019]

[18] The Architecture Web 3.0 Application https://www.preethikasireddy.

com/post/the-architecture-of-a-web-3-0-application

[19] Ethereum and Blockchain -2 url http://iotbl.blogspot.com/

2017/03/ethereum-and-blockchain-2.html Accessed [23-Nov-

2018]

[20] AES256 – https://www.npmjs.com/package/aes256 Accessed

[16- Apr-2019]

[21] How to Build Your Own Chat App – https://hackernoon.

com/

how-to-build-your-own-chat Accessed [23-Apr-2019]

[22] How to compile smart contracts on to Ethereum Blockchain

 93

https://medium.com/mercuryprotocol/

dev-highlights-of-this-week-cb33e58c745f Accessed [21-

Feb-2019]

[23] Ethereum and App integration. https://image.slidesharecdn.

com/blockchainethereumbusinessapps4print-170523081730/

95/blockchain-ethereum-and-business-applications-25-638.

jpg?cb=1495542111 Accessed [28-Apr-2019]