一種基于區域共享的云存儲系統的設計與實現

摘要：利用閑置的計算機的設備及帶寬構建成一個基于共享模式的存儲系統，是一個有價值的研究方向，基于該模式構建的分布式云存儲系統具有利用空閑資源，提高社會資源利用率的特點。在該方向上擁有較為成熟的體系和解決方案的是IPFS（InterPlanetary File System，星際文件系統）。IPFS是一個去中心化的分布式文件系統，其是一個針對于全球范圍的結合區塊鏈技術的共享模式的分布式存儲系統。而其系統非常龐大和復雜。基于人類生活的習慣，往往主要在某一片區域內活動，多數情況僅需要特定一個區域內的服務。根據中國架設的互聯網的結構，在同一片區域內的節點之間連通性相對較好，延遲相對較低，且容易達到較高的網速。因此本研究將會設計并實現一個基于區域共享的云存儲系統，該系統相比IPFS，具備更好更高效的區域服務性能和更低的區域服務成本，以及更輕量級、對硬件的要求更低的系統。

關鍵詞：云存儲;區塊鏈;共享模式;去中心化;IPFS

中圖分類號：TP311 ? ? ?文獻標識碼：A

文章編號：1009-3044（2021）31-0020-06

Design and Implementation of a Cloud Storage System Based on Regional Sharing

LIU Feng

（System R&D Department，PPLabs Networking Technology （Shanghai） Ltd.， Shanghai 200120， China）

Abstract： Using idle computer equipment and bandwidth to build a storage system based on a shared mode is a valuable research direction. A distributed cloud storage system based on this mode has the characteristics of using idle resources to improve the utilization of social resources. The IPFS （InterPlanetary File System， InterPlanetary File System） project has a more mature system and solution in this direction. IPFS is a decentralized distributed file system， and it is a distributed storage system for a global sharing model combined with blockchain technology. The system is very large and complex. Based on the habits of human life， activities tend to be mainly in a certain area， and most of the time， only services in a specific area are needed. According to the structure of the Internet set up in China， the connectivity between nodes in the same area is relatively good， the delay is relatively low， and it is easy to achieve higher network speeds. Therefore， this research will design and implement a cloud storage system based on regional sharing. Compared with IPFS， this system has better and more efficient regional service performance， lower regional service cost. And which lighter the system， lower the requirements.

Key words： cloud storage; blockchain; sharing mode; decentralization; IPFS

1 背景

早在1978年，美國的學者就提出了共享經濟的理念，自2010年以來，共享的模式從原本的小規模或者是無償模式逐漸演變出了一種新的模式，這種模式以獲得一定收益為目的，通過大型的中介平臺共享自己的閑置資源。例如 Uber、Airbnb 等平臺的運作模式。而閑置的資源并不局限于車輛、房屋等。閑置的計算機設備，有剩余流量的寬帶線路，閑置的存儲設備等，均是共享模式的新的角度。IPFS （星際文件系統）是由 Juan Benet 設計的，并于2014年開始由Protocol Labs 在開源社區的幫助下發展的一個網絡傳輸協議，其旨在創建持久且分布式存儲和共享文件。因為該項目是一個P2P、去中心化，基于密碼學技術的文件系統，所以其具備了安全性、隱私和可靠性方面的優點[1]。

而其為了滿足全網的服務能力，其對于每一個文件，根據文件的 CID 進行檢索，檢索范圍是整個系統，而其服務范圍會跨越國家，當 Miner（擁有閑置存儲和帶寬資源希望獲得收益的人，也稱礦工）和 User （用戶）不在相近的區域內，不僅兩個節點直接通信的質量不好，且其他模塊（verifer驗證者，indexer檢索者）也需要進行位于不同區域的通信[2-3]。從而不僅會對網絡的服務質量有影響，且會對于提高其他模塊的復雜程度，從而提高了對硬件的要求。由于所有的礦工和所有的用戶均在同一個系統內，因此整個系統負載的每秒交易量較大。容易出現交易擁堵的情況，其存儲市場的交易是區塊鏈的鏈上交易，因此盡管IPFS已經采取了相應的手段減小了 gas 費用（交易被記賬、打包成區塊的費用），但該費用仍然較為高昂。因此基于上述原因，本研究考慮到，實際應用場景下，大多數需求均為同一地區的服務，因此設計并實現了一個按區域劃分的系統，每個區域的存儲系統獨立運行。并且針對該場景，設計并實現了一個混合擴容區塊鏈的方案。

