基于自定义日志的Fabric的共识交易轨迹可视化追踪方法

李杉杉，王岩泽，邹英龙，陈焕雷，张贺*，吴欧

基于自定义日志的Fabric的共识交易轨迹可视化追踪方法

李杉杉1，2，王岩泽1，2，邹英龙1，2，陈焕雷3，张贺1，2*，吴欧1，2

（1.南京大学 软件学院，南京 210023； 2.计算机软件新技术国家重点实验室（南京大学），南京 210023； 3.中国农业银行 研发中心，广州 511400）（∗通信作者电子邮箱hezhang@nju.edu.cn）

联盟链缺少展示各个节点资源使用情况、健康状态、互相关系、共识交易流程等方面的可视化方法，为此提出一种基于自定义日志的Fabric共识交易轨迹追踪方法（FTL）。首先，以典型联盟链框架Hyperledger Fabric为基础设施实现区块链底层构建；然后，利用ELK工具链收集与解析Fabric的自定义共识交易日志，并利用Spring Boot作为业务逻辑处理框架；最后，采用专注于图分析领域的Graphin实现共识交易轨迹的可视化。实验结果表明，与原生Fabric应用相比，基于FTL的Fabric的应用框架在实现可视化追踪基础后，平均性能仅下降了8.8%，未造成显著延迟，可以为监管方提供更加智能的区块链监管方案。

Hyperledger Fabric；区块链；监管；共识交易；追踪；日志

0 引言

区块链［1］具有上链数据不可篡改、透明可追踪、去中心化等优势［2］，正逐步成为解决产业链上下游参与方相互信任的基础设施，在电子投票［3］、智慧交通［4］、供应链管理［5］、教育［6］、医疗［7］等多个领域或场景中得到广泛应用。

区块链技术的去中心化特性虽然改变了传统中心化信任模型，但使监管主体分散；而且区块链的匿名和不可篡改特性导致链上数据的内容监管难以实施。此外，区块链技术发展也出现了不少负面现象，如：区块链概念滥用；以区块链为媒介扰乱社会秩序，甚至进行非法犯罪活动［8-9］。近年来，一系列时间证明区块链技术本身，以及以区块链技术为基础的去中心化应用（Decentralized App， DApp）依旧存在着安全风险［10-11］。因此，有关区块链技术及其应用的监管技术研究迫在眉睫［12］。

区块链节点追踪与可视化是一种关键的区块链监管技术，是构建一个区块链中全部节点的“图谱”［12］。对于公有链来说，需要标记出区块链节点的详细信息，并利用可视化技术动态展示数据。但对于联盟链来说，节点只有通过授权才能加入网络，且节点通常以容器方式运行，网络地址可能会随容器的创建、销毁而变更。因此除了网络地址，还需要容器的某些专有属性不会因为容器的变化而变更。此外，证书相关的信息也十分重要，用于标识节点身份与权限。监管方除了关注节点的基本信息，还会着重关注共识交易的过程，因为共识交易涉及的共识机制是保证账本数据状态一致性、不可篡改性的关键。通过对共识交易过程的监控，监管方能清晰把控交易发起者、交易处理者、交易涉及的背书策略是否符合预设效果、生成的区块是否完全同步到各节点等细节。除了研究追踪技术，还需要研究可视化技术，以动态、直观、人性化的方式展示联盟链的节点、共识交易信息，为监管方提供细粒度、可视化、动态化的监管服务。

基于以上问题，本文选取国内使用频率较高且具有良好发展前景的联盟链框架Hyperledger Fabric作为研究对象，探索区块链节点追踪与可视化解决方案，并重点关注共识交易的过程追踪。基于Fabric V2.3版本，本文分析了Fabric共识交易流程中三个关键的谷歌远程过程调用（google Remote Procedure Call， gRPC）服务，并在此基础上提出了基于自定义日志的Fabric共识交易轨迹追踪方法（Fabric consensus transaction Tracking method based on custom Log， FTL），详细介绍了方法的原理和流程；然后基于FTL设计和实现了原型工具，并对FTL及原型工具的有效性进行了验证和性能测试，验证了FTL具有有效性和适用性。

1 相关研究

1.1　区块链

区块链是将数据以链式的方式组成的特定数据结构，利用共识机制更新和生成数据，调用智能合约来操作数据的一种去中心化的新型分布式计算范式［13］。区块链的链式结构如图1所示，每一个区块可分为区块头和区块体：区块体包含一定数量的交易集合；区块头记录指向前一个区块的哈希指针，从而在区块之间建立强关联性，因此篡改某一区块数据时会破坏哈希指针。修复哈希指针会导致高昂的计算代价［14］，因此篡改区块数据将变得异常困难。

