fabric区块链源码 区块链交易系统源码

本篇文章给大家谈谈fabric区块链源码，以及区块链交易系统源码对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。

HyperLedgerFabric源码解读(5)-channel

// 在hyperledger fabric中 通道channel其实就是在至少两个成员(members)或组织(orgnization)间专门为私人或机密进行的交易而建立的私有“子网”.

// 一个通道主要包含：成员-member(组织-orgnization)、每个成员的锚节点(anchor peer)、共享账本(sharing ledger)、应用链码(application chaincode)、排序服务节点(orderer peer)

// 网络中的每笔交易(transaction)都在指定的通道channel中执行，每个通信方必须经过身份验证并授权在该通道channel上进行交易。而加入channel的每个peer都具有成员服务提供商(members service provider MSP)提供的身份

// 1、创建channel：通过客户端SDK调用configuration system chaincode以及应用属性(锚点、成员[组织]等)。发起的请求为channel ledger创建一个创世区块(genesis block),存储有关channel的策略、成员、锚点等配置信息

// 当将新成员添加到现有的channel时，Genesis block或最近被配置的区块block分享给新成员

// 2、leader election: channel中每个成员的leadering peer的选举决定了哪个peer代表成员或组织与orderering service进行通信。(若是没有指定leader 则使用算法来指定leader)

// 共识算法将交易排序并以一个block的形式发送给一个leader，然后再由leader分发给其他peer，并用gossip协议进行跨链channel通信

// 在实际情况中任意一个锚节点可以属于多个通道，并维护了多个账本，但不会有任何账本数据从一个通道channel传到另一个通道channel

// 主要是由于账本的分离是基于通道来的，而分离有事在配置链码chaincode、成员标识不玩和gossip协议来定义和实现的

// (1)、数据的传播，包括交易的信息，账本状态和通道成员等都在通道内受限制的验证成员身份的节点之间，是根据通道对节点和账本数据进行隔离，允许网络成员可以在同一个区块链网络中请求私有的和保密的交易给业务上的竞争对手和其他受限的成员。

基于Spring的Fabric区块链Gateway，简化区块链开发

学习Hyperledger Fabric有一阵子了，从网络搭建、SDK调用到基于Spring的Gateway的开发，一路走来，感觉还是有不少的坑。最近，终于有空，将这些东西整理出来，希望能帮到同路的小伙伴们。详细文档地址： 。

前一阵子，曾整理过一篇文章，详细的介绍了Fabirc网络的搭建和部署，小伙伴们请自行查阅：推荐几个开源项目，教你快速搭建Hyperledger Fabric区块链网络

1. Java SDK： GitHub - hyperledger/fabric-sdk-java

2. Gateway： GitHub - hyperledger/fabric-gateway-java

这是我基于官方的Gateway项目，结合Spring MVC做出的一套框架。主要是将Chaincode的函数调用，包装成了Spring的服务。

1. 项目地址： GitHub - ecsoya/spring-fabric-gateway

2. 详细文档：

3. Maven地址：

一个精简版的Fabric区块链浏览器。

1. 项目地址： GitHub - ecsoya/spring-fabric-gateway

2. 详细文档：

3. Maven地址：

以上的项目，包含官方的SDK和Gateway，都离不开 Fabric 网络配置文件的支持。

所谓的配置文件，就是将所有的组织、Peer和其相关的证书，全部配置到一个JSON文件或YAML文件中，方便在项目中读取。

详细文档：

1. 文档：

2. 源码： GitHub - ecsoya/fabric-demo

Fabric源码分析之Peer链码安装

environment:

fabric v1.4.2

在Fabric中交易fabric区块链源码的处理过程fabric区块链源码，客户端将提案首先发送到背书节点，背书节点检提案的合法性。如果合法的话，背书节点将通过交易所属的链码临时执行一个交易，并执行背书节点在本地持有的状态副本。

Chaincode应该仅仅被安装于chaincode所有者的背书节点上，链码运行在节点上的沙盒（Docker容器）中，并通过gRPC协议与相应的Peer节点进行交互，以使该chaincode逻辑对整个网络的其他成员保密。

请务必在一条channel上每一个要运行你chaincode的背书节点上安装你的chaincode

其他没有chaincode的成员将无权成为chaincode影响下的交易的认证节点（endorser）。也就是说，他们不能执行chaincode。不过，他们仍可以验证交易并提交到账本上。

ChainCode要在区块链网络中运行，需要经过链码安装和链码实例化两个步骤。

链码的安装涉及到3个服务，分别是client，peer背书节点和LSCC容器

主要流程:

以下是在客户端执行 "peer chaincode install ..." 的业务流程图:

客户端执行链码安装命令:

客户端的整个流程切入点为 fabric/peer/main.go 的 main 函数

然后继续找到 peer/chaincode/chaincode.go

继续找到 peer/chaincode/install.go 的 installCmd 函数，可以看出 chaincodeInstall 为主要的入口函数

我们进去看看 InitCmdFactory 做了什么，位置在 peer/chaincode/common.go

返回了 ChaincodeCmdFactory 的结构体，定义为:

找到定义 genChaincodeDeploymentSpec

先看 getChaincodeSpec ,位于 peer/chaincode/common.go

封装返回 ChaincodeSpec 结构体

刚才生成的 ChaincodeSpec 作为 getChaincodeDeploymentSpec 函数的输入参数，返回 ChaincodeDeploymentSpec 结构体

CreateInstallProposalFromCDS 位于 protos/utils/proutils.go

调用 createProposalFromCDS

从结构体 ChaincodeInvocationSpec 可以看到用户链码安装需要调用到系统链码 lscc

通过 CreateProposalFromCIS=CreateChaincodeProposal=CreateChaincodeProposalWithTransient

再看 CreateChaincodeProposalWithTxIDNonceAndTransient 函数

最后返回 Proposal 结构体，定义见 protos\peer\proposal.pb.go

到这里 install 调用的 CreateInstallProposalFromCDS 完毕，返回 Proposal 结构体

关系有点复杂，给出一个类图能看得清晰点

回到 install ，看 GetSignedProposal 对刚创建的提案结构进行签名

函数位于 protos/utils/txutils.go

返回 SignedProposal 结构体,定义位于 protos/peer/proposal.pb.go

提案签名完后 install 调用 ProcessProposal 发送提案到peer节点进行处理，参数带了 SignedProposal 结构体

接下来client端就等到peer的 proposalResponse

当client调用了 ProposalResponse 消息就发送到peer背书节点,也就是走peer节点背书提案流程.

要看安装链码前做了什么，直接看 peer节点背书提案流程 就好。

我们从 core/endorser/endorser.go 的 callChaincode=Execute 函数开始讲

在 core/chaincode/chaincode_support.go 找到 Execute

主要看 Invoke :

根据之前的信息，我们调用的是 lscc 来安装链码，所以在peer启动的时候已经初始化 lscc 链码容器了，所以回直接返回 handler 对象，后面的语句就不说了，在启动链码容器的章节再详细研究。

接着我们看 execute 函数，调用 createCCMessage 创建一个 ChaincodeMessage结构体消息 . Execute 负责把消息发送出去

在 core/chaincode/handler.go 找到 Execute

这里关键是 h.serialSendAsync(msg) 语句，功能是把包装好的信息以grpc协议发送出去，直接就等返回结果了。

至此 Execute 调用的 Invoke 就在等返回结果，结果返回就调用 processChaincodeExecutionResult 对链码结果进行处理

peer发送的信息哪去了呢fabric区块链源码？

我们定位到 code/chaincode/shim/chaincode.go ,我们看到两个入口函数 Start 和 StartInProc ， Start 为用户链码的入口函数，而 StartInProc 是系统链码的入口函数，他们同时都调用了 chatWithPeer ,因为我们调用的是lscc，就看 StartInProc

chatWithPeer就是开启grpc的接收模式在等到节点发来信息，接收到信息后就调用 handleMessage 处理信息。

因为我们信息类型为 ChaincodeMessage_TRANSACTION ,所以我们在 core/chaincode/shim/handler.go 顺着 handleMessage=handleReady 扎到 handleTransaction

其中关键语句 res := handler.cc.Invoke(stub) ,这语句是调用相应链码的 Invoke 函数，所以我们找到 core/scc/lscc/lscc.go 下的 Invoke 函数

进去 core/scc/lscc/lscc.go 的 Invoke 函数可以看到，这里有 "INSTALL", "DEPLOY", "UPGRADE" 等操作，我们只看 INSTALL 部分。

关键调用函数是 executeInstall

接着看 executeInstall

HandleChaincodeInstall 为处理statedb，而 PutChaincodeToLocalStorage 是把链码文件安装到本地文件目录

链码安装到peer的默认路径 /var/hyperledger/production/chaincodes

到此链码的安装完毕

lscc链码安装完毕后，返回信息给peer节点，peer节点就给提案背书返回给client服务端，至此链码安装完毕。

github

参考:

5-ChainCode生命周期、分类及安装、实例化命令解析

fabric源码解读【peer chaincode】：安装链码

Fabric1.4源码解析：客户端安装链码

关于fabric区块链源码和区块链交易系统源码的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。