1.Hyperledger Fabric架构介绍

(1)Hyperledger定义:

Hyperledger是一个开放源代码的区块链项目合作组织,旨在推动跨行业的企业级区块链解决方案的发展。该项目由Linux基金会于2015年发起,致力于建立一个可靠、安全和可扩展的区块链框架和工具集。Hyperledger提供了一个集合,其中包含了多个不同的区块链框架、工具和库,用于构建和管理私有、许可的区块链网络。

(2)Hyperledger项目:

Hyperledger项目是一个包含多个区块链框架和工具的合作组织,旨在推动企业级区块链的发展和应用,并提供丰富的功能和灵活性,以满足不同行业的需求。 

Hyperledger项目的核心是开发各种区块链框架和工具,以支持不同的应用场景和需求。

Hyperledger项目的目标是为各行业提供一个通用的、可扩展的区块链平台,以满足不同的商业需求。它致力于解决企业级区块链应用所面临的隐私性、可扩展性、性能和安全性等挑战。

(3)Hyperledger项目之一:Hyperledger Fabric介绍

3.1 Hyperledger Fabric 简介:

Hyperledger Fabric是Hyperledger项目中最为知名和广泛采用的区块链框架之一。它是一个开源的企业级区块链平台,旨在为商业应用提供可扩展、可定制和高度安全的解决方案。

Hyperledger Fabric是一个模块化的、可扩展的企业级区块链框架,它提供了高度可定制的智能合约和隐私性控制。它支持多个共识算法,并提供了丰富的身份验证和访问控制机制。

Hyperledger Fabric的设计目标是满足实际商业需求,特别注重隐私性、灵活性和可扩展性。

3.2  Hyperledger Fabric的关键特点:

  •  模块化架构:Hyperledger Fabric采用模块化的架构,使得各个组件可以独立运行和升级。这种架构使得Fabric更加灵活,可以根据特定需求进行定制和扩展。

  •  智能合约:Fabric支持多种编程语言编写的智能合约,其中最常用的是基于Go语言的链码(Chaincode)。链码可以定义业务逻辑和数据模型,用于执行和验证交易。
  •  隐私性和权限管理:Fabric提供了灵活而精细的权限管理机制,允许网络中的参与者进行身份验证和授权。它支持通道(Channel)的概念,使得特定的参与者只能访问和查看与他们相关的交易数据,确保数据的隐私性。
  •  共识机制:Fabric支持多种共识算法,包括拜占庭容错(Byzantine Fault Tolerant,BFT)算法和实用拜占庭容错(Practical Byzantine Fault Tolerant,PBFT)算法。这些算法可以根据网络需求进行选择,以实现高度安全和高性能的共识。
  •  可扩展性:Fabric的架构允许网络中的参与者根据需要进行扩展,以适应不同规模的业务需求。它支持分布式节点和容器化技术,可以在多个物理或虚拟环境中部署和运行。
  •  安全性和审计:Fabric提供了严格的身份验证和交易验证机制,确保数据的完整性和安全性。它还支持可追溯性,可以对交易进行审计和历史记录的查询。

 3.3 Hyperledger Fabric的架构演变:

Hyperledger Fabric的架构在其演进过程中经历了多个版本和改进。以下是一些关键的架构演变和功能增强:

  1.  V0.6版:初始版本的Hyperledger Fabric是一个单一的链码执行引擎,每个链码实例都有一个共享的状态数据库。这个版本还没有通道(Channel)的概念,所有的交易都是公开可见的。
  2.  V1.0版:引入了通道的概念,使得特定的参与者只能在一个私有的子网络中进行交易和通信。此外,V1.0版还引入了链码生命周期管理,支持链码的安装、实例化、升级和维护。
  3.  V1.1版:引入了私有数据(Private Data)的概念,允许参与者在交易中使用和管理私有数据。这样可以在保护数据隐私的同时,实现跨组织的合作和共享。
  4.  V1.2版:增加了配置交易(Config Transactions)和背书策略(Endorsement Policies)的功能。配置交易可以更改和更新网络配置,而背书策略允许定义需要哪些参与者背书交易。
  5.  V1.4版:引入了Fabric CA(Certificate Authority),提供了更强大和灵活的身份管理和认证机制。Fabric CA支持基于证书的身份验证和访问控制。
  6.  V2.0版:引入了多链码(Multi-chaincode)支持,允许在同一通道中部署和执行多个链码。这提供了更大的灵活性和可扩展性,以满足不同业务需求。
  7.  V2.2版:增加了外部链码(External Chaincode)支持,允许链码以外部进程的形式运行。这样可以更好地支持使用不同编程语言编写的链码。
  8.  V2.3版:引入了跨链码调用(Cross-chaincode Invocation)功能,使不同链码之间可以相互调用和交互,实现更复杂的业务逻辑。

 3.4 Hyperledger Fabric的架构和总体架构:

Hyperledger Fabric的架构和总体架构是相关但不同的概念,架构可看成总体架构的一部分。

Hyperledger Fabric是一个开源的企业级区块链平台,其架构由多个组件和层级构成,用于实现分布式、可扩展和安全的区块链解决方案。

Hyperledger Fabric的架构概述:

1. 应用层(Application Layer):
   - 客户端应用程序(Client Applications):与Hyperledger Fabric网络进行交互的应用程序,可以发送交易请求、查询数据等。
   - 链码(Chaincode):也称为智能合约,包含业务逻辑和数据模型,用于执行和验证交易。

2. 通信层(Communication Layer):
   - 提案和背书(Proposal and Endorsement):客户端应用程序向网络中的节点发送交易提案,并由节点执行背书操作,以获取交易的背书结果。
   - 订购服务(Ordering Service):负责将背书交易打包成区块,并根据共识算法达成共识,生成有序的交易区块。

3. 网络层(Network Layer):
   - 区块链网络(Blockchain Network):由多个节点组成的分布式网络,用于存储和共享交易数据。
   - 节点(Nodes):网络中的参与者,可以是对等节点(Peer Nodes)和排序节点(Ordering Nodes)。
   - 通道(Channels):逻辑上的隔离空间,允许特定的参与者在一个私有的子网络中进行交易和通信。

4. 存储层(Storage Layer):
   - 区块存储(Block Storage):存储已确认的交易记录,组成区块链。
   - 账本(Ledger):存储交易记录的数据结构,包括世界状态(World State)和交易日志(Transaction Log)。

5. 身份和访问控制层(Identity and Access Control Layer):
   - 成员服务提供商(Membership Service Providers,MSP):负责管理参与者的身份验证和权限管理。
   - 安全服务提供商(Security Service Providers,SSP):负责提供安全相关的功能,如加密和解密。

Hyperledger Fabric的总体架构是一个分布式、模块化和可扩展的企业级区块链平台。它由多个组件和层级构成,用于实现交易的验证、共识、存储和执行智能合约等功能。

Hyperledger Fabric的总体架构:

1. 客户端应用程序层(Client Application Layer):
   - 客户端应用程序(Client Applications):与区块链网络进行交互的应用程序,可以发送交易请求、查询数据等。

2. 智能合约层(Smart Contract Layer):
   - 链码(Chaincode):也称为智能合约,包含业务逻辑和数据模型,用于执行和验证交易。
   - 链码生命周期管理(Chaincode Lifecycle Management):负责链码的安装、实例化、升级和维护。

3. 交易处理层(Transaction Processing Layer):
   - 提案和背书(Proposal and Endorsement):客户端应用程序向网络中的节点发送交易提案,并由节点执行背书操作。
   - 共识服务(Consensus Service):负责验证交易的一致性和达成共识,确保交易被有效确认。
   - 区块生成(Block Generation):经过背书和共识的交易被打包成区块,并添加到区块链中。

4. 区块链层(Blockchain Layer):
   - 区块链网络(Blockchain Network):由多个节点组成的分布式网络,用于存储和共享交易数据。
   - 区块存储(Block Storage):存储已确认的交易记录,组成区块链。
   - 账本(Ledger):存储交易记录的数据结构,包括世界状态(World State)和交易日志(Transaction Log)。

5. 身份和访问控制层(Identity and Access Control Layer):
   - 成员服务提供商(Membership Service Providers,MSP):负责管理参与者的身份验证和权限管理。
   - 网络参与者(Network Participants):包括节点和客户端应用程序,共同构成区块链网络的参与者。

6. 网络管理层(Network Management Layer):
   - 配置交易(Configuration Transactions):用于更改和更新网络的配置参数。
   - 区块链管理(Blockchain Management):包括网络的创建、配置和维护。

(4)Hyperledger Fabric 交易流程:

4.1 在此流程中:

1. 客户端应用程序创建并发送交易提案给背书节点。
2. 背书节点执行链码操作,并生成交易背书结果。
3. 客户端应用程序收集足够数量的有效背书结果后,将交易提交给排序服务节点。
4. 排序服务节点对交易进行排序并打包成区块。
(5. 排序后的交易区块被发送给背书节点进行验证。6. 背书节点验证交易区块的合法性。7. 背书节点将交易区块提交到账本,更新世界状态和交易日志。)