根据节点去中心化程度的不同，通常可以把区块链分为三种类型：1）公有链，不限制节点的加入或退出，加入区块链的节点均可参与共识交易过程，去中心化程度最强，适用于加密货币场景，典型的公有链应用是比特币、以太坊等［15］；2）联盟链，节点只有通过许可认证才能参与区块链中的交易，去中心化程度适中，适用于跨机构的企业合作场景，典型的联盟链平台有Hyperledger Fabric、Quorum等；3）私有链，仅由一个组织或者机构完全控制节点的加入与退出，去中心化程度最弱，更偏向于企业内部使用。

图1　区块链链式结构

1.2　Hyperledger Fabric

Hyperledger（超级账本）是2015年Linux基金会发起的开源区块链社区，旨在为跨机构的企业提供商业级区块链开发平台，推动区块链技术的发展。其组织成员来自金融、IT、制造业等领军公司，目前已有IBM、英特尔、百度金融等250多家公司和机构。Hyperledger实现了具有典型成员准入机制的区块链模型，提供对区块链参与者的管理与审计，从而有效降低节点之间达成共识的成本，缩短运算周期，使Hyperledger能够满足不同企业应用场景的定制化需求。

当前Hyperledger社区共有16个子项目，Fabric是核心子项目之一。Fabric是一个具有准入机制的联盟链开发项目，它既克服了公有链交易吞吐量低的缺陷［16］，又避免了私有链强中心化的问题［17］，能为企业提供一个典型的具有许可机制的分布式账本平台。

1.3　ELK Stack

当前海量日志收集与分析技术已经发展得比较成熟，其中最具代表性的解决方案是ELK Stack，能实现不同分布式应用业务系统的日志收集与分析。

ELK（Elasticsearch Logstash Kibana）主要指基于Lucene 的分布式搜索引擎Elasticsearch、日志预处理和规则过滤工具Logstash以及功能多样的可视化日志分析处理平台Kibana三个开源软件组成的生态［18］。利用Elasticsearch快速索引的优势，可以灵活处理结构类型多变的日志内容。在可视化形式上，Kibana支持多种日志数据报表展示，例如饼图、地理位置图、标签云图、时序图等。Kibana还具有高级可视化组件，使日志分析的可视化内容更为丰富，如Vega、Canvas等。

1.4　Docker Logging Driver

云原生时代下，越来越多的服务采取Docker容器的方式进行部署［19］。在日志处理层面，Docker提供了一套针对容器的日志处理机制，如图2所示。

图2　Docker日志处理机制

当容器启动时，容器作为Docker Daemon（守护进程）的一个子进程运行。Docker Daemon可以获取容器里运行的应用进程的stdout（标准输出）与stderr（标准错误输出），并使用Logging Driver机制对这些日志输出信息进行处理。Docker支持多种Logging Driver 处理机制，如“json‑file”表示日志以JSON格式存储到宿主机的规定位置，默认路径格式是/var/lib/docker/containers//json.log。其中：“syslog”表示将日志写入Syslog守护进程，Syslog守护进程需要提前运行；“none”表示容器不输出日志，意味着通过docker log命令将不再返回任何日志数据。

1.5　节点追踪与可视化

目前还未有研究重点关注联盟链的节点追踪与可视化技术，但可借鉴有关区块链监控系统的设计思路。Ko等［20］基于远程过程调用（Remote Procedure Call， RPC）的方式设计了一个用于监控区块链的Agent，通过Agent可以收集区块数据、交易数据和智能合约数据。设计思想是利用区块链系统的JSON­RPC接口服务，通过RPC获取区块链中的数据，并对获取到的JSON格式数据进行解析、存储和分析，实现对区块链账本等数据的监控。在该研究的基础上，Lee等［21］初步实现了区块链监控系统。其中，Agent被安装在每一个区块链节点上，Agent收集好的数据会发往Collector进行数据落盘。由Node.js Web框架Express实现Web后端，用于提取Collector中存储的数据，并封装接口为前端提供数据服务。上述工作仅对接了比特币这类公有链应用，虽然提及设计思路可以沿用到联盟链，但是缺乏具体实践支撑。

Zheng等［22］提出了一种基于日志的方式获取区块链详细性能指标。设计理念是在参与验证的Peer节点上部署收集节点日志的守护进程，并对收集的日志进行解析分类，如区块数据、交易数据、执行数据、状态数据等，最后对解析好的数据进行可视化处理。文献［22］中对比了RPC方式，说明基于日志的方法实时性更优越。因为采用RPC方式时，频繁的调用会降低区块链系统的网络吞吐量和性能，导致无法实时获取指标数据。相比之下，采用日志的方式会在区块链节点产生数据后第一时间记录日志，并通过收集组件异步上报日志信息，具有更强的实时性。现有研究的对象有公有链，也有如CITA（Cryptape Inter‑enterprise Trust Automation）、Fabric的联盟链，涉及日志分析和基于拦截器的链路追踪思路［12］，为本文对区块链节点追踪方法的研究提供了思考方向和实践导向。

