超级账本官方教程第七章

Gaining Network Membership

Hyperledger Fabric is a permissioned network, meaning that only participants who have been approved can gain entry to the network. To handle network membership and identity, membership service providers (MSP) manage user IDs, and authenticate all the participants in the network. A Hyperledger Fabric blockchain network can be governed by one or more MSPs. This provides modularity of membership operations, and interoperability across different membership standards and architectures.

In our scenario, the regulator, the approved fishermen, and the approved restaurateurs should be the only ones allowed to join the network. To achieve this, a membership service provider (MSP) is defined to accommodate membership for all members of this supply chain. In configuring this MSP, certificates and membership identities are created. Policies are then defined to dictate the read/write policies of a channel, or the endorsement policies of a chaincode.

Our scenario has two separate chaincodes, which are run on three separate channels. The two chaincodes are: one for the price agreement between the fisherman and the restaurateur, and one for the transfer of tuna. The three channels are: one for the price agreement between Sarah and Miriam; one for the price agreement between Sarah and Carl; and one for the transfer of tuna. Each member of this network knows about each other and their identity. The channels provide privacy and confidentiality of transactions.

In Hyperledger Fabric, MSPs also allow for dynamic membership to add or remove members to maintain integrity and operation of the supply chain. For example, if Sarah was found to be catching her fish illegally, she can have her membership revoked, without compromising the rest of the network. This feature is critical, especially for enterprise applications, where business relationships change over time.

Hyperledger Fabric是一个基于授权的网络，这意味着只有经过批准的参与者才能进入网络。为了处理网络成员身份和身份，成员服务提供者(MSP)管理用户id，并对网络中的所有参与者进行身份验证。一个Fabric区块链网络可以由一个或多个MSPs控制。这提供了成员操作的模块化，以及跨不同成员标准和体系结构的互操作性。

在我们的方案中，监管机构、被批准的渔民和批准的餐馆老板应该是唯一允许加入网络的角色。为了实现这一点，定义了一个成员服务提供者(MSP)，以管理该供应链所有成员的成员资格。在配置这个MSP时，将创建证书和成员身份标识。然后定义策略来指定通道的读/写策略，或chaincode的支持策略。

我们的场景有两个单独的链码，它们分别运行在三个不同的通道上。这两个链码是:一个是渔民和餐馆老板之间的价格协议，另一个是金枪鱼的转让。这三个通道是: 一个是莎拉和米里亚姆之间的价格协议; 一个是莎拉和卡尔之间的价格协议; 还有一个用来转移金枪鱼。这个网络的每个成员都知道对方的身份和身份。这些通道为交易提供了隐私和机密性。

在Hyperledger Fabric中，MSPs还允许动态成员添加或删除成员以维护供应链的完整性和操作。例如，如果萨拉被发现非法捕捞她的鱼，她可以让她的成员被撤销，而不损害其他的网络。这个特性非常重要，特别是对于企业应用程序来说，业务关系随着时间而变化。

Summary of Demonstrated Scenario

Below is a summary of the tuna catch scenario presented in this section:

1. Sarah catches a tuna and uses the supply chain application’s user interface to record all the details about the catch to the ledger. Before it reaches the ledger, the transaction is passed to the endorsing peers on the network, where it is then endorsed. The endorsed transaction is sent to the ordering service, to be ordered into a block. This block is then sent to the committing peers in the network, where it is committed after being validated.
2. As the tuna is passed along the supply chain, regulators may use their own application to query the ledger for details about specific catches (excluding price, since they do not have access to the price-related chaincode).
3. Sarah may enter into an agreement with a restaurateur Carl, and agree on a price of 80 per pound. They use the blue channel for the chaincode contract stipulating 80/lb. The blue channel’s ledger is updated with a block containing this transaction.
4. In a separate business agreement, Sarah and Miriam agree on a special price of 50 per pound. They use the red channel’s chaincode contract stipulating 50/lb. The red channel’s ledger is updated with a block containing this transaction.

