基于Fabric和IPFS文件共享系統(tǒng)設(shè)計與實(shí)現(xiàn)

楊武文，馬玉鵬，王 軼*，趙 凡，王保全

(1.中國科學(xué)院 新疆理化技術(shù)研究所，新疆 烏魯木齊 830011；2.中國科學(xué)院大學(xué)，北京 100049；3.新疆理化技術(shù)研究所 新疆民族語音語言信息處理實(shí)驗(yàn)室，新疆 烏魯木齊 830011)

0 引 言

隨著信息技術(shù)的普及應(yīng)用，電子文件在人們生產(chǎn)生活中必不可少。協(xié)同工作、遠(yuǎn)程辦公、知識傳播等眾多場景都對文件的網(wǎng)絡(luò)存儲和共享提出了強(qiáng)烈需求，各類網(wǎng)盤類文件共享產(chǎn)品隨之產(chǎn)生并成為人們?nèi)粘Ｉ顚W(xué)習(xí)工作中的重要工具。

傳統(tǒng)的網(wǎng)絡(luò)文件存儲與共享系統(tǒng)大多采用中心化服務(wù)方式，由第三方平臺提供文件存儲與共享服務(wù)。雖然已有較多成熟的產(chǎn)品并被廣泛使用，但在數(shù)據(jù)安全方面仍存在一些問題。一方面，將個人數(shù)據(jù)交予第三方機(jī)構(gòu)集中式存儲，面臨數(shù)據(jù)泄露和被濫用的風(fēng)險。另一方面，文件資源在共享過程中不易受控，即使通過日志等方式記錄共享過程，仍存在中心節(jié)點(diǎn)作惡或日志被篡改的風(fēng)險，導(dǎo)致一些敏感的資源只能在專網(wǎng)或局域網(wǎng)內(nèi)傳輸共享，應(yīng)用場景受限。另有部分依托于點(diǎn)對點(diǎn)(Peer-to-Peer，P2P)去中心化網(wǎng)絡(luò)的文件共享方式，在數(shù)據(jù)安全性方面并無改善，且存在穩(wěn)定性差、難以保證持久化存儲等問題，無法大規(guī)模應(yīng)用。

1 相關(guān)工作

區(qū)塊鏈技術(shù)有著不可篡改、可追溯、去中心化[1]等特點(diǎn)，已經(jīng)在金融[2]、供應(yīng)鏈[3-5]、多媒體[6-7]、醫(yī)療[8-9]等領(lǐng)域得到了廣泛的應(yīng)用。利用區(qū)塊鏈的特性，將區(qū)塊鏈技術(shù)應(yīng)用到文件共享系統(tǒng)中，可以有效改善傳統(tǒng)文件共享系統(tǒng)中所面臨的一系列問題：區(qū)塊鏈的防篡改與可追溯為文件共享記錄追溯提供了可信保障，去中心化可以有效防止中心節(jié)點(diǎn)故障。但區(qū)塊鏈面對海量數(shù)據(jù)存在存儲瓶頸，多節(jié)點(diǎn)同步的共享賬本將極大地消耗存儲資源。針對這一問題，采用鏈上鏈下混合的存儲架構(gòu)逐漸成為主流解決方案。

在區(qū)塊鏈存儲擴(kuò)展方面，Ali M[10]提出了一種將云存儲和區(qū)塊鏈相結(jié)合的方法解決區(qū)塊鏈存儲問題，將數(shù)據(jù)主體儲到云端，數(shù)據(jù)的索引存儲在區(qū)塊鏈，但云端存儲仍存在著信任問題。Saqib Ali等人[11]為Ping ER(Ping End-to-end Reporting)項目設(shè)計了一個分布式存儲架構(gòu)，架構(gòu)使用分布式哈希表(Distribute Hash Table，DHT)拓展聯(lián)盟鏈的存儲，增加了該項目的可持續(xù)性。而隨著IPFS[12]的興起，與區(qū)塊鏈技術(shù)相結(jié)合已逐步成為拓展區(qū)塊鏈存儲的重要技術(shù)手段[13]。Rafi等人[14]利用區(qū)塊鏈和IPFS來存儲物聯(lián)網(wǎng)(IoT)設(shè)備產(chǎn)生的數(shù)據(jù)，解決了IoT設(shè)備數(shù)量巨大時數(shù)據(jù)安全性存儲的問題，但其仍選取采用工作量證明(Proof Of Work，POW)作為共識機(jī)制，會造成資源的浪費(fèi)。

