欢迎来到 Hyperledger Fabric¶

安装 cURL¶

如果您还没有安装cURL工具，或者当您从文件中运行curl命令遇到错误提示时，请下载最新版本的`cURL <https://curl.haxx.se/download.html>`__ 工具。

Docker 和 Docker Compose¶

请在您用于运行、开发、或其他方式使用Hyperledger Fabric的平台上安装以下内容：

• MacOSX, *nix, 或者 Windows 10： Docker Docker 17.06.2-ce 或者更高版本。
• 旧版 Windows： Docker Toolbox - 同样的, Docker 版本需要 Docker 17.06.2-ce 或者更高版本。

您可以在终端提示符中通过以下命令，检查您所安装的Docker版本：

docker --version

您可以在终端提示符中通过以下命令，检查您所安装的Docker Compose版本：

docker-compose --version

Go 编程语言¶

Hyperledger Fabric 在很多组件中使用Go 1.9.x 版本的编程语言。

既然我们写的是Go链码（Chaincode）程序，我们需要确保源代码位于``$GOPATH``树目录中的某处。首先，您需要检查是否已经设置``$GOPATH``环境变量。

echo $GOPATH
/Users/xxx/go

当您echo $GOPATH``时，如果什么都没有显示，您需要设置这个环境变量。 通常来说，如果您的开发工作空间（development workspace）中有一个子树目录（directory tree child）， 这个变量值就是这个目录，或者也可以是您$HOME目录下的子目录。由于我们将要用Go语言进行一系列编码， 您也许需要将如下内容添加至配置文件``~/.bashrc：

export GOPATH=$HOME/go
export PATH=$PATH:$GOPATH/bin

Node.js 运行环境和 NPM¶

如果您打算使用Hyperledger Fabric的Node.js SDK为Hyperledger Fabric开发应用程序，您需要安装Node.js 8.9.x版本。

npm install npm@5.6.0 -g

sudo apt-get install python

python --version

Windows 附加条件¶

如果在Windows 7操作系统上做开发，您可以在 Docker Quickstart Terminal 中工作，它使用 Git Bash ，提供了一个除了内置Windows shell的更好替代。

然而，经验显示，这个开发环境功能比较局限，它适用于运行基于Docker的场景，比如:doc:getting_started， 但是当运行包含``make`` 和 ``docker``的命令时，您可能会遇到困难。

在Windows 10 操作系统上，您应该使用原生的Docker分发版本，您也可能需要使用 Windows PowerShell。 但是，为了让 下载特定平台的二进制文件 命令成功运行，您还是需要有可用的 uname 命令。 您可以通过其作为Git的一部分而得到它，但是需要注意的是，它只支持64-bit的版本。

在运行任何``git clone``命令之前，请运行以下命令：

git config --global core.autocrlf false
git config --global core.longpaths true

您可以通过以下命令，检查这些变量的设置：

git config --get core.autocrlf
git config --get core.longpaths

这些设置需要分别为 false 和 true。

依附Git和Docker Toolbox的``curl`` 命令是旧版的，不能够正常处理 入门指南 中使用的重定向。 请确保您安装和使用`cURL 下载页面 <https://curl.haxx.se/download.html>`__中的较新版本。

对于 Node.js，您也需要必要的 Visual Studio C++ Build Tools，这是免费的工具，可以通过以下命令安装：

npm install --global windows-build-tools

请参照 NPM windows-build-tools 页面 获取更多细节。

当完成以上任务之后，您还需要通过以下命令，安装 NPM GRPC 模块：

npm install --global grpc

到此为止，您的环境应该已经准备好运行 入门指南 中的示例和教程。

下载特定平台的二进制文件¶

接下来，我们将要安装 Hyperledger Fabric 特定平台的二进制文件。这个过程主要用于补充上述 Hyperledger Fabric 示例，但也可以被独立使用。 如果您不安装以上的示例，可以直接创建和输入目录，用于提取存放特定平台的二进制文件内容。

在您即将用于提取存放特定平台的二进制文件的目录下，请执行以下命令：

curl -sSL https://goo.gl/6wtTN5 | bash -s 1.1.0

通过上述命令，下载和执行一个bash脚本，该脚本可以下载和提取，所有您需要用于设置网络的特定平台的二进制文件，并把他们放入您之前创建的克隆仓库中， 其中，包括四个特定平台的二进制文件：

• cryptogen,
• configtxgen,
• configtxlator,
• peer
• orderer 和
• fabric-ca-client

他们会被放入您当前工作目录的 bin 子目录下。

您也许想要把这个目录加入到 PATH 环境变量中，这样可以在不完全符合每个二进制文件路径的情况下就找到他们，比如：

export PATH=<path to download location>/bin:$PATH

最后，这个脚本将会从 Docker Hub 下载 Hyperledger Fabric docker 镜像， 加入您的本地 Docker 注册表，并标记他们为 ‘latest’。

结束之后，这个脚本会罗列出所有已经安装的 Docker 镜像。

看看每一个镜像的名字，这些都将是组成我们的 Hyperledger Fabric 网络的组件。同时，您会发现您有两个同一镜像ID的实例 - 一个标记为 “x86_64-1.x.x”，另一个标记为 “latest”.

What is a Blockchain?¶

A Distributed Ledger

At the heart of a blockchain network is a distributed ledger that records all the transactions that take place on the network.

A blockchain ledger is often described as decentralized because it is replicated across many network participants, each of whom collaborate in its maintenance. We’ll see that decentralization and collaboration are powerful attributes that mirror the way businesses exchange goods and services in the real world.

In addition to being decentralized and collaborative, the information recorded to a blockchain is append-only, using cryptographic techniques that guarantee that once a transaction has been added to the ledger it cannot be modified. This property of immutability makes it simple to determine the provenance of information because participants can be sure information has not been changed after the fact. It’s why blockchains are sometimes described as systems of proof.

 Smart Contracts

To support the consistent update of information – and to enable a whole host of ledger functions (transacting, querying, etc) – a blockchain network uses smart contracts to provide controlled access to the ledger.

Smart contracts are not only a key mechanism for encapsulating information and keeping it simple across the network, they can also be written to allow participants to execute certain aspects of transactions automatically.

A smart contract can, for example, be written to stipulate the cost of shipping an item that changes depending on when it arrives. With the terms agreed to by both parties and written to the ledger, the appropriate funds change hands automatically when the item is received.

Consensus

The process of keeping the ledger transactions synchronized across the network – to ensure that ledgers only update when transactions are approved by the appropriate participants, and that when ledgers do update, they update with the same transactions in the same order – is called consensus.

We’ll learn a lot more about ledgers, smart contracts and consensus later. For now, it’s enough to think of a blockchain as a shared, replicated transaction system which is updated via smart contracts and kept consistently synchronized through a collaborative process called consensus.

Why is a Blockchain useful?¶

Today’s Systems of Record

The transactional networks of today are little more than slightly updated versions of networks that have existed since business records have been kept. The members of a Business Network transact with each other, but they maintain separate records of their transactions. And the things they’re transacting – whether it’s Flemish tapestries in the 16th century or the securities of today – must have their provenance established each time they’re sold to ensure that the business selling an item possesses a chain of title verifying their ownership of it.

What you’re left with is a business network that looks like this:

Modern technology has taken this process from stone tablets and paper folders to hard drives and cloud platforms, but the underlying structure is the same. Unified systems for managing the identity of network participants do not exist, establishing provenance is so laborious it takes days to clear securities transactions (the world volume of which is numbered in the many trillions of dollars), contracts must be signed and executed manually, and every database in the system contains unique information and therefore represents a single point of failure.

It’s impossible with today’s fractured approach to information and process sharing to build a system of record that spans a business network, even though the needs of visibility and trust are clear.

The Blockchain Difference

What if instead of the rat’s nest of inefficiencies represented by the “modern” system of transactions, business networks had standard methods for establishing identity on the network, executing transactions, and storing data? What if establishing the provenance of an asset could be determined by looking through a list of transactions that, once written, cannot be changed, and can therefore be trusted?

That business network would look more like this:

This is a blockchain network. Every participant in it has their own replicated copy of the ledger. In addition to ledger information being shared, the processes which update the ledger are also shared. Unlike today’s systems, where a participant’s private programs are used to update their private ledgers, a blockchain system has shared programs to update shared ledgers.

With the ability to coordinate their business network through a shared ledger, blockchain networks can reduce the time, cost, and risk associated with private information and processing while improving trust and visibility.

You now know what blockchain is and why it’s useful. There are a lot of other details that are important, but they all relate to these fundamental ideas of the sharing of information and processes.

What is Hyperledger Fabric?¶

The Linux Foundation founded Hyperledger in 2015 to advance cross-industry blockchain technologies. Rather than declaring a single blockchain standard, it encourages a collaborative approach to developing blockchain technologies via a community process, with intellectual property rights that encourage open development and the adoption of key standards over time.

Hyperledger Fabric is one of the blockchain projects within Hyperledger. Like other blockchain technologies, it has a ledger, uses smart contracts, and is a system by which participants manage their transactions.

Where Hyperledger Fabric breaks from some other blockchain systems is that it is private and permissioned. Rather than an open permissionless system that allows unknown identities to participate in the network (requiring protocols like Proof of Work to validate transactions and secure the network), the members of a Hyperledger Fabric network enroll through a Membership Service Provider (MSP).

Hyperledger Fabric also offers several pluggable options. Ledger data can be stored in multiple formats, consensus mechanisms can be switched in and out, and different MSPs are supported.

Hyperledger Fabric also offers the ability to create channels, allowing a group of participants to create a separate ledger of transactions. This is an especially important option for networks where some participants might be competitors and not want every transaction they make - a special price they’re offering to some participants and not others, for example - known to every participant. If two participants form a channel, then those participants – and no others – have copies of the ledger for that channel.

Shared Ledger

Hyperledger Fabric has a ledger subsystem comprising two components: the world state and the transaction log. Each participant has a copy of the ledger to every Hyperledger Fabric network they belong to.

The world state component describes the state of the ledger at a given point in time. It’s the database of the ledger. The transaction log component records all transactions which have resulted in the current value of the world state. It’s the update history for the world state. The ledger, then, is a combination of the world state database and the transaction log history.

The ledger has a replaceable data store for the world state. By default, this is a LevelDB key-value store database. The transaction log does not need to be pluggable. It simply records the before and after values of the ledger database being used by the blockchain network.

Smart Contracts

Hyperledger Fabric smart contracts are written in chaincode and are invoked by an application external to the blockchain when that application needs to interact with the ledger. In most cases chaincode only interacts with the database component of the ledger, the world state (querying it, for example), and not the transaction log.

Chaincode can be implemented in several programming languages. The currently supported chaincode language is Go with support for Java and other languages coming in future releases.

Privacy

Depending on the needs of a network, participants in a Business-to-Business (B2B) network might be extremely sensitive about how much information they share. For other networks, privacy will not be a top concern.

Hyperledger Fabric supports networks where privacy (using channels) is a key operational requirement as well as networks that are comparatively open.

Consensus

Transactions must be written to the ledger in the order in which they occur, even though they might be between different sets of participants within the network. For this to happen, the order of transactions must be established and a method for rejecting bad transactions that have been inserted into the ledger in error (or maliciously) must be put into place.

This is a thoroughly researched area of computer science, and there are many ways to achieve it, each with different trade-offs. For example, PBFT (Practical Byzantine Fault Tolerance) can provide a mechanism for file replicas to communicate with each other to keep each copy consistent, even in the event of corruption. Alternatively, in Bitcoin, ordering happens through a process called mining where competing computers race to solve a cryptographic puzzle which defines the order that all processes subsequently build upon.

Hyperledger Fabric has been designed to allow network starters to choose a consensus mechanism that best represents the relationships that exist between participants. As with privacy, there is a spectrum of needs; from networks that are highly structured in their relationships to those that are more peer-to-peer.

We’ll learn more about the Hyperledger Fabric consensus mechanisms, which currently include SOLO, Kafka, and will soon extend to SBFT (Simplified Byzantine Fault Tolerance), in another document.

Where can I learn more?¶

入门指南

We provide a number of tutorials where you’ll be introduced to most of the key components within a blockchain network, learn more about how they interact with each other, and then you’ll actually get the code and run some simple transactions against a running blockchain network. We also provide tutorials for those of you thinking of operating a blockchain network using Hyperledger Fabric.

超级账本 Fabric 模型

A deeper look at the components and concepts brought up in this introduction as well as a few others and describes how they work together in a sample transaction flow.

Identity management-身份管理¶

To enable permissioned networks, Hyperledger Fabric provides a membership identity service that manages user IDs and authenticates all participants on the network. Access control lists can be used to provide additional layers of permission through authorization of specific network operations. For example, a specific user ID could be permitted to invoke a chaincode application, but blocked from deploying new chaincode.

为了启用许可的网络，Hyperledger Fabric提供了一种成员身份识别服务，用于管理用户ID并对网络上的所有参与者进行身份验证。 访问控制列表可用于通过授权特定的网络操作来提供额外的权限层。 例如，特定的用户ID可以被允许调用链码应用程序，但被阻止配置新的链码。

Privacy and confidentiality-隐私和保密¶

Hyperledger Fabric enables competing business interests, and any groups that require private, confidential transactions, to coexist on the same permissioned network. Private channels are restricted messaging paths that can be used to provide transaction privacy and confidentiality for specific subsets of network members. All data, including transaction, member and channel information, on a channel are invisible and inaccessible to any network members not explicitly granted access to that channel.

Hyperledger Fabric使相互竞争的商业利益以及任何需要私密交易的群体能够在同一个许可的网络上共存。 私有“通道”是受限的消息传递路径，可用于为特定的网络成员子集提供交易隐私和机密性。 任何未明确授予访问该通道权限的网络成员，都不可见也无法访问该通道所有的数据，包括交易，成员及通道信息。

Efficient processing-高效的处理¶

Hyperledger Fabric assigns network roles by node type. To provide concurrency and parallelism to the network, transaction execution is separated from transaction ordering and commitment. Executing transactions prior to ordering them enables each peer node to process multiple transactions simultaneously. This concurrent execution increases processing efficiency on each peer and accelerates delivery of transactions to the ordering service.

Hyperledger Fabric按节点类型分配网络角色。 为了向网络提供并发性和并行性，交易执行与交易排序和提交是分开的。 在给它们排序之前执行交易可使每个对等节点同时处理多个交易。 这种并发执行提高了每个节点的处理效率并加速了向排序服务提供交易。

In addition to enabling parallel processing, the division of labor unburdens ordering nodes from the demands of transaction execution and ledger maintenance, while peer nodes are freed from ordering (consensus) workloads. This bifurcation of roles also limits the processing required for authorization and authentication; all peer nodes do not have to trust all ordering nodes, and vice versa, so processes on one can run independently of verification by the other.

除了支持并行处理之外，分工还可以从交易执行和账本维护的需求中解除排序节点的负担，同时节点从排序（共识）工作负载中解放出来。 角色分工也限制了授权和认证所需的处理; 所有对等节点不必信任所有的排序节点，反之亦然，因此一个节点上的进程可以独立于另一节点的验证运行。

Chaincode functionality-Chaincode的功能¶

Chaincode applications encode logic that is invoked by specific types of transactions on the channel. Chaincode that defines parameters for a change of asset ownership, for example, ensures that all transactions that transfer ownership are subject to the same rules and requirements. System chaincode is distinguished as chaincode that defines operating parameters for the entire channel. Lifecycle and configuration system chaincode defines the rules for the channel; endorsement and validation system chaincode defines the requirements for endorsing and validating transactions.

Chaincode应用程序对由通道上特定类型的交易调用的逻辑进行编码。 例如，为资产所有权变更定义参数的链码可确保所有变更所有权的交易都遵守相同的规则和要求。 “system chaincode”区别于Chaincode，它定义了整个通道的工作参数。 Lifecycle和配置system chaincode定义了通道的规则；背书和验证system chaincode定义了批准和验证交易的要求。

Modular design-模块化设计¶

Hyperledger Fabric implements a modular architecture to provide functional choice to network designers. Specific algorithms for identity, ordering (consensus) and encryption, for example, can be plugged in to any Hyperledger Fabric network. The result is a universal blockchain architecture that any industry or public domain can adopt, with the assurance that its networks will be interoperable across market, regulatory and geographic boundaries.

Hyperledger Fabric实现了模块化架构，为网络设计者提供了功能选择。 例如，用于身份识别，排序（共识）和加密的特定算法可以插入任何Hyperledger Fabric网络。 其结果是任何行业或公共领域都可以采用的通用区块链架构，并确保其网络能在市场，法规和地理边界中共同使用。

资产¶

资产可以为有形（房地产和硬件）或无形资产（合同和知识产权）。 超级账本Fabric提供了使用链码交易修改资产的能力。资产在 超级账本Fabric中 以键值对集合的形式表达，资产的状态更改作为交易记录在对应的通道账本里。资产可以用二进制和/或JSON格式表示和纪录。

你可以通过 Hyperledger Composer 这个工具，很容易地在超级账本Fabric里面定义和使用你的资产。

Assets can range from the tangible (real estate and hardware) to the intangible (contracts and intellectual property). Hyperledger Fabric provides the ability to modify assets using chaincode transactions.

Assets are represented in Hyperledger Fabric as a collection of key-value pairs, with state changes recorded as transactions on a Channel - 通道 ledger. Assets can be represented in binary and/or JSON form.

You can easily define and use assets in your Hyperledger Fabric applications using the Hyperledger Composer tool.

链码¶

链码是指包含了一项或多项资产定义，以及所有修改资产交易逻辑的软件。换句话说，链码代表了业务逻辑。 链码限制了被容许执行的读取和更改键值对/

库信息的规则。 链码函数使用当前的stateDB里的数据执行，并通过超级账本Fabric的交易协议启动。 链码执行后会产生一组键值对（写入集），这组键值对会被提交到网络并写入所有Peer节点的账本里。

Chaincode is software defining an asset or assets, and the transaction instructions for modifying the asset(s). In other words, it’s the business logic. Chaincode enforces the rules for reading or altering key value pairs or other state database information. Chaincode functions execute against the ledger’s current state database and are initiated through a transaction proposal. Chaincode execution results in a set of key value writes (write set) that can be submitted to the network and applied to the ledger on all peers.

账本特性¶

Fabric账本是所有资产状态数据修改的纪录，账本上的数据是已排序并且防篡改的。状态数据修改是用户调用链码（交易）的直接结果。每个交易都会生成一个资产键值对，这个键值对会成为一个增加，修改或删除的纪录提交到账本里。账本是以区块链（链）的数据结构，把排序并不可篡改的数据纪录到每个区块里，同时以stateDB纪录fabric的当前数据状态。每一个通道有一个独立账本，每个Peer节点都会为自己参与的通道维护和备份该通道的账本。

The ledger is the sequenced, tamper-resistant record of all state transitions in the fabric. State transitions are a result of chaincode invocations (‘transactions’) submitted by participating parties. Each transaction results in a set of asset key-value pairs that are committed to the ledger as creates, updates, or deletes.

The ledger is comprised of a blockchain (‘chain’) to store the immutable, sequenced record in blocks, as well as a state database to maintain current fabric state. There is one ledger per channel. Each peer maintains a copy of the ledger for each channel of which they are a member.

• 以主键值，键值区间和复合主键查询和更新账本
• 以丰富查询语言执行只读查询（使用CouchDB作为stateDB的情况下）
• 交易的内容包含所有链码已读取的键值对版本（读取集）和所有写入的键值对（写入集）
• 交易包含所有背书节点的加密签名并以提交到排序服务（ordering service）
• 交易被order节点排序，并由排序服务广播到对应通道的Peer节点
• Peer 节点根据背书政策验证交易，并执行背书政策
• 在交易加入区块前，Peer 节点会教验状态数据版本是否在链码执行后有更新，确保交易结果的有效性。
• 一旦交易成功验证并提交到账本后，交易数据就不可篡改
• 每个通道账本都包含一个设定区块，这个设定区块定义了政策，访问权限清单和其他相关信息
• 通道的成员服务（MSP）实例让每个通道可以从不同的证书颁发机构获得加密算法的资料

想了解更多关于账本数据库，存储结构和查询功能的信息，请参考 Ledger - 账本 文档。

• Query and update ledger using key-based lookups, range queries, and composite key queries
• Read-only queries using a rich query language (if using CouchDB as state database)
• Read-only history queries - Query ledger history for a key, enabling data provenance scenarios
• Transactions consist of the versions of keys/values that were read in chaincode (read set) and keys/values that were written in chaincode (write set)
• Transactions contain signatures of every endorsing peer and are submitted to ordering service
• Transactions are ordered into blocks and are “delivered” from an ordering service to peers on a channel
• Peers validate transactions against endorsement policies and enforce the policies
• Prior to appending a block, a versioning check is performed to ensure that states for assets that were read have not changed since chaincode execution time
• There is immutability once a transaction is validated and committed
• A channel’s ledger contains a configuration block defining policies, access control lists, and other pertinent information
• Channel’s contain Membership Service Provider - 成员服务提供者 instances allowing for crypto materials to be derived from different certificate authorities

See the Ledger - 账本 topic for a deeper dive on the databases, storage structure, and “query-ability.”

以通道保障隐私¶

超级账本Fabric在每个通道的基础上使用不可篡改的账本以及可以操纵和修改资产当前状态（即更新键值对）的链码。账本只存在于一个通道范围内，它可以在整个网络中共享（假设每个参与者都在一个共同通道上运营）或者可以将其私有化，只包含一组特定的参与者。在后一种情况下，这些参与者将创建一个单独的通道，从而隔离这个通道的交易和账本。为了缩小总体透明度和隐私之间的差距，链码只能安装在需要访问资产状态以执行读取和写入的Peer节点（换句话说，如果链接代码未安装在Peer节点上，它将无法正确地与账本连接）。为了进一步保护数据，链码可以在将交易发送到排序服务（ordering service）并将区块附加到分类账之前，使用常用的加密算法（如AES）对链码中的值进行加密（部分或全部）。一旦将加密数据写入分类帐，只能由拥有对应密钥的用户解密。

更多关于链码加密的信息，请参考 Chaincode for Developers 面向开发人员的链码指南 文档。

Hyperledger Fabric employs an immutable ledger on a per-channel basis, as well as chaincodes that can manipulate and modify the current state of assets (i.e. update key value pairs). A ledger exists in the scope of a channel - it can be shared across the entire network (assuming every participant is operating on one common channel) - or it can be privatized to only include a specific set of participants.

In the latter scenario, these participants would create a separate channel and thereby isolate/segregate their transactions and ledger. In order to solve scenarios that want to bridge the gap between total transparency and privacy, chaincode can be installed only on peers that need to access the asset states to perform reads and writes (in other words, if a chaincode is not installed on a peer, it will not be able to properly interface with the ledger).

To further obfuscate the data, values within chaincode can be encrypted (in part or in total) using common cryptographic algorithms such as AES before sending transactions to the ordering service and appending blocks to the ledger. Once encrypted data has been written to the ledger, it can only be decrypted by a user in possession of the corresponding key that was used to generate the cipher text. For further details on chaincode encryption, see the Chaincode for Developers 面向开发人员的链码指南 topic.

安全的成员服务¶

超级账本 Fabric 支持一个由已知身份的参与者组成的交易网络。公钥基础建设用于生成与组织，网络成员，用户或客户端的加密证书。数据访问权限因此可以在更广泛的网络和通道级别上进行操纵和管理。 超级账本 Fabric的这种 “授权” 概念，再加上通道的功能，有助于解决隐私和机密性成为首要考量的使用场景。

关于超级账本Fabric的加密功能实现，加密签名，认证和授权的操作，请参考 Membership Service Providers (MSP) 文档。

Hyperledger Fabric underpins a transactional network where all participants have known identities. Public Key Infrastructure is used to generate cryptographic certificates which are tied to organizations, network components, and end users or client applications. As a result, data access control can be manipulated and governed on the broader network and on channel levels. This “permissioned” notion of Hyperledger Fabric, coupled with the existence and capabilities of channels, helps address scenarios where privacy and confidentiality are paramount concerns.

See the Membership Service Providers (MSP) topic to better understand cryptographic implementations, and the sign, verify, authenticate approach used in Hyperledger Fabric.

共识机制¶