在可视化方向上，目前大部分涉及区块链可视化的研究文献或者工具基本都是围绕着公有链，尤其是比特币、以太坊这类热门的数字货币领域应用，如Blockchain Explorer、Etherscan。在联盟链中，开源的联盟链厂商提供可视化的管理工具，支持区块和节点等基本信息查看，但不能展示各个节点的资源使用情况、节点的健康状态、节点之间的关系、共识交易的流程等信息［23-24］。

2 区块链节点共识交易的追踪方法

Fabric已有的日志字段信息无法实现Fabric节点共识交易追踪功能，因此，本文提出了基于自定义日志的Fabric共识交易轨迹追踪方法FTL，在共识交易关键源码流程中嵌入部分自定义日志，通过收集与分析自定义日志数据，动态地还原出共识交易的轨迹。本章对FTL的原理和流程进行说明，通过分析Fabric共识交易流程中三个关键的gRPC服务，以明确自定义日志嵌入源码的位置以及日志的内容格式。

2.1　基本原理和流程

由于Fabric源码架构错综复杂，若要获取全部的共识交易细节流程需要对源码有足够深入的理解，同时也需要对Gossip、Raft等原理有深刻的认识，如不同Gossip消息的源码处理流程、Raft共识算法的代码实现。因此自定义日志在Fabric源码中的嵌入位置难以深入细节，可以往高层次方向考虑，获取Fabric节点共识交易的调用轨迹，从而实现一笔交易从交易发起、背书模拟、交易排序、区块分发以及区块同步等共识交易流程的追踪。通过在Fabric共识交易的gRPC 服务请求和响应方法处理入口打印日志，从而实现共识交易调用轨迹的追踪。在发送方发送请求前或者接收方接收请求后打印自定义日志，代表请求调用；在发送方发回响应前或者接收方接收响应后打印自定义日志，代表响应调用。通过收集并分析这些日志数据，就可建立起Fabric共识交易流程中不同节点之间的调用关系。因此，自定义日志的基本原理流程如图3所示。

图3　自定义日志原理流程

1）对于背书请求和响应，由Endorser Peer节点打印。因为Client是通过软件开发工具包（Software Development Kit，SDK）或命令行界面（Command Line Interface for batch scripting， CLI）与Fabric网络进行交互，Client产生的日志属于应用层的日志，在Fabric容器中无法获取，因此需要通过服务方打印日志。通过此日志信息，可以追踪到Client 与Endorser Peer节点交互的轨迹，从而明确经过背书的Peer节点数、背书的发起者以及背书接收者等信息。

2）对于交易排序的请求和响应，由Orderer节点打印。理由同上，Client打印的日志无法在Fabric容器中获取，需要由服务方打印日志。通过此日志信息，可以追踪到Client与Orderer节点交互的轨迹。

3）对于分发区块的处理，由Leader Peer节点打印。通过此日志信息，可以追踪到Orderer 节点与Leader Peer节点交互的轨迹，从而明确当前组织中Leader Peer节点的扮演者。

4）对于Gossip消息的分发和接收，需要结合Leader Peer节点和Committer Peer节点的日志一同打印。因为Gossip消息在分发时具有随机性，难以跟踪每一条Gossip消息具体转发的路径。但是通过此日志信息，可以明确有哪些Committer Peer节点最终处理了Gossip消息，以及区块数据是否完全同步到当前组织的各个Peer节点

2.2　ProcessProposal背书服务

为了明确背书请求和响应的日志位置，需要对背书服务的流程进行分析。ProcessProposal背书服务的proto文件如下所示：

//fabric‑protos 项目下 peer/peer.proto

service Endorser

｛rpc ProcessProposal（SignedProposal）

returns （ProposalResponse）；｝

背书服务是一元服务，其服务端是Peer节点，Peer节点在启动时会向本地的gRPC服务器注册背书服务；客户端是Client，可以通过SDK或者直接使用CLI命令行，向注册了背书服务的Peer节点发起背书请求。以CLI请求方式为例，客户端的背书请求入口位于fabric/internal/peer/chaincode/common.go中的ChaincodeInvokeOrQuery（）方法，而服务端的背书服务处理入口位于fabric/core/endorser/endorser.go中的 ProcessProposal（）方法。

源码调用流程如图4，Client通过CLI与Fabric网络进行交互，Client发起链码调用，底层会调用ChaincodeInvokeOrQuery（）方法，先创建交易提案并进行签名SignedProposal，再通过调用背书的gRPC方法endorser.ProcessProposal（）向服务端请求背书。Endorser Peer背书节点收到提案后，会调用endorser.preProcess（）预处理方法验证提案消息格式、签名合法性、指定通道的访问权限等。验证通过后，会执行endorser.SimulateProposal（）方法启动链码容器模拟交易执行。最后，Endorser Peer把收到的模拟执行结果通过背书系统链码（Endorsement System Chain Code， ESCC）生成背书签名，再将背书签名等数据封装成ProposalResponse 背书提案响应返回给Client。