在基于區(qū)塊鏈技術(shù)的文件存儲共享應(yīng)用方面，也有研究人員做了大量工作。Muqaddas等人[15]提出了一種基于區(qū)塊鏈的數(shù)字資產(chǎn)安全數(shù)據(jù)共享與交付框架，利用激勵機(jī)制促進(jìn)資源擁有者為客戶提供有質(zhì)量的數(shù)據(jù)，但框架基于以太坊進(jìn)行構(gòu)建，存在使用代價高昂的缺點(diǎn)。譚海波等人[16]針對檔案數(shù)據(jù)管理中存在的問題，提出了一種基于聯(lián)盟鏈和公有鏈的檔案數(shù)據(jù)保護(hù)方法，實(shí)現(xiàn)了檔案館聯(lián)盟的數(shù)字檔案的保護(hù)、驗(yàn)證、恢復(fù)與共享，聯(lián)盟鏈和以太坊結(jié)合，一定程度上減少了系統(tǒng)使用的代價。Khatal[17]提出了一種基于區(qū)塊鏈文件共享框架，實(shí)現(xiàn)了數(shù)據(jù)安全共享和版權(quán)保護(hù)，但其為了實(shí)現(xiàn)版權(quán)保護(hù)，限制了用戶只能用其DApp才能創(chuàng)建和使用文件數(shù)據(jù)，用戶不能通過該App存儲分享自己現(xiàn)有的文件和下載文件到本地系統(tǒng)使用。他們大多基于以太坊公鏈進(jìn)行實(shí)現(xiàn)，使用代價較為高昂，或文件被限制不能脫離平臺使用。

該文設(shè)計并實(shí)現(xiàn)了一個基于Fabric的文件存儲共享系統(tǒng)，有如下特點(diǎn)：

(1)把區(qū)塊鏈與IPFS結(jié)合，拓展了區(qū)塊鏈的存儲；結(jié)合IPFS的內(nèi)容尋址特性和加密技術(shù)，實(shí)現(xiàn)了文件的防篡改、去冗余持久化存儲。

(2)基于屬性的控制策略方便用戶對文件的操作；權(quán)限上鏈和基于細(xì)粒度的權(quán)限控制，實(shí)現(xiàn)了文件的受控共享。

(3)系統(tǒng)實(shí)現(xiàn)了對操作歷史信息和文件歷史版本的溯源。對相同文件用同一密鑰加密處理，在提高文件在IPFS中的隱私安全的同時，又不產(chǎn)生額外的存儲空間浪費(fèi)。

2 相關(guān)技術(shù)

2.1 超級賬本

超級賬本(Hyperledger)[18]是由Linux基金會創(chuàng)建和管理的一個開源項目。Hyperledger Fabric是一個開源企業(yè)級許可的分布式賬本框架，用于開發(fā)解決方案和應(yīng)用程序，其模塊化和多功能設(shè)計可滿足廣泛的行業(yè)用例。Hyperledger Fabric具有良好的性能、可伸縮性和信任水平。Fabric可支持多種鍵值數(shù)據(jù)庫，如levelDB和CouchDB[19]等，該系統(tǒng)選擇使用CouchDB作為狀態(tài)數(shù)據(jù)庫，以提供豐富的查詢功能。

2.2 鏈 碼

Fabric中智能合約[20]稱為鏈碼(chaincode)，鏈碼用來控制區(qū)塊鏈網(wǎng)絡(luò)中的不同實(shí)體或相關(guān)方如何相互交互或交易的業(yè)務(wù)邏輯。鏈碼是獨(dú)立可運(yùn)行的應(yīng)用程序，運(yùn)行在基于Docker[21]的安全容器中。鏈碼支持多種語言進(jìn)行編寫，如Go、Java、NodeJS等。

