史文幟，程永強，劉曉峰，陳澤華

（1.太原理工大學信息與計算機學院，山西晉中 030600；2.太原理工大學大數(shù)據(jù)學院，山西晉中 030600）

隨著全域旅游的發(fā)展，旅游市場的復雜性增加，智慧旅游的不斷發(fā)展[1-2]對傳統(tǒng)旅游業(yè)提出了挑戰(zhàn)。在線旅游平臺(Online Travel Agency,OTA)發(fā)展缺乏成熟經(jīng)驗，國內(nèi)攜程、同程旅游等在線旅游服務平臺在給客戶出行提供便捷服務的同時也帶來了商家點評造假、虛假宣傳等負面效應，使得行業(yè)上下游的參與者付出更多成本，同時這些問題也衍生出游客對OTA 平臺不信任的問題。

區(qū)塊鏈技術(shù)是將數(shù)學、密碼學、計算機等跨領(lǐng)域?qū)W科結(jié)合而形成的一項新技術(shù)，越來越多的學者開始將其應用于供應鏈、食品溯源、版權(quán)保護、政務等眾多領(lǐng)域[3-6]，其中也包括在旅游業(yè)的應用研究[7-8]。文中通過提出一種基于改進PBFT 的在線旅游點評服務模型，利用區(qū)塊鏈技術(shù)分布式存儲、去中心化、數(shù)據(jù)不可篡改等特性實現(xiàn)游客點評、查詢商家信息等服務，從而提升游客旅游體驗感、消除游客與商家的信任裂縫。同時針對模型的應用場景，提出了FPBFT(Fast Practical Byzantine Fault Tolerance)算法共識機制。

1 區(qū)塊鏈技術(shù)

1.1 區(qū)塊鏈概述

區(qū)塊鏈最早見于比特幣(Bitcoin)的底層技術(shù)，由化名為中本聰(Satoshi Nakamoto)的一位學者在2008年發(fā)表的一篇名為《Bitcoin:A peer-to-peer electronic cash system》[9]即《比特幣：一種點對點的電子現(xiàn)金系統(tǒng)》的文章中提出。

Hyperledger Fabric[10]是由IBM 貢獻的面向企業(yè)的分布式賬本平臺，支持用Java、Go 等通用編程語言編寫智能合約，系統(tǒng)的運行不依賴于加密貨幣。Fabric 采用高度模塊化的設(shè)計，提供成員身份管理(MSP)服務、可拔插的共識協(xié)議以及背書策略等，是首個面向聯(lián)盟鏈場景的開源項目。

1.2 智能合約

區(qū)塊鏈的核心構(gòu)成要素——智能合約[11]由密碼學家Szabo 于1995 年提出，其通過指令的方式運行于計算機上。將智能合約部署在區(qū)塊鏈節(jié)點上，一旦滿足觸發(fā)合約條件，程序就自動執(zhí)行合約內(nèi)容，從而使得區(qū)塊鏈具有可編程的特性。智能合約在Fabric 中被稱為鏈碼(Chaincode)，使用Docker（容器）作為鏈碼的執(zhí)行環(huán)境[12]。Fabric 中的鏈碼包括用戶鏈碼和系統(tǒng)鏈碼，系統(tǒng)鏈碼用來實現(xiàn)系統(tǒng)層面的功能，實現(xiàn)系統(tǒng)管理；用戶鏈碼主要處理業(yè)務邏輯，通過應用提交的交易信息對區(qū)塊鏈賬本完成讀、寫數(shù)據(jù)的操作。智能合約為建立基于區(qū)塊鏈技術(shù)的上層應用提供了接口，使得區(qū)塊鏈技術(shù)前景極為廣闊[13-15]。

1.3 PBFT算法

PBFT 是解決拜占庭將軍問題的經(jīng)典共識算法[16]，其在保證可用性和安全性的前提下最多能容忍的作惡或者故障節(jié)點為f=(n-1)/3 個(其中，n為系統(tǒng)內(nèi)的節(jié)點總個數(shù))。達成共識目的的協(xié)議包括一致性協(xié)議、視圖更換協(xié)議和檢查點協(xié)議。