下面是本节介绍的金枪鱼供应链场景的摘要:

莎拉抓住了一条金枪鱼，并使用了供应链应用的用户界面，记录了所有关于捕获的细节。在它到达分布式账本之前，交易被传递给网络上的背书节点，然后被背书。已被背书的事务被发送到排序节点，将被排序到一个块中。然后该块被发送到网络中的提交节点，在经过验证后提交。
当金枪鱼在供应链中被传递时，监管机构可能会使用他们自己的应用程序来查询关于特定渔获物的详细信息(不包括价格，因为他们无法获得与价格相关的链码)。
莎拉可能会和一个餐馆老板达成协议，并同意每磅80美元的价格。他们使用蓝色通道的chaincode合同规定$80/lb。蓝色通道的分类帐将被更新为包含该事务的区块。
在另一份商业协议中，莎拉和米利安同意每磅50美元的特价。他们使用红色通道的chaincode合同规定50美元/磅。红色通道的分类帐将更新为包含该事务的区块。

Roles within a Hyperledger Fabric Network

There are three different types of roles within a Hyperledger Fabric network:

• • Clients
    Clients are applications that act on behalf of a person to propose transactions on the network.
  • Peers
    Peers maintain the state of the network and a copy of the ledger. There are two different types of peers: endorsing and committing
    peers. However, there is an overlap between endorsing and committing
    peers, in that endorsing peers are a special kind of committing peers.
    All peers commit blocks to the distributed ledger.
    - Endorsers simulate and endorse transactions
    - Committers verify endorsements and validate transaction results, prior to committing transactions to the blockchain.
  • Ordering Service
    The ordering service accepts endorsed transactions, orders them into a block, and delivers the blocks to the committing peers.

在Fabric的网络中有三个不同的角色：

1. 客户端：为现实社会中的参与者提供与区块链网络交互的接口
2. 节点：节点维持着整个网络中账本的备份。节点分为两种：背书节点和提交节点，两个功能可能在物理上从属于同一个节点。背书节点的功能为对交易进行模拟及背书；提交节点的功能为校验背书状态和交易的合法性，并提交交易到超级账本。
3. 排序节点：排序节点接收背书之后的交易，将所有交易排序至一个区块，将区块发送至提交节点写入超级账本。

How to Reach Consensus

In a distributed ledger system, consensus is the process of reaching agreement on the next set of transactions to be added to the ledger. In Hyperledger Fabric, consensus is made up of three distinct steps:

• • Transaction endorsement
  • Ordering
  • Validation and commitment.

These three steps ensure the policies of a network are upheld. We will explore how these steps are implemented by exploring the transaction flow.

共识机制用于分布式账本进行下一次生成区块之前达成共识的方法。在Fabric中，共识机制分为三步：

1. 交易背书
2. 交易排序
3. 交易校验及提交

Transaction Flow (Step 1)

Within a Hyperledger Fabric network, transactions start out with client applications sending transaction proposals, or, in other words, proposing a transaction to endorsing peers.

Client applications are commonly referred to as applications or clients, and allow people to communicate with the blockchain network. Application developers can leverage the Hyperledger Fabric network through the application SDK.

在Fabric的架构中，交易起始于客户端应用发送的交易申请（提交交易至背书节点）。客户端应用允许参与者与区块链进行通信。应用的开发者可以利用 SDK 和超级账本进行交互。

Transaction Flow (Step 2)

Each endorsing peer simulates the proposed transaction, without updating the ledger. The endorsing peers will capture the set of Read and Written data, called RW Sets. These RW sets capture what was read from the current world state while simulating the transaction, as well as what would have been written to the world state had the transaction been executed. These RW sets are then signed by the endorsing peer, and returned to the client application to be used in future steps of the transaction flow.

Endorsing peers must hold smart contracts in order to simulate the transaction proposals.

每一个背书节点对交易申请进行模拟，模拟交易将要读取和写入超级账本的内容（但不实际修改账本），将其生成一份RW Sets, 背书节点对RW Sets进行签名并将签名后的内容返回给客户端应用。

