1

Peer Nodes 节点

在任何区块链网络里面，节点都是构成整个网络必不可少的组成部分。在Hyperledger Fabric的网络里面，在节点上，我们可以实现和定制 chaincode，当然还有与之附随的 chaincode 的 Blockchain Ledger。

• 节点是 chaincode， Blockchain Ledger的载体。每个节点上都有一份 chaincode 的 Blockchain Ledger 的拷贝。

• 每个节点都可以被：创建, 开始, 停止, 重新设定, 删除。

• 一个节点上，可以有多个 chaincode 和 Blockchain Ledger， 而一个 Blockchain Ledger为多个chaincode提供服务。

• 每个节点上都有一个默认的 system chaincodes。

2

Multiple Ledgers and Chaincodes *多账本 多智能合约*

一个节点里面，有一个 chaincode 的 Blockchain Ledger 是很常见的。在Hyperledger Fabric的网络里面,一个节点上有多个 Blockchain Ledger，而基于每个 Blockchain Ledger，又有多个 chaincode，也是很常见的。而每个节点上都有一个默认的 system chaincodes。

3

Applications and Peers 应用与节点

what’s most important to understand is the difference in application-peer interactions for ledger-query compared to ledger-update transaction styles.

一个外部应用，比如安卓上的一个应用，可以通过 Hyperledger Fabric Software Development Kit (SDK) 里面提供的 APIs 来连接节点，触发 chaincode，生成交易，通过 ordered（排队，排序） 之后，被广播到网络其他节点上。

从一个应用的角度：

• 通过API链接节点

• 尝试**智能合约

• 收到节点的回复（在回复之前，节点会**请求的智能合约，智能合约生产指令，更新回复）

• 把收到的回复，提交给排序节点（排序节点会做相关确认，然后把这次交易的信息排队到广播队列中）

• 收到节点以及更新的回复

从一个节点的角度：

• 是有能力在确认相关信息之后，独立执行智能合约的。因为所需要的信息在这个节点的本地都有备份。

• 虽然可以独立执行智能合约，但是不能独立的把执行结果广播出去。

4

一次交易的旅程

4.1 参与方

• A ：收购萝卜

• B ：出售萝卜

• peerA：代表A

• peerB：代表B

4.2 假设

• 我们的联盟网络已经建成，而且参与方已经通过相关资格认证机构，注册，并且有相关材料证明其身份。

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的智能合约已经在联盟网络里配置好了。

• 智能合约的逻辑里面，包含了交易的步骤以及一个萝卜的价格。并且在背书协议里面，包含了必须双方提出背书。

4.3 交易步骤

• A想发出购买萝卜的请求。因为需要双方背书，所以A同应用，把这请求同时发给了，peerA和peerB。

• SDK生成请求。这个请求可以执行一个智能合约，从而可以读写（比如加入一对新的代表萝卜市场的key和value）账本。

• SDK将交易打包为正确的格式，并用用户的加密凭证为此交易提议生成唯一的签名。

• 背书节点，如果签名验证成功，就执行请求

主要验证：
・请求的格式是否正确
・这个请求在之前已经被执行过
・签名是否有效
・请求提出者，在权限上是否符合此次请求的内容。

• 背书节点，执行请求，生成结果。此时账本还没有做任何的更新。和背书节点的签名一起，返回给请求者。

本文作者：HiBlock区块链技术布道群-AmyWu

原文发布于简书

加微信baobaotalk_com，加入技术布道群

以下是我们的社区介绍，欢迎各种合作、交流、学习：）