PBFT 一致性協(xié)議主要定義了主節(jié)點和副本節(jié)點兩種節(jié)點。協(xié)議流程包括三個階段，分別是preprepare 階段、prepare 階段和commit 階段，協(xié)議流程保證了鏈上節(jié)點數(shù)據(jù)的一致性。具體一致性協(xié)議流程如圖1 所示，步驟如下：

圖1 PBFT一致性協(xié)議流程

1）pre-prepare 階段：主節(jié)點(primary)收到客戶端(client)的請求REQUEST，并生成pre-prepare 消息發(fā)送給其他副節(jié)點(backups)；

2）prepare 階段：副節(jié)點驗證收到來自主節(jié)點發(fā)送的pre-prepare 消息，并生成prepare 消息發(fā)送給除本身之外的節(jié)點；

3）commit 階段：主節(jié)點和副節(jié)點收到prepare 消息，并且消息個數(shù)大于等于2f+1 個時向除本身之外的節(jié)點廣播commit 消息。

在有n個節(jié)點的PBFT 網(wǎng)絡中，一致性協(xié)議過程pre-prepare 階段最大通信次數(shù)為n，prepare 階段和commit 階段的通信次數(shù)都為n2。隨著網(wǎng)絡中節(jié)點數(shù)目的增加，通信次數(shù)呈指數(shù)平方級增長，共識效率降低。因此，PBFT 算法存在著網(wǎng)絡開銷大從而影響共識效率的問題。

2 模型設(shè)計

2.1 模型架構(gòu)

模型以區(qū)塊鏈技術(shù)為支撐，設(shè)計Web 界面，方便用戶操作使用。模型架構(gòu)設(shè)計如圖2 所示，Web 服務端包括用戶層和應用層，應用層提供信息傳輸接口以及各種信息查詢接口。用戶通過前端頁面操作Fabric-Go-SDK 提供的接口實現(xiàn)對Fabric 合約層中鏈碼對應函數(shù)的調(diào)用，將相關(guān)數(shù)據(jù)寫入數(shù)據(jù)層對應的賬本，同時用戶可以通過調(diào)用鏈碼讀取賬本數(shù)據(jù)。

圖2 模型架構(gòu)

為防止虛假評價問題的出現(xiàn)，平臺設(shè)定游客和商家兩種用戶角色，具體功能如圖3 所示。通過分析，平臺的用戶鏈碼實現(xiàn)的功能包括①游客角色的主要功能包括查詢店鋪信息和添加店鋪評價；②商家角色功能主要有店鋪入駐和修改店鋪信息功能。在Web 部分定義IsAdmin 標志來區(qū)別用戶角色。

圖3 平臺角色功能

2.2 智能合約設(shè)計

模型采用Go 語言編寫Chaincode，用戶鏈碼實現(xiàn)的主要功能包括寫入店鋪信息、評價信息和查詢店鋪信息等。根據(jù)Fabric 提供的管理鏈碼生命周期順序，在鏈碼部署成功后先實例化鏈碼，實例化用到系統(tǒng)的初始化Init 方法，然后通過Invoke、Query 官方接口函數(shù)調(diào)用鏈碼。

功能設(shè)計：

1）如果function=addSolder，首先根據(jù)定義的獲取店鋪信息函數(shù)GetSolderInfo 判斷店鋪信息是否已經(jīng)存在。若存在，則返回添加失?。环駝t調(diào)用ChaincodeStubInterface 接口的Putstate 方法，該方法負責接收并存儲前端傳遞過來的新店鋪信息到Fabric 賬本。

2）如果function=querySolderByNameAndAddress，此方法采用富查詢的方式，根據(jù)前端傳遞過來的店鋪名和店鋪地址兩個參數(shù)，調(diào)用自定義的getSolderByQueryString 函數(shù)獲取所有滿足條件的店鋪信息數(shù)據(jù)。

3）如果function=querySolderInfoByStoreId，根據(jù)前端傳遞過來的店鋪ID 判斷店鋪信息是否存在。若存在，則獲取指定key 鍵對應的全部信息，包括存儲在Historys 字段的歷史記錄；否則返回空值。

