Hyperledger Fabric是由IBM公司主导开发的一个面向企业级客户的开源项目。与比特币和以太坊这类公有链不同,Hyperledger Fabric网络中的节点必须经过授权认证后才能加入,从而避免了POW资源开销,大幅提高了交易处理效率,满足企业级应用对处理性能的诉求。同时,为了满足灵活多变的应用场景,Hyperledger Fabric采用了高度模块化的系统设计理念,将权限认证模块(MSP)、共识服务模块(Ordering Service)、背书模块(Endorsing peers)、区块提交模块(committing peers)等进行分离部署,使开发者可以根据具体的业务场景替换模块,实现了模块的插件式管理(plug-in/plug-out)。所以,Hyperledger Fabric是一个私有链/联盟链的开发框架,而且系统的运行不需要token支持。
节点:在Fabric v1.x中把节点分为peer节点(维护state和ledger),Order节点(负责共识或者排序账本中的交易)和背书节点(负责执行交易和链码)而在Fabric v0.6中则没有这些概念,只有一个peer节点,peer节点同时完成上述所有的功能。
在所有peers中,交易信息必须按照一致的顺序写入账本(区块链的基本原则)。例如,比特币通过POW机制,由最先完成数学难题的节点决定本次区块中的信息顺序,并广播给全网所有节点,以此来达成账本的共识。而Hyperledger Fabric采用了更加灵活、高效的共识算法,以适应企业场景下,对高TPS的要求。目前,Hyperledger Fabric有三种交易排序算法可以选择。
SOLO:只有一个order服务节点负责接收交易信息并排序,这是最简单的一种排序算法,一般用在实验室测试环境中。Sole属于中心化的处理方式。
Kafka:是Apache的一个开源项目,主要提供分布式的消息处理/分发服务,每个kafka集群由多个服务节点组成。Hyperledger Fabric利用kafka对交易信息进行排序处理,提供高吞吐、低延时的处理能力,并且在集群内部支持节点故障容错。
SBFT:简单拜占庭算法,相比于kafka,提供更加可靠的排序算法,包括容忍节点故障以及一定数量的恶意节点。目前,Hyperledger Fabric社区正在开发该算法。
节点(peer)是区块链的通信实体,是一个逻辑概念,不同类型的多个节点可以运行在同一个物理服务器上。节点主要有以下四种:
客户端必须连接到某一个peer节点或排序服务节点上才能与区块链网络进行通信。客户端向背书节点(endorser)提交交易提案(transaction proposal),当收集到足够背书后,向排序服务广播交易提案,进行排序,生成区块。
peer节点根据所承担的角色又可以分为记账节点(committer)、背书节点(endorser)、主节点(leader)和锚节点(anchor)。
接收包含背书签名的交易,对未打包的交易进行排序生成区块,广播给peer节点。排序服务提供的是原子广播,保证同一个链上的节点接收到相同的信息,并且有相同的逻辑顺序。
fabric1.0的证书颁发机构,由服务器和客户端组成。CA节点接收客户端的注册申请,返回注册密码用于用户登录,以便获取身份证书。区块链上的所有操作都需要验证用户身份。
原文链接:https://blog.csdn.net/ASN_forever/article/details/86538915
以下是fabric的经典交易流程,所有涉及到对账本数据更新的操作都是基于这个交易流程来完成的。
客户端发送交易提案(Proposal)到背书节点(peer节点),提案中包含交易所需参数。
背书节点会调用链码模拟执行交易提案(Proposal),这些执行不会更新账本。
每个执行都会产生对状态数据读出和写入的数据集合,叫做读写集(RWsets),读写集是交易中记录的主要内容。
背书节点会对读写集进行背书(Endorse)签名,生成提案响应(Proposal response)并返回给应用程序。
应用程序根据接收到的提案响应生成交易,并发送给排序服务节==(Order节点)==。排序服务打包一组交易到一个区块后,分发给各记账节点。
每个节点会对区块中的所有交易进行验证,包括验证背书策略以及版本冲突验证(防止双花),验证不通过的交易会被标记会无效(Invalid)。
账本更新:节点将读写集更新到状态数据库 ,将区块提交到区块链上。
各记账节点通知应用程序交易的成功与否,交易完成。
在Fabric v1.0中,仅在网络上发送签名和读写集,所以可伸缩性和性能得到了优化,因为只有背书者和提交者能看到交易,所以整个网络所需要的信任更低,提供了更高的安全性。
每个ChainCode在部署时,都需要和背书(ESCC)和验证(VSCC)的系统ChainCode关联。
ESCC决定如何对proposal进⾏背书。
VSCC决定事务的有效性(包括背书的正确性)。
区块链最新的未被持久化的状态是带版本号的键值对(KVS),这些状态被智能合约通过put,get方法操作,并且会被日志记录,如果有其他的RDBMS解决方案都可以灵活的替换。
智能合约可以根据key的名字来识别是属于哪个智能合约,原则上一个合约可以读取所有属于它自身的所有key。跨合约交易(cross-transactions)修改state目前还不支持,属于v1后续版本。
账本提供了所有state成功修改和对state不成功修改的尝试的记录。
账本通过order把所有有效和无效的交易构建了一个完全有序的链,而其中的每一个block中的交易又是完全有序的,这样就保证了所有交易的有序性。
账本保存在Peer或者可以保存在order的子集中,二者唯一的区别是Peer中保存的账本可以通过bitmask来区分交易的有效性。
Ledger允许重做所有transactions的历史记录,并且重建state。
fabric的数据存储结构被设计成多账本体系,每个账本在fabric中被称为channel。每个channel中都有一个完全独立的账本。同一个channel中的所有peer节点都保存一份相同的数据。
通道是两个或多个特定网络成员之间进行通信的专用“子网”,用于进行私有和机密事务。通道由成员(组织)、每个成员的锚节点、账本、链码应用程序和排序服务节点定义。网络上的每个交易都是在一个通道上执行的,在该通道上,每一方都必须经过身份验证和授权才能在该通道上进行交易。加入通道的每一个peer都有其自己的身份,由成员服务提供者(MSP)提供。
为通道上的每个成员选择主节点,用于代表该成员与排序服务进行通信。算法会自动选出主节点。共识服务对交易进行排序打包成区块,并把区块它发送给主节点。然后主节点根据gossip协议将区块分发给 通道中的成员。
尽管一个锚节点可以属于多个通道,因此能够维护多个账本,但是任何账本数据都不能从一个通道传递到另一个通道。这种用通道对账本进行隔离的方式是由配置链码、成员身份服务和gossip数据分发协议共同定义和实现的。通道上只有具备验证成员资格功能的节点才有权限进行数据分发。这种将peers和账本数据进行通道隔离的方式使得网络成员能够在同一个区块链中进行私密交易(只有自己通道的成员才知道交易信息)。
https://zhuanlan.zhihu.com/p/55341714
https://zhuanlan.zhihu.com/p/38289914
网络则主要包括两大部分:用户证书和链码。
接口主要是fabric sdk,比如fabric java sdk和fabric node sdk。
网络基础配置=证书+yaml文件
网络的基本单元是容器,网络是由一个个的容器组成的,如peer容器,orderer容器等。其中,容器是由yaml文件和证书两部分组成的。
yaml文件和docker联系紧密,所以你需要掌握docker的使用方法。yaml文件描述了peer的配置,而peer是网络的重要组成部分,所以如何实现动态的增加用户(peer\user),还得需要使用kubernates进行管理。
在用户证书这部分,由于官方1.1版本的的例子中使用的是cryptogen二进制工具,意思就是说官方1.1版本的例子只能安装事前配置的用户的数量生成相应数量的用户证书,所以没法实现动态生成peer\user证书从而动态增加用户(peer\user)。于是出现了fabric-ca,fabric-ca即是解决这样的需求的。通过使用fabric-ca动态生成证书,你将对fabric证书体系的理解更上一个层次。
在网络配置上运行着的是链码
就好像电线架好了,电就可以传输了一样,基础网络配置好了后,那在网络上运行着的便是链码了。
在fabric中链码和peer是独立的容器,因此你可以独立编辑的你的链码文件,只要实现了规定的链码接口,那么你这个链码便可以在peer上运行了,现在链码文件大都是go语言实现的。