2 區塊鏈交易模塊的設計

2.1 混合擴容而成的區塊鏈交易模塊的設計思路

該模塊為本系統的交易模塊，提供錢包、交易以及結算的功能。即為本系統存儲部分提供交易的服務。由于存儲部分的交易結算的流程并不是一次性支付全部的費用，而是每成功進行一次時空證明后進行一次支付（該部分在3.1節中會介紹），因此每一個文件的存儲都會產生大量的交易，從而該系統最大能存儲的文件的個數會被交易模塊的 TPS （每秒交易次數）所限制。可知 TPS 的大小為該系統的可行性的重要指標。

如果使用傳統的區塊鏈公鏈條作為該系統的結算模塊，將會出現最大TPS難以滿足需求的情況，例如比特幣的交易效率為每秒僅支持7筆交易，而目前的以太坊也僅支持每秒 15 筆左右的交易[4]。并且還存在高昂的gas費用的問題。業界很多技術人員嘗試為區塊鏈擴容。例如比特幣中出現了依據信任程度打分的方式提高交易效率的方案[5]。而以太坊中目前擴容方案主要有兩類：Layer 1 擴容方案，即直接增加鏈上的交易處理能力，這種方式也被稱為鏈上擴容。常見的技術方案有： Sharding 和 DAG。Layer 2 擴容方案，即將鏈上的相當一部分工作量轉移到鏈下來完成。常見則是通過側鏈的方式進行。

由于本項目的交易的群體相對固定，用戶均為該共享的云存儲系統中的成員。因此可以通過Layer2的方案進行擴容，不必在公鏈（比特幣、以太坊等）上進行交易，通過2.4節實現中所示的跨鏈協議，支持將公鏈上賬戶的錢轉入側鏈和將側鏈上賬戶的錢轉回公鏈。而礦工以及用戶的存儲的收益和費用的交易均在側鏈中進行，從而TPS能力將不受制于公鏈的TPS，也不會因公鏈的擁堵造成該系統的阻塞。該側鏈僅由該系統參與者形成，因此節點數目遠小于公鏈。從而需要進行共識的節點數目也會較少，從而該鏈達成一致性的成本較低，從而gas費用較小。從而比直接使用以太坊作為提供合約的鏈擁有更好的效果，并且通過使用 POS 或者 POA 方式構建的側鏈 TPS 可以達到1000以上。

而該系統的應用場景是針對每一個區域提供服務，因此可以利用該特性繼續優化擴容該區塊鏈交易模塊，在原有的layer2的鏈的基礎上，繼續擴容，將每一個區域單獨劃分成一個交易子模塊zkStore。而在某個特定的區域內，所有的用戶和礦工均通過 zkStore 進行交易，而 zkStore 與真正的鏈不同，其并沒有獨立進行共識和交易的能力。其通過利用側鏈提供的合約功能，由Operator（交易收集器）收集一定的交易之后，生成 proof 提交側鏈的合約進行驗證。從而將區域內用戶和礦工之間的交易的 gas 費用降低。

基于上述，依據交易群體相對固定和交易發生在特定區域的性質進行的兩次擴容后，假設每進行M次結算交易之后用戶將會將余額進行存取，Operator 每收集N個交易進行一次驗證，則平均一次交易的gas費用滿足如下公式：

