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.
...
The join-request should be based on native Hyperledger Fabric 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.
The join-request can be generated with the existing Hyperledger Fabric tool set (configtxlator, peer CLI,configtxgen).
General Workflow:
VendorX/orgX creates common.ConfigGroup (e.g. usingconfigtxgen).
OrgX sends 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 minimum requirement to manage channel update proposals (upload new proposal, sign proposal, list proposals) would require the following interfaces:
proposeUpdate(update string) (proposalID proposalID string, update string)
Channel members can propose a new channel update.Update: the base64 encodedprotos/common.ConfigUpdate
Returns: a new proposalID
addSignature(proposalID string, signature string)
Channel members can add their signature to a proposed channel update.Signature: the base64 encodedprotos/common.ConfigSignature
getProposals() ([]Proposal)
Channel members can view proposals to check the status, display them, or check if the channel policy is already met.
Note: That the channel policy has to be checked manually by the user and not by the chaincode.Returns: the pending(/all) proposals with their update and signatures.
getProposal(proposalID string) (Proposal)
Channel members can request the current status of the proposal.deleteProposal(proposalID string)
...
OrgA receives a channel join request from orgX e.g. via email.
OrgA creates channel update and uses the ProposeUpdate interface of the management chaincode and receives a to store the update with a specific proposalID.
OrgA creates a signature on the proposed channel update and publishes it via the AddSignature interface using the proposalID.
[optional] orgA informs other channel members about the new proposal.
This should normally happen via a Channel Management App of the vendors.OrgB and orgC add their signatures via the AddSignature interface. (This call can be triggered via the custom UI implementation of a vendor).
OrgA monitors the signing process and sends the channel update to the orderer when the channel update policy is fulfilled.
If the channel update has been accepted by the orderer, orgA compiles the channel join response message and sends it back to orgX.
Afterwards, OrgA can delete the proposal using the proposalID.
...