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

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

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

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

區(qū)塊鏈?zhǔn)怯芍斜韭斢?008年提出的一種支持比特幣運(yùn)行的底層技術(shù),其去中心化、可追溯、信息不可篡改等特性,給金融服務(wù)等一系列行業(yè)帶來了重大影響.區(qū)塊鏈本質(zhì)上是一個(gè)去中心化的數(shù)據(jù)庫(kù),是分布式數(shù)據(jù)存儲(chǔ)、點(diǎn)對(duì)點(diǎn)傳輸、共識(shí)機(jī)制、加密算法等計(jì)算機(jī)技術(shù)的新型應(yīng)用模式.區(qū)塊鏈將給金融業(yè)、社會(huì)生活、政府管理等各方面帶來變化,尤其是在金融服務(wù)業(yè),區(qū)塊鏈技術(shù)可能會(huì)是金融業(yè)下一個(gè)拐點(diǎn).2016年,Oliver Wyman國(guó)際咨詢公司在一份報(bào)告“區(qū)塊鏈在資本市場(chǎng)”[1]中指出:目前,銀行每年的IT和運(yùn)營(yíng)支出接近1 000億～1 500億美元.此外,交易后和證券服務(wù)費(fèi)用也在1 000億美元左右.由于目前市場(chǎng)運(yùn)作低效率問題,導(dǎo)致了嚴(yán)重的資金損失和流動(dòng)成本.

分布式賬本技術(shù)通過減少重復(fù)流程、結(jié)算時(shí)間、抵押要求和業(yè)務(wù)開銷,為涉及的實(shí)體節(jié)省開支.近年來,各國(guó)證券交易所都在積極探索區(qū)塊鏈技術(shù)在市場(chǎng)基礎(chǔ)設(shè)施領(lǐng)域上的應(yīng)用,旨在利用分布式賬本技術(shù)來大幅度降低交易成本和系統(tǒng)復(fù)雜性,并提高交易和結(jié)算速度,從而徹底改變?nèi)蛸Y本市場(chǎng)的基礎(chǔ)設(shè)施體系,帶來更大的透明度和交易效率.

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

日本交易所集團(tuán)(JPX)聯(lián)合東京股票交易所、大阪交易所以及日本證券清算集團(tuán)組建了區(qū)塊鏈聯(lián)盟,旨在測(cè)試一種區(qū)塊鏈基礎(chǔ)設(shè)施概念驗(yàn)證.2016年2月,JPX宣布與IBM(日本分部)合作測(cè)試區(qū)塊鏈技術(shù),將使用IBM的 Fabric區(qū)塊鏈平臺(tái)作為測(cè)試實(shí)驗(yàn)的基礎(chǔ).2016年 8月底,JPX發(fā)布了相關(guān)工作報(bào)告[3],JPX分析并對(duì)比了HyperledgerFabric,R3Corda等不同的分布式賬本技術(shù)如何幫助公司提高交易效率,以及該技術(shù)在金融服務(wù)領(lǐng)域的可行性.

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

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

本文旨在研究高性能聯(lián)盟區(qū)塊鏈的優(yōu)化算法,結(jié)合上交所主板證券競(jìng)價(jià)交易系統(tǒng)的業(yè)務(wù)和現(xiàn)有聯(lián)盟鏈技術(shù),針對(duì)實(shí)際業(yè)務(wù)場(chǎng)景,對(duì)聯(lián)盟鏈的共識(shí)架構(gòu)、數(shù)字簽名驗(yàn)證和存儲(chǔ)進(jìn)行優(yōu)化,并進(jìn)行性能基準(zhǔn)測(cè)試,驗(yàn)證優(yōu)化手段的效果.本文的主要貢獻(xiàn)如下.

(1) 采用了業(yè)務(wù)邏輯與共識(shí)分離的架構(gòu),將最為耗時(shí)的交易執(zhí)行操作轉(zhuǎn)交給上交所現(xiàn)有的撮合系統(tǒng),不再采用耗時(shí)的智能合約來執(zhí)行業(yè)務(wù).與此同時(shí),共識(shí)過程不再包括業(yè)務(wù)邏輯的執(zhí)行,只需負(fù)責(zé)交易的定序和交易內(nèi)容的校驗(yàn),從而簡(jiǎn)化了共識(shí)流程,并提升了執(zhí)行的速度;

(2) 我們對(duì)存儲(chǔ)模塊進(jìn)行了優(yōu)化,由于本文采用了業(yè)務(wù)執(zhí)行和共識(shí)分離策略,并使用上交所外部業(yè)務(wù)系統(tǒng)來執(zhí)行交易,外部系統(tǒng)數(shù)據(jù)庫(kù)將存儲(chǔ)訂單流水和賬戶信息,故區(qū)塊鏈底層平臺(tái)不再存儲(chǔ)這部分信息(只需存儲(chǔ)區(qū)塊信息),用戶交易流水和賬戶信息的查詢功能也相應(yīng)地轉(zhuǎn)移給了上交所的外部系統(tǒng).機(jī)構(gòu)查賬或?qū)徲?jì)時(shí)才會(huì)從區(qū)塊中解析出交易信息.考慮到機(jī)構(gòu)查賬或?qū)徲?jì)是一種低頻率事件,且延時(shí)要求低,所以我們對(duì)區(qū)塊信息的存儲(chǔ)方式進(jìn)行了優(yōu)化.不再采用levelDB存儲(chǔ)區(qū)塊信息,而是使用順序?qū)懳募姆绞酱鎯?chǔ)區(qū)塊信息,從而大幅度提高了寫性能,更加符合業(yè)務(wù)場(chǎng)景的需求;

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

