Tag: Hyperledger Fabric

Blockchain-powered Smart Supply Chain Management -Auto Parts Business case study

The automotive supply chain is a highly complex and broad ecosystem with participants ranging from parts suppliers, manufacturers, sellers to aftermarket suppliers. All parts come with certain life expectancy, specific requirements and maintenance attributes. With thousands of spare parts, hundreds of parameters, and the number of manufactures distributed regionally or globally, the SCM team need to deal with a very large amount of data.

The two most common challenges are the need to keep inventories well-stocked but not overstocked, and the need to deal with the sheer amount of recalls. In addition, the industry is also facing a mirage of issues including tracking of parts, theft, counterfeit products, and data fraud.

Currently, centralized and siloed IT systems have been used to handle the issues but failed in many aspects. On the contrary, decentralized blockchain inherent features could offer perfect solutions to overcome the automotive parts supply chain issues.

  • All participants share a common data
  • Everyone has access to a single source of truth
  • Reducing intermediaries
  • Improved transparency
  • Trust is embedded in the system
  • Tamperproof due to its immutability

Blockchain technology can improve transparency across the supply chain and significantly reduces the cost and complexity of doing business with multiple parties. For automakers and suppliers, blockchain technology offers unique benefits starting with protecting their brands from counterfeit products to enhancing their brand experience by creating customer-centric business models.

Possible benefits of Blockchain usage in SCM

Identification and Tracking of Automotive Spare Parts

Counterfeit Protection -Verifying Authenticity and Origin

Counterfeit products are a significant issue for automotive manufacturers / suppliers and the counterfeit spare parts market is currently estimated at several billion dollars. Counterfeit spare parts are often of low quality and thus more likely to fail. This leads to dissatisfied customers and trust in the brand .

The Blockchain technology offers  significant advantages over existing solutions where spare parts can be uniquely identified and digitally represented. The digital identification of these parts can be shared transparently to multiple parties in the blockchain business network.

Mutual collaboration is facilitated within the parties knowing that sensitive business information remains confidential. Confidentiality is enforced through blockchain cryptographic methods, hence protect integrity of the data  not only from manipulators within the business network but also externally from attackers.

Spare parts service centers  can accurately verify the authenticity of  parts during replacement. The immutability of blockchain provides for a tamper-proof solution and offers a single source of truth.  This will enhance the  trust relationship between customers and  the manufacturer.

Protection of Aftermarket Business

The global aftermarket business was valued at over 800 billion USD in 2018  and expected to grow to over a trillion USD over the next 10 years. Over 50% of this market consists of the sale of vehicle spare parts and business is split across OEM (Original Equipment Manufacturer) and IAM (Independent Aftermarket) Suppliers.

As each product or part is uniquely represented on the blockchain, the technology can be applied to enforce business terms related to the exact production volume and timing. This level of enforcement can also be applied for manufacturers working with more than one supplier as part of their dual sourcing strategy.

Spare Parts Liability Resolution

In case a spare part needs to be replaced due to failure, liability needs to be established and this requires tracing the part back to the manufacturer. If parts are identified and digitally represented on the blockchain, it offers an accurate way to trace the origin. Liability is thus clearly established and is transparent to all parties in the blockchain. Any liability disputes can be resolved  much faster and resources can be focused on customer engagement.

Vehicle Recall Optimization

Many of the recalls involve product defects that are life-threatening and automakers are exposed to a huge liability. With blockchain technology , the car and the individually assembled parts can be uniquely represented on the blockchain. If automakers  can accurately identify  which defective parts were installed in which cars, then the scope of the recall can be precisely executed thus result in massive cost savings.

Optimizing the Supply Chain Process

Inbound Logistics and Smart Manufacturing

Efficient planning of production capacity requires the manufacturing plant to coordinate between multitier suppliers, 3rd party logistics and transportation companies. Tracking and tracing individual parts across the inbound supply chain is complex and error-prone. Accurate, real-time information is not available and information is spread across individual databases.

By using a distributed immutable blockchain ledger across all parties, an accurate view of the status, quantity and location of the individual parts can be established. This  can improve real-time logistics and plant production capacity.

Outbound Logistics Planning

The outbound supply chain in the automotive sector consists of a complex network of manufacturers, distributors, importers, and dealers. Like the inbound supply chain, participants in the outbound supply chain do not have a common data-sharing model.

