Chapter 3. Setting the Stage with a Business Scenario

The first two chapters were focused on setting the stage and defining the landscape of a blockchain project. We now understand how the technology works within a business framework and how the various Hyperledger projects aim to solve the problem of time and trust.

With an understanding of the components that make up Hyperledger Fabric, we will now delve into application design and implementation considerations. The next few chapters will take you through the steps of creating your very own smart contract and then integrating it to an application.

In order to make these exercises relevant, we will leverage a business use case with its roots in some older civilizations: trading and letters of credit.

The chapter's objective will be to introduce the business concept of letter of credit, walk you through the sample scenario we selected, and conclude by setting up our development environment.

In this chapter, we will:

• Explore letters of credit
• Review...

Trading and letter of credit

Step back in history to a time when merchants traveled across continents to buy cloth in one country to sell in another country. As a Florentine wool merchant, you might make a journey to Amsterdam to buy fine wool in that newly formed city-state, whose port collected resources from the whole of Northern Europe and beyond. You could then transport the wool to Florence, where it could be sold to tailors making fine garments for their wealthy clients. We're talking about 1300 AD—a time when it was not safe to carry gold or other precious metals as a form of currency to buy and sell goods. What was necessary was a form of currency that worked across country boundaries, one that could be used in Amsterdam and Florence, or anywhere! Marco Polo had been to China and had seen how commerce was conducted in that thriving economy. At the heart of the successful Khan empire were advanced financial techniques that we would recognize today. Fiat currencies, paper money, promissory...

Business scenario and use case

International trade includes the kinds of situations that illustrate the inefficiencies and distrust in real-world processes that blockchains were designed to mitigate. So, we have selected an element of an import-export scenario with simplified versions of transactions carried out in the real world as our canonical use case for practical exercises in the next few chapters.

Overview

The scenario we will describe involves a simple transaction: the sale of goods from one party to another. This transaction is complicated by the fact that the buyer and the seller live in different countries, so there is no common trusted intermediary to ensure that the exporter gets the money he was promised and the importer gets the goods. Such trade arrangements in today's world rely on:

• Intermediaries that facilitate payments and physical transfer of goods
• Processes that have evolved over time to enable exporters and importers to hedge their bets and reduce the risks involved

Real...

Setting up the development environment

As you already know by now, an instance of a Hyperledger Fabric blockchain is referred to as a channel, which is a log of transactions linked to each other in a cryptographically secure manner. To design and run a blockchain application, the first step is to determine how many channels are required. For our trade application, we will use one channel, which will maintain the history of trades carried out among the different participants.

Note

A Fabric peer may belong to multiple channels, which from the application's perspective will be oblivious to each other, but which help a single peer run transactions in different applications on behalf of its owners (or clients). A channel may run multiple smart contracts, each of which may be an independent application or linked together in a multi-contract application. In this chapter, and in this book, we will walk the reader through the design of a single-channel, single-contract application for simplicity's...

Network components' configuration files

We have demonstrated how peers, orderers, and CAs can be configured in docker-compose YAML files. But such configurations are meant to override settings that have already been made by default in the components’ respective images. Though a detailed description of these configurations is beyond the scope of this book, we will list the respective files and mention how a user may make changes to them.

For a peer, a core.yaml file (https://github.com/hyperledger/fabric/blob/release-1.1/sampleconfig/core.yaml) contains all of the important runtime settings, including but not limited to addresses, port numbers, security and privacy, and the gossip protocol. You can create your own file and sync it to the container using a custom Dockerfile instead of the one that is used by the hyperledger/fabric-peer image by default. If you log in to a running peer container (let’s take the Exporter organization’s peer's container from the network we just launched):

docker...

Launching a sample trade network

So, now that we have all the configuration for our network, and also the channel artifacts and cryptographic material required to run it, all we need to do is start the network using the docker-compose command, as follows:

docker-compose -f docker-compose-e2e.yaml up

You can run this as a background process and redirect the standard output to a log file if you so choose. Otherwise, you will see the various containers starting up and logs from each displayed on the console.

Note

Note that on some OS configurations, setting up Fabric can be tricky. If you run into problems, consult the documentation. A detailed description of how to install a Fabric network and examples is provided at https://hyperledger-fabric.readthedocs.io/en/release-1.1/samples.html.

The network can be launched in the background using our trade.sh script as well; just run:

./trade.sh up

From a different terminal window, if you run docker ps -a, you will see something as follows:

CONTAINER ID  ...

Summary

In this chapter, we introduced the business use case that our follow-on chapters will leverage to create a context around the code we will write. We have also deployed our first Hyperledger Fabric network and have now transitioned from theory to practice. Well done!

The next chapters will take you through the development of a blockchain application from two perspectives: (1) Foundation API using chaincode and the Fabric SDK (2) Business network implementation using Hyperledger Composer.

Through these two perspectives, we hope to give you an understanding of the flexibility of the solution and the ability to leverage each tool in the right context. To get ready for the next chapter, you should now stop your network using ./trade.sh down.