一種監管友好的可編輯區塊鏈方案

摘 要：現有區塊鏈內容監管方案均采用事后治理方式，缺乏事前審計，且存在簽名失效和多版本區塊驗證效率低的問題。針對這些問題，首先，設計了一種可動態調整可追責的數據審計方法，實現了對區塊鏈交易數據的事前審計；其次，設計了一種編輯可控的數字簽名方案RCDSS（redaction－controlled digital signature scheme），解決了因編輯操作造成的簽名失效問題；最后，設計了一種區塊鏈數據一致性驗證協議，實現了對查詢結果的高效驗證。安全分析和性能測試結果表明了其安全性和有效性。該方案在實現監管可控的情況下，仍然保持了較高的區塊生成和驗證效率，為區塊鏈內容監管提供了一種新的解決思路。

關鍵詞：區塊鏈； 監管； 審計； 可編輯； 數據一致性

中圖分類號：TP311文獻標志碼： A文章編號：1001－3695（2024）04－003－0981－08

doi：10.19734/j.issn.1001－3695.2023.07.0339

Regulatory－friendly redactable blockchain solution

Yu Wangnian Zhao He Tan Haibo Cheng Haotian Zhao Yue Ma Zhiyu1，2

Abstract：Existing blockchain content supervision schemes adopt ex－post governance methods，lack of pre－audit，and have problems of signature invalidity and low efficiency of multi－version block verification.To address these problems，firstly，this paper designed a dynamically adjustable and accountable data audit method to realize prior audit of blockchain transaction data.Secondly，it designed a redaction－controlled digital signature scheme to solve the problem of signature invalidity caused by editing operations.Finally，it designed a blockchain data consistency verification protocol to achieve efficient verification of query results.The results of security analysis and performance testing demonstrate the security and effectiveness of the scheme.In the case of controllable supervision，the scheme still maintains high efficiency in block generation and verification，and it provides a new solution for blockchain content supervision.

Key words：blockchain； supervision； auditing； redactable； data consistency

0 引言

區塊鏈監管一直存在著挑戰性［1，2］。作為公開透明的賬本，用戶可以在鏈上存儲任意數據［3～5］，但這種功能已經被濫用。研究者們在比特幣上已發現敏感信息和違法數據，例如虐待兒童的內容和色情圖像［6～8］等，區塊鏈內容的合法性受到破壞［9］。許多國家針對區塊鏈的監管表明了態度。文獻［10］規定，對于法律法規禁止的內容，在其發布、傳播過程中要進行過濾和阻斷，對已經存儲在區塊鏈上的違法內容，在不破壞區塊鏈數據完整性的前提下，允許編輯此類數據。歐盟出臺規定［11］：用戶具有“被遺忘權”，即用戶可以要求服務商刪除網絡中關于自己的隱私數據。此外，因為用戶疏忽而導致錯誤數據上鏈，也需要刪除鏈上錯誤的數據［12，13］。因此，設計一種滿足監管要求的區塊鏈方案是十分必要的。

任艷麗等人［14］提出了基于門限環簽名的區塊鏈編輯方案，但方案依賴共識機制PoSpace的區塊鏈結構。Deuber等人［15］提出了基于鏈上投票的區塊鏈編輯方案，該方案不依賴于復雜的密碼學工具，但效率很低。Ateniese等人［16］將變色龍哈希函數引入到區塊鏈中，實現編輯操作，但變色龍哈希函數陷門由單一機構保存，編輯權過于集中。Camenisch等人［17］提出了一個具有臨時陷門的變色龍哈希函數CHET，只有同時知道主陷門和某個哈希值的臨時陷門才可以進行編輯操作，從而分散編輯權。部分研究者通過秘密共享技術將陷門碎片分發給多個參與者，只有超過閾值的參與者同意后才可以進行編輯操作［18，19］。Derler等人［20］將基于密文策略屬性的加密CP－ABE與CHET結合，設計一個基于策略的變色龍哈希函數PCH，當編輯者的屬性滿足一定策略時才可以進行編輯操作，但屬性的分發權由單一機構控制。Ma等人［21］將屬性的分發權從單一機構轉為多個機構。然而CP－ABE機制無法實現問責，Tian等人［22］進一步擴展了具有問責性的基于策略的變色龍哈希函數。Li等人［23］提出一個k次可控編輯的方案，監管方可以設置每個編輯者的編輯次數，且有權撤銷編輯者的編輯權限。

然而，上述方案采用事后治理的方式，導致監管滯后，并不能較好地滿足監管要求，并存在以下問題：

a）數據在上鏈之前缺乏對內容的監管審計。區塊鏈節點驗證交易時并不會檢查payload中附帶信息的合規性，并且缺乏對審計行為的有效激勵。這會造成節點僅為爭取共識獎勵與交易手續費而將一些可能包含違法數據的交易打包成區塊并持久化存儲，造成難以消除的不良影響。

b）數據編輯導致交易驗簽失效，使得監管受阻。對已經存儲在鏈上的違法或錯誤數據，需要采用編輯技術刪除或修改。為了不破壞每個賬戶中交易的可追溯性，僅對交易附帶的違法或錯誤數據進行編輯，這會造成交易中原有簽名驗證不通過。

c）數據編輯導致鏈上數據一致性驗證難度增加，破壞監管有效性。編輯后同一高度的區塊可能存在多個版本，且每個版本都可以通過一致性驗證，惡意節點可能保存多個版本。當用戶向區塊鏈請求數據時，惡意節點會將舊版本發送給用戶，用戶無法判別收到的內容是否為編輯后的最新版本。舊版本區塊數據中包含違法內容，惡意節點在數據同步時將其傳輸給新加入的區塊鏈節點，導致已經被刪除的違法內容再次被傳播和存儲，破壞監管有效性。