本文第1節(jié)對(duì)區(qū)塊鏈(尤其是聯(lián)盟鏈)相關(guān)工作進(jìn)行回顧.第2節(jié)介紹基本算法和實(shí)現(xiàn).第3節(jié)展示實(shí)驗(yàn)結(jié)果并進(jìn)行實(shí)驗(yàn)結(jié)果分析.第4節(jié)總結(jié)本文工作內(nèi)容,并規(guī)劃未來的工作.

1 相關(guān)工作

共識(shí)算法和安全機(jī)制是聯(lián)盟鏈的核心要素,下面我們將介紹這兩方面的相關(guān)研究.

(1) 共識(shí)算法

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

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

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

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

文獻(xiàn)[7]提出了一種混合拜占庭式容錯(cuò)狀態(tài)機(jī)副本協(xié)議,在沒有爭(zhēng)用的情況下,HQ采用輕量級(jí)的基于仲裁的協(xié)議,節(jié)省了副本間二次通信的成本.一旦出現(xiàn)爭(zhēng)議,HQ則使用BFT解決爭(zhēng)用.此外,總共僅使用3f+1個(gè)副本來容忍f個(gè)故障,為節(jié)點(diǎn)故障提供了更加優(yōu)秀的恢復(fù)能力.

文獻(xiàn)[8]提出了一種高吞吐量的拜占庭式容錯(cuò)架構(gòu),它使用特定應(yīng)用程序的信息來識(shí)別和同時(shí)執(zhí)行獨(dú)立的請(qǐng)求.該體系結(jié)構(gòu)提供一種通用的方法來利用應(yīng)用程序間的并行性,在提高吞吐量的同時(shí),還不損害系統(tǒng)工作的正確性.

文獻(xiàn)[9]提出了一種使用推測(cè)來降低成本并簡(jiǎn)化拜占庭容錯(cuò)狀態(tài)機(jī)副本的協(xié)議.在 Zyzzyva中,副本可直接響應(yīng)客戶端的請(qǐng)求,而不需要首先運(yùn)行 PBFT的三階段共識(shí)協(xié)議來完成請(qǐng)求的定序處理.副本節(jié)點(diǎn)可采用主節(jié)點(diǎn)提出的請(qǐng)求定序,并立即回應(yīng)客戶端.副本節(jié)點(diǎn)可能會(huì)出現(xiàn)不一致,一旦客戶端檢測(cè)到不一致,將幫助副本節(jié)點(diǎn)收斂在單一請(qǐng)求定序上.同時(shí),Zyzzyva將副本節(jié)點(diǎn)開銷降低到了理論最小值附近.

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

(2) 安全機(jī)制

區(qū)塊鏈系統(tǒng)通過多種密碼學(xué)原理進(jìn)行數(shù)據(jù)加密及隱私保護(hù).目前,區(qū)塊鏈上傳輸和存儲(chǔ)的數(shù)據(jù)都是公開可見的,僅通過“偽匿名”的方式對(duì)交易雙方進(jìn)行一定的隱私保護(hù).但對(duì)于某些涉及大量商業(yè)機(jī)密和利益的聯(lián)盟鏈業(yè)務(wù)場(chǎng)景來說,數(shù)據(jù)的暴露不符合業(yè)務(wù)規(guī)則和監(jiān)管要求.同態(tài)加密、環(huán)簽名和零知識(shí)證明等技術(shù)被認(rèn)為是解決區(qū)塊鏈隱私問題的重要技術(shù)手段.

· 同態(tài)加密技術(shù)允許區(qū)塊鏈節(jié)點(diǎn)在不知道原始數(shù)據(jù)的情況下完成對(duì)交易信息的驗(yàn)證,即驗(yàn)證運(yùn)算是在加密后的數(shù)據(jù)之上進(jìn)行的,得到的結(jié)果仍然是加密的,而交易發(fā)起方對(duì)運(yùn)算得到的加密結(jié)果進(jìn)行解密,從而得到原始運(yùn)算結(jié)果[11-13];

· 環(huán)簽名技術(shù)允許節(jié)點(diǎn)在不知道交易雙方是誰(shuí)的情況下完成對(duì)交易的驗(yàn)證和存儲(chǔ)[14];

· 零知識(shí)證明技術(shù)允許證明者向驗(yàn)證者證明,并使其相信自己知道或擁有某一消息,但證明過程不能向驗(yàn)證者泄漏任何關(guān)于被證明消息的信息.大量事實(shí)證明:如果能夠?qū)⒘阒R(shí)證明用于區(qū)塊鏈,將很好地解決區(qū)塊鏈的隱私保護(hù)問題[15].

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

2 高性能聯(lián)盟區(qū)塊鏈架構(gòu)設(shè)計(jì)與實(shí)現(xiàn)

本節(jié)將介紹提升我們區(qū)塊鏈平臺(tái)(以下簡(jiǎn)稱 Hyperchain)性能的幾種優(yōu)化策略,包括業(yè)務(wù)邏輯和共識(shí)分離、存儲(chǔ)優(yōu)化、數(shù)字簽名驗(yàn)證優(yōu)化這3個(gè)部分.

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

一個(gè)典型聯(lián)盟鏈系統(tǒng)的工作流如圖1所示.

一筆交易最初從客戶端發(fā)起,在簽名后發(fā)送給聯(lián)盟鏈的節(jié)點(diǎn).服務(wù)器端(Http服務(wù)器)在收到交易請(qǐng)求后,會(huì)校驗(yàn)交易簽名和交易證書等信息.校驗(yàn)通過后,再將交易推送給共識(shí)模塊,并通過P2P模塊進(jìn)行廣播,隨后開始節(jié)點(diǎn)間的共識(shí).

執(zhí)行模塊和虛擬機(jī)模塊在收到共識(shí)模塊的交易信息后,會(huì)基于區(qū)塊號(hào)調(diào)取執(zhí)行環(huán)境,并執(zhí)行交易.執(zhí)行內(nèi)容包括簽名驗(yàn)證和交易執(zhí)行等過程.驗(yàn)簽確認(rèn)了交易的來源和內(nèi)容的完整和安全性,該過程在執(zhí)行模塊中進(jìn)行,而具體的交易執(zhí)行則會(huì)以智能合約等形式在虛擬機(jī)中進(jìn)行.交易執(zhí)行結(jié)束后,變化量會(huì)被保存在執(zhí)行模塊緩存中,供后來的交易或賬本持久化使用.交易結(jié)果的Hash會(huì)返回給共識(shí)模塊用于和其他節(jié)點(diǎn)的執(zhí)行結(jié)果進(jìn)行比對(duì).

圖 2是改進(jìn)后的系統(tǒng)架構(gòu),相較圖 1的典型聯(lián)盟鏈系統(tǒng)架構(gòu),該架構(gòu)最大的不同在于將業(yè)務(wù)邏輯執(zhí)行模塊與共識(shí)驗(yàn)證模塊解耦合.由于本文是以“去中心化主板證券競(jìng)價(jià)交易系統(tǒng)”為應(yīng)用場(chǎng)景,上交所現(xiàn)有業(yè)務(wù)系統(tǒng)的TPS可以達(dá)到10萬(wàn)～30萬(wàn).而我們?cè)趯?shí)際測(cè)試中發(fā)現(xiàn),在Hyperchain上使用智能合約執(zhí)行交易時(shí),TPS僅為幾千,這個(gè)吞吐量遠(yuǎn)不能滿足主板證券交易的需求.

優(yōu)化后的聯(lián)盟鏈系統(tǒng)架構(gòu)將交易的執(zhí)行和共識(shí)進(jìn)行了解耦,使得交易執(zhí)行任務(wù)的轉(zhuǎn)移和并行變得可能.如果將交易執(zhí)行的任務(wù)交由上交所現(xiàn)有的外部業(yè)務(wù)系統(tǒng)完成,而不是采用智能合約的形式,區(qū)塊鏈底層平臺(tái)只負(fù)責(zé)交易定序及合法性驗(yàn)證工作,那么系統(tǒng)的吞吐量則可以有很大的提升.故優(yōu)化后的系統(tǒng)架構(gòu)更加適合證券交易這類較高頻的業(yè)務(wù)場(chǎng)景.

下文中,第2.2節(jié)針對(duì)的是共識(shí)模塊的優(yōu)化,第2.3節(jié)是關(guān)于賬本模塊的存儲(chǔ)優(yōu)化,第2.4節(jié)提出了兩種優(yōu)化驗(yàn)簽?zāi)K的方法.

2.2 業(yè)務(wù)邏輯和共識(shí)分離

在聯(lián)盟鏈中,使用智能合約執(zhí)行交易,并將執(zhí)行結(jié)果加入共識(shí)流程是一種較為通用的模式(如圖 3所示).將執(zhí)行結(jié)果加入共識(shí)可以保證節(jié)點(diǎn)間數(shù)據(jù)的一致性,而使用智能合約可以增強(qiáng)整個(gè)聯(lián)盟鏈的通用性.針對(duì)不同的業(yè)務(wù)場(chǎng)景,只需要設(shè)計(jì)不同的智能合約,而不需要更改架構(gòu)本身.

在模擬上交所證券撮合業(yè)務(wù)場(chǎng)景的過程中,我們發(fā)現(xiàn)最為耗時(shí)的步驟是交易的共識(shí)和執(zhí)行.表 1中,交易的共識(shí)和執(zhí)行占一個(gè)區(qū)塊生成時(shí)間的90%.生成一個(gè)區(qū)塊的流程大致可以分為區(qū)塊打包、區(qū)塊共識(shí)和區(qū)塊提交這3個(gè)部分.

Table 1 Duration of each phase表1 每階段占用時(shí)長(zhǎng)

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

因?yàn)閰^(qū)塊執(zhí)行是按序串行執(zhí)行的,交易執(zhí)行大大增加了區(qū)塊生成所用的時(shí)間,是整個(gè)系統(tǒng)的性能瓶頸.為了提高交易執(zhí)行的效率,首先需要解決智能合約運(yùn)行效率的問題.在實(shí)際研究中,我們發(fā)現(xiàn)很難用智能合約進(jìn)行證券交易撮合的業(yè)務(wù).一是證券撮合相對(duì)一般業(yè)務(wù)更為復(fù)雜,設(shè)計(jì)一個(gè)高效完備的智能合約難度較大;二是智能合約架構(gòu)設(shè)計(jì)本身和證券撮合這類業(yè)務(wù)沒有很好地適應(yīng).智能合約運(yùn)行的生命周期是完成一筆交易所用的時(shí)間,每處理一筆新的交易,系統(tǒng)都要重新從內(nèi)存或者數(shù)據(jù)庫(kù)中將數(shù)據(jù)加載進(jìn)合約,合約處理效率低,無法滿足證券交易所需的吞吐量.

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

交易到達(dá)節(jié)點(diǎn)后,共識(shí)節(jié)點(diǎn)只負(fù)責(zé)共識(shí)交易的排序和交易的內(nèi)容,不再執(zhí)行交易和共識(shí)執(zhí)行結(jié)果.定序以后的交易通過網(wǎng)絡(luò)通信發(fā)送給外部業(yè)務(wù)系統(tǒng),由外部業(yè)務(wù)系統(tǒng)執(zhí)行具體的交易,并保存交易結(jié)果.不同的外部業(yè)務(wù)系統(tǒng)可以根據(jù)需求,決定是否返回執(zhí)行結(jié)果.由于共識(shí)節(jié)點(diǎn)不再負(fù)責(zé)交易的執(zhí)行和執(zhí)行結(jié)果的共識(shí),Hyperchain會(huì)在區(qū)塊到達(dá)檢查點(diǎn)(checkpoint)時(shí)再對(duì)執(zhí)行結(jié)果進(jìn)行共識(shí),以保證節(jié)點(diǎn)之間數(shù)據(jù)的一致性.這種架構(gòu)下,共識(shí)節(jié)點(diǎn)的功能更傾向于定序和存證.

