I was wandering what is the "best" practice in ordering the steps for the HF development cycle? Here are some questions organized in different topics.
1. Specification of network infrastructure:
What are the mandatory members in one business
network definition (organizations, peers, ca)?
How many pears do we need in our business network (bn)?
I am aware of the semantic in
relationship between the channel and the peer, but I am not sure
about the relationship between the peer and the organization? Also,
what if just one organization (org1.example.com) will use the
developed network, how to specify the endorsement policy in that use
case (since we need at least two organization in chaincode
instantiate command specification)?
2. SDK development lifecycle
When we develop SDK (Node.js), in order to interact with our BN what are required CA certificates needed for our SDK app to be able to connect and issue chain-code functions?
How to issue the CA certificates needed for SDK app?
3. Chain-code development lifecycle
1.If I am using the CLI docker container for management of my BN, is it a good practice to git clone my chain-code to CLI and then to install it and instantiate it to certain peer node?
2.After I change my go chain-code, do I need to install it again with the different id to the same peer, or I can just update the existing instance of my chain-code?
My idea is to make this question sort of place where we can add all the relevant questions about these three topics, so please edit and add additional questions! Thank you for your answers.
Let me try to answer your questions:
What are the mandatory members in one business network definition (organizations, peers, ca)?
The only mandatory network entities are peers and ordering service. Of course to be able to define anything you should have a notion of organizations the parties which are going to transact. Each such party expected to have a number of peers which running chaincodes (smartcontracts) on organization behalf. CA is required to issue certificates and bind peers and clients identities to certain organization.
How many pears do we need in our business network (bn)?
The desired number of peers is completely up to your business logic and requirements, need to accommodate expectations for availability, scalability and your trust model (endorsement policies).
I am aware of the semantic in relationship between the channel and the peer, but I am not sure about the relationship between the peer and the organization?
Peer is the network entity which executes chaincodes on behalf of given organization increasing the organization confidence in correctness of execution results.
Also, what if just one organization (org1.example.com) will use the developed network, how to specify the endorsement policy in that use case (since we need at least two organization in chaincode instantiate command specification)?
You do not have to have at least two organizations to define endorsement policy, while with one org is a bit redundant since, default endorsement policy is to have some peer from the channel to sign on endorsement request.
When we develop SDK (Node.js), in order to interact with our BN what are required CA certificates needed for our SDK app to be able to connect and issue chain-code functions?
You do not need CA certificate, but you need a client certificated signed by root CA to prove client identity and enable peer to validate whenever client has correct access rights.
How to issue the CA certificates needed for SDK app?
You can use fabric-ca to enroll use and get client certificate, or you can simply leverage cryptogen to produce client certs for you.
If I am using the CLI docker container for management of my BN, is it a good practice to git clone my chain-code to CLI and then to install it and instantiate it to certain peer node?
Here is the thing, peer cli is a bit abused, since it's primary usage is to rapid testing in development and for demoing. The proper way to communicate with Hyperledger Fabric is by using SDK's, e.g. you basically need to implement a client which will be capable to install and instantiate chaincodes based on your own logic and parameters relevant for your application.
After I change my go chain-code, do I need to install it again with the different id to the same peer, or I can just update the existing instance of my chain-code?
You have an upgrade procedure which pretty well covered in Hyperledger Fabric documentation. Or you can see a short demo on video.
My idea is to make this question sort of place where we can add all the relevant questions about these three topics, so please edit and add additional questions!
Please consider to login into Rocket.Chat and use #fabric channel to ask your questions.
Additionally please take a look on documentation, since most of the information and details about your questions could be found there and it constantly being updated.
Related
On Ethereum, by inspecting a transaction on EtherScan, you are able to see the public chaincode used for that transaction.
I would like to see the chaincode used for the transaction, or maybe retrieve the current chaincode instantiated on the channel.
Is it possible, maybe from the SDK, to retrieve the code of the Hyperledger Contract and return it via API?
Ethereum is a public blockchain platform. On the other hand, Hyperledger Fabric is a private and permissioned blockchain platform.
It makes sense to be able to see the public smart contract used for a transaction in the case of Ethereum but the same concept doesn't apply to Hyperledger Fabric. A chaincode(smart contract) is a piece of code that is installed and instantiated through an SDK or CLI onto a network of Hyperledger Fabric peer nodes, enabling interaction with that network’s shared ledger.
You can call the chaincode APIs available to you like query, invoke, get history for a key, etc through SDK or CLI, but you can't get the entire code of chaincode.
Try to understand in this way. In a traditional app, you've your backend service and your frontend service, and they may run on the same or different servers. The frontend is able to interact with your backend service generally through the means of Rest APIs but does backend service ever allow you to see the entire codebase of it? Never.
The same concept applies here as well. Though the chaincode package is signed by every organization's member who is involved, and that is done to keep transparency in the network.
Also, I don't think there'll come any scenario where being able to see the chaincode from SDK or CLI would become crucial. The access to the chaincode codebase should be limited and the authorized member of the concerned organizations always have access to it.
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 have a multi-org fabric network where all the orgs are on a single channel.
I understand that using the composer acl file we can hide data from the users based on their roles and other conditions.
However, the data will be visible when we get into the peer container of any org and issue a peer channel fetch.
So, my question is, is there a way to encrypt this ledger data when the orgs shares the same channel? Here, they mention about encrypting the data. Is there any example/reference that can get me started on that one?
Currently, I'm not planning to use different channels between different orgs.
Yes, there are few ways to protect the ledger data. Like your mentioned in your question, Hyperledger Fabric FAQ, official gives five different ways to help us to achieve security and access control.
In the newest version of Fabric, which is tagged v1.2.0, provided a new definition called private data. I prefer to use this method to build my access control in my apps.
Since I am using Fabric Node SDK to deploy and control the fabric network, and it provides a convenient way for me to embed it into the exists projects.
Using the configuration file to define who can persist data, how many peers the data is distributed to, how many peers are required to disseminate the private data, and how long the private data is persisted in the private database. All the upgrade that you need to do is adding some parameters when install and instantiate, modifying some function to invoke the private data, writing some codes to handle the configuration file and users control.
It gives some examples for us to use this new feature:
Chaincode example
SDK example
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