EOS.IO將迎來史上最複雜硬分叉升級

買賣虛擬貨幣

前言:

EOS.IO開發團隊Block.One於2019年5月15日釋出了1.8.0-rc2的EOS.IO版本,我們認為,1.8.0是EOS.IO開源以來最重要的版本,沒有之一。這一版本將奠定EOS.IO今後透過硬分叉升級快速迭代的基調,也會讓整個區塊鏈行業重新審視硬分叉升級的重要性。同時,所有的使用者,錢包,交易所,DAPP都會受到影響。

2019年年初,一些媒體開始報道EOS.IO程式碼提交次數下降的問題,我們EOS原力團隊曾經公開回應過:EOS.IO每天都有多個開發者在提交程式碼,這些開發內容在不同的分支裡提交,並且需要經過測試以後再合併到主線。今天我們要提到的1.8.0-rc2就是此類情況,從2019年年初甚至更早就開始進行了開發,直到2019年5月15日1.8.0-rc2釋出。 

接下來我們將詳細解釋此次更新何以如此重要。

版本號:1.8.0

Github:https://github.com/EOS.IO/eos/releases/tag/v1.8.0-rc2

一、1.8.0-rc2有哪些重要的改進

1 擴充套件性提升與程式碼重構:

在這個版本中我們看到了大量的提交, 主要集中在程式碼重構和執行緒安全化兩個方面:

首先的程式碼重構,很多人往往不關心這些既沒有增加功能也沒有提升效能的程式碼修改, 但是從開發的角度看,這些其實構成後續開發的重要基礎,我們可以看到,自年初以來, Block.One的核心開發者一直在改善EOS.IO的程式碼結構,並且從設計層面上逐步在建立一個抽象層, 最明顯的是EOS.IO.cdt的完善,這些構成了EOS.IO的框架,不同於很多在一開始就給出了龐大架構的團隊,Block.One的開發團隊一貫以務實且自低向上的思路開發EOS.IO.

在1.8.0版本中, Block.One的開發者拆分了很多之前的巨無霸型別,剝離了散落在各處的一些複雜邏輯,比如`pending_block_state`相關的狀態管理,就從`block_header_state`中剝離出來. 還有之前略帶“壞味”的transaction traces, 也在這次重新整理.

另一個方面是關於多執行緒, 在最近一段時間有很多關於執行緒安全性的提交,為下一步實現多執行緒相關開發做準備,Block.One團隊在2019年的開發中對多執行緒非常重視,此次重構後將很更好的實現EOS.IO白皮書裡描述的多執行緒,屆時TPS會上升到一個新的臺階。

眾所周知, 中大規模C++軟體的多執行緒開發一直是一個“深坑”,為了在引入平行計算的同時保證EOS.IO的穩定性, Block.One團隊並沒有急於進行多執行緒相關新特性的開發, 而是耐心的排查程式碼中的執行緒安全問題,完善基礎架構支援, 同時在特定的適合併發的獨立模組,如chain api以及p2p模組引入對應的多執行緒實現.

2 提升鏈安全性: 在這個版本中,  Block.One團隊修正了之前遺留的一些資源計算問題, EOS.IO中資源相關的邏輯很多,並且極為分散,為了提升鏈效能並避免節點進行不必要的計算, EOS.IO中新增了很多資源相關的特化邏輯, 這也造成了很多特定場景下使用者資源計算的不明確, 對於EOS.IO鏈來說, 這帶來了很多起潛在的安全性問題, 前一階段曝露的由延遲交易所觸發的阻塞交易問題, 很大程度上就是資源檢查不完備的問題.

另外, 某些場景下資源計算的問題也會導致使用者權益上的損失, 所以這方面的修改勢在必行.

3 智慧合約安全

智慧合約安全困擾了EOS.IO社羣很久,DAPP開發者在過去一年的實踐中發現了大量的問題,Block.One團隊吸收了這些問題並且做出了極大的改進,此次更新對智慧合約開發者更友好。

舉例來說, 對於DAPP開發者來說, 一個好訊息就是千呼萬喚的` GET_SENDER ` API終於要引入EOS.IO中了, DAPP開發者可以透過這個API判定當前Action是否是透過inline action機制觸發的, 據此可以迴避大量的基於合約觸發inline action的攻擊手段. 這個更新,可以一定程度上部分解決了困擾社羣已久的隨機數問題,需要注意的是, 即使透過這個api可以遮蔽當前的很多攻擊手段, 固然攻擊者的攻擊成本會大幅提高,但是不意味著DAPP開發者可以高枕無憂, 對於開發者來說安全問題永遠需要注意, 沒有甚麼一勞永逸的銀彈。

4 硬分叉升級機制

這方面的更新可以使得未來的硬分叉升級更加高效的同時使得硬分叉升級過程中不影響使用者使用體驗。

