基于區塊鏈的可搜索加密人才履歷共享方案①

馬 繼, 周 鳳, 田有亮,2,3

1(貴州大學 計算機科學與技術學院, 貴陽 550025)

2(貴州大學 公共大數據國家重點實驗室, 貴陽 550025)

3(貴州大學 密碼學與數據安全研究所, 貴陽 550025)

1 引言

信任作為一個抽象的概念, 卻在不同領域之中都顯得十分重要[1], 在職場領域有調查指出, 職場失信的重災區集中在招聘環節, 個人履歷造假情況超過了半數以上.在傳統的履歷存證方法中, 通常需要委托第三方機構進行候選人背景調查, 然后再由第三方機構出具相關的調查報告, 比如A企業需要核實候選人B的履歷信息, 就需要第三方機構在收到委托與授權后充當中心角色向C企業進行核實并返回調查報告[2]. 此過程涉及到多方的參與, 且對于最終履歷數據的管理呈現為以第三方機構為核心的中心化結構, 這對候選人的履歷信息管理、真實性鑒別帶來了十分巨大的困難. 同時, 隨著云計算技術的崛起, 使用云存儲技術進行數據存儲是大勢所趨,而云服務器通常被認為是半誠實且好奇的[3], 這意味著它將誠實地執行算法,但會嘗試學習盡可能多的私有信息. 因此, 如何安全的將真實可靠的履歷數據存放在云服務器中, 如何安全正確的將履歷數據進行共享, 仍舊是一個不小的難題. 區塊鏈[4]作為一種去中心化的存儲結構, 存儲在鏈上的數據具有不可篡改、公開透明、可溯源性等特征, 這些特性天然的適合需要保證數據可信度以及公開透明的應用場景, 因此基于區塊鏈網絡進行信息共享是解決傳統信息共享中心化的途徑. 目前基于區塊鏈技術對人才履歷存證的相關研究較匱乏, 但在其他方面比如數字版權存證[5]、金融行業[6,7]、電子病歷共享[8]等方面均取得了巨大的進展. 上述研究與區塊鏈技術在人才履歷存證中的應用需要考慮的因素基本相同, 即如何保證數據的真實性與安全性、如何保證用戶收到數據的正確性.

Song等人[9]為了節省本地存儲空間與保護數據安全, 首次提出了一種基于單關鍵字的可搜索加密(Searchable Encryption, SE)方案, 方案將所有文件加密后上傳到服務器進行存儲, 在需要對文件進行檢索時使用加密后的關鍵字與所存儲文件進行一一比較, 以發現是否存在所需文件, 但在數據較大時會限制檢索的效率. 基于此項研究, Cao等人[10]首次提出了基于多關鍵字的SE方案, 方案引入“坐標匹配”相似性度量以提升搜索效率并且實現在不同威脅模型下的系統安全性. Sun等人[11]最早開始研究有效搜索結果驗證問題,并提出了相應的可驗證SE方案, 他們的方案使得用戶能夠進行安全的聯合關鍵詞搜索, 更新外包文件集并有效地驗證搜索結果的真實性. Naveed等人[12]提出了動態SE方案, 方案允許用戶使用服務器存儲加密文檔的動態集合, 然后在對這些加密文檔進行快速搜索的同時, 向服務器顯示最少的信息. Chen等人[8]基于區塊鏈提出了一種可驗證最終結果的SE數據共享方案,方案基于布爾表達式對鏈上數據進行搜索, 相比文獻[9]方案提升了文件搜索效率, 但一旦第三方獲取了數據索引的內容可能會導致數據的泄露. Hu等人[13]結合區塊鏈技術首次提出了無需驗證最終結果正確性的SE數據共享方案, 方案引入押金機制, 確保了數據共享過程中的參與方在無需驗證結果的情況下收到正確的執行結果, 實現了參與者之間的公平性與隱私保護.

本文結合區塊鏈與可搜索加密技術提出了一種基于區塊鏈的可搜索加密人才履歷共享方案, 去除傳統第三方機構, 解決了傳統人才履歷存證中數據管理中心化、履歷造假等問題. 所提方案首先基于區塊鏈不可篡改的特性, 結合云存儲技術對履歷數據實現鏈上鏈下協同存儲, 保證了履歷數據的真實性. 其次, 在履歷數據共享過程中, 利用區塊鏈去中心化的特性取代傳統第三方機構, 結合可搜索加密技術實現了參與方之間的公平性與數據存儲、更新時的隱私保護. 最后基于Hyperledger[14]聯盟鏈實現方案并對安全性和性能進行分析, 保證方案的正確性以及實際的可行性.