在分布式账本技术的讨论中，共识机制最近已成为特定算法的同义词，然而共识不仅仅是简单地就交易顺序达成一致。超级账本 Fabric通过其在整个交易流程中的基本角色（从提案和背书，到排序，确认和提交）突出了这种对共识机制理解的差异。简而言之，超级账本Fabric里的共识机制定义为对区块里的交易组正确性的全面验证。

当区块内交易顺序和结果通过政策标准检查时，这个区块的内的数据就能达成共识。这些检查发生在交易的生命周期中，包括使用背书政策来规定哪些特定成员必须认可那些指定的交易类别。这些交易检查还会使用链码以确保策略得到执行和维护。在发布修改之前，Peer节点将使用链码来确保有有效的背书，并且这些背书来源于适当的实体。此外，在包含交易的任何块被提交到账本之前，Peer 节点将进行版本检查，以确认账本的当前状态已获得共识并没有更新。此最终检查可防止双重支出操作以及可能危及数据完整性的其他威胁，并允许针对非静态变量执行功能。

除了背书操作，有效性和版本检查之外，交易流程中还进行大量的身份验证。访问权限控制列表在网络层上实施（由排序服务到通道）。在交易流程中，交易建议在通过不同的架构组件时会被重复地签名和验证。总而言之，共识机制并不仅仅局限于一批交易的共识顺序，一个有效交易在Fabric机制中，通过提案到提交之间的持续核查过程后，共识是一个必然生成的副产品。

请参考可视化的交易流程 Transaction Flow，以了解更多关于共识机制的内容。

In distributed ledger technology, consensus has recently become synonymous with a specific algorithm, within a single function. However, consensus encompasses more than simply agreeing upon the order of transactions, and this differentiation is highlighted in Hyperledger Fabric through its fundamental role in the entire transaction flow, from proposal and endorsement, to ordering, validation and commitment. In a nutshell, consensus is defined as the full-circle verification of the correctness of a set of transactions comprising a block.

Consensus is ultimately achieved when the order and results of a block’s transactions have met the explicit policy criteria checks. These checks and balances take place during the lifecycle of a transaction, and include the usage of endorsement policies to dictate which specific members must endorse a certain transaction class, as well as system chaincodes to ensure that these policies are enforced and upheld. Prior to commitment, the peers will employ these system chaincodes to make sure that enough endorsements are present, and that they were derived from the appropriate entities. Moreover, a versioning check will take place during which the current state of the ledger is agreed or consented upon, before any blocks containing transactions are appended to the ledger. This final check provides protection against double spend operations and other threats that might compromise data integrity, and allows for functions to be executed against non-static variables.

In addition to the multitude of endorsement, validity and versioning checks that take place, there are also ongoing identity verifications happening in all directions of the transaction flow. Access control lists are implemented on hierarchal layers of the network (ordering service down to channels), and payloads are repeatedly signed, verified and authenticated as a transaction proposal passes through the different architectural components. To conclude, consensus is not merely limited to the agreed upon order of a batch of transactions, but rather, it is an overarching characterization that is achieved as a byproduct of the ongoing verifications that take place during a transaction’s journey from proposal to commitment.

Check out the Transaction Flow diagram for a visual representation of consensus.

什么是身份¶

What is an Identity?¶

在区块链的网络中有很多不同的身份包括节点（对等节点）、排序节点、客户端应用，超级管理员等等。它们中的每一个角色都拥有X.509数字证书封装的身份。而这些身份也因为决定着角色在区块链网络中所能获得的资源权限格外重要。 超级账本Fabric使用角色身份中的某些属性来确定权限，并称之为当事人(principal)，当事人就像是userIDs或者groupIDs这些，但是要更加灵活，它们可以包含角色的各种身份属性。当我们讨论当事人时，我们是在考虑系统中的角色，特别是可以决定它们权限的身份属性。这些属性通常是一个成员的组织，所属部门，承担角色或者其它成员的特殊身份。 The different actors in a blockchain network include peers, orderers, client applications, administrators and more. Each of these actors has an identity that is encapsulated in an X.509 digital certificate. These identities really matter because they determine the exact permissions over resources that actors have in a blockchain network. Hyperledger Fabric uses certain properties in an actor’s identity to determine permissions, and it gives them a special name – a principal. Principals are just like userIDs or groupIDs, but a little more flexible because they can include a wide range of an actor’s identity properties. When we talk about principals, we’re thinking about the actors in the system – specifically the actor’s identity properties which determine their permissions. These properties are typically the actor’s organization, organizational unit, role or even the actor’s specific identity.

更为重要的是，一个身份必须是可证实的（即真实身份），因此它必须来源于一个能被系统信任的权威组织。在Fabric中成员服务提供者(MSP，membership service provider)就是用来完成这件事情的。进一步来说，MSP是表示组织成员资格的组件，因此，它定义了管理该组织成员有效身份的规则。Fabric中默认的MSP方案使用X.509证书作为身份，并采用传统的公钥基础设施（PKI）分层模型。 Most importantly, an identity must be verifiable (a real identity, in other words), and for this reason it must come from an authority trusted by the system. A membership service provider (MSP) is the means to achieve this in Hyperledger Fabric. More specifically, an MSP is a component that represents the membership rules of an organization, and as such, it that defines the rules that govern a valid identity of a member of this organization. The default MSP implementation in Fabric uses X.509 certificates as identities, adopting a traditional Public Key Infrastructure (PKI) hierarchical model.

使用身份的简单场景¶

A Simple Scenario to Explain The Use of an Identity¶

想象这样一个场景：你到超市去买东西，在收银台你看到一个提醒说，只能使用Visa、Mastercard和AMEX银行卡，如果你试着使用其它卡片支付，让我们称它为“幻想卡”——即便这张卡真实且余额充足，也不行，它不会被接受。 Imagine that you visit a supermarket to buy some groceries. At the checkout you see a sign that says that only Visa, Mastercard and AMEX cards are accepted. If you try to pay with a different card – let’s call it an “ImagineCard” – it doesn’t matter whether the card is authentic and you have sufficient funds in your account. It will be not be accepted.

只拥有一个有效的信用卡还不够，还必须是商店可以接受的支付卡片才可以！PKIs和MSPs以相同的方式协同工作——PKI提供有效身份列表，MSP描述哪些身份是网络中给定组织的成员。 Having a valid credit card is not enough – it must also be accepted by the store! PKIs and MSPs work together in the same way – PKI provides a list of identities, and an MSP says which of these are members of a given organization that participates in the network. PKI证书颁发机构和MSPs提供了类似的多功能组合，一个PKI就像是一种卡的提供商，它分配了很多不同的可验证身份，而一个MSP，从某个层面看，就像是商店接受的卡种提供商列表。决定着哪些身份在商店的支付网络中是可信的成员（角色）。MSP将可验证的身份转换成了区块链网络中的成员。 PKI certificate authorities and MSPs provide a similar combination of functionalities. A PKI is like a card provider – it dispenses many different types of verifiable identities. An MSP, on the other hand, is like the list of card providers accepted by the store – determining which identities are the trusted members (actors) of the store payment network. MSPs turn verifiable identities into the members of a blockchain network. 下面让我们更详细的了解这些概念。 Let’s drill into these concepts in a little more detail.

什么事PKIs¶

What are PKIs?¶

一个公钥基础设施（PKI）是在网络中提供安全通信的因特网技术的集合。也正是PKI把S带给HTTPS的，如果你正在网络浏览器中读这篇文档，那么你很可能就在使用PKI去确认文档来源于一个可以验证的资源。

A public key infrastructure (PKI) is a collection of internet technologies that provides secure communications in a network. It’s PKI that puts the S in HTTPS – and if you’re reading this documentation on a web browser, you’re probably using a PKI to make sure it comes from a verified source.

公钥基础设施(PKI)原理。公钥基础设施由向成员（服务的使用者、服务的提供者）颁发数字证书的认证机构（CA）组成，然后这些成员使用数字证书去证明他们在环境中交换的消息确实由该成员所发，一个CA的证书撤销列表（CRL）由无效数字证书的引用组成。证书的吊销可能有很多原因，比如，与证书关联的私有信息（私钥等）已经泄漏，那么证书就应该被吊销。 *The elements of Public Key Infrastructure (PKI). A PKI is comprised of Certificate Authorities who issue digital certificates to parties (e.g., users of a service, service provider), who then use them to authenticate themselves in the messages they exchange with their environment. A CA’s Certificate Revocation List (CRL) constitutes a reference for the certificates that are no longer valid. Revocation of a certificate can happen fora number of reasons. For example, a certificate may be revoked because the cryptographic private material associated to the certificate has been exposed.

虽然区块链网络不只是通信网络，它依赖于PKI标准来确保在各种多样的网络间加密通信，同时确保发布在区块链上的消息都是被正确认证的。因此理解PKI的基础概念十分重要，进而MSPs也很重要。 Although a blockchain network is more than a communications network, it relies on the PKI standard to ensure secure communication between various network participants, and to ensure that messages posted on the blockchain are properly authenticated. It’s therefore really important to understand the basics of PKI and then why MSPs are so important.

PKI有四个关键的元素：

• 数字证书
• 公钥、私钥
• 认证机构
• 证书吊销列表 There are four key elements to PKI:
• Digital Certificates
• Public and Private Keys
• Certificate Authorities
• Certificate Revocation Lists

让我们快速介绍一下这些PKI的基本要素，如果你还想知道更多细节，Wikipedia是个开始的好地方。 Let’s quickly describe these PKI basics, and if you want to know more details, Wikipedia is a good place to start.

数字证书¶

Digital Certificates¶

数字证书是一份保存了成员相关的一系列属性的文件。最通用的数字证书类型满足X.509 标准,该标准允许在其结构中编码成员的身份识别细节。举例来说，张三（原文是John Doe，英语中意为某人）是美国密西根省底特律市FOO公司会计部的员工，他可能有这样的数字证书：主题属性：C=美国, ST=密西根，L=底特律，O=FOO公司，OU=会计部，CN=张三，UID=123456.张三的数字证书和他的官方身份卡是相似的，它提供张三的信息，张三可以使用这些信息来证明关于他的一些关键事实，在X.509中还有很多其它的属性，但目前我们只关注这些就够了。 A digital certificate is a document which holds a set of attributes relating to a party. The most common type of certificate is the one compliant with the X.509 standard, which allows the encoding of a party’s identifying details in its structure. For example, John Doe of Accounting division in FOO Corporation in Detroit, Michigan might have a digital certificate with a SUBJECT attribute of C=US, ST=Michigan, L=Detroit, O=FOO Corporation, OU=Accounting, CN=John Doe /UID=123456. John’s certificate is similar to his government identity card – it provides information about John which he can use to prove key facts about him. There are many other attributes in an X.509 certificate, but let’s concentrate on just these for now.

关于某个成员的数字证书，某人是证书的“主题”，“主题”中加粗的文本显示了关于他的关键事实。如您所见，该证书还保存了更多的信息。最重要的是，此人的公钥信息也发布在他的证书中，而他的私钥不在其中，私钥是必须保密的。 A digital certificate describing a party called John Doe. John is the SUBJECT of the certificate, and the highlighted SUBJECT text shows key facts about John. The certificate also holds many more pieces of information, as you can see. Most importantly, John’s public key is distributed within his certificate, whereas his private signing key is not. This signing key must be kept private.

重要的是张三的所有属性都可以使用一种称为密码学的数学技术来记录（书面语，“密写”）也因为这样，对属性的篡改会使证书失效。密码学使得张三可以向他人出示数字证书来证明身份，只要其它人能够信任证书颁发者，也就是证书颁发机构（CA）。只要CA可以隐秘的保存确定的密文信息（意思是，它自己的私有签名密钥），任何读取证书的人都可以确信，这些信息就是张三的，它没有被篡改。可以把上图里Mary的X.509证书看作是一个不可更改的数字身份证。 What is important is that all of John’s attributes can be recorded using a mathematical technique called cryptography (literally, “secret writing”) so that tampering will invalidate the certificate. Cryptography allows John to present his certificate to others to prove his identity so long as the other party trusts the certificate issuer, known as a Certificate Authority (CA). As long as the CA keeps certain cryptographic information securely (meaning, its own private signing key), anyone reading the certificate can be sure that the information about John has not been tampered with – it will always have those particular attributes for John Doe. Think of Mary’s X.509 certificate as a digital identity card that is impossible to change.

身份验证 & 公钥和私钥¶

Authentication & Public keys and Private Keys¶

身份验证和消息完整性是安全通信的重要概念。身份验证要求各方创建特定消息来确保消息交换者的身份。完整性要求在传输过程中不修改消息。例如，您可能希望确保与真正的张三通信而不是模仿者。或者可能希望确保他向您发送的一条消息，在传输过程中没有被任何人篡改过。 Authentication and message integrity are important concepts of secure communication. Authentication requires that parties who exchange messages can be assured of the identity that created a specific message. Integrity requires that the message was not modified during its transmission. For example, you might want to be sure you’re communicating with the real John Doe than an impersonator. Or if John has sent you a message, you might want to be sure that it hasn’t been tampered with by anyone else during transmission.

传统的身份验证机制依赖于数字签名机制，顾名思义，允许一方对其消息进行数字签名。数字签名还可以保证签名消息的完整性。 Traditional authentication mechanisms rely on digital signature mechanisms, that as the name suggests, allow a party to digitally sign its messages. Digital signatures also provide guarantees on the integrity of the signed message.

从技术上讲，数字签名机制要求每一方都需要保存两个加密有关联的密钥：广泛公开使用的公钥，充当身份验证依据，以及用于在消息上生成数字签名的私钥。 消息的接收者可以通过检查消息的附加数字签名，是否在预期发送者的公钥下有效，来验证接收到的消息来源和完整性。 Technically speaking, digital signature mechanisms require require for each party to hold two cryptographically connected keys: a public key that is made widely available, and acts as authentication anchor, and a private key that is used to produce digital signatures on messages. Recipients of digitally signed messages can verify the origin and integrity of a received message by checking that the attached signature is valid under the public key of the expected sender.

私钥和对应公钥的独特关系是密码学的魔术，这使得加密通信成为可能。密钥之间的唯一数学关系让私钥可以用于消息签名，这一签名仅有对应的公钥和相同的签名信息可以正确匹配。 The unique relationship between a private key and the respective public key is the cryptographic magic that makes secure communications possible. The unique mathematical relationship between the keys is such that the private key can be used to produce a signature on a message that only the corresponding public key can match, and only on the same message.

在上面的示例中，为了验证他的消息，Mary使用她的私钥在消息上生成签名，然后将其附加到消息中，任何使用Mary的公钥查看签名消息的人都可以验证签名真伪。 In the example above, to authenticate his message Joe uses his private key to produce a signature on the message, which he then attaches to the message. The signature can be verified by anyone who sees the signed message, using John’s public key.

认证机构¶

Certificate Authorities¶

如您所见，成员或者说节点能够通过区块链网络所信任的机构为其发布的数字身份加入到网络中。在最常见的情况下，数字身份（或简称身份）具有符合X.509标准的加密验证数字证书的形式，并由证书颁发机构（CA）颁发。 As you’ve seen, an actor or a node is able to participate in the blockchain network, via the means of a digital identity issued for it by an authority trusted by the system. In the most common case, digital identities (or simply identities) have the form of cryptographically validated digital certificates that comply with X.509 standard, and are issued by a Certificate Authority (CA).

CA是互联网安全协议的常见部分，您可能已经听说过一些比较流行的协议：Symantec（最初是Verisign），GeoTrust，DigiCert，GoDaddy和Comodo等。 CAs are a common part of internet security protocols, and you’ve probably heard of some of the more popular ones: Symantec (originally Verisign), GeoTrust, DigiCert, GoDaddy, and Comodo, among others.

证书颁发机构向不同的参与者分发证书。 这些证书由CA进行数字签名（即使用CA的私钥），同时将实际的用户角色与该用户的公钥绑定在一起，并可选地与一个完整的属性列表绑定在一起。显然，如果一个人信任CA（并且知道其公钥），它可以（通过验证参与者证书上的CA签名）信任特定参与者绑定到证书中包含的公钥，并拥有包含的属性。 *A Certificate Authority dispenses certificates to different actors. These certificates are digitally signed by the CA (i.e, using the CA’s private key), and bind together the actual actor with the actor’s public key, and optionally with a comprehensive list of properties. Clearly, if one trust the CA (and knows its public key), it can (by validating the CA’s signature on the actor’s certificate) trust that the specific actor is bound to the public key included in the certificate, and owns the included attributes.

至关重要的，证书因为并不包含角色信息和角色的私钥，因此可以广泛传播，这也就使得证书能够当做信任的锚点，来验证来自不同角色的消息。 Crucially certificates can be widely disseminated, as they do not include neither the actors’ nor the actual CA’s private keys. As such they can be used as anchor of trusts for authenticating messages coming from different actors.

事实上，证书颁发机构本身也有证书，它们被广泛使用。这允许由CA颁发身份的使用者们通过检查证书，来验证只能由相应私钥的持有者生成。 In reality, CAs themselves also have a certificate, which they make widely available. This allows the consumers of identities issued by a given CA to verify them by checking that the certificate could only have been generated by the holder of the corresponding private key (the CA).

在区块链的设置中，每个希望与网络进行交互的参与者都需要有身份。在这样的设置下，可以说有一个或多个CA可以用于从数字角度定义组织的成员。 CA为组织的参与者提供可验证的数字身份的基础。 In the Blockchain setting, every actor who wishes to interact with the network needs an identity. In this setting, you might say that one or more CAs can be used to define the members of an organization’s from a digital perspective. It’s the CA that provides the basis for an organization’s actors to have a verifiable digital identity.

证书废弃列表¶

Certificate Revocation Lists¶

证书废弃列表（CRL）很容易理解——它是一个关于CA已知的因为某种原因而弃用的证书列表，如果你能回忆起商店的那个场景，证书废弃列表就像是被盗信用卡列表一样。 A Certificate Revocation List (CRL) is easy to understand – it’s just a list of references to certificates that a CA knows to be revoked for one reason or another. If you recall the store scenario, a CRL would be like a list of stolen credit cards.

当一个第三方想要验证另一方的身份时，它会先检查证书颁发机构的CRL，来确认该身份证书没有被吊销。验证者不是必须检查CRL，如果他们可以冒着接受来自受损身份的风险。

When a third party wants to verify another party’s identity, it first checks the issuing CA’s CRL to make sure that the certificate has not been revoked. A verifier doesn’t have to check the CRL, but if they don’t they run the risk of accepting a compromised identity.

使用CRL检查证书是否仍然有效。如果模仿者试图将受损的数字证书传递给验证方，则可以首先检查颁发CA的CRL，以确保其未被列为不再有效。

Using a CRL to check that a certificate is still valid. If an impersonator tries to pass a compromised digital certificate to a validating party, it can be first checked against the issuing CA’s CRL to make sure it’s not listed as no longer valid.

请注意，被撤销的证书与证书过期非常不同。撤销的证书尚未过期 - 按其他措施，它们是完全有效的证书。 这类似于过期驾驶执照和被吊销驾驶执照之间的差异。有关CRL的更深入信息，请点击这里。

Note that a certificate being revoked is very different from a certificate expiring. Revoked certificates have not expired – they are, by every other measure, a fully valid certificate. This is similar to the difference between an expired driver’s license and a revoked driver’s license. For more in depth information into CRLs, click here.

您已经了解了PKI如何通过信任链提供可验证的身份，下一步是了解这些身份如何用于代表区块链网络的可信成员。这就是成员服务提供者（MSP）发挥作用的地方——它确定了区块链网络中特定组织成员的各方。 Now that you’ve seen how a PKI can provide verifiable identities through a chain of trust, the next step is to see how these identities can be used to represent the trusted members of a blockchain network. That’s where a Membership Service Provider (MSP) comes into play – it identifies the parties who are the members of a given organization in the blockchain network.

想要学习更多关于成员的内容，可以查阅MSPs的概念文档。 To learn more about membership, check out the conceptual documentation on MSPs.

Mapping MSPs to Organizations¶

###??MSPӳ?䵽??֯

An organization is a managed group of members and can be something as big as a multinational corporation or as small as a flower shop. What’s most important about organizations (or orgs) is that they manage their members under a single MSP. Note that this is different from the organization concept defined in an X.509 certificate, which we’ll talk about later.

??֯??һ???ܹ???ij?Ա??֯????????????˾??????Ҳ?????񻨵?һ??С?? ??֯??orgs?? ????Ҫ??????????һ??MSP?¹??????ǵij?Ա????ע?⣬????X.509֤???ж??????֯???ͬ?????ǽ????Ժ????ۡ?

The exclusive relationship between an organization and its MSP makes it sensible to name the MSP after the organization, a convention you’ll find adopted in most policy configurations. For example, organization ORG1 would have an MSP called ORG1-MSP. In some cases an organization may require multiple membership groups – for example, where channels are used to perform very different business functions between organisations. In these cases it makes sense to have multiple MSPs and name them accordingly, e.g., ORG2-MSP-NATIONAL and ORG2-MSP-GOVERNMENT, reflecting the different membership roots of trust within ORG2 in the NATIONAL sales channel compared to the GOVERNMENT regulatory channel.

??֯????MSP֮??Ķ?ռ??ϵʹ??????֮֯??????MSP?????ǵģ????Ǵ?????????????ж?????õ?Լ???????磬??֯ORG1????һ????ΪORG1-MSP??MSP????ijЩ????£???֯??????Ҫ?????Ա?? - ???磬ʹ???ŵ?????֮֯??ִ?зdz???ͬ??ҵ???ܡ?????Щ????£??ж??MSP????Ӧ??????????????????ģ????磬ORG2-MSP-NATIONAL??ORG2-MSP-GOVERNMENT????ӳ????GOVERNMENT????ŵ???ȣ???NATIONAL?????ŵ??е?ORG2???β?ͬ??Ա????

Two different MSP configurations for an organization. The first configuration shows the typical relationship between an MSP and an organization – a single MSP defines the list of members of an organization. In the second configuration, different MSPs are used to represent different organizational groups with national, international, and governmental affiliation.

һ????֯?????ֲ?ͬMSP???õ?һ????????ʾ??MSP????֮֯??ĵ??͹?ϵ - ????MSP????????֯??Ա?б��� ?ڵڶ????????У???ͬ??MSP???ڱ?ʾ???й??ң????ʺ??????????IJ?ͬ??֯?顣

Local and Channel MSPs¶

###????MSP???ŵ?MSP

MSPs appear in two places in a Blockchain network: channel configuration (channel MSPs), and locally on an actor’s premise (local MSP). Local MSPs defined for nodes (peer or orderer) and users (administrators that use the CLI or client applications that use the SDK). Every node and user must have a local MSP defined, as it defines who has administrative or participatory rights at that level and outside the context of a channel (who the administrators of a peer’s organization, for example).

MSP?????????????????е?????λ?ã??ŵ????ã? ?ŵ?MSP ???Լ??ڲ????ߵı??أ? ????MSP ???? ????MSP??Ϊ?ڵ㣨?ڵ????ڵ㣩???û???ʹ??CLI?Ĺ???Ա??ʹ??SDK?Ŀͻ???Ӧ?ó??򣩶??????ÿ???ڵ???û??????붨??һ??????MSP????Ϊ?????????ڸü???????ŵ?????֮??˭???й????????Ȩ?ޣ????磬һ???ڵ???֯?Ĺ???Ա????

In contrast, channel MSPs define administrative and participatory rights at the channel level. Every organization participating in a channel must have an MSP defined for it. Peers and orderers on a channel will all share the same view on channel MSPs, and will henceforth be able to authenticate correctly the channel participants. This means that if an organization wishes to join the channel, an MSP incorporating the chain of trust for the organization’s members would need to be included in the channel configuration. Otherwise transactions originating from this organization’s identities will be rejected.

?෴???ŵ?MSP???ŵ????????˹???Ͳ????Ȩ???? ?????ŵ???ÿ????֯????????һ??Ϊ?䶨???MSP??һ???ŵ??ϵĽڵ?ͱ???ڵ㽫???ŵ?MSP?Ϲ?????ͬ????ͼ?????Ҵ˺??ܹ???ȷ????֤?ŵ??????ߡ?????ζ?ţ????һ????֯ϣ????????ŵ???????Ҫ??????????֯??Ա????????MSP?????ŵ??????С? ???????Ը???֯????ݵĽ??׽????ܾ???

The key difference here between local and channel MSPs is not how they function, but their scope.

????MSP???ŵ?MSP֮??Ĺؼ????????????ǵ???????ʽ???????????ǵ? ??Χ ??

