Fabric笔记-Orderer
第五讲 Orderer解析 (IBM 开放技术*微讲堂 超级账本Fabric v1.4 LTS系列课程)
大纲：
- 原子广播（全排序）
- channels
- solo/kafka/raft
- permission in Orderer
Fabric的Execute-Order-Validate共识模型，即先执行再排序最后验证的过程。
一个交易的生命周期：
- client先想peer提交一个议案；
- peer执行智能合约，调用数据执行操作，peer将操作结果发送给orderer；
- orderer将收到的所有的议案排序，打包成区块，并发送给Peer;
- Peer打开每个区块，并进行验证，若验证通过，则写入本地账本，更新世界状态，最后想client发送event告知交易被提交到账本中。
Atomic Broadcast(Total Order):
一堆交易–>orderers：将交易排序，打包成块–>各个账本写入全局有序的区块
全局排序要求：全局唯一、容错(cft、bft)、网络分区（分区出去的节点的限制）、强一致性、bft(fabric v1.4 的orderer是cft,并不代表fabric是cft)
Block Cutting（打包规则）：
-
BatchSize:
- MaxMessageCount
- AbsoluteMaxBytes
限制单个交易大小，超过该限制，会被拒绝掉 - PreferredMaxBytes
综合可能超过PreferredMaxBytes,假设PreferredMaxBytes=200b,前9个交易大小为100b,第10个交易大小为200b,这时会把第10个交易一块打包，这样就会大于PreferredMaxBytes。
-
BatchTimeout
- Timeout
配置交易，不遵循上述打包规则，每个配置交易都会形成一个块，因为配置需要尽快生效。
Channels:
Orderer启动需要Genesis block,Genesis block规定了System Channel的配置。
System Channel是管理链，当要创建一个用户链的时候，是要向System Channel发送一个创建用户链的交易，System Channel会将发送来的用户链的配置信息等作为用户链的Genesis,放在系统中。
Join peers操作，就是将User Channel Genesis从System Channel拿下来，然后送给peer,让peer指导去哪找到orderer节点，配置信息中包括了Orderer的锚节点（即endpoints)、涉及的哪些组织。
配置交易，不遵循上述打包规则，每个配置交易都会形成一个块，因为配置需要尽快生效。
Consensus:
- solo
只有一个节点，只能用于实验，只要完成序列化就行，在Fabric集成测试中，大多用solo写的。 - kafka
kfk+zk完成了排序，其内部也是raft排序。全局时钟，通过TTC划分切割打包成块。 - raft
base on etcd/raft library;
No kfk/zk dependency;
Necessary commnunication layer built for future use,加入了点对点的通讯层;
each channel runs on its own raft instance;
A channel can run on a subset of orderers;
All orderers should belong to system channel,否则新创的channel服务从system channel中拿到；
Nodes are identified by TLS cert,在配置channel的时候，定义一个集合，告知该链中有哪些节点，这个定义用tls cert进行一一映射的。
v1.4.2 Support migrating from kafka to Raft
kfk是对Tx进行共识，但在Raft里是对块进行共识，即拿到Tx先由raft leader打包成块，然后再发送给follow进行共识，最后存放到本地账本中。
Permission in Orderer:
-
ImplicitMeta Policy:ANY,ALL,MAJORITY
其本身不决定，而是结合了其他策略进行 -
Signature Policy:NOutOf(AND,OR)