图4　ProcessProposal 背书服务交互过程

2.3　Broadcast 广播服务

为明确交易排序请求和响应的日志位置，需要对广播服务的流程进行分析。Broadcast广播服务的proto文件如下：

// fabric‑protos 项目下 orderer/ab.proto service AtomicBroadcast

｛rpc Broadcast（stream common.Envelope）

returns （stream BroadcastResponse）；｝

广播服务是一个双向流服务，它的客户端和服务端均可发送和接收数据。广播服务的服务端是Orderer节点，Orderer节点在启动时会向本地的gRPC服务器注册广播服务；客户端是Client，当接收到足够的背书提案响应后，Client会把提案响应封装成交易，通过广播服务请求Orderer节点进行排序。客户端的广播请求入口位于fabric/internal/peer/chaincode/common.go中的ChaincodeInvokeOrQuery（）方法，而服务端的广播服务处理入口位于fab­ric/orderer/common/broadcast/broadcast.go中的ProcessMessage（）方法。当Client接收到足够多的提案响应结果后，如果是peer chaincode query等查询链码命令，则从提案响应结果中解析出背书节点模拟执行的查询内容并返回；如果是peer chaincode invoke等调用链码命令，说明需要对账本进行更新，则Client需要把交易提交Orderer节点进行排序。

源码流程上的调用如图5，首先Client通过protoutil.CreateSignedTx（）方法构造签名交易消息Envelope，它封装了提案请求消息、提案响应消息、背书信息列表等；Client再调用BroadcastClient.Send（）方法发送签名交易消息给Orderer节点，Orderer节点收到消息后，首先通过 ChannelSupportRegistrar.BroadcastChannelSupport（）方法解析出Envelope消息，获取通道头部对象、配置交易消息标志位等，再交给共识组件对交易进行排序；最后由Orderer节点返回一个仅包含状态处理信息的响应对BroadcastResponse给 Client，如状态为200表示广播服务处理成功。

图5　Broadcast广播服务交互过程

2.4　Deliver 分发服务

为明确区块分发和Gossip数据同步的日志位置，需要对分发服务的流程进行分析。Deliver分发服务的proto文件如下：

// fabric‑protos 项目下 orderer/ab.proto service

AtomicBroadcast ｛

rpc Deliver（stream common.Envelope）

returns （stream DeliverResponse）；｝

分发服务也是一个双向流服务，其服务端是Orderer节点，Orderer节点在启动的时候会向本地的gRPC服务器注册分发服务；客户端通常是Leader Peer节点，当Peer节点加入通道时会创建Deliver客户端与Orderer节点建立连接，并发送消息请求区块数据。客户端的分发服务请求入口位于fabric/internal/pkg/peer/blocksprovider/blocksprovider.go中的DeliverBlocks（）方法，而服务端的分发服务处理入口位于fabric/common/deliver/deliver.go中的deliverBlocks（）方法。接收Gossip消息并提交区块到账本的处理入口位于fabric/gossip/state/state.go中的commitBlock（）方法。

源码流程上的调用如图6所示，Leader Peer节点加入通道时，通过Deliver客户端向Orderer节点请求区块数据来初始化自身账本的内容。Leader Peer节点与Orderer节点建立好流之后，此流会保持连接。因为Leader Peer节点在发送请求时，请求的区块号范围是［当前账本高度，math.MaxUint64］，请求的区块号截止数转换为数字是264-1。因此，理论上Leader Peer节点会不断等待Orderer节点发回通道账本的最新区块。Ordere 节点接收区块分发服务消息后，首先检查消息的合法性，比如证书合法性、消息格式规范等。验证通过之后，Orderer节点解析出请求区块号的范围等内容，并开启协程调用cursor.Next（）方法获取指定范围的区块内容，然后再通过Server.SendBlockResponse（）方法把区块发回Leader Peer节点。按照同样的方式获取下一个区块再发给Leader Peer节点，此过程不断循环。当Orderer节点在检查没有新的区块生成时，获取区块数据的协程会被阻塞。直到Orderer节点通过处理广播服务的消息并生成新的区块内容，此协程才被唤醒，再取出新的区块数据发往Leader Peer节点，从而实现Orderer节点的区块数据分发。Leader Peer节点通过流收到区块数据后，区块数据的处理在Deliverer.processMsg（）方法中，并通过gossip.GossipMessage｛｝创建Gossip消息，利用Gossip服务将区块发往组织内的其他Peer节点。最终，每个Peer节点收到之后，从Gossip消息中解析出区块数据，再通过GossipStateProviderImpl.commitBlock（）方法把区块数据提交到本地账本中。

图6　Deliver分发服务交互过程

2.5　自定义日志位置与内容格式

