区块链就是分布式的账本，智能合约，共识（如何在不同peers当中，达成一致）
区块链网络是技术基础设施，为应用程序提供ledger和smart contract(chaincode)服务
1 整体对比
bitcoin ：公链 powd
Ethereum：公链 智能合约
Fabric：有权限
智能合约语言支持java，go，node.js
插件化的共识协议，可以选择不同的trust model，部署在单个企业内部，或者可信的权威机构时，crash fault-tolerant (CFT) 协议即可。如果是多方分散环境，byzantine fault tolerant(BFT)拜占庭容错
共识不需要挖块，提高的交易的处理和确认延迟
交易和合约的隐私性和机密性是通过chaincode来实现的
2 fabric介绍
2.1模块化
ordering service建立了对事物顺序的共识，然后将块广播给peers
membership service提供者负责将网络中的实体和加密标识关联起来
点对点的gossip协议来通过ordering service来传播块
智能合约(chaincode)在docker中运行进行隔离。他们可以用标准编程语言来写，但是不能直接访问分类账状态
账本可以支持各种DBMS
一种可插拔的认可和验证策略实施，可以为每个应用程序单独配置
2.2 许可和无许可的blockchains
公链使用pow
许可链，联盟链和私有链采用CFT和BFT
有许可的这种场景通过合约作恶会降低，因为governance model中，每个节点身份都可获取到
2.3 智能合约
fabric中又叫chaincode，它是可信任的分布式应用程序，区块链程序的业务逻辑
现在都是order-execute订单执行架构：验证和顺序交易，广播给peer nodes，每个peer，顺序执行交易
order-execute架构所有存在的blockchain systems，ethereum，到许可链的Tendermint，Chain和Quorum
2.4 A new approach
execute-order-validate
执行交易，检查正确性，从而背书
通过pluggable consensus protocol来订阅事物
在提交到ledger之前，通过特定于应用程序的背书策略来验证交易
2.5 隐私和保密性
如果是公链环境，所有人都能看到你的信息
fabric通过通道来实现隐私和机密性。通过channel建立一系列参与者的集合，所有相关交易信息和合约只有在channel里的人才可以获取
2.6 可插拔的共识
事物的执行顺序是由ordering service来负责。
这样是和execute transactions执行事物和maintain the ledger维护账本是分开的
fabric有一定的信任假设，所以目前共识是CFT(crash fault tolerant)和BFT(byzantine fault-tolerant) ordering
fabric支持两种CFT，第一种是基于raft协议的etcd库，第二种是kafaka(内部是zookeeper)
另外，fabric可以支持不同的ordering service来支持不同的应用
2.7 性能和规模
区块链的性能受到transaction size，block size，network size， limits of the hardware
fabric有开源工具caliper
3.new的2.0 alpha的改动
安全chaincode的升级过程：之前是升级合约，由一个组织发起，可能会对从未安装过chaincode的升级造成风险。新的模型是必须在足够多的组织同意后才可以升级chaincode
raft ordering service：引入了leader-and-follower模型，where a leader node is elected (per channel) and its decisions are replicated to the followers
4 key concepts
4.1 介绍
分布式账本
智能合约
共识：1.当transaction被很多恰当的参与者同意后，才会更新ledger
2.当更新ledger时，相同的顺序相同的交易
shared，replicated的transaction system
为什么区块链有用？共享
为什么hyperledger fabric？私有和有权限，加入节点是有身份共识的，成员都通过membership service provider(MSP)来提供
账本数据可以以不同的format来存储
channel：保证只有可以在一个团体内独立共享ledger
- Shared ledger：两个子ledger，world statue(描述账本在给定时间的一个state)和transaction log
- Smart contracts:智能合约用链码编写，当应用程序需要与ledger
交互时，由区块链外部的应用程序调用。在大多数情况下，链码只与database componet of the ledger、world state（例如查询它）交互，而不与transaction log交互。 - consensus：
交易必须按交易顺序写入分类账
4.2 hyperledger fabric functionalities
4.3 model
asset
chaincode
ledger features
privacy
security & membership services
consensus
4.4 blockchain network
应用通过smart contract生成交易，然后这些交易随后分发到网络中的每个对等节点
summary：
ledger，smart contract，peer nodes，ordering service，channel，certificate authority
4.4.1 creating the network
order启动网络，单独的O4，相关的网络配置NC4，赋予O4 administrator的权限。CA4向R4颁发administrator和网络节点分配身份
4.4.2 adding network adminstrators
4.4.3 defing a consotium
x1: O1, O2, O3
4.4.4 creating a channel for a consortium
NC网络配置和CC信道配置是独立的
4.4.5 peers and ledgers
真正的组件，当peer的标识是由CA1颁布的，确定它属于O1，P1启动和O4链接，O4得到请求后，通过CC1来确定P1的权限。
4.4.6 applications and smart contract chaincode
R1充分参与网络
A1通过S5和分类账L1交互，生成由R1背书的交易(request&&response)，然后被ledger接受
4.4.7 network completed
peers的类型：committing peer，endorsing peer。leader peer(order的共识)， anchor peer（跨组织的比如peer1链接O2的peer）
4.5 Identity
无论是peers，orders，client applications，administrators还是其他，都在X.509数字证书中存有数字身份，决定权限
membership servie负责权限，它默认使用X.509的证书来作为身份，采用传统PKI层次模型
key elements of PKI
数字证书
公钥和私钥
证书颁发机构
证书吊销列表
4.6 Membership
Local and channel MSPs
local：确定自己在网络中的身份，定义了在这个级别管理和参与权限的人员
channel：在channel层级上，确立了管理权和参与权
4.7 Policies
system channel
application channel
4.8 Peers
应用的交互过程
Transaction flow
1.client initiates transaction
client 通过sdk调用chaincode生成response，然后generate tx，加上签名
2.Endorsing peers verify signature & execute the transaction
背书的peers验证 1交易提案格式正确 2在过去没有被提交（重放攻击保护）3签名有效MSP 4提交者clientA被授权可以操作 背书会预执行一遍，生成事物结构，读写集校验，如果ok，将背书签名返回给sdk
3.Proposal responses are inspected
应用程序提交前，检查需要的背书服务节点peerA，peerB是否都已经签名
如果只是query，检查下提案答复，ok就行
如果是update ledger，需要发送到ordering，这里会检查各个背书节点的response是否一致
如果application，不检查背书，强制发送到ordering，在后续的validation阶段也会强制校验
4.Client assembles endorsements into a transaction
客户端组合好交易，channel ID和背书签名，发送到ordering
ordering只会根据channel ID和时间把交易打包，创建blocks
5.Transaction is validated and committed
blocks被传递到channel的peers中，满足背书策略，并确保自事物生成读写集以来，没有更新读写集状态
6.ledger update
peers追加block到channel的链，然后将write set写到state database，每个对等方都会发出事件，通知client，事物已经不可变的增加到channel的链里。通知事物已经验证或者无效
peers and identities
peers and orders
第一阶段：application到背书节点上，做预执行，拿到背书签名
第二阶段：单独的背书作为交易一起收集并打包成块
fabric没有分叉，因为在order中，打包到block，就已经确定了顺序
第三阶段：这些块再分发给peers，做一遍validation，然后更新ledger
包括交易数据的完整性检查、是否重复交易、背书签名是否符合背书策略的要求、交易的读写集是否符合多版本并发控制 MVCC （ Multiversion Concurrency Control ）的校验等等。当交易通过了所有校验之后，将被标注为合法并写入账本中。因为所有的确认节点都按照相同的顺序检验交易，并且把合法的交易依次写入账本中，因此它们的状态能够始终保持一致。
chaincode的部分，只在背书节点上执行
当块最终会commit到ledger上时，peers会生成适当的event，块事件包括完整的块内容，块的事物事件只包括每个transaction是否已被验证或者无效。应用程序可以注册这些事件类型，以便在发生时通知他们
总结：This entire transaction workflow process is called consensus
整个transaction flow图
4.9 Smart Contracts and Chaincode
智能合约是一个个逻辑，chaincode就是把所有有关联的contract打包，一起部署
smart contract
ledger
endorsement：背书策略决定tx是否有效，不管invalid or valid都会写到ledger中，标记tx是否有效或无效。但是world state只会由有效的交易更新。背书策略只是其中的一种
valid transactions
channel
system chaincode：生命周期系统链码，配置系统，背书系统，验证系统
4.10 Ledger
world state：存储当前所有值的数据库
blockchain: 文件形式存储，通过加密的hash，链接起来来做到不可篡改
DLT(distributed ledger technology): 逻辑上是单数的，在网络中有许多一致的副本
blocks：
block header：block number，current block hash，previous block head hash
block data：transactions
block metadata：块写入的时间，验证，公钥和块作者的签名。添加valid/invalid的标签
transaction：
Header：metadata，相关的chaincode，version
Signature：
proposal：
response：rw set
endorsements:
world state database options
LevelDB and CouchDB(存储json信息，复杂)
namespace channel
4.11 The Ordering Service
联盟链：可信环境，只有消息丢失或者重复，没有错误消息，无作恶。paxos和raft
公链：pow，pos，dpos，bft
probabilistic consensus：概率性的一致性算法
deterministic consensus：确定性的一致性算法，不会引起分叉
分离了execution和order，提升性能和可伸缩性
处理transaction和configuration
raft
leader and follower模型
在一个信道中，同意者集合。leader的消息会复制到follower。系统可以承受leader节点的丢失。只要大多数有序节点>1/2存在，CFT。能保证系统的正确使用
log entry，consenter set， Finite-State Machine (FSM)，Quorum，leader，follower
Raft节点总是处于以下三种状态之一：follower、candidate或leader。所有节点最初都是从一个跟随者开始的。在这种状态下，他们可以接受领导人的日志条目（如果已当选），或者投票选举领导人。
如果在设定的时间（例如，5秒）内未接收到日志条目或心跳信号，则节点会自提升到候选状态。
在候选状态下，节点请求来自其他节点的投票。
如果一个候选人获得法定票数，那么他就被提升为领导人。领导者必须接受新的日志条目并将其复制到追随者。
kafka
消息队列Kafka是一个分布式的、高吞吐量、高可扩展性消息队列服务，广泛用于日志收集、监控数据聚合、流式数据处理、在线和离线分析等，是大数据生态中不可或缺的产品之一
Broker：消息处理节点，主要任务是接收producers发送的消息，然后写入对应的topic的partition中，并将排序后的消息发送给订阅该topic的consumers。 大量的Broker节点提高了数据吞吐量，并互相对partition数据做冗余备份（类似RAID技术）。
Zookeeper：为Brokers提供集群管理服务和共识算法服务（paxos算法），例如，选举leader节点处理消息并将结果同步给其它followers节点，移除故障节点以及加入新节点并将最新的网络拓扑图同步发送给所有Brokers。
Producer：消息生产者，应用程序通过调用Producer API将消息发送给Brokers。
Consumer：消息消费者，应用程序通过Consumer API订阅topic并接收处理后的消息。
Broker上的消息布局
Kafka将消息分类保存为多个topic，每个topic中包含多个partition，消息被连续追加写入partition中，形成目录式的结构。一个topic可以被多个consumers订阅。简单来说，partition就是一个FIFO的消息管道，一端由producer写入消息，另一端由consumer取走消息（注意，这里的取走并不会移除消息，而是移动consumer的位置指针）。
Hyperledger Fabric中的每个channel对应一个topic（topic名称就是channelID），每个topic只有一个partition（0号分区），没有利用到多分区的负载均衡特性。每条交易信息对应partition中的一个record消息记录，形成一条有序的交易信息链，最后，经过分割打包后，形成区块链，写入committing peer节点。
4.12 Private data
4.13 Channel capabilities
4.14 Use cases
5 application
application design elements
5.1 contract names
5.2 chaincode namespace
5.3 transaction context
stub：world state data APIs：getState(), putState(), deleteState()
getStateByRange()
private data APIs: getPrivateData(), putPrivateData(), deletePrivateData()
getPrivateDataByRange()
transaction APIs: getTxID(), getTxTimestamp(), getCreator(), getSignedProposal()
key APIs:
event APIs:
Utility APIs:
5.4 transaction handlers
5.5 endorsement policies
5.6 connection profile
5.7 connection options
5.8 wallet
5.9 gateway
6 architecture reference
6.1 transaction flow
6.2 CA's user guid
6.3 sdks
6.4 service discovery
6.5 channels
6.6 couchDB as the state database
6.7 peer channel-based event services
6.8 private data
6.9 read-write set semantics
read set：key和version
write set：key and new value(也可能是删除标记)
6.10 gossip data dissemination protocol
leader peer从ordering service 拉取block，然后通过gossip同步到本channel的其他peers
leader election
static
dynamic