4.2 Fabric交易流程的专业词简要描述:

1. 提案(Proposal):
   - 客户端应用程序创建并发送交易提案(Proposal)给目标组织的背书节点。
   - 提案包括待执行的链码操作(如读取或写入数据)和必要的参数。

2. 背书(Endorsement):
   - 背书节点收到提案后,会执行链码操作,并根据链码的背书策略验证交易的有效性。
   - 背书节点对交易进行背书,生成交易背书结果(Endorsement),该结果包含链码操作的读写集和背书节点的签名。

3. 提交(Commit):
   - 背书节点将交易背书结果返回给客户端应用程序。
   - 客户端应用程序收集足够数量的有效背书结果后,将这些结果作为交易提案提交给排序服务节点。

4. 排序(Ordering):
   - 排序服务节点收到交易提案后,将交易按照顺序打包成区块,并为区块生成区块头。
   - 排序服务节点使用共识算法(如Kafka)对交易进行排序,确保所有节点在同一顺序上达成共识。

5. 验证(Validation):
   - 排序服务节点将排序后的交易区块发送给网络中的所有背书节点。
   - 背书节点验证交易区块的合法性,包括检查交易的签名和背书结果的一致性。

6. 提交(Commit):
   - 背书节点将交易区块提交给自身的账本(Ledger),更新世界状态(World State)和交易日志(Transaction Log)。

7. 查询(Query):
   - 客户端应用程序可以向任何节点发送查询请求,获取经过确认的交易数据或当前的世界状态。

4.3 Hyperledger Fabric的关键技术包括:

1. 账本(Ledger):账本是Hyperledger Fabric中存储交易数据的核心组件。它包括两个重要的部分:
   - 世界状态(World State):记录了所有交易执行后的最新状态,提供了高效的数据查询能力。
   - 交易日志(Transaction Log):记录了所有经过确认的交易,用于实现交易的不可篡改性和可追溯性。

2. 链码(Chaincode):链码是在Hyperledger Fabric中实现业务逻辑和数据模型的智能合约。链码可以使用编程语言(如Go、Java)编写,并在区块链网络中部署和执行。链码定义了可供外部应用程序调用的接口,允许对账本进行读写操作。

3. 通道(Channel):通道是Hyperledger Fabric中用于隔离和隐私保护的机制。它可以将网络中的参与者划分为多个独立的通道,每个通道拥有自己的账本和链码。通道允许不同组织之间进行私有的交易和通信,确保交易的隔离性和安全性。

4. 节点(Node):节点是参与Hyperledger Fabric网络的计算机实体。它可以是对等节点(Peer Node)或排序节点(Ordering Node)。
   - 对等节点负责执行链码和维护账本,参与交易的背书和验证过程。
   - 排序节点负责将交易打包成区块,并为交易达成共识,确保所有节点在同一顺序上达成共识。

5. 排序(Ordering):排序服务节点负责对交易进行排序和打包成区块的过程。排序节点使用共识算法(如Kafka)确保所有节点在交易顺序上达成一致,生成有序的交易区块。排序服务节点将排序后的区块广播给网络中的背书节点和验证节点。

 6. 接口SDK(Software Development Kit):Hyperledger Fabric提供了多种语言的SDK,用于开发和集成应用程序。SDK提供了访问Fabric网络的接口,允许应用程序提交交易、查询状态、监听事件等操作。

(5)Kafka

5.1 Kafka概述:

Kafka是一个开源的分布式消息传递系统,由Apache软件基金会开发和维护。它旨在处理高吞吐量的实时数据流,具有高可扩展性和可靠性。Kafka的设计目标是提供一种高效的、持久化的、可分区的、可复制的消息系统。

以下是Kafka的一些核心概念:

1. 主题(Topic):主题是消息的逻辑分类,可以看作是发布的数据流。消息发送者将消息发布到特定的主题,而消息消费者可以订阅一个或多个主题来接收相应的消息。

2. 分区(Partition):每个主题可以被分成多个分区,每个分区是一个有序的、不可变的消息序列。分区允许在集群中进行消息的并行处理,同时提供了扩展性和容错性。

3. 生产者(Producer):生产者是消息的发送者,负责将消息发布到主题。生产者将消息发送到特定的主题和分区,可以指定消息的键(Key)来决定消息在分区中的分配策略。