在這種系統(tǒng)架構(gòu)下,Hyperchain共識(shí)過程不再包括業(yè)務(wù)邏輯的執(zhí)行,簡(jiǎn)化了共識(shí)流程,提升了共識(shí)速度.此外,將業(yè)務(wù)邏輯從共識(shí)剝離出來后,交易執(zhí)行模塊的可擴(kuò)展性大大提高.Hyperchain可以根據(jù)業(yè)務(wù)需求選擇使用內(nèi)嵌的 EVM/JVM 虛擬機(jī),或者使用網(wǎng)絡(luò)通信對(duì)接企業(yè)原有的業(yè)務(wù)系統(tǒng),不僅降低了開發(fā)成本,還能真正實(shí)現(xiàn)交易的并行執(zhí)行.

從圖 4可知:Hyperchain平臺(tái)是先進(jìn)行共識(shí)定序和校驗(yàn),再調(diào)用執(zhí)行模塊或外部系統(tǒng)來執(zhí)行交易.而 Fabric是先由客戶端指定所需的背書節(jié)點(diǎn)提前執(zhí)行交易,再由共識(shí)(order)節(jié)點(diǎn)進(jìn)行定序和交易合法性校驗(yàn).采用先執(zhí)行后定序的方式必須保證有關(guān)聯(lián)性的交易可以按序執(zhí)行,否則會(huì)導(dǎo)致交易失敗.先執(zhí)行后定序的方式并不適合證券交易場(chǎng)景,因?yàn)樵谠搱?chǎng)景下,訂單的先后順序直接影響成交,訂單之間的相關(guān)性較強(qiáng).

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

2.3 存儲(chǔ)優(yōu)化

在Hyperchain運(yùn)行過程中,我們一般會(huì)存儲(chǔ)3部分內(nèi)容.

(1) 區(qū)塊信息:包括區(qū)塊內(nèi)的交易信息、交易執(zhí)行的順序、交易到達(dá)區(qū)塊的時(shí)間戳、區(qū)塊打包時(shí)間戳、區(qū)塊執(zhí)行時(shí)間戳和區(qū)塊哈希等信息,區(qū)塊信息包含了區(qū)塊上鏈所需的所有內(nèi)容;

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

(3) 賬戶數(shù)據(jù):區(qū)塊鏈?zhǔn)且粋€(gè)分布式的大賬本,每個(gè)節(jié)點(diǎn)共同參與大賬本的記賬.Hyperchain系統(tǒng)支持使用智能合約執(zhí)行交易,因此和以太坊一樣,采用賬戶模型來組織數(shù)據(jù).每執(zhí)行一筆交易,都會(huì)讀/寫相關(guān)賬戶的狀態(tài)數(shù)據(jù).比如,一個(gè)模擬銀行轉(zhuǎn)賬的合約會(huì)生成或者改變用戶余額、轉(zhuǎn)賬信息等數(shù)據(jù).執(zhí)行結(jié)束,會(huì)將期間所有的改動(dòng)統(tǒng)一寫入.

由第 2.2節(jié)可知:針對(duì)上交所的證券交易業(yè)務(wù)場(chǎng)景,Hyperchain采用了業(yè)務(wù)執(zhí)行和共識(shí)分離的策略,不再使用智能合約來執(zhí)行交易,而是直接使用上交所 Java撮合系統(tǒng)來執(zhí)行交易,交易流水和賬戶信息會(huì)儲(chǔ)存于上交所的數(shù)據(jù)庫(kù)中,所以Hyperchain不再存儲(chǔ)交易流水和賬戶信息.與此同時(shí),用戶的交易流水和賬戶信息的查詢功能也相應(yīng)地轉(zhuǎn)移給了上交所外部業(yè)務(wù)系統(tǒng).從圖 5虛線條可知:當(dāng)用戶需要查詢訂單信息或賬戶信息時(shí),我們會(huì)默認(rèn)從上交所數(shù)據(jù)庫(kù)中讀取信息并返回給用戶.如果普通用戶指定要從 Hyperchain查詢訂單信息時(shí),我們會(huì)從內(nèi)存(內(nèi)存中只保存近期的訂單信息)中讀取該筆訂單信息并返回給用戶,僅當(dāng)用戶需要查詢歷史訂單信息時(shí),我們才會(huì)從區(qū)塊中解析出該筆訂單信息并返回給用戶.采用該存儲(chǔ)方式,是因?yàn)槲覀儼l(fā)現(xiàn)證券業(yè)務(wù)具有很強(qiáng)的時(shí)效性,這樣不僅減少了I/O消耗,也節(jié)省了磁盤空間.

值得一提的是,智能合約為了滿足通用性,Hyperchain統(tǒng)一使用了NoSQL類型數(shù)據(jù)庫(kù)去存儲(chǔ)數(shù)據(jù),故在性能上會(huì)遜色于上交所定制化的外部業(yè)務(wù)系統(tǒng).一般使用智能合約執(zhí)行交易時(shí),TPS僅為幾千,但上交所現(xiàn)有業(yè)務(wù)系統(tǒng)的 TPS可以達(dá)到 15萬(wàn),深交所新系統(tǒng) TPS可以達(dá)到 30萬(wàn)左右,在這種高頻業(yè)務(wù)場(chǎng)景下,I/O可能會(huì)成為Hyperchain的性能瓶頸.所以,交易執(zhí)行和存儲(chǔ)任務(wù)的轉(zhuǎn)移,緩解了Hyperchain的數(shù)據(jù)庫(kù)讀寫壓力.