Having a shared blockchain based system across the different participants will offer transparency and visibility. This will ensure faster transactions by lowering settlement periods.

Business Model Innovation

Car Personalization and Customer Engagement

The driver profile along with car customization preferences can be saved in a personal blockchain wallet. Shared or lease cars will authenticate the driver using the wallet and the car settings are personalized based on the driver profile. Automakers and mobility operators can thus create new business models focusing on individual preferences

Dynamic Pricing Models in Automotive Insurance and Leasing

A driver profile including miles covered, economical usage of vehicle and accident history is securely stored on the blockchain. Users share this data with providers offering insurance and leasing products based on their personal driving profile. The advantage that  blockchain technology brings here is that the driver profile and historic events are immutably stored on the blockchain providing a single source of truth.

Digital Car Wallet

Ownership history, maintenance, and repairs can be transparently, and verifiably stored in a blockchain-based car wallet. Ownership record and fair price assessment of second-hand cars can be quickly established and transferring ownership can be done faster.

As vehicles are uniquely identified on the blockchain, stolen cars can be easily tracked and traced. Lack of trust and business friction arising in the transfer of ownership is hugely reduced. If repairs and parts replacements are verifiably tracked on the blockchain, warranty claims will be transparent for all parties.

M2M  Transactions

Blockchain technology offers a unique way to automate transactions between machines and enable the future of M2M commerce. Cars in the future will be equipped with blockchain-based wallets and transactions with toll booths, park stations, and electric charging outlets will be automated without manual intervention.

The Solution-Hyperledger

Hyperledger is an open source effort created to advance cross-industry blockchain technologies hosted by The Linux Foundation. Hyperledger is a group of open source projects focused around cross-industry distributed ledger technologies. Hosted by The Linux Foundation, collaborators include industry leaders in technology, finance, banking, supply chain management, manufacturing, and IoT.

The Hyperledger project has been a collaboration of players from various industries and organizations in technology, finance, banking, supply chain management, manufacturing, IoT and more. Since its inception in December 2015, it has managed to enlist many prominent members that include IBM, Intel, NEC, Cisco, J.P Morgan, AMN AMRO, ANZ Bank, Wells Fargo, Accenture, SAP and more.

This image has an empty alt attribute; its file name is image.png
The Hyperledger Framework

Hyperledger Fabric

Hyperledger Fabric is the first blockchain project developed and hosted by the Linux Foundation. According to the Linux Foundation , it was Intended as a foundation for developing DLT applications or solutions with a modular architecture.

Hyperledger Fabric is an open-source enterprise-grade permissioned distributed ledger technology (DLT) platform, designed for use in developing enterprise applications. It features some key differentiating capabilities over other popular distributed ledger or blockchain platforms.

Hyperledger Fabric is a blockchain framework that runs smart contracts called chaincode, which are written in Go. You can create a private network with Hyperledger Fabric, limiting the peers that can connect to and participate in the network. This private network can be hosted on AWS or other web service provider such as Microsoft Azure , Oracle or IBM.

One special feature of  Hyperledger Fabric is that it allows components, such as consensus and membership services, to be plug-and-play. Besides that, Hyperledger Fabric uses container technology to host smart contracts called chaincode that comprises the application logic of the system.

The AWS Blockchain Template for Hyperledger Fabric creates an EC2 instance with Docker and launches a Hyperledger Fabric network using containers on that instance.

The network includes one order service and three organizations, each with one peer service. The template also launches a Hyperledger Explorer container, which allows you to browse blockchain data. A PostgreSQL server container is launched to support Hyperledger Explorer.

Channels are another unique feature of Hyperledger Fabric. They allow transactions to be private between two actors, while still being verified and committed to the blockchain.

Hyperledger Fabric Architecture

Hyperledger Fabric has a highly modular and configurable architecture. Therefore, enterprises can make use of its versatility to develop innovative business applications.  Besides that, it can be used to optimize the applications. Indeed, Hyperledger Fabric is well suited to develop a broad range of industry use cases including banking, finance, insurance, healthcare, human resources, supply chain and even digital music delivery.

Hyperledger Fabric is a permissioned blockchain network that provides ledger services to application clients and administrators. It allows multiple organizations to collaborate as a consortium to form the network.  The permissions to join the network are determined by a set of policies that are agreed to by the consortium when the network is configured.

Hyperledger Fabric Network