針對問題a），若完全由一個單一的監管方執行審計任務，則該部分可能會成為系統的性能瓶頸。若由普通的區塊鏈節點審計，可能存在惡意節點拒絕審計，或節點間互不信任，同一數據會被多次審計，浪費計算資源。為此，本文引入審計節點這一角色，將審計任務落到多個審計節點，降低審計過程對系統性能的影響，同時利用代理簽名實現對每個審計節點的授權和追責，并設置審計獎勵，激勵審計節點誠實執行審計任務。

針對問題b），若用戶主動配合監管，并重新生成一個新簽名，則可以解決上述問題。但當用戶拒絕配合監管時，依然會使交易驗簽失敗。為此，本文利用變色龍哈希函數的陷門碰撞性和普通哈希函數的抗碰撞性，在實現對交易中部分內容可控編輯的同時，保證交易的簽名一直有效。

針對問題c），本文利用智能合約記錄每個區塊的更新歷史，用戶利用智能合約可以對查詢結果進行驗證，節點同時會返回一個與查詢結果相關的承諾，通過承諾可以判斷節點是否提供了舊版本數據，從而降低節點作惡的可能性。

綜上，本文提出了一種監管友好的可編輯區塊鏈方案，主要工作內容如下：

a）設計了一種可動態調整、可追責的數據審計方法。監管方通過代理簽名將審計權分發給多個審計節點，減輕審計壓力，提高審計效率和系統穩定性。

b）設計了一種編輯可控的數字簽名方案RCDSS，并且設計了與之對應的區塊結構和交易結構。用戶不配合監管時，對于數據的編輯不會影響交易簽名的驗證結果。

c）基于智能合約和原生哈希設計了一種區塊鏈數據一致性驗證協議，數據請求方可以對查詢的結果進行數據一致性驗證。此外，通過數據一致性承諾DCCom可以定位到作惡的數據提供方，并進行懲罰，從而降低數據提供方作惡的可能性。

1 預備知識

1.1 區塊鏈

本文參考文獻［19，24］，給出區塊鏈的形式化定義：假設區塊鏈CN由N個區塊前后連接組成，區塊Bi=（preHi，xi，ctri，ri），i∈［0，N］，B0表示創世區塊，BN表示區塊鏈的頭，即最新區塊，preHi∈{0，1}K表示前一個區塊哈希值，長度為K個比特位，xi∈{0，1}表示當前區塊的區塊體內容，即交易列表，ctri∈N表示該區塊的共識隨機數，ri表示生成區塊哈希值過程中，變色龍哈希函數用到的隨機數。

區塊Bi有效，應當滿足等式（H（ctri，G（preHi，xi，ri））lt;D）∩（ctrilt; q）=1，H：{0，1}→{0，1}K和G：{0，1}→{0，1}K分別為外部哈希函數和內部哈希函數，D∈N為區塊難度，q∈N為每輪共識過程中哈希查詢的最大次數。

1.2 變色龍哈希函數

變色龍哈希函數由四個子算法組成［16］，具體描述如下：

a）（hk，tk）=CH_Gen（1λ）。密鑰生成算法，輸入安全參數λ，輸出變色龍哈希函數的公鑰hk（public hash key）和私鑰tk（secret trapdoor key），私鑰tk也叫作陷門。

b）h=CH_Hash（hk，m，r）。哈希值生成算法，輸入公鑰hk、消息m和隨機數r，輸出哈希值h。

c）d=CH_Ver（hk，m，h，r）。哈希值驗證算法，輸入公鑰hk、消息m、哈希值h和隨機數r，輸出一個比特d，如果h=CH_Hash（hk，m，r），則d=1，否則d=0。

d）r′=CH_Col（tk，m，r，m′）。哈希值碰撞生成算法，輸入私鑰tk、原消息m、原消息m的隨機數r和一個新消息m′，返回一個新的隨機數r′，使得CH_Hash（hk，m，r）= CH_Hash（hk，m′，r′）=h。

2 系統模型

2.1 系統架構

本文的系統架構如圖1所示，主要由數據所有者、監管方、審計節點、數據請求方、數據提供方、普通節點六種角色以及智能合約組成。

a）數據所有者：區塊鏈系統中的用戶，利用區塊鏈存儲自己的數據。

b）監管方：由監管部門（政府）組成的一個監管委員會，是完全可信的，負責審計節點的選擇、 節點行為的激勵和懲罰、哈希碰撞的生成。在系統初始化的時候，負責變色龍哈希函數的初始化并保存陷門tk。監管方在區塊鏈中的操作是公開透明且記錄在區塊鏈上，系統中的所有參與者都可以對監管方進行監管。

c）審計節點：負責對上鏈的數據進行審計、對其他審計節點進行監管。如圖2所示，普通節點通過繳納押金的方式向監管方提交申請，監管方基于每個節點繳納的押金和歷史行為進行審計可靠性評估并排序，前t個節點組成審計節點，監管方可以根據網絡中交易吞吐量動態調整t值。節點審計可靠性評估模型EM不是本文的研究重點，下面給出一個簡化的模型以幫助對文章的理解。節點審計可靠性評估模型EM：reliability=（deposit×α+honesty×β）。α和β為權重系數，deposit為節點繳納的押金，滿足depositmax≥deposit≥depositmingt;0，depositmax和depositmin分別為押金最大值和最小值，honesty為節點的誠實度，滿足0≥honesty≥honestyt，honestyt為參與競選審計節點的誠實度閾值，且honesty與節點的審計數量無關，與節點的審計質量有關，當節點作惡時，honesty將降低。

d）數據請求方：區塊鏈系統中的用戶或輕節點（由于資源受限不能存儲完整的區塊鏈數據）或新加入系統的節點，對鏈上數據發起查詢或同步請求，并對查詢的結果進行一致性驗證。

