Category Archives: Blockchain

Posted on Mon, Apr 22, 2019 @ 2:05 pm

In this series of blog posts, I will take you through the steps involved in the design, architecture, and implementation of a fully functional Enterprise Blockchain Application. I will do so by sharing content from various stages of developing a sample application for Loan Origination and Payment on Blockchain. If you follow through the end of this series, you will have a better understanding of the internal workings of a blockchain application.

We (OFS) are building this application in IBM Blockchain Platform 2.0 Beta. Please check out my previous post — Demystifying the Fabric Chaincode with an Example for better continuity.

In this post, I will cover the nitty-gritty of invoking a fabric chaincode from your application with code samples. This post will get fairly technical quickly.

Going back to the design and architecture of our sample application, you can see that any calls to the Hyperledger Fabric are delegated to Hyperledger Gateway Services:

The Hyperledger Gateway Service is composed of the following components:

Asynch Service Invocation Handler — a set of REST APIs that acts as a gateway for downstream fabric calls. The calls are asynchronous and return immediately after invocations.

Hyperledger (Fabric) Invoker — a core component that uses fabric SDK for chaincode invocations.

Event Hub — a component that listens for chaincode events and pushes the event details to subscribers.

Let us review these components in detail:

Async Service Invocation Handler

It is important to embrace async programming when developing a blockchain application, due to the numerous steps between building and proposing a transaction and adding a transaction to a blockchain.

Hyperledger (Fabric) Invoker

The job that is submitted to the executor service in the step above implements the downstream fabric calls. Conceptually the steps look like this:

Step #1 Build a Transaction Proposal request

Step #2 Send the Transaction Proposal to endorsing peers

This is a synchronous process, and the execution waits here.

Step #3 Collect and verify the Proposal responses

Step #4 Send the Proposal responses to the Orderer

Observe the CompletableFuture, then wait for the promises to resolve and take domain specific actions. Resolved promises mean successful submission to Orderer.

The fabric SDK takes care of the next two steps internally:

  • Step #5 Orderer broadcasts the blocks to all Leader peers
  • Step #6 Leader peer broadcasts the blocks to other peers in the group

Event Hub

Given the async nature of the transaction with the blockchain, we took an event-driven approach to react to the events emitted from chaincode. The events could be a new borrower application added to the blockchain, alender adding a new proposal to the blockchain, etc.

These events are baked into the chaincode and will be emitted when the related transactions are added to the blockchain.

Listening to these chaincode events from your client is fairly straightforward.

I hope this post helped you to get some insights into how to develop a fabric chaincode client using Java Fabric client SDK. Stay tuned for more.

About the Author

gan

Ganeshram Ramamurthy is ObjectFrontier’s technical director and heads technology for presales. For many years, Ganesh has been designing and developing enterprise applications across various domains. He has a keen interest in emerging technologies and is now spearheading blockchain initiatives at OFS.

 

Posted on Wed, Mar 27, 2019 @ 3:36 pm

In this series of blog posts, I will take you through the steps involved in the design, architecture, and implementation of a fully functional Enterprise Blockchain Application. I will do so by sharing content from various stages of developing a sample application for Loan Origination and Payment on Blockchain. If you follow through the end of this series, you will have a better understanding of the internal workings of the blockchain application.

We are building this application in IBM Blockchain Platform 2.0 Beta. Please check out my previous post — Design and Architecture of a Blockchain Application for better continuity.

Basics

Chaincode is the “smart contract” of Hyperledger Fabric. They encapsulate business logic and can be written in Go, Node.js, or Java. Yes, Fabric is polyglot and can provide a runtime sandbox for the chaincode to run in the previously mentioned programming languages.

A chaincode is typically used to read, write, and update the ledger of the given channel. The fabric chaincode library provides useful APIs (shim) for chaincodes to access and update its states, get access to transaction context, and also call other chaincodes. I will walk you through these with pseudocode of the chaincode we built for our sample application.

A chaincode that stores all loan requests

In our sample application, loanrequest.go is a simple chaincode that stores the loan applications of all applicants by applicant ID and provides functions to manage the lifecycle of those loan request. The state stored in the ledger is actually a key-value pair with the key being the combination of applicant ID and loan request ID, the value will be the details of the specific loan request. Let me breakdown the chaincode into smaller units for easy understanding:

Imports