Local and channel MSPs. The trust domain (e.g., organization) of each peer is defined by the peer’s local MSP, e.g., ORG1 or ORG2. Representation of an organization on a channel is achieved by the inclusion of the organization’s MSP in the channel. For example, the channel of this figure is managed by both ORG1 and ORG2. Similar principles apply for the network, orderers, and users, but these are not shown here for simplicity.

????MSP???ŵ?MSP?? ÿ???ڵ???????????磬??֯???ɽڵ?ı???MSP???壬????ORG1??ORG2??ͨ?????ŵ??а?????֯??MSP??ʵ??һ????֯???ŵ??ϵı?ʾ?????磬??ͼ???ŵ?ͬʱ??ORG1??ORG2???���???Ƶ?ԭ???????????磬?ڵ???û?????Ϊ????????˴?δ??ʾ??Щԭ????

Local MSPs are only defined on the file system of the node or user to which they apply. Therefore, physically and logically there is only one local MSP per node or user. However, as channel MSPs are available to all nodes in the channel, they are logically defined once in the channel in its configuration. However, a channel MSP is instantiated on the file system of every node in the channel and kept synchronized via consensus. So while there is a copy of each channel MSP on the local file system of every node, logically a channel MSP resides on and is maintained by the channel or the network.

????MSP????????Ӧ?õĽڵ???û????ļ?ϵͳ?ϱ?????????ˣ????????Ϻ??߼??ϣ?ÿ???ڵ???û?ֻ??һ??????MSP?????ǣ??????ŵ?MSP???????ŵ??е????нڵ???????????????ϣ????????ŵ??н???һ???߼??ϵĶ??塣Ȼ?????ŵ?MSP???ŵ???ÿ???ڵ???ļ?ϵͳ?Ͻ???ʵ????????ͨ????ʶ????ͬ??????ˣ???Ȼÿ???ڵ?ı????ļ?ϵͳ?ϴ???ÿ???ŵ?MSP?ĸ????????߼???һ???ŵ?MSPפ???ڸ??ŵ??ϲ????ŵ???????ά????

You may find it helpful to see how local and channel MSPs are used by seeing what happens when a blockchain administrator installs and instantiates a smart contract, as shown in the diagram above.

ͨ???鿴??????????Ա??װ??ʵ???????ܺ?Լʱ?ᷢ??ʲô?????ܻ?????ʹ?ñ???MSP???ŵ?MSP???а?????????ͼ??ʾ??

An administrator B connects to the peer with an identity issued by RCA1 and stored in their local MSP. When B tries to install a smart contract on the peer, the peer checks its local MSP, ORG1-MSP, to verify that the identity of B is indeed a member of ORG1. A successful verification will allow the install command to complete successfully. Subsequently, B wishes to instantiate the smart contract on the channel. Because this is a channel operation, all organizations in the channel must agree to it. Therefore, the peer must check the MSPs of the channel before it can successfully commits this command. (Other things must happen too, but concentrate on the above for now.)

????ԱBʹ??RCA1????????ݸ??ڵ????Ӳ??洢???䱾??MSP?С???B?????ڽڵ??ϰ?װ???ܺ?Լʱ???ڵ????䱾??MSP ??ORG1-MSP??????֤B?????ȷʵ??ORG1?ij?Ա???ɹ???֤?????���װ????ɹ???ɡ? ???Bϣ?????ŵ???ʵ???????ܺ?Լ??????????һ???ŵ????????ŵ??е???????֯??????ͬ??ò???????ˣ??ڵ?????ȼ???ŵ???MSP??Ȼ????ܳɹ??ύ????? ??????????????Ҳ???뷢?????????ڹ?ע?????????ݡ???

One can observe that channel MSPs, just like the channel itself is a logical construct. They only become physical once they are instantiated on the local filesystem of the peers of the channel orgs, and managed by it.

????Թ۲쵽?ŵ?MSP???????ŵ???????һ?? ?߼??ṹ??????ֻ?????ŵ???֯?Ľڵ?ı????ļ?ϵͳ?Ͻ???ʵ??????Ż??Ϊ?????ϵģ??????????й??���

MSP Levels¶

###MSP??

The split between channel and local MSPs reflects the needs of organizations to administer their local resources, such as a peer or orderer nodes, and their channel resources, such as ledgers, smart contracts, and consortia, which operate at the channel or network level. It’s helpful to think of these MSPs as being at different levels, with MSPs at a higher level relating to network administration concerns while MSPs at a lower level handle identity for the administration of private resources. MSPs are mandatory at every level of administration – they must be defined for the network, channel, peer, orderer and users.

?ŵ?MSP?ͱ???MSP֮??ķ??뷴ӳ????֯?????䱾????Դ??????ڵ????ڵ㣩?????ŵ???Դ?????????ŵ??????缶????Ӫ?ķ????ʣ????ܺ?Լ?????ˣ??????󡣽???ЩMSP??Ϊ???ڲ?ͬ ??? ???а????ģ?MSP???????????????????صĸ??߼??𣬶??ϵͼ????MSP????˽????Դ??????????MSP??ÿ???????ζ??DZ???? -????Ϊ???磬?ŵ????ڵ㣬????ڵ???û?????MSP??

MSP Levels. The MSPs for the peer and orderer are local, whereas the MSPs for a channel (including the network configuration channel) are shared across all participants of that channel. In this figure, the network configuration channel is administered by ORG1, but another application channel can be managed by ORG1 and ORG2. The peer is a member of and managed by ORG2, whereas ORG1 manages the orderer of the figure. ORG1 trusts identities from RCA1, whereas ORG2 trusts identities from RCA2. Note that these are administration identities, reflecting who can administer these components. So while ORG1 administers the network, ORG2.MSP does exist in the network definition.

MSP?㡣 ?ڵ?ͱ???ڵ??MSP?DZ??صģ????ŵ???MSP???????????????ŵ????ڸ??ŵ??????в?????֮?乲?��� ?ڴ?ͼ?У??????????ŵ???ORG1???���????һ??Ӧ?ó????ŵ?????ORG1??ORG2???���?ڵ???ORG2?ij?Ա????ORG2???���??ORG1????ͼ?еı???ڵ㡣 ORG1????????RCA1????ݣ???ORG2????????RCA2????ݡ???ע?⣬??Щ?ǹ?????ݣ???ӳ??˭???Թ?????Щ????? ??ˣ?????ORG1???????磬??ORG2.MSPȷʵ?????????綨??????

• Network MSP: The configuration of a network defines who are the members in the network — by defining the participant organizations MSPs — as well as which of these members are authorized to perform administrative tasks (e.g., creating a channel).
• ????MSP?? ?????????ͨ?????????????֯??MSP?Լ???Щ??Ա????Ȩִ?й??????????磬?????ŵ????????? ˭???????еij?Ա??
• Channel MSP: It is important for a channel to maintain the MSPs of its members separately. A channel provides private communications between a particular set of organizations which in turn have administrative control over it. Channel policies interpreted in the context of that channel’s MSPs define who has ability to participate in certain action on the channel, e.g., adding organizations, or instantiating chaincodes. Note that there is no necessary relationship between the permission to administrate a channel and the ability to administrate the network configuration channel (or any other channel). Administrative rights exist within the scope of what is being administrated (unless the rules have been written otherwise – see the discussion of the ROLE attribute below).
• ?ŵ?MSP?? ?ŵ??????ܹ?????ά?????Ա??MSP???ŵ????ض???һ????֮֯???ṩ˽??ͨ?ţ?????Щ??֯?ַ??? ????????й?????ơ??ڸ??ŵ???MSP?Ļ????н??͵??ŵ????Զ???˭???????????ŵ??ϵ?ijЩ??????磬?????֯ ??ʵ?????????롣??ע?⣬????һ???ŵ???Ȩ?????????????????ŵ??????κ??????ŵ?????????֮??û?б?Ȼ?Ĺ?ϵ ???????Ȩ?޴????ڹ??���Χ?ڣ????ǹ????Ѿ????б?д - ??????????ROLE???Ե????ۣ???
• Peer MSP: This local MSP is defined on the file system of each peer and there is a single MSP instance for each peer. Conceptually, it performs exactly the same function as channel MSPs with the restriction that it only applies to the peer where it is defined. An example of an action whose authorization is evaluated using the peer’s local MSP is the installation of a chaincode on the peer premise.
• ?ڵ?MSP?? ??ÿ???ڵ???ļ?ϵͳ?϶??屾??MSP??????ÿ???ڵ㶼??һ??MSPʵ???? ?Ӹ????Ͻ?????ִ?????? ??MSP??ȫ??ͬ?Ĺ??ܣ?Լ?????????????ڶ??????Ľڵ㡣 ʹ?ýڵ?ı???MSP????????Ȩ?IJ?????һ??ʾ?????ڽڵ? ǰ???°?װ?????롣
• Orderer MSP: Like a peer MSP, an orderer local MSP is also defined on the file system of the node and only applies to that node. Like peer nodes, orderers are also owned by a single organization and therefore have a single MSP to list the actors or nodes it trusts.
• ????ڵ?MSP?? ??ڵ?MSPһ????????ڵ㱾??MSPҲ?ڽڵ???ļ?ϵͳ?϶??岢?ҽ??????ڸýڵ㡣 ??ڵ?һ ????????ڵ?Ҳ?ɵ?????֯ӵ?У????ֻ??һ??MSP???г??????εIJ????߻?ڵ㡣

MSP Structure¶

###MSP?ṹ

So far, you’ve seen that the two most important elements of an MSP are the specification of the (root or intermediate) CAs that are used to used to establish an actor’s or node’s membership in the respective organization. There are, however, more elements that are used in conjunction with these two to assist with membership functions.

??ĿǰΪֹ?????Ѿ?????һ??MSP??????????Ҫ??Ԫ???ǣ??????м䣩CA?ĸ?ʽ??????????Ӧ????֯?н????????߻?ڵ?ij?Ա?ʸ񡣵??ǣ??и????Ԫ??????????Ԫ?ؽ??ʹ????Э????Ա??ݵĹ??ܡ?

The figure above shows how a local MSP is stored on a local filesystem. Even though channel MSPs are not physically structured in exactly this way, it’s still a helpful way to think about them.

??ͼ??ʾ?˱???MSP??δ洢?ڱ????ļ?ϵͳ?С??????ŵ?MSP??????ṹ??????ˣ???????Ȼ??һ?????õķ?ʽ??˼????????

As you can see, there are nine elements to an MSP. It’s easiest to think of these elements in a directory structure, where the MSP name is the root folder name with each subfolder representing different elements of an MSP configuration.

??????????һ??MSP?оŸ?Ԫ?ء???򵥵ķ???????Ŀ¼?ṹ?п?????ЩԪ?أ?????MSP?????Ǹ??ļ??????ƣ?ÿ?????ļ??д???MSP???õIJ?ͬԪ?ء?

Let’s describe these folders in a little more detail and see why they are important.

?????Ǹ???ϸ????????Щ?ļ??У???????Ϊʲô???Ǻ???Ҫ??

• Root CAs: This folder contains a list of self-signed X.509 certificates of the Root CAs trusted by the organization represented by this MSP. There must be at least one Root CA X.509 certificate in this MSP folder.

• ??CA?? ???ļ??а?????MSP????ʾ????֯?????εĸ?CA????ǩ??X.509֤???б��� ??MSP?ļ????б?????????һ ??Root CA X.509֤?顣

  This is the most important folder because it identifies the CAs from which all other certificates must be derived to be considered members of the corresponding organization. ????????Ҫ???ļ??У???Ϊ????ʶCA???Ӹ?CA?????뱻??Ϊ??Ӧ??֯?ij?Ա????????????????????֤??.

• Intermediate CAs: This folder contains a list of X.509 certificates of the Intermediate CAs trusted by this organization. Each certificate must be signed by one of the Root CAs in the MSP or by an Intermediate CA whose issuing CA chain ultimately leads back to a trusted Root CA.

• ?м?CA?? ???ļ??а???????֯???ε??м?CA??X.509֤???б��� ÿ??֤???????MSP?е?һ????CA???м?CAǩ?? ???м?CA?䷢??CA?????ջ᷵?ص??????εĸ?CA.

  Intuitively to see the use of an intermediate CA with respect to the corresponding organization’s structure, an intermediate CA may represent a different subdivision of the organization, or the organization itself (e.g., if a commercial CA is leveraged for the organization’s identity management). In the latter case other intermediate CAs, lower in the CA hierarchy can be used to represent organization subdivisions. Here you may find more information on best practices for MSP configuration. Notice, that it is possible to have a functioning network that does not have any Intermediate CA, in which case this folder would be empty.

  ֱ?۵ؿ??????????Ӧ??֯?Ľṹʹ???м?CA???м?CA???Ա?ʾ??֯????֯????IJ?ͬϸ?֣????磬???һ????ҵCA ??????֯????ݹ??���???ں?һ??????£?CA??νṹ?нϵ͵??????м?CA?????ڱ?ʾ??֯??ϸ?֡???????????? ?ҵ??й?MSP???õ????ʵ???ĸ?????Ϣ????ע?⣬????ʹһ????????????????û???κ??м?CA????????????£????? ???н?Ϊ?ա?

  Like the Root CA folder, this folder defines the CAs from which certificates must be issued to be considered members of the organization.

  ???CA?ļ???һ???????ļ??ж????˱???䷢֤????ܱ???Ϊ??֯??Ա??CA.

• Organizational Units (OUs): These are listed in the $FABRIC_CFG_PATH/msp/config.yaml file and contain a list of organizational units, whose members are considered to be part of the organization represented by this MSP. This is particularly useful when you want to restrict the members of an organization to the ones holding an identity (signed by one of MSP designated CAs) with a specific OU in it.

• ??֯??λ??OU???? ??Щ??λ????$ FABRIC_CFG_PATH / msp / config.yaml?ļ??У???????һ????֯??λ???? ?���???Ա????Ϊ??MSP?????????֯??һ???֡? ????ϣ??????֯??Ա????Ϊӵ?????а????ض?OU????ݣ???MSPָ?? ??CA֮һǩ?????ij?Աʱ???˹??????????á?

  Specifying OUs is optional. If no OUs are listed, all the identities that are part of an MSP – as identified by the Root CA and Intermediate CA folders – will be considered members of the organization.

  ?ض?OU?ǿ?ѡ?ġ? ???δ?г??κ?OU??????ΪMSPһ???ֵ???????ݣ??ɸ?CA???м?CA?ļ??б?ʶ????????Ϊ??֯?? ??Ա??

• Administrators: This folder contains a list of identities that define the actors who have the role of administrators for this organization. For the standard MSP type, there should be one or more X.509 certificates in this list.

• ????Ա?? ???ļ??а???һ????ʶ?б���???ڶ?????д???֯????Ա??ɫ?IJ????ߡ? ???ڱ?׼MSP???ͣ????б??? Ӧ????һ??????X.509֤?顣

  It’s worth noting that just because a actor has the role of an administrator it doesn’t mean that they can administer particular resources! The actual power a given identity has with respect to administering the system, is determined by the policies that manage system resources. For example, a channel policy might specify that ORG1-MANUFACTURING administrators have the rights to add new organizations to the channel, whereas the ORG1-DISTRIBUTION administrators have no such rights.

  ֵ??ע????ǣ???????Ϊһ???????߾??й???Ա?Ľ?ɫ????????ζ?????ǿ??Թ????ض?????Դ??????????ڹ???ϵͳ?? ???ʵ?ʹ?Ч?ɹ???ϵͳ??Դ?IJ??Ծ????????磬?ŵ????Կ???ָ??ORG1-MANUFACTURING????Ա??Ȩ??????֯??ӵ? ?ŵ?????ORG1-DISTRIBUTION????Ա??û?д???Ȩ?ޡ?

  Even though an X.509 certificate has a ROLE attribute (specifying, for example, that a actor is an admin), this refers to a actor’s role within its organization rather than on the blockchain network. This is similar to the purpose of the OU attribute, which – if it has been defined – refers to a actor’s place in the organization.

  ??ʹX.509֤?????ROLE???ԣ????磬ָ??ij?????????ǹ???Ա??????Ҳ??ָ??????֯?ڶ??????????????????еĽ?ɫ ??????????OU???Ե?Ŀ?ģ?????Ѿ????壬??ָ??????֯?в????ߵ?λ?á?

  The ROLE attribute can be used to confer administrative rights at the channel level if the policy for that channel has been written to allow any administrator from an organization (or certain organizations) permission to perform certain channel functions (such as instantiating chaincode). In this way, an organization role can confer a network role. This is conceptually similar to how having a driver’s license issued by the US state of Florida entitles someone to drive in every state in the US.

  ????ѱ?д???ŵ??IJ???????????֯????ijЩ??֯?????κι???Աִ??ijЩ?ŵ????ܣ?????ʵ?????????룩????ROLE ???Կ????????ŵ??????????Ȩ?ޡ? ͨ?????ַ?ʽ????֯??ɫ???Ը????????ɫ?? ???ڸ?????????????????????? ?ݰ䷢?ļ?ʻִ???????Ȩij??????????ÿ???ݿ?????

• Revoked Certificates: If the identity of a actor has been revoked, identifying information about the identity – not the identity itself – is held in this folder. For X.509-based identities, these identifiers are pairs of strings known as Subject Key Identifier (SKI) and Authority Access Identifier (AKI), and are checked whenever the X.509 certificate is being used to make sure the certificate has not been revoked.

• ????֤?飺 ????????ߵ?????ѱ??????????ڴ??ļ????б????й???ݵ???Ϣ - ????????ݱ??��� ???ڻ??? X.509????ݣ???Щ????dz?Ϊ??????Կ??ʶ????SKI??????Ȩ???ʱ?ʶ????AKI?????ַ????ԣ?????ÿ??ʹ??X.509֤ ????ȷ??֤????δ??????ʱ???ͻ??????м?顣

  This list is conceptually the same as a CA’s Certificate Revocation List (CRL), but it also relates to revocation of membership from the organization. As a result, the administrator of an MSP, local or channel, can quickly revoke a actor or node from an organization by advertising the updated CRL of the CA the revoked certificate as issued by. This “list of lists” is optional. It will only become populated as certificates are revoked.

  ???б??ڸ???????CA??֤??????б���CRL????ͬ??????Ҳ?????֯?г?????Ա????йء? ??ˣ?MSP?Ĺ???Ա?????? ???ŵ???????ͨ????CA???????ѳ???֤????????CA???µ?CRL?????ٳ?????֯?еIJ????߻?ڵ㡣 ????ǿ?ѡ?ġ? ?? ֻ????֤?鱻????ʱ??䡣

• Node Identity: This folder contains the identity of the node, i.e., cryptographic material that — in combination to the content of KeyStore – would allow the node to authenticate itself in the messages that is sends to other participants of its channels and network. For X.509 based identities, this folder contains an X.509 certificate. This is the certificate a peer places in a transaction proposal response, for example, to indicate that the peer has endorsed it – which can subsequently be checked against the resulting transaction’s endorsement policy at validation time.

• ?ڵ??ʶ?? ???ļ??а????ڵ?ı?ʶ????????KeyStore??ϵļ??ܲ??Ͻ?????ڵ??ڷ??͸????ŵ???????????? ?????ߵ???Ϣ?ж?????????????֤?? ???ڻ???X.509?ı?ʶ?????ļ??а??? X.509֤???? ???ǽڵ??ڽ??????? ??Ӧ?з??õ?֤?飬???磬????ָʾ?ڵ??Ѿ??Ͽ??? - ???????ڿ???֤ʱ???ڶԽ?????׵??Ͽɲ??Խ??м?顣

  This folder is mandatory for local MSPs, and there must be exactly one X.509 certificate for the node. It is not used for channel MSPs.

  ???ļ??ж??ڱ???MSP?DZ???ģ????Ҹýڵ????ֻ??һ??X.509֤?顣 ?????????ŵ?MSP??

• KeyStore for Private Key: This folder is defined for the local MSP of a peer or orderer node (or in an client’s local MSP), and contains the node’s signing key. This key matches cryptographically the node’s identity included in Node Identity folder and is used to sign data – for example to sign a transaction proposal response, as part of the endorsement phase.

• ˽Կ??KeyStore?? ???ļ?????Ϊ?ڵ????ڵ?ı???MSP????ͻ??˵ı???MSP??????ģ??????ڵ?? ǩ ????Կ?? ????Կ?Լ??ܷ?ʽƥ???ڽڵ??ʶ?ļ????а????Ľڵ??ʶ????????ǩ?????? - ????ǩ??????????Ӧ ????Ϊ?Ͽɽ׶ε?һ???֡?

  This folder is mandatory for local MSPs, and must contain exactly one private key. Obviously, access to this folder must be limited only to the identities, users who have administrative responsibility on the peer.

  ???ļ??ж??ڱ???MSP?DZ???ģ????ұ???ֻ????һ??˽Կ?? ??Ȼ???Դ??ļ??еķ???Ȩ?ޱ???????ڽڵ??Ͼ??й? ??ְ????û???ݡ?

  Configuration of a channel MSPs does not include this part, as channel MSPs aim to offer solely identity validation functionalities, and not signing abilities.

  ?ŵ? MSP?????ò??????˲??֣???Ϊ?ŵ?MSPּ?ڽ??ṩ?????֤???ܣ???????ǩ?????ܡ?

• TLS Root CA: This folder contains a list of self-signed X.509 certificates of the Root CAs trusted by this organization for TLS communications. An example of a TLS communication would be when a peer needs to connect to an orderer so that it can receive ledger updates.

• TLS??CA?? ???ļ??а???????֯???ε????? TLSͨ?? ?ĸ?CA????ǩ??X.509֤???б��� TLSͨ?ŵ?һ??ʾ?? ?ǵ??ڵ???Ҫ???ӵ?????ڵ??Ա??????Խ??շ????ʸ???ʱ??

  MSP TLS information relates to the nodes inside the network, i.e., the peers and the orderers, rather than those that consume the network – applications and administrators.

  MSP TLS??Ϣ?漰?????ڵĽڵ㣬???ڵ?ͱ???ڵ㣬????????Щ????????Ľڵ? - Ӧ?ó???͹???Ա??

  There must be at least one TLS Root CA X.509 certificate in this folder.

  ???ļ????б?????????һ??TLS??CA X.509֤?顣

• TLS Intermediate CA: This folder contains a list intermediate CA certificates CAs trusted by the organization represented by this MSP for TLS communications. This folder is specifically useful when commercial CAs are used for TLS certificates of an organization. Similar to membership intermediate CAs, specifying intermediate TLS CAs is optional.

• TLS?м?CA?? ???ļ??а???һ???б���?м?CA֤?鱻??MSP?????????֯?????Σ???????TLSͨ?š?????ҵCA???? һ????֯??TLS֤??ʱ?????ļ????ر????á????Ա?м?CA???ƣ??м?TLS CA?ǿ?ѡ?ġ?

  For more information on TLS, click here.

  ?й?TLS?ĸ?????Ϣ???뵥???˴?

If you’ve read this doc as well as our doc on Identity), you should have a pretty good grasp of how identities and membership work in Hyperledger Fabric. You’ve seen how a PKI and MSPs are used to identify the actors collaborating in a blockchain network. You’ve learned how certificates, public/private keys, and roots of trust work, in addition to how MSPs are physically and logically structured.

??????Ѿ??Ķ??????ĵ??Լ????ǵ?????ĵ?????ô??Ӧ?÷dz??˽?Hyperledger Fabric?е???ݺͳ?Ա??ݡ? ???Ѿ??˽??????ʹ??PKI??MSP??ʶ????????????????Э???IJ????ߡ? ????MSP????????߼??ṹ֮?⣬?????˽???֤?飬??Կ/˽Կ?????θ??Ĺ???ԭ?���

A word on terminology¶

一个专业术语¶

Hyperledger Fabric implements smart contracts with a technology concept it calls chaincode – simply a piece of code that accesses the ledger, written in one of the supported programming languages. In this topic, we’ll usually use the term chaincode, but feel free to read it as smart contract if you’re more used to this term. It’s the same thing!

Hyperledger Fabric通过一种称为链码的技术来执行智能合约，链码简单说就是以某种Fabric支持的编程 语言编写的一段与账本连接的代码。在本专题中，我们会很频繁地用到链码这个概念，不过若你对智能 合约比较熟悉，你也可以自由地将前者当作后者。因为它们之间并无区别！

Ledgers and Chaincode¶