其中 Gasmainchain 為公鏈一次轉賬的花費， Gassidechain 為往側鏈合約中轉賬的開銷，Gasproof為側鏈一次驗證proof的花費，Gasoperator為Operator收集交易并打包的花費。而實際測試得N穩定在30，而M和用戶習慣有關系，通常使用情況下M大于1000，因此造成Gasmainchain 和 Gassidechain ?的開銷可以忽略，且 Gasoperator 的花費為 Gasmainchain 的1/30，Gasproof約等于3～5倍的Gasoperator，因此基于該結構下，整體Gas約為以太坊的1/25。

測試zkStore模塊的TPS，得到表2所示的zkStore的TPS測試數據。

系統可承載的最大zkStore的個數為：

其中Numzkstore為最大 zkStore 的個數，C為每秒一個 zkStore 造成側鏈的交易數量，TPSsidechain為側鏈的TPS，側鏈的 TPS 由側鏈的實現方式決定，使用 POS 或者 POA 的情況下側鏈的TPS通常可以達到1000。zkStore 剛開始運行的時候負載較低 TPS 測得的值會偏高，長時間穩定運行之后測得zkStore的TPS為3。

從而系統的總最大TPS滿足如下公式：

依據該公式，以及測試得到的數據，最大可并行11174個zkStore，也就是按照地理位置可以將服務劃分成11174個區域，每一個區域的均運行著TPS為3的zkStore模塊，系統理論情況下總共達最大可以到了33522的TPS，遠大于僅僅使用以太坊值為15的TPS。

2.2 側鏈的設計

若在該側鏈中采用類似公鏈的 POW（工作量證明）共識機制構建，通過算力來決定記賬權的歸屬，使用賬單內容和種子構成的塊的 hash 值的方式進行算力加密（該種子需要全系統構成的算力總量求解10分鐘才能得到的結果，從而讓偽造變得幾乎無法完成）。該方案最具有去中心的特性但伴隨的大量的算力浪費。且若考慮在本系統中采用該方案打造側鏈，會因為參與的節點不及公鏈的規模導致構成的算力規模不大，容易遇到51%攻擊的問題。且基于POW的側鏈會導致TPS不夠。因而不能使用 POW 的方式構建側鏈。如果通過基于 POS（權益證明）或 POA（權威證明）的方式打造側鏈，雖然犧牲了區塊鏈的一些去中心化的特性，但是可以大大地減小算力的消耗。POS 基于選舉驗證者的策略，驗證者需要在該系統中擁有一定數量的貨幣，而這些貨幣作為保證金，當驗證者驗證了虛假的交易的時候，其保證金將會受到懲罰，其失去的錢會大于通過虛假交易獲得的利潤。也可以通過POW的策略，通過抵押信譽的方式，進一步犧牲了一些去中心化的特征，但是不需要節點間的通信，且僅需要更少的算力，因此具備了更高的TPS和更低的Gas費用。

2.3 zkStore的設計

zkStore 是基于 zkRollup 的思想通過零知識證明的原理[6]實現的。上鏈前有兩種證明的策略，欺詐證明和有效性證明，而欺詐證明是一種樂觀的方式，認為很少會發生作惡的情況，因此不需要對每一筆交易耗費算力去做零知識證明，而是交易在上鏈之前都會“公示”一段時間，而這一段時間該交易的涉及人發現作惡行為，便可以提出欺詐證明，從而否決掉該交易，但是存在涉及 DDOS 攻擊等因素，導致交易無法進行提交欺詐證明導致缺乏安全。而有效性證明則是所有交易的上鏈必須提交零知識證明，開銷大但是安全性高[7]。因此 zkStore 選擇的是有效性證明方案。

基于 VitalikButerin 的研究[8]，零知識證明具體有兩種實現方法，交互性和非交互性，而交互性則是通過若干次詢問，讓欺詐的概率降到可以忽略的時候，從而信任對方。而 zkStore 則是采用非交互的方案。非交互方案并不是指完全不交互，而是僅交互數次便完成了零知識證明，雖然消耗額外的算力，但是證明的通信過程會變得簡潔。其本質原理是 ZKSNARK 中的核心思想，計算機無法在多項式的時間復雜度內求出橢圓曲線的對數問題從而確保安全[9]。

