基于區(qū)塊鏈的電子文件流轉(zhuǎn)設(shè)計與實現(xiàn)

韓妍妍，張 齊，閆曉璇，劉培鶴，徐鵬格

（1.北京電子科技學(xué)院電子與通信工程系，北京 100070；2.西安電子科技大學(xué)通信工程學(xué)院，西安 710071）

（?通信作者電子郵箱zq_nulinuli@163.com）

0 引言

電子文件是指在機關(guān)、團體、企事業(yè)單位和其他組織在處理公務(wù)過程中，通過計算機等電子設(shè)備形成、辦理、傳輸和存儲的文字、圖表、音頻、視頻等不同形式的信息記錄［1］。電子文件直到20世紀80年代末開始應(yīng)用于政府機關(guān)及企業(yè)，并逐步取代傳統(tǒng)的紙質(zhì)文件，隨之產(chǎn)生了電子文件管理系統(tǒng)和電子文件流轉(zhuǎn)系統(tǒng)。隨著新時代網(wǎng)絡(luò)安全問題的突出，電子文件與各類信息安全緊密聯(lián)系，文件流轉(zhuǎn)直接關(guān)系到行政管理效率以及數(shù)字資產(chǎn)的流通安全，因此國內(nèi)外政府高度重視電子文件流轉(zhuǎn)系統(tǒng)創(chuàng)新，將其列為數(shù)字城市的重要內(nèi)容。而企業(yè)和學(xué)術(shù)界也積極響應(yīng)政府號召，研究和申請電子文件的相關(guān)專利［2-3］。

文件的可靠性和流轉(zhuǎn)過程的安全性［3］是巨大的短板，如電子文件流轉(zhuǎn)過程應(yīng)用節(jié)點多、程序覆蓋廣、數(shù)據(jù)傳輸量較大，純粹的中心化服務(wù)器架構(gòu)會產(chǎn)生巨大基礎(chǔ)設(shè)施建設(shè)成本和后臺維護成本，因此在大應(yīng)用量的前提下如何保證電子文件沒有遭到惡意篡改，且在不暴露內(nèi)容的情況下證明內(nèi)容完整可靠是一大難題；另一方面，傳統(tǒng)的電子文件流轉(zhuǎn)過程采用的是中心化模式，其應(yīng)用的前提是用戶基于信任原則選擇該應(yīng)用進行文件傳輸，但實際應(yīng)用中攻擊者可以利用應(yīng)用程序漏洞偽造身份進行非法訪問，抹除系統(tǒng)的訪問記錄，獲得文件閱讀權(quán)下載權(quán)，從而導(dǎo)致文件和秘密的泄露［4］；再者，在電子文件流轉(zhuǎn)過程中，傳統(tǒng)方式是采用數(shù)據(jù)庫對文件進行存放，面對如今大規(guī)模的文件傳輸量，需要有既滿足安全性又能擺脫傳統(tǒng)數(shù)據(jù)庫限制的文件中轉(zhuǎn)存放平臺。在電子文件的發(fā)展前景中，如何解決電子文件流轉(zhuǎn)過程中的可靠性和安全性，使文件內(nèi)容不被輕易竊取、篡改，文件流轉(zhuǎn)過程日志清晰、透明是電子文件應(yīng)用領(lǐng)域和電子文件流轉(zhuǎn)亟須解決的問題［5］。

對于以上電子公文流轉(zhuǎn)系統(tǒng)中存在的問題，去中心化是一個解決現(xiàn)有問題的有效選擇，近年來區(qū)塊鏈技術(shù)成為了學(xué)術(shù)界的研究熱點［6-7］，同時也在金融業(yè)、服務(wù)業(yè)、IT 界、政府管理等領(lǐng)域具有極高的應(yīng)用價值。本文利用區(qū)塊鏈技術(shù)的安全性、不可逆、防篡改、可追溯特性，借助云存儲［8-9］平臺進行電子文件存放，提出一種基于區(qū)塊鏈［10-11］的電子文件流轉(zhuǎn)系統(tǒng)，通過將文件所有權(quán)轉(zhuǎn)換數(shù)據(jù)加蓋時間戳，使流轉(zhuǎn)過程連續(xù)、關(guān)聯(lián)、可追溯且誠實可信，大幅提升電子文件流轉(zhuǎn)過程透明度和可信度，同時實現(xiàn)文件流轉(zhuǎn)溯源，實現(xiàn)防篡改日志功能［12］。

1 設(shè)計目標與系統(tǒng)架構(gòu)

系統(tǒng)由區(qū)塊鏈數(shù)據(jù)保護、云平臺文件存儲和節(jié)點管理監(jiān)控三大部分組成：區(qū)塊鏈用于實現(xiàn)區(qū)塊鏈數(shù)據(jù)記錄、溯源功能；云平臺文件存儲用于文件中轉(zhuǎn)和存放；節(jié)點管理監(jiān)控保證聯(lián)盟鏈中節(jié)點的添加和正常運轉(zhuǎn)。三部分進行協(xié)調(diào)工作，共同實現(xiàn)系統(tǒng)功能。

1.1 設(shè)計目標

1）文件流轉(zhuǎn)的安全性。電子文件在流轉(zhuǎn)過程中內(nèi)容容錯。此外，文件所有權(quán)只有經(jīng)用戶簽名及礦工驗證后才能更改。

