Architecture to eliminate communication between FSC node and Hyperledger fabric network

[arinddas]

Context:
• Fabric Smart Client Committer technology (Delivery Client) listens to the blocks committed in Fabric network. It also checks for finality of the particular transaction & dependent transactions on the same block.
• To configure the above FSC node need to be equipped with MSP certificates of Fabric network. Also it have to communicate with peers in the network specifically during finality checking.
• Communication of FSC nodes and core fabric peers may not be ideal situation for production.

New Architecture:
• We can shift the responsibility of ‘finality checking’ to ‘server side’ via ‘block listener service’.
• Block listener service will get the block commit notification from the network and check finality, then it will send the final commit message to Kafka cluster.
• FSC node will subscribe to the topic of Kafka cluster and get the result for the same.
• During initial token request submission to ‘transaction submission handler’ same kafka-zk topic-based communication can be used. (optional)

Advantages of the solution:
• Kafka-ZK cluster is highly scalable and resilient in nature.
• TX Commit checking and finality of the tx will be done at a single space at server side, it will help to reduce the redundant work done by all FSC nodes. It help to lower the overall workload and CPU usage of the FSC nodes.
• The architecture will reduce the high interaction from all FSC nodes to fabric peers in turn reduce number of connections to be made at fabric network level.
• If some how FSC node is down still they can read the message from kafka topic at a later point in time without loosing the context of the event.
• Rotation of the certificates at fabric network level will have no effect on FSC node level. It will greatly help to adhere to separation / isolation strategy.