The Hyperledger Fabric network comprises the following components:

  • Ledger
  • Peers
  • Ordering service Chaincode (aka smart contract)
  • Channels
  • Membership service provider

The Hyperledger ecosystem also consists of the client applications that allow users to interact with the network.  Moreover, The Hyperledger Fabric application SDK provides a powerful API for developers to program applications to interact with the blockchain network on behalf of the users. 

Channels are data partitioning mechanisms that allow transaction visibility for stakeholders only. Each channel is an independent chain of transaction blocks containing only transactions for that channel.

The chaincode (Smart Contracts) encapsulates both the asset definitions and the business logic (or transactions) for modifying those assets. Transaction invocations result in changes to the ledger.

The ledger contains the current world state of the network and a chain of transaction invocations. A shared, permissioned ledger is an append-only system of records and serves as a single source of truth.

The network is the collection of data processing peers that form a blockchain network. The network is responsible for maintaining a consistently replicated ledger.

The ordering service is a collection of nodes that orders transactions into a block. The world state reflects the current data about all the assets in the network. This data is stored in a database for efficient access. Currently, supported databases are LevelDB and CouchDB.

The membership service provider (MSP) manages identity and permissioned access for clients and peers.

Channels partition the Fabric network in such a way that only the stakeholders can view the transactions. In this way, organizations can utilize the same network while maintaining separation between multiple blockchains.  The mechanism works by delegating transactions to different ledgers. Members of a channel can communicate and transact privately. Other members of the network cannot see the transactions on that channel.

Components of Hyperledger Network
Channels
SCM Hyperledger Platform on AWS

References

Hyperledger Fabric Architecture Part 2

In my article ” Hyperledger Fabric Architecture Part 1“,  you have learned about the client applications, endorsing peers and committing peers as well as well as the ordering service. We have also discussed the transaction workflow and how consensus is reached. In this article, I shall explain the channels and membership service provider.

Channels

In permissionless blockchains like Bitcoin and Ethereum, all peers share and have access to the same ledger. However, this kind of blockchain may not be suitable for business applications. For example, a supplier may want to set different prices for different wholesalers, and he would not want everyone in the supply chain to view this information. In this scenario, he or she will prefer to deal with the different wholesalers separately. To solve this issue, Hyperledger Fabric came out with the novel concept of channels that allow private transactions within the same network.

Channels partition the Fabric network in such as way that only the stakeholders can view the transactions. In this way, organizations are able to utilize the same network while maintaining separation between multiple blockchains.  The mechanism works by delegating transactions to different ledgers. Members of the particular channel can communicate and transact privately. Other members of the network cannot see the transactions on that channel. The concept is illustrated in the following diagram:

The diagram above shows two channels, channel 1 and channel 2. Each channel has its own application, peers, ledger and smart contract (chaincode). In this example, channel 1 has two peers, P1 and P2 and channel 2 also has two peers, P3 and P4.  Ordering service is the same across any network and channel.

Application 1 will send transaction proposals to channel 1. P1 and P2 will then simulate and commit transactions to ledger L1 based on chaincode S1. On the other hand, Application 2 will send transaction proposals to channel 2. P3 and P4 will simulate and commit transactions to ledger L2 based on chaincode S2. 

Though our example shows peers belong to two distinct channels, in actual case peers can belong to multiple networks or channels. Peers that participate in multiple channels simulate and commit transactions to different ledgers. In addition, the same chaincode can be applied to multiple channels.

Membership Service Provider (MSP)

Hyperledger Fabric is a permissioned blockchain, therefore, every user needs permission to join the Fabric network. In order to obtain permission to join the Fabric blockchain network, the identity of every user must be validated and authenticated. The identity is  important because it determines the exact permissions over resources and access to information that user has in the Fabric network.

To verify an identity, we must employ a trusted authority. In Hyperledger Fabric, the trusted authority is the membership service provider (MSP).  The membership service provider is a component that defines the rules in which identities are validated, authenticated, and allowed access to a network. The MSP manages user IDs and authenticates clients who want to join the network. This includes providing credentials for these clients to propose transactions, defining specific roles a member might play and defining access privileges in the context of a network and channel.

The MSP uses a Certificate Authority to authenticate or revokes user certificates upon confirmed identity. In Fabric, the default Certificate Authority interface used for the MSP is the Fabric-CA API. However, organizations can choose to implement an External Certificate Authority of their choice.  Hyperledger Fabric supports many types of External Certificate Authority interfaces. As a result, a single Hyperledger Fabric network can be controlled by multiple MSPs.