注意：背书节点需要持有交易所用的链码用于交易申请的模拟工作。

Transaction Endorsement

A transaction endorsement is a signed response to the results of the simulated transaction. The method of transaction endorsements depends on the endorsement policy which is specified when the chaincode is deployed. An example of an endorsement policy would be “the majority of the endorsing peers must endorse the transaction”. Since an endorsement policy is specified for a specific chaincode, different channels can have different endorsement policies.

交易的背书指交易申请被背书节点模拟并签名之后的响应。交易背书的方法依赖于链码部署时指定的背书策略。比如：“主要的背书节点必须对交易申请进行背书”。因此，背书策略被链码定制，进而，不同的通道也可以有不同的背书策略。

Transaction Flow (Step 3)

The application then submits the endorsed transaction and the RW sets to the ordering service. Ordering happens across the network, in parallel with endorsed transactions and RW sets submitted by other applications.

客户端将背书交易和RW Sets发送给排序节点。排序节点会收集整个网络里各个客户端的背书交易来进行排序。

Transaction Flow (Step 4)

The ordering service takes the endorsed transactions and RW sets, orders this information into a block, and delivers the block to all committing peers.

The ordering service, which is made up of a cluster of orderers, does not process transactions, smart contracts, or maintains the shared ledger. The ordering service accepts the endorsed transactions and specifies the order in which those transactions will be committed to the ledger. The Fabric v1.0 architecture has been designed such that the specific implementation of ‘ordering’ (Solo, Kafka, BFT) becomes a pluggable component. The default ordering service for Hyperledger Fabric is Kafka. Therefore, the ordering service is a modular component of Hyperledger Fabric.

排序节点将所有的背书交易排好序封装入区块后，将该区块发送给所有的提交节点。排序节点由一个节点集群构成，排序节点不包含处理交易，智能合约和写入账本的功能。排序节点的功能仅仅是接受各个客户端应用发送过来的背书交易，并把所有交易进行排序打包写入区块中，然后将区块发送给提交节点。Fabric实现了Solo,Kafka,SBFT等排序的机制，并且将其作为模块化的形式与区块链网络通信。

Ordering Service

排序节点视频介绍

The ordering service is actually something that we conceived of as a function of the initial rollout of Fabric 0.6, last year,

in the sense that… we determined that, in order to improve the performance of the consensus computation,

that, if we separated out the ordering aspects of consensus, where typically, whether it’s Bitcoin or Ethereum, the minors are determining the order of transactions in a block,

if we instead make that in an independent service, and apply the fault tolerance to the ordering service itself,

we can actually get a significant improvement in performance and throughput of the overall system.

And so, we’ve implemented, to date, two ordering services.

One is called SOLO - it’s really a toy; I mean, it’s intended to be used for development purposes, or initial testing of new functions, and so forth.

And then, another one is based on an implementation of Kafka.

And, over time, as we go forward, we plan on introducing various forms of fault tolerance too to that ordering service.

And so, the initial one is going to be based on RAFT consensus, which isn’t byzantine fault tolerant, but it is crash fault tolerant,

and then, there is ongoing work on something we call Simplified Byzantine Fault Tolerance,

and that, we should have probably in the first half of 2018.

Fabric将排序节点作为一个独立模块的方式，不同于比特币和以太坊将共识机制嵌入到整个公有链系统。最大的好处就是可以针对不同的业务场景自行选择共识的算法，以达到对不同业务场景需求下性能的最优化。

Ordering (Part I)

Transactions within a timeframe are sorted into a block and are committed in sequential order.

In a blockchain network, transactions have to be written to the shared ledger in a consistent order. The order of transactions has to be established to ensure that the updates to the world state are valid when they are committed to the network. Unlike the Bitcoin blockchain, where ordering occurs through the solving of a cryptographic puzzle, or mining, Hyperledger Fabric allows the organizations running the network to choose the ordering mechanism that best suits that network. This modularity and flexibility makes Hyperledger Fabric incredibly advantageous for enterprise applications.

