Merge pull request #605 from hyperledger-labs/release-2.0

Release 2.0
hyperledger · Mar 31, 2020 · 29d1bd7 · 29d1bd7
2 parents ef6bf1a + 50b5f63
commit 29d1bd7
Show file tree

Hide file tree

Showing 8 changed files with 176 additions and 205 deletions.
diff --git a/docs/source/fabric-sdks.rst b/docs/source/fabric-sdks.rst
@@ -1,12 +1,10 @@
-Hyperledger Fabric SDKs
+Hyperledger Fabric SDK
 =======================
 
-Hyperledger Fabric intends to offer a number of SDKs for a wide variety of
-programming languages. The first two delivered are the Node.js and Java
-SDKs. We hope to provide Python, REST and Go SDKs in a subsequent release.
+Hyperledger Fabric 提供多种编程语言的 SDK。目前提供了 Node.js 和 Java 两种 SDK。我们希望在后续的版本中提供 Python、 REST 和 Go SDK。
 
-  * `Hyperledger Fabric Node SDK documentation <https://hyperledger.github.io/fabric-sdk-node/>`__.
-  * `Hyperledger Fabric Java SDK documentation <https://hyperledger.github.io/fabric-gateway-java/>`__.
+  * `Hyperledger Fabric Node SDK 文档 <https://hyperledger.github.io/fabric-sdk-node/>`__.
+  * `Hyperledger Fabric Java SDK 文档 <https://hyperledger.github.io/fabric-gateway-java/>`__.
 
 .. Licensed under Creative Commons Attribution 4.0 International License
    https://creativecommons.org/licenses/by/4.0/
diff --git a/docs/source/membership/membership.md b/docs/source/membership/membership.md
diff --git a/docs/source/peers/peers.md b/docs/source/peers/peers.md
@@ -1,4 +1,4 @@
-# Peers
+# Peer 节点
 
 一个区块链网络主要由一些 *peer 节点*（或者简单称之为 *peers*）组成。Peers 是网络的基本元素，因为他们存储了账本和智能合约。之前我们说过一个账本能够将由智能合约（在 Hyperledger Fabric 中是包含在一个 *链码*中的，稍后会详细介绍）生成的所有交易无法篡改地记录下来。智能合约和账本用来将在网络中共享的 *流程* 和共享的 *信息* 对应地封装起来。一个 peer 的这些方面是理解一个 Fabric 网络的很好的起点。
 

diff --git a/docs/source/policies/policies.md b/docs/source/policies/policies.md
@@ -1,19 +1,18 @@
-# Policies
+# 策略
 
-**Audience**: Architects, application and smart contract developers,
-administrators
+**受众**： 架构师，应用和智能合约开发者，管理员
 
-In this topic, we'll cover:
+本主题将包含：
 
