From 5b7e2b6f76319a043b3584cd64d100cae7310a12 Mon Sep 17 00:00:00 2001 From: Christopher Ferris Date: Wed, 12 Apr 2017 14:30:35 -0400 Subject: [PATCH] [FAB-2290] add channel documentation add documentation for channel definition Change-Id: I6b76b7d0513aba7074599b521c31ba56b988e5ea Signed-off-by: Christopher Ferris Signed-off-by: Yacov Manevich --- docs/source/channels.rst | 34 +++++++++++++++++++++++++++++++++- 1 file changed, 33 insertions(+), 1 deletion(-) diff --git a/docs/source/channels.rst b/docs/source/channels.rst index 6914fc16b33..9b0c13d399e 100644 --- a/docs/source/channels.rst +++ b/docs/source/channels.rst @@ -1,4 +1,36 @@ Channels -------- -...coming soon +A Hyperledger Fabric **channel** is a private "subnet" of communication between +two or more specific network members, for the purpose of conducting private and +confidential transactions. A channel is defined by members (organizations), +anchor peers per member, the shared ledger, chaincode application(s) and the ordering service +node(s). Each transaction on the network is executed on a channel, where each +party must be authenticated and authorized to transact on that channel. +Each peer that joins a channel, has its own identity given by a membership services provider (MSP), +which authenticates each peer to its channel peers and services. + +To create a new channel, the client SDK calls configuration system chaincode +and references properties such as **anchor peer**s, and members (organizations). +This request creates a **genesis block** for the channel ledger, which stores configuration +information about the channel policies, members and anchor peers. When adding a +new member to an existing channel, either this genesis block, or if applicable, +a more recent reconfiguration block, is shared with the new member. + +The election of a **leading peer** for each member on a channel determines which +peer communicates with the ordering service on behalf of the member. If no +leader is identified, an algorithm can be used to identify the leader. The consensus +service orders transactions and delivers them, in a block, to each leading peer, +which then distributes the block to its member peers, and across the channel, +using the **gossip** protocol. + +Although any one anchor peer can belong to multiple channels, and therefore +maintain multiple ledgers, no ledger data can pass from one channel to another. +This separation of ledgers, by channel, is defined and implemented by +configuration chaincode, the identity membership service and the gossip data +dissemination protocol. The dissemination of data, which includes information on +transactions, ledger state and channel membership, is restricted to peers with +verifiable membership on the channel. This isolation of peers and ledger data, +by channel, allows network members that require private and confidential +transactions to coexist with business competitors and other restricted members, +on the same blockchain network.