Ledger - 賬本
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.
賬本是Fabric中所有狀態轉換的記錄，具有有序和防篡改的特點。狀態轉換是參與各方提交鏈代碼調用（交易）產生的結果。每個交易會產生一組資產鍵值對，這些鍵值對作為“創建”、“更新”或者“刪除”提交給賬本。
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.
賬本由一個區塊鏈（鏈）構成，並將不可變的、有序的記錄存放在區塊中；同時包含一個狀態數據庫來記錄當前的Fabric狀態。每個通道中各有一個賬本。各個節點對於它所屬的每個通道，都會保存一份該通道的賬本副本。
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.
鏈碼調用基於當前的狀態數據執行交易。為了使鏈碼調用高效運行，所有鍵的最新值被存儲在狀態數據庫中。狀態數據庫是鏈的交易日誌的索引視圖，因此它可以隨時從鏈中重新導出。節點啟動的時候，在接受交易之前，狀態數據庫將被自動恢復（或者根據需要產生）。
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. The 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.
其次，節點們會對交易的讀集合進行版本檢查，從而保證數據的一致性並防範一些攻擊，比如雙花。Fabric擁有併發控制，從而交易可以（被背書節點）並行運行來提高吞吐量，而且當交易（被節點）提交時，每個交易都會被驗證來保證它所讀取的數據沒有被其他交易更改。換言之，它確保鏈碼執行期間所讀取的數據從執行（背書）開始後沒有變動。如果讀取的數據被其他交易改動了，那麼區塊中的交易將被標記成無效的，也不會被應用到賬本狀態數據庫。客戶端應用會收到提醒，從而進行糾錯或適當重試。
See the Transaction Flow and Read-Write set semantics topics for a deeper dive on transaction structure, concurrency control, and the state DB.
要進一步瞭解交易的結構，併發控制和狀態數據庫的相關內容，可以參考交易流程和讀寫集合語言學。
State Database options - 狀態數據庫選項
State database options include LevelDB and CouchDB (beta). LevelDB is the default key/value state database embedded in the peer process. CouchDB is an optional alternative external state database. Like the LevelDB key/value store, CouchDB can store any binary data that is modeled in chaincode (CouchDB attachment functionality is used internally for non-JSON binary data). 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(beta)。LevelDB是節點流程中集成的缺省鍵值狀態數據庫。CouchDB是可選的外部狀態數據庫。類似於LevelDB的鍵值庫，CouchDB能存儲任何鏈碼中建模的二進制數據（CouchDB附件功能被內部用於非JSON格式的二進制數據）。但作為一個JSON格式文檔庫，當鏈碼的數據（比如資產）以JSON格式建模時，CouchDB額外提供了許多針對鏈碼數據的查詢方式。
Both LevelDB and CouchDB support core chaincode operations such as getting and setting a key (asset), and querying based on keys. Keys can be queried by range, and composite keys can be modeled to enable equivalence queries against multiple parameters. For example a composite key of (owner,asset_id) can be used to query all assets owned by a certain entity. These key-based queries can be used for read-only queries against the ledger, as well as in transactions that update the ledger.
LevelDB和CouchDB都支持核心的鏈碼操作，比如獲取和設置一個鍵（資產），以及基於鍵進行查詢等。鍵的查詢可以通過設置範圍，而且可以通過構建組合鍵來達到按多個參數進行查詢的同等效果。比如一個組合鍵（擁有者，資產編號）可以被用來查詢某實體所擁有的所有資產。這些基於鍵的查詢可以被用做針對賬本的只讀查詢，同時也可以被應用在對賬本進行更新的交易中。
If you model assets as JSON and use CouchDB, you can also perform complex rich queries against the chaincode data values, using the CouchDB JSON query language within chaincode. These types of queries are excellent for understanding what is on the ledger. Proposal responses for these types of queries are typically useful to the client application, but are not typically submitted as transactions to the ordering service. In fact the fabric does not guarantee the result set is stable between chaincode execution and commit time for rich queries, and therefore rich queries are not appropriate for use in update transactions, unless your application can guarantee the result set is stable between chaincode execution time and commit time, or can handle potential changes in subsequent transactions. For example, if you perform a rich query for all assets owned by Alice and transfer them to Bob, a new asset may be assigned to Alice by another transaction between chaincode execution time and commit time, and you would miss this ‘phantom’ item.
如果你將資產以JSON格式進行建模，並且使用的是CouchDB，那你可以通過CouchDB的JSON查詢語言，對鏈碼的數據值進行復雜多樣的查詢。這些查詢類型可以很好的幫助理解賬本中包含什麼。查詢類型的提案響應對客戶端應用通常很有用，但並不會被作為交易提交到排序服務。實際上對於富查詢（rich query），Fabric並不保證結果集在鏈碼執行和提交過程中間是穩定的，或者能處理後續交易中潛在的變化。比如說，如果你對所有Alice擁有的資產進行富查詢，並轉移給Bob，那在鏈碼執行和提交的過程中，可能會有另一個交易將一個新的資產分配給了Alice，你將會錯失這個“幻影”項。
CouchDB runs as a separate database process alongside the peer, therefore there are additional considerations in terms of setup, management, and operations. You may consider starting with the default embedded LevelDB, and move to CouchDB if you require the additional complex rich queries. It is a good practice to model chaincode asset data as JSON, so that you have the option to perform complex rich queries if needed in the future.
CouchDB作為獨立的數據庫進程跟節點一起運行，所以安裝、管理和操作的時候需要一些額外的考慮。你可以嘗試開始的時候用缺省集成的LevelDB，然後當你需要額外的複雜查詢時再切換到CouchDB。將鏈碼的資產數據以JSON格式建模是一個非常好的實踐，這樣有利於你將來進行復雜多樣的查詢。
To enable CouchDB as the state database, configure the /fabric/sampleconfig/core.yaml stateDatabase section.
如果要用CouchDB作為狀態數據庫，需要對/fabric/sampleconfig/core.yaml stateDatabase這部分進行配置。