A PROJECT REPORT ON

DIGITAL CONTRACT MANAGEMENT SYSTEM USING

BLOCKCHAINS

SUBMITTED BY

Neha Mishra 403006

Priya Bhardwaj 403013
Omkar chintalwar 403034
Swapnil Pardeshi 403046

SPONSERED BY
PERSISTENT SYSTEMS PVT.LTD.

UNDER THE GUIDANCE OF

Prof. PRADNYA KULKARNI(Internal Guide)
Mr. SUMIT GHOSH (External Guide)

Department Of Computer Engineering

MAEERs MAHARASHTRA INSTITUTE OF TECHNOLOGY
Kothrud, Pune 411 038
2015-2016
 MAHARASHTRA ACADEMY OF ENGINEERING AND EDUCATIONAL
RESEARCH’S

MAHARASHTRA INSTITUTE OF TECHNOLOGY

PUNE

DEPARTMENT OF COMPUTER ENGINEERING

CERTIFICATE

This is to certify that

Neha Mishra, Priya Bhardwaj, Omkar chintalwar, Swapnil Pardeshi of B.

E. Computer successfully completed design phase project on

DIGITAL CONTRACT MANAGEMENT SYSTEM USING

BLOCKCHAINS

to my satisfaction and submitted the same during the academic year 2015-
2016 towards the partial fulfillment of degree of Bachelor of Engineering
in Computer Engineering of Pune University under the Department of
Computer Engineering , Maharashtra Institute of Technology, Pune.

Prof. Pradnya Kulkarni Prof. Mrs. V. Y. Kulkarni

(Seminar Guide) (Head of Computer Engineering Department)

Place: Pune Date:

 Abstract

Contract management software is a program or series of related programs for

storing and managing legal agreements such as contracts with vendors, leases and
licensing agreements. An important purpose of contract management software is to
streamline administrative tasks and reduce overhead by providing a single, unified
view of each contracts processes.
A block chain or blockchain is a distributed database that maintains a continu-
ously growing list of data records that are hardened against tampering and revision,
even by operators of the data store‘s nodes. The most widely known application of a
block chain is the public ledger of transactions for cryptocurrencies used in bitcoin.
This record is enforced cryptographically and hosted on machines running the soft-
ware.

Keywords:
Decentralized Ledger System, Contract Management, Blockchain.
 ACKNOWLEDGEMENT

We take this opportunity to express our sincere appreciation for the cooperation
given by Prof. Mrs. V. Y. Kulkarni, HOD (Department of Computer Engineer-
ing) and a special mention for all the motivation and support.

We are deeply indebted to our guide Prof. Pradnya Kulkarni for completion
of this seminar work for which she has guided and helped us by going out of the way.

For all efforts behind the Project report, we would also like to express our sincere
appreciation to staff of Department of Computer Engineering, Maharashtra Institute
of Technology Pune, for their extended help and suggestions at every stage.

Neha Mishra
Priya Bhardwaj
Omkar chintalwar
Swapnil Pardeshi

i
Contents

1 SOFTWARE REQUIREMENT SPECIFICATION 2

1.1 PROBLEM STATEMENT . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 LITERATURE SURVEY . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 PROBLEM DEFINITION . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4 SCOPE OF THE PROJECT . . . . . . . . . . . . . . . . . . . . . . 6
1.4.1 INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4.2 FUNCTIONAL REQUIREMENT . . . . . . . . . . . . . . . . 7
1.4.3 USER CHARACTERISTICS . . . . . . . . . . . . . . . . . . 7
1.4.4 GENERAL CONSTRAINTS . . . . . . . . . . . . . . . . . . 7
1.4.5 ASSUMPTIONS AND DEPENDENCIES . . . . . . . . . . . 7
1.4.6 SCOPE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.5 SYSTEM ARCHITECTURE . . . . . . . . . . . . . . . . . . . . . . 9
1.5.1 Smart Contracts: . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.5.2 Merkle Tree: . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.5.3 Blockchain: . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.5.4 Blockchain forks : . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.6 HARDWARE AND SOFTWARE REQUIREMENTS . . . . . . . . . 18
1.6.1 HARWARE REQUIREMENTS . . . . . . . . . . . . . . . . . 18
1.6.2 SOFTWARE REQUIREMENTS . . . . . . . . . . . . . . . . 18
1.7 FEASIBILITY STUDY . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.7.1 Technical Feasibility . . . . . . . . . . . . . . . . . . . . . . . 19
1.7.2 Schedule feasibility . . . . . . . . . . . . . . . . . . . . . . . . 19
1.7.3 Legal feasibility . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.7.4 Financial feasibility . . . . . . . . . . . . . . . . . . . . . . . . 19
1.8 DESIGN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.8.1 UML DIAGRAMS . . . . . . . . . . . . . . . . . . . . . . . . 20
1.8.2 Sequence Diagram . . . . . . . . . . . . . . . . . . . . . . . . 32
1.9 TIME ANALYSIS OF THE PROJECT . . . . . . . . . . . . . . . . . 33

2 FUTURE ENHANCEMENT 34

ii
3 CONCLUSION 35

BIBLIOGRAPHY 36

iii
List of Figures

1.1 System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.2 Use Case diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

1.3 Activity diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

1.4 State Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

1.5 Component Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

1.6 Class Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

1.7 Package Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

1.8 Deployment Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

1.9 Sequence Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

iv
List of Tables

1.1 Use Case-Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

1.2 Use Case-Placing Order . . . . . . . . . . . . . . . . . . . . . . . . . 23

1.3 Use Case-Deposit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

1.4 Use Case-Logout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

1.5 Time Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

1
Chapter 1

SOFTWARE REQUIREMENT
SPECIFICATION

1.1 PROBLEM STATEMENT

Due to centralized ledger system used in banks, the present stock exchange takes
about 2 to 3 days to occur. We are implementing a system to decentralize this ledger
system using blockchains.

1.2 LITERATURE SURVEY

1. Trend of Centralization in Bitcoins Distributed Network
Alireza Beikverdi, JooSeok Song, Department of Computer Science,
Yonsei University, Seoul, Republic of Korea, IEEE, June 2015
Recent improvements in technology and computer industry such as emergence
of web, online shopping and online banking consequently, has created some alterna-
tives for traditional money exchange. Number of users using online payment services
and mobile banking have increased and gained a lot of popularity. However, having
a centralized trusted counter party that issues and stores these transactions such as
banks and services like PayPal has always been controversial. Centralization not only
centralizes the trust factor but it also centralizes the information and processes which
in that case any breaches in security of the centralized database would cause huge
information leak. By having internet as a great platform where everyone has an ac-
cess to, distributing information has become significantly simpler. Therefore many
distributed, decentralized technologies can easily benefit from internet as a platform.