排序节点，实现了区块链上所有的交易排序之后被计入分布式账本的功能，交易排序为了保证交易被写入账本时的合法性。

Ordering (Part II)

Hyperledger Fabric provides three ordering mechanisms: SOLO, Kafka, and Simplified Byzantine Fault Tolerance (SBFT), the latter of which has not yet been implemented in Fabric v1.0.

• • SOLO is the Hyperledger Fabric ordering mechanism most typically used by developers experimenting with Hyperledger Fabric networks. SOLO involves a single ordering node.
  • Kafka is the Hyperledger Fabric ordering mechanism that is recommended for production use. This ordering mechanism utilizes Apache Kafka, an open source stream processing platform that provides a unified, high-throughput, low-latency platform for handling real-time data feeds. In this case, the data consists of endorsed transactions and RW sets. The Kafka mechanism provides a crash fault-tolerant solution to ordering.
  • SBFT stands for Simplified Byzantine Fault Tolerance. This ordering mechanism is both crash fault-tolerant and byzantine fault-tolerant, meaning that it can reach agreement even in the presence of malicious or faulty nodes. The Hyperledger Fabric community has not yet implemented this mechanism, but it is on their roadmap.

These three ordering mechanisms provide alternate methodologies for agreeing on the order of transactions.

目前Fabric提供了三个排序算法实现：

1. Solo用于开发阶段的调试。
2. Kafka建议商用。
3. 其他如Raft,SFBT等实现仍在开发阶段。

Transaction Flow (Step 5)

The committing peer validates the transaction by checking to make sure that the RW sets still match the current world state. Specifically, that the Read data that existed when the endorsers simulated the transaction is identical to the current world state. When the committing peer validates the transaction, the transaction is written to the ledger, and the world state is updated with the Write data from the RW Set.

If the transaction fails, that is, if the committing peer finds that the RW set does not match the current world state, the transaction ordered into a block will still be included in that block, but it will be marked as invalid, and the world state will not be updated.

Committing peers are responsible for adding blocks of transactions to the shared ledger and updating the world state. They may hold smart contracts, but it is not a requirement.

提交节点在接收到排序节点排序完成的交易之后，通过验证RW Sets是否还满足当前的区块链账本的状态的方式来判断交易是否依旧合法。特别的，对于Read Data而言，需要判断背书节点进行模拟交易时的读取数据与当前区块链账本的数据是否完全一致。完成交易验证之后，提交节点将按照Write Data的内容对区块链账本进行更新。

如果验证交易失败，该交易仍旧会在区块中，但会被标记为非法状态并且整个的账本状态不会更新。

提交节点用于接收排序节点的输出，并将区块写入区块链账本，对校验失败的交易标志非法。提交节点可以持有智能合约但非必须。

Transaction Flow (Step 6)

Lastly, the committing peers asynchronously notify the client application of the success or failure of the transaction. Applications will be notified by each committing peer.

最后，各个提交节点异步的通知客户端应用，其提交的交易是否成功。

Identity Verification

In addition to the multitude of endorsement, validity, and versioning checks that take place, there are also ongoing identity verifications happening during each step of the transaction flow. Access control lists are implemented on the hierarchical layers of the network (from the ordering service down to channels), and payloads are repeatedly signed, verified, and authenticated as a transaction proposal passes through the different architectural components.

在整个交易流程中，除了上述操作，同时发生的还有身份鉴权及权限控制。访问控制列表是在网络结构的各层上实现的(从排序节点到通道)，其相关的开销（签名，验证，授权）同交易申请一起在交易流程中出现。

Transaction Flow Summary