e）數據提供方：區塊鏈系統中的一些全節點，存儲完整的區塊鏈數據，能提供數據查詢和同步服務。

f）普通節點：包含全節點和輕節點，全節點具有完整的賬本數據，輕節點具有部分賬本數據。

g）智能合約：由監管方部署的一個一致性驗證合約CVContract（consistency verification contract）。合約存儲了鏈上每個區塊的一致性證明，可以提供鏈上數據一致性驗證服務。合約狀態更新操作由監管方執行，用戶和所有節點可以執行合約的狀態查詢操作。

2.2 編輯可控的數字簽名方案RCDSS

2.2.1 算法介紹

為了解決交易中部分數據被編輯后造成驗簽失效而導致監管受阻的問題，對原有數字簽名算法進行改進，提出一種編輯可控的數字簽名方案RCDSS。主要思想是將被簽名的消息m劃分為不可變部分m1和可變部分m2，即m=（m1，m2）。在對消息m進行簽名時，利用普通哈希函數對m1計算哈希值h1，利用變色龍哈希函數對m2計算哈希值h2，再對（h1，h2）進行簽名。通過這種方式，當m2發生改變時，可以利用變色龍哈希函數的陷門碰撞特性［25］保證消息m的簽名依舊有效。編輯可控的數字簽名方案RCDSS主要包含四個子算法，下面給出具體描述：

a）（pk，sk）=Gen（1λ）。密鑰生成算法，輸入安全參數λ，輸出公鑰pk和私鑰sk。

b）σ=RC_Sign（sk，m1，m2，hk，r）。簽名生成算法，輸入私鑰sk、消息對（m1，m2）、變色龍哈希公鑰hk和隨機數r，輸出sk關于消息對（m1，m2）的簽名σ=Sign（sk，（h1，h2）），其中，h1=Hash（m1），h2=CH_Hash（hk，m2，r），m1為不可變部分，m2為可變部分，h1為m1通過普通哈希函數計算得到的哈希值，h2為m2通過變色龍哈希函數計算得到的哈希值，Sign（）為普通的數字簽名算法的子算法，本文使用的是ECDSA簽名算法的子算法。

c）d=RC_Verify（pk，m1，m2，σ，r，hk）。簽名驗證算法，輸入公鑰pk、消息對（m1，m2）、簽名σ、隨機數r和變色龍哈希公鑰hk，輸出一個比特d，如果σ為公鑰pk的私鑰sk在消息對（m1，m2）上的一個簽名，則簽名驗證通過，d=1，否則簽名驗證不通過，d=0，即d=Verify（pk，（h1，h2）， σ），h1=Hash（m1），h2=CH_Hash（hk，m2，r），Verify（）為普通的數字簽名算法的子算法，本文使用的是ECDSA簽名算法的子算法。

d）r′=RC_RedactSign（pk，m1，m2，σ，r，m2′，tk），簽名可控編輯算法，輸入公鑰pk、消息對（m1，m2）、簽名σ，隨機數r、新消息消息m2′和變色龍哈希陷門tk，輸出簽名σ的一個新的隨機數r′，使得RC_Verify（pk，m1，m2′，σ，r′，hk）=1，即使得等式CH_Hash（hk，m2，r）= CH_Hash（hk，m2′，r′）成立。

2.2.2 算法分析

a）可編輯性與可控性：在保證簽名σ有效性不變的情況下，利用變色龍哈希函數的性質，可以且僅可以修改m2。

b）安全性：由RCDSS簽名生成過程可知，RCDSS簽名方案的安全性由現有的數字簽名的安全性來保證。RCDSS簽名算法僅改變消息m到哈希值h之間的映射關系，并沒有改變哈希值h到簽名σ之間的映射關系，因此RCDSS的安全性由其底層采用的數字簽名算法的安全性來保證，例如基于ECDSA的RCDSS的安全性由ECDSA的安全性來保證，ECDSA的安全性已經在文獻[26]中討論過，此處不再贅述。

2.3 數據結構

為了實現對區塊中數據內容的監管，本文對區塊結構和交易結構進行重新設計。區塊結構如表1所示，交易結構如表2所示。

在區塊頭中增加兩個新的字段bl_r和natHash，分別存儲該區塊的變色龍哈希函數的隨機數和原生哈希，區塊Bi的哈希值hi=Hash（CHi，noncei），CHi=CH_Hash（hk，（preHashi，timestamp，rooti），bl_ri），原生哈希natHashi=Hash（preHashi，timestamp，rooti，noncei，bl_ri）。在區塊內容編輯過程中，區塊的哈希值hi保持不變，區塊的原生哈希值natHashi會發生變化。區塊鏈的哈希鏈的前后連接由區塊的哈希值hi來保證，區塊鏈的數據一致性由區塊的原生哈希值natHashi來保證。

auditorNum為負責審計這個交易的審計節點編號，審計節點的編號由監管方確定，且全局可見，簽名signature=RC_Sign（sk，m1，m2，hk，tx_r），m1=（from，to，value，auditorNum），m2=data。

2.4 安全需求

a）上鏈數據審計不可逃避性：數據上鏈前需要被審計，且審計過程不可逃避。

b）鏈上違法或錯誤數據可擦除性：已經上鏈的數據變成違法或錯誤數據后，此類數據能夠被順利擦除且不影響區塊鏈的完整性。

c）鏈上數據不可偽造性：攻擊者在不知道變色龍哈希陷門的情況下，無法偽造鏈上數據。

d）鏈上數據一致性可驗證性：數據請求方對鏈上數據進行查詢或同步時，可以對得到的數據進行一致性驗證。

