Search code examples
hyperledger-fabricblockchainhyperledgerhyperledger-fabric-ca

How to organize nodes of the hyperledger fabrik network?


Could you please give us advice on how to organize the nodes of Hyperledger Fabric?

Background: we are building a commercial app using blockchain smart contracts based on Hyperledger Fabric platform. The architecture of the app expects some RESTful API web service (possibly in bound with some load balancing) accessing Hyperledger nodes and exposing the API to SPA Web UI. The web service API is proxying application requests to the another Hyperledger alloted RESTful API dedicated to node accessing and smart contract invocation rather then direct acces to the blockchain nodes from the app API. The customers access the facilities of smart contracts through the web UI (SPA). The requrements of Hyperledger are the options given by blockchain such as trust, confidence reliability, consensus and so on and required by the business logic. The main problem is hidden in node distribution.

So, the question is how to organize the nodes of the network if the users have only web access and main blockchain features are provided only in a distributed network. Maybe, you can suggest us some suitable solution or a direction to investigate? (besides IBM cloud platform and AWS)

Thank you.


Solution

  • You generally want to distribute nodes to parties interested in verifying transactions. This means that if your application involves several distrusting parties, all of those should operate a peer node each. Also, depending on the consensus algorithm of your choice, you might also want to distribute orderer nodes to all distrusting parties. If you are unsure of the final size of your network you might want to put in place a way to quickly update channel configuration (gather signatures etc.) so that you can join new nodes in.

    For users and certificates, I would also go with one CA (generally fabric-ca) per peer operating organisation. I don't know if your users are preset or can dynamically register. In any case I would register all users with the CA of the organisation that operates the peer to whom the REST API communicates with.

    In terms of infrastructure, by far the most popular way to setup a distributed fabric network is through Kubernetes. In your case, you would need one Kubernetes cluster for each of the node operating organisations (for your development you could use one cluster, but keep in mind that you would have to adjust the endpoints when you move to a multi-cluster, distributed setup).