近一段時間, Block.One其實開發了非常多的新功能,包括上面提到的幾個功能, 但都沒有在過往的更新中出現,一個很大的原因就是開發者必須保證EOS.IO的相容性, 節點可以選擇不升級節點版本, 顯然這會極大的阻撓EOS.IO的發展, 這次1.8.0的版本與以往的一個最大區別是這個版本不相容前面的版本, 也就是所謂的“硬分叉”, 在這個版本之前EOS.IO並沒有應對硬分叉的機制, 硬分叉的過程會對使用者的使用帶來很大影響, 為了使以後的更新不會像這一次一樣造成很大影響, 這次更新中新增了一系列硬分叉升級機制, 為的是以後的硬分叉更新可以更加平滑和安全.

在EOS原力過往的更新中, 原力團隊也遇到了同樣的問題, 所以引入了鏈配置功能, 透過這個機制向鏈新增特性的開啟區塊高度和鏈維護狀態, 以此解決硬分叉中的過渡問題, Block.One的對策與此類似, 透過引入protocol feature來解決這個問題, 與原力強調簡單通用的解決方案不同, Block.One的feature設計希望更加完備的解決特性的相容問題, 具體的設計可以參見 #6831. 

這裡可以判斷Block.One以後的開發過程中會有比之以往更多的硬分叉, 未來EOS.IO的進展會明顯快於以往.

二、 EOS.IO硬分叉影響

EOS.IO第一次使用硬分叉方式來升級,因此帶來的影響也是非常巨大的。

1 節點: 大部分節點應該沒有經歷過硬分叉升級,如果嚴格按照硬分叉的要求來,所有節點需要重放一遍區塊,按現在的節點配置,大多數節點最少需要數天才能完成區塊重放,當然,還有一種比較偷懶的方法,就是直接使用其他機構提供的快照,但是這樣的壞處是如果太多核心節點尤其是BP如果這樣更新, 則會影響整個鏈的安全性。

2 使用者:交易所,錢包,區塊瀏覽器,DAPP等所有的P2P節點都會暫停一段時間,其他所有的外部訪問資料都會中斷,使用者感知非常明顯。

當然,區塊鏈本身並沒有停止,只是為了安全著想,暫停外部和鏈的互動。

3 DAPP開發者

理論上鍊的硬分叉不會影響合約的執行, 但是考慮到很多DAPP採取了半中心化的架構, 有大量的邏輯在鏈外執行並與鏈互動, 這樣一次硬分叉勢必帶來一定的風險.

三 、硬分叉好處和風險

1 好處

在網際網路時代,產品迭代是家常便飯,幾乎每週開發者都會發布新的版本,使用者也習慣第一時間更新升級享受更多的功能和服務。

而此前硬分叉升級在區塊鏈行業幾乎非常少見,原因是大部分割槽塊鏈由去中心化的自由開發者組成,因此開發進度緩慢,節點極其分散,導致硬分叉升級更加麻煩,以比特幣為例,2010年的溢位漏洞導致了導致了1840億的BTC憑空建立出來,中本聰第一時間釋出了新的版本硬分叉升級,避免了比特幣的危機,後來中本聰離開社羣後,比特幣由社羣接管,硬分叉升級很難達成共識,因此很少使用硬分叉升級的方式。

而Block.One團隊是一個專業開發組織,開發進度比以往的區塊鏈專案得到了指數級的提升,因此快速迭代適應使用者需求成為了主流。以目前大多數公有鏈的技術架構來看,如果要實現大規模的功能升級,硬分叉升級的方式不可避免。

2 風險

如果分叉的過程中超級節點作惡,分叉過程會變得十分危險

如果一部分節點聯合起來拒絕升級,那麼大概率會出現兩個EOS。

Blockone做了一定的防範措施:儘管Block.One在2019年上半年進行了大量的開發,有很多的新功能,但是此次更新只包括一些必要的功能和安全性問題修復,等到feature上線後硬分叉會變得更加順利。

四、本次硬分叉注意事項

這是EOS.IO面臨的第一次硬分叉更新,而且是沒有在一個有效的升級機制下進行的硬分叉更新,需要節點和社羣付出更多的努力。

EOS原力團隊從主網啟動開始進行過多次大規模的硬分叉升級以迭代新的功能,這裡我們分享一下硬分叉升級中的一些經驗: 

首先, 準備越多則更新越順利, 在更新之前, 節點必須做好備份工作, 當前EOS.IO節點資料很大, 節點備份時也一定要考慮恢復備份資料時的效率, 備份資料與節點一定要在同一內網中, 不要依賴於他人的備份, 否則出現問題時傳輸備份資料的時間會很漫長, 最好的方式是直接建立節點的備份節點.

