is there some general rule of thumb that advises when it's
appropriate to create multiple channels within a single network, and
when it's appropriate to simply create entirely distinct fabric
networks?

clearly(?), one of the driving rationales behind multiple channels
is the efficiency in sharing commonality across the channels, such as
when many of the same orgs are involved, or some of the same
chaincode, and so on. but does there come a point where there's just
not enough commonality to justify multiple channels in a single
network?

my analogy is someone saying, "hey, let's check all this content
into a git repository," while someone else observes, "well, all that
content really is two fairly disparate code bases, i'm thinking it
makes more sense to create two independent repositories."

is there some analogy with fabric in here somewhere?

rday

recently, i asked if there was any rationale for, rather than
creating another channel within an existing fabric network, just
creating an entirely new network, whereupon christopher ferris
replied:

On Sun, 13 May 2018, Christopher Ferris wrote:

"is there some general rule of thumb that advises when it's
appropriate to create multiple channels within a single network, and
when it's appropriate to simply create entirely distinct fabric
networks?"

no. unless the set of members is disjoint and it were unlikely that
membership would ever be overlapping, there would be no reason that
one should go to that extreme.

Chris

is this explained somewhere in the docs? more to the point, is it
something that should be immediately obvious to the fabric developer?
i know this might sound like reaching, but if you took this position
to its logical extreme, then the entire planet would need only one
network, with a gazillion different channels, which is obviously
absurd.

rday

Some thoughts ...

Blockchain sub-networks get attached to larger business networks, which themselves probably include an IoT sub-network (brokers, devices, gateways, and such) and are interconnected with related sub-networks based on the industry in which the business network operates. Some will be privately owned networks, but many will be complex collaborations among competitors.

When all is said and done, the blockchain network must have a reason to exist, and that will drive its architecture. If all parties in a business network will be transacting, then they may all exist as separate entities on the blockchain network (or not, if a trusted 3rd party can manage the user base). If they have serious concerns regarding information leakage to other members, then you may have to use channels heavily for privacy reasons, but you could also opt to run encryption everywhere to ensure that no one can peek.

If the collaboration is more friendly than that, then they might share a single channel, which also makes life easier for the kind of oversight applications that regulators and administrators use. Strong ACL rules can also protect against too much leakage of competitive info.

So my point is that I don't really see a point where it would occur to me to deploy a separate blockchain network instance instead of just creating a new channel, which of course is an independent ledger on its own.

Kim

Kim Letkeman Senior Technical Staff Member, IBM Watson IoT IoT Blockchain Phone: +1 (613) 762-0352 E-mail: kletkema@...

"rpjday@..." ---05/16/2018 05:40:32 AM--- recently, i asked if there was any rationale for, rather than creating another channel within an e

From: "rpjday@..." <rpjday@...>
To: Christopher Ferris <chris.ferris@...>
Cc: Hyperledger Fabric discussion list <hyperledger-fabric@...>
Date: 05/16/2018 05:40 AM
Subject: Re: [Hyperledger Fabric] multiple channels versus multiple networks?
Sent by: fabric@...

---

 recently, i asked if there was any rationale for, rather than
creating another channel within an existing fabric network, just
creating an entirely new network, whereupon christopher ferris
replied: