高性能聯盟區塊鏈技術研究*

朱 立, 俞 歡, 詹士瀟, 邱煒偉, 李啟雷

1(上海證券交易所 技術規劃與服務部,上海 200120)

2(杭州趣鏈科技有限公司,浙江 杭州 310000)

3(浙江大學 軟件學院,浙江 杭州 310000)

區塊鏈是由中本聰于2008年提出的一種支持比特幣運行的底層技術,其去中心化、可追溯、信息不可篡改等特性,給金融服務等一系列行業帶來了重大影響.區塊鏈本質上是一個去中心化的數據庫,是分布式數據存儲、點對點傳輸、共識機制、加密算法等計算機技術的新型應用模式.區塊鏈將給金融業、社會生活、政府管理等各方面帶來變化,尤其是在金融服務業,區塊鏈技術可能會是金融業下一個拐點.2016年,Oliver Wyman國際咨詢公司在一份報告“區塊鏈在資本市場”[1]中指出:目前,銀行每年的IT和運營支出接近1 000億～1 500億美元.此外,交易后和證券服務費用也在1 000億美元左右.由于目前市場運作低效率問題,導致了嚴重的資金損失和流動成本.

分布式賬本技術通過減少重復流程、結算時間、抵押要求和業務開銷,為涉及的實體節省開支.近年來,各國證券交易所都在積極探索區塊鏈技術在市場基礎設施領域上的應用,旨在利用分布式賬本技術來大幅度降低交易成本和系統復雜性,并提高交易和結算速度,從而徹底改變全球資本市場的基礎設施體系,帶來更大的透明度和交易效率.

2016年12月,日本銀行(BoJ)和歐洲央行(ECB)成立了Stella項目,目的是為了研究分布式賬本系統是否能夠取代當前日本央行和歐洲央行部署的實時全額結算系統(RTGS).2017年9月發布了對分布式賬本技術(DLT)的評估報告[2],報告指出:當節點數量增加,DLT方案將會導致網絡中交易結算時間的延長,驗證節點之間的距離也會對性能產生影響.兩家銀行基于Fabric進行了相關測試,使用正常智能合約時,其TPS是10～70之間,最高可達到250TPS.報告得出結論:目前,DLT方案能夠符合大額價值支付系統的性能需求,但當前DLT技術還不夠成熟,不應被用于替代兩家央行的現有系統.

日本交易所集團(JPX)聯合東京股票交易所、大阪交易所以及日本證券清算集團組建了區塊鏈聯盟,旨在測試一種區塊鏈基礎設施概念驗證.2016年2月,JPX宣布與IBM(日本分部)合作測試區塊鏈技術,將使用IBM的 Fabric區塊鏈平臺作為測試實驗的基礎.2016年 8月底,JPX發布了相關工作報告[3],JPX分析并對比了HyperledgerFabric,R3Corda等不同的分布式賬本技術如何幫助公司提高交易效率,以及該技術在金融服務領域的可行性.

2015年,證券交易巨頭納斯達克推出了他們的區塊鏈產品——Nasdaq Linq.2017年5月,納斯達克和花旗銀行宣布采用初創企業Chain的分布式賬本技術來整合支付方案.Linq能夠展示如何在區塊鏈技術上實現資產交易,同時也是一個私人股權管理工具,是納斯達克私人股權市場的一部分.目前,Linq還處于概念探索階段,性能還不能滿足Nasdaq主流業務的需求.

2016年初,主流區塊鏈的吞吐量依然比較慢,比如,比特幣一秒鐘只能完成 7筆交易.目前,以太坊真實吞吐量大約是10筆/s左右.通過調整區塊大小,其吞吐量可以達到30～40筆/s.但與此同時,調整區塊大小也會帶來一系列負面影響,比如叔區塊率增加以及礦工收益降低等.隨著一年以來的技術發展,尤其是共識算法和分片(sharding)技術的逐步成熟,使得區塊鏈的性能得到了較大的提升.一些項目組宣稱,自己可以達到上萬級別的吞吐量,但離開業務背景和測試環境配置,單純提TPS大小是不具備說服力的.因為證券交易業務是一個很好的壓力測試場景,因此,本文將以集中交易的訂單簿的撮合作為業務背景,然后通過控制各種軟硬件配置,盡可能去探索聯盟區塊鏈的性能上限.

本文旨在研究高性能聯盟區塊鏈的優化算法,結合上交所主板證券競價交易系統的業務和現有聯盟鏈技術,針對實際業務場景,對聯盟鏈的共識架構、數字簽名驗證和存儲進行優化,并進行性能基準測試,驗證優化手段的效果.本文的主要貢獻如下.

(1) 采用了業務邏輯與共識分離的架構,將最為耗時的交易執行操作轉交給上交所現有的撮合系統,不再采用耗時的智能合約來執行業務.與此同時,共識過程不再包括業務邏輯的執行,只需負責交易的定序和交易內容的校驗,從而簡化了共識流程,并提升了執行的速度;

