A connection profile will describe the Hyperledger Fabric network to the Hyperledger Fabric Node.js Client (fabric client). It also contains entries that describe the Hyperledger Fabric network including entries that describe the fabric client that will access the network. The connection profile has specific addresses and settings for network items. Configuring a connection profile for a single channel - single chaincode is pretty straightforward but it will be a little tricky the other way round. Let me showcase a scenario which will define the channels and chaincodes with their relationships between them.
The Scenario
There will be two organizations with their respective channels. The scenario will be that the first organization can make use of the second organization’s channel and chaincode but not the vice versa. Let us first start with the first organization’s connection profile.
Before proceeding with this article, make sure that you have a basic understanding of the YAML.
ORG1 Connection Profile
The first organization’s connection profile is where we will be defining the configuration to interact with the second organization’s channel & chaincode.
name: "ORG1 Client"version: "1.0"client: organization: org1 credentialStore: path: "./KeyStore/clearingHouse" cryptoStore: path: "./KeyStore/clearingHouse"
The above configuration defines the name and the HLF Keystore location which will store the private and public keys.
channels: org1channel: orderers: - orderer.example.com peers: peer0.org1.example.com: endorsingPeer: true chaincodeQuery: true ledgerQuery: true eventSource: true peer1.org1.example.com: endorsingPeer: false chaincodeQuery: false ledgerQuery: false eventSource: false org2channel: orderers: - orderer.example.com peers: peer0.org2.example.com: endorsingPeer: true chaincodeQuery: true ledgerQuery: true eventSource: true peer1.org2.example.com: endorsingPeer: false chaincodeQuery: false ledgerQuery: false eventSource: false
Channels are the state store of a blockchain network which holds the application data generated during the lifecycle of the system. It’s used to store information like user data, purchase data, order data, invoices and more. We defined the channels in such a way that the first organization’s fabric client will now know the available channels for its organization. In our scenario, the first organization will be able to interact with the second organization’s channel.
organizations: org1: mspid: ORG1MSP peers: - peer0.org1.example.com - peer1.org1.example.com certificateAuthorities: - ca.org1.example.com adminPrivateKey: path: crypto-config/peerOrganizations/org1.example.com/users/[email protected]/msp/keystore/7f6d1298f6a1a98a2bae3aa68d2b0a1b32be00f49298c5c1aad2e6ed74b9a72e_sk signedCert: path: crypto-config/peerOrganizations/org1.example.com/users/[email protected]/msp/signcerts/[email protected]
The organizations key defines the attributes that are related to its organization. This will stay the same for the second organization with its respective attributes. This defines the Membership Service Provider Identifier
(mspid), the peers with which the client will interact with, the certificate authority
that enrolls the admin and the key that is generated during the cryptogenic key generation
.
orderers: orderer.example.com: url: grpcs://localhost:7050 grpcOptions: ssl-target-name-override: orderer.example.com grpc-max-send-message-length: 15 tlsCACerts: path: crypto-config/ordererOrganizations/example.com/msp/tlscacerts/tlsca.example.com-cert.pem
The orderers form the ordering service, i.e., a communication fabric that provides delivery guarantees. The ordering service can be implemented in different ways: ranging from a centralized service (used e.g., in development and testing) to distributed protocols that target different network and node fault models. If you’re using Kafka solo, you will have only one orderer for both the organizations.
peers: peer0.org1.example.com: url: grpcs://localhost:9051 eventUrl: grpcs://localhost:9053 grpcOptions: ssl-target-name-override: peer0.org1.example.com grpc.keepalive_time_ms: 600000 tlsCACerts: path: crypto-config/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/msp/tlscacerts/tlsca.org1.example.com-cert.pem peer1.org1.example.com: url: grpcs://localhost:10051 eventUrl: grpcs://localhost:10053 grpcOptions: ssl-target-name-override: peer1.org1.example.com grpc.keepalive_time_ms: 600000 tlsCACerts: path: crypto-config/peerOrganizations/org1.example.com/peers/peer1.org1.example.com/msp/tlscacerts/tlsca.org1.example.com-cert.pem
peer0.org2.example.com: url: grpcs://localhost:13051 eventUrl: grpcs://localhost:13053 grpcOptions: ssl-target-name-override: peer0.org2.example.com grpc.keepalive_time_ms: 600000 tlsCACerts: path: crypto-config/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/msp/tlscacerts/tlsca.org2.example.com-cert.pem peer1.org2.example.com: url: grpcs://localhost:14051 eventUrl: grpcs://localhost:14053 grpcOptions: ssl-target-name-override: peer1.org2.example.com grpc.keepalive_time_ms: 600000 tlsCACerts: path: crypto-config/peerOrganizations/org2.example.com/peers/peer1.org2.example.com/msp/tlscacerts/tlsca.org2.example.com-cert.pem
A blockchain network is comprised primarily of a set of peer nodes (or, simply, peers). Peers are a fundamental element of the network because they host ledgers and smart contracts. The above peer configuration defines the available peers for the first organization. Since the first organization will interact with the second organization, we’ll define both the peers.
certificateAuthorities: ca.org1.example.com: url: http://localhost:8054 httpOptions: verify: false tlsCACerts: path: crypto-config/peerOrganizations/org1.example.com/ca/ca.org1.example.com-cert.pem registrar: - enrollId: admin enrollSecret: adminpw caName: ca.org1.example.com
The Certificate Authority (CA) provides a number of certificate services to the users of a blockchain. More specifically, these services relate to the user enrollment, transactions invoked on the blockchain and TLS-secured connections between users or components of the blockchain. Every channel has it’s own CA.
ORG2 Connection Profile
The second organization’s connection profile is pretty straightforward as it is bound to access its own channel.
name: "ORG2 Client"version: "1.0"
client: organization: org2 credentialStore: path: "./KeyStore/org2" cryptoStore: path: "./KeyStore/org2"
channels: org2channel: orderers: - orderer.example.com peers: peer0.org2.example.com: endorsingPeer: true chaincodeQuery: true ledgerQuery: true eventSource: true peer1.org2.example.com: endorsingPeer: false chaincodeQuery: false ledgerQuery: false eventSource: false
organizations: org2: mspid: ORG2MSP peers: - peer0.org2.example.com - peer1.org2.example.com certificateAuthorities: - ca.org2.example.com adminPrivateKey: path: crypto-config/peerOrganizations/org2.example.com/users/[email protected]/msp/keystore/1bf30f8854f99c3667ed8664769d8957dc8193414611e93f9d18e2a24374887b_sk signedCert: path: crypto-config/peerOrganizations/org2.example.com/users/[email protected]/msp/signcerts/[email protected]
orderers: orderer.example.com: url: grpcs://localhost:7050 grpcOptions: ssl-target-name-override: orderer.example.com grpc-max-send-message-length: 15 tlsCACerts: path: crypto-config/ordererOrganizations/example.com/msp/tlscacerts/tlsca.example.com-cert.pem
peers: peer0.org2.example.com: url: grpcs://localhost:11051 eventUrl: grpcs://localhost:11053 grpcOptions: ssl-target-name-override: peer0.org2.example.com grpc.keepalive_time_ms: 600000 tlsCACerts: path: crypto-config/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/msp/tlscacerts/tlsca.org2.example.com-cert.pem peer1.org2.example.com: url: grpcs://localhost:12051 eventUrl: grpcs://localhost:12053 grpcOptions: ssl-target-name-override: peer1.org2.example.com grpc.keepalive_time_ms: 600000 tlsCACerts: path: crypto-config/peerOrganizations/org2.example.com/peers/peer1.org2.example.com/msp/tlscacerts/tlsca.org2.example.com-cert.pem
certificateAuthorities: ca.org2.example.com: url: http://localhost:8054 httpOptions: verify: false tlsCACerts: path: crypto-config/peerOrganizations/org2.example.com/ca/ca.org2.example.com-cert.pem registrar: - enrollId: admin enrollSecret: adminpw caName: ca.org2.example.com
And that’s all there is to it! If you’re using a different SDK and have a different approach of writing the fabric client, let’s discuss in the comments section below!
Subscribe to our newsletter
Get the latest updates from our team delivered directly to your inbox.
Related Posts
5 advantages of using Hyperledger Fabric for your Enterprise Blockchain
"Why should I use Hyperledger Fabric for my Enterprise Blockchain?", "What is the preferred way of implementing Hyperledger Fabric?". Everything answered.
Six ways the blockchain can be an advantage for Supply Chain
The blockchain for supply chain is going to be the standard in the industry in the next five years. We've already seen the adoption of the blockchain technology with our supply chain customer, and this article focuses on the advantages that the blockchain has on the supply chain industry.
6 Blockchain frameworks to build Enterprise Blockchain & how to choose them?
Let us help you list some of the open frameworks for blockchain (both public and private blockchain frameworks), that can help you develop your Enterprise Blockchain solution faster and better. Learn more.