Skip to content

Commit 5b7e2b6

Browse files
christo4ferrisyacovm
authored andcommitted
[FAB-2290] add channel documentation
add documentation for channel definition Change-Id: I6b76b7d0513aba7074599b521c31ba56b988e5ea Signed-off-by: Christopher Ferris <[email protected]> Signed-off-by: Yacov Manevich <[email protected]>
1 parent c6df437 commit 5b7e2b6

File tree

1 file changed

+33
-1
lines changed

1 file changed

+33
-1
lines changed

docs/source/channels.rst

+33-1
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,36 @@
11
Channels
22
--------
33

4-
...coming soon
4+
A Hyperledger Fabric **channel** is a private "subnet" of communication between
5+
two or more specific network members, for the purpose of conducting private and
6+
confidential transactions. A channel is defined by members (organizations),
7+
anchor peers per member, the shared ledger, chaincode application(s) and the ordering service
8+
node(s). Each transaction on the network is executed on a channel, where each
9+
party must be authenticated and authorized to transact on that channel.
10+
Each peer that joins a channel, has its own identity given by a membership services provider (MSP),
11+
which authenticates each peer to its channel peers and services.
12+
13+
To create a new channel, the client SDK calls configuration system chaincode
14+
and references properties such as **anchor peer**s, and members (organizations).
15+
This request creates a **genesis block** for the channel ledger, which stores configuration
16+
information about the channel policies, members and anchor peers. When adding a
17+
new member to an existing channel, either this genesis block, or if applicable,
18+
a more recent reconfiguration block, is shared with the new member.
19+
20+
The election of a **leading peer** for each member on a channel determines which
21+
peer communicates with the ordering service on behalf of the member. If no
22+
leader is identified, an algorithm can be used to identify the leader. The consensus
23+
service orders transactions and delivers them, in a block, to each leading peer,
24+
which then distributes the block to its member peers, and across the channel,
25+
using the **gossip** protocol.
26+
27+
Although any one anchor peer can belong to multiple channels, and therefore
28+
maintain multiple ledgers, no ledger data can pass from one channel to another.
29+
This separation of ledgers, by channel, is defined and implemented by
30+
configuration chaincode, the identity membership service and the gossip data
31+
dissemination protocol. The dissemination of data, which includes information on
32+
transactions, ledger state and channel membership, is restricted to peers with
33+
verifiable membership on the channel. This isolation of peers and ledger data,
34+
by channel, allows network members that require private and confidential
35+
transactions to coexist with business competitors and other restricted members,
36+
on the same blockchain network.

0 commit comments

Comments
 (0)