参考文章:http://hyperledger-fabric.readthedocs.io/en/latest/txflow.html
交易流程示意图
交易流程
本文件概述了在标准资产交换过程中发生的交易机制。该情景包括两个买卖萝卜的客户A和B。他们每个人都有网络上的对等体,通过它们发送他们的交易并与分类帐进行交互。
![_images / step0.png](https://i-blog.csdnimg.cn/blog_migrate/ffa230ac5c8492a251ab06537f63953c.png)
假设
此流程假设一个通道设置并运行。应用程序用户已经注册并注册了组织的认证中心(CA),并收到了必要的加密资料,用于向网络进行身份验证。
链码(包含表示萝卜市场初始状态的一组键值对)安装在对等体上并在通道上实例化。链码包含定义一组交易指令和萝卜的商定价格的逻辑。还为此链码设定了认可政策,并表示同意peerA
并peerB
必须批准任何交易。
![_images / step1.png](https://i-blog.csdnimg.cn/blog_migrate/1e4a25f6cd9af8063c5067e72529345a.png)
- 客户端A启动事务
发生了什么? - 客户A正在发送购买萝卜的请求。请求目标,peerA
以及peerB
谁分别代表客户A和客户B.代言政策规定,双方必须批准任何交易,因此请求将转到peerA
和peerB
。
接下来,构建交易提案。利用受支持的SDK(Node,Java,Python)的应用程序利用生成交易提案的可用API之一。该提案是调用链码功能的请求,以便可以将数据读取和/或写入分类帐(即为资产写入新的键值对)。SDK用作将交易提议打包成正确架构的格式(通过gRPC的协议缓冲区)的垫片,并采用用户的加密凭据为此交易提案生成唯一签名。
![_images / step2.png](https://i-blog.csdnimg.cn/blog_migrate/d43450ddd2dd1f64956bc8673467ecee.png)
- 支持对等体验证签名并执行事务
认可对等方验证(1)交易方案是否形成良好,(2)以前没有提交(重播攻击保护),(3)签名有效(使用MSP),(4)提交者(示例中的客户端A)被正确地授权在该频道上执行建议的操作(即,每个认可的对等方确保提交者满足频道的作者政策)。认可的对等体将事务提案输入作为引用的链码功能的参数。然后针对当前状态数据库执行链码以产生包括响应值,读取集合和写入集合的事务结果。此时不对分类帐进行任何更新。这些值的集合以及支持的对等体的签名作为“解答”应用程序消耗的有效载荷的SDK作为“提案响应”传回。
{MSP是一个对等组件,允许他们验证从客户端到达的事务请求并签署事务结果(签注)。写作策略在频道创建时定义,并确定哪个用户有权向该频道提交交易。}
![_images / step3.png](https://i-blog.csdnimg.cn/blog_migrate/6cd9367e6be818e17b9151df8d87bb4f.png)
- 提案回应被检查
应用程序验证认可的对等体签名,并比较提案响应,以确定提案响应是否相同。如果链码仅查询分类帐,应用程序将检查查询响应,通常不会将交易提交给订购服务。如果客户应用程序打算将交易提交给订购服务来更新分类帐,应用程序将在提交之前确定指定的认可策略是否已经满足(即peerA和peerB都认可)。架构是这样的,即使应用程序选择不检查响应或以其他方式转发未经授权的交易,则认可策略仍将由同行执行并在提交验证阶段维护。
![_images / step4.png](https://i-blog.csdnimg.cn/blog_migrate/2db72e16faf6f73debf365430131edce.png)
- 客户将配件装配到事务中
应用程序将“交易消息”中的交易建议和响应“广播”到订购服务。交易将包含读/写集,支持对等体签名和信道ID。订单服务不需要检查交易的整个内容以执行其操作,它只是从网络中的所有渠道接收交易,按时间顺序排列通道,并创建每个通道的交易块。
![_images / step5.png](https://i-blog.csdnimg.cn/blog_migrate/bd485dd8c7f2168e9372728323b89822.png)
- 交易已验证并提交
事务块被“传递”到通道上的所有对等体。块内的交易经过验证,以确保认可政策得到履行,并确保由于事务执行生成了读取集,读取集变量对分类帐状态没有任何变化。块中的事务被标记为有效或无效。
![_images / step6.png](https://i-blog.csdnimg.cn/blog_migrate/97efa9a3ce6dd29d3ebb289e3764b804.png)
- 分类帐更新
每个对等体将块添加到通道的链,并且对于每个有效事务,写集合被提交到当前状态数据库。发出一个事件,以通知客户端应用程序,该事务(调用)已经不可变地附加到链中,以及通知该事务是否被验证或无效。
搭建完fabric环境后,一般情况会启动first-network实例,测试环境是否ok,熟悉first-network实例可以帮助我们理解fabric原理
原文地址:http://hyperledger-fabric.readthedocs.io/en/latest/build_network.html
git clone https://github.com/hyperledger/fabric-samples.git
cd fabric-samples/first-network
./byfn.sh -m generate此第一步生成所有各种网络实体的所有证书和密钥,用于引导排序服务的起源块,以及配置通道所需的配置事务集合。
./byfn.sh -m up 开启网络
./byfn.sh -m down 关闭网络
工具的手动使用
cryptogen
我们将使用cryptogen工具为我们的各种网络实体生成加密材料(x509证书)。这些证书是身份的代表,它们允许在我们的实体进行交流和交易时进行签名/验证身份验证。
../bin/cryptogen generate --config=./crypto-config.yaml
运行cryptogen工具后,生成的证书和密钥将被保存到名为crypto-config的文件夹中
configtxgen
使用文档: http://hyperledger-fabric.readthedocs.io/en/latest/configtxgen.html
configtxgen工具用于创建四个配置工件:
orderer genesis block
,
channel channel configuration transaction
,
and two anchor peer transactions
- one for each Peer Org.
1.创建创世区块
首先设置环境变量告诉configtxgen
工具去哪寻找configtx.yaml
文件
export FABRIC_CFG_PATH=$PWD
然后使用configtxgen
创建orderer的创世区块
../bin/configtxgen -profile TwoOrgsOrdererGenesis -outputBlock ./channel-artifacts/genesis.block
2.创建管道配置
首先设置环境变量CHANNEL_NAME,设置管道名
export CHANNEL_NAME=mychannel
../bin/configtxgen -profile TwoOrgsChannel -outputCreateChannelTx ./channel-artifacts/channel.tx -channelID $CHANNEL_NAME
3.接下来,我们将在正在构建的通道上定义Org1、Org2的锚节点。
../bin/configtxgen -profile TwoOrgsChannel -outputAnchorPeersUpdate ./channel-artifacts/Org1MSPanchors.tx -channelID $CHANNEL_NAME -asOrg Org1MSP
../bin/configtxgen -profile TwoOrgsChannel -outputAnchorPeersUpdate ./channel-artifacts/Org2MSPanchors.tx -channelID $CHANNEL_NAME -asOrg Org2MSP
开启网络
注释掉docker-compose-cli.yaml中,command: /bin/bash -c './scripts/script.sh ${CHANNEL_NAME} ${DELAY}; sleep $TIMEOUT'
CHANNEL_NAME=$CHANNEL_NAME TIMEOUT=10000 docker-compose -f docker-compose-cli.yaml up -d
创建和加入通道
我们将使用docker exec命令进入CLI容器:
docker exec -it cli bash
接下来,我们将创建的通道配置(我们称之为channel.tx)传递给orderer,作为创建通道请求的一部分。
export CHANNEL_NAME=mychannel
peer channel create -o orderer.example.com:7050 -c $CHANNEL_NAME -f ./channel-artifacts/channel.tx --tls $CORE_PEER_TLS_ENABLED --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem
这个命令会生成一个<channel-ID.block>
文件,此例中为mychannel.block文件
现在我们让peer0.org1.example.com
加入通道
peer channel join -bmychannel.block
安装和实例化智能合约
应用程序通过智能合约与区块链账本交互。因此,我们需要在将执行和认可我们的交易的每个peer上安装智能合约,然后在通道上实例化智能合约(跑起来)。
首先,将示例Go的智能合约安装到四个peer之一上。该命令将智能合约放在peer的文件系统上。
peer chaincode install -n mycc -v 1.0 -p github.com/hyperledger/fabric/examples/chaincode/go/chaincode_example02
接下来,在通道上实例化智能合约。这将初始化通道上的智能合约,设置区块链的认证策略,并在选定的peer开启智能合约容器
peer chaincode instantiate -o orderer.example.com:7050 --tls $CORE_PEER_TLS_ENABLED --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem -C $CHANNEL_NAME -n mycc -v 1.0 -c '{"Args":["init","a", "100", "b","200"]}' -P "OR ('Org1MSP.member','Org2MSP.member')"
查询
我们来查询a的值,以确保智能合约被正确实例化,状态DB被填充。
peer chaincode query -C $CHANNEL_NAME -n mycc -c '{"Args":["query","a"]}'
Query Result: 100
调用
我们让a转10给b
. 这个交易将产生一个新的区块并且更新反应在状态数据中。
peer chaincode invoke -o orderer.example.com:7050 --tls $CORE_PEER_TLS_ENABLED --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem -C $CHANNEL_NAME -n mycc -c '{"Args":["invoke","a","b","10"]}'
Chaincode invoke successful. result: status:200
再次查询
peer chaincode query -C $CHANNEL_NAME -n mycc -c '{"Args":["query","a"]}'
Query Result: 90