The Authentication Process

In the authentication process,  the Fabric-CA identifies the application, peer, endorser, and orderer identities, and verifies them. Next, a signature is generated through the use of a Signing Algorithm and a Signature Verification Algorithm.  The Signing Algorithm utilizes the credentials of the entities associated with their respective identities and outputs an endorsement. The generated signature is a byte array that is bound to a specific identity.

In the following step, the Signature Verification Algorithm will accept the request(to join the network) if the signature byte array matches a valid signature for the inputted endorsement, or reject the request if not. If the user is accepted, he or she can see the transactions in the network and perform transactions with other actors in the network. On the other hand, if the user is rejected, he or she will not able to submit transactions to the network or view any previous transactions.

We shall explore chaincode in the next article.

Hyperledger Fabric Architecture Part 1

In a previous article, you have learned that Hyperledger Fabric has a highly modular and configurable architecture.  In this article, we shall examine the architecture in more details.

Hyperledger Fabric Network

Hyperledger Fabric is a permissioned blockchain network that provides ledger services to application clients and administrators. It allows multiple organizations to collaborate as a consortium to form the network.  The permissions to join the network are determined by a set of policies that are agreed to by the consortium when the network is configured. The network policies may change over time subject to the agreement of the organizations in the consortium.

The Hyperledger Fabric network comprises the following components:

  • Ledger 
  • Peers
  • Ordering service
  • Chaincode (aka smart contract)
  • Channels
  • Membership service provider

The Hyperledger ecosystem also consists of the client applications that allow users to interact with the network.  Moreover, The Hyperledger Fabric application SDK provides a powerful API for developers to program applications to interact with the blockchain network on behalf of the users.  

Peers

The Fabric network is comprised primarily of a set of peers or nodes. Peers maintain the state of the network and a copy of the ledger. In addition,  they also host smart contracts(chaincode).

There are two different types of peers in Fabric, the endorsing peer and the committing peer. The endorsing peers (aka endorsers) simulate and endorse transactions. On the other hand, the committing peers (aka committers) verify endorsements and validate transactions before committing transactions to the blockchain. On a separate note, the endorsing peers can also commit transactions to the blockchain. Indeed, the endorsers are special kind of committers. However, the committers cannot be the endorsers.  All peers can commit blocks to the distributed ledger.

Ordering Service

The ordering service is  made up of a cluster of special nodes known as orderers. The ordering service accepts the endorsed transactions and specifies the order in which those transactions will be committed to the ledger.  However, It does not process transactions, smart contracts, or maintains the shared ledger. 

The Transaction workflow

Let’s examine the transaction workflow that involves the client applications, the peers and the orderers.  By examining the entire transaction workflow, we will learn how consensus is reached in the process.

The transaction flow to reach consensus consists of three phases:

  • Transaction endorsement
  • Ordering
  • Validation and commitment

Phase 1 Transaction Endorsement

Transactions begin with client applications sending transaction proposals to the endorsing peers, as shown in the following diagram:

Phase 2 Transactions Simulation

At this phase, the endorsers will simulate the proposed transactions, without actually updating the ledger.  The Endorsers must hold smart contracts in order to simulate the transaction proposals. In the simulation process, the endorsing peers will capture the set of Read and Written data, known as RW Sets.

These RW sets contain data that was read from the current world state while simulating the transaction, as well as data that would have been written to the world state had the transaction been executed. The endorsing peers then sign these RW sets and send them back to the client application for use in the next phase of the transaction flow, as shown below:

Phase 3 Ordering 

At this phase,  the client application submits the endorsed transactions and the RW sets to the ordering service. The ordering service will take the endorsed transactions and RW sets and orders them into a block and delivers the block to all committing peers.

The order of transactions needs to be established to ensure that the updates to the world state are valid when they are committed to the network. Unlike the Bitcoin blockchain or Ethereum, where ordering occurs through mining, Hyperledger Fabric allows the organizations to choose the ordering mechanism that best suits that network.

Hyperledger Fabric provides three ordering mechanisms i.e. SOLO, Kafka, and Simplified Byzantine Fault Tolerance (SBFT). However, SOLO is used only for experimentation purposes and SBFT has not yet been implemented. Therefore, Kafka is the default ordering mechanism for production use. The Kafka mechanism provides a crash fault-tolerant solution to ordering.

