区块链技术 | Fabric架构演变之路
时间: 2020年10月16日                     分类: 区块链技术 标签:, ,

Hyperledger Fabric是当前主流的开源联盟链产品之一。自代码仓库于2016年5月12日开放至今已近4年。该产品已稳定下来,其功能也越来越完善。 ,正在适应不同业务场景的需求。

在Fabric的整个发布过程中,从v0.6.1-预览版到v1.0.0的迁移过程中,体系结构发生了重大变化。在v1.[k3中,0之后,已向每个次要版本中添加了一些新功能,以支持不同的业务场景并改进相应的功能。接下来,让我们从个人角度谈谈Fabric体系结构更改过程中的一些想法。

区块链技术

#Fabric v0.6

v0.6版本的技术架构在整个开发过程中会保留很短的时间。与当前的v1.x版本相比,它不稳定并且适合在poc阶段进行测试。

下图是Fabric v0.6版本的体系结构图:

区块链技术

在v0.6版本中,它主要分为核心模块,例如成员资格,共识,链码,分类帐,P2P和事件流。

-会员资格:负责颁发相应的E证书,T证书,TLS证书和其他证书。

-共识:负责整个区块链的共识,统一交易顺序,并确保区块链的一致性。

-Chaincode:Chaincode(Fabric中的智能合约),用于在区块链网络中执行交易。

-Ledger:用于在事务中存储事务日志和键值。

-P2P:基于Google的Grpc框架的基础网络通信层。

-事件流:事件订阅发布结构,用于接收事务和阻止事件。

Fabric v0.6中使用的共识算法是PBFT算法(实用拜占庭容错),它可以避免信任度较低的情况下的拜占庭问题。但是,由于算法特性的限制,n> = 3f + 1可以容忍一个拜占庭节点。因此,在v0.6版本中,vp节点的数量至少为4。在v0.6版本中,节点角色分为三种类型:VP(验证对等体),NVP(无验证对等体) ,以及用于颁发证书的成员资格节点。当然,从第一个版本v0.6.0-preview开始,Fabric就采用了基于docker的运行时环境,这减少了部署的许多麻烦并屏蔽了操作系统的差异。当然,最重要的一点可能是由于Chaincode的设计机制。整个生产环境的链代码的部署和操作基于docker,这可能是由于考虑了docker的稳定性和相对安全的操作环境。只要实现了相应的接口,Fabric的智能合约设计理论上就可以支持任何开发语言。因为它是基于Peer节点与chaincode容器之间的双向通信来完成相应的交互。

下图是Fabric v0.6版本的网络拓扑图:

区块链技术

在此图中,VP和NVP有2个角色。 NVP将在此处共享VP的部分工作,从客户端接收交易以进行验证并将交易请求转发到共识节点VP,这将由VP节点执行。真正的共识是将事务写入块中。在此,NVP可以分担共识节点VP的事务处理压力,从而可以提高共识的性能。

下图显示了Fabric v0.6的交易流程图:

区块链技术

应用程序需要首先从会员资格中申请电子证书,然后通过电子证书申请T证书。对应于T-cert的私钥用于签署客户交易,并将其发送到VP节点以进行三个阶段的协商。完成后,将通过Chaincode依次执行区块中的每个节点交易,并更新分类帐。

由于重新构建了1.0体系结构,可能无法继续维持结构v0.6版本,但是与1.0版本的体系结构相比,该设计具有区块链相对对称的作用,与1.0-1.4版本相比,它没有集中式的Kafka,并且在实际场景中具有更合理的对等节点设计。

区块链技术

#Fabric v1.x

在Fabric的1.0版本中,对体系结构进行了重构。与v0.6版本相比,发生了颠覆性变化。功能模块已耦合并具有更好的性能。可伸缩性,性能,通道级安全隔离,可插入共识算法区块链技术,更高的可操作性,更丰富的功能以及为开发人员带来的更好体验。在v0.6版本中,成员资格也已升级为独立的Fabric CA项目。

区块链技术

在Fabric v1.x版本中,拆分了节点的功能,明确了每个节点的责任,并拆分了认可的信任假设和排名的信任假设。最大的变化在于共识过程中事务执行的进展,这由Endorser节点模拟并认可。订购节点订购者将统一打包和分类所有交易,并将其分发到Committer节点。这种设计的优点是可以并行执行前后无关的事务以及不同通道中的事务,从而提高了事务的执行速度。在v0.6版本中,不可能实现并行执行。在0.6中,统一进行排序和打包,然后按顺序执行事务,即使之前和之后的事务无关。下图也很好地反映了Fabric v1.x中的网络拓扑。

区块链技术

下图是Fabric v1.x版本的体系结构图:

区块链技术

在v1.x版本中,它主要分为Fabric CA,Endorser,Committer,Orderer,Application和其他角色。

-Fabric CA:负责在整个Fabric网络中维护证书,包括诸如签发,吊销和续签签证证书之类的操作。

-Endorser:负责批准客户发送的交易建议。

-提交者:负责验证该块并将该块写入分类帐。

-订购者:负责所有交易的全局唯一排序和包装。

-Application:用于发送交易建议,收集响应,打包交易并将其发送到Orderer订购服务节点。

在1.0及更高版本中,客户端应用程序将首先向Fabric CA申请用户在Fabric CA中用于签署提议和交易所需的访问证书,然后由客户端(Application)生成(提案)(通用应用程序将使用Fabric当前提供的一系列SDK来生成提案)被发送到认可节点进行模拟执行和认可,认可者节点认可者将执行相应的验证,然后将提案提交给相应的将对链码进行仿真并执行,然后认可节点Endorser将认可执行结果,并将认可的Response返回给客户端程序Application。

随后,在客户端程序收集了符合认可策略的投标响应之后,它将其封装到交易Transaction中,调用订购节点Orderer的Broadcast接口,并将交易发送给订购者,在v1.中在0-v1.4版本中,生产环境仅具有基于分布式消息队列Kafka的排序和打包方法。作为生产者,订购者将交易发送到与每个渠道相对应的主题分区,以实现统一的全局订单。每个订购节点都根据相同的阻止规则从Kafka切下该块,并将其推送到与其连接的Leader Peer(在良好的网络环境中,每个组织只有一个Leader),Leader Peer接收该块。将通过Gossip协议广播到组织中的其余节点。每个提交者收到该块后,将验证该块,包括签名,认可策略以及对读写集的验证。如果验证正确,则提交将提交到分类帐,并且世界状态将同时更新。订阅相应事件的应用将从事件中心接收消息通知。

下图是Fabric v1.x交易过程的简化版本:

区块链技术

此外,在v1.0之后,Fabric强调组织的概念。在对等节点级别,每个组织都需要配置一个或多个Anchor Peer节点以代表整个区块链网络中的组织。一开始与其他组织交换节点信息,以便每个节点都能掌握整个网络的节点信息。

同时,在v1.0之后,Fabric添加了多通道技术(Muti-channel),该技术使多个分类帐可以在Fabric网络中运行,并且每个通道之间的逻辑均不受影响,因为如下图所示,每条色线代表一个逻辑通道。每个对等节点可以加入不同的渠道。每个频道在Kafka中都有一个独立的分类帐,世界状态,链代码和主题。通道之间的消息是隔离的。 ,不要互相影响。

区块链技术

在Fabric v1.x中,多通道技术用于在业务逻辑级别执行全局操作,以隔离不同业务的通道,以便将不同业务的交易存储在与不同通道对应的节点中。主要在订购者中实现。订购者将交易与不同渠道区分开。同时,在对等节点中使用MSP验证不同通道的消息,以确定该消息是否属于某个通道。通过将Orderer和Peer结合起来,形成了逻辑渠道技术。

区块链技术

在认可和提交验证阶段,Fabric提出了两个系统链代码,ESCC和VSCC,其中ESCC:用于认可链代码执行结果; VSCC:用于验证接收到的块事务已验证。

区块链技术

在存储方面,v1.0也已优化。存储设计分为两部分。一部分是块的存储。文件系统是传统的文件系统,旨在使用文件。存储的原因是区块链中的块被连续追加,也就是说,它们被连续追加。没有随机书写。如果使用键值数据库,则可能存在数据压缩或相关索引算法的消耗。在这种情况下,文件系统将比KV数据库更好。因此,无论是订购者还是对等者,文件系统都将用于块存储部分,而块索引将使用Level DB进行存储维护,这将基于BlockHash,BlockNumber,TxId等。以Key的形式存储,而Value是区块或交换+偏移量的段号,可用于根据Key快速定位所需的区块或交易。

此外,对于世界状态的存储,这是指状态DB。在v1.0之后,可以使用Level DB或Couch DB进行存储。根据存储数据的复杂性和链代码的业务逻辑,可以选择不同的示例。例如,如果需要索引Json数据,则可以使用Couch DB进行存储。如果它是普通的键值,则可以使用Level DB进行存储。

下图是Fabric v1.0之后的存储设计:

区块链技术

从结构v0.6到v1.0的结构v1.0之后的CA,结构CA是从成员资格模块派生的,该模块负责颁发,更新和签署数字证书。整个Fabric网络的工作(如吊销)作为一项独立服务存在。同时,Fabric CA支持多层CA,以确保根CA的绝对安全性。同时,存储部分也是可插入的。您可以选择MySQL,LDAP,Postgres等,并且可以使用HA Proxy进行负载平衡。

区块链技术

区块链技术

#Fabric v1.1

Fabric v1.1的主要新功能包括:

-织物CA的CRL

-块和交易的事件推送

-在所有组件之间添加了相互TLS通讯

-Node.js Chaincode链码支持

-Chaincode API添加了创建者身份

-与v1.0相比,性能已得到显着改善

区块链技术

#Fabric v1.2

织物v1.2开始具有更大的功能并开始出现:

私人数据收集:必须说此功能解决了许多项目在隐私保护方面的难题,并且还减少了在业务层进行隐私保护的许多项目的复杂设计。

服务发现:此服务发现功能使客户端具有更大的灵活性和可操作性,并且可以动态感知整个Fabric网络中的更改。

可插拔的认可和验证:可插拔的认可和验证机制是通过Go Plugin机制实现的,从而避免了需要在之前重新编译源代码并提高了灵活性。

区块链技术

#Fabric v1.3

Fabric v1.3还添加了一个非常有用的功能:

基于Identity Mixer的MSP实现:基于零知识证明的身份的匿名性和不可链接性。此功能取代了v0.6版本中的T-cert。

关键级别的认可政策:更细粒度的认可政策,细化为特定的键值以及更灵活,不仅限于用于认可的连锁程序。

新的Java链码:到目前为止,在v1.3之后,支持Go,Node.js和Java的三个链码,这为开发人员提供了更多选择。

基于对等通道的事件服务:通道级事件订阅机制,已在v1.1版本中发布,并在v1.3版本中正式发布。到目前为止,旧的Event Hub已被正式废弃。 #Fabric v1.4

Fabric v1.4是一个里程碑版本,第一个LTS版本(长期支持版本):

可操作性和可维护性的改进:打开日志级别设置界面,打开节点运行状况检查界面,打开节点数据索引收集界面。

改进了Node SDK的编程模型,简化了开发人员的代码复杂度,并使SDK易于使用。

增强私有数据:对于随后添加的访问节点,这些访问节点允许访问以前的私有数据并为客户端级别的私有数据添加权限控制,因此无需添加链代码逻辑。

对于Fabric的体系结构更改,从版本v0.6到版本v1.0已有相对较大的更改,并且在v1.0-> v1.4之间,存在还收集,改进了许多行业需求,并增加了许多实用功能。目前,v1.4版本的后续较小迭代将修复现有的错误,并且将来将引入新的主要功能。它将在v2.0中发布,敬请期待。