Commit ec0df5ad authored by David Enyeart's avatar David Enyeart Committed by Gerrit Code Review
Browse files

Merge "[FAB-9836] Glossary"

parents 25381f6b 3f9d2c94
......@@ -20,7 +20,24 @@ Each organization added to a channel should identify at least one of its
peers as an anchor peer. The anchor peer address is stored in the
configuration block of the channel. Each organization that has a peer
should have at least one (there can be more than one) of its peers
defined as an anchor peer.
defined as an anchor peer. Thus, the anchor peer is used as the entry point
from another organization's peer on the same channel to get the message
delivered to each of the peers in the anchor peer's org.
.. _glossary_ACL:
ACL
---
Access Control List. Used to associate policies with specific resources.
Access control lists are defined in the ``configtx.yaml`` file, used by
configtxgen to build channel configurations. An ACL is formatted as a key-value
pair consisting of a resource function name followed by the name of the group
with access to the resource. A set of default ACLs are provided in the
``configtx.yaml`` file and can be overridden by editing the configtx.yaml
for the orderer system channel (new channels copy the configuration of the
orderer system channel by default) or the ``configtx.yaml`` for a specific
channel.
.. _Block:
......@@ -227,11 +244,11 @@ invoke, and an array of arguments.
Leading Peer
------------
Each Member_ can own multiple peers on each channel that
it subscribes to. One of these peers is serves as the leading peer for the channel,
Each Organization_ can own multiple peers on each channel that
it subscribes to. One of these peers serves as the leading peer for the channel,
in order to communicate with the network ordering service on behalf of the
member. The ordering service "delivers" blocks to the leading peer(s) on a
channel, who then distribute them to other peers within the same member cluster.
organization. The ordering service "delivers" blocks to the leading peer(s) on a
channel, who then distribute them to other peers within the same org cluster.
.. _Ledger:
......@@ -327,8 +344,24 @@ read/write operations to the ledger. Peers are owned and maintained by members.
Policy
------
There are policies for endorsement, validation, chaincode
management and network/channel management.
How members come to agreement on accepting or rejecting changes to the network
or a channel. Policies include criteria for adding or removing members or peers
from the network. They also include the requirements needed to update a channel
or endorsements required to instantiate chaincode and have a transaction
validated by a channel.
Policies are fundamental to the way Fabric works because they allow the identity
associated with a request to be checked against the policy associated with the
resource (such as a chaincode API) needed to fulfill the request. There are two
types of policies -- ``Signature`` and ``ImplicitMeta``. ``Signature`` policies
define specific users who must sign in order for a policy to be satisfied such
as ``Org1.Peer OR Org2.Peer``. ``ImplicitMeta`` policies are only valid in the
context of configuration and aggregate the result of policies deeper in the
configuration hierarchy which are ultimately defined by Signature policies.
They use a different syntax, for example ``"MAJORITY Admins``. Policies can be
defined globally for the entire network in the ``configtx.yaml`` file under
``Application: Policies``, but channel specific policies may also be defined in
the channel profile section as well.
.. _Proposal:
......
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment