eth 1.x 與無狀態節點介紹

買賣虛擬貨幣
本篇文章將剖析 eth 1.0 存在的各項問題,並介紹 Ethereum Foundation 提出的 eth 1.x 升級相關改動能如何改善當前以太坊的困境。什麼是 eth 1.x以太坊 2.0 的研究行之有年,迄今(2020/06 )距離全面啟動仍需要 2–3 年的時間,並且 eth 2.0 將被部署為由信標鏈(Beacon Chain)與多條分片鏈( Shard Chains)構成的獨立區塊鏈,而 eth 1.0 需要經過改動與升級方能成為 eth 2.0 中的其中一條分片鏈。這意味著現在執行的以太坊 1.0 區塊鏈需要進行改動,並且在未來的 5~10 年保持運作,持續發展。而 eth 1.x 即為以太坊 1.0 升級版本的代稱。eth 1.x 的首要目標旨在解決現在區塊鏈日益增長的資料負擔(編者注:即資料規模負擔),在區塊鏈大小持續增長的情況下保持 eth 1.0 網路的彈性。以太坊 1.0 的弊端與問題在開始介紹以太坊 1.x 之前,必須先認知到目前(2020/06)以太坊存在的問題,如此方能充分了解 eth 1.x 被提出的背景與旨在解決的痛點。
Problem (A):網路趨於中心化自 2020/05 以來,Gas Price 的節節攀升導致開發者與高頻率使用者叫苦連天,其背後原因除了以太坊使用者數量的增加,亦是由於耗費大量 Gas 的智慧合約互動行為比例提升(單純轉帳 ETH 的佔比被稀釋),使得以太坊網路持續壅塞。面對這樣的情景,礦工社群於 2020/6/19 UTC 投票透過,將每個區塊的 Gas Limit 從 10,000,000 提升到 12,000,000。

截至 2020/06/30,儘管每個區塊的 Gas Limit 提升至12,000,000,合約交易佔比的提升依舊讓每個區塊所能容納的交易數十分有限,在 Etherscan 上可以檢視到以太坊的 TPS(Transactions Per Second)在 Gas Limit 提升前平均落在 12 左右(低於號稱的 15 TPS);在 Gas Limit 擴增後,TPS 亦沒有出現明顯的提升。

可能有些人會想說既然 12,000,000 Gas Limit 依舊壅塞,那怎麼不再往上提升?原因是 Gas Limit 的提升將導致每個區塊的處理時間變長,進而造成 Uncle Block 的數量增加,使得網路的共識機制變不健康,礦工必須耗費大量額外運算來進行處理。

此外,由於獨立節點與小型礦池更容易挖到 Uncle Block,長期下來出塊獎勵的期望值降低將導致部分節點入不敷出,進而離開網路。如此將讓以太坊網路變得更加中心化,更向大型礦池集中,危害了網路的長期健康與安全性。

Problem (B):狀態爆炸

隨著越來越多的智慧合約被部署,以及大量的合約互動行為,導致以太坊網路需要儲存的「狀態」大小正以「等比級數」增長。狀態的增長即反映在節點的儲存空間大小上。

筆者於另一篇文章中摘要介紹了以太坊網路中的節點: 全節點與輕節點:以太坊節點面面觀(10)文科生也該知道的區塊鏈技術知識

在 2019 年年底,全節點的每月增長大小「小於 20 GB」;到了 2020/06,隨著 Gas Limit 的提升,全節點的每月增長大小「逼近 40 GB」。狀態不斷加速增長的結果會對以太坊網路的效能帶來衰退與網路健康的損害。未來全節點的執行將會變得更加艱難,可能導致網路變得越來越「中心化」。(編者注:此處作者的計算有點粗疏了,以 Etherscan 上的資料來看,Gas Limit 提升以後,以太坊區塊的平均大小上升到 30 多 KB(在提升以前平均是 20 多 KB),即以 30 KB 計算,單月的區塊資料增長量為 30×4×60×24×30 = 5,184,000 KB,換算過來就是 5 GB。而狀態資料的增長更不可能有幾十 GB 之巨。)

