Re: Multiple Channels in Hyperledger Leading to Multiple Point to Point Connection and Multiple Ledgers
So generally speaking, fabric code tends to have data structures scoped per channel, so there is a certain memory overhead in having lots of channels, but I have never made any experiments to figure how much of an overhead that is so I can't attest whether there are issues with reasonable numbers.toggle quoted messageShow quoted text
You can try using some memory monitoring system that draws graphs like graphite and grafana and do some experiments to see, if you're interested.
From: Nathan Aw <nathan.mk.aw@...>
Date: 09/12/2017 03:07 PM
Subject: Re: [Hyperledger-fabric] Multiple Channels in Hyperledger Leading to Multiple Point to Point Connection and Multiple Ledgers
Sent by: hyperledger-fabric-bounces@...
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