第7章 账本

The ledger is the sequenced, tamper-resistant record of all state transitions. 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 state. There is one ledger per channel. Each peer maintains a copy of the ledger for each channel of which they are a member.

账本由存储不变的、顺序记录的区块链和维护当前状态的状态数据库组成。每个通道有一个账本，每个对等节点为他们是其成员的每个通道维护一份账本的拷贝。

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.

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

链

链是一个交易日志，它由哈希链接的块组成，其中每个块包含N个交易的顺序。块头部包含该块交易的哈希和上一个块头部的哈希。通过这种方式，账本中的所有交易便有序且加密地链接在一起。换言之，不破坏哈希链，想要篡改账本数据是不可能的。最新的块的哈希，表示了之前发生的所有交易，从而确保所有对等节点处于一致并信任的状态。

链存储在对等文件系统（本地或附加存储），有效地支持区块链工作负载只允许追加的特性。

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，允许JSON内容的丰富查询时，它提供额外的查询支持。查阅状态数据库CouchDB获取关于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.

关于交易结构、并发控制和状态数据库的深入研究，请参看交易流、读写集合语义和状态数据库CouchDB。