2 相關技術

2.1 聯盟鏈

區塊鏈技術發展至今, 演化出了許多分支. 按照網絡結構去中心化程度的不同可以分為:

公有鏈: 全網公開, 無用戶授權機制的區塊鏈, 節點可以自由出入網絡, 以文獻[4]為代表；

聯盟鏈: 允許授權的節點加入網絡, 可根據權限查看信息, 往往被用于機構間的區塊鏈, 也稱為行業鏈,代表有文獻[14]；

私有鏈: 所有網絡中的節點都掌握在單獨的個人或實體手中, 鏈上的數據不被其他任何人所知曉.

由于訪問聯盟鏈需要許可的特性, 現在已被廣泛應用于銀行、保險、證券、商業協會等[15]. 聯盟鏈的記賬節點是提前在內部預選的多個節點作為記賬節點,新塊的產生由預選記賬節點決定, 其他節點只參與交易過程, 但不過問記賬細節, 因此聯盟鏈不需要通過工作量證明算法(Proof Of Work, POW)共識, 轉而更傾向于實用拜占庭算法(Practical Byzantine Fault Tolerance, PBFT)或委托權益證明(Delegated Proof Of Stake, DPOS)[16]共識算法來保證數據的正確性. 由于共識機制的更改, 聯盟鏈通常還具有更高的系統吞吐量, 更低的資源消耗, 還允許擁有權限的第三方通過開放的API查詢指定的數據, 這些特性極大拓寬了區塊鏈的應用領域.

2.2 智能合約

智能合約[17]定義為“一套以數字形式定義的承諾,包括合約參與方可以在上面執行這些承諾的協議”. 在比特幣以前, 智能合約由于缺少可信的運行環境, 并沒有在實際生產中實現和運用. 但是在區塊鏈系統中, 智能合約在共識和網絡的封裝之上, 可在不涉及第三方的情況下促進交易的可靠執行, 并且所有交易都是可追蹤且不可逆的, 隱藏了區塊鏈網絡中各節點的復雜行為, 同時提供了區塊鏈應用層的接口. 這意味著智能合約可提供優于傳統合約法的安全性, 并降低與合約相關的交易成本, 這些特性與區塊鏈的結合同樣增加了區塊鏈的應用場景.

2.3 可搜索加密

可搜索加密問題最早源于文獻[9]: 假設用戶試圖將文件存放在誠實但好奇的服務器中, 以節約本地資源, 同時為保護文件隱私, 須采用某種加密方式將文件加密后存儲. 可搜索加密主要由4個算法組成[18]:

(1)加密: 用戶使用密鑰對明文進行加密并將所得密文上傳服務器.

(2)陷門生成: 用戶使用密鑰生成待查詢關鍵詞的陷門, 要求陷門不能泄露關鍵詞的任何信息.

(3)檢索: 服務器以陷門為輸入, 執行檢索算法, 返回所有包含該陷門對應關鍵詞的密文文件, 要求服務器除了能知道密文文件是否包含某個特定關鍵詞外,無法獲得更多信息.

(4)解密: 用戶使用密鑰解密服務器返回的密文文件, 獲得明文結果.

從密碼構造角度可搜索加密現可劃分為兩大類,即對稱可搜索加密與非對稱可搜索加密. 其中, 對稱可搜索加密的構造通常基于偽隨機函數, 具有計算開銷小、算法簡單、速度快的特點, 除了加解密過程采用相同的密鑰外, 其陷門生成也需密鑰的參與. 相比于非對稱加密, 對稱加密的計算量小, 加密速度快, 當加密大量數據時其實現效率要比非對稱加密高6-10倍, 但密鑰的分發缺乏安全, 算法的安全性在很大程度上依賴于密鑰[19]. 非對稱可搜索加密使用兩種密鑰: 公鑰用于明文信息的加密和目標密文的檢索, 私鑰用于解密密文信息和生成關鍵詞陷門. 非對稱加密算法通常較為復雜, 加解密速度較慢, 然而其公私鑰相互分離的特點, 避免了在發送者與接收者之間建立安全通道: 發送者使用接收者的公鑰加密文件和關鍵詞, 檢索時, 接收者使用私鑰生成待檢索關鍵詞陷門, 服務器根據陷門執行檢索算法后返回目標密文, 具有較高的實用性.