##账本与链码

Let’s look at a peer in a little more detail. We can see that it’s the peer that hosts both the ledger and chaincode. More accurately, the peer actually hosts instances of the ledger, and instances of chaincode. Note that this provides a deliberate redundancy in a Fabric network – it avoids single points of failure. We’ll learn more about the distributed and decentralized nature of a blockchain network later in this topic. 让我们更详细地研究一下peer节点。我们可以看到它是一种保存保存了账本和链码的节点。更准确地说， peer节点实际上保存保存的是账本和链码的实例。注意这在Fabric网络中提供了有意的冗余以避免单点故障。 在本专题接下来的部分，我们会学到更多关于区块链网络分布式和去中心化的特性。

A peer hosts instances of ledgers and instances of chaincodes. In this example, P1 hosts an instance of ledger L1 and an instance of chaincode S1. There can be many ledgers and chaincodes hosted on an individual peer. 一个peer节点保存了账本和链码的实例。在本例中，节点P1保存了账本L1和链码S1的各一个实例。 一个独立节点其实可以保存多个账本和链码。

Because a peer is a host for ledgers and chaincodes, applications and administrators must interact with a peer if they want to access these resources. That’s why peers are considered the most fundamental building blocks of a Hyperledger Fabric blockchain network. When a peer is first created, it has neither ledgers nor chaincodes. We’ll see later how ledgers get created, and chaincodes get installed, on peers. 由于peer节点保存了账本和链码，所以如果应用程序和管理员想访问这些资源，他们就必须和节点交互。 这也是为什么节点被看作组成Hyperledger Fabric区块链网络中区块的最基本元素。一个节点在创建之初 并不保存账本或链码。稍后我们会看到节点上的账本如何被创建以及链码如何被安装。

Applications and Peers¶

##应用程序和节点

We’re now going to show how applications interact with peers to access the ledger. Ledger-query interactions involve a simple three step dialogue between an application and a peer; ledger-update interactions are a little more involved, and require two extra steps. We’ve simplified these steps a little to help you get started with Hyperledger Fabric, but don’t worry – what’s most important to understand is the difference in application-peer interactions for ledger-query compared to ledger-update transaction styles. 现在我们要展示应用程序如何通过与peer节点交互来实现访问账本。账本查询交互涉及应用程序和 peer节点间简单的三步会话；账本更新交互与之联系更加密切，它还要求额外的两步。我们已经对这些 步骤稍作简化以便你开始了解Hyperledger Fabric，不过请勿担心——最有必要理解的是程序—节点交互在执行账本查询时相比于账本更新时呈现的差异。

Applications always connect to peers when they need to access ledgers and chaincodes. The Hyperledger Fabric Software Development Kit (SDK) makes this easy for programmers – its APIs enable applications to connect to peers, invoke chaincodes to generate transactions, submit transactions to the network that will get ordered and committed to the distributed ledger, and receive events when this process is complete. 当需要访问账本和链码时，应用程序都会连接peer节点。Hyperledger Fabric软件开发工具包使其对 程序员而言更加容易——它的应用编程接口使应用程序能连接到节点，调用链码来生成交易，并将交易 上传到网络中进行排序然后提交到分布式账本中，并且在处理完成时接收事件。

Through a peer connection, applications can execute chaincodes to query or update the ledger. The result of a ledger query transaction is returned immediately, whereas ledger updates involve a more complex interaction between applications, peers, and orderers. Let’s investigate in a little more detail. 通过与节点的连接，应用程序可以执行链码以查询或更新账本。账本查询交易的结果会立即反馈， 而账本更新则涉及应用程序，peer节点和排序节点之间更复杂的交互，让我们更详细地研究一下。

Peers, in conjunction with orderers, ensure that the ledger is kept up-to-date on every peer. In this example application A connects to P1 and invokes chaincode S1 to query or update the ledger L1. P1 invokes S1 to generate a proposal response that contains a query result or a proposed ledger update. Application A receives the proposal response, and for queries the process is now complete. For updates, A builds a transaction from the all the responses, which it sends it to O1 for ordering. O1 collects transactions from across the network into blocks, and distributes these to all peers, including P1. P1 validates the transaction before applying to L1. Once L1 is updated, P1 generates an event, received by A, to signify completion. peer节点与排序节点相连，保证每一个peer节点上的账本都是最新的。在本例中应用程序A连接 peer节点P1且调用链码S1以查询或更新账本L1。P1调用S1来生成一个包含了查询结果或提议 账本更新的提案响应。应用程序A接收该响应，此时查询过程便完成了。为了执行更新，程序A从所有它发送到排序节点O1以进行排序的响应中建立交易。排序节点O1收集整个网络中的交易并写入区块，并将 它们分发到包括P1在内的所有peer节点上。P1在将其应用到L1之前先进行验证。一旦L1更新完成，P1就 生成一个事件，由A来接收以表示完成。

A peer can return the results of a query to an application immediately because all the information required to satisfy the query is in the peer’s local copy of the ledger. Peers do not consult with other peers in order to return a query to an application. Applications can, however, connect to one or more peers to issue a query – for example to corroborate a result between multiple peers, or retrieve a more up-to-date result from a different peer if there’s a suspicion that information might be out of date. In the diagram, you can see that ledger query is a simple three step process. 一个peer节点可以将查询的结果立即反馈给应用程序，因为完成查询所需要的全部信息都在peer节点 本地的账本副本中。peer节点之间不需要相互协商来将查询反馈给应用程序。但是，应用程序可以连接 一个或多个peer节点来提出查询——比如要确认多个peer节点间的查询结果，或者若怀疑信息可能过期可以 从另一个peer节点恢复最新的结果。在该图中，你能发现账本查询是简单的三个步骤。

An update transaction starts in the same way as a query transaction, but has two extra steps. Although ledger-updating applications also connect to peers to invoke a chaincode, unlike with ledger-querying applications, an individual peer cannot perform a ledger update at this time, because other peers must first agree to the change – a process called consensus. Therefore, peers return to the application a proposed update – one that this peer would apply subject to other peers’ prior agreement. The first extra step – four – requires that applications send an appropriate set of matching proposed updates to the entire network of peers as a transaction for commitment to their respective ledgers. This is achieved by the application using an orderer to package transactions into blocks, and distribute them to the entire network of peers, where they can be verified before being applied to each peer’s local copy of the ledger. As this whole ordering processing takes some time to complete (seconds), the application is notified asynchronously, as shown in step five. 一个更新事件的开始方式和查询事件一样，但还有额外的两步。尽管账本更新程序也连接peer节点以调用 链码，但与账本查询程序不同，单个peer节点此时不能执行账本更新，因为其他节点必须首先认同 账本的改变——即一个称为共识的过程。所以，peer节点为应用程序反馈 提议的更新——该更新将 被该节点加入其他节点先前的认同中。第一个额外步骤——four——要求应用程序向整个节点网络发送 一组合适的匹配提议更新，作为提交到各个节点各自账本的交易。该过程通过应用程序使用排序节点将交易打包成区块， 并将它们分发到整个节点网络上来完成，网络中的这些交易在被加入到每个节点的账本副本前会 被验证。由于整个排序进程需要耗费一些时间来完成（几秒），故该程序是异步通知的，如第五步所示。

Later in this topic, you’ll learn more about the detailed nature of of this ordering process – and for a really detailed look at this process see the Transaction Flow topic. 在本专题后面的部分中，你会学习更多关于排序过程的详细原理——若要了解该进程更加详细的内容， 参见专题交易流程。

Peers and Channels¶

Although this topic is about peers rather than channels, it’s worth spending a little time understanding how peers interact with each other, and applications, via channels – a mechanism by which a set of components within a blockchain network can communicate and transact privately. 尽管本专题更多涉及的是peer节点而非通道，我们也值得花一点时间来了解各peer节点之间、peer节点与应 用程序之间是如何通过通道实现交互的——这是一种区块链网络中一组组成元素之间可以私下 交流与交易的机制。

These components are typically peer nodes, orderer nodes, and applications, and by joining a channel they agree to come together to collectively share and manage identical copies of the ledger for that channel. Conceptually you can think of channels as being similar to groups of friends (though the members of a channel certainly don’t need to be friends!). A person might have several groups of friends, with each group having activities they do together. These groups might be totally separate (a group of work friends as compared to a group of hobby friends), or there can be crossover between them. Nevertheless each group is its own entity, with “rules” of a kind. 这些组成元素主要有peer节点，排序节点和应用程序，通过加入同一通道，上述组成元素可以在通道 内共享和管理相同的账本副本。从概念上你可以把通道认为是一群朋友的集合（尽管通道内的成员不 需要是朋友）。一个人可能有好几群朋友，每一群的朋友都有他们的集体活动。这些不同的朋友圈子可能完 全不相干（如一群工作伙伴相比于一群有共同爱好的朋友），或者他们之间也可以有交集。然而每一群 都各自为一个实体，有自己的一套“规则”。

Channels allow a specific set of peers and applications to communicate with each other within a blockchain network. In this example, application A can communicate directly with peers P1 and P2 using channel C. You can think of the channel as a pathway for communications between particular applications and peers. (For simplicity, orderers are not shown in this diagram, but must be present in a functioning network.) 通道允许一组特定的peer节点和应用程序在区块链网络中互相交流。在本例中，程序A可以通过通道C 直接和节点P1和P2交流。你可以把通道认为是特定的节点和程序之间交流的途径（简单起见， 本图并未画出排序节点，但其在一个功能网络中必须出现。）

We see that channels don’t exist in the same way that peers do – it’s more appropriate to think of a channel as a logical structure that is formed by a collection of physical peers. It is vital to understand this point – peers provide the control point for access to, and management of, channels. 我们看到通道的存在方式与peer节点不同——将通道认为是由一组物理节点组成的逻辑结构更恰当。 明白这一点至关重要——peer节点提供了访问和管理通道的控制点。

Peers and Organizations¶

##peer节点与组织

Now that you understand peers and their relationship to ledgers, chaincodes and channels, you’ll be able to see how multiple organizations come together to form a blockchain network. 现在你明白了peer节点及其与账本、链码和通道的关系，你能看到多个组织怎样共同组成一个区块链网络。

Blockchain networks are administered by a collection of organizations rather than a single organization. Peers are central to how this kind of distributed network is built because they are owned by – and are the connection points to the network for – these organizations. 区块链网络由多个而非单个组织管理。peer节点对于这种分布式网络的建立起着核心作用，因为它们是 由这些组织拥有的，并且是这些组织的网络连接点。

Peers in a blockchain network with multiple organizations. The blockchain network is built up from the peers owned and contributed by the different organizations. In this example, we see four organizations contributing eight peers to form a network. The channel C connects five of these peers in the network N – P1, P3, P5, P7 and P8. The other peers owned by these organizations have not been joined to this channel, but are typically joined to at least one other channel. Applications that have been developed by a particular organization will connect to their own organization’s peers as well as those of different organizations. Again,for simplicity, an orderer node is not shown in this diagram. 区块链网络中与多个组织相连的peer节点。不同组织拥有并贡献的peer节点建立了区块链网络。在本例中， 我们看到四个组织贡献了八个peer节点组成一个网络。在网络N中，通道C连接了这八个节点中的五个——P1、 P3、P5、P7和P8。这些组织拥有的其他节点并未接入该信道，但通常都接入至少一个其他通道。某个组织 开发的应用程序会与本组织和其他组织的节点相连。重申一遍，简单起见，本图未展示排序节点。

It’s really important that you can see what’s happening in the formation of a blockchain network. The network is both formed and managed by the multiple organizations who contribute resources to it. Peers are the resources that we’re discussing in this topic, but the resources an organization provides are more than just peers. There’s a principle at work here – the network literally does not exist without organizations contributing their individual resources to the collective network. Moreover, the network grows and shrinks with the resources that are provided by these collaborating organizations. 重要的是你能看到在该区块链网络结构中发生了什么。网络是由贡献资源的多个组织组成并管理的。 本专题中我们讨论的资源即是peer节点，但组织提供的资源远非于此。可运行的区块链网络有一个原 则——如果各成员组织没有向这个集体网络贡献他们的个体资源，此网络原则上就不存在了。此外，网络也随着这些协作组织 提供的资源扩大和缩小。

You can see that (other than the ordering service) there are no centralized resources – in the example above, the network, N, would not exist if the organizations did not contribute their peers. This reflects the fact that the network does not exist in any meaningful sense unless and until organizations contribute the resources that form it. Moreover, the network does not depend on any individual organization – it will continue to exist as long as one organization remains, no matter which other organizations may come and go. This is at the heart of what it means for a network to be decentralized. 你能看到（除了排序服务外）并没有中心化的资源——在上例中，如果组织不贡献自己的peer节点， 网络N不会存在。这反映了这样一个事实，即除非组织贡献出组成 它的资源，否则网络从任何意义上都不存在，。此外，网络不依赖于任何一个组织——只要有一个组织留下，网络就会继续存在，无论其他 组织可能加入或离开。这正是网络去中心化的核心意义所在。

Applications in different organizations, as in the example above, may or may not be the same. That’s because it’s entirely up to an organization how its applications process their peers’ copies of the ledger. This means that both application and presentation logic may vary from organization to organization even though their respective peers host exactly the same ledger data. 正如上例所示，不同组织的应用程序，或许一样或许不同。这是因为程序如何处理节点的账本副本完 全取决于组织。这意味着即使不同组织的节点记录了完全相同的账本数据，它们的应用程序和呈现逻 辑也可能不同。

Applications either connect to peers in their organization, or peers in another organization, depending on the nature of the ledger interaction that’s required. For ledger-query interactions, applications typically connect to their own organization’s peers. For ledger-update interactions, we’ll see later why applications need to connect to peers in every organization that is required to endorse the ledger update. 应用程序要么连接到自身组织的peer节点，要么连接到其他组织的peer节点，这取决于所需的账本交 互的特性。对于账本查询交互，程序通常会连接到自身组织的节点上。至于账本更新交互，稍后我们 会看到为什么应用程序必须连接到每个需要用来对账本更新背书的组织的节点上。

Peers and Identity¶

peer节点与身份¶

Now that you’ve seen how peers from different organizations come together to form a blockchain network, it’s worth spending a few moments understanding how peers get assigned to organizations by their administrators. 现在你已经看到来自不同组织的peer节点是如何一起组成一个区块链网络的了，我们值得花几分钟 来理解这些节点怎样被管理员分配到各个组织。

Peers have an identity assigned to them via a digital certificate from a particular certificate authority. You can read lots more about how X.509 digital certificates work elsewhere in this guide, but for now think of a digital certificate as being like an ID card that provides lots of verifiable information about a peer. Each and every peer in the network is assigned a digital certificate by an administrator from its owning organization. peer节点具有通过来自特定证书机构的数字证书分配给它们的身份，在本指南的其他部分你可以 阅读更多关于X.509数字证书如何工作的信息，但现在请将数字证书看作一张提供大量关于节点的 可证实信息的身份证。网络中的每个peer节点都由管理员从其拥有的组织中分配数字证书 。

When a peer connects to a channel, its digital certificate identifies its owning organization via a channel MSP. In this example, P1 and P2 have identities issued by CA1. Channel C determines from a policy in its channel configuration that identities from CA1 should be associated with Org1 using ORG1.MSP. Similarly, P3 and P4 are identified by ORG2.MSP as being part of Org2. 当一个节点接入通道时，它的数字证书就通过通道MSP标识了它所属的组织。在本例中，节点P1 和P2具有CA1颁发的身份。通道C根据其通道配置的策略确定来自CA1的身份标识应该使用ORG1.MSP 与Org1关联。相似地，P3和P4由ORG2.MSP认定为Org2的一部分。

Whenever a peer connects using a channel to a blockchain network, a policy in the channel configuration uses the peer’s identity to determine its rights. The mapping of identity to organization is provided by a component called a Membership Service Provider (MSP) – it determines how a peer gets assigned to a specific role in a particular organization and accordingly gains appropriate access to blockchain resources. Moreover, a peer can only be owned by a single organization, and is therefore associated with a single MSP. We’ll learn more about peer access control later in this topic, and there’s an entire topic on MSPs and access control policies elsewhere in this guide. But for now, think of an MSP as providing linkage between an individual identity and a particular organizational role in a blockchain network. 每当一个节点使用通道接入区块链网络，通道配置的策略就通过节点身份验证它的权限。身份到组织 的映射是由叫做成员资格服务提供者（MSP）的成分提供的——它决定了peer节点在特定组织中如何被分配 特定角色，并相应地获得区块链资源适当的访问权限，此外，一个节点只能被单个组织拥有，因此与单个MSP关联。本专题的稍后部分我们 将学习更多关于节点访问控制的内容，且本指南的其他部分有一整个关于MSP和接入控制策略的专题。 但现在，请将MSP看作在区块链网络中，为节点身份和特殊组织角色提供连接的工具。

And to digress for a moment, peers as well as everything that interacts with a blockchain network acquire their organizational identity from their digital certificate and an MSP. Peers, applications, end users, administrators, orderers must have an identity and an associated MSP if they want to interact with a blockchain network. We give a name to every entity that interacts with a blockchain network using an identity – a principal. You can learn lots more about principals and organizations elsewhere in this guide, but for now you know more than enough to continue your understanding of peers! 说句题外话，peer节点和所有其他与区块链网络交互的元素一样，从他们的数字证书和MSP中获取组 织身份。peer节点、应用程序、终端用户、管理员、排序节点如果要和区块链网络交互，都必须要有一 个身份以及一个关联的MSP。我们给所有通过身份和区块链网络交互的实体一个名字——主体。在本指南 的其他部分，你能学到更多关于主体和组织的内容，但现在你所知道的已经超过你继续理解peer节点所需！

Finally, note that it’s not really important where the peer is physically located – it could reside in the cloud, or in a data centre owned by one of the organizations, or on a local machine – it’s the identity associated with it that identifies it as owned by a particular organization. In our example above, P3 could be hosted in Org1’s data center, but as long as the digital certificate associated with it is issued by CA2, then it’s owned by Org2. 最后，请记住peer节点的物理位置并不重要——它可以存在于云端，或者在某个组织拥有的数据中心中， 亦或是在一个本地机器上——与它绑定的身份证实了它被某一特定的组织拥有。在上面的例子中，P3可 以存储在Org1的数据中心中，但只要与它绑定的数字证书是由CA2颁发的，它就属于Org2。

Peers and Orderers¶

peer节点与排序节点¶

We’ve seen that peers form a blockchain network, hosting ledgers and chaincodes contracts which can be queried and updated by peer-connected applications. However, the mechanism by which applications and peers interact with each other to ensure that every peer’s ledger is kept consistent is mediated by special nodes called orderers, and it’s these nodes to which we now turn our attention. 我们已经看到peer节点组成区块链网络，保存账本和能被与节点相连的应用程序查询和更新的链码合同。 然而，应用程序和peer节点相互作用以确保每个peer节点的账本保持一致的机制是由一种称为排序节点的特 殊节点所调节的，排序节点也正是我们正要关注的。

An update transaction is quite different to a query transaction because a single peer cannot, on its own, update the ledger – it requires the consent of other peers in the network. A peer requires other peers in the network to approve a ledger update before it can be applied to a peer’s local ledger. This process is called consensus – and takes much longer to complete than a query. But when all the peers required to approve the transaction do so, and the transaction is committed to the ledger, peers will notify their connected applications that the ledger has been updated. You’re about to be shown a lot more detail about how peers and orderers manage the consensus process in this section. 更新交易和查询交易颇有不同，因为单个peer节点无法独立更新账本——这要求网络中其他节点的同意。 在节点为本地账本执行更新之前，它需要网络中其他节点的支持。这个过程称为共识——它比查询要多花 很长时间。但是当所有需要的节点支持了该交易的更新，且交易被提交到账本上时，peer节点将通知与之相连的应用 程序账本已更新。本节接下来的部分，你将看到更多关于peer节点和排序节点如何管理共识进程的细节。

Specifically, applications that want to update the ledger are involved in a 3-phase process, which ensures that all the peers in a blockchain network keep their ledgers consistent with each other. In the first phase, applications work with a subset of endorsing peers, each of which provide an endorsement of the proposed ledger update to the application, but do not apply the proposed update to their copy of the ledger. In the second phase, these separate endorsements are collected together as transactions and packaged into blocks. In the final phase, these blocks are distributed back to every peer where each transaction is validated before being applied to that peer’s copy of the ledger. 具体而言，要更新账本的应用程序都涉及到一个三阶段的过程，这确保了区块链网络中各peer节点的账本 保持一致。在第一阶段，应用程序与一部分背书节点一起工作，且每一个背书节点都为程序提供所提议的账本 更新的背书。但并不将提议的更新应用到账本的副本上。在第二阶段，这些分散的背书将被作为交易 收集起来并打包成区块。在最后一个阶段，这些区块被分发回每个peer节点，每个交易被在被加入 这些节点的账本副本之前都将被验证。

As you will see, orderer nodes are central to this process – so let’s investigate in a little more detail how applications and peers use orderers to generate ledger updates that can be consistently applied to a distributed, replicated ledger. 正如你将见到的，排序节点是这个过程的核心——所以，让我们更详细地研究应用程序和peer节点是 如何使用排序节点来生成账本更新，且这些更新可以一致应用到分布式的复制账本上的。

Chain - 链¶

The chain is a transaction log, structured as hash-linked blocks, where each block contains a sequence of N transactions. The block header includes a hash of the block’s transactions, as well as a hash of the prior block’s header. In this way, all transactions on the ledger are sequenced and cryptographically linked together. In other words, it is not possible to tamper with the ledger data, without breaking the hash links. The hash of the latest block represents every transaction that has come before, making it possible to ensure that all peers are in a consistent and trusted state.

链是一个交易日志，它由哈希值链接的区块构造而成，每个区块包含 N 个有序的交易。区块头中包含了本区块内所有交易的总哈希值，以及上一个区块头的哈希值。通过这种方式，账本中的所有交易都以有序的、加密的形式串联在了一起。换而言之，在不破坏哈希链的情况下，是无法篡改账本数据的。最新区块的哈希是之前每一笔交易的体现，从而可以保证所有的节点处于一致的可信任的状态。

The chain is stored on the peer file system (either local or attached storage), efficiently supporting the append-only nature of the blockchain workload.

链被存放于对等节点的文件系统中（本地的或者挂载的），有效地支持着区块链工作量只追加的特性。

State Database - 状态数据库¶

The ledger’s current state data represents the latest values for all keys ever included in the chain transaction log. Since current state represents all latest key values known to the channel, it is sometimes referred to as World State.

账本的当前状态信息呈现的是链交易日志中记录过的所有键的最新值。由于当前状态表示的是通道已知的所有键的最新值，因此也常被称作世界状态。

Chaincode invocations execute transactions against the current state data. To make these chaincode interactions extremely efficient, the latest values of all keys are stored in a state database. The state database is simply an indexed view into the chain’s transaction log, it can therefore be regenerated from the chain at any time. The state database will automatically get recovered (or generated if needed) upon peer startup, before transactions are accepted.

链码调用基于当前的状态数据执行交易。为了使链码调用高效运行，所有键的最新值被存储在状态数据库中。状态数据库是链的交易日志的索引视图，因此它可以随时从链中重新导出。节点启动的时候，在接受交易之前，状态数据库将被自动恢复（或者根据需要产生）。

State database options include LevelDB and CouchDB. LevelDB is the default state database embedded in the peer process and stores chaincode data as key/value pairs. CouchDB is an optional alternative external state database that provides addition query support when your chaincode data is modeled as JSON, permitting rich queries of the JSON content. See CouchDB as the State Database for more information on CouchDB.

状态数据库的可选项包括 LevelDB 和 CouchDB。LevelDB 是对等节点中内嵌的默认状态数据库，将链码数据以键值对的形式保存。 CouchDB 是一个可选的外部状态数据库，当链码数据以 JSON 格式建模时，CouchDB 可以提供额外的查询支持，允许使用富查询的方式检索 JSON 内容。阅读 CouchDB as the State Database 获取更多的关于 CouchDB 的信息。

Transaction Flow - 交易流程¶

At a high level, the transaction flow consists of a transaction proposal sent by an application client to specific endorsing peers. The endorsing peers verify the client signature, and execute a chaincode function to simulate the transaction. The output is the chaincode results, a set of key/value versions that were read in the chaincode (read set), and the set of keys/values that were written in chaincode (write set). The proposal response gets sent back to the client along with an endorsement signature.