2.3 IPFS

IPFS集合BitTorrent、DHT、Git、自驗(yàn)證文件系統(tǒng)(Self-Certifying File System，SFS)和密碼學(xué)等已有技術(shù)，提供了一種更加便宜、安全、可快速集成的存儲解決方案。IPFS采用為數(shù)據(jù)塊內(nèi)容建立哈希去重的方式存儲數(shù)據(jù)，相同內(nèi)容的數(shù)據(jù)塊具有同樣的哈希，數(shù)據(jù)的存儲成本將會顯著下降。IPFS分為公有集群和私有集群，具有相同的swarm.key才能加入同一個私有集群里。通過IPFS集群，IPFS以可持續(xù)的速率固定數(shù)據(jù)，并在出現(xiàn)故障時重試固定，保證數(shù)據(jù)持久化存儲。

3 系統(tǒng)設(shè)計

3.1 系統(tǒng)架構(gòu)

如圖1所示，所設(shè)計的文件共享系統(tǒng)包括四部分：客戶端、系統(tǒng)服務(wù)、Fabric聯(lián)盟鏈和IPFS私有集群。

圖1 系統(tǒng)架構(gòu)

客戶端通過良好的界面交互直接給用戶提供服務(wù)，通過系統(tǒng)服務(wù)提供的RESTful接口進(jìn)行訪問；系統(tǒng)服務(wù)是一種去中心化應(yīng)用(DApp)，通過調(diào)用Fabric- SDK和IPFS API，分別與Fabric系統(tǒng)和IPFS集群進(jìn)行交互配合，實(shí)現(xiàn)用戶管理、權(quán)限控制、文件操作和信息溯源等系統(tǒng)功能；Fabric存儲用戶、部分文件和控制策略等信息，提供鏈上數(shù)據(jù)信息的查詢、更新以及驗(yàn)證等功能；IPFS私有集群則用來存儲文件原始數(shù)據(jù)，保證持久化存儲，提供穩(wěn)定的數(shù)據(jù)支持。

3.2 鏈碼架構(gòu)

系統(tǒng)主要鏈碼包括文件管理鏈碼(File Manage Chaincode，F(xiàn)MC)、文件授權(quán)鏈碼(File Authority Chaincode，F(xiàn)AC)、身份管理鏈碼(Identity Manage Chaincode，IMC)等，如圖2所示。

圖2 鏈碼架構(gòu)

FMC用于實(shí)現(xiàn)文件的保護(hù)、驗(yàn)證、溯源、下載等業(yè)務(wù)邏輯，包括文件信息存儲鏈碼(File Information Storage Chaincode，F(xiàn)ISC)、文件密鑰管理鏈碼(File Encryption Key Manage Chaincode，F(xiàn)EMC)、操作歷史鏈碼(Operation History Chaincode，OHC)。FISC鏈碼用于存儲文件的關(guān)鍵信息，包括文件名、摘要信息、類型、屬性、上傳者、版本等信息，執(zhí)行文件的上傳、下載、更新、共享等操作；FEMC鏈碼用來管理文件加密密鑰，保持與文件加密前后文件指紋的映射關(guān)系；OHC鏈碼用于記錄用戶的操作，記錄了操作目標(biāo)、操作用戶、目標(biāo)用戶、操作具體內(nèi)容等信息。

FAC用來實(shí)現(xiàn)對文件的細(xì)粒度控制，包括目錄管理鏈碼(Catalog Manage Chaincode，CMC)和用戶權(quán)限鏈碼(User Auth Chaincode，UAC)。CMC鏈碼對目錄樹進(jìn)行管理，包括對目錄的創(chuàng)建、修改和刪除等操作；UAC鏈碼控制用戶對目錄及其包含的文件操作權(quán)限。

IMC管理整個鏈中所有用戶的身份信息，包括其通行證書ID、用戶名等對應(yīng)的信息。