由上可知,Hyperchain不再單獨(dú)存儲(chǔ)每筆交易的信息和回執(zhí)以及用戶的賬戶信息,只存儲(chǔ)了區(qū)塊信息.一段時(shí)間后,再向Hyperchain請(qǐng)求交易信息的,可能是機(jī)構(gòu)為了查賬或?qū)徲?jì),這時(shí),可從區(qū)塊中還原出訂單信息(見圖5實(shí)線條).尤其在多中心的業(yè)務(wù)場(chǎng)景下(如深交所和上交所合作的交易場(chǎng)景),由于區(qū)塊鏈具有區(qū)塊數(shù)據(jù)不可篡改的特性,審計(jì)單位可以從節(jié)點(diǎn)回溯到原始數(shù)據(jù),避免了多中心數(shù)據(jù)不一致的問題.

一般情況下,由于LevelDB有很多和Hyperchain相適應(yīng)的特性,Hyperchain會(huì)選擇LevelDB作為默認(rèn)數(shù)據(jù)庫(kù).LevelDB是Google實(shí)現(xiàn)的一個(gè)高效KV數(shù)據(jù)庫(kù),支持多條操作的原子批量操作,滿足Hyperchain對(duì)原子性寫入?yún)^(qū)塊信息的需求.借助LSM(log-structured merge tree)樹和WAL(write-ahead logging)的設(shè)計(jì),LevelDB寫性能較為出色,隨機(jī)寫性能達(dá)到每秒40萬(wàn)條記錄,可以支持Hyperchain快速存儲(chǔ)大量的區(qū)塊信息.

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

2.4 數(shù)字簽名驗(yàn)證優(yōu)化

區(qū)塊鏈所有交易都帶有交易簽名,區(qū)塊鏈節(jié)點(diǎn)通過驗(yàn)證簽名,確保交易的有效性.在證券交易這種高頻業(yè)務(wù)場(chǎng)景中,交易數(shù)目大,要求程序能快速完成驗(yàn)簽運(yùn)算,系統(tǒng)才能具備較低的響應(yīng)延遲和較高的吞吐量.Hyperchain對(duì)驗(yàn)簽策略進(jìn)行了優(yōu)化,加快了簽名運(yùn)算.Hyperchain對(duì)數(shù)字簽名驗(yàn)證優(yōu)化包括兩方面:多訂單打包驗(yàn)簽和基于GPU加速的橢圓曲線驗(yàn)簽算法.

2.4.1 多訂單打包驗(yàn)簽

由于本文是以去中心化主板證券競(jìng)價(jià)交易系統(tǒng)為應(yīng)用場(chǎng)景,我們了解到證券交易是一個(gè)B2B的市場(chǎng),證券交易存在 OPS(orders per second)的概念,即:訂單數(shù)(order)跟交易(transaction)并不是一一對(duì)應(yīng)的關(guān)系,一個(gè)transaction里面可以打包若干筆 order.對(duì)這些訂單只需要在一次簽名后打包到單個(gè)交易中一起發(fā)送.實(shí)際業(yè)務(wù)場(chǎng)景中,券商報(bào)單就是十幾筆、二十幾筆訂單一起打包發(fā)送.

在研究過程中,我們發(fā)現(xiàn)交易的簽名驗(yàn)證是整個(gè)系統(tǒng)處理流程中最為耗時(shí)步驟之一.在分析了上述證券交易的實(shí)際情況以后我們發(fā)現(xiàn),合并驗(yàn)簽的方式可以提升系統(tǒng)效率.因?yàn)閱蝹€(gè)區(qū)塊通常包含不止一筆交易,而共識(shí)是按塊進(jìn)行的,所以打包驗(yàn)簽是最為直接的優(yōu)化方案.

打包簽名和驗(yàn)簽可以將共識(shí)節(jié)點(diǎn)簽名和驗(yàn)簽的開銷平攤在塊中的每筆交易上,從而降低總體的開銷.尤其是在證券競(jìng)價(jià)高頻交易的情況下,客戶端往往會(huì)一起發(fā)送大量的訂單,如果客戶端可以將若干筆訂單合成在一筆交易中,并進(jìn)行簽名,就會(huì)減少大量的驗(yàn)簽次數(shù).同時(shí),由于網(wǎng)絡(luò)帶寬是限制聯(lián)盟鏈吞吐量的另一個(gè)重要因素,合并訂單還可以減少節(jié)點(diǎn)間的通信量,降低網(wǎng)絡(luò)帶寬的負(fù)擔(dān).

多訂單打包驗(yàn)簽即在用戶發(fā)送交易時(shí)候,將多個(gè)交易打包成為一個(gè)整體,然后通過對(duì)應(yīng)的加密算法(ECDSA或者國(guó)密)來進(jìn)行統(tǒng)一的簽名,隨后發(fā)送給服務(wù)器進(jìn)行統(tǒng)一驗(yàn)簽(如圖6所示).

多訂單打包的內(nèi)容會(huì)被當(dāng)成一條交易,但在交易驗(yàn)證的過程中,節(jié)點(diǎn)會(huì)把交易進(jìn)行反序列化,并按訂單打包的順序,按序執(zhí)行訂單內(nèi)容.

2.4.2 基于GPU加速的橢圓曲線驗(yàn)簽算法

