u011386109的博客

加密涉及到了内容挺复杂的，是一门专业性很强的学科。笔者没有专门学过，在此只是略讲一些bccsp服务所涉及到的皮毛：RSA - 一种非对称的加密算法，用于加密。有几种族簇，如RSA1024，RSA2048等。AES - 一种块加密算法，用于加密成块的大量数据。有几种族簇，如AES128，AES192等。ECDSA - 一种椭圆曲线签名，用于签名。有几种族簇，如ECDSAP256，ECDSAP

MSP是Membership Service Provider的缩写，个人习惯直译为成员关系服务提供者。作用类似于，在一个运行的fabric系统网络中有众多的参与者，MSP就是为了管理这些参与者，辨识验证哪些人有资格，哪些人没资格，既维护某一个参与者的权限，也维护参与者之间的关系。关于MSP更专业的概念，请参阅Fabric文档。这里说句题外话，最近这几篇文章其实感觉听别扭的，因为有些模块是

继续start.Go的serve函数，peerServer对象在ChaincodeSupport服务之后，又注册了Admin，Endorser服务：pb.RegisterAdminServer(peerServer.Server(), core.NewAdminServer())serverEndorser := endorser.NewEndorserServer()pb.Registe

fabric的配置系统是程序原始数据的来源之一，虽然简单却很重要。在阅读源码过程中对于具象化程序也很有帮助。在分析peer的具体交易工作之前，我们可以先分析一下fabric的配置系统。我们还将我们的目光聚焦在/fabric/peer/main.Go的main函数中，除了一系列mainCmd的命令操作，还有viper进行的一系列配置操作，并通过err := common.InitConfig(c

前两篇文章借由/fabric/peer/main.Go这个线头，简单分析了fabric的配置和日志系统。虽然还有一部分可说的内容，如common.InitCrypto()调用，但现在暂且按下main.go不表，而把目光投到/fabric/peer/node/start.go中的serve()函数。具体原因参见peer命令结构一文的最后。账本简单介绍ledger，中文就是账本，账册的

综述fabirc源码解析6中讲述了peer结点如何创建和注册grpc服务，接下来的几篇文章将对peer注册的各个服务进行详述。该篇讲述ChaincodeSupport服务，ChaincodeSupport服务为每个peer提供了chaincode操作的支持。registerChaincodeSupport(peerServer.Server())一句，位于/fabric/peer/node

GRPC简介GRPC是由自谷歌开发的一项多语言开源的RPC技术，在fabric用于实现客户端与服务器端的远程调用。比如chaincode，客户定义了一项rpc服务并相应生成了客户端代码和服务端代码，在此基础上进行业务逻辑上的开发后，分别运行服务端代码和客户端代码，实现客户端调用服务器端服务的目的。由于gprc相对来说还是很复杂的，所有还请自行学习。在gprc官网非常详细的资料和例子。

综述关于System Chaincode，下文中以系统链码称之。这是个人翻译，依据是Chaincode本质是注册存储到链上的一段逻辑代码，因此个人习惯称Chaincode为链码，fabric文档中也变相的称为智能合约。但是，因为Chaincode是专用名词，个人觉得不翻译而直接使用是最好的。start.Go中的serve函数里，在为peerServer注册ChaincodeSupp

只看代码而不读文档，无论是对自己的理解，还是对文章的释明，都容易使之存在困惑之处。因此在此先写fabric官方文档中几个相关主题的译文，作为自己相关主题文章的预热。水平有限，尽量直译，生硬之处很多，错误之处估计也不少而不自知。译文中括号内若是中文，则为解释，若为英文，则是专用名词。个人觉得fabric的官方文档不好：文档用语不简。作为说明性文档，个人认为语言应该尽量简明短小，以

构架释义Fabric的构架提供了以下优势：Chaincode信任机制（trust）灵活性。Fabric的构架将对于chaincode的信任假设（trust assumptions）从对于ordering的信任假设中分离了出来。换句话说，ordering服务（the ordering service）可能由一个结点集合（orderers）提供并容忍其中的一些结点失败或犯错（即容错性）

这里所说的日志，是指程序运行过程中打印到终端或日志文件，记录程序运行过程的日志，而非涉及到fabric记录交易数据，账本数据一类的交易日志。其实日志系统机制对于源码研究可以忽略，且相对简单，但是一方面日志系统对于程序运行和调试必不可少，fabric如何形成这个日志系统可以学习学习，日志所打印的内容对阅读源码也是一种提示；另一方面不弄清楚这个日志，在阅读源码的过程中这些到处出现的打印日志总像围绕在源

peer目录结构peer目录结构自身十分清晰，一个main.Go文件，其余文件夹除common,gossip外均为子命令集合，有chaincode，channel，clilogging，node，version五个，各司其职，供main.go整合使用。子命令文件夹中，与文件夹名称相同的.go文件为主要源码文件，其余的均为按功能划分的动作命令源码。以node目录为例，node自身作为根命令的

IBM于2017年7月推出商业正式版本1.0，改动比较大，核心共识由以前的pbft改为gossip，智能合约升级改为迭代版本号升级，优点明显，可以保留升级前的数据。与之前的0.6完全不同，同时提供了nodejs sdk和java sdk，目前NODEJS-SDK比较完善，笔者在使用过程中感觉这个SDK比较成熟，相反JAVA-SDK不太完善，从内部了解到，这个在完善中。之后笔者会从源码介绍fabric

前段时间公司上个fabric项目，底层区块链网络部署好了，之后重点考察了Java版本和nodejs版本的API。java版本的目前功能不是很完善，官方建议使用nodejs版本的API，经过使用发现基本功能满足。创建通道，加入通道，交易等等。当查询当前区块HASH和前一区块HASH时，发现结果都是一样，目前不明确是调用的问题还是底层的问题。后续跟踪中，如解决即时更新。API与底层的交互目前主要是