从总体看，交易流程包括了应用客户端发送交易提案给背书节点。背书节点验证客户端的签名，然后执行链码来模拟交易。产生的输出就是链码结果，一组链码读取的键值版本（读集合），和一组被写入链码的键值集合（写集合）。交易提案的响应被发送回客户端，同时包含了背书签名。

The client assembles the endorsements into a transaction payload and broadcasts it to an ordering service. The ordering service delivers ordered transactions as blocks to all peers on a channel.

客户端汇总所有的背书到一个交易有效载荷中，并将它广播到排序服务。排序服务将排好序的交易放入区块并发送到通道内的所有对等节点。

Before committal, peers will validate the transactions. First, they will check the endorsement policy to ensure that the correct allotment of the specified peers have signed the results, and they will authenticate the signatures against the transaction payload.

在提交之前，节点们会验证交易。首先它们会检查背书策略来保证足够的指定节点正确地对结果进行了签名，并且会认证交易有效载荷中的签名。

Secondly, peers will perform a versioning check against the transaction read set, to ensure data integrity and protect against threats such as double-spending. Hyperledger Fabric has concurrency control whereby transactions execute in parallel (by endorsers) to increase throughput, and upon commit (by all peers) each transaction is verified to ensure that no other transaction has modified data it has read. In other words, it ensures that the data that was read during chaincode execution has not changed since execution (endorsement) time, and therefore the execution results are still valid and can be committed to the ledger state database. If the data that was read has been changed by another transaction, then the transaction in the block is marked as invalid and is not applied to the ledger state database. The client application is alerted, and can handle the error or retry as appropriate.

其次，节点们会对交易的读集合进行版本检查，从而保证数据的一致性并防范一些攻击，比如双花。Hyperledger Fabric 拥有并发控制，从而交易可以（被背书节点）并行运行来提高吞吐量，而且当交易（被所有对等节点）提交时，每个交易都会被验证来保证它所读取的数据没有被其他交易更改。换言之，它确保链码执行期间所读取的数据从执行（背书）开始后没有变动。如果读取的数据被其他交易改动了，那么区块中的交易将被标记成无效的，也不会被应用到账本状态数据库。客户端应用会收到提醒，从而进行纠错或适当重试。

See the Transaction Flow, Read-Write set semantics - 读写集语义, and CouchDB as the State Database topics for a deeper dive on transaction structure, concurrency control, and the state DB.

要进一步了解交易的结构、并发控制和状态数据库的相关内容，可以参考 Transaction Flow、 Read-Write set semantics - 读写集语义 和 CouchDB as the State Database。

Install prerequisites - 安装依赖¶

Before we begin, if you haven’t already done so, you may wish to check that you have all the 预备知识 installed on the platform(s) on which you’ll be developing blockchain applications and/or operating Hyperledger Fabric.

在开始前，请确认你已经按照 预备知识 的介绍，在你准备开发和运行 Hyperledger Fabric 的电脑上安装了所有的依赖软件。

You will also need to download and install the Hyperledger Fabric 示例. You will notice that there are a number of samples included in the fabric-samples repository. We will be using the first-network sample. Let’s open that sub-directory now.

你还需要下载和安装 Hyperledger Fabric 示例。你会注意到在 fabric-samples 项目中包含了一系列的示例。我们会使用 first-network 示例，下面请进入该示例的子目录：

cd fabric-samples/first-network

Want to run it now? - 是否已经迫不及待想要开始了？¶

We provide a fully annotated script - byfn.sh - that leverages these Docker images to quickly bootstrap a Hyperledger Fabric network comprised of 4 peers representing two different organizations, and an orderer node. It will also launch a container to run a scripted execution that will join peers to a channel, deploy and instantiate chaincode and drive execution of transactions against the deployed chaincode.

我们提供了一个包含完整注释的脚本 byfn.sh ，利用 Docker 镜像快速构建起一个 Hyperledger Fabric 网络，该网络包含 2 个机构下的共 4 个对等节点 (peer)，以及 1 个排序服务节点 (orderer)。同时，我们还会启动一个容器来运行脚本，实现如下功能：将对等节点添加到通道 (channel)、部署和初始化链码 (chaincode) 以及执行已部署链码的交易。

Here’s the help text for the byfn.sh script:

如下是 byfn.sh 脚本的帮助说明

./byfn.sh --help
Usage:
byfn.sh up|down|restart|generate [-c <channel name>] [-t <timeout>] [-d <delay>] [-f <docker-compose-file>] [-s <dbtype>]
byfn.sh -h|--help (print this message 打印本消息)
  -m <mode> - one of 'up', 'down', 'restart' or 'generate'
    - 'up' - bring up the network with docker-compose up 使用 docker-compose up 命令启动本网络
    - 'down' - clear the network with docker-compose down 使用 docker-compose down 命令关闭本网络
    - 'restart' - restart the network 重启本网络
    - 'generate' - generate required certificates and genesis block 生成需要的证书文件和初始区块
  -c <channel name> - channel name to use (defaults to "mychannel") channel 名称 (默认是 "mychannel")
  -t <timeout> - CLI timeout duration in seconds (defaults to 10) 客户端超时时间 (默认是 10 秒)
  -d <delay> - delay duration in seconds (defaults to 3) 延时时间 (默认是 3 秒)
  -f <docker-compose-file> - specify which docker-compose file use (defaults to docker-compose-cli.yaml) 指定使用的 docker-compose 文件 (默认是 docker-compose-cli.yaml)
  -s <dbtype> - the database backend to use: goleveldb (default) or couchdb 所使用的数据库: goleveldb (默认) 或者 couchdb
  -l <language> - the chaincode language: golang (default) or node chaincode 编程语言: golang (默认) 或者 node
  -a - don't ask for confirmation before proceeding 在运行前无需确认

  Typically, one would first generate the required certificates and
  genesis block, then bring up the network. e.g.:

  一般情况下，可以先生成需要的证书文件和初始区块，随后启动整个网络。例如:

      byfn.sh -m generate -c mychannel
      byfn.sh -m up -c mychannel -s couchdb

If you choose not to supply a channel name, then the script will use a default name of mychannel. The CLI timeout parameter (specified with the -t flag) is an optional value; if you choose not to set it, then the CLI will give up on query requests made after the default setting of 10 seconds.

如果你没有指定通道名称，该脚本会使用默认的通道名称 mychannel。客户端超时时间 (由 -t 选项指定)是一个可选项，如果你没有设置它，客户端会在默认的 10 秒超时时间后，放弃查询请求。

./byfn.sh -m generate

Generating certs and genesis block for with channel 'mychannel' and CLI timeout of '10'
Continue? [Y/n] y
proceeding ...
/Users/xxx/dev/fabric-samples/bin/cryptogen

##########################################################
##### Generate certificates using cryptogen tool #########
##########################################################
org1.example.com
2017-06-12 21:01:37.334 EDT [bccsp] GetDefault -> WARN 001 Before using BCCSP, please call InitFactories(). Falling back to bootBCCSP.
...

/Users/xxx/dev/fabric-samples/bin/configtxgen
##########################################################
#########  Generating Orderer Genesis block ##############
##########################################################
2017-06-12 21:01:37.558 EDT [common/configtx/tool] main -> INFO 001 Loading configuration
2017-06-12 21:01:37.562 EDT [msp] getMspConfig -> INFO 002 intermediate certs folder not found at [/Users/xxx/dev/byfn/crypto-config/ordererOrganizations/example.com/msp/intermediatecerts]. Skipping.: [stat /Users/xxx/dev/byfn/crypto-config/ordererOrganizations/example.com/msp/intermediatecerts: no such file or directory]
...
2017-06-12 21:01:37.588 EDT [common/configtx/tool] doOutputBlock -> INFO 00b Generating genesis block
2017-06-12 21:01:37.590 EDT [common/configtx/tool] doOutputBlock -> INFO 00c Writing genesis block

#################################################################
### Generating channel configuration transaction 'channel.tx' ###
#################################################################
2017-06-12 21:01:37.634 EDT [common/configtx/tool] main -> INFO 001 Loading configuration
2017-06-12 21:01:37.644 EDT [common/configtx/tool] doOutputChannelCreateTx -> INFO 002 Generating new channel configtx
2017-06-12 21:01:37.645 EDT [common/configtx/tool] doOutputChannelCreateTx -> INFO 003 Writing new channel tx

#################################################################
#######    Generating anchor peer update for Org1MSP   ##########
#################################################################
2017-06-12 21:01:37.674 EDT [common/configtx/tool] main -> INFO 001 Loading configuration
2017-06-12 21:01:37.678 EDT [common/configtx/tool] doOutputAnchorPeersUpdate -> INFO 002 Generating anchor peer update
2017-06-12 21:01:37.679 EDT [common/configtx/tool] doOutputAnchorPeersUpdate -> INFO 003 Writing anchor peer update

#################################################################
#######    Generating anchor peer update for Org2MSP   ##########
#################################################################
2017-06-12 21:01:37.700 EDT [common/configtx/tool] main -> INFO 001 Loading configuration
2017-06-12 21:01:37.704 EDT [common/configtx/tool] doOutputAnchorPeersUpdate -> INFO 002 Generating anchor peer update
2017-06-12 21:01:37.704 EDT [common/configtx/tool] doOutputAnchorPeersUpdate -> INFO 003 Writing anchor peer update

./byfn.sh -m up

# we use the -l flag to specify the chaincode language
# forgoing the -l flag will default to Golang

./byfn.sh -m up -l node

Starting with channel 'mychannel' and CLI timeout of '10'
Continue? [Y/n]
proceeding ...
Creating network "net_byfn" with the default driver
Creating peer0.org1.example.com
Creating peer1.org1.example.com
Creating peer0.org2.example.com
Creating orderer.example.com
Creating peer1.org2.example.com
Creating cli


 ____    _____      _      ____    _____
/ ___|  |_   _|    / \    |  _ \  |_   _|
\___ \    | |     / _ \   | |_) |   | |
 ___) |   | |    / ___ \  |  _ <    | |
|____/    |_|   /_/   \_\ |_| \_\   |_|

Channel name : mychannel
Creating channel...

Query Result: 90
2017-05-16 17:08:15.158 UTC [main] main -> INFO 008 Exiting.....
===================== Query on peer1.org2 on channel 'mychannel' is successful =====================

===================== All GOOD, BYFN execution completed =====================


 _____   _   _   ____
| ____| | \ | | |  _ \
|  _|   |  \| | | | | |
| |___  | |\  | | |_| |
|_____| |_| \_| |____/

./byfn.sh -m down

Stopping with channel 'mychannel' and CLI timeout of '10'
Continue? [Y/n] y
proceeding ...
WARNING: The CHANNEL_NAME variable is not set. Defaulting to a blank string.
WARNING: The TIMEOUT variable is not set. Defaulting to a blank string.
Removing network net_byfn
468aaa6201ed
...
Untagged: dev-peer1.org2.example.com-mycc-1.0:latest
Deleted: sha256:ed3230614e64e1c83e510c0c282e982d2b06d148b1c498bbdcc429e2b2531e91
...

cli:
  container_name: cli
  image: hyperledger/fabric-tools:$IMAGE_TAG
  tty: true
  stdin_open: true
  environment:
    - GOPATH=/opt/gopath
    - CORE_VM_ENDPOINT=unix:///host/var/run/docker.sock
    - CORE_LOGGING_LEVEL=DEBUG
    #- CORE_LOGGING_LEVEL=INFO

Crypto Generator - 加密文件的生成¶

We will use the cryptogen tool to generate the cryptographic material (x509 certs and signing keys) for our various network entities. These certificates are representative of identities, and they allow for sign/verify authentication to take place as our entities communicate and transact.

我们使用 cryptogen 工具来为各种网络实体生成加密文件 (x509 证书和密钥)。这些证书代表了身份的标示，网络实体在进行通信和交易的时候，会利用这些证书来进行签名和校验身份。

OrdererOrgs:
#---------------------------------------------------------
# Orderer
# --------------------------------------------------------
- Name: Orderer
  Domain: example.com
  CA:
      Country: US
      Province: California
      Locality: San Francisco
  #   OrganizationalUnit: Hyperledger Fabric
  #   StreetAddress: address for org # default nil
  #   PostalCode: postalCode for org # default nil
  # ------------------------------------------------------
  # "Specs" - See PeerOrgs below for complete description
# -----------------------------------------------------
  Specs:
    - Hostname: orderer
# -------------------------------------------------------
# "PeerOrgs" - Definition of organizations managing peer nodes
 # ------------------------------------------------------
PeerOrgs:
# -----------------------------------------------------
# Org1
# ----------------------------------------------------
- Name: Org1
  Domain: org1.example.com
  EnableNodeOUs: true

Configuration Transaction Generator - 配置交易的生成¶

The configtxgen tool is used to create four configuration artifacts:

configtxgen 工具用于创建以下四个配置工件：

• orderer genesis block,
• channel configuration transaction,
• and two anchor peer transactions - one for each Peer Org.
• 排序服务节点的 初始区块(genesis block)
• 通道的 配置交易(configuration transaction)
• 以及两笔 锚节点交易(anchor peer transactions) - 每笔对应一个机构

Please see configtxgen for a complete description of this tool’s functionality.

请参阅 configtxgen 获取本工具功能的完整描述。

The orderer block is the Genesis Block - 初始区块 for the ordering service, and the channel configuration transaction file is broadcast to the orderer at Channel - 通道 creation time. The anchor peer transactions, as the name might suggest, specify each Org’s Anchor Peer - 锚节点 on this channel.

排序服务节点区块是排序服务的 Genesis Block - 初始区块 ，通道配置交易在创建 Channel - 通道 时广播给排序服务节点。 锚节点交易（正如名字所描述的一样）指定了通道中每个机构的 Anchor Peer - 锚节点 。

Run the tools - 运行工具¶

You can manually generate the certificates/keys and the various configuration artifacts using the configtxgen and cryptogen commands. Alternately, you could try to adapt the byfn.sh script to accomplish your objectives.

你可以使用 configtxgen 和 cryptogen 命令手动生成证书、密钥以及各种配置工件。此外，你还可以尝试修改 byfn.sh 脚本来达到同样的目的。

../bin/cryptogen generate --config=./crypto-config.yaml

org1.example.com
org2.example.com

export FABRIC_CFG_PATH=$PWD

../bin/configtxgen -profile TwoOrgsOrdererGenesis -outputBlock ./channel-artifacts/genesis.block

2017-10-26 19:21:56.301 EDT [common/tools/configtxgen] main -> INFO 001 Loading configuration
2017-10-26 19:21:56.309 EDT [common/tools/configtxgen] doOutputBlock -> INFO 002 Generating genesis block
2017-10-26 19:21:56.309 EDT [common/tools/configtxgen] doOutputBlock -> INFO 003 Writing genesis block

# The channel.tx artifact contains the definitions for our sample channel

# channel.tx 文件中包含了我们示例通道的配置信息

export CHANNEL_NAME=mychannel  && ../bin/configtxgen -profile TwoOrgsChannel -outputCreateChannelTx ./channel-artifacts/channel.tx -channelID $CHANNEL_NAME

2017-10-26 19:24:05.324 EDT [common/tools/configtxgen] main -> INFO 001 Loading configuration
2017-10-26 19:24:05.329 EDT [common/tools/configtxgen] doOutputChannelCreateTx -> INFO 002 Generating new channel configtx
2017-10-26 19:24:05.329 EDT [common/tools/configtxgen] doOutputChannelCreateTx -> INFO 003 Writing new channel tx

../bin/configtxgen -profile TwoOrgsChannel -outputAnchorPeersUpdate ./channel-artifacts/Org1MSPanchors.tx -channelID $CHANNEL_NAME -asOrg Org1MSP

../bin/configtxgen -profile TwoOrgsChannel -outputAnchorPeersUpdate ./channel-artifacts/Org2MSPanchors.tx -channelID $CHANNEL_NAME -asOrg Org2MSP

Start the network - 启动网络¶

We will leverage a script to spin up our network. The docker-compose file references the images that we have previously downloaded, and bootstraps the orderer with our previously generated genesis.block.

我们会使用一个脚本来启动我们的网络。docker-compose 文件引用了之前我们已经下载好的镜像文件，启动了一个排序服务节点，该排序服务节点使用的是前文生成的 genesis.block 。

We want to go through the commands manually in order to expose the syntax and functionality of each call.

我们希望手动输入一遍所有命令，以便了解每个调用的语法和功能。

First let’s start your network:

首先，让我们启动网络：

docker-compose -f docker-compose-cli.yaml up -d

If you want to see the realtime logs for your network, then do not supply the -d flag. If you let the logs stream, then you will need to open a second terminal to execute the CLI calls.

如果你希望看到网络的实时输出，请不要添加 -d 参数。此时，日志将会持续打印，你需要打开另一个终端来执行 CLI 调用。

The CLI container will stick around idle for 1000 seconds. If it’s gone when you need it you can restart it with a simple command:

CLI 容器会持续闲置等待 1000 秒。如果该容器被关闭，可以使用如下命令重启：

docker start cli

# Environment variables for PEER0

# 针对 PEER0 的环境变量

CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp
CORE_PEER_ADDRESS=peer0.org1.example.com:7051
CORE_PEER_LOCALMSPID="Org1MSP"
CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt

docker exec -it cli bash

root@0d78bb69300d:/opt/gopath/src/github.com/hyperledger/fabric/peer#

export CHANNEL_NAME=mychannel

# the channel.tx file is mounted in the channel-artifacts directory within your CLI container
# as a result, we pass the full path for the file
# we also pass the path for the orderer ca-cert in order to verify the TLS handshake
# be sure to export or replace the $CHANNEL_NAME variable appropriately

# channel.tx 文件被挂载在 CLI 容器的 channel-artifacts 目录下
# 因此，我们需要传入该文件的绝对路径
# 同时，我们还传入了用于校验 TLS 握手的排序服务节点的 ca 证书
# 请确保设置了环境变量 $CHANNEL_NAME，或者将命令中的 $CHANNEL_NAME 修改为实际值

peer channel create -o orderer.example.com:7050 -c $CHANNEL_NAME -f ./channel-artifacts/channel.tx --tls --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem

# By default, this joins ``peer0.org1.example.com`` only
# the <channel-ID.block> was returned by the previous command
# if you have not modified the channel name, you will join with mychannel.block
# if you have created a different channel name, then pass in the appropriately named block

# 下述命令默认将 ``peer0.org1.example.com`` 加入 mychannel.block 对应的通道中
# 如果你修改了通道名称，请传入相应的 .block 文件名

 peer channel join -b mychannel.block

CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/users/Admin@org2.example.com/msp CORE_PEER_ADDRESS=peer0.org2.example.com:7051 CORE_PEER_LOCALMSPID="Org2MSP" CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/ca.crt peer channel join -b mychannel.block

peer channel update -o orderer.example.com:7050 -c $CHANNEL_NAME -f ./channel-artifacts/Org1MSPanchors.tx --tls --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem

CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/users/Admin@org2.example.com/msp CORE_PEER_ADDRESS=peer0.org2.example.com:7051 CORE_PEER_LOCALMSPID="Org2MSP" CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/ca.crt peer channel update -o orderer.example.com:7050 -c $CHANNEL_NAME -f ./channel-artifacts/Org2MSPanchors.tx --tls --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem

# this installs the Go chaincode

# 安装 Go 链码
peer chaincode install -n mycc -v 1.0 -p github.com/chaincode/chaincode_example02/go/

# this installs the Node.js chaincode
# make note of the -l flag; we use this to specify the language

# 安装 Node.js 链码
# 注意 -l 参数，我们使用它来指定编程语言
peer chaincode install -n mycc -v 1.0 -l node -p /opt/gopath/src/github.com/chaincode/chaincode_example02/node/

# be sure to replace the $CHANNEL_NAME environment variable if you have not exported it
# if you did not install your chaincode with a name of mycc, then modify that argument as well

# 请确保替换了 $CHANNEL_NAME 环境变量，或已经提前设置好
# 如果你安装链码时指定的名称不是 mycc，请修改如下参数为对应值

peer chaincode instantiate -o orderer.example.com:7050 --tls --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem -C $CHANNEL_NAME -n mycc -v 1.0 -c '{"Args":["init","a", "100", "b","200"]}' -P "OR ('Org1MSP.peer','Org2MSP.peer')"

# be sure to replace the $CHANNEL_NAME environment variable if you have not exported it
# if you did not install your chaincode with a name of mycc, then modify that argument as well
# notice that we must pass the -l flag after the chaincode name to identify the language

# 请确保替换了 $CHANNEL_NAME 环境变量，或已经提前设置好
# 如果你安装链码时指定的名字不是 mycc，请修改如下参数为对应值
# 注意必须在链码名称后传入 -l 参数来指定链码编程语言

peer chaincode instantiate -o orderer.example.com:7050 --tls --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem -C $CHANNEL_NAME -n mycc -l node -v 1.0 -c '{"Args":["init","a", "100", "b","200"]}' -P "OR ('Org1MSP.peer','Org2MSP.peer')"

# be sure to set the -C and -n flags appropriately

peer chaincode query -C $CHANNEL_NAME -n mycc -c '{"Args":["query","a"]}'

# be sure to set the -C and -n flags appropriately

peer chaincode invoke -o orderer.example.com:7050  --tls --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem  -C $CHANNEL_NAME -n mycc -c '{"Args":["invoke","a","b","10"]}'

# be sure to set the -C and -n flags appropriately

peer chaincode query -C $CHANNEL_NAME -n mycc -c '{"Args":["query","a"]}'

Query Result: 90

docker logs -f cli

2017-05-16 17:08:01.366 UTC [msp] GetLocalMSP -> DEBU 004 Returning existing local MSP
2017-05-16 17:08:01.366 UTC [msp] GetDefaultSigningIdentity -> DEBU 005 Obtaining default signing identity
2017-05-16 17:08:01.366 UTC [msp/identity] Sign -> DEBU 006 Sign: plaintext: 0AB1070A6708031A0C08F1E3ECC80510...6D7963631A0A0A0571756572790A0161
2017-05-16 17:08:01.367 UTC [msp/identity] Sign -> DEBU 007 Sign: digest: E61DB37F4E8B0D32C9FE10E3936BA9B8CD278FAA1F3320B08712164248285C54
Query Result: 90
2017-05-16 17:08:15.158 UTC [main] main -> INFO 008 Exiting.....
===================== Query on peer1.org2 on channel 'mychannel' is successful =====================

===================== All GOOD, BYFN execution completed =====================


 _____   _   _   ____
| ____| | \ | | |  _ \
|  _|   |  \| | | | | |
| |___  | |\  | | |_| |
|_____| |_| \_| |____/

$ docker logs dev-peer0.org2.example.com-mycc-1.0
04:30:45.947 [BCCSP_FACTORY] DEBU : Initialize BCCSP [SW]
ex02 Init
Aval = 100, Bval = 200

$ docker logs dev-peer0.org1.example.com-mycc-1.0
04:31:10.569 [BCCSP_FACTORY] DEBU : Initialize BCCSP [SW]
ex02 Invoke
Query Response:{"Name":"a","Amount":"100"}
ex02 Invoke
Aval = 90, Bval = 210

$ docker logs dev-peer1.org2.example.com-mycc-1.0
04:31:30.420 [BCCSP_FACTORY] DEBU : Initialize BCCSP [SW]
ex02 Invoke
Query Response:{"Name":"a","Amount":"90"}

Understanding the Docker Compose topology - 理解 Docker Compose 的拓扑结构¶

The BYFN sample offers us two flavors of Docker Compose files, both of which are extended from the docker-compose-base.yaml (located in the base folder). Our first flavor, docker-compose-cli.yaml, provides us with a CLI container, along with an orderer, four peers. We use this file for the entirety of the instructions on this page.

本示例（BYFN）提供了两种方案的 Docker Compose 配置文件，两个方案都是基于 docker-compose-base.yaml （位于 base 目录下）扩展而来。第一种方案的配置文件为 docker-compose-cli.yaml，提供了 1 个 CLI 容器、1 个排序服务节点以及 4 个对等节点。在本篇介绍中，我们使用的都是此方案。

The second flavor, docker-compose-e2e.yaml, is constructed to run end-to-end tests using the Node.js SDK. Aside from functioning with the SDK, its primary differentiation is that there are containers for the fabric-ca servers. As a result, we are able to send REST calls to the organizational CAs for user registration and enrollment.

