3

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。

file

每个区块的数据结构包括三部分:
区块头:区块号,区块高度 ,当前区块hash,前一区块hash
区块数据:多条tx
区块元数据:生成时间,证书,签名等。

每个tx有特定的数据结构如下:
file
Header : 存储相应的链码和链码的版本。
Signature:用客户端的私钥生成的签名,此签名用于检查数据是否被篡改。
Proposal:对由客户端传递给智能合约的参数进行编码,并根据这些参数结合当前的worldstate值,来模拟链码的执行。
Response:通过调用链码来获取world state里的值是智能合约的返回值,叫做RW读写集,如果tx验证成功,该返回的值将会被应用到world state中。
Endorsements:tx响应签名的列表,只有拥有正确的背书,world state 和区块才会更新。
other :其他字段,一些非必须的字段。

那么如何获取区块的数据,并如何查看,我们下回分解。


桃猿结义
42 声望5 粉丝