Corda共識機制的深入分析
點選回顧
3. 共識機制設計方案
Corda系統應該針對發生notary變更的物件(STXO)達成共識,這是本文第二部分通過理論推導得出的結論,但並沒有給出具體的共識方案。在這裡,我們首先從實踐的角度把這個共識機制的合理性再論述一次,也就自然而然地推匯出共識機制的具體實現模式了。
為什麼無法針對UTXO達成共識
我們首先來看基於UTXO的共識模式(其實這個名字不精確,嚴格意義上說應該叫交易階段共識,後面我們會詳細討論到),也就是典型的區塊鏈系統的共識模式:當你要使用或花掉一個UTXO的時候,各個節點要確認這個UTXO沒有被花過,因此要查詢UTXO資料庫,找到這個物件,才能確認交易。驗證節點都同意交易成立,交易(或者交易所屬的區塊)就被記錄在鏈上,成為了“事實”。
很顯然,UTXO共識模式對基於notary的、非廣播式的系統是不適用的:以Corda為例,一個狀態如果沒有在若干notary之間發生轉移,那麼其當前notary就可以確認他是否以前被使用過,不需要其他notary的參與。
另一方面,由於系統的交易是不廣播的,系統中的其他notary對這個物件的存在一無所知,也就是文章第二部分提到過的的:對系統中其他notary而言,這個物件既不是UTXO,也不是STXO,所以其他notary也無法參與這個交易過程。
反過來,對於發生過notary變更的物件,基於UTXO的共識模式也有問題:要實現基於UTXO的交易合法性檢查,意味著要讓所有notary知道變更之後的物件在交易發生時仍然是一個UTXO,也就是說讓每個notary都把變更後的UTXO記錄在案,用於交易發生時的判斷依據。
簡單來說,這樣做確實是可以的,對於防止這個新的UTXO被雙花,是有效的,讀者可以自行驗證。然而,由於廣播的是notary變更產生的新UTXO,而那個經過notary變更已經失效的STXO的資訊卻不被其他notary所知,這樣就無法避免文章第二部分所說的,由於各種技術的或者蓄意欺詐的原因,而使得這個物件再次通過變更notary的方式,在其他notary那裡生成新的UTXO,從而實現雙花——關鍵點在於,剛剛廣播的那個UTXO是上一次notary變更生成的物件,而雙花攻擊者通過二次notary變更生成的UTXO和上次變更生成的UTXO確實不是同一個物件,所以任何節點都無法通過UTXO的記錄判斷這個雙花。
簡單說,無論從有效性還是必要性的角度,針對UTXO達成共識在Corda模式的系統中都是沒有意義的。
基於STXO的共識
針對STXO達成共識,也就是說系統中所有的notary都知道某個物件是STXO,後續交易確認時可以作為依據。很顯然,對於沒有發生過notary變更的物件,他的所有歷史資訊都在某一個notary那裡記錄,讓系統中的其他notary知道他什麼時候變成STXO仍然沒意義,因此我們可以只針對發生notary變更的情況來討論共識的流程:
廣播,當一個物件發生notary變更的時候,該物件的當前notary應該把這件事廣播通知系統中的所有其他notary,告訴他們“某個物件發生了notary變更,因此他已經變成了STXO,另外會新生成一個UTXO”。其他notary收到這個廣播,應該做一系列的處理:
查詢,按照交易規則,查詢自己的STXO庫,看看這個物件是不是在自己這裡以前發生過交易,已經是STXO了。注意,我們前面提到過的,在Corda這樣的系統中,一個notary對自身STXO資料庫的查詢結果,只能反映一個物件在當前notary見證過的交易範圍內是不是STXO,而在整個系統中是不是STXO,就要靠下面一個動作——“共識”——來完成了。
共識,每個notary能夠返回的結果無非三種可能性:查到/沒查到/沒反饋,看到這裡,大家應該會心一笑了,這就是共識機制派上用場的地方:不是所有節點都一定會反饋同一個結果(包括有些節點因為不線上而沒有反饋),因此必須要有合適的機制來解決整個系統對“這個物件是不是STXO”最終達成一致的問題,這就是典型的分散式共識場景。
實現共識的技術手段,Corda並沒有具體規定,根據官方的說法,Corda並不拒絕採用任何有效的共識機制,聽起來有點類似Fabric支援可插拔的共識模型,總之我們應該認為共識可以達成。具體的實現技術,我們將在下一節進行討論。
確認,如果共識的結論是這個物件目前不是STXO,因此可以交易,則系統中的各個notary就可以接受這個交易,並且將該物件記錄到自己的STXO資料庫中,使其成為已經交易的狀態,從而杜絕這個物件未來可能的雙花。而後,釋出這個變更訊息的notary,也應當根據這個共識的結果,最終確認這個變更交易,產生新的UTXO。這樣一來,notary變更交易就正式完成了。反過來,如果共識的結論是“這個物件以前就是STXO”,那麼各個節點就通過這個共識拒絕了這個交易,他們自身不需要做額外的動作,而釋出變更訊息的節點,也不應該為這個交易提供確認。
上述共識機制可以用下圖表示:
若干要點
至此,我們就講完了針對notary變更的共識機制的基本流程,下面通過幾個問題來討論/總結一下這個共識機制有什麼特點:
總體效率
很明顯,本文介紹的共識機制是“notary變更共識”,也就是說凡是不涉及notary變更的交易,仍然是由交易雙方通過notary直接確認的,不需要在多個notary之間達成共識。只有這樣,考慮到notary變更的概率,Corda系統的效能才能大幅度超越每筆交易都需要共識的區塊鏈模式,這也是“多中心化”存在的意義。
共識保障
既然是共識機制,必然要滿足達成共識所需要的各種條件,這一點與其他系統的共識機制是一樣的,例如:如果採用PBFT方式,則必須有2f+1個以上的節點是可信的並且線上;如果是採用類似比特幣的機制,則要考慮軟分叉之後的恢復等。
這裡筆者只想強調一點,就是在類似Corda這種系統中,必須使用類似PBFT的“強”共識機制,不能允許“分叉”情況的出現。這是因為系統中沒有“區塊鏈”這樣的全域性資料結構,一旦允許分叉,很難設計有效的機制進行恢復,或者說恢復機制一定會導致系統引入非常複雜的處理流程。當然,這個保障在聯盟鏈的系統中應該是比較容易實現的,現有聯盟鏈也基本上都是採用強共識機制。
惡意notary
拋開細節不說,Corda引入notary這種新角色,在共識機制中還有沒有其他影響呢?
我想最基本的就是要看看惡意notary與區塊鏈系統中一般的惡意節點之間有什麼差異,例如:notary變更交易根本不發出廣播要求達成共識,或者共識過程拒絕了此次變更而notary仍然去完成變更交易。
這種情況是普通區塊鏈系統不會出現的,也就是惡意notary的特殊之處。解決的辦法也很簡單,只需要在規定notary變更交易,必須有“目標”notary的參與即可。具體參與方式可以有多種,最簡單的就是這種交易應該讓目標notary也參與驗證,這樣他就能獲得這個交易的全部資訊,從而知道輸入(STXO)的資訊和輸出(UTXO)的全部資訊。
未來,當新的UTXO到自己這裡來交易時,可以查詢STXO在全網的狀態,看看是否達成了共識,從而實現對惡意notary的防範,並且仍然保持了只有notary變更交易才需要共識的模式。
除了上述要點之外,筆者提個“小問題”:共識過程中,如果有一個notary發現需要共識的物件在他這裡被使用過,從而拒絕這個共識,而其他notary由於認定該物件未被使用過而同意,則最後這個物件會被認定為未使用過,根據共識的定義,這個物件“未被使用過”的共識仍然能夠達成。可是如果這個物件“真的”在這個反對的notary那裡使用過怎麼辦呢?系統不是出現錯誤了嗎?在notary這種模式下,是不是該有個什麼一票否決機制?這些問題,就留給讀者去思考吧。
小結
本節給出了基於notary模式的系統的一種特殊的共識機制——notary變更交易的共識,建立在這樣一個前提下:notary模式的系統中普通型別的交易既不需要,也不可能通過共識來進行確認。
這種共識機制本身是標準的,也就是說原則可以採用任何一種一致的共識演算法,但是從實踐的角度看,由於沒有區塊鏈模型的資料結構,必須採用類似PBFT的強共識機制才有意義,否則必然要為解決分叉問題涉及大量額外的處理流程。
此外,為了進一步防止惡意notary的攻擊,需要在notary變更流程中設計更多的環節以確保防止雙花攻擊,但是這與共識機制的處理流程是無關的。
最後,筆者要進行一個“劇透”——本系列文章還有第四部分,在第四部分我們要對共識機制的具體技術實現給出描述,並且還要給出一個令人“驚訝”的事實和相應的解釋,敬請期待。
作者簡介:王瑋
“中關村20週年突出貢獻獎”獲得者
北京微志科技有限公司創始人
渡鴉區塊鏈專欄作者
在金融IT領域從業近20年,主持過世界上最大的基於開放平臺和分散式技術的銀行賬務系統的設計與開發,曾任國家“核高基”國產化中介軟體應用示範專案副組長等。目前從事區塊鏈技術在金融等領域應用的研究、開發和推廣工作。同時還是中國人民大學資訊學院工程碩士企業導師、華夏基石e洞察管理雜誌專欄作家。
本文為渡鴉原創專家專欄,轉載請聯絡後臺授權。
加入渡鴉(全職∕實習生):cx@jqblockchain.com
相關文章
- 以太坊的POS共識機制
- NEO共識機制圖解圖解
- NEO共識機制白皮書
- kafka和raft共識機制KafkaRaft
- 區塊鏈共識機制區塊鏈
- 區塊鏈共識機制技術一--POW(工作量證明)共識機制區塊鏈
- Fabric基於Kafka的共識機制剖析Kafka
- 區塊鏈共識機制的演進區塊鏈
- 通俗講解:PoW共識機制與以太坊的關係、Ghost協議 及 Casper PoS共識機制的變種協議
- 共識機制proof of efficiency(PoE)是什麼?
- SPI機制深入分析
- 區塊鏈中的共識機制分析與對比區塊鏈
- ATL Thunk機制深入分析
- 016 | 漫談區塊鏈共識機制區塊鏈
- 共識機制-區塊鏈核心技術之一區塊鏈
- 簡介 以太坊 2.0 核心 之 共識機制的改變
- Native Rollup 的去中心化共識機制是什麼?中心化
- 深入分析 Python 的垃圾回收機制Python
- Go 包管理機制深入分析Go
- 【許曉笛】詳解 EOS 的新共識機制 BFT-DPoS
- 迅雷鏈基於智慧硬體的DPoA共識機制介紹
- 深入分析Redis的主從複製機制Redis
- NEO共識協議:授權拜占庭容錯機制如何工作協議
- 跨共識訊息格式XCM有幾種傳遞機制?
- 讀懂區塊鏈共識機制 :PoW、PoS、PAXOS、RAFT、PBFT區塊鏈Raft
- 讓POW的共識機制不再成為公鏈系統吞吐率的瓶頸
- 對Koa-middleware實現機制的深入分析
- 瞭解公鏈,先從共識機制和擴容方案開始
- 國際區塊鏈大會:大咖共話共識機制技術與應用創新區塊鏈
- 深入分析Java執行緒中斷機制Java執行緒
- 區塊鏈2.0-共識機制如何打破網際網路資訊大爆炸區塊鏈
- 從分散式一致性到共識機制(二)Raft演算法分散式Raft演算法
- 區塊鏈型別和共識機制 | 公共、私有和聯盟鏈開發搭建區塊鏈型別
- Flutter 命令本質之 Flutter tools 機制原始碼深入分析Flutter原始碼
- 近幾天對區塊鏈中幾種常見的共識機制(PBFT,Raft,PoW,PoS,DPoS,Ripple)區塊鏈Raft
- Redis哨兵機制全面深入分析與講解[實戰演示篇]Redis
- 分散式賬本 Corda分散式
- 全面認識Flex事件機制Flex事件