import (

“fmt”

“bytes”

“encoding/json”

“github.com/hyperledger/fabric/core/chaincode/shim”

pb “github.com/hyperledger/fabric/protos/peer”

)

Pay attention to “github.com/hyperledger/fabric/core/chaincode/shim” because you will need this to do pretty much anything with the ledger.

Chaincode interface

All chaincodes must implement “Chaincode” interface. This interface provides two key functions, Init and Invoke.

Init will be called once when you instantiate the chaincode or upgrade a chaincode. Use this to initialize or migrate a state.
Invoke will be called to update or query the ledger — Invoke is the entry point to your chaincode from fabric client SDK.

 

// The chaincode that manages the lifecycle of the loans by applicants

type LoanRequest struct {}

 

//Implementaion of Chaincode Interface.

 

//We are not doing much in this function

func(t *LoanRequest) Init(stub shim.ChaincodeStubInterface) pb.Response {

 

   return shim.Success(nil)

}

 

// Invoke – Our entry point for Invocations

func(t *LoanRequest) Invoke(stub shim.ChaincodeStubInterface) pb.Response {

 

   function, args: = stub.GetFunctionAndParameters()

 

   // Handle different functions

   if

   function == “newLoanRequest” {

 

       return t.publishNewLoanRequest(stub, args)

   } else if

   function == “updateRequestStatus” {

 

       return t.updateLoanRequest(stub, args)

   } else if

   function == “listRequestsByApplicant” {

 

       return t.getAllLoanRequests(stub, args)

   }

   // No matching function received

   return shim.Error(“Received unknown invoke function name – ‘” + function +”‘”)

}

ChaincodeStubInterface.PutState

ChaincodeStubInterface provides useful functions to query and update the states in the ledger and to invoke other chaincodes. In our case, we will use PutState to store the new loan request onto the ledger in the default channel (by installing and instantiating this chaincode in the default channel) and hence making it available for all the parties in the network.

 

func(t * LoanRequest) publishNewLoanRequest(stub shim.ChaincodeStubInterface, args[] string) pb.Response {

 

   var requestId string

   var err error

 

   //Assignments from args

   requestId = args[0] //State Key

   loanrequestJson, _: = json.Marshal(args[1]) //State Value

   err = stub.PutState(requestId, [] byte(string(loanJson))) //Initiate the Tx

 

   if err != nil {

       return shim.Error(err.Error())

   }

 

   //Event to emit after Tx is commited

   stub.SetEvent(“NewLoanRequestRecived”, [] byte(string(loanId)));

 

   return shim.Success(nil)

}

As you can see the ledger stores a simple key-value pair with the key being request ID mapped to a JSON representing the loan request:

{

 “applicant”: {

   “name”: “string”,

   “gender”: “string”,

   “age”: 0,

   “ssn”: 0,

   “annualIncome”: 0

 },

 “loan”: {

   “amount”: 0,

   “propertyId”: 0,

   “propertyType”: “string”,

   “address”: “string”

 }

}

Pay attention to the stub.SetEvent because this is an instruction for the chaincode to emit an event when the transaction (PutState) is committed. This is the event our Event hub will listen and react to.

Make sure you have only one event per transaction.

ChaincodeStubInterface.GetQueryResult

Use GetQueryResult to query your ledger. You can use “selector” to query the underlying CouchDB ledger like in the sample below:

 

func (t *LoanRequest) getAllLoanRequests(stub shim.ChaincodeStubInterface, args []string) pb.Response {

 

var err error

var query string

query = args[0]

queryString := “{\”selector\”:”+query+”}”

applications, err := stub.GetQueryResult(queryString)

if err != nil {

return shim.Error(err.Error())

}

defer applications.Close()

 

// buffer is a JSON array containing QueryResults

var buffer bytes.Buffer

buffer.WriteString(“[“)

 

existingApplication := false

for applications.HasNext() {

queryResponse, err := applications.Next()

if err != nil {

return shim.Error(err.Error())

}

// Add a comma before array members, suppress it for the first array member

if existingApplication == true {

buffer.WriteString(“,”)

}

buffer.WriteString(string(queryResponse.Value))

existingApplication = true

}

buffer.WriteString(“]”)

stub.SetEvent(“GetLoan”, buffer.Bytes());

return shim.Success(buffer.Bytes())

}

 

In conclusion, you can write a simple chaincode using the shim interfaces Chaincode and ChaincodeStubInterface.

 