It is important to note that the state of the network is maintained by peers, and not by the ordering service or the client. Normally, you will design your system such that different machines in the network play different roles. That is, machines that are part of the ordering service should not be set up to also endorse or commit transactions, and vice versa. However, there is an overlap between endorsing and committing peers on the system. Endorsing peers must have access to and hold smart contracts, in addition to fulfilling the role of a committing peer. Endorsing peers do commit blocks, but committing peers do not endorse transactions.

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 by the chaincode. The proposal response gets sent back to the client, along with an endorsement signature. These proposal responses are sent to the orderer to be ordered. The orderer then orders the transactions into a block, which it forwards to the endorsing and committing peers. The RW sets are used to verify that the transactions are still valid before the content of the ledger and world state is updated. Finally, the peers asynchronously notify the client application of the success or failure of the transaction.

整个的区块链网络是由提交节点提供支撑的。一般情况下，设计的区块链系统中，不同功能的节点会出现在不同的宿主机上。但提交节点和背书节点的功能会有重合，背书节点必须持有链码，但提交节点不一定。背书节点可以背书交易，但提交节点不可以。

背书节点需要验证客户端的签名，利用持有的链码逻辑来进行交易模拟。模拟的结果就是链码的执行结果。包括一个读的 K/V 列表以及一个写的 K/V 列表。背书节点将上述RW Sets以及背书节点自身的签名一起返回给客户端应用。客户端应用再将背书交易发送至排序节点。排序节点介绍全网的背书交易，并将其排序放入区块中，之后将区块发送给各个提交节点。最后，各个提交节点利用RW Sets验证交易，并执行写入区块链账本的操作。最后提交节点异步的通知客户端应用其发送的交易是否合法。

Channels

Channels allow organizations to utilize the same network, while maintaining separation between multiple blockchains. Only the members of the channel on which the transaction was performed can see the specifics of the transaction. In other words, channels partition the network in order to allow transaction visibility for stakeholders only. This mechanism works by delegating transactions to different ledgers. Only the members of the channel are involved in consensus, while other members of the network do not see the transactions on the channel.

The diagram above shows three distinct channels – blue, orange, and grey. Each channel has its own application, ledger, and peers.

Peers can belong to multiple networks or channels. Peers that do participate in multiple channels simulate and commit transactions to different ledgers. The ordering service is the same across any network or channel.

A few things to remember:

• • The network setup allows for the creation of channels.
  • The same chaincode logic can be applied to multiple channels.
  • A given user can participate in multiple channels.

通道技术允许不同的组织公用同一套区块链网络，却可以实现数据层面的相对独立。只有交易所在的通道的参与方才能够获取有关该通道的信息。通道的这种机制通过委托交易至不同的账本实现。只有通道的参与方才需要针对该交易达成共识，而非该通道的参与方则无法看见该交易。

上面的示意图所示，蓝色橘色和灰色代表不同的通道，不同的通道包含不同的客户端应用，账本和节点。

节点可以同时属于多个通道。节点对来自不同通道的业务执行模拟交易，背书，提交交易到不同账本的功能。但排序节点是所有通道公用的。

注意：

1. 区块链网络通信允许创建通道。
2. 同样的链码可以部署给不同的通道。
3. 一个确定的用户可以参与到多个不同的通道中。

State Database

The current state data represents the latest values for all assets in the ledger. Since the current state represents all the committed transactions on 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 key/value pairs for each asset are stored in a state database. The state database is simply an indexed view into the chain’s committed transactions. 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 new transactions are accepted. The default state database, LevelDB, can be replaced with CouchDB.

• • LevelDB is the default key/value state database for Hyperledger Fabric, and simply stores key/value pairs.
  • CouchDB is an alternative to LevelDB. Unlike LevelDB, CouchDB stores JSON objects. CouchDB is unique in that it supports keyed, composite, key range, and full data-rich queries.

Hyperledger Fabric’s LevelDB and CouchDB are very similar in their structure and function. Both LevelDB and CouchDB support core chaincode operations, such as getting and setting key assets, and querying based on these keys. With both, keys can be queried by range, and composite keys can be modeled to enable equivalence queries against multiple parameters. But, as a JSON document store, CouchDB additionally enables rich query against the chaincode data, when chaincode values (e.g. assets) are modeled as JSON data.