第二种方案的配置文件为 docker-compose-e2e.yaml，该方案构建了一个端到端的测试场景，用于运行 Node.js SDK。除了和 SDK 的交互功能外，该方案最大的区别是包含了作为 fabric-ca 服务器的容器。因此，我们可以通过发送 REST 请求给 CA，实现用户的注册和登记。

If you want to use the docker-compose-e2e.yaml without first running the byfn.sh script, then we will need to make four slight modifications. We need to point to the private keys for our Organization’s CA’s. You can locate these values in your crypto-config folder. For example, to locate the private key for Org1 we would follow this path - crypto-config/peerOrganizations/org1.example.com/ca/. The private key is a long hash value followed by _sk. The path for Org2 would be - crypto-config/peerOrganizations/org2.example.com/ca/.

如果你希望不通过 byfn.sh 脚本而直接使用 docker-compose-e2e.yaml 的话，需要做 4 处修改。我们需要指定机构的 CA 的密钥。你可以指定 crypto-config 文件夹中的值。例如，机构 Org1 的密钥值，可以指定为 crypto-config/peerOrganizations/org1.example.com/ca/。密钥包含了一个长哈希值，并以 _sk 结尾。机构 Org2 的密钥可以是 crypto-config/peerOrganizations/org2.example.com/ca/。

In the update the FABRIC_CA_SERVER_TLS_KEYFILE variable for ca0 and ca1. You also need to edit the path that is provided in the command to start the ca server. You are providing the same private key twice for each CA container.

更新 docker-compose-e2e.yaml 中 ca0 和 ca1 的 FABRIC_CA_SERVER_TLS_KEYFILE 值。你还需要修改启动 ca 服务器的命令中的路径。对每一个 CA 容器，你需要提供两次相同的密钥。

Using CouchDB - 使用 CouchDB¶

The state database can be switched from the default (goleveldb) to CouchDB. The same chaincode functions are available with CouchDB, however, there is the added ability to perform rich and complex queries against the state database data content contingent upon the chaincode data being modeled as JSON.

状态数据库可以从默认的 goleveldb 切换到 CouchDB。CouchDB 提供了相同的链码函数，此外，对于采用 JSON 结构的链码数据，CouchDB 还提供了进行富查询和复杂查询的能力。

To use CouchDB instead of the default database (goleveldb), follow the same procedures outlined earlier for generating the artifacts, except when starting the network pass docker-compose-couch.yaml as well:

要想使用 CouchDB 替换默认的数据库 (goleveldb)，按照之前完全相同的步骤生成相关配置工件，只是在启动网络时，如下所示增加 docker-compose-couch.yaml 文件：

docker-compose -f docker-compose-cli.yaml -f docker-compose-couch.yaml up -d

chaincode_example02 should now work using CouchDB underneath.

chaincode_example02 此时就是基于 CouchDB 运行。

You can use chaincode_example02 chaincode against the CouchDB state database using the steps outlined above, however in order to exercise the CouchDB query capabilities you will need to use a chaincode that has data modeled as JSON, (e.g. marbles02). You can locate the marbles02 chaincode in the fabric/examples/chaincode/go directory.

基于上述步骤，你可以基于 CouchDB 状态数据库运行 chaincode_example02 链码，但是，如果想利用 CouchDB 的查询能力，你还需要一个采用 JSON 结构保存数据的链码 (例如 marbles02)。你可以在 fabric/examples/chaincode/go 目录下找到 marbles02 链码的源文件。

We will follow the same process to create and join the channel as outlined in the Create & Join Channel - 创建和加入通道 section above. Once you have joined your peer(s) to the channel, use the following steps to interact with the marbles02 chaincode:

我们将会采用和 Create & Join Channel - 创建和加入通道 一节相同的步骤去创建和加入通道。在将你的对等节点（们）加入到通道后，采用如下步骤去和 marbles02 链码进行交互：

• Install and instantiate the chaincode on peer0.org1.example.com:
• 在 peer0.org1.example.com 上安装和实例化链码：

# be sure to modify the $CHANNEL_NAME variable accordingly for the instantiate command

# 请确保将 $CHANNEL_NAME 修改为实例化命令中对应的值

peer chaincode install -n marbles -v 1.0 -p github.com/chaincode/marbles02/go
peer chaincode instantiate -o orderer.example.com:7050 --tls --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem -C $CHANNEL_NAME -n marbles -v 1.0 -c '{"Args":["init"]}' -P "OR ('Org0MSP.peer','Org1MSP.peer')"

• Create some marbles and move them around:
• 创建一些弹珠 (marble) 并移动它们：

# be sure to modify the $CHANNEL_NAME variable accordingly

# 请确保将 $CHANNEL_NAME 修改为合适的值

peer chaincode invoke -o orderer.example.com:7050 --tls --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem -C $CHANNEL_NAME -n marbles -c '{"Args":["initMarble","marble1","blue","35","tom"]}'
peer chaincode invoke -o orderer.example.com:7050 --tls --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem -C $CHANNEL_NAME -n marbles -c '{"Args":["initMarble","marble2","red","50","tom"]}'
peer chaincode invoke -o orderer.example.com:7050 --tls --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem -C $CHANNEL_NAME -n marbles -c '{"Args":["initMarble","marble3","blue","70","tom"]}'
peer chaincode invoke -o orderer.example.com:7050 --tls --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem -C $CHANNEL_NAME -n marbles -c '{"Args":["transferMarble","marble2","jerry"]}'
peer chaincode invoke -o orderer.example.com:7050 --tls --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem -C $CHANNEL_NAME -n marbles -c '{"Args":["transferMarblesBasedOnColor","blue","jerry"]}'
peer chaincode invoke -o orderer.example.com:7050 --tls --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem -C $CHANNEL_NAME -n marbles -c '{"Args":["delete","marble1"]}'

• If you chose to map the CouchDB ports in docker-compose, you can now view the state database through the CouchDB web interface (Fauxton) by opening a browser and navigating to the following URL:

• 如果你在 docker-compose 中对 CouchDB 进行了端口映射，你可以使用 CouchDB 网页接口 (Fauxton) 去查看状态数据库的内容，需要打开浏览器并输入如下网址：

  http://localhost:5984/_utils

You should see a database named mychannel (or your unique channel name) and the documents inside it.

你会看到一个名为 mychannel （或你所指定的通道名称）的数据库及其内部的文档。

You can run regular queries from the CLI (e.g. reading marble2):

你可以从 CLI 发起常规查询（例如读取 marble2）：

peer chaincode query -C $CHANNEL_NAME -n marbles -c '{"Args":["readMarble","marble2"]}'

The output should display the details of marble2:

输出为 marble2 的详细信息：

Query Result: {"color":"red","docType":"marble","name":"marble2","owner":"jerry","size":50}

You can retrieve the history of a specific marble - e.g. marble1:

你可以获取指定弹珠的历史信息 - 例如 marble1：

peer chaincode query -C $CHANNEL_NAME -n marbles -c '{"Args":["getHistoryForMarble","marble1"]}'

The output should display the transactions on marble1:

输出为 marble1 相关的所有交易：

Query Result: [{"TxId":"1c3d3caf124c89f91a4c0f353723ac736c58155325f02890adebaa15e16e6464", "Value":{"docType":"marble","name":"marble1","color":"blue","size":35,"owner":"tom"}},{"TxId":"755d55c281889eaeebf405586f9e25d71d36eb3d35420af833a20a2f53a3eefd", "Value":{"docType":"marble","name":"marble1","color":"blue","size":35,"owner":"jerry"}},{"TxId":"819451032d813dde6247f85e56a89262555e04f14788ee33e28b232eef36d98f", "Value":}]

You can also perform rich queries on the data content, such as querying marble fields by owner jerry:

你还可以基于数据内容发起一个富查询，例如查询所有者 (owner) 为 jerry 的弹珠：

peer chaincode query -C $CHANNEL_NAME -n marbles -c '{"Args":["queryMarblesByOwner","jerry"]}'

The output should display the two marbles owned by jerry:

输出为 jerry 拥有的两个弹珠信息：

Query Result: [{"Key":"marble2", "Record":{"color":"red","docType":"marble","name":"marble2","owner":"jerry","size":50}},{"Key":"marble3", "Record":{"color":"blue","docType":"marble","name":"marble3","owner":"jerry","size":70}}]

Why CouchDB - 为何使用 CouchDB¶

CouchDB is a kind of NoSQL solution. It is a document oriented database where document fields are stored as key-value mpas. Fields can be either a simple key/value pair, list, or map. In addition to keyed/composite-key/key-range queries which are supported by LevelDB, CouchDB also supports full data rich queries capability, such as non-key queries against the whole blockchain data, since its data content is stored in JSON format and fully queryable. Therefore, CouchDB can meet chaincode, auditing, reporting requirements for many use cases that not supported by LevelDB.

CouchDB 是 NoSQL 的一种解决方案。它是一种面向文档的数据库，其中文档字段以键-值 (key-value) 的形式保存。字段可以是简单的键值对 (key/value pair)、列表 (list) 或者图 (map)。CouchDB 不仅支持 LevelDB 所支持的 keyed/composite-key/key-range 等查询方式，还提供了全数据富查询的能力，例如对于整个区块链数据的无键查询 (non-key queries)，这是因为 CouchDB 的数据内容使用了 JSON 格式进行存储，提供了全方位的查询能力。因此，在一些 LevelDB 无法支持的应用场景下，CouchDB 还可以满足链码、审计和报告等需求。

CouchDB can also enhance the security for compliance and data protection in the blockchain. As it is able to implement field-level security through the filtering and masking of individual attributes within a transaction, and only authorizing the read-only permission if needed.

CouchDB 还可以增强区块链中合规和数据保护的安全性。通过过滤和提取交易中的独立属性，它具备了字段级别的安全性，在需要时授予只读权限即可。

In addition, CouchDB falls into the AP-type (Availability and Partition Tolerance) of the CAP theorem. It uses a master-master replication model with Eventual Consistency. More information can be found on the Eventual Consistency page of the CouchDB documentation. However, under each fabric peer, there is no database replicas, writes to database are guaranteed consistent and durable (not Eventual Consistency).

此外，CouchDB 是 CAP 理论中的 AP 类型 (可用性和分区容错性，Availability and Partition Tolerance)。它利用主 - 主复制模型 (master-master replication model) 实现了 最终一致性 (Eventual Consistency)。更详细的信息请参考 Eventual Consistency page of the CouchDB documentation 。然而，在每个 fabric 的对等节点内，并不包含数据库拷贝，对数据库的写入是担保形式的一致性和持久性 (非 最终一致性 )。

CouchDB is the first external pluggable state database for Fabric, and there could and should be other external database options. For example, IBM enables the relational database for its blockchain. And the CP-type (Consistency and Partition Tolerance) databases may also in need, so as to enable data consistency without application level guarantee.

CouchDB 是 Fabric 的第一个可插拔的外部状态数据库，可以有也应该有其他的外部数据库选项。例如，IBM 在它的区块链中采用了关系型数据库。此外，CP 类型 (一致性和分区容错性，Consistency and Partition Tolerance) 的数据库也是需要的，这样可以在不需要应用层担保的情况下实现数据的一致性。

A Note on Data Persistence - 数据持久化的注意事项¶

If data persistence is desired on the peer container or the CouchDB container, one option is to mount a directory in the docker-host into a relevant directory in the container. For example, you may add the following two lines in the peer container specification in the docker-compose-base.yaml file:

如果对等节点的容器或者 CouchDB 容器需要进行数据持久化，一种方法是将主机的目录挂载到容器内的相关目录。例如你可以将如下两行添加到 docker-compose-base.yaml 文件中对等节点容器的配置中：

volumes:
 - /var/hyperledger/peer0:/var/hyperledger/production

For the CouchDB container, you may add the following two lines in the CouchDB container specification:

对于 CouchDB 容器，你可以添加如下两行到 CouchDB 容器的配置中：

volumes:
 - /var/hyperledger/couchdb0:/opt/couchdb/data

Troubleshooting - 疑难解答¶

• Always start your network fresh. Use the following command to remove artifacts, crypto, containers and chaincode images:

• 总是在全新的环境下启动你的网络。 使用如下命令来删除工件、加密文件、容器以及链码镜像：

  ./byfn.sh -m down
  

  注解

  You will see errors if you do not remove old containers and images.

  如果你没有删除旧的容器和镜像，你 将会 看到错误

• If you see Docker errors, first check your docker version (预备知识), and then try restarting your Docker process. Problems with Docker are oftentimes not immediately recognizable. For example, you may see errors resulting from an inability to access crypto material mounted within a container.

• 如果你看到 Docker 错误，首先检查你的 docker 版本 (预备知识)，随后尝试重启你的 Docker 进程。Docker 相关的问题有时并不能很直观的被发现。例如，如果容器内没有权限读取挂载的加密文件，你会看到错误。

  If they persist remove your images and start from scratch:

  如果这些错误始终存在，删除你的镜像，随后从头开始：

  docker rm -f $(docker ps -aq)
  docker rmi -f $(docker images -q)
  

• If you see errors on your create, instantiate, invoke or query commands, make sure you have properly updated the channel name and chaincode name. There are placeholder values in the supplied sample commands.

• 如果在执行创建、实例化、调用或查询链码命令时遇到错误，请确保你已经正确更新了通道名称和链码名称。在提供的示例命令中包含一些占位的变量。

• If you see the below error:

• 如果你看到如下错误

  Error: Error endorsing chaincode: rpc error: code = 2 desc = Error installing chaincode code mycc:1.0(chaincode /var/hyperledger/production/chaincodes/mycc.1.0 exits)
  

  You likely have chaincode images (e.g. dev-peer1.org2.example.com-mycc-1.0 or dev-peer0.org1.example.com-mycc-1.0) from prior runs. Remove them and try again.

  很有可能是还有之前运行网络时生成的链码镜像（例如 dev-peer1.org2.example.com-mycc-1.0 或 dev-peer0.org1.example.com-mycc-1.0 ）。把它们删除后重试。

  docker rmi -f $(docker images | grep peer[0-9]-peer[0-9] | awk '{print $3}')
  

• If you see something similar to the following:

• 如果你看到类似如下的内容：

  Error connecting: rpc error: code = 14 desc = grpc: RPC failed fast due to transport failure
  Error: rpc error: code = 14 desc = grpc: RPC failed fast due to transport failure
  

  Make sure you are running your network against the “1.0.0” images that have been retagged as “latest”.

  请确保你是基于 “1.1.0” 版本的镜像运行你的网络，并且这些镜像都被标记为 “latest”。

• If you see the below error:

• 如果你看到如下错误：

  [configtx/tool/localconfig] Load -> CRIT 002 Error reading configuration: Unsupported Config Type ""
  panic: Error reading configuration: Unsupported Config Type ""
  

  Then you did not set the FABRIC_CFG_PATH environment variable properly. The configtxgen tool needs this variable in order to locate the configtx.yaml. Go back and execute an export FABRIC_CFG_PATH=$PWD, then recreate your channel artifacts.

  这是由于你没有设置环境变量 FABRIC_CFG_PATH 导致的。configtxgen 工具需要依赖这个变量来访问 configtx.yaml。执行 export FABRIC_CFG_PATH=$PWD ，然后重新创建你的通道配置工件。

• To cleanup the network, use the down option:

• 使用 down 选项清理网络：

  ./byfn.sh -m down
  

• If you see an error stating that you still have “active endpoints”, then prune your Docker networks. This will wipe your previous networks and start you with a fresh environment:

• 如果你看到错误提示是还有 “active endpoints”，请删除你的 Docker 网络。如下命令会清空之前的网络，使你可以从一个全新环境开始：

  docker network prune
  

  You will see the following message:

  你会看到如下信息：

  WARNING! This will remove all networks not used by at least one container.
  Are you sure you want to continue? [y/N]
  

  Select y.

  选择 y。

Setting up your Dev Environment - 构建一个开发环境¶

First thing, let’s download the Fabric images and the accompanying artifacts for the network and applications...

首先，需要下载 Fabric 镜像以及网络和应用的相关文件...

Visit the 预备知识 page and ensure you have the necessary dependencies installed on your machine.

访问 预备知识 页面，确保你已经安装了所有必要的依赖。

Next, visit the Hyperledger Fabric 示例 page and follow the provided instructions. Return to this tutorial once you have cloned the fabric-samples repository, and downloaded the latest stable Fabric images and available utilities.

下一步，访问 Hyperledger Fabric 示例 页面并按照所提供的说明进行操作。 一旦完成克隆 fabric-samples 仓库后，返回本教程，随后下载最新的稳定版 Fabric 镜像以及可用的工具。

At this point everything should be installed. Navigate to the fabcar subdirectory within your fabric-samples repository and take a look at what’s inside:

至此，所有需要的依赖应该已经都安装好。 进入 fabric-samples 仓库的 fabcar 子目录，查看里面有哪些文件：

cd fabric-samples/fabcar  && ls

You should see the following:

你会看到如下输出：

enrollAdmin.js     invoke.js       package.json    query.js        registerUser.js startFabric.sh

Before starting we also need to do a little housekeeping. Run the following command to kill any stale or active containers:

在开始之前，我们需要进行一些清理工作。 运行下述命令，关闭所有的容器：

docker rm -f $(docker ps -aq)

Clear any cached networks:

清空已缓存的网络：

# Press 'y' when prompted by the command

docker network prune

And lastly if you’ve already run through this tutorial, you’ll also want to delete the underlying chaincode image for the fabcar smart contract. If you’re a user going through this content for the first time, then you won’t have this chaincode image on your system:

最后，如果你之前已经运行过本教程的内容，需要删除 fabcar 智能合约对应的链码镜像。 如果你是第一次阅读和运行本教程的内容，你的机器上不会有这些链码镜像。

docker rmi dev-peer0.org1.example.com-fabcar-1.0-5c906e402ed29f20260ae42283216aa75549c571e2e380f3615826365d8269ba

npm install

./startFabric.sh

./startFabric.sh node

How Applications Interact with the Network - 应用是如何和网络进行交互的¶

For a more in-depth look at the components in our fabcar network (and how they’re deployed) as well as how applications interact with those components on more of a granular level, see Understanding the Fabcar Network.

如果想深入了解 fabcar 网络的每一个组件（包括他们是如何部署的），以及应用是如何与这些组件之间进行交互的，请参考 Understanding the Fabcar Network 文档。

Developers more interested in seeing what applications do – as well as looking at the code itself to see how an application is constructed – should continue. For now, the most important thing to know is that applications use a software development kit (SDK) to access the APIs that permit queries and updates to the ledger.

希望了解应用是如何构建以及运行的开发者，请继续阅读本文档。 到目前为止最需要明确的事情是，应用使用了一个软件开发套件（SDK）来访问 APIs，实现对账本的查询和更新。

Enrolling the Admin User - 登记管理员用户¶

To stream your CA logs, split your terminal or open a new shell and issue the following:

为了查看你的 CA 日志，将终端分屏或者打开一个新的终端并输入如下命令：

docker logs -f ca.example.com

Now hop back to your terminal with the fabcar content...

现在，回到你的包含 fabcar 内容的终端...

When we launched our network, an admin user - admin - was registered with our Certificate Authority. Now we need to send an enroll call to the CA server and retrieve the enrollment certificate (eCert) for this user. We won’t delve into enrollment details here, but suffice it to say that the SDK and by extension our applications need this cert in order to form a user object for the admin. We will then use this admin object to subsequently register and enroll a new user. Send the admin enroll call to the CA server:

当我们启动我们的网络是，一个管理员用户 - admin - 被注册到我们的认证授权管理中。 现在我们需要发送一个登记请求到 CA 服务器，并且获取该用户登记证书（eCert）。 这里我们并不会深入讨论登记的细节，但是注意 SDK 以及基于我们应用的扩展都需要这个证书来构建一个管理员用户。 随后，我们会使用这个管理员来注册和登记新的用户。 发送管理员登记请求到 CA 服务器：

node enrollAdmin.js

This program will invoke a certificate signing request (CSR) and ultimately output an eCert and key material into a newly created folder - hfc-key-store - at the root of this project. Our apps will then look to this location when they need to create or load the identity objects for our various users.

这个程序会执行一个证书签名请求（CSR），最后输出 eCert 和密钥文件到一个新创建的目录下 - hfc-key-store - 该目录位于项目的根目录下。 随后，我们的应用在需要创建或者加载用户的身份标识对象时，会查看这个目录。

Register and Enroll user1 - 注册和登记 user1¶

With our newly generated admin eCert, we will now communicate with the CA server once more to register and enroll a new user. This user - user1 - will be the identity we use when querying and updating the ledger. It’s important to note here that it is the admin identity that is issuing the registration and enrollment calls for our new user (i.e. this user is acting in the role of a registrar). Send the register and enroll calls for user1:

使用我们新生成的管理员 eCert，我们可以再次和 CA 服务器进交互，注册和登记一个新用户。 这个用户 - user1 - 会被我们用于查询和更新账本。 值得注意的是，只有 admin 身份可以执行对新用户的注册和登记请求（该用户扮演了一个登记员的角色）。 发送 user1 的注册和登记请求：

node registerUser.js

Similar to the admin enrollment, this program invokes a CSR and outputs the keys and eCert into the hfc-key-store subdirectory. So now we have identity material for two separate users - admin & user1. Time to interact with the ledger...

和登记管理员时类似，该程序执行了一个 CSR，输出密钥和 eCert 文件到 hfc-key-store 子目录下。 现在我们有了两个用户的身份标识文件 - admin 和 user1。 现在到了和账本进行交互的时间了...

Querying the Ledger - 查询账本¶

Queries are how you read data from the ledger. This data is stored as a series of key/value pairs, and you can query for the value of a single key, multiple keys, or – if the ledger is written in a rich data storage format like JSON – perform complex searches against it (looking for all assets that contain certain keywords, for example).

查询操作实际上就是如果从账本读取数据。这些数据是以键/值对的形式存储的，我们可以查询一个键或者多个键对应的值，或者如果账本是以JSON等富数据存储格式写入的，我们可以进行复杂的查询（比如，可以查询所有包含有特定关键词的资产）。

This is a representation of how a query works:

下面的图展示了查询操作是如果工作的：

First, let’s run our query.js program to return a listing of all the cars on the ledger. We will use our second identity - user1 - as the signing entity for this application. The following line in our program specifies user1 as the signer:

首先，我们运行``query.js``返回账本记录的所有汽车的列表。我们会使用我们的第二个身份 - ``user1``作为这个应用的签名实体。程序中下面这行指定``user1``作为签名者：

fabric_client.getUserContext('user1', true);

Recall that the user1 enrollment material has already been placed into our hfc-key-store subdirectory, so we simply need to tell our application to grab that identity. With the user object defined, we can now proceed with reading from the ledger. A function that will query all the cars, queryAllCars, is pre-loaded in the app, so we can simply run the program as is:

回想``user1``的注册信息，我们已经放置在``hfc-key-store``子目录，所以我们仅需要告诉我们的应用从这个子目录获取身份信息。 根据定义的用户对象，我们可以继续读取账本数据。 应用中一个函数``queryAllCars``用来查询所有的汽车，所以我们仅需要启动这个应用程序：

node query.js

It should return something like this:

它应该返回如下的一下信息：

Successfully loaded user1 from persistence
Query has completed, checking results
Response is  [{"Key":"CAR0", "Record":{"colour":"blue","make":"Toyota","model":"Prius","owner":"Tomoko"}},
{"Key":"CAR1",   "Record":{"colour":"red","make":"Ford","model":"Mustang","owner":"Brad"}},
{"Key":"CAR2", "Record":{"colour":"green","make":"Hyundai","model":"Tucson","owner":"Jin Soo"}},
{"Key":"CAR3", "Record":{"colour":"yellow","make":"Volkswagen","model":"Passat","owner":"Max"}},
{"Key":"CAR4", "Record":{"colour":"black","make":"Tesla","model":"S","owner":"Adriana"}},
{"Key":"CAR5", "Record":{"colour":"purple","make":"Peugeot","model":"205","owner":"Michel"}},
{"Key":"CAR6", "Record":{"colour":"white","make":"Chery","model":"S22L","owner":"Aarav"}},
{"Key":"CAR7", "Record":{"colour":"violet","make":"Fiat","model":"Punto","owner":"Pari"}},
{"Key":"CAR8", "Record":{"colour":"indigo","make":"Tata","model":"Nano","owner":"Valeria"}},
{"Key":"CAR9", "Record":{"colour":"brown","make":"Holden","model":"Barina","owner":"Shotaro"}}]