4 方法設(shè)計與實(shí)現(xiàn)

4.1 細(xì)粒度權(quán)限控制

文件共享系統(tǒng)既要能夠?qū)崿F(xiàn)文件受控共享，又要有良好的操作性，需要有合理的權(quán)限控制策略來保證。

4.1.1 基于屬性的文件訪問控制策略

根據(jù)文件所需共享范圍的差異，分別對文件賦予不同的屬性?；趯傩圆顒e，通過鏈碼進(jìn)行預(yù)處理規(guī)則控制，分別執(zhí)行不同的共享方式和權(quán)限訪問控制策略。

如圖3所示，根據(jù)業(yè)務(wù)需求，給文件賦予public、shared和private三類屬性?；赨AC鏈碼，以文件屬性作為輸入，屬性為public的文件由所有用戶任意訪問，屬性為shared的文件根據(jù)權(quán)限約束進(jìn)行更加細(xì)粒度的控制訪問，屬性為private的文件則只能由文件擁有者進(jìn)行操作，其他用戶不可見。

圖3 基于屬性訪問控制

4.1.2 基于合約的細(xì)粒度權(quán)限控制

針對需要共享的數(shù)據(jù)資源，執(zhí)行細(xì)粒度的權(quán)限控制與驗(yàn)證，如圖4所示。

圖4 細(xì)粒度權(quán)限控制示意圖

(1)規(guī)約系統(tǒng)的數(shù)據(jù)集和文件瀏覽、下載、刪除和共享等動作，將每項操作均內(nèi)化成一個權(quán)限點(diǎn)，UAC鏈碼為每一個權(quán)限點(diǎn)進(jìn)行編碼注冊。

(2)將權(quán)限點(diǎn)、作用域和用戶之間的關(guān)系用數(shù)據(jù)集上鏈存儲，基于CMC、IMC和UAC鏈碼進(jìn)行細(xì)粒度的控制約束。

(3)權(quán)限的驗(yàn)證以權(quán)限控制鏈碼為核心，以用戶操作動作為權(quán)限點(diǎn)進(jìn)行輸入，以用戶和權(quán)限點(diǎn)的關(guān)聯(lián)作為授權(quán)條件。

4.1.3 面向?qū)蛹壍臋?quán)限賦予與驗(yàn)證

為便于進(jìn)行批量文件資源的共享管理，以文件夾為對象，采用面向?qū)蛹壍淖饔糜驒?quán)限管理。

依托于文件夾的層級目錄結(jié)構(gòu)，將作用域的根目錄域用戶進(jìn)行權(quán)限綁定，下級目錄自動繼承相應(yīng)權(quán)限。若需要在整體作用域下對部分文件資源權(quán)限進(jìn)行調(diào)整，可以以子目錄方式，新建一個作用域，重新關(guān)聯(lián)用戶和相應(yīng)權(quán)限點(diǎn)，兄弟節(jié)點(diǎn)間權(quán)限互不影響。

進(jìn)行權(quán)限驗(yàn)證時，根據(jù)文件資源所在層級位置，進(jìn)行權(quán)限查詢與驗(yàn)證。驗(yàn)證流程如算法1所示。

算法1：面向?qū)蛹墮?quán)限驗(yàn)證算法。

輸入(nodeId,userId)

輸出(authCode)

authCode =getAuth(nodeId,userId);//查詢當(dāng)前節(jié)點(diǎn)用戶權(quán)限

if authCode exist then //如果權(quán)限存在

return authCode;//返回權(quán)限碼

else

while(authCode=null and nodeId.father != null)//進(jìn)入循環(huán)

nodeId = nodeId.father;//轉(zhuǎn)到父節(jié)點(diǎn)

authCode = getAuth(nodeId,userId); //查詢父節(jié)點(diǎn)權(quán)限

end while //退出循環(huán)

return authCode;//返回查詢到的權(quán)限點(diǎn)

end if

