Hyperledger Fabric 官网翻译架构篇--之系统架构说明

Architecture Explained/架构说明

The Hyperledger Fabric architecture delivers the following advantages:

Hyperledger Fabric架构具有以下优势：

• Chaincode trust flexibility. The architecture separates trust assumptions for chaincodes (blockchain applications) from trust assumptions for ordering. In other words, the ordering service may be provided by one set of nodes (orderers) and tolerate some of them to fail or misbehave, and the endorsers may be different for each chaincode.

Chaincode信任灵活性。该体系结构将chaincodes（区块链应用程序）的信任假设与用于排序的信任假设分开。换句话说，ordering服务可以由一组节点（orderers）提供并且容忍它们中的一些失败或行为不当，并且对于每个chaincode，endorsers可以是不同的。

• Scalability. As the endorser nodes responsible for particular chaincode are orthogonal to the orderers, the system may scale better than if these functions were done by the same nodes. In particular, this results when different chaincodes specify disjoint endorsers, which introduces a partitioning of chaincodes between endorsers and allows parallel chaincode execution (endorsement). Besides, chaincode execution, which can potentially be costly, is removed from the critical path of the ordering service.

可扩展性。由于负责特定链码的endorser节点与orderers是正交的，因此系统可能比这些功能（排序 和 认可）由相同节点完成的情况更好地扩展。特别是，当不同的链码指定不相交的endorsers时，会产生这种情况，这会在endorsers之间引入链码的分区，并允许并行链码执行（认可）。此外，从ordering服务的关键路径中移除可能成本高昂的链码执行。

• Confidentiality. The architecture facilitates deployment of chaincodes that have confidentiality requirements with respect to the content and state updates of its transactions.

机密性。该体系结构有助于部署对其交易的内容和状态更新具有机密性要求的链码。

• Consensus modularity. The architecture is modular and allows pluggable consensus (i.e., ordering service) implementations.

共识模块化。该架构是模块化的，并且允许可插入的共识（即，ordering服务）实现。

Part I: Elements of the architecture relevant to Hyperledger Fabric v1

第一部分：与Hyperledger Fabric v1相关的架构元素

1. System architecture/系统架构

2. Basic workflow of transaction endorsement/交易认可的基本工作流程

3. Endorsement policies/背书(endorsement)策略

Part II: Post-v1 elements of the architecture

第二部分：体系结构的后v1元素

1. Ledger checkpointing (pruning)

1. System architecture/系统架构

The blockchain is a distributed system consisting of many nodes that communicate with each other. The blockchain runs programs called chaincode, holds state and ledger data, and executes transactions. The chaincode is the central element as transactions are operations invoked on the chaincode. Transactions have to be “endorsed” and only endorsed transactions may be committed and have an effect on the state. There may exist one or more special chaincodes for management functions and parameters, collectively called system chaincodes.

区块链是一个分布式系统，由许多相互通信的节点组成。 区块链运行称为链码的程序，保存状态和总账数据，并执行交易。 链码是核心元素，因为交易是在链码上调用的操作。 交易必须得到“认可”，并且只有经过认可的交易可能会被承认并对总账状态产生影响。 可能存在用于管理功能和参数的一个或多个特殊链码，统称为系统链码。

1.1. Transactions/交易

Transactions may be of two types:

交易可以有两种类型：

• Deploy transactions create new chaincode and take a program as parameter. When a deploy transaction executes successfully, the chaincode has been installed “on” the blockchain.

部署交易创建新的链码并将一个程序作为参数。当成功执行一个部署交易时，链码已安装在区块链“上”。

• Invoke transactions perform an operation in the context of previously deployed chaincode. An invoke transaction refers to a chaincode and to one of its provided functions. When successful, the chaincode executes the specified function - which may involve modifying the corresponding state, and returning an output.

调用交易在先前部署的链码的上下文中执行操作。调用交易引用链码及其提供的若干功能之一。成功时，链码执行指定的功能 – 功能可能涉及修改相应的状态，并返回输出。

 

As described later, deploy transactions are special cases of invoke transactions, where a deploy transaction that creates new chaincode, corresponds to an invoke transaction on a system chaincode.

