toggle quoted messageShow quoted text
Hi Gari, Yacov,
Thank you so much for the detailed sharing. This clear things up.
On Sun, Dec 10, 2017 at 3:51 AM, Gari Singh <garis@...>
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.
Distinguished Engineer, CTO - IBM Blockchain
550 King St
Littleton, MA 01460
-----hyperledger-fabric-bounces@... wrote: -----
From: Nathan Aw
Sent by: email@example.com
Date: 12/09/2017 08:08AM
Subject: Re: [Hyperledger-fabric] Multiple Channels in Hyperledger Leading to Multiple Point to Point Connection and Multiple Ledgers
2nd try. Any quick inputs + thoughts?
On Thu, Dec 7, 2017 at 12:49 AM, Nathan Aw <nathan.mk.aw@...> wrote:
Understand that privacy in HyperLedger is achieved via a per-channel basis and one ledger per channel. My question -- will there be scalability/maintenance issues if there are many members (>50) with many channels due to this design?
Say there are 31 banks in a network (a bit of a stretch... just assuming), each bank needs to transact with the other 31 banks.
Bank A setup 30 channels to the other 30 banks.
Bank B setup 30 channels to the other 30 banks.
Bank C setup 30 channels to the other 30 banks
The list goes on.
30 * 30 = 900 channels.
Comparing this to Quorum where Zero Knowledge Proofs are used and R3 Corda via Notaries, how does the channel design in Hyperledger stack up to these differing technologies?
Hyperledger-fabric mailing list