其次, 需要注意控制節點的互動, 在更新的過程中, 整個EOS.IO網路會處於一個節點半相容狀態, 此時如果有人提交觸發不相容邏輯的交易到已經更新過的BP, 則會導致未更新的BP立即分叉, 雖然這次硬分叉的功能本身就是基於feature來管理是否生效的, 同時執行邏輯出錯的交易一般不會在p2p網路中傳遞, 但是很難排出完全不會出現整個網路分裂的可能性, 所以在更新過程中節點尤其是超級節點要注意控制互動, 首先是要控制http api的開放, 可以適當的開啟幾個rpc節點, 但rpc節點與出塊幾點間不能有直接的p2p連結, 同時重要的節點與其他外部節點間也不要有直接的p2p連結, 這樣可以在出現硬分叉時保證關鍵節點執行. 

最後, 需要控制好更新次序, 如果基於一個有序的更新次序, 即使有硬分叉可能, 多數節點也不會受到影響, EOS.IO中的節點往往分為資料節點、出塊節點、RPC節點和同步節點, 透過控制節點的互動可以很容易的為出塊節點門建立一個“綠區”, 遮蔽外部對核心的出塊節點的影響, 此時出塊節點可以進行升級, 在此之後,逐步更新出塊節點與外部的同步節點, 同時應該為社羣中的資料節點和其他只讀節點預留一個更新視窗期, 社羣和開發者的節點可以一次類推, 先透過建立遮蔽的同步節點建立一個安全區, 再更新內部節點, 最後更新同步節點,最終當大部分節點以及全部的核心節點更新完畢之後, 再更新RPC節點, 進而完成整個網路的更新.

其實以上談到的手段和部署規範早已是老生常談, 只不過很多節點的維護者並沒有嚴格的按照規範規劃節點的部署, 可以預見, 如果節點的維護者還不完善節點部署, 那麼在這次更新中將會是很多問題的一個集中爆發點.

總之, 越多準備則越加順利, 很多問題無法預測, 所以節點在正式更新之前應當進行一次或者多次演練, 這樣會讓EOS.IO的這次升級更加穩定.

五、硬分叉的意義是甚麼

硬分叉本應該是一個再普通不過的技術詞彙,然而不同目的的硬分叉會產生不同的結果,因此社羣對於硬分叉概念有著非常不同的理解。

從技術角度來講:硬分叉會導致新的規則不相容以前的規則,如果獲得社羣所有人的支援,那麼大概率不會有甚麼影響。

從社羣角度來講:硬分叉時如果出現不同的共識和技術路線,那麼大概率社羣會分叉成兩個公有鏈,各自支援不同的路線。

2016年,以太坊(ETH)出現了DAO危機,創始人Vitalik決定回滾交易,社羣有一部分人不同意回滾交易,認為區塊鏈賬本不可篡改,拒絕回滾,因此誕生ETC(以太坊經典)

2017年,比特幣(BTC)的擁堵使得大區塊的支持者迫不及待要改進比特幣,但是社羣裡有不同意見,因此誕生了比特幣現金(BCH)

2018年,EOS主網啟動時,EOS原力團隊提出了不同的治理路線,隨後誕生了EOS原力(EOSC)

我們可以看到,Block.One團隊做了大量的準備

六、本次硬分叉的重要性

本次硬分叉是EOS.IO誕生以來最重要的版本,所有基於EOS.IO開發的公有鏈如EOS,EOSC,ENU,Telos,BOS,Worbli等均需要採用硬分叉升級。

Block.One作為業內水平最高的開發組織之一,開發思路都非常大膽,此次新增了硬分叉機制,意味著後半年還會至少有兩三次硬分叉。

以往的區塊鏈都非常害怕硬分叉,只有BCH社羣維持著半年一次的硬分叉升級,EOS原力也進行過多次硬分叉升級,隨著節點和社羣認知的發展,硬分叉將不再是一個令人恐慌的詞彙,反而會成為區塊鏈進步的方式,即使出現新的分支也是有意義的探索。

此次硬分叉升級將會給EOS.IO帶來更多的功能和易用性,可以預計,如果想要使得公有鏈適應時代的發展,未來硬分叉的升級方式將會成為主流。

七、 關於近期社羣關於BM跑路的傳言

近期又有傳言稱BM開發了新的專案,引發了EOS.IO社羣的恐慌。

從EOS.IO的角度來講,主網啟動後Block.One在EOS.IO上付出了極大的努力,持續高效的開發將EOS.IO打造成了最強大的去中心化應用軟體平臺。同時,社羣也有EOS原力,EOS Canada  BOS Core這樣一直在公鏈開發一線深耕的團隊,即使BM離開社羣也不會影響EOS.IO的發展。

EOS原力團隊追蹤著世界上大部分主流公有鏈的實際開發進展,無論是開發速度還是程式碼質量,BlockOne在EOS.IO開發上的表現遠超其他主流公有鏈開發團隊,和1.8.0-rc2一樣重要的分支還有多個都在開發中,讓我們拭目以待。

免責聲明:

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

推荐阅读

;