Netaji Subhas Institute of Technology

Practical Training Report

COE-409

Submitted By:
Nitin Kumar
297/CO/14
COE-II

Nitin Kumar (297CO14)

 ACKNOWLEDGEMENT

It is my great pleasure to present this practical training report in partial

fulfillment of the requirements for the award of degree of B.E. in
Computer Engineering. Summer internship forms an indispensable part
of the B.E. programme and it is a golden opportunity to learn, grow and
gain valuable industry experience. I would like to take this opportunity
to thank the Training and Placement Cell, NSIT for providing me with
the opportunity to intern at Nucleus Software Exports Ltd.

I would like to express my sincere gratitude to Mr. Gaurav Marwaha

(my mentor) and all my team members for their extensive support, help
and guidance throughout my internship period, in spite of their busy
schedules.

NITIN KUMAR (297CO14)

1
 Contents

About the company ........................................................................................................ 3

Project Overview: ........................................................................................................... 4
BLOCKCHAIN INTRODUCTION: ........................................................................................ 5
 A short History of Transacting Money:........................................................................ 5
 What’s under the blockchain hood?............................................................................. 6
CONSENSUS IN BLOCKCHAIN AND HOW TO IMPLEMENT IT: ........................................... 10
Smart contract:.............................................................................................................. 13
APPLICABILITY TO LOANS/ LENDING: ............................................................................ 16
FRAMEWORK/ LANGUAGES USED: ................................................................................ 17
BIBLIOGRAPHY ............................................................................................................. 21
Result: .......................................................................................................................... 22

NITIN KUMAR (297CO14)

2
Nucleus Software Exports Limited

Nucleus Software Exports Limited is an Indian global IT products and

solutions company serving the Banking and Financial Services sector for
the past 27 years. It offers wide range of IT solutions and consultancy
services serving a variety of sectors of the banking industry. It is listed
on the Bombay Stock Exchange and the National Stock Exchange of
India.
The company has its headquarters in Noida, Uttar Pradesh, India, and it
operates in more than 50 countries.

NITIN KUMAR (297CO14)

3
 Project Overview:

Integration of Blockchain technology to Nucleus software

products for identity management, smart contracts and asset
verification.

NITIN KUMAR (297CO14)

4
 BLOCKCHAIN
INTRODUCTION:
 A short History of Transacting
Money:
Historically, when it comes to transacting money or anything of value,
people and businesses have relied heavily on intermediaries like banks
and governments to ensure trust and certainty. Middlemen perform a
range of important tasks that help build trust into the transactional
process like authentication & record keeping.

The need for intermediaries is especially acute when making a digital

transaction. Because digital assets like money, stocks & intellectual
property, are essentially files, they are incredibly easy to reproduce. This
creates what’s known as the double spending problem (the act of
spending the same unit of value more than once) which until now has
prevented the peer to peer transfer of digital assets.

But what if there was a way of conducting digital transactions without a

third party intermediary? Well, a new technology exists today that makes
this possible.

NITIN KUMAR (297CO14)

5
  What’s under the blockchain
hood?
Simply put, a blockchain is a type of distributed ledger or decentralized
database that keeps continuously updated digital records of who owns
what. Rather than having a central administrator like a traditional
database, (think banks, governments & accountants), a distributed
ledger has a network of replicated databases, synchronized via the
internet and visible to anyone within the network. Blockchain networks
can be private with restricted membership similar to an intranet, or
public, like the Internet, accessible to any person in the world.

When a digital transaction is carried out, it is grouped together in a

cryptographically protected block. Miners (members in the network with
high levels of computing power) then compete to validate the
transactions by solving complex coded problems.

In order to add these blocks to the distributed ledger, the data needs to be
validated by 51% of all the computers within the network that have
access to the Blockchain. The validation is done via cryptography,
which means that a mathematical equation has to be solved. Solving the
mathematical equation is difficult and requires a lot of computing power.
However, once it is solved it is immediately clear that the answer is
correct. This can be compared to a crossword puzzle, which can be very
difficult to solve, but once completed you immediately know that it is
done correctly.

Once the validation is done, the Block will receive a timestamp and a so-
called hash. This hash is then used to create the next block in the chain.
If even one bit in the block changes, the hash will change completely
and as a result, all subsequent blocks in the chain will change. Such a
change has to be validated again by 51% of all the nodes in the network,
which will not happen because they don’t have an incentive to work on

NITIN KUMAR (297CO14)

