Hyperledger Fabric 官网翻译架构篇--之交易认可的基本工作流程

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

In the following we outline the high-level request flow for a transaction.

在下文中，我们概述了交易的高级请求流程。

Remark: Notice that the following protocol *does not assume that all transactions are deterministic, i.e., it allows for non-deterministic transactions.*

注：请注意，以下协议*并未假定所有交易都是确定性的，比如，即它允许非确定性交易。*

2.1. The client creates a transaction and sends it to endorsing peers of its choice/ 客户端创建一个交易并将其发送给自己选择的背书(endorsing) peers

To invoke a transaction, the client sends a PROPOSE message to a set of endorsing peers of its choice (possibly not at the same time - see Sections 2.1.2. and 2.3.). The set of endorsing peers for a given chaincodeID is made available to client via peer, which in turn knows the set of endorsing peers from endorsement policy (see Section 3). For example, the transaction could be sent to all endorsers of a given chaincodeID. That said, some endorsers could be offline, others may object and choose not to endorse the transaction. The submitting client tries to satisfy the policy expression with the endorsers available.

为了调用交易，客户端向其选择的一组背书(endorsing) peers发送PROPOSE消息（可能不同时 - 参见2.1.2。和2.3节）。给定chaincodeID的一组背书(endorsing) peers通过peer提供给客户端，而peer又从背书(endorsement)策略中了解背书(endorsing) peers的集合（参见第3节）。例如，可以将交易发送给指定chaincodeID的所有endorsers 。也就是说，一些endorsers 可能会脱机，其他endorsers 可能会反对并选择不支持交易。提交客户端尝试使用可用的endorsers 来满足策略表达式。

In the following, we first detail PROPOSE message format and then discuss possible patterns of interaction between submitting client and endorsers.

在下文中，我们首先详细介绍PROPOSE消息格式，然后讨论提交客户端和endorsers 之间可能的交互模式。

2.1.1. `PROPOSE` message format/PROPOSE 消息格式

The format of a PROPOSE message is <PROPOSE,tx,[anchor]>, where tx is a mandatory and anchor optional argument explained in the following.

PROPOSE消息的格式是<PROPOSE，tx，[anchor]>，其中tx是必需的，并且anchor 可选参数在下面说明。

tx=<clientID,chaincodeID,txPayload,timestamp,clientSig>, where

tx = <clientID，chaincodeID，txPayload，timestamp，clientSig>，其中

- clientID is an ID of the submitting client,

clientID是提交客户端的ID，

- chaincodeID refers to the chaincode to which the transaction pertains,

chaincodeID引用交易所属的链码，

- txPayload is the payload containing the submitted transaction itself,

txPayload是提交的交易本身的有效负载，

- timestamp is a monotonically increasing (for every new transaction) integer maintained by the client,

timestamp是由客户端维护的单调递增（对于每个新交易）整数，

- clientSig is signature of a client on other fields of tx.
  clientSig是tx在其他字段上的客户端的签名。

The details of txPayload will differ between invoke transactions and deploy transactions (i.e., invoke transactions referring to a deploy-specific system chaincode). For an invoke transaction, txPayload would consist of two fields

txPayload的细节在调用交易和部署交易之间会有所不同（即，调用交易引用一个特定于部署的系统链码）。对于调用交易，txPayload将包含两个字段

- txPayload = <operation, metadata>, where

txPayload = <操作，元数据>，其中

- - operation denotes the chaincode operation (function) and arguments,

operation表示链代码操作（函数）和参数，

- - metadata denotes attributes related to the invocation.

元数据表示与调用相关的属性。

For a deploy transaction, txPayload would consist of three fields

对于部署交易，txPayload将包含三个字段

- txPayload = <source, metadata, policies>, where
  - source denotes the source code of the chaincode,

source表示链码的源代码，

- - metadata denotes attributes related to the chaincode and application,

metadata（元数据）表示与链码和应用程相关的属性，

- - policies contains policies related to the chaincode that are accessible to all peers, such as the endorsement policy. Note that endorsement policies are not supplied with txPayload in a deploy transaction, but txPayload of a deploy contains endorsement policy ID and its parameters (see Section 3).

policies（策略)包含与所有peers都可访问的链码相关的策略，例如背书(endorsement)策略。请注意，部署交易中的txPayload不提供背书(endorsement)策略，但部署的txPayload包含背书(endorsement)策略ID及其参数（请参阅第3节）。

