毛寧，李霞，丁明月，李秦偉

（貴州大學(xué)計算機(jī)科學(xué)與技術(shù)學(xué)院，貴州550025）

0 引言

區(qū)塊鏈技術(shù)也即分布式賬本技術(shù)，起源于2009年，現(xiàn)在正逐漸發(fā)展成為一個去中心化、分布式、去信任的技術(shù)方案[1]。利用區(qū)塊鏈的共識算法、密碼學(xué)、智能合約等技術(shù)，以及透明化、可追溯、不可篡改等特性[2]，將其應(yīng)用于電商平臺，能夠解決商品難辨真假、數(shù)據(jù)透明與隱私保護(hù)難以平衡、監(jiān)管與信息追溯困難、電商平臺、買家用戶、賣家網(wǎng)店之間不能完全信任等諸多實(shí)際問題。

就電商平臺而言，因?yàn)槠鋵?shí)際實(shí)施情況和特點(diǎn)，使得區(qū)塊鏈技術(shù)的使用受到限制，在實(shí)際操作中，商家節(jié)點(diǎn)總是會出現(xiàn)很多情況，導(dǎo)致完全照搬類似比特幣等區(qū)塊鏈技術(shù)是行不通的。所以需要一種折中的方案，既能使用區(qū)塊鏈技術(shù)也能提高交易效率并促進(jìn)電商平臺模式創(chuàng)新[3]。

本文以聯(lián)盟鏈作為應(yīng)用場景，應(yīng)用于節(jié)點(diǎn)數(shù)量較少的小型電商平臺，針對鏈狀態(tài)不一致的問題，設(shè)計一種隊列同步方案（Queue Synchronization，QS）使得塊數(shù)據(jù)落后的節(jié)點(diǎn)能在不影響共識的情況下恢復(fù)丟失的信息。

1 電商平臺下區(qū)塊鏈狀態(tài)不一致問題

在以聯(lián)盟鏈為應(yīng)用場景，應(yīng)用在節(jié)點(diǎn)數(shù)目較少的小型電商系統(tǒng)中，鏈狀態(tài)不一致問題更為突出。一是因?yàn)橄到y(tǒng)中的節(jié)點(diǎn)數(shù)量較少，對系統(tǒng)的影響大，二是因?yàn)橄到y(tǒng)中節(jié)點(diǎn)狀態(tài)變化很快。這些實(shí)際情況就會讓各節(jié)點(diǎn)區(qū)塊鏈狀態(tài)的一致性變得非常脆弱，很大可能會導(dǎo)致某些節(jié)點(diǎn)區(qū)塊鏈的塊數(shù)據(jù)落后于其他節(jié)點(diǎn)的塊數(shù)據(jù)，從而破壞系統(tǒng)的安全性與可用性。如何使塊數(shù)據(jù)落后的節(jié)點(diǎn)與正常節(jié)點(diǎn)鏈狀態(tài)達(dá)到一致，正是需要研究的一個問題。

將區(qū)塊鏈技術(shù)引入到這樣一種小型平臺下，因?yàn)閷?shí)際應(yīng)用場景的限制，而存在著一些與理想情況不相適應(yīng)的問題。智能合約的完全去中心化也無法完全避免技術(shù)上的操作風(fēng)險[4]。在該小型電商平臺中，分布式環(huán)境并不太穩(wěn)定，這樣可能會使得狀態(tài)滯后的節(jié)點(diǎn)與某些一直在線節(jié)點(diǎn)的鏈狀態(tài)不一致。不僅如此，電商系統(tǒng)中，新加入的商家節(jié)點(diǎn)數(shù)量更新很快，新節(jié)點(diǎn)需要同步歷史區(qū)塊。綜上，以下兩種情況最有可能導(dǎo)致鏈狀態(tài)不一致問題：

（1）節(jié)點(diǎn)離線后恢復(fù)，離線原因可能是故障或者關(guān)機(jī)，在離線期間因未參與共識建塊，從而導(dǎo)致該節(jié)點(diǎn)區(qū)塊數(shù)據(jù)落后，出現(xiàn)鏈狀態(tài)不一致。

（2）新節(jié)點(diǎn)的加入，新節(jié)點(diǎn)加入后是沒有歷史區(qū)塊數(shù)據(jù)的，這樣新節(jié)點(diǎn)鏈狀態(tài)肯定和其余節(jié)點(diǎn)的鏈狀態(tài)不一致。