如稍后所述，部署交易是调用交易的特殊情况，其中创建新链码的部署交易对应于系统链码上的调用交易。

Remark: This document currently assumes that a transaction either creates new chaincode or invokes an operation provided by *one already deployed chaincode. This document does not yet describe: a) optimizations for query (read-only) transactions (included in v1), b) support for cross-chaincode transactions (post-v1 feature).*

备注：本文档目前假定交易要么创建新的链码，要么调用*已经部署的链码提供的操作。本文档尚未描述：a）优化查询（只读）交易（包含在v1中），b）支持交叉链码交易（v1后功能）。*

 

1.2. Blockchain datastructures/ 区块链数据结构

1.2.1. State/状态

The latest state of the blockchain (or, simply, state) is modeled as a versioned key-value store (KVS), where keys are names and values are arbitrary blobs. These entries are manipulated by the chaincodes (applications) running on the blockchain through put and get KVS-operations. The state is stored persistently and updates to the state are logged. Notice that versioned KVS is adopted as state model, an implementation may use actual KVSs, but also RDBMSs or any other solution.

区块链的最新状态（或简称为状态）被建模为版本化键值存储（KVS），其中键是名称，值是任意blobs。这些条目由区块链上运行的链代码（应用程序）通过put和get KVS操作来操纵。持久存储状态和更新状态是记录的。请注意，采用版本化的KVS作为状态模型，实现可以使用实际的KVSs，但也可以使用RDBMS或任何其他解决方案。

 

More formally, state s is modeled as an element of a mapping K -> (V X N), where:

更正式地说，状态s被建模为映射K - >（V X N）的元素，其中：

• K is a set of keys / K是一组键

• V is a set of values / V是一组值

• N is an infinite ordered set of version numbers. Injective function next: N -> N takes an element of N and returns the next version number.

N是无限有序的版本号集。内射函数next：N - > N 取N中的一个元素并返回下一个版本号。

 

Both V and N contain a special element ⊥ (empty type), which is in case of N the lowest element. Initially all keys are mapped to (⊥, ⊥). For s(k)=(v,ver) we denote v by s(k).value, and ver by s(k).version.

V和N都包含一个特殊元素⊥（空类型），在N的情况下是最低元素。最初所有键都映射到（⊥，⊥）。对于s（k）=（v，ver），我们用s（k）.value表示v，用s（k）.version表示ver。

KVS operations are modeled as follows:

KVS操作建模如下：