3 系統模型

通過對傳統人才履歷存證流程的分析, 本文提出了一個基于區塊鏈的可搜索加密人才履歷共享方案,方案模型如圖1所示.

模型共包含4個實體, 分別是數據擁有者、用戶、云服務器以及區塊鏈, 表示為四元組(Cs,B,D,U). 其中Cs代表云服務器；B代表區塊鏈網絡；D代表數據擁有者集合, 由負責生成人才履歷信息并將數據上鏈的用戶組成, 即:

U代表用戶集合, 由需要從鏈上獲取數據的參與方組成, 即:

模型改進了傳統履歷存證完全依靠人工方式的缺點, 去除了傳統履歷存證中的第三方機構, 進而減少了履歷造假的可能性. 并且模型對參與方進行了嚴格的身份權限控制: 數據擁有者需要通過身份認證才能獲得區塊鏈的準入權限, 而用戶在對數據進行搜索之前同樣需要獲得數據擁有者授權以獲得數據索引才能進行數據的搜索工作, 這樣的設計從源頭上解決了可能的數據造假問題, 相比傳統的履歷存證提升了效率與數據真實性. 完整的系統過程描述如下:

(1) 數據擁有者Di申請區塊鏈準入權限以加入集合D, 之后Di對已有數據運行第4節中算法以獲得加密后的密文C與數據索引I.

(2) 數據擁有者Di上傳密文C至云服務器Cs.

(3) 數據擁有者Di上傳索引I至區塊鏈網絡B.

(4) 用戶Uj向Di申請授權以獲得搜索標識Q.

(5)Di分別將搜索標識Q發往區塊鏈B及用戶Uj.

(6)Uj用標識Q向區塊鏈網絡B發起搜索請求.

(7)B執行搜索算法之后返回數據索引給Uj.

(8)Uj使用數據索引向云服務器請求密文Cm.

(9) 云服務器返回對應密文Cm給Uj.

在上述過程中, 搜索標識Q包含當次查詢所需的數據索引信息以及雙方的身份信息, 并且分別由數據擁有者以及用戶發往區塊鏈進行存儲備份, 再由智能合約調用搜索算法對Q進行相關數據搜索, 并假設最終結果將通過一個安全的通道傳輸給用戶.

4 方案設計

在本節中, 將給出所提方案的具體構造. 方案基于區塊鏈與可搜索加密技術, 不僅可以保證履歷數據的真實性, 實現數據的隱私保護, 還具有公平性和健壯性.方案一共由3個多項式時間算法組成: 初始化, 查詢,更新. 我們定義了如下兩個偽隨機函數, 其中λ是系統安全性參數, *代表長度可為任意值. 假設所有數據存放在非關系型數據庫CouchDB中, 且涉及到的其他符號定義如表1所示.

表1 符號定義

在初始化階段, 數據擁有者首先將隨機生成兩個長度為λ的mk、sk以作為后續生成中間參數以及進行數據加密的密鑰. 然后對于已有的每份數據, 將mk、sk以及整份數據作為算法的輸入, 輸出是數據的索引以及加密后的密文. 在對所有數據進行上述操作之后,將輸出的數據索引集合I發送到智能合約, 由智能合約進行索引的存儲, 將輸出的密文集合C存儲至云端.詳細的算法步驟見算法1.

算法1. Setup輸入: mk, sk, R輸出: I, C 1. the data owner init list L 2. for r∈R 3. K1←F(mk, 1|| rid)； K2←F(mk, 2||r)s←-4. g {0,1}λ； d← id⊕G(K2, g)； l←F(K1,1)5. add tuple (l, d||g)) to L 6. encrypt r with sk；7. end for 8. the data owner send L to the smart contract 9. the smart contract init list γ, γD and γU 10. for tuple (l, d||g) ∈ L 11. add (l, d||g) to γ；12. end for 13. end

