EOSIO 的出現引領了區塊鏈技術從實驗室向大規模商用發展,隨着更多高性能區塊鏈協議涌現,信任經濟的雛形已現。高性能區塊鏈的大規模部署帶來了新的問題:全節點的運維成本居高不下,應用數據無法高效同步,數據無法在多鏈之間共享。高性能區塊鏈亟需引入輕量級的節點方案,爲信任經濟進一步發展掃清最後的障礙。

「EOS 弧光」

EOS 原力開發團隊於近日發佈了首個高性能區塊鏈輕節點方案--EOS 弧光。該方案基於 Golang 開發,爲 EOSIO 這類高性能區塊鏈協議引入輕量級節點解決方案。與基於 nodeos 啓動的 EOSIO 全節點不同 ,「EOS 弧光 」輕節點僅需驗證區塊頭 , 無需執行區塊中 Action。

高性能區塊鏈的新瓶頸:

1、運維費用高

EOSIO 的區塊頭結構支持輕量級的節點,但是當前 EOSIO 社區中並沒有一個可靠的輕量級節點實現。

在比特幣白皮書中,中本聰提出不運行一個完整的網絡節點也是可以進行支付驗證。對於區塊鏈數據可以採取剪枝的方式進行進行壓縮, 老的區塊可以只保留區塊頭和節點關注的交易數據,即使在白皮書發佈的 2008 年,也可以在當時常見的微型計算機的內存中存儲全部區塊頭數據。

隨後的討論中, 中本聰認爲比特幣網絡最終可能只存在 10 萬左右的全節點,這些全節點具備生產區塊的能力,而同時存在着數百萬的輕量級客戶端,這些客戶端可以收發交易,雖然不能生產區塊,但仍能自己驗證支付,而不需要依賴別的節點進行驗證。

EOSIO 的區塊鏈結構同樣支持輕量級節點,在其網絡與應用中,同樣需要大量的輕量級節點,特別的, 區別於比特幣的設計,EOSIO 全節點對機器性能的要求十分苛刻,並且由於其本身的 Token 增發與 RAM 擴容機制,這一要求不會隨着機器物理性能的提升而得到緩解。

在 EOSIO 網絡中,一個全節點對於機器性能、網絡和運維的要求是非常高的,目前 EOSIO 網絡中可用的全節點很少 , 這意味着當前 EOSIO 網絡結構不夠去中心化 , 對整個網絡的穩定性產生了很大影響 , 同時這也提高了鏈上應用的開發和部署難度。

以 EOS 網絡(chainID:aca376f206b8fc25a6ed44dbdc66547c36c6c33e3a119ffbeaef943642f0e906)爲例(2020 年 1 月中旬),RAM 總量爲 174G,已分配的內存爲 74G 左右,雖然實際使用的數據很少,但作爲一個全節點至少要配置超過 64G 的內存,否則會出現因爲內存讀寫未命中而導致事務執行失敗,即使是重放區塊,也可能導致區塊重放速度無法跟上新區塊生產速度,這也意味着目前的大多數計算設備無法滿足 EOSIO 節點的需求。

另一方面,目前 EOSIO 區塊數據十分龐大,這給節點的維護和存儲帶來很大挑戰,同時重放區塊消耗時間過長,在一些主流性能服務器上,完整的重放區塊需要近一個月時間。即便使用快照功能可以在幾個小時時間之內恢復 RAM 狀態但依然不能解決節點消耗過大的問題。有的開發者甚至感嘆高 TPS 是「僞命題」,認爲今後節點部署甚至會花費一年時間,以至於沒有新的全節點出現。

2、開發難度及成本高

雖然 EOSIO 的插件式架構可以允許節點拓展功能 , 但是節點對機器性能的要求較高 , 同時 EOSIO 基於 C++開發插件有較高的開發門檻 , 因此 EOSIO 的拓展工具很少 , 這也間接提高了 DAPP 的開發難度。

早期的很多 DAPP 的查詢與索引服務依賴於 EOSIO 的 history 插件和 mongoDB 插件,但隨着節點區塊數據的增多,這樣的 history 節點或 mongoDB 數據庫產生了很大的性能問題,雖然社區也提出了一些解決方案,但是由於其往往依賴於全節點,故而成本頗高,使得很多此類服務的價格比較高昂,這給 DAPP 的開發和運營帶來了很多額外成本。

中本聰對於比特幣網絡結構的預測同樣適用於其他的區塊鏈網絡,除了全節點外,EOSIO 的網絡也同樣需要大量符合成本博弈的輕量級節點。

3、跨鏈需求無法滿足

目前公有鏈發展的一個重要方向是跨鏈功能的支持 , EOSIO 將支持基於 IBC 來添加側鏈 , 目前啓動 IBC 需要基於全節點以使用戶可以獲取基於 Merkle Tree 的證明數據 , 但是由於搭建一個全節點的成本過高 , 即使要求少數驗證者和釣魚者啓動全節點也是一件非常難以實現的事,這會使得某些理論上的支持方案從經濟成本上不成立,如果跨鏈的運行僅僅依賴於少數的全節點提供的服務 , 那麼整個系統將會十分脆弱。

綜合以上問題 , 我們需要一個足夠輕量級的 EOSIO 節點實現 , 輕節點在保證對區塊的驗證同時 , 應當易於拓展和二次開發。

「EOS 弧光」技術原理:

「EOS 弧光」輕節點不會處理每一個事務,僅僅驗證區塊與區塊頭的有效性,同時確認其區塊不可逆。

EOSIO 對節點高需求的一個主要原因是其內存(RAM)狀態,這些狀態十分龐大且沒有在區塊中驗證,所以任何一個想要獲取任意狀態的節點都需要完整的重放一遍 EOSIO 的區塊,雖然可以通過快照功能復原節點,但即使對於保持同步的節點,一旦出現故障其復原時間也比較漫長。同時由於 EOSIO 鏈上的事務比較繁忙,峯值時可達 4000 TPS 左右,同步實時的 EOSIO 區塊也會對機器的要求較高。

不處理每一個事務意味輕節點的大部分工作可以並行完成,而且也可以從任意區塊高度開始同步,在目前的原型實現中,輕節點只需佔用很少的計算資源即可完成驗證。

不處理每一個事務雖然允許輕節點佔用很少的資源,但是也使得輕節點無法提供內存(RAM)狀態,而在 EOSIO 中幾乎所有的狀態都在內存中,一些操作(EOSIO 稱之爲 Action)也需要通過執行事務來觸發,爲了解決這個問題,這就需要一些斷言機制來保證節點僅僅基於區塊數據就可以獲得 EOSIO 的狀態,這可以通過 EOSIO 狀態斷言合約和狀態靜態斷言合約來實現。

根據 EOSIO 輕節點所負擔的角色的不同,我們將 EOSIO 輕節點分爲區塊節點和區塊頭節點,前者包含全部或部分 EOSIO 區塊,後者只包括 EOSIO 區塊頭數據。

考慮到 EOSIO 還在不斷的發展中 , 輕節點也需要跟隨其進行迭代 , 所以輕節點的設計應該儘可能的和 EOSIO 保持同構 , 其 API 與操作也應該儘可能與 nodeos 保持統一 , 當然 , 輕節點不含內存狀態 , 所以一些 API。如:get table 等。

「EOS 弧光」使用場景:

1 真正的去中心化錢包:

目前的 EOSIO 錢包往往基於中心化的第三方提供的數據,這些數據並沒有被驗證,這與比特幣的錢包有很大區別,這些錢包如果脫離了第三方提供的服務就無法正常使用,同時在這些錢包中,用戶無法得到準確的交易執行回饋,如果要確認交易是否完成,只能依賴於其他服務,例如區塊瀏覽器來確認交易完成,這實際上存在的很大安全風險。

基於「EOS 弧光」我們可以將輕節點嵌入進錢包中,這樣每一個錢包都是一個輕節點,這時錢包可以獨立去驗證交易是否成功,即使在不安全的網絡環境中也可以安全的使用。

2 可信實時的區塊數據服務:

很多 DAPP 需要實時的鏈上數據,尤其是去中心化交易所等響應短且重視安全性的應用,需要可以安全、確定的獲取鏈上實時的狀態,特別是 EOSIO 的不可逆區塊判定,由於目前的共識算法尚處於初步完成的階段,區塊進入不可逆狀態的時間間隔較長,這也就意味着很多應用需要先樂觀的接受未進不可逆的區塊,以事後驗證的方式避免狀態不一致,這樣的邏輯需要編寫節點插件,並部署全節點,這會增加很大的 DAPP 開發與運營成本。

基於「EOS 弧光」,可以把輕節點以庫的形式納入到已有的數據服務中,輕節點基於 Golang 開發,對於後端開發比較友好且不存在門檻,同時因爲輕節點完整的實現了共識算法,所以實現可信實時的區塊數據服務十分方便。

3 高性能跨鏈服務:

如果需要實現 EOSIO 鏈與其他鏈的跨鏈交互,往往需要同時實現兩條鏈的輕節點,「EOS 弧光」可以很簡單的嵌入其他服務或節點中,並且能夠獨立的驗證節點,可以很好的支撐此類應用。

事實上,「EOS 弧光」最初的開發動機即是作爲跨鏈服務中的一環,比如,目前很多鏈基於 Cosmos SDK 開發,一個很常見的架構就是把基於 Cosmos SDK 的鏈作爲結算鏈,把基於 EOSIO 的鏈作爲計算鏈,通過實現 Cosmos 的 IBC 協議來完成跨鏈計算結果結算。在這個系統中,我們只需在結算鏈節點節點中集成「EOS 弧光」,使每個結算鏈的節點都是計算鏈的輕節點,通過原有結算鏈的共識機制使各個結算鏈節點持有的計算鏈區塊數據(只需考慮不可逆塊的 ID)達成共識,這樣就實現了計算鏈的數據回溯到結算鏈的過程。

「EOS 弧光」技術路線圖

「EOS 弧光」由 EOSC 社區開發團隊 EOS 原力開發,目前開發工作主要分爲三個方向:節點實現、兼容全節點 API 和計算性能優化,EOS 原力團隊已經實現了初步的版本,可以完成區塊數據的同步和驗證,同時發佈了技術路線圖:

2020 Q1 : 實現區塊不可逆塊判定算法,完善區塊存儲實現 , 兼容 nodeos 的 block db
2020 Q2 : 支持其他節點從輕節點同步區塊與事務,完善 API 接口以儘可能兼容 nodeos
2020 Q3 :優化併發計算能力 , 加速同步過程,支持 EOS-VM 以實現部分 Action 的執行

「EOS 弧光」已全部開源,Github 地址:https://github.com/eosforce/eos-light-node