2.4 公鏈與側鏈之間的跨鏈協議

公鏈和側鏈之間的轉賬通過跨鏈協議實現，跨鏈使用 Validator 模塊完成。如圖1所示，公鏈和側鏈均有一個 Validato r模塊的賬號分別為 Manager 和 Holder，該模塊將會監聽公鏈上的所有往 Manager 轉賬的交易。當出現公鏈上的用戶往公鏈上的 Manager 賬戶轉賬，則會在側鏈的 Holder 賬戶中往側鏈的上該用戶對應的賬戶轉賬，即完成存款操作。當出現側鏈上用戶往側鏈上的 Holder 賬戶轉賬時，則會在公鏈的 Manager 賬戶中往公鏈的上該用戶對應的賬戶轉賬，即完成取款。所有公鏈的交易都是公開可查的，并且所有側鏈上的交易必須公開才能被確認，因此 Validator 偽造任何的交易記錄都會和公鏈上的交易記錄無法形成匹配，從而無法偽造，因此該方案具備安全性。

2.5 側鏈和 zkStore 的關系

側鏈上會運行大量的 zkStore，每一個 zkStore 負責該區域的交易的收集，而 zkStore 主要功能就是收集交易并打包生成 proof，然后提交至側鏈的合約進行校驗。zkStore 收集交易并進行零知識證明的運算都不需要通過側鏈，在鏈下完成。每一次的狀態轉變都需要提供零知識證明，由側鏈上的合約進行驗證，只有驗證通過才能更改狀態。合約不需要單獨校驗每筆交易的合法性，只需要校驗 proof 是否有效，從而降低了鏈上 gas 消耗。

1）zkStore 鏈下利用 Merkle tree[10]存儲賬戶狀態。

2）由 zkStore 中的交易匯總器（Operator）收集用戶的交易（TX1，TX2，TX3......）。

3）交易收集完成后 Operator 會執行每個交易（校驗余額，校驗nonce，校驗簽名，執行狀態轉換）。

4）當交易執行完成后會產生一個新的 Merkle tree Root。

5）為了證明鏈下狀態轉移是正確的，Operator 會在交易執行完成后生成一個零知識證明的 proof。

6）如圖2所示，Operator 把 prev state root，post state root，交易數據和 proof 證明提交至側鏈的合約。

7）合約校驗 proof ，通過后，將新的狀態寫入到鏈上。

3 云存儲系統的設計

3.1 整體設計思路

在存儲部分的目標是實現一個基于區域的、去中心化、低存儲費用、支持分享資源的系統。該系統與傳統的中心化存儲系統（百度網盤、騰訊網盤、115網盤等）不同，該系統不依賴傳統的中心化集群的機房的存儲和帶寬資源，而是利用零散在各地的空閑帶寬和存儲資源，提高了整個網絡的利用率。對比現有的中心存儲解決方案來說，隱私程度更高。該文件系統中，用戶無需暴露任何身份信息，通過不需要第三方參與的賬戶創建模式，保證了整個系統中的匿名性[11-12]。本系統與有相同研究方向的 IPFS 項目不同，本系統參考了部分 IPFS 的思想，并且在此基礎上進行了劃分區域，提高了服務的質量且降低了服務的成本。并且通過多副本的方式，提高了文件的可靠性。針對隱私性高的文件，將會在每一個Miner中存儲該文件的非全部分片，從而任何一個Miner均不能還原該文件，保證了文件的隱私性。通過參考IPFS實現的復制證明和時空證明的確認機制以及王玉秀[13]等人的 merkle樹校驗方案，實現高的安全性的檢驗策略，以防止女巫攻擊（Sybil Attack）、外部數據源攻擊（Outsourcing Attack）、生成攻擊（Generation Attack）的功能。存儲費用的支付參考微支付[14]的思路。該文件存放若干天，每一天都需要進行若干次時空證明。每一次Miner通過時空證明后支付一部分的費用方式取代一開始就付完全部費用的方式。從而降低無論哪一方發生作惡時的損失。從TPS角度考慮，本系統可以支持最大的文件數量滿足如下公式。