2. Information Propagation in the Bitcoin Network

Christian Decker, Roger Wattenhofert, ETH Zurich, Switzerland, IEEE

2
1.2. LITERATURE SURVEY
DIGITAL CONTRACT MANAGEMENT SYSTEM USING BLOCKCHAINS

International Conference on Peer-to-Peer Computing, 2013

In order for the ledger replicas to remain consistent a common order over the
transactions has to be agreed among the nodes. Agreeing on a common order of trans-
actions in a distributed system is not trivial. This problem is solved by tentatively
committing transactions and then synchronizing at regular intervals by broadcasting
a block created by one of the nodes. In this paper, it has been analyzed how in-
formation in the network is disseminated in order to synchronize the ledger replicas.
The reliance on blocks not only delays the clearing of transactions, but it also poses
a threat to the network itself. Large blocks are propagated slowly in the network,
giving an attacker an advantage. An Introduce to a model that explains the existence
of blockchain forks, and corroborate the model by matching it to our observations.
As blockchain forks are symptomatic for an inconsistency in the ledger replicas, it is
important that the nodes in the network are aware about them. However, due to in-
formation eclipsing, most nodes are unable to detect them. Measurements have shown
that a single node implementing these changes reduces the number of blockchain forks
in the network by over 50%. The root cause of the problem however is intrinsic to
the way information is propagated in the network. The changes may mitigate the
problem in the short term, until a scalable long term solution is found.

3. Decentralizing Privacy: Using Blockchain to Protect Personal Data

IEEE CS Security and Privacy Workshops
Guy Zyskind, MIT Media Lab, Cambridge, Massachusetts, Oz Nathan,
Tel-Aviv University, Tel-Aviv, Israel, Alex ‘Sandy‘ Pentland, MIT Media
Lab, Cambridge, Massachusetts, 2015
In this paper, blockchain and off blockchain storage have been combined to
construct a personal data management platform focused on privacy. An illustration
and a discussion of future improvements to the technology, how blockchains could
become a vital resource in trusted-computing has been explained. Personal data,
and sensitive data in general, should not be trusted in the hands of third-parties,
where they are susceptible to attacks and misuse. Instead, users should own and
control their data without compromising security or limiting companies‘ and author-
ities‘ ability to provide personalized services. In this paper blockcahins have been
combined, re-purposed as an access-control moderator, with an offblockchain storage
solution. Users are not required to trust any third-party and are always aware of the
data that is being collected about them and how it is used. In addition, the blockchain
recognizes the users as the owners of their personal data. Companies, in turn, can
focus on utilizing data without being overly concerned about properly securing and
compartmentalizing them. Furthermore, with a decentralized platform, making legal
and regulatory decisions about collecting, storing and sharing sensitive data should

MIT, Pune . 3 Dept. of Computer Engg.

1.2. LITERATURE SURVEY
DIGITAL CONTRACT MANAGEMENT SYSTEM USING BLOCKCHAINS

be simpler. Moreover, laws and regulations could be programmed into the blockchain
itself, so that they are enforced automatically. In other situations, the ledger can act
as legal evidence for accessing (or storing) data, since it is (computationally) tamper-
proof.

4. Difficulty Control for Blockchain-Based Consensus Systems

Daniel Kraft, University of Graz, Institute of Mathematics, NAWI
Graz, Universitatsplatz 3, 8010 Graz, Austria, Springer, March 2015
In this paper, a model has been deveoped that allows to predict average block
times in Bitcoin mining. It is possible to account for the effect of changes in the
network hash rate over time, and to predict how the difficulty-update mechanism of
reacts. Unfortunately, this currently applied method yields too fast blocks while the
hash rate is exponentially rising. To improve the stability of block times, an alterna-
tive has been proposed for difficulty control that is designed to work perfectly not just
for constant hash rate but also if the hash rate grows exponentially (with a constant
but unknown rate).Even for real-world data (of the historical Bitcoin and Namecoin
blockchains), the method leads to significant improvements.

5. The Blockchain-based Digital Content Distribution System

Jay Kishigami, Muroran Institute of Technology, Hokkaido, Japan, Shigeru
Fujimura, Hiroki Watanabe, Atsushi Nakadaira, and Akihiko Akutsu, NTT
Service Evolution Laboratories, Kanagawa, Japan, IEEE Fifth Interna-
tional Conference on Big Data and Cloud Computing, 2015
The blockchain-based digital content distribution system was developed. De-
centralized and pear-to-pear authentication mechanism can be considered as the ideal
rights management mechanism. The blockchain has the potential to realize this ideal
content distribution system. This paper represents the successful model of the Su-
perdistribution concept which was announced almost 30 years ago. The proposed
system was demonstrated and got a lot of feedback for the future practical system.
Decentralized blockchain-based digital content distribution system was proposed, and
developed a prototype for the easy understanding its concept. The proposed system
in this paper has no incentive mechanism for the mining calculation at this moment.
This means no cost can be covered if each minor calculates the hash value. Some
BTC would be paid to the minor as a incentive in the case of the Bitcoin system. It
has been considered that the incentive mechanism should be discussed in the business
model.

MIT, Pune . 4 Dept. of Computer Engg.

1.3. PROBLEM DEFINITION
DIGITAL CONTRACT MANAGEMENT SYSTEM USING BLOCKCHAINS

1.3 PROBLEM DEFINITION

When a transaction is made, the terminal at user‘s end makes a request at
his bank, and his bank has only a few seconds to accept or reject the transaction.
Once the transaction is accepted by his bank, it appears in the Pending transactions.

At the end of the business day, the user‘s end terminal submits all of the final
transactions for the day to the bank in a batch, and the banks all trade transactions
in a batch, and money is sent between banks. This is the process that takes a couple
of days, and after this happens, the transaction moves from pending transactions into
the regular transactions area. Most of the time, the pending transaction and the final
transaction are the same. However, there are cases where it is different.

With a credit account, the fact that the final amount is not known for a few
days is no big deal: if the user doesn‘t have any money in the account, and if he ends
up spending more than he has, then the bank will let the user take some time coming
up with the money at a cost.