2）系統(tǒng)可信性。系統(tǒng)應(yīng)具有抵御偽造區(qū)塊攻擊能力，從而保證區(qū)塊鏈所記錄數(shù)據(jù)的真實性。當(dāng)文件所有權(quán)存在爭議時可將賬本作為解決糾紛的依據(jù)。

3）系統(tǒng)擴展性。利用云平臺完成文件存儲，應(yīng)考慮到后續(xù)系統(tǒng)維護和拓展使用，通過擴充云平臺功能增加系統(tǒng)新功能和新需求，從而適應(yīng)更復(fù)雜的系統(tǒng)要求。

4）系統(tǒng)高效性。底層區(qū)塊鏈中數(shù)據(jù)的存儲需要通過認證節(jié)點確認交易并打包成區(qū)塊后才能完成［13］，此時存在數(shù)據(jù)效率低下問題，需要進行優(yōu)化解決。

1.2 技術(shù)架構(gòu)

本文電子文件流轉(zhuǎn)方案的技術(shù)架構(gòu)如圖1 所示，系統(tǒng)分為三部分：用戶、云端和授權(quán)節(jié)點。

客戶端 用戶在系統(tǒng)中通過用戶ID完成身份記錄并進行驗證，依據(jù)ID可獲取系統(tǒng)中唯一身份標識的公私鑰對，實現(xiàn)用戶的登錄操作。當(dāng)用戶連接客戶端后，用戶關(guān)于文件的上傳、下載和所有權(quán)交易均通過客戶端進行操作，交易如圖2所示。

用戶對文件進行交易時，首先在客戶端上進行文件的上傳，文件存儲在云端后即在底層區(qū)塊鏈獲得該文件的所有權(quán)記錄。用戶通過客戶端，在區(qū)塊鏈操作交易數(shù)據(jù)TX，區(qū)塊鏈網(wǎng)絡(luò)調(diào)用協(xié)議接口將交易數(shù)據(jù)發(fā)送到電子文件流轉(zhuǎn)區(qū)塊鏈網(wǎng)絡(luò)中，新區(qū)塊鏈NB 入鏈時交易即生效。用戶可以通過調(diào)用智能合約S 控制云端C，實現(xiàn)電子文件所有權(quán)的轉(zhuǎn)讓、權(quán)限賦予或查詢功能。

圖1 電子文件流轉(zhuǎn)示意圖Fig.1 Schematic diagram of electronic file circulation

圖2 客戶端用戶文件所有權(quán)交易流程Fig.2 Transaction process of client-side user file ownership

授權(quán)節(jié)點 即礦工，主要負責(zé)驗證和打包電子文件流轉(zhuǎn)交易。系統(tǒng)需預(yù)先指定一定數(shù)目的節(jié)點為記賬人，每個區(qū)塊的生成由需要授權(quán)節(jié)點經(jīng)共識機制進行認證方可鏈入，其他接入節(jié)點可以參與交易，但不過問記賬過程和區(qū)塊認證，當(dāng)需要進行交易數(shù)據(jù)查詢時，第三方可以對區(qū)塊鏈中交易信息限定查詢。當(dāng)系統(tǒng)中有用戶發(fā)起文件流轉(zhuǎn)交易時，授權(quán)節(jié)點將交易請求數(shù)據(jù)通過電子文件流轉(zhuǎn)區(qū)塊鏈共識機制，經(jīng)本地運算產(chǎn)生的新區(qū)塊，會廣播到每個節(jié)點，當(dāng)超過半數(shù)授權(quán)節(jié)點確認了該區(qū)塊的有效性后和合法性后，此次的交易才會被寫入?yún)^(qū)塊鏈存儲，通過記錄父塊哈希鏈接到區(qū)塊鏈上，如圖3 所示。該過程中智能合約是提前部署于區(qū)塊鏈上的自動執(zhí)行代碼，通過自動觸發(fā)執(zhí)行，可以滿足不受干預(yù)地進行電子文件的轉(zhuǎn)讓、權(quán)限賦予或查詢等操作，保障電子文件所有權(quán)的權(quán)威性。

圖3 電子文件區(qū)塊生成與鏈接Fig.3 Generation and link of electronic file blocks

云端 完成文件的存放與流轉(zhuǎn)，如圖4所示。

當(dāng)用戶A 在登錄客戶端后將文件上傳至云端時，用戶會同時將文件F的哈希值以及對文件哈希值的數(shù)字簽名發(fā)送至云端進行確認。上傳內(nèi)容①中包含的內(nèi)容為：

其中：Hash(F)為文件F 的哈希值，Sig(Hash(F))為該哈希值的數(shù)字簽名，GA為用戶A 的公鑰。云端先進行文件哈希值及用戶A 的簽名的驗證，通過驗證后向用戶A 返回文件所屬的唯一憑證以及對此關(guān)于云端的數(shù)字簽名。返回憑證②中包含的內(nèi)容為：

其中：I 為文件所屬憑證，GC為云端的公鑰。用戶A 以簽名驗證的方式對接收到的信息進行文件流轉(zhuǎn)操作。文件流轉(zhuǎn)操作首先進行但是文件所有權(quán)的轉(zhuǎn)移，隨著所有權(quán)的變化，憑證I也會同時發(fā)生變化，云端文件只有擁有憑證I 的人才能進行下載。在云端中進行文件的轉(zhuǎn)存一方面提高了文件流轉(zhuǎn)效率，同時能夠有效防止流轉(zhuǎn)過程中重要電子文件的隨意瀏覽。

