For the channel join request, the focus will be on the artifacts that needs to be exchanged between orgX and orgA (as proxy for the complete business network). Only the artifacts to be exchanged is defined, the exchange process, for example via email, is outside the scope of the definition.For the channel join request, the focus will be on the artefacts that needs to be exchanged between orgX and orgA (as proxy for the complete business network). Only the artefacts to be exchanged is defined, the exchange process, for example via email, is outside the scope of the definition.
Also not defined is the interaction between any organization and vendor. It is assumed that either the organization has a direct access to the peer node and can complete all steps required, or that the organization has access to a management UI of the vendor where the relevant join steps are encapsulated.
...
The join-request should be based on native Hyperledger Fabric protobuf definition (protos/common.ConfigGroup) since that includes all required information to represent an organization on a Hyperledger Fabric channel. Furthermore, it integrates well with the existing tooling.
...
VendorX/orgX creates common.ConfigGroup (e.g. usingconfigtxgen,configtxlator). The result can be protobuf encoded or a JSON representation.
OrgX sends the serialized protobuf or the JSON representation to orgA.
VendorA/OrgA generates a channel update based on the current channel configuration (e.g. usingconfigtxlator).
OrgA proposes the update to the other channel members, possibly using the “management” chaincode.
OrgB and orgC, if so defined or required by the business network rules, sign the update and send it to orgA (e.g. usingpeer CLI) possible with the help of a “management” chaincode. -- The “management” chaincode should support relevant rules and policies, such as which organizations are required to sign the update, which kinds of conditions should apply, such as signing algorithm, consensus algorithm, etc. It is important to understand that the “management” chaincode is a technical implementation of the rules and regulations of this very specific business network (business entity) and that it can be conceived that the “management” chaincode will be different between different business networks.
OrgA applies the Fabric channel update with the given signatures, signed by its own organization.
...
The response should look like this:
| Code Block | ||
|---|---|---|
| ||
{ |
...
“channelID”: “mybusinesschannel”,
...
"channelID": "mybusinesschannel", "ordererEndpoints": ["orderer0.org1.com:7050 |
...
"], |
...
“ordererTlsCertificates”: [“YmVpc3BpZWw….”]
"ordererTlsCertificates": ["YmVpc3BpZWw..."] } |
Management Chaincode
The purpose of the management chaincode is to standardize the way how channel updates (new channel members, configuration parameters) are shared will all the participants and how the required signatures to authorize a channel update, are collected.
...