基于自定義日志的Fabric的共識(shí)交易軌跡可視化追蹤方法

李杉杉，王巖澤，鄒英龍，陳煥雷，張賀*，吳歐

基于自定義日志的Fabric的共識(shí)交易軌跡可視化追蹤方法

李杉杉1，2，王巖澤1，2，鄒英龍1，2，陳煥雷3，張賀1，2*，吳歐1，2

（1.南京大學(xué) 軟件學(xué)院，南京 210023； 2.計(jì)算機(jī)軟件新技術(shù)國家重點(diǎn)實(shí)驗(yàn)室（南京大學(xué)），南京 210023； 3.中國農(nóng)業(yè)銀行 研發(fā)中心，廣州 511400）（?通信作者電子郵箱hezhang@nju.edu.cn）

聯(lián)盟鏈缺少展示各個(gè)節(jié)點(diǎn)資源使用情況、健康狀態(tài)、互相關(guān)系、共識(shí)交易流程等方面的可視化方法，為此提出一種基于自定義日志的Fabric共識(shí)交易軌跡追蹤方法（FTL）。首先，以典型聯(lián)盟鏈框架Hyperledger Fabric為基礎(chǔ)設(shè)施實(shí)現(xiàn)區(qū)塊鏈底層構(gòu)建；然后，利用ELK工具鏈?zhǔn)占c解析Fabric的自定義共識(shí)交易日志，并利用Spring Boot作為業(yè)務(wù)邏輯處理框架；最后，采用專注于圖分析領(lǐng)域的Graphin實(shí)現(xiàn)共識(shí)交易軌跡的可視化。實(shí)驗(yàn)結(jié)果表明，與原生Fabric應(yīng)用相比，基于FTL的Fabric的應(yīng)用框架在實(shí)現(xiàn)可視化追蹤基礎(chǔ)后，平均性能僅下降了8.8%，未造成顯著延遲，可以為監(jiān)管方提供更加智能的區(qū)塊鏈監(jiān)管方案。

Hyperledger Fabric；區(qū)塊鏈；監(jiān)管；共識(shí)交易；追蹤；日志

0 引言

區(qū)塊鏈［1］具有上鏈數(shù)據(jù)不可篡改、透明可追蹤、去中心化等優(yōu)勢(shì)［2］，正逐步成為解決產(chǎn)業(yè)鏈上下游參與方相互信任的基礎(chǔ)設(shè)施，在電子投票［3］、智慧交通［4］、供應(yīng)鏈管理［5］、教育［6］、醫(yī)療［7］等多個(gè)領(lǐng)域或場(chǎng)景中得到廣泛應(yīng)用。

區(qū)塊鏈技術(shù)的去中心化特性雖然改變了傳統(tǒng)中心化信任模型，但使監(jiān)管主體分散；而且區(qū)塊鏈的匿名和不可篡改特性導(dǎo)致鏈上數(shù)據(jù)的內(nèi)容監(jiān)管難以實(shí)施。此外，區(qū)塊鏈技術(shù)發(fā)展也出現(xiàn)了不少負(fù)面現(xiàn)象，如：區(qū)塊鏈概念濫用；以區(qū)塊鏈為媒介擾亂社會(huì)秩序，甚至進(jìn)行非法犯罪活動(dòng)［8-9］。近年來，一系列時(shí)間證明區(qū)塊鏈技術(shù)本身，以及以區(qū)塊鏈技術(shù)為基礎(chǔ)的去中心化應(yīng)用（Decentralized App， DApp）依舊存在著安全風(fēng)險(xiǎn)［10-11］。因此，有關(guān)區(qū)塊鏈技術(shù)及其應(yīng)用的監(jiān)管技術(shù)研究迫在眉睫［12］。

區(qū)塊鏈節(jié)點(diǎn)追蹤與可視化是一種關(guān)鍵的區(qū)塊鏈監(jiān)管技術(shù)，是構(gòu)建一個(gè)區(qū)塊鏈中全部節(jié)點(diǎn)的“圖譜”［12］。對(duì)于公有鏈來說，需要標(biāo)記出區(qū)塊鏈節(jié)點(diǎn)的詳細(xì)信息，并利用可視化技術(shù)動(dòng)態(tài)展示數(shù)據(jù)。但對(duì)于聯(lián)盟鏈來說，節(jié)點(diǎn)只有通過授權(quán)才能加入網(wǎng)絡(luò)，且節(jié)點(diǎn)通常以容器方式運(yùn)行，網(wǎng)絡(luò)地址可能會(huì)隨容器的創(chuàng)建、銷毀而變更。因此除了網(wǎng)絡(luò)地址，還需要容器的某些專有屬性不會(huì)因?yàn)槿萜鞯淖兓兏４送?，證書相關(guān)的信息也十分重要，用于標(biāo)識(shí)節(jié)點(diǎn)身份與權(quán)限。監(jiān)管方除了關(guān)注節(jié)點(diǎn)的基本信息，還會(huì)著重關(guān)注共識(shí)交易的過程，因?yàn)楣沧R(shí)交易涉及的共識(shí)機(jī)制是保證賬本數(shù)據(jù)狀態(tài)一致性、不可篡改性的關(guān)鍵。通過對(duì)共識(shí)交易過程的監(jiān)控，監(jiān)管方能清晰把控交易發(fā)起者、交易處理者、交易涉及的背書策略是否符合預(yù)設(shè)效果、生成的區(qū)塊是否完全同步到各節(jié)點(diǎn)等細(xì)節(jié)。除了研究追蹤技術(shù)，還需要研究可視化技術(shù)，以動(dòng)態(tài)、直觀、人性化的方式展示聯(lián)盟鏈的節(jié)點(diǎn)、共識(shí)交易信息，為監(jiān)管方提供細(xì)粒度、可視化、動(dòng)態(tài)化的監(jiān)管服務(wù)。

基于以上問題，本文選取國內(nèi)使用頻率較高且具有良好發(fā)展前景的聯(lián)盟鏈框架Hyperledger Fabric作為研究對(duì)象，探索區(qū)塊鏈節(jié)點(diǎn)追蹤與可視化解決方案，并重點(diǎn)關(guān)注共識(shí)交易的過程追蹤?；贔abric V2.3版本，本文分析了Fabric共識(shí)交易流程中三個(gè)關(guān)鍵的谷歌遠(yuǎn)程過程調(diào)用（google Remote Procedure Call， gRPC）服務(wù)，并在此基礎(chǔ)上提出了基于自定義日志的Fabric共識(shí)交易軌跡追蹤方法（Fabric consensus transaction Tracking method based on custom Log， FTL），詳細(xì)介紹了方法的原理和流程；然后基于FTL設(shè)計(jì)和實(shí)現(xiàn)了原型工具，并對(duì)FTL及原型工具的有效性進(jìn)行了驗(yàn)證和性能測(cè)試，驗(yàn)證了FTL具有有效性和適用性。