anchor contains read version dependencies, or more specifically, key-version pairs (i.e., anchor is a subset of KxN), that binds or “anchors” the PROPOSE request to specified versions of keys in a KVS (see Section 1.2.). If the client specifies the anchor argument, an endorser endorses a transaction only upon read version numbers of corresponding keys in its local KVS match anchor (see Section 2.2. for more details).

anchor包含读版本依赖性，或者更具体地说，key-version pairs（即，anchor是KxN的子集），它将PROPOSE请求绑定或“锚定”到KVS中的指定版本的键（参见第1.2节）。如果客户端指定了anchor 参数，只有当读取其本地KVS中对应键的读版本号匹配anchor时，endorser才认可该交易。（有关详细信息，请参见第2.2节）。

Cryptographic hash of tx is used by all nodes as a unique transaction identifier tid (i.e., tid=HASH(tx)). The client stores tid in memory and waits for responses from endorsing peers.

所有节点使用tx的密码散列作为唯一交易标识符tid（即，tid = HASH（tx））。客户端将tid存储在内存中并等待来自endorsing peers的响应。

2.1.2. Message patterns/消息模式

The client decides on the sequence of interaction with endorsers. For example, a client would typically send <PROPOSE, tx> (i.e., without the anchor argument) to a single endorser, which would then produce the version dependencies (anchor) which the client can later on use as an argument of its PROPOSE message to other endorsers. As another example, the client could directly send <PROPOSE, tx> (without anchor) to all endorsers of its choice. Different patterns of communication are possible and client is free to decide on those (see also Section 2.3.).

客户端决定与endorsers 的互动顺序。例如，客户端通常会将<PROPOSE，tx>（即没有anchor参数）发送给单个endorser，然后生成版本依赖项（anchor），客户端稍后可以将其用作其PROPOSE消息的参数对其他endorsers。作为另一个例子，客户端可以直接向其选择的所有endorsers 发送<PROPOSE，tx>（无anchor）。不同的通信模式是可能的，客户可以自由决定（参见第2.3节）。

2.2. The endorsing peer simulates a transaction and produces an endorsement signature/背书(endorsing) peer 模拟交易并产生认可签名

On reception of a <PROPOSE,tx,[anchor]> message from a client, the endorsing peer epID first verifies the client’s signature clientSig and then simulates a transaction. If the client specifies anchor then endorsing peer simulates the transactions only upon read version numbers (i.e., readset as defined below) of corresponding keys in its local KVS match those version numbers specified by anchor.

在从客户端接收到<PROPOSE，tx，[anchor]>消息时，背书(endorsing) peer epID首先验证客户端的签名clientSig，然后模拟交易。如果客户端指定anchor，那么仅当读取的本地KVS中的相应键的读版本号（即，如下定义的readset）匹配由anchor指定的那些版本号时，背书(endorsing) peer才模拟交易。

Simulating a transaction involves endorsing peer tentatively executing a transaction (txPayload), by invoking the chaincode to which the transaction refers (chaincodeID) and the copy of the state that the endorsing peer locally holds.

模拟交易涉及背书(endorsing) peer 实验性的执行一个交易（txPayload), 其通过调用交易引用的链码（chaincodeID）和背书(endorsing) peer本地保存的状态的副本来实现。

As a result of the execution, the endorsing peer computes read version dependencies (readset) and state updates (writeset), also called MVCC+postimage info in DB language.

作为执行的结果，背书(endorsing) peer计算读取版本依赖性（readset）和状态更新（writeset），在DB语言中也称为MVCC + postimage info。

Recall that the state consists of key-value pairs. All key-value entries are versioned; that is, every entry contains ordered version information, which is incremented each time the value stored under a key is updated. The peer that interprets the transaction records all key-value pairs accessed by the chaincode, either for reading or for writing, but the peer does not yet update its state. More specifically:

回想一下，状态由键值对组成。所有键值条目都是版本化的;也就是说，每个条目都包含有序版本信息，每次更新存储在键下的值时，该信息都会递增。解释交易的peer记录链码访问的所有键值对，用于读取或写入，但peer尚未更新其状态。进一步来说：

Given state s before an endorsing peer executes a transaction, for every key k read by the transaction, pair (k,s(k).version) is added to readset.

在背书(endorsing) peer执行交易之前给定状态s，对于交易所读取的每个键k，将pair（k，s（k）.version）添加到readset。