e）節點作惡可追責性：在數據上鏈審計過程中和鏈上數據查詢過程中，節點作惡行為不可抵賴、可追責。

3 監管友好的可編輯區塊鏈方案

3.1 系統初始化階段

該階段可以劃分為監管方初始化、普通節點和用戶初始化。

1）監管方初始化 監管方選擇安全參數λ，通過運行CH_Gen（1λ）和Gen（1λ）得到（hk，tk）和（rpk，rsk），hk和tk分別為變色龍哈希函數的公鑰和陷門，rpk和rsk分別為監管方的公鑰和私鑰，監管方將hk、rpk廣播到全網。監管方也可以使用安全多方計算（secure multi－party computation，SMPC），讓多個監管成員協作生成公鑰hk和哈希碰撞，保證陷門tk在整個過程中從未被生成，避免陷門丟失和泄露。

2）普通節點和用戶初始化 普通節點和用戶在本地選擇隨機數λ，通過運行Gen（1λ）得到自己的公鑰pk和sk。用戶僅在生成交易時采用RCDSS簽名方案。

3.2 審計節點選取與激勵

審計節點是從普通節點中選出，監管方可以根據當前網絡中交易吞吐量動態調整審計節點數量。 普通節點nodei向監管方提交申請applayi=（pki，depositi），pki為節點nodei的公鑰， depositi為押金。收到多個申請后，監管方生成審計節點申請集合Φapplay={applay1，…，applayn}，通過節點審計可靠性評估模型EM，計算得到節點審計可靠性集合Φreliability={reliability1，…，reliabilityn}，集合Φreliability的前t個節點為審計節點。監管方基于 每個審計節點的公鑰pki生成授權內容Wi=（pki，timei，auditorNumi，quota），timei為節點nodei被授權進行審計的有效時間，auditorNumi是節點nodei被分配的全局唯一的審計編號，quota為節點nodei的審計額度，監管方根據網絡中歷史交易流量動態調整quota值，并用私鑰rsk對Wi進行簽名得到簽名σWi，最終生成t個審計節點的授權信息集合ΦauthorizeInfor={（W1，σW1），…，（Wt，σWt）}，并將ΦauthorizeInfor廣播到整個網絡中。

當系統時間超過timei或其審計額度用完時，節點nodei將重新變成普通節點，并進入一個冷卻期。在冷卻期中，節點nodei不能參與審計節點的競選。監管方將根據節點nodei的審計的交易數量、審計的有效性來計算報酬，并將押金和報酬返回給節點nodei，如果節點nodei存在作惡行為，全網節點和用戶可以對節點nodei進行舉報，監管方將扣除其押金、降低其可信度。

3.3 數據審計和上鏈階段

審計節點在數據上鏈之前對數據進行審計，審計節點可以利用人工智能和自然語言處理技術對數據進行審計。數據審計和上鏈流程如圖3所示，流程詳細敘述如下：

a）用戶在本地生成交易tx=（from，to，value，data，auditorNum，tx_r，signature），其中auditorNum為負責審計該交易tx的審計節點的編號，用戶在生成交易時，選擇剩余審計額度多且審計速度不為0的審計節點。

b）用戶通過區塊鏈網絡廣播tx。

c）審計節點i（審計編號為i）收到交易tx，通過auditorNum值判斷這筆交易是否由自己審計，如果是，則對交易的data進行審計。

d）審計通過后，審計節點為交易tx生成一個合法性證明proofOL=Sign（ski，tx），ski為審計節點i的私鑰。

e）審計節點i將tx和proofOL廣播到全網中。

f）全網節點收到tx和proofOL后進行驗證，驗證通過則將tx通過全網共識上鏈。

g）全網節點向用戶返回交易tx成功上鏈的信息。

3.4 鏈上數據編輯階段

鏈上數據編輯包括用戶主動請求編輯和監管方主動編輯。用戶在數據上鏈的時候，由于數據采集或傳輸的疏忽而導致錯誤數據上鏈，數據的所有者發現錯誤后可以向監管方提交編輯請求以修正鏈上錯誤數據。當其他用戶向監管方舉報鏈上存在違法數據或者監管方自己發現鏈上存在違法數據時，監管方可以主動發起編輯，隱藏或刪除此類數據。

3.4.1 用戶主動請求編輯

用戶主動發起請求編輯的過程如圖4所示，過程詳細敘述如下：

a）用戶在本地生成編輯請求EditRequest，具體過程如下：

（a）找到需要編輯的數據所在區塊的區塊號blockNum和交易tx。

（b）計算tx的哈希值oldTxHash=Hash（tx）。

（c）將tx中data換成新的內容newData形成新交易newTX ， 并計算newTX的變色龍哈希隨機數newTX_R和簽名newSignature （使用RCDSS簽名方案）。

（d）生成編輯請求EditRequest=（ERContent，ERSignature）， ERContent=（oldTxHash，blockNum，newData，newTX_R，newSignature）， ERSignature=Sign（sk，ERContent），sk為用戶的私鑰。

b）用戶廣播編輯請求EditRequest。

c）監管方收到編輯請求EditRequest并審計通過后，為新的交易newTx生成一個合法性證明proofOL=Sign（rsk，newTx）、目標區塊blockNum的新的變色龍哈希隨機數newBL_R和新的原生哈希newNatHash。

d）監管方將EditRequest、proofOL、newBL_R、newNatHash廣播到全網中。

e）節點收到EditRequest、proofOL、newBL_R、newNatHash后進行驗證，驗證通過則將它們存儲在本地數據庫并更新本地賬本數據。

f）節點完成更新后，向監管方發送更新成功信息。

g）當大部分節點完成更新后，監管方調用一致性驗證智能合約CVContract更新區塊blockNum的一致性證明proofOC=（natHashblockNum）。

