Multi channel support in fabric connector

nklincoln commented 4 years ago

It would be nice to provide a more suitable structure to enable multi channel transactions within the Fabric connector. At the moment, whilst "kind of possible" it is not a route that is easily facilitated by Caliper.

Possible Solution

There are a few changes required here. They will impact the Caliper configuration files and workload module (arguments), so now is the idea time to do this as we are making breaking changes

Network Configuration Changes

Move the wallet used by (currently all) clients into the client definition. ie each client is linked to a wallet, meaning that clients may use the same or different wallets, thereby providing them with different identities. This is essential for organisational scoped clients, and useful for within organisations to provide explicit identities.
Within the channel definition, under each channel name, list the clients that have access to the channel.

Through the above changes a user can:

Provide clients with different wallets, which mirrors the current ability to provide clients with their own crypto material
Explicitly name the channels that the client may interact with, without the need for discovery being enabled

Fabric Connector Changes

Since it is possible to deploy the same name and version contract on different channels, we will need to build up a different hierarchy such that a client maps to multiple channels, these channels map to multiple contracts. This implies the need to generate the hierarchy, which may be done in two ways:

If using discovery, it is possible to determine the channel access for the client
If not using discovery, it is possible use the channel/client list

It is now required to be able to prescribe the channel to use for a transaction, which may be done through provision of a new transaction argument, such as targetChannel. If it is not provided, then it is assumed there is only one channel in use, and this default channel is used.

Through the above changes a user can:

Build a transaction to be submitted/evaluated on a named, or default, channel

aklenik commented 4 years ago

Some questions/remarks regarding the issue.

Wallets

I absolutely support the client-level wallet attribute. Flexibility++

Channel access

Channel access in Fabric is determined on the organization level, right? We already know the MspId/Org of a client identity, so based on that we have an access list for channels.

I think this is already used when initializing the channel objects of the CCPs. So I think we already have that information with the current config structure.

Multiple channel support

Fabric contracts in the networkconfig have a globally unique contractID which defaults to the simple chaincode id when omitted. The adapter uses this to map a simple name to a channel-chaincode-version combination. Then only this simple name is referenced in the workload modules, so the channel mechanism of Fabric can be transparent.

Network config example from the CI test: https://github.com/hyperledger/caliper/blob/c6cb4a6a1375b8931783aff8c00f016e89b5cd45/packages/caliper-tests-integration/fabric_tests/phase3/networkconfig.yaml#L47-L83

Workload module invoke example for alternating between channels/chaincodes: https://github.com/hyperledger/caliper/blob/c6cb4a6a1375b8931783aff8c00f016e89b5cd45/packages/caliper-tests-integration/fabric_tests/init.js#L63-L69

Are these the main concerns raised by the issue? Or are there other inflexible parts as well? Beside this: https://github.com/hyperledger/caliper/issues/582

nklincoln commented 4 years ago

The only remaining thoughts are related to the ability to maximise the use of discovery to eliminate the need for the contracts section in the configuration file, as discovery could essentially search across the organization channels for installed contracts.

The above does raise the issue relating to how one could interact with the same name contract on different channels; the current implementation covers this nicely, but a discovery based method would need more help to select the correct contract as it would not have knowledge of the contractID aspect

The Fabric V2 lifecycle will assist here (deploy as X), but we would need such a solution to be applicable to both versioned adaptors

There is an implicit nesting in the current configuration file

channels: 
     mychannel: 
         created: true   
         contracts: 
         - id: marbles 
           contractID: mymarbles

such that we know mymarbles exists as marbles in channel mychannel, so my suggestion pretty much boils down to enabling either the passage of a contractID or the passage of channelName and id to enable absolute resolution of the contract to invoke/query.

aklenik commented 4 years ago

A transparent solution would be to set contractID to id, if no other contractID exists with that name, otherwise set it to mychannel.marbles. So for most of the times, the current behavior would be the fallback.

Or if we detect conflicting ids across multiple channels, then everything will default to channelname.id, to be consistent with contract references.

(It would be nice to keep the current single-string reference for chaincodes, so TX builders could be consistent across SUT connectors.)

miribeiro commented 3 years ago

It would be nice to provide a more suitable structure to enable multi channel transactions within the Fabric connector. At the moment, whilst "kind of possible" it is not a route that is easily facilitated by Caliper.

Possible Solution

There are a few changes required here. They will impact the Caliper configuration files and workload module (arguments), so now is the idea time to do this as we are making breaking changes

Network Configuration Changes

Move the wallet used by (currently all) clients into the client definition. ie each client is linked to a wallet, meaning that clients may use the same or different wallets, thereby providing them with different identities. This is essential for organisational scoped clients, and useful for within organisations to provide explicit identities.

Within the channel definition, under each channel name, list the clients that have access to the channel.

Through the above changes a user can:

Provide clients with different wallets, which mirrors the current ability to provide clients with their own crypto material

Explicitly name the channels that the client may interact with, without the need for discovery being enabled

Fabric Connector Changes

Since it is possible to deploy the same name and version contract on different channels, we will need to build up a different hierarchy such that a client maps to multiple channels, these channels map to multiple contracts. This implies the need to generate the hierarchy, which may be done in two ways:

If using discovery, it is possible to determine the channel access for the client

If not using discovery, it is possible use the channel/client list

It is now required to be able to prescribe the channel to use for a transaction, which may be done through provision of a new transaction argument, such as targetChannel. If it is not provided, then it is assumed there is only one channel in use, and this default channel is used.

Through the above changes a user can:

Build a transaction to be submitted/evaluated on a named, or default, channel

Hi! I'm trying to test an existing network with Caliper (v0.3.2). This network has 3 organizations (Org1, Org2, Org3), with one peer each, and 2 channels. Org1 has access to channel1 and channel2; Org2 has access only to channel1 and Org3 has access only to channel2. I specified in configtx.yaml this relations and enabled the discovery service, using the flag on the launch command.

However, an error appears saying: "[Network]: _initializeInternalChannel: Unable to initialize channel. Attempted to contact 1 Peers. Last error was Error: Channel:channel1 Discovery error:access denied"

This is the output:

Can you explain me why does this happen? Or how can I resolve this issue?

Thank you in advance for your attention!

aklenik commented 3 years ago

@miribeiro This is an error returned by the Fabric SDK, probably caused by a configuration error on the Fabric side. Please check the Fabric docs about discovery and Fabric-related forums.

If you encountered this error by running a Caliper example, then please provide more details, so we can reproduce the error.

hyperledger / caliper