Merge pull request #592 from stone-ch/release-2.0

reviewed #567 #537

docs/source/functionalities.rst

@@ -1,34 +1,34 @@
 Hyperledger Fabric功能
 ==================================
 
-Hyperledger Fabric 是分布式账本技术（DLT）的一种实现，该技术可在模块化区块链架构中提供企业级网络安全性、可扩展性、机密性和性能。Hyperledger Fabric 提供以下区块链网络功能：
+Hyperledger Fabric 是分布式账本技术（DLT）的一种实现，该技术可在模块化区块链架构中提供企业级网络安全性、可扩展性、机密性和高性能。Hyperledger Fabric 提供以下区块链网络功能：
 
 身份管理
 -------------------
 
-为了启用许可网络，Hyperledger Fabric 提供了一个成员身份服务，用于管理用户 ID 并认证网络上的所有参与者。访问控制列表可用于通过授权特定网络操作来提供额外的权限层。例如，可以允许特定用户 ID 调用链码应用程序，但是不能部署新的链码。
+为了使用许可网络，Hyperledger Fabric 提供了一个成员身份服务，用于管理用户 ID 并认证网络上的所有参与者。访问控制列表可用于通过授权特定网络操作来提供额外的权限层。例如，可以允许特定用户 ID 调用链码应用程序，但是不能部署新的链码。
 
 隐私和保密
 ---------------------------
 
-Hyperledger Fabric 使竞争商业利益以及任何需要私人机密交易的群体能够在同一个许可网络上共存。私有 **通道** 是受限制的消息传递路径，可用于为网络成员的特定子集提供交易隐私和机密性。通道上的所有数据（包括交易、成员和通道信息）都是不可见的，并且对于未明确授予对该通道的访问权限的任何网络成员都是不可访问的。
+Hyperledger Fabric 使竞争商业利益以及任何需要私人、机密交易的群体能够在同一个许可网络上共存。私有 **通道** 是受限制的消息传递路径，可用于为网络成员的特定子集提供交易隐私和机密性。通道上的所有数据（包括交易、成员和通道信息）都是不可见的，并且对于未明确授予对该通道的访问权限的任何网络成员都是不可访问的。
 
 高效处理
 --------------------
 
-Hyperledger Fabric 按节点类型分配网络角色。为了向网络提供并发性和并行性，交易执行与交易排序、承诺分开。先执行交易再将其排序，使每个节点能够同时处理多个交易。这种并发执行提高了每个节点的处理效率，并加速了交易交付到排序服务的过程。
+Hyperledger Fabric 按节点类型分配网络角色。为了向网络提供并发性和并行性，交易执行与交易排序、提交分开。先执行交易再将其排序，使每个节点能够同时处理多个交易。这种并发执行提高了每个节点的处理效率，并加速了交易分发到排序服务的过程。
 
-除了启用并行处理之外，分工还可以减轻排序节点对交易执行和账本维护的需求，同时使节点免于排序（共识）工作负载。角色的分叉也限制了授权和认证所需的处理；所有节点都不必信任所有排序节点，反之亦然，因此一方上的进程可以独立于另一方的验证运行。
+除了使用并行处理之外，分工还可以减轻排序节点对交易执行和账本维护的需求，同时使节点免于排序（共识）工作负载。角色的设置也限制了授权和认证所需的处理；所有节点都不必信任所有排序节点，反之亦然，因此一方上的进程可以独立于另一方的验证进程。
 
 链码功能
 -----------------------
 
-Chaincode 应用程序编码由通道上特定交易类型调用的逻辑，例如，确保所有转让所有权的交易都遵循相同的规则和要求。 **系统链码** 与链码不同，其定义整个通道的操作参数。生命周期和配置系统链码定义了通道的规则；背书和验证系统链码定义了背书和验证交易的要求。
+链码应用程序实现了由通道上特定交易类型调用的逻辑。例如，链码定义了变更资产所有权的参数，确保所有转让所有权的交易都遵循相同的规则和要求。 **系统链码** 与应用链码不同，系统链码定义整个通道的操作参数。生命周期和配置系统链码定义了通道的规则；背书和验证系统链码定义了背书和验证交易的要求。
 
 模块化设计
 --------------
 
-Hyperledger Fabric 实现了模块化架构，为网络设计人员提供了功能选择。例如，用于身份验证，排序（一致）和加密的特定算法可以插入到任何 Hyperledger Fabric 网络。这会产生任何行业或公共领域都可以采用的通用区块链架构，并确保其网络可跨市场、监管和地理边界进行互操作。
+Hyperledger Fabric 实现了模块化架构，为网络设计人员提供了功能选择。例如，用于身份验证、排序（共识）和加密的特定算法可以插入到任何 Hyperledger Fabric 网络。这就可以让任何行业或公共领域都采用的通用区块链架构，并确保其网络可跨市场、监管和地理边界进行互操作。
 
 .. Licensed under Creative Commons Attribution 4.0 International License
    https://creativecommons.org/licenses/by/4.0/