4）如果function=updateEvaluation，首先根據(jù)前端輸入的參數(shù)調(diào)用GetSolderInfo 判斷店鋪信息是否存在。若存在，將評價內(nèi)容增加到該店鋪的評價字段；否則添加失敗。

模型對于商家修改店鋪信息功能進行限制，由于店鋪編號、注冊日期、資質(zhì)和評價這些字段代表該店鋪的真實性，屬于不可更改值字段。商家具有修改店鋪姓名和地址的權(quán)限，歷史信息留存于Historys字段以供查詢。系統(tǒng)采用CouchDB 作為世界狀態(tài)存儲數(shù)據(jù)庫與區(qū)塊鏈中賬本做數(shù)據(jù)映射，以店鋪名和店鋪地址屬性為參數(shù)查詢，獲取歷史修改信息的數(shù)據(jù)，實現(xiàn)富查詢。

查詢數(shù)據(jù)合約首先判斷輸入的參數(shù)是否為店鋪名、店鋪地址；若參數(shù)正確，則使用getQueryResult方法執(zhí)行rich 查詢，將所有相關(guān)信息賦值給迭代器ri；然后將ri中的值通過循環(huán)的方式存入r，最后返回給Si。

2.3 F-PBFT算法

PBFT 是基于聯(lián)盟鏈的經(jīng)典共識算法，PBFT 算法的提出解決了拜占庭將軍問題。由于PBFT 每個節(jié)點都需要與其他節(jié)點進行共識同步，通信開銷大，隨著節(jié)點數(shù)量增加，其性能下降也很快?；赑BFT算法優(yōu)化一致性協(xié)議，提出F-PBFT(Fast Practical Byzantine Fault Tolerance)算法。F-PBFT 的一致性協(xié)議刪除pre-prepare 階段，減少節(jié)點間的通信次數(shù)從而提高算法的共識效率，算法整體流程如圖4 所示。

圖4 F-PBFT一致性協(xié)議流程

具體步驟如下：

1）選取主節(jié)點，負責接收到來自客戶端的請求消息。

2）f-prepare 階段：主節(jié)點接收客戶端的交易請求，判斷消息是否超出限制并生成序列號。主節(jié)點向所有副節(jié)點廣播f-prepare 消息。

3）f-commit 階段：所有節(jié)點對收到的f-prepare消息進行驗證，通過驗證就向客戶端發(fā)送確認消息。

4）主節(jié)點和副節(jié)點各自對收到的f-commit 消息進行驗證，若有2f+1 個正確消息，則給client 回復reply 消息，完成共識。

3 模型實現(xiàn)

基于區(qū)塊鏈的在線旅游點評服務模型基于Hyperledger Fabric 框架開發(fā)，由Web 前端和區(qū)塊鏈端組成。平臺提供了一個可視化的、操作簡便的系統(tǒng)界面，在命令行終端輸入make 命令啟動平臺，通過http://localhost:9001 訪問平臺。

平臺運行于Ubuntu 20.04.4 操作系統(tǒng)，配置如下：內(nèi)存為8 GB，處理器為四核，硬盤為1 TB，采用Hyperledger Fabric 1.4.4 版本，使用html+go+css 組合實現(xiàn)網(wǎng)頁開發(fā)，通過Fabric-Go-SDK 與區(qū)塊鏈端實現(xiàn)交互，鏈碼運行在Docker 容器內(nèi)。

3.1 環(huán)境部署

在Fabric 網(wǎng)絡環(huán)境中，系統(tǒng)采用單機多節(jié)點的部署方式，配置文件中設(shè)定了Org1 組織，組織下有peer0 和peer1 兩個節(jié)點。使用cryptogen 二進制文件生成的證書文件存放在本地文件夾crypto-config 中，使用configtxgen 二進制文件生成的初始區(qū)塊文件genesis.block、鏈碼通道文件channel.tx 以及錨節(jié)點配置更新交易文件Org1MSPanchors.tx 存放在本地文件夾artifacts 中。

系統(tǒng)的基本準備工作完成后首先初始化Fabric SDK，然后創(chuàng)建通道并將指定的Peers 加入通道，接著安裝用戶鏈碼并完成實例化，最后添加實例測試上述用戶鏈碼的業(yè)務邏輯。