(2) 我們對存儲模塊進行了優化,由于本文采用了業務執行和共識分離策略,并使用上交所外部業務系統來執行交易,外部系統數據庫將存儲訂單流水和賬戶信息,故區塊鏈底層平臺不再存儲這部分信息(只需存儲區塊信息),用戶交易流水和賬戶信息的查詢功能也相應地轉移給了上交所的外部系統.機構查賬或審計時才會從區塊中解析出交易信息.考慮到機構查賬或審計是一種低頻率事件,且延時要求低,所以我們對區塊信息的存儲方式進行了優化.不再采用levelDB存儲區塊信息,而是使用順序寫文件的方式存儲區塊信息,從而大幅度提高了寫性能,更加符合業務場景的需求;

(3) 提出了兩種數字簽名驗證的優化策略,分別是多訂單打包驗簽和基于 GPU加速的橢圓曲線驗簽算法.證券交易存在 OPS(orders per second)的概念,一個交易(transaction)里面通常打包了若干筆訂單(order),對這些訂單只需要進行一次簽名,并打包成單個交易一起發送.同時,我們還發現,驗證交易的簽名是整個系統處理流程中較為耗時的一個步驟.故多訂單打包驗簽可以將共識節點簽名和驗簽的開銷平攤在交易中的每筆訂單上,從而降低總體的開銷.同時,合并訂單還減少了節點間的通信量,降低網絡帶寬的負擔.此外,經過對橢圓曲線驗簽算法的分析,我們從有限域運算和橢圓曲線標量乘法運算這兩方面進行了優化,提出了一種全新的快速有限域求模運算,并在此基礎上實現了橢圓曲線標量乘法的并行運算.

本文第1節對區塊鏈(尤其是聯盟鏈)相關工作進行回顧.第2節介紹基本算法和實現.第3節展示實驗結果并進行實驗結果分析.第4節總結本文工作內容,并規劃未來的工作.

1 相關工作

共識算法和安全機制是聯盟鏈的核心要素,下面我們將介紹這兩方面的相關研究.

(1) 共識算法

1982年,Lamport等人提出了拜占庭將軍問題(Byzantine generals problem)[4],它是一個分布式計算領域的問題,設法建立具有容錯性的分布式系統,即:在一個存在故障節點和錯誤信息的分布式系統中,正常節點達到共識,保持信息傳遞的一致性.區塊鏈共識層的作用就是在不同的應用場景下,通過使用共識算法,在決策權高度分散的去中心/多中心化系統中,使得各個節點高效地達成共識.

最初,比特幣區塊鏈選用了一種依賴節點算力的工作量證明共識(proof of work,簡稱 POW)機制來保證比特幣網絡分布式記賬的一致性.隨著區塊鏈技術的不斷演進和改進,研究者們陸續提出了一些不過度依賴算力而能達到全網一致的算法,比如權益證明共識(proof of stake,簡稱POS)機制、授權股份證明共識(delegated proof of stake,簡稱DPOS)機制、實用拜占庭容錯(practical Byzantine fault tolerance,簡稱PBFT)算法等.

然而,POW,POS和DPOS等共識機制不太適合聯盟鏈的應用場景,聯盟鏈中通常采用BFT(Byzantine fault tolerance)類共識機制.這是因為在惡意節點數不超限制的前提下,BFT類算法可以支持較高的吞吐量和極短的終局時間,其正確性和活動性又可被嚴格證明,非常符合大機構的需求.經典的 PBFT算法及其變體是最為常見的聯盟鏈共識算法,PBFT算法最初出現在學術論文中[5],初衷是為一個低延遲存儲系統所設計,降低算法的復雜度.它解決了原始拜占庭容錯算法效率不高的問題,將算法復雜度由指數級降低到多項式級,使得拜占庭容錯算法在實際系統應用中變得可行.PBFT可以應用于吞吐量不大但需要處理大量事件的數字資產平臺,它允許每個節點發布公鑰,任何通過節點的消息都由節點簽名,以驗證其格式.PBFT是首先得到廣泛應用的BFT算法,隨后,業界還提出了若干改進版的BFT共識算法[6-10].

文獻[6]提出了一種可伸縮的故障容忍方法,系統可根據需要配置可容忍的故障數量,而不會顯著降低性能.Q/U是一種quorum-based協議,可用于構建故障可擴展的拜占庭式容錯服務.相較使用agreement-based的副本狀態機協議,Q/U協議可以提供更好的吞吐量和故障可伸縮性.使用Q/U協議構建的原型服務在實驗中優于使用副本狀態機實現的相同服務,使用Q/U協議時,性能減少了36%,而拜占庭式容錯的數量從1增加到5,使用副本狀態機協議時,性能下降了83%.

文獻[7]提出了一種混合拜占庭式容錯狀態機副本協議,在沒有爭用的情況下,HQ采用輕量級的基于仲裁的協議,節省了副本間二次通信的成本.一旦出現爭議,HQ則使用BFT解決爭用.此外,總共僅使用3f+1個副本來容忍f個故障,為節點故障提供了更加優秀的恢復能力.

文獻[8]提出了一種高吞吐量的拜占庭式容錯架構,它使用特定應用程序的信息來識別和同時執行獨立的請求.該體系結構提供一種通用的方法來利用應用程序間的并行性,在提高吞吐量的同時,還不損害系統工作的正確性.