docs/source/key_concepts.rst

@@ -1,5 +1,5 @@
 关键概念
-============
+=================
 
 .. toctree::
    :maxdepth: 1

docs/source/logging-control.rst

@@ -1,19 +1,18 @@
-日志
+日志控制
 ===============
 
-综述
+概述
 --------
 
 ``peer`` 和 ``orderer`` 中的日志是由 ``common/flogging`` 包提供的，这个包支持：
 
 -  根据消息的严重性进行日志记录控制
--  基于生成消息的软件记录器的记录控制
--  根据消息的严重性，提供不同的漂亮打印选项
+-  根据生成消息的软件 *记录器* 的记录控制
+-  根据消息的严重性，提供不同的漂亮的打印选项
 
-目前所有日志都指向 ``stderr``，为用户和开发人员提供了按严重性对日志进行全局和日志级别的控制。目前没有针对每个严重性级别提供信息类型的正式规则。提交错误报告时，开发人员可能希望在 DEBUG 级别查看完整的日志
-
-在正常打印的日志中，日志记录级别由不同颜色的四个字符的代码表示，例如，"ERRO" 表示错误，"DEBU" 表示调试，等等。在日志记录上下文中，*记录器*是由开发人员对相关消息组的命名（字符串）。在下面的正常打印的实施例中，记录器 ``ledgermgmt``, ``kvledger``, 和 ``peer`` 都在生成日志。
+目前所有日志都输出到 ``stderr``。为用户和开发人员提供了按严重性对日志进行全局和日志级别的控制。目前没有针对每个严重性级别提供信息类型的正式规范。提交错误报告时，开发人员可能希望在 DEBUG 级别查看完整的日志
 
+在正常打印的日志中，日志记录级别由不同颜色的四个字符的代码表示，例如，"ERRO" 表示错误（ERROR），"DEBU" 表示调试（DEBUG），等等。在日志记录上下文中，*记录器* 是由开发人员对相关消息组的命名（字符串）。在下面的正常打印的示例，记录器 ``ledgermgmt``、``kvledger`` 和 ``peer`` 都在生成日志。
 
 ::
 
@@ -24,10 +23,9 @@
    2018-11-01 15:32:38.357 UTC [peer] func1 -> INFO 006 Auto-detected peer address: 172.24.0.3:7051
    2018-11-01 15:32:38.357 UTC [peer] func1 -> INFO 007 Returning peer0.org1.example.com:7051
 
+可以在运行时创建任意数量的记录器，因此没有记录器的“主列表”，并且日志控件结构无法检查记录器是否确实存在或将生成。
 
-可以在运行时创建任意数量的记录器，因此没有记录器的“主列表”，并且记录控件构造无法检查记录器是否确实存在或将存在。
-
-记录规范
+日志规范
 ---------------------
 
 ``peer`` 和 ``orderer`` 命令的日志记录级别由日志记录规范控制，该规范是通过``FABRIC_LOGGING_SPEC`` 环境变量设置的。 
@@ -44,7 +42,7 @@
    FATAL | PANIC | ERROR | WARNING | INFO | DEBUG
 
 
-日志记录级别本身被视为整体默认值。否则，可以使用如下语法来重写某个或某组记录器
+日志记录级别有默认值。但是，可以使用如下语法来指定某个或某组记录器
 
 ::
 
@@ -62,24 +60,24 @@
 记录格式
 --------------
 
- ``peer`` 和 ``orderer`` 命令的日志记录格式是通过 ``FABRIC_LOGGING_FORMAT`` 环境变量控制的。可以将其设置为格式字符串，例如下例以人类可读的默认控制台格式打印日志。也可以将其设置为 ``json`` 以按照 JSON 格式输出日志。
+ ``peer`` 和 ``orderer`` 命令的日志记录格式是通过 ``FABRIC_LOGGING_FORMAT`` 环境变量控制的。可以将其设置为格式化的字符串，例如默认打印为可读的控制台格式：
 
 ::
 
    "%{color}%{time:2006-01-02 15:04:05.000 MST} [%{module}] %{shortfunc} -> %{level:.4s} %{id:03x}%{color:reset} %{message}"
 
-
+也可以将其设置为 ``json``，按照 JSON 格式输出日志。
 
 链码
 ---------
 
