如何內行地評價公鏈(一)從真正的不可能三角談起


最近幾期,Conflux 計劃推出一系列的科普文章,從一些簡單的技術原理開始,幫助你們辨別一些項目宣傳的概念中,哪些概念是可能實現的,哪些概念若是要實現,是須要有妥協的。安全

在第一期,咱們從區塊鏈的「不可能三角」談起,談一談若是要追求極致的效率,究竟要犧牲什麼。目前在區塊鏈媒體中,有一個流傳很廣的概念叫「不可能三角」,即效率、安全、去中心化三者不可並存。和「不可能三角」出現一樣頻繁的概念,是「不可能三角」被公鏈某個項目打破。在一些媒體宣傳 Conflux 的時候,也曾經使用過這個說法。網絡

不過,Conflux 從未在官方宣稱「打破不可能三角」,咱們認爲這並非一個嚴謹的概念。只能說,這個概念被提出來的時候,尚未人把這三件事情同時作好,並無人經過嚴謹的分析證實它不可能。工具

今天,咱們來介紹另外一個不可能三角。不管一個區塊鏈是公有鏈仍是聯盟鏈,是 PoW 仍是 PoS, 是採用中本聰共識仍是 BFT 仍是其餘的什麼方式,都繞不開它。這個不可能三角包括三個目標。(爲了便於理解,咱們避免採起嚴謹的形式化語言去定義它,而是大概描述一下想法與思路)post

1. 所有節點同步與驗證

在公鏈網絡中,公鏈網絡的正確性與安全性依賴於一些節點的背書。例如,在比特幣或以太坊中,根據協議,每個礦工挖出區塊時,要保證新區塊和歷史上的每個區塊每筆交易都是正確的。也就是說,比特幣礦工出塊時,在爲以前全部的區塊進行正確性背書。在 EOS 中,超級節點經過簽名對區塊的正確性背書。咱們這裏稱爲「參與共識的節點」。區塊鏈

「所有節點同步與驗證」要求每個被確認的交易,都獲得過全部參與共識的節點(攻擊者除外)的同步與驗證。spa

這個目標是和安全相關的。咱們想象一個場景,有一我的想經過僞造無效簽名,製造非法交易,盜走你的資產。若是隻有一小部分參與共識的節點同步和驗證了這個交易,而其餘節點不一樣步這個交易,直接採信那一小部分節點的判斷結果。若是這樣的話,將一筆非法交易混入交易歷史的可能性,就會高於每一個參與共識的節點都進行同步和驗證。兩者的安全性是不同的。flux

2. 超高吞吐率

最終確認交易的平均吞吐率超過 11000 TPS 稱之爲超高吞吐率。 (每筆交易的大小按 250 字節計)資源

3. 低帶寬要求

對於每個參與共識的節點,網絡帶寬的最低配置要求不高於 20 Mbps (2.5 MB/s)。rem

這個目標是和去中心化相關的,參與的門檻越低,能參與共識的人就越多,越有利於去中心化。get

以上就是這個不可能三角的三個目標。緣由理解起來也很簡單,若是一個節點只有 20 Mbps 的帶寬,那麼每秒只能下載 2.5 MB 的數據,大約是 10000 筆交易。若是網絡中最終確認交易的平均吞吐率超過 11000 TPS, 這個只有 20 Mbps 帶寬的節點是沒有能力同步和驗證每一筆交易的。

那麼面對這個困難,作出取捨的方案又有哪些呢?

1. 放棄全節點同步與驗證

在這些方案中,Sharding 是一個很著名的解決方案。Sharding 方案的大致思路是,整個區塊鏈在邏輯上分出若干個 Shard, 將沒有關聯、互不衝突的交易分到不一樣的 Shard 中去, 每一個 Shard 由一部分礦工負責同步和驗證。對於礦工來講,不須要爲其餘 Shard 中的交易正確性負責。

Sharding 方案是一個提升吞吐率的思路,但這個思路犧牲了一部分的安全性。畢竟,若是有一我的想經過僞造簽名,製造非法交易盜竊你的資產,全網中每個節點都幫你防範非法交易,和只有一小部分節點幫你防範非法交易,兩者的安全程度是不一樣的。不過,對於只是存個零花錢的帳戶地址,相對於安全性,可能用戶對交易成本更敏感。因此這一方向是很是有探索價值的。

但若是用 Sharding 方案下的 TPS 和別人全節點同步與驗證下的 TPS 比,就很不科學了。


另一個思路是,經過零知識證實或可驗證計算等密碼學工具,容許一個節點沒必要同步每個交易,只須要同步區塊頭及一些密碼學的元素,也能夠驗證一個區塊的 Merkle Root 是正確的。固然,這個思路上有不少坑須要去解決,若是有機會,咱們會寫一篇文章展開討論一下。

2. 放棄高 TPS

這裏的放棄高 TPS,是指在現有的網絡條件下,放棄 10000 TPS 以上的吞吐率。Conflux 保留了去中心化和安全性,就須要保留全節點同步與驗證和低帶寬要求,以實現家用網絡條件也能夠當礦工,每一筆交易都獲得了每個礦工的驗證。若是要保留這兩點,效率是有天花板的。

3. 低帶寬要求

在一些共識機制中,普通用戶不參與對交易的同步與驗證,而是經過一些方式選出少數特殊的節點來進行共識。這時,咱們能夠假設每個參選的節點都準備了足夠的計算機資源,例如更好的 CPU, 更大的硬盤, 更大的網絡帶寬。這時,也就不必將「最低配置要求」設的很低了。

下一次,若是您看到一個項目聲稱大於 10000 TPS,甚至是喊出無限可擴展的口號時,您就須要來看一下在這個不可能三角中,它放棄了哪一角。是放棄了第一點仍是第三點?若是是放棄第一點,項目是採用了 Sharding 方案?仍是作出了其餘的修改?這種修改會不會帶來安全性問題,如何解決?若是是放棄第三點,高 TPS 是否基於更高的網絡帶寬要求?仍是說在網絡帶寬無限的條件下無限可擴展?


順便推薦一下咱們的線下活動~在本期Conflux Meetup(杭州站),咱們爲你們邀請到了Conflux CTO伍鳴、Conflux研究總監楊光、TOP Network Co-founder & CEO Steve Wei來一塊兒聊一聊《下一代公鏈和DApps生態前景》。
點擊報名

相關文章
相關標籤/搜索