以上兩種情況都是電商平臺中經(jīng)常出現(xiàn)的，恰恰就是這些“正?！鼻闆r，會導(dǎo)致節(jié)點(diǎn)出現(xiàn)鏈狀態(tài)不一致問題。

2 電商平臺下的區(qū)塊鏈狀態(tài)問題分析

由上面所描述的實(shí)際情況，可以看出在這樣一個電商平臺系統(tǒng)背景下，鏈狀態(tài)不一致是一個很容易出現(xiàn)的情況，并且這種情況很難規(guī)避。所以重點(diǎn)就落在了如何高效的解決這個問題。針對區(qū)塊同步問題，以太坊給出了三種模式的解決方案：

（1）fast：直接通過網(wǎng)絡(luò)同步狀態(tài)數(shù)據(jù)，在同步到當(dāng)前塊之前不進(jìn)行任何事務(wù)的處理，只對區(qū)塊里的數(shù)據(jù)進(jìn)行校驗(yàn)。節(jié)省了時間，但該模式可能對歷史數(shù)據(jù)有部分丟失，不過不影響今后使用。

（2）full：全節(jié)點(diǎn)同步，需要下載所有的區(qū)塊數(shù)據(jù)信息，該模式最安全但相當(dāng)費(fèi)時，能得到所有的歷史數(shù)據(jù)。

（3）light：只同步區(qū)塊頭數(shù)據(jù)，可以完成基本的命令操作，速度快，適用于較低配置的設(shè)備中。

因?yàn)楸疚乃枋龅膽?yīng)用場景與以太坊或比特幣等應(yīng)用場景有很大的區(qū)別，所以它們的區(qū)塊同步方案的實(shí)施會收到很大的限制。本文所設(shè)計的方案應(yīng)用于節(jié)點(diǎn)數(shù)目較少的小型電商平臺中，旨在不影響系統(tǒng)性能與共識的基礎(chǔ)上解決鏈狀態(tài)不一致問題。

3 隊列同步方案

為了解決上述電商平臺下的節(jié)點(diǎn)鏈狀態(tài)不一致問題，設(shè)計出了一種隊列同步方案，在該方案中，每個節(jié)點(diǎn)都有一個缺失隊列（Defective Queue）和隊列掃描器（Queue Scanner），缺失隊列存儲節(jié)點(diǎn)所缺失的區(qū)塊信息，隊列掃描器定時掃描缺失隊列中是否存有數(shù)據(jù)。方案設(shè)計兩個部分：狀態(tài)檢測模塊和狀態(tài)同步模塊。

3.1 QS實(shí)現(xiàn)前提

QS能實(shí)現(xiàn)的前提是系統(tǒng)滿足拜占庭算法[5]。在聯(lián)盟鏈和私有鏈中，大多使用了經(jīng)典的實(shí)用拜占庭容錯算法（PBFT）。在惡意結(jié)點(diǎn)數(shù)目不超過限制時，該算法的正確性可被嚴(yán)格證明[6]。假設(shè)系統(tǒng)中惡意節(jié)點(diǎn)、離線節(jié)點(diǎn)、鏈狀態(tài)待同步節(jié)點(diǎn)的總數(shù)為f，那么系統(tǒng)中節(jié)點(diǎn)總數(shù)至少應(yīng)該為3f+1?；蛘邠Q句話說，當(dāng)系統(tǒng)中非正常節(jié)點(diǎn)數(shù)量為f時，只要節(jié)點(diǎn)總數(shù)超過3f，QS就能實(shí)現(xiàn)對數(shù)據(jù)丟失節(jié)點(diǎn)鏈狀態(tài)的同步。

3.2 隊列同步

將本文所用到的符號進(jìn)行說明：

（1）m：節(jié)點(diǎn)廣播的交易哈希值

（2）t：時間戳

（3）σi：節(jié)點(diǎn)i用MAC技術(shù)對信息進(jìn)行簽名

（4）flag：標(biāo)記，即區(qū)塊在區(qū)塊鏈中的位置

（5）flagi：節(jié)點(diǎn)i中最新區(qū)塊的標(biāo)記