圖4 云存儲文件所有權(quán)流轉(zhuǎn)過程Fig.4 Process of cloud storage file ownership transfer

1.3 智能合約設(shè)計與執(zhí)行

智能合約［14］在該方案中作為邏輯層，本文對智能合約的結(jié)構(gòu)及執(zhí)行流程進行了針對性設(shè)計，如圖5所示。

圖5 電子文件所有權(quán)流轉(zhuǎn)合約結(jié)構(gòu)Fig.5 Contract structure for circulation of ownership transfer of electronic files

文件流轉(zhuǎn)合約的索引部分主要由合約編號Num(S)、所在區(qū)塊鏈編號Num(block)及合約內(nèi)容的哈希值Hash(S)組成，有利于挖礦節(jié)點對交易信息中的關(guān)聯(lián)合約進行追蹤和執(zhí)行。

節(jié)點A向B進行文件F的流轉(zhuǎn)交易，并且此交易入鏈生效后，挖礦節(jié)點D追蹤到交易所屬的智能合約，并根據(jù)合約自動執(zhí)行以下步驟：

1）驗證交易所屬文件F 的標識與哈希值是否和合約中一致。

2）驗證交易發(fā)起方的公鑰是否是合約中的當(dāng)前用戶。

3）驗證交易信息中發(fā)起方的數(shù)字簽名。

4）驗證交易接收方是否屬于合約中的用戶集。

5）若以上步驟均通過驗證，則挖礦節(jié)點D 向云端C 發(fā)出文件所有權(quán)變更的指示。內(nèi)容如下：

云端C 在收到指示后，通過找到文件F 后核對哈希值，一致后再驗證節(jié)點D的數(shù)字簽名，通過即認為此指示有效。

通過調(diào)用部署在電子文件流轉(zhuǎn)區(qū)塊鏈上的智能合約，將自己的文件所有權(quán)轉(zhuǎn)移給接收者，寫入新的區(qū)塊并鏈接到區(qū)塊鏈上。由于區(qū)塊鏈本身具有不可篡改的特性，每一筆交易中都包含相應(yīng)的時間戳和文件的特征值，因此能防止文件被惡意篡改和刪除。

1.4 電子文件所有權(quán)交易流程

具體流程如下：

1）發(fā)起交易。電子文件流轉(zhuǎn)區(qū)塊鏈網(wǎng)絡(luò)中的客戶端發(fā)起的交易TX，主要結(jié)構(gòu)如圖6所示。

圖6 文件所有權(quán)交易結(jié)構(gòu)Fig.6 Transaction framework of file ownership

交易信息主要包括兩種：一種是在特定的條件下進行部署的智能合約S；另一種是通過已部署合約產(chǎn)生的消息調(diào)用M。若用戶發(fā)起交易T 時交易的接收方賬戶地址為空，交易類型為部署一份新的合約S；若交易T的接收方賬戶地址不為空，此時交易類型為調(diào)用已部署的智能合約進行交易，其中T調(diào)用的M中包括交易接收方的賬戶地址、合約接口等數(shù)據(jù)。

2）創(chuàng)建區(qū)塊。電子文件流轉(zhuǎn)區(qū)塊鏈中礦工創(chuàng)建區(qū)塊的過程為：授權(quán)節(jié)點同步區(qū)塊鏈并對交易池中的未確認交易進行收集和驗證，主要驗證該文件所有人的交易簽名合法性及賬戶合法性。然后授權(quán)節(jié)點采用工作量證明機制（Proof-of-Work，PoW）對區(qū)塊進行打包，即將Bp的區(qū)塊頭、隨機數(shù)值、確認交易的哈希值通過哈希算法后得到的哈希值小于Bp 中所設(shè)定的挖礦目標Target，則節(jié)點成功創(chuàng)建出該電子文件流轉(zhuǎn)區(qū)塊B。最后，授權(quán)節(jié)點向全網(wǎng)記賬節(jié)點廣播創(chuàng)建成功的電子文件流轉(zhuǎn)區(qū)塊，其余的記賬節(jié)點會對該區(qū)塊進行驗證，判斷其交易是否具備合法性，從而開始新一輪的記賬權(quán)競爭。底層區(qū)塊鏈中文件所有權(quán)信息入鏈后，自動觸發(fā)文件流轉(zhuǎn)的智能合約，進行云端文件所有權(quán)變更。

3）云端文件所有權(quán)變更。云端變更文件F的具體流程如圖7所示。

圖7 云端文件所有權(quán)變更流程Fig.7 File ownership transfer process on cloud platform

由于方案基于聯(lián)盟鏈進行設(shè)計，所以挖礦節(jié)點負責(zé)執(zhí)行智能合約，當(dāng)新區(qū)塊生成時，每個挖礦節(jié)點D對區(qū)塊中的交易TX 所對應(yīng)的智能合約S 進行驗證。驗證通過后自動執(zhí)行合約，將所有權(quán)變更指示發(fā)送至云端C，云端在收到超過50%的挖礦節(jié)點發(fā)送的同一文件F 的相同變更指示后，將文件F 的所有權(quán)變更為本次交易的接收方。至此，文件所有權(quán)變更結(jié)束，交易接收方可通過交易發(fā)起方給予的文件憑證I 登錄云端，下載相應(yīng)文件F，文件流轉(zhuǎn)流程結(jié)束。

