search

hyperledger-labs / fabric-smart-client

The Fabric Smart Client is a new Fabric Client that lets you focus on the business processes and simplifies the development of Fabric-based distributed application.
Apache License 2.0
53 stars 50 forks source link

Provide a discovery service to reduce FSC configuration complexity #165

Open mffrench opened 2 years ago

mffrench commented 2 years ago

With such service, an FSC node may register to the bootstrape node(s) (see: https://github.com/hyperledger-labs/fabric-smart-client/issues/158) and then the discovery service would populate endpoint definitions (url, port, sign cert) to the other FSC node in the network.

-> No need to configure the FSC p2p network manually

Also, in case we define an FSC node as a fabric ready node (ie: crypto type = MSP) the discovery service would handle it too -> No need to declare again Fabric FSC node in the fabric network definitions

Also, connecting to the Fabric network discovery service we could get the fabric peers / orderers definitions -> No need to declare HLF nodes in the fabric network definitions

adecaro commented 2 years ago

Hi @mffrench, let me address your points:

  1. The discovery service you envision is possible but it is not clear to me what it means for Alice's FSC node's endpoints to be populate with information Alice might not be able to use. For example, in a business scenario, Alice needs to connect to Bob. In order to do so, Alice should know at least Bob's PK to be able to recognise him. The way Alice obtains Bob's PK should happen in a way that Alice can believe that that is really Bob's PK. So, what do you think about this: the discovery service collects all info of the registered PKs.

  2. Setting an FSC's node identity to a Fabric identity is in principle doable but at the same time risky when you have a node that connects to multiple networks. I still prefer to use different identities for different purposes. Anyhow, I'm willing to discuss more this and see in which scenarios what you ask makes our life better.

  3. Fabric's discovery service is already used when invoking a chaincode, indeed. Very helpful.

@yacovm , what do you think about all this?

mffrench commented 2 years ago

Hi @adecaro,

about 1: So, what do you think about this: the discovery service collects all info of the registered PKs. : I'm full agree. Also we need probably to take care about cert validity etc... So there maybe should we define an ID service which would be responsible to do such check / storage + queryable by the discovery service...

about 2: that's true we can have some escrow scenario (topology A) where one FSC node can connect to many blockchain network. However, I would tend to avoid an FSC node connecting to many fabric network but would go on a cluster of FSC nodes (on same org) communicating with each other and where each of this node would be an access point to the target blockchain network for the other FSC node (topology B). But here, we should draw some diagram and explicit the plus and cons on both setup.

For topology A: we should have as many crypto ID + FQDN as an FSC node can connect too. For topology B: obviously we will have 1 fabric crypto ID + FQDN per node