• put(k,v) for k ∈ K and v ∈ V, takes the blockchain state s and changes it to s' such that s'(k)=(v,next(s(k).version)) with s'(k')=s(k') for all k'!=k.

• get(k) returns s(k).

State is maintained by peers, but not by orderers and clients.

State由peers维护，但不是由orderers 和客户维护。

State partitioning. Keys in the KVS can be recognized from their name to belong to a particular chaincode, in the sense that only transaction of a certain chaincode may modify the keys belonging to this chaincode. In principle, any chaincode can read the keys belonging to other chaincodes. Support for cross-chaincode transactions, that modify the state belonging to two or more chaincodes is a post-v1 feature.

状态分区。 KVS中的键可以从其名称中识别为属于特定的链码，在某种意义上，只有某个链码的交易可以修改属于该链码的键。原则上，任何链码都可以读取属于其他链码的键。支持跨链码交易，修改属于两个或多个链码的状态是后v1功能。

1.2.2 Ledger/总账

Ledger provides a verifiable history of all successful state changes (we talk about valid transactions) and unsuccessful attempts to change state (we talk about invalid transactions), occurring during the operation of the system.

Ledger提供了在系统运行期间发生的所有成功状态更改（我们讨论有效交易）和不成功尝试更改状态（我们谈论无效交易）的可验证历史记录。

Ledger is constructed by the ordering service (see Sec 1.3.3) as a totally ordered hashchain of blocks of (valid or invalid) transactions. The hashchain imposes the total order of blocks in a ledger and each block contains an array of totally ordered transactions. This imposes total order across all transactions.

Ledger由ordering 服务构建（参见第1.3.3节），作为（有效或无效）交易块的完全有序的哈希链。 哈希链强制总账中块的总序，每个块包含一组完全有序的交易。这会强制所有交易完全有序。

Ledger is kept at all peers and, optionally, at a subset of orderers. In the context of an orderer we refer to the Ledger as to OrdererLedger, whereas in the context of a peer we refer to the ledger as to PeerLedger. PeerLedger differs from the OrdererLedger in that peers locally maintain a bitmask that tells apart valid transactions from invalid ones (see Section XX for more details).

Ledger保留在所有peers，并且可选地保留在orderers的子集中。在orderer的上下文中，我们将Ledger称为OrdererLedger，而在peer的上下文中，我们将总账称为PeerLedger。PeerLedger与同在该peer中的OrdererLedger的不同之处在于，peers在本地维护一个bitmask – 其将有效交易与无效交易分开（有关更多详细信息，请参见第XX节）。
 

Peers may prune PeerLedger as described in Section XX (post-v1 feature). Orderers maintain OrdererLedger for fault-tolerance and availability (of the PeerLedger) and may decide to prune it at anytime, provided that properties of the ordering service (see Sec. 1.3.3) are maintained.

如第XX节（v1后的功能）中所述，peers可以修剪PeerLedger。 Orderers维护OrdererLedger的容错性和可用性（PeerLedger），并且可以决定在任何时候修剪它，前提是维护ordering 服务的属性（参见第1.3.3节）。
 

The ledger allows peers to replay the history of all transactions and to reconstruct the state. Therefore, state as described in Sec 1.2.1 is an optional datastructure.

总账允许peers重放所有交易的历史记录并重建状态。因此，第1.2.1节中描述的状态是可选的数据结构。

 

1.3. Nodes/节点

Nodes are the communication entities of the blockchain. A “node” is only a logical function in the sense that multiple nodes of different types can run on the same physical server. What counts is how nodes are grouped in “trust domains” and associated to logical entities that control them.

节点是区块链的通信实体。 “节点”在某种意义上只是一个逻辑功能，即不同类型的多个节点可以在同一物理服务器上运行。重要的是节点如何在“信任域”中分组并与控制它们的逻辑实体相关联。
 

There are three types of nodes:

有三种类型的节点：

1.Client or submitting-client: a client that submits an actual transaction-invocation to the endorsers, and broadcasts transaction-proposals to the ordering service.

客户端或提交客户端：一个客户端，向endorsers 提交实际交易调用，并将交易提议广播到ordering 服务。
 

2.Peer: a node that commits transactions and maintains the state and a copy of the ledger (see Sec, 1.2). Besides, peers can have a special endorser role.

Peer：一个节点，提交交易并维护状态和总账的副本（参见Sec，1.2）。此外，peers可以拥有特殊的endorser 角色。

3.Ordering-service-node or orderer: a node running the communication service that implements a delivery guarantee, such as atomic or total order broadcast.

Ordering-service-node or orderer：运行通信服务的节点，实现交付保证，例如原子的或总序广播。

The types of nodes are explained next in more detail.

接下来更详细地解释节点的类型。

1.3.1. Client/客户端

The client represents the entity that acts on behalf of an end-user. It must connect to a peer for communicating with the blockchain. The client may connect to any peer of its choice. Clients create and thereby invoke transactions.

客户端代表代表最终用户的实体。它必须连接到一个peer以与区块链通信。客户端可以连接到其选择的任何peer。客户端创建并从而调用交易。
 

As detailed in Section 2, clients communicate with both peers and the ordering service.

如第2节所述，客户端与peers和ordering 服务进行通信。

1.3.2. Peer

A peer receives ordered state updates in the form of blocks from the ordering service and maintain the state and the ledger.

peer从ordering 服务接收块形式的有序状态更新，并维护状态和总账。

Peers can additionally take up a special role of an endorsing peer, or an endorser. The special function of an endorsing peer occurs with respect to a particular chaincode and consists in endorsing a transaction before it is committed. Every chaincode may specify an endorsement policy that may refer to a set of endorsing peers. The policy defines the necessary and sufficient conditions for a valid transaction endorsement (typically a set of endorsers’ signatures), as described later in Sections 2 and 3. In the special case of deploy transactions that install new chaincode the (deployment) endorsement policy is specified as an endorsement policy of the system chaincode.

Peers还可以扮演endorsing peer 或endorser的特殊角色。 endorsing peer的特殊功能针对特定的链码发生，并且包括在一个交易提交之前认可该交易。每个链码可以指定一 个endorsement policy – 可能引用到一组 endorsing peers。该策略定义了有效交易认可的必要和充分条件（通常是一组endorsers 的签名），如后面第2节和第3节所述。在安装新链码的部署交易的特殊情况下，（部署）背书(endorsement)策略是指定为系统链码的背书(endorsement)策略。

1.3.3. Ordering service nodes (Orderers)

The orderers form the ordering service, i.e., a communication fabric that provides delivery guarantees. The ordering service can be implemented in different ways: ranging from a centralized service (used e.g., in development and testing) to distributed protocols that target different network and node fault models.

orderers 形成ordering 服务，即提供递送保证的通信结构。ordering 服务可以以不同的方式实现：从集中式服务（例如，在开发和测试中使用）到针对不同网络和节点故障模型的分布式协议。

Ordering service provides a shared communication channel to clients and peers, offering a broadcast service for messages containing transactions. Clients connect to the channel and may broadcast messages on the channel which are then delivered to all peers. The channel supports atomic delivery of all messages, that is, message communication with total-order delivery and (implementation specific) reliability. In other words, the channel outputs the same messages to all connected peers and outputs them to all peers in the same logical order. This atomic communication guarantee is also called total-order broadcast, atomic broadcast, or consensus in the context of distributed systems. The communicated messages are the candidate transactions for inclusion in the blockchain state.

Ordering服务为客户端和peers提供共享通信管道(channel)，为包含交易的消息提供广播服务。客户端连接到管道(channel)并且可以在管道(channel)上广播消息，然后将消息传递给所有peers。该管道(channel)支持所有消息的原子传递，即具有全序(total-order)传递和（特定于实现）可靠性的消息通信。换句话说，管道(channel)向所有连接的peers输出相同的消息，并以相同的逻辑顺序将它们输出到所有peers。这种原子通信保证在分布式系统的上下文中也称为全序(total-order)广播，原子广播或共识。传递的消息是包含在区块链状态中的候选交易。

Partitioning (ordering service channels). Ordering service may support multiple channels similar to the topics of a publish/subscribe (pub/sub) messaging system. Clients can connect to a given channel and can then send messages and obtain the messages that arrive. Channels can be thought of as partitions - clients connecting to one channel are unaware of the existence of other channels, but clients may connect to multiple channels. Even though some ordering service implementations included with Hyperledger Fabric support multiple channels, for simplicity of presentation, in the rest of this document, we assume ordering service consists of a single channel/topic.

分区（ordering 服务管道）。Ordering服务可以支持类似于发布/订阅（发布/订阅）消息传送系统的主题的多个管道。客户端可以连接到给定的管道，然后可以发送消息并获取到达的消息。可以将管道视为分区 - 连接到一个管道的客户端不知道其他管道的存在，但客户端可能连接到多个管道。尽管Hyperledger Fabric中包含的某些ordering服务实现支持多个管道，但为了简化演示，在本文档的其余部分中，我们假设ordering服务由单个管道/主题组成。

Ordering service API. Peers connect to the channel provided by the ordering service, via the interface provided by the ordering service. The ordering service API consists of two basic operations (more generally asynchronous events):

Ordering服务API。Peers通过ordering服务提供的接口连接到ordering服务提供的管道。ordering服务API包含两个基本操作（更常见的是异步事件）：

TODO add the part of the API for fetching particular blocks under client/peer specified sequence numbers.

TODO添加API的一部分，用于在客户端/peer指定的序列号下获取特定块。
 

• broadcast(blob): a client calls this to broadcast an arbitrary message blob for dissemination over the channel. This is also called request(blob) in the BFT context, when sending a request to a service.

broadcast（blob）：客户端调用它来广播任意消息blob，以便通过该管道进行传播。当向服务发送请求时，这在BFT上下文中也称为request（blob）。

• deliver(seqno, prevhash, blob): the ordering service calls this on the peer to deliver the message blob with the specified non-negative integer sequence number (seqno) and hash of the most recently delivered blob (prevhash). In other words, it is an output event from the ordering service. deliver() is also sometimes called notify() in pub-sub systems or commit() in BFT systems.

deliver（seqno，prevhash，blob）：ordering服务在peer上调用它来传递具有指定的非负整数序列号（seqno）和最近交付的blob（prevhash）的散列的消息blob。换句话说，它是来自ordering服务的输出事件。 deliver（）有时在pub-sub系统中称为notify（），或在BFT系统中称为commit（）。

Ledger and block formation. The ledger (see also Sec. 1.2.2) contains all data output by the ordering service. In a nutshell, it is a sequence of deliver(seqno, prevhash, blob) events, which form a hash chain according to the computation of prevhash described before.

总账和块形成。总账（另见第1.2.2节）包含ordering服务输出的所有数据。简而言之，它是一系列deliver（seqno，prevhash，blob）事件，根据前面描述的prevhash的计算形成哈希链。

Most of the time, for efficiency reasons, instead of outputting individual transactions (blobs), the ordering service will group (batch) the blobs and output blocks within a single deliver event. In this case, the ordering service must impose and convey a deterministic ordering of the blobs within each block. The number of blobs in a block may be chosen dynamically by an ordering service implementation.

大多数情况下，出于效率原因，ordering服务不是输出单个交易（blob），而是在单个deliver 事件中对blob和输出块进行分组（批处理）。在这种情况下，ordering服务必须强制并传达每个块内blob的确定性排序。可以通过ordering服务实现来动态地选择块中的blob的数量。
 

In the following, for ease of presentation, we define ordering service properties (rest of this subsection) and explain the workflow of transaction endorsement (Section 2) assuming one blob per deliver event. These are easily extended to blocks, assuming that a deliver event for a block corresponds to a sequence of individual deliver events for each blob within a block, according to the above mentioned deterministic ordering of blobs within a block.

在下文中，为了便于呈现，我们定义了ordering服务属性（本小节的其余部分）并解释了交易认可的工作流程（第2节），假设每个deliver 事件有一个blob。根据上面提到的块内blob的确定性排序，假设块的deliver 事件对应于块内每个blob的一系列单独deliver 事件，这些很容易扩展到块。

Ordering service properties/Ordering服务属性

The guarantees of the ordering service (or atomic-broadcast channel) stipulate what happens to a broadcasted message and what relations exist among delivered messages. These guarantees are as follows:
ordering服务（或原子广播管道）的保证规定了广播消息发生了什么以及所传递的消息之间存在什么关系。这些保证如下：

1.Safety (consistency guarantees): As long as peers are connected for sufficiently long periods of time to the channel (they can disconnect or crash, but will restart and reconnect), they will see an identical series of delivered (seqno, prevhash, blob) messages. This means the outputs (deliver() events) occur in the same order on all peers and according to sequence number and carry identical content (blob and prevhash) for the same sequence number. Note this is only a logical order, and a deliver(seqno, prevhash, blob) on one peer is not required to occur in any real-time relation to deliver(seqno, prevhash, blob) that outputs the same message at another peer. Put differently, given a particular seqno, no two correct peers deliver different prevhash or blob values. Moreover, no value blob is delivered unless some client (peer) actually called broadcast(blob) and, preferably, every broadcasted blob is only delivered once.

安全性（一致性保证）：只要peers连接到管道足够长的时间（它们可以断开连接或崩溃，但将重新启动并重新连接），它们将看到相同的deliver 系列（seqno，prevhash，blob）消息。这意味着输出（deliver（）事件）在所有peers上以相同的顺序发生并且根据序列号,对于相同的序列号携带相同的内容（blob和prevhash）。请注意，这只是一个逻辑顺序，并且在一个peer上的传递（seqno，prevhash，blob）并不需要实时的在另一个peer上发生一个相关的输出相同消息的传递（seqno，prevhash，blob）。换句话说，给定一个特定的seqno，没有两个正确的peers提供不同的prevhash或blob值。此外，除非某些客户端（peer）实际上调用广播（blob），并且优选地，每个广播的blob仅被传送一次，否则不传递值blob。

Furthermore, the deliver() event contains the cryptographic hash of the data in the previous deliver() event (prevhash). When the ordering service implements atomic broadcast guarantees, prevhash is the cryptographic hash of the parameters from the deliver() event with sequence number seqno-1. This establishes a hash chain across deliver() events, which is used to help verify the integrity of the ordering service output, as discussed in Sections 4 and 5 later. In the special case of the first deliver() event, prevhash has a default value.

此外，deliver（）事件包含先前deliver（）事件（prevhash）中数据的加密哈希。当ordering 服务实现原子广播保证时，prevhash是来自deliver（）事件的参数的加密哈希，序列号为seqno-1。这将在deliver（）事件之间建立一个哈希链，用于帮助验证ordering 服务输出的完整性，如第4节和第5节中所述。在第一个deliver（）事件的特殊情况下，prevhash具有默认值。

2.Liveness (delivery guarantee): Liveness guarantees of the ordering service are specified by a ordering service implementation. The exact guarantees may depend on the network and node fault model.

活动（交付保证）：ordering 服务的活动保证由ordering 服务实施指定。确切的保证可能取决于网络和节点故障模型。

In principle, if the submitting client does not fail, the ordering service should guarantee that every correct peer that connects to the ordering service eventually delivers every submitted transaction.

原则上，如果提交客户端没有失败，则ordering 服务应该保证连接到ordering 服务的每个正确的peers最终提供每个提交的交易。

To summarize, the ordering service ensures the following properties:

总而言之，排序服务可确保以下属性：

• Agreement. For any two events at correct peers deliver(seqno, prevhash0, blob0) and deliver(seqno, prevhash1, blob1) with the same seqno, prevhash0==prevhash1 and blob0==blob1;

协议。对于正确的peers上的任何两个事件 deliver（seqno，prevhash0，blob0）和deliver（seqno，prevhash1，blob1）具有相同的seqno，prevhash0 == prevhash1和blob0 == blob1;

• Hashchain integrity. For any two events at correct peers deliver(seqno-1, prevhash0, blob0) and deliver(seqno, prevhash, blob), prevhash = HASH(seqno-1||prevhash0||blob0).

Hashchain完整性。对于正确的peers上的任何两个事件 deliver（seqno-1，prevhash0，blob0）和deliver（seqno，prevhash，blob），prevhash = HASH（seqno-1 || prevhash0 || blob0）。

• No skipping. If an ordering service outputs deliver(seqno, prevhash, blob) at a correct peer p, such that seqno>0, then p already delivered an event deliver(seqno-1, prevhash0, blob0).

没有跳过。如果ordering 服务在正确的peer p处输出deliver（seqno，prevhash，blob），使得seqno> 0，则p已经传递了事件deliver（seqno-1，prevhash0，blob0）。

• No creation. Any event deliver(seqno, prevhash, blob) at a correct peer must be preceded by a broadcast(blob) event at some (possibly distinct) peer;

没有创造。在正确的peer上任何事件 deliver（seqno，prevhash，blob）必须先于某个peer（可能是不同的）上的broadcast（blob）事件;

• No duplication (optional, yet desirable). For any two events broadcast(blob) and broadcast(blob'), when two events deliver(seqno0, prevhash0, blob) and deliver(seqno1, prevhash1, blob') occur at correct peers and blob == blob', then seqno0==seqno1 and prevhash0==prevhash1.

没有重复（可选，但仍然可取）。对于任何两个事件broadcast（blob）和broadcast（blob'），当两个事件deliver（seqno0，prevhash0，blob）和deliver（seqno1，prevhash1，blob'）发生在正确的peers点并且blob == blob'时，则seqno0 = = seqno1和prevhash0 == prevhash1。

• Liveness. If a correct client invokes an event broadcast(blob) then every correct peer “eventually” issues an event deliver(*, *, blob), where * denotes an arbitrary value.
  活跃度。如果正确的客户端调用事件broadcast（blob），则每个正确的peer“最终”发出事件deliver（*，*，blob），其中*表示任意值。
  
  Hyperledger Fabric 官网翻译入门教程目录