There is no clear documentation of hyperledger fabric multichannel, can someone from community share example of configuration.
This Stack Overflow thread on creating multi-channel for a Hyperledger Fabric configuration should help you (mostly in yellow and grey code blocks) -> Configure Multiple Channel in Hyperledger Fabric.
Once you have configured your custom runtime Fabric environment for your multi-Org, multi-channel setup, you can then create the requisite Hyperledger Composer config artifacts (eg. such as business network cards, one for a PeerAdmin for runtime install on the two peers in a specific organisation, and one card for a PeerAdmin to instantiate/start the business network across all the multi-Org peers joined to the specific channel in question) - and thereafter, issue cards for the individual identities that will consume/transact on the business network (on whatever channel the connection profile information is set up to communicate on). See this Multi-Org tutorial (for two Organisations, but similar principles apply) https://hyperledger.github.io/composer/tutorials/deploy-to-fabric-multi-org.html for guidance.
Related
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?
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.
I created a composer business network and successfully deployed in to the fabric network(Single organization) . The next step is deploying to the fabric network(Multiple organizations). I'm not understanding the purpose of deploying to Multiple organizations . Is it necessary to deploy the composer network into fabric Multiple organizations. Can any one help me from this confusion .
Thanks in advance..
IMHO, The OP is asking "Why do I need to deploy to Multi-org fabric network", not how.
While it is not required for you to deploy anything to a multi-organizational fabric network, typically in real-world scenarios you'd be mostly deploying to such a network structure.
Enterprise Blockchain solutions typically are most useful when they are bringing together different organizations which do business together, and though they are co-operating with each other while doing so, they typically don't trust each other.
Normally, in a non-blockchain scenario, these organizations would each have their own system of record keeping, and all business transactions would get entered into multiple independent record books. This creates all sorts of delays, dependencies and need for arbitration when one organization's records don't agree with the other organization's records.
The blockchain becomes a single record for all these co-operating but untrusting organizations. All data entered in to the blockchain is first reviewed by all the organizations, and only after consensus is it entered into the records.
This kind of setup is only possible using the multi-org network, with each peer hosting it's own peers that it trusts to review the transactions and perform consensus. THAT'S WHY you need this kind of setup in real-world scenarios.
The composer multi-org tutorial provides the information needed to understand the operational aspects needed to run a business network in a multi-organisational fabric network. The tutorial can be found here
https://hyperledger.github.io/composer/latest/tutorials/deploy-to-fabric-multi-org
From there you will see that defining an endorsement policy (in the case of the tutorial, both organisations have to endorse transactions) that you need to install the business network onto at least 1 of the peers in each organisation (in the case of the multi-org tutorial the business network is installed to all peers in the organisation).
Once installed and the business network started those peers are able to endorse the transaction.
hyperledger fabric is designed to allow multiple different organisations to share a ledger between them. This is a very common use case of hyperledger fabric.
I’m interested into the development of Blockchain Apps using Fabric and Composer.
I’ve got just one question: while Ethereum is a public blockchain so you can deploy your Smart Contract on it and use them freely, can we do the same thing with Fabric? Let me explain: Ethereum has a running Blockchain on which we can work and access, but Fabric has not, right? Should I set up an entire new blockchain network before (setting up all the nodes, giving permissions etc.)?
Thank you
Hyperledger Fabric is different to the blockchain systems you mention in it is private and permissioned. Rather than an open permissionless system that allows unknown identities to participate in the network (requiring protocols like “proof of work” to validate transactions and secure the network), the members of a Hyperledger Fabric network enroll through a trusted Membership Service Provider (MSP). Member organisations would generally set up their own Fabric infrastructure, if they're participating in the blockchain network (context provided earlier). See more on FAQ here -> http://hyperledger-fabric.readthedocs.io/en/release-1.2/Fabric-FAQ.html and understand more on key Fabric Concepts here -> http://hyperledger-fabric.readthedocs.io/en/release-1.2/key_concepts.html . As for Hyperledger Composer, that is a development framework, with tools etc to accelerate development and abstract things to a business level (ie App development using structure/validated, model driven development as a given). See more here -> https://hyperledger.github.io/composer/latest/introduction/introduction (and also see the architectural and key concept links there).
So yes, you will have a running, private blockchain network (including all of the functionality discussed in the docs) with Hyperledger Fabric.
As in Ethereum we can able to create public blockchain and then the user can able to run smart contract on it, same thing we can do in Hyperledger fabric also.
Hyperledger Fabric has the same functionality as smart contracts called as “chaincode”.
A chaincode is a program that is written to read and update the ledger state. All the business logic handled by chaincode.
For example, if a transaction created then chaincode share and update the ledger throughout the network.
About a Fabric based running blockchain we can work on it and can access it but that's only possible when someone from existing network invites you.
It is quite difficult to say you should setup an entire new blockchain network until I know your use case. Based on your use case you can setup an entire new blockchain network using fabric which will be private.
I have started to learn Hyperledger Fabric and Composer. I am able to create a simple Business Network using Composer and deploy it on Fabric, but I have a question. Let's say I have 2 BNA (instantiated on single channel) files both having same namespace (org.example) and having same participant name as well, as Customer (identifier will be org.example.Customer). Is there any way that I can access the participants created by first Business Network App in another Business Network App? Logically what I can think of is since both have been instantiated in the same channel with different chaincode and same model file, data should be cross accessible. But it isn't.
Although chaincodes share the same ledger when installed on the same channel (and as business networks are just chaincodes this applies to them also). Fabric still partitions the data that a chaincode can read/write by it's chaincode id. So when you install 2 business networks onto the same channel they will have different chaincode id's and so their data is separately partitioned.
As mentioned in the other answer (although the link is not quite correct), what you can do is make use of a feature of composer to be able to invoke another business network on the same or even different channel from the executing business network.
As the 2 business networks are on the same channel you can not only read information but you are also able to invoke transactions that can change information. (You can only read information if the business networks are on different channels).
The correct link for the tutorial is here
https://hyperledger.github.io/composer/latest/tutorials/invoke-composer-network
Unfortunately this tutorial is rather basic and only offers a glimpse of how to interact with other business networks.
Is available a tutorial about how to interact from a bna to another one.
Here the link to the official Hyperledger Composer documentation.
https://hyperledger.github.io/composer/latest/tutorials/invoke-composer-network
I have been building an application in hyperledger composer.
All the tutorials I find related to hyperledger fabrics talks a lot about Orderers, Channels, Peers, Ledger etc. But none of the hyperledger composer tutorial relates the concepts of Asset, transaction or Participants to those.
For instance, hyperledger composer supports only a single channel, then how is the privacy of a transaction maintained there? Is it through the permission.acl file?
Also relating to the famous Vehicle lifecycle network.
Will each of those manufacturer be an organization(having several peers within it) in a blockchain network?
Do all the manufactures needs to host a peer(containing both the ledger and chaincode)?
Does the regulator body also need a peer?
Please help me understanding it clearly.
See here https://hyperledger.github.io/composer/latest/introduction/key-concepts for Concepts and here -> https://hyperledger.github.io/composer/latest/introduction/introduction for an Intro to Hyperledger Composer and a slidedeck on Composer concepts can be found here -> https://www.slideshare.net/MattLucas3/blockchain-composed-v207
Manufacturer will be a member organisation of the blockchain network
Its likely a Manufacturer will want to host it, or have it hosted as a major party. Its also possible that an organisation doesn't stand up any infrastructure and relies on a portal into the blockchain if it is agreed it should have an interest, by the consortium that stand up the blockchain network. Same applies for the Regulator in that respect.
Sadly, the concept of private channels is a feature of Hyperledger fabric and isn't available in the composer framework. But, to achieve the privacy of transaction that you are talking about you can use the ACL rules effectively. You can control who sees which transaction by defining rules in the acl file and applying them on the Historian record that contains all the transactions.
You must read about historian record (Will prove to be very useful while writing the acl for controlling transaction records): https://hyperledger.github.io/composer/unstable/reference/historian.html
Also, For data privatization in hyperledger composer there are certain practices and ways that will prove to be very useful. Go through this article: https://medium.com/coinmonks/implementing-data-privatization-within-hyperledger-composer-2bc99a11c344
Now, about the second part of your questions- Hyperledger composer doesn't involves all those endorsing peers, committing peers endorsing policy and such. In hyperledger composer when we create the rest server and the angular application and all the transactions are recorded from a single identity. For achieving a multi-user model for production using composer we can use the multi-user mode of the composer rest server and the authentication feature of the same. This helps in creating different identities/wallet for different users and then the transactions are recorded from those respective wallets.