1 相關(guān)研究

1.1　區(qū)塊鏈

區(qū)塊鏈?zhǔn)菍?shù)據(jù)以鏈?zhǔn)降姆绞浇M成的特定數(shù)據(jù)結(jié)構(gòu)，利用共識(shí)機(jī)制更新和生成數(shù)據(jù)，調(diào)用智能合約來操作數(shù)據(jù)的一種去中心化的新型分布式計(jì)算范式［13］。區(qū)塊鏈的鏈?zhǔn)浇Y(jié)構(gòu)如圖1所示，每一個(gè)區(qū)塊可分為區(qū)塊頭和區(qū)塊體：區(qū)塊體包含一定數(shù)量的交易集合；區(qū)塊頭記錄指向前一個(gè)區(qū)塊的哈希指針，從而在區(qū)塊之間建立強(qiáng)關(guān)聯(lián)性，因此篡改某一區(qū)塊數(shù)據(jù)時(shí)會(huì)破壞哈希指針。修復(fù)哈希指針會(huì)導(dǎo)致高昂的計(jì)算代價(jià)［14］，因此篡改區(qū)塊數(shù)據(jù)將變得異常困難。

根據(jù)節(jié)點(diǎn)去中心化程度的不同，通?？梢园褏^(qū)塊鏈分為三種類型：1）公有鏈，不限制節(jié)點(diǎn)的加入或退出，加入?yún)^(qū)塊鏈的節(jié)點(diǎn)均可參與共識(shí)交易過程，去中心化程度最強(qiáng)，適用于加密貨幣場(chǎng)景，典型的公有鏈應(yīng)用是比特幣、以太坊等［15］；2）聯(lián)盟鏈，節(jié)點(diǎn)只有通過許可認(rèn)證才能參與區(qū)塊鏈中的交易，去中心化程度適中，適用于跨機(jī)構(gòu)的企業(yè)合作場(chǎng)景，典型的聯(lián)盟鏈平臺(tái)有Hyperledger Fabric、Quorum等；3）私有鏈，僅由一個(gè)組織或者機(jī)構(gòu)完全控制節(jié)點(diǎn)的加入與退出，去中心化程度最弱，更偏向于企業(yè)內(nèi)部使用。

圖1　區(qū)塊鏈鏈?zhǔn)浇Y(jié)構(gòu)

1.2　Hyperledger Fabric

Hyperledger（超級(jí)賬本）是2015年Linux基金會(huì)發(fā)起的開源區(qū)塊鏈社區(qū)，旨在為跨機(jī)構(gòu)的企業(yè)提供商業(yè)級(jí)區(qū)塊鏈開發(fā)平臺(tái)，推動(dòng)區(qū)塊鏈技術(shù)的發(fā)展。其組織成員來自金融、IT、制造業(yè)等領(lǐng)軍公司，目前已有IBM、英特爾、百度金融等250多家公司和機(jī)構(gòu)。Hyperledger實(shí)現(xiàn)了具有典型成員準(zhǔn)入機(jī)制的區(qū)塊鏈模型，提供對(duì)區(qū)塊鏈參與者的管理與審計(jì)，從而有效降低節(jié)點(diǎn)之間達(dá)成共識(shí)的成本，縮短運(yùn)算周期，使Hyperledger能夠滿足不同企業(yè)應(yīng)用場(chǎng)景的定制化需求。

當(dāng)前Hyperledger社區(qū)共有16個(gè)子項(xiàng)目，F(xiàn)abric是核心子項(xiàng)目之一。Fabric是一個(gè)具有準(zhǔn)入機(jī)制的聯(lián)盟鏈開發(fā)項(xiàng)目，它既克服了公有鏈交易吞吐量低的缺陷［16］，又避免了私有鏈強(qiáng)中心化的問題［17］，能為企業(yè)提供一個(gè)典型的具有許可機(jī)制的分布式賬本平臺(tái)。

1.3　ELK Stack

當(dāng)前海量日志收集與分析技術(shù)已經(jīng)發(fā)展得比較成熟，其中最具代表性的解決方案是ELK Stack，能實(shí)現(xiàn)不同分布式應(yīng)用業(yè)務(wù)系統(tǒng)的日志收集與分析。

ELK（Elasticsearch Logstash Kibana）主要指基于Lucene 的分布式搜索引擎Elasticsearch、日志預(yù)處理和規(guī)則過濾工具Logstash以及功能多樣的可視化日志分析處理平臺(tái)Kibana三個(gè)開源軟件組成的生態(tài)［18］。利用Elasticsearch快速索引的優(yōu)勢(shì)，可以靈活處理結(jié)構(gòu)類型多變的日志內(nèi)容。在可視化形式上，Kibana支持多種日志數(shù)據(jù)報(bào)表展示，例如餅圖、地理位置圖、標(biāo)簽云圖、時(shí)序圖等。Kibana還具有高級(jí)可視化組件，使日志分析的可視化內(nèi)容更為豐富，如Vega、Canvas等。

1.4　Docker Logging Driver

云原生時(shí)代下，越來越多的服務(wù)采取Docker容器的方式進(jìn)行部署［19］。在日志處理層面，Docker提供了一套針對(duì)容器的日志處理機(jī)制，如圖2所示。

圖2　Docker日志處理機(jī)制

當(dāng)容器啟動(dòng)時(shí)，容器作為Docker Daemon（守護(hù)進(jìn)程）的一個(gè)子進(jìn)程運(yùn)行。Docker Daemon可以獲取容器里運(yùn)行的應(yīng)用進(jìn)程的stdout（標(biāo)準(zhǔn)輸出）與stderr（標(biāo)準(zhǔn)錯(cuò)誤輸出），并使用Logging Driver機(jī)制對(duì)這些日志輸出信息進(jìn)行處理。Docker支持多種Logging Driver 處理機(jī)制，如“json?file”表示日志以JSON格式存儲(chǔ)到宿主機(jī)的規(guī)定位置，默認(rèn)路徑格式是/var/lib/docker/containers//json.log。其中：“syslog”表示將日志寫入Syslog守護(hù)進(jìn)程，Syslog守護(hù)進(jìn)程需要提前運(yùn)行；“none”表示容器不輸出日志，意味著通過docker log命令將不再返回任何日志數(shù)據(jù)。