I hope you found this short post useful. The next post in the series will be on the Java Fabric client SDK, showing how the chaincode functions can be invoked, integrating your enterprise applications to the blockchain behind the scenes. Hang tight—you are only a few steps away from fully understanding the internals of a fully functional blockchain application.

References

Package shim

Package shim provides APIs for the chaincode to access its state variables, transaction context and call other…

godoc.org

Chaincode for Developers – hyperledger-fabricdocs master documentation

whose methods are called in response to received transactions. In particular, the method is called when a chaincode… hyperledger-fabric.readthedocs.io

About the Author

gan

Ganeshram Ramamurthy is ObjectFrontier’s technical director and heads technology for presales. For many years, Ganesh has been designing and developing enterprise applications across various domains. He has a keen interest in emerging technologies and is now spearheading blockchain initiatives at OFS.

 

Posted on Wed, Mar 20, 2019 @ 11:20 am

In this series of blog posts, I will take you through the steps involved in the design, architecture, and implementation of a fully functional Enterprise Blockchain Application. I will do that by sharing content from various stages of developing a sample application we (OFS) built for Loan Origination and Payment on Blockchain. If you follow through the end of this series, you will have a better understanding of the internal workings of a blockchain application.

We are building this application in IBM Blockchain Platform 2.0 Beta. Please check out my previous post — IBM Blockchain Platform 2.0 Beta: Run your Blockchain N/W in 10 Simple Steps for better continuity.

Objective

The objective is to develop a Decentralized Application that explores potential business benefits of using blockchain like

  • Improved process efficiency
  • Economy of scale
  • Privacy when you need it
  • Transparency and trust
  • Decentralized data with a logically centralized view
  • Recording of payments onto a blockchain

Use case and Actors

The use case we picked up to meet our objectives is a Loan Origination and Payment Application. The actual implementation of the use case doesn’t cover all intricacies and regulatory aspects of the loan origination and payments process but will be a good indicator of the design aspects to consider while building a DApp on the blockchain. The actors in the app are

  1. The Credit Reporting Agency — publishes the credit report of the citizens of demo universe to the Blockchain network. Controls access to the reports through smart contracts.
  2. The Property Title Search Organization — publishes the title report of the properties in the demo universe to the Blockchain N/W. Controls access to the reports through smart contracts.
  3. The Borrower (Applicant) — applies for a loan → receives proposals of various T&C from lenders → obtains the loan → makes the monthly payment, all on the blockchain.
  4. Lender 1 — fully utilizes all that blockchain has to offer, hence the fully automated business process behind the proposal response to the applicant.
  5. Lender 2 — still follows some traditional business process, slowly embracing blockchain.
  6. Consortium — facilitates onboarding organizations and establishes the governing principles of the business network.

Blockchain Business Network

 

The Blockchain business network of the application looks like this:

Use Case Flow

Animated use case flow

Technical Design and Architecture

IBM Blockchain Platform Business Network Architecture

  • Every organization in the network has a CA and a peer node.
  • A private channel is established between the consortium orchestrator and lenders to securely share proposals, terms, and conditions of the loan with the applicant.
  • The chaincode to create and process the loans will be deployed to the peers of Lender 1, Lender 2, and the consortium orchestrator. We will review the chaincode in detail in another post.

Application Architecture

The design of the Blockchain network is just one piece of the puzzle. Application design and architecture is equally important. Consider the following as you design your application:

  • Although IBM Blockchain Platform with Hyperledger Fabric at its heart scales well when compared to the public blockchain platforms, it is not a transactional database, so don’t expect throughputs like traditional centralized databases have.
  • Use the blockchain for what it has to offer — trust, transparency, and immutability. Decide what you store in your blockchain based on that.
  • Embrace asynchronous event-driven programming — the blockchain nodes are only eventually consistent. The consensus process is not instantaneous.
  • The data in the blockchain is secured by design through encryption and various governing principles of the network, but the security stops at the blockchain network level. You should still address the application security with your design.
  • Think about GDPR-like regulations before you store personally identifiable information onto the blockchain.

Design

We followed a modular microservices architecture. The complexity of interaction with the blockchain itself is abstracted out to a generic component that knows how to invoke chaincode to read/write data from/to blockchain. This helps to keep the other services lightweight and flexible.

Internal components of the architecture

As you can see we are expanding the IBP network to include a node running in AWS, showing the multi-cloud ability of IBM Blockchain Platform.

