I'm not going to get into the architectural merits and/or deficiencies of Hyperledger Fabric, Quorum or Corda here, but I'll attempt to answer the question in terms of scalability/maintenance from a resource perspective.

Each Fabric peer will have a separate ledger and state store per channel. At least one peer will also need to make connection to the ordering service for each channel. From a storage perspective, there is not a significant overhead in using channels from a peer perspective although if the transaction rate is low for a channel you might end up with a little bit of storage overhead based on the block structure because transaction for different channels cannot be in the same block. From a network connection perspective, there's always overhead in the number of connections, but I don't think Fabric channels actually create more connections for the peer (the ordering service of course needs to scale). The use of an ordering service does potentially add additional storage to the overall network, but that will be addressed in the future by archive / pruning of the orderer.

Corda is peer to peer architecture; in your example, each bank node must connect to the node of every other bank it wishes to transact with. Additionally, in order to avoid "double spend", each flow will communicate with a notary (and generally this means that each node in the transaction will communicate with the notary). From a storage perspective, each Corda node only stores data for transactions it is involved in. So in this way, a Corda node will typically store less data than a Fabric node in the case where a channel has more than 2 members. The notaries of course currently store the entire history for each type of asset they are responsible for.

The Quorum architecture actually typically involves running two processes per node / member: an Ethereum process and a Constellation process. Constellation is used to handle private contracts and private data. And again, in this case it is also a peer to peer / point to point architecture. If a bank wants to conduct a private transaction with another bank, Constellation is used to handle the private data with the hash being sent to the "public" ledger managed by the Ethereum nodes. Quorum did recently add support for z-contracts which run on the Ethereum nodes in order to prevent double-spending of assets in private contracts.

As you can see, while the architecture / processing models of Hyperledger Fabric, Cord and Quorum are different, in the end the resource requirements per member and overall for the network are actually more similar than they seem.

I'll also say that each architecture has it's own complexities in actually getting things setup and running.

Hope this helps.

-- G


-----------------------------------------
Gari Singh
Distinguished Engineer, CTO - IBM Blockchain
IBM Middleware
550 King St
Littleton, MA 01460
Cell: 978-846-7499
garis@us.ibm.com
-----------------------------------------

-----hyperledger-fabric-bounces@lists.hyperledger.org wrote: -----
To: hyperledger-fabric@lists.hyperledger.org
From: Nathan Aw
Sent by: hyperledger-fabric-bounces@lists.hyperledger.org
Date: 12/09/2017 08:08AM
Subject: Re: [Hyperledger-fabric] Multiple Channels in Hyperledger Leading to Multiple Point to Point Connection and Multiple Ledgers

Dear all,

2nd try. Any quick inputs + thoughts?

Thank you.