Hyperledger Fabric从源码分析系统链码

系统链码简介

在 Fabric 中，有一些链码是比较特殊的，叫系统链码。它们作为peer进程的一部分运行，而不是像用户链码一样运行在独立的 docker 容器中。因此它们有更高的权限来访问 peer 中的资源来实现用户链码难以实现或者不能实现的功能。

在 Fabric 1.4 版本之前，总共有五种系统链码，它们分别是：

• Life Cycle System Chaincode (LSCC)：生命周期系统链码
• Configuration System Chaincode (CSCC)：配置系统链码
• Query System Chaincode (QSCC)：查询系统链码
• Endorser System Chaincode (ESCC)：背书系统链码
• Validator System Chaincode (VSCC)：验证系统链码

在我学习的过程中都是按照 Fabric 1.4 版本的源码及资料学习的，在 1.4 版本中，官方文档明确表示，当前现有只支持 LSCC、CSCC、QSCC 三种链码，而 ESCC 与 VSCC 则是被可插拔背书和验证方法所取代，具体的描述文档可以参考官方文档——可插拔交易背书与交易验证，主要是是因为在某些情况下，用户需要自定义背书与验证的规则。

和用户链码不同的是，系统链码不使用 SDK 或 CLI 的提案安装和实例化。它在 peer 节点启动的时候注册和部署。

本篇文章将从源码角度，分析系统链码是如何在 peer 节点启动的时候就注册和部署的，并且它们主要对外主要提供了哪些方法。

注：本篇文章会着重分析 1.4 版本中支持的三种链码，对于 ESCC 与 VSCC 只会简单带过。

1. peer 节点如何完成系统链码的注册与部署

peer 节点是以 docker 容器的形式存在的，在容器启动是会执行 peer node start命令来启动 peer 节点，因此我们顺藤摸瓜就可以找到 peer 节点启动时的源码文件 —— peer/node/start.go

我把有关系统链码的部分贴出来，别的部分暂时先不关心。start 命令的主要入口函数就是 serve 函数。

func serve(args []string) error {
   
  //.................
  
	// Initialize chaincode service
	chaincodeSupport, ccp, sccp, packageProvider := startChaincodeServer(peerHost, aclProvider, pr, opsSystem)
	
  //.................
  
	// deploy system chaincodes
	sccp.DeploySysCCs("", ccp)
  
  //.................
}

在 serve 函数主要就是调用了一个 startChaincodeServer 函数，创建了我们关心的两个对象 ccp （ChainCodeProvider，链码提供者）和 sccp （system ChainCodeProvider，系统链码提供者），之后调用 sccp.DeploySysCCs 方法来部署系统链码。因此系统链码的安装和部署就完成了，我们主要关心的是创建了一个 sccp 对象，之后调用了 sccp 的 sccp.DeploySysCCs 方法部署系统链码。那么我们就先来关心一下 startChaincodeServer 函数中创建系统链码的部分。

// startChaincodeServer will finish chaincode related initialization, including:
// 1) setup local chaincode install path
// 2) create chaincode specific tls CA
// 3) start the chaincode specific gRPC listening service
func startChaincodeServer(
	peerHost string,
	aclProvider aclmgmt.ACLProvider,
	pr *platforms.Registry,
	ops *operations.System,
)<