fabric知识梳理图解

1.整体架构

2、交易流程

 

流程步骤：

1. 应用程序通过SDK发送请求到Peer节点（一个或多个） 即发起交易
   1. 客户A发起交易请求：合约设置的背书策略规定所有交易需要经过两个Peer节点的签名背书，因此请求需要被同时发往Peer A和Peer B.
   2. 客户端应用程序利用任意SDK（nodeJS，java，go）构造交易提案。该提案是一个调用智能合约功能函数的请求，用来确认哪些数据可以读取或写入账本（即更新资产的Key/Value）。
   3. SDK将交易提案打包为可识别的格式（如gRPC上的protocol buffer），并使用用户的加密凭证为该交易提案生成唯一的签名。
2. peer节点（Committer节点）通过chaincode分别执行交易，但是并不将执行结果提交到本地的账本中 （可以认为是模拟执行，交易处于挂起状态，放置于候选池）
   1. 参与背书的peer将执行结果返回给应用程序（其中包括自身对背书结果的签名）
   2. 背书节点（使用MSP）验证签名（ProcessPropsal()->preProcess()-->Verify()验证签名）并确定提交者是否有权执行操作（使用通道的ACL）。
   3. 背书节点将交易提案的参数作为输入，在当前状态数据库上执行交易，生成包含执行返回值、读操作集合和写操作集合的交易结果（此时不会更新账本），这些值的集合、背书节点的签名和背书结果（YES / NO）作为“提案的结果”返回给SDK
   4. SDK解析这些信息判断是否应用于后续的交易。
3. 应用程序收集背书结果并将结果提交给Ordering服务节点
   1. 应用程序（SDK）验证背书节点签名，并比较各节点返回的提案结果，判断提案结果是否一致以及是否参照指定的背书策略执行。
   2. 应用程序（SDK）将交易提案和结果以消息形式广播到排序服务(Orderers/Consenter)。交易包含读/写操作集合、背书节点的签名和通道ID。
   3. 排序服务不读取交易的详细信息，它从整个区块链网络接收交易信息，按通道分类进行排序，并为每个通道创建包含交易的区块。
4. Ordering服务节点执行共识过程并生成block，通过消息通道发布给Peer节点（所有节点包括committer, submitter, endorser），由peer节点各自验证交易并提交到本地的ledger中（包括state状态的变化）
   1. 排序服务将区块发送到通道上的所有节点，所有交易需要被验证，确保满足背书策略
   2. 同时，需要确保全部读操作集合在交易生成之后，账本上的状态值没有改变。
   3. 经过验证，区块中的交易会被标记为有效或无效，通过Event通知客户端
5. 所有节点账本更新
   1. 所有通道上的区块链节点将新区块加入区块链，并且对于所有有效的交易，将写操作集合提交更新到状态数据库中。
   2. 节点通过事件(Event)通知客户端交易是否已被加入区块链、以及交易是否有效。

问题1：committer 如何验证区块提交交易的有效性？

           —— 验证交易读写集中的读集（刚刚读取到的）、世界状态、之前未被提交的写集（模拟交易过程）的状态是否一致。

问题2：Fabric中的MSP的作用是什么？

         ——Fabric中的MSP可以理解为账号，是根据PKI规范生成的一组证书和秘钥文件。Fabric中的组织、节点、用户都拥有各自的MSP账号信息，这种机制的好处是可以保证网络中的用户数量是可控的并且用户都是被授权的。fabric基于这样的MSP账号体系保证了网络中的每条交易都有发起人的数字签名，而且背书节点也会在交易中加入自己的签名，保证了交易过程的清晰透明，不可篡改。

      Fabric中的orderer、peer、客户端等操作都需要使用MSP账号。比如：启动orderer节点、启动peer节点、创建通道、部署链码、调用链码、peer向orderer发送请求。

3、多通道

 

4、账户存储

5、智能合约交互

6、应用开发模型

7、节点说明

peer节点包括：Endorse（背书节点）、Anchor（锚节点）、Leader（leader节点）、commit（提交节点）。背书节点负责背书策略，提交节点负责数据的提交。