其中TPS表示系統總共的 TPS，由上文推導得為33522，Avgcnt ?表示平均文件的分片數量，D 表示每一天文件需要進行時空證明的次數。Avgcnt 通常平均為64，D 通常為1，因此該系統最大支持45254700個文件。

本系統可以用于多種場景，文件分享，文件的存儲備份，以及視頻類文件的點播等。

3.2 云存儲系統的結構

首先通過域名解析，讓 User 和 Miner 獲得一些 Bootstrap 節點的地址。從而接入整個系統。當用戶和Miner接入系統后，將會形成如下所示的結構（圖3僅代表各個角色之間的關系，并不代表數量關系，每一個角色在系統中都會有多個）。

如圖3所示為系統的整體結構，各個角色的功能如下介紹：

Indexer：索引者，主要功能是內置了一個 bitmap，bitmap 記錄每個文件的每個分片存儲在哪一個 Miner 上。User 上傳的文件是分成許多分片的，而這些分片會分散在許多 Miner 之間。從而需要 Indexer 進行索引。 該模塊由索引礦工運行。

Bootstrap：用于服務發現，提供接入系統的User 以及 Miner一個List（列表），該列表中包含了該系統中其他節點以及indexer和verifier的地址。

Verifier：用于驗證 Miner 以及 User 是否作惡。當 User 上傳了文件后，則需要通知 Verifier 去檢驗文件是否真實的存在于 Miner 中。而其中對于 Miner 是否真的存儲了這個文件以及Miner是否真的存在女巫攻擊等行為，通過復制證明和時空證明的方法實現。

Miner：礦工的客戶端，定期接受 Verifier 的檢查。接受到用戶的存儲請求后，接收用戶的文件分片并存儲。對于高隱私度的文件每一個Miner都會存儲每一個文件的部分分片。從而有兩個優點，第一是安全性高，任意一個 Miner 均不能獲得完整的文件數據，第二是傳輸效率高，文件可以從多個 Miner 同時下載。

User：用戶的客戶端，當上線的時候，會通過 Bootstrap 發現服務節點，然后需要上傳文件時，與 Indexer 協調分片信息以及每個片存放的 Miner，而后連接 Miner 通過直接上傳和 Miner間的互相的傳輸并完成本次存儲。分享則是產生分享碼，該碼可向其他 Miner 證明自己擁有文件的下載權利，從而別的 User 可以依據該分享碼進行下載。下載時，通過調度算法，從多個 Miner 同時下載。

3.3 系統傳輸模型

從實際角度分析，用戶側的流量成本是最高的，因此需要讓用戶側的傳輸量最少，在文件需要進行多副本存儲的情況下，不能讓用戶對這個文件進行多次上傳。采取如下策略，每當用戶上傳文件的一個分片的時候，通過先將該分片上傳至一個 Miner，然后通過 Miner 將該分片分發給其他的 Miner。由于是基于分片級別的轉發，當收到一個文件的分片的時候，將會立即進行轉發，因此上傳一個副本和上傳多個副本的耗時相差不大。用戶還需將該分片的 merkle 樹的樹頂結點的 Hash 值發送給 Verifier，而后最開始獲得分片以及獲得副本的Miner 需要對 Verifier 進行存儲證明和時空證明。從而使用戶上傳了一份文件但是完成了多副本的存儲。