在查詢階段, 用戶首先向數據擁有者發送申請授權請求以獲得特定數據的搜索標識Q. 數據擁有者先將Q發送至區塊鏈進行記錄, 然后再發送給用戶. 用戶在獲得Q之后將其發往區塊鏈進行數據查詢, 由智能合約調用搜索算法執行當次數據搜索, 并判斷搜索結果的有效性, 同時將Q再次記錄到區塊鏈中. 在所有操作執行完成之后由智能合約將數據索引返回給用戶.詳細的算法步驟見算法2.

算法2. Search輸入: Q輸出: Dataindex 1. the data owner sends Q to the smart contract and the user；2. the smart contract add Q to γD；3. the user sends Q to the smart contract to get data index；4. the smart contract:5. add Q to γU；6. l←F(K1, 1)； d,g←Get(γ, l)；7. if d=⊥ && g=⊥8. return false；9. else 11. id←d⊕G(K2, g)；10. return id；11. end if 12. end

在更新階段中包含了在新區塊中新增履歷數據和更新已有數據兩個操作. 算法以mk、sk以及待操作的數據作為輸入, 首先按照初始化階段算法的思路對數據生成索引以及密文C, 然后再從操作集合O(新增add和更新update)中選取當次更新是做什么操作. 對所有數據進行上述操作之后, 將得到的索引以及密文集合分別發送至區塊鏈以及文件存儲系統, 再由智能合約根據每條數據對應的操作進行數據處理: 如果是新增操作, 則再插入一條數據, 否則就對已有數據進行更新操作. 詳細的算法步驟見算法3.

算法3. Upgrade輸入: mk, sk, R輸出: I, C 1. the data owner init list LA；2. for r∈R 3. K1←F(mk, 1|| rid)； K2←F(mk, 2||r)；s←-4. g {0, 1}λ； d← id⊕G(K2, g)； l←F(K1, 1)；5. choose an operation o from list O；6. add tuple (l, d, g, o) to LA；7. encrypt r with sk；8. end for 9. the data owner send LA to the smart contract；10. the smart contract:11. for tuple (l, d, g, o) ∈ LA 12. if o= add 13. add (l, d||g) to γ；14. else 15. d′, g′←Get(γ, l)；16. set d′=d, g′=g；17. update γ with tuple (l, d′||g′)；18. end if 19. end for 20. end

本文所提出的方案主要關注查詢結果的準確性與公平性, 而沒有考慮訪問每條履歷信息更細粒度的權限控制問題, 這可以使用現有的方案來實現, 例如使用ABE (Attribute-Based Encryption)算法來實現更細粒度的訪問控制[20,21].

5 安全分析與實驗仿真

5.1 安全分析

上述方案通過引入區塊鏈與可搜索加密技術以保證人才履歷信息的真實性, 并且對于履歷數據的存儲與共享目標和文獻[8,13]所提出的目標類似, 我們實現了履歷數據在存儲過程中的保密性、數據共享時的公正性和方案的健壯性.

真實性: 履歷數據僅來自于上述模型中的數據擁有者, 由個人或企業直接向相應的驗證方發起認證并獲得履歷數據. 由于在進行履歷驗證的各環節中均需要進行身份認證, 并且數據一旦生成就會在區塊鏈中記錄下來, 減少了全過程的參與方, 實現了履歷數據存儲的去中心化, 降低了履歷造假的可能性, 提升了履歷信息的真實性.

健全性: 顯然在Hyperledger聯盟區塊鏈安全性保證的前提下, 本文所提方案實現了健全性. 因為智能合約代碼直接由Hyperledger聯盟區塊鏈執行, 不受任何第三方的干擾, 同時區塊鏈的共識機制可以確保每個操作的正確執行, 并且執行后的結果會被永久的存儲在鏈上, 鏈上的所有節點都可以驗證數據的有效性.

公平性: 在此前的多方參與數據共享方案中存在的問題是: 如何保證數據擁有者給出正確的數據索引,以及如何確保用戶無法抵賴稱自己沒有收到索引. 針對這兩個問題, 在所提方案中, 當數據擁有者給出數據搜索標識Q時, 需先將其記錄在鏈上集合γD中； 用戶在進行數據搜索之前, 也需要將Q記錄在鏈上集合γU中, 即:

當其中一方試圖抵賴自己之前的操作時, 另一方可以選擇發起請求驗證交易并由智能合約執行以下算法判斷撒謊者, 算法以驗證交易作為輸入, 首先判斷請求者身份:

若交易發起者是數據擁有者, 判斷集合γU中是否存在關于QD的數據, 若存在, 則返回1表示用戶Uj撒謊, 否則返回null表示交易正常.

若交易發起者是用戶, 則判斷集合γD中是否存在關于QU的數據, 若存在, 與QU進行比較, 數據不一致則返回0表示Di撒謊, 否則返回null表示交易正常；若不存在, 則返回0表示Di撒謊.

算法4. Sentence輸入: verify request輸出: 0|1|null 1. if requester ∈D 2. if find QD in γU 3. return 1 4. else 5. return null

6. end if 7. else 8. if find Qu in γD 9. if Qu≠Qu 10. return 0 11. else 12. return null 13. end if 14. else 15. return 0 16. end if 17. end

由于整個算法是由智能合約執行, 由系統的健壯性可知, 鏈上所記錄的數據都是完全正確的, 因此無論是數據擁有者還是用戶, 任何一方提供的錯誤信息都將被發現.

保密性: 為了證明方案的保密性, 我們使用一個在模擬者S和對手A之間的real-ideal模擬游戲來進行證明. 在此之前給出如下3個關于本文方案的狀態泄露函數SL=(SL1,SL2,SL3).

給定初始化輸入R,SL1被定義為初始化狀態泄露函數:

同時它初始化一個空集合L, 一個密文集C, 并將他們進行存儲.

給定一個搜索輸入r,SL2被定義為:

其中,sp(r, L)表示搜索模式. 給定待搜索文檔r, 它將輸出搜索模式sp以及搜索標識Q.

給定一個更新輸入(id,r),SL3被定義為:

其中,ap(i,d,L)表示r關于L的新增模式；up(i,d,L)表示r關于L的更新模式.

定理1. 如果F和G是偽隨機的, 那么本文所提方案針對非自適應攻擊是安全的.

證明: 我們假設S是多項式時間的模擬者, 那么對于任意同樣是多項式時間的對手來說, 真實執行RealA(λ)的輸出和模擬執行的IdealA, S(λ)的輸出在計算上是難以區分的. 模擬器通過給定的泄漏函數SL模仿真實協議來模擬對手的視角. 例如, 為了模擬初始化階段,S首先為每個搜索隨機的選擇k1,k2由搜索模式指定重復的次數. 對于所有的文件,S按真實的初始化階段計算出l,d,g并將每一個鍵值對(l,d||g)加入到集合L中,再隨機的添加m個鍵值對到L中, 并最終創建出一個字典γ′. 類似的,S可以通過泄露函數SL模擬出搜索和更新請求. 因此, 由于F和G的偽隨機性, 我們的定理成立. 特別的, 方案可以通過使用隨機預言機以達到對自適應攻擊的安全性[13,22].

5.2 實驗仿真

為了驗證本文所提方法的安全性及性能, 我們使用了5臺搭載Intel(R) Xeon(R) Gold 6278C CPU, 8 GB RAM, 操作系統為 CentOS 7.6的云服務器作為實驗基礎, 基于開源區塊鏈網絡Hyperledger Fabric 1.4.0, 構建了一個包含3個order節點, 4個peer節點, 使用CouchDB作為WorldState數據庫, 智能合約由Java編寫的區塊鏈網絡作為基礎實驗環境, 使用了搭載Intel core i5-7500 CPU,16 GB RAM, Windows10 (64 bit)的本地主機模擬數據擁有者以及用戶進行所提方案的實驗仿真,同時忽略出塊時間對實驗結果的影響.

由于沒有足夠的履歷信息數據集支撐, 因此本次實驗選擇了由Rajkovic等人[23]建立的Nursery數據集進行實驗. 這是一個包含了12 960條純文本記錄的數據集, 為了滿足方案的條件, 我們為每條數據添加了文件id作為CouchDB數據庫的_id字段, 并且將每條文本下含的8個屬性進行調整以滿足履歷信息的數據格式. 實驗共從3方面進行, 包含了系統的安全性、搜索以及數據更新的性能. 整個方案的初始化階段可視作為更新操作的變體, 因此所需時間的多少可由初始化時具體的數據量估算, 此處沒有進行實驗.

針對方案的安全性, 我們設計了2組測試場景, 并分別對每種測試場景進行了系統安全性測試. 2組測試場景內容如下:

場景1. 未取得授權時數據擁有者以及用戶對區塊鏈的操作.

預期結果: 所有操作均被拒絕.

場景2. 取得區塊鏈系統授權時數據擁有者以及用戶抵賴的情況.

預期結果: 雙方的抵賴操作均被發現.

通過對場景1和場景2各進行100次實驗, 實驗結果表明, 參與者在未取得授權的情況下, 在系統模型的健全性以及Hyperledger Fabric網絡本身安全性的保證下, 所有的異常數據操作都被拒絕. 同時, 當取得授權的雙方在對區塊鏈做數據查詢時, 在系統公平性的保證下, 如果是數據擁有者提供錯誤的數據索引給用戶, 在出現異常時通過對鏈上存儲的數據索引進行檢驗即可發現錯誤的數據索引項； 如果用戶收到正確的數據索引卻意圖抵賴, 此時存在兩種情況: 一是用戶不進行數據查詢操作, 那么即使他獲得了數據索引也無法獲得任何的原始數據信息. 二是用戶進行數據查詢,除非使用正確的數據索引進行搜索, 否則仍舊無法獲得任何信息, 而一旦使用正確的信息進行搜索, 此過程將被區塊鏈系統記錄下來, 即用戶無法對此過程進行抵賴.

下面對本文所提方案的性能進行評估. 本文所提方案的時間開銷主要分為兩種類型: 搜索和更新操作的時間開銷. 其中搜索的時間開銷主要包含兩部分, 即實際數據搜索時間以及將數據標識Q上鏈備份的時間, 如圖2中曲線x所示, 當用戶首次向服務器發起查詢數據請求時, 由于用戶需要與區塊鏈網絡之間建立連接, 因此需要花費更多的時間. 更新操作所需時間僅包含在新塊中更新賬本狀態的時間, 因此整體消耗時間比數據搜索操作更低一些, 如圖2中曲線y所示.

圖2 方案時間開銷

根據上述實驗表明, 本文提出的基于區塊鏈的可搜索加密人才履歷共享方案, 在數據搜索方面和文獻[8,13]所提方案的搜索性能相比, 由于方案具備更加嚴格的搜索控制, 因而增加了部分開銷. 但在數據更新方面,由于本方案在數據更新時不需要做額外的狀態判斷,因此數據更新性能要優于文獻[13], 提升了對數據的更新效率.

下面將本文提出的方案與現有方案進行比較. 表2將從方案的查詢模式、查詢內容、是否支持對數據的動態更新等方面與其他方案進行對比.

表2 本方案與其他方案對比

Chen等人[8]提出的方案主要是針對電子病歷共享. 方案采用范圍查詢對位于鏈上的病歷數據進行搜索, 因而在數據量較少時擁有最快的搜索效率, 但是方案卻不支持對數據的動態更新, 導致方案的通用性較差.

Hu等人[13]提出的信息共享方案支持對通用數據的信息共享. 方案對鏈上數據進行單關鍵字搜索, 因此在搜索文本的數量較多時搜索性能會趨近于一個穩定值； 同時方案還支持對數據的動態更新, 但是更新操作的開銷遠大于搜索操作開銷, 并且在多方參與時需進行額外調整以滿足多方之間的搜索公平性.

本文提出的信息共享方案主要是針對履歷信息進行共享, 方案通過對具體數據的搜索以實現查詢特定履歷數據的目的. 方案滿足在履歷數據發生變更時的數據動態更新操作, 并取締了數據更新時在區塊鏈上判斷的過程, 提升了數據更新效率. 同時, 利用智能合約執行結果的正確性保證了在數據分享過程中雙方之間的公平性與結果正確性.

6 總結

本文基于區塊鏈與可搜索加密技術對傳統人才履歷存證中存在的數據管理中心化、履歷造假等問題提出了一個新的解決方案. 方案利用區塊鏈取代傳統第三方機構, 結合鏈上鏈下協同存儲機制保證了履歷數據的真實性, 并基于可搜索加密技術實現了參與方之間的公平性與數據存儲、更新時的隱私保護. 通過對方案的安全性及性能進行分析與實驗, 表明方案在支持人才履歷共享的同時也滿足隱私需求以及擁有足夠的系統性能, 但同時對于惡意參與者的懲罰細節還有待進一步完善.