Blockchain: How should you organize your peers?
The last time we communicated, we spoke about the types of users on a Blockchain network – and about Hyperledger in particular. Now, I would like to map this conversation to peers. As you may know, Hyperledger has three components: Membership services – which manages digital certificates and access, ordering service – which keeps the peers in alignment, and peers – which hold the ledger. A peer is also where chaincode, also known as smart contracts, are executed. Membership and ordering services align well to being centralized. Peers, on the other hand, can be distributed and placed anywhere you desire in the world. Each member of the Hyperledger network should have their own peer. The channels (databases) that a peer subscribes to, and transacts against, determines the member’s role and capabilities in the blockchain network.
Architecturally, the fabric is extremely flexible, but in practice consider two recommendations. First, you only need one or two peers. Per a given channel, peers are identical. They execute the same transactions and receive the same code updates in the exact same order as all other peers on that channel. There is no reason to have lots of peers. Get two peers if you need the availability – which I would recommend. Secondly, the front-end systems that hold the Hyperledger SDKs (those systems that provide RESTful interfaces) should be aligned to a member’s peers. Which means you want your front-end systems talking to your peers and you want other member’s front-end systems talking to their peers. The idea of an SDK talking to all of the peers for consensus purposes makes little to no sense when they will all return the same results. One SDK only needs to talk to one peer or two, for high availability, to get the optimal performance and functional capabilities of the fabric.
These two items will simplify your configuration and keep your costs down. It will also provide an added layer of security since only your SDKs are talking to your peers. Couple this access control recommendation with the secure service containers used by the IBM Blockchain Platform to control administrative access to the network, and you have the basis for a high-security system.
To better understand the Hyperledger Fabric, for more information on how you can build your own Hyperledger network, or to learn how we can work with you, check out these links and stay tuned for my next blog post on blockchain: “What is a good blockchain use case?”
The post Blockchain: How should you organize your peers? appeared first on IBM Systems Blog: In the Making.