数据结构 - 机器学习

要理解超级账本Fabric的设计，首先要掌握节点、交易、排序、共识、通道等基本组件和相关核心概念。弄清楚了这些核心组件的功能，就可以准确地把握Fabric的底层运行原理，并深入理解其在架构上的设计初衷。知其然，进而可以知其所以然。超级账本Fabric采用了模块化功能设计，整体的功能模块结构如图12-3所示。总体来看，超级账本Fabric面向不同的开发人员提供了不同层面的功能，自下而上可以分为三层：·网络层：面向系统管理人员。实现P2P网络，提供底层构建区块链网络的基本能力，包括代表不同角色的节点和服务。·共识机制和权限管理：面向联盟和组织的管理人员。基于网络层的连通，实现共识机制和权限管理，提供分布式账本的基础。·业务层：面向业务应用开发人员。基于分布式账本，支持链码、交易等跟业务相

Fabric中大量采用了gRPC消息在不同组件之间进行通信交互，主要包括如下几种情况：客户端访问Peer节点，客户端和Peer访问Orderer节点，链码容器跟Peer节点之间，以及多个Peer节点之间的通信。12.3.1　Envelope消息结构这些通信消息大多采用了Envelope结构来进行封装。Envelope消息结构定义在protos/common/common.proto文件中，结构如图12-14所示。Envelope消息结构并不复杂，包括一个Payload域存放数据，以及Payload域中内容进行签名的Signature域。图12-14　Envelope消息结构Payload域中又包括Header域（记录类型、版本、签名者信息等元数据）和Data域（记录消息内容）。Header域

权限管理是联盟链中十分重要的功能，一般要解决谁（身份）在某个场景（条件）下是否允许采取某个操作（行动）的问题。超级账本Fabric项目通过策略（policy）来指定和实现网络中的各种场景下的权限限制。12.4.1　策略应用场景常见的策略场景包括10种情况，总结如表12-3所示。其中，大部分都与系统配置链码相关。表12-3　常见的策略场景12.4.2　身份证书执行策略检查的基础是身份证书机制。通过基于PKI的成员身份管理，Fabric网络可以对接入的节点和用户的各种能力进行限制。Fabric设计中考虑了三种类型的证书：登记证书（EnrollmentCertificate）、交易证书（TransactionCertificate），以及保障通信链路安全的TLS证书。证书的默认签名算法为ECD

用户链码对应用开发者来说十分重要，它提供了基于区块链分布式账本的状态处理逻辑，基于它可以开发出多种复杂的应用。在超级账本Fabric项目中，用户可以使用Go语言来开发链码，未来还将支持包括Java、JavaScript在内的多种高级语言。用户链码相关的代码都在core/chaincode路径下。其中core/chaincode/shim包中的代码主要是供链码容器侧调用使用，其他代码主要是Peer侧使用。12.5.1　基本结构Fabric中为链码提供了很好的封装支持，用户编写链码十分简单。下面给出了链码的典型结构，用户只需要关注到Init（）和Invoke（）函数的实现上，在其中利用shim.ChaincodeStubInterface结构，实现跟账本的交互逻辑：packagemainimp

系统链码（SystemChaincode）是超级账本Fabric项目在设计上的一大创新。通过上一小节的阅读，相信读者已经了解，最常见的用户应用链码（UserApplicationChaincode），由应用开发者来编写逻辑，运行在链码容器中，通过Fabric提供的有限接口与账本平台进行交互。而系统链码则负责Fabric节点自身的处理逻辑，包括系统配置、背书、校验等工作。这些处理过程最初通过硬编码（Hard-Coded）的方式固化在系统中。Fabric通过系统链码的形式来实现，运行在Peer主进程内，兼顾了逻辑实现和管理的灵活性，以及通信的性能。系统链码目前仅支持Go语言，在Peer节点启动时会自动完成注册和部署，以进程内逻辑形式跟主进程进行交互。目前，Fabric中包括五大类型