With a debit card tied to user‘s checking account, the transaction is handled
the same way, as far is the user‘s end terminal is concerned. However, user‘s bank
is not going to run the risk of user overdrawing his checking account. They also are
not going to run the risk of user withdrawing money from his account that is needed
to cover pending transactions. So they usually treat these pending transactions as
final transactions, deducting the pending transaction from user‘s account balance im-
mediately. When the final transaction comes through, they adjust the transaction,
and user‘s balance goes up or down accordingly. This is one of the big drawbacks
to using a debit card. If a bad pending transaction comes through, you are out this
money until it gets straightened out. This same system is implemented in contract
management legder system. This system is a centralized system. Hence, making the
transaction processing slow.
We are developing a ledger system that would be decentralized, hence, making the
transactions faster and safer. This goal has been achieved by using the concept of
blockchain.

The core advantages of the block chain architecture include the following:

ˆ The ability for a large number of nodes to converge on a single consensus of

the most up-to-date version of a large data set such as a ledger, even when the
nodes are run anonymously, have poor connectivity with one another, and have
operators who may be dishonest or malicious.

MIT, Pune . 5 Dept. of Computer Engg.

1.4. SCOPE OF THE
DIGITAL PROJECTMANAGEMENT SYSTEM USING BLOCKCHAINS
CONTRACT

ˆ The ability for any node that is well-connected to other nodes to determine, with
a reasonable level of certainty, whether a transaction does or does not exist in
the confirmed data set.

ˆ The ability for any node that creates a transaction to, after a certain period of
confirmation time, determine with a reasonable level of certainty whether the
transaction is valid, able to take place, and become final (i.e. that there were
no conflicting transactions confirmed into the block chain elsewhere that would
make the transaction invalid, such as the same currency units ”double-spent”
somewhere else).

ˆ A prohibitively high cost to attempt to rewrite or alter any transaction history.

An automated form of resolution that ensures that conflicting transactions (such
as two or more attempts to spend the same balance in different places) never
become part of the confirmed data set.
The decentralization of the ledger system is achieved by: Every node in a de-
centralized cryptocurrency has a complete or partial copy of the block chain. This
avoids the need to have a centralized database that other systems, such as PayPal,
require. Whereas a conventional ledger records the transfers of actualbillsorpromis-
sory notesthat exist apart from it, the block chain is the only place that bitcoins can
be said to exist in the form of unspent outputs of transactions.

Transactions of the form payer X sends Y currency to payee Z are broadcast

to this network using software applications. Network nodes can validate transactions,
add them to their copy of the ledger, and then broadcast these ledger additions to
other nodes.

Cryptocurrencies use various timestamping schemes, such as proof-of-work, to

avoid the need for a trusted third party to timestamp transactions added to the block
chain. This avoids anyone easily double-spending the currency.

1.4 SCOPE OF THE PROJECT

1.4.1 INTRODUCTION
In this project, we aim to build a decentralized ledger system for digital contract
system. We are using ”Blockchain” technology to implement it.
What does the project will implement :
ˆ Centralized ledger system will be decentralized so it will be more secure from
malicious activities.

MIT, Pune . 6 Dept. of Computer Engg.

1.4. SCOPE OF THE
DIGITAL PROJECTMANAGEMENT SYSTEM USING BLOCKCHAINS
CONTRACT

ˆ Faster execution time i.e. the time taken in transfering money digitally now will
decrease.

1.4.2 FUNCTIONAL REQUIREMENT

1. Login details for new user or existing user.

2. Store the user‘s order whether it is buy, sell or cancel stock transactions.

3. User can view its portfolio.

4. Withdraw or deposit stocks/money according to user‘s transactions.

5. Logout from the system.

1.4.3 USER CHARACTERISTICS

ˆ Developer :

– They create the system using blockchains and analyse customer feedbacks.
– They should be knowledgeable about end users.

ˆ User :

– User should be able to fill in the login and transaction details correctly.
– They need not to be knowledgeable about the internal working of blockchain.

1.4.4 GENERAL CONSTRAINTS

1. Multiple user login should be supported.

2. Correct login details should be entered.

3. Open source blockchain will be used.

1.4.5 ASSUMPTIONS AND DEPENDENCIES

1. The system depends on formation time of a block in blockchain for updation.
Presently in every 10 minutes one block is formed in blockchain technology.

2. The ledger system decentralization does not depend on the type whether it is
branch by branch or city by city.

MIT, Pune . 7 Dept. of Computer Engg.

1.4. SCOPE OF THE
DIGITAL PROJECTMANAGEMENT SYSTEM USING BLOCKCHAINS
CONTRACT

1.4.6 SCOPE
We describe what features are in the scope of the software and what are not in
scope of the software to be developed.

1. Increase in security
A centralized asset ledger is a list of transactions that is controlled by a single
entity, such as a bank statement. The bank has total control over which trans-
actions are posted on the ledger. For example they can fine you and directly
take money away from you without your consent. This is a danger of centralized
ledgers because if the entity-in-charge has malicious intent, it can do some seri-
ous damage to its clients. The answer to this problem is a decentralized ledger.
Without a central entity, there is no one capable of cheating the system and
transactions will be entered in an honest manner.

2. No intermediate intervention in transactions

A disadvantage of a centralized ledger is the controlling entity can shut down
without notice and transactions will no longer be processed. Giving this kind of
authority to someone will result in error, whether it be accidental or not. The
answer to this problem is also a decentralized ledger. The decentralized ledger
system can be made possible by the concept of ”Proof of Work”.

3. Faster transactions
Presently, a normal digital transaction takes about 2 to 3 days to complete.
But by using the concept of blockchain in contract management system we can
reduce this transaction time into much lesser period.

MIT, Pune . 8 Dept. of Computer Engg.

1.5. SYSTEM ARCHITECTURE
DIGITAL CONTRACT MANAGEMENT SYSTEM USING BLOCKCHAINS

1.5 SYSTEM ARCHITECTURE

Figure 1.1: System Architecture

MIT, Pune . 9 Dept. of Computer Engg.

1.5. SYSTEM ARCHITECTURE
DIGITAL CONTRACT MANAGEMENT SYSTEM USING BLOCKCHAINS

1.5.1 Smart Contracts:

A general sense of blockchain-based smart contracts emerges from the smart
property discussion. In the blockchain context, contracts or smart contracts mean
blockchain transactions that go beyond simple buy/sell currency transactions, and
may have more extensive instructions embedded into them. In a more formal defi-
nition, a contract is a method of using Bitcoin to form agreements with people via
the blockchain. A contract in the traditional sense is an agreement between two or
more parties to do or not do something in exchange for something else. Each party
must trust the other party to fulfill its side of the obligation. Smart contracts feature
the same kind of agreement to act or not act, but they remove the need for one type
of trust between parties. This is because a smart contract is both defined by the
code and executed (or enforced) by the code, automatically without discretion. In
fact, three elements of smart contracts that make them distinct are autonomy, self
sufficiency, and decentralization.