用戶在子目錄權(quán)限驗(yàn)證時，若未查詢到當(dāng)前目錄用戶對應(yīng)權(quán)限點(diǎn)，則向上遞歸查詢驗(yàn)證，直到達(dá)到邊界條件。

4.2 存儲策略

4.2.1 基于IPFS的鏈下存儲擴(kuò)展

區(qū)塊鏈由于全節(jié)點(diǎn)備份和只可追加的特性，本身面臨較大的存儲壓力，文件本身并不適合寫入?yún)^(qū)塊。為了對區(qū)塊鏈的存儲進(jìn)行擴(kuò)展，把文件內(nèi)容本身存入鏈下IPFS，將文件的摘要信息和IPFS返回的指紋寫入?yún)^(qū)塊作為鏈上存儲。鏈上文件存儲結(jié)構(gòu)定義如下：

fileStore={file_id,cid,name,ipfs_hash,size,abstract,version,time,user}

其中，file_id是用戶在當(dāng)前目錄下首次創(chuàng)建時生成的唯一識別碼(Universally Unique Identifier，UUID)，作為文件唯一識別id，也作為查詢鍵值；cid是文件當(dāng)前所屬文件夾id；name，ipfs_hash，size，abstract，version，time，user分別對應(yīng)文件名，文件IPFS哈希，大小，摘要信息，版本號，上傳時間，文件擁有者。

4.2.2 基于內(nèi)容尋址的去冗余存儲和版本追溯

IPFS依據(jù)內(nèi)容尋址，存儲時將文件數(shù)據(jù)劃分為256K的多個塊，根據(jù)塊內(nèi)容計算hash，組合后再次哈希計算構(gòu)造出整個文件的地址哈希。兩個相同內(nèi)容的文件只需要存儲一次，達(dá)到去冗余效果。若文件部分變動產(chǎn)生變化僅變動內(nèi)容所在塊的hash也會同步產(chǎn)生變化，此時文件同步會產(chǎn)生新的hash，如圖5所示。

圖5 IPFS文件更新示意圖

Fabric維護(hù)了一個歷史索引數(shù)據(jù)庫，可以快速實(shí)現(xiàn)對區(qū)塊鏈賬本歷史數(shù)據(jù)的查詢。系統(tǒng)調(diào)用GetHistoryForKey()接口可查詢鍵值對應(yīng)的歷史變化記錄。

結(jié)合Fabric和IPFS的特性，以文件的file_id為鍵值，在歷史數(shù)據(jù)庫中檢索ipfs_hash的變動記錄，以及相應(yīng)的文件修改信息，從IPFS中獲取歷史文件數(shù)據(jù)，實(shí)現(xiàn)了對文件歷史版本的追溯。

4.2.3 文件加密存儲

IPFS是一個內(nèi)容尋址的開放分布式動態(tài)共享網(wǎng)絡(luò)，在應(yīng)用與IPFS進(jìn)行交互時不可避免地需要進(jìn)行文件內(nèi)容hash的明文傳輸，處于集群中的任一節(jié)點(diǎn)在獲得文件hash的情況下均能下載文件，這導(dǎo)致一定的文件泄露風(fēng)險。

針對這一問題，該系統(tǒng)采用加密存儲的方式進(jìn)一步提升文件的安全性，實(shí)現(xiàn)對非法訪問的可見不可讀。其中針對IPFS內(nèi)容尋址特性，對相同內(nèi)容的文件采用同一密鑰進(jìn)行加密，使用FEMC鏈碼對密鑰進(jìn)行統(tǒng)一管理，避免了存儲冗余。

加密存儲流程為：

(1)計算文件hash，調(diào)用FEMC鏈碼判斷系統(tǒng)是否已經(jīng)存儲過相同文件；

(2)若存在，則調(diào)用FISC查詢該文件其相關(guān)信息，然后在當(dāng)前用戶目錄下創(chuàng)建該文件，上傳成功；

(3)若不存在，則需要加密后再進(jìn)行存儲，將新的密鑰及其對應(yīng)加密前后的hash信息交由FEMC進(jìn)行管理。關(guān)鍵代碼如下所示。

