基于區(qū)塊鏈的電子文件流轉設計與實現

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

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

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

0 引言

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

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

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

1 設計目標與系統(tǒng)架構

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

1.1 設計目標

1）文件流轉的安全性。電子文件在流轉過程中內容容錯。此外，文件所有權只有經用戶簽名及礦工驗證后才能更改。

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

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

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

1.2 技術架構

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

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

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

圖1 電子文件流轉示意圖Fig.1 Schematic diagram of electronic file circulation

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

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

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

云端 完成文件的存放與流轉，如圖4所示。

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

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

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

圖4 云存儲文件所有權流轉過程Fig.4 Process of cloud storage file ownership transfer

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

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

圖5 電子文件所有權流轉合約結構Fig.5 Contract structure for circulation of ownership transfer of electronic files

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

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

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

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

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

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

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

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

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

1.4 電子文件所有權交易流程

具體流程如下：

1）發(fā)起交易。電子文件流轉區(qū)塊鏈網絡中的客戶端發(fā)起的交易TX，主要結構如圖6所示。

圖6 文件所有權交易結構Fig.6 Transaction framework of file ownership

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

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

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

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

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

2 系統(tǒng)實現

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

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

2.2 文件上傳功能實現

2.2.1 用戶登錄連接

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

1）用戶連接客戶端。

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

2）公私鑰獲取。

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

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

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

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

3）交易地址獲取。

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

2.2.2 電子文件上傳和登記

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

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

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

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

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

2.3 文件所有權和流轉溯源查詢

2.3.1 文件所有權交易

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

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

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

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

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

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

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

2.3.2 文件流轉溯源查詢

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

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

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

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

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

3 系統(tǒng)測試

系統(tǒng)測試流程主要由用戶注冊、文件所有權轉讓、文件溯源查詢三部分組成。

3.1 用戶注冊

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

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

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

3.2 文件所有權轉讓

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

用戶 向云端上傳需進行公證的電子文件。為防止電子文件傳輸誤差，用戶需要在文件末尾附加相關哈希值。效果圖如圖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）形式向網絡廣播電子文件的合約信息。其中，UserAddress 為用戶的交易地址，TxtName 為文件名稱，TxtHash 為對應的哈希值，sig為交易的簽名，pk為用于簽名驗證的公鑰。用戶上傳文件成功后向區(qū)塊鏈網絡發(fā)起文件所有權交易申請，該交易需要先進行智能合約的上傳和觸發(fā)，隨后將自動實現文件所有權的轉換。

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

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

圖18 新區(qū)塊并入區(qū)塊鏈Fig.18 Adding new block into blockchain

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

3.3 文件追溯查詢

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

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

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

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

4 安全性分析

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

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

由式（4）可知，在節(jié)點算力不變的情況下，節(jié)點總數越多，惡意節(jié)點偽造區(qū)塊成功的概率越小，惡意節(jié)點需要提升算力，增大生成新區(qū)塊的概率，才能提高偽造成功率。本文通過降低惡意節(jié)點的區(qū)塊生成難度，達到提升惡意節(jié)點算力的效果。通過系統(tǒng)測試，本系統(tǒng)在正常節(jié)點數為5 時，惡意節(jié)點與正常節(jié)點的挖礦難度差距H=2 時，才能使生成新區(qū)塊所需平均時間與正常節(jié)點組基本一致。如圖19 所示，當正常節(jié)點數為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

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

5 性能測試

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

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

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

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

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

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

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

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

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

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

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

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

6 結語

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