This section discusses the building blocks of the business network and covers the steps involved in forming a business network. All the terms are based on HLF. The following are the steps required to build a business network:

Step 1: Initiating the blockchain network: The first step in forming a network is to start an orderer. In the sample (refer to the preceding Architecture: conceptual view diagram), node O5 is owned by organization O5, and it is also defined as the orderer. The founder organization (O5) uses network configuration, NC05, and configures an ordering service (Ord05) for the blockchain network. This setup offers full administrative rights to the founder organization (O5) over the blockchain network (ProductChain). The CA for organization O5 is CA O5. The CA issues certificates to administrators of the network nodes of the founder organization (O5):

• Essentially, the ordering service is hosted on the founder organization (O5), or a cloud platform administrator, by O5, and further managed, and administered by O5. The network configuration file (NC05) defines the rights and privilege information of organization O5 over the business network.
• CAs are central to HLF. HLF offers a built-in Fabric CA for a quick start. However, organizations can use their own CAs. Different participants use certificates to identify themselves on the blockchain network. In this fictitious blockchain network (ProductChain), we will define five CAs, one for each organization.
• Network configuration (NC05) uses a structure called a membership service provider (MSP) to map certificate issues by CA05 to the certificate holder of the O5 organization. Furthermore, the MSP name is used in policies, by NC05, to grant access to participants from the founder organization (O5) over blockchain network resources. Take the example of identifying a participant from O5 who acts as the administrator of a blockchain network and can further add new member organizations to the blockchain network.

Other administrators being added by the founder: The founder organization (O5) adds a producer organization (O1) as an administrator by updating the network configuration (NC05). This modification further defines O1 as the administrator of the blockchain network. The producer organization employs its resource (node) as an additional orderer (O1) to the blockchain network.

Step 2: Defining a consortium to realize the separation and security of transactions: Secondly, we will look at defining the consortium. It is an association of two or more organizations, which participate to achieve a common goal. In a consortium, each participating organization has its own legal status and is joined by agreed-upon contracts. This consortium formation is different from the consortium defined in Chapter 2, Construing Distributed Ledger Tech and Blockchain. In Chapter 2, Construing Distributed Ledger Tech and Blockchain, the founder organization itself defines and owns the consortium and also participates in the transactions. Here, a founder is responsible for setting up, maintaining, and operating the infrastructure of the blockchain network. It also offers a solution, where various organizations can amalgamate and form a consortium and channels, and can enter into transactions. Such a configuration can allow cloud platform providers to manage the business network, without participating in it. After all, consortia are groups of like-minded organizations, working to solve a common problem. In this process, they employ their resources in the business network. In this sample, the founder organization is employing its infrastructure and also employs a few nodes as orderers. In this consortium, the following applies:

• The founder organization is employing its infrastructure and also employs node P5 (Ord O5) as the orderer node
• The producer organization O1 (also defined as the network administrator) defines a Consortium-X1 with two members—organization O1 and organization O2
• The consortium definition is stored in the network configuration (NC05) file

Step 3: Defining channels: Thirdly, we will be creating a channel that allows members of a consortium to enter into transactions with one another securely. Generally, such channels are referred to as application channels:

• Channel configuration CCon1 governs Channel-C1. Channel-C1 is created for Consortium-X1. O1 and O2 can both manage channel configuration, CCon1, and they have equal rights over it.
• Channel configuration (CCon1) is completely separate from network configuration (NC05) and, hence, organization O5 has no control over channel configuration (CCon1). However, Channel-C1 is connected to the ordering service (Ord 05).
• Channel configuration (CCon1) contains policies that define the organizations (O1 and O2) rights to transact over Channel-C1. Other organizations, such as O3 and O5, cannot affect transactions over it.

Adding peer nodes to channels:

• Adding peers to the channel, organization 1: Peer P1 is joined to a business network by the producer organization (O1). This is possible because the organization owns the peer (O1 owns P1). Peer P1 in the diagram also hosts the copy of ledger 1 (L1). It is clear that P1 and O5 (the peer and ordering service) can communicate with one another over Channel-C1.
• Adding peers to the channel, organization 2: Similarly, peer P2 is joined to the channel by the retailer organization (O2), which owns peer P2. Peer P2 also hosts the copy of ledger 1 (L1). It is clear that P2 and O5 (the peer and ordering service) can communicate with one another over Channel-C1.

The following are the lessons we can take from this configuration:

• Associating peer with the organization: The association of peer P1 with organization (O1) can be confirmed based on the certificates. In this sample, organization O1's CA (CA O1) has issued the X.509 identity to peer (P1), hence, P1 is associated with O1. Similarly, the association of peer (P2) with the organization (O2) can be confirmed based on the certificates. In this sample, organization O2's CA (CA O2) has issued the X.509 identity to peer (P2), hence, P2 is associated with O2.
• Associating peer with the ledger: Peer 1 (P1) and Peer 2 (P2) host the copy of ledger 1 (L1). Hence, ledger 1 (L1) is physically associated with P1 and P2, while logically associated with channel (C1).
• Functioning: At startup, peer (P1) sends a request to the orderer (Ord O5). The request from peer (P1) is verified by the orderer (Ord O5) by referring to the channel configuration (CCon1). This verification unlocks information about P1's permissions (access controls) over the channel (C1). It helps in determining the operations (read/write) that peer (P1) can perform over ledger 1 (L1). The same holds true for peer P2.

Adding chaincode and allowing an application to access the ledger: In this sample, a dApp is not fully offered by the founder. dApps are individually built by the organization.

However, they use SDKs, REST APIs, and other integration methods to connect with the business blockchain network and execute transactions:

• Producer organization (O1) owns application (O1App1), and retailer organization (O2) owns application (O2App2). These applications are integrated with chaincode (a smart contract), defined as chaincode (SC1) in the diagrams. Chaincode (SC1) is deployed on peer 1 (P1) and peer 2 (P2) and allows dApp (O1App1 and O1App2) to access ledger 1 (L1). All the participating entities, such as applications (O1App1 and O2App2), peers (P1 and P2), and the ordering service (O5) use Channel-C1 for communication purposes (transactions).
• dApps (O1App1 and O2App2) are also known as client applications. They, too, have identities associated with the organizations (O1 and O2). Chaincode (SC1) defines operations, and dApps (applications) can integrate with chaincode to execute transactions that allow access to the ledger (L1). The applications (O1App1 and O2App2) access to ledger (L1) is completely governed by the chaincode (SC1) operations.
  • Chaincode is developed by an organization's (O1) development team, and is reviewed and agreed by the consortium team (X1's members, such as O1 and O2). However, a consensus on the chaincode is required by the consortium before being deployed to the peer(s).