算法2：文件存儲加密算法。

輸入：(file, userId)

輸出 (status)

fileHash=SHA256(file);//計算文件hash

if fileExist(fileHash) then //如果文件存在

fileInfo = getFileInfo(fileHash)//獲取文件信息

status=createNewFile(fileInfo,fileHash,userId)；//在用戶目錄下創(chuàng)建文件

return status;//返回成功創(chuàng)建結(jié)果

else

key=randomKey();//產(chǎn)生隨機(jī)密鑰

encryptedFile= AESencrypt(file, key)//文件加密得到密文

ipfsHash=ipfs.add(encryptedFile);//上傳至IPFS

keyManage(fileHash,ipfsHash,key); //管理文件hash與密鑰

status=createNewFile(fileInfo, fileHash, user.id) //根據(jù)文件信息創(chuàng)建文件

return status;//返回創(chuàng)建成功狀態(tài)

end if

用戶下載文件時，系統(tǒng)只會給授權(quán)的合法用戶進(jìn)行下載解密，整個過程用戶本身不能拿到密鑰。非法用戶在使用泄露的IPFS hash下載文件后，并不能解密使用，從而實(shí)現(xiàn)了文件的隱私安全保護(hù)。

5 系統(tǒng)測試與分析

系統(tǒng)實(shí)現(xiàn)使用Fabric-2.2.0作為區(qū)塊鏈框架，鏈碼開發(fā)使用Go語言進(jìn)行編寫；IPFS則使用go-ipfs v0.8.0客戶端進(jìn)行本地私有集群模式的搭建；客戶端主要通過angular 8框架、Ant Design框架進(jìn)行構(gòu)建；系統(tǒng)服務(wù)使用了SpringBoot框架，通過Fabric-SDK-Java調(diào)用Fabric鏈碼，通過java-ipfs-api實(shí)現(xiàn)了與IPFS的接口調(diào)用。在文件加解密部分，為了提高處理速率，采用了加解密速度較快的AES對稱加密算法。

核心功能實(shí)現(xiàn)了用戶管理、權(quán)限編輯、文件操作和信息溯源等功能。用戶管理主要包括用戶注冊、用戶信息編輯等功能；權(quán)限編輯包括了權(quán)限的賦予、編輯和申請驗(yàn)證等功能；文件操作包括了文件的上傳、共享、下載、更新和檢索等常用功能；信息溯源包括了對文件歷史信息等溯源，以及用戶的操作記錄和共享記錄等。

5.1 系統(tǒng)性能測試

實(shí)驗(yàn)設(shè)備為1臺筆記本電腦，配置為16 GB內(nèi)存，Intel Corei5處理器，兩臺服務(wù)器搭載了CentOS 7.9系統(tǒng)，16 GB內(nèi)存，E5620處理器。使用Fabric自帶的etcdRaft共識協(xié)議，共兩個組織，每個組織一個證書頒發(fā)機(jī)構(gòu)(Certificate Authority，CA)，兩個peer節(jié)點(diǎn)，一個排序節(jié)點(diǎn)。其中Fabric初始參數(shù)配置為：BatchTimeout:2 s，MaxMessageCount:500，Absolute MaxBytes:10 MB，PreferredMaxBytes:2 MB。

系統(tǒng)中對文件的操作以上傳下載的時間開銷最大，主要包含文件到IPFS網(wǎng)絡(luò)的上傳下載，文件本身的加解密和相關(guān)信息的上鏈存儲三個過程。為了探究各個階段處理性能，以四組不同尺寸大小的文件做上傳下載測試。文件平均尺寸分別為0.5 M，4 M，10 M和80 M，每組50個測試樣例。測試結(jié)果取平均值，實(shí)驗(yàn)數(shù)據(jù)如表1所示。

表1 系統(tǒng)性能測試結(jié)果(BatchTimeout=2)