为了获取Fabric节点调用关系轨迹，其中关系是由实体和实体之间的联系构成，在自定义日志的内容格式中应包含两个关键字段，即发送方和接收方。发送方和接收方分别代表两个实体，日志本身代表着发送方请求或响应了接收方，双方之间产生了调用关系。通过关系的思路，自定义日志字段设计如表1所示。

表1　自定义日志字段格式

在Client发起背书之前会创建一个交易ID，此交易ID贯穿整个共识交易的流程。此外，不同的通道可能会生成相同的交易ID。因此，通过组合自定义日志中的通道ID和交易ID，就可串联不同节点在不同共识交易阶段生成的无关联日志。至于服务调用顺序，还需打印时间字段。在设计的日志内容格式中未包含此字段，因为Fabric在输出日志时会自带时间戳字段，代表日志产生的时间，因此调用顺序可使用时间戳字段进行判断。

分析了Fabric共识交易的三个关键的gRPC服务后，自定义日志嵌入到Fabric共识交易源码的具体位置如下：①Endorser背书服务端处理方法ProcessProposal（）在接收到Client发送的背书请求后，打印代表背书请求的日志；Endorser背书服务端处理方法ProcessProposal（）把交易提案结果返回给Client前，打印代表背书响应的日志。②Broadcast广播服务端处理方法ProcessMessage（）在接收到Client发送的交易排序请求后，打印代表广播请求的日志；Broadcast广播服务端处理方法ProcessMessage（）在状态信息的响应结果返回之前，打印代表广播响应的日志。③Deliver分发服务的客户端处理方法DeliverBlocks（）在收到Orderer节点发送的区块数据后，打印代表区块分发的日志；在Gossip消息发送之前，打印代表Gossip消息分发的日志。④Gossip消息处理的方法commitBlock（），当Leader Peer节点通过Gossip服务分发区块后，每个Peer节点通过此方法接收并提交区块到本地账本中，在区块提交之后，打印代表区块提交的日志。

3 Fabric共识交易可视化追踪原型工具

根据第2章的自定义日志分析思路，本章基于FTL设计和实现了Fabric共识交易可视化追踪原型工具（简称FTL工具）。FTL工具整体架构如图7所示。

FTL工具处理的数据可分为两类：一类是Fabric网络中节点的日志数据，包含自定义日志数据和正常交易日志数据；另一类是Fabric网络中节点的指标数据。

1）对Fabric日志数据的处理。

首先在Peer、Orderer的共识交易关键方法中嵌入自定义日志，再由日志收集组件Filebeat收集Fabric网络中各个节点的日志，并进行初步的数据处理。随后，Filebeat把日志数据传给Logstash，由Logstash负责日志的复杂过滤与转换，将日志数据中的JSON格式字符串转为正确的“Key‑Value”形式，从而把不规则的字符串日志数据转为规整的JSON格式数据。最后，把转换好的日志数据存储到Elasticsearch集群中，利用Elasticsearch集群的高可用、高拓展性和快速检索等优势为上层应用提供服务。在可视化层面上，虽然Kibana具有丰富的日志分析可视化功能如Vega、Canvas等，但由于共识交易的自定义日志数据较为复杂，日志形式也多样，因此需要进行定制化的日志数据分析。

图7　FTL整体架构设计

FTL工具以Spring Boot和Ant Design Pro搭建可视化平台。Spring Boot后端应用首先从Elasticsearch中拉取自定义日志数据，随后对日志进行格式转换，把每一条无关联的日志数据转换为有关联的点边关系数据，最后封装成值对象（Value Object， VO）提供给前端使用。前端则以Ant Design Pro进行快速搭建，Ant Design Pro是一个企业级中后台前端解决方案，可以无缝使用Ant Design提供的多种React组件快速实现页面布局。Ant Design Pro前端应用调用Spring Boot后端应用封装好的接口来实现数据的获取。至于可视化点边关系的技术选型方面，FTL工具未选择通用的可视化方案如Echarts、Highcharts等，因为这些方案在点边关系的可视化效果上，可设置的点边样式和属性较少，不能进行深入的定制化处理。因此FTL工具选择了专注于图分析领域的Graphin实现共识交易轨迹的可视化。Graphin不仅具有丰富的图布局和图交互功能，内置的图算法也为后续对共识交易的调用数据分析提供支撑。

2）对Fabric指标数据的处理。

Fabric V2.3版本基于RESTful API风格为Peer和Orderer节点提供了以下四种运维服务：

a）日志等级管理/logspec：可查看Peer和Orderer节点的日志等级。

b）节点健康检查/healthz：可查看Peer和Orderer节点的存活情况、CouchDB的连接情况等。

c）版本信息/version：可查看Peer和Orderer节点的版本信息。

d）指标信息/metric：可对外支持Prometheus和StatsD第三方组件接入。

