一種監(jiān)管友好的可編輯區(qū)塊鏈方案

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

關(guān)鍵詞：區(qū)塊鏈； 監(jiān)管； 審計(jì)； 可編輯； 數(shù)據(jù)一致性

中圖分類號(hào)：TP311文獻(xiàn)標(biāo)志碼： A文章編號(hào)：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 引言

區(qū)塊鏈監(jiān)管一直存在著挑戰(zhàn)性［1，2］。作為公開透明的賬本，用戶可以在鏈上存儲(chǔ)任意數(shù)據(jù)［3～5］，但這種功能已經(jīng)被濫用。研究者們?cè)诒忍貛派弦寻l(fā)現(xiàn)敏感信息和違法數(shù)據(jù)，例如虐待兒童的內(nèi)容和色情圖像［6～8］等，區(qū)塊鏈內(nèi)容的合法性受到破壞［9］。許多國(guó)家針對(duì)區(qū)塊鏈的監(jiān)管表明了態(tài)度。文獻(xiàn)［10］規(guī)定，對(duì)于法律法規(guī)禁止的內(nèi)容，在其發(fā)布、傳播過程中要進(jìn)行過濾和阻斷，對(duì)已經(jīng)存儲(chǔ)在區(qū)塊鏈上的違法內(nèi)容，在不破壞區(qū)塊鏈數(shù)據(jù)完整性的前提下，允許編輯此類數(shù)據(jù)。歐盟出臺(tái)規(guī)定［11］：用戶具有“被遺忘權(quán)”，即用戶可以要求服務(wù)商刪除網(wǎng)絡(luò)中關(guān)于自己的隱私數(shù)據(jù)。此外，因?yàn)橛脩羰韬龆鴮?dǎo)致錯(cuò)誤數(shù)據(jù)上鏈，也需要?jiǎng)h除鏈上錯(cuò)誤的數(shù)據(jù)［12，13］。因此，設(shè)計(jì)一種滿足監(jiān)管要求的區(qū)塊鏈方案是十分必要的。

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

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

a）數(shù)據(jù)在上鏈之前缺乏對(duì)內(nèi)容的監(jiān)管審計(jì)。區(qū)塊鏈節(jié)點(diǎn)驗(yàn)證交易時(shí)并不會(huì)檢查payload中附帶信息的合規(guī)性，并且缺乏對(duì)審計(jì)行為的有效激勵(lì)。這會(huì)造成節(jié)點(diǎn)僅為爭(zhēng)取共識(shí)獎(jiǎng)勵(lì)與交易手續(xù)費(fèi)而將一些可能包含違法數(shù)據(jù)的交易打包成區(qū)塊并持久化存儲(chǔ)，造成難以消除的不良影響。

b）數(shù)據(jù)編輯導(dǎo)致交易驗(yàn)簽失效，使得監(jiān)管受阻。對(duì)已經(jīng)存儲(chǔ)在鏈上的違法或錯(cuò)誤數(shù)據(jù)，需要采用編輯技術(shù)刪除或修改。為了不破壞每個(gè)賬戶中交易的可追溯性，僅對(duì)交易附帶的違法或錯(cuò)誤數(shù)據(jù)進(jìn)行編輯，這會(huì)造成交易中原有簽名驗(yàn)證不通過。

c）數(shù)據(jù)編輯導(dǎo)致鏈上數(shù)據(jù)一致性驗(yàn)證難度增加，破壞監(jiān)管有效性。編輯后同一高度的區(qū)塊可能存在多個(gè)版本，且每個(gè)版本都可以通過一致性驗(yàn)證，惡意節(jié)點(diǎn)可能保存多個(gè)版本。當(dāng)用戶向區(qū)塊鏈請(qǐng)求數(shù)據(jù)時(shí)，惡意節(jié)點(diǎn)會(huì)將舊版本發(fā)送給用戶，用戶無法判別收到的內(nèi)容是否為編輯后的最新版本。舊版本區(qū)塊數(shù)據(jù)中包含違法內(nèi)容，惡意節(jié)點(diǎn)在數(shù)據(jù)同步時(shí)將其傳輸給新加入的區(qū)塊鏈節(jié)點(diǎn)，導(dǎo)致已經(jīng)被刪除的違法內(nèi)容再次被傳播和存儲(chǔ)，破壞監(jiān)管有效性。

