In this article, we will talk about Hyperledger Fabric, a permissioned blockchain, and share our experiences with a simple proof-of-concept implementation for a car supply chain.
Introduction
Blockchain is a technology that has been making noise in recent years, due to its applications in Decentralized Finance (deFi), cryptocurrencies (such as Bitcoin), and Non-Fungible Tokens (NFTs). However, the characteristics of technology can be explored in different ways, such as in a supply chain, which is the topic we will explore in this article.
Blockchain is a decentralized database of transactions that is shared and updated across a network of computers (each computer on the network holds a copy of the data). This provides an infrastructure not owned by a specific company but shared. Blockchain works similarly to a ledger book, recording transactions in a sequential manner. The transactions are stored in blocks that are linked to each other by a cryptographic hash. Therefore, it is not possible to update the ledger, only adding new transaction blocks. For this reason, blockchain also provides immutability.
Types of Blockchain
We can group blockchains into 2 broad categories: Public and Permissioned.
Public blockchains also referred to as permissionless, are open blockchains that allow anyone to participate. In this type of blockchain, all registered information is public (usually encrypted), allowing any user to access it. Another characteristic of public blockchains is that participants are usually anonymous. For example, in the case of Ethereum, each user has an address defined by a 64-character hex string. No additional information belonging to the user is recorded in the transactions.
Permissioned blockchains, on the other hand, allow organizations to set up controls on who can participate. Participants are identified, and access to information can be more tightly controlled.
The choice of which type of blockchain to use is directly related to the application. Applications that target the public (DeFi, Metaverse, etc.) usually end up opting for public blockchains. Applications with a restricted scope of participants, where regulatory, privacy, and data confidentiality issues are important, end up opting for permissioned blockchains.
Another factor that can support the decision is performance since public blockchains (at the moment) have limitations in this regard.
Hyperledger Fabric
Hyperledger Fabric is an open-source, permissioned blockchain project maintained by the Linux Foundation.
Hyperledger is highly modular and configurable, which facilitates adaptation to different business requirements, although it brings some complexity to network setup and maintenance. For this reason, companies offer solutions that encapsulate the Hyperledger Fabric, offering a more simplified management interface. An example of this is the Amazon Managed Blockchain.
Hyperledger also implements smart contract functionality that can be used to implement business logic for the applications that interact with the blockchain. Another interesting characteristic is that it supports multiple languages for smart contract development, such as Node.js, Java, and Golang. Usually, blockchains provide domain-specific languages; for example, on Ethereum, it is Solidity. This could facilitate adoption as your team won’t need to ramp up on a new language to start developing blockchain applications.
It also provides multiple ways to control access to the network and information. We will provide more information about these controls in the next sessions.
Car Supply Chain Blockchain
The supply chain is an interesting scenario to explore with blockchain as it involves multiple parties who need to share information. Blockchain provides a way to track information on goods and products throughout the entire supply chain while avoiding data tampering. This can be an issue for conventional supply chain solutions as the information can be segregated into multiple platforms owned by multiple companies.
For our Proof-of-Concept (PoC), we took a simplified car supply chain scenario. In this scenario, we have 3 types of organizations.
- Supplier: Builds parts that will be used by manufacturers to build the cars
- Manufacturer: Builds the cars using the parts provided by the suppliers
- Dealer: Purchases cars from manufacturers and sells them to the end user
We had four goals we wanted to achieve:
- Control the access to the network: participants should be allowed to verify and approve new participants.
- Participants should be able to review and approve smart contract releases to avoid malicious code.
- There should be a way to control which operations each participant can execute.
- Participants should be able to retrieve every information about a particular asset, including history tracking.
Over the course of the next few sections, we will provide some possibilities on how Hyperledger can address these requirements. Note that, as previously mentioned, Hyperledger is very flexible and configurable, providing different ways of solving a given requirement. In this article, we will comment a little about the features that we used.
To develop the PoC we used the samples provided by the Hyperledger Fabric community.
We set up a simple network with 3 organizations: 1 Supplier, 1 Manufacturer, and 1 Dealer.
We used Docker to run each component of the network in a local environment. This is how our PoC network looks:
Architecture of our local Hyperledger network (Source: Encora)
The image shows 2 types of peers, Endorsing and Ordering. Endorsing peers are responsible for validating transactions, executing the smart contract, and endorsing the results. Ordering peers are responsible for ordering and packaging the endorsed transactions into blocks and distributing them to the peers. On our PoC we have only 1 ordering peer maintained by the Manufacturer company. This is only to simplify the architecture, note that other organizations could also run an ordering peer to provide fault tolerance and prevent a single point of failure.
Note that each peer holds a copy of the ledger and has our smart contract installed, this way each company's application can interact directly if its hosted peer.
There are other types of peers in Hyperledger Fabric, but we will not go into detail in this article.
In the next sessions, we will provide information about the Channel Configuration and Certificate Authority components.
Goals 1 and 2: Control network participants and network configuration/code release
Hyperledger Fabric uses Certificate Authorities (CA) and Membership Service Providers (MSP) to identify the members of the network. Certificate Authorities issue certificates that can be used to identify the members. The MSPs, on a basic level, identify which certificates are allowed to interact with the network, it also turns the identity into a role by identifying specific privileges an actor possesses (admin, peer, client, etc.).
An analogy that the Hyperledger documentation provides to facilitate understanding is to imagine that if the CAs were the credit card companies, the MSPs would be the list of card flags an establishment accepts.
Recent versions of Hyperledger Fabric use the concept of Channel (sometimes referenced as network) to refer to components, policies, and processes that govern the interactions between organizations inside the network.
Usually, the Hyperledger Fabric network starts with a channel configuration, that is approved by the initial set of organizations. The channel is created by a channel creation transaction artifact that specifies the initial configuration of the channel. This configuration is stored on the ledger as the genesis block and governs all the subsequent blocks that are added to the channel. This way, each channel has one ledger that can be accessed by members of the channel.
Core network information is defined on the channel configuration, such as Member Organizations, nodes that can add blocks to the ledger, and Channel update policies, among others.
Each organization is identified by an MSP ID and a channel MSP, which is also stored in the channel configuration and contains the certificates that are used to identify the actors of an organization.
By using the channel policies, we can control, for example, the number of organizations that need to approve an update to the channel configuration or a new smart contract definition.
In our PoC, we used the default policies which implies that for both channel configuration updates and smart contract definitions, the majority of organizations’ admins must approve.
Using the sample scripts, we started the network with both Organization 1 (Supplier) and Organization 2 (Manufacturer), and then we submitted a channel configuration update using Organization 1 to add Organization 3 (Dealer) to the network. Organization 2 had to approve this channel configuration, otherwise, it would not be committed to the ledger. In the image below, we changed the script used to add Organization 3 to the network to provide a signature only from Organization 1. Note that when Organization 3 tries to fetch information, it is unable to do so.
Similarly, we deployed our smart contract to the channel using Organization 1 and approved using the other organizations, at least 2 of them, to be able to proceed.
We will not cover details about the Hyperledger CLI or the sample scripts provided by Hyperledger Fabric, we just want to highlight that Hyperledger provides this kind of control over the network participants and smart contract definitions. For example, in the future, if a new Supplier organization wants to join the network, then it will need consent from the network members.
Another important configuration is the Endorsement Policy. You can use them to identify which organization’s peers need to validate a transaction before it is submitted to the ledger. This is useful if you want specific types of transactions to be validated by a specific set of peers. You can also define endorsement policies at the smart contract level, thus overriding the default policy defined on the channel.
Goal 3: Control operations
One way to control operations inside the network is to create multiple channels, this way you can segregate data that can be accessed only by members of a given channel. Keep in mind that organizations can have access to multiple channels.
However, Hyperledger Fabric provides other ways, one of them is the state-based control, which we used in our PoC. Basically, inside the smart contract, you can retrieve requester information such as their organization identification. In our PoC for each asset (part or car), we also store the owner organization and check this value, for example, on transfer operations to verify if the requester is the actual owner of the asset.
Another interesting feature is the attributed-based access control (ABAC). Hyperledger Fabric allows you to extract attributes from the requestor certificate inside the smart contract. This way you can, for example, validate these attributes before proceeding with the method execution.
You can also define state-based endorsements inside the smart contract. This can be used, for example, to enforce that a transaction updating an asset that belongs to Organization 1 must be endorsed by a peer of this organization.
On Hyperledger Fabric, you can also create Private Data collections. This is a useful tool as it allows you to keep part of asset information private to a defined group of organizations without the need to create a new channel. This way every organization on the channel has access to the transaction but part of the information is encrypted for some.
Note in the image above that the “secret value” is also stored on the Channel State, visible to everyone, but only the hash and not the plain secret value.
We will talk a little bit more about how some of these features can be used in the PoC showcase section.
Goal 4: Access to Asset Information and History
We created simple structs on our smart contract to represent the Parts and Car assets:
Hyperledger Fabric stores information using key/value pair. On our PoC, the asset IDs are defined by a hash created over the asset’s immutable information. For Part assets, it is the Supplier (a company that manufactured the part), Serial Number, and Part Type. For car assets, it is the Serial Number, Manufacturer (a company that manufactured the car), and the parts Ids.
Hyperledger Fabric provides an API that can be used to interact with the ledger. It provides methods to insert and query assets, but also methods to retrieve assets history, containing all the previous versions of the asset.
PoC Showcase
Using the API mentioned before, we created a set of methods that allows external applications to interact with our smart contract. On these methods, we implemented the business logic that controls access to the methods and information on the ledger.
Note that, to simplify it, in our PoC we restricted the create and update operations, but every organization that belongs to the channel can fetch the information registered on the Ledger. We could have restricted the query methods as well, for example, allowing companies to retrieve only information about assets that belong or belonged to them, or that are marked as visible by the Owner (e.g., Parts and Cars available for sale).
We could have gone even further by using a separate channel or using private data collection to store information that should be visible only to a group of organizations, such as a transfer receipt that should be visible only to the 2 organizations involved in the transfer.
To interact with our smart contract, we developed 3 simple applications:
- Supplier App: Allows creation and transfer of parts
- Manufacturer App: Allows creation and transfer of cars
- Dealer App: Allows car selling to end users
To integrate our application with the blockchain, we used Fabric SDK for Golang.
In the following video, we will provide a quick Demo of these applications interacting with the blockchain. Each application uses the identification information as follows:
- Supplier: Identified by Org1MSP
- Manufacturer: Identified by Org2MSP
- Dealer: Identified by Org3MSP
Encora PoC - Car supply chain on Hyperledger Fabric Blockchain demo video. Background music on the video was obtained from Mixkit.com.
Key Takeaways
Permissioned blockchains are an interesting alternative for applications that need information sharing and transaction governance but at the same time require a certain level of data privacy and confidentiality. In this article, we showcased Hyperledger Fabric, a permissioned blockchain that provides interesting functionality for these scenarios. Using it, we created a simple PoC demonstrating how some of these features can be used in a supply chain context.
Acknowledgment
This piece was written by Guilherme Carrenho, Innovation Expert at Encora’s Product Engineering Technology Practices group. Thanks to Álison Ramos da Silva, João Augusto Caleffi, and João Pedro São Gregorio Silva for their reviews and insights.
About Encora
Fast-growing tech companies partner with Encora to outsource product development and drive growth. Contact us to learn more about our software engineering capabilities.