FTL工具对接Fabric提供的/metric指标数据接口，使用 Prometheus拉取指标数据，并利用开源的度量分析与可视化组件Grafana提取Prometheus中的数据来实现指标数据的定制化展示。日志收集、过滤和存储的ELK组件，以及指标数据收集组件Prometheus和可视化组件Grafana均采用Docker方式进行部署，对于FTL工具开发涉及的组件或框架版本信息如表2所示。

表2　FTL工具开发涉及组件或框架的版本信息

FTL工具的实现主要包含五个关键环节：基于FTL的代码实现；ELK工具链的搭建，利用Docker Logging Driver机制收集Fabric日志；Spring Boot后端应用处理自定义日志业务逻辑；前端Graphin组件实现Fabric共识交易轨迹的可视化；Fabric指标数据的采集与展示。

使用Graphin可视化测试Fabric 共识交易轨迹的效果如图8所示。图9是FTL工具对Grafana配置后，Fabric指标数据的整体显示效果。FTL的具体实现源码本文已开源公开至Github上，详见文献［17］。

图8　Graphin实现共识交易节点调用轨迹可视化

图9　Grafana可视化Fabric指标数据

4 FTL评估

为验证FTL的有效性与性能，从两方面进行评测：1）对Fabric网络节点的配置进行修改，通过判断FTL工具生成的共识交易轨迹图的正确性，以验证FTL的有效性；2）测试FTL给原生Fabric源码所带来的性能损耗程度，以验证FTL的实际适用性。

有效性测试方面，Fabric网络从三个角度进行修改：背书策略变更、Leader Peer节点开启动态选举以及动态添加组织，从而多方面验证FTL工具在不同Fabric节点环境下的适用情况。通过对背书策略的修改，验证Client与Endorser Peer背书节点交互轨迹的正确性；通过对Leader Peer节点的修改，验证Orderer节点与各个组织的Leader Peer节点交互轨迹的正确性；通过动态添加组织，验证多组织多节点变化下，组织内多个Peer节点的数据同步轨迹的正确性。完整测试流程及测试环境的搭建过程详见文献［17］。测试结果显示，对于可验证Leader Peer节点、可验证背书策略和可验证多组织多节点的变化，FTL和工具均可以兼容。

除了对FTL进行有效性验证之外，还需考虑FTL所带来的性能损耗问题，需要进行性能方面的测试。由于本文选取的Fabric版本为 2.3，Hyperledger社区提供的开源区块链性能测试工具Caliper暂不支持此Fabric版本。因此，本文选取Tape轻量级区块链性能测试工具。它是由超级账本中国技术工作组（Technical Working Group China， TWGC）性能优化小组维护的一款开源工具，可以对Fabric共识交易流程中的背书、提交账本、交易区块分发等阶段进行压力测试。性能测试实验环境如表3，详细测试过程及相关配置见文献［17］。

表3　性能测试环境

性能对比的网络设置分别为：基于原生Fabric源码启动的测试网络和基于FTL修改过的Fabric源码启动的测试网络。两个测试网络的组织、节点、安装的链码等配置均保持一致，并由Tape工具通过gRPC调用与Fabric网络进行交互。为防止因网络带宽造成的延迟，Tape工具与Fabric网络部署在同一台物理机上；采用pyecharts库实现性能数据的可视化；设置Tape记录每出块10次所消耗的时间，测试结果如图10所示。测试结果显示，刚开始测试时，出块所消耗的时间较多，因为Peer节点在处理提案，后续消耗时间逐渐均衡。从图10可观测到，基于FTL的Fabric源码性能比原生Fabric源码性能略微低，因为FTL需要在Fabric源码中新增部分逻辑代码，尤其是为了获取交易ID来关联共识交易中不同节点的自定义日志。例如，在区块提交到本地账本的方法时，需要从区块数据中解析出交易ID，会根据proto文件对区块数据进行反序列化。虽然Protocol Buffer在序列化和反序列化上已经有不少优化，但还是会带来一定的性能损耗，平均性能下降占比为8.8%。但从整体上来看，二者差异不大，经Tape工具测试TPS（Transaction Per Second）后，两种方法每秒平均处理的交易数之差小于10，可见FTL方法中系统吞吐量未出现明显的衰减。因此，FTL具有一定的实用性。

图10　原生Fabric源码和基于FTL修改过的 Fabric源码的性能差异对比

5 结语

本文提出了基于自定义日志的Fabric共识交易轨迹追踪方法FTL，并对方法的原理和流程进行详细说明；分析了Fabric共识交易流程中三个关键的gRPC服务，明确了自定义日志在源码中的嵌入位置和日志内容格式。基于FTL，本文还设计并实现了Fabric共识交易可视化追踪原型工具——FTL工具。最后，通过对FTL进行有效性验证与性能测试，实验结果表明了FTL能够有效追踪到Fabric各节点共识交易的调用轨迹，并且性能表现符合预期需求。