針對(duì)問題a），若完全由一個(gè)單一的監(jiān)管方執(zhí)行審計(jì)任務(wù)，則該部分可能會(huì)成為系統(tǒng)的性能瓶頸。若由普通的區(qū)塊鏈節(jié)點(diǎn)審計(jì)，可能存在惡意節(jié)點(diǎn)拒絕審計(jì)，或節(jié)點(diǎn)間互不信任，同一數(shù)據(jù)會(huì)被多次審計(jì)，浪費(fèi)計(jì)算資源。為此，本文引入審計(jì)節(jié)點(diǎn)這一角色，將審計(jì)任務(wù)落到多個(gè)審計(jì)節(jié)點(diǎn)，降低審計(jì)過程對(duì)系統(tǒng)性能的影響，同時(shí)利用代理簽名實(shí)現(xiàn)對(duì)每個(gè)審計(jì)節(jié)點(diǎn)的授權(quán)和追責(zé)，并設(shè)置審計(jì)獎(jiǎng)勵(lì)，激勵(lì)審計(jì)節(jié)點(diǎn)誠(chéng)實(shí)執(zhí)行審計(jì)任務(wù)。

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

針對(duì)問題c），本文利用智能合約記錄每個(gè)區(qū)塊的更新歷史，用戶利用智能合約可以對(duì)查詢結(jié)果進(jìn)行驗(yàn)證，節(jié)點(diǎn)同時(shí)會(huì)返回一個(gè)與查詢結(jié)果相關(guān)的承諾，通過承諾可以判斷節(jié)點(diǎn)是否提供了舊版本數(shù)據(jù)，從而降低節(jié)點(diǎn)作惡的可能性。

綜上，本文提出了一種監(jiān)管友好的可編輯區(qū)塊鏈方案，主要工作內(nèi)容如下：

a）設(shè)計(jì)了一種可動(dòng)態(tài)調(diào)整、可追責(zé)的數(shù)據(jù)審計(jì)方法。監(jiān)管方通過代理簽名將審計(jì)權(quán)分發(fā)給多個(gè)審計(jì)節(jié)點(diǎn)，減輕審計(jì)壓力，提高審計(jì)效率和系統(tǒng)穩(wěn)定性。

b）設(shè)計(jì)了一種編輯可控的數(shù)字簽名方案RCDSS，并且設(shè)計(jì)了與之對(duì)應(yīng)的區(qū)塊結(jié)構(gòu)和交易結(jié)構(gòu)。用戶不配合監(jiān)管時(shí)，對(duì)于數(shù)據(jù)的編輯不會(huì)影響交易簽名的驗(yàn)證結(jié)果。

c）基于智能合約和原生哈希設(shè)計(jì)了一種區(qū)塊鏈數(shù)據(jù)一致性驗(yàn)證協(xié)議，數(shù)據(jù)請(qǐng)求方可以對(duì)查詢的結(jié)果進(jìn)行數(shù)據(jù)一致性驗(yàn)證。此外，通過數(shù)據(jù)一致性承諾DCCom可以定位到作惡的數(shù)據(jù)提供方，并進(jìn)行懲罰，從而降低數(shù)據(jù)提供方作惡的可能性。

1 預(yù)備知識(shí)

1.1 區(qū)塊鏈

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

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

1.2 變色龍哈希函數(shù)

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

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

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

c）d=CH_Ver（hk，m，h，r）。哈希值驗(yàn)證算法，輸入公鑰hk、消息m、哈希值h和隨機(jī)數(shù)r，輸出一個(gè)比特d，如果h=CH_Hash（hk，m，r），則d=1，否則d=0。

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

2 系統(tǒng)模型

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

本文的系統(tǒng)架構(gòu)如圖1所示，主要由數(shù)據(jù)所有者、監(jiān)管方、審計(jì)節(jié)點(diǎn)、數(shù)據(jù)請(qǐng)求方、數(shù)據(jù)提供方、普通節(jié)點(diǎn)六種角色以及智能合約組成。

a）數(shù)據(jù)所有者：區(qū)塊鏈系統(tǒng)中的用戶，利用區(qū)塊鏈存儲(chǔ)自己的數(shù)據(jù)。

b）監(jiān)管方：由監(jiān)管部門（政府）組成的一個(gè)監(jiān)管委員會(huì)，是完全可信的，負(fù)責(zé)審計(jì)節(jié)點(diǎn)的選擇、 節(jié)點(diǎn)行為的激勵(lì)和懲罰、哈希碰撞的生成。在系統(tǒng)初始化的時(shí)候，負(fù)責(zé)變色龍哈希函數(shù)的初始化并保存陷門tk。監(jiān)管方在區(qū)塊鏈中的操作是公開透明且記錄在區(qū)塊鏈上，系統(tǒng)中的所有參與者都可以對(duì)監(jiān)管方進(jìn)行監(jiān)管。

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

d）數(shù)據(jù)請(qǐng)求方：區(qū)塊鏈系統(tǒng)中的用戶或輕節(jié)點(diǎn)（由于資源受限不能存儲(chǔ)完整的區(qū)塊鏈數(shù)據(jù)）或新加入系統(tǒng)的節(jié)點(diǎn)，對(duì)鏈上數(shù)據(jù)發(fā)起查詢或同步請(qǐng)求，并對(duì)查詢的結(jié)果進(jìn)行一致性驗(yàn)證。