而當文件較大的時候，會出現文件切片數目太多，從而會導致 indexer 的開銷較大，因為 indexer 需要支持查詢文件的每一個分片在哪些Miner上進行了存儲，分片數量太大將會需要indexer更大的存儲能力和更高效的查詢能力，并且針對每一個分片需要進行一次證明的生成，導致整個系統負擔太大。為了減小分片數量，如果將文件的每一個分片的大小設置的更大，則會導致傳輸的成本增加，且對于在線播放等功能造成較大的延遲問題。因此通過二級分片的方案。先對文件進行第一次切片，保證文件的存儲以第一級分片為單位進行，從而使indexer的索引僅僅需要提供第一級分片的索引即可。而傳輸的時候針對第一級分片進行第二次分片，從而減小傳輸時的延遲以及校驗的復雜程度。

該系統的冗余率主要取決于，indexer 的索引開銷，以及 miner 和 user 之間傳輸協議的開銷，通過 iptables 流量統計的方式，抓取該程序的通信數據，得到表3所示的數據，當傳輸的文件較小的時候，會導致因為 indexer 的索引開銷相比較大而造成較高的冗余率，當文件大小大于10M的時候，系統的冗余率趨于穩定。

3.4 下載調度算法

文件的下載有兩種調度算法，稀缺性優先和緊急度優先，分別對應兩種不同的場景。

稀缺性優先適用于普通的文件下載，普通的文件下載的時候，考慮到 Miner 可能會出現掉線或者被許多 User 連接導致網絡擁堵。因此分配給每一個空閑 Miner 下載的分片，選擇下載該 Miner 擁有的但是全局最稀缺的分片。從而使穩定性最高、完成時間的期望最短。其核心邏輯即為優先把稀缺的部分先下載完成，而非稀缺的部分如果出現一些 Miner 的波動，仍然可以通過別的 Miner 下載。

如下述例子所描述的場景，假設如分片1在 A、B、C、D 四個 Miner 中有備份，分片2在 B、C、D 三個 Miner 中有備份，分片3在 A、B 兩個 Miner 中有存儲，分片4在A中有存儲。因此基于稀缺性優先的策略。此時選擇 Miner A 下載分片4，因為分片4僅僅 A 中有備份，全局層面最稀缺。分配 B 下載分片3，因為僅僅在 A 與 B 中存在分片3，而 A 暫時為忙碌狀態（下載分片4），所以在此情況下分片2能下載的只有 Miner B，因此優先使用 MinerB，然后需要分配 Miner C 和 Miner D，而 Miner C 與 Miner D均擁有分片1與分片2，則會隨機分配從 C 中下載分片1，分片2將會從D下載。當有Miner下載完資源的時候，若還有新的分片也會按照上述策略進行繼續分配。

當用戶存儲的視頻類的文件，需要邊下邊播，則采用緊急度優先算法，緊急度優先算法的思路如下：

視頻類文件的切片存在于各個 Miner，同時從這些 Miner中進行多路下載，從而獲得一個較高的下載速度，而針對這個下載的過程，采用緊急度的優先調度算法。該策略是分別針對每一個分片進行決策，決策分片下載源時，首先計算所有 Miner 預期下載完成該分片的時間，選擇預計最早完成的 Miner 進行下載。而每一次選擇之后，該 Miner的任務列表中就加入了該分片的計劃，而下一個分片調度時，要在上一個分片的調度結果上進行調度。如圖6所示，每一個 tunnel 對應一個 Miner，默認對于該文件的前26個分片，這些分片在6個 Miner 上均有儲存。

當調度完成 a、b、c 分片的時候，d分片會在a、b、c調度結果上繼續計算，通過 tunnel1、tunnel2 下載，要先等待之前分片下載完成，因此預計完成為2s的時刻，而 tunnel3與tunnel4 則是速度較慢，分別要2s和4s時刻完成。tunnel5 則是在1.5秒時刻完成，tunnel6 為4s時刻完成，因此該分片將會調度到 tunnel5 下載。依據該算法在所有miner均擁有所有分片的情況下第N片分片的期望到達時刻為

其中size_i表示該分片i的大小，speed_i表示第i個下載鏈路的速度，m為總共Miner的數量。

4 結束語