1.5　節(jié)點(diǎn)追蹤與可視化

目前還未有研究重點(diǎn)關(guān)注聯(lián)盟鏈的節(jié)點(diǎn)追蹤與可視化技術(shù)，但可借鑒有關(guān)區(qū)塊鏈監(jiān)控系統(tǒng)的設(shè)計(jì)思路。Ko等［20］基于遠(yuǎn)程過程調(diào)用（Remote Procedure Call， RPC）的方式設(shè)計(jì)了一個(gè)用于監(jiān)控區(qū)塊鏈的Agent，通過Agent可以收集區(qū)塊數(shù)據(jù)、交易數(shù)據(jù)和智能合約數(shù)據(jù)。設(shè)計(jì)思想是利用區(qū)塊鏈系統(tǒng)的JSON-RPC接口服務(wù)，通過RPC獲取區(qū)塊鏈中的數(shù)據(jù)，并對(duì)獲取到的JSON格式數(shù)據(jù)進(jìn)行解析、存儲(chǔ)和分析，實(shí)現(xiàn)對(duì)區(qū)塊鏈賬本等數(shù)據(jù)的監(jiān)控。在該研究的基礎(chǔ)上，Lee等［21］初步實(shí)現(xiàn)了區(qū)塊鏈監(jiān)控系統(tǒng)。其中，Agent被安裝在每一個(gè)區(qū)塊鏈節(jié)點(diǎn)上，Agent收集好的數(shù)據(jù)會(huì)發(fā)往Collector進(jìn)行數(shù)據(jù)落盤。由Node.js Web框架Express實(shí)現(xiàn)Web后端，用于提取Collector中存儲(chǔ)的數(shù)據(jù)，并封裝接口為前端提供數(shù)據(jù)服務(wù)。上述工作僅對(duì)接了比特幣這類公有鏈應(yīng)用，雖然提及設(shè)計(jì)思路可以沿用到聯(lián)盟鏈，但是缺乏具體實(shí)踐支撐。

Zheng等［22］提出了一種基于日志的方式獲取區(qū)塊鏈詳細(xì)性能指標(biāo)。設(shè)計(jì)理念是在參與驗(yàn)證的Peer節(jié)點(diǎn)上部署收集節(jié)點(diǎn)日志的守護(hù)進(jìn)程，并對(duì)收集的日志進(jìn)行解析分類，如區(qū)塊數(shù)據(jù)、交易數(shù)據(jù)、執(zhí)行數(shù)據(jù)、狀態(tài)數(shù)據(jù)等，最后對(duì)解析好的數(shù)據(jù)進(jìn)行可視化處理。文獻(xiàn)［22］中對(duì)比了RPC方式，說明基于日志的方法實(shí)時(shí)性更優(yōu)越。因?yàn)椴捎肦PC方式時(shí)，頻繁的調(diào)用會(huì)降低區(qū)塊鏈系統(tǒng)的網(wǎng)絡(luò)吞吐量和性能，導(dǎo)致無法實(shí)時(shí)獲取指標(biāo)數(shù)據(jù)。相比之下，采用日志的方式會(huì)在區(qū)塊鏈節(jié)點(diǎn)產(chǎn)生數(shù)據(jù)后第一時(shí)間記錄日志，并通過收集組件異步上報(bào)日志信息，具有更強(qiáng)的實(shí)時(shí)性?，F(xiàn)有研究的對(duì)象有公有鏈，也有如CITA（Cryptape Inter?enterprise Trust Automation）、Fabric的聯(lián)盟鏈，涉及日志分析和基于攔截器的鏈路追蹤思路［12］，為本文對(duì)區(qū)塊鏈節(jié)點(diǎn)追蹤方法的研究提供了思考方向和實(shí)踐導(dǎo)向。

在可視化方向上，目前大部分涉及區(qū)塊鏈可視化的研究文獻(xiàn)或者工具基本都是圍繞著公有鏈，尤其是比特幣、以太坊這類熱門的數(shù)字貨幣領(lǐng)域應(yīng)用，如Blockchain Explorer、Etherscan。在聯(lián)盟鏈中，開源的聯(lián)盟鏈廠商提供可視化的管理工具，支持區(qū)塊和節(jié)點(diǎn)等基本信息查看，但不能展示各個(gè)節(jié)點(diǎn)的資源使用情況、節(jié)點(diǎn)的健康狀態(tài)、節(jié)點(diǎn)之間的關(guān)系、共識(shí)交易的流程等信息［23-24］。

2 區(qū)塊鏈節(jié)點(diǎn)共識(shí)交易的追蹤方法

Fabric已有的日志字段信息無法實(shí)現(xiàn)Fabric節(jié)點(diǎn)共識(shí)交易追蹤功能，因此，本文提出了基于自定義日志的Fabric共識(shí)交易軌跡追蹤方法FTL，在共識(shí)交易關(guān)鍵源碼流程中嵌入部分自定義日志，通過收集與分析自定義日志數(shù)據(jù)，動(dòng)態(tài)地還原出共識(shí)交易的軌跡。本章對(duì)FTL的原理和流程進(jìn)行說明，通過分析Fabric共識(shí)交易流程中三個(gè)關(guān)鍵的gRPC服務(wù)，以明確自定義日志嵌入源碼的位置以及日志的內(nèi)容格式。

2.1　基本原理和流程

由于Fabric源碼架構(gòu)錯(cuò)綜復(fù)雜，若要獲取全部的共識(shí)交易細(xì)節(jié)流程需要對(duì)源碼有足夠深入的理解，同時(shí)也需要對(duì)Gossip、Raft等原理有深刻的認(rèn)識(shí)，如不同Gossip消息的源碼處理流程、Raft共識(shí)算法的代碼實(shí)現(xiàn)。因此自定義日志在Fabric源碼中的嵌入位置難以深入細(xì)節(jié)，可以往高層次方向考慮，獲取Fabric節(jié)點(diǎn)共識(shí)交易的調(diào)用軌跡，從而實(shí)現(xiàn)一筆交易從交易發(fā)起、背書模擬、交易排序、區(qū)塊分發(fā)以及區(qū)塊同步等共識(shí)交易流程的追蹤。通過在Fabric共識(shí)交易的gRPC 服務(wù)請(qǐng)求和響應(yīng)方法處理入口打印日志，從而實(shí)現(xiàn)共識(shí)交易調(diào)用軌跡的追蹤。在發(fā)送方發(fā)送請(qǐng)求前或者接收方接收請(qǐng)求后打印自定義日志，代表請(qǐng)求調(diào)用；在發(fā)送方發(fā)回響應(yīng)前或者接收方接收響應(yīng)后打印自定義日志，代表響應(yīng)調(diào)用。通過收集并分析這些日志數(shù)據(jù)，就可建立起Fabric共識(shí)交易流程中不同節(jié)點(diǎn)之間的調(diào)用關(guān)系。因此，自定義日志的基本原理流程如圖3所示。