e）數(shù)據(jù)提供方：區(qū)塊鏈系統(tǒng)中的一些全節(jié)點(diǎn)，存儲(chǔ)完整的區(qū)塊鏈數(shù)據(jù)，能提供數(shù)據(jù)查詢和同步服務(wù)。

f）普通節(jié)點(diǎn)：包含全節(jié)點(diǎn)和輕節(jié)點(diǎn)，全節(jié)點(diǎn)具有完整的賬本數(shù)據(jù)，輕節(jié)點(diǎn)具有部分賬本數(shù)據(jù)。

g）智能合約：由監(jiān)管方部署的一個(gè)一致性驗(yàn)證合約CVContract（consistency verification contract）。合約存儲(chǔ)了鏈上每個(gè)區(qū)塊的一致性證明，可以提供鏈上數(shù)據(jù)一致性驗(yàn)證服務(wù)。合約狀態(tài)更新操作由監(jiān)管方執(zhí)行，用戶和所有節(jié)點(diǎn)可以執(zhí)行合約的狀態(tài)查詢操作。

2.2 編輯可控的數(shù)字簽名方案RCDSS

2.2.1 算法介紹

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

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

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

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

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

2.2.2 算法分析

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

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

2.3 數(shù)據(jù)結(jié)構(gòu)

為了實(shí)現(xiàn)對(duì)區(qū)塊中數(shù)據(jù)內(nèi)容的監(jiān)管，本文對(duì)區(qū)塊結(jié)構(gòu)和交易結(jié)構(gòu)進(jìn)行重新設(shè)計(jì)。區(qū)塊結(jié)構(gòu)如表1所示，交易結(jié)構(gòu)如表2所示。

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

auditorNum為負(fù)責(zé)審計(jì)這個(gè)交易的審計(jì)節(jié)點(diǎn)編號(hào)，審計(jì)節(jié)點(diǎn)的編號(hào)由監(jiān)管方確定，且全局可見，簽名signature=RC_Sign（sk，m1，m2，hk，tx_r），m1=（from，to，value，auditorNum），m2=data。

2.4 安全需求

a）上鏈數(shù)據(jù)審計(jì)不可逃避性：數(shù)據(jù)上鏈前需要被審計(jì)，且審計(jì)過程不可逃避。

b）鏈上違法或錯(cuò)誤數(shù)據(jù)可擦除性：已經(jīng)上鏈的數(shù)據(jù)變成違法或錯(cuò)誤數(shù)據(jù)后，此類數(shù)據(jù)能夠被順利擦除且不影響區(qū)塊鏈的完整性。

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

d）鏈上數(shù)據(jù)一致性可驗(yàn)證性：數(shù)據(jù)請(qǐng)求方對(duì)鏈上數(shù)據(jù)進(jìn)行查詢或同步時(shí)，可以對(duì)得到的數(shù)據(jù)進(jìn)行一致性驗(yàn)證。

e）節(jié)點(diǎn)作惡可追責(zé)性：在數(shù)據(jù)上鏈審計(jì)過程中和鏈上數(shù)據(jù)查詢過程中，節(jié)點(diǎn)作惡行為不可抵賴、可追責(zé)。

3 監(jiān)管友好的可編輯區(qū)塊鏈方案

3.1 系統(tǒng)初始化階段

該階段可以劃分為監(jiān)管方初始化、普通節(jié)點(diǎn)和用戶初始化。

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

2）普通節(jié)點(diǎn)和用戶初始化 普通節(jié)點(diǎn)和用戶在本地選擇隨機(jī)數(shù)λ，通過運(yùn)行Gen（1λ）得到自己的公鑰pk和sk。用戶僅在生成交易時(shí)采用RCDSS簽名方案。

3.2 審計(jì)節(jié)點(diǎn)選取與激勵(lì)

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

當(dāng)系統(tǒng)時(shí)間超過timei或其審計(jì)額度用完時(shí)，節(jié)點(diǎn)nodei將重新變成普通節(jié)點(diǎn)，并進(jìn)入一個(gè)冷卻期。在冷卻期中，節(jié)點(diǎn)nodei不能參與審計(jì)節(jié)點(diǎn)的競(jìng)選。監(jiān)管方將根據(jù)節(jié)點(diǎn)nodei的審計(jì)的交易數(shù)量、審計(jì)的有效性來計(jì)算報(bào)酬，并將押金和報(bào)酬返回給節(jié)點(diǎn)nodei，如果節(jié)點(diǎn)nodei存在作惡行為，全網(wǎng)節(jié)點(diǎn)和用戶可以對(duì)節(jié)點(diǎn)nodei進(jìn)行舉報(bào)，監(jiān)管方將扣除其押金、降低其可信度。

3.3 數(shù)據(jù)審計(jì)和上鏈階段