本研究實現了一個基于區塊鏈技術的區域共享型云存儲系統，致力于為用戶在某個特定的區域內提供服務，在該場景下的區塊鏈擴容技術在實驗室環境以及理論推導均有較好的TPS指標。系統核心技術主要由傳輸策略、檢驗策略、區塊鏈擴容組成。可解決傳統中心化云存儲的數據不安全、價格太高的問題。

該系統還可以應用在流媒體平臺的音視頻加速、用戶數據的加密存儲等領域，可提升區塊鏈的底層平臺服務水平，進一步促進新型共識算法、鏈上數據保密等區塊鏈服務發展。

從模式上來看，本項目通過利用區塊鏈的激勵系統刺激閑置的海量帶寬與存儲資源的共享，解決了傳統的中心化云存儲的價格太高的問題。

用戶可以用更低廉的價格獲取更優質的服務。該研究旨在為云服務的模式提供新的思路，面向廣大開發者，可依賴本研究提供的去中心化存儲資源和思路，在上層構建出更豐富的存儲應用，比如去中心化的云計算，去中心化內容分發網絡等。

參考文獻：

[1] 苗齊.基于IPFS優化的區塊鏈物流信息平臺[J].電腦知識與技術，2021，17（11）：257-259.

[2] 丁博文，徐躍東，王亮.IPFS網絡內容和性能測量[J].計算機工程與應用：1-14.[2020-12-07].http：//kns.cnki.net/kcms/detail/11.2127.TP.20210420.1330.060.html.

[3] 石秋娥，周喜，王軼.基于去中心化索引的IPFS數據獲取方法研究[J].計算機工程與應用：1-10.[2020-12-07].http：//kns.cnki.net/kcms/detail/11.2127.TP.20210419.1450.073.html.

[4] 李雯林.以太坊吞吐量瓶頸分析與優化研究[D].湘潭：湘潭大學，2020.

[5] Lepom?ki L，Kanniainen J，Hansen H R.Retaliation in Bitcoin networks[J].Economics Letters，2021，203：109822.

[6] Miers I，Garman C，Green M，et al.Zerocoin：anonymous distributed E-cash from bitcoin[C]//2013 IEEE Symposium on Security and Privacy.May 19-22，2013，Berkeley，CA，USA.IEEE，2013：397-411.

[7] StarkWare.Validity Proofs vs.Fraud Proofs[EB/OL].[2020-10-23].https：//medium.com/starkware/validity-proofs-vs-fraud-proofs-4ef8b4d3d87a.

[8] VitalikButerin.Quadratic Arithmetic Programs： from Zero to Hero[EB].[2020-10-23].https：//medium.com/@VitalikButerin/quadratic-arithmetic-programs-from-zero-to-hero-f6d558cea649.

[9] 黎琳，張旭霞.zk-snark的雙線性對的國密化方案[J].信息網絡安全，2019（10）：10-15.

[10] 胡逸飛.基于區塊鏈的數字證書審計技術研究[D].合肥：中國科學技術大學，2019.

[11] 劉敖迪，杜學繪，王娜，等.區塊鏈技術及其在信息安全領域的研究進展[J].軟件學報，2018，29（7）：2092-2115.

[12] 祝烈煌，高峰，沈蒙，等.區塊鏈隱私保護研究綜述[J].計算機研究與發展，2017，54（10）：2170-2186.

[13] 王玉秀，楊青，程偉，等.基于格的線性同態簽名在云存儲數據動態驗證方案中的應用[J].中國科技論文，2016，11（20）：2381-2386.

[14] 劉怡.基于存儲證明的區塊鏈數字內容交易平臺設計與實現[D].北京：北京郵電大學，2020.

【通聯編輯：謝媛媛】

收稿日期：2021-06-20

基金項目：上海市科學技術委員會科研項目“基于區塊鏈的高可用分布式存儲與分發網絡平臺”（19511102300）

作者簡介：劉峰（1982—），男，上海交通大學碩士，主要研究方向為區塊鏈。