圖3　自定義日志原理流程

1）對(duì)于背書請(qǐng)求和響應(yīng)，由Endorser Peer節(jié)點(diǎn)打印。因?yàn)镃lient是通過軟件開發(fā)工具包（Software Development Kit，SDK）或命令行界面（Command Line Interface for batch scripting， CLI）與Fabric網(wǎng)絡(luò)進(jìn)行交互，Client產(chǎn)生的日志屬于應(yīng)用層的日志，在Fabric容器中無法獲取，因此需要通過服務(wù)方打印日志。通過此日志信息，可以追蹤到Client 與Endorser Peer節(jié)點(diǎn)交互的軌跡，從而明確經(jīng)過背書的Peer節(jié)點(diǎn)數(shù)、背書的發(fā)起者以及背書接收者等信息。

2）對(duì)于交易排序的請(qǐng)求和響應(yīng)，由Orderer節(jié)點(diǎn)打印。理由同上，Client打印的日志無法在Fabric容器中獲取，需要由服務(wù)方打印日志。通過此日志信息，可以追蹤到Client與Orderer節(jié)點(diǎn)交互的軌跡。

3）對(duì)于分發(fā)區(qū)塊的處理，由Leader Peer節(jié)點(diǎn)打印。通過此日志信息，可以追蹤到Orderer 節(jié)點(diǎn)與Leader Peer節(jié)點(diǎn)交互的軌跡，從而明確當(dāng)前組織中Leader Peer節(jié)點(diǎn)的扮演者。

4）對(duì)于Gossip消息的分發(fā)和接收，需要結(jié)合Leader Peer節(jié)點(diǎn)和Committer Peer節(jié)點(diǎn)的日志一同打印。因?yàn)镚ossip消息在分發(fā)時(shí)具有隨機(jī)性，難以跟蹤每一條Gossip消息具體轉(zhuǎn)發(fā)的路徑。但是通過此日志信息，可以明確有哪些Committer Peer節(jié)點(diǎn)最終處理了Gossip消息，以及區(qū)塊數(shù)據(jù)是否完全同步到當(dāng)前組織的各個(gè)Peer節(jié)點(diǎn)

2.2　ProcessProposal背書服務(wù)

為了明確背書請(qǐng)求和響應(yīng)的日志位置，需要對(duì)背書服務(wù)的流程進(jìn)行分析。ProcessProposal背書服務(wù)的proto文件如下所示：

//fabric?protos 項(xiàng)目下 peer/peer.proto

service Endorser

｛rpc ProcessProposal（SignedProposal）

returns （ProposalResponse）；｝

背書服務(wù)是一元服務(wù)，其服務(wù)端是Peer節(jié)點(diǎn)，Peer節(jié)點(diǎn)在啟動(dòng)時(shí)會(huì)向本地的gRPC服務(wù)器注冊(cè)背書服務(wù)；客戶端是Client，可以通過SDK或者直接使用CLI命令行，向注冊(cè)了背書服務(wù)的Peer節(jié)點(diǎn)發(fā)起背書請(qǐng)求。以CLI請(qǐng)求方式為例，客戶端的背書請(qǐng)求入口位于fabric/internal/peer/chaincode/common.go中的ChaincodeInvokeOrQuery（）方法，而服務(wù)端的背書服務(wù)處理入口位于fabric/core/endorser/endorser.go中的 ProcessProposal（）方法。

源碼調(diào)用流程如圖4，Client通過CLI與Fabric網(wǎng)絡(luò)進(jìn)行交互，Client發(fā)起鏈碼調(diào)用，底層會(huì)調(diào)用ChaincodeInvokeOrQuery（）方法，先創(chuàng)建交易提案并進(jìn)行簽名SignedProposal，再通過調(diào)用背書的gRPC方法endorser.ProcessProposal（）向服務(wù)端請(qǐng)求背書。Endorser Peer背書節(jié)點(diǎn)收到提案后，會(huì)調(diào)用endorser.preProcess（）預(yù)處理方法驗(yàn)證提案消息格式、簽名合法性、指定通道的訪問權(quán)限等。驗(yàn)證通過后，會(huì)執(zhí)行endorser.SimulateProposal（）方法啟動(dòng)鏈碼容器模擬交易執(zhí)行。最后，Endorser Peer把收到的模擬執(zhí)行結(jié)果通過背書系統(tǒng)鏈碼（Endorsement System Chain Code， ESCC）生成背書簽名，再將背書簽名等數(shù)據(jù)封裝成ProposalResponse 背書提案響應(yīng)返回給Client。

圖4　ProcessProposal 背書服務(wù)交互過程

2.3　Broadcast 廣播服務(wù)

為明確交易排序請(qǐng)求和響應(yīng)的日志位置，需要對(duì)廣播服務(wù)的流程進(jìn)行分析。Broadcast廣播服務(wù)的proto文件如下：

// fabric?protos 項(xiàng)目下 orderer/ab.proto service AtomicBroadcast

｛rpc Broadcast（stream common.Envelope）

returns （stream BroadcastResponse）；｝