Additionally, for every key k modified by the transaction to the new value v', pair (k,v') is added to writeset. Alternatively, v' could be the delta of the new value to previous value (s(k).value).
另外，对于由交易修改为新值v'的每个键k，将pair（k，v'）添加到writeset。或者，v'可以是新值到先前值（s（k）.value）的增量。

If a client specifies anchor in the PROPOSE message then client specified anchor must equal readset produced by endorsing peer when simulating the transaction.

如果客户端在PROPOSE消息中指定了anchor，则客户端指定的anchor必须等于在模拟交易时通过背书(endorsing) peer生成的readset。

Then, the peer forwards internally tran-proposal (and possibly tx) to the part of its (peer’s) logic that endorses a transaction, referred to as endorsing logic. By default, endorsing logic at a peer accepts the tran-proposal and simply signs the tran-proposal. However, endorsing logic may interpret arbitrary functionality, to, e.g., interact with legacy systems with tran-proposal and tx as inputs to reach the decision whether to endorse a transaction or not.

然后，peer在内部转发tran-proposal （并且可能是tx）到认可交易的（peer's）逻辑部分，称为认可逻辑。默认情况下，peer的认可逻辑接受tran-proposal 并简单地签署tran-proposal。然而，认可逻辑可以解释任意功能，例如，与具有tran-proposal 和tx作为输入的遗留系统交互以达到是否认可交易的决定。

If endorsing logic decides to endorse a transaction, it sends <TRANSACTION-ENDORSED, tid, tran-proposal,epSig> message to the submitting client(tx.clientID), where:

如果认可逻辑决定认可某个交易，它会向提交客户端（tx.clientID）发送<TRANSACTION-ENDORSED，tid，tran-proposal，epSig>消息，其中：

tran-proposal := (epID,tid,chaincodeID,txContentBlob,readset,writeset),

where txContentBlob is chaincode/transaction specific information. The intention is to have txContentBlob used as some representation of tx (e.g., txContentBlob=tx.txPayload).

epSig is the endorsing peer’s signature on tran-proposal
epSig是背书(endorsing) peer对tran-proposal的签名

Else, in case the endorsing logic refuses to endorse the transaction, an endorser may send a message (TRANSACTION-INVALID, tid, REJECTED) to the submitting client.

否则，如果认可逻辑拒绝批准该交易，则endorser 可以向提交客户端发送消息（TRANSACTION-INVALID，tid，REJECTED）。

Notice that an endorser does not change its state in this step, the updates produced by transaction simulation in the context of endorsement do not affect the state!

请注意，在此步骤中，endorser 不会更改其状态，在认可的上下文中由交易模拟生成的更新不会影响状态！

2.3. The submitting client collects an endorsement for a transaction and broadcasts it through ordering service/ 提交客户端收集对交易的认可并通过ordering 服务进行广播

The submitting client waits until it receives “enough” messages and signatures on (TRANSACTION-ENDORSED, tid, *, *) statements to conclude that the transaction proposal is endorsed. As discussed in Section 2.1.2., this may involve one or more round-trips of interaction with endorsers.

提交客户端等待，直到它在（TRANSACTION-ENDORSED，tid，*，*）语句上收到“足够”的消息和签名，以推断出交易提议已经被认可。如第2.1.2节所述，这可能涉及一次或多次与endorsers 互动的往返行程。

The exact number of “enough” depend on the chaincode endorsement policy (see also Section 3). If the endorsement policy is satisfied, the transaction has been endorsed; note that it is not yet committed. The collection of signed TRANSACTION-ENDORSED messages from endorsing peers which establish that a transaction is endorsed is called an endorsement and denoted by endorsement.

“足够”的确切数量取决于链码背书(endorsement)策略（另见第3节）。如果背书(endorsement)策略得到满足，则该交易已获得批准;请注意，它尚未提交。来自背书(endorsing) peers的签名TRANSACTION-ENDORSED消息的集合（其确定交易被认可）被称为认可并且由endorsement 表示。

If the submitting client does not manage to collect an endorsement for a transaction proposal, it abandons this transaction with an option to retry later.

如果提交客户端无法收集对交易提议的认可，则会放弃此交易，并可选择稍后重试。