h）智能合約CVContract更新成功后向監管方返回更新成功信息。

i）監管方返回編輯成功信息給用戶。

當用戶發起惡意的數據編輯請求時，將會被全網節點加入黑名單，黑名單上的用戶發起的交易將不被審計和打包上鏈，除非繳納相應罰款。因為用戶發起的數據編輯請求中包含一個請求簽名，所以用戶的惡意請求行為不可偽造、不可抵賴。

3.4.2 監管方主動編輯與用戶申訴

監管方主動發起編輯的過程與用戶主動發起編輯的過程相似，主要區別在于編輯請求EditRequest和新的內容newData的生成方式不同。下面具體介紹EditRequest和newData的生成過程，其余過程不再贅述。

a）監管方找到目標數據所在區塊的區塊號blockNum和交易tx=（from，to，value，data，auditorNum，tx_r，signature）。

b）計算tx的哈希值oldTxHash=Hash（tx）。

c）將tx中data內容更改為新的內容newData=encrypt（rpk，data）+被編輯的原因，并計算交易新的變色龍哈希隨機數newTX_R=CH_Col（tk，data，tx_r，newData）。

d）監管方生成一個編輯請求EditRequest=（ERContent，ERSignature），ERContent=（oldTxHash，blockNum，newData，newTX_R，signature）， ERSignature=Sign（rsk，ERContent），rsk為監管方私鑰。

監管方出于監管要求，對某個交易tx進行編輯，將tx內的數據換成原始數據的密文和被編輯的原因，當用戶對監管方的編輯存在質疑時，用戶可以向監管方進行申訴。

監管方收到用戶的申訴后會進行判斷，如果申訴通過，監管方將用戶的數據進行恢復，過程與上述編輯過程類似，不再贅述，否則，返回用戶申訴不通過的信息。

3.5 鏈上數據查詢和一致性驗證

當數據請求方（用戶、輕節點、新加入區塊鏈網絡的節點）對鏈上數據進行查詢或同步時，會向區塊鏈中的數據提供方（全節點）請求賬本數據。由于數據所有者和監管方可能對鏈上數據進行了編輯，所以區塊鏈的一致性不能由區塊哈希值的唯一性來保證，本文方案利用智能合約和區塊原生哈希來保證區塊鏈數據的一致性。以區塊查詢為例，過程如圖5所示，具體描述如下：

a）數據請求方生成一個區塊查詢請求blockQuery=（heighti，hi），heighti和hi分別為所要查詢的目標區塊Bi的區塊高度和區塊哈希。

b）數據請求方廣播區塊查詢請求blockQuery。

c）數據提供方收到blockQuery后，根據blockQuery定位到目標區塊Bi=（preHashi，timestamp，rooti，bl_ri，noncei，natHashi，transactions），并生成Bi的數據一致性承諾DCCom=Sign（sk，（natHashi，time）），其中sk為數據提供方的私鑰，time為當前系統時間。

d）數據提供方返回Bi和DCCom。

e）數據請求方收到Bi和DCCom后，調用區塊鏈上的智能合約CVContract，獲取目標區塊Bi的一致性證明。

f）CVContract返回目標區塊Bi的一致性證明proofOC。

g）數據請求方收到proofOC后，進行一致性驗證，具體過程如下：

（a）從Bi中提取區塊的原生哈希natHashi。

（b）比較等式proofOC=natHashi是否成立。若成立，則數據是可信的；若不成立，則數據是不可信的，將區塊Bi的一致性證明proofOC、區塊查詢請求blockQuery和數據一致性承諾DCCom發給監管方，對數據提供方進行追責。

監管方收到數據提供方發送的proofOC、blockQuery和DCCom后，會根據DCCom中的時間time，通過智能合約查詢到區塊Bi在時間time時的一致性證明proofOC′，如果natHashi=proofOC′，則說明數據請求方從數據提供方獲取區塊Bi后，區塊Bi的數據發生編輯更新，數據提供方沒有作惡，否則數據提供方作惡了，監管方根據DCCom定位到作惡的數據提供方并追責。同時，為了防止用戶惡意請求干擾數據提供方正常運行，數據提供方對用戶請求頻率進行適當限制。

4 安全性分析

根據2.4節所述的5項安全需求，本章對監管友好的可編輯區塊鏈方案展開分析。

a） 上鏈數據審計不可逃避性。交易tx（包含數據）在上鏈之前會被審計，審計通過的交易才會被生成一個相應的合法性證明proofOL，節點收到tx和proofOL才會進行驗證，驗證通過的交易才可以被上鏈。在本文的合法性證明的生成和驗證過程中，使用的簽名算法SIG=（Gen，Sign，Verify）是以太坊中的ECDSA簽名算法。假設存在一個概率多項式（probabilistic po－lynomial time，PPT）敵手Euclid Math OneAAp，在不持有私鑰sk的情況下，可以為交易tx生成一個合法性證明proofOL′，使得等式Verify（pk，tx，proofOL′）=1成立。而ECDSA簽名算法是基于橢圓曲線離散對數問題（elliptic curve discrete logarithm problem，ECDLP），且在橢圓曲線上定義的離散對數問題比在有限域上定義的傳統離散對數問題更難解決［27，28］，所以上述假設不成立，即數據在上鏈之前無法逃避審計。

b）鏈上違法等數據可擦除性。本文方案中，在交易簽名和區塊哈希的生成過程中使用了變色龍哈希函數，變色龍哈希函數具有陷門碰撞性，即在持有陷門tk的前提下，對于任意消息m、隨機數r，給定消息m′，可以計算出r′=CH_Col（tk，m，r，m′），使得CH_Hash（hk，m，r）=CH_Hash（hk，m′，r′）。監管方持有陷門tk，且交易簽名采用RCDSS簽名方案生成，因此在保證區塊鏈完整性和有效性的前提下，可以對鏈上違法內容等數據進行擦除。