此外,區塊驗證的難度將隨之提升,導致整體網路的延遲與 TPS 的進一步下降。

儘管這個過程如同溫水煮青蛙,在數年之後才會導致以太坊網路出現巨大的安全性問題,然而為了避免走到那步田地,早在數年前便開始以太坊 2.0 的相關研究與開發。

以太坊的未來

Vitalik 於 2020/3/19 在推特上分享了他對於以太坊未來 5~10 年發展觀點的路線圖,主要由以下四個部分構成:

eth 1.x other
eth 1.x statelessness(無狀態性)
eth 2 phase 0 prep(核心路徑,聚焦於eth 1 ➔ eth 2 合併,移除 PoW)
eth 2 phase 2 and beyond

圖中間的橫軸代表時間線,沿著時間軸是一個從 Phase 0 啟動,到 Phase 1,再到「eth2 ➔ eth2 合併」的「核心路徑」。要完成合並有三個先備條件:

eth 2 phase 1
eth2 ➔ eth2 合併的規範與實現
eth 1.x statelessness(無狀態性)

其中,「eth 1.x statelessness(無狀態性)」可說是對於 eth2 ➔ eth2合併最至關重要的一個條件,本文將以「無狀態性」為主軸做相關的介紹。

狀態爆炸對以太坊網路的影響

由於以太坊區塊鏈的本質是一臺依靠礦工維護的去中心化大型「狀態機」,隨著區塊數量的增加更迭狀態,不斷向前移動。以太坊的完整「狀態」包含所有個人帳戶和餘額的當前狀態,以及在 EVM 中部署和執行的所有智慧合約的整體記憶體。

以太坊網路在每個區塊高度都只有唯一一個獲得全網所有節點共識的「狀態」,這個「狀態」在每一個新區塊會產生變動並隨著區塊接至區塊鏈上。

礦工在執行交易運算時,必須依據交易內容至節點內以「Merkle-Patricia Trie 」資料結構組成的狀態樹中更改相關的狀態值,再重新計算出每個樹狀節點的 hash 值,算出新的「Merkle Root」,生成新的狀態樹。

截至 2020/06,當前的以太坊網路中約有 5 億個狀態值,總狀態大小約為 10 GB,狀態會隨著網路上的帳戶與智慧合約數量增加而按比例增長。因此,如果以太坊繼續獲得主流採納,狀態可能會在未來數年持續爆發性增長。不斷擴大的狀態主要會對節點造成兩大影響:

節點讀取狀態耗時增加,交易處理速度變慢

目前每個新區塊礦工大約需要新增或修改 3000~6000 個狀態值。由於礦工處理每一筆交易時都必須要讀取節點資料庫中狀態的相關資訊,當狀態數量持續增長,在狀態樹中查詢到指定狀態值的耗費時間就越長。

建構新的狀態樹耗時更長,區塊驗證速度減慢

當礦工將交易處理完時,必須建構一個由新的狀態組成的 Trie 結構狀態樹,當中涉及大量的 hash 值運算。計算完 Root Hash 方能建構出新的 Block Header,打包出新區塊。

小結

綜合來說,持續增大的「狀態」與「節點大小」將導致新的全節點啟動成本大幅提升:對於「儲存空間」的需求與「同步時間」的增加可能會進一步導致網路中全節點數量的減少。

此外,以太坊網路的整體效能下降也在所難免。以太坊隨著狀態樹查詢與運算耗時的增加以及越來越多的合約交易,TPS 可能會進一步下降,導致網路變得更加壅塞,迎來更高的 Gas Price 競逐。

eth 1.x 的提出

對於以太坊 1.0 升級的相關研究最早可以溯及到 2018/10 在捷克布拉格召開的 Devcon IV,會議談論到以太坊 2.0 無法在未來 3~5 年內完全取到以太坊 1.0 的所有功能,因此 eth 1.0 仍必須保持安全穩定執行,於是乎無數的核心開發人員開始研究一系列延長 eth 1.0 壽命以及與 eth 2.0 介接的解決方案。