4. 消费者(Consumer):消费者是消息的接收者,负责从主题中消费消息。消费者可以订阅一个或多个主题,并根据订阅的规则从分区中拉取消息。

5. 消费者组(Consumer Group):多个消费者可以组成一个消费者组来共同消费主题中的消息。Kafka将消息分发给消费者组中的消费者,每个消息只会被同一个消费者组中的一个消费者处理。

6. 偏移量(Offset):偏移量是消息在分区中的唯一标识,用于跟踪消费的进度。消费者可以使用偏移量来指定要消费的消息的位置。

Kafka的设计理念是基于发布-订阅模型和持久化日志的思想。它提供了高吞吐量的消息传递,保证了消息的可靠性、持久性和顺序性,并支持水平扩展和分布式部署。Kafka广泛应用于大规模数据处理、实时流处理、事件驱动架构等场景中。

5.2 在Hyperledger Fabric中Kafka处理流程:


在Hyperledger Fabric中,Kafka被用作排序服务的共识算法之一。

下面是基于Kafka的排序服务在Fabric中的处理流程:

1. 创建和配置Kafka集群:首先,需要创建一个Kafka集群,并进行相应的配置。Kafka集群由多个Kafka节点组成,其中包括至少一个主节点和多个从节点。

2. 配置排序服务:在Hyperledger Fabric网络的配置文件中,指定要使用Kafka作为排序服务的共识算法,并提供Kafka集群的连接信息和参数。

3. 交易提交到排序服务:当客户端应用程序提交交易时,交易将被发送到排序服务进行处理。交易可以通过客户端SDK或使用Fabric命令行工具进行提交。

4. 排序服务进行交易排序:排序服务接收到提交的交易后,对交易进行排序和打包成区块的处理。Kafka利用其发布-订阅模型和分区机制,确保在Kafka集群中所有节点上的交易具有相同的顺序。

5. 交易区块的传播:排序服务将排序后的交易区块广播给网络中的其他节点,包括背书节点和验证节点。

6. 背书和验证:背书节点和验证节点接收到交易区块后,进行背书和验证的过程。背书节点验证交易的正确性和合法性,并为交易签署背书结果。验证节点对交易进行验证,确保交易符合共识规则和网络配置。

7. 共识达成:背书节点和验证节点将其背书结果发送回排序服务节点。当排序服务节点收集到足够数量的背书结果时,根据共识算法(如Kafka)对交易达成共识。

8. 区块写入账本:排序服务节点将达成共识的交易区块写入账本,更新世界状态和交易日志。这标志着交易被永久性地记录在区块链上。

通过Kafka的发布-订阅模型和分布式的排序机制,Hyperledger Fabric确保了交易的顺序一致性和可靠性。Kafka作为一种高吞吐量的消息传递系统,为Fabric提供了可扩展的排序服务,并能够处理大量的交易和节点。

(6)SOLO

在Hyperledger Fabric中,Solo指的是一种共识模式,也称为单节点共识模式。

下面是一些关于Solo的概念解释:

1. Solo模式:Solo模式是Hyperledger Fabric中的一种共识算法,用于排序和达成共识。在这种模式下,整个网络只有一个排序服务节点,负责接收交易、排序交易和广播交易给验证节点。

2. 排序服务节点:在Solo模式下,排序服务节点扮演着排序和共识的角色。它接收来自客户端的交易,并按照接收顺序将它们排序到区块中。排序服务节点负责将排序后的交易区块广播给网络中的验证节点。

3. 验证节点:验证节点是Solo模式下的参与方,它们接收由排序服务节点广播的交易区块,并验证其中的交易。验证节点执行链码逻辑以验证交易的合法性,并更新本地的账本状态。

4. 链码执行:在Solo模式下,链码执行是在排序服务节点和验证节点上进行的。排序服务节点执行链码来确定交易的顺序,验证节点执行链码以验证交易的合法性和更新世界状态。

5. 单节点共识:Solo模式中只有一个节点参与共识过程,这意味着整个共识过程的决策权集中在单个节点上。由于缺乏分布式的共识机制,Solo模式在可扩展性和容错性方面有一定的限制。

需要注意的是,Solo模式主要用于开发、测试和学习目的,或者在小规模私有网络中使用。在实际的生产环境中,推荐使用具有分布式共识算法的共识模式,例如使用Kafka共识算法,以实现更好的性能、可扩展性和容错性。

本图文内容来源于网友网络收集整理提供,作为学习参考使用,版权属于原作者。
THE END
分享
二维码
< <上一篇
下一篇>>