Configuring Node SDK’s Connection Profile for Multiple Channel - Multiple Chaincode

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.

1
name: "ORG1 Client"
2
version: "1.0"
3
client:
4
  organization: org1
5
  credentialStore:
6
    path: "./KeyStore/clearingHouse"
7
    cryptoStore:
8
      path: "./KeyStore/clearingHouse"

The above configuration defines the name and the HLF Keystore location which will store the private and public keys.

1
channels:
2
  org1channel:
3
    orderers:
4
      - orderer.example.com
5
    peers:
6
      peer0.org1.example.com:
7
        endorsingPeer: true
8
        chaincodeQuery: true
9
        ledgerQuery: true
10
        eventSource: true
11
      peer1.org1.example.com:
12
        endorsingPeer: false
13
        chaincodeQuery: false
14
        ledgerQuery: false
15
        eventSource: false
16
  org2channel:
17
    orderers:
18
      - orderer.example.com
19
    peers:
20
      peer0.org2.example.com:
21
        endorsingPeer: true
22
        chaincodeQuery: true
23
        ledgerQuery: true
24
        eventSource: true
25
      peer1.org2.example.com:
26
        endorsingPeer: false
27
        chaincodeQuery: false
28
        ledgerQuery: false
29
        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.

1
organizations:
2
  org1:
3
    mspid: ORG1MSP
4
    peers:
5
      - peer0.org1.example.com
6
      - peer1.org1.example.com
7
    certificateAuthorities:
8
      - ca.org1.example.com
9
    adminPrivateKey:
10
      path: crypto-config/peerOrganizations/org1.example.com/users/[email protected]/msp/keystore/7f6d1298f6a1a98a2bae3aa68d2b0a1b32be00f49298c5c1aad2e6ed74b9a72e_sk
11
    signedCert:
12
      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.

1
orderers:
2
  orderer.example.com:
3
    url: grpcs://localhost:7050
4
    grpcOptions:
5
      ssl-target-name-override: orderer.example.com
6
      grpc-max-send-message-length: 15
7
    tlsCACerts:
8
      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.

1
peers:
2
  peer0.org1.example.com:
3
    url: grpcs://localhost:9051
4
    eventUrl: grpcs://localhost:9053
5
    grpcOptions:
6
      ssl-target-name-override: peer0.org1.example.com
7
      grpc.keepalive_time_ms: 600000
8
    tlsCACerts:
9
      path: crypto-config/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/msp/tlscacerts/tlsca.org1.example.com-cert.pem
10
  peer1.org1.example.com:
11
    url: grpcs://localhost:10051
12
    eventUrl: grpcs://localhost:10053
13
    grpcOptions:
14
      ssl-target-name-override: peer1.org1.example.com
15
      grpc.keepalive_time_ms: 600000
16
    tlsCACerts:
17
      path: crypto-config/peerOrganizations/org1.example.com/peers/peer1.org1.example.com/msp/tlscacerts/tlsca.org1.example.com-cert.pem
18

19
  peer0.org2.example.com:
20
    url: grpcs://localhost:13051
21
    eventUrl: grpcs://localhost:13053
22
    grpcOptions:
23
      ssl-target-name-override: peer0.org2.example.com
24
      grpc.keepalive_time_ms: 600000
25
    tlsCACerts:
26
      path: crypto-config/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/msp/tlscacerts/tlsca.org2.example.com-cert.pem
27
  peer1.org2.example.com:
28
    url: grpcs://localhost:14051
29
    eventUrl: grpcs://localhost:14053
30
    grpcOptions:
31
      ssl-target-name-override: peer1.org2.example.com
32
      grpc.keepalive_time_ms: 600000
33
    tlsCACerts:
34
      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.

1
certificateAuthorities:
2
  ca.org1.example.com:
3
    url: http://localhost:8054
4
    httpOptions:
5
      verify: false
6
    tlsCACerts:
7
      path: crypto-config/peerOrganizations/org1.example.com/ca/ca.org1.example.com-cert.pem
8
    registrar:
9
      - enrollId: admin
10
        enrollSecret: adminpw
11
    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.

1
name: "ORG2 Client"
2
version: "1.0"
3

4
client:
5
  organization: org2
6
  credentialStore:
7
    path: "./KeyStore/org2"
8
    cryptoStore:
9
      path: "./KeyStore/org2"
10

11
channels:
12
  org2channel:
13
    orderers:
14
      - orderer.example.com
15
    peers:
16
      peer0.org2.example.com:
17
        endorsingPeer: true
18
        chaincodeQuery: true
19
        ledgerQuery: true
20
        eventSource: true
21
      peer1.org2.example.com:
22
        endorsingPeer: false
23
        chaincodeQuery: false
24
        ledgerQuery: false
25
        eventSource: false
26

27
organizations:
28
  org2:
29
    mspid: ORG2MSP
30
    peers:
31
      - peer0.org2.example.com
32
      - peer1.org2.example.com
33
    certificateAuthorities:
34
      - ca.org2.example.com
35
    adminPrivateKey:
36
      path: crypto-config/peerOrganizations/org2.example.com/users/[email protected]/msp/keystore/1bf30f8854f99c3667ed8664769d8957dc8193414611e93f9d18e2a24374887b_sk
37
    signedCert:
38
      path: crypto-config/peerOrganizations/org2.example.com/users/[email protected]/msp/signcerts/[email protected]
39

40
orderers:
41
  orderer.example.com:
42
    url: grpcs://localhost:7050
43
    grpcOptions:
44
      ssl-target-name-override: orderer.example.com
45
      grpc-max-send-message-length: 15
46
    tlsCACerts:
47
      path: crypto-config/ordererOrganizations/example.com/msp/tlscacerts/tlsca.example.com-cert.pem
48

49
peers:
50
  peer0.org2.example.com:
51
    url: grpcs://localhost:11051
52
    eventUrl: grpcs://localhost:11053
53
    grpcOptions:
54
      ssl-target-name-override: peer0.org2.example.com
55
      grpc.keepalive_time_ms: 600000
56
    tlsCACerts:
57
      path: crypto-config/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/msp/tlscacerts/tlsca.org2.example.com-cert.pem
58
  peer1.org2.example.com:
59
    url: grpcs://localhost:12051
60
    eventUrl: grpcs://localhost:12053
61
    grpcOptions:
62
      ssl-target-name-override: peer1.org2.example.com
63
      grpc.keepalive_time_ms: 600000
64
    tlsCACerts:
65
      path: crypto-config/peerOrganizations/org2.example.com/peers/peer1.org2.example.com/msp/tlscacerts/tlsca.org2.example.com-cert.pem
66

67
certificateAuthorities:
68
  ca.org2.example.com:
69
    url: http://localhost:8054
70
    httpOptions:
71
      verify: false
72
    tlsCACerts:
73
      path: crypto-config/peerOrganizations/org2.example.com/ca/ca.org2.example.com-cert.pem
74
    registrar:
75
      - enrollId: admin
76
        enrollSecret: adminpw
77
    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!

Configuring Node SDK's Connection Profile for Multiple Channel - Multiple Chaincode

The Scenario

ORG1 Connection Profile

ORG2 Connection Profile