陳曉姣,林憲正,俞能海
比特幣區(qū)塊鏈的數(shù)據(jù)壓縮
陳曉姣1,2,林憲正1,2,俞能海1,2
(1. 中國科學技術(shù)大學網(wǎng)絡空間安全學院,安徽 合肥 230001;2. 中國科學院電磁空間信息重點實驗室,安徽 合肥 230001)
區(qū)塊鏈技術(shù)為數(shù)據(jù)存儲提供了一種透明、不可更改、去中心化的方法。但隨著數(shù)據(jù)量不斷增加,比特幣區(qū)塊鏈系統(tǒng)需要大量的存儲空間。分析了比特幣區(qū)塊的結(jié)構(gòu),針對比特幣交易中的部分字段,提出相應的編碼方案來減小比特幣區(qū)塊體積。實驗表明,所提方案可使區(qū)塊鏈體積減小18.13%。
區(qū)塊鏈;壓縮;熵;編碼
區(qū)塊鏈技術(shù)首次出現(xiàn)在比特幣研究[1]中,被用來實現(xiàn)分布式共識以及防止雙重花費。區(qū)塊鏈由一組節(jié)點使用共識協(xié)議(如工作量證明、權(quán)益證明、代理權(quán)益證明)維護[2]。每個全節(jié)點在本地存儲完整區(qū)塊鏈的復制,因此全節(jié)點可獨立完成交易查找、賬戶余額計算等工作[3]。然而,隨著比特幣區(qū)塊鏈包含的數(shù)據(jù)量不斷增加,區(qū)塊鏈體積不斷增大。例如,截至2019年12月,比特幣區(qū)塊鏈約占存儲空間260 GB。比特幣區(qū)塊鏈體積過大演變?yōu)榭缮炜s性問題[4],導致空白節(jié)點同步時間增長。同時,繁重的存儲負擔會增加維護全節(jié)點的成本,從而導致愿意成為全節(jié)點的節(jié)點數(shù)目減少。相應地,區(qū)塊鏈系統(tǒng)會被少數(shù)的全節(jié)點掌控,這與區(qū)塊鏈的去中心化思想相違背。
本文提出一種減小比特幣區(qū)塊鏈體積的方法。在分析比特幣區(qū)塊結(jié)構(gòu)的前提下,針對比特幣交易中的特定字段,本文提出相應的編碼方案減小交易體積,從而減小比特幣區(qū)塊體積。
隨著區(qū)塊鏈數(shù)據(jù)不斷增多,減小區(qū)塊鏈區(qū)塊體積方面的研究不斷增加。在比特幣白皮書中,Nakamoto[1]提出:一旦最近的交易被納入足夠多的區(qū)塊中,就可以丟棄它之前的交易數(shù)據(jù),以節(jié)省硬盤空間。由于Merkle根被包含在區(qū)塊哈希中,該樹的分支被清除后,并不會影響區(qū)塊的哈希數(shù)據(jù)。Géraud等[5]提出基于圖和格基約減技術(shù)的交易刪除方法。Bruce[6]提出迷你區(qū)塊鏈策略,最新的部分區(qū)塊鏈被保留,舊的交易則被刪除,因為賬戶樹維護了所有非空地址的余額平衡,所以不會影響賬戶余額平衡和錢幣歸屬。Palai等[7]提出了區(qū)塊摘要,一個區(qū)塊摘要可以看成包含它所有子區(qū)塊輸入以及未花費輸出的大型單筆交易。Nadiya等[8]提出基于比特幣區(qū)塊鏈的區(qū)塊摘要生成方法。Dorri等[9]提出一種存儲優(yōu)化的區(qū)塊鏈來使物聯(lián)網(wǎng)用戶移除它們舊的交易。Ateniese等[10]提出一種可重寫區(qū)塊鏈,任意數(shù)量的區(qū)塊可以被重寫并壓縮成較少的區(qū)塊。Rajasekhar等[11]提出基于比特幣的區(qū)塊可重寫方法。Marsalek等[12]提出一種雙鏈結(jié)構(gòu),使空白輕量節(jié)點可以下載更少的數(shù)據(jù)量完成同步。Kim等[13]提出一種基于實用拜占庭容錯(PBFT,practical Byzantine fault tolerance)的存儲壓縮共識算法,該算法可減小輕量節(jié)點所需存儲的區(qū)塊鏈體積。Boneh等[14]提出一種新的多重簽名策略來進行簽名壓縮和公鑰聚合,從而減小比特幣區(qū)塊體積。
一些研究嘗試將整個區(qū)塊鏈分成塊存儲在不同的節(jié)點中,以減小單個節(jié)點的存儲壓力。Perard等[15]提出基于糾刪碼的區(qū)塊鏈數(shù)據(jù)編碼方法。區(qū)塊可以被編碼成分片存儲在不同的節(jié)點中,同時可以從這些節(jié)點下載分片以恢復原先的區(qū)塊。Dai等[16]提出一種類似的網(wǎng)絡編碼方法。Abe等[17]提出一些存儲資源受限的節(jié)點組成集群,每個節(jié)點存儲由分布式哈希表(DHT,distributed hash table)算法得到的部分區(qū)塊鏈數(shù)據(jù)。同時,這些節(jié)點共同協(xié)作來驗證新的交易以及區(qū)塊。Xu[18]提出了section-blockchain,其中,每個節(jié)點都是平等的并且共同對網(wǎng)絡作出貢獻。每個節(jié)點只需要存儲區(qū)塊頭、一些區(qū)塊鏈分片以及數(shù)據(jù)庫閃照,并且不會影響整個區(qū)塊鏈的安全性。Liu等[19]提出一種雙鏈策略,使沒有足夠存儲空間的節(jié)點可以把數(shù)據(jù)存儲在其他節(jié)點。Mei等[20]提出一種基于余數(shù)系統(tǒng)的存儲優(yōu)化方法來減小每個節(jié)點的存儲量。Mcconaghy等[21]提出一種結(jié)合區(qū)塊鏈和現(xiàn)有分布式數(shù)據(jù)庫特性的可伸縮的區(qū)塊鏈數(shù)據(jù)庫。
Poon等[22]提出閃電網(wǎng)絡。閃電網(wǎng)絡實現(xiàn)了在離線環(huán)境下提供比特幣交易的方式,在支付通道打開后,參與方可離線發(fā)生任意數(shù)量的交易,而無須廣播到比特幣的網(wǎng)絡上,從而大大提高了交易速度,減輕了比特幣網(wǎng)絡的壓力。當支付通道關閉后,將交易的最終版本廣播到網(wǎng)絡中,從而減小總的交易體積。Decker等[23]提出一種雙向小額支付渠道,支持小額支付渠道自動更新,確保了端到端安全。
Pontiveros等[24]提出以太坊區(qū)塊鏈的壓縮方法。由于以太坊中的智能合約傾向使用相似的字節(jié)碼結(jié)構(gòu),他們提出將一種偽操作碼作為指針指向前一個智能合約中相同字節(jié)碼的位置。王守道等[25]提出了類似的操作碼來壓縮以太坊中的智能合約。Zheng等[26]提出基于星際文件系統(tǒng)(IPFS,inter-planetary file system)的區(qū)塊鏈存儲模型。具體的交易數(shù)據(jù)被存儲到IPFS系統(tǒng)中,只有IPFS哈希被打包到區(qū)塊中。Norvil等[27]提出類似的借助于IPFS系統(tǒng)減小以太坊區(qū)塊鏈的方法。
一些研究主要圍繞減小區(qū)塊鏈中交易的體積。在隔離見證[28]中,見證樹用來存儲交易中的腳本以及簽名,而不影響整個交易的效果。在可變交易[29]中,交易的結(jié)構(gòu)被重構(gòu),因此可以刪除其中無用的字段。在Lumino交易壓縮協(xié)議[30]中,同一個用戶的不同交易間可以采用增量壓縮來減小體積。Zima[31]提出用交易哈希前綴取代完整哈希以及可變長字節(jié)數(shù)表示輸出索引,從而減小交易輸入的體積。
比特幣區(qū)塊數(shù)據(jù)以網(wǎng)格格式存儲在磁盤上,單個文件不超過128 MB,每個文件中存儲若干個區(qū)塊。比特幣區(qū)塊之間由4 byte的魔數(shù)(0xD9B4BEF9)分隔。接下來是區(qū)塊大?。? byte),表示單個區(qū)塊的體積。一個完整的比特幣區(qū)塊由區(qū)塊頭和區(qū)塊體組成。區(qū)塊頭占80 byte,包含以下信息:版本號(4 byte)、前一區(qū)塊的哈希值(32 byte)、Merkle樹的根哈希值(32 byte)、時間戳(4 byte)、目標值(4 byte)、隨機數(shù)(4 byte)。區(qū)塊體包含交易信息,這些交易構(gòu)成Merkle樹,Merkle樹的樹根值存儲在區(qū)塊頭中。每個區(qū)塊的第一筆交易是coinbase交易,這是一筆為了讓礦工獲得獎勵及手續(xù)費的特殊交易。一筆完整的比特幣交易結(jié)構(gòu)如圖1所示,包含版本號(4 byte)、若干輸入、若干輸出以及鎖定時間(4 byte)。交易輸入包含引用交易哈希(4 byte)、引用交易輸出索引(32 byte)、輸入腳本信息以及序列號(4 byte)。交易輸出由比特幣數(shù)量(8 byte)以及輸出腳本信息組成。一筆交易中的每個輸入對應引用的之前一筆交易的一個輸出,該對應關系通過交易輸入中的引用交易哈希以及引用交易輸出索引表示。比特幣區(qū)塊主要由交易信息組成,且改變區(qū)塊頭內(nèi)部字段會導致區(qū)塊哈希變化,因此本文主要考慮比特幣區(qū)塊內(nèi)交易的壓縮。
本節(jié)基于對真實比特幣區(qū)塊數(shù)據(jù)的統(tǒng)計分析,提出相應的編碼方案。使用Bitcoin Core客戶端下載區(qū)塊鏈,下載時間為2019年12月27日15時19分,共609 973個區(qū)塊。熵可衡量平均信息量,計算如式(1)所示。其中,指概率空間中所有可能的樣本,x指該樣本出現(xiàn)的概率。
Figure 1 Composition of a bitcoin transaction
3.2.1 版本號
交易版本號占4 byte,表示該交易遵循的規(guī)則。統(tǒng)計數(shù)據(jù)包含487 589 740筆交易。其中,87.89%的交易版本號為1,12.11%的交易版本號為2,僅6筆交易使用其他版本號。根據(jù)式(1),計算得到熵為0.53 bit。編碼后,絕大多數(shù)版本號可用1 byte表示,當無法用1 byte表示時,采用5 byte表示,第一個字節(jié)置為0xFF,后4 byte保持不變。
3.2.2 引用交易哈希
交易輸入中的引用交易哈希占32 byte,用來指代所引用的交易。新編碼方案共40 bit,其中,前20 bit表示引用交易所在的區(qū)塊高度,后20 bit表示引用交易在區(qū)塊內(nèi)的索引。創(chuàng)世區(qū)塊的區(qū)塊高度為0,每個區(qū)塊中coinbase交易的交易索引為0。目前,比特幣區(qū)塊高度約600 000,用20 bit足夠表示。同時,統(tǒng)計數(shù)據(jù)中單個比特幣區(qū)塊中最大交易數(shù)量為12 239,20 bit足夠表示。
3.2.3 引用交易輸出索引
交易輸入中引用交易輸出索引占4 byte,表示引用輸出在引用交易中的位置。統(tǒng)計數(shù)據(jù)中最大的交易輸出數(shù)量為13 107,可用14 bit表示。根據(jù)式(1),計算得到熵為1.26 bit。編碼后,輸出索引可用1 byte或2 byte表示。前2 bit為00時,后6 bit表示輸出索引,可表示0~63,前2 bit為11時,2字節(jié)中的后14 bit表示輸出索引。
3.2.4 序列號
交易輸入中序列號占4 byte,用來覆蓋在交易鎖定時間之前失效的交易。統(tǒng)計數(shù)據(jù)中包含1 196 011 166個序列號,其中,78.10%為0xFFFFFFFF,18.57%為0xFFFFFFFE,2.91%為0xFFFFFFFD。根據(jù)式(1),計算得到熵為0.92 bit。編碼后,序列號可用1 byte或5 byte來表示。當?shù)?字節(jié)為0xFF、0xFE、0xFD時,分別表示0xFFFFFFFF、0xFFFFFFFE、0xFFFFFFFD這3種情況;當?shù)?字節(jié)為0時,表示之后的4 byte為完整的序列號。
3.2.5 比特幣數(shù)量
交易輸出中比特幣數(shù)量占8 byte。統(tǒng)計數(shù)據(jù)中包含1 298 644 580個比特幣數(shù)量。從圖2可以看出,比特幣數(shù)量集中在106聰。根據(jù)式(1),計算得到熵為20.72 bit。編碼方案根據(jù)第1 byte(<0xFD,=0xFD,=0xFE,=0xFF)可將編碼方案分為1 byte,3 byte,5 byte,9 byte。經(jīng)過統(tǒng)計,3.29%的比特幣數(shù)量用1 byte表示,14.64%的用3 byte表示,80.86%的用5 byte表示,1.21%的用9 byte表示。
圖2 比特幣數(shù)量分布
Figure 2 Distribution of bitcoin amount
3.2.6 鎖定時間
交易中鎖定時間占4 byte,表示該交易能被加到區(qū)塊鏈中最早的時間。統(tǒng)計數(shù)據(jù)中83.36%的鎖定時間為0,表示立即執(zhí)行。如果鎖定時間小于或等于5億,則該字段表明區(qū)塊高度,表明該交易在指定區(qū)塊高度前不會被包含在區(qū)塊鏈中。如果鎖定時間大于5億,則為UNIX時間戳(從1970年1月1日以來的秒數(shù)),表明該交易在指定時間點前不會被包含在區(qū)塊鏈中。根據(jù)式(1),計算得到熵為3.55 bit。編碼后,鎖定時間為0時,用1 byte表示,其余用5 byte表示,其中,第1個字節(jié)置為0xFF,其余保持不變。
每個區(qū)塊中的coinbase交易不進行壓縮。該壓縮算法包含比特幣交易中6個字段的編碼替換,其中,在替換引用交易哈希字段前,需先查詢該引用交易所在區(qū)塊高度及其塊內(nèi)索引,具體算法如算法1所示。[]表示高度在的區(qū)塊。REP([],tx.version,encode(tx.version))表示用編碼后的版本號替換原先的版本號,INQ(in.hash,A)表示根據(jù)交易輸入中引用交易哈希查詢得到引用交易所在的區(qū)塊高度以及該交易在塊內(nèi)的索引。
算法1 壓縮算法
輸入比特幣區(qū)塊鏈,區(qū)塊數(shù)量
輸出壓縮后的區(qū)塊鏈
與壓縮算法類似,該解壓縮算法包含比特幣交易中6個字段的解碼替換,其中,在替換編碼后的引用交易哈希字段前,需先計算引用交易哈希,具體的解壓縮算法如算法2所示。REP(D[], tx.version,decode(tx.version))表示用解碼后的版本號代替之前編碼的版本號,T←FIND (in. newindex, D)表示根據(jù)交易輸入中的新指針找到引用交易的內(nèi)容。由于解壓縮過程是從前往后依次進行,此時查找到的引用交易已經(jīng)解壓完成,其交易哈??蓪ζ鋬?nèi)容直接進行兩次SHA256運算得到。
算法2 解壓縮算法
輸入 壓縮后的區(qū)塊鏈,區(qū)塊數(shù)量
輸出 解壓后的區(qū)塊鏈
首先,將算法1應用于區(qū)塊鏈文件blk00004測量壓縮時延,該文件包含6 395個區(qū)塊,1 675 996筆交易。算法1中INQ功能通過構(gòu)建本地數(shù)據(jù)庫完成。該實驗在配置為2.2 GHz Intel Xeon Gold 5120T中央處理器以及32 GB 2400 MHz DDR4內(nèi)存的服務器上完成。文件blk00004的初始大小為131 041 kB,壓縮后大小為108 146 kB,相應的壓縮率為82.53%,壓縮時間為140 s。之后,將算法1應用于獲取的完整比特幣區(qū)塊鏈,包含609 973個區(qū)塊,487 589 740筆交易。圖3表示壓縮率隨壓縮的區(qū)塊個數(shù)的變化。當壓縮的區(qū)塊個數(shù)較小時,壓縮率不穩(wěn)定,隨著區(qū)塊個數(shù)逐漸增大,壓縮率趨近于81.87%,表明該壓縮方案可減小比特幣區(qū)塊鏈體積18.13%。圖4表示壓縮率與區(qū)塊中包含交易筆數(shù)的關系。當一個區(qū)塊只包含一筆交易時,該交易為coinbase交易,無法壓縮。由于區(qū)塊頭僅占據(jù)80 byte,當單個區(qū)塊中包含的交易筆數(shù)逐漸增大時,它對壓縮率的影響可以忽略。如圖4所示,大多數(shù)區(qū)塊的壓縮率接近81%。
圖3 壓縮率隨區(qū)塊數(shù)量變化
Figure 3 Compression rate of various numbers of bitcoin blocks
圖4 壓縮率隨交易數(shù)量變化
Figure 4 Compression rate of bitcoin blocks containing various numbers of transactions
如圖5所示,本文方案可用于減小空白節(jié)點同步時所需帶寬。當新的空白節(jié)點加入網(wǎng)絡,該節(jié)點需從全節(jié)點下載區(qū)塊鏈數(shù)據(jù)。全節(jié)點首先將比特幣數(shù)據(jù)進行壓縮再進行傳輸。當節(jié)點接收到全部數(shù)據(jù)后,對數(shù)據(jù)進行解壓縮,恢復出完整的區(qū)塊鏈數(shù)據(jù)并保存在本地。
圖5 空白節(jié)點同步
Figure 5 Blank node synchronization
如圖6所示,全節(jié)點可采用算法1減小本地所需的區(qū)塊鏈存儲空間。考慮到分叉的可能,保留最新的6個區(qū)塊不進行壓縮。它維護了交易池和未花費交易輸出(UTXO,unspent transaction output)集合,在進行壓縮存儲前,對需壓縮的區(qū)塊鏈進行掃描,確保UTXO集合的正確性,之后和普通全節(jié)點一樣,使用現(xiàn)有比特幣協(xié)議查詢本地信息,對新交易以及新區(qū)塊進行驗證,完成共識,且不會帶來額外開銷。同時,簡易支付驗證(SPV,simplified payment verification)節(jié)點可以從節(jié)點獲取足夠信息來驗證交易。
圖6 全節(jié)點本地存儲
Figure 6 Local storage of a full node
在比特幣區(qū)塊鏈中,交易哈希被用來構(gòu)建Merkle樹。交易哈希由對交易內(nèi)容進行兩次SHA256運算得到Hash←SHA256(transaction content)。由于算法1更改了交易內(nèi)容,交易哈希無法直接根據(jù)其內(nèi)容進行哈希運算得到。必須先恢復其交易內(nèi)容,才可以進行哈希計算。由于coinbase交易未被壓縮,必須追溯到與該交易相關的所有coinbase交易來恢復交易內(nèi)容。
如算法3所示,壓縮后的交易哈希計算主要由兩步組成。首先,所有與該交易相關的交易輸入在棧1的輔助下被壓入棧2中,這個過程類似于叉樹的遍歷,它的葉子節(jié)點是所有與之相關的coinbase交易。然后,棧3用來存儲每一步中恢復出的哈希值。最后,恢復出完整的交易內(nèi)容,其哈??芍苯舆M行兩次SHA256運算得到。其中,S1.push(E.inputs.newindex)表示將交易中所有輸入中的新交易哈希索引壓入棧1中?!鸉IND()表示根據(jù)交易輸入中的新哈希索引找到與之對應的交易內(nèi)容。hash←CALHASH(,3,T.inputsnum)表示根據(jù)交易中交易輸入的數(shù)量,從棧3中彈出相應數(shù)量的交易哈希進行替換,同時對交易中編碼壓縮的部分進行相應解碼替換,然后對補全的交易進行兩次SHA256運算得到哈希值。3.pop(T.inputsnum)表示棧3執(zhí)行與交易輸入數(shù)量對應的彈出操作。
算法3 交易哈希計算算法
輸入 壓縮后的交易
輸出 交易哈希
SPV節(jié)點是一種只存儲區(qū)塊頭的輕量節(jié)點,該類型節(jié)點需要從全節(jié)點獲取足夠信息來完成交易驗證,信息包括一條連接交易哈希與區(qū)塊頭中Merkle根哈希的Merkle路徑。SPV獲取該信息后,根據(jù)Merkle路徑計算當前待驗證交易所在區(qū)塊的Merkle根哈希,然后與本地存儲的區(qū)塊頭信息進行比較,從而定位到待驗證交易所在的區(qū)塊位置。如果該交易所在區(qū)塊的區(qū)塊深度至少為6,則認為該交易是有效的。由于上述壓縮算法更改了交易內(nèi)容,每個交易哈希都需通過算法3來構(gòu)建Merkle路徑。
本文在分析比特幣區(qū)塊結(jié)構(gòu)的前提下,針對比特幣交易中部分字段提出相應編碼方案,減小比特幣交易體積,從而減小比特幣區(qū)塊鏈體積。在未來工作中,將會提出一種基于上述編碼方案的新區(qū)塊鏈構(gòu)建方案,該方案可解決由哈希指針引起的碰撞問題。例如,在比特幣區(qū)塊鏈中,兩筆coinbase交易(分別位于塊91 812和塊91 842)有相同的交易哈希。這就導致依靠現(xiàn)有的比特幣協(xié)議無法解決這兩筆交易的“雙花”問題。同時該方案可拓展為通用的區(qū)塊鏈存儲改進方案,使用指針替換區(qū)塊鏈中重復出現(xiàn)的數(shù)據(jù)內(nèi)容,并可對定長字段進行數(shù)據(jù)統(tǒng)計,若計算所得熵小于定長,則可考慮用可變長編碼替換。
[1]NAKAMOTO S. Bitcoin: a peer-to-peer electronic cash system[R]. 2008.
[2]章峰, 史博軒, 蔣文保. 區(qū)塊鏈關鍵技術(shù)及應用研究綜述[J]. 網(wǎng)絡與信息安全學報, 2018, 4(4): 22-29.
ZHANG F, SHI B X, JIANG W B. Review of key technology and its application of blockchain[J]. Chinese Journal of Network and Information Security, 2018, 4(4): 22-29.
[3]沈鑫, 裴慶祺, 劉雪峰. 區(qū)塊鏈技術(shù)綜述[J]. 網(wǎng)絡與信息安全學報, 2016, 2(11): 11-20.
SHEN X, PEI Q Q, LIU X F. Survey of block chain[J]. Chinese Journal of Network and Information Security, 2016, 2(11): 11-20.
[4]XIE J, YU F R, HUANG T, et al. A survey on the scalability of blockchain systems[J]. IEEE Network, 2019, 33(5): 166-173.
[5]GéRAUD R, NACCACHE D, RO?IE R. Twisting lattice and graph techniques to compress transactional ledgers[C]//International Conference on Security and Privacy in Communication Systems. 2017: 108-127.
[6]BRUCE J D. Purely P2P crypto-currency with finite mini-blockchain[R]. 2013.
[7]PALAI A, VORA M, SHAH A. Empowering light nodes in blockchains with block summarization[C]//2018 9th IFIP International Conference on New Technologies, Mobility and Security (NTMS). 2018: 1-5.
[8]NADIYA U, MUTIJARSA K, RIZQI C Y. Block summarization and compression in bitcoin blockchain[C]//2018 International Symposium on Electronics and Smart Devices (ISESD). 2018: 1-4.
[9]DORRI A, KANHERE S S, JURDAK R. MOF-BC: a memory optimized and flexible blockchain for large scale networks[J]. Future Generation Computer Systems, 2019, 92: 357-373.
[10]ATENIESE G, MAGRI B, VENTURI D, et al. Redactable blockchain or rewriting history in bitcoin and friends[C]//2017 IEEE European Symposium on Security and Privacy (EuroS&P). 2017: 111-126.
[11]RAJASEKHAR K, YALAVARTHY S H, MULLAPUDI S, et al. Redactable blockchain and it's implementation in bitcoin[J]. International Journal of Engineering & Technology, 2018, 7(1): 401-405.
[12]MARSALEK A, ZEFFERER T, FASLLIJA E, et al. Tackling data inefficiency: compressing the bitcoin blockchain[C]//2019 18th IEEE International Conference on Trust, Security and Privacy in Computing And Communications/13th IEEE International Conference on Big Data Science and Engineering (TrustCom/BigDataSE). 2019: 626-633.
[13]KIM T, NOH J, CHO S. SCC: storage compression consensus for blockchain in lightweight IoT network[C]//2019 IEEE International Conference on Consumer Electronics (ICCE). 2019: 1-4.
[14]BONEH D, DRIJVERS M, NEVEN G. Compact multi-signatures for smaller blockchains[C]//International Conference on the Theory and Application of Cryptology and Information Security. 2018: 435-464.
[15]PERARD D, LACAN J, BACHY Y, et al. Erasure code-based low storage blockchain node[C]//2018 IEEE International Conference on Internet of Things (iThings) and IEEE Green Computing and Communications (GreenCom) and IEEE Cyber, Physical and Social Computing (CPSCom) and IEEE Smart Data (SmartData). 2018: 1622-1627.
[16]DAI M, ZHANG S, WANG H, et al. A low storage room requirement framework for distributed ledger in blockchain[J]. IEEE Access, 2018, 6: 22970-22975.
[17]ABE R, SUZUKI S, MURAI J. Mitigating bitcoin node storage size by DHT[C]//Proceedings of the Asian Internet Engineering Conference. 2018: 17-23.
[18]XU Y. Section-Blockchain: a storage reduced blockchain protocol, the foundation of an autotrophic decentralized storage architecture[C]//2018 23rd International Conference on Engineering of Complex Computer Systems (ICECCS). 2018: 115-125.
[19]LIU T, WU J, LI J, et al. Secure and balanced scheme for non-local data storage in blockchain network[C]//2019 IEEE 21st International Conference on High Performance Computing and Communications, IEEE 17th International Conference on Smart City, IEEE 5th International Conference on Data Science and Systems (HPCC/SmartCity/DSS). 2019: 2424-2427.
[20]MEI H, GAO Z, GUO Z, et al. Storage mechanism optimization in blockchain system based on residual number system[J]. IEEE Access, 2019, 7: 114539-114546.
[21]MCCONAGHY T, MARQUES R, MüLLER A, et al. BigchainDB: a scalable blockchain database[R]. 2016.
[22]POON J, DRYJA T. The bitcoin lightning network: scalable off-chain instant payments[R]. 2016.
[23]DECKER C, WATTENHOFER R. A fast and scalable payment network with bitcoin duplex micropayment channels[C]//Symposium on Self-Stabilizing Systems. 2015: 3-18.
[24]PONTIVEROS B B F, NORVILL R, STATE R. Recycling smart contracts: compression of the ethereum blockchain[C]//2018 9th IFIP International Conference on New Technologies, Mobility and Security (NTMS). 2018: 1-5.
[25]王守道, 蔣玉明, 胡大裟. 基于區(qū)塊鏈的智能合約壓縮存儲方法[J]. 現(xiàn)代計算機, 2019(9): 42-46.
WANG S D, JIANG Y M, HU D S. Smart contract compression storage method based on blockchain[J]. Modern Computer, 2019(9): 42-46.
[26]ZHENG Q, LI Y, CHEN P, et al. An innovative IPFS-based storage model for blockchain[C]//2018 IEEE/WIC/ACM International Conference on Web Intelligence (WI). 2018: 704-708.
[27]NORVILL R, PONTIVEROS B B F, STATE R, et al. IPFS for reduction of chain size in Ethereum[C]//2018 IEEE International Conference on Internet of Things (iThings) and IEEE Green Computing and Communications (GreenCom) and IEEE Cyber, Physical and Social Computing (CPSCom) and IEEE Smart Data (SmartData). 2018: 1121-1128.
[28]LOMBROZO E, LAU J, WUILLE P. BIP 141: segregated witness[R]. 2015.
[29]ZANDER T. Flexible transactions[R]. 2016.
[30]LERNER S D. Lumino transaction compression protocol(LTCP)[R]. 2017.
[31]ZIMA M. Inputs reduction for more space in bitcoin blocks[C]//2018 Crypto Valley Conference on Blockchain Technology (CVCBT). 2018: 112-115.
Compression of bitcoin blockchain
CHEN Xiaojiao1,2, LIN Xianzheng1,2, YU Nenghai1,2
1. School of CyberScience, University of Science and Technology of China, Hefei 230001, China 2. Key Laboratory of Electro-magnetic Space Information, Chinese Academy of Sciences, Hefei 230001, China
The blockchain provides an immutable, transparent, and decentralized method for data storage. However, as the volume of data gradually increases, the public blockchain system requires significant storage space. The bitcoin block's structure was analyzed. A method was introduced to compress the size of transactions in the bitcoin blockchain by encoding specific fields. Experiment shows that the proposed method can reduce the storage space of the bitcoin blockchain by 18.13%.
blockchain, compression, entropy, encode
TP311
A
10.11959/j.issn.2096?109x.2021008
2020?01?14;
2020?03?18
林憲正,sjlin@ustc.edu.cn
安徽省自然科學基金(BJ2100330001)
The Natural Science Foundation of Anhui Province, China (BJ2100330001)
陳曉姣, 林憲正, 俞能海. 比特幣區(qū)塊鏈的數(shù)據(jù)壓縮[J]. 網(wǎng)絡與信息安全學報, 2021, 7(1): 76-83.
CHEN X J, LIN X Z, YU N H. Compression of bitcoin blockchain[J]. Chinese Journal of Network and Information Security, 2021, 7(1): 76-83.
陳曉姣(1995? ),女,江蘇鎮(zhèn)江人,中國科學技術(shù)大學碩士生,主要研究方向為區(qū)塊鏈。
林憲正(1981? ),男,中國臺灣人,博士,中國科學技術(shù)大學研究員、博士生導師,主要研究方向為信道編碼算法、應用于存儲系統(tǒng)的糾刪碼設計。
俞能海(1964? ),男,安徽無為人,博士,中國科學技術(shù)大學教授、博士生導師,主要研究方向為多媒體信息檢索、圖像處理與視頻通信、數(shù)字媒體內(nèi)容安全。