-**链码记录是链码开发人员的责任。**
+**链码日志是链码开发人员的责任。**
 
-作为独立执行的程序，技术上用户提供的链码也可以在 stdout / stderr 上生成输出。虽然这些通道天然地可以调用 “devmode”，但通常会在生产网络上将其禁用，以减轻破坏性代码或恶意代码的滥用。然而，可以通过配置 CORE_VM_DOCKER_ATTACHSTDOUT = true 选项，在每个 peer 节点管理容器（例如，“ netmode”）上启用此输出。
+作为独立执行的程序，技术上用户提供的链码也可以在 stdout / stderr 上生成输出。这自然对 “devmode” 很有用，但在生产环境中通道一般会禁用该模式以减轻有破坏性或恶意代码的滥用。然而，可以通过配置 CORE_VM_DOCKER_ATTACHSTDOUT = true 选项，在每个 Peer 节点管理容器（例如，“netmode”）上启用此输出。
 
-一旦启用，每个链码都将收到由其自身容器ID键入密钥的日志记录通道。写入到 stdout 或 stderr 的任何输出都将逐行集成到 peer 节点的日志中。不建议将其用于生产。
+一旦启用，每个链码都将收到以其自身容器 ID 为键的日志记录通道。写入到 stdout 或 stderr 的任何输出都将逐行集成到 Peer 节点的日志中。不建议将其用于生产。
 
-可以使用适用于容器平台的标准命令，从链码容器查看未转发到 peer 容器的 Stdout 和 stderr。
+可以使用适用于容器平台的标准命令，从链码容器查看未转发到 Peer 容器的 stdout 和 stderr。
 
 ::
 

docs/source/orderer_deploy.md

@@ -1,64 +1,57 @@
-# 设置orderer节点
+# 设置排序节点
 
-在本主题中，我们将描述引导 orderer 节点的过程。如果想了解更多有关不同 orderer 服务实现及其相对优缺点的信息，请查看[conceptual documentation about ordering](./orderer/ordering_service.html).
+本章中，我们将介绍启动排序节点的过程。如果想了解更多有关不同排序服务实现及其优缺点的信息，请查看[conceptual documentation about ordering](./orderer/ordering_service.html)。
 
-大致而言，该主题将涉及一些相互关联的步骤：
+总体来说，本章将涉及以下步骤：
 
+1. 创建排序节点所属的组织（如果尚未创建）
+2. 配置节点 （使用 `orderer.yaml`）
+3. 为排序系统通道创建创世块
+4. 引导排序节点
 
-配置节点（使用 orderer.yaml ）
-为订购系统通道创建创世块
-引导orderer节点
-1. 创建orderer节点所属的组织（如果尚未创建）
-2. 配置节点 (使用 `orderer.yaml` )
-3. 为orderer系统通道创建创世块
-4. 引导orderer节点
-
-注意：本主题假定您已从 docker hub 中提取了 Hyperledger Fabric orderer 镜像。
-
+注意：本章假定您已从 docker hub 中拉取了 Hyperledger Fabric orderer 镜像。
 
 ## 创建组织定义
 
-像 peer 节点一样，所有 orderer 节点都必须属于创建于 orderer 之前的组织。该组织具有由[成员资格服务提供商](./membership/membership.html)(MSP)封装的定义，该定义由认证机构（CA）创建，该机构专门为该组织创建证书和 MSP 。
+和 Peer 节点一样，所有排序节点都必须属于已存在的组织。该组织拥有[成员服务提供者](./membership/membership.html)（MSP），MSP 由 CA（Certificate Authority）创建，CA 专门为该组织创建证书和 MSP 。
 