審計(jì)節(jié)點(diǎn)在數(shù)據(jù)上鏈之前對(duì)數(shù)據(jù)進(jìn)行審計(jì)，審計(jì)節(jié)點(diǎn)可以利用人工智能和自然語言處理技術(shù)對(duì)數(shù)據(jù)進(jìn)行審計(jì)。數(shù)據(jù)審計(jì)和上鏈流程如圖3所示，流程詳細(xì)敘述如下：

a）用戶在本地生成交易tx=（from，to，value，data，auditorNum，tx_r，signature），其中auditorNum為負(fù)責(zé)審計(jì)該交易tx的審計(jì)節(jié)點(diǎn)的編號(hào)，用戶在生成交易時(shí)，選擇剩余審計(jì)額度多且審計(jì)速度不為0的審計(jì)節(jié)點(diǎn)。

b）用戶通過區(qū)塊鏈網(wǎng)絡(luò)廣播tx。

c）審計(jì)節(jié)點(diǎn)i（審計(jì)編號(hào)為i）收到交易tx，通過auditorNum值判斷這筆交易是否由自己審計(jì)，如果是，則對(duì)交易的data進(jìn)行審計(jì)。

d）審計(jì)通過后，審計(jì)節(jié)點(diǎn)為交易tx生成一個(gè)合法性證明proofOL=Sign（ski，tx），ski為審計(jì)節(jié)點(diǎn)i的私鑰。

e）審計(jì)節(jié)點(diǎn)i將tx和proofOL廣播到全網(wǎng)中。

f）全網(wǎng)節(jié)點(diǎn)收到tx和proofOL后進(jìn)行驗(yàn)證，驗(yàn)證通過則將tx通過全網(wǎng)共識(shí)上鏈。

g）全網(wǎng)節(jié)點(diǎn)向用戶返回交易tx成功上鏈的信息。

3.4 鏈上數(shù)據(jù)編輯階段

鏈上數(shù)據(jù)編輯包括用戶主動(dòng)請(qǐng)求編輯和監(jiān)管方主動(dòng)編輯。用戶在數(shù)據(jù)上鏈的時(shí)候，由于數(shù)據(jù)采集或傳輸?shù)氖韬龆鴮?dǎo)致錯(cuò)誤數(shù)據(jù)上鏈，數(shù)據(jù)的所有者發(fā)現(xiàn)錯(cuò)誤后可以向監(jiān)管方提交編輯請(qǐng)求以修正鏈上錯(cuò)誤數(shù)據(jù)。當(dāng)其他用戶向監(jiān)管方舉報(bào)鏈上存在違法數(shù)據(jù)或者監(jiān)管方自己發(fā)現(xiàn)鏈上存在違法數(shù)據(jù)時(shí)，監(jiān)管方可以主動(dòng)發(fā)起編輯，隱藏或刪除此類數(shù)據(jù)。

3.4.1 用戶主動(dòng)請(qǐng)求編輯

用戶主動(dòng)發(fā)起請(qǐng)求編輯的過程如圖4所示，過程詳細(xì)敘述如下：

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

（a）找到需要編輯的數(shù)據(jù)所在區(qū)塊的區(qū)塊號(hào)blockNum和交易tx。

（b）計(jì)算tx的哈希值oldTxHash=Hash（tx）。

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

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

b）用戶廣播編輯請(qǐng)求EditRequest。

c）監(jiān)管方收到編輯請(qǐng)求EditRequest并審計(jì)通過后，為新的交易newTx生成一個(gè)合法性證明proofOL=Sign（rsk，newTx）、目標(biāo)區(qū)塊blockNum的新的變色龍哈希隨機(jī)數(shù)newBL_R和新的原生哈希newNatHash。

d）監(jiān)管方將EditRequest、proofOL、newBL_R、newNatHash廣播到全網(wǎng)中。

e）節(jié)點(diǎn)收到EditRequest、proofOL、newBL_R、newNatHash后進(jìn)行驗(yàn)證，驗(yàn)證通過則將它們存儲(chǔ)在本地?cái)?shù)據(jù)庫并更新本地賬本數(shù)據(jù)。

f）節(jié)點(diǎn)完成更新后，向監(jiān)管方發(fā)送更新成功信息。

g）當(dāng)大部分節(jié)點(diǎn)完成更新后，監(jiān)管方調(diào)用一致性驗(yàn)證智能合約CVContract更新區(qū)塊blockNum的一致性證明proofOC=（natHashblockNum）。

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

i）監(jiān)管方返回編輯成功信息給用戶。

當(dāng)用戶發(fā)起惡意的數(shù)據(jù)編輯請(qǐng)求時(shí)，將會(huì)被全網(wǎng)節(jié)點(diǎn)加入黑名單，黑名單上的用戶發(fā)起的交易將不被審計(jì)和打包上鏈，除非繳納相應(yīng)罰款。因?yàn)橛脩舭l(fā)起的數(shù)據(jù)編輯請(qǐng)求中包含一個(gè)請(qǐng)求簽名，所以用戶的惡意請(qǐng)求行為不可偽造、不可抵賴。