2 系統(tǒng)實現(xiàn)

2.1 系統(tǒng)開發(fā)環(huán)境

本系統(tǒng)基于Windows 環(huán)境進行開發(fā)，前后端均采用Java語言進行實現(xiàn)，在MyEclipse 平臺進行系統(tǒng)開發(fā)，數(shù)據(jù)庫使用MySQL，利用SQLyog 進行數(shù)據(jù)庫界面化管理，系統(tǒng)界面使用HTML進行實現(xiàn)。

2.2 文件上傳功能實現(xiàn)

2.2.1 用戶登錄連接

在本系統(tǒng)中用戶登錄是通過端口連接實現(xiàn)客戶端連接的，連接成功后加入系統(tǒng)的每一個用戶設(shè)置用戶ID 作為登錄密碼，該ID 是用戶生成公私鑰的基本依據(jù)。系統(tǒng)中會將用戶ID 通過算法計算生成合法的用戶公鑰地址，公鑰地址是用戶在本系統(tǒng)中唯一的身份標識，成為區(qū)塊鏈賬戶后才正式完成系統(tǒng)登錄，可以對系統(tǒng)應(yīng)用進行訪問。登錄過程中會對用戶的資料進行統(tǒng)一驗證管理。

1）用戶連接客戶端。

輸入要連接的IP 地址和連入的端口，通過ClientStart 類中的Socket（ip，port）方法根據(jù)IP 和端口進行socket 連接，連接成功即完成與服務(wù)器的連接，并使用Receive 類中g(shù)etInputStream（）與getOutputStream（）方法打開I/O 流，接收客戶端發(fā)送的數(shù)據(jù)及向其發(fā)送信息。

2）公私鑰獲取。

①處理用戶ID。使用getText（）.trim（）方法從用戶端界面接收到用戶輸入的ID，轉(zhuǎn)為字符串形式后先進行SM2、SM3參數(shù)準備，由于SM2、SM3函數(shù)的相關(guān)運算均基于字節(jié)型字符串，因此用戶端通過使用Base58.decodeBase58（id）方法將用戶ID 轉(zhuǎn)化為Base58 編碼形式，以字節(jié)型數(shù)組存儲，從而進行下一步加密處理。

②獲取私鑰。調(diào)用SM3 函數(shù)中的getHashBytes（）方法將Base58 編碼方式的ID 字節(jié)型數(shù)組進行SM3 哈希運算，所得256 位字節(jié)型數(shù)組結(jié)果通過Base58.encodeBase58（）方法進行填充、分塊、迭代壓縮，得到的32 字節(jié)字符串即為用戶獲取的私鑰地址。

③獲取公鑰。經(jīng)SM3 運算得到的私鑰通過SM2 函數(shù)的generatePubkeyFromPrikey（）方法將私鑰與SM2 算法的基點進行橢圓曲線的倍點運算，得到密鑰對，其中公鑰使用gmcuser.formatPublicKey（）方法以［x‖y］形式存儲為字節(jié)型數(shù)組，共有64字節(jié)數(shù)據(jù)，以供SM2算法的簽名運算。用戶ID 獲取公私鑰對如圖8所示。

圖8 輸入用戶ID獲取公私鑰對Fig.8 Input user ID to obtain public-private key pair

3）交易地址獲取。

考慮到64 字節(jié)數(shù)據(jù)量的公鑰較為占用空間，且用戶難以直接使用位數(shù)較多的地址進行交易的情況，用戶在使用SM2算法產(chǎn)生公私鑰對后，將公鑰進行兩次SM3運算，并取結(jié)果的前16 字節(jié)處理生成位數(shù)較短的節(jié)點交易地址，便于用戶間進行交易。地址生成后，將16 字節(jié)數(shù)據(jù)通過Base58.encodeBase58Check（）方法轉(zhuǎn)化為Base58 編碼形式字符串并輸出，用戶作為交易接收方時，將此作為交易輸出地址發(fā)送至交易發(fā)起方以生成交易信息。

2.2.2 電子文件上傳和登記

文件上傳由客戶端發(fā)起，用戶需要形成文件哈希作為文件標記，用于云端存放時的標識。云端接收后，需要在本地進行哈希運算，且結(jié)果需要同用戶的哈希值一致。

1）打開本地文件并上傳。獲取電子文件本地地址如圖9所示，打開本地文件并通過getSelectedFile（）選擇上傳文件，使用file.getAbsolutePath（）方法獲取絕對路徑，以字符串形式導(dǎo)出文件地址后發(fā)起上傳。

圖9 獲取電子文件本地地址Fig.9 Obtaining local address of electronic file