区块链当前的数据状态代表了当前时刻分布式账本上记录的所有资产的状态信息。因此当前的数据状态代表了在通道上所有已经被提交的交易，有时会把这个状态称为世界观。

链码对当前状态数据通过调用执行交易的方式进行通信。为了使这些链码的交互非常高效，每个资产的最新密钥/值对存储在一个状态数据库中。状态数据库只是对区块链的提交事务的索引视图。因此，它可以在任何时候从链中重新生成，在新事务被接受之前，状态数据库将自动恢复(或生成，如果需要的话)。默认的状态数据库是 LevelDB，可以用CouchDB来替换。

LevelDB 是一个简单的存储K/V的数据库

CouchDB则存储json对象

两个数据库都支持通过核心链码 API来操作。

Smart Contracts

As a reminder, smart contracts are computer programs that contain logic to execute transactions and modify the state of the assets stored within the ledger. Hyperledger Fabric smart contracts are called chaincode and are written in Go. The chaincode serves as the business logic for a Hyperledger Fabric network, in that the chaincode directs how you manipulate assets within the network. We will discuss more about chaincode in the Understanding Chaincode section.

智能合约是包含执行交易，修改分布式账本中资产状态的代码逻辑, 在超级账本中被称为链码。链码用GO语言编写。在Fabric中，链码用于实现具体的业务逻辑，包括如何在区块链网络中处置你的资产。

Membership Service Provider (MSP)

The membership service provider, or MSP, is a component that defines the rules in which identities are validated, authenticated, and allowed access to a network. The MSP manages user IDs and authenticates clients who want to join the network. This includes providing credentials for these clients to propose transactions. The MSP makes use of a Certificate Authority, which is a pluggable interface that verifies and revokes user certificates upon confirmed identity. The default interface used for the MSP is the Fabric-CA API, however, organizations can implement an External Certificate Authority of their choice. This is another feature of Hyperledger Fabric that is modular. Hyperledger Fabric supports many credential architectures, which allows for many types of External Certificate Authority interfaces to be used. As a result, a single Hyperledger Fabric network can be controlled by multiple MSPs, where each organization brings their favorite.

MSP用于超级账本的成员管理，其管理着联盟链的准入权，以及所有已经加入联盟链的所有用户的id。 默认基于CA为加入的用户颁发/取消授权，默认的接口为Fabric-CA API。但开发者可以根据自己的需求选则其他方案作为CA模块。

What Does the MSP Do?

To start, users are authenticated using a certificate authority. The certificate authority identifies the application, peer, endorser, and orderer identities, and verifies these credentials. A signature is generated through the use of a Signing Algorithm and a Signature Verification Algorithm.

Specifically, generating a signature starts with a Signing Algorithm, which utilizes the credentials of the entities associated with their respective identities, and outputs an endorsement. A signature is generated, which is a byte array that is bound to a specific identity. Next, the Signature Verification Algorithm takes the identity, endorsement, and signature as inputs, and outputs ‘accept’ if the signature byte array corresponds with a valid signature for the inputted endorsement, or outputs ‘reject’ if not. If the output is ‘accept’, the user can see the transactions in the network and perform transactions with other actors in the network. If the output is ‘reject’, the user has not been properly authenticated, and is not able to submit transactions to the network, or view any previous transactions.

CA鉴权用于节点，背书，排序和验证的各个环节。主要包含“签名算法“和”验签算法“两个。

具体地说，生成签名首先使用一个签名算法，该算法利用签名者的数字身份对一段信息进行签名，并输出一个背书。生成签名，表面是绑定到特定标识的字节数组。接下来，签名验证算法将身份、背书和签名作为输入，如果签名字节数组对应于输入的背书的有效签名则输出“通过”，反之输出“拒绝”，。如果输出是“通过”，则用户可以看到网络中的交易，并与网络中的其他参与者执行交易。如果输出是“拒绝”，则用户没有经过正确的身份验证，不能向网络提交交易，也不能查看任何以前的交易。