6
‘old’ blocks in the chain. Not only that, the blockchain keeps on
growing, so you would require a tremendous amount of computing
power to achieve that, which is extremely expensive. So it is simply not
worth it to change any data. As a result, it is nearly impossible to change
data that has been recorded on the Blockchain.

The result is that peer-to-peer transactions become possible, without the

need for a centralised certifying authority, such as a bank, which usually
takes a small commission to carry out the work. If third parties are no
longer necessary and organisations or consumers can do transactions
peer-to-peer, which are also processed nearly instantly, that is a
paradigm shift and that’s why the Blockchain is so important.

NITIN KUMAR (297CO14)

7
NITIN KUMAR (297CO14)
8
NITIN KUMAR (297CO14)
9
CONSENSUS IN BLOCKCHAIN
AND HOW TO IMPLEMENT IT:
There are four main methods of finding consensus in a blockchain (and
all distributed systems, for that matter): the practical byzantine fault
tolerance algorithm (PBFT), the proof-of-work algorithm(PoW) ,the
proof-of-stake algorithm (PoS), and the delegated proof-of-stake
algorithm (DPoS).

The Practical Byzantine Fault Tolerance Algorithm (PBFT) was

designed as a solution to a problem presented in the form of an allegory:
NITIN KUMAR (297CO14)
10
Imagine that several divisions of the Byzantine army are camped outside
an enemy city, each division commanded by its own general. The
generals can communicate with one another only by messenger. After
observing the enemy, they must decide upon a common plan of action.
However, some of the generals may be traitors, trying to prevent the
loyal generals from reaching agreement. The generals must decide on
when to attack the city, but they need a strong majority of their army to
attack at the same time. The generals must have an algorithm to
guarantee that (a) all loyal generals decide upon the same plan of action,
and (b) a small number of traitors cannot cause the loyal generals to
adopt a bad plan. The loyal generals will all do what the algorithm says
they should, but the traitors may do anything they wish. The algorithm
must guarantee condition (a) regardless of what the traitors do. The
loyal generals should not only reach agreement, but should agree upon a
reasonable plan.

To clarify the allegory for our purposes: the ‘generals’ in the story are the
parties participating in the distributed network running the blockchain
(database) in question. The messengers they are sending back and forth
are the means of communication across the network on which the
blockchain is running. The collective goal of the “loyal generals” is to
decide whether or not to accept a piece of information submitted to the
blockchain (database) as valid or not. A valid piece of information would
be, in our allegory, a correct opportunity to decide in favor of attack.
Loyal generals, for their part, are faithful blockchain participants, who
are interested in ensuring the integrity of the blockchain (database) and
therefore ensuring that only correct information is accepted. The
treacherous generals, on the other hand, would be any party seeking to
falsify information on the blockchain (the database). Their potential
motives are myriad — it could be an individual seeking to spend a
BitCoin that she does not actually own or another person who wants to

NITIN KUMAR (297CO14)

11
get out of contractual obligations as outlined in a smart contract he
already signed and submitted.

Various computer scientists have outline a number of potential solutions

to the Byzantine generals problem from the allegory. The practical
byzantine fault tolerance algorithm (PBFT), which is used to establish
consensus in blockchain systems, is only one of those potential solutions.
Three examples of blockchains that rely on the PBFT for consensus are
Hyperledger, Stellar, and Ripple. Very roughly and without explaining
the whole algorithm (which would take a multiple page research paper),
what the PBFT does is as follows: Each ‘general’ maintains an internal
state (ongoing specific information or status). When a ‘general’ receives
a message, they use the message in conjunction with their internal state
to run a computation or operation. This computation in turn tells that
individual ‘general’ what to think about the message in question. Then,
after reaching his individual decision about the new message, that
‘general’ shares that decision with all the other ‘generals’ in the system.
A consensus decision is determined based on the total decisions
submitted by all generals.

NITIN KUMAR (297CO14)

12
 Smart contract:
Smart contract — is a piece of code which is stored in the blockchain
network (on each participant database). It defines the conditions to which
all parties using contract agrees. So if required conditions are met certain
actions are executed.

As the smart contract is stored on every computer in the network, they all
must execute it and get to the same result. This way user can be sure, that
outcome is correct.

Let’s say you want to ship a pallet of goods to your friend Bob.

You trust Bob, but you don’t trust trucker Tom, who will carry your
pallet. On the other hand, Tom does not trust you as well, maybe you
won’t pay him?

