-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathnetwork-config.yaml
218 lines (191 loc) · 9.36 KB
/
network-config.yaml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
---
#
# 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: "balance-transfer"
#
# 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: "Balance Transfer 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:
# name of the channel
composerchannel:
# Required. list of orderers designated by the application to use for transactions on this
# channel. This list can be a result of access control ("org1" can only access "ordererA"), or
# operational decisions to share loads from applications among the orderers. The values must
# be "names" of orgs defined under "organizations/peers"
orderers:
- orderer.xuyuntech.com
# Required. list of peers from participating orgs
peers:
peer0.trt.xuyuntech.com:
# [Optional]. will this peer be sent transaction proposals for endorsement? The peer must
# have the chaincode installed. The app can also use this property to decide which peers
# to send the chaincode install request. Default: true
endorsingPeer: true
# [Optional]. will this peer be sent query proposals? The peer must have the chaincode
# installed. The app can also use this property to decide which peers to send the
# chaincode install request. Default: true
chaincodeQuery: true
# [Optional]. will this peer be sent query proposals that do not require chaincodes, like
# queryBlock(), queryTransaction(), etc. Default: true
ledgerQuery: true
# [Optional]. will this peer be the target of the SDK's listener registration? All peers can
# produce events but the app typically only needs to connect to one to listen to events.
# Default: true
eventSource: true
# [Optional]. what chaincodes are expected to exist on this channel? The application can use
# this information to validate that the target peers are in the expected state by comparing
# this list with the query results of getInstalledChaincodes() and getInstantiatedChaincodes()
chaincodes:
# the format follows the "cannonical name" of chaincodes by fabric code
- mycc:v0
#
# list of participating organizations in this network
#
organizations:
Trt:
mspid: TrtMSP
peers:
- peer0.trt.xuyuntech.com
# - peer1.org1.example.com
# [Optional]. Certificate Authorities issue certificates for identification purposes in a Fabric based
# network. Typically certificates provisioning is done in a separate process outside of the
# runtime network. Fabric-CA is a special certificate authority that provides a REST APIs for
# dynamic certificate management (enroll, revoke, re-enroll). The following section is only for
# Fabric-CA servers.
certificateAuthorities:
- ca-trt
# [Optional]. If the application is going to make requests that are reserved to organization
# administrators, including creating/updating channels, installing/instantiating chaincodes, it
# must have access to the admin identity represented by the private key and signing certificate.
# Both properties can be the PEM string or local path to the PEM file. Note that this is mainly for
# convenience in development mode, production systems should not expose sensitive information
# this way. The SDK should allow applications to set the org admin identity via APIs, and only use
# this route as an alternative when it exists.
adminPrivateKey:
path: artifacts/channel/crypto-config/peerOrganizations/trt.xuyuntech.com/users/[email protected]/msp/keystore/8e12c2c5efb8facfc6d71c565b518d24612cad684c0f2cb4b9506b49ebd89b68_sk
signedCert:
path: artifacts/channel/crypto-config/peerOrganizations/trt.xuyuntech.com/users/[email protected]/msp/signcerts/[email protected]
# the profile will contain public information about organizations other than the one it belongs to.
# These are necessary information to make transaction lifecycles work, including MSP IDs and
# peers with a public URL to send transaction proposals. The file will not contain private
# information reserved for members of the organization, such as admin key and certificate,
# fabric-ca registrar enroll ID and secret, etc.
# Org2:
# mspid: Org2MSP
# peers:
# - peer0.org2.example.com
# - peer1.org2.example.com
# certificateAuthorities:
# - ca-org2
# adminPrivateKey:
# path: artifacts/channel/crypto-config/peerOrganizations/org2.example.com/users/[email protected]/msp/keystore/1995b11d6573ed3be52fcd7a5fa477bc0f183e1f5f398c8281d0ce7c2c75a076_sk
# signedCert:
# path: artifacts/channel/crypto-config/peerOrganizations/org2.example.com/users/[email protected]/msp/signcerts/[email protected]
#
# 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.xuyuntech.com:
url: grpcs://localhost:7050
# these are standard properties defined by the gRPC library
# they will be passed in as-is to gRPC client constructor
grpcOptions:
ssl-target-name-override: orderer.xuyuntech.com
grpc-max-send-message-length: 15
tlsCACerts:
path: artifacts/channel/crypto-config/ordererOrganizations/xuyuntech.com/orderers/orderer.xuyuntech.com/tls/ca.crt
#
# List of peers to send various requests to, including endorsement, query
# and event listener registration.
#
peers:
peer0.trt.xuyuntech.com:
# this URL is used to send endorsement and query requests
url: grpcs://localhost:7051
# this URL is used to connect the EventHub and registering event listeners
eventUrl: grpcs://localhost:7053
grpcOptions:
ssl-target-name-override: peer0.trt.xuyuntech.com
tlsCACerts:
path: artifacts/channel/crypto-config/peerOrganizations/trt.xuyuntech.com/peers/peer0.trt.xuyuntech.com/tls/ca.crt
# peer1.org1.example.com:
# url: grpcs://localhost:7056
# eventUrl: grpcs://localhost:7058
# grpcOptions:
# ssl-target-name-override: peer1.org1.example.com
# tlsCACerts:
# path: artifacts/channel/crypto-config/peerOrganizations/org1.example.com/peers/peer1.org1.example.com/tls/ca.crt
# peer0.org2.example.com:
# url: grpcs://localhost:8051
# eventUrl: grpcs://localhost:8053
# grpcOptions:
# ssl-target-name-override: peer0.org2.example.com
# tlsCACerts:
# path: artifacts/channel/crypto-config/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/ca.crt
# peer1.org2.example.com:
# url: grpcs://localhost:8056
# eventUrl: grpcs://localhost:8058
# grpcOptions:
# ssl-target-name-override: peer1.org2.example.com
# tlsCACerts:
# path: artifacts/channel/crypto-config/peerOrganizations/org2.example.com/peers/peer1.org2.example.com/tls/ca.crt
#
# 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-trt:
url: https://localhost: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: artifacts/channel/crypto-config/peerOrganizations/trt.xuyuntech.com/ca/ca.trt.xuyuntech.com-cert.pem
# Fabric-CA supports dynamic user enrollment via REST APIs. A "root" user, a.k.a registrar, is
# needed to enroll and invoke new users.
registrar:
- enrollId: admin
enrollSecret: adminpw
# [Optional] The optional name of the CA.
caName: ca-trt
# ca-org2:
# url: https://localhost:8054
# httpOptions:
# verify: false
# tlsCACerts:
# path: artifacts/channel/crypto-config/peerOrganizations/org2.example.com/ca/ca.org2.example.com-cert.pem
# registrar:
# - enrollId: admin
# enrollSecret: adminpw
# # [Optional] The optional name of the CA.
# caName: ca-org2