-有关创建 CA 以及使用 CA 创建用户和 MSP 的信息，请参阅 [Fabric CA user's guide](https://hyperledger-fabric-ca.readthedocs.io/en/latest/users-guide.html).
+有关创建 CA 以及使用 CA 创建用户和 MSP 的信息，请参阅 [Fabric CA user's guide](https://hyperledger-fabric-ca.readthedocs.io/en/latest/users-guide.html)。
 
 ## 配置节点
 
-orderer 节点通过名为 `orderer.yaml` 的 `yaml` 文件来进行配置。 其中 `FABRIC_CFG_PATH` 环境变量需指向一个已经配置好的 `orderer.yaml` 文件，该文件将在文件系统中提取一系列文件和证书。
-
-要阅读示例 `orderer.yaml` ，请查看 [`fabric-samples` github repo](https://github.com/hyperledger/fabric/blob/release-2.0/sampleconfig/orderer.yaml)，并在继续下一步之前**仔细阅读和研究** 。特别注意以下值：
-
-* `LocalMSPID` --- 这是orderer组织的CA生成的MSP的名称，并在此列出orderer组织管理员的位置。
+排序节点通过名为 `orderer.yaml` 的 `yaml` 文件来进行配置。其中 `FABRIC_CFG_PATH` 环境变量需指向一个已经配置好的 `orderer.yaml` 文件，该文件将在文件系统中提取一系列文件和证书。
 
-* `LocalMSPDir` --- 文件系统中本地MSP所在的位置。
+示例 `orderer.yaml` 请查看 [`fabric-samples` github repo](https://github.com/hyperledger/fabric/blob/release-2.0/sampleconfig/orderer.yaml)，在继续下一步之前**仔细阅读和研究** 。需要特别注意以下值：
 
-*  `# TLS enabled`, `Enabled: false`. 在这里可以指定是否要[启用TLS](enable_tls.html). 如果将此值设置为 `true` , 则必须指定相关TLS证书的位置。请注意，这对于Raft节点是必需的。
+* `LocalMSPID` —— 这是排序组织的 MSP 的名称，由 CA 生成，并在这里列出了排序组织管理员。
 
-* `BootstrapFile` --- 这是您将为此排序服务（Orderer节点）生成的创世块的名称。
+* `LocalMSPDir` —— 文件系统中本地 MSP 所在的位置。
 
-* `BootstrapMethod` --- 引导区块的给出方法。目前，这里必须是 `BootstrapFile` 中所指定的文件
+*  `# TLS enabled`, `Enabled: false`。在这里可以指定是否要[启用 TLS ](enable_tls.html)。如果将此值设置为 `true` , 则必须指定相关 TLS 证书的位置。请注意，这对于 Raft 节点是必须的。
 
-如果将此节点部署为集群的一部分（例如，作为Raft节点集群的一部分），请注意 `Cluster` 和 `Consensus` 部分。
+* `BootstrapFile` —— 这是您将为此排序服务生成的创世块的名称。
 
-如果想要部署基于Kafka的排序服务（Orderer），则需要完成 `Kafka` 部分。
+* `BootstrapMethod` —— 给定引导区块的方法。目前，这里只能是 `file`，引导文件是 `BootstrapFile` 中所指定的文件。
 
-## 创建 orderer 的创世区块
+如果将此节点部署为集群的一部分（例如，作为 Raft 节点集群的一部分），请注意 `Cluster` 和 `Consensus` 部分。
 
-新创建通道的第一个区块称为“创世区块”。如果在创建**新网络**的过程中创建了创世区块 （换言之，如果正在创建的 orderer 节点不会加入现有 orderer 集群），则该创世区块将是 “orderer系统通道”（也称为“排序系统通道”），由 orderer 管理员管理的特殊通道，其中包括允许创建通道的组织的列表。*orderer系统通道的创世区块很特殊：必须先创建它并将其包含在节点的配置中，然后才能启动该节点。*
+如果想要部署基于 Kafka 的排序服务，则需要完成 `Kafka` 部分。
 
-想要了解如何使用 `configtxgen` 创建创世区块，请查阅 [Channel Configuration (configtx)](configtx.html)
+## 创建排序节点的创世区块
 
+新创建通道的第一个区块称为“创世区块”。如果在创建**新网络**的过程中创建了创世区块（换言之，正在创建的排序节点不会加入现有的排序节点集群），则该创世区块将是“排序系统通道”的第一个区块，“排序系统通道”是一个特殊的通道，它由排序管理员管理，排序管理员包括了允许创建通道的组织列表。*排序系统通道的创世区块很特殊：必须先创建它并将其包含在节点的配置中，然后才能启动该节点。*
 
-## 引导 ordering 节点
+想要了解如何使用 `configtxgen` 创建创世区块，请查阅 [通道配置（configtx）](configtx.html)
 
-完成构建镜像，创建 MSP，配置 `orderer.yaml` 并创建了创世区块之后，就可以使用如下类似命令来启动 orderer 排序：
+## 引导排序节点
 
+当您完成构建镜像，创建 MSP，配置 `orderer.yaml` 并创建了创世区块之后，就可以使用类似下面的命令来启动排序节点：
 
 ```
 docker-compose -f docker-compose-cli.yaml up -d --no-deps orderer.example.com
 ```
 
-注意用本地 orderer 节点地址替换 `orderer.example.com`.
+注意用你的排序节点地址来替换 `orderer.example.com`。
 
 <!--- Licensed under Creative Commons Attribution 4.0 International License
 https://creativecommons.org/licenses/by/4.0/) -->