Data Flow

  • The microservices expose REST APIs for the presentation layer to consume.
  • The services delegate calls to the Hyperledger Gateway for blockchain invocations.
  • The blockchain calls are asynchronous. Once the transactions are added to the blockchain the Event Hub pushes the signal to all interested subscribers through a callback endpoint.
  • We use WebSockets for the presentation layer to react to the events from the Event hub.

Data flow diagram with synchronous (red) and asynchronous (black) calls

Service API Definitions

Borrower (Applicant) Services

Lender Services

Partner Services

Asynch Blockchain Invoker

Event Hub Services

Check out our swagger hub documentation for the APIs

I hope you’ve been able follow up until now. We will catch up on the design and development of the chaincode in my next post.

Posted on Tue, Mar 19, 2019 @ 9:42 am

Good blockchain ideas don’t take off because of the most critical blockchain adoption challenge i.e bringing the blockchain business network together. IBM is leading the way in solving this challenge by bringing well-established enterprises and budding entrepreneurs together trying to build a minimum viable ecosystem needed for blockchain solutions. IBM Blockchain platform is the foundation on which these business networks are built on.

The N/W we will build in this guide

Powered by Hyperledger, IBM Blockchain Platform with its value add tools greatly ease the technicalities in establishing and operationalizing your blockchain network.

IBM Blockchain platform Technical Brief (source)

This post assumes some understanding of Blockchain and Hyperledger Fabric. Please listen to this webinar that OFS co-hosted with IBM Introducing blockchain and IBM Blockchain Platform with a demo

IBM Blockchain Platform 2.0 Beta

Early February’19 IBM unveiled the IBM Blockchain Platform 2.0 for free Beta. This release packages the following powerful features

  1. Greater deployment flexibility backed by Kubernetes cluster that you manage
  2. Multi-cloud blockchain network bringing true decentralization in where you run your nodes
  3. Dev tools integration with VS Code extension

In this post, we will see how to quickly set up a Blockchain network with two organizations in 10 simple steps.

What are we setting up?

Blockchain N/W model

If you prefer a video walkthrough of the entire setup process, please listen to this — takes 30 mins. In fact, I recommend you to do that. The remainder of this post is the abstraction of the video content. I am linking the steps to the video so that you can jump to sections of interest

Step 1: Launch your own Blockchain Instance

After you log in to IBM cloud, Blockchain Platform 2.0 will be available in the database section — start there.

Blockchain Platform 2.0

following the wizard should land you here

IBM Blockchain Platform 2.0 Console

Step 2: Create a Certificate Authority

A certificate authority is a mandatory component of your IBP network. You will need a certificate authority per MSP(Organization in the network).

Add a CA to be used by your MSP

Register users

Make sure you register two types of identities when you create the certificate authority

1.A user of type “peer” whose certificates your peers will use to communicate

2.A user of type “client” the certificate that will be used for administration

Step 3: Setup MSP

MSPs are the organizations in the network. Register your organizations and choose the certificate authority.

The organization admin should be the identity that you registered of type “client”. Enroll the identity.

Set up MSP

Enrolled ids will show up in the wallet

Pay attention to the fact that the Wallet here is ephemeral so you have to re-enroll your identities if don’t see them here, so take a back of the keys.

Enrolled Identities in Wallet

Step 4: Add Peers

Add peers and associate identity

Use the account of the type “peer” for Peer enroll id.Use CA admin for TLS.Use the account of type “client” when asked to associate identity

Peer detail view

Step 5: Add Orderer

Orderer is a key service acting as an orchestrator of the network broadcasting transactions between various peers in the network.

The configuration of the orderer is similar to that of peer configuration the orderer is usually one per organization, however, one has the flexibility to create more than one orderer when necessary.

Step 6: Create your Consortium

A consortium is your business network. You should attach your consortium to the orderer

Establish a network of organisations

Step 7: Set up a channel

Channels are created leveraging the foundational elements we established so far, channels are really a subnet of communication between two or more specific network members.

Create a channel

Please note that the newly created channel will not be listed until a peer is added to the channeleven if it is successfully added.

Step 8: Add Peers to Channel

Launch your peer and join a channel

You should know the name of the channel to add your peer to the channel

The Genesis Block

Step 9: Install and Instantiate Chaincode

Once the channel is established you can deploy smart contracts to the channel. Smart contracts are chain codes which are usually written in Javascript or GoLang