廣播服務(wù)是一個(gè)雙向流服務(wù)，它的客戶端和服務(wù)端均可發(fā)送和接收數(shù)據(jù)。廣播服務(wù)的服務(wù)端是Orderer節(jié)點(diǎn)，Orderer節(jié)點(diǎn)在啟動(dòng)時(shí)會(huì)向本地的gRPC服務(wù)器注冊(cè)廣播服務(wù)；客戶端是Client，當(dāng)接收到足夠的背書提案響應(yīng)后，Client會(huì)把提案響應(yīng)封裝成交易，通過廣播服務(wù)請(qǐng)求Orderer節(jié)點(diǎn)進(jìn)行排序?？蛻舳说膹V播請(qǐng)求入口位于fabric/internal/peer/chaincode/common.go中的ChaincodeInvokeOrQuery（）方法，而服務(wù)端的廣播服務(wù)處理入口位于fab-ric/orderer/common/broadcast/broadcast.go中的ProcessMessage（）方法。當(dāng)Client接收到足夠多的提案響應(yīng)結(jié)果后，如果是peer chaincode query等查詢鏈碼命令，則從提案響應(yīng)結(jié)果中解析出背書節(jié)點(diǎn)模擬執(zhí)行的查詢內(nèi)容并返回；如果是peer chaincode invoke等調(diào)用鏈碼命令，說明需要對(duì)賬本進(jìn)行更新，則Client需要把交易提交Orderer節(jié)點(diǎn)進(jìn)行排序。

源碼流程上的調(diào)用如圖5，首先Client通過protoutil.CreateSignedTx（）方法構(gòu)造簽名交易消息Envelope，它封裝了提案請(qǐng)求消息、提案響應(yīng)消息、背書信息列表等；Client再調(diào)用BroadcastClient.Send（）方法發(fā)送簽名交易消息給Orderer節(jié)點(diǎn)，Orderer節(jié)點(diǎn)收到消息后，首先通過 ChannelSupportRegistrar.BroadcastChannelSupport（）方法解析出Envelope消息，獲取通道頭部對(duì)象、配置交易消息標(biāo)志位等，再交給共識(shí)組件對(duì)交易進(jìn)行排序；最后由Orderer節(jié)點(diǎn)返回一個(gè)僅包含狀態(tài)處理信息的響應(yīng)對(duì)BroadcastResponse給 Client，如狀態(tài)為200表示廣播服務(wù)處理成功。

圖5　Broadcast廣播服務(wù)交互過程

2.4　Deliver 分發(fā)服務(wù)

為明確區(qū)塊分發(fā)和Gossip數(shù)據(jù)同步的日志位置，需要對(duì)分發(fā)服務(wù)的流程進(jìn)行分析。Deliver分發(fā)服務(wù)的proto文件如下：

// fabric?protos 項(xiàng)目下 orderer/ab.proto service

AtomicBroadcast ｛

rpc Deliver（stream common.Envelope）

returns （stream DeliverResponse）；｝

分發(fā)服務(wù)也是一個(gè)雙向流服務(wù)，其服務(wù)端是Orderer節(jié)點(diǎn)，Orderer節(jié)點(diǎn)在啟動(dòng)的時(shí)候會(huì)向本地的gRPC服務(wù)器注冊(cè)分發(fā)服務(wù)；客戶端通常是Leader Peer節(jié)點(diǎn)，當(dāng)Peer節(jié)點(diǎn)加入通道時(shí)會(huì)創(chuàng)建Deliver客戶端與Orderer節(jié)點(diǎn)建立連接，并發(fā)送消息請(qǐng)求區(qū)塊數(shù)據(jù)?？蛻舳说姆职l(fā)服務(wù)請(qǐng)求入口位于fabric/internal/pkg/peer/blocksprovider/blocksprovider.go中的DeliverBlocks（）方法，而服務(wù)端的分發(fā)服務(wù)處理入口位于fabric/common/deliver/deliver.go中的deliverBlocks（）方法。接收Gossip消息并提交區(qū)塊到賬本的處理入口位于fabric/gossip/state/state.go中的commitBlock（）方法。

源碼流程上的調(diào)用如圖6所示，Leader Peer節(jié)點(diǎn)加入通道時(shí)，通過Deliver客戶端向Orderer節(jié)點(diǎn)請(qǐng)求區(qū)塊數(shù)據(jù)來初始化自身賬本的內(nèi)容。Leader Peer節(jié)點(diǎn)與Orderer節(jié)點(diǎn)建立好流之后，此流會(huì)保持連接。因?yàn)長eader Peer節(jié)點(diǎn)在發(fā)送請(qǐng)求時(shí)，請(qǐng)求的區(qū)塊號(hào)范圍是［當(dāng)前賬本高度，math.MaxUint64］，請(qǐng)求的區(qū)塊號(hào)截止數(shù)轉(zhuǎn)換為數(shù)字是264-1。因此，理論上Leader Peer節(jié)點(diǎn)會(huì)不斷等待Orderer節(jié)點(diǎn)發(fā)回通道賬本的最新區(qū)塊。Ordere 節(jié)點(diǎn)接收區(qū)塊分發(fā)服務(wù)消息后，首先檢查消息的合法性，比如證書合法性、消息格式規(guī)范等。驗(yàn)證通過之后，Orderer節(jié)點(diǎn)解析出請(qǐng)求區(qū)塊號(hào)的范圍等內(nèi)容，并開啟協(xié)程調(diào)用cursor.Next（）方法獲取指定范圍的區(qū)塊內(nèi)容，然后再通過Server.SendBlockResponse（）方法把區(qū)塊發(fā)回Leader Peer節(jié)點(diǎn)。按照同樣的方式獲取下一個(gè)區(qū)塊再發(fā)給Leader Peer節(jié)點(diǎn)，此過程不斷循環(huán)。當(dāng)Orderer節(jié)點(diǎn)在檢查沒有新的區(qū)塊生成時(shí)，獲取區(qū)塊數(shù)據(jù)的協(xié)程會(huì)被阻塞。直到Orderer節(jié)點(diǎn)通過處理廣播服務(wù)的消息并生成新的區(qū)塊內(nèi)容，此協(xié)程才被喚醒，再取出新的區(qū)塊數(shù)據(jù)發(fā)往Leader Peer節(jié)點(diǎn)，從而實(shí)現(xiàn)Orderer節(jié)點(diǎn)的區(qū)塊數(shù)據(jù)分發(fā)。Leader Peer節(jié)點(diǎn)通過流收到區(qū)塊數(shù)據(jù)后，區(qū)塊數(shù)據(jù)的處理在Deliverer.processMsg（）方法中，并通過gossip.GossipMessage｛｝創(chuàng)建Gossip消息，利用Gossip服務(wù)將區(qū)塊發(fā)往組織內(nèi)的其他Peer節(jié)點(diǎn)。最終，每個(gè)Peer節(jié)點(diǎn)收到之后，從Gossip消息中解析出區(qū)塊數(shù)據(jù)，再通過GossipStateProviderImpl.commitBlock（）方法把區(qū)塊數(shù)據(jù)提交到本地賬本中。

圖6　Deliver分發(fā)服務(wù)交互過程