2）文件上傳。上傳的地址作為用戶節(jié)點交易地址，系統(tǒng)按照給定路徑在本地需找上傳文件。通過對文件數(shù)據(jù)內(nèi)容以字節(jié)的形式進行讀取操作，獲取文件內(nèi)容后將內(nèi)容轉(zhuǎn)為GBK編碼形式。文件內(nèi)容編碼后經(jīng)SM3 運算生成文件哈希值，作為該文件的完整性標識。文件上傳時需以固定數(shù)據(jù)格式消息集通過socket 連接發(fā)送至云端。根據(jù)信息格式，將上傳文件｛S3=（"1，"+wenjianming+"，"+Hash+"，"+Address+"，"+AlartTxt1）｝數(shù)據(jù)包的形式傳至云端，實現(xiàn)文件內(nèi)容存儲和索引記錄，其中：wenjianming 是上傳文件名稱，Hash 指文件經(jīng)SM3 算法生成的數(shù)字摘要，用于防止文件上傳過程中發(fā)生內(nèi)容篡改；Address 是上傳方節(jié)點地址，作為文件發(fā)送方證明；AlartTxt1指文件的十六進制字符串內(nèi)容。

云端接收到數(shù)據(jù)包后將信息以“，”分割為字符串?dāng)?shù)組，將文件名，所有人及哈希存入云端文件索引數(shù)據(jù)庫，十六位文件內(nèi)容的字符串內(nèi)容則轉(zhuǎn)換為GBK 編碼形式的文件存于云端文件存儲區(qū)，至此完成文件的存儲和索引生成。此時云端會向用戶返回存儲成功的反饋，告知用戶端文件成功上傳。

2.3 文件所有權(quán)和流轉(zhuǎn)溯源查詢

2.3.1 文件所有權(quán)交易

電子文件交易合約是主要節(jié)點提前嵌套至系統(tǒng)中的執(zhí)行程序，當(dāng)交易信息滿足條件時自動執(zhí)行。合約內(nèi)容必須按照固定格式存儲于區(qū)塊鏈中，格式如圖10所示。

圖10 文件所有權(quán)交易合約信息Fig.10 Contract information of file ownership transaction

用戶在客戶端輸入users 用戶集合發(fā)起合約上傳，用戶集中包含所有需要文件流轉(zhuǎn)的地址集?？蛻舳藢⑽募鸑ame、文件Hash、users 打包為消息M，使用用戶私鑰對消息M 進行SM2 簽名運算，以固定格式的數(shù)據(jù)包發(fā)送至主要節(jié)點。格式與云端消息類似，如圖11所示。

圖11 用戶端發(fā)送交易信息Fig.11 Sending transaction information by client-side

用戶將上述信息以｛S3=（"1，"+Address+"，"+name+"，"+Hash+"，"+users+"，"+gongyao+"，"+sign0+"，"+sign1）｝的字符串形式將內(nèi)容發(fā)送至授權(quán)節(jié)點進行記錄，sign0 與sign1 分別表示消息經(jīng)SM2算法所產(chǎn)生數(shù)字簽名的r與s。節(jié)點收到信息后將信息分割并進行處理，判斷對比交易發(fā)起方的地址是否與節(jié)點本地生成的地址一致，以及簽名驗證是否通過，均通過則生成新的合約，將合約記錄入鏈，并將合約在數(shù)據(jù)庫中的對應(yīng)索引值即新的合約編號發(fā)回合約請求節(jié)點。

當(dāng)用戶使用客戶端發(fā)起交易申請時，需輸入上傳合約后返回的合約編號、文件流轉(zhuǎn)目標Address，讀取文件名Name、交易發(fā)起方的私鑰和上次交易編號，上次交易編號作為流轉(zhuǎn)憑證起溯源索引作用，如果是初次交易，則上次交易編號與合約編號相同。將｛合約編號+目標地址+上次交易編號｝數(shù)據(jù)打包作為簽名內(nèi)容，使用私鑰進行SM2 簽名，獲得sign0 和sign1 兩個簽名部分。底層區(qū)塊鏈網(wǎng)絡(luò)收到交易申請后，提取消息中的sign0 和sign1 與交易信息中被簽名的內(nèi)容進行SM2 簽名驗證，授權(quán)節(jié)點生成新區(qū)塊使用SM3 算法對當(dāng)前區(qū)塊鏈中所有未入鏈交易進行提取，合并全部交易信息后在尾部加入隨機數(shù)，使用SM3算法生成哈希值，通過改變隨機數(shù)值更新哈希值直至該值滿足一定條件后，作為新區(qū)塊的哈希值進行廣播。

節(jié)點在生成區(qū)塊后，對所有新入鏈的交易信息進行提取處理，摘出交易信息中的交易接收方，同時追蹤該交易所屬合約，提取合約中的文件名與哈希值，鏈接MySQL數(shù)據(jù)庫，向云端發(fā)起socket連接，發(fā)送文件更名命令。云端收到底層區(qū)塊確認信息后調(diào)用SM2算法驗證簽名，驗證通過且明確該公鑰屬于授權(quán)節(jié)點后，連接文件索引數(shù)據(jù)庫，對數(shù)據(jù)庫中文件進行更名處理，此時文件所有權(quán)屬于文件接收方，文件所有權(quán)交易完成。

2.3.2 文件流轉(zhuǎn)溯源查詢

接收端用戶在收到流轉(zhuǎn)文件新索引后通過客戶端請求下載，如圖12 所示，獲取文件名稱、私鑰、公鑰、地址和哈希值，將私鑰進行編碼轉(zhuǎn)換。

圖12 接收端下載電子文件Fig.12 Downloading electronic file at the receiving terminal

云端接收到下載文件申請，對接收的信息進行分割處理，利用簽名內(nèi)容1、簽名內(nèi)容2、文件信息m1 和公鑰進行SM2 簽名驗證，判斷申請人和文件是否存在，若存在，則將文件進行解碼轉(zhuǎn)換為十六進制字符串輸出，并用socket連接。