既然狀態的持續增大對於以太坊網路的健康帶來重大影響,解決方案之一便是「消除以太坊網路對狀態的需求」。細看 Vitalik 於 2020/3/19 釋出的以太坊未來路線圖中即可看到一系列的解決方案:

上述的路線圖是較為精要的版本,以太坊研究員 Griffin Ichiba Hotchkiss 於 2020/4/2 在 Ethereum Blog 分享了他對於目前 eth 1.x 研究開發方向的理解,整理出下圖的「技能樹」 :

由於細節族繁不及備載,本文只會挑出其中幾個核心來做說明。有興趣的朋友可以參考並持續關注 Ethereum Blog 中的相關文章:

The 1.x Files: The Updated Stateless Tech Tree (April 2, 2020)
The 1.x Files: A Primer for the Witness Specification (May 4, 2020)
The 1.x Files: EIP 1559 and the Ethereum Improvement Horizon (June 16, 2020)(Up to date)

eth 1.x 的目的

簡而言之,eth 1.x 的核心目的有兩個:

(A) 延長 eth 1.0 的壽命
在區塊持續增長的情況下維持 eth 1.0 區塊鏈的安全、穩定與彈性,讓人們可以選擇僅下載部分的狀態,在較便宜的硬體上執行節點。

(B) 與 eth 2.0 介接
由於 eth 2.0 中的分片(shards)將是無狀態的,因此「無狀態」將是參與 eth 2.0 區塊驗證的先決條件。eth 1.0 要與 eth 2.0 相容的話勢必得支援無狀態運作,方能順利過度,與 eth 2.0 介接。

為了達成這兩個目的,在技能樹圖最右側的終點我們可以看到「無狀態以太坊 Stateless Ethereum」。然而,「無狀態」的以太坊這個詞可能有些不夠精確,因為整個以太坊網路就是基於狀態而存在的。

具體來說,是找到一種方式讓以太坊網路中的部分節點可以將「保留整個以太坊狀態的副本」這件事變為一個選項,而非必須。因此,要讓現行的以太坊網路能夠支援沒有儲存完整全網狀態的輕量級節點:「無狀態節點」參與到網路中的新區塊驗證。

而為了讓無狀態節點能夠進行驗證,以太坊 1.x 提出了以下三項主要改動,我們將逐一來進行介紹:

(1) 區塊見證機制
(2) EVM 改動
(3) 資料結構轉換為二進位制(Binary)

(1) 區塊見證機制

無狀態節點如何參與驗證

簡單來說,作法是:擁有全網狀態資訊的「完整狀態節點 Full State Node」在打包新區塊時會一併產生「區塊見證 Block Witness」,讓沒有儲存全網狀態的「無狀態節點」能藉由區塊見證提供的資訊對新區塊進行驗證。

什麼是「區塊見證 Block Witness」

前面提到,以太坊的資料結構是由約 5 億個狀態值所構成的 Merkle-Patricia Trie。然而,其中大約只有 0.1% 狀態值(約 50 萬個)會隨著區塊高度產生變化,如:個人帳戶的 ETH 餘額、合約底下記載的每個地址持有 Token 數量。99.9% 的狀態值如:智慧合約的程式碼、Uniswap 手續費 0.3% 的引數等資訊一但智慧合約部署完成便不會再進行更動。

由於一個新的區塊(目前為 1,200 萬 Gas Limit)至多隻能容納 571 筆交易,其涉及的狀態值更改是十分有限的。那麼一個沒有儲存所有狀態值的無狀態節點只要向擁有完整狀態的節點請求涉及交易的相關狀態值與未涉及到的 hash 值其實即可算出 Merkle Root 進行驗證。

如下圖所示,假設底層的 14 個菱形代表以太坊網路中所有的狀態值,而新區塊中僅有一筆交易,針對綠色的狀態值進行更改,那麼無狀態節點其實只需要 1 個綠色的原狀態值以及紫色的 Hash 值與其它未變動的 6 個Hash 值資訊即能透過 4 次 Hash 值計算,算出新的 Root Hash(Merkle Root),而不需要擁有所有的 14 個狀態值來進行 9 次 Hash 值計算。

這些為了完成 Root Hash 計算所需要向擁有全網狀態資訊的「完整狀態節點(全節點)」請求的「最小資訊量」即為「區塊見證 Block Witness」,包含了狀態 Trie 中「不涉及變動的部分 Hash 值」與「涉及變動的原狀態值」。如此一來,沒有儲存完整全網狀態的「無狀態節點 Stateless Client」將可以藉由請求而來的「區塊見證」資訊計算出新的 Root Hash。

為了便於讓無狀態節點參與驗證,目前的最新研究方向是「區塊見證」將可能成為「區塊標頭 Block Header」的一部分,隨著新挖出的區塊一併廣播給全網節點,讓無狀態節點不用再發起額外的「區塊見證請求」即能進行驗證區塊的動作。

透過這樣的方式,無狀態節點即能參與以太坊網路中新區塊的驗證。

礙於篇幅,我們在這篇文章只會做概念性的闡述,具體的實作細節先不展開細說,想更進一步瞭解的朋友可以參考我上方附上的連結以及以太坊部落格中的其它相關文章。

(2) EVM 改動

狀態值的更改和運算都是在 EVM 中進行,同理,區塊見證也必須經由全節點的 EVM 透過運算來生成。EVM 的改動目標與成本和激勵機制息息相關,主要包含耗費 Gas 的估算以及如何降低對節點間廣播延遲的影響。

區塊見證 Gas 計算(Witness Gas Accounting)

由於區塊見證必須由全節點花費額外的計算資源來運算生成,因此會產生相應的 Gas 成本,而這個成本目前比較可行的方式是由交易的發起者來進行負擔。至於如何讓交易發起者在傳送交易時即能準確估算額外的 Gas,以設定精確的 Gas Limit,目前仍在研究中,尚未產生明確的定案。

另外,考慮到在同個區塊中可能有一個狀態值被不止一筆交易進行更改,因而產生重複支付 Gas 的情形,這部分可能會成為礦工額外的獎勵費用。

智慧合約程式碼分塊(Code Merkleization)

區塊見證的目的是為了讓無狀態節點能夠進行新區塊的驗證,其中必定包含了智慧合約相關的運算。然而,無狀態節點沒有儲存包含智慧合約程式碼在內的狀態,所以當無狀態節點要進行一筆智慧合約交易的狀態運算時,便需要一併擁有包含智慧合約程式碼的在內區塊見證。

這時會有另外一個問題,智慧合約洋洋灑灑的程式碼中可能只有其中的一小片段是與該交易運算相關聯的,因此「程式碼分塊」的概念被提出。

「程式碼分塊」是一種拆分智慧合約位元組碼(Bytecode)的方式,將智慧合約中與涉及交易相關的程式碼拆出,作為區塊見證中的一部分,一併提供給無狀態節點讓其做運算驗證之用。

其目的便是避免呼叫到不必要的程式碼,免於生成龐大的區塊鏈見證導致運算時間的增加及節點間傳遞溝通的延遲。

(3) 資料結構轉換為二進位制(Binary)

根據以太坊研究員 Igor Mandrigen 進行的實驗(Binary Tries Experiment),若將以太坊資料結構從目前的十六進位制(Hex)更改為二進位制(Binary),每個區塊的區塊見證大小將能從 800~3,400 kB縮小至 300~1,400 kB,如此將大幅減低區塊見證在網路中傳播的延遲時間,讓區塊見證機制能夠執行得更加理想。

然而從 Hex 轉換為 Binary 具體的實作方式以及過度策略目前仍未有完全的定論,有興趣的朋友可以持續關注 Ethereum Foundation 釋出的相關訊息。