针对Fabric共识交易追踪与可视化的研究，后续会进一步深化共识交易的源码、原理的学习，优化自定义日志的内容，细化自定义日志的嵌入位置，挖掘更多区块链节点追踪与可视化的解决方案。在工具功能上，优化Graphin的表现形式，完善工具功能的完整性，积极探索与区块链业务平台的结合点，形成更加闭环的区块链监管平台。此外，基于共识交易的追踪数据，加强交易数据的实时跟踪与异常交易分析的研究工作，探索区块链穿透式监管技术研究方向，为监管方提供更加智能的区块链监管方案。

[1] NAKAMOTO S. Bitcoin： a peer­to­peer electronic cash system［EB/OL］. （2008-11-31）［2022-01-07］. https：//bitcoin.org/bitcoin.pdf.

[2] KHETTRY A R， PATIL K R， BASAVARAJU A C. A detailed review on blockchain and its applications［J］. SN Computer Science， 2021， 2（1）： 30.

[3] GHOSH A，GUPTA S， DUA A， et al. Security of cryptocurrencies in blockchain technology： state­of­art， challenges and future prospects［J］. Journal of Network and Computer Applications， 2020， 163： 102635.

[4] LUND E H， JACCHERI L， LI J， et al. Blockchain and sustainability： a systematic mapping study［C］// Proceedings of the 2019 IEEE/ACM 2nd International Workshop on Emerging Trends in Software Engineering for Blockchain. Piscataway： IEEE， 2019： 16-23.

[5] POURNADER M， SHI Y， SEURING S， et al. Blockchain applications in supply chains， transport and logistics： a systematic review of the literature［J］. International Journal of Production Research， 2020， 58（7）： 2063-2081.

[6] HAN M， LI Z， HE J S， et al. A novel blockchain­based education records verification solution［C］// Proceedings of the 19th Annual SIG Conference on Information Technology Education. New York： ACM， 2018： 178-183.

[7] NARIKIMILLI N R S， KUMAR A， ANTU A D， et al. Blockchain applications in healthcare — a review and future perspective［C］// Proceedings of the 2020 International Conference on Blockchain. Cham： Springer. 2020： 198-218.

[8] 邹萍，李艳东，王肖，等. 区块链监管的现状与展望［J］. 网络空间安全， 2019， 10（6）： 51-56.（ZOU P， LI Y D，WANG X， et al.The status quo and future trends of blockchain regulation［J］.Cyberspace Security，2019， 10（6）： 51-56.）

[9] QAYYUM A， QADIR J， JANJUA M U， et al. Using blockchain to rein in the new post‑truth world and check the spread of fake news［J］. IT Professional， 2019， 21（4）： 16-24.

[10] IQBAL M， MATULEVIČIUS R. Blockchain­based application security risks： A systematic literature review［C］// Proceedings of the 2019 International Conference on Advanced Information Systems Engineering. Cham： Springer， 2019： 176-188.

[11] TAYLO P J， DARGAHI T， DEHGHANTANHA A， et al. A systematic literature review of blockchain cyber security［J］. Digital Communications and Networks， 2020， 6（2）： 147-156.

[12] 洪学海，汪洋，廖方宇. 区块链安全监管技术研究综述［J］. 中国科学基金， 2020，34（1）： 18-24.（HONG X H， WANG Y， LIAO F Y. Review on the Technology Research of Blockchain Security Supervision［J］. Bulletin of National Natural Science Foundation of China， 2020， 34（1）： 18-24.）

[13] 袁勇，王飞跃. 区块链技术发展现状与展望［J］. 自动化学报， 2016， 42（4）： 481-494.（YUAN Y， WANG F Y. Blockchain： the state of the art and future trends［J］.Acta Automatica Sinica， 2016， 42（4）： 481-494.）

[14] 郭上铜，王瑞锦，张凤荔.区块链技术原理与应用综述［J］.计算机科学，2021，48（2）：271-281. （GUO S T， WANG R J， ZHANG F L. Summary of principle and application of blockchain［J］. Computer Science， 2021， 48（2）： 271-281.）

[15] LIN I C， LIAO T C. A survey of blockchain security issues and challenges［J］. International Journal of Network Security， 2017， 19（5）： 653-659.

[16] KAUR G， GANDHI C. Scalability in blockchain： challenges and solutions［M］// Handbook of Research on Blockchain Technology. Pittsburgh： Academic Press， 2020： 373-406.

[17] 邵奇峰，张召，朱燕超，等.企业级区块链技术综述［J］. 软件学报， 2019， 30（9）： 2571– 2592.（SHAO Q F， ZHANG Z， ZHU Y C， et al. Survey of enterprise blockchains［J］. Journal of Software，2019， 30（9）： 2571-2592.）

[18] YANG C‑T， KRISTIANI E， WANG Y‑T， et al. On construction of a network log management system using ELK Stack with Ceph ［J］. The Journal of Supercomputing， 2020， 76（8）： 6344-6360.

