--- # # The network connection profile provides client applications the information about the target # blockchain network that are necessary for the applications to interact with it. These are all # knowledge that must be acquired from out-of-band sources. This file provides such a source. # name: "Akachain" # # Any properties with an "x-" prefix will be treated as application-specific, exactly like how naming # in HTTP headers or swagger properties work. The SDK will simply ignore these fields and leave # them for the applications to process. This is a mechanism for different components of an application # to exchange information that are not part of the standard schema described below. In particular, # the "x-type" property with the "hlfv1" value example below is used by Hyperledger Composer to # determine the type of Fabric networks (v0.6 vs. v1.0) it needs to work with. # x-type: "hlfv1" # # Describe what the target network is/does. # description: "Akachain Network" # # Schema version of the content. Used by the SDK to apply the corresponding parsing rules. # version: "1.0" # # The client section will be added on a per org basis see org1.yaml and org2.yaml # # client # # [Optional]. But most apps would have this section so that channel objects can be constructed # based on the content below. If an app is creating channels, then it likely will not need this # section. # channels: mychannel: orderers: - orderer.example.com peers: peer0.org1.example.com: endorsingPeer: true chaincodeQuery: true ledgerQuery: true eventSource: true peer0.org2.example.com: endorsingPeer: true chaincodeQuery: true ledgerQuery: true eventSource: true organizations: org1: mspid: org1MSP peers: - peer0.org1.example.com # Fabric-CA servers. certificateAuthorities: - ca_org1 org2: mspid: org2MSP peers: - peer0.org2.example.com # Fabric-CA servers. certificateAuthorities: - ca_org2 # # List of orderers to send transaction and channel create/update requests to. For the time # being only one orderer is needed. If more than one is defined, which one get used by the # SDK is implementation specific. Consult each SDK's documentation for its handling of orderers. # orderers: orderer.example.com: url: grpcs://orderer.example.com:7050 grpcOptions: ssl-target-name-override: orderer.example.com grpc-max-send-message-length: -1 tlsCACerts: path: /shared/crypto-config/ica-orderer-ca-chain.pem peers: peer0.org1.example.com: url: grpcs://peer0.org1.example.com:7051 grpcOptions: ssl-target-name-override: peer0.org1.example.com tlsCACerts: path: /shared/crypto-config/peerOrganizations/org1.example.com/tlsca/tlsca.org1.example.com-cert.pem peer0.org2.example.com: url: grpcs://peer0.org2.example.com:9051 grpcOptions: ssl-target-name-override: peer0.org2.example.com tlsCACerts: path: /shared/crypto-config/peerOrganizations/org2.example.com/tlsca/tlsca.org2.example.com-cert.pem # # Fabric-CA is a special kind of Certificate Authority provided by Hyperledger Fabric which allows # certificate management to be done via REST APIs. Application may choose to use a standard # Certificate Authority instead of Fabric-CA, in which case this section would not be specified. # certificateAuthorities: ca_org1: url: https://ca_org1:7054 # the properties specified under this object are passed to the 'http' client verbatim when # making the request to the Fabric-CA server httpOptions: verify: false tlsCACerts: path: /shared/crypto-config/peerOrganizations/org1.example.com/tlsca/tlsca.org1.example.com-cert.pem # [Optional] The optional name of the CA. caName: ca-org1 ca_org2: url: https://ca_org2:8054 # the properties specified under this object are passed to the 'http' client verbatim when # making the request to the Fabric-CA server httpOptions: verify: false tlsCACerts: path: /shared/crypto-config/peerOrganizations/org2.example.com/tlsca/tlsca.org2.example.com-cert.pem # [Optional] The optional name of the CA. caName: ca-org2