無狀態以太坊Stateless Ethereum

介紹至此,透過引入「區塊見證機制」、對「EVM」進行必要的改動,以及將資料結構轉換為「二進位制」,已能勾勒出 eth 1.x 的大致樣貌。

支援無狀態節點的 1.x 網路,將能夠對以太坊 1.0 的區塊鏈網路產生下方几點關鍵影響:

i. 對新加入節點更加友善

隨著全網狀態的膨脹與區塊高度的提升,啟動一個新節點的同步時間會變得越來越長(截至 2020/06,啟動一個新全節點需要同步至少一週的時間),超長耗時的原因是因為全節點的同步必須從創世區塊開始對每一個區塊進行驗證與同步的動作,而驗證區塊必須要擁有該區塊高度的全網狀態,因此在每一個區塊同步狀態是目前同步節點的極大瓶頸。

無狀態節點時代的到來將能夠大幅改善同步區塊的痛苦過程,未來僅需憑藉「區塊標頭」與「區塊見證」即能完成區塊的驗證,同步節點體驗的改善將能讓更多人有意願且能夠負擔執行節點的成本(時間與硬體資源)。

ii. 輕節點得以自力更生

在現行的以太坊網路中,輕節點不具備獨立驗證新區塊與驗證交易的能力,因為輕節點沒有儲存驗證交易需要的 merkle proof 資訊,因而必須向鄰近全節點發出 p2p request 進行請求,但輕節點現在願意提供支援的佛心全節點變得越來越少。

無狀態機制將能幫助輕節點依靠自己維護的部分狀態(自己帳戶與合約的餘額等資訊),以區塊標頭和區塊見證獨立進行驗證,不求於人。

iii. 節點網路安全性提升

由於區塊鏈網路的安全性取決於能參與新區塊驗證的節點總數量,對網路的攻擊成本將隨著節點總數量的增加而提高,能有效地低系統被擊潰的風險。

隨著新節點啟動成本的降低以及大量的輕節點投入到新區塊的驗證中,將讓網路的整體安全性大幅提升。

iv. 介接 eth 2.0

最後一點也是最核心的一點,前面提到 eth 2.0 將會是由核心的信標鏈與多條分片鏈構成,全網的狀態將被多個分片分開儲存。由於每條分片各自擁有不同的狀態,並且沒有儲存其它分片的狀態資訊。因此對每條分片來說,其它條分片都像是「無狀態節點」。

為了能夠在多條分片鏈間有效驗證與同步,必須依靠「無狀態的驗證機制」。因此現在的 eth 1.0 未來要能順利成為 eth 2.0 的其中一條分片鏈,升級為無狀態的 eth 1.x是至關重要的一個步驟。

結論

透過以上介紹,相信讀者們應該對於現行的 eth 1.0 升級到 eth 1.x 需要進行的改動,以及改動完成後的未來有更清晰的認識。

在 eth 1.x 升級完成後,人們將能用便宜的硬體執行自己的無狀態節點(輕節點),更多能夠參與驗證的輕節點可以進一步維護全網的安全性。

擁有無狀態驗證機制的 eth 1.x 方能順利和 eth 2.0 的信標鏈與其它分片鏈介接,正式讓以太坊網路進入由無狀態驗證機制與分片技術構築成的輕量化 eth 2.0 未來。

以上,若有任何

A. 我寫得不夠清楚的地方 B. 撰寫上改進的建議 C. 希望我能夠撰寫分享的區塊鏈技術知識內容

都非常歡迎在底下留言回覆。希望我的文章能幫助到更多像我一樣想學習區塊鏈技術與知識的朋友。如果您覺得讀完有所收穫,也希望能

· 給我 50 claps
· 分享給您的朋友們

謝謝大家!
也歡迎大家閱讀區塊鏈技術知識系列的其它篇文章:https://medium.com/pelith/blockchain-technical-overview-8c2a643424fa

免責聲明:

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

推荐阅读

;