Hyperchain可支持SM2橢圓曲線公鑰密碼算法[19],橢圓曲線密碼體制的安全性基于橢圓曲線離散對(duì)數(shù)問題(ECDLP)的難解性.因此,橢圓曲線密碼系統(tǒng)的單位比特強(qiáng)度要遠(yuǎn)高于傳統(tǒng)的離散對(duì)數(shù)系統(tǒng).因?yàn)閰^(qū)塊中所有的交易都帶有簽名,所以簽名速度直接影響了系統(tǒng)響應(yīng)延時(shí)和吞吐量.經(jīng)過對(duì)橢圓曲線驗(yàn)簽算法的分析,我們提出了用GPU進(jìn)行硬件加速,實(shí)現(xiàn)快速的驗(yàn)簽運(yùn)算的方案.

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

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

故對(duì)于物理并發(fā)度為3 072的Tesla K40,最優(yōu)區(qū)塊大小為

關(guān)于橢圓曲線運(yùn)算具體理論見文獻(xiàn)[20],SM2算法的具體理論見文獻(xiàn)[19].Hyperchain以相關(guān)理論為基礎(chǔ),對(duì)現(xiàn)有的有限域運(yùn)算和橢圓曲線標(biāo)量乘法運(yùn)算進(jìn)行了優(yōu)化,實(shí)現(xiàn)了基于硬件加速的橢圓曲線加密算法:

· 優(yōu)化1:提升有限域運(yùn)算性能

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

有限域元素Fp在計(jì)算機(jī)中的表達(dá)方式,用整數(shù)表達(dá)單個(gè)域元素需要用 256位,在目前計(jì)算機(jī)體系結(jié)構(gòu)下,必須使用多個(gè)整數(shù)來表達(dá)一個(gè)域元素.根據(jù)目前多數(shù)CUDA設(shè)備的計(jì)算能力,32位整數(shù)的每位均攤運(yùn)算性能遠(yuǎn)高于64位整數(shù)[21],故本文采用8個(gè)32位整數(shù)來表達(dá)一個(gè)有限域Fp元素:

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

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

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

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

或者是另一種變體:

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

算法1. 快速有限域求模運(yùn)算.

輸入:標(biāo)量ω;

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

1. 當(dāng)ω>(232-1)·2224,執(zhí)行循環(huán):

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

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

4. 輸出結(jié)果ω′=ω

· 優(yōu)化2:以并行方式實(shí)現(xiàn)橢圓曲線標(biāo)量乘法運(yùn)算

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

算法2. Montgomery階梯算法.

輸入:標(biāo)量K,曲線C上的點(diǎn)P;

輸出:橢圓曲線標(biāo)量乘法的結(jié)果K×P.

1. 令P1=P,P2=2P

2. 令i從n-2到0循環(huán),n為K的位長(zhǎng)

3. 如果K的第i個(gè)二進(jìn)制位為1

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

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

6. 輸出結(jié)果P1

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

· 并行橢圓曲線點(diǎn)加與加倍算法

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

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

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

3 實(shí)驗(yàn)結(jié)果與分析

本節(jié)通過多個(gè)對(duì)比實(shí)驗(yàn)來驗(yàn)證優(yōu)化策略對(duì)系統(tǒng)性能提升的有效性.下文中,第 3.1節(jié)詳細(xì)介紹了本次實(shí)驗(yàn)的具體配置和指標(biāo),第3.2節(jié)～第3.4節(jié)分別是關(guān)于業(yè)務(wù)邏輯與共識(shí)分離、存儲(chǔ)優(yōu)化和數(shù)字簽名等優(yōu)化策略對(duì)性能影響的對(duì)比實(shí)驗(yàn),第3.5節(jié)～第3.9節(jié)展示和分析了節(jié)點(diǎn)數(shù)、打包時(shí)間、區(qū)塊大小、網(wǎng)絡(luò)延遲和帶寬等因素對(duì)聯(lián)盟鏈性能的影響.

3.1 實(shí)驗(yàn)設(shè)置

3.1.1 集群環(huán)境

(1) 客戶端節(jié)點(diǎn)配置(見表2);

(2) Hyperchain節(jié)點(diǎn)配置:本次實(shí)驗(yàn)將采用騰訊的云服務(wù)器,根據(jù)不同場(chǎng)景,實(shí)驗(yàn)會(huì)采用多種類型的服務(wù)器,具體配置如下.

· 配置1:4臺(tái)服務(wù)器,Hyperchain默認(rèn)記賬節(jié)點(diǎn)服務(wù)器配置.型號(hào):16核32G云服務(wù)器(標(biāo)準(zhǔn)型S2,見表3);

· 配置2:大于4臺(tái)服務(wù)器,用于多節(jié)點(diǎn)測(cè)試.型號(hào):16核16G云服務(wù)器(標(biāo)準(zhǔn)型S1,見表4);

· 配置3:用于國(guó)密GPU驗(yàn)簽測(cè)試,型號(hào):CPU 28核56G計(jì)算型(GN2).

Table 2 Test environment of the client side表2 客戶端測(cè)試環(huán)境

Table 3 Standard S2 server configuration表3 標(biāo)準(zhǔn)型S2服務(wù)器配置

Table 4 Standard S1 server configuration表4 標(biāo)準(zhǔn)型S1服務(wù)器配置

3.1.2 網(wǎng)絡(luò)拓?fù)鋱D

本次實(shí)驗(yàn)的服務(wù)器網(wǎng)絡(luò)拓?fù)鋱D如圖7所示,左邊部署了Hyperchain平臺(tái)節(jié)點(diǎn),右邊的客戶端節(jié)點(diǎn)用于發(fā)送交易請(qǐng)求,終端節(jié)點(diǎn)用于控制Hyperchain節(jié)點(diǎn)和客戶端節(jié)點(diǎn).

3.1.3 參數(shù)設(shè)置

· 記賬節(jié)點(diǎn)服務(wù)器數(shù)量:4臺(tái)(標(biāo)準(zhǔn)型S2);