排序服务在超级账本Fabric网络中起到十分核心的作用。所有交易在发送到网络中交由Committer进行验证接受之前，需要先经过排序服务进行全局排序。排序服务提供了原子广播排序功能。在目前架构中，排序服务的功能被抽取出来，作为单独的fabric-orderer模块来实现，代码主要在fabric/orderer目录下。排序服务主要由三部分组成：gRPC协议对外提供服务接口；账本组件网络中每个应用通道维护区块链结构，排序插件跟不同类型的排序后端打交道，如图12-26所示。图12-26　Orderer主要结构12.7.1　gRPC服务接口Orderer通过gRPC接口提供了对外的调用服务，主要包括两个接口：Broadcast（srvab.AtomicBroadcast_BroadcastSe

代码即律法（Codeislaw）。数字货币曾是区块链技术的唯一应用场景。对智能合约的支持突破了场景限制，极大地丰富了区块链应用的适用范围，让基于区块链技术的分布式账本支持多行业、大规模的商业应用成为可能。作为区块链应用开发者，需要根据业务逻辑来开发与分布式账本打交道的智能合约，以及相应的用户侧应用程序。成熟的区块链底层平台会为应用提供强大的开发接口与框架。例如，超级账本Fabric支持了基于主流编程语言的智能合约（链码）设计，极大地方便了应用开发人员快速开发新型的分布式应用，或将已有应用迁移到区块链系统上。本章将以Fabric链码为例介绍其基本工作原理和核心的API，并通过案例演示如何利用Fabric网络提供的接口来实现典型的上层应用，最后还讨论了区块链应用开发的一些实践经验。通

区块链应用，一般由若干部署在区块链网络中的智能合约，以及调用这些智能合约的应用程序组成。典型的区块链应用程序的工作过程如图13-1所示。其中，用户专注于与业务本身相关的应用程序；智能合约则封装了与区块链账本直接交互的相关过程，被应用程序调用。图13-1　区块链应用程序为了实现完整的运行在区块链之上的分布式应用，开发者不仅需要开发上层应用，还需要编写智能合约代码。智能合约往往是无状态的、事件驱动的代码。被调用时智能合约会自动执行合约功能，支持进行图灵完备的计算。智能合约可以操作账本中的状态，这些状态往往记录着与业务相关的重要数据（例如，资产的拥有者）。应用程序通过向区块链网络发送交易来调用智能合约。同一个区块链网络可以部署多个智能合约，应用程序通过名称、版本号来指定具体调用哪个智能合约

在超级账本Fabric中，链码（chaincode）延伸自智能合约的概念（链码使用参见本书9.5节），支持采用主流高级编程语言编写。链码会对Fabric应用程序发送的交易做出响应，执行代码逻辑，与账本进行交互。区块链网络中的成员商定业务逻辑后，可将业务逻辑编程到链码中，大家遵循合约执行。链码会创建一些状态（state）并写入账本中。状态带有绑定到链码的命名空间，仅限于创建它的链码使用，不能被其他链码直接访问。不过，在合适的许可范围内，一个链码也可以调用另一个链码，间接访问其状态。另外，在一些场景下，不仅需要访问状态的当前值，还需要能够查询状态的所有历史值，这就对存放账本状态的数据库提出了更多的要求。链码在Fabric节点上的隔离沙盒（目前为Docker容器）中执行，并通过gRPC协议

工欲善其事，必先利其器。作为链码中的利器，shim.ChaincodeSubInterface提供了一系列API，供开发者在编写链码时灵活选择使用。这些API可分为四类：账本状态交互API、交易信息相关API、参数读取API、其他API，下面分别介绍。13.3.1　账本状态交互API如前文所述，链码需要将一些数据记录在分布式账本中。需要记录的数据称为状态（state），以键值对（key-value）的形式存储。账本状态交互API可以对账本状态进行操作，十分重要。方法的调用会更新交易提案的读、写集合，在Committer进行验证时会再次执行，跟账本状态进行比对。这类API的大致功能参见表13-1。表13-1　账本状态交互API提示　每个链码有自己的命名空间，所以不用担心自己设定的