2.5　自定義日志位置與內(nèi)容格式

為了獲取Fabric節(jié)點(diǎn)調(diào)用關(guān)系軌跡，其中關(guān)系是由實(shí)體和實(shí)體之間的聯(lián)系構(gòu)成，在自定義日志的內(nèi)容格式中應(yīng)包含兩個(gè)關(guān)鍵字段，即發(fā)送方和接收方。發(fā)送方和接收方分別代表兩個(gè)實(shí)體，日志本身代表著發(fā)送方請(qǐng)求或響應(yīng)了接收方，雙方之間產(chǎn)生了調(diào)用關(guān)系。通過關(guān)系的思路，自定義日志字段設(shè)計(jì)如表1所示。

表1　自定義日志字段格式

在Client發(fā)起背書之前會(huì)創(chuàng)建一個(gè)交易ID，此交易ID貫穿整個(gè)共識(shí)交易的流程。此外，不同的通道可能會(huì)生成相同的交易ID。因此，通過組合自定義日志中的通道ID和交易ID，就可串聯(lián)不同節(jié)點(diǎn)在不同共識(shí)交易階段生成的無關(guān)聯(lián)日志。至于服務(wù)調(diào)用順序，還需打印時(shí)間字段。在設(shè)計(jì)的日志內(nèi)容格式中未包含此字段，因?yàn)镕abric在輸出日志時(shí)會(huì)自帶時(shí)間戳字段，代表日志產(chǎn)生的時(shí)間，因此調(diào)用順序可使用時(shí)間戳字段進(jìn)行判斷。

分析了Fabric共識(shí)交易的三個(gè)關(guān)鍵的gRPC服務(wù)后，自定義日志嵌入到Fabric共識(shí)交易源碼的具體位置如下：①Endorser背書服務(wù)端處理方法ProcessProposal（）在接收到Client發(fā)送的背書請(qǐng)求后，打印代表背書請(qǐng)求的日志；Endorser背書服務(wù)端處理方法ProcessProposal（）把交易提案結(jié)果返回給Client前，打印代表背書響應(yīng)的日志。②Broadcast廣播服務(wù)端處理方法ProcessMessage（）在接收到Client發(fā)送的交易排序請(qǐng)求后，打印代表廣播請(qǐng)求的日志；Broadcast廣播服務(wù)端處理方法ProcessMessage（）在狀態(tài)信息的響應(yīng)結(jié)果返回之前，打印代表廣播響應(yīng)的日志。③Deliver分發(fā)服務(wù)的客戶端處理方法DeliverBlocks（）在收到Orderer節(jié)點(diǎn)發(fā)送的區(qū)塊數(shù)據(jù)后，打印代表區(qū)塊分發(fā)的日志；在Gossip消息發(fā)送之前，打印代表Gossip消息分發(fā)的日志。④Gossip消息處理的方法commitBlock（），當(dāng)Leader Peer節(jié)點(diǎn)通過Gossip服務(wù)分發(fā)區(qū)塊后，每個(gè)Peer節(jié)點(diǎn)通過此方法接收并提交區(qū)塊到本地賬本中，在區(qū)塊提交之后，打印代表區(qū)塊提交的日志。

3 Fabric共識(shí)交易可視化追蹤原型工具

根據(jù)第2章的自定義日志分析思路，本章基于FTL設(shè)計(jì)和實(shí)現(xiàn)了Fabric共識(shí)交易可視化追蹤原型工具（簡稱FTL工具）。FTL工具整體架構(gòu)如圖7所示。

FTL工具處理的數(shù)據(jù)可分為兩類：一類是Fabric網(wǎng)絡(luò)中節(jié)點(diǎn)的日志數(shù)據(jù)，包含自定義日志數(shù)據(jù)和正常交易日志數(shù)據(jù)；另一類是Fabric網(wǎng)絡(luò)中節(jié)點(diǎn)的指標(biāo)數(shù)據(jù)。

1）對(duì)Fabric日志數(shù)據(jù)的處理。

首先在Peer、Orderer的共識(shí)交易關(guān)鍵方法中嵌入自定義日志，再由日志收集組件Filebeat收集Fabric網(wǎng)絡(luò)中各個(gè)節(jié)點(diǎn)的日志，并進(jìn)行初步的數(shù)據(jù)處理。隨后，F(xiàn)ilebeat把日志數(shù)據(jù)傳給Logstash，由Logstash負(fù)責(zé)日志的復(fù)雜過濾與轉(zhuǎn)換，將日志數(shù)據(jù)中的JSON格式字符串轉(zhuǎn)為正確的“Key?Value”形式，從而把不規(guī)則的字符串日志數(shù)據(jù)轉(zhuǎn)為規(guī)整的JSON格式數(shù)據(jù)。最后，把轉(zhuǎn)換好的日志數(shù)據(jù)存儲(chǔ)到Elasticsearch集群中，利用Elasticsearch集群的高可用、高拓展性和快速檢索等優(yōu)勢(shì)為上層應(yīng)用提供服務(wù)。在可視化層面上，雖然Kibana具有豐富的日志分析可視化功能如Vega、Canvas等，但由于共識(shí)交易的自定義日志數(shù)據(jù)較為復(fù)雜，日志形式也多樣，因此需要進(jìn)行定制化的日志數(shù)據(jù)分析。

圖7　FTL整體架構(gòu)設(shè)計(jì)

FTL工具以Spring Boot和Ant Design Pro搭建可視化平臺(tái)。Spring Boot后端應(yīng)用首先從Elasticsearch中拉取自定義日志數(shù)據(jù)，隨后對(duì)日志進(jìn)行格式轉(zhuǎn)換，把每一條無關(guān)聯(lián)的日志數(shù)據(jù)轉(zhuǎn)換為有關(guān)聯(lián)的點(diǎn)邊關(guān)系數(shù)據(jù)，最后封裝成值對(duì)象（Value Object， VO）提供給前端使用。前端則以Ant Design Pro進(jìn)行快速搭建，Ant Design Pro是一個(gè)企業(yè)級(jí)中后臺(tái)前端解決方案，可以無縫使用Ant Design提供的多種React組件快速實(shí)現(xiàn)頁面布局。Ant Design Pro前端應(yīng)用調(diào)用Spring Boot后端應(yīng)用封裝好的接口來實(shí)現(xiàn)數(shù)據(jù)的獲取。至于可視化點(diǎn)邊關(guān)系的技術(shù)選型方面，F(xiàn)TL工具未選擇通用的可視化方案如Echarts、Highcharts等，因?yàn)檫@些方案在點(diǎn)邊關(guān)系的可視化效果上，可設(shè)置的點(diǎn)邊樣式和屬性較少，不能進(jìn)行深入的定制化處理。因此FTL工具選擇了專注于圖分析領(lǐng)域的Graphin實(shí)現(xiàn)共識(shí)交易軌跡的可視化。Graphin不僅具有豐富的圖布局和圖交互功能，內(nèi)置的圖算法也為后續(xù)對(duì)共識(shí)交易的調(diào)用數(shù)據(jù)分析提供支撐。