接收端用戶獲得下載許可，調(diào)用數(shù)據(jù)流通過socket 取出數(shù)據(jù)，然后以String 的形式返回此字符串作為文件名，調(diào)用fileLength（）讀取文件長度。根據(jù)directory 抽象路徑名和E：\FTCache 路徑符串創(chuàng)建一個新File 實例，判斷返回目錄名E：\FTCach 是否有實體存在，若失敗返回false，若成功則返回true，調(diào)用mkdir（）函數(shù)創(chuàng)建目錄。在目錄下，創(chuàng)建文件directory.getAbsolutePath（）+File.separatorChar+fileName，該流向File 對象表示的文件寫出數(shù)據(jù)進行文件接收。從此輸入流中將最多1 024個字節(jié)的數(shù)據(jù)讀入一個byte數(shù)組中，返回值是返回讀入緩沖區(qū)的字節(jié)總數(shù)，當(dāng)已經(jīng)到達文件末尾而沒有更多的數(shù)據(jù)時，則返回-1。當(dāng)它返回-1 時，數(shù)據(jù)已經(jīng)復(fù)制完了while循環(huán)終止程序結(jié)束，則該文件接收成功。

當(dāng)授權(quán)節(jié)點接收到查詢申請時，會通過申請方提供的文件索引值在數(shù)據(jù)庫中進行查詢，依據(jù)新舊索引值變化查找到對應(yīng)的文件流轉(zhuǎn)過程，從而完成文件的流轉(zhuǎn)溯源過程查詢。

3 系統(tǒng)測試

系統(tǒng)測試流程主要由用戶注冊、文件所有權(quán)轉(zhuǎn)讓、文件溯源查詢?nèi)糠纸M成。

3.1 用戶注冊

首先，用戶在客戶端輸入IP 地址和相關(guān)端口號，與服務(wù)器建立連接。用戶連接成功和失敗的效果圖分別為圖13所示。

圖13 用戶連接成功或失敗Fig.13 Success and fail of user connection

然后，用戶輸入用戶ID，生成相應(yīng)的公私鑰對及交易地址。生成的效果如圖14所示。

3.2 文件所有權(quán)轉(zhuǎn)讓

用戶上傳文件成功后向區(qū)塊鏈網(wǎng)絡(luò)發(fā)起文件所有權(quán)交易申請，該交易需要先進行智能合約的上傳和觸發(fā)，隨后將自動實現(xiàn)文件所有權(quán)的轉(zhuǎn)換。電子文件流轉(zhuǎn)的智能合約是由主要節(jié)點提前嵌套至系統(tǒng)中的執(zhí)行程序，當(dāng)交易信息滿足條件時自動執(zhí)行。

用戶 向云端上傳需進行公證的電子文件。為防止電子文件傳輸誤差，用戶需要在文件末尾附加相關(guān)哈希值。效果圖如圖15所示。

圖14 輸入ID不同獲得公私鑰對Fig.14 Inputting different ID to obtain different public and private key pairs

云端 在接收文件后，需要對用戶提供的電子文件進行哈希計算，與接收到的哈希值做對比。完成驗證后，云端會向用戶返回存儲成功的反饋，告知用戶端文件成功上傳。若驗證不通過，則該交易無效，節(jié)點不予記錄，同時向用戶返回報錯信息。云端接收文件并進行存儲如圖16所示。

圖15 選取上傳文件并完成上傳Fig.15 Choosing and uploading file

圖16 云端接收文件并進行存儲Fig.16 Receiving and storing files on cloud platform

用戶 以（UserAddress+TxtName+TxtHash+sig+pk）形式向網(wǎng)絡(luò)廣播電子文件的合約信息。其中，UserAddress 為用戶的交易地址，TxtName 為文件名稱，TxtHash 為對應(yīng)的哈希值，sig為交易的簽名，pk為用于簽名驗證的公鑰。用戶上傳文件成功后向區(qū)塊鏈網(wǎng)絡(luò)發(fā)起文件所有權(quán)交易申請，該交易需要先進行智能合約的上傳和觸發(fā)，隨后將自動實現(xiàn)文件所有權(quán)的轉(zhuǎn)換。

礦工 首先驗證用戶提供的公鑰UserAddress 與地址是否一致，接著對交易的簽名進行驗證。以上驗證均通過則生成新的合約，并將合約記錄入鏈。若驗證不通過，則該交易無效，節(jié)點不予記錄，同時向用戶返回報錯信息。確認合法的效果圖如圖17所示。

然后在生成區(qū)塊后，對所有新入鏈的交易信息進行提取處理，摘出交易信息中的交易接收方，同時追蹤該交易所屬合約，提取合約中的文件名與哈希值，向云端發(fā)起文件更名命令，新區(qū)塊并入?yún)^(qū)塊鏈如圖18所示。

圖18 新區(qū)塊并入?yún)^(qū)塊鏈Fig.18 Adding new block into blockchain

云端 云端收到底層區(qū)塊確認信息后調(diào)用SM2算法驗證簽名，驗證通過且明確該公鑰屬于授權(quán)節(jié)點后，連接文件索引數(shù)據(jù)庫，對數(shù)據(jù)庫中文件owner 進行更名處理，此時文件所有權(quán)屬于文件接收方，即為交易信息中的輸出方txout。

