We aim to provide a universal design and implementation roadmap for a permissioned-based enterprise blockchain. The stated approach is generic in nature and will provide you with a fair idea on how to kick-start your blockchain implementation in the enterprise. We will start with identifying business entities and designing the network topology and end up showing implementation and deployment. In the end, we will demonstrate the end-to-end test cases that will fulfill our smart contract as it executes transactions and query through the same to depict the final trade completion state.
The approach will have the following stages that can be used to design and implement a permissioned enterprise blockchain application:
- Defining Business Network
- Designing Network Topology
- Defining Smart Contract
- Application Deployment
- End-to-end Test Execution
Defining Business Network
Defining business network involves identifying parties to the business, their roles, and stake in the business. It involves creating users, their roles and affiliations or departments. For our trade finance application, we will use three different groups of business entities that will form the business network to carry out the trade business. All these entities will interact with the trade finance application and perform its respective function to fulfill a smart contract to take it to its logical end. In short, it will signify the completion of the trade in a free, transparent and trusted manner. The following are the three entities or organizations we will configure:
- Free Trade Enterprise (FTE)
- Banking Consortium (BNK)
- Shipping and Logistics firm (SHP)
Free Trade Enterprise (FTE)
FTE will consist of registered buyers and sellers that make use of the platform to discover each other and carry out trades. Their goal will be to fulfill their purchase and sale orders respectively. They will interact with the application to typically initiate the quotations or proposal and approve them as smart contracts. The following table depicts the user organization of FTE:
| User Id | Role | Organization MSP Id |
| User1 | Buyer | Org1FTE |
| User2 | Seller | Org1FTE |
As shown in the above table, we have two users defined with the roles of buyer and seller respectively and an MSP id of the organization to which the user belongs. (Note: MSP Id can be any arbitrary value; it just identifies your organization). In Hyperledger Fabric, the users can be created using Fabric CA client component. But one can also plug in their own CA server implementation to create users or generate crypto credentials. For our trade finance application, we have used the cryptogen tool provided by Fabric runtime, to generate users and certificates. This is discussed in the later section.
Banking Consortium (BNK)
The banking consortium can be viewed as a consortium of various banks. For our trade finance application, we will have an importer and an exporter bank as a member of this consortium. Importer bank will be involved in the process of LOC creation, which will be eventually approved by the exporter bank. This will be all done using trade finance application provided by FTE through the use of smart contracts. Just like FTE, the banking consortium will also represent an MSP. The below table depicts its user organization:
| User Id | Role | Organization MSP Id |
| User1 | Importer Bank | Org2BNK |
| User2 | Exporter Bank | Org2BNK |
We will have users with the role of importer and exporter bank respectively. The MSP id of the consortium will be Org2BNK
Shipping And Logistics Firm (SHP)
Our design will have a separate entity that will handle shipping and logistics aspect of the trade. Once the seller verifies the LOC approval, the shipper will initiate the shipping by creating the BOL document. This again will be done using the smart contract. The below table depicts the user organization of the shipper:
| User Id | Role | Organization MSP Id |
| User1 | Shipper | Org3SHP |
There will be only one user with the role name as a shipper and the MSP id as Org3SHP
In the next stage of our design and implementation approach, we will talk about designing a network topology.
Designing Network Topology
Designing a network topology is a very significant step when it comes to implementing blockchain in the enterprise. For our trade finance application, the network topology or the deployment model will look like the following:
The above network topology defines a blueprint with many nodes or deployment units that communicate with each other to execute or fulfill a blockchain transaction. Our network design will comprise of six peer nodes representing three different organizations viz. FTE, BNK and SHP and an Orderer node. The model also depicts a channel that will be used by peers to validate and execute transactions.
The Orderer node will be responsible for guaranteeing transaction order and delivery. The orderer service is also used to create a channel that provides a common communication infrastructure for peer and client nodes. Our orderer node will be part of FTE organization (orderer.fte.com) hosted on port 7050. The orderer service is bootstrapped with genesis block also known as the first block of the blockchain network that contains configuration details like which organization will manage the orderer node and number of peers and users managed by each organization.
Channel is another core component that provides a common infrastructure for all the peers (part of that channel) to communicate. We will have one channel termed as ‘tradechannel’ where our MSP instances like orderer (orderer.fte.com) and peers from all the three organizations will participate in the transaction. Each peer will have its own copy of ledger associated with ‘tradechannel’ channel. In short, all the peers will have visibility of every trade finance transactions that will be carried out on this channel.
Every organization will host peer nodes. We will have two peers per each organization – peer0.app.fte.com and peer1.app.fte.com as part of FTE, peer0.bnk.com, and peer1.bnk.com as part of BNK and peer0.shp.com and peer1.shp.com as part of organization SHP. One of the responsibilities of peer is to execute the transactions and validate them against the endorsement policy. The transactions itself will be part of chaincode that represents our smart contract. And therefore, our chaincode named ‘tradefinancecc’ will be installed on each peer. Peers itself can also become an endorser of transactions. All the peers will form a part of channel ‘tradechannel’.
In the next article, we will talk a bit about our trade finance smart contract, termed as ‘tradefinancecc’. We will explore through the business methods and workflow that will represent the trade finance application.