The ledger in fabric is divided into two parts, one is file based storage, which meets the characteristics of blockchain that can not be tampered with. This way of storage basically uses Merkle tree, and the whole storage way can only be added, not deleted and modified. The other part is to use database for storage, which is called world in fabric State, such as leveldb, CouchDB and other K-V databases, the advantage of using this kind of database is that the database only stores the current latest value, which is convenient for business expansion, so that the current value can be found quickly, without the need to search through traversal. The fabric ledger is relatively complex. If you need to learn fabric through video, you can refer to video tutorials.
Both world state and file storage are distributed storage, and there are replicas in multiple nodes. The consistency of data in each node is ensured by consensus. CouchDB and leveldb can be used as state databases, but CouchDB has unique advantages in handling JSON and rich queries. Fabric here can support plug-in database, which can be relational database, graphic database, etc., which is convenient for fabric extension.
File store, which stores the operation records of the whole state database, and can export the value of the current state. Therefore, the combination of two ways of accounting in fabric can complement each other and better meet the needs of application.
So how is the file storage and state database storage of fabric stored? Let’s take a simple example. For example, if a has 100 yuan and B has 100 yuan, then a transfers to B 10 yuan. Then the file store stores four fields, a, transfer, B, 10. It stores the whole operation, but does not store the latest values after a and B transfers. Our state database stores the latest values of a and B. generally, the state database is based on K-V storage, so a: 90, B: 110, so when we want to query the latest account of a, we can directly find the state database, instead of traversing the file storage.
Then file storage forms our blocks. The relationship between blocks is as follows. Through hash Association, a block stores multiple data, that is, multiple transaction TX.
The data structure of each block includes three parts:
Block head: block number, block height, current block hash, previous block hash
Block data: multiple TX
Block metadata: generation time, certificate, signature, etc.
Each TX has a specific data structure as follows:
Header: stores the version of the corresponding chain code and chain code.
Signature: a signature generated with the client’s private key, which is used to check whether the data has been tampered with.
Proposal: code the parameters passed to the smart contract by the client, and simulate the execution of the chain code according to these parameters and the current worldstate value.
Response: the value in the world state obtained by calling the chain code is the return value of the smart contract, which is called RW read-write set. If TX verification is successful, the returned value will be applied to the world state.
Endorsements: the list of TX response signatures. The world state and block will be updated only if they have the correct endorsements.
Other: other fields, some non required fields.
So how to get the data of the block and how to view it, we will decompose it next time.