基于自定義日志的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—），女，遼寧新民人，講師，碩士，主要研究方向：區塊鏈、排隊論。