· 客戶端并發(fā)度:100×4(4節(jié)點(diǎn),每個(gè)節(jié)點(diǎn)并發(fā)度為100);

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

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

· 合并驗(yàn)簽數(shù):10.

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

3.1.4 性能指標(biāo)

本實(shí)驗(yàn)擬采用的性能指標(biāo)包括吞吐量(TPS)和延遲(Latency,默認(rèn)單位為ms).

(1) 吞吐量計(jì)算方式:交易發(fā)送完畢后,遍歷測(cè)試中間三分之一時(shí)間區(qū)塊:

(2)Latency計(jì)算方式:遍歷測(cè)試中間三分之一時(shí)間的區(qū)塊,計(jì)算平均時(shí)間:

注 1:遍歷測(cè)試中間三分之一時(shí)間的區(qū)塊是為了統(tǒng)計(jì)系統(tǒng)處理能力處于相對(duì)穩(wěn)定狀態(tài)時(shí)的實(shí)驗(yàn)數(shù)據(jù),避免負(fù)載不足對(duì)實(shí)驗(yàn)結(jié)果的影響;

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

3.2 業(yè)務(wù)邏輯和共識(shí)分離架構(gòu)對(duì)比實(shí)驗(yàn)

本節(jié)將分別使用傳統(tǒng)共識(shí)架構(gòu)與業(yè)務(wù)邏輯和共識(shí)分離架構(gòu)來執(zhí)行系統(tǒng)交易.采用傳統(tǒng)共識(shí)架構(gòu)時(shí),我們將使用Hyperchain實(shí)現(xiàn)的EVM虛擬機(jī)來執(zhí)行交易.

從表5和表6可知,采用業(yè)務(wù)邏輯和共識(shí)分離架構(gòu)的Hyperchain平臺(tái)其系統(tǒng)性能明顯提升.系統(tǒng)運(yùn)行1分鐘時(shí),TPS和Latency性能效果分別提升了18.5倍和17倍;系統(tǒng)運(yùn)行5分鐘時(shí),TPS和Latency分別提升了18.7倍和 17.5倍.由此可見,采用業(yè)務(wù)邏輯和共識(shí)分離架構(gòu),節(jié)點(diǎn)只共識(shí)區(qū)塊鏈上交易的排序和交易的內(nèi)容,具體交易交由外部業(yè)務(wù)系統(tǒng)執(zhí)行,提升了系統(tǒng)性能.

Table 5 Impacts of separation architecture of business logic and consensus on system throughput表5 業(yè)務(wù)邏輯和共識(shí)分離架構(gòu)對(duì)系統(tǒng)吞吐量的影響

Table 6 Impacts of separation architecture of business logic and consensus on system latency表6 業(yè)務(wù)邏輯和共識(shí)分離架構(gòu)對(duì)系統(tǒng)延遲的影響

3.3 存儲(chǔ)優(yōu)化對(duì)比實(shí)驗(yàn)

Hyperchain采用區(qū)塊業(yè)務(wù)執(zhí)行和共識(shí)分離策略,并使用外部業(yè)務(wù)系統(tǒng)執(zhí)行交易,節(jié)點(diǎn)不再執(zhí)行交易,所以數(shù)據(jù)庫(kù)只存儲(chǔ)區(qū)塊信息,不再存儲(chǔ)交易執(zhí)行結(jié)果的相關(guān)數(shù)據(jù).本節(jié)通過對(duì)比存儲(chǔ)優(yōu)化前后系統(tǒng)的 TPS和 Latency,來驗(yàn)證存儲(chǔ)優(yōu)化對(duì)系統(tǒng)性能提升的效果.

從表7和表8可知,系統(tǒng)運(yùn)行1、5、10、15和30分鐘時(shí),系統(tǒng)的TPS和Latency較為穩(wěn)定,并無明顯波動(dòng).采用存儲(chǔ)優(yōu)化策略后,TPS和Latency的性能效果平均提升了27.3%和28.7%,系統(tǒng)性能得到了較為明顯的提升.

Table 7 Impacts of storage optimization on system throughput表7 存儲(chǔ)優(yōu)化對(duì)系統(tǒng)吞吐量的影響

Table 8 Impacts of storage optimization on system latency表8 存儲(chǔ)優(yōu)化對(duì)系統(tǒng)延遲的影響

3.4 數(shù)字簽名驗(yàn)證優(yōu)化對(duì)比實(shí)驗(yàn)

3.4.1 多訂單打包驗(yàn)簽對(duì)系統(tǒng)性能的影響

本節(jié)我們將改變每個(gè)交易包含的訂單(order)數(shù)量,來驗(yàn)證統(tǒng)一驗(yàn)簽功能對(duì)系統(tǒng)性能提升的有效性.

每筆交易只包含一個(gè)訂單(1 order)時(shí),系統(tǒng)的瓶頸在于驗(yàn)簽.由表 9可知:每筆交易分別包含 10 order、20 order、30 order進(jìn)行統(tǒng)一驗(yàn)簽時(shí),系統(tǒng)交易的吞吐量逐漸下降.一方面是因?yàn)榫W(wǎng)絡(luò)帶寬的壓力增加,轉(zhuǎn)發(fā)時(shí)間變長(zhǎng);另一方面是因?yàn)楣?jié)點(diǎn)處理 order數(shù)增加,反序列化存在內(nèi)存中更加緩慢.但系統(tǒng)訂單的吞吐量在增加,因?yàn)轵?yàn)簽是系統(tǒng)的瓶頸,打包驗(yàn)簽將低了驗(yàn)簽的次數(shù).

Table 9 Impacts of multi-order packaging verification on system throughput and latency表9 不同訂單數(shù)量的打包驗(yàn)簽對(duì)性能的影響

