How to talk to a company about blockchain: the IBM Hyperledger example — 2/2
In the first article of this mini-series we proposed a possible approach for the presentation of blockchain technology to companies.
Now let’s go down more in detail. There are several solutions to implement corporate blockchains. Hyperledger is an open source meta-project under the aegis of the Linux Foundation which aims to create interoperable cross-industry blockchain technologies. There are several variations including Sawtooth and Iroha, each with unique features and functionality. Another meta-project, not open source, for the development of business blockchain is R3 consortium Corda framework.
For this introduction I chose the IBM solution, which consists of two modules operating at different levels, Hyperledger Composer and Hyperledger Fabric.
Hyperledger Composer is a suite of high-level applications that makes it possible to design a business network; the terminology used is linked to the world of business, commerce and companies, making this first modeling phase simpler and faster.
It starts from the real structure of the business network that revolves around a company: it creates a model that is developed and tested, using API and REST architecture to dialogue with other business systems.
The Hyperledger Composer architecture provides four modules that will be integrated into a final file with the extension .bna. This file will be the input and model for Hyperledger Fabric, the real blockchain system.
The modules are:
- Model file, contains definitions and characteristics of participants, assets and transactions: The three key entities of a business network. It is the responsibility of the Business Analyst.
- Access Control, which defines the different types and levels of permissions for different participants.
- Script file, essentially contains the codes to perform the transactions. It is the responsibility of the developers.
- Query file, implements the different types of queries that can be made to read the data recorded in the blockchain.
Let’s take a simple example of designing a business network, just to clarify the ideas.
Let’s think about the chocolate production supply chain.
Participants in our network are:
- the farmers
- the importer
- the confectionery company
- the forwarder
Assets are anything that has value and can be transferred from one participant to another.
Obviously the cocoa beans are an asset, but there are others. An expedition is an asset (which can “embedded” cocoa beans); an asset is a contract between the importer and the confectionery company for the purchase and delivery of a batch of cocoa beans.
A “contract” asset can be identified by these parameters and be linked to these participants:
- contract id
- arrival date
- penalties for delays
- -> forwarder
- -> importer
- -> confectionery company
Other parameters may be present, such as the permissible temperature range during transport. The temperature is detected through the sensors during the journey, on ships, on trucks, etc.: These data are transmitted to the blockchain.If the limits established and written in the asset code are exceeded, the shipper will automatically pay a penalty.
A shipment can have these parameters and must be linked to the other asset, the contract.
- Shipping ID
- Shipping status
- -> contract
Unlike a public blockchain, not all participants have access to any information. Transporters can not access transaction data between importers and growers. And the forwarder are not authorized to view transaction data between importer and shippers.
Transactions, written in the Script file, contain instructions for managing and completing a transaction, payments and any ancillary clauses such as penalties. In practice, it is a series of “if it happens A execute B otherwise execute C”.
It is important to understand how the steps that are traditionally accompanied by a purchase and a shipment are managed automatically by blockchain in a single “environment” common to all the parties involved. This automation can be upgraded if you use IoT tools or anyway devices able to talk to each other through mobile, wi-fi, NFC, bluetooth.
We can also assume that there are other participants with supervisory or control functions. If the business network joins to fair trade rules, a supervisor may be authorized to view asset-contracts and transactions between growers and importer to check that there is adequate payment. A government agency could read the blockchain in the context of monitoring imports from particular countries. A quality consortium would verify the origin area of cocoa beans and transport conditions. All these participants could be blockchain nodes, although they probably would not be block endorser, as we’ll see shortly.
Let’s now analyze more technical aspects, competence of a hypothetical corporate IT sector.
Hyperledger Fabric is a framework that implements the basic functionality of the IBM blockchain, managing the communication between nodes, the consensus mechanism for the validation of transactions, the creation of blocks and so on.
We’ll explore architecture without going into too much detail.
The central system that implements the blockchain executes programs called chaincodes (similar to smart contracts), contains status data and executes transactions. External applications can, through API, connect to a node and perform essentially two operations: a simple one, read blockchain data through queries similar to the queries of a database and a more complex one, which involves a blockchain update or a transaction request .
Nodes are logical entities; on a server, more nodes can coexist. It is worth remembering that nodes are technically instances of the blockchain and the chaincode and reside in the servers or in the cloud of the (authorized) actors of the business network.
There are three types of nodes:
- Peers, nodes that maintain copy of the blockchain and can validate transactions (endorsers).
- Orderers, service nodes that deal with communications
- Clients, who send the proposals for transactions to be approved (by endorsers). The clients DO NOT own a copy of the blockchain.
In the above example, a endorsement peer could reside in the company’s servers or its South American branch, a client could be a grower who starts — perhaps from his smartphone — the payment procedure (transaction) by the importer (endorser) for a load of cocoa beans.
Often the peers nodes also use a traditional database, which preserves what is called “the state of the world”, ie the last data stored in the blockchain (in the immutable register): Who has at that time in charge an expedition, the last payment to a given grower, the last arrival of cocoa beans on the farm etc. The database represents a “photograph” at the present time of the transaction status; it is used to increase the efficiency and the fast recovery of the information but it is not — theoretically — indispensable because from the ledger (ledger) it is always possible to reconstruct the history of the transactions until the last confirmed (commit). Note that the blockchain also contains unapproved transactions.
An important feature of the Hyperledger Fabric architecture are the channels; since a company can be part of different business networks, it is necessary to use secure and independent channels in which information can flow. Each channel is also the protected space where credentials and authorizations are valid, limited to that business network. Think of channels as separate Whatsapp groups in which you can talk to some people but not others. A participant can also be an endorser in a business network, a client in another, a non-endorser in another.
Now let’s talk about managing transactions and creating chain blocks. Here you need a little patience and attention.
We resume our example of the confectionery company and its delicious chocolate. Imagine that the peer nodes are:
- The company headquarters
- The South American branch
- The importer
- The shipping company
- The farmers’ cooperative
The endorser nodes are the first three.
The clients are the growers. They could also be peers, in another model.
A farmer wants to sell a batch of cocoa beans. Send the transaction request to the network via smartphone; it does so by means of its reference peer, in this case that of the cooperative which “digitally” signs the request.
This is passed to other peers, in particular to endorsers who make sure that the request is “well formed”, that the client is authorized to carry out the transaction, that the digital signature is authentic, that it has not already been presented, etc. The endorsers send their response to the request through the network.
The client application collects the answers and checks that the approval rules have been met (for example that the headquarter node OR the branch node has approved the transaction). If an endorser does not approve the request or the client does not receive all the necessary vendorsments, the transaction proposal is abandoned and nothing is altered in the blockchain or in the state database. Otherwise, the customer sends transactions and approvals associated with the Ordering Service. This service application sorts and groups transactions into blocks and sends them to all peers in the network.
The peers control the block, ie the transactions and the associated answers and “tag” as valid or invalid; only at this point the peers add the block to their copy of the blockchain and update the database on the new “world state”.
The client will receive a notification that will notify him that the transaction has been approved (or not approved).
The procedure — defined “consensus” — may appear complicated but in fact follows the classic one, with start-up, control and verification phases, signature and approval; the difference is that everything happens automatically, in extremely fast times, with consistent data shared between the parties involved and stored in a safe and unalterable way. No emails, no paper, no phone/skype calls, no delay, no data discrepancy.
This wiki is collecting use cases of Hyperledger: in some cases there is detailed information, in others less. But then it’s a work in progress.
One last information on Hyperledger. For now, only in the United States, IBM has activated a preconfigured blockchain solution — based on IBM Cloud — with two available plans: the “Starter Plan” for development and testing, and the “Enterprise Plan” for production . The first, free at the moment, allows you to develop and test a solution with two organizations, two nodes and one channel. The second provides all the infrastructure to manage a blockchain in a real context. It’s an interesting solution because, once set up, you can invite the other participants in the business network to become nodes, connecting to their own instance in the IBM Cloud: this contains its own copy of the blockchain and the code needed for the typical functions a peer, in particular the endorsment of transactions and the committing of blocks.
Sources
This story is published in The Startup, Medium’s largest entrepreneurship publication followed by 320,131+ people.
Subscribe to receive our top stories here.
