Hyperledger Composer - Participants and peers

Question

I recently started trying to grasp the concepts of Hyperledger Composer.

Based on what I understand, Hyperledger Composer is just a layer on top of Hyperledger Fabric with the purpose of simplifying how things are done. The confusion came when I tried to understand the difference between participants (composer term) and peers (fabric term). Based on the definition of the former, I understand that the participants are some kind of clients of the blockchain network (e.g. car manufacturer, car buyer) that have a user interface and interact with the blockchain through a REST api. Peers on the other hand are the actual nodes in the network. Intuitively, these concepts seem kind of related with each other, in the sense that an organization (participant) needs to contact each own node(peer) in the network where this peer has specific read/write rights in the network.

In their example-networks they use a default network configuration (crypto-config.yaml) in which they define, among other things, a single peer. However, I am allowed to create different types of participants with only a single peer in the network. Moreover, a single REST api is generated for the entire network.

For a network of two parties (e.g. car-manufacturer and car-quality-assurance-guy) it would make sense for me to have 2 participants (clients with ui), 2 peers (one with read/write rights and one with read-only rights) and 2 REST APIs (one for the car-manufacturer and one for the car-qa-guy). However, that doesn't seem to be how Composer works.

1) Is my understanding that different types of participants need to have their own peer in the network wrong?

2) Why do they generate a single REST api including methods for every participant in the network and not multiple so that they can be used by different clients with different rights?

Answer 1

To answer your questions first:

1) Your description that

I understand that the participants are some kind of clients of the blockchain network (e.g. car manufacturer, car buyer) that have a user interface and interact with the blockchain through a REST api. Peers on the other hand are the actual nodes in the network.

is indeed correct and that is how I understand it after using Composer for more than half a year in multiple projects. However, the statement that

different types of participants need to have their own peer in the network

is not quite true. As you stated it correctly, Composer is an abstraction of Fabric and aims to simplify prototype development on Fabric significantly. As a result, some of the nuances in Fabric are lost. For instance, it is incredibly complicated if you want to run Composer with support for multiple channels (in the Fabric sense).

In the case of participants vs peers, they are completely different and have little to almost no relations to each other. The peers belong to the Fabric world and they are responsible for running the Fabric blockchain infrastructure. In the basic tutorial (for Fabric which is also used in Composer), you have just one peer in the entire Fabric network. Once you have a Fabric network running, you can use Composer to model and deploy business networks however you wish. Note the distinction between Fabric network and business network. Fabric network refers to the underlying blockchain infrastructure built with Fabric while business network is a model built with Composer. Participants live in the business network modelled and deployed using Composer while peers are the backbone running the blockchain infrastructure. Hence, the two are weakly related in that without the peers, you simply can't have any business network at all. However, once you have a network running, the participants are almost entirely independent of the Fabric peers.

2) You have generated a single REST API most likely because the tutorial is worded as such. If you still remember, when you bring up the REST API, you needed to specify a business network card. Hence, each owner of a business network card can very well run their own REST API. In practice, you would issue an identity and business network card for each and every participant in the business network. Each participant will have different permissions granted by the access controls you have created when you modelled the business network (recall that these access controls are written in ACL). Hence, even though every participant and every REST API can see all the methods available, they can't invoke ones that they are not supposed to invoke. Of course you would have to model the access control policies properly in ACL.

---

Here are some of my thoughts on Composer.

Hyperledger Composer is just a layer on top of Hyperledger Fabric with the purpose of simplifying how things are done.

This is indeed true but it is a pity that they will be dropping support for Composer. (See this update by the authors) Therefore, it is recommended that production software should not be running on Composer. However, I personally find it extremely easy and quick to create prototypes (with nice UI) using Composer and I would personally continue using it for prototypes despite its deprecation simply because it is incredibly easy to use and free from major problems.