由表1測試結(jié)果可以看出，系統(tǒng)總耗時，IPFS耗時和加解密耗時均隨著文件尺寸增大而增大，其中加解密過程所占耗時對于整個文件上傳下載處理速度影響幾乎可以忽略不計。區(qū)塊鏈系統(tǒng)交易耗時相對穩(wěn)定，且上傳交易耗時是下載交易的兩倍，這是由于上傳操作Fabric系統(tǒng)需要處理兩筆數(shù)據(jù)寫入交易：一筆是創(chuàng)建文件信息，另一筆是文件密鑰的管理。而下載操作，只是調(diào)用了查詢交易，沒有賬本數(shù)據(jù)的寫入操作。

表2 系統(tǒng)性能測試結(jié)果(BatchTimeout=0.2)

可以注意到，在文件尺寸較小時，相關(guān)信息的上鏈交易是主要的性能瓶頸。分析其原因，主要在于Fabric出塊速度受四個參數(shù)共同影響，需滿足任意一個參數(shù)才能完成區(qū)塊的上鏈寫入。在本實(shí)驗(yàn)中由于測試輸入并發(fā)不夠，上鏈信息并不滿足其他參數(shù)條件，只能等待時間達(dá)到BatchTimeout設(shè)定的時間條件才能觸發(fā)數(shù)據(jù)打包，出塊完成交易。針對這一問題，調(diào)整Fabric出塊配置參數(shù)，將BatchTimeout時間設(shè)為0.2 s，其他參數(shù)保持不變，驗(yàn)證交易耗時的提升。實(shí)驗(yàn)結(jié)果如表2所示。

可以看出，調(diào)整后系統(tǒng)信息上鏈耗時有了明顯的降低，在應(yīng)用中可以根據(jù)實(shí)際的并發(fā)壓力，調(diào)整Fabric的網(wǎng)絡(luò)參數(shù)以提升系統(tǒng)性能。綜合而言，系統(tǒng)的整體性能可以接受，能夠滿足用戶的實(shí)際使用需求。

5.2 安全性分析

該系統(tǒng)采用的許可型區(qū)塊鏈Fabric，結(jié)合IPFS實(shí)現(xiàn)文件資源的安全存儲與共享。系統(tǒng)安全性從以下三個方面來保證：

Fabric安全性：利用Fabric認(rèn)證機(jī)制保護(hù)，只有經(jīng)過系統(tǒng)認(rèn)證的合法用戶才能進(jìn)入?yún)^(qū)塊鏈進(jìn)行操作。區(qū)塊鏈節(jié)點(diǎn)間通信可以通過TLS來保證傳輸層的安全。Fabric系統(tǒng)會區(qū)分參與的節(jié)點(diǎn)和應(yīng)用程序角色，為訪問資源的操作設(shè)置嚴(yán)格的權(quán)限控制。

IPFS安全性：IPFS對數(shù)據(jù)進(jìn)行分布式存儲，通過集群可把整個系統(tǒng)存儲統(tǒng)一調(diào)度，能夠?qū)崿F(xiàn)資源自動修復(fù)和去冗余，自帶容災(zāi)備份功能。通過swarm.key組成私有集群，可以與外部數(shù)據(jù)有效隔離，保證數(shù)據(jù)僅在IPFS私有集群中流轉(zhuǎn)。IPFS存儲文件時將文件分割成數(shù)據(jù)塊存儲，并通過計算數(shù)據(jù)塊的哈希值來進(jìn)行唯一標(biāo)識該文件，只有通過文件的CID才能從IPFS網(wǎng)絡(luò)中獲取到該文件。

文件流轉(zhuǎn)安全：細(xì)粒度權(quán)限控制鏈碼，可以有效控制文件的合法流轉(zhuǎn)。隨機(jī)生成密鑰對文件進(jìn)行加密，密鑰與文件本身分別存儲在區(qū)塊鏈系統(tǒng)和IPFS中，在整個文件的流轉(zhuǎn)過程中，密鑰由系統(tǒng)進(jìn)行管理，其他任何人無權(quán)單獨(dú)取出密鑰，即使非法用戶通過IPFS集群中節(jié)點(diǎn)獲取到了加密文件，也無法獲取文件解密對應(yīng)的密鑰，從而保證了文件的流轉(zhuǎn)安全。

