Fabric概念━━基础和架构
逻辑架构图
该图是从不同角度来划分的：上层从应用层程序的角度，提供了标准的gRPC接口，在API的基础上封装了不同语言的SDK，包括Golang、Node.js、Java、Python等，开发人员可以利用SDK开发基于区块链的应用。
区块链强一致性要求各个节点之间达成共识需要较长的执行时间，也是采用异步通信模式进行开发的，事件模块可以在触发区块事件或者链码事件的时候执行预先定义的回调函数
应用程序角度
1.身份管理
- 用户注册和登录系统后，获取到用户注册证书（ECert），其他所有的操作都需要与用户证书关联的私钥进行签名。
- 消息接收方首先会进行签名验证，才进行后续的消息处理。
- 网络节点同样会收到颁发的证书，比如系统启动和网络节点管理等都会对用户身份进行认证和授权。
2.账本管理
授权的用户是可以查询账本数据（ledger）的，这可以通过多种方式查询，包括：根据区块号查询区块、根据区块哈希查询区块、根据交易号查询区块、根据交易号查询交易、还可以根据通道名称获取查询到的区块链信息。
3.交易管理
账本数据只能通过交易执行才能更新，应用程序通过交易管理提交交易提案（Proposal）并获取到交易背书（Endorsement）以后，再给排序服务节点提交交易，然后打包生成区块。
SDK提供接口，利用用户证书本地生成交易号，背书节点和记账节点都会校验是否存在重复交易。
4.智能合约
实现“可编程的交易账本”（Programmable Ledger），通过链码执行提交的交易，实现基于区块链的智能合约业务逻辑。
只有智能合约才能更新账本数据，其他模块是不能直接修改状态数据（World State）的。
底层角度
1.成员管理
MSP（Membership Service Provider）对成员管理进行了抽象
每个MSP都会建立一套根信任证书(Root of Truest Certificate)体系，利用PKI(Public Key Infrastructure)对成员身份进行认证，验证成员用户提交交易请求的签名
结合Fabric-CA或者第三方CA系统，提供成员注册功能，并对成员身份证书进行管理，例如证书新增和撤销。
注册的证书分为注册证书（ECert）、交易证书（TCert）和TLS证书（TLS Cert），它们分别用于用户身份、交易签名和TLS传输。
2.共识服务
在分布式节点环境下，要实现同一个链上不同节点区块的一致性，同时要确保区块里的交易有效和有序。
共识机制由3个阶段完成：
- 客户端向背书节点提交交易提案进行签名背书；
- 客户端将背书后的交易提交给排序服务节点进行交易排序，生成区块和排序服务；
- 之后广播给记账节点验证交易后写入本地账本。
网络节点的P2P协议采用的是基于Gossip的数据分发，以同一组织为传播范围来同步数据，提升网络传输的效率。
3.链码服务
智能合约的实现依赖于安全和执行环境，确保安全的执行过程和用户数据的隔离。
Fabric采用Docker管理普通的链码，提供安全的沙箱环境和镜像文件仓库。其好处是容易支持多种语言的链码，扩展性很好。Docker方案的也有不足，如：对环境要求较高，占用资源较多，性能不高等，实现过程也存在与Kubernetes、Rancher等平台的兼容性问题。
4.安全和密码服务
Fabric 1.0专门定义了一个BCCSP(BlockChain Cryptographic Service Provider)，使其实现密钥生成、哈希运算、签名验签、加密解密等基础功能
BBSCP是一个抽象接口，默认是软实现的国标算法，目前社区和较多的厂商都在实现国密的算法和HSM(Hardware Security Module)
网络拓扑
- 客户端（应用程序/SDK/命令行工具）
- Peer（Anchor/Endorser/Committer）
- Orderer
- CA
节点架构图
客户端节点
客户端或者应用程序代表有最终用户操作的实体
- 它必须连接到某一个Peer节点或者排序服务节点上与区块链网络进行通信
- 客户端向背书节点（Endorser）提交交易提案（Transaction Proposal）
- 当收集到足够背书后，向排序服务广播结义，进行排序，生成区块
Peer节点
所有的Peer节点都是记账节点/提交节点（Committeer），负责验证从排序服务节点区块里的交易，维护状态数据和账本的副本
部分节点会执行交易并对结果进行签名背书，充当背书节点。背书节点是动态的角色，是与具体链码绑定的。每个链码在实例化/定义的时候都会设置背书策略，指定哪些节点对交易背书后才是有效的。也只有在应用程序向它发起交易背书请求的时候才是背书节点，其他的时候就是普通的记账节点，只负责验证交易并记账。
每个安装了智能合约的 Peer 节点都可以作为一个背书节点。然而，想要成为一个真正的背书节点，节点上的智能合约必须要被客户端应用使用(实际被调用)，来生成一个被签名的交易响应
Peer节点还有一种角色是主节点（Leader Peer），代表的是和排序服务节点通信的节点，负责从排序服务节点处获取最新的区块并在组织内部同步。可以强制设置为主节点，也可以动态选举产生
对于静态选择，0个或者多个节点可以被配置为主节点；对于动态选举，一个节点会被选举成为主节点
另外一种角色是锚节点，如果一个 Peer 节点需要同另一个组织的 Peer 节点通信的话，它可以使用对方组织通道配置中定义的锚节点。
需要注意的是，一个 Peer 节点可以同时是一个提交节点、背书节点、主节点和锚节点。在实际情况中只有锚节点是可选的，一般都会有一个主节点，至少一个背书节点和一个提交节点
排序服务节点
排序服务节点（Ordering Service Node或者Orderer）接收包含背书签名的交易，对未打包的交易进行排序生成区块，广播给Peer节点。
排序服务提供的是原子广播（Atomic Broadcast），保证同一个链上的节点接收到相同的消息，并且有相同的逻辑顺序。
排序服务的多通道（MultiChannel）实现了多链的数据隔离，保证只有同一个链的Peer节点才能访问链上的数据，保护用户隐私。排序服务可以采用集中式服务，也可以采用分布式协议。
1.0版本只支持Apache Kafka集群，提供交易排序的功能，只实现CFT(Crash Fault Tolerance，崩溃故障容错)，不支持BFT(Byzantime Fault Tolerance，拜占庭容错)
CA节点
CA节点是证书颁发机构（Certificate Authority），由服务器和客户端组件组成
CA节点接收客户端的注册申请，返回注册密码用于用户登录，以便获取身份证书，在区块链网络上所有的操作都会验证用户的身份，CA节点是可选的，可以用其他成熟的第三方CA颁发证书。
交易流程
通道以及网络配置
一旦通道被创建后，它是由定义的组织来管理的，独立于网络中的其他元素。通道策略通常是保持彼此分离的，并且只能由通道中授权的组织来进行改动。
- 独立于其他通道以及整个网络配置NC
- 网络和通道的配置在逻辑上是独立的，网络会有一个配置，每个通道也会有一个配置（应用程序通道）
- 尽管在逻辑上是独立的配置，实际上它会被复制到组成网络或者通道的每个节点，并保持一致（节点都有对应通道配置CC的副本，每个排序服务节点都会有他们自己的关于网络配置的副本）
- 想要改变网络或者通道的配置，管理员必须要提交一个配置交易来改变网络或者通道的配置。该交易必须被对应策略中指定的组织签名
- 排序服务节点运行着一个小型的区块链，通过系统通道连接（分发网络配置交易，用来维护每个排序服务节点间网络配置副本的一致性）
- 系统通道的通道配置（排序通道）是网络配置 NC 的一部分
随着网络和通道的发展，网络和通道的配置也会升级。引入包含配置变更的配置交易。每次配置的改变会生成一个新的配置区块，最后更新相关网络及通道的配置。
一个基本的网络拓扑
这个 Fabric 区块链网络包括了两个应用程序通道以及一个排序通道。组织 R1 和 R4 负责排序通道，R1 和 R2 负责蓝色的应用程序通道，R2 和 R3 负责红色的应用程序通道。客户端应用程序 A1 是组织 R1 的元素，CA1 是它的证书颁发机构。注意到组织 R2 的节点 P2 可以使用蓝色的通道，也可以使用红色的应用程序通道。每个应用程序通道具有它自己的通道配置，这里是 CC1 和 CC2。系统通道的通道配置是网络配置 NC4 的一部分
上图是一个有四个组织 \(R_1,R_2,R_3,R_4\) 的网络，带有两个通道 \(C1,C2\) 和三个 Peer 节点，两个智能合约 \(S_5,S_6\) 和一个排序服务。并由四个证书颁发机构来支撑。它为三个客户端应用程序提供了账本及智能合约服务，这些应用程序可以通过两个通道与账本和智能合约进行交互。
说明
- 链码的安装
当一个组织在一个通道中有多个 Peer 节点时，可以选择在哪个节点安装智能合约/链码，而不需要每个 Peer 节点上都安装。
- 安装链码和定义链码的区别
尽管链码会被安装在组织的 Peer 节点上，但是它是在一个通道范围内被管理和维护的。每个组织需要批准一个链码定义，和一系列参数来定义在一个通道中链码应该被如何使用。一个组织必须要批准一个链码定义，才能使用已经安装的智能合约来查询账本和为交易背书。
在链码定义能够被提交到通道并且用来同通道账本进行互动之前，需要有效数量的组织来批准一个链码的定义（默认为大多数）
实际上是定义并提交了智能合约的接口到通道，而不是安装了智能合约的实现。安装智能合约是如何将它物理地存储在 Peer 节点上，而实例化智能合约是如何将它逻辑地存储在通道中。
只有安装了智能合约的 Peer 节点才能够参与交易背书的流程(才能运行它)，这是生成一笔有效交易的核心
- 背书策略是怎么关联链码的？
背书策略：描述了在交易被其他的组织接受并存储在他们的账本副本上之前，哪些组织必须要同意此交易。
将链码定义提交到通道的同时背书策略也会被放置在通道账本上，通道中的每个成员都可以访问该策略。
- 向通道中添加组织和节点后需要重新批准链码的定义吗？
链码定义提交到通道的交易只需要发生一次，通道中新的组织批准了通道中其他成员已经同意的链码参数之后就可以使用该链码了。链码定义的批准是发生在组织级别的，一个组织批准链码定义一次，就可以将多个节点加入到安装了链码包的通道。
如果想让新组织的节点Peer来生成交易，该节点就必须安装了该智能合约
- 多组织提供的排序服务节点是怎么管理网络资源的？
如果排序服务包括排序服务节点 O1 和 O4。O1 是由组织 R1 提供的，O4 是由组织 R4 提供的：网络配置策略 NC中定义了来自 R1 和 R4 的操作者的网络资源权限。R1 和 R4 的客户端应用程序和 Peer 节点可以通过连接 O1 或者 O4 来管理网络资源，就像在网络配置 NC4 中定义的策略一样
- 如何解决双花？时间接近的2个交易如果怎么检查合法性呢？
验证阶段可以检查读写集进行验证
浙公网安备 33010602011771号