解讀Conflux的共識機制:如何解決公鏈可擴展性問題

2018年12月5日,區塊鏈協議項目Conflux獲得了包括紅杉資本在內的多家知名投資機構的3500萬美元(約人民幣2.4億元)的融資。Conflux作爲一個可擴展的、分散的區塊鏈系統,採用了工作量證明(PoW)與有向無環圖(DAG)的機制,在去中心化的前提下,既保障了區塊鏈的安全,又提升了區塊鏈的可擴展性,在某些層面上,突破了“不可能三角”。

圖靈獎獲得者姚期智院士參與了Conflux項目,其有關區塊鏈的論文也被更多人所關注:

Scaling Nakamoto Consensus to Thousands of Transactions per Second (擴展中本聰共識至上千交易每秒

我們今天將解讀姚期智院士參與的這篇論文, 讓大家進一步瞭解Conflux所提出的共識機制。

1、打破不可能三角

事實證明,中本聰共識對記賬權和交易順序做出了嚴格的規定,使得比特幣在運行和發展過程中面臨如下瓶頸:

  • 只有一個參與者可獲得算力競爭的勝利並給主鏈提供有效的區塊,其他同時期產生的區塊會被視做分叉而遺棄,這種記賬權機制導致的算力競爭,極大地浪費了網絡和算力資源;
  • 最長鏈規則使得比特幣網絡工作效率低下(比特幣每10分鐘纔出一個塊,每秒僅處理7筆交易。用戶需等待數小時才能來確認最長鏈,然後完成交易以確保自己的交易安全不被逆轉)。

中本聰共識導致的生產效率低下和交易時滯過長的問題,引發了糟糕的用戶體驗、飆漲的轉賬費用和擁堵的網絡,不利於區塊鏈技術長期的推廣和發展。雖然已有很多團隊試圖解決中本聰共識的瓶頸,但他們的方案仍存在不完美之處:

  • 通過選舉代理節點,降低無效競爭產生的資源浪費,雖然可以提升區塊鏈的效率,但會使得鏈變得中心化。
  • 增加區塊大小或提升出塊速度,只是表面上虛增了區塊鏈的吞吐量,實際上會令同一時段產生更多的併發區塊,增加區塊鏈分叉的風險。

這種困境,被早期區塊鏈開發人員稱作爲“不可能三角”,即:公鏈的三個屬性:去中心化(Decentralization)、安全(Security)和可擴展性(Scalability),在技術實現上有二缺一,不能同時實現。

然而,Conflux團隊在論文中設計了一種對比特幣的擴展方案,它結合了工作量證明(PoW)與有向無環圖(DAG)的優勢,在去中心化的前提下,既保障了區塊鏈的安全,又提升了區塊鏈的可擴展性,在某些層面上,突破了“不可能三角”。

2、Conflux的實現方案

與中本聰共識在打包區塊時對交易順序進行嚴格規範不同,Conflux樂觀地假設,在並存的區塊中,交易(Tx,Transactions)是不衝突的,只要所有節點對一致的交易順序達成共識即可。

基於這一假設,Conflux首先設立規則將區塊們整合爲有向無環圖(DAG):每個區塊都需要引用一個它的父區塊的邊(Parent Edges),每個區塊也可以引用發生在它之前的,還沒有被引用過的區塊的邊作爲他們的引用邊(Reference Edges),父邊和引用邊確定了各個區塊之間的先後關係,實現了DAG的整體框架,增加了同一時段一起被處理的區塊的數量。相較於比特幣一次只能處理一個區塊的低效模式而言,DAG結構大大提升了公鏈的速度。

然而DAG不能顯示同一時段產生的不同區塊之間的順序(即區塊全序),爲進一步完善區塊排序機制,Conflux團隊引入了GHOST算法、拓撲排序,並提出了Epoch概念,將細化排列區塊全序的步驟拆分成了四步:

(圖中實線箭頭指向父區塊邊,虛線箭頭指向引用區塊邊)
  1. 確認樞軸鏈(Pivot Chain):Conflux改採用GHOST算法,即選擇擁有最多子區塊的區塊作爲樞軸鏈(Pivot Chain)上的區塊,然後再採用同樣的算法將它之後的區塊納入樞軸鏈。如上圖所示,區塊A和區塊B都是創世區塊的子區塊, 雖然區塊B之後的的鏈是最長鏈,但區塊A擁有更多的子區塊(5個),所以GHOST算法會選擇區塊A作爲樞軸鏈上的區塊。樞軸鏈即確定整個公鏈方向的主鏈,Conflux團隊表示GHOST算法讓樞軸鏈和樞軸鏈以外其他分叉鏈上的區塊,都對確認樞軸鏈做出了貢獻,這樣就可以進一步保障由誠實節點確定的樞軸鏈的安全性,除非攻擊者的算力超過了50%。
  2. 排列分叉鏈的區塊:在確認了主鏈之後,爲了讓所有節點對區塊全序產生共識,Conflux又提出了“時段”(Epoch)概念,每個樞軸鏈上的區塊,都對應某一時段,分叉鏈上區塊的時段,由產生在它之後的第一個引用它的樞軸鏈區塊決定。如下圖所示,區塊D的時段屬於Epoch E,因爲區塊E是最先引用D的樞軸鏈區塊。
  3. 時段(Epoch)內排序:Epoch內的區塊,都產生於同一時段,這些區塊之間的順序,由拓撲排序(Topologically Sorting)來決定,如果兩個區塊的排序一樣,那就根據他們的哈希ID來排序。
  4. 交易(Tx)排序:此時,每個區塊之間的順序已經確定了,Conflux按照區塊順序給交易排序。區塊內部的交易順序由交易自己在區塊出現的順序來確定。

(樞軸鏈區塊E確認分叉鏈區塊D和區塊F的時段(Epoch))

3、安全性分析和性能檢驗

在區塊全序和交易全序確認之後,Conflux還設定了規則來應對公鏈容易面對的交易問題和雙花問題:

  • 交易問題:衝突交易和重複打包是最常見的交易問題。如下圖所示,Tx2(X轉8個幣給Y)和Tx3(X轉8個幣給Z)屬於衝突交易,因爲X的賬戶裏只有10個幣,所以這兩筆交易只能實現一筆;而另一種問題如Tx4(Y轉8個幣給Z)所示,Tx4被重複打包到了區塊B和區塊G當中。當出現這類交易問題時,Conflux只承認在全序中位置靠前的那一筆交易,讓排序靠後的衝突交易無效化;
  • 雙花問題:Conflux防止雙花的思路和比特幣基本一致。由於Conflux中的交易順序是由樞軸鏈決定的,攻擊者要進行雙花交易,就需要改變樞軸鏈上的區塊順序以逆轉已經被確認過的交易。除非攻擊者掌握50%以上的算力,分叉出有更多子節點的鏈來取代樞軸鏈,否則不可能實現雙花。理論上講,Conflux的運行時間越長,受到這類攻擊的概率越小。

此外,Conflux團隊還在Amazon EC2上搭建了原型系統,運行了10,000個帶寬爲20Mbps的Conflux節點,用控制變量法來測試在區塊大小、出塊率變化之下,Conflux、GHOST和比特幣的吞吐率和交易確認時間。

結果顯示,儘管區塊大小和出塊率發生了變化,Conflux(下圖中以藍色三角線表示)都能實現100%的高區塊利用率,它有能力去處理所有的區塊,鮮少遺漏掉分叉中的區塊,減少了出塊時的資源浪費,實現了更大的吞吐量。此外,Conflux可實現分鐘級別的確認時間(即用戶高度相信區塊全序不會改變所需要花費的時間),然而和其他共識一樣,區塊越大,確認時間也會變長。

(不同區塊大小或出塊率對應的各共識機制的區塊利用率)

Conflux團隊以帶寬和用戶數量作爲變量,對Conflux的可擴展性做出了測試。測試結果顯示:Conflux可以實現5.68GB/h的吞吐量,即如果參考比特幣網絡在現實中的交易量,Conflux可以提升公鏈的每秒處理量至6400tps。Conflux團隊認爲:限制區塊鏈可擴展性的瓶頸已不再是共識機制,而是網絡帶寬與節點算力了。

尋弊索瑕的一點,我們認爲Conflux在證明區塊鏈性能的過程中,過分樂觀地假設了交易之間不衝突(即假設節點打包的都是獨一無二的交易),忽略了被重複打包的交易對真實交易處理量的影響,如果Conflux希望在未來實現大規模應用的話,這是一個有待完善的方面。

Conflux在實現原理上也有一些顯著的問題點。首先樞軸鏈的確認依賴區塊數量而不是重量,而DAG上數量基本可以靠刷,兩根樞軸鏈數量相近時看上去樞軸鏈會經常變動(搖擺);樞軸鏈的搖擺又會引發時段的搖擺,時段的搖擺會對排序造成影響,並且影響所有後續規則的前提條件。如果重量就是數量,那其實還是要靠算力去支撐安全性。其次對於交易的確認依舊是分鐘級而且是基於概率的,並且帶寬是個大麻煩,重複交易要麼無法廣播,要麼將會掛滿整棵樹,帶寬的需求是幾倍甚至是幾十倍。這些問題的存在都讓Confulx的實現存在現實的困難。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章