文獻[9]提出了一種使用推測來降低成本并簡化拜占庭容錯狀態機副本的協議.在 Zyzzyva中,副本可直接響應客戶端的請求,而不需要首先運行 PBFT的三階段共識協議來完成請求的定序處理.副本節點可采用主節點提出的請求定序,并立即回應客戶端.副本節點可能會出現不一致,一旦客戶端檢測到不一致,將幫助副本節點收斂在單一請求定序上.同時,Zyzzyva將副本節點開銷降低到了理論最小值附近.

Aardvark算法[10]提出了一種實用的BFT方法,通常被稱為RBFT(robust BFT)算法,RBFT算法使得系統在面對最好和最壞的情況下,性能都能大致保持不變,極大地提高了系統的可用性.

(2) 安全機制

區塊鏈系統通過多種密碼學原理進行數據加密及隱私保護.目前,區塊鏈上傳輸和存儲的數據都是公開可見的,僅通過“偽匿名”的方式對交易雙方進行一定的隱私保護.但對于某些涉及大量商業機密和利益的聯盟鏈業務場景來說,數據的暴露不符合業務規則和監管要求.同態加密、環簽名和零知識證明等技術被認為是解決區塊鏈隱私問題的重要技術手段.

· 同態加密技術允許區塊鏈節點在不知道原始數據的情況下完成對交易信息的驗證,即驗證運算是在加密后的數據之上進行的,得到的結果仍然是加密的,而交易發起方對運算得到的加密結果進行解密,從而得到原始運算結果[11-13];

· 環簽名技術允許節點在不知道交易雙方是誰的情況下完成對交易的驗證和存儲[14];

· 零知識證明技術允許證明者向驗證者證明,并使其相信自己知道或擁有某一消息,但證明過程不能向驗證者泄漏任何關于被證明消息的信息.大量事實證明:如果能夠將零知識證明用于區塊鏈,將很好地解決區塊鏈的隱私保護問題[15].

此外,聯盟鏈中常見的非對稱加密算法有RSA、Elgamal、背包算法、Rabin、D-H、ECC(橢圓曲線加密算法)[16,17]和ECDSA(橢圓曲線數字簽名算法)[18].對部分投產使用的區塊鏈產品,要求使用國密級別的安全算法.

2 高性能聯盟區塊鏈架構設計與實現

本節將介紹提升我們區塊鏈平臺(以下簡稱 Hyperchain)性能的幾種優化策略,包括業務邏輯和共識分離、存儲優化、數字簽名驗證優化這3個部分.

2.1 系統架構

一個典型聯盟鏈系統的工作流如圖1所示.

一筆交易最初從客戶端發起,在簽名后發送給聯盟鏈的節點.服務器端(Http服務器)在收到交易請求后,會校驗交易簽名和交易證書等信息.校驗通過后,再將交易推送給共識模塊,并通過P2P模塊進行廣播,隨后開始節點間的共識.

執行模塊和虛擬機模塊在收到共識模塊的交易信息后,會基于區塊號調取執行環境,并執行交易.執行內容包括簽名驗證和交易執行等過程.驗簽確認了交易的來源和內容的完整和安全性,該過程在執行模塊中進行,而具體的交易執行則會以智能合約等形式在虛擬機中進行.交易執行結束后,變化量會被保存在執行模塊緩存中,供后來的交易或賬本持久化使用.交易結果的Hash會返回給共識模塊用于和其他節點的執行結果進行比對.

圖 2是改進后的系統架構,相較圖 1的典型聯盟鏈系統架構,該架構最大的不同在于將業務邏輯執行模塊與共識驗證模塊解耦合.由于本文是以“去中心化主板證券競價交易系統”為應用場景,上交所現有業務系統的TPS可以達到10萬～30萬.而我們在實際測試中發現,在Hyperchain上使用智能合約執行交易時,TPS僅為幾千,這個吞吐量遠不能滿足主板證券交易的需求.

優化后的聯盟鏈系統架構將交易的執行和共識進行了解耦,使得交易執行任務的轉移和并行變得可能.如果將交易執行的任務交由上交所現有的外部業務系統完成,而不是采用智能合約的形式,區塊鏈底層平臺只負責交易定序及合法性驗證工作,那么系統的吞吐量則可以有很大的提升.故優化后的系統架構更加適合證券交易這類較高頻的業務場景.

下文中,第2.2節針對的是共識模塊的優化,第2.3節是關于賬本模塊的存儲優化,第2.4節提出了兩種優化驗簽模塊的方法.

2.2 業務邏輯和共識分離

在聯盟鏈中,使用智能合約執行交易,并將執行結果加入共識流程是一種較為通用的模式(如圖 3所示).將執行結果加入共識可以保證節點間數據的一致性,而使用智能合約可以增強整個聯盟鏈的通用性.針對不同的業務場景,只需要設計不同的智能合約,而不需要更改架構本身.

在模擬上交所證券撮合業務場景的過程中,我們發現最為耗時的步驟是交易的共識和執行.表 1中,交易的共識和執行占一個區塊生成時間的90%.生成一個區塊的流程大致可以分為區塊打包、區塊共識和區塊提交這3個部分.