ˆ Autonomy means that after it is launched and running, a contract and its ini-
tiating agent need not be in further contact.

ˆ Smart contracts might be self-sufficient in their ability to marshal resourcesthat

is, raising funds by providing services or issuing equity, and spending them on
needed resources, such as processing power or storage.

ˆ Smart contracts are decentralized in that they do not subsist on a single cen-
tralized server; they are distributed and self-executing across network nodes.

1.5.2 Merkle Tree:

Incryptographyandcomputer science, ahash treeorMerkle treeis atreein which ev-
ery non-leaf node is labelled with thehashof the labels of its children nodes. Hash
trees are useful because they allow efficient and secure verification of the contents
of large data structures. Hash trees are a generalization ofhash listsandhash chains.
Demonstrating that a leaf node is a part of the given hash tree requires processing an
amount of data proportional to thelogarithmof the number of nodes of the tree;this
contrasts with hash lists, where the amount is proportional to the number of nodes.
Hash trees can be used to verify any kind of data stored, handled and transferred in
and between computers. Currently the main use of hash trees is to make sure that
data blocks received from other peers in apeer-to-peer networkare received undam-
aged and unaltered, and even to check that the other peers do not lie and send fake
blocks.A hash tree is atreeofhashesin which the leaves are hashes of data blocks in,

MIT, Pune . 10 Dept. of Computer Engg.

1.5. SYSTEM ARCHITECTURE
DIGITAL CONTRACT MANAGEMENT SYSTEM USING BLOCKCHAINS

for instance, a file or set of files. Nodes further up in the tree are the hashes of their
respective children. For example, in the picturehash 0is the result of hashing the
result of concatenatinghash 0-0andhash 0-1. That is,hash 0 = hash( hash 0-0 + hash
0-1 )where + denotes concatenation.

Most hash tree implementations are binary (two child nodes under each node)
but they can just as well use many more child nodes under each node.

Usually, acryptographic hash function such asSHA-2is used for the hashing.
If the hash tree only needs to protect against unintentional damage, much less se-
curechecksumssuch asCRC scan be used.

In the top of a hash tree there is atop hash(orroot hashormaster hash). Before
downloading a file on a p2p network, in most cases the top hash is acquired from a
trusted source. When the top hash is available, the hash tree can be received from
any non-trusted source, like any peer in the p2p network. Then, the received hash
tree is checked against the trusted top hash, and if the hash tree is damaged or fake,
another hash tree from another source will be tried until the program finds one that
matches the top hash.

Overlay Network:

Anoverlay networkis acomputer networkthat is built on top of another network.Nodesin

the overlay network can be thought of as being connected by virtual or logical links,
each of which corresponds to a path, perhaps through many physical links, in the
underlying network.

Nonce:

A nonce is an arbitrary number used only once in a cryptographic communication,

in the spirit of anonce word. They are oftenrandomor pseudo-randomnumbers. Many
nonces also include a timestamp to ensure exact timeliness, though this requires clock
synchronization between organizations. The addition of a client nonce (”cnonce”)
helps to improve the security in some ways as implemented indigest access authenti-
cation. To ensure that a nonce is used only once, it should be time-variant (including
a suitably fine-grainedtimestampin its value), or generated with enough random bits
to ensure a probabilistically insignificant chance of repeating a previously generated
value. Some authors define pseudo-randomness (or unpredictability) as a requirement
for a nonce.

MIT, Pune . 11 Dept. of Computer Engg.

1.5. SYSTEM ARCHITECTURE
DIGITAL CONTRACT MANAGEMENT SYSTEM USING BLOCKCHAINS

Hashing:

Nonces are used inproof-of-work systemsto vary the input to a cryptographic hash
functionso as to obtain a hash for a certain input that fulfills certain arbitrary condi-
tions. In doing so, it becomes far more difficult to create a ”desirable” hash than to
verify it, shifting the burden of work onto one side of a transaction or system.
Theblockchain hashing algorithm can be tuned to an arbitrary difficulty by chang-
ing the required minimum/maximum value of the hash for reducing the number of
blocks created for each transaction. This is likewise achieved by forcing to add nonce
values to the value being hashed to change the hash algorithm output.

1.5.3 Blockchain:
Eachblockin the chain contains a reference to the previous block in the chain (that
is thePrev Hashin the picture) and some additional information which makes up the
content of the block. The link to the previous block is what makes it a chain:given
a block you can find all the information in all the previous blocks that led to this
one, right back to whats called the genesis block, the very first one in the chain.
Up to this point, blocks do not provide any added synchronization on top of the
individual transactions. This changes when the blocks are chained together, creating
a chronological order over the blocks and therefore about the transactions contained
within them. The blocks are organized in a directed tree. Each block contains a
reference to a previously found block. The block b referenced by a block bl is called
its parent. The transitive closure of this relation gives its ancestors. The root block
in the tree is the genesis block, which is hardcoded into the clients. This block is an
ancestor of all blocks by definition. The blockchain is defined as the longest path
from any block to the genesis block. The distance between a block b and the genesis
is referred to as its block height hb. The genesis block therefore has height hg = O.
The block with maximal height, i.e., the block that is furthest away from the genesis
block is referred to as blockchain head, with height hhead. We use the notation Bh
to reference the set of blocks at height h. Since to include a reference to the parent
block, that parent block‘s identity (its hash) has to be known, the child block must
have been found after the parent. The chaining is used to assign a chronological order
to the transactions: transactions in lower height blocks have been verified before
transactions in higher blocks. As only blocks appearing in the blockchain will be
rewarded with newly minted coins that are accepted by other users, miners will always
attempt to find a block that builds on the current blockchain head. Building on an
earlier block would require the resulting branch to become longer than the currently
longest branch, i.e., the blockchain, to be rewarded.

MIT, Pune . 12 Dept. of Computer Engg.

1.5. SYSTEM ARCHITECTURE
DIGITAL CONTRACT MANAGEMENT SYSTEM USING BLOCKCHAINS

Storage

The blockchain is managed by a network of distributed nodes. Every node has

acopy of the entire blockchain. New nodes can come and go, synchronising their copies
of the blockchain against those of other nodes as they join the network. The fact that
there are multiple copies of the blockchain on a distributed network of nodes is one of
the powerful features of the blockchain. Itmakes the blockchain robust against nodes
disappearingeither temporarily or permanently, whether that is due to connectivity
issues, hardware failures, or interference. The more nodes there are in the network,
the harder it is to disrupt the storage of the blockchain. There is no single point of
failure, unlike in a centralised system with a single authority.