-* [What is a policy](#what-is-a-policy)
-* [Why are policies needed](#why-are-policies-needed)
-* [How are policies implemented throughout Fabric](#how-are-policies-implemented-throughout-fabric)
-* [Fabric policy domains](#fabric-policy-domains)
-* [How do you write a policy in Fabric](#how-do-you-write-a-policy-in-fabric)
-* [Fabric chaincode lifecycle](#fabric-chaincode-lifecyle)
-* [Overriding policy definitions](#overriding-policy-definitions)
+* [策略是什么](#策略是什么)
+* [为什么需要策略](#为什么需要策略)
+* [Fabric 是如何实现策略](#Fabric是如何实现策略的)
+* [Fabric 策略作用域](#策略作用域)
+* [如何将策略写入 Fabric](#如何将策略写入Fabric)
+* [Fabric 链码生命周期](#Fabric链码生命周期)
+* [覆盖策略定义]](#覆盖策略定义)
 
-## What is a policy
+## 策略是什么
 
 At its most basic level, a policy is a set of rules that define the structure
 for how decisions are made and specific outcomes are reached. To that end,
@@ -39,7 +38,7 @@ actions are described by a policy which defines who can perform the action.
 Simply put, everything you want to do on a Fabric network is controlled by a
 policy.
 
-## Why are policies needed
+## 为什么需要策略
 
 Policies are one of the things that make Hyperledger Fabric different from other
 blockchains like Ethereum or Bitcoin. In those systems, transactions can be
@@ -59,7 +58,7 @@ they are written, policies evaluate the collection of signatures attached to
 transactions and proposals and validate if the signatures fulfill the governance
 agreed to by the network.
 
-## How are policies implemented throughout Fabric
+## Fabric是如何实现策略的
 
 Policies are implemented at different levels of a Fabric network. Each policy
 domain governs different aspects of how a network operates.
@@ -137,7 +136,7 @@ required to sign (approve) any configuration _update_. It is the policy that
 defines how the policy is updated. Thus, each channel configuration element
 includes a reference to a policy which governs its modification.
 
-## The policy domains
+## 策略作用域
 
 While Fabric policies are flexible and can be configured to meet the needs of a
 network, the policy structure naturally leads to a division between the domains
@@ -166,7 +165,7 @@ to create channels. Application channels and ACLs are the mechanism that
 consortium organizations use to add or remove members from a channel and restrict
 access to data and smart contracts on a channel.
 
-## How do you write a policy in Fabric
+## 如何将策略写入Fabric
 
 If you want to change anything in Fabric, the policy associated with the resource
 describes **who** needs to approve it, either with an explicit sign off from
@@ -346,7 +345,7 @@ BlockValidation:
 ```
 </details>
 
-## Fabric chaincode lifecycle
+## Fabric链码生命周期
 
 In the Fabric 2.0 release, a new chaincode lifecycle process was introduced,
 whereby a more democratic process is used to govern chaincode on the network.
@@ -466,7 +465,7 @@ For a deeper dive on how to write an endorsement policy refer to the topic on
   requires that organizations agree to the parameters that define a chaincode,
   such as name, version, and the chaincode endorsement policy.
 
-## Overriding policy definitions
+## 覆盖策略定义
 
 Hyperledger Fabric includes default policies which are useful for getting started,
 developing, and testing your blockchain, but they are meant to be customized

diff --git a/docs/source/readwrite.rst b/docs/source/readwrite.rst
@@ -1,20 +1,20 @@
 读写集语义
 ~~~~~~~~~~~~~~~~~~~~~~~~
 
-本文档讨论有关读写集语义实现的详细信息
+本文档讨论有关读写集语义实现的详细信息。
 
-事务模拟和读写集
+交易模拟和读写集
 '''''''''''''''''''''''''''''''''''''''''
 
-在``endorser``上进行交易模拟时，会为交易准备一个读写集。``读集``包含一个键列表和在模拟过程中所要读取的键版本号（而不是值）。``写集``含有键列表（尽管可能被读集中的键覆盖），和事务所写入的新值。如果事务执行的更新内容是删除键，则为键设置一个删除标记（代替新值）。
+ ``背书节点`` 在模拟交易期间，会为交易准备一个读写集。``读集`` 包含了模拟期间交易读取的键和键的版本的列表。``写集`` 包含了交易写入键（可以与读取集中的键重叠）的新值。如果交易是删除一个键，该键就会被增加一个删除标识（在新值的位置）。
 
-此外，如果事务向一个键多次写入同一个值，则仅保留最后写入的值。同样，如果事务读取键的值，则即使事务在发出读取之前已更新键的值，也将返回处于提交状态的值。换句话说，不支持“读即写”语义。
+如果交易多次向同一个键写入数据，只有最后写入的数据会记录下来。同样，如果交易读取一个键的值，就会返回这个键的已提交状态的值，即使读取之前在同一个交易中更新了键值。换句话说，不支持“读你所写”的语义。
 
-如前所述，键的版本仅记录在读集中。写集仅包含唯一键的列表及其由事务设置的最新值。
+就像前面所说的，键的版本只记录在读集中；写集只包含键和交易设置的键的最新值。
 
-实现版本的方案可能有多种。版本控制方案的最低要求是为给定的键生成非重复的标识符。例如，可以对版本使用单调递增的数字来标记。在当前实现中，我们使用基于区块高度的版本控制方案，其中将提交事务的高度用作该事务修改的所有键的最新版本。在此方案中，事务的高度由数组表示（ txNumber 是区块事务的高度）。与增量编号方案相比，此方案具有许多优点-首当其冲的是，它使其他组件（如 saidb，事务模拟和验证）能够做出有效的设计选择。
+版本的实现有很多种。版本设计的基本需求是，键不能有重复的版本号。例如单调递增的数字。在目前的实现中，我们使用交易所在的区块高度来作为交易中所有修改的键的版本号。这样区块中交易的高度通过一个元组来表示（txNumber 是区块中交易的高度）。这种方式比递增的数字有更多好处，主要有，它可以让其他组件比如状态数据库、交易模拟和验证有更多的设计选择。
 
-以下是模拟交易仿真的读写集示例的说明。为了简单起见，在图示中，我们使用增量数字表示版本。
+下边是为模拟一个交易所准备的读写集示例。为了简化说明，我们使用了一个递增的数字来表示版本。
 
 ::
 
@@ -32,26 +32,25 @@
       </NsReadWriteSet>
     <TxReadWriteSet>
 
-此外，如果事务在模拟过程中执行范围查询，则范围查询及其结果将作为 ``query-info`` 添加到读写集中
+另外，如果交易在模拟中执行的是一个范围查询，范围查询和它的结果都会被记录在读写集的 ``查询信息（query-info）`` 中。
 
-使用读写集进行事务验证和世界状态更新
+交易验证和使用读写集更新世界状态
 ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
 
- ``committer`` 使用读写集的读集部分检查事务的有效性，并使用读写集的写集部分更新相关键的版本和值。
+``提交节点`` 使用读写集中的读集来验证交易，使用写集来更新受影响的键的版本和值。
 
-在验证阶段，如果事务的读集中的每个键的版本与世界状态下的对应键的版本相匹配，则该事务是 ``有效的`` -假设所有前序的有效事务（包括同一区块中的前序事务）都已提交（*committed-state*）。如果读写集还包含一个或多个查询信息，则将执行附加验证。
+在验证阶段，如果读集中键的版本和世界状态中键的版本一致就认为该交易是 ``有效的`` ，这里我们假设所有之前 ``有效`` 的交易（同一个区块中该交易之前的交易）都会被提交（*提交状态*）。当读写集中包含一个或多个查询信息（query-info）时，需要执行额外的验证。
 
-这个额外验证应确保，在查询结果的超范围（即范围的并集）中没有插入/删除/更新键。换言之，如果我们在进行状态验证时，重新执行任何范围查询（在模拟过程中执行事务），则该范围查询产生的结果，应与模拟时事务观察到的结果相同。如此一来可确保，如果事务在提交期间观察到幻影项（phantom
-items），则应将该事务标记为无效。请注意，这种保护仅限于范围查询（即 ``GetStateByRange`` 链码中的函数），尚未针对其他查询实现（即， ``GetQueryResult`` 链代码中的功能）。其他查询可能会产生幻影，因此，除非应用程序可以保证结果集在仿真与验证/提交时间之间的稳定性，否则其他对未提交到 ordering 服务的事务应提供只读查询。
+这种额外的验证需要确保在根据查询信息获得的结果的超集（多个范围的合并）中没有插入、删除或者更新键。换句话说，如果我们在模拟执行交易期间重新执行任何一个范围，我们应该得到相同的结果。这个检查保证了如果交易在提交期间出了虚项，该交易就会被标记为无效的。这种检查只存在于范围查询中（例如链码中的 ``GetStateByRange`` 方法）其他查询中没有实现（例如链码中的 ``GetQueryResult`` 方法）。其他查询仍会存在出现虚项的风险，我们应该只在不向排序服务提交的只读交易中使用查询，除非应用程序能保证模拟的结果和验证/提交时的结果一致。
 
-如果事务通过了有效性检查，则提交者将使用写集更新世界状态。在更新阶段，对于写集中存在的每个键，将该键在世界状态下的值，设置为写集中指定的值。此外，世界状态下的键的版本也被改为最新版本。
+如果交易通过了有效性验证，提交节点就会根据写集更新世界状态。在更新阶段，会根据写集更新世界状态中对应的键的值。然后，世界状态中键的版本会更新到最新的版本。
 
-示例模拟与验证
+模拟和验证示例
 '''''''''''''''''''''''''''''''''
 
-本节通过一个场景帮助理解语义。为了进行示例，在世界状态下，键由数组 ``(k,ver,val)`` 进行表示， 其中 ``ver`` 表示键的最新版本， ``val`` 表示``k``的值。
+本章节通过示例场景帮助你理解读写集语义。在本例中，``k`` 表示键，在世界状态中表示一个元组 ``(k,ver,val)`` ， ``ver`` 是键 ``k`` 的版本， ``val`` 是值。
 
-现在，考虑``T1, T2, T3, T4, T5``五个交易，所有交易都在世界状态的同一快照上模拟。以下代码段显示了模拟交易所依据的世界状态的快照，以及每个交易所执行的读取和写入活动的顺序。
+现在假设有五个交易 ``T1，T2，T3，T4 和 T5`` ，所有的交易模拟都基于同一个世界状态的快照。下边的步骤展示了世界状态和模拟这些交易时的读写活动。
 
 ::
 
@@ -62,19 +61,19 @@ items），则应将该事务标记为无效。请注意，这种保护仅限于
     T4 -> Write(k2, v2'''), read(k2)
     T5 -> Write(k6, v6'), read(k5)
 
-现在，假定这些事务按T1，..，T5的顺序排序（可以包含在单个区块中或不同区块中）
+现在，假设这些交易的顺序是从 T1 到 T5（他们可以在同一个区块，也可以在不同区块）
 
-1. ``T1`` 通过验证，因为他不需要任何读取。然后， ``k1`` 和 ``k2`` 两个键在世界状态中的数组被更新为``(k1,2,v1'), (k2,2,v2')``
+1. ``T1`` 通过了验证，因为它没有执行任何读操作。然后世界状态中的键 ``k1`` 和 ``k2`` 被更新为 ``(k1,2,v1'), (k2,2,v2')``
 
-2. ``T2`` 验证失败，因为它读取了一个 ``k1`` ，该键已经被之前的事务 ``T1`` 修改过。
+2. ``T2`` 没有通过验证，因为它读了键 ``k1``，但是交易 ``T1`` 改变了 ``k1``
 
-3. ``T3`` 通过验证，因为它不执行读取。然后，``k2`` 键在世界状态中的数组被更新为 ``(k2,3,v2'')`` 
+3. ``T3`` 通过了验证，因为它没有执行任何读操作。然后世界状态中的键 ``k2`` 被更新为 ``(k2,3,v2'')``
 
-4. ``T4`` 验证失败，因为它读取了一个 ``k2`` ，该键已经被之前的事务 ``T1`` 修改过。
+4. ``T4`` 没有通过验证，因为它读了键 ``k2``，但是交易 ``T1`` 改变了 ``k2``
 
-5. ``T5`` 通过验证，因为它读取了一个 ``k5`` ，该键没有被任何前序事务修改过。
+5. ``T5`` 通过了验证，因为它读了键 ``k5``，但是 ``k5`` 没有被其他任何交易改变
 
-**注意**: 目前不支持具有多个读写集的事务。
+**Note**: 不支持有多个读写集的交易。
 
 .. Licensed under Creative Commons Attribution 4.0 International License
    https://creativecommons.org/licenses/by/4.0/