[19] SHAH J， DUBARIA D. Building modern clouds： using Docker， Kubernetes & Google cloud platform［C］// Proceedings of the 2019 IEEE 9th Annual Computing and Communication Workshop and Conference. Piscataway： IEEE. 2019： 0184 - 0189.

[20] KO K， LEE C， JEONG T， et al. Design of RPC­based blockchain monitoring agent［C］// Proceedings of the 2018 International Conference on Information and Communication Technology Convergence. Piscataway： IEEE， 2018： 1090-1095.

[21] LEE C， KIM H， MAHARJAN S， et al. Blockchain explorer based on RPC­based monitoring system［C］// Proceedings of the 2019 IEEE International Conference on Blockchain and Cryptocurrency. Piscataway： IEEE， 2019： 117-119.

[22] ZHENG P， ZHENG Z， LUO X， et al. A detailed and real­time performance monitoring framework for blockchain systems［C］// Proceedings of the 2018 IEEE/ACM 40th International Conference on Software Engineering： Software Engineering in Practice Track. New York： ACM， 2018： 134-143.

[23] KANGA D B， AZZOUAZI M， EL GHOUMRARI M Y， et al. Management and monitoring of blockchain systems ［J］. Procedia Computer Science， 2020， 177： 605-612.

[24] HELEBRANDT P， BELLUS M， RIES M， et al. Blockchain adoption for monitoring and management of enterprise networks ［C］// Proceedings of the 2018 IEEE 9th Annual Information Technology， Electronics and Mobile Communication Conference. Piscataway： IEEE， 2018： 1221-1225.

Consensus transaction trajectory visualization tracking method for Fabric based on custom logs

LI Shanshan1，2， WANG Yanze1，2， ZOU Yinglong1，2， CHEN Huanlei3， ZHANG He1，2*， WU Ou1，2

（1，，210023，；2（），210023，；3，511400，）

Concerning that the federated chain lacks visualization methods to show the resource usage， health status， mutual relationship and consensus transaction process of each node， a Fabric consensus transaction Tracking method based on custom Log （FTL） was proposed. Firstly， Hyperledger Fabric， a typical federation framework， was used as the infrastructure to build the bottom layer of FTL. Then， the custom consensus transaction logs of the Fabric were collected and parsed by using the ELK （Elasticsearch，Logstash， Kibana） tool chain， and Spring Boot was used as the business logic processing framework. Finally， Graphin which focuses on graph analysis was utilized to realize the visualization of consensus trade trajectory. Experimental results show that compared with native Fabric applications， FTL Fabric‑based application framework only experienced an 8.8% average performance decline after the implementation of visual tracking basis without significant latency， which can provide a more intelligent blockchain supervision solution for regulators.

Hyperledger Fabric; blockchain; supervision; consensus transaction; tracking; log

This work is partially supported by National Key Research and Development Program of China （2019YFE0105500）， National Natural Science Foundation of China （62072227， 61802173）， Key Research and Development Program of Jiangsu Province （BE2021002）， Intergovernmental Bilateral Innovation Project of Jiangsu Province （BZ2020017）， Jiangsu Scientific Research and Innovation Program （KYCX_21_0061）， Research Council of Norway （309494）.

LI Shanshan， born in 1990， Ph. D.， assistant research fellow. Her research interests include microservice architecture， blockchain， software engineering.

WANG Yanze， born in 1998， M. S. candidate. His research interests include blockchain.

ZOU Yinglong， born in 2000. His research interests include blockchain.

CHEN Huanlei， born in 1994， M. S. candidate. His research interests include blockchain.

ZHANG He， born in 1970， Ph. D.， professor. His research interests include software engineering， service‑oriented computing， big data， blockchain.

WU Ou， born in 1981， M. S.， lecturer. Her research interests include blockchain， queuing theory.

TP391

A

1001-9081（2022）11-3421-08

10.11772/j.issn.1001-9081.2021111935

2021⁃11⁃14；

2022⁃01⁃21；

2022⁃02⁃28。

国家重点研发计划项目（2019YFE0105500）；国家自然科学基金资助项目（62072227， 61802173）；江苏省重点研发计划项目（BE2021002）；江苏省政府间双边创新项目（BZ2020017）；江苏省科研创新计划项目（KYCX_21_0061）；挪威研究理事会项目（309494）。

李杉杉（1990—），女，山东平度人，助理研究员，博士，CCF会员，主要研究方向：微服务架构、区块链、软件工程；王岩泽（1998—），男，山西太原人，硕士研究生，CCF会员，主要研究方向：区块链；邹英龙（2000—），男，黑龙江哈尔滨人，主要研究方向：区块链；陈焕雷（1994—），男，海南海口人，硕士研究生，主要研究方向：区块链；张贺（1970—），男，天津人，教授，博士，CCF会员，主要研究方向：软件工程、面向服务计算、大数据、区块链；吴欧（1981—），女，辽宁新民人，讲师，硕士，主要研究方向：区块链、排队论。