-
Notifications
You must be signed in to change notification settings - Fork 8.9k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
[FAB-2290] add channel documentation
add documentation for channel definition Change-Id: I6b76b7d0513aba7074599b521c31ba56b988e5ea Signed-off-by: Christopher Ferris <chrisfer@us.ibm.com> Signed-off-by: Yacov Manevich <yacovm@il.ibm.com>
- Loading branch information
1 parent
c6df437
commit 5b7e2b6
Showing
1 changed file
with
33 additions
and
1 deletion.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -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. |