Table 1 Duration of each phase表1 每階段占用時長

區塊打包的耗時與客戶端發送交易的內容相關,區塊共識和執行、區塊提交的耗時則與區塊大小和智能合約代碼相關.Hyperchain采用的 PBFT共識一般可以分為 3個階段,分別是 Pre-prepare階段、Prepare階段和Commit階段.

因為區塊執行是按序串行執行的,交易執行大大增加了區塊生成所用的時間,是整個系統的性能瓶頸.為了提高交易執行的效率,首先需要解決智能合約運行效率的問題.在實際研究中,我們發現很難用智能合約進行證券交易撮合的業務.一是證券撮合相對一般業務更為復雜,設計一個高效完備的智能合約難度較大;二是智能合約架構設計本身和證券撮合這類業務沒有很好地適應.智能合約運行的生命周期是完成一筆交易所用的時間,每處理一筆新的交易,系統都要重新從內存或者數據庫中將數據加載進合約,合約處理效率低,無法滿足證券交易所需的吞吐量.

為了解決這一問題,我們采用了一種新的架構——業務邏輯和共識分離(如圖4所示).這是一種在聯盟鏈中越來越流行的架構,如著名開源項目Fabric 1.0(https://hyperledger-fabric.readthedocs.io/en/release-1.3/arch-deepdive.html#system-architecture).采用該架構,交易的執行不再受到節點共識的影響,交易可并行執行.

交易到達節點后,共識節點只負責共識交易的排序和交易的內容,不再執行交易和共識執行結果.定序以后的交易通過網絡通信發送給外部業務系統,由外部業務系統執行具體的交易,并保存交易結果.不同的外部業務系統可以根據需求,決定是否返回執行結果.由于共識節點不再負責交易的執行和執行結果的共識,Hyperchain會在區塊到達檢查點(checkpoint)時再對執行結果進行共識,以保證節點之間數據的一致性.這種架構下,共識節點的功能更傾向于定序和存證.

在這種系統架構下,Hyperchain共識過程不再包括業務邏輯的執行,簡化了共識流程,提升了共識速度.此外,將業務邏輯從共識剝離出來后,交易執行模塊的可擴展性大大提高.Hyperchain可以根據業務需求選擇使用內嵌的 EVM/JVM 虛擬機,或者使用網絡通信對接企業原有的業務系統,不僅降低了開發成本,還能真正實現交易的并行執行.

從圖 4可知:Hyperchain平臺是先進行共識定序和校驗,再調用執行模塊或外部系統來執行交易.而 Fabric是先由客戶端指定所需的背書節點提前執行交易,再由共識(order)節點進行定序和交易合法性校驗.采用先執行后定序的方式必須保證有關聯性的交易可以按序執行,否則會導致交易失敗.先執行后定序的方式并不適合證券交易場景,因為在該場景下,訂單的先后順序直接影響成交,訂單之間的相關性較強.

此外,由于使用網絡通信,交易執行模塊的插拔可以跨語言和平臺,不再限于 Go語言,各模塊可以部署在一臺服務器上以降低成本,也可以選擇分別部署在不同服務器上,讓業務邏輯和共識邏輯可以分布在不同的物理機上,降低IO和CPU的搶占.交易執行模塊可以針對不同業務場景編寫特定交易處理系統,提升效率.以去中心化主板證券競價交易系統為例,簡易 Java撮合系統每秒可以撮合幾十萬筆交易,遠遠超過了目前所有智能合約執行器能達到的效率,使得交易執行的速率可以滿足實際生產中的高頻交易處理需求.

2.3 存儲優化

在Hyperchain運行過程中,我們一般會存儲3部分內容.

(1) 區塊信息:包括區塊內的交易信息、交易執行的順序、交易到達區塊的時間戳、區塊打包時間戳、區塊執行時間戳和區塊哈希等信息,區塊信息包含了區塊上鏈所需的所有內容;

(2) 單筆交易信息和交易回執:Hyperchain為了提供快速的交易查詢功能,交易信息除了儲存于區塊中,也會獨立存儲于數據庫中(如levelDB).交易哈希作為存儲的key,交易內容作為存儲的value.以空間換時間,一次數據庫讀取操作就可以完成交易信息的查詢.交易回執在數據庫的存儲方式和交易信息類似,key是交易哈希加特定前綴,value則記錄了交易執行的結果.用戶通過查詢交易回執可以快速獲知交易結果;

(3) 賬戶數據:區塊鏈是一個分布式的大賬本,每個節點共同參與大賬本的記賬.Hyperchain系統支持使用智能合約執行交易,因此和以太坊一樣,采用賬戶模型來組織數據.每執行一筆交易,都會讀/寫相關賬戶的狀態數據.比如,一個模擬銀行轉賬的合約會生成或者改變用戶余額、轉賬信息等數據.執行結束,會將期間所有的改動統一寫入.

由第 2.2節可知:針對上交所的證券交易業務場景,Hyperchain采用了業務執行和共識分離的策略,不再使用智能合約來執行交易,而是直接使用上交所 Java撮合系統來執行交易,交易流水和賬戶信息會儲存于上交所的數據庫中,所以Hyperchain不再存儲交易流水和賬戶信息.與此同時,用戶的交易流水和賬戶信息的查詢功能也相應地轉移給了上交所外部業務系統.從圖 5虛線條可知:當用戶需要查詢訂單信息或賬戶信息時,我們會默認從上交所數據庫中讀取信息并返回給用戶.如果普通用戶指定要從 Hyperchain查詢訂單信息時,我們會從內存(內存中只保存近期的訂單信息)中讀取該筆訂單信息并返回給用戶,僅當用戶需要查詢歷史訂單信息時,我們才會從區塊中解析出該筆訂單信息并返回給用戶.采用該存儲方式,是因為我們發現證券業務具有很強的時效性,這樣不僅減少了I/O消耗,也節省了磁盤空間.

值得一提的是,智能合約為了滿足通用性,Hyperchain統一使用了NoSQL類型數據庫去存儲數據,故在性能上會遜色于上交所定制化的外部業務系統.一般使用智能合約執行交易時,TPS僅為幾千,但上交所現有業務系統的 TPS可以達到 15萬,深交所新系統 TPS可以達到 30萬左右,在這種高頻業務場景下,I/O可能會成為Hyperchain的性能瓶頸.所以,交易執行和存儲任務的轉移,緩解了Hyperchain的數據庫讀寫壓力.

由上可知,Hyperchain不再單獨存儲每筆交易的信息和回執以及用戶的賬戶信息,只存儲了區塊信息.一段時間后,再向Hyperchain請求交易信息的,可能是機構為了查賬或審計,這時,可從區塊中還原出訂單信息(見圖5實線條).尤其在多中心的業務場景下(如深交所和上交所合作的交易場景),由于區塊鏈具有區塊數據不可篡改的特性,審計單位可以從節點回溯到原始數據,避免了多中心數據不一致的問題.

一般情況下,由于LevelDB有很多和Hyperchain相適應的特性,Hyperchain會選擇LevelDB作為默認數據庫.LevelDB是Google實現的一個高效KV數據庫,支持多條操作的原子批量操作,滿足Hyperchain對原子性寫入區塊信息的需求.借助LSM(log-structured merge tree)樹和WAL(write-ahead logging)的設計,LevelDB寫性能較為出色,隨機寫性能達到每秒40萬條記錄,可以支持Hyperchain快速存儲大量的區塊信息.

考慮到機構查賬或審計是一種低頻率事件,且延時要求低,所以我們對區塊信息的存儲方式進行了優化.不再采用 levelDB存儲區塊信息,而是以一定形式組織區塊,然后存儲在特定后綴的文件中.每個文件存儲固定數目的區塊,在文件被關閉時,文件頭部預留處將添加區塊索引.采用這種形式存取區塊的時間復雜為O(1),不會隨著數據量改變而變化.區塊按序存儲的特性也使得待寫入的數據會在緩存中連續存儲,磁盤 IO多為順序寫,以提高IO效率.這種存儲方式大幅度提高了寫性能,更加適合本文的業務場景.

2.4 數字簽名驗證優化

區塊鏈所有交易都帶有交易簽名,區塊鏈節點通過驗證簽名,確保交易的有效性.在證券交易這種高頻業務場景中,交易數目大,要求程序能快速完成驗簽運算,系統才能具備較低的響應延遲和較高的吞吐量.Hyperchain對驗簽策略進行了優化,加快了簽名運算.Hyperchain對數字簽名驗證優化包括兩方面:多訂單打包驗簽和基于GPU加速的橢圓曲線驗簽算法.

2.4.1 多訂單打包驗簽

由于本文是以去中心化主板證券競價交易系統為應用場景,我們了解到證券交易是一個B2B的市場,證券交易存在 OPS(orders per second)的概念,即:訂單數(order)跟交易(transaction)并不是一一對應的關系,一個transaction里面可以打包若干筆 order.對這些訂單只需要在一次簽名后打包到單個交易中一起發送.實際業務場景中,券商報單就是十幾筆、二十幾筆訂單一起打包發送.

在研究過程中,我們發現交易的簽名驗證是整個系統處理流程中最為耗時步驟之一.在分析了上述證券交易的實際情況以后我們發現,合并驗簽的方式可以提升系統效率.因為單個區塊通常包含不止一筆交易,而共識是按塊進行的,所以打包驗簽是最為直接的優化方案.

打包簽名和驗簽可以將共識節點簽名和驗簽的開銷平攤在塊中的每筆交易上,從而降低總體的開銷.尤其是在證券競價高頻交易的情況下,客戶端往往會一起發送大量的訂單,如果客戶端可以將若干筆訂單合成在一筆交易中,并進行簽名,就會減少大量的驗簽次數.同時,由于網絡帶寬是限制聯盟鏈吞吐量的另一個重要因素,合并訂單還可以減少節點間的通信量,降低網絡帶寬的負擔.

多訂單打包驗簽即在用戶發送交易時候,將多個交易打包成為一個整體,然后通過對應的加密算法(ECDSA或者國密)來進行統一的簽名,隨后發送給服務器進行統一驗簽(如圖6所示).

多訂單打包的內容會被當成一條交易,但在交易驗證的過程中,節點會把交易進行反序列化,并按訂單打包的順序,按序執行訂單內容.

2.4.2 基于GPU加速的橢圓曲線驗簽算法

Hyperchain可支持SM2橢圓曲線公鑰密碼算法[19],橢圓曲線密碼體制的安全性基于橢圓曲線離散對數問題(ECDLP)的難解性.因此,橢圓曲線密碼系統的單位比特強度要遠高于傳統的離散對數系統.因為區塊中所有的交易都帶有簽名,所以簽名速度直接影響了系統響應延時和吞吐量.經過對橢圓曲線驗簽算法的分析,我們提出了用GPU進行硬件加速,實現快速的驗簽運算的方案.

本文使用Tesla M40加速卡來加速SM2算法的簽名驗證.Tesla M40為NVIDIA在2015年推出的針對高性能計算領域的通用圖形處理(GPGPU),其擁有3 072個處理器核心,單精度浮點峰值性能7Tflops.

任何并行系統為了達到最佳性能,程序的并行度都必須大于等于并行系統的物理并行線程數.對于NVIDIA Tesla K40,其擁有3 072個核心,可以同時并行執行3 072個線程,故程序至少應達到3 072的并行度.但對于數字簽名的驗證與簽名等密碼學操作,其本身運算量龐大并且難以并行.經過數學變換后可以得到簽名操作為6的并行度、簽名驗證操作為12的并行度.為了完全利用并行系統的性能,需要將多個運算請求打包統一發送同時執行,以平攤并降低單個運算的時間,這個最低的包大小即為

故對于物理并發度為3 072的Tesla K40,最優區塊大小為

關于橢圓曲線運算具體理論見文獻[20],SM2算法的具體理論見文獻[19].Hyperchain以相關理論為基礎,對現有的有限域運算和橢圓曲線標量乘法運算進行了優化,實現了基于硬件加速的橢圓曲線加密算法:

· 優化1:提升有限域運算性能

為了提升有限域運算的性能,在工程實現上我們采用了CUDA匯編語言PTX來實現.在算法層次上,我們則提出了一種全新的快速有限域求模運算.

有限域元素Fp在計算機中的表達方式,用整數表達單個域元素需要用 256位,在目前計算機體系結構下,必須使用多個整數來表達一個域元素.根據目前多數CUDA設備的計算能力,32位整數的每位均攤運算性能遠高于64位整數[21],故本文采用8個32位整數來表達一個有限域Fp元素:

SM2算法所有的橢圓曲線運算都在Fp中進行,每一步基本運算都需要對p求模.推薦參數中給出的p為:p=0xFFFFFFFEFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF00000000FFFFFFFFFFFFFFFF,p為256位.

直接使用普通的求模運算,開銷十分巨大.為了解決這個問題,Hyperchain提出了一種全新的快速求模算法.快速有限域求模運算的推導過程如下:

對p進行變換,得到P=2256-2224-296+264-1,并參考公式(4)得到:

任意ω=χ·(232-1)2224+γ,γ<(232-1)2224,可以使用公式(4.2)得到:

或者是另一種變體:

若ω1仍然超出了(232-1)2224,再次使用公式(4.3)或公式(4.4)即可.

算法1. 快速有限域求模運算.

輸入:標量ω;

輸出:標量ω′<(232-1)·2224,且ω′≡ωmodp.

1. 當ω>(232-1)·2224,執行循環:

2. 求得γ,x滿足ω=x·(232-1)·2224+γ

3. 令ω=γ+x·(232-1)·264+x

4. 輸出結果ω′=ω

· 優化2:以并行方式實現橢圓曲線標量乘法運算

橢圓曲線標量乘法很難直接并行,且包含除法等在 256位有限域內開銷極大的運算.Hyperchain擬采用Ficher等人在文獻[22]中提出的方法,使用Montgomery階梯算法將一次橢圓曲線數乘運算分解成256次加法與加倍運算的迭代,通過將橢圓曲線點坐標投影到仿射坐標系,以變換每次加法與加倍運算,進而消除除法運算,只留下加法與乘法運算,從而可以并行化實現橢圓曲線標量乘法運算.

算法2. Montgomery階梯算法.

輸入:標量K,曲線C上的點P;

輸出:橢圓曲線標量乘法的結果K×P.

1. 令P1=P,P2=2P

2. 令i從n-2到0循環,n為K的位長

3. 如果K的第i個二進制位為1

4. 那么令P1=P1+P2,P2=2P2

5. 否則,P2=P1+P2,P1=2P1

6. 輸出結果P1

Montgomery階梯算法擁有一個重要的特殊性質,它保證了任何點加與倍操作時,操作數P1,P2間的差值始終為P.而這一重要的性質將允許橢圓曲線點加與倍操作能被并行執行.至此,對橢圓曲線標量乘法的運算已被歸約為并行快速地完成橢圓曲線點加與加倍運算.

· 并行橢圓曲線點加與加倍算法

首先對橢圓曲線上的點進行仿射變換,將點P=(x,y)變換成

參見文獻[22],點加公式可以被變形為P=(Px,Pz),Q=(Qx,Qz)為兩個點,那么:

由此可見:原橢圓曲線運算的加法運算[20]中不可被并行化并包含除法運算的操作,被變形為了可以被并行化并且只有有限域加法與乘法運算的形式.綜上,我們得出了并行的橢圓曲線標量乘法算法.

3 實驗結果與分析

本節通過多個對比實驗來驗證優化策略對系統性能提升的有效性.下文中,第 3.1節詳細介紹了本次實驗的具體配置和指標,第3.2節～第3.4節分別是關于業務邏輯與共識分離、存儲優化和數字簽名等優化策略對性能影響的對比實驗,第3.5節～第3.9節展示和分析了節點數、打包時間、區塊大小、網絡延遲和帶寬等因素對聯盟鏈性能的影響.

3.1 實驗設置

3.1.1 集群環境

(1) 客戶端節點配置(見表2);

(2) Hyperchain節點配置:本次實驗將采用騰訊的云服務器,根據不同場景,實驗會采用多種類型的服務器,具體配置如下.

· 配置1:4臺服務器,Hyperchain默認記賬節點服務器配置.型號:16核32G云服務器(標準型S2,見表3);

· 配置2:大于4臺服務器,用于多節點測試.型號:16核16G云服務器(標準型S1,見表4);

· 配置3:用于國密GPU驗簽測試,型號:CPU 28核56G計算型(GN2).

Table 2 Test environment of the client side表2 客戶端測試環境

Table 3 Standard S2 server configuration表3 標準型S2服務器配置

Table 4 Standard S1 server configuration表4 標準型S1服務器配置

3.1.2 網絡拓撲圖

本次實驗的服務器網絡拓撲圖如圖7所示,左邊部署了Hyperchain平臺節點,右邊的客戶端節點用于發送交易請求,終端節點用于控制Hyperchain節點和客戶端節點.

3.1.3 參數設置

· 記賬節點服務器數量:4臺(標準型S2);

· 客戶端并發度:100×4(4節點,每個節點并發度為100);

· 區塊大小(batch size):500;

· 打包時間(batch time):500ms;

· 合并驗簽數:10.

注:區塊打包有兩種情況,一種是按時間打包(batch time),一種是按交易數目打包(batch size).

3.1.4 性能指標

本實驗擬采用的性能指標包括吞吐量(TPS)和延遲(Latency,默認單位為ms).

(1) 吞吐量計算方式:交易發送完畢后,遍歷測試中間三分之一時間區塊:

(2)Latency計算方式:遍歷測試中間三分之一時間的區塊,計算平均時間:

注 1:遍歷測試中間三分之一時間的區塊是為了統計系統處理能力處于相對穩定狀態時的實驗數據,避免負載不足對實驗結果的影響;

注2:Commit時間為Commit階段(即共識流程的Commit階段)寫數據的時間.

3.2 業務邏輯和共識分離架構對比實驗

本節將分別使用傳統共識架構與業務邏輯和共識分離架構來執行系統交易.采用傳統共識架構時,我們將使用Hyperchain實現的EVM虛擬機來執行交易.

從表5和表6可知,采用業務邏輯和共識分離架構的Hyperchain平臺其系統性能明顯提升.系統運行1分鐘時,TPS和Latency性能效果分別提升了18.5倍和17倍;系統運行5分鐘時,TPS和Latency分別提升了18.7倍和 17.5倍.由此可見,采用業務邏輯和共識分離架構,節點只共識區塊鏈上交易的排序和交易的內容,具體交易交由外部業務系統執行,提升了系統性能.

Table 5 Impacts of separation architecture of business logic and consensus on system throughput表5 業務邏輯和共識分離架構對系統吞吐量的影響

Table 6 Impacts of separation architecture of business logic and consensus on system latency表6 業務邏輯和共識分離架構對系統延遲的影響

3.3 存儲優化對比實驗

Hyperchain采用區塊業務執行和共識分離策略,并使用外部業務系統執行交易,節點不再執行交易,所以數據庫只存儲區塊信息,不再存儲交易執行結果的相關數據.本節通過對比存儲優化前后系統的 TPS和 Latency,來驗證存儲優化對系統性能提升的效果.

從表7和表8可知,系統運行1、5、10、15和30分鐘時,系統的TPS和Latency較為穩定,并無明顯波動.采用存儲優化策略后,TPS和Latency的性能效果平均提升了27.3%和28.7%,系統性能得到了較為明顯的提升.

Table 7 Impacts of storage optimization on system throughput表7 存儲優化對系統吞吐量的影響

Table 8 Impacts of storage optimization on system latency表8 存儲優化對系統延遲的影響

3.4 數字簽名驗證優化對比實驗

3.4.1 多訂單打包驗簽對系統性能的影響

本節我們將改變每個交易包含的訂單(order)數量,來驗證統一驗簽功能對系統性能提升的有效性.

每筆交易只包含一個訂單(1 order)時,系統的瓶頸在于驗簽.由表 9可知:每筆交易分別包含 10 order、20 order、30 order進行統一驗簽時,系統交易的吞吐量逐漸下降.一方面是因為網絡帶寬的壓力增加,轉發時間變長;另一方面是因為節點處理 order數增加,反序列化存在內存中更加緩慢.但系統訂單的吞吐量在增加,因為驗簽是系統的瓶頸,打包驗簽將低了驗簽的次數.

Table 9 Impacts of multi-order packaging verification on system throughput and latency表9 不同訂單數量的打包驗簽對性能的影響

3.4.2 基于GPU的國密簽名對性能的影響

本節對Hyperchain平臺實現的CUDA并行版本的SM2算法與GmSSL庫進行對比.GmSSL是一套基于OpenSSL使用純CPU實現的SM系列算法庫,是目前工業界常用的SM2算法實現.

測試環境:服務器類型為配置3(GN2),在本次實驗中,平臺的記賬節點是4.

由表10可知,GPU驗簽的吞吐量是CPU驗簽的4.5倍左右.由表11可知,GPU驗簽的延遲時間只有CPU驗簽的一半.

Table 10 Impacts of GPU Optimization on system throughput表10 GPU優化對系統吞吐量的影響

Table 11 Impacts of GPU optimization on system latency表11 GPU優化對系統延遲的影響

3.5 節點數對系統性能的影響

當節點數量增加,聯盟鏈方案將會導致網絡中交易結算時間的延長.本節將測試不同節點數下的系統性能.

在服務器配置2的情況下,由圖8和圖9可知:隨著節點數的增加,系統性能略有提升.這是因為節點數在一定范圍內增加時(系統帶寬還未成為瓶頸的范圍內),發起共識之前的驗簽壓力可以分攤給各個節點,每個節點可以擁有更多的資源用于共識.在 8節點后,系統性能略有下降.這是由于共識節點之間需要相互通信(發送request,pre-prepare等消息),節點數過多后,系統帶寬會逐漸成為性能瓶頸.

由于課題經費有限,我們沒有測試更多節點的場景.總的來說,從4個節點～10個節點,系統吞吐量變化不大.這是由于此時系統帶寬還沒碰到瓶頸.

3.6 Batch time對系統性能的影響

在服務器配置1的條件下,由表12可知,區塊打包時間對系統性能沒有顯著影響.

Table 12 Impacts of batch time on system throughput and latency表12 區塊打包時間對系統性能的影響

3.7 Batch size對系統性能的影響

在服務器配置1(4節點)的條件下,由圖10可知,Batch size小于200后TPS較顯著下降.由圖11可知,Batch size越大延遲越高.這是因為區塊需要在共識節點間進行流轉,受網絡帶寬的限制,造成Batch size越大延遲也越高.選用200～500筆交易作為區塊大小為佳.

3.8 網絡延遲對系統性能的影響

驗證節點之間的距離也會對性能產生影響,物理距離太近使得吞吐量會變得很高,所以我們人為地用LINUX的工具軟件增加了網卡延遲.

由表13可知,隨著網絡延時的提升,系統TPS略有下降,Latency急劇提升.在網絡延時大于等于500ms以后,節點間的共識會超時,使交易無法正常執行.

Table 13 Network delays impacts on system throughput and latency表13 網絡延遲對系統性能的影響

3.9 帶寬對系統性能的影響

在服務器配置1的條件下,由圖12可知,帶寬對TPS有顯著影響.在4節點情況下,10MB帶寬僅有642TPS;500MB帶寬時,帶寬瓶頸不再顯著.由圖13可知:隨著帶寬的增加,系統延遲顯著減小.目前,網絡帶寬是限制聯盟鏈吞吐量的最主要因素之一.

4 總結與展望

我們已經研究了聯盟區塊鏈技術應用于證券撮合系統的技術難點,并提出了高性能撮合系統解決方案.課題組對接了 Java撮合系統并進行了性能測試、可靠性測試和部分調優等工作.針對證券交易的訂單,整個系統的處理速度可以達到20萬/s.在不同節點數量、區塊大小和網絡延遲的條件下,也能保證正確性和較高的性能.

未來我們將繼續探索FPGA、微服務架構等技術在區塊鏈領域的相關應用.微服務架構是一個分布式的技術架構,可對應用進行模塊拆分,具備敏捷開發、快速演化和彈性伸縮等特性.使用微服務架構可進一步提升聯盟鏈系統性能.目前,我們已經將共識模塊和業務邏輯執行模塊進行分離,執行過程比較耗時;而共識模塊比較穩定,拆分之后的共識模塊可不受執行效率的影響.在執行模塊中,虛擬機和存儲模塊也可做進一步拆分.未來還可以使用 FPGA對更多加密算法與其他功能函數進行更高性能的優化.由于密碼學模型與電子電路模型的天然相似性以及FPGA模型的流水線并行模式,密碼學算法在FPGA上的實現能夠輕松地發揮FPGA的全部性能,同時保持足夠的并行度.而且FPGA本身的性能上限并不輸于CPU與GPU,甚至在整數計算上擁有更強的能力.因此,使用FPGA實現密碼學算法能夠提升更快的性能.