基于改進PBFT 的在線旅游點評服務模型

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

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

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

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

1 區塊鏈技術

1.1 區塊鏈概述

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

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

1.2 智能合約

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

1.3 PBFT算法

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

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

圖1 PBFT一致性協議流程

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

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

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

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

2 模型設計

2.1 模型架構

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

圖2 模型架構

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

圖3 平臺角色功能

2.2 智能合約設計

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

功能設計：

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

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

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

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

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

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

2.3 F-PBFT算法

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

圖4 F-PBFT一致性協議流程

具體步驟如下：

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

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

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

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

3 模型實現

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

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

3.1 環境部署

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

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

3.2 功能實現

基于區塊鏈的在線旅游點評服務模型的前端界面主要包括查詢、信息錄入和信息展示。環境部署成功后，在瀏覽器輸入指定網址即可訪問平臺，Web服務指定監聽端口號為9001。以店鋪信息查詢為例，游客在客戶端發起查詢請求，客戶端根據接收到的查詢請求調用Fabric 鏈碼實現數據查詢。

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

4 性能實驗分析

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

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

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

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

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

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

5 結束語

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

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