fabric中的ledger分为两部分内容，一部分是基于文件的存储，基于文件的存储满足区块链不可篡改的特性，此种方式存储基本是采用Merkle Tree，整个存储的方式是只能追加，不能删除和修改。另一部分则是使用数据库进行存储此种方式在fabric中叫做world state，如leveldb、couchdb等K-V数据库，使用此类数据库的优势是数据库只存储当前的最新值，便于业务的拓展，这样可以很快的查找到当前的值，而无需通过遍历的方式来查找，fabric的ledger相对复杂，如需视频学习fabric，可以参考视频教程。
无论是world state 还是文件存储都是分布式的存储，在多个节点里都存在副本的。通过共识保证数据在各个节点上的一致性。couchdb和leveldb都可以作为state的数据库，但是couchdb在处理json和富查询方面有着独特的的优势。fabric 此处可以支持插件方式的数据库，可以是关系型，图形数据库等，这样便于fabric扩展。
文件存储，他存储了整个state数据库的操作记录，，可以导出当前state的值。因此fabric中的账本结合两种方式相辅相成，能够更好的满足应用的需要。
那么fabric的文件存储和state数据库存储分别是如何存储的呢？我们来举个简单的例子，如A有100元，B有100元，那么A转账给B 10元，那么文件存储存储四个字段，分别是 A , transfer, b , 10，它存储了整个操作，并未存储A和B转账后的最新值。而我们的state数据库则是存储了A和B的最新值，一般state数据库是基于K-V存储的，所以A:90, B: 110, 这样当我们要查询A的最新账户直接查找state 数据库就可以了，而不必去遍历查找文件存储。
那么文件存储就形成了我们的一个个区块，区块之间的关系如下，通过hash关联，而一个区块里面存储了多条数据，也就是多条交易tx。
每个区块的数据结构包括三部分：
区块头：区块号，区块高度 ，当前区块hash，前一区块hash
区块数据：多条tx
区块元数据：生成时间，证书，签名等。
每个tx有特定的数据结构如下：
Header ： 存储相应的链码和链码的版本。
Signature：用客户端的私钥生成的签名，此签名用于检查数据是否被篡改。
Proposal：对由客户端传递给智能合约的参数进行编码，并根据这些参数结合当前的worldstate值，来模拟链码的执行。
Response：通过调用链码来获取world state里的值是智能合约的返回值，叫做RW读写集，如果tx验证成功，该返回的值将会被应用到world state中。
Endorsements：tx响应签名的列表，只有拥有正确的背书，world state 和区块才会更新。
other ：其他字段，一些非必须的字段。
那么如何获取区块的数据，并如何查看，我们下回分解。