These are the 10 cars. A black Tesla Model S owned by Adriana, a red Ford Mustang owned by Brad, a violet Fiat Punto owned by Pari, and so on. The ledger is key/value based and in our implementation the key is CAR0 through CAR9. This will become particularly important in a moment.

这里有10辆车。一辆黑色的特斯拉Model S，拥有者是Adriana。一辆福特野马属于Brad，一辆Pari的菲亚特Punto（朋多）等等。这个账本是键/值对集合，在我们的实现中键是``CAR0`` through CAR9。这些信息在有些时刻将会特别重要。

Let’s take a closer look at this program. Use an editor (e.g. atom or visual studio) and open query.js.

让我们来仔细看看这个程序。用一个编辑器（比如atom或者visual studio）来打开 query.js。

The initial section of the application defines certain variables such as channel name, cert store location and network endpoints. In our sample app, these variables have been baked-in, but in a real app these variables would have to be specified by the app dev.

在程序开头定义了一些变量如通道名称、证书存储位置和网络端点。在我们的示例，这些变量已经定义好了，但是在真实的应用中这些变量需要我们在开发过程中指定。

var channel = fabric_client.newChannel('mychannel');
var peer = fabric_client.newPeer('grpc://localhost:7051');
channel.addPeer(peer);

var member_user = null;
var store_path = path.join(__dirname, 'hfc-key-store');
console.log('Store path:'+store_path);
var tx_id = null;

This is the chunk where we construct our query:

这是我们构造查询的代码片段：

// queryCar chaincode function - requires 1 argument, ex: args: ['CAR4'],
// queryAllCars chaincode function - requires no arguments , ex: args: [''],
const request = {
  //targets : --- letting this default to the peers assigned to the channel
  chaincodeId: 'fabcar',
  fcn: 'queryAllCars',
  args: ['']
};

When the application ran, it invoked the fabcar chaincode on the peer, ran the queryAllCars function within it, and passed no arguments to it.

当程序运行的时候，它会调用节点上的``fabcar``链码上的``queryAllCars``方法，没有传递其他参数。

To take a look at the available functions within our smart contract, navigate to the chaincode/fabcar/go subdirectory at the root of fabric-samples and open fabcar.go in your editor.

来看一下智能合约中的方法，访问根目录下``fabric-samples``的子目录``chaincode/fabcar/go``，用编辑器打开``fabcar.go``文件。

You’ll see that we have the following functions available to call: initLedger, queryCar, queryAllCars, createCar, and changeCarOwner.

你会看到我们有下面一些方法可供调用：initLedger, queryCar, queryAllCars, createCar, 和 changeCarOwner。

Let’s take a closer look at the queryAllCars function to see how it interacts with the ledger.

我们仔细看一下``queryAllCars``方法是如何与账本交互的。