Install your Chaincode
The type of package accepted by the console is cds. The VScode plugin for IBM blockchain makes is very easy to create a cds package

Instantiate smart contract

Step 10: Your Blockchain network is ready. Rock On!!!

Up on successful installation of the smart contract, you can instantiate them. With that step, your very own IBP v2 Network is ready for consumption.

Rock On!!!

Kubernetes Dashboard

Kubernetes Pods Deployed for our N/W

Hope you found this guide helpful. Please share your comments. Thank you.

Disclaimer: This post is not intended to replace any official documentation from IBM for IBM Blockchain Platform. Also, note that the IBM Blockchain platform 2.0 is in Beta at the time of preparing this documentation, instructions might change as the platform progreses to GA

About the Author

gan

Ganeshram Ramamurthy is ObjectFrontier’s technical director and heads technology for presales. For many years, Ganesh has been designing and developing enterprise applications across various domains. He has a keen interest in emerging technologies and is now spearheading blockchain initiatives at OFS.

 

 

Posted on Thu, Oct 12, 2017 @ 10:51 am

OFS Prototypes and Accelerators in Blockchain

To show you blockchain in action, I would like to share several of the prototypes and accelerators OFS just built in blockchain.

Please note that the use cases discussed below do not address all the regulatory concerns required in their respective fields. Practical applications of blockchain are still evolving and, in fact, it is possible that blockchain will do away with some of these regulatory concerns. We think this is what makes blockchain applications even more interesting. Having said that, the objective of the proofs of concepts given below is to demonstrate the disruptive potential of blockchain and the skills OFS has developed in-house to develop and deploy them.

#1 Tokenization of Automobiles Enabling Title and Lien Processing in Blockchain 

“Tokenization” is the process of representing the right to a real-world asset as a digital token in a blockchain. A tangible asset like an automobile, which over its lifetime could have many owners, titles, liens, and leases, is a perfect candidate for tokenization.

Automobiles as a Smart Contract

A real-world automobile will be represented as a smart contract on blockchain. When such a smart contract is deployed it gets a unique ID (address) and the functions (contractual terms) of the contract become immutable. The smart contract will initially have all unique and identifiable attributes required, such as a VIN number set during deployment, to uniquely identify the vehicle.

5

Smart Titles – Record of Ownership

A title is an instrument of ownership. There are a lot of administrative efforts involved in issuing, transferring, and maintaining titles. From the consumer point of view, it is something that should be kept safe. There are a lot of contractual terms regarding when a title should be transferred from a lien holder to an owner, and from a previous owner to a new owner, etc.

At the end of the day, a title is just a piece of paper and all the contractual processes around this paper are manual and time consuming. With blockchain, these paper titles can be represented as digital smart contracts.

4

Representation of titles as smart contracts makes them ‘smart’ titles with self-executing functions defining the contractual terms. For example, the transfer of ownership can be programmed in the contract according to specific conditions, such as having the outstanding loan amount paid in full. Even the payments can be processed through these smart contracts. Note that these contracts are immutable (tamper-proof), self-executing and always available.

The functions above can be implemented through traditional applications without blockchain or smart contracts, but also without disintermediation, immutability and transparency.

In the future, as the blockchain technology matures, there is so much potential for these smart contracts to be used to control the operational aspects of an automobile. For example, the contracts can be used to stop a loan defaulter from starting a vehicle until they become current in their payments.

Please note the same use case can be repurposed to fit any kind of asset that can be tokenized. Land registration is another good example.

#2 Mortgage Processing – Blockchain in Business Process Improvement

Mortgage processing has some inherent inefficiencies with its many handoffs, exchanges of value, third-party certifications and built-in delays.

A PwC report from 2016 has this to say:

“Having a third-party intermediary involved in a mortgage transaction can cost as much as 1% to 2% of a property’s value. Blockchain could reduce or eliminate the need for a third-party intermediary in the mortgage process and instead allow two parties to interact directly instead.”