A block in blockchain

A block has a header and a list of transactions (they are theTx0,Tx1Tx3in the
picture of the blockchain). The header includes: a pointer to the previous block
(Prev Hashin the picture a summary of the transactions the block contains (techni-
cally, the Merkle hashof those transactions, theTx Rootin the picture) a timestamp
that indicates when the block was created, a proof of the work that went into creating
the block (Noncein the picture) a timestamp server: itprovides irrefutable evidence
that the data in a block existed at a particular time. The actualtimestampgiven in a
particular block isnt necessarily to-the-second accurate. In fact theres nothing stop-
ping the timestamp of a particular block being before the timestamp of the previous
block. If a block is in the blockchain, what is guaranteed is: the block was added at
most two hours before its timestamp. The block before this block in the chain existed
at the time the block was created. This block was added to the chain before the next
block in the chain existed. The data in this block existed at the time the block was
created. Thehash of the header of the block, incorporating each of these pieces of
information, becomes the identifier for the block which is used by the next block in
the chain. Every node in the network can add blocks to the chain. Every node is sent
the data that needs to go into the blocks (the transactions). Every node can package
up that data into a block that links back to the last block in the chain that they are
aware of. And every node can then transmit that block to the rest of the network to
assert this is the new chain.
So what stops this being a completely chaotic situation where every node is adding
blocks at the same point in the chain at the same time, forking it willy-nilly? What
ensures that the nodes in the network have a consistent, consensus view of what the
blockchain holds? The first barrier is that nodes all operate under a set of protocol
rulesthat determine what a valid block looks like. These rules include ensuring that
each transaction is a valid transaction: that it is spending money that actually exists

MIT, Pune . 13 Dept. of Computer Engg.

1.5. SYSTEM ARCHITECTURE
DIGITAL CONTRACT MANAGEMENT SYSTEM USING BLOCKCHAINS

(technically, pointing to a previous matching transaction within the blockchain) and

that it has been signed by the creator of the transaction. They also ensure integrity
between transactions: that the same money isnt being spent twice (technically, each
output of a transaction can only form the input of one other transaction).The other
test for a valid block is where itsnoncecomes in. To be a valid block,the hash of the
header of the block always has to start with a certain number of zeros. (Or, put
another way, it has to be below a certaintarget number.) If you remember, the header
contains:the hash of the previous block in the chain, the Merkle hash of the transac-
tions in the block, a timestamp and a nonce.

There is a node and a whole bunch of transactions that has to be put together
into a block to add to the chain. The hash of the previous block in the chain is
known. Then calculate the Merkle hash for the transactions to be put in the block.
The time is known. But what is not known, and what has to be to worked out, iswhat
nonce will result in the header of the new block having a hash that starts with lots
of zeros. Now, the way thathashing works means that there is no way a node can
algorithmically compute what nonce is going to give the block this magic property.
Different nonces have to be tried.
Thecurrent probabilityof managing to get a nonce that works per attempt is about
1 in a sextillion (102̂1,about the number of grains of sand on all the beaches in the
world). Specialised hardware performs at 1000 GH (giga-hashes), which means it
tries about one trillion (101̂2) nonces each second. So nodes have to work really hard
to create valid blocks. They have to try lots and lots and lots of different nonces,
calculating lots and lots and lots of hashes. A valid block, whose hash begins with
lots of zeros, is proof that the node that created it did lots of work, hence the nonce
is sometimes called aproof of work. The number of zeros that a blocks hash has to
start with, or the target number that it has to be below, determines the difficulty of
creating a new block, and hence the average time that it will take. The smaller the
target number, the more zeros the hash has to start with, the lower the probability
of hitting on such a hash, and the harder it is to create a new block. The difficulty
of creating a new block is automatically regulatedsuch that no matter how big the
network of nodes gets, and no matter how much compute power they have,it will
always takeabout 10 minutesfor the whole network to find a new block.

Every 2016 blocks, which is about every 2 weeks, a new target number is
calculated based on how long it took to create those 2016 blocks. If it averaged more
than 10 minutes to create them, the target number goes up and the difficulty goes
down; if it took less than 10 minutes to create them, the target number goes down and
the difficulty goes up. So the difficulty adapts andvaries over timebased on the total

MIT, Pune . 14 Dept. of Computer Engg.

1.5. SYSTEM ARCHITECTURE
DIGITAL CONTRACT MANAGEMENT SYSTEM USING BLOCKCHAINS

compute power of the network. This adaptation does give some limits to the growth
of the blockchain and to the number of transactions the network can handle. A new
block is added roughly every 10 minutes. Each block currently has a maximum size
of 1MB, put in place to limit the amount of data that nodes have to pass around to
stay synchronised. The size of transactions varies, but the commonly quotedmaximum
transaction rateis 7 transactions per second, equivalent to 4200 transactions per block.
It also means thatas the network grows, the total energy consumed grows, but the
output stays the same. Researchers have estimated that the total power consumed
by the Bitcoin network is something in the region of 3GW about the same power
consumption as Ireland.

Creation of new blocks:

Weve looked at the large numbers of calculations that nodes have to do in order
to create new blocks. At the time of writing there are estimated to beabout 100,000
nodes. All of them are trying to add new blocks to the chain; about every 10 minutes
one of them will succeed.The work that nodes have to do to create a new block takes
time. This lowers the probability that two blocks are made at the same time, but
its still possible. When this happens, it creates a fork in the blockchain; some nodes
might start building on one of those branches and some on the other. But theprotocol
rulesthat govern how the nodes operate prevent this situation from going on for very
long. Each node keeps track of all the branches, butnodes will only try to extend
the longest branch they know about. (The length isnt determined by the number of
blocks but by the total amount of work that has gone into building the branch, based
on the number of zeros at the beginning of the block hash.)

The transactions in shorter branches arent lost. When a node learns that an-
other branch is longer than the one it has been working on, it checks its current
branch for any transactions that arent in the new branch. These missed transactions
are broadcast to the network again, and incorporated into new blocks on the chain. So
the blocks at the end of the blockchain could be retracted at any time. The network
of nodes will eventually come to a consensus position on which block follows a given
block, but at any one time there might be many branches in operation, potentially in-
cluding different transactions. And some of the transactions that are in the blockchain
currently accepted by a node may eventually turn out to be invalid. If two branches
contain transactions that cannot coexist, one of the transactions will eventually be
refused.This uncertainty about the end of the chain leads to the common rule thata
given transaction isnt confirmeduntil it is at least 6 blocks deep in the chain(ie after
about an hour, given each block takes about 10 minutes to create). This number is

MIT, Pune . 15 Dept. of Computer Engg.

1.5. SYSTEM ARCHITECTURE
DIGITAL CONTRACT MANAGEMENT SYSTEM USING BLOCKCHAINS

based on understanding what it would take to change the contents of the blockchain.
As weve seen, each block contains a reference to the previous block, and that
reference the hash of the block encodes both the content of the block and the ref-
erence to the previous block. In other words,if you changed the content of a block,
you would change its hash. If you changed its hash, you would need to change the
reference to it in the block after it in the chain. That in turn would change that
blocks hash, which would mean changing the reference in the block after that, and so
on to the end of the chain. So changing the content of a block is hard to do when the
block is followed by other blocks. Once a block is embedded within the chain, you
have to unpick all the following blocks right back to the one you want to change, and
then reconstruct those blocks again. As weve seen, creating a block is hard work: it
takes lots of computational power. But more than that, while you are busy trying
to recreate the chain youve unpicked, the rest of the network is merrily continuing to
add even more blocks to that chain.
The ease with which someone can alter the blockchain depends on the proportion
of the network that they own.Its possible tocalculate the probabilityof someone be-
ing able to alter the blockchain depending on the proportion of the compute power
that they control and the number of blocks back in the chain they are trying to amend.

For example, someone who controlled 20% of the compute power of the network
has a 40% chance of being able to change the last block in the chain, but only a 4%
chance of being able to change a block that is 5 blocks back in the chain. Someone
who controls 10% of the compute power of the network has a less than 0.1% chance
of being able to change a block 6 blocks back in the chain.This last calculation is
the basis for deciding when a transaction is confirmed: even if someone managed to
capture 10% of the compute power of the network, theyd still have less than a 0.1%
chance of altering a block that is 6 blocks deep in the chain. Its judged unlikely that
anyone would capture that much of the network, and theyre still unlikely to succeed
even if they did, so 6 blocks feels like a safe bar for transactions in the network to
need to meet.
In order for the ledger replicas to remain consistent a common order over the
transactions has to be agreed among the nodes. Agreeing on a common order of trans-
actions in a distributed system is not trivial. This problem is solved by tentatively
committing transactions and then synchronizing at regular intervals by broadcasting
a block created by one of the nodes. A block b contains the set of transactions Tb that
the node which created the block has committed since the previous block. The block
is then distributed to all the nodes in the network and each node receiving it will roll
back the tentatively committed transactions since the last block and apply the trans-
actions from the current block. At this point all the nodes have agreed on the validity

MIT, Pune . 16 Dept. of Computer Engg.

1.5. SYSTEM ARCHITECTURE
DIGITAL CONTRACT MANAGEMENT SYSTEM USING BLOCKCHAINS

of all the transactions in the block. Transactions that were conunitted as part of the
block are confirmed and do not have to be reapplied. The transactions that have been
rolled back will then be validated again and reapplied on top of the new base state.
Transactions that are now invalid because they conflict with transactions committed
as part of the block are discarded. The node that created the block effectively imposes
its view of the changes since the previous block. However, the decisions of the block
creator are limited. The node cannot forge any transactions as long as the under-
lying public-private-key cryptosystem is secure. The block creator may only decide
in which order transactions arrived and whether to include transactions in its block.
To determine which node may impose its view the nodes attempt to find a solution
to a proof-of-work with a given probability of success. The proof-of-work consists in
finding a byte string, called nonce, that combined with the block header results in a
hash 1-lb with a given number of leading zero-bits, or target. As cryptographic hashes
are one-way functions, finding such a nonce can only be done by actually calculating
the hash of the block for all possible nonces until a valid solution is found. It is
therefore difficult to find an input that produces a solution, but straight forward to
verify it. The nonce is part of the block so that nodes receiving it can verify that the
creator solved the proof-of-work. The hash 1-lb is also used as the block‘s identity.
The target is determined via consensus by all nodes in order to achieve an average of
one result every 10 minutes in the entire network and is adjusted every 2016 blocks,
which should occur once every 14 days in expectation. Nodes attempting to find a
solution to the proof-of-work are often called miners. To incentivize miners, the node
finding a block receives a reward in the form of newly minted bitcoins, i.e., it may
include a transaction that has no inputs but may specify outputs for a predetermined
number of coins into the block. This reward transaction is only valid if it appears in
the block and is the only exception to the rule that the sum of a transaction‘s outputs
has to be smaller or equal to the sum of the transaction‘s inputs.

1.5.4 Blockchain forks :

From the definition of blockchain directly follows that there can be multiple heads
at a time, i.e., when IBhl ¿ 1 with h = hhead. This situation is called a blockchain
fork. During a blockchain fork the nodes in the network do not agree on which of the
blocks in Bh is the current blockchain head. Two blocks b, bl E Bh are guaranteed to
disagree about the current state of the ledger, because they both introduce a reward
transaction. Hence, a blockchain fork implies that the system is no longer consistent.
When a node, whose blockchain head bh is at height h, receives a block bh, for height
hi ¿ h it switches its blockchain head to this block. The new block bh‘ may either
be on the same branch as bh, i.e., bh is an ancestor of bh” or on another branch.

MIT, Pune . 17 Dept. of Computer Engg.

1.6. HARDWARE
DIGITALAND SOFTWARE
CONTRACT REQUIREMENTS
MANAGEMENT SYSTEM USING BLOCKCHAINS

Should block bh be on the same branch as the newly found blockchain head bh‘ it will
retrieve all intermediate blocks on the branch and apply their changes incrementally.
On the other hand, should bh, be part of another branch, i.e., bh is not an ancestor
of bh” then they share a COlmnon ancestor. Since bh, is on a longer chain than bh it
becomes the new blockchain head, therefore the node has to revert all changes down
to the common ancestor and apply the changes in the branch of bh‘. A blockchain
fork may be prolonged by the partitions of the network finding more blocks Bh+l,
Bh+2, ... building on their respective blockchain heads. Eventually one branch will
be longer than the other branches, and the partitions that did not adopt this branch
as theirs will switch over to this branch. At this point the blockchain fork is resolved
and the ledger replicas are consistent up to the blockchain head. The blocks discarded
by the blockchain resolution are referred to as orphan block. Every transaction can be
invalidated if a longer chain that started below the block including the transaction is
created. If a single entity could control a majority of the computational power on the
network, and thus be able to find blocks faster than the rest of the network combined,
it could revert any transaction. If an attacker attempts to revert a transaction that
was included in block bh it would create a new transaction that conflicts with the
original transaction and include it into a block bh‘ with hi ¡ h. The attacker would
then proceed to create blocks on top of bh‘ until this new chain overtakes the original
blockchain and thus becomes the new blockchain. One may argue that the existence of
blockchain forks is the very reason that transactions are never definitively committed.
The tight coupling between blocks and the validity of a transaction not only slows
down the confinnation time of a transaction but also limits the confirmation to be a
probabilistic statement about the validity.

1.6 HARDWARE AND SOFTWARE REQUIRE-

MENTS
1.6.1 HARWARE REQUIREMENTS
1. 300GB Hard disk

2. 2GB RAM minimum,4GB RAM recommended

3. Intel core i3 and above

1.6.2 SOFTWARE REQUIREMENTS

1. Windows 7/8,Linux

MIT, Pune . 18 Dept. of Computer Engg.

1.7. FEASIBILITY
DIGITAL STUDY
CONTRACT MANAGEMENT SYSTEM USING BLOCKCHAINS

2. Programming languages Java API/Swing

3. Database Mysql

1.7 FEASIBILITY STUDY

The purpose of a feasibility study is to identify the likelihood of one or more
solutions meeting the stated business requirements. In other words, if you are unsure
whether your solution will deliver the outcome you want, then a Project Feasibility
Study will help gain the clarity. During the Feasibility Study, a variety of assessment
solutions are implemented.

1.7.1 Technical Feasibility

ˆ The system will be developed using Blockchain technology.

ˆ The programming is done using Java and mysql.

1.7.2 Schedule feasibility

ˆ After understanding the scope of the project, we can conclude that the project
can be successfully completed in given time frame of 8 months.

1.7.3 Legal feasibility

ˆ Our proposed project does not conflict with any legal requirement in person
or in company’s favour. The project undertaken meets all legal and ethical
requirements and does not violate the company’s norms. Also, we are using all
open source technologies for the development of the project. Therefore, there is
no legal binding for our project.

1.7.4 Financial feasibility

ˆ Since this project is simply to be developed using Blockchain technology, which
is open source, there is no need of financial help. The company would also be
providing the hardware as a part of the sponsorship and hence no financial help
is necessary.

MIT, Pune . 19 Dept. of Computer Engg.

1.8. DESIGN
DIGITAL CONTRACT MANAGEMENT SYSTEM USING BLOCKCHAINS

1.8 DESIGN
1.8.1 UML DIAGRAMS
UML diagrams consists of following diagrams:

1. Use-Case Diagram

2. Activity Diagram

3. State Diagram

4. Component Diagram

5. Class Diagram

6. Package Component Diagram

7. Deployment Diagram

8. Sequence Diagram

Use-Case Diagram

Use case diagram shows the overall functionality of the system. In our system there
are three use case diagrams.

1. Developer :

ˆ They create the system using blockchains and analyse customer feedbacks.
ˆ They should be knowledgeable about end users.

2. User :

ˆ User should be able to fill in the login and transaction details correctly.
ˆ They need not to be knowledgeable about the internal working of blockchain.

MIT, Pune . 20 Dept. of Computer Engg.

1.8. DESIGN
DIGITAL CONTRACT MANAGEMENT SYSTEM USING BLOCKCHAINS

Figure 1.2: Use Case diagram

MIT, Pune . 21 Dept. of Computer Engg.

1.8. DESIGN
DIGITAL CONTRACT MANAGEMENT SYSTEM USING BLOCKCHAINS

Table 1.1: Use Case-Login

Use Case Login

ID 1
Brief Description This is the entry point for the
user in the system. Which au-
thenticate the customer depend-
ing upon username and password
Primary Actors Customer
Secondary Actors System for checking the valida-
tion
Precondition Customer must register in system
before login
Main flow
ˆ Customer should register
himself in the system before
login.

ˆ System automatically di-

vert the control of process
towards the registration if
customer which is not exist-
ing.

ˆ Customer login into system

if given information is au-
thenticate.

Post condition Customer proceeds towards the

next process
Alternative flow None

MIT, Pune . 22 Dept. of Computer Engg.

1.8. DESIGN
DIGITAL CONTRACT MANAGEMENT SYSTEM USING BLOCKCHAINS

Table 1.2: Use Case-Placing Order

Use case Placed an Order

ID 2
Brief Description In this case customers can
buy/sale the stock according to
his wish. This is the main part of
the project. Which actually do
the work of exchange of share
Primary Actors Customer
Secondary Actors System
Precondition Customer should be authenticat-
ing through login process
Main flow
ˆ Check the operation which
customer want to do like
buy, sale, etc.

ˆ Perform the operation ac-

cording to customer.

ˆ Placed an order for the cus-

tomer.

ˆ Provide the status of ac-

counts of customer to the
next module of the system.

Post condition Result is to sent to the deposit

module of the system
Alternative flow None

MIT, Pune . 23 Dept. of Computer Engg.

1.8. DESIGN
DIGITAL CONTRACT MANAGEMENT SYSTEM USING BLOCKCHAINS

Table 1.3: Use Case-Deposit

Use case Deposit

ID 3
Brief Description Deposit money/shares to the
buyer account
Primary Actors Customer
Secondary Actors User
Precondition Order should be placed by cus-
tomer
Main flow
ˆ Depending upon the oper-
ation selected by the cus-
tomer deposit/withdraw of
shares along with money
takes place.

ˆ Status of account get up-

dated

ˆ Updated result is then sent

to the next module of the
system.

Post condition Account details of the customer

get updated.
Alternative flow None

MIT, Pune . 24 Dept. of Computer Engg.

1.8. DESIGN
DIGITAL CONTRACT MANAGEMENT SYSTEM USING BLOCKCHAINS

Table 1.4: Use Case-Logout

Use case Logout

ID 5
Brief Description This facility is provide to cus-
tomer for instant exit from the
system
Primary Actors User
Secondary Actors System
Precondition Customer must be logged in
with authenticated username and
password
Main flow
ˆ Customer log in through lo-
gin process.

ˆ Logout option is always

available for the customer.

ˆ It terminates the all work

of customer and exited from
the current state.

ˆ System provide the initial

login UI for the customer.

ˆ Result of the logout is

passed to the internal func-
tionality for resuming the
status of account and user
as well.

Post condition System is restart in the initial

state by updating all information.
Alternative flow From any state of system this
state can be achieved.

MIT, Pune . 25 Dept. of Computer Engg.

1.8. DESIGN
DIGITAL CONTRACT MANAGEMENT SYSTEM USING BLOCKCHAINS

Activity Diagram

In activity diagram the overall flow of the system is shown. It contains the following
sequence of action.

Figure 1.3: Activity diagram

MIT, Pune . 26 Dept. of Computer Engg.

1.8. DESIGN
DIGITAL CONTRACT MANAGEMENT SYSTEM USING BLOCKCHAINS

State diagram

State machine diagram capture the behavior of the software system. State ma-
chines can be used to model the behavior of a class or an entire application

Figure 1.4: State Diagram

MIT, Pune . 27 Dept. of Computer Engg.

1.8. DESIGN
DIGITAL CONTRACT MANAGEMENT SYSTEM USING BLOCKCHAINS

Component diagram

A component diagram in the unified modeling language represents a modular art

of the system that encapsulates its content and whose manifestation is replaceable
within its environment. A component defines its behavior in terms of provided and
required intefaces.

Figure 1.5: Component Diagram

MIT, Pune . 28 Dept. of Computer Engg.

1.8. DESIGN
DIGITAL CONTRACT MANAGEMENT SYSTEM USING BLOCKCHAINS

Class diagram

Class diagram are the most common diagram found in modeling object oriented
systems. A class diagram shows set of classes interface and collaboration and their
relationships.

Figure 1.6: Class Diagram

MIT, Pune . 29 Dept. of Computer Engg.

1.8. DESIGN
DIGITAL CONTRACT MANAGEMENT SYSTEM USING BLOCKCHAINS

Package diagram

A package diagram is a UML diagram composed only of package and the depen-
dencies between them. A package is a UML construct that enables you to organize
model elements such as use cases or classes into groups.Package are depicted as file
folders and can be applied on any UML diagrams.
The package diagram shows that our system uses five main packages i.e. cus-
tomer data, portfolio info, Order detail, Transaction and logging info package. The
customer data package is using the services offered by the portfolio info package and
the portfolio info is using the services offered by order detail. Order detail is using the
services offered by transaction and transaction is accessing the logging information
from logging info package.

Figure 1.7: Package Diagram

MIT, Pune . 30 Dept. of Computer Engg.

1.8. DESIGN
DIGITAL CONTRACT MANAGEMENT SYSTEM USING BLOCKCHAINS

Deployment diagram

A deployment diagram in the UML serves to model the physical deployment of ar-
tifacts on deployment target. Deployment diagram shows the allocation the artifacts
to nodes according to deployment defined between them. Deployment of an artifact
to a node is indicated by placing the artifact inside the node. Instances of nodes are
used in deployment diagram to indicate the multiplicity of nodes.

Figure 1.8: Deployment Diagram

MIT, Pune . 31 Dept. of Computer Engg.

1.8. DESIGN
DIGITAL CONTRACT MANAGEMENT SYSTEM USING BLOCKCHAINS

1.8.2 Sequence Diagram

UML sequence diagram model the flow of logic within your system in a visual
manner, enabling you to document and validate your logic, and are commonly used
for both analysis and design purpose.

Figure 1.9: Sequence Diagram

MIT, Pune . 32 Dept. of Computer Engg.

1.9. TIMEDIGITAL
ANALYSIS OF THE PROJECT
CONTRACT MANAGEMENT SYSTEM USING BLOCKCHAINS

1.9 TIME ANALYSIS OF THE PROJECT

Table 1.5: Time Analysis

From To Task Status

27–06–2015 30–06–2015 Group For- Done
mation and
finalization
01–07–2015 15–07–2015 Topic Search Done
16–07–2015 20–07–2015 Preliminary In- Done
formation Gath-
ering
21–07–2015 28–07–2015 Project Dic- Done
sussion with
Project Coordi-
nator and topic
finalization
01–08–2015 04–08–2015 Synopsis prepa- Done
ration and sub-
mission
25–08–2015 30–08–2015 Detailed Litera- Done
ture Survey
19–09–2015 24–09–2015 . .
25–09–2015 06–10–2015 Preparing In- Done
terim report
20–12–2015 02–01–2016 Language Study Done
03–01–2016 20–01–2016 Android and Done
Bluetooth LE
Study
21–01–2016 04–03–2016 Coding and Im- Done
plementation
05–03–2016 21–04–2016 Testing Done
13–04–2016 21–04–2016 Final Documen- Done
tation
25–04–2016 20–05–2016 Final Project Done
Report

MIT, Pune . 33 Dept. of Computer Engg.

Chapter 2

FUTURE ENHANCEMENT

In the future,we want to add the following as enhancement:

1. The favouritism can be extended to investments other than stocks.

2. The system can be updated more frequently by changing the updation time of
formation of a block in blockchain.

3. One issue is the proliferation of blockchains, and that with so many different
blockchains in existence, it could be easy to deploy the resources to launch a
51-percent attack on smaller chains.This can be cured in future.

34
Chapter 3

CONCLUSION

In ths project we are developing a decentralized ledger system using blockchain

technology. This system would help customers to fasten their transactions.
The system uses blockchain technology which is a distributed database that main-
tains a continuously growing list of data records that are hardened against tampering
and revision, even by operators of the data store’s nodes.
Thus, we successfully solved the problem of late transactions and also increased
the security of the system.
In future, more functionalities can be added to this system like extending it to
other domains and also to make the formation of block faster.

35
Bibliography

[1] Alireza Beikverdi, JooSeok Song,”Trend of Centralization in Bitcoin‘s Distributed

Network”, IEEE, 978-1-4799-8676-7/15 , SNPD 2015, June 1-3 2015

[2] Christian Decker, Roger Wattenhofert, ETH Zurich, ”Information Propagation in

the Bitcoin Network”, IEEE International Conference on Peer-to-Peer Computing,
2013

[3] Guy Zyskind, Oz Nathan, Tel-Aviv, Alex ‘Sandy‘ Pentland, ”Decentralizing Pri-
vacy: Using Blockchain to Protect Personal Data”, IEEE CS Security and Privacy
Workshops , 2015

[4] Daniel Kraft, NAWI Graz, ”Difficulty Control for Blockchain-Based Consensus
Systems”, Springer, March 2015

[5] Jay Kishigami, Shigeru Fujimura, Hiroki Watanabe, Atsushi Nakadaira, Akihiko
Akutsu, ”The Blockchain-based Digital Content Distribution System”, IEEE Fifth
International Conference on Big Data and Cloud Computing, 2015

36