2）對(duì)Fabric指標(biāo)數(shù)據(jù)的處理。

Fabric V2.3版本基于RESTful API風(fēng)格為Peer和Orderer節(jié)點(diǎn)提供了以下四種運(yùn)維服務(wù)：

a）日志等級(jí)管理/logspec：可查看Peer和Orderer節(jié)點(diǎn)的日志等級(jí)。

b）節(jié)點(diǎn)健康檢查/healthz：可查看Peer和Orderer節(jié)點(diǎn)的存活情況、CouchDB的連接情況等。

c）版本信息/version：可查看Peer和Orderer節(jié)點(diǎn)的版本信息。

d）指標(biāo)信息/metric：可對(duì)外支持Prometheus和StatsD第三方組件接入。

FTL工具對(duì)接Fabric提供的/metric指標(biāo)數(shù)據(jù)接口，使用 Prometheus拉取指標(biāo)數(shù)據(jù)，并利用開源的度量分析與可視化組件Grafana提取Prometheus中的數(shù)據(jù)來實(shí)現(xiàn)指標(biāo)數(shù)據(jù)的定制化展示。日志收集、過濾和存儲(chǔ)的ELK組件，以及指標(biāo)數(shù)據(jù)收集組件Prometheus和可視化組件Grafana均采用Docker方式進(jìn)行部署，對(duì)于FTL工具開發(fā)涉及的組件或框架版本信息如表2所示。

表2　FTL工具開發(fā)涉及組件或框架的版本信息

FTL工具的實(shí)現(xiàn)主要包含五個(gè)關(guān)鍵環(huán)節(jié)：基于FTL的代碼實(shí)現(xiàn)；ELK工具鏈的搭建，利用Docker Logging Driver機(jī)制收集Fabric日志；Spring Boot后端應(yīng)用處理自定義日志業(yè)務(wù)邏輯；前端Graphin組件實(shí)現(xiàn)Fabric共識(shí)交易軌跡的可視化；Fabric指標(biāo)數(shù)據(jù)的采集與展示。

使用Graphin可視化測(cè)試Fabric 共識(shí)交易軌跡的效果如圖8所示。圖9是FTL工具對(duì)Grafana配置后，F(xiàn)abric指標(biāo)數(shù)據(jù)的整體顯示效果。FTL的具體實(shí)現(xiàn)源碼本文已開源公開至Github上，詳見文獻(xiàn)［17］。

圖8　Graphin實(shí)現(xiàn)共識(shí)交易節(jié)點(diǎn)調(diào)用軌跡可視化

圖9　Grafana可視化Fabric指標(biāo)數(shù)據(jù)

4 FTL評(píng)估

為驗(yàn)證FTL的有效性與性能，從兩方面進(jìn)行評(píng)測(cè)：1）對(duì)Fabric網(wǎng)絡(luò)節(jié)點(diǎn)的配置進(jìn)行修改，通過判斷FTL工具生成的共識(shí)交易軌跡圖的正確性，以驗(yàn)證FTL的有效性；2）測(cè)試FTL給原生Fabric源碼所帶來的性能損耗程度，以驗(yàn)證FTL的實(shí)際適用性。

有效性測(cè)試方面，F(xiàn)abric網(wǎng)絡(luò)從三個(gè)角度進(jìn)行修改：背書策略變更、Leader Peer節(jié)點(diǎn)開啟動(dòng)態(tài)選舉以及動(dòng)態(tài)添加組織，從而多方面驗(yàn)證FTL工具在不同F(xiàn)abric節(jié)點(diǎn)環(huán)境下的適用情況。通過對(duì)背書策略的修改，驗(yàn)證Client與Endorser Peer背書節(jié)點(diǎn)交互軌跡的正確性；通過對(duì)Leader Peer節(jié)點(diǎn)的修改，驗(yàn)證Orderer節(jié)點(diǎn)與各個(gè)組織的Leader Peer節(jié)點(diǎn)交互軌跡的正確性；通過動(dòng)態(tài)添加組織，驗(yàn)證多組織多節(jié)點(diǎn)變化下，組織內(nèi)多個(gè)Peer節(jié)點(diǎn)的數(shù)據(jù)同步軌跡的正確性。完整測(cè)試流程及測(cè)試環(huán)境的搭建過程詳見文獻(xiàn)［17］。測(cè)試結(jié)果顯示，對(duì)于可驗(yàn)證Leader Peer節(jié)點(diǎn)、可驗(yàn)證背書策略和可驗(yàn)證多組織多節(jié)點(diǎn)的變化，F(xiàn)TL和工具均可以兼容。

除了對(duì)FTL進(jìn)行有效性驗(yàn)證之外，還需考慮FTL所帶來的性能損耗問題，需要進(jìn)行性能方面的測(cè)試。由于本文選取的Fabric版本為 2.3，Hyperledger社區(qū)提供的開源區(qū)塊鏈性能測(cè)試工具Caliper暫不支持此Fabric版本。因此，本文選取Tape輕量級(jí)區(qū)塊鏈性能測(cè)試工具。它是由超級(jí)賬本中國技術(shù)工作組（Technical Working Group China， TWGC）性能優(yōu)化小組維護(hù)的一款開源工具，可以對(duì)Fabric共識(shí)交易流程中的背書、提交賬本、交易區(qū)塊分發(fā)等階段進(jìn)行壓力測(cè)試。性能測(cè)試實(shí)驗(yàn)環(huán)境如表3，詳細(xì)測(cè)試過程及相關(guān)配置見文獻(xiàn)［17］。

表3　性能測(cè)試環(huán)境