Phase 4 Transactions Validation

At this final phase, the committing peers validate the transactions by checking that the RW sets still match the current world state. In addition, they need to ensure that Read data that existed during the simulation process is identical to the current world state.

After the committing peers validated the transactions, the transactions are then written to the ledger, and the world state is updated with the Write data from the RW Set. Committing peers are responsible for adding blocks of transactions to the blockchain and updating the world state.  Lastly, the committing peers asynchronously notify the client application the results of the transactions.

I shall discuss channels, membership service provider and chaincode in another article.

Hyperledger Fabric- A Short Introduction

You have learned about Hyperledger in one of my previous articles. Hyperledger is not a platform but it is an umbrella body that incubates and promotes business blockchain technologies.

The Hyperlegder projects,  which is known as The Hyperledger Greenhouse consists of five projects, as follows:

  • Hyperledger Fabric
  • Hyperledger Sawtooth
  • Hyperledger Burrow
  • Hyperledger Iroha
  • Hyperledger Indy

I shall introduce Hyperledger Fabric in this article.

Hyperlegder Fabric Key Features

Hyperledger Fabric is the first blockchain project developed and hosted by the Linux Foundation.  It was initially contributed by Digital Asset and IBM, as a result of the first hackathon. According to the Linux Foundation , it was Intended as a foundation for developing DLT applications or solutions with a modular architecture.

Hyperledger Fabric is an open-source enterprise-grade permissioned distributed ledger technology (DLT) platform, designed for use in developing enterprise applications. It features some key differentiating capabilities over other popular distributed ledger or blockchain platforms.

One special feature of  Hyperledger Fabric is that it allows components, such as consensus and membership services, to be plug-and-play. Besides that, Hyperledger Fabric uses container technology to host smart contracts called chaincode that comprises the application logic of the system.

Channels are another unique feature of Hyperledger Fabric. They allow transactions to be private between two actors, while still being verified and committed to the blockchain.

Hyperledger Fabric Architecture

Hyperledger Fabric has a highly modular and configurable architecture. Therefore, enterprises can make use of its versatility to develop innovative business applications.  Besides that, it can be used to optimize the applications. Indeed, Hyperledger Fabric is well suited to develop a broad range of industry use cases including banking, finance, insurance, healthcare, human resources, supply chain and even digital music delivery.

Like Ethereum, Hyperledger Fabric also features smart contracts. However, it does not use Solidity as the programming language to code smart contracts. Hyperledger Fabric smart contracts are written in general-purpose programming languages such as Java, Go and Node.js. This means that most enterprises already have the skill set needed to develop smart contracts, therefore no additional training to learn a new language is needed.

Unlike Ethereum and many other public blockchains or DLT platforms, Hyperledger Fabric is a permissioned platform. It means the participants are known to each other, rather than anonymous and fully untrusted. In the Hyperledger Fabric ecosystem, while the participants may not fully trust one another, it can be operated under a governance model that is built with trust exist between participants, such as a legal agreement or framework for handling disputes.

Consensus Protocol

One key difference between Hyperledger Fabric and other DLT platforms is its support for pluggable consensus protocols. It enables the platform to be more effectively customized to fit particular use cases and trust models.

For example, when Hyperledger Fabric is implemented within a single enterprise or operated by a trusted authority, fully Byzantine fault tolerant consensus might be considered unnecessary as it might cause excessive drag on performance and throughput. Instead, a crash fault-tolerant (CFT) consensus protocol is more than adequate. However,  in a multi-party, decentralized platform, a more traditional Byzantine fault tolerant (BFT) consensus protocol might be required.

Another significant difference between Hyperledger Fabric and other DLT platforms is that it can implement consensus protocols that do not require a native cryptocurrency. It means it neither need a cryptocurrency to incentivize costly mining nor to fuel smart contract execution.  The avoidance of a cryptocurrency reduces some significant risk due to hacking via attack vector. Besides that, the absence of cryptographic mining operations means that the platform can be deployed with the same operational cost as other distributed platforms.

The combination of the aforementioned differentiating features makes Hyperledger Fabric one of the better performing DLT platforms available today both in terms of transaction processing and transaction confirmation latency. Besides that,  it enables privacy and confidentiality of transactions and the smart contracts (chaincode) that implement them.

I shall discuss the Hyperledger Fabric architecture and chaincode in more details in another article.