3.4.2 監(jiān)管方主動(dòng)編輯與用戶申訴

監(jiān)管方主動(dòng)發(fā)起編輯的過程與用戶主動(dòng)發(fā)起編輯的過程相似，主要區(qū)別在于編輯請(qǐng)求EditRequest和新的內(nèi)容newData的生成方式不同。下面具體介紹EditRequest和newData的生成過程，其余過程不再贅述。

a）監(jiān)管方找到目標(biāo)數(shù)據(jù)所在區(qū)塊的區(qū)塊號(hào)blockNum和交易tx=（from，to，value，data，auditorNum，tx_r，signature）。

b）計(jì)算tx的哈希值oldTxHash=Hash（tx）。

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

d）監(jiān)管方生成一個(gè)編輯請(qǐng)求EditRequest=（ERContent，ERSignature），ERContent=（oldTxHash，blockNum，newData，newTX_R，signature）， ERSignature=Sign（rsk，ERContent），rsk為監(jiān)管方私鑰。

監(jiān)管方出于監(jiān)管要求，對(duì)某個(gè)交易tx進(jìn)行編輯，將tx內(nèi)的數(shù)據(jù)換成原始數(shù)據(jù)的密文和被編輯的原因，當(dāng)用戶對(duì)監(jiān)管方的編輯存在質(zhì)疑時(shí)，用戶可以向監(jiān)管方進(jìn)行申訴。

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

3.5 鏈上數(shù)據(jù)查詢和一致性驗(yàn)證

當(dāng)數(shù)據(jù)請(qǐng)求方（用戶、輕節(jié)點(diǎn)、新加入?yún)^(qū)塊鏈網(wǎng)絡(luò)的節(jié)點(diǎn)）對(duì)鏈上數(shù)據(jù)進(jìn)行查詢或同步時(shí)，會(huì)向區(qū)塊鏈中的數(shù)據(jù)提供方（全節(jié)點(diǎn)）請(qǐng)求賬本數(shù)據(jù)。由于數(shù)據(jù)所有者和監(jiān)管方可能對(duì)鏈上數(shù)據(jù)進(jìn)行了編輯，所以區(qū)塊鏈的一致性不能由區(qū)塊哈希值的唯一性來保證，本文方案利用智能合約和區(qū)塊原生哈希來保證區(qū)塊鏈數(shù)據(jù)的一致性。以區(qū)塊查詢?yōu)槔?，過程如圖5所示，具體描述如下：

a）數(shù)據(jù)請(qǐng)求方生成一個(gè)區(qū)塊查詢請(qǐng)求blockQuery=（heighti，hi），heighti和hi分別為所要查詢的目標(biāo)區(qū)塊Bi的區(qū)塊高度和區(qū)塊哈希。

b）數(shù)據(jù)請(qǐng)求方廣播區(qū)塊查詢請(qǐng)求blockQuery。

c）數(shù)據(jù)提供方收到blockQuery后，根據(jù)blockQuery定位到目標(biāo)區(qū)塊Bi=（preHashi，timestamp，rooti，bl_ri，noncei，natHashi，transactions），并生成Bi的數(shù)據(jù)一致性承諾DCCom=Sign（sk，（natHashi，time）），其中sk為數(shù)據(jù)提供方的私鑰，time為當(dāng)前系統(tǒng)時(shí)間。

d）數(shù)據(jù)提供方返回Bi和DCCom。

e）數(shù)據(jù)請(qǐng)求方收到Bi和DCCom后，調(diào)用區(qū)塊鏈上的智能合約CVContract，獲取目標(biāo)區(qū)塊Bi的一致性證明。

f）CVContract返回目標(biāo)區(qū)塊Bi的一致性證明proofOC。

g）數(shù)據(jù)請(qǐng)求方收到proofOC后，進(jìn)行一致性驗(yàn)證，具體過程如下：

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

（b）比較等式proofOC=natHashi是否成立。若成立，則數(shù)據(jù)是可信的；若不成立，則數(shù)據(jù)是不可信的，將區(qū)塊Bi的一致性證明proofOC、區(qū)塊查詢請(qǐng)求blockQuery和數(shù)據(jù)一致性承諾DCCom發(fā)給監(jiān)管方，對(duì)數(shù)據(jù)提供方進(jìn)行追責(zé)。

監(jiān)管方收到數(shù)據(jù)提供方發(fā)送的proofOC、blockQuery和DCCom后，會(huì)根據(jù)DCCom中的時(shí)間time，通過智能合約查詢到區(qū)塊Bi在時(shí)間time時(shí)的一致性證明proofOC′，如果natHashi=proofOC′，則說明數(shù)據(jù)請(qǐng)求方從數(shù)據(jù)提供方獲取區(qū)塊Bi后，區(qū)塊Bi的數(shù)據(jù)發(fā)生編輯更新，數(shù)據(jù)提供方?jīng)]有作惡，否則數(shù)據(jù)提供方作惡了，監(jiān)管方根據(jù)DCCom定位到作惡的數(shù)據(jù)提供方并追責(zé)。同時(shí)，為了防止用戶惡意請(qǐng)求干擾數(shù)據(jù)提供方正常運(yùn)行，數(shù)據(jù)提供方對(duì)用戶請(qǐng)求頻率進(jìn)行適當(dāng)限制。