c）鏈上數據不可偽造性。想要成功偽造鏈上數據，攻擊者Euclid Math OneAAp要保證偽造后的數據不會改變區塊原有的哈希值。在本文中，區塊哈希值計算過程中用到外部哈希函數H和內部哈希函數G，H是普通哈希函數，G是變色龍哈希函數，區塊哈希值h=H（ctri，G（preHi，xi，ri）），變色龍哈希函數具有抗碰撞性，即在不知道陷門tk的前提下，攻擊者Euclid Math OneAAp找到變色龍哈希碰撞的難度與找到普通哈希函數碰撞的難度相當，在計算上不可行。

d）鏈上數據一致性可驗證性。當從數據提供方獲取到數據后，數據請求方可以調用一致性驗證智能合約CVContract獲取目標區塊的一致性證明proofOC，對數據進行一致性驗證，CVContract的狀態由可信的監管方進行維護。

e）節點作惡可追責性。

（a）審計節點作惡。審計節點是普通節點向監管方申請，并由監管方確定的。每個審計節點會受到監管方、普通節點和其他審計節點的監督。理性的審計節點會認真執行審計并獲得相應收益，如果某個審計節點進行低效或無效審計，監管方可以根據交易上的審計節點編號auditorNum追蹤到該審計節點并進行追責。

（b）數據提供方作惡。數據請求方在對收到的區塊Bi進行一致性驗證時，如果發現數據提供方作惡（提供包含違法內容等數據的舊版本區塊），數據請求方可以將Bi的數據一致性承諾DCCom發送給監管方，監管方根據DCCom可以定位到作惡的數據提供方，并進行追責。

5 實驗與評估

為了說明本文方案的有效性和可行性，即評估引入本文設計的監管方案后，對整個方案性能的影響，實現了基于本文方案的區塊鏈內容監管平臺原型系統，如圖6所示。

本文對系統的關鍵階段進行測試，包括RCDSS各階段時間、區塊生成時間、編輯時間和一致性驗證時間，并與現有方案進行對比。實驗平臺基于Windows 10系統的 Intel CoreTM i7－9750H CPU@2.60 GHz、6核處理器和16 GB RAM，使用go語言進行測試。 在實驗中，對以太坊近一年的數據進行隨機采樣，得出平均每個區塊包含165筆交易，且區塊包含的交易數主要在100～500。

5.1 功能對比

如表3所示，將本文方案與現有方案從編輯方式、數據上鏈審計、編輯后交易簽名驗證、一致性驗證、節點作惡追責和監管友好方面進行比較。

方案1［15］支持對鏈上違法等數據進行刪除和修改，編輯操作由系統中節點投票來表決，系統大多數節點同意后就執行編輯操作，且投票記錄保存在鏈上。

方案2［18］支持對鏈上違法等數據進行刪除和修改，編輯操作由系統中的權限節點來決定，每個權限節點保存變色龍哈希陷門的秘密碎片，當某個權限節點收集到一定閾值的秘密碎片即可恢復陷門并執行編輯操作。

方案3［19］以追加的方式對鏈上數據進行編輯，通過MPC技術，讓系統所有節點協同完成編輯，思想上與方案2類似，并試圖通過RSA累加器來提供有效的鏈上數據一致性檢查，但并不能保證惡意節點保存多種RSA累加器狀態進行作惡。同時，該方案不支持刪除或修改，違法內容等數據依舊保存在鏈上，不符合監管要求，后面將不與其進行性能對比。

本文方案 設計一個監管友好的可編輯區塊鏈模型，通過代理簽名，監管方可以選取并授權審計節點對上鏈的數據進行審計，對于惡意用戶不配合編輯的情況，通過RCDSS簽名方案和變色龍哈希函數，在保證鏈的完整性的前提下，監管方可以編輯違法內容等數據，并為用戶提供申訴恢復數據的機會，通過智能合約和區塊原生哈希，用戶可以對查詢結果進行有效的一致性驗證。同時，對節點的作惡行為可以進行定位和追責。

5.2 性能分析

5.2.1 簽名算法各階段時間

本文為了解決編輯后驗簽失效導致編輯受阻問題，將交易的簽名算法換成本文提出的RCDSS，方案1和2采用的是普通的ECDSA簽名算法。為了全面比較兩種簽名算法的性能，下面從算法的各個階段進行對比。

從圖7可以看出，在Gen階段，兩種算法時間相同，在Sign、Verify階段，RCDSS的時間比ECDSA的時間多，RedactSign是RCDSS獨有的階段。因為初始化方式一樣，且RCDSS在Sign、Verify階段進行了額外的變色龍哈希計算，所以上述結果符合預期。總體上，兩者各階段的時間都是微秒級別，性能幾乎一樣。

5.2.2 區塊生成時間

方案1、2和本文方案為了使得編輯操作不破壞區塊之間的連接，對區塊的生成方式進行修改。下面將對比三種方案的區塊生成時間，為了有效比較三種方案的區塊生成時間，將共識難度設置為0。

從圖8可以看出，方案1的時間最少，方案2的時間最多，本文方案的時間略高于方案1，且隨著區塊內交易數量增加，三者時間都在增加，其中方案2增長最多。因為方案1僅僅在區塊頭中增加一個舊態oldState字段，并沒有用到復雜的密碼學工具，方案2在區塊生成過程中利用變色龍哈希函數對每個交易計算哈希值， 本文方案在區塊生成過程中僅用變色龍哈希函數來計算區塊哈希值，且變色龍哈希函數相比普通哈希函數，其進行的指數運算更多，時間更長。總體上，本文方案與方案1的區塊生成時間相近，方案2的區塊生成時間最長。

