上周小结
从上周的Hyperledger Fabric构架简述之二 节点，我们知道关于节点的基础。
- 节点是 chaincode， Blockchain Ledger的载体。
- 一个节点可以包含多个 Blockchain Ledger, 而一个 Blockchain Ledger为多个 chaincode提供服务。
- 每个节点上都有一个默认的 system chaincodes
这一周，我们继续一起了解应用与节点的关系。以及他们是怎么完成一次交易，并且把交易广播出去的。
一次交易的旅程
一个外部应用，比如安卓上的一个应用，可以通过 Hyperledger Fabric Software Development Kit (SDK) 里面提供的 APIs 来连接节点，触发 chaincode，生成交易，通过 ordered（排队，排序） 之后，被广播到网络其他节点上。
从一个应用的角度：
- 通过API链接节点
- 尝试激活智能合约
- 收到节点的回复（在回复之前，节点会激活请求的智能合约，智能合约生产指令，更新回复）
- 把收到的回复，提交给排序节点（排序节点会做相关确认，然后把这次交易的信息排队到广播队列中）
- 收到节点以及更新的回复
从一个节点的角度：
- 是有能力在确认相关信息之后，独立执行智能合约的。因为所需要的信息在这个节点的本地都有备份。
- 虽然可以独立执行智能合约，但是不能独立的把执行结果广播出去
交易过程概图
参与方
- A ：收购萝卜
- B ：出售萝卜
- peerA：代表A
- peerB：代表B
假设
- 我们的联盟网络已经建成，而且参与方已经通过相关资格认证机构，注册，并且有相关材料证明其身份。
The application user has registered and enrolled with the organization’s certificate authority (CA) and received back necessary cryptographic material, which is used to authenticate to the network.
包含了代表萝卜市场的一对key和value的智能合约已经在联盟网络里配置好了。
智能合约的逻辑里面，包含了交易的步骤以及一个萝卜的价格。并且在背书协议里面，包含了必须双方提出背书。
交易步骤
- A想发出购买萝卜的请求。因为需要双方背书，所以A同应用，把这请求同时发给了，peerA和peerB。
- SDK生成请求。这个请求可以执行一个智能合约，从而可以读写（比如加入一对新的代表萝卜市场的key和value）账本。
- SDK将交易打包为正确的格式，并用用户的加密凭证为此交易提议生成唯一的签名。
- 背书节点，如果签名验证成功，就执行请求
主要验证：
・请求的格式是否正确
・这个请求在之前已经被执行过
・签名是否有效
・请求提出者，在权限上是否符合此次请求的内容。
- 背书节点，执行请求，生成结果。此时账本还没有做任何的更新。和背书节点的签名一起，返回给请求者。
图片来源
图片来自官方网站
