Merge pull request #587 from 125801169/release-2.0

capability_requirements is translated

docs/source/capability_requirements.rst

@@ -1,49 +1,36 @@
-Defining capability requirements
+定义功能需求
 ================================
 
-As discussed in :doc:`capabilities_concept`, capability requirements are defined
-per channel in the channel configuration (found in the channel’s most recent
-configuration block). The channel configuration contains three locations, each
-of which defines a capability of a different type.
+如文档:doc:`capabilities_concept`中所述，在通道配置（在通道的最新配置区块中找到）中，为每个通道定义了功能需求。通道配置包含三个位置，每个位置定义了不同类型的功能。
 
 +------------------+-----------------------------------+----------------------------------------------------+
-| Capability Type  | Canonical Path                    | JSON Path                                          |
+|   功能类型       |       规范路径                    | JSON路径                                          |
 +==================+===================================+====================================================+
-| Channel          | /Channel/Capabilities             | .channel_group.values.Capabilities                 |
+|     通道         | /Channel/Capabilities             | .channel_group.values.Capabilities                 |
 +------------------+-----------------------------------+----------------------------------------------------+
-| Orderer          | /Channel/Orderer/Capabilities     | .channel_group.groups.Orderer.values.Capabilities  |
+|   排序服务        | /Channel/Orderer/Capabilities     | .channel_group.groups.Orderer.values.Capabilities  |
 +------------------+-----------------------------------+----------------------------------------------------+
-| Application      | /Channel/Application/Capabilities | .channel_group.groups.Application.values.          |
+|     应用          | /Channel/Application/Capabilities | .channel_group.groups.Application.values.          |
 |                  |                                   | Capabilities                                       |
 +------------------+-----------------------------------+----------------------------------------------------+
 
-Setting Capabilities
+功能设置
 --------------------
 
-Capabilities are set as part of the channel configuration (either as part of the
-initial configuration -- which we'll talk about in a moment -- or as part of a
-reconfiguration).
+功能设置是通道配置的一部分（要么作为初始配置（稍后我们将讨论），要么作为重新配置的一部分）。
 
-.. note:: For more information about how to update a channel configuration, check
+.. note:: 有关如何更新通道配置的更多信息，请参阅
           out :doc:`config_update`.
 
-Because new channels copy the configuration of the ordering system channel by
-default, new channels will automatically be configured to work with the orderer
-and channel capabilities of the ordering system channel and the application
-capabilities specified by the channel creation transaction.
+由于新通道在默认情况下复制了orderer系统通道的配置，因此将自动配置新通道，使其与orderer系统通道的orderer和通道功能以及通道创建事务指定的应用程序功能一起工作。
 
-Capabilities in an Initial Configuration
+初始配置中的功能
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+在 ``config`` 目录分发的 ``configtx.yaml`` 文件中，有一个 ``Capabilities`` 部分，列举了每种功能类型（通道，orderer和应用程序）的可能功能。
 
-In the ``configtx.yaml`` file distributed in the ``config`` directory of the release
-artifacts, there is a ``Capabilities`` section which enumerates the possible capabilities
-for each capability type (Channel, Orderer, and Application).
+请注意， ``Capabilities`` 在根级别（用于通道功能）和orderer级别（用于orderer功能）各有一个定义部分。
 
-Note that there is a ``Capabilities`` section defined at the root level (for the channel
-capabilities), and at the Orderer level (for orderer capabilities).
-
-When defining the orderer system channel there is no Application section, as those
-capabilities are defined during the creation of an application channel.
+定义orderer系统通道时，没有“应用程序”部分，因为这些功能是在创建应用程序通道时定义的。
 
 .. Licensed under Creative Commons Attribution 4.0 International License
    https://creativecommons.org/licenses/by/4.0/

docs/source/channels.rst

@@ -1,42 +1,16 @@
-Channels
+通道
 ========
 
-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.
+Hyperledger Fabric的 ``通道`` 是两个或多个特定网络成员之间通信的专用“子网”，目的是进行专用和私有交易。通道定义包括成员（组织），每个成员的锚节点，共享账本，链码应用程序和排序服务节点。网络上的每个事务都在一个通道上执行，在该通道上必须对各方进行身份验证并授权在该通道上进行交易。加入通道的每个对等节点都有由成员资格服务提供商（MSP）赋予自己的身份，并且MSP会对每个peer节点所在通道的peer节点和和服务节点进行身份验证。
 
-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
-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.
+要创建新通道，客户端SDK会调用系统链码配置并引用诸如锚节点（ ``anchor peers``）和成员（组织）之类的属性。该请求为通道账本创建一个创世区块（ ``genesis block`` ），存储有关通道策略，成员和锚节点的配置信息。将新成员添加到现有通道时，此创世块或更新的重新配置块（如果可用）将与新成员共享。
 
-.. note:: See the :doc:`configtx` section for more details on the properties
-          and proto structures of config transactions.
+.. note:: 有关配置事务的属性和原型结构的更多详细信息，请参见:doc:`configtx` 
 
-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.
+在通道中每个成员的领导节点（ ``leading peer`` ）的选举，决定了由哪个节点来代表成员与排序服务进行通信，如果没有识别出领导者，则可以使用算法来定义领导者。共识服务对交易进行排序，并以区块的形式将其交付给每个领导节点，然后使用 ``gossip`` 协议将该区块分配给其成员节点，以及整个通道。
+
+尽管任何一个锚节点都可以属于多个通道，因此可以维护多个账本，但是账本数据不可以从一个通道传递到另一个通道。这种基于通道的账本隔离，是由配置链码，MSP服务和gossip协议定义和实现的。数据的分发（包括交易信息，账本状态和通道成员信息）仅限于通道上身份可验证的peer节点。基于通道的节点及账本数据隔离，使得需要私有和机密交易的网络成员与其业务竞争者和其他受限成员可以在同一区块链网络上共存。
 
-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.
 
 .. Licensed under Creative Commons Attribution 4.0 International License
    https://creativecommons.org/licenses/by/4.0/