通過模擬權(quán)限受限用戶，解析客戶端與服務(wù)端通信的數(shù)據(jù)，可以獲得當(dāng)前用戶可見但無權(quán)操作的列表文件對應(yīng)的CID。對獲取到的CID進(jìn)行下載驗(yàn)證，通過文件CID可從IPFS集群中的節(jié)點(diǎn)獲取到文件，但由于無法獲取到對應(yīng)的文件密鑰，無法對獲取到的文件進(jìn)行解密。因此系統(tǒng)安全性得到保障。

5.3 存儲空間分析

分別用區(qū)塊鏈、區(qū)塊鏈+IPFS的方式存儲文件，對比兩種方式的單個區(qū)塊平均大小和系統(tǒng)整體存儲消耗。測試樣例為四組不同大小的文件，文件平均尺寸分別為0.5 M，1 M，2 M，4 M，每組50個測試樣例進(jìn)行存儲測試，測試結(jié)果如圖6所示。

圖6(a)所示為區(qū)塊存儲文件和區(qū)塊存儲文件CID兩種方案的單個區(qū)塊大小，由于存儲CID時區(qū)塊平均大小僅為60 KB，在圖中所占比例太小幾乎不可見。而采用區(qū)塊存儲文件時，區(qū)塊的平均大小約為所存文件的4.8倍。在存儲超過10 M的文件測試時，會導(dǎo)致區(qū)塊鏈系統(tǒng)崩潰，這是由于存儲文件時是作為單筆區(qū)塊交易進(jìn)行，單筆交易數(shù)據(jù)過大導(dǎo)致系統(tǒng)產(chǎn)生錯誤，所以Fabric中單筆交易數(shù)據(jù)不能過大。

圖6 存儲性能測試

使用區(qū)塊存儲文件時會導(dǎo)致區(qū)塊大小尺寸五倍增大，對區(qū)塊數(shù)據(jù)進(jìn)行了多次測試和解析。區(qū)塊在存儲數(shù)據(jù)時，F(xiàn)abric為了安全性進(jìn)行數(shù)據(jù)處理，導(dǎo)致寫入?yún)^(qū)塊數(shù)據(jù)增大。如利用鏈碼存儲數(shù)據(jù)，解析對應(yīng)交易區(qū)塊時數(shù)據(jù)存儲為{"key":"Demon", "value":"eyJmaWxlIjoiRGVtb24i LCJmaWxlX2NvbnRlbnQiOiJnb29kIn0=" }，從而導(dǎo)致數(shù)據(jù)增大。而當(dāng)中value數(shù)據(jù)大小為0.5 M時，解析出value對應(yīng)的數(shù)據(jù)大小為2.3 M。

圖6(b)展示的為不同節(jié)點(diǎn)數(shù)量存儲相同文件時的系統(tǒng)整體存儲空間消耗，其中IPFS的備份數(shù)量設(shè)定為3。采用區(qū)塊鏈賬本存儲文件導(dǎo)致整個系統(tǒng)的存儲空間消耗極具增大，且隨著節(jié)點(diǎn)數(shù)量增加線性增長。

綜上所述，該系統(tǒng)所采用的方式具有極大的空間節(jié)省性能。

6 結(jié)束語

系統(tǒng)利用區(qū)塊鏈技術(shù)克服了傳統(tǒng)文件存儲共享系統(tǒng)存在的不易溯源和防篡改性差的問題；通過細(xì)粒度的權(quán)限控制實(shí)現(xiàn)了文件受控共享；文件采用先驗(yàn)證是否存在，然后確定是否加密存儲的方法，在提高隱私安全的同時，沒有帶來額外的空間浪費(fèi)。通過實(shí)驗(yàn)測試，系統(tǒng)的整體性能可以滿足日常生活需要。在未來工作中，將會探究對已存儲文件的內(nèi)容進(jìn)行分布式檢索等功能，探索新的功能和方法，進(jìn)一步完善系統(tǒng)。