I'd like to know how to enable the ordering service of Hyperledger Fabric for exchanging messages among these kind of nodes. For instance, if only these nodes have to compute a result together but everyone has only one part of the input, is it possible to allow them to exchange this partial input and compute the result as output in order to send to an application client afterwards? I know that ordering service is used to order transactions and to enable the broadcast of validated blocks among other peers but I'd like to know if this kind of customisation is granted on this platform.
No. Orderer nodes do not "compute results". Only endorser peer nodes do.
Related
I want to have orderer beside each organization and NOT to create a separate organization for orderers. Is it possible? If yes, how can I do it?
Yes, the application organizations can provide ordering nodes. For example the sample configuration shows a single organization providing both peers and ordering nodes. Simply configure OrdererEndpoints under the organization configuration.
That being said, for each organization that provides an ordering node, you may want to consider creating a separate logical organization in the channel configuration, so that the peer credentials and orderer credentials can be managed separately using different root certificate authorities.
I am planning to implement a decentralized orderer or say peer-org-owned orderer in Hyperledger Fabric.
Can someone please explain whether is it valid to implement an orderer from a peer-org-owned organization?
If it's valid then how the configuration will look like?
It is not only valid, but actually encouraged. A decentralized ordering service is the best scenario in HLF, as no single organization has total control over the ordering process. From Fabric v2.3, you can have any organization contribute to the ordering service. They also made it very easy to do so: create an ordering node, and join that ordering node to a channel much like you currently do with your peer nodes. A full tutorial from the Fabric Docs can be found here. Take your time when reading through the tutorial as it is quite long and may seem complicated at first.
I have some questions regarding the deployment of a HLF use case. consider that we want to implement a network for insurance industry.
clients want to interact with an insurance company to make an agreement and whenever they suffer from an accident, make a request to claim their funds.
We also have an organization that assesses the damage.
When the customer requests an assessment, the damage assessment process may take several days.
In the compensation process, the assessors must endorse the transaction.
Do customers in the network need an organization and peer or is it enough to be interacted with the application?
Doesn't the fact that transactions take several days to be endorsed pose a problem for the network? What solution do you suggest for its implementation? What functions should be used in a developing Chaincodes?
The documents that assessors want to record after completing their work may include images, videos, and a lot of information. How should this information be stored on the network? Doesn't it create a heavy load on the network?
Do customers in the network need an organization and peer or is it enough to be interacted with the application?
It's up to you whether or not you want to register your users on the blockchain. Registering and enrolling an identity in a Hyperleder Fabric network means you're making them a member of an organization. With registering identities on the blockchain, you can have better access control management of identities. Also, if you're registering a user on the blockchain, the admin would be able to see in the ledger which member did a particular transaction. You can achieve the same without registering members on blockchain but it's one of the perks and underlying principles of Hyperledger Fabric so why not leverage it.
Doesn't the fact that transactions take several days to be endorsed pose a problem for the network? What solution do you suggest for its implementation? What functions should be used in a developing Chaincodes?
No, transactions don't take several days to get endorsed in Hyperleder Fabric. It takes only a few seconds to complete a transaction. And, you can increase the throughput by structuring your application better(have more no. of peers etc). Yes, there'll be a limit to how many transactions you can do per second even when you have a good architecture, but isn't it what blockchain infamous for?
There're other ways of increasing the throughput depending on the use-case. One could be returning the response to the API caller as soon as the transaction gets endorsed, not waiting for the transaction to get committed in the ledger. There're definitely some cons to this approach like getting an MVCC error later but if handled properly, this can be one of the best ways to increase the throughput in Hyperledger Fabric.
The documents that assessors want to record after completing their work may include images, videos, and a lot of information. How should this information be stored on the network? Doesn't it create a heavy load on the network?
There's no need of storing blob files in the database. It doesn't have anything to do with blockchain. In a simple project which handles uploading and downloading images/videos, you don't save those files in your database. You just store the name in the database which points to a file in the filesystem.
You can read more about "Should you store images in DB or not?" here.
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 have created a network composed by two nodes using this tutorial: Multiple Machine.
In the node with orderer and ca installed, I can use the composer-playground to interact with the blockchain. Instead, analysing the logs of the docker on the second node, I am able to see the communication between the nodes but I am not able to access the data.
How can I access data on the second machine?
It is a simple node connect to the first node (where is installed the orderer and the ca).
Thanks,
What do you mean by accessing the data?
In Hyperledger Fabric the ledger data is composed of two components i.e. World State and Transaction History Log (the blockchain).
Here World state refers to the most recent (current) state of the assets you have and Transaction History log refers to the transaction executed on these assets. Assets or Key Value set when using CouchDB as the World State allows you to have KeyValue with Value as JSON documents.
The World State by default is stored in levelDB or couchDB, if you have docker containerized network the World State levelDB is stored on the peer container while using couchDB sets up its own couchDB container associated with each peer. The couchdb for each peer can be accessed from host machine using http://couchdbIp:port
The Transaction log get's stored in the underlying file system as blockFiles somewhere under location /var/hyperledger/ledgerdata or something in the peer container.
When you mention Orderer, which is another component like peer, is a docker container assigned the role of making sure that transactions are properly ordered and verified that their endorsement are valid. This gets complicated as you go to having multiple ordering service nodes and requires Kafka implementation rather than the default SOLO implementation. You can read about each of these implementations in Hyperledger Fabric official documentation.
Also CA is associated with each organization responsible for establishing chain of trust is another component of Hyperledger Fabric that signs certificates of network components like organization peers, client and participants following PKI.
The Playground will connect to the Fabric based on the connection profile (connection.json) for the Business Network Cards you have. If you want to specifically connect to second node you could modify a card.
But remember that Playground is a development and test tool not a production tool so you shouldn't worry too much about hitting different containers with it - particularly as the data will be the same replicated across Peers.