4 安全性分析

根據(jù)2.4節(jié)所述的5項(xiàng)安全需求，本章對(duì)監(jiān)管友好的可編輯區(qū)塊鏈方案展開分析。

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

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

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

d）鏈上數(shù)據(jù)一致性可驗(yàn)證性。當(dāng)從數(shù)據(jù)提供方獲取到數(shù)據(jù)后，數(shù)據(jù)請(qǐng)求方可以調(diào)用一致性驗(yàn)證智能合約CVContract獲取目標(biāo)區(qū)塊的一致性證明proofOC，對(duì)數(shù)據(jù)進(jìn)行一致性驗(yàn)證，CVContract的狀態(tài)由可信的監(jiān)管方進(jìn)行維護(hù)。

e）節(jié)點(diǎn)作惡可追責(zé)性。

（a）審計(jì)節(jié)點(diǎn)作惡。審計(jì)節(jié)點(diǎn)是普通節(jié)點(diǎn)向監(jiān)管方申請(qǐng)，并由監(jiān)管方確定的。每個(gè)審計(jì)節(jié)點(diǎn)會(huì)受到監(jiān)管方、普通節(jié)點(diǎn)和其他審計(jì)節(jié)點(diǎn)的監(jiān)督。理性的審計(jì)節(jié)點(diǎn)會(huì)認(rèn)真執(zhí)行審計(jì)并獲得相應(yīng)收益，如果某個(gè)審計(jì)節(jié)點(diǎn)進(jìn)行低效或無效審計(jì)，監(jiān)管方可以根據(jù)交易上的審計(jì)節(jié)點(diǎn)編號(hào)auditorNum追蹤到該審計(jì)節(jié)點(diǎn)并進(jìn)行追責(zé)。

（b）數(shù)據(jù)提供方作惡。數(shù)據(jù)請(qǐng)求方在對(duì)收到的區(qū)塊Bi進(jìn)行一致性驗(yàn)證時(shí)，如果發(fā)現(xiàn)數(shù)據(jù)提供方作惡（提供包含違法內(nèi)容等數(shù)據(jù)的舊版本區(qū)塊），數(shù)據(jù)請(qǐng)求方可以將Bi的數(shù)據(jù)一致性承諾DCCom發(fā)送給監(jiān)管方，監(jiān)管方根據(jù)DCCom可以定位到作惡的數(shù)據(jù)提供方，并進(jìn)行追責(zé)。

5 實(shí)驗(yàn)與評(píng)估

為了說明本文方案的有效性和可行性，即評(píng)估引入本文設(shè)計(jì)的監(jiān)管方案后，對(duì)整個(gè)方案性能的影響，實(shí)現(xiàn)了基于本文方案的區(qū)塊鏈內(nèi)容監(jiān)管平臺(tái)原型系統(tǒng)，如圖6所示。

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

5.1 功能對(duì)比

如表3所示，將本文方案與現(xiàn)有方案從編輯方式、數(shù)據(jù)上鏈審計(jì)、編輯后交易簽名驗(yàn)證、一致性驗(yàn)證、節(jié)點(diǎn)作惡追責(zé)和監(jiān)管友好方面進(jìn)行比較。

方案1［15］支持對(duì)鏈上違法等數(shù)據(jù)進(jìn)行刪除和修改，編輯操作由系統(tǒng)中節(jié)點(diǎn)投票來表決，系統(tǒng)大多數(shù)節(jié)點(diǎn)同意后就執(zhí)行編輯操作，且投票記錄保存在鏈上。

方案2［18］支持對(duì)鏈上違法等數(shù)據(jù)進(jìn)行刪除和修改，編輯操作由系統(tǒng)中的權(quán)限節(jié)點(diǎn)來決定，每個(gè)權(quán)限節(jié)點(diǎn)保存變色龍哈希陷門的秘密碎片，當(dāng)某個(gè)權(quán)限節(jié)點(diǎn)收集到一定閾值的秘密碎片即可恢復(fù)陷門并執(zhí)行編輯操作。

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