3.3 文件追溯查詢

用戶 在收到流轉(zhuǎn)文件新索引后通過客戶端向授權(quán)節(jié)點提出下載請求。

授權(quán)節(jié)點 當(dāng)收到查詢申請時，通過申請方提供的文件索引值在數(shù)據(jù)庫中進行查詢，依據(jù)新舊索引值變化查找到對應(yīng)的文件流轉(zhuǎn)過程，從而完成文件的流轉(zhuǎn)溯源過程查詢。若請求合法，向云端發(fā)出同意該用戶下載文件指令。

云端 接收到下載文件申請后，判斷文件地址是否正確和文件owner是否是下載申請人，當(dāng)判斷為true時則創(chuàng)建文件流，在當(dāng)前目錄中創(chuàng)建新文件并進行操作，隨后判斷該文件是否存在。向用戶發(fā)出文件下載許可。

用戶 通過云端指定路徑即可下載目標文件。

4 安全性分析

本章主要針對區(qū)塊偽造攻擊和篡改數(shù)據(jù)攻擊進行安全說明。當(dāng)惡意節(jié)點企圖通過篡改交易數(shù)據(jù)、延遲交易生效等方式進行非法交易操作時，需要偽造新區(qū)塊保證惡意交易生效。考慮到惡意節(jié)點的攻擊方式為通過延遲當(dāng)前賬本中未入鏈交易的入鏈速度，通過連續(xù)生成區(qū)塊導(dǎo)致同樣輸入，不同輸出的交易生效的“雙花”交易。

下面假設(shè)正常節(jié)點生成新區(qū)塊的概率為Ps，惡意節(jié)點生成新區(qū)塊的概率為Pe，正常節(jié)點的個數(shù)為g，則若惡意節(jié)點發(fā)起一次偽造區(qū)塊操作，連續(xù)生成兩個新區(qū)塊的概率Pn為：

由式（4）可知，在節(jié)點算力不變的情況下，節(jié)點總數(shù)越多，惡意節(jié)點偽造區(qū)塊成功的概率越小，惡意節(jié)點需要提升算力，增大生成新區(qū)塊的概率，才能提高偽造成功率。本文通過降低惡意節(jié)點的區(qū)塊生成難度，達到提升惡意節(jié)點算力的效果。通過系統(tǒng)測試，本系統(tǒng)在正常節(jié)點數(shù)為5 時，惡意節(jié)點與正常節(jié)點的挖礦難度差距H=2 時，才能使生成新區(qū)塊所需平均時間與正常節(jié)點組基本一致。如圖19 所示，當(dāng)正常節(jié)點數(shù)為10 時，惡意節(jié)點與正常節(jié)點的挖礦難度差距H=3 仍比正常交易節(jié)點組生成區(qū)塊用時更長，此時惡意節(jié)點的算力已大約為正常節(jié)點的8 倍。本文系統(tǒng)使用10 個節(jié)點進行區(qū)塊生成，所用共識算法在惡意節(jié)點算力遠大于正常節(jié)點時，仍能抵抗惡意節(jié)點的偽造區(qū)塊攻擊。

圖19 惡意節(jié)點偽造區(qū)塊攻擊用時Fig.19 Time of malicious node forged block attack

對于篡改數(shù)據(jù)攻擊，由于本文系統(tǒng)基于聯(lián)盟鏈設(shè)計，新區(qū)塊生成需要經(jīng)過全部在線主要節(jié)點投票決定是否作為有效區(qū)塊，當(dāng)票數(shù)超過50%才能生效。因此只有當(dāng)惡意節(jié)點超過當(dāng)前在線節(jié)點總和的半數(shù)，篡改數(shù)據(jù)才能成功。本文系統(tǒng)使用10 個主要節(jié)點進行區(qū)塊生成，主要節(jié)點長期在線，可以有效防止惡意節(jié)點通過多數(shù)投票達到篡改交易數(shù)據(jù)的目的。

5 性能測試

在本章的性能測試中，將實際運行結(jié)果與預(yù)設(shè)功能進行對比分析，得出本系統(tǒng)各部分功能正常且電子文件流轉(zhuǎn)過程順利，已滿足了電子文件的流轉(zhuǎn)要求。對系統(tǒng)的性能測試和仿真中，本系統(tǒng)能夠有效抵抗惡意攻擊，防止篡改文件所有權(quán)問題的發(fā)生，相較于傳統(tǒng)電子文件流轉(zhuǎn)系統(tǒng)具備更高的安全性和不可篡改性。同時，系統(tǒng)的效率測試表明該系統(tǒng)的交易過程滿足系統(tǒng)需要，當(dāng)需要大批量文件流轉(zhuǎn)時可以通過增加授權(quán)節(jié)點數(shù)量縮短交易確認時間，從而提升系統(tǒng)效率。

本系統(tǒng)基于Java 語言搭建聯(lián)盟鏈環(huán)境，使用數(shù)據(jù)庫完成區(qū)塊鏈數(shù)據(jù)存放，調(diào)用云平臺端口完成文件存放，故其安全性和穩(wěn)定性可以滿足要求。