（6）F：標(biāo)準(zhǔn)標(biāo)記，系統(tǒng)中正常節(jié)點(diǎn)的最新區(qū)塊的標(biāo)記

（7）DQ：缺失隊列

（8）Scanner：隊列掃描器

（9）DF：缺失隊列中位于隊首位置的區(qū)塊標(biāo)記

（10）Ni：節(jié)點(diǎn)i的節(jié)點(diǎn)編號

（11）block：區(qū)塊

（12）data：交易數(shù)據(jù)

●狀態(tài)監(jiān)測模塊：

在系統(tǒng)中，因?yàn)槊總€節(jié)點(diǎn)都會接收交易并全網(wǎng)廣播交易哈希值，所以當(dāng)每個節(jié)點(diǎn)廣播交易的哈希值的時候就是觸發(fā)狀態(tài)檢測模塊的時候。假設(shè)節(jié)點(diǎn)NodeA準(zhǔn)備廣播交易哈希值，則它廣播的消息如{m,{STATUS_CHECK,Ni,t}σi}，其他節(jié)點(diǎn)收到消息后回復(fù)如下消息 {STATUS_REPLY,Nj,flagj,t}σj。因?yàn)橄到y(tǒng)滿足拜占庭算法，所以NodeA會收到超過2/3個節(jié)點(diǎn)發(fā)來的flagj是相等的，并且是最大值，將這個值記為標(biāo)準(zhǔn)標(biāo)記F。之后節(jié)點(diǎn)對比自己鏈中最新區(qū)塊的標(biāo)記和F的大小，如果小于F，則該節(jié)點(diǎn)需要進(jìn)行鏈狀態(tài)同步，就將自己所缺失區(qū)塊的標(biāo)記按照順序存入缺失隊列，并且將最新區(qū)塊的標(biāo)記強(qiáng)制更新為F，使得該節(jié)點(diǎn)能夠和正常節(jié)點(diǎn)一樣，參與標(biāo)記F之后的區(qū)塊的共識建塊。假設(shè)NodeA最新區(qū)塊的標(biāo)記為H，H＜F，則需要將H+1,H+2,…,F等標(biāo)記按照順序存入缺失隊列隊尾，并將H的值更新為F。如果H=F則不需要將標(biāo)記存入隊列中，到此，狀態(tài)檢測模塊結(jié)束。

圖1 缺失隊列功能示意圖

該模塊的作用是檢測節(jié)點(diǎn)是否需要進(jìn)行鏈狀態(tài)的同步，如果需要就將節(jié)點(diǎn)所缺失區(qū)塊的標(biāo)記存入缺失隊列，為狀態(tài)同步模塊做準(zhǔn)備。并且將節(jié)點(diǎn)最新區(qū)塊的標(biāo)記更新后，使得該節(jié)點(diǎn)能夠繼續(xù)參與后續(xù)共識，避免了節(jié)點(diǎn)在同步歷史區(qū)塊的同時，新區(qū)塊不能及時上鏈。模塊執(zhí)行過程中系統(tǒng)的運(yùn)行與共識不受到影響。算法過程如下，其中Message表示節(jié)點(diǎn)廣播的交易哈希值時廣播的消息。

Begin

1：if某一節(jié)點(diǎn)廣播Messagethen

2：if Message中含有STATUS_CHECK請求then

3： F←Max(flaga,flagb,flagc...)

4： if H ＜Fthen

5： for temp←H+1 to F

6： DQ.push(temp)

7： H←F

End

圖2 狀態(tài)檢測模塊流程圖

●狀態(tài)同步模塊：