5.2.3 編輯時間

為了評估編輯效率，對方案1、2和本文方案進行實驗，實驗過程中忽略網絡延遲。

在方案1中，一個節點提出編輯請求，其他節點通過將編輯請求的哈希值包含在自己生成的區塊中來進行投票，因此一個區塊代表一個投票。筆者調整了編輯請求提出之后進行投票的區塊數。從圖9可知，編輯時間隨著投票數的增加而增加，在實際過程中編輯的時間會更長，因為每個區塊的生成具有時間間隔（以太坊約15 s，比特幣約10 min）。

在方案2中，一個權限節點node提出編輯請求，其他權限節點同意后將自己的陷門碎片發給node，node收集到足夠陷門碎片即可恢復陷門并執行編輯操作。本文方案包括用戶主動請求編輯和監管方主動編輯兩種方式，兩種方式的主要區別在與編輯請求和新數據的生成方式不同，后者進行的操作較復雜，兩者每次編輯都需要生成新的區塊原生哈希值，時間會較長。如圖10所示，方案2編輯時間較短，且與區塊內交易數無關，本文兩種編輯方式的時間較長，且隨著區塊內交易數增加而增加。

綜上所述，方案1的編輯時間最長，且在實際中會受到區塊生成的間隔時間影響，將編輯時間放大，方案2的編輯時間最短，本文方案的兩種編輯方式的編輯時間比方案2多，但總體時間低于20 ms。

5.2.4 一致性驗證時間

方案1和本文方案具有數據一致性驗證功能，因此，對方案1和本文方案進行測試。方案1的編輯過程中的所有投票都保存在區塊鏈上，用戶可以通過遍歷目標區塊的后續所有區塊來進行目標區塊的數據一致性驗證。

從圖11可以知道，方案1的一致性驗證時間隨著目標區塊后續區塊數的增加而增加，當后續區塊數達到5 000時，一致性驗證時間超過100 s，且隨著鏈的生長，后續區塊數會不斷增加，一致性驗證時間也會不斷增加，因此效率會隨著鏈的生長而降低。

本文方案中，用戶獲取到目標區塊數據后，可以計算目標區塊的原生哈希，并從一致性驗證智能合約CVContract中獲取目標區塊的一致性證明proofOC，通過比較原生哈希和一致性證明來驗證目標區塊的一致性。從圖12可知，隨著區塊內交易數增加，本文方案的時間也會增加，因為區塊原生哈希的計算時間與區塊內交易數是正相關，但總體時間是遠遠小于方案1。總體上，在一致性驗證時間方面，本文方案的效率優于方案1。

6 結束語

本文針對區塊鏈監管需求提出了一種監管友好的區塊鏈方案，解決了現有區塊鏈內容監管存在的三個主要問題。通過代理簽名技術降低數據上鏈前的審計難度，且審計過程可控、可追責；設計一種編輯可控的數字簽名方案RCDSS以及新的區塊和交易結構，解決因編輯后交易簽名驗證不通過造成的監管受阻問題；利用智能合約和原生哈希為用戶提供有效的鏈上數據驗證服務，保證監管的有效性和數據可信。安全分析顯示，本文方案安全可信、監管可控、可追責；實驗結果顯示，相對于現有方案，本文方案在區塊生成、編輯和一致性驗證等關鍵階段的效率高、可行性強。

本文方法仍有不足之處，一是監管方是誠實可信且陷門由監管方保存，二是交易審計效率會影響交易上鏈速度。下一步將針對以上問題繼續開展研究。

參考文獻：

［1］陳純.聯盟區塊鏈關鍵技術與區塊鏈的監管挑戰［J］.企業觀察家，2019（11）：76－78. （Chen Chun.Key technology in alliance chain and challenges in monito－ring blockchain［J］. Enterprise Observer ，2019（11）：76－78.）

［2］蔡亮.聯盟區塊鏈技術、應用與監管［J］.招標采購管理，2021（6）：25，27. （Cai Liang.Alliance blockchain technology，application and supervision［J］. Tendering amp; Purchasing Management ，2021（6）：25，27.）

［3］Musamih A，Salah K，Jayaraman R，et al.A blockchain－based approach for drug traceability in healthcare supply chain［J］. IEEE Access ，202 2021 （9）：9728－9743.

［4］譚海波，周桐，趙赫，等.基于區塊鏈的檔案數據保護與共享方法［J］.軟件學報，2019， 30 （9）：2620－2635. （Tan Haibo，Zhou Tong，Zhao He，et al.Archival data protection and sharing method based on blockchain［J］. Journal of Software ，2019， 30 （9）：2620－2635.）

［5］Feng Chaosheng，Yu Keping，Bashir A K，et al.Efficient and secure data sharing for 5G flying drones：a blockchain－enabled approach［J］. IEEE Network ，202 35 （1）：130－137.

［6］Dousti M S，Kyupyu A.Tri－op redactable blockchains with block modification，removal，and insertion［J］. Turkish Journal of Electrical Engineering and Computer Sciences ，2022， 30 （2）：376－391.

［7］Mathew J.Bitcoin：blockchain could become ‘safe haven’ for hosting child sexual abuse images［EB/OL］.（2021）［2023－05－25］.https：//www.dailydot.com/business/bitcoin－child－porn－transaction－code.

［8］Matzutt R，Hiller J，Henze M，et al.A quantitative analysis of the impact of arbitrary blockchain content on bitcoin［C］//Proc of International Conference on Financial Cryptography and Data Security.Berlin：Springer，2018：420－438.

［9］王熠玨.區塊鏈信息服務提供者的刑事責任研究［J］.中國刑事法雜志，2020（6）：90－104. （Wang Yijue.Research on the criminal liability of a blockchain information service provider［J］. Criminal Science ，2020（6）：90－104.）

