Skip to content

Commit

Permalink
FAB-9665 change bold to code block
Browse files Browse the repository at this point in the history
rather than use bold type, use code block for such
things as ``anchor peer``, etc.

Change-Id: Ia3c1a65b404240fefe59f26f415daa376d3a183a
Signed-off-by: Christopher Ferris <chrisfer@us.ibm.com>
  • Loading branch information
christo4ferris committed May 9, 2018
1 parent f65e128 commit 64a5b7b
Showing 1 changed file with 5 additions and 5 deletions.
10 changes: 5 additions & 5 deletions docs/source/channels.rst
Original file line number Diff line number Diff line change
@@ -1,7 +1,7 @@
Channels
========

A Hyperledger Fabric **channel** is a private "subnet" of communication between
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
Expand All @@ -11,21 +11,21 @@ Each peer that joins a channel, has its own identity given by a membership servi
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 peers**, and members (organizations).
This request creates a **genesis block** for the channel ledger, which stores configuration
and references properties such as ``anchor peers``, 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.

.. note:: See the :doc:`configtx` section for more more details on the properties
and proto structures of config transactions.

The election of a **leading peer** for each member on a channel determines which
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.
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.
Expand Down

0 comments on commit 64a5b7b

Please sign in to comment.