Reference book: "Hyperledger Fabric Rookie Advanced Guide"-edited by Li Yuechun and others
Ledger data
The ledger keeps the records of all transaction changes and is orderly and tamper-proof. For each transaction, the chain code needs to record the data changes in the ledger. The data that needs to be recorded is called the state, which is stored in the form of key-value pairs.
The ledger in Fabric consists of two different but related parts.
- World state
- Blockchain
The world state saves the latest value of a set of ledger data states in the form of key-value pairs in Fabric. The state of the world is actually a NoSQL database for storage and retrieval of the state; it allows applications to quickly obtain the latest value of the current ledger without traversing the entire transaction log. The value can be a simple value, or it can be composed of a set of complex data composed of key-value pairs.
Each world state has a version number, and the starting version number value is 0. Each time the status is changed, the version number is incremented.
Blockchain is a file system that records transaction logs. It is constructed from N blocks connected by hash values; each block contains a series of multiple ordered transactions. The block header contains the hash value of the transaction recorded in this zone. In this way, all transactions in the ledger are linked together in an orderly and encrypted form.
data storage
Blockchain is stored in the form of files. By default, each block file is prefixed with blockfile_, followed by a 6-digit name, and the default starting number is 000000. If there is a new file, it will be incremented by 1 each time.
Blockchain files are stored in the chains folder by default, which contains two subdirectories:
-
The chains directory to save blockchain files
In this directory, each ledger is distinguished by the channel file directory, and each peer node will save a copy of the ledger for each channel to which it belongs.
-
Use LevelDB to implement an index directory that saves index information
The orderer node will only save a copy of the ledger, excluding the state database and historical index data, which are maintained by the peer node.
In the peer node, in addition to storing a ledger, it also needs to maintain the status database, historical database, and block index.
-
State database
Store the latest value (world state) of all Keys in the transaction log. The default database uses LeverDB (optional CouchDB).
-
Historical database
The LevelDB database is used as the data storage carrier to store the key related to the effective transaction in the block instead of the value.
-
idStore
Store all ledgerIDs (chainID/channelID) (channel ID) added by the current Peer node, and ensure the uniqueness of the ledger number.
Read-write set
After the simulated transaction is executed, the endorsement node will generate a Read-Write Set. The Read Set contains the unique key read during the simulation execution of the transaction, the corresponding submitted value and the submitted Version list.
The Write Set contains a list of unique keys and new values written by the transaction. That is, Key-Value (the new value to be written).
If the transaction reads the value of the specified Key, only the submitted status value Value will be returned, and the modified but uncommitted value in the same transaction cannot be read.
If the transaction performs a delete operation, set a delete flag for the Key in the write set. If the same key is changed multiple times in a transaction, only the last changed value (the latest value) is retained.
If the transaction executes a range query, the range query and its result will be added to the read-write set, which is represented by query-info.
Example of read-write set:
Transaction verification and world status update
The committee role node in Peer uses the read set part of the read-write set to check the validity of the transaction, and the write set part updates the version number and value of the affected Key. During verification, the version number of each Key in the read set is compared with the world state in the state database. If it matches, the transaction is considered valid.
If one or more query information is included in the read-write set, additional verification is performed. This verification ensures that no Key is added, deleted or changed within the result range of this batch query.
In other words, if any range query is re-executed during verification, the result should be the same as the result obtained during the simulation execution of the transaction. This verification ensures that the transaction will be considered invalid if a phantom read occurs when it is submitted.
Phantom reading: It is a phenomenon that occurs when the transaction is not executed independently. For example, the first transaction modifies the data in a table, and this modification involves all data rows in the table. At the same time, the second transaction inserts a new row of data in the table. Then the user who operates the first transaction finds that there are no modified data rows in the table.
For example: Transaction A reads 10 employees with a salary of 5000 in the table. At this time, transaction B inserts an employee record with a salary of 5000. When transaction A queries again, the record becomes 11.
If the transaction passes the validity check, the committee role node uses the write set to update the world state. During the update, for each key in the write set, the corresponding Value and version number in the world state will be updated.
Simulation and verification example
Assume that World State is represented by a tuple (k, ver, val). There are 5 transactions, namely T1, T2, T3, T4, T5.
World State （（k1，1 ， v1） （k2，1 ， v2） （k3，1 ， v3） （k4，1 ， v4） （k5，1 ， v5）
①执行T1：Write（k1,v1’） write（k2,v2’）
world state （（k1，2 ， v1 '） （k2，2 ， v2'） （k3，1 ， v3） （k4，1 ， v4） （k5，1 ， v5）
Due to the write operation performed by T1, it is updated directly.
②Execute T2: read(k1) write(k3,v3')
T2 needs to be validated. Since the value of k1 is modified in T1, the T2 verification fails.
world state （（k1，2 ， v1 '） （k2，2 ， v2'） （k3，1 ， v3） （k4，1 ， v4） （k5，1 ， v5）
③Execute T3: write(k2,v2'')
The transaction verification is successful, because there is no read operation, the world state is updated.
world state （（k1，2 ， v1 '） （k2，3 ， v2' '） （k3，1 ， v3） （k4，1 ， v4） （k5，1 ， v5）
④Execute T4: write(k2,v2''') read(k2)
Transaction verification failed because the value of k2 was modified before
world state （（k1，2 ， v1 '） （k2，3 ， v2' '） （k3，1 ， v3） （k4，1 ， v4） （k5，1 ， v5）
⑤Execute T5: write(k6,v6) read(k5)
The transaction verification is successful. Because the value of k5 has not been modified
world state （（k1，2 ， v1 '） （k2，3 ， v2' '） （k3，1 ， v3） （k4，1 ， v4） （k5，1 ， v5） （k6，1 ， v6）
Summary: After the client sends the transaction proposal to the endorsing node, the endorsing node simulates the execution of the transaction and generates a read-write set. Among them, the read set contains the unique key read during the simulation execution of the transaction, the corresponding submitted value and the submitted Version list; the write set (Write Set) contains a unique key list and the new value written by the transaction. The commuter role in the Peer node verifies the validity of the transaction according to the read set part of the read and write set.
Take the example of 1.3 to explain in detail why some transactions fail the validity verification.
For the above group of transactions, the version corresponding to the key in the world state when the transaction proposal is submitted is all 1. The T1 transaction modifies the value of k1, and the version number is increased by 1 to become 2, and the value is changed accordingly. When verifying T2, the read-write set contains read operations, and each key version number (k1) in the read set needs to be matched with the version number in the world state. When the read set is created, the version number of k1 is 1. At this time, the version number of k1 in the world state is 2. The two do not match, and the verification fails.