Therefore, you have to sign an agreement with Tom that you will pay for
the shipment in a few days after delivery. Usually third party is involved
in this process, legal papers, contracts are scanned, printed, signed.

NITIN KUMAR (297CO14)

13
Can we simplify the process? Yes! We can do that with the help of smart
contracts. We could define those rules in code.

You make a payment for shipment to smart contract on a day of loading.

It holds payment till shipment delivery is confirmed by Bob. Then smart
contract releases the payment and money is transferred to Tom
automatically.

Let’s move a little bit forward. What if we would have a GPS tracker
attached to the pallet? Then we simply could eliminate Bob from this
process and just release the payment automatically, when the location
rule is met.

NITIN KUMAR (297CO14)

14
NITIN KUMAR (297CO14)
15
APPLICABILITY TO LOANS/
LENDING:
 Customer:
Customers are clearly immutable in the context of a single running
loan. Sometimes customers remain immutable across loans/
relationships.
 Asset/collateral:
The asset being procured or for which loan is taken and the
underlying collaterals sometimes shared with the bank as guarantee
remain immutable in the context of a loan.
 REPAYMENT SCHEDULE:
The schedule is not an immutable entity as it is subject the change
even within the contract term of a loan.
 LOAN CONTRACT:
The contract by nature is normally done for the entire term of the
loan and is immutable in that loan. Any change to the contract has
to be communicated to all parties.

NITIN KUMAR (297CO14)

16
FRAMEWORK/ LANGUAGES
USED:
Hyperledger Composer is an extensive, open development toolset and
framework to make developing blockchain applications easier. Our
primary goal is to accelerate time to value, and make it easier to
integrate your blockchain applications with the existing business
systems. You can use Composer to rapidly develop use cases and deploy
a blockchain solution in weeks rather than months. Composer allows
you to model your business network and integrate existing systems and
data with your blockchain applications.

NITIN KUMAR (297CO14)

17
Hyperledger Composer supports the existing Hyperledger Fabric
blockchain infrastructure and runtime, which supports pluggable
blockchain consensus protocols to ensure that transactions are validated
according to policy by the designated business network participants.

Everyday applications can consume the data from business networks,

providing end users with simple and controlled access points.
You can use Hyperledger Composer to quickly model your current
business network, containing your existing assets and the transactions
related to them. Assets are tangible or intangible goods, services, or
properties which are declared in the model file (.cto) along with
participants and transactions as shown in this figure.

NITIN KUMAR (297CO14)

18
Sample model file containing an asset, a transaction and a participant
As part of your business network model, you define the transactions
which can interact with assets. Business networks also include the
participants who interact with them, each of which can be associated
with a unique identity, across multiple business networks.
The JavaScript file (.js) contains the transaction processor functions
which are invoked by the external applications.

NITIN KUMAR (297CO14)

19
The access control list contains the rules that define the access level of
each participant to the resources. A sample acl file looks like this:

NITIN KUMAR (297CO14)

20
 BIBLIOGRAPHY

 https://en.wikipedia.org/wiki/Nucleus_Software_Exports
 https://www.thoughtworks.com/insights/blog/blockchain-under-
hood
 https://www.linkedin.com/pulse/consensus-mechanisms-used-
blockchain-ronald-chan/
 https://medium.com/blockchain-review/how-does-the-blockchain-
work-for-dummies-explained-simply-9f94d386e093
 https://www.coindesk.com/
 http://composer-playground.mybluemix.net/
 https://hyperledger.github.io/composer/tutorials/playground-
tutorial.html
 https://medium.com/startup-grind/gentle-intro-to-blockchain-and-
smart-contracts-part-1-3328afca62ab
 https://www.linkedin.com/pulse/what-blockchain-why-so-
important-mark-van-rijmenam/
 https://www.investopedia.com/terms/d/doublespending.asp
 https://en.wikipedia.org/wiki/Double-spending

NITIN KUMAR (297CO14)

21
 Result:
 Designed the blockchain network on hyperledger composer V1.
 Created assets, participants and transaction processor functions
to carry out various transactions between different banks (which
would act as participants).
 Converted the source code to a business network archive (.bna)
file.
 Deployed the .bna file on a cloud server.
 Exposed the blockchain network as a REST API within the
cloud server so that any external application could use it using
the cloud’s IP address.

NITIN KUMAR (297CO14)

22
 THANK YOU

NITIN KUMAR (297CO14)

23