Fabric-01模型及交易流程

内容及图片整理自IBM开放技术微讲堂

一、Fabric Characteristic

• 多重认证机制
• 高度模块化
• 通用语言编写智能合约
• 可插拔的共识机制
• 隐私性
• 没有挖矿
• 执行-排序-验证 vs 排序-执行

二、Fabric Model

Fabric模型示例图（以一个channel为例）：

2.1Organization

fabric中最小单位是组织Organization。组织可以是工厂、零售商、批发商或者监管机构等，它们之间组成了一个联盟，每个都是以组织的名义参与到网络中。

组织是由MSP（Membership Service Provider）来唯一标识的。

2.2Identity

每个组织背后都是由人来组成，每个人都需要一个标签Identity。每个人从技术上来说其实就是一对公私钥对以及相应的证书。每个人都需要用代表自己的私钥在联盟链中进行操作和交互。

2.3Consortium

有了组织，这些组织之间就可以组成一个联盟Consortium。

2.4Channel

在联盟之内，可以创建不同的通道Channel，通道可以理解成作用域。

2.5Smart Contract

有了通道就可以创建智能合约Smart Contract，智能合约的作用域是在一个通道内部，智能合约里包含了业务逻辑。

2.6Endorsement

Fabric中比较独有的一个特点是背书策略Endorsement。Fabric作为许可链，需要很好的去反映一个商业逻辑，所以用背书策略来做一个商业逻辑的描述。书写规则主要包括：Majority_of、And、Or等，比如Majority_of(OrgB, OrgC, OrgD) AND OrgA的意思就是B、C、D三个组织中需要大多数同意，并且需要A组织来同意，A有一票否决权。好比现实中一笔交易，作为监管机构A必须同意，工厂、零售商、批发商BCD组织中大多数同意，这笔交易才生效，否则无效。

2.7Private Data

Fabric中进一步对隐私数据的保护就是隐私数据Private Data。隐私数据可以在一个通道内部进一步对数据进行隔离。比如说工厂生产货物，分别发给批发商和零售商，其中批次、货号对所有人公开，但是价格是敏感信息，不想让零售商看到批发价格，就可以用隐私数据的功能来实现，也就是敏感数据只给隐私数据集合内的人看到，保护数据不被集合外部的人看到，但是该数据的Hash依然会被所有人共享。

随着网络的不断扩张，联盟内可能会有越来越多的组织，通过创建不同的通道，可以把整个联盟划分为不同的作用域：

在组织内部的几个模块：

CA：与传统CA类似，给所有参与到网络中的实体（用户以及参与到网络中的节点）签发相应的证书。在本地生成公私钥对，然后用公钥去申请证书，最后 用证书以及本地存储的私钥作为身份标识在网络中进行交互。

节点：Fabric中的节点分为peer和orderer，这些节点参与到网络中也有自己的身份，通过自己的身份来与网络交互。比如peer节点做背书，就用自己的私钥来进行签名。每个组织内跑这些节点，这些节点通过网络进行连接，进而组成整个fabric网络。

三、Fabric Tx Flow

3.1Proposals

用户通过SDK/CLI根据背书策略将Proposal发给相应的背书节点，希望背书节点对Proposal进行背书。

3.2Execute

背书节点拿到Proposal之后，会本地模拟运行智能合约（不会真正修改账本），运行之后会产生读写集RW set。比如一发送方(balance=100)户转给接收方(balance=80)10个币，那么产生的读集可能就是发送方原本账户的余额100以及版本号1，如果按照k-v形式看，就是{key=balance1，value=100} version=1,写集就是把余额100改成90以及版本号加1，{key=balance1，value=90} version=2；接收方同理，读集就是{key=balance2，value=80} version=1，写集就是{key=balance2，value=90} version=2，至此读写集也就相应的产生。

3.3ProposalResponse (Endorsed)

产生读写集之后，每个背书节点会对读写集进行签名，然后返回给用户SDK/CLI。

3.4Broadcast

用户SDK/CLI拿到满足条件的签名之后，比如收集到足够的签名，就会把签名整合起来，一起发送给orderer节点。

3.5Order

orderer节点拿到签名后，不会看交易内容，只会对接收到所有的transaction进行全排序，完成排序之后，按照一定的规则打包成区块。

3.6Deliver

orderer节点会把产生的区块分发给所有的peer节点。

3.7Validate & Commit

peer节点拿到区块后，会把所有的区块打开，看到里面的transaction，对transaction进行验证Validate。验证读写集是否根据背书策略，接收到足够的签名；验证读写集版本号，比如读集是1，写集是2，记账节点会验证现在的账本状态key的版本号是否还是1，如果是，就说明这个key在异步的时间里，并没有被更新过，因为version没有变。

验证通过的transaction会被提交Commit到账本Ledger。

3.8Notify

最后peer节点会向用户端发送notification，告诉用户交易已经提交。至此完整的交易流程结束。

Fabric对于双花问题(Double Spending)的预防：

例如A账户余额是10，给B转10，同时给C转10，如果成功就是双花问题。那么在fabric中，这两笔交易在背书节点模拟执行都是成功的，也就是这两笔交易都会产生读写集，都会签名，但是产生的读集version都是1，写集version都是2；中间过程没有变化，直到最后记账节点进行验证的时候，因为orderer节点对交易进行了全排序，所以一定有一笔交易在另一笔前面，比如A->B在前，那么当记账节点拿到该交易之后，先验证读集version是1，写集version是2，当前账本状态也满足条件，会更新账本，把账本的key的version改成2；但是当拿到第二笔交易A->C的时候，进行验证会发现读集version是1，与当前账本不匹配，拒绝该交易，也就是说双花问题在这一步得到了解决。

四、What’s new in 2.0

1. 分布式合约管理
2. 对于多方投票新的链码编程范式，fabric内部内建了这样的机制来使用。
3. 私有数据加强
4. 服务的方式启动智能合约
5. CouchDB增加了缓存层来提升性能
6. docker镜像都是基于Alpine而不再是Ubuntu，体积更小，速度更快
7. Fabric源码由GitHub来管理