一、架构图

在这里插入图片描述

1、应用层

  • API:提供GRPC,RPC框架
  • SDK:在API基础上封装的SDK,go、java、python、nodejs
  • 事件:分布式系统中,达成共识需要一定的时间,fabric使用异步通信模式开发,触发回调函数执行
  • 身份:依托于底层的成员服务,是联盟链的认证功能,例如CA
  • 账本:区块链的查询数据,是账本中查出来的,区块高度+交易ID,不重复
  • 交易:对区块链数据进行修改,先提交交易到背书节点,签名认证之后再执行
  • 智能合约:做合约的安装、实例化和升级

2、区块链底层

  • 成员服务:提供证书,用于加密和签名
  • 共识服务:CAP(不能全满足,只能满足两个,一致性、可用性和分区容忍性),实际上区块链弱化了一致性,所以需要共识算法保证一致性,fabric的共识大概分为3个阶段
    • 首先客户端向背书节点发送一个背书提案,背书节点进行交易模拟,将背书结果和签名返回客户端
    • 客户端将背书后的交易交给排序节点进行排序,由排序节点生成区块,向全网广播,网络节点收到广播后,先验证区块交易的正确性
    • 验证通过后,存入本地账本
    • PS:排序节点与组织的锚节点使用的是GRPC通信,组织内使用的是gossip协议通信;
    • 排序服务:顺序一样就认为状态是一样的,达成一个分布式一致性
  • 链码服务:提供安全的、可隔离的交易环境,所以fabric使用docker,链码直接与docker通信,目前阶段对k8s支持的不好,会出问题
  • 安全及密码服务:fabric定义了一个BCCSP接口,定义签名、加密解密等功能,默认实现了一套国际通用的密码服务,如sha256等

二、网络拓扑图

在这里插入图片描述

1、概念

  • 客户端节点:应用程序和底层的交互媒介,与上层和peer和orderer连接发挥作用,连接peer做交易模拟
  • peer节点:
    • 锚节点(主节点),在一个组织内可以有多个peer,一个组织中锚节点只有一个,锚节点的作用是与orderer进行通信,锚节点需要HA支持,若锚节点挂了,组织内会选举新的节点与orderer进行通信
    • 背书节点(endorse)理解为担保,与智能合约绑定,每一个智能合约安装到区块链中,会有一个专属的背书策略,适应企业复杂的业务需求
    • 记账节点(committer)所有的peer结点都是记账节点,用于验证从orderer接收到的区块,验证交易的有效性,验证通过后,同步到本地账本
  • orderer节点:排序节点,接受全网客户端节点的交易信息,按照一定规则进行排序,将排序好的交易,按照固定的时间间隔打包成区块,与其他组织的主节点进行通信,排序可以用solo(整个网络中只有一个排序节点,适用于开发和测试)和kafka(生产环境下使用,分布式消息队列)模式
  • CA节点:可选的,作用:颁发证书,只有被CA认证的节点才能进行交易,因此,fabric不存在51%攻击问题。

2、动作和行为

  • 注册登记:由客户端发起,向CA机构表明自己的身份,获取证书,上图中是第三方的CA,也可以使用官方提供的CA
  • 交易提案:向组织的背书节点提交请求,背书节点实际上就是peer节点,组织是独立的,可以理解为现实中的商业主体(京东、淘宝);组织的数据来源有两个(客户端来的数据用来做模拟,排序节点来的数据用来执行)
  • 提交交易:客户端节点向排序节点发请求,orderer内部进行排序打包成区块,广播给其他组织的锚节点,上图是基于kafka实现的,每个组织会选择一个orderer节点进行通信

三、交易流程图

客户端提交交易,最终到记账节点同步数据
在这里插入图片描述

  • 智能合约安装要指定背书节点,正常情况下,背书节点返回相同的结果,但签名是不一样的
  • 背书节点是模拟的过程,不会持久化
  • 1,2,3步是交易模拟;4,5步是交易排序;6,7,8,9是交易同步和记账,交易模拟对应智能合约,交易排序对应共识机制,同步和记账对应账本存储
Logo

开源、云原生的融合云平台

更多推荐