系統(tǒng)的效率測試是對系統(tǒng)在正常使用下其系統(tǒng)運行用時的測試。因系統(tǒng)中節(jié)點的文件上傳與下載工作用時主要取決于云端架構(gòu)、文件大小及網(wǎng)速等因素，與區(qū)塊鏈系統(tǒng)運行效率不直接相關(guān)，故不進行測試。本文主要對系統(tǒng)區(qū)塊鏈節(jié)點運行部分進行效率仿真與測試。

節(jié)點在上傳文件至云端后，需在本地根據(jù)密鑰對及文件哈希值等信息生成相應(yīng)文件流轉(zhuǎn)合約。進行文件流轉(zhuǎn)時，須根據(jù)返回的合約編號及流轉(zhuǎn)方的地址制作交易信息。本文定義節(jié)點生成智能合約所需平均時間Sm與生成交易信息平均用時Sq為：

式（5）～（6）中：Ti(m)與Ti(q)分別表示第i 次測試時節(jié)點生成智能合約與生成交易信息所用的時間。平均用時即為進行20次實驗之后所得的平均值。由圖20可知，在用戶密鑰對成功生成的情況下，成功制作一次智能合約與交易信息的平均時間分別為41.8 ms 與40.4 ms，因為本文系統(tǒng)兩個功能步驟所需運算類似，因此用時差距較小，并且用時均較短，在確保功能完整的情況下生成數(shù)據(jù)量較少，滿足聯(lián)盟鏈交易的要求。

圖20 節(jié)點生成智能合約和生成交易所用時間Fig.20 Times of nodes to generate smart contracts and generate transactions

交易信息由用戶發(fā)送至授權(quán)節(jié)點后，開始確認交易信息。本文定義系統(tǒng)交易平均驗證時間Stx與最短耗時Mtx為：

式（7）～（8）中：n為參與仿真測試的區(qū)塊數(shù)，Ti為主要節(jié)點對第i個區(qū)塊的驗證時間，Pi為第i個區(qū)塊中所包含的交易個數(shù)，平均驗證速度即為單位時間內(nèi)主要節(jié)點驗證交易信息的平均次數(shù)。經(jīng)過節(jié)點的區(qū)塊驗證仿真測試，在確認交易信息無誤的情況下，授權(quán)節(jié)點驗證區(qū)塊合法性的時間與該區(qū)塊所含的交易量間呈圖21關(guān)系。由圖21可知，本方案中授權(quán)節(jié)點平均驗證通過一個區(qū)塊所需時間為34.2 ms，最快可達到20.1 ms，可算出不考慮共識算法消耗時間的情況下，系統(tǒng)平均交易速度為每秒29.2 次，最多可達49.7 次，交易次數(shù)滿足聯(lián)盟鏈應(yīng)用場景需要。

圖21 仿真環(huán)境下授權(quán)節(jié)點驗證區(qū)塊合法性時間與所含交易量關(guān)系Fig.21 Relationship between time of authorized node verifying block legality and transaction volume in simulation

交易信息經(jīng)授權(quán)節(jié)點確認入鏈后，開始執(zhí)行智能合約。本文定義節(jié)點執(zhí)行智能合約平均用時Sc及最短耗時Mc為：

式（9）～（10）中：Ti(F)為第i 次實驗時節(jié)點在區(qū)塊鏈中找到交易信息所屬智能合約的時間，Ti(S)為節(jié)點根據(jù)交易信息，執(zhí)行對應(yīng)智能合約，向云端發(fā)送文件所屬權(quán)變更命令的時間，x為實驗仿真次數(shù)。如圖22 所示，經(jīng)20 次仿真可知，在確認交易信息無誤的情況下，成功追蹤到所屬智能合約的平均用時為25.5 ms，最短需要21.7 ms。在驗證交易信息滿足所屬智能合約執(zhí)行條件的情況下，授權(quán)節(jié)點執(zhí)行一次智能合約，發(fā)送所屬權(quán)變更指令的平均用時為150.7 ms，最短需要101.1 ms。因此，節(jié)點執(zhí)行智能合約平均用時約172.4 ms。合約執(zhí)行時間較短，可以滿足電子文件流轉(zhuǎn)的實際需要。

圖22 仿真環(huán)境下授權(quán)節(jié)點追蹤合約用時Fig.22 Time of authorized node tracking contract in simulation

6 結(jié)語

將區(qū)塊鏈技術(shù)和云存儲技術(shù)相結(jié)合，極大程度地解決電子文件流轉(zhuǎn)中的一些問題，同時二者相互結(jié)合并應(yīng)用于電子文件領(lǐng)域?qū)U大區(qū)塊鏈技術(shù)的應(yīng)用場景，對推動區(qū)塊鏈應(yīng)用具有一定理論和實踐意義。本文提出的電子文件流轉(zhuǎn)方案在可接受的時延范圍內(nèi)實現(xiàn)了文件的安全流轉(zhuǎn)和可信記錄，能夠根據(jù)區(qū)塊鏈記錄進行流轉(zhuǎn)過程查詢，有效防止數(shù)據(jù)篡改和惡意攻擊，保證接入記錄的結(jié)果完整可信，保障整體系統(tǒng)運行可靠、安全可用。為了弱化中心化環(huán)節(jié)系統(tǒng)的正常運行，本系統(tǒng)采用輸入ID 作為用戶登錄的方法，自動置入密鑰功能暫未實現(xiàn)，可以在下一步工作中繼續(xù)完善設(shè)備系統(tǒng)，實現(xiàn)自動置入功能。