func (s *SmartContract) queryAllCars(APIstub shim.ChaincodeStubInterface) sc.Response {

      startKey := "CAR0"
      endKey := "CAR999"

      resultsIterator, err := APIstub.GetStateByRange(startKey, endKey)

This defines the range of queryAllCars. Every car between CAR0 and CAR999 – 1,000 cars in all, assuming every key has been tagged properly – will be returned by the query.

这里定义了``queryAllCars``方法的范围，所有在``CAR0``和``CAR999``之间的1000辆汽车。假定每一个键都有对应的值，而且会返回给查询操作。

Below is a representation of how an app would call different functions in chaincode. Each function must be coded against an available API in the chaincode shim interface, which in turn allows the smart contract container to properly interface with the peer ledger.

下图展示的是一个应用如何调用链码中不同的方法。每一个方法必须实现链码的shim接口，这样智能合约容器才能跟节点的账本进行交互。

We can see our queryAllCars function, as well as one called createCar, that will allow us to update the ledger and ultimately append a new block to the chain in a moment.

我们看到``queryAllCars``方法和``createCar``方法可以让我们来更新账本，最后可以添加一个新的区块到我们的链上。

But first, go back to the query.js program and edit the constructor request to query CAR4. We do this by changing the function in query.js from queryAllCars to queryCar and passing CAR4 as the specific key.

但是首先，回到``query.js``，编辑request构造函数来查询``CAR4``。我们通过改变``query.js``中的``queryAllCars`` 为 queryCar，并且传递参数``CAR4``作为指定的键。

The query.js program should now look like this:

``query.js``程序应该像下面这样：

const request = {
  //targets : --- letting this default to the peers assigned to the channel
  chaincodeId: 'fabcar',
  fcn: 'queryCar',
  args: ['CAR4']
};

Save the program and navigate back to your fabcar directory. Now run the program again:

保存程序，回到``fabcar``目录，再次运行程序：

node query.js

You should see the following:

现在你可以看到下面的输出：

{"colour":"black","make":"Tesla","model":"S","owner":"Adriana"}

If you go back and look at the result from when we queried every car before, you can see that CAR4 was Adriana’s black Tesla model S, which is the result that was returned here.

如果你回头看之前运行查询汽车资产的输出结果，``CAR4``是Adriana的黑色特斯拉Model S，跟这里的输出结果一致。

Using the queryCar function, we can query against any key (e.g. CAR0) and get whatever make, model, color, and owner correspond to that car.

使用``queryCar``方法我们能够根据任何一个键（比如``CAR0``）查询得到汽车的制造商，型号，颜色和拥有者。

Great. At this point you should be comfortable with the basic query functions in the smart contract and the handful of parameters in the query program. Time to update the ledger...

很好！目前为止你应该很熟悉这个查询程序中的智能合约的基本查询功能和有用的参数。现在再来更新下账本...

Updating the Ledger - 更新账本¶

Now that we’ve done a few ledger queries and added a bit of code, we’re ready to update the ledger. There are a lot of potential updates we could make, but let’s start by creating a car.

前面我们添加了一些代码并且已经做了一些账本的查询操作，我们也准备好了更新账本。这里有一些潜在的更新我们可以进行，但是我们从添加一辆汽车资产开始。

Below we can see how this process works. An update is proposed, endorsed, then returned to the application, which in turn sends it to be ordered and written to every peer’s ledger:

下图我们将看到这个过程如何进行。一个更新从提案到背书，再返回应用程序，最后发送到排序服务写入每一个节点的账本：

Our first update to the ledger will be to create a new car. We have a separate Javascript program – invoke.js – that we will use to make updates. Just as with queries, use an editor to open the program and navigate to the code block where we construct our invocation:

我们第一个更新账本操作是添加一辆新汽车资产。我们有一个独立的Javascript程序 – invoke.js – 来进行更新操作。跟查询一样，我们用编辑器打开程序，移动到我们创建的调用的代码块：

// createCar chaincode function - requires 5 args, ex: args: ['CAR12', 'Honda', 'Accord', 'Black', 'Tom'],
// changeCarOwner chaincode function - requires 2 args , ex: args: ['CAR10', 'Barry'],
// must send the proposal to endorsing peers
var request = {
  //targets: let default to the peer assigned to the client
  chaincodeId: 'fabcar',
  fcn: '',
  args: [''],
  chainId: 'mychannel',
  txId: tx_id
};

You’ll see that we can call one of two functions - createCar or changeCarOwner. First, let’s create a red Chevy Volt and give it to an owner named Nick. We’re up to CAR9 on our ledger, so we’ll use CAR10 as the identifying key here. Edit this code block to look like this:

你会看到我们调用了``createCar`` 或者 changeCarOwner``中的一个。首先，我们新建一个红色的Chevy Volt，拥有者为Nick。我们账本最大是``CAR9，所以我们用``CAR10``作为当前键。编辑这段代码后将如下：

var request = {
  //targets: let default to the peer assigned to the client
  chaincodeId: 'fabcar',
  fcn: 'createCar',
  args: ['CAR10', 'Chevy', 'Volt', 'Red', 'Nick'],
  chainId: 'mychannel',
  txId: tx_id
};

Save it and run the program:

保存后再次运行程序：

node invoke.js

There will be some output in the terminal about ProposalResponse and promises. However, all we’re concerned with is this message:

终端将会有一些关于``ProposalResponse``的输出结果和响应。但是，我们更关心的下面这条信息：

The transaction has been committed on peer localhost:7053

To see that this transaction has been written, go back to query.js and change the argument from CAR4 to CAR10.

为了看这条交易如何被写入，回到``query.js``，将参数``CAR4`` 修改为 CAR10：

In other words, change this:

也就是修改下面的代码：

const request = {
  //targets : --- letting this default to the peers assigned to the channel
  chaincodeId: 'fabcar',
  fcn: 'queryCar',
  args: ['CAR4']
};

To this:

修改为：

const request = {
  //targets : --- letting this default to the peers assigned to the channel
  chaincodeId: 'fabcar',
  fcn: 'queryCar',
  args: ['CAR10']
};

Save once again, then query:

保存后运行查询：

node query.js

Which should return this:

将得到如下返回结果：

Response is  {"colour":"Red","make":"Chevy","model":"Volt","owner":"Nick"}

Congratulations. You’ve created a car!

恭喜！你已经新添加了一辆汽车汽车！

So now that we’ve done that, let’s say that Nick is feeling generous and he wants to give his Chevy Volt to someone named Dave.

现在我们已经完成了这个步骤。加入Nick非常慷慨，他想赠送他的Chevy Volt给Dave。

To do this go back to invoke.js and change the function from createCar to changeCarOwner and input the arguments like this:

要完成这件事我们先回到``invoke.js``，修改``createCar``方法为``changeCarOwner``，方法参数如下：

var request = {
  //targets: let default to the peer assigned to the client
  chaincodeId: 'fabcar',
  fcn: 'changeCarOwner',
  args: ['CAR10', 'Dave'],
  chainId: 'mychannel',
  txId: tx_id
};

The first argument – CAR10 – reflects the car that will be changing owners. The second argument – Dave – defines the new owner of the car.

第一个参数是 – CAR10 – 说明了哪一俩汽车将会被变更所有者，第二个参数 – Dave – 定义了汽车的新的拥有者。

Save and execute the program again:

保存后运行程序：

node invoke.js

Now let’s query the ledger again and ensure that Dave is now associated with the CAR10 key:

现在我们再来查询账本来确保Dave现在和键``CAR10``关联起来了：

node query.js

It should return this result:

它将返回如下结果：

Response is  {"colour":"Red","make":"Chevy","model":"Volt","owner":"Dave"}

The ownership of CAR10 has been changed from Nick to Dave.

``CAR10``的拥有者已经由Nick变更为Dave。

Summary - 总结¶

Now that we’ve done a few queries and a few updates, you should have a pretty good sense of how applications interact with the network. You’ve seen the basics of the roles smart contracts, APIs, and the SDK play in queries and updates and you should have a feel for how different kinds of applications could be used to perform other business tasks and operations.

现在我们已经进行了一下查询和更新操作，你应该对应用如何和网络交互有了全新的认识。看到了智能合约的基本角色，API和SDK在查询和更新的使用，你应该对不同种类的应用如何进行其他商业任务和操作有了新的认识。

In subsequent documents we’ll learn how to actually write a smart contract and how some of these more low level application functions can be leveraged (especially relating to identity and membership services).

在接下来的文档我们将会学习如何真正的**写**一个智能合约，将看到更多的底层的函数和方法如何被调用（特别是一些涉及到身份认证和成员服务的方法）。

Additional Resources - 其他资源¶

The Hyperledger Fabric Node SDK repo is an excellent resource for deeper documentation and sample code. You can also consult the Fabric community and component experts on Hyperledger Rocket Chat.

Setup the Environment – 环境构建¶

We will be operating from the root of the first-network subdirectory within your local clone of fabric-samples. Change into that directory now. You will also want to open a few extra terminals for ease of use.

我们后续的操作都在 fabric-samples 项目本地副本的 first-network 子目录下进行。现在切换 到该目录下。你同时需要打个几个额外的终端，以便于于操作。

First, use the byfn.sh script to tidy up. This command will kill any active or stale docker containers and remove previously generated artifacts. It is by no means necessary to bring down a Fabric network in order to perform channel configuration update tasks. However, for the sake of this tutorial, we want to operate from a known initial state. Therefore let’s run the following command to clean up any previous environments:

首先，使用 byfn.sh 脚本清理环境。这个命令会清除运行、终止状态的容器，并且移除之前构建 的部件等。移除Fabric网络并非执行通道配置升级的必要步骤。但是为了便于这个指南的书写， 我们希望从一个已知的初始状态开始，因此让我们运行以下命令来清理之前的环境：

./byfn.sh -m down

Now generate the default BYFN artifacts:

现在生成默认的BYFN部件：

./byfn.sh -m generate

And launch the network making use of the scripted execution within the CLI container:

然后通过执行CLI容器内的脚本来构建网络：

./byfn.sh -m up

Now that you have a clean version of BYFN running on your machine, you have two different paths you can pursue. First, we offer a fully commented script that will carry out a config transaction update to bring Org3 into the network.

现在你的机器上运行着一个干净的BYFN版本，你有两种不同的方式可选。第一种，我们提供了一 个通过实施配置交易更新来将Org3添加到网络中的全量注释的脚本。

Also, we will show a “manual” version of the same process, showing each step and explaining what it accomplishes (since we show you how to bring down your network before this manual process, you could also run the script and then look at each step).

我们也提供同样过程的手动版本，演示并说明每一个步骤的作用（因为我们刚演示了在继续手动 操作前如何移除你的网络，你可以先运行那个脚本，然后再来看每个步骤）。

Bring Org3 into the Channel with the Script - 使用脚本向通道加入Org3¶

You should be in first-network. To use the script, simply issue the following:

在 first-network 目录下，简单地执行以下命令来使用脚本：

./eyfn.sh up

The output here is well worth reading. You’ll see the Org3 crypto material being added, the config update being created and signed, and then chaincode being installed to allow Org3 to execute ledger queries.

此处的脚本输出值得一读。你可以看到添加了Org3的加密材料，配置更新被创建、签名，之后链 码被安装，Org3也被允许执行账本查询。

If everything goes well, you’ll get this message:

如果诸事顺利，你会看到以下信息：

========= All GOOD, EYFN test execution completed ===========

eyfn.sh can be used with the same Node.js chaincode and database options as byfn.sh by issuing the following (instead of ./byfn.sh -m -up):

eyfn.sh 可以使用和 byfn.sh 一样的Node.js链码和数据库选项，如下所示（替代 ./byfn.sh -m -up）：

./byfn.sh up -c testchannel -s couchdb -l node

And then:

然后：

./eyfn.sh up -c testchannel -s couchdb -l node

For those who want to take a closer look at this process, the rest of the doc will show you each command for making a channel update and what it does.

对于想要详细了解该过程的人，文档的剩余部分会为你展示通道升级的每个命令，以及命令的作 用。

Bring Org3 into the Channel Manually – 向通道手动添加Org3¶

cli:
  container_name: cli
  image: hyperledger/fabric-tools:$IMAGE_TAG
  tty: true
  stdin_open: true
  environment:
    - GOPATH=/opt/gopath
    - CORE_VM_ENDPOINT=unix:///host/var/run/docker.sock
    #- CORE_LOGGING_LEVEL=INFO
    - CORE_LOGGING_LEVEL=DEBUG

Org3cli:
  container_name: Org3cli
  image: hyperledger/fabric-tools:$IMAGE_TAG
  tty: true
  stdin_open: true
  environment:
    - GOPATH=/opt/gopath
    - CORE_VM_ENDPOINT=unix:///host/var/run/docker.sock
    #- CORE_LOGGING_LEVEL=INFO
    - CORE_LOGGING_LEVEL=DEBUG

If you’ve used the eyfn.sh script, you’ll need to bring your network down. This can be done by issuing:

如果你已经使用了 eyfn.sh 脚本，你需要先移除你的网络。通过如下所示命令来完成：

./eyfn.sh down

This will bring down the network, delete all the containers and undo what we’ve done to add Org3.

When the network is down, bring it back up again.

这会移除网络，删除所有的容器，并且撤销我们添加Org3的操作。

当网络移除后，再次将它建立起来。

./byfn.sh -m generate

Then:

然后：

./byfn.sh -m up

This will bring your network back to the same state it was in before you executed the eyfn.sh script.

这会将你的网络恢复到你执行 eyfn.sh 脚本之前的状态。

Now we’re ready to add Org3 manually. As a first step, we’ll need to generate Org3’s crypto material.

现在我们可以手动添加Org3。第一步，我们需要生成Org3的加密材料。

Generate the Org3 Crypto Material – 生成Org3加密材料¶

In another terminal, change into the org3-artifacts subdirectory from first-network.

在另一个终端，切换到 first-network 的子目录 org3-artifacts 中。

cd org3-artifacts

There are two yaml files of interest here: org3-crypto.yaml and configtx.yaml. First, generate the crypto material for Org3:

这里需要关注两个 yaml 文件：org3-crypto.yaml 和 configtx.yaml。首先，生成Org3的加密 材料：

../../bin/cryptogen generate --config=./org3-crypto.yaml

This command reads in our new crypto yaml file – org3-crypto.yaml – and leverages cryptogen to generate the keys and certificates for an Org3 CA as well as two peers bound to this new Org. As with the BYFN implementation, this crypto material is put into a newly generated crypto-config folder within the present working directory (in our case, org3-artifacts).

该命令读取我们新的加密 yaml 文件 – org3-crypto.yaml – 然后调用 cryptogen 来为Org3 CA 和其他两个绑定到这个组织的peers生成秘钥和证书。如同BYFN实现，加密材料放到最近生成的 crypto-config 文件夹下，均在当前工作路径下（在我们例子中是 org3-artifacts）。

Now use the configtxgen utility to print out the Org3-specific configuration material in JSON. We will preface the command by telling the tool to look in the current directory for the configtx.yaml file that it needs to ingest.

现在使用 configtxgen 工具打印出Org3对应的配置材料，用JSON格式展示。我们将在执行命令 前，告诉这个工具去获取当前目录的 configtx.yaml 文件。

export FABRIC_CFG_PATH=$PWD && ../../bin/configtxgen -printOrg Org3MSP > ../channel-artifacts/org3.json

The above command creates a JSON file – org3.json – and outputs it into the channel-artifacts subdirectory at the root of first-network. This file contains the policy definitions for Org3, as well as three important certificates presented in base 64 format: the admin user certificate (which will be needed to act as the admin of Org3 later on), a CA root cert, and a TLS root cert. In an upcoming step we will append this JSON file to the channel configuration.

上面的命令会创建一个JSON文件 – org3.json – 并把文件输出到 first-network 的 channel-artifacts 子目录下。这个文件包含了Org3的策略定义，还有base 64编码的重要的证 书：管理员用户证书（之后作为Org3的管理员角色），一个根证书，一个TLS根证书。之后的步 骤我们会用这个JSON文件去扩展通道配置。

Our final piece of housekeeping is to port the Orderer Org’s MSP material into the Org3 crypto-config directory. In particular, we are concerned with the Orderer’s TLS root cert, which will allow for secure communication between Org3 entities and the network’s ordering node.

我们最后的例行工作是拷贝排序Org的MSP材料到Org3的 crypto-config 目录下。我们尤其关注 排序服务的TLS根证书，它可以用于Org3的通信实体和网络的排序节点间的安全通信。

cd ../ && cp -r crypto-config/ordererOrganizations org3-artifacts/crypto-config/

Now we’re ready to update the channel configuration...

现在我们准备开始升级通道配置。

Prepare the CLI Environment 准备CLI环境¶

The update process makes use of the configuration translator tool – configtxlator. This tool provides a stateless REST API independent of the SDK. Additionally it provides a CLI, to simplify configuration tasks in Fabric networks. The tool allows for the easy conversion between different equivalent data representations/formats (in this case, between protobufs and JSON). Additionally, the tool can compute a configuration update transaction based on the differences between two channel configurations.

更新的步骤需要用到配置转化工具 – configtxlator，这个工具提供了和SDK无关的无状态REST API。 它还额外提供了CLI，用于简化Fabric网络中的配置任务。这个工具提供不同的数据表示/格 式间进行转化的便利功能（在这个例子中就是protobufs和JSON格式的互转）。另外，这个工具 能基于两个不同的通道配置计算出配置更新交易。

First, exec into the CLI container. Recall that this container has been mounted with the BYFN crypto-config library, giving us access to the MSP material for the two original peer organizations and the Orderer Org. The bootstrapped identity is the Org1 admin user, meaning that any steps where we want to act as Org2 will require the export of MSP-specific environment variables.

首先，进入到CLI容器。这个容器挂载了BYFN crypto-config 库，允许我们访问两个原始的peer节点组织和 Orderer排序组织。默认的身份是Org1的管理员用户，所以如果我们想作为Org2进行任何操作，需要设置和MSP相关的环境变量。

docker exec -it cli bash

Now install the jq tool into the container. This tool allows script interactions with JSON files returned by the configtxlator tool:

现在在容器里安装 jq 工具。这个工具可以解析 configtxlator 工具返回的JSON文件。

apt update && apt install -y jq

Export the ORDERER_CA and CHANNEL_NAME variables:

Export ORDERER_CA 和 CHANNEL_NAME 变量。

export ORDERER_CA=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem  && export CHANNEL_NAME=mychannel

Check to make sure the variables have been properly set:

检查并确保环境变量已合理设置：

echo $ORDERER_CA && echo $CHANNEL_NAME

Fetch the Configuration 获取配置¶

Now we have a CLI container with our two key environment variables – ORDERER_CA and CHANNEL_NAME exported. Let’s go fetch the most recent config block for the channel – mychannel.

现在我们有了一个设置了 ORDERER_CA 和 CHANNEL_NAME 环境变量的CLI容器。让我们获取通道 mychannel 的最近的配置区块。

The reason why we have to pull the latest version of the config is because channel config elements are versioned.. Versioning is important for several reasons. It prevents config changes from being repeated or replayed (for instance, reverting to a channel config with old CRLs would represent a security risk). Also it helps ensure concurrency (if you want to remove an Org from your channel, for example, after a new Org has been added, versioning will help prevent you from removing both Orgs, instead of just the Org you want to remove).

我们必须拉取最新版本配置的原因是通道配置元素是版本化的。版本管理由于一些原因显得很重 要。它可以防止通道配置更新被重复或者重放攻击（例如，回退到带有旧的CRLs的通道配置将会 产生安全风险）。同时它保证了并行性（例如如果你想从你的通道中添加新的Org后移除一个 Org，版本管理可以帮助你移除想移除的那个Org，防止移除两个Orgs）。

peer channel fetch config config_block.pb -o orderer.example.com:7050 -c $CHANNEL_NAME --tls --cafile $ORDERER_CA

This command saves the binary protobuf channel configuration block to config_block.pb. Note that the choice of name and file extension is arbitrary. However, following a convention which identifies both the type of object being represented and its encoding (protobuf or JSON) is recommended.

这个命令将通道配置区块以二进制protobuf形式保存在 config_block.pb。注意文件的名字和扩 展名可以任意指定。然而，我们建议之后根据区块存储对象的类型和编码格式（protobuf或 JSON）进行转换。

When you issued the peer channel fetch command, there was a decent amount of output in the terminal. The last line in the logs is of interest:

当你执行 peer channel fetch 命令后，在终端上会有相当数量的打印输出。日志的最后一行比较 有意思：

2017-11-07 17:17:57.383 UTC [channelCmd] readBlock -> DEBU 011 Received block: 2

This is telling us that the most recent configuration block for mychannel is actually block 2, NOT the genesis block. By default, the peer channel fetch config command returns the most recent configuration block for the targeted channel, which in this case is the third block. This is because the BYFN script defined anchor peers for our two organizations – Org1 and Org2 – in two separate channel update transactions.

这是告诉我们最近的 mychannel 的配置区块实际上是区块2，非 初始区块。 peer channel fetch config 命令默认返回目标通道最新的配置区块，在这个例子里是第三个区 块。这是因为BYFN脚本分别在两个不同通道更新交易中为两个组织– Org1 和 Org2 定义了锚节 点。

As a result, we have the following configuration sequence:

那么，我们有如下的配置块序列：

• block 0: genesis block
• block 1: Org1 anchor peer update
• block 2: Org2 anchor peer update

Convert the Configuration to JSON and Trim It Down – 转换配置到JSON格式并裁剪¶

Now we will make use of the configtxlator tool to decode this channel configuration block into JSON format (which can be read and modified by humans). We also must strip away all of the headers, metadata, creator signatures, and so on that are irrelevant to the change we want to make. We accomplish this by means of the jq tool:

现在我们是用 configtxlator 的工具将这个通道配置转换为JSON格式（以便友好地被阅读和修 改）。我们也必须裁剪所有的头部，元数据，创建者签名等这些和我们即将做的无关的内容。我 们通过 jq 这个工具来实现：

configtxlator proto_decode --input config_block.pb --type common.Block | jq .data.data[0].payload.data.config > config.json

This leaves us with a trimmed down JSON object – config.json, located in the fabric-samples folder inside first-network – which will serve as the baseline for our config update.

我们得到一个裁剪后的JSON对象 – config.json ，放置在 fabric-samples 下的 first-network 文件夹下 – first-network 是我们配置更新的基准工作目录。

Take a moment to open this file inside your text editor of choice (or in your browser). Even after you’re done with this tutorial, it will be worth studying it as it reveals the underlying configuration structure and the other kind of channel updates that can be made. We discuss them in more detail in Updating a Channel Configuration.

花一些时间用你的text编辑器（或者你的浏览器）打开这个文件。即使你已经完成了这个指南， 也值得研究下它，因为它揭示了底层配置结构，和能做的其它类型的通道更新升级。我们将在 Updating a Channel Configuration 更详细地讨论。

Add the Org3 Crypto Material – 添加Org3加密材料¶

We’ll use the jq tool once more to append the Org3 configuration definition – org3.json – to the channel’s application groups field, and name the output – modified_config.json.

我们将再次使用 jq 工具去扩展Org3的配置定义 – org3.json – 对应到通道的应用组属性，同时定义输出文件是 – modified_config.json

jq -s '.[0] * {"channel_group":{"groups":{"Application":{"groups": {"Org3MSP":.[1]}}}}}' config.json ./channel-artifacts/org3.json > modified_config.json

Now, within the CLI container we have two JSON files of interest – config.json and modified_config.json. The initial file contains only Org1 and Org2 material, whereas “modified” file contains all three Orgs. At this point it’s simply a matter of re-encoding these two JSON files and calculating the delta.

现在，我们在CLI容器有两个重要的JSON文件 – config.json 和 modified_config.json。初始 的文件包含Org1和Org2的材料，而”modified”文件包含了总共三个Orgs。现在只需要将这两个 JSON文件重新编码并计算出差异部分。

First, translate config.json back into a protobuf called config.pb:

首先，将 config.json 文件倒回到protobuf格式，命名为 config.pb ：

configtxlator proto_encode --input config.json --type common.Config --output config.pb

Next, encode modified_config.json to modified_config.pb:

下一步，将 modified_config.json 编码成 modified_config.pb:

configtxlator proto_encode --input modified_config.json --type common.Config --output modified_config.pb

Now use configtxlator to calculate the delta between these two config protobufs. This command will output a new protobuf binary named org3_update.pb:

现在使用 configtxlator 去计算两个protobuf配置的差异。这条命令会输出一个新的protobuf二 进制文件，命名为 org3_update.pb 。

configtxlator compute_update --channel_id $CHANNEL_NAME --original config.pb --updated modified_config.pb --output org3_update.pb

This new proto – org3_update.pb – contains the Org3 definitions and high level pointers to the Org1 and Org2 material. We are able to forgo the extensive MSP material and modification policy information for Org1 and Org2 because this data is already present within the channel’s genesis block. As such, we only need the delta between the two configurations.

这个新的proto文件 – org3_update.pb – 包含了Org3定义和指向Org1和Org2材料的更高级别的指 针。我们可以抛弃Org1和Org2相关的MSP材料和修改策略信息，因为这些数据已经存在于通道 的初始区块。因此，我们只需要两个配置的差异部分。

Before submitting the channel update, we need to perform a few final steps. First, let’s decode this object into editable JSON format and call it org3_update.json:

在我们提交通道更新前，我们最后做几个操作。首先，我们将这个对象解码成可编辑的JSON格 式，并命名为 org3_update.json 。

configtxlator proto_decode --input org3_update.pb --type common.ConfigUpdate | jq . > org3_update.json

Now, we have a decoded update file – org3_update.json – that we need to wrap in an envelope message. This step will give us back the header field that we stripped away earlier. We’ll name this file org3_update_in_envelope.json:

现在，我们有了一个解码后的更新文件 – org3_update.json – 我们需要用信封消息来包装它。这 个步骤要把之前裁剪掉的头部信息还原回来。我们将命名这个新文件为 org3_update_in_envelope.json。

echo '{"payload":{"header":{"channel_header":{"channel_id":"mychannel", "type":2}},"data":{"config_update":'$(cat org3_update.json)'}}}' | jq . > org3_update_in_envelope.json

Using our properly formed JSON – org3_update_in_envelope.json – we will leverage the configtxlator tool one last time and convert it into the fully fledged protobuf format that Fabric requires. We’ll name our final update object org3_update_in_envelope.pb:

使用我们格式化好的JSON – org3_update_in_envelope.json – 我们最后一次使用 configtxlator 工具将他转换为fabric需要的完整独立的protobuf格式。我们将最后的更新对象命名为 org3_update_in_envelope.pb。

configtxlator proto_encode --input org3_update_in_envelope.json --type common.Envelope --output org3_update_in_envelope.pb

Sign and Submit the Config Update – 签名并提交配置更新¶

Almost done!

We now have a protobuf binary – org3_update_in_envelope.pb – within our CLI container. However, we need signatures from the requisite Admin users before the config can be written to the ledger. The modification policy (mod_policy) for our channel Application group is set to the default of “MAJORITY”, which means that we need a majority of existing org admins to sign it. Because we have only two orgs – Org1 and Org2 – and the majority of two is two, we need both of them to sign. Without both signatures, the ordering service will reject the transaction for failing to fulfill the policy.

差不多大功告成了！

我们现在有一个protobuf二进制 – org3_update_in_envelope.pb – 在我们的CLI容器内。但是，在 配置写入到账本前，我们需要必要的Admin用户的签名。我们通道应用组的修改策略(mod_policy)设置 为默认值”MAJORITY”，因此意味着我们需要大多数已经存在的组织管理员去签名这个更 新。因为我们只有两个组织 – Org1和Org2 – 也即两个的大多数也还是两个，我们需要它们都签 名。没有这两个签名，排序服务会以不满足策略为由拒绝这个交易。

First, let’s sign this update proto as the Org1 Admin. Remember that the CLI container is bootstrapped with the Org1 MSP material, so we simply need to issue the peer channel signconfigtx command:

首先，让我们以Org1管理员升级来签名这个更新proto。因为CLI容器是以Org1 MSP材料启动 的，我们只需要简单执行 peer channel signconfigtx 命令:

peer channel signconfigtx -f org3_update_in_envelope.pb

The final step is to switch the CLI container’s identity to reflect the Org2 Admin user. We do this by exporting four environment variables specific to the Org2 MSP.

最后一步，我们将CLI容器的身份切换为Org2管理员。为此，我们通过export和Org2 MSP相关的 四个环境变量。

Export the Org2 environment variables:

Export Org2的环境变量：

# you can issue all of these commands at once

export CORE_PEER_LOCALMSPID="Org2MSP"

export CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/ca.crt

export CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/users/Admin@org2.example.com/msp

export CORE_PEER_ADDRESS=peer0.org2.example.com:7051

Lastly, we will issue the peer channel update command. The Org2 Admin signature will be attached to this call so there is no need to manually sign the protobuf a second time:

最后，我们执行 peer channel update 命令。Org2 管理员在这个命令中会附带签名，因此就没有 必要对protobuf进行两次签名。

Send the update call:

发起更新调用：

peer channel update -f org3_update_in_envelope.pb -c $CHANNEL_NAME -o orderer.example.com:7050 --tls --cafile $ORDERER_CA

You should see a message digest indication similar to the following if your update has been submitted successfully:

如果你的更新提交成功，将会看到一个类似如下的摘要提示信息：

2018-02-24 18:56:33.499 UTC [msp/identity] Sign -> DEBU 00f Sign: digest: 3207B24E40DE2FAB87A2E42BC004FEAA1E6FDCA42977CB78C64F05A88E556ABA

You will also see the submission of our configuration transaction:

你也会看到我们的配置交易的提交：

2018-02-24 18:56:33.499 UTC [channelCmd] update -> INFO 010 Successfully submitted channel update

The successful channel update call returns a new block – block 5 – to all of the peers on the channel. If you remember, blocks 0-2 are the initial channel configurations while blocks 3 and 4 are the instantiation and invocation of the mycc chaincode. As such, block 5 serves as the most recent channel configuration with Org3 now defined on the channel.

成功的通道更新调用返回一个新的区块 – 区块5 – 给所有在这个通道上的peers节点。如果你还记 得，区块0-2是初始的通道配置，而区块3和4是链码 mycc 的实例化和调用。至此，区块5就是带 有Org3定义的最新的通道配置。

Inspect the logs for peer0.org1.example.com:

查看 peer0.org1.example.com 的日志：

docker logs -f peer0.org1.example.com

Follow the demonstrated process to fetch and decode the new config block if you wish to inspect its contents.

如果你想查看新的配置区块的内容，可以跟着示范的过程获取和解码配置区块。

Configuring Leader Election – 配置领导选举¶

Newly joining peers are bootstrapped with the genesis block, which does not contain information about the organization that is being added in the channel configuration update. Therefore new peers are not able to utilize gossip as they cannot verify blocks forwarded by other peers from their own organization until they get the configuration transaction which added the organization to the channel. Newly added peers must therefore have one of the following configurations so that they receive blocks from the ordering service:

新加入的peer节点是根据初始区块启动，初始区块是不包含通道配置更新中新加入的组织信息 的。因此新的peer节点就无法利用gossip协议，因为它们无法验证从自己组织里其他peer节点发 送过来的区块，直到它们接收到加入组织到通道的那个配置交易。因此新加入的节点必须有以下 的一个配置来保证能从排序服务接收区块：

1. To utilize static leader mode, configure the peer to be an organization leader:

1. 采用静态领导者模式，将peer节点配置为组织的领导者。

CORE_PEER_GOSSIP_USELEADERELECTION=false
CORE_PEER_GOSSIP_ORGLEADER=true

2. To utilize dynamic leader election, configure the peer to use leader election:

2. 采用动态领导者选举，配置peer节点采用领导选举：

CORE_PEER_GOSSIP_USELEADERELECTION=true
CORE_PEER_GOSSIP_ORGLEADER=false

Join Org3 to the Channel – 向通道添加Org3¶

At this point, the channel configuration has been updated to include our new organization – Org3 – meaning that peers attached to it can now join mychannel.

此时，通道的配置已经更新并包含了我们新的组织 – Org3 – 意味者这个组织下的peer节点可以加入 到 mychannel。

First, let’s launch the containers for the Org3 peers and an Org3-specific CLI.

首先，让我们部署Org3 peer节点容器和Org3-specific CLI容器。

Open a new terminal and from first-network kick off the Org3 docker compose:

打开一个以 first-network 为工作目录的新的终端，开始Org3 docker compose的部署：

docker-compose -f docker-compose-org3.yaml up -d

This new compose file has been configured to bridge across our initial network, so the two peers and the CLI container will be able to resolve with the existing peers and ordering node. With the three new containers now running, exec into the Org3-specific CLI container:

这个新的compose文件配置为桥接我们的初始网络，因此两个peer容器和CLI容器可以融入到已经 存在的peer和排序节点中。当三个容器运行后，进入Org3-specific CLI容器：

docker exec -it Org3cli bash

Just as we did with the initial CLI container, export the two key environment variables: ORDERER_CA and CHANNEL_NAME:

和我们之前在初始CLI容器一样，export两个关键环境变量： ORDERER_CA 和 CHANNEL_NAME：

export ORDERER_CA=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem && export CHANNEL_NAME=mychannel

Check to make sure the variables have been properly set:

检查确保环境变量已经合理设置：

echo $ORDERER_CA && echo $CHANNEL_NAME

Now let’s send a call to the ordering service asking for the genesis block of mychannel. The ordering service is able to verify the Org3 signature attached to this call as a result of our successful channel update. If Org3 has not been successfully appended to the channel config, the ordering service should reject this request.

现在，我们向排序服务发送一个请求 mychannel 的初始区块的请求。如果通道更新成功执行，排 序服务会成功校验这个请求中Org3的签名。如果Org3没有成功地添加到通道配置中，排序服务会 拒绝这个请求。

Use the peer channel fetch command to retrieve this block:

使用 peer channel fatch 命令来检索这个区块：

peer channel fetch 0 mychannel.block -o orderer.example.com:7050 -c $CHANNEL_NAME --tls --cafile $ORDERER_CA

Notice, that we are passing a 0 to indicate that we want the first block on the channel’s ledger (i.e. the genesis block). If we simply passed the peer channel fetch config command, then we would have received block 5 – the updated config with Org3 defined. However, we can’t begin our ledger with a downstream block – we must start with block 0.

注意，我们传递了 0 去索引我们在这个通道账本上想要的区块（例如，初始区块）。如果我们 简单地执行 peer channel fetch config 命令，我们将会收到区块5 – 那个带有Org3定义的更新 后的配置。然而，我们的账本不能从一个下游的区块开始 – 我们必须从区块0开始。

Issue the peer channel join command and pass in the genesis block – mychannel.block:

执行 peer channel join 命令并指定初始区块 – mychannel.block:

peer channel join -b mychannel.block

If you want to join the second peer for Org3, export the TLS and ADDRESS variables and reissue the peer channel join command:

如果你想将第二个peer节点加入到Org3中，export TLS 和 ADDRESS 变量，再重新执行 peer channel join command

export CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org3.example.com/peers/peer1.org3.example.com/tls/ca.crt && export CORE_PEER_ADDRESS=peer1.org3.example.com:7051

peer channel join -b mychannel.block

pgrade and Invoke Chaincode – 升级和调用链码¶

The final piece of the puzzle is to increment the chaincode version and update the endorsement policy to include Org3. Since we know that an upgrade is coming, we can forgo the futile exercise of installing version 1 of the chaincode. We are solely concerned with the new version where Org3 will be part of the endorsement policy, therefore we’ll jump directly to version 2 of the chaincode.

这个智力游戏的最后一部分是升级链码的版本，并升级背书策略以加入Org3。因为我们知道马上 要做的是升级，将无关紧要的安装第一个版本链码的过程抛诸脑后吧。我们只关心Org3会是背书 策略一部分的新的版本，因此我们直接跳到链码的第二个版本。

From the Org3 CLI:

从Org3 CLI执行：

peer chaincode install -n mycc -v 2.0 -p github.com/chaincode/chaincode_example02/go/

Modify the environment variables accordingly and reissue the command if you want to install the chaincode on the second peer of Org3. Note that a second installation is not mandated, as you only need to install chaincode on peers that are going to serve as endorsers or otherwise interface with the ledger (i.e. query only). Peers will still run the validation logic and serve as committers without a running chaincode container.

如果你要在Org3的第二个peer节点上安装链码，请相应地修改环境变量并再次执行命令。注意第 二次安装并不是强制的，因为你只需要在背书节点或者和账本有交互行为(如，只做查询)节点上 安装链码。即使没有运行链码容器，Peer节点仍然会运行检验逻辑，作为commiter角色工作。

Now jump back to the original CLI container and install the new version on the Org1 and Org2 peers. We submitted the channel update call with the Org2 admin identity, so the container is still acting on behalf of peer0.org2:

现在跳回 original CLI容器，在Org1和Org2 peer节点上安装新版本链码。我们使用Org2管理员身 份提交通道更新请求，所以容器仍然是代表”peer0.Org2”:

peer chaincode install -n mycc -v 2.0 -p github.com/chaincode/chaincode_example02/go/

Flip to the peer0.org1 identity:

切回 peer0.org1 身份：

export CORE_PEER_LOCALMSPID="Org1MSP"

export CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt

export CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp

export CORE_PEER_ADDRESS=peer0.org1.example.com:7051

And install again:

然后再次安装：

peer chaincode install -n mycc -v 2.0 -p github.com/chaincode/chaincode_example02/go/

Now we’re ready to upgrade the chaincode. There have been no modifications to the underlying source code, we are simply adding Org3 to the endorsement policy for a chaincode – mycc – on mychannel.

现在我们已经准备好升级链码。底层的源代码没有任何变化，我们只是简单为在 mychannel 通道上的 mycc 链码的背书策略添加Org3组织。

Send the call:

发送调用：

peer chaincode upgrade -o orderer.example.com:7050 --tls $CORE_PEER_TLS_ENABLED --cafile $ORDERER_CA -C $CHANNEL_NAME -n mycc -v 2.0 -c '{"Args":["init","a","90","b","210"]}' -P "OR ('Org1MSP.peer','Org2MSP.peer','Org3MSP.peer')"

You can see in the above command that we are specifying our new version by means of the v flag. You can also see that the endorsement policy has been modified to -P "OR ('Org1MSP.peer','Org2MSP.peer','Org3MSP.peer')", reflecting the addition of Org3 to the policy. The final area of interest is our constructor request (specified with the c flag).

你可以看到上面的命令，我们用 v 标志指定了我们的新的版本号。你也能看到背书策略修改为 -P "OR ('Org1MSP.peer','Org2MSP.peer','Org3MSP.peer')" ，说明Org3要被添加到策略中。最后一部分注意的是我们的构造请求(用 c 标志指定)。

As with an instantiate call, a chaincode upgrade requires usage of the init method. If your chaincode requires arguments be passed to the init method, then you will need to do so here.

链码升级和实例化一样需要用到 init 方法。 如果 你的链码需要传递参数给 init 方法，那你 需要在这里添加。

The upgrade call adds a new block – block 6 – to the channel’s ledger and allows for the Org3 peers to execute transactions during the endorsement phase. Hop back to the Org3 CLI container and issue a query for the value of a. This will take a bit of time because a chaincode image needs to be built for the targeted peer, and the container needs to start:

升级调用对于通道的账本添加一个新的区块 – 允许Org3的peer节点在背书阶段执行交易。跳回到 Org3 CLI容器，并执行对 a 值得查询。这需要花费一点时间，因为需要为目标peer构建链码镜 像，链码容器需要运行。

peer chaincode query -C $CHANNEL_NAME -n mycc -c '{"Args":["query","a"]}'

We should see a response of Query Result: 90.

我们能看到 Query Result：90 的响应。

Now issue an invocation to move 10 from a to b:

现在执行调用，从 a 转移 10 到 b：

peer chaincode invoke -o orderer.example.com:7050  --tls $CORE_PEER_TLS_ENABLED --cafile $ORDERER_CA -C $CHANNEL_NAME -n mycc -c '{"Args":["invoke","a","b","10"]}'

Query one final time:

peer chaincode query -C $CHANNEL_NAME -n mycc -c '{"Args":["query","a"]}'

We should see a response of Query Result: 80, accurately reflecting the update of this chaincode’s world state.

我们能看到 Query Result: 80 的响应，准确反映了链码的世界状态的更新。

Conclusion – 总结¶

The channel configuration update process is indeed quite involved, but there is a logical method to the various steps. The endgame is to form a delta transaction object represented in protobuf binary format and then acquire the requisite number of admin signatures such that the channel configuration update transaction fulfills the channel’s modification policy.

通道配置的更新过程是非常复杂的，但是仍然有一个诸多步骤对应的逻辑方法。终局就是为了构 建一个用protobuf二进制表达的差异化的交易对象，然后获取必要数量的管理员签名来满足通道 的修改策略。

The configtxlator and jq tools, along with the ever-growing peer channel commands, provide us with the functionality to accomplish this task.

configtxlator 和 jq 工具，和不断使用的 peer channel 命令，为我们提供了完成这个任务的基本功能。

Overview¶

概述¶

Because the :doc:`build_network` (BYFN) tutorial defaults to the “latest” binaries, if you have run it since the release of v1.1, your machine will have v1.1 binaries and tools installed on it and you will not be able to upgrade them.

因为 ：doc：`build_network`（BYFN） 教程默认使用“最新”二进制文件，如果你自v1.1发布以来已经运行它，你的机器上将会已经安装v1.1二进制文件和工具，你就不可能升级它们。

As a result, this tutorial will provide a network based on Hyperledger Fabric v1.0.6 binaries as well as the v1.1 binaries you will be upgrading to. In addition, we will show how to update channel configurations to recognize :doc:`capability_requirements`.

因此，本教程将提供基于Hyperledger Fabric v1.0.6二进制文件的网络以及您要升级到的v1.1二进制文件。 此外，我们将展示如何更新信道配置以识别 ：doc：`capability_requirements`。

However, because BYFN does not support the following components, our script for upgrading BYFN will not cover them:

但是，由于BYFN不支持以下组件，因此我们用于升级BYFN的脚本不会涵盖它们：

• Fabric-CA
• Kafka
• SDK

The process for upgrading these components will be covered in a section following the tutorial.

升级这些组件的过程将在本教程后面的部分中介绍。

At a high level, our upgrade tutorial will perform the following steps:

在较高级别，我们的升级教程将执行以下步骤：

1. Back up the ledger and MSPs.
2. Upgrade the orderer binaries to Fabric v1.1.
3. Upgrade the peer binaries to Fabric v1.1.
4. Enable v1.1 channel capability requirements.

1. 备份分类帐和MSP。
2. 将背书节点的二进制文件升级到Fabric v1.1。
3. 将节点的二进制文件升级到Fabric v1.1。
4. 启用v1.1信道功能要求。

注意： 在生产环境中，背书节点和节点可以同时滚动升级（换句话说，在升级节点之前，您无需升级背书节点）。必须特别注意的是启用功能。必须在该步骤之前升级所有背书节点和节点（如果在启用功能时仅升级了一些背书节点，则可以创建灾难性的状态分支）。

This tutorial will demonstrate how to perform each of these steps individually with CLI commands.

本教程将演示如何使用CLI命令单独执行每个步骤。

Launch a v1.0.6 Network¶

启动v1.0.6网络¶

To begin, we will provision a basic network running Fabric v1.0.6 images. This network will consist of two organizations, each maintaining two peer nodes, and a “solo” ordering service.

首先，我们将提供运行Fabric v1.0.6映像的基本网络。 该网络将由两个组织组成，每个组织维护两个节点，以及一个“独立”的背书服务。

We will be operating from the first-network subdirectory within your local clone of fabric-samples. Change into that directory now. You will also want to open a few extra terminals for ease of use.

我们将在您的本地 Fabric-samples 克隆中的 第一个网络 子目录中运行。 立即切换到该目录。 您还需要打开一些额外的终端以方便使用。

./byfn.sh -m down

git fetch origin

git checkout v1.0.6

./byfn.sh -m generate

./byfn.sh -m up -t 3000 -i 1.0.6

===================== All GOOD, BYFN execution completed =====================

git fetch origin

git checkout v1.1.x

# Note, replace '1.1.x' with a specific version, for example '1.1.0'.
# Don't pass the image flag '-i 1.1.x' if you prefer to default to 'latest' images.

#注意，将“1.1.x”替换为特定版本，例如“1.1.0”。
#如果您希望默认为“最新”图像，就不要图像标记'-i 1.1.x'。

./byfn.sh upgrade -i 1.1.x

===================== All GOOD, End-2-End UPGRADE Scenario execution completed =====================

Upgrade the Orderer Containers¶

升级背书节点容器¶

注意： 请 密切 关注您的背书节点升级。 如果它们没有正确完成 - 特别是，如果只升级了一些背书节点而其他背书节点没有升级 - 可以创建一个状态分支（ 意味着，分类账将不再一致）。 这必须是被避免的。

Orderer containers should be upgraded in a rolling fashion (one at a time). At a high level, the orderer upgrade process goes as follows:

背书节点容器（Order Containers）应以滚动方式升级（一次一个）。 在较高级别，背书节点升级过程如下：

1. Stop the orderer.
2. Back up the orderer’s ledger and MSP.
3. Restart the orderer with the latest images.
4. Verify upgrade completion.

1. 停止背书节点。
2. 收回背书节点的分类账和MSP。
3. 使用最新图像重新打开背书节点。
4. 验证升级完成。

As a consequence of leveraging BYFN, we have a solo orderer setup, therefore, we will only perform this process once. In a Kafka setup, however, this process will have to be performed for each orderer.

由于使用BYFN，我们有一个独立的背书节点的设置，因此，我们只会执行一次此过程。 但是，在Kafka设置中，必须为每个背书节点执行此过程。