本文方案 設(shè)計(jì)一個(gè)監(jiān)管友好的可編輯區(qū)塊鏈模型，通過代理簽名，監(jiān)管方可以選取并授權(quán)審計(jì)節(jié)點(diǎn)對(duì)上鏈的數(shù)據(jù)進(jìn)行審計(jì)，對(duì)于惡意用戶不配合編輯的情況，通過RCDSS簽名方案和變色龍哈希函數(shù)，在保證鏈的完整性的前提下，監(jiān)管方可以編輯違法內(nèi)容等數(shù)據(jù)，并為用戶提供申訴恢復(fù)數(shù)據(jù)的機(jī)會(huì)，通過智能合約和區(qū)塊原生哈希，用戶可以對(duì)查詢結(jié)果進(jìn)行有效的一致性驗(yàn)證。同時(shí)，對(duì)節(jié)點(diǎn)的作惡行為可以進(jìn)行定位和追責(zé)。

5.2 性能分析

5.2.1 簽名算法各階段時(shí)間

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

從圖7可以看出，在Gen階段，兩種算法時(shí)間相同，在Sign、Verify階段，RCDSS的時(shí)間比ECDSA的時(shí)間多，RedactSign是RCDSS獨(dú)有的階段。因?yàn)槌跏蓟绞揭粯樱襌CDSS在Sign、Verify階段進(jìn)行了額外的變色龍哈希計(jì)算，所以上述結(jié)果符合預(yù)期?？傮w上，兩者各階段的時(shí)間都是微秒級(jí)別，性能幾乎一樣。

5.2.2 區(qū)塊生成時(shí)間

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

從圖8可以看出，方案1的時(shí)間最少，方案2的時(shí)間最多，本文方案的時(shí)間略高于方案1，且隨著區(qū)塊內(nèi)交易數(shù)量增加，三者時(shí)間都在增加，其中方案2增長(zhǎng)最多。因?yàn)榉桨?僅僅在區(qū)塊頭中增加一個(gè)舊態(tài)oldState字段，并沒有用到復(fù)雜的密碼學(xué)工具，方案2在區(qū)塊生成過程中利用變色龍哈希函數(shù)對(duì)每個(gè)交易計(jì)算哈希值， 本文方案在區(qū)塊生成過程中僅用變色龍哈希函數(shù)來計(jì)算區(qū)塊哈希值，且變色龍哈希函數(shù)相比普通哈希函數(shù)，其進(jìn)行的指數(shù)運(yùn)算更多，時(shí)間更長(zhǎng)。總體上，本文方案與方案1的區(qū)塊生成時(shí)間相近，方案2的區(qū)塊生成時(shí)間最長(zhǎng)。

5.2.3 編輯時(shí)間

為了評(píng)估編輯效率，對(duì)方案1、2和本文方案進(jìn)行實(shí)驗(yàn)，實(shí)驗(yàn)過程中忽略網(wǎng)絡(luò)延遲。

在方案1中，一個(gè)節(jié)點(diǎn)提出編輯請(qǐng)求，其他節(jié)點(diǎn)通過將編輯請(qǐng)求的哈希值包含在自己生成的區(qū)塊中來進(jìn)行投票，因此一個(gè)區(qū)塊代表一個(gè)投票。筆者調(diào)整了編輯請(qǐng)求提出之后進(jìn)行投票的區(qū)塊數(shù)。從圖9可知，編輯時(shí)間隨著投票數(shù)的增加而增加，在實(shí)際過程中編輯的時(shí)間會(huì)更長(zhǎng)，因?yàn)槊總€(gè)區(qū)塊的生成具有時(shí)間間隔（以太坊約15 s，比特幣約10 min）。

在方案2中，一個(gè)權(quán)限節(jié)點(diǎn)node提出編輯請(qǐng)求，其他權(quán)限節(jié)點(diǎn)同意后將自己的陷門碎片發(fā)給node，node收集到足夠陷門碎片即可恢復(fù)陷門并執(zhí)行編輯操作。本文方案包括用戶主動(dòng)請(qǐng)求編輯和監(jiān)管方主動(dòng)編輯兩種方式，兩種方式的主要區(qū)別在與編輯請(qǐng)求和新數(shù)據(jù)的生成方式不同，后者進(jìn)行的操作較復(fù)雜，兩者每次編輯都需要生成新的區(qū)塊原生哈希值，時(shí)間會(huì)較長(zhǎng)。如圖10所示，方案2編輯時(shí)間較短，且與區(qū)塊內(nèi)交易數(shù)無關(guān)，本文兩種編輯方式的時(shí)間較長(zhǎng)，且隨著區(qū)塊內(nèi)交易數(shù)增加而增加。

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

5.2.4 一致性驗(yàn)證時(shí)間

方案1和本文方案具有數(shù)據(jù)一致性驗(yàn)證功能，因此，對(duì)方案1和本文方案進(jìn)行測(cè)試。方案1的編輯過程中的所有投票都保存在區(qū)塊鏈上，用戶可以通過遍歷目標(biāo)區(qū)塊的后續(xù)所有區(qū)塊來進(jìn)行目標(biāo)區(qū)塊的數(shù)據(jù)一致性驗(yàn)證。