［10］國家互聯網信息辦公室.區塊鏈信息服務管理規定［J］.中華人民共和國國務院公報，2019（14）：62－64. （National Internet Information Office.Blockchain information service management regulations［J］. Gazette of the State Council of the People’s Republic of China ，2019（14）：62－64.）

［11］Regulation P.General data protection regulation［J］. Intouch ，2018， 2018 （25）：1－5.

［12］袁勇，王飛躍.可編輯區塊鏈：模型、技術與方法［J］.自動化學報，2020， 46 （5）：831－846. （Yuan Yong，Wang Feiyue.Editable blockchain：models，techniques and methods［J］. Acta Automatica Sinica ，2020， 46 （5）：831－846.）

［13］王利朋，關志，李青山，等.區塊鏈數據安全服務綜述［J］.軟件學報，2023， 34 （1）：1－32. （Wang Lipeng，Guan Zhi，Li Qingshan，et al.Survey on blockchain－based security services［J］. Journal of Software ，2023， 34 （1）：1－32.）

［14］任艷麗，徐丹婷，張新鵬，等.基于門限環簽名的可刪除區塊鏈［J］.通信學報，2019， 40 （4）：71－82. （Ren Yanli，Xu Danting，Zhang Xinpeng，et al.Deletable blockchain based on threshold ring signature［J］. Journal on Communications ，2019， 40 （4）：71－82.）

［15］Deuber D，Magri B，Thyagarajan S A K.Redactable blockchain in the permissionless setting［C］//Proc of IEEE Symposium on Security and Privacy.Piscataway，NJ：IEEE Press，2019：645－659.

［16］Ateniese G，Magri B，Venturi D，et al.Redactable blockchain－or－rewriting history in bitcoin and friends［C］//Proc of IEEE European Symposium on Security and Privacy.Piscataway，NJ：IEEE Press，2017：111－126.

［17］Camenisch J，Derler D，Krenn S，et al.Chameleon－hashes with ephe－meral trapdoors：and applications to invisible sanitizable signatures［C］//Proc of the 20th IACR International Conference on Practice and Theory in Public Key Cryptography.Berlin：Springer，2017：152－182.

［18］呂偉龍，魏松杰，于銘慧，等.面向可信聯盟的區塊鏈賬本可驗證修改方法研究［J］.計算機學報，202 44 （10）：2016－2032. （Lyu Weilong，Wei Songjie，Yu Minghui，et al.Research on verifiable blockchain ledger redaction method for trusted consortium［J］. Chinese Journal of Computers ，202 44 （10）：2016－2032.）

［19］Jia Meng，Chen Jing，He Kun，et al.Redactable blockchain from decentralized chameleon hash functions［J］. IEEE Trans on Information Forensics and Security ，2022， 17 ：2771－2783.

［20］Derler D，Samelin K，Slamanig D，et al.Fine－grained and controlled rewriting in blockchains：chameleon－hashing gone attribute－based［EB/OL］.（2019）.［2023－05－25］.https：//eprint.iacr.org/2019/406.

［21］Ma Jinhua，Xu Shengmin，Ning Jianting，et al.Redactable blockchain in decentralized setting［J］. IEEE Trans on Information Forensics and Security ，2022， 17 ：1227－1242.

［22］Tian Yangguang，Li Nan，Li Yingjiu，et al.Policy－based chameleon hash for blockchain rewriting with black－box accountability［C］//Proc of the 36th Annual Computer Security Applications Conference.New York：ACM Press，2020：813－828.

［23］Li Yong，Zhang Zhenghao，Chen Xi，et al.Redactable blockchain with k－time controllable editing［C］//Proc of the 21st IEEE International Conference on Trust，Security and Privacy in Computing and Communications.Piscataway，NJ：IEEE Press，2022：1455－1461.

［24］Chen Xiaofeng，Gao Ying.CDEdit：a highly applicable redactable blockchain with controllable editing privilege and diversified editing types［EB/OL］.（2022）［2023－05－25］.https：//arxiv.org/abs/2205.07054.

［25］任艷麗，徐丹婷，張新鵬，等.可修改的區塊鏈方案［J］.軟件學報，2020， 31 （12）：3909－3922. （Ren Yanli，Xu Danting，Zhang Xinpeng，et al.Scheme of revisable blockchain［J］. Journal of Software ，2020， 31 （12）：3909－3922.）

［26］Johnson D，Menezes A，Vanstone S.The elliptic curve digital signature algorithm（ECDSA）［J］. International Journal of Information Security ，200 1 ：36－63.

［27］Koblitz N.Elliptic curve cryptosystems［J］. Mathematics of Computation ，1987， 48 （177）：203－209.

［28］Miller V S.Use of elliptic curves in cryptography［C］//Proc of Conference on Theory and Application Cryptographic Techniques.Berlin：Springer，1986：417－426.

收稿日期：2023－07－12；修回日期：2023－09－07 基金項目：國家重點研發計劃資助項目（2021YFB2700800）

作者簡介：俞望年（1997—），男，安徽合肥人，碩士研究生，主要研究方向為區塊鏈監管技術；趙赫（1984—），男，正高級工程師，博士，主要研究方向為軟件工程、區塊鏈技術；譚海波（1976—），男（通信作者），研究員，博士，主要研究方向為區塊鏈技術、網絡安全（hbtan@hfcas.ac.cn）；程昊天（1996—），男，博士研究生，主要研究方向為區塊鏈監管技術、區塊鏈隱私保護；趙越（2000—），男，碩士研究生，主要研究方向為區塊鏈網絡技術；馬志宇（1998—），男，博士研究生，主要研究方向為區塊鏈分片技術、區塊鏈數據庫技術.