github.com/kaituanwang/hyperledger@v2.0.1+incompatible/docs/source/config_update.md (about) 1 # Updating a channel configuration 2 3 *Audience: network administrators, node administrators* 4 5 ## What is a channel configuration? 6 7 Like many complex systems, Hyperledger Fabric networks are comprised of both **structure** and a number related of **processes**. 8 9 * **Structure**: encompassing users (like admins), organizations, peers, ordering nodes, CAs, smart contracts, and applications. 10 * **Process**: the way these structures interact. Most important of these are [Policies](./policies/policies.html), the rules that govern which users can do what, and under what conditions. 11 12 Information identifying the structure of blockchain networks and the processes governing how structures interact are contained in **channel configurations**. These configurations are collectively decided upon by the members of application channels, where transactions between peer organizations happen, and the "orderer system channel" managed by ordering organizations, and are contained in blocks that are committed to the ledger of a channel. 13 14 Because configurations are contained in blocks (the first of these is known as the genesis block with the latest representing the current configuration of the channel), the process for updating a channel configuration (changing the structure by adding members, for example, or processes by modifying channel policies) is known as a **configuration update transaction**. 15 16 In production networks, these configuration update transactions will normally be proposed by a single channel admin after an out of band discussion, just as the initial configuration of the channel will be decided on out of band by the initial members of the channel. 17 18 In this topic, we'll: 19 20 * Show a full sample configuration of an application channel. 21 * Discuss many of the channel parameters that can be edited. 22 * Show the process for updating a channel configuration, including the commands necessary to pull, translate, and scope a configuration into something that humans can read. 23 * Discuss the methods that can be used to edit a channel configuration. 24 * Show the process used to reformat a configuration and get the signatures necessary for it to be approved. 25 26 ## Channel parameters that can be updated 27 28 Channels are highly configurable, but not infinitely so. Once certain things about a channel (for example, the name of the channel) have been specified, they cannot be changed. And changing one of the parameters we'll talk about in this topic requires satisfying the relevant policy as specified in the channel configuration. 29 30 In this section, we'll look a sample channel configuration and show the configuration parameters that can be updated. 31 32 ### Sample channel configuration 33 34 To see what the configuration file of an application channel looks like after it has been pulled and scoped, click **Click here to see the config** below. For ease of readability, it might be helpful to put this config into a viewer that supports JSON folding, like atom or Visual Studio. 35 36 Note: for simplicity, we are only showing an application channel configuration here. The configuration of the orderer system channel is very similar, but not identical, to the configuration of an application channel. However, the same basic rules and structure apply, as do the commands to pull and edit a configuration, as you can see in our topic on [Updating the capability level of a channel](./updating_capabilities.html). 37 38 <details> 39 <summary> 40 **Click here to see the config**. Note that this is the configuration of an application channel, not the orderer system channel. 41 </summary> 42 ``` 43 { 44 "channel_group": { 45 "groups": { 46 "Application": { 47 "groups": { 48 "Org1MSP": { 49 "groups": {}, 50 "mod_policy": "Admins", 51 "policies": { 52 "Admins": { 53 "mod_policy": "Admins", 54 "policy": { 55 "type": 1, 56 "value": { 57 "identities": [ 58 { 59 "principal": { 60 "msp_identifier": "Org1MSP", 61 "role": "ADMIN" 62 }, 63 "principal_classification": "ROLE" 64 } 65 ], 66 "rule": { 67 "n_out_of": { 68 "n": 1, 69 "rules": [ 70 { 71 "signed_by": 0 72 } 73 ] 74 } 75 }, 76 "version": 0 77 } 78 }, 79 "version": "0" 80 }, 81 "Readers": { 82 "mod_policy": "Admins", 83 "policy": { 84 "type": 1, 85 "value": { 86 "identities": [ 87 { 88 "principal": { 89 "msp_identifier": "Org1MSP", 90 "role": "ADMIN" 91 }, 92 "principal_classification": "ROLE" 93 }, 94 { 95 "principal": { 96 "msp_identifier": "Org1MSP", 97 "role": "PEER" 98 }, 99 "principal_classification": "ROLE" 100 }, 101 { 102 "principal": { 103 "msp_identifier": "Org1MSP", 104 "role": "CLIENT" 105 }, 106 "principal_classification": "ROLE" 107 } 108 ], 109 "rule": { 110 "n_out_of": { 111 "n": 1, 112 "rules": [ 113 { 114 "signed_by": 0 115 }, 116 { 117 "signed_by": 1 118 }, 119 { 120 "signed_by": 2 121 } 122 ] 123 } 124 }, 125 "version": 0 126 } 127 }, 128 "version": "0" 129 }, 130 "Writers": { 131 "mod_policy": "Admins", 132 "policy": { 133 "type": 1, 134 "value": { 135 "identities": [ 136 { 137 "principal": { 138 "msp_identifier": "Org1MSP", 139 "role": "ADMIN" 140 }, 141 "principal_classification": "ROLE" 142 }, 143 { 144 "principal": { 145 "msp_identifier": "Org1MSP", 146 "role": "CLIENT" 147 }, 148 "principal_classification": "ROLE" 149 } 150 ], 151 "rule": { 152 "n_out_of": { 153 "n": 1, 154 "rules": [ 155 { 156 "signed_by": 0 157 }, 158 { 159 "signed_by": 1 160 } 161 ] 162 } 163 }, 164 "version": 0 165 } 166 }, 167 "version": "0" 168 } 169 }, 170 "values": { 171 "AnchorPeers": { 172 "mod_policy": "Admins", 173 "value": { 174 "anchor_peers": [ 175 { 176 "host": "peer0.org1.example.com", 177 "port": 7051 178 } 179 ] 180 }, 181 "version": "0" 182 }, 183 "MSP": { 184 "mod_policy": "Admins", 185 "value": { 186 "config": { 187 "admins": [], 188 "crypto_config": { 189 "identity_identifier_hash_function": "SHA256", 190 "signature_hash_family": "SHA2" 191 }, 192 "fabric_node_ous": { 193 "admin_ou_identifier": { 194 "certificate": "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNVakNDQWZpZ0F3SUJBZ0lSQVBYKzVxL21nckhNR280NFB5bjhYRnd3Q2dZSUtvWkl6ajBFQXdJd2N6RUwKTUFrR0ExVUVCaE1DVlZNeEV6QVJCZ05WQkFnVENrTmhiR2xtYjNKdWFXRXhGakFVQmdOVkJBY1REVk5oYmlCRwpjbUZ1WTJselkyOHhHVEFYQmdOVkJBb1RFRzl5WnpFdVpYaGhiWEJzWlM1amIyMHhIREFhQmdOVkJBTVRFMk5oCkxtOXlaekV1WlhoaGJYQnNaUzVqYjIwd0hoY05NVGt4TVRFME1UTTBPREF3V2hjTk1qa3hNVEV4TVRNME9EQXcKV2pCek1Rc3dDUVlEVlFRR0V3SlZVekVUTUJFR0ExVUVDQk1LUTJGc2FXWnZjbTVwWVRFV01CUUdBMVVFQnhNTgpVMkZ1SUVaeVlXNWphWE5qYnpFWk1CY0dBMVVFQ2hNUWIzSm5NUzVsZUdGdGNHeGxMbU52YlRFY01Cb0dBMVVFCkF4TVRZMkV1YjNKbk1TNWxlR0Z0Y0d4bExtTnZiVEJaTUJNR0J5cUdTTTQ5QWdFR0NDcUdTTTQ5QXdFSEEwSUEKQkV5TWtxZndLUkJCWDNKY2xGM3c0UkJZdGFGZytPeFgzSW9RanRrZzJodGxsV3dMV3YrWExXdVl2dkpUMTdxZAp1ei9uWGlWRWhhYnQ2VmVkRnBzanJuR2piVEJyTUE0R0ExVWREd0VCL3dRRUF3SUJwakFkQmdOVkhTVUVGakFVCkJnZ3JCZ0VGQlFjREFnWUlLd1lCQlFVSEF3RXdEd1lEVlIwVEFRSC9CQVV3QXdFQi96QXBCZ05WSFE0RUlnUWcKVytUN0RIb2puYXh0TkpJTHAvREd4UmVONkpPZENSUlBIdVhPNzZXY3k5OHdDZ1lJS29aSXpqMEVBd0lEU0FBdwpSUUloQUtUaHZNaFlBR3p6aVpNR1B1TjFpTTBEcHVpaFNydHJXRHJ6NkQ4QTBXOXBBaUI0MTFrTnJzVjN4ZU05ClNnaHFNc2lzK2QxWThEWE9DOXVrZGhBcU5GZ25FUT09Ci0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K", 195 "organizational_unit_identifier": "admin" 196 }, 197 "client_ou_identifier": { 198 "certificate": "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNVakNDQWZpZ0F3SUJBZ0lSQVBYKzVxL21nckhNR280NFB5bjhYRnd3Q2dZSUtvWkl6ajBFQXdJd2N6RUwKTUFrR0ExVUVCaE1DVlZNeEV6QVJCZ05WQkFnVENrTmhiR2xtYjNKdWFXRXhGakFVQmdOVkJBY1REVk5oYmlCRwpjbUZ1WTJselkyOHhHVEFYQmdOVkJBb1RFRzl5WnpFdVpYaGhiWEJzWlM1amIyMHhIREFhQmdOVkJBTVRFMk5oCkxtOXlaekV1WlhoaGJYQnNaUzVqYjIwd0hoY05NVGt4TVRFME1UTTBPREF3V2hjTk1qa3hNVEV4TVRNME9EQXcKV2pCek1Rc3dDUVlEVlFRR0V3SlZVekVUTUJFR0ExVUVDQk1LUTJGc2FXWnZjbTVwWVRFV01CUUdBMVVFQnhNTgpVMkZ1SUVaeVlXNWphWE5qYnpFWk1CY0dBMVVFQ2hNUWIzSm5NUzVsZUdGdGNHeGxMbU52YlRFY01Cb0dBMVVFCkF4TVRZMkV1YjNKbk1TNWxlR0Z0Y0d4bExtTnZiVEJaTUJNR0J5cUdTTTQ5QWdFR0NDcUdTTTQ5QXdFSEEwSUEKQkV5TWtxZndLUkJCWDNKY2xGM3c0UkJZdGFGZytPeFgzSW9RanRrZzJodGxsV3dMV3YrWExXdVl2dkpUMTdxZAp1ei9uWGlWRWhhYnQ2VmVkRnBzanJuR2piVEJyTUE0R0ExVWREd0VCL3dRRUF3SUJwakFkQmdOVkhTVUVGakFVCkJnZ3JCZ0VGQlFjREFnWUlLd1lCQlFVSEF3RXdEd1lEVlIwVEFRSC9CQVV3QXdFQi96QXBCZ05WSFE0RUlnUWcKVytUN0RIb2puYXh0TkpJTHAvREd4UmVONkpPZENSUlBIdVhPNzZXY3k5OHdDZ1lJS29aSXpqMEVBd0lEU0FBdwpSUUloQUtUaHZNaFlBR3p6aVpNR1B1TjFpTTBEcHVpaFNydHJXRHJ6NkQ4QTBXOXBBaUI0MTFrTnJzVjN4ZU05ClNnaHFNc2lzK2QxWThEWE9DOXVrZGhBcU5GZ25FUT09Ci0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K", 199 "organizational_unit_identifier": "client" 200 }, 201 "enable": true, 202 "orderer_ou_identifier": { 203 "certificate": "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNVakNDQWZpZ0F3SUJBZ0lSQVBYKzVxL21nckhNR280NFB5bjhYRnd3Q2dZSUtvWkl6ajBFQXdJd2N6RUwKTUFrR0ExVUVCaE1DVlZNeEV6QVJCZ05WQkFnVENrTmhiR2xtYjNKdWFXRXhGakFVQmdOVkJBY1REVk5oYmlCRwpjbUZ1WTJselkyOHhHVEFYQmdOVkJBb1RFRzl5WnpFdVpYaGhiWEJzWlM1amIyMHhIREFhQmdOVkJBTVRFMk5oCkxtOXlaekV1WlhoaGJYQnNaUzVqYjIwd0hoY05NVGt4TVRFME1UTTBPREF3V2hjTk1qa3hNVEV4TVRNME9EQXcKV2pCek1Rc3dDUVlEVlFRR0V3SlZVekVUTUJFR0ExVUVDQk1LUTJGc2FXWnZjbTVwWVRFV01CUUdBMVVFQnhNTgpVMkZ1SUVaeVlXNWphWE5qYnpFWk1CY0dBMVVFQ2hNUWIzSm5NUzVsZUdGdGNHeGxMbU52YlRFY01Cb0dBMVVFCkF4TVRZMkV1YjNKbk1TNWxlR0Z0Y0d4bExtTnZiVEJaTUJNR0J5cUdTTTQ5QWdFR0NDcUdTTTQ5QXdFSEEwSUEKQkV5TWtxZndLUkJCWDNKY2xGM3c0UkJZdGFGZytPeFgzSW9RanRrZzJodGxsV3dMV3YrWExXdVl2dkpUMTdxZAp1ei9uWGlWRWhhYnQ2VmVkRnBzanJuR2piVEJyTUE0R0ExVWREd0VCL3dRRUF3SUJwakFkQmdOVkhTVUVGakFVCkJnZ3JCZ0VGQlFjREFnWUlLd1lCQlFVSEF3RXdEd1lEVlIwVEFRSC9CQVV3QXdFQi96QXBCZ05WSFE0RUlnUWcKVytUN0RIb2puYXh0TkpJTHAvREd4UmVONkpPZENSUlBIdVhPNzZXY3k5OHdDZ1lJS29aSXpqMEVBd0lEU0FBdwpSUUloQUtUaHZNaFlBR3p6aVpNR1B1TjFpTTBEcHVpaFNydHJXRHJ6NkQ4QTBXOXBBaUI0MTFrTnJzVjN4ZU05ClNnaHFNc2lzK2QxWThEWE9DOXVrZGhBcU5GZ25FUT09Ci0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K", 204 "organizational_unit_identifier": "orderer" 205 }, 206 "peer_ou_identifier": { 207 "certificate": "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNVakNDQWZpZ0F3SUJBZ0lSQVBYKzVxL21nckhNR280NFB5bjhYRnd3Q2dZSUtvWkl6ajBFQXdJd2N6RUwKTUFrR0ExVUVCaE1DVlZNeEV6QVJCZ05WQkFnVENrTmhiR2xtYjNKdWFXRXhGakFVQmdOVkJBY1REVk5oYmlCRwpjbUZ1WTJselkyOHhHVEFYQmdOVkJBb1RFRzl5WnpFdVpYaGhiWEJzWlM1amIyMHhIREFhQmdOVkJBTVRFMk5oCkxtOXlaekV1WlhoaGJYQnNaUzVqYjIwd0hoY05NVGt4TVRFME1UTTBPREF3V2hjTk1qa3hNVEV4TVRNME9EQXcKV2pCek1Rc3dDUVlEVlFRR0V3SlZVekVUTUJFR0ExVUVDQk1LUTJGc2FXWnZjbTVwWVRFV01CUUdBMVVFQnhNTgpVMkZ1SUVaeVlXNWphWE5qYnpFWk1CY0dBMVVFQ2hNUWIzSm5NUzVsZUdGdGNHeGxMbU52YlRFY01Cb0dBMVVFCkF4TVRZMkV1YjNKbk1TNWxlR0Z0Y0d4bExtTnZiVEJaTUJNR0J5cUdTTTQ5QWdFR0NDcUdTTTQ5QXdFSEEwSUEKQkV5TWtxZndLUkJCWDNKY2xGM3c0UkJZdGFGZytPeFgzSW9RanRrZzJodGxsV3dMV3YrWExXdVl2dkpUMTdxZAp1ei9uWGlWRWhhYnQ2VmVkRnBzanJuR2piVEJyTUE0R0ExVWREd0VCL3dRRUF3SUJwakFkQmdOVkhTVUVGakFVCkJnZ3JCZ0VGQlFjREFnWUlLd1lCQlFVSEF3RXdEd1lEVlIwVEFRSC9CQVV3QXdFQi96QXBCZ05WSFE0RUlnUWcKVytUN0RIb2puYXh0TkpJTHAvREd4UmVONkpPZENSUlBIdVhPNzZXY3k5OHdDZ1lJS29aSXpqMEVBd0lEU0FBdwpSUUloQUtUaHZNaFlBR3p6aVpNR1B1TjFpTTBEcHVpaFNydHJXRHJ6NkQ4QTBXOXBBaUI0MTFrTnJzVjN4ZU05ClNnaHFNc2lzK2QxWThEWE9DOXVrZGhBcU5GZ25FUT09Ci0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K", 208 "organizational_unit_identifier": "peer" 209 } 210 }, 211 "intermediate_certs": [], 212 "name": "Org1MSP", 213 "organizational_unit_identifiers": [], 214 "revocation_list": [], 215 "root_certs": [ 216 "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNVakNDQWZpZ0F3SUJBZ0lSQVBYKzVxL21nckhNR280NFB5bjhYRnd3Q2dZSUtvWkl6ajBFQXdJd2N6RUwKTUFrR0ExVUVCaE1DVlZNeEV6QVJCZ05WQkFnVENrTmhiR2xtYjNKdWFXRXhGakFVQmdOVkJBY1REVk5oYmlCRwpjbUZ1WTJselkyOHhHVEFYQmdOVkJBb1RFRzl5WnpFdVpYaGhiWEJzWlM1amIyMHhIREFhQmdOVkJBTVRFMk5oCkxtOXlaekV1WlhoaGJYQnNaUzVqYjIwd0hoY05NVGt4TVRFME1UTTBPREF3V2hjTk1qa3hNVEV4TVRNME9EQXcKV2pCek1Rc3dDUVlEVlFRR0V3SlZVekVUTUJFR0ExVUVDQk1LUTJGc2FXWnZjbTVwWVRFV01CUUdBMVVFQnhNTgpVMkZ1SUVaeVlXNWphWE5qYnpFWk1CY0dBMVVFQ2hNUWIzSm5NUzVsZUdGdGNHeGxMbU52YlRFY01Cb0dBMVVFCkF4TVRZMkV1YjNKbk1TNWxlR0Z0Y0d4bExtTnZiVEJaTUJNR0J5cUdTTTQ5QWdFR0NDcUdTTTQ5QXdFSEEwSUEKQkV5TWtxZndLUkJCWDNKY2xGM3c0UkJZdGFGZytPeFgzSW9RanRrZzJodGxsV3dMV3YrWExXdVl2dkpUMTdxZAp1ei9uWGlWRWhhYnQ2VmVkRnBzanJuR2piVEJyTUE0R0ExVWREd0VCL3dRRUF3SUJwakFkQmdOVkhTVUVGakFVCkJnZ3JCZ0VGQlFjREFnWUlLd1lCQlFVSEF3RXdEd1lEVlIwVEFRSC9CQVV3QXdFQi96QXBCZ05WSFE0RUlnUWcKVytUN0RIb2puYXh0TkpJTHAvREd4UmVONkpPZENSUlBIdVhPNzZXY3k5OHdDZ1lJS29aSXpqMEVBd0lEU0FBdwpSUUloQUtUaHZNaFlBR3p6aVpNR1B1TjFpTTBEcHVpaFNydHJXRHJ6NkQ4QTBXOXBBaUI0MTFrTnJzVjN4ZU05ClNnaHFNc2lzK2QxWThEWE9DOXVrZGhBcU5GZ25FUT09Ci0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K" 217 ], 218 "signing_identity": null, 219 "tls_intermediate_certs": [], 220 "tls_root_certs": [ 221 "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNWekNDQWY2Z0F3SUJBZ0lSQUtvOGhJS0JjeldFOFQrSUZSVWVmZm93Q2dZSUtvWkl6ajBFQXdJd2RqRUwKTUFrR0ExVUVCaE1DVlZNeEV6QVJCZ05WQkFnVENrTmhiR2xtYjNKdWFXRXhGakFVQmdOVkJBY1REVk5oYmlCRwpjbUZ1WTJselkyOHhHVEFYQmdOVkJBb1RFRzl5WnpFdVpYaGhiWEJzWlM1amIyMHhIekFkQmdOVkJBTVRGblJzCmMyTmhMbTl5WnpFdVpYaGhiWEJzWlM1amIyMHdIaGNOTVRreE1URTBNVE0wT0RBd1doY05Namt4TVRFeE1UTTAKT0RBd1dqQjJNUXN3Q1FZRFZRUUdFd0pWVXpFVE1CRUdBMVVFQ0JNS1EyRnNhV1p2Y201cFlURVdNQlFHQTFVRQpCeE1OVTJGdUlFWnlZVzVqYVhOamJ6RVpNQmNHQTFVRUNoTVFiM0puTVM1bGVHRnRjR3hsTG1OdmJURWZNQjBHCkExVUVBeE1XZEd4elkyRXViM0puTVM1bGVHRnRjR3hsTG1OdmJUQlpNQk1HQnlxR1NNNDlBZ0VHQ0NxR1NNNDkKQXdFSEEwSUFCRUdGY3N6UmNJWXJnUVltK1JwL0owR3NrRXk4OFlDS2xqY2lSY1BoS3FKVWI3L29aSExRSWRtNQpSV0pLcVNZeSs3R2FqWHlROFQxNG1mY2IrM0ZodkpTamJUQnJNQTRHQTFVZER3RUIvd1FFQXdJQnBqQWRCZ05WCkhTVUVGakFVQmdnckJnRUZCUWNEQWdZSUt3WUJCUVVIQXdFd0R3WURWUjBUQVFIL0JBVXdBd0VCL3pBcEJnTlYKSFE0RUlnUWdOZzd3RHhRSkMwREYvQWo5YUwvbXJQVlJNMkozb2VRelEwdnV2cWgzdm5Fd0NnWUlLb1pJemowRQpBd0lEUndBd1JBSWdkYWZXMjJ0WXZuZVd6bEp2Mlg5WC9qM2VCbTdxSG9xejZ2QmV2cENZd3Q4Q0lHYXJJTm5oCnArRnFyaUVoaDI5SDgrcEVTV1NvZXQ1UzFKQVRrd0srNTJMawotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg==" 222 ] 223 }, 224 "type": 0 225 }, 226 "version": "0" 227 } 228 }, 229 "version": "1" 230 }, 231 "Org2MSP": { 232 "groups": {}, 233 "mod_policy": "Admins", 234 "policies": { 235 "Admins": { 236 "mod_policy": "Admins", 237 "policy": { 238 "type": 1, 239 "value": { 240 "identities": [ 241 { 242 "principal": { 243 "msp_identifier": "Org2MSP", 244 "role": "ADMIN" 245 }, 246 "principal_classification": "ROLE" 247 } 248 ], 249 "rule": { 250 "n_out_of": { 251 "n": 1, 252 "rules": [ 253 { 254 "signed_by": 0 255 } 256 ] 257 } 258 }, 259 "version": 0 260 } 261 }, 262 "version": "0" 263 }, 264 "Readers": { 265 "mod_policy": "Admins", 266 "policy": { 267 "type": 1, 268 "value": { 269 "identities": [ 270 { 271 "principal": { 272 "msp_identifier": "Org2MSP", 273 "role": "ADMIN" 274 }, 275 "principal_classification": "ROLE" 276 }, 277 { 278 "principal": { 279 "msp_identifier": "Org2MSP", 280 "role": "PEER" 281 }, 282 "principal_classification": "ROLE" 283 }, 284 { 285 "principal": { 286 "msp_identifier": "Org2MSP", 287 "role": "CLIENT" 288 }, 289 "principal_classification": "ROLE" 290 } 291 ], 292 "rule": { 293 "n_out_of": { 294 "n": 1, 295 "rules": [ 296 { 297 "signed_by": 0 298 }, 299 { 300 "signed_by": 1 301 }, 302 { 303 "signed_by": 2 304 } 305 ] 306 } 307 }, 308 "version": 0 309 } 310 }, 311 "version": "0" 312 }, 313 "Writers": { 314 "mod_policy": "Admins", 315 "policy": { 316 "type": 1, 317 "value": { 318 "identities": [ 319 { 320 "principal": { 321 "msp_identifier": "Org2MSP", 322 "role": "ADMIN" 323 }, 324 "principal_classification": "ROLE" 325 }, 326 { 327 "principal": { 328 "msp_identifier": "Org2MSP", 329 "role": "CLIENT" 330 }, 331 "principal_classification": "ROLE" 332 } 333 ], 334 "rule": { 335 "n_out_of": { 336 "n": 1, 337 "rules": [ 338 { 339 "signed_by": 0 340 }, 341 { 342 "signed_by": 1 343 } 344 ] 345 } 346 }, 347 "version": 0 348 } 349 }, 350 "version": "0" 351 } 352 }, 353 "values": { 354 "AnchorPeers": { 355 "mod_policy": "Admins", 356 "value": { 357 "anchor_peers": [ 358 { 359 "host": "peer0.org2.example.com", 360 "port": 9051 361 } 362 ] 363 }, 364 "version": "0" 365 }, 366 "MSP": { 367 "mod_policy": "Admins", 368 "value": { 369 "config": { 370 "admins": [], 371 "crypto_config": { 372 "identity_identifier_hash_function": "SHA256", 373 "signature_hash_family": "SHA2" 374 }, 375 "fabric_node_ous": { 376 "admin_ou_identifier": { 377 "certificate": "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNVakNDQWZpZ0F3SUJBZ0lSQU1JaCt2V1lHTGs5bUFTT1JNb05iVkl3Q2dZSUtvWkl6ajBFQXdJd2N6RUwKTUFrR0ExVUVCaE1DVlZNeEV6QVJCZ05WQkFnVENrTmhiR2xtYjNKdWFXRXhGakFVQmdOVkJBY1REVk5oYmlCRwpjbUZ1WTJselkyOHhHVEFYQmdOVkJBb1RFRzl5WnpJdVpYaGhiWEJzWlM1amIyMHhIREFhQmdOVkJBTVRFMk5oCkxtOXlaekl1WlhoaGJYQnNaUzVqYjIwd0hoY05NVGt4TVRFME1UTTBPREF3V2hjTk1qa3hNVEV4TVRNME9EQXcKV2pCek1Rc3dDUVlEVlFRR0V3SlZVekVUTUJFR0ExVUVDQk1LUTJGc2FXWnZjbTVwWVRFV01CUUdBMVVFQnhNTgpVMkZ1SUVaeVlXNWphWE5qYnpFWk1CY0dBMVVFQ2hNUWIzSm5NaTVsZUdGdGNHeGxMbU52YlRFY01Cb0dBMVVFCkF4TVRZMkV1YjNKbk1pNWxlR0Z0Y0d4bExtTnZiVEJaTUJNR0J5cUdTTTQ5QWdFR0NDcUdTTTQ5QXdFSEEwSUEKQlBBc2FrbklPUmx2M0pPdnBsQld5VCt0SUlFZWo2U2ZQaTlKTS8yQmYzOWkxdFVpRCt2aVV1Tk43MGlKcXRwRQpUbm50V2htWjA5elAzaVUwcklXWGJLcWpiVEJyTUE0R0ExVWREd0VCL3dRRUF3SUJwakFkQmdOVkhTVUVGakFVCkJnZ3JCZ0VGQlFjREFnWUlLd1lCQlFVSEF3RXdEd1lEVlIwVEFRSC9CQVV3QXdFQi96QXBCZ05WSFE0RUlnUWcKQzl3Y0RKb3FKL2dyUGF3S1d4RnVjNVB3MitTdTBsQVpFcFRGaEdDQlJSTXdDZ1lJS29aSXpqMEVBd0lEU0FBdwpSUUloQU1JaFJOVDVJMHpwTlRaa1dCSkdyblJqSUhkWXYwS2lWL1JKbkd5Yi9XVFFBaUJ6eUJqYnR3L1JyWEV3Clpzb0N1MmtoOUUwOUZIdXl5dGgydUtWc3Y0ZTlnUT09Ci0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K", 378 "organizational_unit_identifier": "admin" 379 }, 380 "client_ou_identifier": { 381 "certificate": "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNVakNDQWZpZ0F3SUJBZ0lSQU1JaCt2V1lHTGs5bUFTT1JNb05iVkl3Q2dZSUtvWkl6ajBFQXdJd2N6RUwKTUFrR0ExVUVCaE1DVlZNeEV6QVJCZ05WQkFnVENrTmhiR2xtYjNKdWFXRXhGakFVQmdOVkJBY1REVk5oYmlCRwpjbUZ1WTJselkyOHhHVEFYQmdOVkJBb1RFRzl5WnpJdVpYaGhiWEJzWlM1amIyMHhIREFhQmdOVkJBTVRFMk5oCkxtOXlaekl1WlhoaGJYQnNaUzVqYjIwd0hoY05NVGt4TVRFME1UTTBPREF3V2hjTk1qa3hNVEV4TVRNME9EQXcKV2pCek1Rc3dDUVlEVlFRR0V3SlZVekVUTUJFR0ExVUVDQk1LUTJGc2FXWnZjbTVwWVRFV01CUUdBMVVFQnhNTgpVMkZ1SUVaeVlXNWphWE5qYnpFWk1CY0dBMVVFQ2hNUWIzSm5NaTVsZUdGdGNHeGxMbU52YlRFY01Cb0dBMVVFCkF4TVRZMkV1YjNKbk1pNWxlR0Z0Y0d4bExtTnZiVEJaTUJNR0J5cUdTTTQ5QWdFR0NDcUdTTTQ5QXdFSEEwSUEKQlBBc2FrbklPUmx2M0pPdnBsQld5VCt0SUlFZWo2U2ZQaTlKTS8yQmYzOWkxdFVpRCt2aVV1Tk43MGlKcXRwRQpUbm50V2htWjA5elAzaVUwcklXWGJLcWpiVEJyTUE0R0ExVWREd0VCL3dRRUF3SUJwakFkQmdOVkhTVUVGakFVCkJnZ3JCZ0VGQlFjREFnWUlLd1lCQlFVSEF3RXdEd1lEVlIwVEFRSC9CQVV3QXdFQi96QXBCZ05WSFE0RUlnUWcKQzl3Y0RKb3FKL2dyUGF3S1d4RnVjNVB3MitTdTBsQVpFcFRGaEdDQlJSTXdDZ1lJS29aSXpqMEVBd0lEU0FBdwpSUUloQU1JaFJOVDVJMHpwTlRaa1dCSkdyblJqSUhkWXYwS2lWL1JKbkd5Yi9XVFFBaUJ6eUJqYnR3L1JyWEV3Clpzb0N1MmtoOUUwOUZIdXl5dGgydUtWc3Y0ZTlnUT09Ci0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K", 382 "organizational_unit_identifier": "client" 383 }, 384 "enable": true, 385 "orderer_ou_identifier": { 386 "certificate": "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNVakNDQWZpZ0F3SUJBZ0lSQU1JaCt2V1lHTGs5bUFTT1JNb05iVkl3Q2dZSUtvWkl6ajBFQXdJd2N6RUwKTUFrR0ExVUVCaE1DVlZNeEV6QVJCZ05WQkFnVENrTmhiR2xtYjNKdWFXRXhGakFVQmdOVkJBY1REVk5oYmlCRwpjbUZ1WTJselkyOHhHVEFYQmdOVkJBb1RFRzl5WnpJdVpYaGhiWEJzWlM1amIyMHhIREFhQmdOVkJBTVRFMk5oCkxtOXlaekl1WlhoaGJYQnNaUzVqYjIwd0hoY05NVGt4TVRFME1UTTBPREF3V2hjTk1qa3hNVEV4TVRNME9EQXcKV2pCek1Rc3dDUVlEVlFRR0V3SlZVekVUTUJFR0ExVUVDQk1LUTJGc2FXWnZjbTVwWVRFV01CUUdBMVVFQnhNTgpVMkZ1SUVaeVlXNWphWE5qYnpFWk1CY0dBMVVFQ2hNUWIzSm5NaTVsZUdGdGNHeGxMbU52YlRFY01Cb0dBMVVFCkF4TVRZMkV1YjNKbk1pNWxlR0Z0Y0d4bExtTnZiVEJaTUJNR0J5cUdTTTQ5QWdFR0NDcUdTTTQ5QXdFSEEwSUEKQlBBc2FrbklPUmx2M0pPdnBsQld5VCt0SUlFZWo2U2ZQaTlKTS8yQmYzOWkxdFVpRCt2aVV1Tk43MGlKcXRwRQpUbm50V2htWjA5elAzaVUwcklXWGJLcWpiVEJyTUE0R0ExVWREd0VCL3dRRUF3SUJwakFkQmdOVkhTVUVGakFVCkJnZ3JCZ0VGQlFjREFnWUlLd1lCQlFVSEF3RXdEd1lEVlIwVEFRSC9CQVV3QXdFQi96QXBCZ05WSFE0RUlnUWcKQzl3Y0RKb3FKL2dyUGF3S1d4RnVjNVB3MitTdTBsQVpFcFRGaEdDQlJSTXdDZ1lJS29aSXpqMEVBd0lEU0FBdwpSUUloQU1JaFJOVDVJMHpwTlRaa1dCSkdyblJqSUhkWXYwS2lWL1JKbkd5Yi9XVFFBaUJ6eUJqYnR3L1JyWEV3Clpzb0N1MmtoOUUwOUZIdXl5dGgydUtWc3Y0ZTlnUT09Ci0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K", 387 "organizational_unit_identifier": "orderer" 388 }, 389 "peer_ou_identifier": { 390 "certificate": "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNVakNDQWZpZ0F3SUJBZ0lSQU1JaCt2V1lHTGs5bUFTT1JNb05iVkl3Q2dZSUtvWkl6ajBFQXdJd2N6RUwKTUFrR0ExVUVCaE1DVlZNeEV6QVJCZ05WQkFnVENrTmhiR2xtYjNKdWFXRXhGakFVQmdOVkJBY1REVk5oYmlCRwpjbUZ1WTJselkyOHhHVEFYQmdOVkJBb1RFRzl5WnpJdVpYaGhiWEJzWlM1amIyMHhIREFhQmdOVkJBTVRFMk5oCkxtOXlaekl1WlhoaGJYQnNaUzVqYjIwd0hoY05NVGt4TVRFME1UTTBPREF3V2hjTk1qa3hNVEV4TVRNME9EQXcKV2pCek1Rc3dDUVlEVlFRR0V3SlZVekVUTUJFR0ExVUVDQk1LUTJGc2FXWnZjbTVwWVRFV01CUUdBMVVFQnhNTgpVMkZ1SUVaeVlXNWphWE5qYnpFWk1CY0dBMVVFQ2hNUWIzSm5NaTVsZUdGdGNHeGxMbU52YlRFY01Cb0dBMVVFCkF4TVRZMkV1YjNKbk1pNWxlR0Z0Y0d4bExtTnZiVEJaTUJNR0J5cUdTTTQ5QWdFR0NDcUdTTTQ5QXdFSEEwSUEKQlBBc2FrbklPUmx2M0pPdnBsQld5VCt0SUlFZWo2U2ZQaTlKTS8yQmYzOWkxdFVpRCt2aVV1Tk43MGlKcXRwRQpUbm50V2htWjA5elAzaVUwcklXWGJLcWpiVEJyTUE0R0ExVWREd0VCL3dRRUF3SUJwakFkQmdOVkhTVUVGakFVCkJnZ3JCZ0VGQlFjREFnWUlLd1lCQlFVSEF3RXdEd1lEVlIwVEFRSC9CQVV3QXdFQi96QXBCZ05WSFE0RUlnUWcKQzl3Y0RKb3FKL2dyUGF3S1d4RnVjNVB3MitTdTBsQVpFcFRGaEdDQlJSTXdDZ1lJS29aSXpqMEVBd0lEU0FBdwpSUUloQU1JaFJOVDVJMHpwTlRaa1dCSkdyblJqSUhkWXYwS2lWL1JKbkd5Yi9XVFFBaUJ6eUJqYnR3L1JyWEV3Clpzb0N1MmtoOUUwOUZIdXl5dGgydUtWc3Y0ZTlnUT09Ci0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K", 391 "organizational_unit_identifier": "peer" 392 } 393 }, 394 "intermediate_certs": [], 395 "name": "Org2MSP", 396 "organizational_unit_identifiers": [], 397 "revocation_list": [], 398 "root_certs": [ 399 "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNVakNDQWZpZ0F3SUJBZ0lSQU1JaCt2V1lHTGs5bUFTT1JNb05iVkl3Q2dZSUtvWkl6ajBFQXdJd2N6RUwKTUFrR0ExVUVCaE1DVlZNeEV6QVJCZ05WQkFnVENrTmhiR2xtYjNKdWFXRXhGakFVQmdOVkJBY1REVk5oYmlCRwpjbUZ1WTJselkyOHhHVEFYQmdOVkJBb1RFRzl5WnpJdVpYaGhiWEJzWlM1amIyMHhIREFhQmdOVkJBTVRFMk5oCkxtOXlaekl1WlhoaGJYQnNaUzVqYjIwd0hoY05NVGt4TVRFME1UTTBPREF3V2hjTk1qa3hNVEV4TVRNME9EQXcKV2pCek1Rc3dDUVlEVlFRR0V3SlZVekVUTUJFR0ExVUVDQk1LUTJGc2FXWnZjbTVwWVRFV01CUUdBMVVFQnhNTgpVMkZ1SUVaeVlXNWphWE5qYnpFWk1CY0dBMVVFQ2hNUWIzSm5NaTVsZUdGdGNHeGxMbU52YlRFY01Cb0dBMVVFCkF4TVRZMkV1YjNKbk1pNWxlR0Z0Y0d4bExtTnZiVEJaTUJNR0J5cUdTTTQ5QWdFR0NDcUdTTTQ5QXdFSEEwSUEKQlBBc2FrbklPUmx2M0pPdnBsQld5VCt0SUlFZWo2U2ZQaTlKTS8yQmYzOWkxdFVpRCt2aVV1Tk43MGlKcXRwRQpUbm50V2htWjA5elAzaVUwcklXWGJLcWpiVEJyTUE0R0ExVWREd0VCL3dRRUF3SUJwakFkQmdOVkhTVUVGakFVCkJnZ3JCZ0VGQlFjREFnWUlLd1lCQlFVSEF3RXdEd1lEVlIwVEFRSC9CQVV3QXdFQi96QXBCZ05WSFE0RUlnUWcKQzl3Y0RKb3FKL2dyUGF3S1d4RnVjNVB3MitTdTBsQVpFcFRGaEdDQlJSTXdDZ1lJS29aSXpqMEVBd0lEU0FBdwpSUUloQU1JaFJOVDVJMHpwTlRaa1dCSkdyblJqSUhkWXYwS2lWL1JKbkd5Yi9XVFFBaUJ6eUJqYnR3L1JyWEV3Clpzb0N1MmtoOUUwOUZIdXl5dGgydUtWc3Y0ZTlnUT09Ci0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K" 400 ], 401 "signing_identity": null, 402 "tls_intermediate_certs": [], 403 "tls_root_certs": [ 404 "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNXRENDQWY2Z0F3SUJBZ0lSQVBoOGJPUzV1aVZLK2xwdjBKZDN5ZUl3Q2dZSUtvWkl6ajBFQXdJd2RqRUwKTUFrR0ExVUVCaE1DVlZNeEV6QVJCZ05WQkFnVENrTmhiR2xtYjNKdWFXRXhGakFVQmdOVkJBY1REVk5oYmlCRwpjbUZ1WTJselkyOHhHVEFYQmdOVkJBb1RFRzl5WnpJdVpYaGhiWEJzWlM1amIyMHhIekFkQmdOVkJBTVRGblJzCmMyTmhMbTl5WnpJdVpYaGhiWEJzWlM1amIyMHdIaGNOTVRreE1URTBNVE0wT0RBd1doY05Namt4TVRFeE1UTTAKT0RBd1dqQjJNUXN3Q1FZRFZRUUdFd0pWVXpFVE1CRUdBMVVFQ0JNS1EyRnNhV1p2Y201cFlURVdNQlFHQTFVRQpCeE1OVTJGdUlFWnlZVzVqYVhOamJ6RVpNQmNHQTFVRUNoTVFiM0puTWk1bGVHRnRjR3hsTG1OdmJURWZNQjBHCkExVUVBeE1XZEd4elkyRXViM0puTWk1bGVHRnRjR3hsTG1OdmJUQlpNQk1HQnlxR1NNNDlBZ0VHQ0NxR1NNNDkKQXdFSEEwSUFCRHlhdEd3R2ZLSmFLazZ5ZmVJMGpObHVyWU5rbjdOaG5uNGVYbnVTd0hCazBRMDY4bnZ1Ujg4awprQTBRWm5vR2ZRWkEwU3RRM3JqVCt4b3BnMHFMcVBhamJUQnJNQTRHQTFVZER3RUIvd1FFQXdJQnBqQWRCZ05WCkhTVUVGakFVQmdnckJnRUZCUWNEQWdZSUt3WUJCUVVIQXdFd0R3WURWUjBUQVFIL0JBVXdBd0VCL3pBcEJnTlYKSFE0RUlnUWdGVDh3UThUcWlIVUxqMU1sY21JRWoreUFPSDF1R1NDNGxFRUVadUlTVkZBd0NnWUlLb1pJemowRQpBd0lEU0FBd1JRSWhBTExXb3Z2Z2JWTnJwcC9mbzZwTStoVXNMTTFkT3NncGRKNlRNd2FFdzQrTkFpQnJ0WFArCno5MFd6ZEQvRWpFWlcyM0xmeVhNMWRscXcyVHJEL3FWUVlGYXJRPT0KLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo=" 405 ] 406 }, 407 "type": 0 408 }, 409 "version": "0" 410 } 411 }, 412 "version": "1" 413 } 414 }, 415 "mod_policy": "Admins", 416 "policies": { 417 "Admins": { 418 "mod_policy": "Admins", 419 "policy": { 420 "type": 3, 421 "value": { 422 "rule": "MAJORITY", 423 "sub_policy": "Admins" 424 } 425 }, 426 "version": "0" 427 }, 428 "Readers": { 429 "mod_policy": "Admins", 430 "policy": { 431 "type": 3, 432 "value": { 433 "rule": "ANY", 434 "sub_policy": "Readers" 435 } 436 }, 437 "version": "0" 438 }, 439 "Writers": { 440 "mod_policy": "Admins", 441 "policy": { 442 "type": 3, 443 "value": { 444 "rule": "ANY", 445 "sub_policy": "Writers" 446 } 447 }, 448 "version": "0" 449 } 450 }, 451 "values": { 452 "Capabilities": { 453 "mod_policy": "Admins", 454 "value": { 455 "capabilities": { 456 "V1_4_2": {} 457 } 458 }, 459 "version": "0" 460 } 461 }, 462 "version": "1" 463 }, 464 "Orderer": { 465 "groups": { 466 "OrdererOrg": { 467 "groups": {}, 468 "mod_policy": "Admins", 469 "policies": { 470 "Admins": { 471 "mod_policy": "Admins", 472 "policy": { 473 "type": 1, 474 "value": { 475 "identities": [ 476 { 477 "principal": { 478 "msp_identifier": "OrdererMSP", 479 "role": "ADMIN" 480 }, 481 "principal_classification": "ROLE" 482 } 483 ], 484 "rule": { 485 "n_out_of": { 486 "n": 1, 487 "rules": [ 488 { 489 "signed_by": 0 490 } 491 ] 492 } 493 }, 494 "version": 0 495 } 496 }, 497 "version": "0" 498 }, 499 "Readers": { 500 "mod_policy": "Admins", 501 "policy": { 502 "type": 1, 503 "value": { 504 "identities": [ 505 { 506 "principal": { 507 "msp_identifier": "OrdererMSP", 508 "role": "MEMBER" 509 }, 510 "principal_classification": "ROLE" 511 } 512 ], 513 "rule": { 514 "n_out_of": { 515 "n": 1, 516 "rules": [ 517 { 518 "signed_by": 0 519 } 520 ] 521 } 522 }, 523 "version": 0 524 } 525 }, 526 "version": "0" 527 }, 528 "Writers": { 529 "mod_policy": "Admins", 530 "policy": { 531 "type": 1, 532 "value": { 533 "identities": [ 534 { 535 "principal": { 536 "msp_identifier": "OrdererMSP", 537 "role": "MEMBER" 538 }, 539 "principal_classification": "ROLE" 540 } 541 ], 542 "rule": { 543 "n_out_of": { 544 "n": 1, 545 "rules": [ 546 { 547 "signed_by": 0 548 } 549 ] 550 } 551 }, 552 "version": 0 553 } 554 }, 555 "version": "0" 556 } 557 }, 558 "values": { 559 "MSP": { 560 "mod_policy": "Admins", 561 "value": { 562 "config": { 563 "admins": [], 564 "crypto_config": { 565 "identity_identifier_hash_function": "SHA256", 566 "signature_hash_family": "SHA2" 567 }, 568 "fabric_node_ous": { 569 "admin_ou_identifier": { 570 "certificate": "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNQVENDQWVTZ0F3SUJBZ0lSQUxCOWVtTVhObkxaWW56TitkMHNJQ2N3Q2dZSUtvWkl6ajBFQXdJd2FURUwKTUFrR0ExVUVCaE1DVlZNeEV6QVJCZ05WQkFnVENrTmhiR2xtYjNKdWFXRXhGakFVQmdOVkJBY1REVk5oYmlCRwpjbUZ1WTJselkyOHhGREFTQmdOVkJBb1RDMlY0WVcxd2JHVXVZMjl0TVJjd0ZRWURWUVFERXc1allTNWxlR0Z0CmNHeGxMbU52YlRBZUZ3MHhPVEV4TVRReE16UTRNREJhRncweU9URXhNVEV4TXpRNE1EQmFNR2t4Q3pBSkJnTlYKQkFZVEFsVlRNUk13RVFZRFZRUUlFd3BEWVd4cFptOXlibWxoTVJZd0ZBWURWUVFIRXcxVFlXNGdSbkpoYm1OcApjMk52TVJRd0VnWURWUVFLRXd0bGVHRnRjR3hsTG1OdmJURVhNQlVHQTFVRUF4TU9ZMkV1WlhoaGJYQnNaUzVqCmIyMHdXVEFUQmdjcWhrak9QUUlCQmdncWhrak9QUU1CQndOQ0FBVGVXYjlZWUdMNmgwMVlFckdzVS9xZmFzUmEKbUpHcFlWZGxsVTNwNldNUTMwZjcyazBFQitPRVQ3WWM3K0w2TWxxTTdNUDJBYnQ2RWUwV2w2OGpjZGxXbzIwdwphekFPQmdOVkhROEJBZjhFQkFNQ0FhWXdIUVlEVlIwbEJCWXdGQVlJS3dZQkJRVUhBd0lHQ0NzR0FRVUZCd01CCk1BOEdBMVVkRXdFQi93UUZNQU1CQWY4d0tRWURWUjBPQkNJRUlMQ0ZrREpzNkJNNzQ1YlVMUUhPY3RscFRtbFIKTTR6ZGpDaHlicW11QVNqb01Bb0dDQ3FHU000OUJBTUNBMGNBTUVRQ0lIQllZTVplZ2V3Wk5BUU1iU3hoQUhZMApqZnNCdDJOOHVTZ3prNHRIUWMvQ0FpQklCSjVXK3AyVTRzYi9zWjhPeS9mZjBIdFBBekZCSWV4VERkUGNnNUxBCk1RPT0KLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo=", 571 "organizational_unit_identifier": "admin" 572 }, 573 "client_ou_identifier": { 574 "certificate": "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNQVENDQWVTZ0F3SUJBZ0lSQUxCOWVtTVhObkxaWW56TitkMHNJQ2N3Q2dZSUtvWkl6ajBFQXdJd2FURUwKTUFrR0ExVUVCaE1DVlZNeEV6QVJCZ05WQkFnVENrTmhiR2xtYjNKdWFXRXhGakFVQmdOVkJBY1REVk5oYmlCRwpjbUZ1WTJselkyOHhGREFTQmdOVkJBb1RDMlY0WVcxd2JHVXVZMjl0TVJjd0ZRWURWUVFERXc1allTNWxlR0Z0CmNHeGxMbU52YlRBZUZ3MHhPVEV4TVRReE16UTRNREJhRncweU9URXhNVEV4TXpRNE1EQmFNR2t4Q3pBSkJnTlYKQkFZVEFsVlRNUk13RVFZRFZRUUlFd3BEWVd4cFptOXlibWxoTVJZd0ZBWURWUVFIRXcxVFlXNGdSbkpoYm1OcApjMk52TVJRd0VnWURWUVFLRXd0bGVHRnRjR3hsTG1OdmJURVhNQlVHQTFVRUF4TU9ZMkV1WlhoaGJYQnNaUzVqCmIyMHdXVEFUQmdjcWhrak9QUUlCQmdncWhrak9QUU1CQndOQ0FBVGVXYjlZWUdMNmgwMVlFckdzVS9xZmFzUmEKbUpHcFlWZGxsVTNwNldNUTMwZjcyazBFQitPRVQ3WWM3K0w2TWxxTTdNUDJBYnQ2RWUwV2w2OGpjZGxXbzIwdwphekFPQmdOVkhROEJBZjhFQkFNQ0FhWXdIUVlEVlIwbEJCWXdGQVlJS3dZQkJRVUhBd0lHQ0NzR0FRVUZCd01CCk1BOEdBMVVkRXdFQi93UUZNQU1CQWY4d0tRWURWUjBPQkNJRUlMQ0ZrREpzNkJNNzQ1YlVMUUhPY3RscFRtbFIKTTR6ZGpDaHlicW11QVNqb01Bb0dDQ3FHU000OUJBTUNBMGNBTUVRQ0lIQllZTVplZ2V3Wk5BUU1iU3hoQUhZMApqZnNCdDJOOHVTZ3prNHRIUWMvQ0FpQklCSjVXK3AyVTRzYi9zWjhPeS9mZjBIdFBBekZCSWV4VERkUGNnNUxBCk1RPT0KLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo=", 575 "organizational_unit_identifier": "client" 576 }, 577 "enable": true, 578 "orderer_ou_identifier": { 579 "certificate": "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNQVENDQWVTZ0F3SUJBZ0lSQUxCOWVtTVhObkxaWW56TitkMHNJQ2N3Q2dZSUtvWkl6ajBFQXdJd2FURUwKTUFrR0ExVUVCaE1DVlZNeEV6QVJCZ05WQkFnVENrTmhiR2xtYjNKdWFXRXhGakFVQmdOVkJBY1REVk5oYmlCRwpjbUZ1WTJselkyOHhGREFTQmdOVkJBb1RDMlY0WVcxd2JHVXVZMjl0TVJjd0ZRWURWUVFERXc1allTNWxlR0Z0CmNHeGxMbU52YlRBZUZ3MHhPVEV4TVRReE16UTRNREJhRncweU9URXhNVEV4TXpRNE1EQmFNR2t4Q3pBSkJnTlYKQkFZVEFsVlRNUk13RVFZRFZRUUlFd3BEWVd4cFptOXlibWxoTVJZd0ZBWURWUVFIRXcxVFlXNGdSbkpoYm1OcApjMk52TVJRd0VnWURWUVFLRXd0bGVHRnRjR3hsTG1OdmJURVhNQlVHQTFVRUF4TU9ZMkV1WlhoaGJYQnNaUzVqCmIyMHdXVEFUQmdjcWhrak9QUUlCQmdncWhrak9QUU1CQndOQ0FBVGVXYjlZWUdMNmgwMVlFckdzVS9xZmFzUmEKbUpHcFlWZGxsVTNwNldNUTMwZjcyazBFQitPRVQ3WWM3K0w2TWxxTTdNUDJBYnQ2RWUwV2w2OGpjZGxXbzIwdwphekFPQmdOVkhROEJBZjhFQkFNQ0FhWXdIUVlEVlIwbEJCWXdGQVlJS3dZQkJRVUhBd0lHQ0NzR0FRVUZCd01CCk1BOEdBMVVkRXdFQi93UUZNQU1CQWY4d0tRWURWUjBPQkNJRUlMQ0ZrREpzNkJNNzQ1YlVMUUhPY3RscFRtbFIKTTR6ZGpDaHlicW11QVNqb01Bb0dDQ3FHU000OUJBTUNBMGNBTUVRQ0lIQllZTVplZ2V3Wk5BUU1iU3hoQUhZMApqZnNCdDJOOHVTZ3prNHRIUWMvQ0FpQklCSjVXK3AyVTRzYi9zWjhPeS9mZjBIdFBBekZCSWV4VERkUGNnNUxBCk1RPT0KLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo=", 580 "organizational_unit_identifier": "orderer" 581 }, 582 "peer_ou_identifier": { 583 "certificate": "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNQVENDQWVTZ0F3SUJBZ0lSQUxCOWVtTVhObkxaWW56TitkMHNJQ2N3Q2dZSUtvWkl6ajBFQXdJd2FURUwKTUFrR0ExVUVCaE1DVlZNeEV6QVJCZ05WQkFnVENrTmhiR2xtYjNKdWFXRXhGakFVQmdOVkJBY1REVk5oYmlCRwpjbUZ1WTJselkyOHhGREFTQmdOVkJBb1RDMlY0WVcxd2JHVXVZMjl0TVJjd0ZRWURWUVFERXc1allTNWxlR0Z0CmNHeGxMbU52YlRBZUZ3MHhPVEV4TVRReE16UTRNREJhRncweU9URXhNVEV4TXpRNE1EQmFNR2t4Q3pBSkJnTlYKQkFZVEFsVlRNUk13RVFZRFZRUUlFd3BEWVd4cFptOXlibWxoTVJZd0ZBWURWUVFIRXcxVFlXNGdSbkpoYm1OcApjMk52TVJRd0VnWURWUVFLRXd0bGVHRnRjR3hsTG1OdmJURVhNQlVHQTFVRUF4TU9ZMkV1WlhoaGJYQnNaUzVqCmIyMHdXVEFUQmdjcWhrak9QUUlCQmdncWhrak9QUU1CQndOQ0FBVGVXYjlZWUdMNmgwMVlFckdzVS9xZmFzUmEKbUpHcFlWZGxsVTNwNldNUTMwZjcyazBFQitPRVQ3WWM3K0w2TWxxTTdNUDJBYnQ2RWUwV2w2OGpjZGxXbzIwdwphekFPQmdOVkhROEJBZjhFQkFNQ0FhWXdIUVlEVlIwbEJCWXdGQVlJS3dZQkJRVUhBd0lHQ0NzR0FRVUZCd01CCk1BOEdBMVVkRXdFQi93UUZNQU1CQWY4d0tRWURWUjBPQkNJRUlMQ0ZrREpzNkJNNzQ1YlVMUUhPY3RscFRtbFIKTTR6ZGpDaHlicW11QVNqb01Bb0dDQ3FHU000OUJBTUNBMGNBTUVRQ0lIQllZTVplZ2V3Wk5BUU1iU3hoQUhZMApqZnNCdDJOOHVTZ3prNHRIUWMvQ0FpQklCSjVXK3AyVTRzYi9zWjhPeS9mZjBIdFBBekZCSWV4VERkUGNnNUxBCk1RPT0KLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo=", 584 "organizational_unit_identifier": "peer" 585 } 586 }, 587 "intermediate_certs": [], 588 "name": "OrdererMSP", 589 "organizational_unit_identifiers": [], 590 "revocation_list": [], 591 "root_certs": [ 592 "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNQVENDQWVTZ0F3SUJBZ0lSQUxCOWVtTVhObkxaWW56TitkMHNJQ2N3Q2dZSUtvWkl6ajBFQXdJd2FURUwKTUFrR0ExVUVCaE1DVlZNeEV6QVJCZ05WQkFnVENrTmhiR2xtYjNKdWFXRXhGakFVQmdOVkJBY1REVk5oYmlCRwpjbUZ1WTJselkyOHhGREFTQmdOVkJBb1RDMlY0WVcxd2JHVXVZMjl0TVJjd0ZRWURWUVFERXc1allTNWxlR0Z0CmNHeGxMbU52YlRBZUZ3MHhPVEV4TVRReE16UTRNREJhRncweU9URXhNVEV4TXpRNE1EQmFNR2t4Q3pBSkJnTlYKQkFZVEFsVlRNUk13RVFZRFZRUUlFd3BEWVd4cFptOXlibWxoTVJZd0ZBWURWUVFIRXcxVFlXNGdSbkpoYm1OcApjMk52TVJRd0VnWURWUVFLRXd0bGVHRnRjR3hsTG1OdmJURVhNQlVHQTFVRUF4TU9ZMkV1WlhoaGJYQnNaUzVqCmIyMHdXVEFUQmdjcWhrak9QUUlCQmdncWhrak9QUU1CQndOQ0FBVGVXYjlZWUdMNmgwMVlFckdzVS9xZmFzUmEKbUpHcFlWZGxsVTNwNldNUTMwZjcyazBFQitPRVQ3WWM3K0w2TWxxTTdNUDJBYnQ2RWUwV2w2OGpjZGxXbzIwdwphekFPQmdOVkhROEJBZjhFQkFNQ0FhWXdIUVlEVlIwbEJCWXdGQVlJS3dZQkJRVUhBd0lHQ0NzR0FRVUZCd01CCk1BOEdBMVVkRXdFQi93UUZNQU1CQWY4d0tRWURWUjBPQkNJRUlMQ0ZrREpzNkJNNzQ1YlVMUUhPY3RscFRtbFIKTTR6ZGpDaHlicW11QVNqb01Bb0dDQ3FHU000OUJBTUNBMGNBTUVRQ0lIQllZTVplZ2V3Wk5BUU1iU3hoQUhZMApqZnNCdDJOOHVTZ3prNHRIUWMvQ0FpQklCSjVXK3AyVTRzYi9zWjhPeS9mZjBIdFBBekZCSWV4VERkUGNnNUxBCk1RPT0KLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo=" 593 ], 594 "signing_identity": null, 595 "tls_intermediate_certs": [], 596 "tls_root_certs": [ 597 "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNRekNDQWVtZ0F3SUJBZ0lRYmVteDhRa200VTNMT1EwWWJibzNmVEFLQmdncWhrak9QUVFEQWpCc01Rc3cKQ1FZRFZRUUdFd0pWVXpFVE1CRUdBMVVFQ0JNS1EyRnNhV1p2Y201cFlURVdNQlFHQTFVRUJ4TU5VMkZ1SUVaeQpZVzVqYVhOamJ6RVVNQklHQTFVRUNoTUxaWGhoYlhCc1pTNWpiMjB4R2pBWUJnTlZCQU1URVhSc2MyTmhMbVY0CllXMXdiR1V1WTI5dE1CNFhEVEU1TVRFeE5ERXpORGd3TUZvWERUSTVNVEV4TVRFek5EZ3dNRm93YkRFTE1Ba0cKQTFVRUJoTUNWVk14RXpBUkJnTlZCQWdUQ2tOaGJHbG1iM0p1YVdFeEZqQVVCZ05WQkFjVERWTmhiaUJHY21GdQpZMmx6WTI4eEZEQVNCZ05WQkFvVEMyVjRZVzF3YkdVdVkyOXRNUm93R0FZRFZRUURFeEYwYkhOallTNWxlR0Z0CmNHeGxMbU52YlRCWk1CTUdCeXFHU000OUFnRUdDQ3FHU000OUF3RUhBMElBQkR4aWpEY3FDMjlja0JOb21lam4KKzliaHVhc05yNlRMZjlIOStibTFPNTZJcko4ZmZ6WnEwaUJ4MWlpdmJSVGRDb2gwQ1d6ZUxRRHQyR3VBTkMrTgpBMDJqYlRCck1BNEdBMVVkRHdFQi93UUVBd0lCcGpBZEJnTlZIU1VFRmpBVUJnZ3JCZ0VGQlFjREFnWUlLd1lCCkJRVUhBd0V3RHdZRFZSMFRBUUgvQkFVd0F3RUIvekFwQmdOVkhRNEVJZ1Fnbm56SFBNRlFsSk50d1NqRXNBUUkKdnBFb3BvK2R4RElxbVB3bW0xczErT1V3Q2dZSUtvWkl6ajBFQXdJRFNBQXdSUUloQUtCTGhsSTlTcVkwTTZzTQozdC9DVG9sSXVEcXNmUVF0eWxhTkZpOTFYZjVZQWlCb1JCVWNCdy95SExTU01BSEwwcXBqVStUWHdDVzBzZ29FCmZ3NUNnU2s4MWc9PQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg==" 598 ] 599 }, 600 "type": 0 601 }, 602 "version": "0" 603 } 604 }, 605 "version": "0" 606 } 607 }, 608 "mod_policy": "Admins", 609 "policies": { 610 "Admins": { 611 "mod_policy": "Admins", 612 "policy": { 613 "type": 3, 614 "value": { 615 "rule": "MAJORITY", 616 "sub_policy": "Admins" 617 } 618 }, 619 "version": "0" 620 }, 621 "BlockValidation": { 622 "mod_policy": "Admins", 623 "policy": { 624 "type": 3, 625 "value": { 626 "rule": "ANY", 627 "sub_policy": "Writers" 628 } 629 }, 630 "version": "0" 631 }, 632 "Readers": { 633 "mod_policy": "Admins", 634 "policy": { 635 "type": 3, 636 "value": { 637 "rule": "ANY", 638 "sub_policy": "Readers" 639 } 640 }, 641 "version": "0" 642 }, 643 "Writers": { 644 "mod_policy": "Admins", 645 "policy": { 646 "type": 3, 647 "value": { 648 "rule": "ANY", 649 "sub_policy": "Writers" 650 } 651 }, 652 "version": "0" 653 } 654 }, 655 "values": { 656 "BatchSize": { 657 "mod_policy": "Admins", 658 "value": { 659 "absolute_max_bytes": 103809024, 660 "max_message_count": 10, 661 "preferred_max_bytes": 524288 662 }, 663 "version": "0" 664 }, 665 "BatchTimeout": { 666 "mod_policy": "Admins", 667 "value": { 668 "timeout": "2s" 669 }, 670 "version": "0" 671 }, 672 "Capabilities": { 673 "mod_policy": "Admins", 674 "value": { 675 "capabilities": { 676 "V1_4_2": {} 677 } 678 }, 679 "version": "0" 680 }, 681 "ChannelRestrictions": { 682 "mod_policy": "Admins", 683 "value": null, 684 "version": "0" 685 }, 686 "ConsensusType": { 687 "mod_policy": "Admins", 688 "value": { 689 "metadata": null, 690 "state": "STATE_NORMAL", 691 "type": "solo" 692 }, 693 "version": "0" 694 } 695 }, 696 "version": "0" 697 } 698 }, 699 "mod_policy": "Admins", 700 "policies": { 701 "Admins": { 702 "mod_policy": "Admins", 703 "policy": { 704 "type": 3, 705 "value": { 706 "rule": "MAJORITY", 707 "sub_policy": "Admins" 708 } 709 }, 710 "version": "0" 711 }, 712 "Readers": { 713 "mod_policy": "Admins", 714 "policy": { 715 "type": 3, 716 "value": { 717 "rule": "ANY", 718 "sub_policy": "Readers" 719 } 720 }, 721 "version": "0" 722 }, 723 "Writers": { 724 "mod_policy": "Admins", 725 "policy": { 726 "type": 3, 727 "value": { 728 "rule": "ANY", 729 "sub_policy": "Writers" 730 } 731 }, 732 "version": "0" 733 } 734 }, 735 "values": { 736 "BlockDataHashingStructure": { 737 "mod_policy": "Admins", 738 "value": { 739 "width": 4294967295 740 }, 741 "version": "0" 742 }, 743 "Capabilities": { 744 "mod_policy": "Admins", 745 "value": { 746 "capabilities": { 747 "V1_4_3": {} 748 } 749 }, 750 "version": "0" 751 }, 752 "Consortium": { 753 "mod_policy": "Admins", 754 "value": { 755 "name": "SampleConsortium" 756 }, 757 "version": "0" 758 }, 759 "HashingAlgorithm": { 760 "mod_policy": "Admins", 761 "value": { 762 "name": "SHA256" 763 }, 764 "version": "0" 765 }, 766 "OrdererAddresses": { 767 "mod_policy": "/Channel/Orderer/Admins", 768 "value": { 769 "addresses": [ 770 "orderer.example.com:7050" 771 ] 772 }, 773 "version": "0" 774 } 775 }, 776 "version": "0" 777 }, 778 "sequence": "3" 779 } 780 ``` 781 </details> 782 783 A config might look intimidating in this form, but once you study it you’ll see that it has a logical structure. 784 785 For example, let's take a look at the config with a few of the tabs closed. 786 787 Note that this is the configuration of an application channel, not the orderer system channel. 788 789 ![Sample config simplified](./images/sample_config.png) 790 791 The structure of the config should now be more obvious. You can see the config groupings: `Channel`, `Application`, and `Orderer`, and the configuration parameters related to each config grouping (we'll talk more about these in the next section), but also where the MSPs representing organizations are. Note that the `Channel` config grouping is below the `Orderer` group config values. 792 793 ### More about these parameters 794 795 In this section, we'll take a deeper look at the configurable values in the context of where they sit in the configuration. 796 797 First, there are config parameters that occur in multiple parts of the configuration: 798 799 * **Policies**. Policies are not just a configuration value (which can be updated as defined in a `mod_policy`), they define the circumstances under which all parameters can be changed. For more information, check out [Policies](./policies/policies.html). 800 801 * **Capabilities**. Ensures that networks and channels process things in the same way, creating deterministic results for things like channel configuration updates and chaincode invocations. Without deterministic results, one peer on a channel might invalidate a transaction while another peer may validate it. For more information, check out [Capabilities](./capabilities_concept.html). 802 803 #### `Channel/Application` 804 805 Governs the configuration parameters unique to application channels (for example, adding or removing channel members). By default, changing these parameters requires the signature of a majority of the application organization admins. 806 807 * **Add orgs to a channel**. To add an organization to a channel, their MSP and other organization parameters must be generated and added here (under `Channel/Application/groups`). 808 809 * **Organization-related parameters**. Any parameters specific to an organization, (identifying an anchor peer, for example, or the certificates of org admins), can be changed. Note that changing these values will by default not require the majority of application organization admins but only an admin of the organization itself. 810 811 #### `Channel/Orderer` 812 813 Governs configuration parameters unique to the ordering service or the orderer system channel, requires a majority of the ordering organizations’ admins (by default there is only one ordering organization, though more can be added, for example when multiple organizations contribute nodes to the ordering service). 814 815 * **Batch size**. These parameters dictate the number and size of transactions in a block. No block will appear larger than `absolute_max_bytes` large or with more than `max_message_count` transactions inside the block. If it is possible to construct a block under `preferred_max_bytes`, then a block will be cut prematurely, and transactions larger than this size will appear in their own block. 816 817 * **Batch timeout**. The amount of time to wait after the first transaction arrives for additional transactions before cutting a block. Decreasing this value will improve latency, but decreasing it too much may decrease throughput by not allowing the block to fill to its maximum capacity. 818 819 * **Block validation**. This policy specifies the signature requirements for a block to be considered valid. By default, it requires a signature from some member of the ordering org. 820 821 * **Consensus type**. To enable the migration of Kafka based ordering services to Raft based ordering services, it is possible to change the consensus type of a channel. For more information, check out [Migrating from Kafka to Raft](./kafka_raft_migration.html). 822 823 * **Raft ordering service parameters**. For a look at the parameters unique to a Raft ordering service, check out [Raft configuration](./raft_configuration.html). 824 825 * **Kafka brokers** (where applicable). When `ConsensusType` is set to `kafka`, the `brokers` list enumerates some subset (or preferably all) of the Kafka brokers for the orderer to initially connect to at startup. 826 827 #### `Channel` 828 829 Governs configuration parameters that both the peer orgs and the ordering service orgs need to consent to, requires both the agreement of a majority of application organization admins and orderer organization admins. 830 831 * **Orderer addresses**. A list of addresses where clients may invoke the orderer `Broadcast` and `Deliver` functions. The peer randomly chooses among these addresses and fails over between them for retrieving blocks. 832 833 * **Hashing structure**. The block data is an array of byte arrays. The hash of the block data is computed as a Merkle tree. This value specifies the width of that Merkle tree. For the time being, this value is fixed to `4294967295` which corresponds to a simple flat hash of the concatenation of the block data bytes. 834 835 * **Hashing algorithm**. The algorithm used for computing the hash values encoded into the blocks of the blockchain. In particular, this affects the data hash, and the previous block hash fields of the block. Note, this field currently only has one valid value (`SHA256`) and should not be changed. 836 837 #### System channel configuration parameters 838 839 Certain configuration values are unique to the orderer system channel. 840 841 * **Channel creation policy.** Defines the policy value which will be set as the mod_policy for the Application group of new channels for the consortium it is defined in. The signature set attached to the channel creation request will be checked against the instantiation of this policy in the new channel to ensure that the channel creation is authorized. Note that this config value is only set in the orderer system channel. 842 843 * **Channel restrictions.** Only editable in the orderer system channel. The total number of channels the orderer is willing to allocate may be specified as `max_count`. This is primarily useful in pre-production environments with weak consortium `ChannelCreation` policies. 844 845 ## Editing a config 846 847 Updating a channel configuration is a three step operation that's conceptually simple: 848 849 1. Get the latest channel config 850 2. Create a modified channel config 851 3. Create a config update transaction 852 853 However, as you'll see, this conceptual simplicity is wrapped in a somewhat convoluted process. As a result, some users might choose to script the process of pulling, translating, and scoping a config update. Users also have the option of how to modify the channel configuration itself, either manually or by using a tool like `jq`. 854 855 We have two tutorials that deal specifically with editing a channel configuration to achieve a specific end: 856 857 * [Adding an Org to a Channel](./channel_update_tutorial.html): shows the process for adding an additional organization to an existing channel. 858 * [Updating channel capabilities](./updating_a_channel.html): shows how to update channel capabilities. 859 860 In this topic, we'll show the process of editing a channel configuration independent of the end goal of the configuration update. 861 862 ### Set environment variables for your config update 863 864 Before you attempt to use the sample commands, make sure to export the following environment variables, which will depend on the way you have structured your deployment. Note that the channel name, `CH_NAME` will have to be set for every channel being updated, as channel configuration updates only apply to the configuration of the channel being updated (with the exception of the ordering system channel, whose configuration is copied into the configuration of application channels by default). 865 866 * `CH_NAME`: the name of the channel being updated. 867 * `TLS_ROOT_CA`: the path to the root CA cert of the TLS CA of the organization proposing the update. 868 * `CORE_PEER_LOCALMSPID`: the name of your MSP. 869 * `CORE_PEER_MSPCONFIGPATH`: the absolute path to the MSP of your organization. 870 * `ORDERER_CONTAINER`: the name of an ordering node container. Note that when targeting the ordering service, you can target any active node in the ordering service. Your requests will be forwarded to the leader automatically. 871 872 Note: this topic will provide default names for the various JSON and protobuf files being pulled and modified (`config_block.pb`, `config_block.json`, etc). You are free to use whatever names you want. However, be aware that unless you go back and erase these files at the end of each config update, you will have to select different when making an additional update. 873 874 ### Step 1: Pull and translate the config 875 876 The first step in updating a channel configuration is getting the latest config block. This is a three step process. First, we'll pull the channel configuration in protobuf format, creating a file called `config_block.pb`. 877 878 Make sure you are in the peer container. 879 880 Now issue: 881 882 ``` 883 peer channel fetch config config_block.pb -o $ORDERER_CONTAINER -c $CH_NAME --tls --cafile $TLS_ROOT_CA 884 ``` 885 886 Next, we'll covert the protobuf version of the channel config into a JSON version called `config_block.json` (JSON files are easier for humans to read and understand): 887 888 ``` 889 configtxlator proto_decode --input config_block.pb --type common.Block --output config_block.json 890 ``` 891 892 Finally, we'll scope out all of the unnecessary metadata from the config, which makes it easier to read. You are free to call this file whatever you want, but in this example we'll call it `config.json`. 893 894 ``` 895 jq .data.data[0].payload.data.config config_block.json > config.json 896 ``` 897 898 Now let's make a copy of `config.json` called `modified_config.json`. **Do not edit ``config.json`` directly**, as we will be using it to compute the difference between ``config.json`` and ``modified_config.json`` in a later step. 899 900 ``` 901 cp config.json modified_config.json 902 ``` 903 904 ### Step 2: Modify the config 905 906 At this point, you have two options of how you want to modify the config. 907 908 1. Open ``modified_config.json`` using the text editor of your choice and make edits. Online tutorials exist that describe how to copy a file from a container that does not have an editor, edit it, and add it back to the container. 909 2. Use ``jq`` to apply edits to the config. 910 911 Whether you choose to edit the config manually or using `jq` depends on your use case. Because `jq` is concise and scriptable (an advantage when the same configuration update will be made to multiple channels), it's the recommend method for performing a channel update. For an example on how `jq` can be used, check out [Updating channel capabilities](./updating_a_channel.html#Create-a-capabilities-config-file), which shows multiple `jq` commands leveraging a capabilities config file called `capabilities.json`. If you are updating something other than the capabilities in your channel, you will have to modify your `jq` command and JSON file accordingly. 912 913 For more information about the content and structure of a channel configuration, check out our [sample channel config](#Sample-channel-configuration) above. 914 915 ### Step 3: Re-encode and submit the config 916 917 Whether you make your config updates manually or using a tool like `jq`, you now have to run the process you ran to pull and scope the config in reverse, along with a step to calculate the difference between the old config and the new one, before submitting the config update to the other administrators on the channel to be approved. 918 919 First, we'll turn our `config.json` file back to protobuf format, creating a file called `config.pb`. Then we'll do the same with our `modified_config.json` file. Afterwards, we'll compute the difference between the two files, creating a file called `config_update.pb`. 920 921 ``` 922 configtxlator proto_encode --input config.json --type common.Config --output config.pb 923 924 configtxlator proto_encode --input modified_config.json --type common.Config --output modified_config.pb 925 926 configtxlator compute_update --channel_id $CH_NAME --original config.pb --updated modified_config.pb --output config_update.pb 927 ``` 928 929 Now that we have calculated the difference between the old config and the new one, we can apply the changes to the config. 930 931 ``` 932 configtxlator proto_decode --input config_update.pb --type common.ConfigUpdate --output config_update.json 933 934 echo '{"payload":{"header":{"channel_header":{"channel_id":"'$CH_NAME'", "type":2}},"data":{"config_update":'$(cat config_update.json)'}}}' | jq . > config_update_in_envelope.json 935 936 configtxlator proto_encode --input config_update_in_envelope.json --type common.Envelope --output config_update_in_envelope.pb 937 ``` 938 939 Submit the config update transaction: 940 941 ``` 942 peer channel update -f config_update_in_envelope.pb -c $CH_NAME -o $ORDERER_CONTAINER --tls true --cafile $TLS_ROOT_CA 943 ``` 944 945 Our config update transaction represents the difference between the original config and the modified one, but the ordering service will translate this into a full channel config. 946 947 ## Get the Necessary Signatures 948 949 Once you’ve successfully generated the new configuration protobuf file, it will need to satisfy the relevant policy for whatever it is you’re trying to change, typically (though not always) by requiring signatures from other organizations. 950 951 *Note: you may be able to script the signature collection, dependent on your application. In general, you may always collect more signatures than are required.* 952 953 The actual process of getting these signatures will depend on how you’ve set up your system, but there are two main implementations. Currently, the Fabric command line defaults to a “pass it along” system. That is, the Admin of the Org proposing a config update sends the update to someone else (another Admin, typically) who needs to sign it. This Admin signs it (or doesn’t) and passes it along to the next Admin, and so on, until there are enough signatures for the config to be submitted. 954 955 This has the virtue of simplicity --- when there are enough signatures, the last admin can simply submit the config transaction (in Fabric, the `peer channel update` command includes a signature by default). However, this process will only be practical in smaller channels, since the “pass it along” method can be time consuming. 956 957 The other option is to submit the update to every Admin on a channel and wait for enough signatures to come back. These signatures can then be stitched together and submitted. This makes life a bit more difficult for the Admin who created the config update (forcing them to deal with a file per signer) but is the recommended workflow for users which are developing Fabric management applications. 958 959 Once the config has been added to the ledger, it will be a best practice to pull it and convert it to JSON to check to make sure everything was added correctly. This will also serve as a useful copy of the latest config. 960 961 <!--- Licensed under Creative Commons Attribution 4.0 International License 962 https://creativecommons.org/licenses/by/4.0/ -->