首先所有的peer节点都是committer（记账节点），而又有可能担任的角色有endorser（背书节点）、Leader（主节点）、Anchor（锚节点）。

Committer

记账节点使用基于Gossip的p2p数据分发，节点会定期跟其他节点交换信息。如果在这个过程中有节点发生故障，则会从存活的节点中删除这个节点的信息。对于故障节点，还会定时检查是否已经恢复，恢复存活的节点会更新到存活节点列表中。如果有新加入的节点，也能通过节点信息的交换获取到，添加到存活列表中，广播给其他节点。由于超级账本采用基于反熵的状态同步，每个节点周期性的和邻居节点交换保存的数据，然后对比本地数据和邻居节点所保存的数据，检查是否有缺失或者过期的数据，然后更新本地节点的数据为最新的数据，因此故障的节点重新连接到网络时会自动恢复数据。这些都能通过Gossip协议学习到，自动调整网络的拓扑结构，适应网络节点的变化，保证整个网络正常运行。并且协议能正确工作的概率不会因为错误数超过f（可靠的广播协议中存在一个f，错误数超过这个值就会出现异常，协议的可靠性等于不超过f个错误的概率）时就快速地降低。（优雅降级）

Leader

主节点连接到排序服务，负责把接受到的批量区块转发给其他节点。因此主节点与排序服务的稳定连接至关重要。可以强制设置为主节点，也可以动态选举产生。主节点选举的用处是，判断在相同的组织中哪个节点可以作为代表连接排序服务。选举过程在Gossip层实现，一个节点启动的时候它先等网络稳定再开始参与主节点选举，一次主节点选举的有效时间是10s。这样可以有效避免强制设置主节点出现的发生故障无法分发区块的问题。

Endorser

背书节点为动态的角色与具体的chaincode绑定，背书节点的故障对网络的影响取决于chaincode对应的背书策略，例如背书策略指定只要3个组织其中的2个组织的成员完成背书，该交易就是有效的，那么只有一个组织的成员节点出现故障对交易完成没有影响。

Anchor

锚节点是在一个channel上可以被所有其他peer发现的peer，channel上的每个成员都有一个anchor Peer(或多个anchor peer 来防止单点故障)，允许属于不同成员的peer发现channel上的所有现有peer。锚节点的配置文件可以通过configtxgen工具生成。

锚节点负责组织之间通信，如上图。

Leader节点负责与order节点通信，如上图。

8、网络拓补结构

9、数据库

账本由区块链和状态数据库两部分组成。
区块链是一组不可更改的有序的区块（数据块），记录着全部交易的日志。每个区块中包含若干个交易的数据，不同区块所包含的交易数量可以不同。区块之间用哈希链（Hashed-link）关联：每个区块头包含该区块所有交易的哈希值以及上一个区块头的哈希值。链式结构可以确保每个区块的数据不可更改以及每个区块之间的顺序关系不可更改。因此，区块链的区块只可以添加在链的尾部。
状态数据库记录了账本中所有键值对的当前值，相当于对当前账本的交易日志做了索引。链码执行交易的时候需要读取账本的当前状态，从状态数据库可以迅速获取键值的最新状态。
如果没有状态数据库，要获得某个键值时，需要遍历整个区块链中和该键值相关的交易，效率非常低，因此，读取状态数据库可以认为是快速定位和访问某个键值的方法。另外，当状态数据库出现故障的时候，可以通过遍历账本重新生成。
当一个区块附加到区块链尾部的时候，如果区块中的有效交易修改了键值对，则会在状态数据库中作相应的更新，确保区块链和状态数据库始终保持一致。
区块链的数据块以文件形式保存在各个节点中。状态数据库可以是各种键值数据库，Fabric缺省使用LevelDB ，也支持CouchDB的选项。CouchDB除了支持键值数据外，也支持JSON格式的文档模型，能够做复杂的查询。

转载 https://blog.csdn.net/weixin_42117918/article/details/85230754