环境搭建
0-0
- 下载源码
git clone https://github.com/hyperledger/fabric.git
这里使用的是2.2的版本，需要进行checkout
- 安装 docker
搭建过程中执行的脚本会需要下载镜像
If you are using Docker for Mac,
you will need to use a location under /Users, /Volumes, /private, or /tmp.
To use a different location, please consult the Docker documentation for file sharing.
mac 需要修改docker
0-1
下载官方给的samples
cd fabric/scripts
- 查看脚本内容bootstrap.sh主要信息
9：当前hyperledger的版本
11：ca的版本
25：会在下docker镜像、二进制文件
32：下载docker镜像
49：下载官方给的demo
81：下载hyperledger的二进制文件，这个也可以在/hyperledger-fabric 下make生成
可能因为网络问题 二进制文件下载不了
可以cd hyperledger 执行make ，会在build/bin 生成，在添加到环境变量中
-
执行脚本
scripts/bootstrap.sh -
执行日志主要信息
会clone fabric-samples
会下载images
下载bin
Pull Hyperledger Fabric binaries
===> Downloading version 2.2.0 platform specific fabric binaries
===> Downloading: https://github.com/hyperledger/fabric/releases/download/v2.2.0/hyperledger-fabric-darwin-amd64-2.2.0.tar.gz
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 655 100 655 0 0 387 0 0:00:01 0:00:01 --:--:-- 387
100 64.9M 100 64.9M 0 0 135k 0 0:08:10 0:08:10 --:--:-- 67218
==> Done.
===> Downloading version 1.4.7 platform specific fabric-ca-client binary
===> Downloading: https://github.com/hyperledger/fabric-ca/releases/download/v1.4.7/hyperledger-fabric-ca-darwin-amd64-1.4.7.tar.gz
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 658 100 658 0 0 107 0 0:00:06 0:00:06 --:--:-- 169
100 19.1M 100 19.1M 0 0 170k 0 0:01:55 0:01:55 --:--:-- 215k
==> Done.
- 执行结果
下载 hyperledger 的镜像
hyperledger/fabric-baseos:2.2, hyperledger/fabric-baseos:2.2.0, hyperledger/fabric-baseos:latest
hyperledger/fabric-ca:1.4, hyperledger/fabric-ca:1.4.7, hyperledger/fabric-ca:latest
hyperledger/fabric-ccenv:2.2, hyperledger/fabric-ccenv:2.2.0, hyperledger/fabric-ccenv:latest
hyperledger/fabric-javaenv:2.2, hyperledger/fabric-javaenv:2.2.0, hyperledger/fabric-javaenv:latest
hyperledger/fabric-nodeenv:2.2, hyperledger/fabric-nodeenv:2.2.0, hyperledger/fabric-nodeenv:latest
hyperledger/fabric-orderer:2.2, hyperledger/fabric-orderer:2.2.0, hyperledger/fabric-orderer:latest
hyperledger/fabric-peer:2.2, hyperledger/fabric-peer:2.2.0, hyperledger/fabric-peer:latest
hyperledger/fabric-tools:2.2, hyperledger/fabric-tools:2.2.0, hyperledger/fabric-tools:latest
1-1 进行测试
-
测试
cd fabric-samples/test-network
./network.sh up # up 启动 down 关闭 -
执行日志中的主要信息
Create Org1 Identities
Create Org2 Identities
Create Orderer Org Identities
Generating Orderer Genesis block
orderer type: etcdraft
Generating genesis block 创世区块
- 执行结果
docker启动三个容器。
1d0514a77017 hyperledger/fabric-orderer:latest "orderer"
d8b871ac06dd hyperledger/fabric-peer:latest "peer node start"
bcca7274f522 hyperledger/fabric-peer:latest "peer node start"
- 总结
到这里可以看到两个peer 和orderer 说明 环境已经准备好了
peer
区块链网络主要由 Peer 节点（或者简单称之为 Peer）组成。Peer 是网络的基本元素，因为他们存储了账本和智能合约，
智能合约和账本将网络中共享的流程和信息对应地封装起来。
区块链网络是由 Peer 节点组成的，每个节点都保存着账本和智能合约的副本。
peer 节点可以被创建、启动、停止、重新配置甚至删除。
Fabric 是使用一个被称为链码的技术概念来实现智能合约 的，就是使用已支持的编程语言编写的一段简单的代码来访问账本。
Peer 节点在维护账本和链码。确切地说，Peer 节点维护的是账本及链码的实例。请注意这其实是在 Fabric 网络中故意提供了冗余，因为这样可以避免单点失效。
Peer 节点是账本及链码的宿主，应用程序及管理员如果想要访问这些资源，他们必须要和 Peer 节点进行交互。这就是为什么 Peer 节点被认为是 Hyperledger Fabric 网络最基本的组成模块。
账本数量和访问账本的链码的数量之间没有固定的关系。一个 Peer 节点可能会有很多链码和账本。
应用程序是如何通过跟 Peer 节点交互来访问账本
查询账本的操作涉及到应用程序和 Peer 节点之间的一个简单的三步对话
1、需要连接到 Peer 节点，可以使用sdk
2、通过连接 Peer 节点，应用程序能够执行链码来查询或者更新账本。
Peer 节点和排序节点，确保了账本在每个 Peer 节点上都具有最新的账本。
在这个例子中，
应用程序 A 连接到了 P1 并且调用了链码 S1 来查询或者更新账本 L1。
P1 调用了链码 S1 来生成提案响应，这个响应包含了查询结果或者账本更新的提案。
应用程序 A 接收到了提案的响应，
- 对于查询来说，流程到这里就结束了。
- 对于更新来说，应用程序 A 会从所有的响应中创建一笔交易，它会把这笔交易发送给排序节点 O1 进行排序。
- O1 会搜集网络中的交易并打包到区块中，然后将这些区块分发到所有 Peer 节点上，包括 P1。
- P1 在把交易提交到账本 L1 之前对交易进行验证。
- 当 L1 被更新之后，P1 会生成一个事件，该事件会被 A 接收到，来标识这个过程结束了。
Peer 节点可以马上将查询的结果返回给应用程序，因为满足这个查询的所有信息都保存在 Peer 节点本地的账本副本中。
Peer 节点从来不会为了应用程序的查询返回结果而去询问其他 Peer 节点的。
但是应用程序还是能够连接到一个或者多个 Peer 节点来执行一个查询；比如，为了协调在多个 Peer 节点间的一个结果，或者当怀疑数据不是最新的时候，需要从不同的 Peer 节点获得更新的结果。
一个独立的 Peer 节点目前是不能进行账本更新的，因为其他的 Peer 节点必须首先要同意这个变动（即达成共识）。
Peer 节点会返回给应用程序一个被提案过的更新，这个 Peer 节点会依据其他节点之前的协议来应用这个更新。
第一个额外的步骤，也就是第四步，要求应用程序将响应的提案过的更新发送到网络中，网络中的 Peer 节点会将交易提交到它们相应的账本中。
应用程序会收到排序节点打包了交易的区块，然后将他们分发到网络中所有的 Peer 节点，
在区块被更新到每个 Peer 节点本地账本的副本中之前，这些区块都需要被验证。排序流程需要一定时间来完成 (数秒钟)，因此应用程序会被异步通知
通道
区块链网络中组件能够进行交流和私密交易的机制。
组织
区块链网络是由多个组织来管理的，而不是单个组织。对于如何构建这种类型的分布式网络，Peer 节点是核心，因为他们是由这些组织所有，也是这些组织同这个网络的连接点。
这里有一个工作原则：如果组织不为这个网络贡献他们的资源，这个网络是不会存在的。更关键的是，这个网络会随着这些互相合作的组织提供的资源而增长或者萎缩。
网络不依赖于任何一个单独的组织，只要还存在一个组织，网络就会继续存在，不管其他的组织加入或者离开。这就是去中心化网络的核心。
Peer 节点和身份
Peer 节点会有一个身份信息被分给他们，这是通过一个特定的证书认证机构颁发的数字证书来实现的。
数字证书看成是能够为 Peer 节点提供可验证信息的身份证。在网络中的每个 Peer 节点都会被所属组织的管理员分配一个数字证书。
当 Peer 节点连接到一个通道的时候，它的数字证书会通过通道 MSP 来识别它的所属组织。
当 Peer 节点使用通道连接到一个区块链网络的时候，在通道配置中的策略会使用 Peer 节点的身份信息来确定它的权利。
关于身份信息和组织的映射是由成员服务提供者（MSP）来提供的，它决定了一个 Peer 节点如何在指定的组织中分配到特定的角色以及得到访问区块链资源的相关权限。
一个 Peer 节点只能被一个组织所有，因此也就只能被关联到一个单独的 MSP。
Peer 节点以及同一个区块链网络进行交互的每件事情都会从他们的数字证书和 MSP 来得到他们的组织的身份信息。
Peer 节点、应用程序、终端用户、管理员以及排序节点如果想同一个区块链网络进行交互的话，必须要有一个身份信息和一个相关联的 MSP。
我们使用身份信息来为每个跟区块链网络进行交互的实体提供一个名字——一个主角（principal）。
但应用程序和 Peer 节点彼此互相交互来确保每个 Peer 节点的账本永远保持一致是通过以排序节点作为中心媒介的一种特殊机制，
一个单独的 Peer 节点不能够由它自己来更新账本——更新需要网络中其他节点的同意。在一个账本的更新被应用到 Peer 节点的本地账本之前， Peer 节点会请求网络中的其他 Peer 节点来批准这次更新。这个过程被称为共识，
更新账本的应用程序会被引入到一个三阶段的流程，这确保了在一个区块链网络中所有的 Peer 节点都彼此保持着一致的账本。
在第一个阶段，应用程序会跟背书节点的子集一起工作，其中的每个节点都会向应用程序为提案的账本更新提供背书，但是不会将提案的更新应用到他们的账本副本上。
在第二个阶段，这些分散的背书会被搜集到一起当做交易被打包进区块中。
在最后一个阶段，这些区块会被分发回每个 Peer 节点，在这些 Peer 节点上每笔交易在被应用到 Peer 节点的账本副本之前会被验证。
区块更新
提案
应用程序会生成一笔交易的提案，它会把这个提案发送给一系列的被要求的节点来获得背书。
其中的每一个背书节点接下来都会独立地使用交易提案来执行链码，以此来生成这个交易提案的响应。
这并没有将这次更新应用到账本上，只是简单地为它提供签名然后将它返回给应用程序。
当应用程序接收到有效数量的被签过名的提案响应之后，交易流程中的第一个阶段就结束了。
交易提案会被 Peer 节点独立地执行，Peer 节点会返回经过背书的提案响应。
最初，应用程序会选择一些 Peer 节点来生成一套关于账本更新的提案。
应用程序会选择哪些 Peer 节点呢？
这取决于背书策略（这是为链码来义的），这个策略定义了在一个账本提案能够被网络所接受之前，都需要哪些 Peer 节点需要对这个账本变更提案进行背书。
这很明显就是为了实现共识——每一个需要的组织必须对账本更新的提案在被各个 Peer 节点同意更新到他们的账本之前，对这个提案进行背书。
排序
交易流程的第二个阶段是打包阶段。排序节点是这个过程的关键——它接收交易，这些交易中包含了来自很多个应用的已经背书过的交易提案，并且将交易排序并打包进区块。
验证和提交
排序节点将区块分发到所有与它连接的 Peer 节点开始的。
Peer 节点会和通道中的排序节点相连，所有跟这个排序节点相连的 Peer 节点将会收到一个新的区块的副本。
每个 Peer 节点会独立处理这个区块，但是会跟这个通道上的每一个其他 Peer 节点使用完全一致的方式处理。
通过这种方式，我们会看到账本是会始终保持一致的。
不是每个 Peer 节点都需要连接到排序节点——Peer 节点可以使用 gossip 协议将区块的信息发送给其他 Peer 节点，其他 Peer 节点也可以独立地处理这些区块。
当接到区块的时候，Peer 节点会按照区块中的顺序处理每笔交易。
对于每一笔交易，每个 Peer 节点都会确认这笔交易已经根据产生这笔交易的链码中定义的背书策略由要求的组织进行过背书了。
在一些交易被认为是有效之前，这些交易可能仅仅需要一个组织的背书，但是其他的交易可能会需要多个背书。
这个验证的流程确认了所有相关的组织已经生成了相同的产出或者结果。
也需要注意到的是，这次的验证跟在阶段 1 中进行的背书检查是不同的，应用程序从背书节点那里接收到了交易的响应，然后做了决定来发送交易提案。
如果应用程序违反了背书策略发送了错误的交易，那么 Peer 节点还是能够在阶段 3 中的验证流程里拒绝这笔交易。
如果一笔交易被正确的背书，Peer 节点会尝试将它应用到账本中。
为了做这个，Peer 节点必须要进行账本一致性检查来验证当前账本中的状态同应用了更新提案后的账本是能够兼容的。这可能不是每次都是有可行的，即使交易已经被完整地背书过了。
比如，另外一笔交易可能会更新账本中的同一个资产，这样的话交易的更新就不会是有效的了，因此也就不会被应用。通过这种方式，账本在通道中的每个 Peer 节点都是保持一致的，因为他们中每个都在遵守相同的验证规则。
当 Peer 节点成功地验证每笔单独的交易之后，它就会更新账本了。失败的交易是不会应用到账本中的，但是他们会被保留为之后的审计使用，
我们也注意到了第三阶段并没有要求执行链码——那只会在第一阶段执行，这是很重要的。
这意味着链码仅仅需要在背书节点中有效，而不需要在区块链网络的所有部分都要有。
这个通常是很有帮助的，因为这保持了链码逻辑的机密性只有背书组织了解。
这个同链码的输出（交易提案的响应）恰恰相反，这个输出会被分享给通道中的所有 Peer 节点，不管这些 Peer 节点是否为这交易提供背书。
这个关于背书节点的特殊性是被设计用来帮助扩展性和保密性的。
每次当区块被提交到 Peer 节点的账本的时候，那个 Peer 节点会生成一个合适的事件。
区块事件包括了整个区块的内容，然而区块交易事件仅仅包含了概要信息，比如是否在区块中的每笔交易是有效的还是无效的。
链码已经被执行的链码事件也可以在这个时候公布出去。
应用程序可以对这些事件类型进行注册，所以在这些事件发生的时候他们能够被通知到。
这些通知结束了交易流程的第三以及最后的阶段。
整个交易处理流程被称为共识，因为所有 Peer 节点在由排序节点提供的流程中对交易的排序及内容都达成了一致。共识是一个多步骤的流程，并且应用程序只会在这个流程结束的时候通知账本更新——这个在不同的 Peer 节点上可能在不同的时间会发生。