Mortgage processing has many stages like origination, fulfillment, settlement, servicing, and secondary markets with many document handoffs and transfers happening between different parties, organizations, and departments, making mortgage processing a very good candidate for the smart contracts and distributed ledger aspects of blockchain. The applications are not just limited to processing and closing, but also in secondary markets for mortgage securitization.
We are developing a consumer centric mortgage origination proof of concept. Instead of working with a traditional mortgage broker or bank, the philosophy here is to allow a borrower to register the intent to borrow and submit necessary documents in a blockchain marketplace for mortgages. The lenders who have access to the blockchain review the application and respond with competing offers. Technically, blockchain is inefficient to store documents, so we propose using IPFS (https://ipfs.io/) for document storage. We will talk in more detail about IPFS in forthcoming blogs.

The proof of concept shall be expanded to include inter- and intra-organization workflows.

Blockchain-Based Mortgage Marketplace

 

2

#3 ALT Coin Payment Processing Gateway Accelerator

As cryptocurrency gains more acceptance in the market today, there is an increasing number of customers who wish to accept cryptocurrency as a form of payment. In the meantime, there is an explosion of altcoins in the market. To start accepting cryptocurrencies, existing payment processing systems should be linked to cryptocurrency exchanges to ensure users can pay with these alternate currencies. There are multiple cryptocurrency exchanges, each with its own pros and cons regarding time taken for payment processing, transaction fees, etc.

We are developing a pluggable accelerator – an API wrapper for leading exchanges – that can be plugged into your current payment processing gateway. This API wrapper will extend your gateway to start accepting cryptocurrencies.

1

Blockchain, with its smart contracts and the decentralized nature, has greater potential to disrupt any domain and its conventional applications. Even though it will take time for this technology to mature for enterprise applications, an increasing number of organizations and governments around the world are investing time and resources in developing prototypes and proof-of-concept applications with blockchain. There is great interest in how they can make better use of this technology.

Think of the saying, “Today’s fiction is tomorrow’s reality.” Blockchain is already a reality, and that tomorrow is today.

Are you currently exploring the possibility of implementing blockchain technology in your organization? The OFS tech team would love to show you a demo of our accelerators and prototypes and exchange ideas on how you can start working with blockchain technologies. Contact us here.

About the Author

gan

Ganeshram Ramamurthy is ObjectFrontier’s technical director and heads technology for presales. For many years, Ganesh has been designing and developing enterprise applications across various domains. He has a keen interest in emerging technologies and is now spearheading blockchain initiatives at OFS.

 

 

Posted on Thu, Oct 5, 2017 @ 1:58 pm

Hardly a day passes by without someone mentioning Bitcoin, especially when the currency’s market value has reached thousands of dollars. This grabs our attention immediately. At ObjectFrontier, we are interested in Bitcoin not just for its market value, but because of the technology that makes it tick, makes it secure, and makes it successful: blockchain.

 Thanks to the likes of Vitalik Buterin, blockchain – the same engine behind the success of Bitcoin – is now available for enterprises to use and build applications on it.

 This is the first post in a two-part series on blockchain. Here, I’d like to show a brief technical view of what blockchain is and how your company can use it. In Part 2 of this series, you’ll get to learn about some of the prototypes we are building and see the opportunities blockchain enables when it’s in action.

 Please note that this post might get fairly technical, so you will need some prior understanding of databases, distributed storage, peer-to-peer (P2P) networks and computer programming.

Applications of Blockchain

As explained in Bretton Woods’ 2015 white paper here , blockchain has far-reaching applications in financial services, healthcare, retail, media, personal investment and governance. To name a few, some applications are already built for the following:

  • Clearing and settlement
  • Payments
  • Property ownership
  • Digital identity
  • Voting
  • Insurance mortgage lending
  • Release of health records
  • Title and lien holding
  • Crowd sourcing

The Blockchain

It is an undeniable fact that Bitcoin revolutionized the field of cryptocurrencies. As mentioned above, the key to Bitcoin’s success compared to many of its predecessors is its underlying technology: the blockchain. Blockchain is a distributed transaction ledger replicated in all participating nodes in the blockchain network, with no central authority controlling it.

Technically, a blockchain is a decentralized database with random independent nodes participating in the network. All the nodes in this network will have the same version of blockchain, and hence the ledger is distributed and one single version of blockchain is replicated across all the nodes. As the name indicates, a “blockchain” is a chain of blocks. The blocks contain transactions committed to the blockchain.

The state of the blockchain changes based on the transactions added to the blocks that make up the chain. Any node in the network can add a block to a blockchain. However, since a blockchain is disintermediated, with no central authority controlling what transactions make up a block or which block is added to the chain, we need a consensus between the competing nodes trying to add the block. A consensus algorithm called Proof of Work (PoW) achieves this unanimity. PoW is the consensus algorithm currently employed by the likes of Bitcoin and Ethereum. Check out this Ethereum white paper for more details.

Beyond cryptocurrencies, blockchain technology—with its decentralized, disintermediary nature—has immense potential to open up new avenues and markets for enterprises willing to build revolutionary applications on blockchain, giving them an edge over others. Private, permissioned blockchain is especially attractive to many enterprises in financial services and healthcare. It is encouraging to see increased acceptance of blockchain with states like Vermont passing legislations honoring transactions on blockchain.

Programmability of Blockchain

To understand the programmability of blockchain, we have to take a good look at how Bitcoin works. When Alice transfers a few bitcoins to Bob, this is considered a transaction in Bitcoin’s blockchain.

As shown below, a Bitcoin transaction has two sections: Input and Output.


Input:

Previous tx: f5d8ee39a430901c91a5917b9f2dc19d6d1a0e9cea205b009ca73dd04470b9a6

Index: 0

scriptSig: 304502206e21798a42fae0e854281abd38bacd1aeed3ee3738d9e1446618c4571d10

90db022100e2ac980643b0b82c0e88ffdfec6b64e3e6ba35e7ba5fdd7d5d6cc8d25c6b241501


Output:

Value: 5000000000

scriptPubKey: OP_DUP OP_HASH160 404371705fa9bd789a2fcd52d2c580b65d35549d

OP_EQUALVERIFY OP_CHECKSIG

Without getting into the fine-grained details, the scriptSig and sciptPubKey are actually scripts that define the business logic for this transaction. When executed, this script evaluates the input against defined conditions and ends up changing the state of blockchain if all conditions are met. This ability to define logic in a transaction is what makes blockchain programmable.

Scripting in Bitcoin cannot be expanded much beyond cryptocurrencies, because it is not developed with such applications in mind. Technically, the scripting language in Bitcoin is not Turing complete. This limitation in Bitcoin is overcome by the leading blockchain platforms like Ethereum and Hyperledger, making blockchain a viable option to develop and deploy applications for enterprises.

These platforms also focus on privacy, scalability and access control, making them ready for building and deploying enterprise applications.

Blockchain Platforms

There are many blockchain platforms available in the market today that enable the use of a “smart contract,” which is a code that facilitates the secure execution of contracts between two parties on blockchain. Applications that use smart contracts are called “Decentralized Applications (DAPPS).”

Here are the two leading blockchain platforms:

Both of these platforms enjoy good community contribution, industry adoption and enterprise backing.

Ethereum, which is backed by Ethereum Foundation, is an open software platform based on blockchain technology that can be used to build and deploy smart contracts for decentralized applications. Smart contracts are programs that are deployed to blockchain and run on the Ethereum Virtual Machine (EVM) in an Ethereum network.

Smart contracts are immutable once deployed, and because of blockchain’s decentralized nature, they will always be available for invocations. Invocations of smart contracts are transactions that make up the blocks in blockchain. These transactions can contain data for functions called on smart contracts. Smart contracts have their own storage that can be used to register state changes and can return output of the function invocations. One contract can call other contracts and create more contracts in run time. Ethereum smart contracts are developed using a contract-oriented language called Solidity.

DAPPS are traditional web applications that invoke and use smart contracts behind the scenes. Ethereum is primarily a public blockchain that can be run as a private blockchain.

Hyperledger Fabric backed by Linux Foundation is a platform for running a private blockchain (a.k.a. permission blockchains). Permissioned blockchains are similar in all aspects to the public blockchain except for the following:

  • They are private. These blockchains are accessible only by approved parties.
  • They have pluggable consensus. Participating organizations can decide on the consensus protocol.
  • They allow for specific permissions. There is fine-grained control over who can read and initiate transactions in these blockchains.

The characteristics of a private blockchain sometimes make Hyperledger Fabric an attractive option for the enterprises. You can use the factors above to determine what suits your own use case best.

In general, Hyperledger Fabric works with the same principles as Ethereum with some differences in terminologies. For example, smart contracts are referred to as chaincode and the choice of language for development of contract is Go.

Both the platforms are equally powerful and capable of building revolutionary applications.

To see what blockchain looks like in action through several use cases, check out Part 2 of this series here.

About the Author

ganGaneshram Ramamurthy is ObjectFrontier’s technical director and heads technology for presales. For many years, Ganesh has been designing and developing enterprise applications across various domains. He has a keen interest in emerging technologies and is now spearheading blockchain initiatives at OFS.