隊列掃描器按照事先設(shè)定的時間間隔定時對缺失隊列進(jìn)行掃描。如果發(fā)現(xiàn)缺失隊列不為空，就將在隊首位置的標(biāo)記（DF）出隊，然后將DF封裝成一個索要區(qū)塊的請求消息{BLOCK_SYN_REQUEST,Ni,DF,t}σi，然后將該消息進(jìn)行廣播，其余節(jié)點(diǎn)收到請求消息后，就在自己的鏈中查找標(biāo)記為DF的區(qū)塊，如果找到了，就向編號為Ni的節(jié)點(diǎn)回復(fù)如下消息{BLOCK_SYN_REPLY,Nj,DF,block,data,t}σj。節(jié)點(diǎn)統(tǒng)計收到的塊（block）和交易數(shù)據(jù)（data）。如果發(fā)現(xiàn)超過2/3個節(jié)點(diǎn)發(fā)來的消息中塊和交易數(shù)據(jù)是一致的，就可以將該區(qū)塊補(bǔ)充上鏈。如果小于2/3，則再將該區(qū)塊的標(biāo)記重新存入缺失隊列的隊尾，等待下一輪處理。因?yàn)槠渌?jié)點(diǎn)回復(fù)的消息中有對應(yīng)區(qū)塊的標(biāo)記，所以節(jié)點(diǎn)在進(jìn)行消息匯總統(tǒng)計時，不會引起混淆。一旦隊列掃描器掃描到缺失隊列中有數(shù)據(jù)時，就會觸發(fā)狀態(tài)同步模塊完成對丟失區(qū)塊的補(bǔ)充。

整個QS在執(zhí)行的過程中，是完全沒有影響到系統(tǒng)的共識過程的。通過狀態(tài)檢測中對最新標(biāo)記的更新使得系統(tǒng)中的所有節(jié)點(diǎn)均在參與共識，使得丟失區(qū)塊的節(jié)點(diǎn)能夠?qū)罄m(xù)區(qū)塊進(jìn)行共識建塊，同時狀態(tài)同步模塊也在對丟失區(qū)塊進(jìn)行補(bǔ)充。整體達(dá)到了系統(tǒng)的共識與鏈狀態(tài)同步互不干擾的目的，在保證了系統(tǒng)性能與可用性的基礎(chǔ)上解決了鏈狀態(tài)不一致的問題。算法過程如下：

鏈狀態(tài)待同步節(jié)點(diǎn)，Scanner定時掃描DQ，封裝并發(fā)送區(qū)塊索取請求消息。

Begin：

1：Scanner掃描 DQ

2：if DQ不為空then

3： DF←DQ.pop()

楊嬈：在北方，冬天說降溫就降溫，哪怕昨天還是晴朗天，也不影響第二天大風(fēng)呼嘯，氣溫驟降。在整個冬天，我就反反復(fù)復(fù)地感冒，沒幾天舒服的時候。懷孕感冒了，不敢隨便亂吃藥，只能硬挺著。我也很奇怪，為什么冬天孕媽媽這么容易感冒呢？

4： 封裝并發(fā)送{BLOCK_SYN_REQUEST,Ni,DF,t}σi

5： 統(tǒng)計收到的{BLOCK_SYN_REPLY,Nj,DF,block,data,t}σj中的block與data

6： if超過2/3數(shù)據(jù)相同then

7： 存儲block與data

8：else

9： DQ.push(DF)

10：goto1

12：goto 1

End

其余節(jié)點(diǎn)，接收區(qū)塊索取請求消息，若查詢到相同區(qū)塊則進(jìn)行消息回復(fù)。

Begin

1：if收到 {BLOCK_SYN_REQUEST,Ni,DF,t}σithen

2：if查詢到相同的區(qū)塊then

3： 回復(fù){BLOCK_SYN_REPLY,Nj,DF,block,data,t}σjEnd

圖3 狀態(tài)同步模塊流程圖

4 結(jié)語

在以聯(lián)盟鏈為應(yīng)用場景，應(yīng)用在節(jié)點(diǎn)數(shù)目較少的小型電商系統(tǒng)中，傳統(tǒng)的區(qū)塊鏈技術(shù)在這樣的環(huán)境下會受到很多限制。首先在小型電商平臺中，做到完全去中心化是不太實(shí)際的，其次，商家節(jié)點(diǎn)狀態(tài)變化快、新商家節(jié)點(diǎn)加入頻繁。這些原因都使得電商平臺系統(tǒng)中的節(jié)點(diǎn)鏈狀態(tài)極大可能出現(xiàn)不一致，導(dǎo)致某些節(jié)點(diǎn)鏈中塊數(shù)據(jù)丟失。本文針對這一問題提出隊列同步方案，通過狀態(tài)檢測和狀態(tài)同步兩個模塊完成鏈狀態(tài)的同步，并且整個過程不會影響系統(tǒng)的共識建塊過程，是在保證了系統(tǒng)性能與可用性的前提下完成鏈狀態(tài)同步的方案。