Blockchain- Hyperledger Fabric — Part 3
by Abhishek VT
In the previous articles, we explored the following topics. Now, in this article, we’ll dive into the fascinating world of MSP and policies of Blockchain. Get ready for an adventure to understand how these essential elements make Blockchain safe and reliable!
MSP -Membership Service Provider
Let’s learn about MSP in Hyperledger Fabric! Imagine you have a secret club with your friends, and you want to make sure only the right friends can join and do specific things in the club. That’s what MSP is all about!
MSP stands for “Membership Service Provider.” It’s like having a magical guardian who checks everyone’s ID before they can enter your secret club. In Hyperledger Fabric, we use MSP to manage who can participate and do certain tasks in the blockchain network.
Just like your secret club has rules, the blockchain network also has rules, called “policies.” These policies decide who can do what, like who can add new information to the blockchain, who can change it, and who can read it.
MSP uses special keys called “digital signatures” to verify if someone is a real member of the network. It’s like having a special badge or a secret code that only the right members have.
Every member of the blockchain network has their own special ID, just like you have your own unique name. And MSP makes sure that each member’s ID is valid and they follow the rules of the club (or network).
So, when someone wants to join the network or do something in the network, MSP checks their ID and makes sure they are allowed to do it. If they are, then they can participate, just like your friends can join your secret club if they have the right ID and know the club rules.
Remember, MSP is like a magical guardian that keeps the blockchain network safe and makes sure only the right people can be part of the fun!
MSP Domains
- Local MSP
- Channel MSP
Let’s imagine that we have a bunch of kids who want to play different games together. To keep things organised, they form different groups, and each group has its own set of rules and leaders. Now, let’s see how this concept applies to local and channel level MSPs in Hyperledger Fabric.
Local MSP : In Hyperledger Fabric, a local MSP (Membership Service Provider) is like the rules and leaders of each individual group of kids. Each organisation that participates in the blockchain network has its own local MSP. The local MSP of an organisation handles the membership and authentication within that organisation.
Think of it as each kid’s home where they have their own parents or guardians who set rules for them. Similarly, the local MSP of an organisation decides who can be a member of that organisation and issues them special membership cards (certificates) to participate in the blockchain network. It also takes care of verifying the identity of its members when they want to do something within the organisation.
Channel MSP : Now, let’s take this a step further. Sometimes, kids from different groups want to play games together, but they also want to have their own rules and leaders when they play together. So, they create special play zones for that purpose. In Hyperledger Fabric, these special play zones are called “channels.”
A channel is like a private space where specific organisations can interact and share information. It’s like having a secret hideout where only certain kids are allowed.
For each channel, there is something called the channel level MSP. This is like the combined rules and leaders that apply to all the kids playing together in that specific channel. It is formed by taking representatives from the local MSPs of each organisation that is part of the channel.
The channel level MSP ensures that only the right kids from each organisation are allowed to participate in that particular channel. It’s like creating a special club with its own set of invited members from different groups.
MSP Structure
- Config.yaml : Used to set up identity classification in Fabric by enabling ‘Node OUs’ and specifying accepted roles
- Cacerts : This folder holds self-signed X.509 certificates of trusted Root CAs for the organisation represented by this MSP. It must have at least one Root CA certificate.
- Intermediatecerts : In this folder, you’ll find a collection of X.509 certificates belonging to Intermediate CAs that are trusted by this organisation. Each certificate in this collection is signed either by one of the Root CAs within the MSP or by an Intermediate CA whose issuing CA chain ultimately connects back to a trusted Root CA.
- Admincerts : Starting from Fabric v1.4.3 and higher, the “admincerts” folder has been deprecated. Previously, this folder used to hold a list of identities that defined the administrators for this organisation. These administrators were the individuals with special roles and permissions within the organisation. Typically, you would find one or more X.509 certificates in this list, representing the identities of these administrators. However, in the newer versions of Fabric, this folder is no longer in use.
- Keystore : In the context of a peer or orderer node’s local MSP, or even in a client’s local MSP, there exists a folder specifically dedicated to storing the node’s private key. This private key plays a crucial role in signing data, such as transaction proposal responses during the endorsement phase. This folder is mandatory for local MSPs, and it must strictly contain just one private key. For security reasons, access to this folder should be restricted solely to the identities of users who hold administrative responsibility on the peer. This ensures that only authorised individuals with administrative privileges can access and utilise the node’s private key for signing operations.
- Signcert: The local MSP of a peer or orderer node, or even in a client’s local MSP, there is a folder that holds the node’s certificate issued by the Certificate Authority (CA). This certificate serves as the node’s unique identity, and its associated private key enables the generation of signatures that can be verified by anyone possessing a copy of this certificate. The presence of this folder is obligatory for local MSPs, and it must strictly contain just one public key. As a security measure, access to this folder should be restricted solely to users who have administrative responsibility on the peer. This ensures that only authorised individuals with administrative privileges can access and manage the node’s certificate and public key.
- Tlscacerts: In this folder, you’ll discover a collection of self-signed X.509 certificates belonging to the Root CAs that are trusted by this organisation for ensuring secure communications between nodes using TLS. TLS communication is employed when, for instance, a peer requires a secure connection to an orderer to receive updates to the shared ledger.
- Tlsintermediatecacerts : Within this folder, you will find a collection of intermediate CA certificates that are trusted by the organisation represented by this MSP. These certificates are essential for ensuring secure communications between nodes using TLS. This folder becomes particularly useful when an organisation uses commercial CAs for TLS certificates. Similar to membership intermediate CAs, the specification of intermediate TLS CAs is optional.
- Operationscerts : This folder contains the certificates required to communicate with the Fabric Operations Service API.
Policies
In simple terms, a policy is like a set of important rules that show us how to make decisions and reach specific results. It tells us who can do what, like who can use or control something valuable, such as a car, our health, or our home. You see, policies are everywhere in our daily lives, helping us keep things safe and making sure everything works smoothly. They’re like the secret codes that protect the things we care about!
Imagine you and your friends are building a super cool clubhouse where you can play games and have fun together. To make sure everything is organised and fair, you need some rules, right? Well, in Hyperledger Fabric, we have something called “policies,” which are just like the rules for your clubhouse!
- Access Control Policies : Access control policies are like the special keys that decide who gets to enter your clubhouse and who doesn’t. You want to make sure only your trusted friends can come in and play. So, these policies help you choose which friends can join your special clubhouse and participate in all the fun activities.
- Endorsement Policies: Imagine you have some super fun games that need everyone’s approval to play. Endorsement policies work just like that! When you want to play a game, all your friends need to agree to play it. That way, everyone is on the same page, and the game can begin!
- Validation Policies: Validation policies are like your clubhouse’s security guards. They make sure that everything that happens inside your clubhouse is fair and follows the rules. They check if all the game scores are correct and if everyone is playing nicely.
- Consensus Policies: You know how sometimes your friends have different ideas about what game to play next? Consensus policies help you all agree on which game to play. They make sure everyone in the clubhouse has a say, and the decision is made together as a team.
- Channel Policies: Sometimes you want to have a secret room in your clubhouse where only a few friends can play special games. Channel policies help you create those secret rooms, and they decide who can enter and what games can be played there.
How do you write a policy in Fabric
Imagine you and your friends are building a cool treehouse club, and you want to make sure only the right members can do certain things. Well, in Hyperledger Fabric, we have policies that work just like the rules in your treehouse club!
1. Implicit Policies:
Think of implicit policies as the default rules that the grown-ups (the system) set up to keep everyone safe and happy. These rules are automatic and can’t be changed by the club members. Just like how you always wear helmets while riding bikes for safety, implicit policies make sure that certain things always happen in the club without you having to think about it.
For example, there’s a rule that says, “If a new member wants to join, they must be approved by the majority of existing members.” This helps ensure that only trusted friends can become part of the club.
Another implicit policy is, “Whenever we want to do something important, we need to get permission from the club administrators.” This helps avoid confusion and makes sure everything is done properly.
2. Signature Policies:
Now, imagine you and your friends are the club administrators, and you get to decide on some special rules for your treehouse club. These special rules are like signature policies. You can set them based on your club’s unique needs and what you all think is best.
For example, you might say, “For any new idea to become a rule in the club, at least two of the administrators need to agree and put their signatures on it.” This way, important decisions require agreement from multiple people to make sure it’s fair.
Another signature policy could be, “If we want to organize a big event, we need approval from both the secret club and the mystery club members to make sure everyone is excited and involved.”
So, in Hyperledger Fabric, implicit policies are like the automatic rules set by the system to keep things safe and running smoothly, while signature policies are like the special rules that you and your friends create to make your treehouse club unique and awesome! Together, these policies help manage access and make sure everything in the club works just the way you want it to!
Examples:
Example of an organisation defined with signature policies
To understand policies, we start by looking at the configtx.yaml file, where the channel policies are defined. In the Fabric test network, we can find examples of both policy syntax types by exploring this file. It’s like reading a special book that tells us how the rules are set for the network, and we can learn a lot from it!
The first part of the file is like a special section that lists all the friends (organisations) who will be part of the channel. Inside each organisation’s details, there are default rules for different things like Readers, Writers, Admins, and Endorsement. You can even give your own cool names to these rules if you want. Each rule has a Type, which tells us how it works (Signature or ImplicitMeta), and a Rule that explains the rule itself.
Let’s take an example from the test network. In the channel, we have Org1 as one of the friends. For Org1, the rule Type is Signature, and the Endorsement rule says “OR(‘Org1MSP.peer’)”. This means that any peer from Org1MSP has to sign something for it to be valid. These signature rules are like mini-rules that the ImplicitMeta policies look at to make big decisions. It’s like having puzzle pieces that fit together to create the whole picture!
Example of ImplicitMeta policies
In the configtx.yaml file, we have another example of a special policy type called “ImplicitMeta” used in the Application section. These policies are located on the /Channel/Application/ path. When we use the default Fabric ACLs (Access Control Lists), these policies decide how important things work in the application channels.
For example, they determine who can check the channel ledger, run a special code called chaincode, or make changes to the channel settings. These policies are like road signs that guide the behaviour of the application channels.
The cool thing is that these policies link to smaller policies called “sub-policies” defined for each organisation. Let’s say we have an organisation called Org1 with Reader, Writer, and Admin sub-policies. Now, the Reader ImplicitMeta policy, the Writer ImplicitMeta policy, and the Admin ImplicitMeta policy in the Application section will use these smaller policies to make important decisions.
In conclusion, MSP (Membership Service Provider) and policies are crucial components of Hyperledger Fabric blockchain that play a vital role in ensuring security, trust, and governance. MSP helps manage identities and access control, making sure only authorized participants can interact with the network and perform specific actions. It creates a secure and organized environment for the blockchain.
On the other hand, policies set the rules and decision-making structure within the network. They define who can do what, and under what conditions, making sure transactions are valid, endorsed by the right parties, and the network operates smoothly. Signature policies and ImplicitMeta policies work together to create a powerful system of checks and balances, maintaining the integrity of the blockchain.
By understanding and implementing MSP and policies effectively, Hyperledger Fabric blockchain can maintain a high level of transparency, accountability, and trust among its participants. As we continue to explore the world of blockchain technology, the knowledge of these essential components will enable us to harness the full potential of this innovative and transformative technology. So, let’s keep learning and exploring the exciting possibilities of Hyperledger Fabric and blockchain!