3.4.2 基于GPU的國(guó)密簽名對(duì)性能的影響

本節(jié)對(duì)Hyperchain平臺(tái)實(shí)現(xiàn)的CUDA并行版本的SM2算法與GmSSL庫(kù)進(jìn)行對(duì)比.GmSSL是一套基于OpenSSL使用純CPU實(shí)現(xiàn)的SM系列算法庫(kù),是目前工業(yè)界常用的SM2算法實(shí)現(xiàn).

測(cè)試環(huán)境:服務(wù)器類型為配置3(GN2),在本次實(shí)驗(yàn)中,平臺(tái)的記賬節(jié)點(diǎn)是4.

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

Table 10 Impacts of GPU Optimization on system throughput表10 GPU優(yōu)化對(duì)系統(tǒng)吞吐量的影響

Table 11 Impacts of GPU optimization on system latency表11 GPU優(yōu)化對(duì)系統(tǒng)延遲的影響

3.5 節(jié)點(diǎn)數(shù)對(duì)系統(tǒng)性能的影響

當(dāng)節(jié)點(diǎn)數(shù)量增加,聯(lián)盟鏈方案將會(huì)導(dǎo)致網(wǎng)絡(luò)中交易結(jié)算時(shí)間的延長(zhǎng).本節(jié)將測(cè)試不同節(jié)點(diǎn)數(shù)下的系統(tǒng)性能.

在服務(wù)器配置2的情況下,由圖8和圖9可知:隨著節(jié)點(diǎn)數(shù)的增加,系統(tǒng)性能略有提升.這是因?yàn)楣?jié)點(diǎn)數(shù)在一定范圍內(nèi)增加時(shí)(系統(tǒng)帶寬還未成為瓶頸的范圍內(nèi)),發(fā)起共識(shí)之前的驗(yàn)簽壓力可以分?jǐn)偨o各個(gè)節(jié)點(diǎn),每個(gè)節(jié)點(diǎn)可以擁有更多的資源用于共識(shí).在 8節(jié)點(diǎn)后,系統(tǒng)性能略有下降.這是由于共識(shí)節(jié)點(diǎn)之間需要相互通信(發(fā)送request,pre-prepare等消息),節(jié)點(diǎn)數(shù)過多后,系統(tǒng)帶寬會(huì)逐漸成為性能瓶頸.

由于課題經(jīng)費(fèi)有限,我們沒有測(cè)試更多節(jié)點(diǎn)的場(chǎng)景.總的來說,從4個(gè)節(jié)點(diǎn)～10個(gè)節(jié)點(diǎn),系統(tǒng)吞吐量變化不大.這是由于此時(shí)系統(tǒng)帶寬還沒碰到瓶頸.

3.6 Batch time對(duì)系統(tǒng)性能的影響

在服務(wù)器配置1的條件下,由表12可知,區(qū)塊打包時(shí)間對(duì)系統(tǒng)性能沒有顯著影響.

Table 12 Impacts of batch time on system throughput and latency表12 區(qū)塊打包時(shí)間對(duì)系統(tǒng)性能的影響

3.7 Batch size對(duì)系統(tǒng)性能的影響

在服務(wù)器配置1(4節(jié)點(diǎn))的條件下,由圖10可知,Batch size小于200后TPS較顯著下降.由圖11可知,Batch size越大延遲越高.這是因?yàn)閰^(qū)塊需要在共識(shí)節(jié)點(diǎn)間進(jìn)行流轉(zhuǎn),受網(wǎng)絡(luò)帶寬的限制,造成Batch size越大延遲也越高.選用200～500筆交易作為區(qū)塊大小為佳.

3.8 網(wǎng)絡(luò)延遲對(duì)系統(tǒng)性能的影響

驗(yàn)證節(jié)點(diǎn)之間的距離也會(huì)對(duì)性能產(chǎn)生影響,物理距離太近使得吞吐量會(huì)變得很高,所以我們?nèi)藶榈赜肔INUX的工具軟件增加了網(wǎng)卡延遲.

由表13可知,隨著網(wǎng)絡(luò)延時(shí)的提升,系統(tǒng)TPS略有下降,Latency急劇提升.在網(wǎng)絡(luò)延時(shí)大于等于500ms以后,節(jié)點(diǎn)間的共識(shí)會(huì)超時(shí),使交易無法正常執(zhí)行.

Table 13 Network delays impacts on system throughput and latency表13 網(wǎng)絡(luò)延遲對(duì)系統(tǒng)性能的影響

3.9 帶寬對(duì)系統(tǒng)性能的影響

在服務(wù)器配置1的條件下,由圖12可知,帶寬對(duì)TPS有顯著影響.在4節(jié)點(diǎn)情況下,10MB帶寬僅有642TPS;500MB帶寬時(shí),帶寬瓶頸不再顯著.由圖13可知:隨著帶寬的增加,系統(tǒng)延遲顯著減小.目前,網(wǎng)絡(luò)帶寬是限制聯(lián)盟鏈吞吐量的最主要因素之一.

4 總結(jié)與展望

我們已經(jīng)研究了聯(lián)盟區(qū)塊鏈技術(shù)應(yīng)用于證券撮合系統(tǒng)的技術(shù)難點(diǎn),并提出了高性能撮合系統(tǒng)解決方案.課題組對(duì)接了 Java撮合系統(tǒng)并進(jìn)行了性能測(cè)試、可靠性測(cè)試和部分調(diào)優(yōu)等工作.針對(duì)證券交易的訂單,整個(gè)系統(tǒng)的處理速度可以達(dá)到20萬(wàn)/s.在不同節(jié)點(diǎn)數(shù)量、區(qū)塊大小和網(wǎng)絡(luò)延遲的條件下,也能保證正確性和較高的性能.

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