樹圖(Conflux)的技術核心與整體運用架構

買賣虛擬貨幣
• 現狀:只有極少數的區塊鏈交易會產生衝突• Conflux將大幅提高併發塊的的處理效率  · 利用樂觀處理併發區塊的想法,採用有向無環圖結構組織區塊  · 利用對主鏈的共識來幫助對有向無環圖中所有區塊的一致排序• Conflux能將公鏈系統的吞吐率提升到每秒上千次交易,且能夠在分鐘級別的延時內確認交易• Conflux將打破共識機制的效能瓶頸

Conflux的整體執行架構

1. 區塊鏈目前所面臨的問題

區塊鏈行業的問題之一(1/2)比特幣無併發處理能力

在比特幣生成區塊時,礦工就要確定一個嚴格的交易順序:

區塊鏈行業的問題之一(2/2)比特幣無併發處理能力

區塊鏈交易僅極少產生衝突,那麼如何提升交易處理的效率?

區塊鏈交易之間極少產生衝突的情況。沒有衝突的交易之間可以按任何順序排序;對於所有在併發的區塊中的交易,如果它們之間沒有衝突,為什麼不都執行呢? 

在 Conflux 中,所有區塊構成一個有向無環圖結構 
2. 有向無環圖的設計與解釋

如何在有向無環圖中確認一個區塊的排序(1/2)

每個區塊有一個“父邊”,指向它的父親區塊;所有的區塊和它們的父邊構成一棵樹 

如何在有向無環圖中確認一個區塊的排序(2/2)

這個引用邊主要是記錄和表達哪些區塊的生成早於當前的區塊 

如何將一條鏈對區塊的全序達成共識 (1/2) 

根據主鏈,透過一個確定性的規則,決定一個一致的區塊的全序 

如何將一條鏈對區塊的全序達成共識 (2/2) 

有向無環圖中產生一個新區塊的規則

如何在有向無環圖中對區塊的全序達成共識 (1/3)

全序達成共識的規則:

1. 在主鏈上的每一個區塊就確定了一個Epoch
2. 在分叉上的區塊屬於哪個Epoch,是由第一個產生在它之後的主鏈區塊所在的Epoch決定的

如何在有向無環圖中對區塊的全序達成共識 (2/3)

全序達成共識的規則:

1. 首先按照Epoch的順序來給區塊排個序
2. 再按照拓撲排序來確定區塊的順序
3. 根據區塊頭雜湊值來打破平局

如何在有向無環圖中對區塊的全序達成共識 (3/3)

3. 為什麼Conflux可以防止雙花攻擊

為什麼Conflux的設計能夠成功地防止雙花攻擊?

宣告1:除非攻擊者能夠改變主鏈,否則無法完成逆轉交易(1/2)

• 若攻擊者想成功對交易2(在區塊2中)發起雙花攻擊,它需要將創世區塊作為父親,並且寄希望於各個節點對排序達成的共識中,惡意的區塊在區塊 B 前面。

宣告1:除非攻擊者能夠改變主鏈,否則無法完成逆轉交易(2/2) 

• 然而,只要主鏈未發生變化,則不良/惡意區塊一定被列於較後的epoch;所以攻擊者無法對較早的epoch中的交易完成雙花攻擊

宣告2:若攻擊者未超過50%的算力,則無法改變主鏈

• 改變主鏈中老區塊的理論分析

假定要轉換主鏈上的區塊A

那麼所有攻擊者產生的塊都會在A’的子樹下面,然而所有誠實的節點所產生的塊都會在A的子樹;攻擊者則需要超過50%的算力才能讓A’的子樹超過A的子樹。

為什麼需要50%的算力來改變主鏈 

有向環形圖的確認機制

Conflux確認機制的設計基於大量且精準的安全性分析 

• 使用者假設:
 攻擊者的算力 -- q
 交易被逆轉所承受的風險率 -- r 

• Conflux首先找到這個交易所屬的Epoch
• 然後找到和這個Epoch相應的主鏈區塊
• 最後再檢查這個主鏈區塊被逆轉的概率是否小於使用者所能承受的風險

4.Conflux的研究評估 

測試Conflux的實驗環境

• 我們搭建了Conflux的一個原型系統,並在Amazom EC2上執行1萬個Conflux節點來做實驗
• 為了模擬公網上真實網路環境,我們限制每個節點的網路頻寬是20Mbps
• 實驗中我們調整不同的區塊大小和出塊率:
 區塊大小範圍: 1MB ~ 8MB
 出塊率速度範圍: 5s ~ 80s
• 對實驗已達成的結果進行測算,並確認遞延時間
• 與其他協議的實驗表現進行對比,包括比特幣、Ghost協議

Conflux的實驗成果 – 現階段成果

• Conflux 可達 2.88G/小時 處理 每5秒產生4MB大小區塊的內部環境下,在每5秒產生4MB大小區塊的實驗引數下,可以每小時處理 2.88G 的交易資料量~3200 TPS
• 在一致環境下,效率為Algorand 的3.7倍
• 效率為比特幣/GHOST的12.5倍

Conflux的實驗成果 – 區塊的使用率

• 更高的出塊速度和更大的區塊大小 à在比特幣/GHOST中有效區塊的比例更低
• 在處理4MB+5s的設定下,比特幣僅有 8% 的區塊被保留,其他區塊作為孤塊被丟棄
• 相對而言,Conflux中的所有區塊都能出塊

可信交易的確認時間(1/2)

• 高效出塊
 - 區塊之間會快速建立聯絡
 - 快速及時的確認
• 在每5秒產生4MB大小的區塊的實驗引數下,確認時間平均約 10 分鐘
• 比特幣無法在高出塊率/大區塊下保證安全

可信交易的確認時間(2/2) 

• 假設攻擊者算力增加,則使用者需要等待確認的時間會更長
• 使用者等待確認時間越長,則交易被逆轉的機率會呈指數下降

Conflux頻寬的延展性

• Conflux在頻寬為20Mbps時無法處理每2.5秒4MB的區塊
• 而網路頻寬為整個系統吞吐率的瓶頸
• 如果將網路頻寬假設提高到——40Mbps
• 10000 個 Conflux 節點在 40Mbps 的頻寬下,可以成功對每2.5秒4MB的實驗設定下達成共識
  · 達到5.76GM/小時的吞吐
  · 最高達6400筆交易每秒 (比特幣的交易規模)
• 在6.3分鐘的延遲時間內確認交易 

在更多全節點情況下的延展性 (4MB+5s) 

• Conflux 能擴充套件至20,000個全節點
• 全節點的數量成倍增加時,網路傳播延遲時間 d 將呈線性增長

相關研究 

免責聲明:

  1. 本文版權歸原作者所有,僅代表作者本人觀點,不代表鏈報觀點或立場。
  2. 如發現文章、圖片等侵權行爲,侵權責任將由作者本人承擔。
  3. 鏈報僅提供相關項目信息,不構成任何投資建議

推荐阅读

;