Ledger记账本是Hyperdger Fabric基础的最后一章。
记账本我们天天都在使用,银行卡,支付宝和微信支付,我们较关心的肯定是账号上的余额了(即资产的当前状态),我想看下昨天我具体花了多少钱花在哪里就需要看交易的流水明细。同理Hyperledger Fabric结构也是类似的,需要记录Asset资产的当前状态和交易的历史。
区块链的账本
区块链的账本包含两部分,world state(世界的状态?整体的状态?)和区块链。
首先是World state 通常使用数据库保存一组账本的当前的状态值,这样就不用遍历所有的交易日志去计算当前的状态值,通常使用key-value键值对表示,状态值可被创建,更新和删除。
其次是区块链,记录着决定world state状态的交易日志。交易的信息会收集起来追加到区块链,一旦写入,就不能修改了。
![](actionImg/Publoadimg.do?id=4028813e711a7c3901713fa940232359&type=max)
World State
World state如上所述,程序和应用更多的时候需要获取账本当前的状态值。![](actionImg/Publoadimg.do?id=4028813e711a7c3901713fa9f983235a&type=max)
上面的例子, 有两个车, 第一个车CAR1(key值/键值), 它的值是Audi。而CAR2的值就更完善些, 类型是BMW,红色,归属于Jane。两个车的版本号都是0。
账本的状态用于记录在区块链中共享的应用信息,我们可以编写程序调用链码采访这些状态,例如通过key操作(查增删)。
现实中,World state常用数据库实现,数据库对于读取和存储状态都提供了高效的实现,是不是和no-sql中的couchdb, mongodb有点像 :-)
交易保存了World state的变化,它是有生命周期的, 从应用发起到提交到区块链保存为止。 只是交易必须要足够的背书节点签名之后才可以更新world state.
我们注意到CAR的记录都有版本号,状态值变化,版本号就会增加。交易创建的时候会对应到状态的版本号,如果交易记录打包到区块分发到其它节点,其它节点的账本副本发现对应的状态版本变了, 那么这个交易记录认为是无效的。 这个跟我们实际开发中常用的乐观锁的概念是类似的。
区块链
我们学习下区块链的大体结构。 区块链是交易日志,内部连接的区块,每个区块包含一系列的交易,每个交易代表一个查询或更新world state的操作。
每个区块的头部包含了区块所有交易的哈希值,还有上一个区块头部的哈希值,
有点像链表,这样所有的交易就有序的串起来了,也可以保证数据的安全。即使保存账本的一个节点被篡改了,它不能让其它有正确区块记录的记账节点认同。
实际上,区块链于world state不同,通常不使用数据库保存,通常使用文件保存。这是一个合理的设计选择,因为区块链的数据结构偏向于大量的小操作的集合, 区块链追加数据是最常用的操作,而查询频率不高。
![](actionImg/Publoadimg.do?id=4028813e711a7c3901713faab932235c&type=max)
上图为例, B0是第一个区块,也称为genesis block创世块,没交易记录,只会保存有通道,orderer,peer等信息,后面我们实际部署配置的时候会用到创世块。
区块
(1)区块头部
头部的数字编号,从0开始递增。
当前区块的哈希值,例如下图的CH2
上一块区块的哈希值, 例如PH1
![](actionImg/Publoadimg.do?id=4028813e711a7c3901713fab45ef235d&type=max)
(2)区块数据段
B2开始保存的都是有序的交易日志。
(3)区块的元数据
包含区块写入的时间戳,证书,公钥,写入者的签名,是否合法的标记位等。
交易
参考下图交易数据的具体结构
![](actionImg/Publoadimg.do?id=4028813e711a7c3901713fabc8fa235e&type=max)
(1)头部
即上图H4, 包含交易必要的元数据,例如对应的链码和版本等。
(2)Sinature签名
上图S4, 由客户端应用创建,使用客户的私钥做签名。
(3)Proposal 提议
上图P4, 封装了应用提供给链码使用的输入参数,链码执行,使用这些入参, 与现有world state一起使用,就能计算出新的world state.
(4)响应
R4, 保存world state改变前后的状态值,作为读写的结合。 这个就是链码的响应,如果后面交易验证通过了,账本就按照响应去更新world state状态值。
(5)Endorsements背书记录
E4, 如之前章节所述,更新交易第一步发起提议后,需要背书节点的签名,就在这里记录了。
World State数据库的选择
Hyperledger Fabric当前支持Level DB和CouchDB.
Level DB适合于简单的key-value键值对,嵌入网络的peer节点进程。
CouchDB适合于复杂些的world state状态要用JSON文档表示的场景,提供了更多的富查询特性,与peer节点进程隔离开。
重要的是,Hyperledger Fabric作为state DB实现的level DB或couchDB都是可插拔的设计, 完全可能用其它的关系型数据库或非关系型数据库实现。
基础完结, 后面我们会通过Hyperledger Fabric的入门例子, 实际操作和配置, 使用Go和Nodejs编写联链码。
再之后估计就是学下更方便些的Hyperledger Composer的方式去开发部署区块链。
但是相信有了前面这些核心基础知识, 后面的学习会相对简单很多。技术原本就是苦中作乐的事情,希望大家多些快乐。
————————————————
版权声明:本文为CSDN博主「zealVampire」的原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接及本声明。
原文链接:
https://blog.csdn.net/zealVampire/article/details/81839664