性能對(duì)比的網(wǎng)絡(luò)設(shè)置分別為：基于原生Fabric源碼啟動(dòng)的測(cè)試網(wǎng)絡(luò)和基于FTL修改過的Fabric源碼啟動(dòng)的測(cè)試網(wǎng)絡(luò)。兩個(gè)測(cè)試網(wǎng)絡(luò)的組織、節(jié)點(diǎn)、安裝的鏈碼等配置均保持一致，并由Tape工具通過gRPC調(diào)用與Fabric網(wǎng)絡(luò)進(jìn)行交互。為防止因網(wǎng)絡(luò)帶寬造成的延遲，Tape工具與Fabric網(wǎng)絡(luò)部署在同一臺(tái)物理機(jī)上；采用pyecharts庫實(shí)現(xiàn)性能數(shù)據(jù)的可視化；設(shè)置Tape記錄每出塊10次所消耗的時(shí)間，測(cè)試結(jié)果如圖10所示。測(cè)試結(jié)果顯示，剛開始測(cè)試時(shí)，出塊所消耗的時(shí)間較多，因?yàn)镻eer節(jié)點(diǎn)在處理提案，后續(xù)消耗時(shí)間逐漸均衡。從圖10可觀測(cè)到，基于FTL的Fabric源碼性能比原生Fabric源碼性能略微低，因?yàn)镕TL需要在Fabric源碼中新增部分邏輯代碼，尤其是為了獲取交易ID來關(guān)聯(lián)共識(shí)交易中不同節(jié)點(diǎn)的自定義日志。例如，在區(qū)塊提交到本地賬本的方法時(shí)，需要從區(qū)塊數(shù)據(jù)中解析出交易ID，會(huì)根據(jù)proto文件對(duì)區(qū)塊數(shù)據(jù)進(jìn)行反序列化。雖然Protocol Buffer在序列化和反序列化上已經(jīng)有不少優(yōu)化，但還是會(huì)帶來一定的性能損耗，平均性能下降占比為8.8%。但從整體上來看，二者差異不大，經(jīng)Tape工具測(cè)試TPS（Transaction Per Second）后，兩種方法每秒平均處理的交易數(shù)之差小于10，可見FTL方法中系統(tǒng)吞吐量未出現(xiàn)明顯的衰減。因此，F(xiàn)TL具有一定的實(shí)用性。

圖10　原生Fabric源碼和基于FTL修改過的 Fabric源碼的性能差異對(duì)比

5 結(jié)語

本文提出了基于自定義日志的Fabric共識(shí)交易軌跡追蹤方法FTL，并對(duì)方法的原理和流程進(jìn)行詳細(xì)說明；分析了Fabric共識(shí)交易流程中三個(gè)關(guān)鍵的gRPC服務(wù)，明確了自定義日志在源碼中的嵌入位置和日志內(nèi)容格式?；贔TL，本文還設(shè)計(jì)并實(shí)現(xiàn)了Fabric共識(shí)交易可視化追蹤原型工具——FTL工具。最后，通過對(duì)FTL進(jìn)行有效性驗(yàn)證與性能測(cè)試，實(shí)驗(yàn)結(jié)果表明了FTL能夠有效追蹤到Fabric各節(jié)點(diǎn)共識(shí)交易的調(diào)用軌跡，并且性能表現(xiàn)符合預(yù)期需求。

針對(duì)Fabric共識(shí)交易追蹤與可視化的研究，后續(xù)會(huì)進(jìn)一步深化共識(shí)交易的源碼、原理的學(xué)習(xí)，優(yōu)化自定義日志的內(nèi)容，細(xì)化自定義日志的嵌入位置，挖掘更多區(qū)塊鏈節(jié)點(diǎn)追蹤與可視化的解決方案。在工具功能上，優(yōu)化Graphin的表現(xiàn)形式，完善工具功能的完整性，積極探索與區(qū)塊鏈業(yè)務(wù)平臺(tái)的結(jié)合點(diǎn)，形成更加閉環(huán)的區(qū)塊鏈監(jiān)管平臺(tái)。此外，基于共識(shí)交易的追蹤數(shù)據(jù)，加強(qiáng)交易數(shù)據(jù)的實(shí)時(shí)跟蹤與異常交易分析的研究工作，探索區(qū)塊鏈穿透式監(jiān)管技術(shù)研究方向，為監(jiān)管方提供更加智能的區(qū)塊鏈監(jiān)管方案。

[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] 鄒萍，李艷東，王肖，等. 區(qū)塊鏈監(jiān)管的現(xiàn)狀與展望［J］. 網(wǎng)絡(luò)空間安全， 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] 洪學(xué)海，汪洋，廖方宇. 區(qū)塊鏈安全監(jiān)管技術(shù)研究綜述［J］. 中國科學(xué)基金， 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] 袁勇，王飛躍. 區(qū)塊鏈技術(shù)發(fā)展現(xiàn)狀與展望［J］. 自動(dòng)化學(xué)報(bào)， 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] 郭上銅，王瑞錦，張鳳荔.區(qū)塊鏈技術(shù)原理與應(yīng)用綜述［J］.計(jì)算機(jī)科學(xué)，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] 邵奇峰，張召，朱燕超，等.企業(yè)級(jí)區(qū)塊鏈技術(shù)綜述［J］. 軟件學(xué)報(bào)， 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。

國家重點(diǎn)研發(fā)計(jì)劃項(xiàng)目（2019YFE0105500）；國家自然科學(xué)基金資助項(xiàng)目（62072227， 61802173）；江蘇省重點(diǎn)研發(fā)計(jì)劃項(xiàng)目（BE2021002）；江蘇省政府間雙邊創(chuàng)新項(xiàng)目（BZ2020017）；江蘇省科研創(chuàng)新計(jì)劃項(xiàng)目（KYCX_21_0061）；挪威研究理事會(huì)項(xiàng)目（309494）。

李杉杉（1990—），女，山東平度人，助理研究員，博士，CCF會(huì)員，主要研究方向：微服務(wù)架構(gòu)、區(qū)塊鏈、軟件工程；王巖澤（1998—），男，山西太原人，碩士研究生，CCF會(huì)員，主要研究方向：區(qū)塊鏈；鄒英龍（2000—），男，黑龍江哈爾濱人，主要研究方向：區(qū)塊鏈；陳煥雷（1994—），男，海南?？谌?，碩士研究生，主要研究方向：區(qū)塊鏈；張賀（1970—），男，天津人，教授，博士，CCF會(huì)員，主要研究方向：軟件工程、面向服務(wù)計(jì)算、大數(shù)據(jù)、區(qū)塊鏈；吳歐（1981—），女，遼寧新民人，講師，碩士，主要研究方向：區(qū)塊鏈、排隊(duì)論。