3.2 功能實現(xiàn)

基于區(qū)塊鏈的在線旅游點評服務模型的前端界面主要包括查詢、信息錄入和信息展示。環(huán)境部署成功后，在瀏覽器輸入指定網(wǎng)址即可訪問平臺，Web服務指定監(jiān)聽端口號為9001。以店鋪信息查詢?yōu)槔?，游客在客戶端發(fā)起查詢請求，客戶端根據(jù)接收到的查詢請求調(diào)用Fabric 鏈碼實現(xiàn)數(shù)據(jù)查詢。

管理員登錄平臺后，通過點擊查詢店鋪信息和商家入駐來查看平臺店鋪的相關(guān)信息以及執(zhí)行注冊新商家功能。用戶查詢店鋪信息有兩種方式：根據(jù)店鋪名與店鋪地址查詢店鋪信息、根據(jù)店鋪ID 查詢店鋪信息。Web 端執(zhí)行查詢操作，區(qū)塊鏈端收到并輸出鏈碼事件，通過接口將數(shù)據(jù)返回給Web 端。

4 性能實驗分析

從吞吐量和時延兩個方面對F-PBFT 算法進行仿真和分析，與PBFT 算法做對比實驗以驗證FPBFT 算法的有效性。每次實驗進行六次并取平均值來保證實驗的一般性。

時延即交易發(fā)起到交易結(jié)束的響應時間。吞吐量(Transaction Per Second,TPS)是衡量共識算法性能的一個重要指標，即單位時間內(nèi)區(qū)塊鏈可以處理的交易數(shù)量，一般用TPS 來表示。

在共識時延測試實驗中，選取四個共識節(jié)點，相同時間內(nèi)進行200～1 000 條交易量的對比實驗，實驗結(jié)果如圖5 所示。圖5 中，F(xiàn)-PBFT 算法的共識時延明顯低于PBFT 算法，改進的PBFT 算法共識時延在交易量為300 條時降低了16%，隨著交易數(shù)量的增多，F(xiàn)-PBFT 算法的時延一直低于PBFT 算法。

圖5 不同交易量對應共識時延對比

在TPS 測試實驗中，選取四個共識節(jié)點，相同時間內(nèi)進行1 200～3 000 條交易量的對比實驗，實驗結(jié)果如圖6 所示。F-PBFT 算法執(zhí)行優(yōu)化一致性協(xié)議，其TPS 明顯優(yōu)于PBFT 算法，交易量提升比最高達到了10%。當交易量增加到2 500 條左右時，TPS 呈下降趨勢，但從整體上來看，F(xiàn)-PBFT 算法的TPS 仍然優(yōu)于PBFT 算法。

圖6 不同交易量對應TPS對比

5 結(jié)束語

文中首先分析了傳統(tǒng)在線旅游平臺點評業(yè)務存在的問題，利用區(qū)塊鏈技術(shù)和智能合約，將商家信息上鏈，設(shè)計基于區(qū)塊鏈的在線旅游點評服務模型。解決了旅游點評業(yè)務中虛假宣傳、惡意刷評等信息不對稱問題，保證游客獲取到信息的真實性；其次，針對PBFT 算法因通信量增大而導致共識效率變低的問題，提出F-PBFT 算法。相比于PBFT 算法，F(xiàn)PBFT 在共識時延和TPS 兩個性能指標方面均有較好提升，平均共識時延降低了6%，平均吞吐量提升了5%。

旅游業(yè)是綜合性產(chǎn)業(yè)，具有產(chǎn)業(yè)關(guān)聯(lián)度高、產(chǎn)業(yè)鏈條長、產(chǎn)業(yè)要素多、交易的中間環(huán)節(jié)多等特點，模型目前實現(xiàn)的功能比較單一，尚未實現(xiàn)其他必須功能，后續(xù)將利用區(qū)塊鏈智能合約實現(xiàn)訂購功能，為游客提供更多個性化服務，例如積分服務、景點推薦、旅游保險等，完善系統(tǒng)功能；同時，在未來的工作中，有望在F-PBFT 算法中節(jié)點引入積分制增加節(jié)點的誠實性，實現(xiàn)對算法的進一步優(yōu)化。