For transaction with a valid endorsement, we now start using the ordering service. The submitting client invokes ordering service using the broadcast(blob), where blob=endorsement. If the client does not have capability of invoking ordering service directly, it may proxy its broadcast through some peer of its choice. Such a peer must be trusted by the client not to remove any message from the endorsement or otherwise the transaction may be deemed invalid. Notice that, however, a proxy peer may not fabricate a valid endorsement.
对于有效认可的交易，我们现在开始使用ordering 服务。提交客户端使用broadcast(blob)调用ordering 服务，其中blob =endorsement。如果客户端没有直接调用ordering 服务的能力，它可以通过其选择的某个peer代理其广播。客户端必须信任这样的peer，其不会从 endorsement 中删除任何消息，否则该交易可能被视为无效。但请注意，代理peer可能无法制作有效的endorsement。

2.4. The ordering service delivers a transactions to the peers/Ordering 服务转发交易到peers

When an event deliver(seqno, prevhash, blob) occurs and a peer has applied all state updates for blobs with sequence number lower than seqno, a peer does the following:

当事件deliver（seqno，prevhash，blob）发生并且peer已经为序列号低于seqno的blob应用了(申请了）所有状态更新时，peer执行以下操作：

It checks that the blob.endorsement is valid according to the policy of the chaincode (blob.tran-proposal.chaincodeID) to which it refers.

它根据它所引用的链码（blob.tran-proposal.chaincodeID）的策略检查blob.endorsement是否有效。

In a typical case, it also verifies that the dependencies (blob.endorsement.tran-proposal.readset) have not been violated meanwhile. In more complex use cases, tran-proposal fields in endorsement may differ and in this case endorsement policy (Section 3) specifies how the state evolves.

在典型的情况下，它还同时验证没有违反依赖项（blob.endorsement.tran-proposal.readset）。在更复杂的使用案例中，认可中的tran-proposal 字段可能不同，在这种情况下，背书(endorsement)策略（第3节）规定了状态如何演化。

Verification of dependencies can be implemented in different ways, according to a consistency property or “isolation guarantee” that is chosen for the state updates. Serializability is a default isolation guarantee, unless chaincode endorsement policy specifies a different one. Serializability can be provided by requiring the version associated with every key in the readset to be equal to that key’s version in the state, and rejecting transactions that do not satisfy this requirement.

根据为状态更新选择的一致性属性或“隔离保证”，可以以不同方式实现依赖性的验证。可串行化是默认的隔离保证，除非链码背书(endorsement)策略指定不同的保证。可以通过要求与readset中的每个键相关联的版本等于该状态中的该键的版本来提供可串行化，并拒绝不满足此要求的交易。

If all these checks pass, the transaction is deemed valid or committed. In this case, the peer marks the transaction with 1 in the bitmask of the PeerLedger, applies blob.endorsement.tran-proposal.writeset to blockchain state (if tran-proposals are the same, otherwise endorsement policy logic defines the function that takes blob.endorsement).

如果所有这些检查都通过，则该交易被视为有效或已提交。在这种情况下，peer在PeerLedger的位掩码中用1标记该交易，将blob.endorsement.tran-proposal.writeset应用于区块链状态（如果tran-proposal相同，否则背书(endorsement)策略逻辑定义功能--采用blob.endorsement）。

If the endorsement policy verification of blob.endorsement fails, the transaction is invalid and the peer marks the transaction with 0 in the bitmask of the PeerLedger. It is important to note that invalid transactions do not change the state.

如果blob.endorsement的背书(endorsement)策略验证失败，则交易无效，并且peer在PeerLedger的位掩码中将交易标记为0。请务必注意，无效交易不会更改状态。

Note that this is sufficient to have all (correct) peers have the same state after processing a deliver event (block) with a given sequence number. Namely, by the guarantees of the ordering service, all correct peers will receive an identical sequence of deliver(seqno, prevhash, blob) events. As the evaluation of the endorsement policy and evaluation of version dependencies in readset are deterministic, all correct peers will also come to the same conclusion whether a transaction contained in a blob is valid. Hence, all peers commit and apply the same sequence of transactions and update their state in the same way.
请注意，在处理具有给定序列号的传递事件（块）之后，这足以使所有（正确的）peers具有相同的状态。也就是说，通过ordering 服务的保证，所有正确的peers将接收相同的deliver（seqno，prevhash，blob）序列事件。由于对背书(endorsement)策略的评估和对readset中版本依赖性的评估是确定性的，所以所有正确的peers也将得出相同的结论，即blob中包含的交易是否有效。因此，所有peers都以相同的方式提交并应用相同的交易序列并更新其状态。

Figure 1. Illustration of one possible transaction flow (common-case path).