從圖11可以知道，方案1的一致性驗(yàn)證時(shí)間隨著目標(biāo)區(qū)塊后續(xù)區(qū)塊數(shù)的增加而增加，當(dāng)后續(xù)區(qū)塊數(shù)達(dá)到5 000時(shí)，一致性驗(yàn)證時(shí)間超過100 s，且隨著鏈的生長(zhǎng)，后續(xù)區(qū)塊數(shù)會(huì)不斷增加，一致性驗(yàn)證時(shí)間也會(huì)不斷增加，因此效率會(huì)隨著鏈的生長(zhǎng)而降低。

本文方案中，用戶獲取到目標(biāo)區(qū)塊數(shù)據(jù)后，可以計(jì)算目標(biāo)區(qū)塊的原生哈希，并從一致性驗(yàn)證智能合約CVContract中獲取目標(biāo)區(qū)塊的一致性證明proofOC，通過比較原生哈希和一致性證明來驗(yàn)證目標(biāo)區(qū)塊的一致性。從圖12可知，隨著區(qū)塊內(nèi)交易數(shù)增加，本文方案的時(shí)間也會(huì)增加，因?yàn)閰^(qū)塊原生哈希的計(jì)算時(shí)間與區(qū)塊內(nèi)交易數(shù)是正相關(guān)，但總體時(shí)間是遠(yuǎn)遠(yuǎn)小于方案1?？傮w上，在一致性驗(yàn)證時(shí)間方面，本文方案的效率優(yōu)于方案1。

6 結(jié)束語

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

本文方法仍有不足之處，一是監(jiān)管方是誠(chéng)實(shí)可信且陷門由監(jiān)管方保存，二是交易審計(jì)效率會(huì)影響交易上鏈速度。下一步將針對(duì)以上問題繼續(xù)開展研究。

參考文獻(xiàn)：

［1］陳純.聯(lián)盟區(qū)塊鏈關(guān)鍵技術(shù)與區(qū)塊鏈的監(jiān)管挑戰(zhàn)［J］.企業(yè)觀察家，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］蔡亮.聯(lián)盟區(qū)塊鏈技術(shù)、應(yīng)用與監(jiān)管［J］.招標(biāo)采購(gòu)管理，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］譚海波，周桐，趙赫，等.基于區(qū)塊鏈的檔案數(shù)據(jù)保護(hù)與共享方法［J］.軟件學(xué)報(bào)，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］王熠玨.區(qū)塊鏈信息服務(wù)提供者的刑事責(zé)任研究［J］.中國(guó)刑事法雜志，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］國(guó)家互聯(lián)網(wǎng)信息辦公室.區(qū)塊鏈信息服務(wù)管理規(guī)定［J］.中華人民共和國(guó)國(guó)務(wù)院公報(bào)，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］袁勇，王飛躍.可編輯區(qū)塊鏈：模型、技術(shù)與方法［J］.自動(dòng)化學(xué)報(bào)，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］王利朋，關(guān)志，李青山，等.區(qū)塊鏈數(shù)據(jù)安全服務(wù)綜述［J］.軟件學(xué)報(bào)，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］任艷麗，徐丹婷，張新鵬，等.基于門限環(huán)簽名的可刪除區(qū)塊鏈［J］.通信學(xué)報(bào)，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－h(huán)ashes 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］呂偉龍，魏松杰，于銘慧，等.面向可信聯(lián)盟的區(qū)塊鏈賬本可驗(yàn)證修改方法研究［J］.計(jì)算機(jī)學(xué)報(bào)，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－h(huán)ashing 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］任艷麗，徐丹婷，張新鵬，等.可修改的區(qū)塊鏈方案［J］.軟件學(xué)報(bào)，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 基金項(xiàng)目：國(guó)家重點(diǎn)研發(fā)計(jì)劃資助項(xiàng)目（2021YFB2700800）

作者簡(jiǎn)介：俞望年（1997—），男，安徽合肥人，碩士研究生，主要研究方向?yàn)閰^(qū)塊鏈監(jiān)管技術(shù)；趙赫（1984—），男，正高級(jí)工程師，博士，主要研究方向?yàn)檐浖こ?、區(qū)塊鏈技術(shù)；譚海波（1976—），男（通信作者），研究員，博士，主要研究方向?yàn)閰^(qū)塊鏈技術(shù)、網(wǎng)絡(luò)安全（hbtan@hfcas.ac.cn）；程昊天（1996—），男，博士研究生，主要研究方向?yàn)閰^(qū)塊鏈監(jiān)管技術(shù)、區(qū)塊鏈隱私保護(hù)；趙越（2000—），男，碩士研究生，主要研究方向?yàn)閰^(qū)塊鏈網(wǎng)絡(luò)技術(shù)；馬志宇（1998—），男，博士研究生，主要研究方向?yàn)閰^(qū)塊鏈分片技術(shù)、區(qū)塊鏈數(shù)據(jù)庫技術(shù).