喻 輝 張宗洋,2 劉建偉
1(北京航空航天大學電子信息工程學院 北京 100191) 2(信息安全國家重點實驗室(中國科學院信息工程研究所) 北京 100093) (yhsteven@outlook.com)
2017-06-09;
2017-08-02
中國科學院信息工程研究所信息安全國家重點實驗室開放課題(2017-MS-02) This work was supported by the Fund of the State Key Laboratory of Information Security (Institute of Information Engineering, Chinese Academy of Sciences) (2017-MS-02).
張宗洋(zongyangzhang@buaa.edu.cn)
比特幣區(qū)塊鏈擴容技術研究
喻 輝1張宗洋1,2劉建偉1
1(北京航空航天大學電子信息工程學院 北京 100191)2(信息安全國家重點實驗室(中國科學院信息工程研究所) 北京 100093) (yhsteven@outlook.com)
比特幣是中本聰(Nakamoto)于2008年提出的數(shù)字貨幣,它具有去中心化、跨國界和發(fā)行總量固定等特性,現(xiàn)在已經成為使用最廣泛的數(shù)字貨幣之一.然而,比特幣設計初期的一些人為限制,導致現(xiàn)有網絡處理交易的速率十分有限,最近交易處理能力已經接近上限,交易確認時間顯著增加.這不僅嚴重影響比特幣的使用體驗,進而限制使用范圍,而且對比特幣的設計提出更高的要求.針對比特幣所面臨的交易處理性能挑戰(zhàn),以提升區(qū)塊鏈容量為目標對比特幣展開深入研究.首先,分析比特幣當前網絡狀態(tài),根據比特幣交易數(shù)據,統(tǒng)計交易延遲情況;其次,針對鏈上擴容方案,分析可行性,研究擴容效果;再次,針對鏈下擴容方案,分析作用原理,研究擴容效果;最后,分析鏈上鏈下擴容方案優(yōu)缺點,提出適應社區(qū)的可行的比特幣擴容路線方案.最新比特幣擴容的進展進一步證明了我們結論的正確性.
比特幣;區(qū)塊鏈;擴容;見證隔離;閃電網絡
比特幣是一種去中心化的數(shù)字貨幣,最早由中本聰(Nakamoto)于2008年10月提出[1],其目的是避免傳統(tǒng)金融體系中存在中心機構可能帶來的風險.和傳統(tǒng)電子貨幣相比,比特幣具有系統(tǒng)健壯性強、使用便捷和安全性高等優(yōu)勢.自從被推出以來,比特幣正受到越來越多的關注[2].隨著比特幣的廣泛使用,比特幣設計之初的一些缺陷逐漸顯露出來,其中非常嚴重的缺陷就是區(qū)塊鏈容量不足.
從2012年開始,平均區(qū)塊大小不斷增加.在2016年年中左右,區(qū)塊容量已經接近1 MB上限[3].這意味著一些交易將不能及時地被收集到區(qū)塊中,交易雙方需要等待更長的時間確認交易.如果交易頻次繼續(xù)增加而區(qū)塊容量保持不變,那么一些交易可能永遠也不能入塊.因此,這一問題將會嚴重影響比特幣的使用體驗.
文獻[4]針對研究交易延遲問題,分析2016年5月交易入塊情況,結果表明:43%的交易在發(fā)布超過1 h后仍未進入區(qū)塊鏈.文獻[5]列舉出比特幣等密碼貨幣的研究遠景和面臨的各種挑戰(zhàn),其中之一就是可擴展性問題.由于改變比特幣規(guī)則需要引入分叉,同時造成各方面的影響,因此比特幣擴容是一個非常復雜的問題.
文獻[6]指出,將交易雜湊值代替交易數(shù)據可以提升網絡處理交易的能力.同時,該文獻主張以修改區(qū)塊鏈本身結構的方式達到擴容的目的.文獻[7]研究區(qū)塊在網絡中的傳播情況,指出過大區(qū)塊需要更長的時間傳播至整個網絡,傳播延遲將不再遠小于區(qū)塊間隔,這會影響網絡的共識機制,造成高孤塊率等問題.同時作者指出當前網絡未被充分利用,可以改進比特幣協(xié)議以提高網絡利用效率.文獻[8]引入定量框架分析基于工作量證明的區(qū)塊鏈安全和性能,并分析了區(qū)塊參數(shù)改變對于比特幣系統(tǒng)安全性的影響.作者得出結論:在區(qū)塊大小是1 MB的前提下,將區(qū)塊間隔降低至1 min不會顯著影響比特幣區(qū)塊鏈的安全性.
為解決比特幣區(qū)塊鏈容量不足帶來的問題,比特幣社區(qū)已經提出多個解決方案,下面依次介紹代表性方案.
2015年6月,Andresen在比特幣改進建議(bitcoin improvement protocol)BIP101中提出區(qū)塊容量限制在未來一段時間內以可預測方式增大[9];同月,Garzik在BIP102中提出區(qū)塊容量上限一次性從1 MB增長到2 MB[10];同期,相關人員提出很多類似的直接提高區(qū)塊鏈上限的改進建議[11-12].由于交易數(shù)目與區(qū)塊大小成正比,因此通過增大單個區(qū)塊的大小,可以使得更多的交易被容納.
2015年12月,Lombrozo,Lau和Wuille在BIP141中提出的見證隔離(segregated witness)技術也對區(qū)塊鏈擴容有幫助[13].當前的比特幣交易中,交易數(shù)據與簽名數(shù)據保存于同一數(shù)據結構中.見證隔離則將簽名數(shù)據從交易中分離出來,組成新的結構另行保存.由于舊節(jié)點不能解析這些新的數(shù)據,因此他們認為區(qū)塊大小要小于新節(jié)點,這意味著區(qū)塊實際大小可以超過1 MB.
2015年,Poon和Dryja提出閃電網絡方案,將頻繁的小額支付利用事先建立的通道離鏈完成[14].這種方案可以避免大量小額交易占用區(qū)塊鏈容量;文獻[15]提出了建立雙向微支付通道的協(xié)議,允許用戶建立離線通道,實現(xiàn)無延遲的實時支付,同時保證了端到端的安全性;文獻[16]對上述方案作了改進,提出了新的支付通道Sprites.利用狀態(tài)通道,Sprites將閃電網絡在最壞情況下的抵押開銷復雜度大為降低,由O(Δ)變?yōu)镺(+Δ),其中,Δ分別代表通道個數(shù)和鏈上交易確認時間;文獻[17]引入Teechan,它是一種全雙工的支付通道框架,可直接部署在現(xiàn)有區(qū)塊鏈上,比閃電網絡具有更高的交易容量和更低的交易延遲.但是,它需要利用具備可信執(zhí)行環(huán)境的安全硬件,例如Intel SGX,因此會額外增加開銷;Teechan的升級版Teechain實現(xiàn)了沿路徑支付,允許未直接建立連接的用戶交換資金[18].
可見,針對區(qū)塊鏈容量不足的情況,社區(qū)和學術界都已經提出多個擴容方案.但是依然存在區(qū)塊鏈統(tǒng)計數(shù)據不直觀、鏈上擴容方案缺乏可行性分析、見證隔離對區(qū)塊容量的貢獻不明確和社區(qū)意見不統(tǒng)一等問題.
本文主要貢獻有3個方面:
1) 針對區(qū)塊容量達到上限的問題,分析當前比特幣網絡中交易確認狀態(tài).通過抓取2017年1~3月的比特幣交易數(shù)據,統(tǒng)計分析交易確認理論時間和實際時間的差別.已經進入區(qū)塊的交易中,有16%等待時間超過1 h,甚至有1%等待時間超過1 d.另外,待確認交易(unconfirmed transaction)池不斷擴大,一度超過110 MB.
2) 針對鏈上擴容方案爭論,分析方案的優(yōu)點和缺點.鏈上擴容提倡增大區(qū)塊容量上限,此方案對改善交易延遲效果顯著,將區(qū)塊容量上限設定為2 MB,即可解決當下交易延遲問題.但考慮到當前網絡情況,為避免過高的孤塊產生率,最大區(qū)塊不應超過4MB.鏈上擴容優(yōu)勢在于見效快,但是無限擴容易造成中心化.
3) 針對鏈下擴容方案的不確定性,分析鏈下擴容效果.鏈下擴容方案也附帶有鏈上擴容效果,基于當前交易比例的統(tǒng)計顯示,見證隔離最多可以將區(qū)塊容量提升83%.基于見證隔離的閃電網絡技術,完全部署可以極大提高交易處理能力,縮短確認時間.鏈下擴容可以達到近乎無限的交易處理能力,但網絡建立需要時間.
本節(jié)簡要介紹比特幣的相關背景知識,包括比特幣的交易、區(qū)塊鏈形式和工作量證明機制等,詳細的介紹可以參考文獻[19-20].
1) 比特幣交易.比特幣是一種基于交易的數(shù)字貨幣,一切行為均通過交易完成.每一項交易均有至少一個輸入和至少一個輸出.每一個交易指向另一個交易的輸出,用于表明資金的來源,僅當交易被正確簽名之后,驗證方可通過.交易可以包含多個輸入和多個輸出,從而起到拆分與合并資金的功能.
2) 比特幣腳本.交易輸出中存在scriptPubKey腳本,在標準P2PKH交易中,scriptPubKey包含收款人的公鑰雜湊值.交易輸入中存在scriptSig腳本,包含公鑰和簽名等信息.驗證交易時,依次運行scriptSig腳本與前一交易中的scriptPubKey腳本,如果成功運行并在棧頂設置true,即相當于成功驗證交易發(fā)起人的公鑰與簽名,那么證明交易發(fā)起人具備對應輸出的使用權限,驗證通過[21].在BIP16中,P2SH類型的交易被引入.該類型允許輸出中不指明收款人公鑰雜湊,并用一段腳本的雜湊替代.這種交易將復雜性從輸出腳本轉移到了輸入腳本,使得付款更加方便,利于多重簽名等交易普及[22].
3) 比特幣賬本.基于交易的數(shù)字貨幣存在的最大問題是雙花(double-spending),即支付者生成2筆交易,共用同一項輸出.解決辦法之一是維護一個任何人都可以訪問的賬本,記錄所有歷史交易,使收款方可以查看一項輸出是否已被使用過.比特幣使用梅克爾樹與區(qū)塊鏈構建全局賬本.當交易雙方需要交易快速完成時,收款方會選擇在交易未進入區(qū)塊鏈時即接受,這會帶來額外的雙花風險[23].只要攻擊者算力資源不超過全網算力的50%,此風險隨時間增長呈指數(shù)級下降[1].
4) 梅克爾樹.梅克爾樹是一種二叉樹,其葉子節(jié)點用于存放數(shù)據,其他節(jié)點為2個子節(jié)點串聯(lián)的雜湊值.比特幣將交易雜湊值存放于梅克爾樹葉子節(jié)點中,任何一筆交易的變動都將影響到梅克爾樹根的值.因此,只要保留梅克爾樹根的值,即可驗證每一筆交易是否被篡改[19].
5) 區(qū)塊鏈.每個區(qū)塊中包含一個梅克爾樹根,作為當前區(qū)塊所有交易的指代.除此之外,區(qū)塊中還包含上一個區(qū)塊頭的雜湊值,作為此前區(qū)塊的指代.區(qū)塊依次相連形成區(qū)塊鏈,使用這種鏈狀結構,只要保存最后一個區(qū)塊頭的雜湊值,就能保證整條區(qū)塊鏈上所有交易不被篡改[19].比特幣區(qū)塊頭包含如下字段:version字段,表示當前區(qū)塊版本號,被解釋為比特向量,用于表明支持的特性;previous block header Hash字段,表示前一區(qū)塊頭的雜湊值,是所有歷史數(shù)據的指代;merkle root Hash字段,表示梅克爾樹根,是區(qū)塊中所有交易的指代;time字段,表示區(qū)塊產生的時間,是Unix時間戳;nBits字段與nonce字段是工作量證明相關的字段[24].
6) 工作量證明.作為一種去中心化的數(shù)字貨幣,比特幣區(qū)塊鏈的維護工作無法由中心化機構完成.實際中區(qū)塊鏈由運行于互聯(lián)網上的節(jié)點進行維護.在新區(qū)塊生成問題上,所有節(jié)點需要達成共識.比特幣采用的解決方案是工作量證明機制.所有節(jié)點利用算力解決一個難題,得到正確結果的節(jié)點有資格發(fā)布新的區(qū)塊.因此,難題應該是難于求解和易于驗證的.比特幣采用的難題為:改變區(qū)塊頭中的nonce字段(如果nonce字段遍歷完畢,那么礦工也可以改變coinbase交易中的coinbase script字段,從而改變梅克爾根的值),計算區(qū)塊頭雜湊值,僅當雜湊值低于某個目標值時,區(qū)塊合法,目標值越低,難度越高.這樣,計算出合法區(qū)塊的節(jié)點即可證明自己已經花費足夠多的算力.目標值保存在區(qū)塊頭的nBits字段中,每經過2 016個區(qū)塊(約2周),根據平均區(qū)塊間隔重新確定目標值,調整難題難度,以保證平均區(qū)塊間隔的穩(wěn)定.
本節(jié)對比特幣網絡的當前狀態(tài)進行分析.當前,比特幣區(qū)塊大小已經接近上限.通過統(tǒng)計最新數(shù)據,計算交易延遲時間與待確認交易內存池的大小,借此反映區(qū)塊鏈容量不足對比特幣使用體驗的影響,揭示出區(qū)塊鏈擴容的緊迫性,同時為后續(xù)分析提供數(shù)據支撐.
2.1交易延遲時間
比特幣的交易由交易發(fā)起者生成,并廣播至比特幣網絡,等待礦工確認.礦工將這些未確認的交易打包放入新的區(qū)塊中.大約每10 min一個新的合法區(qū)塊產生并連接至現(xiàn)有區(qū)塊鏈末端.交易從被發(fā)起到最終進入區(qū)塊鏈的時間為交易延遲時間.因此,正常情況下,如果忽略交易傳播至整個網絡所用的時間,平均交易延遲時間應在5 min左右.我們通過分析2017年初的區(qū)塊鏈數(shù)據,研究當前交易的延遲狀況.
文獻[4]通過運行比特幣節(jié)點,統(tǒng)計每筆交易的產生時間與入塊時間,統(tǒng)計交易的入塊情況.與此方法不同,本文通過分析已存在于區(qū)塊中的數(shù)據進而統(tǒng)計交易延遲情況.每一項交易在產生時,都會包含time字段(此信息不存在于區(qū)塊鏈,由網站提供),用于表明交易產生時間.同時,每一個區(qū)塊的頭部都包含有time字段,記錄區(qū)塊的產生時間.因此可以通過區(qū)塊中time字段與交易中time字段的比較,估算出交易的延遲時間.具體步驟如下:
1) 獲取時間戳位于2017-01-01 0:0:0—2017-03-16 0:0:0之間的區(qū)塊,區(qū)塊高度在446 033~457 418之間.采用https://blockchain.info/ 網站提供的API,獲取JSON格式的區(qū)塊數(shù)據.
2) 對于每一個區(qū)塊,將區(qū)塊時間戳記為TB,將當前區(qū)塊中每筆交易的時間戳與TB相減,差值即為該交易的延遲時間,將其記錄.
3) 以分鐘為單位進行統(tǒng)計,并做出交易占比-延遲時間統(tǒng)計圖.
圖1為交易延遲時間的統(tǒng)計圖.曲線代表交易延遲時間小于某值的交易占比,橫軸采用對數(shù)坐標.3條虛線分別代表延遲10 min,60 min和1 d.實線與虛線3個交點分別為(10,48.34%)、(60,83.71%)、(1440,98.96%).因此可以得出結論,大約有16%的交易延遲時間超過1 h,甚至有1%的交易在1 d之后才能進入區(qū)塊鏈,這個時間嚴重超出正常情況下的延遲時間.另外,將步驟2中計算的延遲時間求算術平均數(shù),得到本次測得的交易延遲時間平均值為76.53 min,和5 min的理論值相比也過長.根據交易額進行加權平均,得到的交易延遲時間平均值為68.12 min,小于算術平均值,這說明交易額大的交易更容易入塊.根據交易大小進行加權平均,得到的交易延遲時間平均值為116.59 min,這證明礦工更傾向于收錄體積較小的交易.
Fig. 1 Transaction latency time from 2017-01-01—2017-03-15圖1 2017-01-01—2017-03-15交易延遲時間統(tǒng)計
在正常情況下,礦工會盡可能在新區(qū)塊中打包所有未確認交易.因為,每筆交易都包含交易費,打包更多的交易幾乎不會影響成本卻這可以使礦工獲得更多的收益.因此,在正常情況下,交易的滯留不會發(fā)生.但是,當?shù)V工受限于區(qū)塊容量時,會盡可能將包含交易費較多的交易收入區(qū)塊,將其他交易推遲處理,以獲得最大收益.在這種環(huán)境下,小額交易的延遲時間增加.因此,當前區(qū)塊容量已經成為交易延遲時間的主要影響因素.
2.2待確認交易數(shù)量
如1.1節(jié)中所述,當一項交易被廣播至全網并等待進入區(qū)塊鏈時,它是一項待確認交易.通常,待確認交易的總大小不會超過1 MB,這樣可以保證新區(qū)塊能夠將它們全部包含.我們從https://btc.com/獲取實時數(shù)據,每分鐘記錄待確認交易內存池的總大小,并利用北京時間2017-04-21 0:0:0—2017-05-09 12:0:0的數(shù)據繪出圖2.
圖2展示待確認交易內存池的總大小隨時間的變化狀況.在正常情況下,曲線應以約10 min一次的頻率歸零,峰值也不應超過1 MB.而實際的曲線在19 d的統(tǒng)計中從未歸零,最小值為4.7 MB,最大值高達113.0 MB,遠超正常值.從圖2可以明顯看到,由于比特幣區(qū)塊鏈容量不足,導致大量的交易滯留,排隊等待確認.這可以印證2.1節(jié)的結論.
PS: The timestamp of x-axis is from 2017-04-21 0:0:0 to 2017-05-09 12:0:0(19.5 d)Fig. 2 Size of unconfirmed transactions mempool圖2 待確認交易內存池大小
本節(jié)研究比特幣擴容方案之一:鏈上擴容(on-chain scaling).這種方案提議直接修改比特幣區(qū)塊容量上限,使其可以容納更多的交易.針對鏈上擴容方案,本節(jié)分析單區(qū)塊大小受限于網絡承載力的上限,對比現(xiàn)有鏈上擴容方案,說明可行性.其次,分析鏈上擴容方案對當前交易延遲問題的改善效果.最后,對于鏈上擴容方案普遍使用的硬分叉風險進行分析.
3.1現(xiàn)有鏈上擴容方案
最容易的方案就是在設計上改變單個區(qū)塊1 MB大小的限制,以達到擴容的目的.現(xiàn)在有多個提案建議通過硬分叉直接提高單個區(qū)塊大?。?/p>
在BIP101中,建議區(qū)塊容量上限在2016-01-11 0:0:0直接提高到8 000 000 B.此后,每過63 072 000 s(2年)上限翻倍,直至2036-01-06 0:0:0達到8 192 000 000 B(即8 GB)[9].
在BIP102中,建議區(qū)塊容量直接從1 MB提升至2 MB,在不改變任何其他規(guī)則的前提下解決當下困境[10].
Bitcoin Unlimited 方案提出,區(qū)塊容量上限不再是固定值,而是可由礦工投票改變.礦工可以通過投票以當前區(qū)塊容量上限為基準,在一定浮動范圍內決定新區(qū)塊容量上限[25].
3.2網絡承載力分析
在3.1節(jié)所列舉的鏈上擴容方案存在一個關鍵的隱患:不能確定在未來某段時間內,網絡帶寬和存儲容量是否足以支撐更大的區(qū)塊.
由于比特幣網絡的去中心化,測試整個網絡的承載能力并不容易.文獻[7,26]提供了一種分析方案.根據比特幣協(xié)議,當節(jié)點A收到一個新的區(qū)塊時,首先驗證區(qū)塊的正確性.如果驗證通過,節(jié)點A會廣播inv消息,通知其他節(jié)點新區(qū)塊的存在.如果某節(jié)點B在此之前未收到同樣的inv消息,則會向節(jié)點A發(fā)送getdata消息,向節(jié)點A索取block[27].因此,可以認為節(jié)點A發(fā)送inv消息的時間,是其收到新區(qū)塊的時間.測量者可以偽裝成正常節(jié)點接入比特幣網絡,連接大量其他節(jié)點,監(jiān)測inv消息的發(fā)送情況,從而判斷區(qū)塊在網絡中的傳播情況.以一個新區(qū)塊發(fā)布時,上一個區(qū)塊應已傳播至90%的節(jié)點為標準,可以計算出網絡中可以傳輸?shù)淖畲髤^(qū)塊容量.
由表1可見,在2015年,網絡可承載的區(qū)塊大小上限為4 MB左右.從2012—2015年的3年時間,網絡狀態(tài)提升100%.但是傳播延遲主要來自于2個方面:1)inv與getdata消息的網絡延遲Td,這部分與區(qū)塊大小無關;2)block數(shù)據的傳輸延遲Tt,這部分和區(qū)塊大小成正比.當區(qū)塊較大時,Tt?Td,傳播延遲主要來自于Tt,由此計算的區(qū)塊大小上限更為準確.當區(qū)塊較小時,Tt與Td均對傳播延遲有貢獻,此時計算的區(qū)塊大小上限偏小.因此,從2012—2015年,比特幣網絡狀態(tài)提升小于表1所表現(xiàn)的100%.
Table 1 Block Size Limit Constrained by Network
根據上述測量,BIP101提出的方案“立即提升區(qū)塊大小上限至8 MB,之后每2年提升100%”是不合理的.首先,提升區(qū)塊大小上限至8 MB會超出網絡承載能力,這意味著新區(qū)塊產生時,依然有10%以上的節(jié)點沒有收到上一個區(qū)塊,增加孤塊產生的風險.另一方面,每2年提升100%的方案也超過網絡發(fā)展速度,使得未來孤塊產生風險進一步提高,影響網絡穩(wěn)定性.根據文獻[28]的研究,區(qū)塊的傳播延遲與區(qū)塊大小是線性相關的.更大的傳播延遲意味著部分節(jié)點的算力并未用于主鏈計算,這部分算力無法用于增強比特幣安全性.同時,孤塊造成的分叉會導致算力進一步分散,增加鏈的維護難度,同時也降低了算力攻擊的難度[28].
3.3改變區(qū)塊容量效果分析
PS: The timestamp of x-axis is from 2017-04-21 0:0:0 to 2017-05-09 12:0:0 (19.5 d)Fig. 3 Size of unconfirmed transactions mempool when the block size is increased圖3 區(qū)塊容量不同的待確認交易內存池大小
為驗證增大區(qū)塊容量對于當前交易延遲的改善作用,利用1.2節(jié)中的數(shù)據,模擬當區(qū)塊容量增加到1.5 MB,2 MB和4 MB時,待確認交易內存池中交易大小的狀況.假設:1) 在2017年4月21日,區(qū)塊容量立即增大;2) 礦工是完全理性的,會盡可能提高自己的收益;3) 每10 min產生一個新的區(qū)塊.模擬結果如圖3所示.對比圖2與圖3可以看出,提升區(qū)塊容量可顯著減少待確認交易內存池大小.假設交易在時間軸上均勻分布而且每10 min產生一個新區(qū)塊,待確認交易值平均值小于0.5×區(qū)塊容量時,可以保證所有交易延遲不超過10 min.以此為標準,區(qū)塊容量提升至1.5 MB并不能完全解決當下問題.區(qū)塊容量提升至2 MB可以解決當下交易延遲問題.
當交易內存池不為空時開始計時,直到交易內存池再次清空計時結束.將計時的最大值記為交易內存池的最大清空時間.在交易內存池第1次清空后開始統(tǒng)計交易內存池的最大清空時間、峰值和平均值,結果統(tǒng)計如表2所示:
Table2IndexesofUnconfirmedTransactionsMempoolUponBlockSizeIncrease
表2 區(qū)塊容量提高后待確認交易內存池指標
3.4實現(xiàn)方法分析
增大單個區(qū)塊容量的方式優(yōu)點在于邏輯簡單、易于實現(xiàn)、幾乎不會增加復雜度;但是缺點在于在這種情況下,新節(jié)點產生的區(qū)塊在舊節(jié)點看來是無效的,這意味著將不可避免地引入硬分叉.舊節(jié)點不會接受新節(jié)點產生的區(qū)塊,他們認為包括這些新區(qū)塊的區(qū)塊鏈是無效的,因此會選擇繼續(xù)延長不包含新區(qū)塊的鏈.從硬分叉部署的一刻起,只要舊節(jié)點存在,區(qū)塊鏈將出現(xiàn)2條并行的分支,分別獨立運行.
支撐以太坊(Ethereum)平臺的數(shù)字貨幣以太幣經歷過硬分叉.自2016年7月實施硬分叉開始,以太幣分裂為ETH與ETC(Ethereum Classic)兩種數(shù)字貨幣,其中ETC堅持以舊規(guī)則延續(xù)區(qū)塊鏈,而ETH以新規(guī)則運行[29].至今,2種數(shù)字貨幣都在穩(wěn)定運行之中.以太坊的分裂事件證實未達到足夠共識的情況下實施區(qū)塊鏈硬分叉存在分裂風險.
除第2節(jié)提到的鏈上擴容方案之外,還有另外一套擴容方案:鏈下擴容(off-chain Scaling).見證隔離方案解決交易延展性問題,是鏈下擴容的基礎.與此同時,見證隔離技術還能帶來一定的鏈上擴容的效果.鏈下擴容方案的關鍵在于允許交易離鏈(off-chain)完成,這通常需要在比特幣網絡之上建立第2層網絡,閃電網絡就是其中的一種.閃電網絡通過序列到期可撤銷合約(revocable sequence maturity contract, RSMC)和雜湊時間鎖定合約(hashed timelocked contract, HTLC)形成離鏈的微支付模式.這2種合約均需要在見證隔離的基礎上構建.
在4.1節(jié)首先分析見證隔離的技術細節(jié),統(tǒng)計分析當前網絡中各種交易的比例,并基于此對見證隔離附帶的鏈上擴容效果進行計算.然后,在4.2節(jié)分析閃電網絡實現(xiàn)方式與預期效果.
4.1見證隔離
4.1.1 技術介紹
見證隔離技術在BIP141~BIP144中被提出并詳細描述[13,30-32].
在當前的比特幣交易中存在一個問題,交易數(shù)據與簽名數(shù)據存在于同一數(shù)據結構中.簽名延展性指,可以在不知道私鑰的情況下改變簽名值,使其依然能夠驗證通過(這個過程中被簽名內容不會改變,即不能通過這種方式篡改交易輸出)[33].簽名雖然保證交易數(shù)據不會被篡改,但是交易ID是整個交易的雙雜湊,既包含交易數(shù)據,又包含簽名數(shù)據,簽名的延展性導致交易ID不是唯一確定的.而每項交易都會指向其前一項交易的輸出,因此基于未確認交易的所有交易都是不安全的[34].文獻[35]通過實驗證實,主流錢包軟件無法正確處理交易延展性帶來的問題.
為解決這個問題,BIP62對比特幣簽名驗證增加了額外的限制,避免了第三方利用交易延展性進行攻擊的可能,但依然不能阻止交易發(fā)起者利用交易延展性的漏洞[36].見證隔離可以徹底解決交易延展性問題.見證隔離將簽名數(shù)據從交易中撤出,將簽名放入被稱為見證的數(shù)據結構中.一個交易將具有2個ID.其中交易ID依然和原來是相同的,是以下內容序列化(將數(shù)據依次轉換為字節(jié)序列并連續(xù)存儲)的雙雜湊:
[nVersion][txins][txouts][nLockTime]
另外定義見證ID,其為以下新結構序列化后的雙雜湊:
[nVersion][marker][flag][txins][txouts][witness][nLockTime]
和舊版本不同的是,簽名數(shù)據已經從txins中取出并放在見證中,因此交易ID不會具有延展性且唯一.
由于區(qū)塊頭部和新加入的見證結構無關,這意味著見證不會被區(qū)塊鏈保護,需要將見證加入當前結構以達到保護見證的目的.為保證通過軟分叉完成,考慮到每一個區(qū)塊的第1項交易必須是一項coinbase交易,用于將挖礦獎勵發(fā)送給礦工指定的地址,可以將見證數(shù)據通過梅克爾樹整理,并將梅克爾樹根部放入coinbase交易中.當見證數(shù)據被改動,coinbase交易ID會改變,從而導致交易梅克爾樹根部的改變,最終影響到區(qū)塊雜湊值,因此區(qū)塊鏈可以保證見證數(shù)據不被篡改[13].
BIP141~BIP144通過軟分叉實現(xiàn)見證隔離,如果它被部署,意味著交易ID是可以唯一確定的,這為后面閃電網絡的展開提供條件.
4.1.2 區(qū)塊容量提升分析
見證隔離可以提高區(qū)塊的實際大小.因為簽名從交易中提出,放入見證數(shù)據之中,而舊的節(jié)點看不到這部分數(shù)據,這意味著他們能看到的部分相對較少,那么保證舊節(jié)點看到的區(qū)塊小于1 MB的同時,區(qū)塊可以包含更多的交易,新節(jié)點識別的實際大小也大于1 MB.
實際部署中,見證隔離本身對于區(qū)塊鏈的擴容效果不易確定,因為對于不同類型的交易,提升效果是不同的.因此需要先計算出見證隔離對各種常見交易的空間節(jié)約效果,再結合當前網絡中各種交易的比例計算出最終結果.
當前最常用的比特幣交易為P2PKH與P2SH兩種.P2PKH是直接向某公鑰的雜湊支付,意味著直接支付給某人,收款人可以用自己的私鑰取得交易中幣所有權;P2SH是向某個腳本的雜湊值支付,收款時需要運行對應的腳本,通常用于完成多人簽名支付,允許指定m個公鑰,使用其中n個公鑰對應的私鑰(n≤m),即可取得交易中的幣.
對應上述2種交易,在見證隔離中,提出2種新的交易類型,即P2WPKH和P2WSH,除交易結構的變化外,輸入字段中的scriptSig和輸出字段中的scriptPubKey也發(fā)生相應變化[13].將scriptSig長度記為s,將txins字段中單個輸入的長度記為in,將txouts字段中單個輸出的長度記為out,將witnesses字段中單個見證數(shù)據長度記為witness,交易結構中其他字段總長度記為meta.交易各部分占用空間如表3和表4所示.
表3和表4默認輸入與輸出計數(shù)不會超過252,這與通常情況是相符的,包含大量輸入/輸出的交易是十分稀少的.根據表3和表4,以及常用交易的scriptSig長度,可以得到圖4.
Table 3 Space Comparison Between P2PKH and P2WPKH
① Ifs>252 B,inshould be added 2 B.
Table 4 Space Comparison Between P2SH and P2WSH
① Ifs>252 B,inshould be added 2 B.
Fig. 4 Space comparison of typical transactions圖4 典型交易數(shù)據占用空間對比
圖4中基礎數(shù)據(SW-Base)指除witness字段之外的數(shù)據.這里暫時假設每筆交易都是單輸入單輸出.存在2種P2PKH是因為早期的〈PublicKey〉直接使用公鑰,而近期普遍使用經過壓縮的公鑰.因此現(xiàn)在存在2種不同長度的P2PKH交易.由圖4可見,見證隔離相對現(xiàn)有設計在基礎數(shù)據上可以節(jié)約50%左右的空間.同時能看到,交易中簽名數(shù)據所占比例越大,空間節(jié)約效果越明顯.用同樣的方法,可以計算出其他類型交易相對現(xiàn)有設計的空間節(jié)約效果.
為計算見證隔離對于整個網絡交易容量的提升效果,需要分析不同類型的交易所占比例.我們用1.1節(jié)的方法,獲取2017-01-01 0:0:0—2017-03-16 0:0:0的所有區(qū)塊.通過交易中包含的地址信息和腳本長度,可以用于判斷其類型.圖5和圖6顯示統(tǒng)計結果.
圖5(a)是對P2PKH輸出腳本的統(tǒng)計.其中只有一個明顯的峰值,在腳本長度25 B處,這是標準的P2PKH輸出腳本.圖5(b)是對P2SH輸出腳本的統(tǒng)計,由于輸出腳本已被規(guī)定,因此所有該類型的輸出腳本長度都是23 B.圖5(c)是對于其他類型交易輸出腳本的統(tǒng)計,這里包含任何人都可花費的輸出、OP_RETURN銷毀證明等[37].
Fig. 5 Length statistics of different types of output scripts圖5 不同類型輸出腳本長度統(tǒng)計
圖6(a)統(tǒng)計P2PKH輸入腳本.可以看出最高峰值出現(xiàn)在106~107 B附近,這是當前最常用的P2PKH輸入腳本;另外一個峰值在138~139 B附近,這是使用早期未壓縮的公鑰格式產生的交易.圖6(b)統(tǒng)計P2SH輸入腳本,2個明顯峰值分別在218 B和253 B附近;它們分別對應2-of-2多重簽名交易和2-of-3多重簽名交易.圖6(c)統(tǒng)計其他類型的輸入腳本,從縱坐標可以看出,這些交易相對于前面2種交易低4~5個數(shù)量級,因此可以忽略不計.
Fig. 6 Length statistics of different types of input scripts圖6 不同類型輸入腳本長度統(tǒng)計
BIP141中定義塊重(block weight)為3×基礎數(shù)據大小+總大小.其中基礎數(shù)據為區(qū)塊中不包括見證數(shù)據的部分,這是舊節(jié)點所能看到的內容;總大小為包含所有字段的數(shù)據大小,是新節(jié)點看到的區(qū)塊大小.新規(guī)則規(guī)定:塊重不大于4 000 000 B[13].在此規(guī)則下,可以保證基礎數(shù)據不大于1 000 000 B.根據新規(guī)則,假設所有P2PKH交易都被P2WPKH替代,所有P2SH交易都被P2WSH替代,將原有統(tǒng)計數(shù)據中的交易大小替換為新交易的基礎大小與總交易大小,結合各類型交易比例得出結論:新區(qū)塊中的平均基礎數(shù)據大小是361.7 KB,平均總大小是921.6 KB,平均塊重為2 006.7 KB.考慮到當前平均區(qū)塊大小未達理論上限,如果當前區(qū)塊容量達到理論上限1 MB,計算出新區(qū)塊塊重為2 185.4 KB.新規(guī)則允許的最大塊重為4 000 KB,因此新規(guī)則允許多容納83.0%的交易.考慮到比特幣錢包軟件開發(fā)商對于見證隔離支持度很高(參看本文5.1節(jié)),見證隔離部署后,新交易使用比例會持續(xù)上升,最終完全替代舊交易.
4.1.3 實現(xiàn)方法分析
見證隔離技術通過軟分叉實現(xiàn),這要求新節(jié)點產生的區(qū)塊對舊節(jié)點而言依然是有效的,即交易有效的條件比更新前更加嚴格.在大部分節(jié)點部署更新之后(見證隔離要求95%節(jié)點支持),更新會激活.這種情況下區(qū)塊鏈不會出現(xiàn)分裂,大部分節(jié)點會沿著正確的鏈工作,即使是少部分未更新的節(jié)點也會跟隨在最長鏈上工作(和硬分叉不同,軟分叉后主鏈對舊節(jié)點來說是有效的).
軟分叉通常通過BIP9提供的方式投票部署.區(qū)塊頭部的version字段被解釋為比特向量,每一位都可用于一種新特性的標志位[38].見證隔離占用第1位.如果礦工將產出區(qū)塊的version第1位設定為1,代表其投票支持見證隔離的激活,否則代表反對.如果一段時間內支持見證隔離的區(qū)塊超過95%,就意味著網絡中95%的算力投票支持見證隔離,新特性隨之激活.主鏈投票從2016-11-15 0:0:0—2017-11-15 0:0:0[13].如果截止時間前未獲得足夠支持,投票結束,version字段投票位收回.見證隔離的投票與激活過程是開發(fā)者提議,礦工算力投票表決.
4.2閃電網絡
閃電網絡主要由RSMC和HTLC兩種合約構成.其中,RSMC允許2用戶構建雙向離鏈微支付通道,在限額內實現(xiàn)無限次快速離鏈轉賬;HTLC允許未直接建立通道的2用戶通過其他中繼用戶實現(xiàn)轉賬,同時保證資金不會因中繼用戶錯誤或惡意行為而丟失.這2種合約均需要在見證隔離的基礎上構建.
4.2.1 序列到期可撤銷合約
進行交易的雙方可以通過向腳本的雜湊地址進行支付的方式[22],將資金注入資金池,并將資金池輸出按照注資比例發(fā)往各自的地址.雙方只將前一項交易廣播至網路,后一項交易簽名后相互交換.當雙方需要進行支付時,只需改變資金池的分配方案,并將舊方案作廢處理.只有當決定終止交易時,才會將分配方案最終公布到區(qū)塊鏈上.這樣,無論交易雙方之間進行過多少次離鏈交易,都不會對區(qū)塊鏈造成更大的負擔.
4.2.2 雜湊時間鎖定合約
更進一步地,除雙方的微支付通道之外,雜湊時間鎖定合約使得未建立通道的2人,可以通過多個非可信第三方完成支付.這里額外引入條件支付.如果A和C都與B建立支付通道,A可通過這種方法向C支付0.5 BTC:收款方C生成一個秘密值R,并將雜湊值H(R)交給A,A與B建立條件支付,如果B能在一段時間內(假設區(qū)塊高度100)出示R,則A向B支付0.51 BTC.同樣,B與C建立條件交易,如果C能在一定時間內(假設區(qū)塊高度80)出示R,則B向C支付0.5 BTC.由于R由C生成,因此條件支付顯然可以達成.通過這種方法,也可以像路由尋址的方式一樣經過多跳完成支付.因此,在此過程中,不必信任B,即可達成交易.對于B而言,輸入和輸出的差值0.01 BTC就是此過程獲得的交易費.
如果大量的雙向支付通道建立起來,那么陌生的雙方通過第三方交易也將變得十分簡單.屆時,甚至不需要資金重新回到區(qū)塊鏈上,所有交易都可以在閃電網絡中離鏈完成.離鏈交易速度很快,無需等待確認,只要雙方完成互換交易即時達成.由此可見,閃電網絡的方案可以大幅降低鏈上的小額支付交易,避免大量的帶寬和存儲空間占用.但是缺點在于錢包實現(xiàn)相對復雜.傳統(tǒng)錢包只需要關注區(qū)塊鏈上的交易或向網絡發(fā)布交易,錢包開發(fā)者遵循比特幣的規(guī)則即可.而閃電網絡錢包還需要關注一個離鏈的網絡,錢包需要具有類似于當前路由協(xié)議的功能,以找到從發(fā)送方到接收方之間的最佳路徑.為能夠相互兼容,錢包開發(fā)者必須建立統(tǒng)一的規(guī)則.因此,閃電網絡的錢包普及需要時間.只有當大量支付通道建立起之后,閃電網絡的效果才能最終展現(xiàn)出來.
2017年4月,德國酒吧Room77嘗試在比特幣測試網絡中建立閃電網絡,結果表明:轉賬可在數(shù)毫秒之內完成[39].2017年5月,萊特幣激活見證隔離后,Blockstream的Christian Decker在萊特幣中測試了閃電網絡,通道建立之后,從蘇黎世向舊金山的轉賬在1 s內完成[40].由此可見,閃電網絡在擴容同時,亦可大幅減少交易確認時間.
4.2.3 實現(xiàn)方法分析
為保證公平交易,閃電網絡需要先對子交易簽名,再對父交易簽名.由于交易延展性,當前比特幣規(guī)則無法支持這種簽名順序.為解決這個問題,閃電網絡白皮書中提出一種解決方案.通過軟分叉引入SIGHASH_NOINPUT操作.與當前的簽名方式不同,SIGHASH_NOINPUT不對輸入中的交易ID簽名.這樣,父交易的交易ID變化不會破壞子交易中簽名的有效性.見證隔離提供另一種解決思路,通過將簽名數(shù)據轉移出輸入字段,徹底解決交易延展性的問題.與閃電網絡白皮書中提到的方案相比,見證隔離更徹底將上述問題解決,且更具有通用性.因為每一次引入軟分叉都意味著系統(tǒng)的復雜度提升,社區(qū)更期望能夠通過一次軟分叉解決盡可能多的問題,所以見證隔離的軟分叉相對閃電網絡中提到的SIGHASH_NOINPUT更容易被社區(qū)接受.
見證隔離+閃電網絡是比特幣核心開發(fā)者(Bitcoin Core)大力支持的升級路線圖.見證隔離可以在短期內提升區(qū)塊鏈容量,解決當前交易延遲的問題.隨著閃電網絡的成熟,大量交易可以在區(qū)塊鏈之外完成,緩解區(qū)塊鏈壓力.
本節(jié)分析比特幣社區(qū)對擴容方案的態(tài)度.在擴容問題上,社區(qū)明顯分為2派,大礦池為主的一派更傾向于鏈上擴容,甚至希望徹底取消區(qū)塊容量上限,交易所和核心開發(fā)者為主的一派則更支持鏈下擴容方案,2派均為推動擴容方案的實現(xiàn)做出不懈努力.
5.1社區(qū)分歧
對于比特幣未來的發(fā)展方向,社區(qū)有2種不同的看法.以Bitcoin Core為主的一派認為比特幣應該作為結算系統(tǒng),采用見證隔離+閃電網絡的方式,以現(xiàn)有比特幣網絡為基礎,建立第2層網絡(如閃電網絡),大部分交易都在第2層網絡中完成,底層的比特幣網絡只為上層網絡提供安全保障[41].但是也有人持反對態(tài)度,原因是作為結算系統(tǒng)的比特幣與中本聰?shù)谋忍貛虐灼脑O想走向了完全不同的方向.他們著力于保持比特幣現(xiàn)有的特性,使其繼續(xù)以現(xiàn)金系統(tǒng)的方式運行下去.為達到這個目的,唯一的解決方案就是擴大區(qū)塊容量上限(或減少區(qū)塊產生間隔).由于和Bitcoin Core理念不同,部分開發(fā)者選擇放棄Bitcoin Core的客戶端,獨立開發(fā)出Bitcoin Unlimited(BU)客戶端.因此,和通過BIP9部署的閃電網絡不同,支持BU方案是通過使用不同客戶端的方式達成的.
上述2種方案均有一定支持度.結算系統(tǒng)的代表是見證隔離+閃電網絡方案,現(xiàn)金系統(tǒng)的代表是Bitcoin Unlimited方案.2017年4月,BU方案支持度略高于見證隔離,二者支持度均在30%以上[42].
從見證隔離的歷史支持度來看,在BIP141規(guī)定的投票時間開始時,支持見證隔離的區(qū)塊迅速增多,但是,此后一直保持在30%左右[43].按照此趨勢,見證隔離很難在規(guī)定時間內(2017年11月15日)通過.“用戶激活軟分叉(UASF)”方案提出,若大多數(shù)實體(包括用戶、交易所、錢包軟件開發(fā)者等)同意,節(jié)點客戶端將強制開啟更新.BIP148中加入規(guī)定:從2017年8月1日起,未宣布同意支持新版本的區(qū)塊將會被其他節(jié)點拒絕[44].此方案相當于開發(fā)者繞過礦工激活見證隔離.為應對UASF,比特大陸(bitmain.com)提出“用戶激活硬分叉(UAHF)”方案.此方案不包含見證隔離,同時將區(qū)塊容量上限提升至8 MB.UAHF在UASF激活12 h 20 min后啟動[45].上述2種方案均不考慮算力支持度,因此極易造成比特幣分叉.
相比于礦工對見證隔離支持的猶豫不決,礦工之外的群體中,見證隔離的支持度遠高于BU,在對公司的統(tǒng)計中,見證隔離的支持度(包括確認支持和準備就緒的公司)超過70%,而BU方案僅20%左右[46].這些公司中除礦池之外,還包括比特幣交易所、錢包軟件開發(fā)商等.由此可見,礦工與交易所對于比特幣的發(fā)展方向問題存在分歧.
5.2鏈上方案擴容風險分析
5.2.1 中心化風險
比特幣社區(qū)一直對于比特幣網絡的中心化趨勢十分警惕.中本聰在比特幣白皮書中就提到,“如果決定大多數(shù)的方式是基于IP地址的,一IP地址一票,那么如果有人擁有分配大量IP地址的權力,則該機制就被破壞.而工作量證明機制的本質則是一CPU一票[1].”在最初的設計中,比特幣節(jié)點可以運行在個人計算機上.由于運行門檻極低,所有人都可以作為礦工運行節(jié)點.這一點保證主鏈的投票權分散在用戶手中.
社區(qū)擔心,支持BU的團體取消區(qū)塊容量上限的方案會增大中心化風險.較大的區(qū)塊需要更好的網絡條件進行傳輸、更大的硬盤空間用于存儲,這會提高全節(jié)點的運行門檻.如果比特幣平均交易大小保持不變,即490 B,全網交易速率達到visa的當前平均水平2 000交易/秒[7],則平均區(qū)塊大小將超過500 MB,遠遠超過3.3節(jié)中網絡的承載力.另外,網絡每月產生的數(shù)據量高達85 GB,每年產生數(shù)據量超過1 TB,造成很大的存儲負擔.不斷增高的帶寬和存儲成本對小礦工而言是致命的,但是對于大型公司而言是可以接受的.在此情況下,大量的小礦工將被迫退出,比特幣的去中心化特性將被削弱.
因此,對于大小不受限制的區(qū)塊,社區(qū)持懷疑態(tài)度.比特幣難以作為去中心化現(xiàn)金系統(tǒng)持續(xù)運行.
5.2.2 攻擊風險
實施鏈上擴容的方案之后,會導致區(qū)塊傳播延遲的增長,從而降低部分攻擊的難度.下面分析常見攻擊方式與鏈上擴容的關系.
1) 雙花攻擊(double spending).鏈上擴容后,零確認雙花攻擊難度不會改變,N確認雙花攻擊難度會下降.
零確認雙花與區(qū)塊傳播關系不大.在需要快速交易且交易金額不大的情況下,收款方會在收到網絡上廣播的交易后即認為收款成功,此時交易還未進入區(qū)塊鏈.惡意付款者可以在付款后,網絡上廣播另一項同輸入的交易,輸出指向自己控制的地址,兩交易互斥,但均有機會進入區(qū)塊鏈.若最終后者入塊,則惡意付款者獲利[23].此攻擊方式與交易在比特幣網絡中傳播延遲相關,鏈上擴容對此影響不大.
N確認雙花是指攻擊者在N個區(qū)塊確認之后,通過改變主鏈走向,達到撤回某項交易的目的.當攻擊者擁有算力超過全網50%時,即可使用此攻擊方式.3.2節(jié)指出:更大的區(qū)塊會導致區(qū)塊傳播延遲增加,自然分叉有可能出現(xiàn),從而造成有效算力的減少.這使比特幣網絡的安全性降低,攻擊者可以利用更少的算力制造超過主鏈長度的分支,從而改變主鏈走向[28].
2) 自私挖礦(selfish mining).鏈上擴容會使得比特幣更容易受到自私挖礦影響.
文獻[47]提出,當算力達到一定水平之后,礦工可以通過暫時隱瞞挖到區(qū)塊的方式獲利.獲利情況由礦工算力占比α和追隨者占比γ(即誠實結點和攻擊者分別生成的2個合法區(qū)塊同時廣播時,誠實節(jié)點支持攻擊者的比例)決定.在不考慮延遲,且γ=50%的情況下,α達到25%的礦工即可通過自私挖礦獲利.當區(qū)塊傳播延遲不可忽略時,雖然自私礦工γ可能降低,但是由于3.2節(jié)提到的全網算力損失,自私礦工α有所上升.由于自然分叉的存在,自私挖礦的獲利閾值可能比25%更低[48].
3) 日蝕攻擊(eclipse attack)等傳播阻斷.這類攻擊的難度不會因鏈上擴容的實施而下降.
通過分割比特幣網絡,使得部分節(jié)點數(shù)據的更新晚于其他節(jié)點,這種作法可以協(xié)助實施某些攻擊(如零確認雙花).在網絡層面阻斷數(shù)據傳播[49],或利用比特幣協(xié)議中對比特幣區(qū)塊和交易廣播過程中的聲譽管理系統(tǒng)、基于廣告的請求管理系統(tǒng)和超時規(guī)定等措施的缺陷[50],均可達到此目的.如果僅僅實行鏈上擴容,而不改動比特幣協(xié)議的其他部分,那么這類攻擊的難度不會下降.
5.3鏈下方案短期效果分析
雖然見證隔離理論上可以等效提高區(qū)塊容量上限,但是達到理論的效果需要一段過渡時間.根據3.1節(jié)的計算,基于當前的交易比例,見證隔離技術可以使區(qū)塊多容納83%的交易數(shù)量,即相當于通過軟分叉將區(qū)塊容量最多提升至1.83 MB.利用2.3節(jié)使用的方法,計算出待確認交易內存池平均大小為479 665 B,可以解決當下的區(qū)塊鏈容量不足的難題.但是,花費舊版本的交易時,輸入中依然需要使用包含簽名的舊格式scriptSig,無法節(jié)約空間.見證隔離部署之后的時間點上,用戶持有的貨幣依然保存在舊版本的交易中,因此擴容的效果不會在短時間內立即顯現(xiàn).
本文對比特幣網絡當前狀態(tài)進行詳細分析,結果顯示:2017年初,有16%的交易需要1 h以上的時間進行確認,等待確認的交易內存池大小一度超過110 MB.對鏈上擴容的分析指出,不改變區(qū)塊間隔前提下,單個區(qū)塊大小不應超過4 MB,否則會超出當前網絡負載能力,導致孤塊率上升等問題.另外,單個區(qū)塊大小增大至2 MB可以緩解當前交易延遲的問題.
對于鏈下擴容方案的分析發(fā)現(xiàn),見證隔離技術具有增大區(qū)塊容量的效果.基于當前交易數(shù)據計算得出的結論是,見證隔離可以將區(qū)塊容量增大83%.更重要的是,見證隔離技術可以解決當前的交易延展性問題,從而為閃電網絡等基于比特幣的第2層網絡搭建鋪平道路.一旦閃電網絡搭建完成,可以極大減輕區(qū)塊鏈負擔,增大比特幣系統(tǒng)對交易的處理能力,減少交易確認等待時間.
比特幣擴容問題的關鍵在于社區(qū)對當前擴容方案的認同度.比特幣擴容技術無法部署的主要原因在于社區(qū)意見的不統(tǒng)一.鏈上擴容方案見效快,但是增大中心化風險,適合作為短期方案使用.鏈上擴容方案雖然能極大提升容量,但是見效慢,適合作為長期擴容方案.重要的是2種方案從技術上分析并不是互斥的.
一種合理的路線圖是將區(qū)塊容量上限提高至2 MB(引入見證隔離后的區(qū)塊實際大小保持在4 MB以下,符合3.3節(jié)分析),緩解當下交易大量延遲問題.同時引入見證隔離,開始部署閃電網絡,逐漸將小額交易移到鏈外,減少區(qū)塊鏈的容量負擔,達成長期平穩(wěn)運行目標.
比特幣區(qū)塊鏈擴容技術已經準備就緒,一旦社區(qū)達成一致,相應技術即可部署應用.我們很高興地看到,社區(qū)正在持續(xù)努力實現(xiàn)這個目標.最新的進展是2017年5月23日分布于21個國家的56家公司就比特幣擴容問題達成共識,其中包括蟻池等大型礦池以及Coinbase等比特幣交易所,這個群體占有全網83.28%的比特幣算力.達成的共識包括:以80%閾值激活見證隔離,以bit4為信號;在6個月內激活2 MB區(qū)塊硬分叉[51].此共識通過SegWit2x擴容方案實施(硬分叉激活時間變?yōu)橐娮C隔離激活后3個月).BIP91規(guī)定,若336個區(qū)塊中80%以上包含bit4信號則可激活,確認期后,礦工將拒絕所有未包含bit1信號的區(qū)塊[52],以此實現(xiàn)了SegWit2x與BIP141的兼容.根據Coin Dance的統(tǒng)計,SegWit2x算力支持度在2017年7月已超過80%[53].BIP91已于7月23日正式生效,礦池拒絕不支持見證隔離的區(qū)塊,如果見證隔離支持度達到95%而且持續(xù)2016個區(qū)塊,則見證隔離被鎖定,再經過2016個區(qū)塊,見證隔離將在8月完成激活[54].根據本文的計算,如果各方能夠執(zhí)行協(xié)議,那么現(xiàn)階段比特幣擴容問題將被很好地解決.
后記:本文審稿完成后,比特幣擴容又發(fā)生新的進展.SegWit2x的成功激活避免了2017年8月1日激活UASF可能產生的分叉[54],但是作為應對UASF可能分叉的UAHF,卻由于Bitcoin Cash在2017-08-01 20:20開始生成新的區(qū)塊,進而產生新的競爭幣Bitcoin Cash (BCC)[55].
[1] Nakamoto S. Bitcoin: A peer-to-peer electronic cash system[OL]. (2008-10-31) [2016-11-02]. https://bitcoin.org/bitcoin.pdf
[2] Qin Bo, Chenli C, Wu Qianhong, et al. Bitcoin and digital fiat currency[J]. Journal of Cryptologic Research, 2017, 4(2): 176-186 (in Chinese)
(秦波, 陳李昌豪, 伍前紅, 等. 比特幣與法定數(shù)字貨幣[J]. 密碼學報, 2017, 4(2): 176-186)
[3] Blockchain Luxembourg S A. Average Block Size[OL]. [2017-01-05]. https://blockchain.info/en/charts/avg-block-size
[4] Pappalardo G, Di Matteo T, Caldarelli G, et al. Blockchain inefficiency in the Bitcoin peers network[DB/OL]. [2017-06-01]. https://arxiv.org/pdf/1704.01414.pdf
[5] Bonneau J, Miller A, Clark J, et al. Sok: Research perspectives and challenges for Bitcoin and cryptocurrencies[C] //Proc of the 36th IEEE Symp on Security and Privacy (SP 2015). Piscataway, NJ: IEEE, 2015: 104-121
[6] Sompolinsky Y, Zohar A. Accelerating Bitcoin’s transaction processing, fast money grows on trees, not chains[DB/OL]. [2017-03-05]. https://eprint.iacr.org/2013/881.pdf
[7] Croman K, Decker C, Eyal I, et al. On scaling decentralized blockchains[G] //LNCS 9604: Proc of the 20th Int Conf on Financial Cryptography and Data Security (FC 2016). Berlin: Springer, 2016: 106-125
[8] Gervais A, Karame G O, Wüst K, et al. On the security and performance of proof of work blockchains[C] //Proc of the 2016 ACM SIGSAC Conf on Computer and Communications Security (CCS 2016). New York: ACM, 2016: 3-16
[9] Andresen G. BIP101: Increase maximum block size[OL]. [2017-06-01]. https://github.com/bitcoin/bips/blob/master/bip-0101.mediawiki
[10] Garzik J. BIP102: Block size increase to 2 MB[OL]. [2017-06-01]. https://github.com/bitcoin/bips/blob/master/bip-0102.mediawiki
[11] Wuille P. BIP103: Block size following technological growth[OL]. [2017-06-01]. https://github.com/bitcoin/bips/blob/master/bip-0103.mediawiki
[12] Andresen G. BIP109: Two million byte size limit with sigop and sighash limits[OL]. [2017-06-01]. https://github.com/bitcoin/bips/blob/master/bip-0109.mediawiki
[13] Lombrozo E, Lau J, Wuille P. BIP141: Segregated Witness (Consensus layer)[OL]. [2016-11-15]. https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki
[14] Poon J, Dryja T. The Bitcoin lightning network: Scalable off-chain instant payments[OL]. [2016-12-17]. https://lightning.network/lightning-network-paper.pdf
[15] Decker C, Wattenhofer R. A fast and scalable payment network with Bitcoin duplex micropayment channels[G] //LNCS 9212: Symp on Self-Stabilizing Systems (SSS 2015). Berlin: Springer, 2015: 3-18
[16] Miller A, Bentov I, Kumaresan R, et al. Sprites: Payment channels that go faster than lightning[DB/OL]. [2017-05-06]. https://arxiv.org/pdf/1702.05812
[17] Lind J, Eyal I, Pietzuch P, et al. Teechan: Payment channels using trusted execution environments[DB/OL]. [2017-05-20]. https://arxiv.org/pdf/1612.07766
[18] Higgins S. IC3 Debuts Upgraded Off-Chain Transaction Protocol “Teechain”[OL].[2017-05-07]. http://www.coindesk.com/ic3-debuts-upgraded-off-chain-transaction-protocol-teechain/
[19] Narayanan A, Bonneau J, Felten E. Bitcoin and Cryptocurrency Technologies[M]. Princeton: Princeton University Press, 2016
[20] Tschorsch F, Scheuermann B. Bitcoin and beyond: A technical survey on decentralized digital currencies[J]. IEEE Communications Surveys & Tutorials, 2015, 18(3): 2084-2123
[21] Theymos. Bitcoin wiki: Script[OL]. [2017-05-05]. https://en.bitcoin.it/wiki/Script
[22] Andresen G. BIP16: Pay to Script Hash[OL]. [2016-11-14]. https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki
[23] Karame G O, Androulaki E, Capkun S. Double-spending fast payments in Bitcoin[C] //Proc of the 19th ACM Conf on Computer and Communications Security. New York: ACM, 2012: 906-917
[24] Sanders G, Harding D A. Bitcoin Developer Reference[OL]. [2017-05-05]. https://bitcoin.org/en/developer-reference#block-chain
[25] Bitcoin Unlimited Organization. Bitcoin Unlimited: Articles of Federation[OL]. [2017-04-20]. https://www.bitcoinunlimited.info/resources/BUarticles.pdf
[26] Decker C, Wattenhofer R. Information propagation in the Bitcoin network[C] //Proc of the 13th IEEE Int Conf on Peer-to-Peer Computing (P2P). Piscataway, NJ: IEEE, 2013: 1-10
[27] Karpelès M. Bitcoin Protocol Documentation[OL]. [2017-05-15]. https://en.bitcoin.it/wiki/Protocol_documentation
[28] Sompolinsky Y, Zohar A. Secure high-rate transaction processing in Bitcoin[G] //LNCS 8975: Proc of the 19th Int Conf on Financial Cryptography and Data Security. Berlin: Springer, 2015: 507-527
[29] Wirdum V A. Ethereum Classic Community Navigates a Distinct Path to the Future[OL]. [2017-02-15]. https://bitcoinmagazine.com/articles/ethereum-classic-community-navi gates-a-distinct-path-to-the-future-1471620464/
[30] Lau J. BIP142: Address format for segregated witness[OL]. [2016-11-15]. https://github.com/bitcoin/bips/blob/master/bip-0142.mediawiki
[31] Lau J, Wuille P. BIP143: Transaction signature verification for version 0 witness program[OL]. [2016-11-15]. https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki
[32] Lombrozo E, Wuille P. BIP144: Segregated witness (peer services)[OL]. [2016-11-16]. https://github.com/bitcoin/bips/blob/master/bip-0144.mediawiki
[33] Andrychowicz M, Dziembowski S, Malinowski D, et al. How to deal with malleability of Bitcoin transactions[DB/OL]. [2016-12-03]. https://arxiv.org/pdf/1312.3230
[34] Decker C, Wattenhofer R. Bitcoin transaction malleability and MtGox[G] //LNCS 8713: Proc of European Symp on Research in Computer Security (ESOCRIS 2014). Berlin: Springer, 2014: 313-326
[35] Andrychowicz M, Dziembowski S, Malinowski D, et al. On the malleability of Bitcoin transactions[G] //LNCS 8976: Proc of the 19th Int Conf on Financial Cryptography and Data Security (FC 2015). Berlin: Springer, 2015: 1-18
[36] Wuille P. BIP62: Dealing with malleability[OL]. [2017-02-05]. https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki
[37] Sanders G, Harding D A. Bitcoin Developer Guide[OL]. [2017-05-18]. https://bitcoin.org/en/developer-guide#term-null-data
[38] Wuille P, Todd P, Maxwell G, et al. Version bits with timeout and delay[OL]. [2016-11-16]. https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki
[39] Helms K. Lightning Network Used to Sell Beer at Room77[OL]. [2017-04-10]. https://news.bitcoin.com/lightning-network-beer-room77/
[40] Russell R. Major Milestone: The First Lightning Payment on Litecoin pays from Zurich to San Francisco[OL]. [2017-05-23]. https://blockstream.com/2017/05/11/lightning-on-litecoin.html
[41] Tremback J, Hess Z. Universal payment channels[OL]. [2016-12-20]. http://jtremback.github.io/universal-payment-channels/universal-payment-channels.pdf
[42] Coin Dance. Bitcoin Block Details[OL]. [2017-04-07]. https://coin.dance/blocks
[43] Blockchain Luxembourg S A. Percentage of blocks signalling SegWit support[OL]. [2017-04-04]. https://blockchain.info/charts/bip-9-segwit
[44] Fry S. Mandatory activation of segwit deployment[OL]. [2017-04-05]. https://github.com/bitcoin/bips/blob/master/bip-0148.mediawiki
[45] Bitmain Technologies. UAHF: A contingency plan against UASF (BIP148)[OL]. [2017-07-28]. https://blog.bitmain.com/en/uahf-contingency-plan-uasf-bip148/
[46] Coin Dance. Global Bitcoin Political Support & Public Opinion[OL]. [2017-04-07]. https://coin.dance/poli
[47] Eyal I, Sirer E G. Majority is not enough: Bitcoin mining is vulnerable[J]. Computer Science, 2013, 8437: 436-454
[48] Sapirshtein A, Sompolinsky Y, Zohar A. Optimal selfish mining strategies in Bitcoin[G] //LNCS 9603: Proc of the 20th Int Conf on Financial Cryptography and Data Security. Berlin, Springer, 2016: 515-532
[49] Heilman E, Kendler A, Zohar A, et al. Eclipse attacks on Bitcoin’s peer-to-peer network[C] //Proc of the 24th USENIX Conf on Security Symp. Berkeley, CA: USENIX Association, 2015: 129-144
[50] Gervais A, Ritzdorf H, Karame G O, et al. Tampering with the delivery of blocks and transactions in Bitcoin[C] //Proc of 2015 ACM SIGSAC Conf on Computer and Communications Security. New York: ACM, 2015: 692-705
[51] Digital Currency Group. Bitcoin Scaling Agreement at Consensus 2017[OL]. [2017-05-24]. https://medium.com/@DCGco/bitcoin-scaling-agreement-at-consensus-2017-133521fe9a77
[52] Hilliard J. BIP91: Reduced threshold Segwit MASF[OL]. [2017-07-21]. https://github.com/bitcoin/bips/blob/master/bip-0091.mediawiki
[53] Blockchain Luxembourg S A. Percentage of blocks signalling support for the New York agreement[OL]. [2017-07-22]. https://blockchain.info/charts/nya-support
[54] Rizzo P. What’s Left Before SegWit Goes Live? Bitcoin’s Path to More Capacity[OL]. [2017-07-25]. https://www.coindesk.com/whats-left-before-segwit-goes-live-bitcoins-path-more-capacity/
[55] Séchet A. Bitcoin Cash[OL]. [2017-08-02]. https://www.bitcoincash.org/
ResearchonScalingTechnologyofBitcoinBlockchain
Yu Hui1, Zhang Zongyang1,2, and Liu Jianwei1
1(SchoolofElectronicandInformationEngineering,BeihangUniversity,Beijing100191)2(StateKeyLaboratoryofInformationSecurity(InstituteofInformationEngineering,ChineseAcademyofSciences),Beijing100093)
Bitcoin is a crypto currency introduced by Satoshi Nakamoto in 2008. It has the features of decentralization, cross-border and fixed total amount and has become one of the most widely used crypto currencies. Due to some initial limitations set by the inventor and the following developers, the transaction throughput of the Bitcoin network is much limited. Recently, the transaction throughput has been close to the maximum limit, and the corresponding transaction confirmation time has been greatly increased. Not only this affects user experiences of Bitcoin and limits its usage, but also this puts forward higher requirements for Bitcoin protocol design. Focusing on the challenges of transaction processing performance, this paper aims to promote blockchain capacity and takes a deep research on Bitcoin protocol. Firstly, we do a research on the current network status of Bitcoin, and analyze the transaction delay according to Bitcoin transaction data. Secondly, we analyze the feasibility and effectiveness of on-chain scaling proposals. Thirdly, we analyze mechanics and effects of off-chain scaling proposals. Finally, we analyze the advantages and disadvantages of on-chainoff-chain scaling proposals, and propose a scaling roadmap which meets the community requirements. The recent progress on the Bitcoin scaling shows the correctness of our proposals.
Bitcoin; blockchain; scaling; segregated witness; lightning network
TN918; TP309
YuHui, born in 1994. Bachelor. Student member of CCF. His main research interests include cryptography, blockchain, and smart contract.
ZhangZongyang, born in 1984. PhD, assistant professor, master supervisor. His main research interests include cryptography and blockchain.
LiuJianwei, born in 1964. PhD, professor, PhD supervisor. His main research interests include network security and cyberspace security (liujianwei@buaa.edu.cn).